Ariane 5 1996: błąd za 370 mln dolarów w 37 sekund

Dziewiczy lot, który trwał krócej niż reklama

Ariane 5 miała być dumą Europejskiej Agencji Kosmicznej. Program kosztował około 7 miliardów dolarów i trwał blisko dekadę. Nowa rakieta była dużo mocniejsza od swojej poprzedniczki, Ariane 4, i miała wynosić na orbitę cięższe satelity, dając Europie przewagę na rynku komercyjnych startów.

Na pokładzie lotu 501 znajdowały się cztery satelity naukowe misji Cluster, przeznaczone do badania magnetosfery Ziemi. Start z kosmodromu Kourou wyglądał podręcznikowo. Po około 37 sekundach rakieta nagle zmieniła kurs, zaczęła rozpadać się pod wpływem sił aerodynamicznych i uruchomił się system samozniszczenia. Szczątki spadły na bagna wokół kosmodromu.

Straty samej rakiety i ładunku szacuje się na około 370 milionów dolarów, a niektóre wyliczenia uwzględniające opóźnienia programu mówią o jeszcze większych kwotach. Satelity nie były ubezpieczone.

Liczba, która się nie zmieściła

Komisja śledcza pod kierunkiem francuskiego matematyka Jacques-Louisa Lionsa już w lipcu 1996 roku opublikowała raport, który do dziś jest lekturą obowiązkową na wielu studiach informatycznych. Przyczyna okazała się zaskakująco prosta.

W systemie odniesienia inercyjnego (SRI), odpowiedzialnym za określanie położenia i prędkości rakiety, działał moduł napisany w języku Ada. Jedna z jego procedur zamieniała wartość związaną z poziomą prędkością rakiety z 64-bitowej liczby zmiennoprzecinkowej na 16-bitową liczbę całkowitą ze znakiem. Taki typ przechowuje wartości maksymalnie do 32 767.

W Ariane 4 ta wartość nigdy nie zbliżała się do limitu. Ariane 5 przyspieszała jednak znacznie szybciej, więc już w pierwszych sekundach lotu liczba przekroczyła zakres. Procesor zgłosił wyjątek przepełnienia, którego nikt nie obsłużył, i komputer SRI po prostu się wyłączył.

Dlaczego zapasowy system nie pomógł

Inżynierowie przewidzieli awarię sprzętu, dlatego rakieta miała dwa identyczne komputery SRI. Problem w tym, że oba uruchamiały ten sam kod z tymi samymi danymi wejściowymi. Zapasowy komputer padł dokładnie z tego samego powodu, około 72 milisekund wcześniej niż główny.

Potem nastąpiła reakcja łańcuchowa:

1. Komputer pokładowy, zamiast danych o położeniu, otrzymał z SRI dane diagnostyczne o błędzie.
2. Potraktował ten wzorzec bitów jak prawdziwe dane lotu.
3. Uznał, że rakieta mocno zboczyła z kursu, i wychylił dysze silników do maksimum, aby to skorygować.
4. Gwałtowny manewr przy dużej prędkości spowodował ogromne obciążenia i rozpad konstrukcji.
5. Zadziałał automatyczny system samozniszczenia.

To klasyczny przykład, że redundancja chroni przed awarią sprzętu, ale nie chroni przed błędem logicznym, który jest identyczny w obu kopiach.

Najbardziej ironiczny szczegół: ten kod nie był potrzebny

Feralna procedura odpowiadała za kalibrację systemu nawigacji przed startem. Po oderwaniu się rakiety od ziemi nie miała już żadnego zastosowania. W Ariane 4 pozostawiono ją jednak aktywną przez około 40 sekund lotu, aby w razie krótkiego wstrzymania odliczania można było szybko wznowić start bez ponownej, długiej kalibracji.

W Ariane 5 ta funkcja w ogóle nie była potrzebna, ale moduł przeniesiono bez zmian, bo w poprzedniej rakiecie działał bezbłędnie. Raport komisji wskazał też inne zaniedbania:

• Z siedmiu ryzykownych konwersji w module zabezpieczono tylko cztery. Pozostałe pominięto, aby nie obciążać procesora, przy założeniu, że wartości nigdy nie przekroczą zakresu.
• Założenie to udokumentowano dla Ariane 4, ale nie sprawdzono go ponownie dla nowej trajektorii lotu.
• Nie przeprowadzono pełnych testów symulacyjnych systemu SRI z danymi lotu Ariane 5.
• Domyślna reakcja na każdy nieobsłużony wyjątek zakładała wyłączenie komputera, co miało sens przy awarii sprzętu, ale nie przy błędzie programu.

Co lot 501 mówi o współczesnym IT w firmie

Historia Ariane 5 brzmi jak opowieść z innego świata, ale te same mechanizmy widzimy dziś w zwykłych firmach. Skrypt skopiowany z innego serwera, aktualizacja wdrożona bez testu na kopii środowiska, system zapasowy, który ma dokładnie tę samą konfigurację co główny. Podobnie jak w przypadku pluskwy Y2K, źródłem problemu było założenie, że pewne wartości nigdy nie przekroczą ustalonego zakresu.

Najważniejsze lekcje, które warto przenieść na grunt firmowej infrastruktury:

• Ponowne użycie kodu to nie zwolnienie z testów. Coś, co działało w starym środowisku, może zawieść w nowym, nawet bez jednej zmienionej linijki.
• Testuj w warunkach zbliżonych do produkcji. Środowisko testowe i automatyczne testy przed wdrożeniem to dokładnie to, czego zabrakło w 1996 roku. Pomagamy budować takie procesy w ramach usługi DevOps dla firm.
• Kopia zapasowa musi być faktycznie niezależna. Backup na tym samym dysku czy replika z tym samym błędem konfiguracji nie uratuje firmy. Dlatego tak ważny jest regularny test odtwarzania backupu.
• Dokumentuj założenia i weryfikuj je przy każdej zmianie. Migracja serwera czy nowa wersja systemu to dobry moment, by sprawdzić, czy stare reguły nadal mają sens.

Happy end: Ariane 5 i Cluster wróciły

Mimo spektakularnej porażki program nie został zamknięty. Po poprawkach Ariane 5 stała się jedną z najbardziej niezawodnych rakiet świata. W grudniu 2021 roku wyniosła w kosmos Kosmiczny Teleskop Jamesa Webba, a tak precyzyjnie, że zaoszczędzone paliwo wydłużyło planowaną misję teleskopu o wiele lat. Ostatni lot Ariane 5 odbył się w lipcu 2023 roku.

Misja Cluster również dostała drugą szansę. Odbudowane satelity, nazwane Cluster II, wystartowały w 2000 roku na rosyjskich rakietach Sojuz i prowadziły badania przez ponad dwie dekady, znacznie dłużej, niż planowano.

Lot 501 pozostaje jednak symbolem tego, że w świecie oprogramowania jedna niesprawdzona linijka kodu potrafi kosztować więcej niż cały budynek firmy. Podobnie jak błąd Heartbleed, przypomina, że małe szczegóły techniczne mają wielkie konsekwencje.