Ariane 5: błąd w jednej linijce kodu za 370 milionów dolarów

Rakieta, która miała udowodnić potęgę Europy

Ariane 5 była wizytówką europejskiego programu kosmicznego. Po latach sukcesów swojej poprzedniczki, Ariane 4, Europejska Agencja Kosmiczna (ESA) postawiła na znacznie potężniejszą konstrukcję, zdolną wynosić na orbitę cięższe i droższe ładunki niż konkurencja z USA czy Rosji. Lot 501 był pierwszym startem tej nowej rakiety i miał udowodnić, że inwestycja w nowy program się opłaciła.

Na pokładzie znajdowały się cztery satelity naukowe klastra Cluster, zaprojektowane do badania oddziaływania wiatru słonecznego z magnetosferą Ziemi. Ich budowa i przygotowanie do lotu kosztowały setki milionów dolarów, a start transmitowano na żywo jako triumf europejskiej inżynierii.

37 sekund do katastrofy

Start z kosmodromu Kourou w Gujanie Francuskiej wyglądał na wzorowy. Silniki zapaliły się poprawnie, rakieta oderwała się od ziemi i zaczęła nabierać wysokości zgodnie z planem lotu. Problemy zaczęły się dokładnie 36,7 sekundy po starcie.

System naprowadzania rakiety nagle skręcił dyszami silników pod skrajnym kątem, próbując skorygować kurs, którego w rzeczywistości rakieta wcale nie potrzebowała. Ogromne siły aerodynamiczne wywołane tym gwałtownym manewrem zaczęły rozrywać konstrukcję rakiety. System bezpieczeństwa, wykrywając rozpad struktury, automatycznie uruchomił samozniszczenie. Ariane 5 eksplodowała w powietrzu, a jej szczątki spadły na bagnisty teren wokół wyrzutni.

Kod z Ariane 4, który nie pasował do nowej rakiety

Dochodzenie ujawniło przyczynę, która zszokowała inżynierów swoją prostotą. System naprowadzania inercyjnego (SRI) rakiety, odpowiedzialny za obliczanie jej pozycji i prędkości, w pewnym momencie próbował przekonwertować 64-bitową liczbę zmiennoprzecinkową opisującą poziomą prędkość rakiety na 16-bitową liczbę całkowitą.

Problem polegał na tym, że wartość ta była znacznie większa niż mogła pomieścić 16-bitowa zmienna, ponieważ Ariane 5 przyspieszała szybciej niż jej poprzedniczka. Doszło do przepełnienia zmiennej, którego procedura nie potrafiła obsłużyć, co wywołało nieprzechwycony wyjątek i zatrzymanie komputera.

• Fragment kodu odpowiedzialny za błąd pochodził wprost z Ariane 4, gdzie działał bez zarzutu przez lata.
• Nikt nie przeanalizował ponownie, czy założenia dotyczące zakresu prędkości wciąż są prawdziwe dla nowej, mocniejszej rakiety.
• Co gorsza, system miał zapasowy komputer dla redundancji, ale uruchamiał dokładnie ten sam kod, więc awarii uległy oba jednocześnie, w odstępie zaledwie 0,05 sekundy.
• Komputer główny, już wyłączony, przekazał do sterowania silnikami swoje ostatnie dane diagnostyczne, które system naprowadzania błędnie zinterpretował jako prawidłowe dane lotu, stąd gwałtowny i niepotrzebny skręt dyszami.

Dlaczego redundancja nie uratowała misji

Redundancja, czyli dublowanie krytycznych systemów, to podstawowa zasada inżynierii bezpieczeństwa. Problem w tym, że chroni ona przed awarią sprzętu, a nie przed błędem w logice, który jest identyczny w obu kopiach systemu. Skoro oba komputery SRI uruchamiały ten sam, wadliwy kod na tych samych danych wejściowych, oba padły w tym samym momencie z tego samego powodu.

To jedna z najważniejszych, choć wciąż niedocenianych lekcji tej katastrofy: dublowanie sprzętu bez zróżnicowania oprogramowania daje fałszywe poczucie bezpieczeństwa. Ta sama słabość dotyczy dziś firmowych systemów IT, gdzie kopia zapasowa serwera czy drugi węzeł klastra nie pomoże, jeśli awarię wywołał błąd w konfiguracji lub logice, replikowany automatycznie na oba urządzenia.

Co ta historia mówi o pracy w dzisiejszym IT

Ariane 5 na stałe weszła do podręczników inżynierii oprogramowania jako przykład tego, jak niebezpieczne bywa bezrefleksyjne ponowne użycie kodu. Kilka wniosków z tej awarii jest równie aktualnych w małej firmie, jak w agencji kosmicznej.

• Ponowne użycie kodu wymaga ponownej walidacji. Fragment działający idealnie w jednym środowisku może zawieść w innym, jeśli zmienią się założenia wejściowe.
• Obsługa wyjątków nie jest opcjonalna. Niekontrolowany błąd, który zatrzymuje cały system zamiast zostać bezpiecznie przechwycony, potrafi sparaliżować krytyczną infrastrukturę w ułamku sekundy.
• Testowanie na realistycznych scenariuszach jest kluczowe. Symulacje przed lotem nie uwzględniły pełnego zakresu prędkości nowej rakiety, więc błąd nigdy nie ujawnił się przed startem.
• Przegląd kodu i audyt to nie formalność. Dokładna analiza logiki, zwłaszcza w miejscach dziedziczonych ze starszych projektów, potrafi wychwycić założenia, które przestały być prawdziwe.

Jak uniknąć podobnych błędów we własnej firmie

Mało która firma zarządza rakietami, ale każda firma zarządza systemami, w których błąd może kosztować przestoje, utratę danych albo reputację. Praktyki, które mogłyby uratować Ariane 5, sprawdzają się równie dobrze w codziennym IT małej i średniej firmy:

• Regularny audyt infrastruktury i konfiguracji, zamiast zakładania, że skoro coś działało wcześniej, zadziała zawsze.
• Testowanie zmian i aktualizacji w środowisku możliwie zbliżonym do produkcyjnego, zanim trafią na serwery obsługujące realną pracę firmy.
• Monitoring systemów, który wychwytuje nietypowe wartości i błędy, zanim doprowadzą do poważniejszej awarii.
• Rzetelna dokumentacja procesów i zależności, dzięki której wiadomo, które elementy infrastruktury dziedziczą rozwiązania ze starszych wdrożeń.

To właśnie na tym polega dobrze prowadzone wsparcie IT: nie tylko reagowanie na awarie, ale systematyczne wyszukiwanie miejsc, w których stary kod, stara konfiguracja czy stare założenia mogą wywołać problem w nowych warunkach.