Bugün bir bug öğrendin mi?
4 Haziran 1996. Avrupa Uzay Ajansı’nın (ESA) yeni gururu Ariane 5 roketi, Fransız Guyanası’ndaki Kourou üssünden ilk kez fırlatılıyor. Üzerinde yaklaşık 370-500 milyon dolar değerinde dört bilimsel uydu (Cluster misyonu) var. Her şey mükemmel görünüyor… ta ki 37. saniyeye kadar.
Roket aniden rotasından sapıyor, aerodinamik yükler altında parçalanmaya başlıyor ve otomatik imha sistemi devreye girerek kendini imha ediyor. Gökyüzünde büyük bir ateş topu. Tarihin en pahalı ve en ünlü yazılım hatalarından biri yaşanmış oluyor.
Asıl Suçlu: Kodun Kendisi!
Sorun mekanik değildi. Yakıt sızıntısı yoktu, motor arızası yoktu. Sorun, inertial reference system (SRI – ataletsel referans sistemi) yazılımındaydı.
Ariane 5, önceki model Ariane 4’ten miras alınan bir yazılım modülünü kullanıyordu. Bu modül, roket henüz yerdeyken ataletsel platformun hizalamasını yapıyordu. Ariane 4’te mantıklı olan bir özellik, Ariane 5’te fırlatmadan sonra yaklaşık 40 saniye daha çalışmaya devam ediyordu. Çünkü kod “ölü kod” haline gelmişti; yani artık işlevsizdi ama silinmemişti.
Ariane 5, Ariane 4’e göre çok daha hızlı yatay hız kazanıyordu. Bu yüzden “Horizontal Bias (BH)” adı verilen bir değer, beklenenden çok daha büyük çıktı. Yazılım, 64-bit kayan noktalı bir sayıyı 16-bit işaretli tamsayıya dönüştürmeye çalıştı. Sonuç: integer overflow (tamsayı taşması).
Ada dilinde yazılan kodda bu dönüşüm korumasız bırakılmıştı (performans endişesiyle sadece bazı değişkenler korunmuştu). Operand Error oluştu. Hem ana hem yedek SRI aynı anda çöktü. Ana bilgisayar, hata mesajlarını “uçuş verisi” sanarak nozulları maksimum açılara çevirdi. Roket kontrolden çıktı.
Test Neden Yetmedi?
En acı kısım burası: Bu hata, kapsamlı testlerle yakalanabilirdi. Ancak:
- Ariane 4’ten gelen kod, yeni roketin farklı uçuş profilinde simüle edilmemişti.
- Hizalama fonksiyonunun fırlatmadan sonra da çalışmaya devam etmesi dikkate alınmamıştı.
- “Bu değer asla o kadar büyüyemez” varsayımı yapılmıştı (klasik “olmaz öyle şey” tuzağı).
- Yedek sistemler aynı yazılımı çalıştırdığı için gerçek anlamda yedek değildi.
Resmi soruşturma raporu net: Spesifikasyon ve tasarım hataları + yetersiz sistem testi.
Yazılım Test Mühendisleri İçin Çıkarımlar
Bu olay, bugün hâlâ ders kitaplarında okutuluyor çünkü bize şunları hatırlatıyor:
- Kod yeniden kullanımı tehlikelidir. Eski kodu yeni ortama taşırken “zaten çalışıyordu” demek yetmez. Yeni bağlamda yeniden test etmek şarttır.
- Ölü kod bile risk taşır. Kullanılmayan kod parçaları silinmeli veya en azından güvenli hale getirilmelidir.
- Varsayımları test edin. “Bu değer asla taşmaz” demek yetmez; o değeri gerçekten aşacak senaryoları üretin.
- Exception handling ve savunmacı programlama kritiktir. Özellikle güvenlik-kritik sistemlerde.
- Sistem testi, birim testinden daha önemlidir. Bileşenler tek tek mükemmel çalışsa bile entegrasyon ve uçuş profili simülasyonları şarttır.
- Yedeklilik aynı yazılımla sağlanamaz. Gerçek çeşitlilik (diversity) gerekir.
Ariane 5 felaketi, yazılım testinin sadece “hata bulmak” olmadığını, felaketleri önlemek olduğunu kanıtlayan klasik bir örnek. 370 milyon dolarlık bir ders… ve hâlâ geçerliliğini koruyor.
Sizce günümüzde benzer bir hata kaç projenin içinde saklanıyor? Yorumlarda buluşalım 👇🏻