За долгий период существования IT в прод уходила не одна тысяча багов. Большинство из них были безобидными и исчезали после следующего патча. Но отдельные приводили к катастрофам. Буквально. Анализируя тему крупных техногенных провалов, я удивился одному: за большинством этих инцидентов стояли не сложные цепочки событий, а маленькие, пустяковые на первый взгляд детали. Вот тут что-то забыли дописать, тут понадеялись, что пронесет, там решили что «и так сойдет». А итог — многомиллионные убытки, удар по репутации и потерянные жизни.

Рассмотрим на примерах, почему не стоит недооценивать баги.

Pentium FDIV: баг, стоивший Intel $475 миллионов и репутации

В 1994 году корпорация Intel была на вершине мира. Однако осенью того же года разразился скандал, который серьезно ударил по репутации. Математик Томас Найсли из Линчбергского колледжа обнаружил, что процессоры Pentium иногда ошибаются при выполнении операции деления чисел с плавающей запятой. Ошибка была ничтожно малой и проявлялась на очень редких комбинациях чисел, но для научного и инженерного сообщества сам факт ее существования был неприемлем.

Техническая причина крылась не в программном обеспечении, а в самом «кремнии». В блоке вычислений с плавающей запятой (FPU) использовался алгоритм деления SRT, который для ускорения операций обращался к специальной таблице констант, зашитой прямо в кристалл. Из-за производственного дефекта пять из более чем тысячи ячеек в этой таблице оказались пустыми (незапрограммированными). Когда алгоритм в ходе вычислений натыкался на такую пустую ячейку, он получал ноль вместо нужного значения, что и приводило к накоплению погрешности в конечном результате.

Ошибка возникала только при определенных комбинациях числителя и знаменателя. Один из самых известных примеров, который позволял любому пользователю проверить свой процессор Pentium — это деление 4 195 835 на 3 145 727. Если выполнить это действие в любом приложении, использующем сопроцессор для вычислений с плавающей запятой (например, в стандартном калькуляторе Windows), можно было легко выяснить, подвержен ли чип этой проблеме.

Правильный результат: 4 195 835 / 3 145 727 = 1,333820449136241002

В шестнадцатеричном формате, который использует процессор, эти числа выглядят так: 4 195 835 = 0x4005FB и 3 145 727 = 0x2FFFFF. Именно цифра 5 в числе 0x4005FB инициировала обращение к тем самым «пустым» ячейкам таблицы.

Результат на дефектном Pentium: 4 195 835 / 3 145 727 = 1.333739068902037589

Изначально Intel попыталась преуменьшить проблему, заявив, что среднестатистический пользователь столкнется с этой ошибкой раз в 27 000 лет. Эта реакция вызвала бурю негодования. Такие гиганты, как IBM, которая на тот момент была крупным клиентом Intel, публично остановили поставки компьютеров на базе Pentium. Медиа и ранний интернет подхватили горячую тему для обсуждений. Под давлением общественности, Intel была вынуждена пойти на беспрецедентный шаг — объявить о полной и безоговорочной замене всех дефектных процессоров для любого желающего.

Это был первый случай в истории, когда компания отозвала компьютерный чип. В своем годовом отчете за 1994 год Intel указала, что списала до налогообложения 475 миллионов долларов на покрытие расходов, связанных с заменой и утилизацией этих микропроцессоров.

Случай, с тех пор известный как Pentium FDIV bug, навсегда изменил индустрию. Он показал, как дорого может стоить попытка скрыть или преуменьшить проблему. Для самой Intel это стало уроком, который привел к кардинальному пересмотру процессов тестирования и валидации аппаратного обеспечения.

Снижаем цены на выделенные серверы в реальном времени

Успейте арендовать со скидкой до 35%, пока лот не ушел другому.

Подробнее →

Spectre и Meltdown: когда уязвимость встроена в процессор

В начале 2018 года группа исследователей из Google Project Zero и нескольких университетов раскрыла информацию о двух уязвимостях. На этот раз проблема была не в коде операционной системы или прикладной программы. Уязвимости, получившие названия Spectre и Meltdown, скрывались в самой архитектуре практически всех современных процессоров, включая модели от Intel и AMD. Это означало, что под угрозой находились миллиарды устройств по всему миру — от серверов в дата-центрах до персональных компьютеров и смартфонов.

Причиной появления этих дыр в безопасности стала гонка за производительностью. Для ускорения вычислений современные процессоры используют механизм спекулятивного исполнения — они пытаются предугадать, какие команды понадобятся следующими, и выполняют их заранее. Spectre и Meltdown эксплуатируют именно эту особенность. Если вкратце:

• Meltdown позволял вредоносному процессу читать данные из защищенной памяти ядра операционной системы, разрушая фундаментальную изоляцию между пользовательскими приложениями и ядром.

• Spectre работал тоньше: он заставлял другие, совершенно безопасные программы, спекулятивно выполнить код, который бы они никогда не выполнили в обычном режиме, и через анализ побочных каналов (например, состояния кэша) считать их секретные данные.

Теоретически, любой сайт, открытый в браузере, или любая программа, запущенная на компьютере, могли украсть пароли, ключи шифрования и любую другую конфиденциальную информацию из памяти. Началась экстренная гонка по выпуску патчей. Microsoft, Apple, разработчики ядра Linux, создатели браузеров — все в экспресс режиме выпускали обновления. Однако эти хотфиксы приводили к снижению производительности, порой до 30%. Хотя массовых атак с использованием Spectre и Meltdown так и не было зафиксировано, индустрия потратила миллиарды долларов на аудит, обновление и смягчение последствий.

Mars Climate Orbiter: цена неконвертируемых единиц

История освоения космоса полна как великих триумфов, так и обидных провалов. Один из самых поучительных фейлов случился 23 сентября 1999 года, когда NASA потеряло свой новенький аппарат Mars Climate Orbiter стоимостью 327 миллионов долларов. Аппарат должен был выйти на орбиту Марса для изучения его климата, но вместо этого он вошел в атмосферу планеты и попросту сгорел.

Причина кроется не в сложной технической неисправности или сбое в электронике. Это была банальная ошибка в единицах измерения. Программное обеспечение на Земле, разработанное американским подрядчиком Lockheed Martin, рассчитывало импульс корректирующих двигателей в имперской системе: в фунт-секундах. А бортовое программное обеспечение самого аппарата, написанное в Лаборатории реактивного движения NASA, ожидало эти данные в метрической системе: в ньютон-секундах.

Каждый раз, когда с Земли отправлялась команда на коррекцию курса, бортовой компьютер интерпретировал ее неверно. Коэффициент пересчета между этими единицами составляет примерно 4,45, так что каждая коррекция была в 4,45 раза слабее, чем нужно. В результате этих отклонений, накапливавшихся долгое время, аппарат подошел к Марсу по траектории, которая была на десятки километров ниже расчетной. Вместо того, чтобы безопасно выйти на орбиту, он нырнул в плотные слои атмосферы и прекратил свое существование.

Ранее по меньшей мере два навигатора (операторы, отвечающие за расчет и контроль траектории) обратили внимание на несоответствие между вычисленной и фактической позицией. Было видно, что фактическая высота при выходе на орбиту отличалась от запланированной. Их опасения не приняли всерьез: формально объяснили тем, что они «не выполнили правила заполнения формы для документирования замечаний». Для решения вопроса была созвана встреча с разработчиками программ траекторий, операторами траекторного ПО, инженерами по системам тяги и менеджерами. Был уговор провести маневр коррекции траектории №5 (TCM-5), но в результате его так и не выполнили.

Потеря Mars Climate Orbiter случилась за два с половиной месяца до гибели Mars Polar Lander. Он разбился во время посадки на Марс из-за ошибочно сработавшего датчика. Космическая программа Mars Surveyor '98 полностью провалилась.

Эти неудачи стала для NASA холодным душем. После инцидентов агентство провело полную ревизию своих процедур. Многие проблемы списали на недостаток финансирования (бюджет программы Mars Surveyor '98 был на 30% меньше необходимого). Было введено жесткое правило: во всех миссиях использовать исключительно метрическую систему. Кроме того, были значительно усилены процессы проверки и интеграции данных, получаемых от разных команд и внешних партнеров, чтобы подобные ошибки больше никогда не смогли уничтожить многомиллионную космическую миссию.

Ракета «Ариан-5»: экономия на тестировании приводит к взрыву

История знает немало примеров, когда крошечная программная ошибка приводила к катастрофическим последствиям. Один из самых хрестоматийных случаев — первый полет европейской ракеты-носителя «Ариан-5» 4 июня 1996 года. Пуск, который должен был стать триумфом Европейского космического агентства, обернулся зрелищным взрывом на 37-й секунде полета. Вместе с ракетой были уничтожены четыре спутника миссии «Cluster», предназначенные для изучения магнитосферы Земли.

Причиной катастрофы, стоившей более $370 миллионов, стала ошибка в программном обеспечении инерциальной навигационной системы. Разработчики в целях экономии решили использовать модуль, который отлично зарекомендовал себя на предыдущей модели, «Ариан-4». Однако они не учли, что траектория и динамические характеристики новой ракеты существенно отличаются. Горизонтальное ускорение «Ариан-5» было намного выше и это привело к неожиданным значениям в одном из внутренних счетчиков.

Началось расследование. Комиссии были предоставлены телеметрические данные ракеты, данные траектории (с радиолокационных станций и с постов оптического наблюдения), а также полученная информация с упавших обломков и восстановленной ИСО. Расследование выявило коренную причину сбоя.

Технически проблема заключалась в попытке преобразовать 64-битное число с плавающей запятой, содержащее значение горизонтальной скорости, в 16-битное целое число со знаком. В какой-то момент полета значение стало слишком большим для 16-битного формата и случилось переполнение, затем аппаратное исключение. Система защиты, которая должна была обработать сбой, не была предусмотрена для этого конкретного участка кода, так как разработчики посчитали, что такое большое значение в принципе невозможно. В результате отказал основной бортовой компьютер, а следом и резервный, работавший на том же ПО. Потеряв ориентацию, ракета резко отклонилась от курса, и на 37-й секунде полета произошел взрыв.

Последствия: гигантские финансовые потери, серьезный удар по репутации Arianespace и приостановка программы запусков «Ариан-5». В дальнейшем инженеры внедрили комплексное тестирование системы в условиях, максимально приближенных к реальному полёту.

Boeing 737 MAX: когда «улучшение» приводит к двум авиакатастрофам

История авиации знает немного столь же громких провалов, как история с Boeing 737 MAX. Две катастрофы, произошедшие с разницей в пять месяцев, унесли жизни 346 человек. 29 октября 2018 года разбился рейс 610 авиакомпании Lion Air (189 погибших), а 10 марта 2019 года — рейс 302 Ethiopian Airlines(157 погибших).

В обоих случаях абсолютно новые самолеты входили в неконтролируемое пике вскоре после взлета. Причиной стала новая система улучшения характеристик маневренности — MCAS.

Система MCAS (Maneuvering Characteristics Augmentation System) была создана, чтобы программно компенсировать конструктивные изменения в модели MAX. На самолет установили более крупные и мощные двигатели, которые пришлось вынести вперед и вверх. Это изменило аэродинамику и создало риск слишком сильного задирания носа на больших углах атаки. MCAS должна была автоматически опускать нос самолета, чтобы предотвратить сваливание.

Фатальная ошибка проектировщиков заключалась в том, что система для принятия решения использовала данные только с одного из двух датчиков угла атаки. В обоих разбившихся самолетах этот единственный датчик вышел из строя и начал передавать ложные показания. MCAS, получив сигнал о якобы критическом угле атаки, начинала агрессивно опускать нос самолета перестановкой стабилизатора. Пилоты пытались противодействовать, но система активировалась снова и снова, поскольку была уверена, что спасает самолет от сваливания. Ситуацию усугубило то, что Boeing не сочла нужным подробно информировать пилотов о работе новой системы и не включила ее отработку в программы тренажеров.

После второй катастрофы авиационные власти всего мира остановили полеты всех Boeing 737 MAX. Глобальный запрет продлился 20 месяцев — беспрецедентный случай для современной авиации. Для Boeing это обернулось многомиллиардными убытками, потерей заказов, отставкой генерального директора и огромным ударом по репутации. Расследование выявило серьезные недостатки в проектировании MCAS и процессе сертификации самолета. В итоге Boeing пришлось полностью переписать ПО, задействовав в логике MCAS оба датчика угла атаки и ограничив ее воздействие на управление. Также дополнили программу обучения для пилотов, чтобы они точно знали, как действовать в случае отказа системы.

Therac-25: смертельный луч из-за гонки состояний

Пожалуй, один из самых пугающих примеров программной ошибки. В период с 1985 по 1987 год эта машина, созданная для лечения рака, стала причиной как минимум шести инцидентов, в ходе которых пациенты получили дозы радиации, в сотни раз превышающие терапевтические. Это привело к тяжелейшим радиационным ожогам и, по разным данным, к трем смертельным исходам. Therac-25 из инструмента спасения превратился в оружие.

Метод лучевой терапии сформировался в 1950-х, а настоящий прорыв произошел в 1970-х после появления компьютерной томографии. Она позволила точно определять границы опухолей и уменьшать воздействие радиации на здоровые ткани. Аппараты Therac стали развитием этой идеи: чем выше энергия электронного или рентгеновского луча, тем глубже и эффективнее действие. Цифра в названии аппарата означала максимальную энергию луча в мегаэлектронвольтах. Therac-6, затем Therac-20, и наконец Therac-25, который полностью управлялся программным обеспечением и считался безопаснее благодаря минимальному участию человека.

Летом 1985 года 61-летняя Кэти Ярбро проходила профилактическое облучение области ключицы после удаления опухоли молочной железы. Она должна была получить 10 мэВ — обычную терапевтическую дозу. Но сразу после начала процедуры пациентка почувствовала резкий жар. Оператор удивился: аппарат не мог вызвать боль, а на коже не было повреждений, поэтому женщину отправили домой. Только через несколько дней появились признаки глубинного радиационного ожога. Физик центра пересчитал фактическую дозу: 15–20 тысяч рад. У Кэти развился тяжелый ожог, потребовалась операция и ампутация груди. Она потеряла подвижность руки и всю жизнь испытывала боль. Позже она подала в суд против производителя — компании AECL. Дело закрыли вне суда.

Через два месяца трагедия повторилась в Канаде. Женщина с раком шейки матки легла под Therac-25, и аппарат начал выдавать сообщение «Доза отсутствует». Оператор несколько раз продолжал процедуру, полагая, что облучения нет. На самом деле луч работал, и пациентка получила около 17 тысяч рад. Ее бедро было разрушено радиацией, позже его пришлось заменить. Спустя время она умерла от прогрессирующего рака — последствия передозировки ухудшили прогноз лечения.

AECL и канадское бюро радиационной безопасности провели проверку. В отчете говорилось о неисправном микропереключателе и ошибках в проектировании. Производитель внес изменения: добавил новый переключатель, обновил алгоритм проверки положения диска, улучшил диагностику. Исправления установили на все аппараты. Компания уверяла, что теперь Therac-25 безопасен. Но основной дефект даже не был обнаружен.

Корень проблемы лежал в излишней самоуверенности разработчиков из Atomic Energy of Canada Limited (AECL). В предыдущих моделях, Therac-6 и Therac-20, безопасность пациента обеспечивалась в том числе за счет аппаратных блокировок, которые не позволяли включить мощный электронный пучок без специального рассеивающего фильтра. В новой модели Therac-25 от многих аппаратных защит отказались в пользу программных. Разработчики посчитали, что софт справится с этой задачей не хуже. Они ошиблись.

Проблему нашел не производитель, а физик из техасского центра — Фриц Хаггер. Он заметил повторяющуюся ошибку №54, которая появлялась перед каждым инцидентом. Он стал имитировать рабочие условия: вводил планы лечения, быстро менял режимы, исправлял опечатки — так, как это делал бы оператор с опытом. Он выявил, что если выбрать режим рентгеновского облучения, затем вернуться назад и переключиться на электронный режим, то поворотный стол не всегда занимал корректное положение. Аппарат выдавал ошибку №54, но оператор, привыкший к частым сбоям интерфейса, нажимал «Продолжить». Без фильтра узконаправленный пучок высокой энергии попадал прямо в пациента, нанося фатальные повреждения.

Именно в этот момент Therac-25 мог включить мощный электронный луч в неправильной конфигурации, направив десятки тысяч рад прямо в тело пациента. В старых моделях такое было невозможно: аппаратные блокировки физически предотвращали опасную комбинацию. В Therac-25 инженеры посчитали их излишними и заменили на программную логику, которая содержала критическую гонку данных. Несколько миллисекунд — и проверка могла пропустить неверное состояние.

Сегодня эти истории напоминают, что любое программное обеспечение, управляющее реальными физическими процессами, должно проходить строгие проверки, независимые ревизии и защиту от человеческих факторов.