Більшість багів в програмному забезпеченні завдають маленькі незручності, які користувач може обійти, але були й такі випадки, коли звичайна помилка впливала на мільйони людей в тому чи іншому плані, або навіть спричиняла травму або смерть.
Нижче представлені десять прикладів тих випадків, коли наслідки багів були величезними в тому чи іншому плані:
10. Тераком-25 (Therac-25)
Тераком-25 - апарат для променевої терапії, який використовується найчастіше для лікування онкологічних хворих. В апарата було два режими роботи. У першому режимі апарат направляв промінь електронів прямо на пацієнта маленькими дозами і нетривалий час. У другому режимі апарат направляв інтенсивний промінь електронів на металеву «мета», що дозволяло фактично перетворити промінь в рентгенівське випромінювання, яке потім досягало пацієнта.
У попередніх моделях Тераком для другого режиму роботи були фізичні запобіжники, які забезпечували наявність металевого відбивача, без якого промені високої енергії могли б потрапити помилково прямо на пацієнта. У новій моделі фізичні запобіжники були замінені «запобіжниками» в програмному забезпеченні.
На жаль, в програмі був баг: іноді під час автоматичних перевірок на безпеку траплялося «арифметичне переповнення». При такому баге система використовує в обчисленнях занадто велике число, яке вона не може обробити. Якщо в цей момент оператор налаштовував апарат, запобіжники не спрацьовували, і металева пластина не поміщалася на потрібне місце. В результаті на пацієнта потрапляли промені, інтенсивність яких була в 100 разів більше, ніж потрібна. У шести випадках пацієнти отримали передозування радіацією, 4 з цих випадків закінчилися смертю потерпілого.
Розробники не передбачили одне: інфіковані гравці могли переміщуватися в інші локації гри і передавати це захворювання іншим гравцям - що і сталося. Скільки саме персонажів загинуло від цієї хвороби невідомо, але цілі ігрові міста спорожніли - всюди на вулицях міст валялися трупи ігрових персонажів. На щастя, смерть персонажа в World of Warcraft неостаточна, і незабаром «чума» закінчилася - адміністратори гри перезавантажили сервера і застосували програмну «латочку», яка виправила баг. Цікаво, що реакція гравців на зараження і заражених була схожа на реакцію людей в подібних ситуаціях в реальному житті.
Причина аварії ніяк не пов'язана з багом в програмному забезпеченні, але її можна було б запобігти, якби не баг в програмі, яка відповідає за систему оповіщення в центрі управління енергосистемами. Дві частини системи «змагалися» за один ресурс і не могли вирішити конфлікт (помилка проектування під назвою «стан гонки»), через це система оповіщення зависла і перестала обробляти сигнали тривоги. На жаль, зупинка системи оповіщення була «тихої», тобто вона не оповістила нікого про свою поломки. Не було вироблено ніяких звукових або візуальних сповіщень, які б попередили працівників про зупинку системи, які повністю спираються на подібні оповіщення для отримання інформації про статус енергосистеми. Наслідки аварії широко висвітлювалися в мас-медіа: багато території залишалися без електрики протягом декількох днів, що вплинуло на промисловість, надання комунальних послуг і зв'язку. Вважається, що навіть кілька смертей були результатом аварії.
7. Подія на авіаносці USS Yorktown
У світі розробки програмного забезпечення є кілька широко відомих багів з якими стикаються програмісти і які вони повинні обов'язково враховувати при написанні коду. Одним з таких багів є «поділ на нуль» - коли проводиться обчислення, в якому будь-яке число ділиться на нуль. Таке обчислення неможливо зробити, принаймні, якщо не використовувати вищу математику, через що більшість програм, що встановлюються на суперкомп'ютери або навіть на кишенькові калькулятори, пишуться таким чином, щоб враховувати таку можливість.
На сором програмістів рушійна система USS Yorktown повністю зупинилася, залишивши авіаносець безпорадним в воді на 3 години, коли один з членів екіпажу корабля ввів нуль в бортову систему управління базами даних, а система спробувала провести операцію ділення на нуль. Програмне забезпечення було встановлено в ході проекту по використанню комп'ютерів для зменшення необхідної кількості людей в екіпажах деяких кораблів. На щастя, корабель в цей час брав участь в навчальних маневрах, і не був в розпалі битви, інакше наслідки помилки були б плачевними.
6. Вибух на Транссибірському газопроводі
Цей пункт треба сприймати з часткою скептицизму, так як це можливо чутки, але, якщо це правда - це прекрасний приклад навмисно залишеного бага, який спричинив за собою велику аварію.
Під час Холодної Війни, коли відносини між США і СРСР були, м'яко скажемо, напруженими, ЦРУ, нібито, навмисно ввів кілька багів в програмне забезпечення, що продається канадською компанією, яке використовувалося для управління газопроводом в Сибіру. ЦРУ визнало, що Росія купувала це програмне забезпечення у канадської компанії в спробі отримати технологію США, і це було б чудовою нагодою дати СРСР неповноцінну технологію.
Такі операції були пізніше відкриті в результаті розсекречені «Досьє Farewell» (Farewell Dossier), де крім усього іншого, стверджувалося, що в газопроводі були встановлені браковані турбіни. Колишній міністр військово-повітряних сил США, Томас Рід (Thomas Reed) стверджує, що в систему було введено кілька багів, які б не проявили себе під час тестування, але привели б до аварії під час безпосереднього використання. Налаштування насосів і клапанів були змінені, що призвело до позаштатного тиску в газопроводі, що в свою чергу призвело до найбільшого неядерній вибуху в світі.
Ветеран КДБ, Анатолій Медецький спростовує варіант диверсії, на його думку, вибух стався через помилки, допущені при будівництві. На щастя, від вибуху ніхто не постраждав, так як він стався на віддаленому від цивілізації ділянці території.
5. Потенційний початок ядерної війни під час Холодної Війни
Станіслав Петров - офіцер, який служив в секретному командному пункті, неподалік від Москви, в якому була розташована система раннього попередження. В одну з ночей, коли Петров був на чергуванні, йому надійшло попередження про те, що США запустило 5 міжконтинентальних балістичних ракет Мінітмен (Minuteman). Згідно з доктриною обопільного знищення, переважаючою під час Холодної Війни, у відповідь на атаку США, СРСР повинен був помститися такий же атакою.
Якщо атака була справжньою, офіцер повинен був швидко відреагувати на неї. Однак, Петрову здалося дивним, що США атакувало б таким малою кількістю боєголовок: хоча і ці ракети б завдали величезної шкоди і великі людські втрати, вони б не змогли завдати непоправної шкоди СРСР. Крім цього, радари, розташовані на землі нічого не показували, хоча вони і не могли помітити нічого за лінією горизонту через кривизни Землі, що пояснило б затримку в наземних радарах.
Іншим фактором, що вплинув на рішення Петрова, було те, що сама по собі система раннього попередження була ще «сирий» і іноді помилялася. Офіцер зважив всі фактори і вирішив, що тривога була помилковою. Незважаючи на те, що сам Петров не міг запустити у відповідь ядерний удар, якби він передав рекомендацію атакувати вищестоящого керівництва, це б спричинило початок руйнівної ядерної війни. Рішення Петрова було правильним, неважливо чи була вона прийнята, спираючись на досвід, інтуїцію або просто удачу.
Пізніше було визначено, що програмне забезпечення раннього попередження зреагувало на сонячне світло, відбите від висотних хмар, який вона сприйняла як запуск ракет.
4. Шкідлива захист від копіювання на дисках Sony
Війна між корпораціями шоу-бізнесу і піратами не припиняється. Як тільки придумуються нові способи захисту від копіювання та безпечного поширення мультимедіа, з'являються і нові шляхи обходу подібних методів захисту.
Руткіт досяг своєї мети, але через те, що він намагався сховатися від користувача, це дозволило і іншому шкідливому програмному забезпеченню приховувати свою присутність на комп'ютерах користувачів. Погано продумана імплементація і зростаюча впевненість користувачів, що Sony BMG не мало права намагатися непомітно управляти їх комп'ютерами, призвело до того, що схема провалилася. Багато компаній, що займаються комп'ютерною безпекою, класифікували руткит, як шкідливий код, а Sony BMG довелося відповідати за свої дії в суді і відкликати партію аудіодисків з руткітом.
3. Баг в ракетному комплексі Петріот (Patriot)
Під час операції «Щит пустелі» (Desert Shield) США взяло на озброєння ракетний комплекс «Петріот» для захисту від ракетних ударів і ворожої авіації - в цьому випадку, від іракських ракет SCUD. Керуючий програмне забезпечення ракет Петріот використовує швидкість своєї мети і поточний час для передбачення траєкторії руху цілі. З огляду на, що цілі можуть досягати швидкості в 1.5 км / с, ці обчислення повинні бути дуже точні.
На той момент в програмному забезпеченні, відповідальному за ведення мети, був присутній баг, через який з часом внутрішній годинник поступово відходили від істинного значення часу. Баг вже був відомий, і його можна було вирішити регулярної перевантаженням системи, і скиданням значення внутрішнього годинника.
Відповідали за це люди, не зовсім зрозуміли що таке «регулярна» перезавантаження і система працювала протягом 100 годин. Коли Ірак запустив свою ракету в бік аеродрому США в Дахране (Dhahran), система Петріот визначила запуск. Однак, на той час, внутрішній годинник вже були зміщені на 0.34 секунди, тому, обчислена ПО траєкторія виявилася помилковою і система порахувала, що ворожої ракети більше не існує і скасувала спробу збиття ракети. Ракета долетіла до своєї мети, в результаті чого 28 американських солдатів загинуло, і 98 було поранено.
Складно сказати чи було успішне вирішення проблеми результатом проведеної роботи або сама проблема була спочатку перебільшена - швидше за все, і те й інше.
Баг може принести набагато більше шкоди, якщо враховувати що UNIX використовується у вбудованих системах, в яких зв'язок між «залізної» і софтверної частиною набагато сильніше - наприклад, в роботах, які використовуються на конвеєрах, в годиннику, в Рутер і т.д.
Сподобалося? Поділися новиною з друзями. )