В 1996 году новая европейская ракета Ariane-5 взорвалась через 37 секунд после старта. Причина оказалась не в железе и не в конструкции, а в программной ошибке. 64-битное значение с плавающей точкой было преобразовано в 16-битное знаковое целое без проверки переполнения. В условиях полёта это привело к аварийному завершению навигационного модуля и передаче некорректных данных системе управления. Один перенос кода из старой версии ракеты, одна числовая операция - и миссия стоимостью сотни миллионов долларов закончилась самоуничтожением.
Эту историю рассказывают на курсах по качеству кода как предупреждение: даже одна строчка может стоить катастрофы. Ariane-5 была флагманским проектом Европейского космического агентства, разрабатывалась десять лет, тестировалась сотнями инженеров. И всё равно крошечная ошибка в программном обеспечении прошла незамеченной до самого первого полёта. Когда видишь кадры взрыва - огромная ракета разворачивается в сторону, теряет управление и разрушается - сложно поверить, что причина в банальном переполнении переменной.
Что такое переполнение переменной
Переполнение - это ситуация, когда число становится слишком большим для типа данных, в котором оно хранится. Представьте старомодный одометр в машине с пятью цифрами. Максимальное значение - 99999 километров. Проедете ещё один километр - счётчик обнулится и покажет 00000.
В программировании то же самое. Переменная имеет фиксированный размер в битах. 16-битное знаковое целое число может хранить значения от -32768 до +32767. Попытаетесь записать туда 40000 - получите переполнение и непредсказуемый результат.
64-битное число с плавающей точкой (double) вмещает огромные значения - триллионы и больше. Когда разработчики Ariane-5 пытались конвертировать такое число в 16-битное целое без проверок, они фактически говорили компьютеру: «засунь слона в спичечный коробок, и плевать, что не влезет».
Компьютер послушно пытался это сделать. Значение не влезло, произошло переполнение, система получила мусорные данные вместо корректных координат. Дальше - цепная реакция ошибок.
«Переполнение переменной - это как налить литр воды в стакан. Лишнее пойдёт не туда, куда вы ожидали».
Что именно пошло не так
Ariane-5 использовала инерциальную навигационную систему от предыдущей ракеты Ariane-4. Код проверенный, годами работал без проблем - зачем переписывать? Логично, но опасно.
Ariane-4 летала по определённой траектории с конкретными ускорениями. Навигационная система рассчитывалась под эти параметры. Ariane-5 была мощнее, разгонялась быстрее, летела по другой траектории. Горизонтальная скорость оказалась значительно выше, чем у предшественницы.
Программа вычисляла горизонтальную скорость в 64-битном формате. Потом конвертировала её в 16-битное целое для передачи другим системам. На Ariane-4 это значение никогда не превышало допустимый диапазон 16 бит. На Ariane-5 превысило.
Переполнение вызвало исключение - программная ошибка. Система зафиксировала сбой и аварийно завершила работу. Запустился резервный навигационный компьютер. Но там был точно такой же код с той же ошибкой! Он тоже упал через миллисекунды.
Ракета осталась без навигации. Система управления получила последние данные от навигационного модуля - но это были данные ошибки, интерпретированные как корректные значения угла отклонения. Компьютер решил, что ракета отклонилась на огромный угол и начал корректировать траекторию.
Ракета резко развернулась. Аэродинамические нагрузки превысили допустимые. Сработала система самоуничтожения - для безопасности, чтобы обломки не упали на населённые пункты. Всё закончилось через 37 секунд после старта.
Почему тесты не выявили ошибку
Самый больной вопрос: как это не заметили при тестировании? Ведь систему проверяли вдоль и поперёк.
Проблема в том, что навигационный модуль не тестировали в условиях, соответствующих реальной траектории Ariane-5. Использовали данные Ariane-4, где скорости были меньше. При таких параметрах переполнение не возникало, система работала штатно.
Ещё момент: код переполнения был в участке программы, который вообще не должен был выполняться в полёте. Это был расчёт для выравнивания перед стартом. После старта этот код не нужен и должен отключаться.
Но разработчики решили оставить его работать ещё 40 секунд после взлёта - на случай прерванного старта. Если ракету придётся опустить обратно на стартовый стол, навигационная система останется в рабочем состоянии и не потребует долгой перенастройки.
Благие намерения. Экономия времени на подготовку к повторному пуску. Никто не подумал, что эти лишние 40 секунд работы ненужного кода могут стать проблемой. А именно в этом коде и сидела бомба замедленного действия.
«Катастрофа Ariane-5 - урок о том, что самые опасные баги прячутся там, где их не ищут: в "проверенном" коде и "ненужных" функциях».
Расследование и выводы
Комиссия по расследованию аварии опубликовала детальный отчёт. Выводы оказались жёсткими: недостаточное тестирование, неоправданное повторное использование кода, отсутствие защиты от переполнения.
Но главное - культурная проблема. Инженеры слепо доверяли коду из Ariane-4, считая его безупречным. «Код работал двадцать лет без проблем, зачем перепроверять?» Классическая ловушка legacy-кода.
Формально код был безупречным для Ariane-4. Но переносить его на ракету с другими характеристиками без ревизии - опасная самонадеянность. Новая система, новые параметры - нужна новая валидация.
После катастрофы процессы разработки и тестирования полностью пересмотрели. Внедрили дополнительные проверки, расширили тестовые сценарии, ужесточили контроль за повторным использованием кода. Следующие запуски Ariane-5 прошли успешно.
Но урок был дорогим. Груз стоимостью $370 миллионов уничтожен. Четыре спутника для изучения магнитосферы Земли потеряны. Десять лет разработки ракеты едва не пошли насмарку. Репутация Европейского космического агентства пострадала.
Что программисты должны помнить
История Ariane-5 преподаёт несколько уроков.
Проверяйте переполнение. Любое преобразование типов с уменьшением разрядности требует проверки диапазона. Если значение не влезает - обработайте ошибку явно, не полагайтесь на удачу.
Не доверяйте старому коду слепо. Даже если программа годами работала без проблем, перенос в новые условия требует переоценки. Новое оборудование, новые параметры, новые нагрузки - новые риски.
Тестируйте на реальных данных. Использование данных из предыдущих проектов для тестирования нового - опасная практика. Параметры изменились? Тестовые сценарии должны измениться тоже.
Удаляйте ненужный код. Код, который не должен выполняться в продакшене, не должен там присутствовать. Чем меньше кода - тем меньше потенциальных ошибок.
Документируйте допущения. Если код написан с расчётом на определённые ограничения (например, «скорость не превысит X»), это должно быть явно задокументировано и проверено.
Современные языки программирования пытаются защитить от подобных ошибок. Rust, например, по умолчанию вызывает панику при переполнении. Java бросает исключение. Но в критических системах часто используется C или Ada, где программист сам отвечает за корректность.
Стоимость ошибки
$370 миллионов - прямые потери от уничтожения груза. Но реальная цена выше. Отложенные научные исследования, потерянное время учёных, подорванная репутация, затраты на расследование, пересмотр процессов.
И это не считая морального ущерба для команды разработчиков. Представьте: десять лет работы, сотни инженеров, тысячи часов тестирования. И всё это уничтожено за 37 секунд из-за одной строки кода, которую никто не перепроверил.
Комиссия не стала искать виновных конкретно. Проблема была системной: процессы разработки позволяли такой ошибке проскочить. Виноват не программист, написавший код для Ariane-4, а система, которая позволила перенести этот код без должной проверки.
После Ariane-5 космическая индустрия стала параноидально осторожной с программным обеспечением. Каждая строка кода проходит множественные ревью. Тесты покрывают самые маловероятные сценарии. Повторное использование кода допускается только после полной ревалидации.
Но это не гарантия. Баги всё равно находят пути пробраться в продакшен. Просто теперь их ловят раньше и чаще. А Ariane-5 стала символом того, как дорого может стоить пренебрежение основами разработки.
Катастрофа Ariane-5 - это не просто история о сбое ракеты. Это напоминание о цене ошибок в программировании. Когда ваш код управляет чем-то критичным - будь то космический корабль, медицинское оборудование или финансовая система - у вас нет права на небрежность.
Переполнение переменной кажется мелочью. Студенты проходят эту тему в первом семестре. Но именно эта «мелочь» уничтожила ракету стоимостью сотни миллионов. Потому что кто-то посчитал проверку излишней. Кто-то решил, что старый код и так надёжен. Кто-то не подумал о последствиях.
Тридцать семь секунд полёта. Одна переменная. Одна отсутствующая проверка. Триста семьдесят миллионов долларов. История Ariane-5 должна быть обязательной для изучения каждым программистом, чей код влияет на что-то более серьёзное, чем отображение котиков на веб-странице.
📖 Читайте также:
→ Баг с годом 2038, который до сих пор пугает инженеров
→ Почему в NASA до сих пор есть строка кода, которую запрещено трогать?
→ Серверные ошибки, которые могут остановить ваш сайт