Birleşik Krallık hava trafik kontrol sisteminin çöküşü

• 28 Ağustos 2023'te Birleşik Krallık hava trafik kontrol operatörü NATS'in FPRSA-R arızası nedeniyle 2.000'den fazla uçuş iptal edildi ve maliyetin 100 milyon sterlini aştığı tahmin ediliyor
• Karmaşayı tetikleyen uçuş planı, Eurocontrol IFPS'nin kabul ettiği geçerli bir plandı ve NATS sistemi, ADEXP verileri ile ICAO4444 rotasını eşleştirerek Birleşik Krallık hava sahası bölümünü çıkarmaya çalışıyordu
• Doğrudan neden, coğrafi olarak farklı iki waypoint'in aynı tanımlayıcıya sahip olmasıydı; FPRSA-R yanlış yinelenen tanımlayıcıyı çıkış noktasıyla eşleştirdi ve geçerli bir Birleşik Krallık bölümü oluşturamadı
• Ana sistem ve yedek sistem, aynı mantıkla aynı uçuş planını işlerken ayrı ayrı critical exception üretti ve 20 saniye içinde maintenance mode'a girerek otomatik işlemeyi durdurdu
• Uçaklar güvenli şekilde kontrol edilmeye devam etti, ancak tek bir uçuş planının tüm otomatik işleme sistemini durdurabilmesi, yetersiz testler ve düşük seviyeli loglara dayanan kurtarma prosedürü sorun olarak kaldı

---

28 Ağustos 2023 NATS arızasının boyutu

• Birleşik Krallık hava trafik kontrol operatörü NATS, 28 Ağustos 2023'te ciddi bir teknik arıza yaşadı
• BBC'ye göre 2.000'den fazla uçuş iptal edildi ve maliyetin 100 milyon sterlini aştığı tahmin edildi
• Arıza yüz binlerce kişiyi etkilemiş olabilir
• İlk basın haberlerinde “hatalı uçuş planı” ya da “Fransız havayolunun hatası” ihtimali ele alındı, ancak soruna yol açan uçuş planı Eurocontrol IFPS'nin kabul ettiği ICAO4444 uyumlu bir uçuş planıydı
• Daha sonra arızayı tetikleyen gerçek uçuşun, LAX/KLAX'tan ORY/LFPO'ya giden French Bee FBU731 olduğu belirlendi

Uçuş planının NATS'e ulaşma akışı

• Havayolu şirketleri uçuş planlarını Eurocontrol'ün IFPS sistemine gönderir
  • IFPS uçuş planını kabul ettiğinde, kalkış havalimanı kontrol onayından sonra uçak havalanabilir
  • Bu aşamada NATS girdisi gerekmez
• IFPS, uçuş planını ilgili hava seyrüsefer hizmet sağlayıcılarına iletir
  • NATS'in, uçak Birleşik Krallık hava sahasına girmeden en az 4 saat önce uçuş planını alması gerekir
  • Bu 4 saat, işleme sorunlarını çözebilmek için bir tampon süre işlevi görür
• Swanwick Centre'daki NATS En-route operasyonunda veriler FPRSA-R'ye aktarılır
  • FPRSA-R, IFPS'den gelen ADEXP biçimindeki verileri UK National Airspace System yani NAS ile uyumlu bir biçime dönüştürür
  • NAS, ilgili hava sahası ve rota bilgilerini içeren bir uçuş veri işleme sistemidir

ICAO4444 ile ADEXP arasındaki fark

• ICAO4444 uçuş planı, makine tarafından okunabilen ve gerekirse insan tarafından da okunabilen bir biçimdir
  • Rota bölümünde hız, irtifa, waypoint'ler, rota adları ve DCT gibi direkt uçuş göstergeleri yer alır
  • Örneğin N0440 440 knot, F310 ise Flight Level 310 anlamına gelir
• IFPS, ICAO4444 uçuş planını ADEXP biçimine dönüştürerek iletir
  • ADEXP, özgün ICAO4444 uçuş planına ek olarak Avrupa bölgesel rotası için ek coğrafi waypoint'ler içerir
  • Birleşik Krallık'a iniş yapmadan Birleşik Krallık hava sahasından geçen uçuşlar, Birleşik Krallık dışındaki yolculuğun geri kalanı için gereken waypoint'leri de içerebilir
• ADEXP'nin RTEPTS alanında her waypoint için irtifa ve tahmini geçiş zamanı daha ayrıntılı yer alır
  • ICAO rotasında 9 waypoint olabilirken, ADEXP'nin genişletilmiş listesinde 21 waypoint bulunabilir
  • ICAO rotasındaki kalkış ve varış noktaları ayrı alanlarda bulunduğundan rota listesinde tekrar yer almaz

Arızaya yol açan yinelenen waypoint

• Sorunlu ADEXP waypoint listesinde, coğrafi olarak farklı iki waypoint aynı designator'a sahipti
  • ICAO ve diğer kurumlar benzersiz olmayan waypoint adlarını kaldırmaya çalışsa da dünya genelinde hâlâ yinelenen adlar bulunuyor
  • Güncel standartlar, aynı tanımlayıcıya sahip waypoint'lerin coğrafi olarak geniş ölçüde ayrı olması gerektiğini belirtiyor
  • Bu olaydaki iki waypoint de Birleşik Krallık dışındaydı; biri rotanın başında, diğeri sonunda yer alıyordu ve aralarında yaklaşık 4.000 deniz mili vardı
• Gerçekte tespit edilen FBU731 uçuşunun genişletilmiş uçuş planında DVL adlı waypoint iki kez görünüyordu
  • Biri ABD Wisconsin'deki Devil’s Lake
  • Diğeri Fransa Normandiya'daki Deauville
  • İkincisinin, UN859 hava yolu genişletme sürecinde uçuşun ilerleyen bölümünde ortaya çıktığı açıklandı

FPRSA-R'nin işleme prosedürü ve başarısızlık noktası

• FPRSA-R, ADEXP waypoint verilerinde Birleşik Krallık hava sahası giriş noktasını baştan itibaren arayarak bulur
• Ardından Birleşik Krallık hava sahası çıkış noktasını bulur ve sonrasında ICAO4444 bölümünde buna karşılık gelen kısmı aramaya çalışır
• ICAO rotasında hava sahası çıkış noktasının mutlaka bulunması gerekmez
  • Yazılım, çıkış noktası ICAO rotasında yoksa ADEXP dosyasındaki bir sonraki en yakın noktayı kullanarak yeniden arama yapacak şekilde tasarlanmıştı
• Bu olayda yazılım, ADEXP'deki sonraki waypoint'leri izlerken ICAO rotasında bulunan bir yinelenen tanımlayıcı buldu
  • Ancak bu tanımlayıcı, Birleşik Krallık hava sahasından gerçek çıkıştan sonraki waypoint değil, rotanın başlarında bulunan başka bir coğrafi waypoint'ti
  • Sonuç olarak giriş ve çıkış noktalarının sırası ya da bölümü geçerli olmadı ve Birleşik Krallık hava sahasına karşılık gelen ICAO bölümü çıkarılamadı
• NATS raporu bu noktayı olayın root cause'u olarak işaretledi ve siber güvenlikle ilgili bir katkı ihtimalini dışlayabileceklerini belirtti

Ana sistem ile yedek sistemin aynı anda durmasının nedeni

• Güvenlik açısından kritik yazılımlar, güvenli şekilde devam edemediğinde manuel müdahale gerektiren bir duruma geçecek şekilde tasarlanır
• FPRSA-R ana sistemi, uçuş planının doğru verisini garanti edemeyeceğine karar vererek critical exception üretti
  • Log dosyasını sistem günlüğüne yazdı
  • maintenance mode'a geçti
  • C&M sistemi, ana sistemin artık kullanılabilir olmadığını algıladı
• Yedek sistem, ana sistem arızalandığında işlemeyi devralmak üzere tasarlanmıştı
  • Ayrı donanım, ayrı güç kaynağı ve ayrı veri akışı üzerinde bulunuyordu
  • Ancak aynı uçuş planına aynı mantığı uyguladı ve aynı nedenle critical exception üretti
• ADEXP mesajının alınmasından ana sistem ve yedek sistemin ikisinin de maintenance mode'a geçmesine kadar 20 saniyeden az zaman geçti
• 08:32'de otomatik uçuş planı işleme durdu ve sonrasında 4 saatlik tampon süre içinde uçuş planlarının manuel girilmesi gerekti

Kurtarma prosedürü ve operasyonel etki

• 1st Line destek ekibi, özel C&M sistemi, merkezi C&M sistemi ve operasyon ekibinin geri bildirimi üzerinden arızayı fark etti
• İlk müdahale, merkezi C&M sistemi üzerinden alt sistemi yeniden başlatmaya yönelik standart kurtarma prosedürüydü
  • Birden fazla kurtarma denemesi başarısız oldu
  • 2nd Line mühendislik ekibi devreye alındı ve sahadaki mühendise uzaktan görüntülü bağlantı üzerinden destek verdi
• 1st Line ve 2nd Line ekipleri hizmeti geri getirmede veya kesin nedeni belirlemede başarısız olunca Technical Design ekibi ve alt sistem üreticisinin desteği istendi
• Üretici, düşük seviyeli yazılım loglarını analiz ederek arızaya yol açtığı düşünülen uçuş planını tespit etti
  • Bu uçuş planı anlaşıldıktan sonra, sistemi kontrollü ve güvenli biçimde geri getirmek için gereken kesin prosedürü sağladı
• Arıza durumunda manuel giriş ve sektörler arası manuel koordinasyon prosedürleri vardı, ancak manuel prosedüre geçildiğinde Birleşik Krallık trafik akışını azaltmak için hava trafik kontrol kısıtlamalarının uygulanması gerekiyordu

Frequentis AG ve FPRSA-R

• FPRSA alt sistemi NATS bünyesinde uzun süredir bulunuyordu ve 2018'de mevcut sistem, Frequentis AG'nin yeni donanım ve yazılımıyla değiştirildi
• Frequentis AG, Avusturyalı bir şirket ve hava trafik kontrol sistemi tedarikçilerinden biri
• Şirketin ATC ürünlerinin yaklaşık 150 ülkede kullanıldığı ve havacılık bilgi yönetimi ile mesaj işleme sistemlerinde küresel ölçekte güçlü bir konuma sahip olduğu belirtiliyor
• Frequentis AG'nin kariyer sayfasında hava trafik kontrol sistemleriyle bağlantılı olarak Ada, C++, Java, Python yer alıyor ve en sık görünen dil Java

Yazılım hatası ve test sorunu

• FPRSA-R, IFPS'nin kabul ettiği geçerli bir uçuş planından Birleşik Krallık hava sahasına karşılık gelen ICAO bölümünü çıkaramadı
• Waypoint tanımlayıcıları küresel olarak benzersiz değildir ve bu bilinen bir sorundur
  • Yinelenen waypoint'ler birbirinden çok uzaktaysa, normal bir uçuş planı yine de belirsiz olmayabilir
  • Ancak yazılımın bu durumu sağlam şekilde ele alması gerekirdi
• NATS, ICAO'nun yönettiği küresel veri kümesinde bu olayla ilgili az sayıdaki yinelenen waypoint adının kaldırılmasını Birleşik Krallık hükümeti aracılığıyla değerlendirebileceğini söyledi
• NATS CEO'su Martin Rolfe, BBC'ye bu olayın “15 milyonda 1” olasılık olduğunu söyledi
  • Sistemin 2018'de devreye alındığını ve o zamandan beri 15 milyon uçuş planı işlediğini belirtti
• Güvenlik açısından kritik bir sistemde, özellikle Birleşik Krallık bölümünün çıkarılması gibi önemli bir adım olmak üzere uçuş planı işleme aşamaları test edilmelidir
  • Yinelenen waypoint adlarını hesaba katmayan testler bu hatayı ortaya çıkaramamış olabilir
  • Büyük miktarda rastgele uçuş planı vererek yapılan fuzzing, sistemi kötü bir başarısızlık moduna sokan girdileri bulmaya yardımcı olabilirdi

Başarısızlık modunun sorunu

• Tek bir uçuş planı tüm FPRSA-R otomatik işleme sistemini durdurdu ve bunun sonucunda hiçbir uçuş planı otomatik olarak işlenemedi
• Daha iyi bir başarısızlık modu, sorunlu tek bir uçuş planını ayrı bir yavaş kuyruğa gönderip insanın manuel olarak işlemesini sağlamak olurdu
• NATS, halihazırda yürüttüğü veya tamamladığı önlemler kapsamında IFPS ile FPRSA-R arasındaki veri akışına belirli mesaj filtreleri ekleyerek, olaya yol açan koşullara uyan uçuş planlarını süzeceğini açıkladı
• FPRSA-R durduğunda ilgili uçuş planı ancak düşük seviyeli yazılım loglarında tespit edilebildi
  • Uçuş planı işleme sisteminde belirli bir uçuş planı işleme hatası tüm sistemi durduruyorsa, bu uçuş planını içeren bir uyarının izleme ekibine anında iletilmesi daha uygun olurdu
• NATS, aynı durumun tekrar etmesi halinde FPRSA-R'yi hızla kurtarmaya yönelik operasyonel yönergeler hazırladığını ve teknik operatörlerin yeni prosedürleri uygulamak üzere eğitildiğini belirtti
  • Güçlendirilmiş izleme ve ek mühendislik uzmanları da süreci denetleyecek

Biçimsel doğrulama olasılığı

• Olayın bu aşamasında ve bu sistemde biçimsel doğrulama kullanıldığına dair açık bir iz yok ve raporda da bundan söz edilmiyor
• Biçimsel doğrulama ya da model checking, bu tür hataların azaltılmasına yardımcı olabilirdi
• Ancak büyük sistemlerde uçtan uca biçimsel doğrulama hâlâ erken aşamada ve kısmen kullanılmış olsa bile hatalı kodun üretim ortamına girmesi ihtimali sürüyor
• Nihai soruşturma sonucu çıktığında gerçekte hangi doğrulama yöntemlerinin kullanıldığı daha iyi anlaşılabilir

Güvenlik ve kamuya açık raporlama

• Birleşik Krallık üzerindeki uçaklar olay boyunca güvenli şekilde tutuldu
  • Deneyimli hava trafik kontrolörleri, bilinen uçuş planları, telsiz, radar ve görüş yoluyla uçakları izledi
  • Sonuç can güvenliği riski değil, çok daha az sayıda uçuşun kalkabilmesi veya uçakların Birleşik Krallık hava sahasından kaçınarak yönlendirilmesi oldu
• NATS, güvenliği korumak için uçuş sayısını azaltan önlemler aldı
• Kamuya açık rapor oldukça şeffaf ve ayrıntılı; kritik altyapı için bu tür raporlama önemli
• Ryanair'den Michael O’Leary raporu “rubbish” diye eleştirdi ve havacılık sektörü üzerindeki etkiyi küçümsediğini söyledi, ancak ilk raporun kapsamının NATS'in başarısızlığının derecesini analiz etmek olmadığı yönünde değerlendirmeler de var

Daha sağlam bir uygulama yönü

• Sorun, iki waypoint dizisini birlikte ele almakla ilgili
  • ADEXP: tam waypoint listesi
  • ICAO: ADEXP waypoint'lerinin bir alt dizisi
• ICAO planında hava sahası giriş/çıkış noktaları mutlaka yer almadığından, ICAO içindeki Birleşik Krallık hava sahasına karşılık gelen en küçük sürekli bölümü bulmak basit değildir
• Hatalı algoritmanın sorunu, ICAO verisi ile ADEXP verisini aynı anda işaret eden pointer'ları yönetirken, açık olmayan invariant'ları kodun dışında bırakmış olmasıydı
• Önerilen yaklaşım, önce ICAO ile ADEXP verilerini tek bir Combined uçuş planı yapısında uzlaştırmak, ardından Birleşik Krallık bölümünü çıkarmak
  • Olası tüm reconciliation sonuçları hesaplanarak belirsiz durumlar tespit edilir
  • reconciliation sayısı 0 ise ICAO ile ADEXP uzlaştırılamaz
  • Birden fazlaysa durum belirsizdir ve manuel işleme adayı yapılabilir
• Haskell örnek uygulaması NonUkPlan, CannotReconcileIcaoAdexp, AmbiguousReconciliationsOfIcaoAdexp hatalarını açıkça ele alıyor
• Örnekte ADEXP listesinde yinelenen Q tanımlayıcısı bulunsa bile, ICAO ile ADEXP verileri belirsiz olmadan uzlaştırılabiliyorsa doğru Birleşik Krallık bölümü döndürülüyor
• Tüm kod uk-portion-of-ICAO adresinde bulunuyor

[GN⁺]

Hacker News yorumları

• Uçuş planı sorgusunda coğrafi olarak ayrılmış kapsam sınırlamasını atlamışlar. Geçmişte uçuş seyrüsefer sistemi geliştirirken bu hatayı biliyordum, gerçekten de görmüştüm ve bu hatadan kaçınmak için geofence eklenmesini isteyen şartnameye uymuştum

  • Seyrüsefer noktası adları küresel olarak benzersiz değilse ve bölgeler arası rotalar yaygınsa, bu seyrüsefer noktalarına neden GUID eklenmediğini anlayamıyorum
  • Merak ediyorum, geliştirmede hangi dili kullandıklarını bilmek isterdim
  • ICAO standardı, 1978'den beri tanımlayıcıların tekrarlanması için birbirlerinden en az 600 deniz mili (690 mil, 1.100 km) uzakta olmaları gerektiğini belirtiyor

• “Yedek sistem aynı mantığı uçuş planına uyguladı ve aynı sonuç ortaya çıktı” kısmı sorunlu. Yazılımda yedek sistem farklı bir mantık kullanmalı
  Eskiden Boeing'de 757 stabilizatör trim sistemiyle uğraşırken, trimi çalıştıran kablolamaya iki aviyonik bilgisayarı bağlıydı ve bunlar bir karşılaştırıcı üzerinden bağlanmıştı. İki kutu aynı fikirde değilse ikisinin de yetkisini kaybettiği bir yapıydı
  İki kutu; farklı algoritmalar, farklı programlama dilleri, farklı CPU'lar ve güvenlik duvarıyla ayrılmış farklı ekiplerin kodlarıyla tasarlanmıştı; amaç, bir taraftaki hatanın diğer tarafı aynı şekilde bozmasını engellemekti

  • Bu, pilotun yedek olduğu bir 2oo2 sistemi olmalıydı; 2oo2'nin kullanılabilirliği yüksek değildir
    Hava trafik kontrol sistemi en az 2oo3[1], yani bağımsız geliştirilmiş 3 sistemden her zaman 2'sinin uzlaşması gereken bir yapıda olmalı. Böylece bir sistem arızalansa bile kalan ikisi çalışmaya devam eder ve havacılık sektörünün kullanılabilirliğini etkilemez
    İnsanı yedek olarak tutmak, personel ve karmaşıklık nedeniyle mümkün değil. Hava trafik kontrol sistemi IFR[2] ve CVFR[3] koşullarında ayırma kontrolü sağlayabilmeli
    [1] https://en.wikipedia.org/wiki/Triple_modular_redundancy
    [2] https://en.wikipedia.org/wiki/Instrument_flight_rules#Separa...
    [3] https://en.wikipedia.org/wiki/Visual_flight_rules#Controlled...
  • Okurken benim de aklıma ilk aynı şey geldi. Bu failover sistemi, yazılım hatasından ziyade donanım arızasını hafifletmek için tasarlanmış gibi görünüyor
  • “Emniyet sistemi arızalandığında, güvenli biçimde arızalanamayacak şekilde arızalanır”
    J. Gall
  • Farklı ekipler de sık sık aynı hatayı yapar. Kusursuz bir yapı değil ama anlatılan yöntem makul görünüyor
  • Konu dışı sayılır ama MAX'te böyle bir yaklaşımı bilip de yeniden kullanmamış olmaları üzücü

• NATS'te aynı etkiyi yaratan başka bir sorun da olduğunu hatırlıyorum. Birincil sistem çöktü ve ikincile geçildi, ama ikincil de tam olarak aynı nedenle çöktü
  Failover sanırım yalnızca sorunun yazılımın kendisinde değil, birincil sistemin kendisinde olduğunu bildiğinizde yapılmalı. Körlemesine geçiş yapmak, gerçekte ne yapılması gerektiğine karar verecek kadar yeterli bilginin ortaya çıkarılmadığı hissini güçlendiriyor
  Daha da can sıkıcı kısım, “ValidateFlightPlan” gibi bir metodun olmaması; herhangi bir nedenle ayrıştırılamazsa hata fırlatması ve bu hatayı çok basitçe ele alan bir yolun bulunmaması. Dış girdi işleyicisine bakıp “bozuk, kötü bir girdi gelirse ne yaparım?” diye düşünmeyen programcı olur mu diye merak ediyorum

  • Birincil sistemin normal durumda olmadığı biliniyorsa, diskin yanmış olması ya da kozmik ışın kaynaklı bit flip gibi bir sorun çıkmış olmasını umarak geçiş yapmayı deneyebilirsiniz
    Asıl güvenlik özelliği, manuel işleme gerek kalmadan önceki 4 saatlik paydır
    Havacılıkta temel güvenlik kontrolü, “bunu en başta nasıl bozulmaz hale getiririz?”den çok “bu herhangi bir nedenle bozulursa ne yaparız?” sorusuna yakındır
  • Doğrulama olmamasının yanı sıra, yazıdaki şu kısım dikkatimi çekti
    Programlama tarzı çok imperatif ve anlatıma bakılırsa süreç, bir metin dosyasından ayrıştırılmış veri yapılarıyla değil, uçuş planının metin temsilini doğrudan işliyormuş gibi geliyor. Gerçekten öyleyse epey endişe verici, ama anlatım biçiminden de kaynaklanıyor olabilir
    Bu açıklamaya göre metin üzerinde regex ya da alt dize eşleştirmesi çalıştırıyor olmaları ve sınıf, nesne ya da veri yapısı olmayan bir yapı bulunması şaşırtıcı olmaz. Tüm Birleşik Krallık havacılığının bağımlı olduğu, yeniden yazılamayan ya da değiştirilemeyen onlarca yıllık C kodu olma ihtimalini de hesaba katmak gerek
  • Nedenin donanım olmadığını ayırt etmenin bir yolu olmadığı için failover'ın kendisi doğru. Ancak ikinci arıza yaşandığında zincirleme etkiyi önlemek için müdahale daha iyi tasarlanmalıydı
  • Elektrik açısından bakarsak, sigortayı değiştirip tekrar attığını izlemek gibi. Dükkânda başka sigorta yok. Bu bir ilerleme mi?
  • Ariane 5 fırlatma başarısızlığı[1] da benzer bir sorundu ve sonucu çok daha gösterişliydi
    Birincil sistem tamsayı taşmasıyla arızalandı, aynı ikincil sistem de onunla birlikte taştı. Hücum açısı arttı, iticiler ayrıldı ve roket patladı
    [1] https://en.wikipedia.org/wiki/Ariane_flight_V88

• Neden yalnızca başarısız olan uçuş planlarının insan inceleme kuyruğuna alınmadığını ve kalan uçuşların işlenmeye devam edemediğini anlamıyorum. O “özelliğin” olmaması en anlaşılması zor nokta

  • Kod o hatayı “bu asla olmamalı!” diye sınıflandırmıştı ve gerçekten de o oldu. “Uçuş planı verisi kötü” ya da “veri doğru ama henüz desteklenmiyor” diye sınıflandırmamıştı
    “Asla olmamalı” türü bir hata oluştuğunda, sistemde neyin yanlış olduğunu, etkinin ne kadar büyük ve yaygın olduğunu bilemezsiniz. Bu olayda olduğu gibi devam etmek mümkün olabilirdi; ama yazılımda ölümcül yeni bir hata ortaya çıkıp diğer tüm uçuş planlarını sessizce bozabilir ve insanları öldürebilirdi. Devam etmenin güvenli olup olmadığını bilmiyorsanız durmanız gerekir
  • Adil olmak gerekirse, yazının başlarında bu uçuş planlarının bazen hâlihazırda havadaki uçaklar için işlendiği de söyleniyor. En azından Birleşik Krallık’tan 4 saatten fazla uzakta olsalar da
    Sorunlu belirli bir uçağın kalkışını engelleyebiliyorsanız sistemi çalıştırmaya devam etmek sorun olmayabilir; ama uçak zaten havadaysa iş değişir
    “Birleşik Krallık hava sahasına girecek bir uçak rota üzerinde, ama ne zaman ve nereden gireceğini bilmiyoruz. O uçağın konumunu öğrenene kadar ek uçuş planlarını durduruyoruz” kararı tamamen mantıksız değil
    Uçuş planı gerçekten işlenemiyorsa, uçağı Birleşik Krallık’a ulaşmadan önce başka yere yönlendirip indirmek gibi bir çözüm makul olabilir; ama bu da sonuçta manuel müdahaleyi beklemesi gereken bir iş
  • Hem yazı hem de olay sonrası analiz, FPRSA-R sisteminin kötü arıza modunu temel sorun olarak görüyordu; bence de en önemli kısım bu
    Tüm sistemler arızalanabilir; önemli olan iyi bir şekilde arızalanmaları ve sorumluların bu duruma hazırlıklı olmasıdır
    Tek bir uçuş planı sorun çıkardı ve tüm FPRSA-R sistemi çöktü, hiçbir uçuş planı işlenmedi. Bir uçuş planında sorun varsa, insanın manuel olarak işleyeceği ayrı ve yavaş bir kuyruğa taşınmalı. NATS de “zaten gerçekleştirilen veya devam eden önlemler” arasında, IFPS ile FPRSA-R arasındaki veri akışına bu koşuldaki uçuş planlarını eleyecek bir mesaj filtresi ekleyeceğini kabul ediyor
  • Güvenlik açısından kritik bir sistemde “bilinmeyen hata” ile karşılaşırsanız, tüm değişmez koşulların bozulduğunu ve tanımsız davranışa girildiğini varsaymak zorundasınız; bu yüzden durmaktan başka çare yoktur
    Bunun bilinen bir hata olarak ele alınması gerektiği sözü haklı; ama geniş açıdan bakınca “hatasız kod yazılmalıydı” demeye benziyor. Bir struct olarak ayrıştırılmış olsa bile, seçimli bir anahtarın var olduğunu varsayan kodda birden KeyError fırlaması gibi olabilir
    Bu tür olayların olay sonrası analizi ve iyileştirilmesi, öngörülemeyen, yakalanmamış bilinmeyen hataların bir gün mutlaka ortaya çıkacağı varsayımıyla, o anda bunun nasıl daha iyi ele alınacağını tartışmalı. Bir bug’ın çözümü bug’ı düzeltmektir; ama büyük kesintinin nedeni, makul bir süre içinde uygulanamayacak bir felaket kurtarma planıydı. Hangi programlama pratiği, tarzı, dili ya da aracı kullanılırsa kullanılsın, benzer ölçekte bir olay en iyi geliştiricilerin elinde bile bir gün olasılık 1 ile yeniden yaşanır
  • Yazıda anlatılan algoritmanın, girdi uçuş planındaki yol noktalarını sırayla izleyen basit prosedürel kod olması pek olası değil. Bir tür soyutlama, bunun girdi hatası olduğu gerçeğini perdelemiş olabilir
    Kod açısından bu, alttaki seyrüsefer yol noktası veritabanının bütünlük hatası gibi görünmüşse, uçuş planı işlemeyi durdurma kararı çok daha anlaşılır olur
    Örneğin kod, yol noktası ve rota deposuna “bu rotanın Birleşik Krallık hava sahasından çıktığı yol noktasını bul” diye soruyor, sonra o yol noktasını içeren rota segmentini buluyor ve ardından bu segmentin Birleşik Krallık hava sahasından geçtiğini kesinliyor; bu kesinleme başarısız oluyorsa, bu bir uçuş planı sorunu değil, rota verisine gömülü bir varsayımın bozulması gibi görünebilir
    Bir anlamda gerçekten ölümcül bir bug olması da mümkün. Bu olay, algoritmanın veri hakkında yaptığı varsayımın yanlış olduğunu ve potansiyel olarak yanlış yanıt döndürebileceğini gösteriyor

• İlgili yazılar
  Aynı yol noktası adının tesadüfen çakışması Birleşik Krallık hava trafik kontrol sistemini yanılttı - https://news.ycombinator.com/item?id=37430384 - Eylül 2023, 64 yorum
  Kötü uçuş planı verisi Birleşik Krallık hava trafik kontrol arızasına yol açtı - https://news.ycombinator.com/item?id=37402766 - Eylül 2023, 20 yorum
  NATS hava trafik kontrol olay raporu kök nedeni ve çözümü ayrıntılı olarak açıkladı - https://news.ycombinator.com/item?id=37401864 - Eylül 2023, 19 yorum
  Birleşik Krallık hava trafik kontrol ağı arızası - https://news.ycombinator.com/item?id=37292406 - Ağustos 2023, 23 yorum

  • The Daily’nin ABD havacılık sektörüyle ilgili son bölümünü dinledikten sonra, yakında felaket niteliğinde manşetler göreceğimize ikna oldum. Böyle devam edilemez
  • Bu yazı başlığını görünce şu anda yeni meydana gelmiş bir arıza sandım

• Eurocontrol’ün zaten kabul ettiği bir Fransız uçuş planını suçlamaları, yazılımın nasıl çalıştığını doğru dürüst bilmediklerinin kanıtı. Avusturyalı şirket de yoğun test eksikliği konusunda sorumluluğun bir kısmını üstlenmeli

  • Birleşik Krallık oldukları için Fransa’yı suçladılar sadece. Kötü alışkanlıklardan kurtulmak zordur

• Harika bir yazı. Okuyunca ana fikrin şu olduğunu düşünüyorum:
  Dünya genelinde kullanılan yol noktası adları benzersiz değil; karışıklığı önlemeye yönelik bir tür yama olarak güncel standart, aynı tanımlayıcıların coğrafi olarak yeterince uzağa yerleştirilmesini söylüyor. Yine de tek bir rota içinde aynı yol noktası adı farklı konumları ifade edebiliyor.
  Yazılım bu olasılığı hesaba katmamış, rota hesaplaması başarısız olmuş, “ölümcül istisna” fırlatmış ve “bakım moduna” girmiş. Yani ölmüş.
  Yedek sistem devralmış ama aynı verilerle aynı hataya yakalanıp o da ölmüş; destek ekibi de epey uğraşmış. Sonunda ancak yazılım tedarikçisiyle iletişime geçtikten sonra nedeni ortaya çıkaran düşük seviyeli logları bulmuşlar.

  • Bu seviyede görev kritik bir sistem için, koda aşina birinin neden 7/24 çağrıya hazır beklemediğini anlayamıyorum.
  • Asıl mesele uygun bir ad alanı olmamasıydı. Havacılık ve uzay mühendislerinin işletim sistemleri çalışması gerekeceğini kim bilebilirdi?
    Emekli Hava Kuvvetleri pilotu bir arkadaşım Cranfield University mezunu; burası Birleşik Krallık’ın önde gelen havacılık ve uzay mühendisliği lisansüstü kurumlarından biri ve eğitim/araştırma amaçlı kendi havalimanı da var[1]. O arkadaş Cranfield’da işletim sistemleri öğrendiğini söylemişti; nedenini şimdi anlıyorum.
    Diğer yorumlara bakılırsa ad alanı standardı zaten var ama NATS/ATC bunu kullanmıyor gibi görünüyor. Umarım bu olay vesilesiyle kullanmaya başlarlar. En üstteki yorum geofencing hatasından söz etmişti ama NATS/ATC doğru ad alanını kullanıyor olsaydı geofencing’e baştan hiç gerek kalmamış olma ihtimali yüksek.
    [1] Cranfield University:
    https://en.wikipedia.org/wiki/Cranfield_University

• “Açıklamaya bakınca, prosedürün bir metin dosyasından ayrıştırılmış veri yapılarıyla değil de uçuş planının metinsel gösterimiyle doğrudan çalıştığı izlenimi doğuyor. Gerçekten öyleyse epey kaygı verici, ama anlatım biçiminden de kaynaklanıyor olabilir.”
  Havacılık sektöründeki işlerde bu tarz yaygın. Programcılara alan modeli ya da ayrıştırma sorduğunuzda boş boş bakabiliyorlar. Doğrulama kodunu seviyorlar; doğrulama olmazsa da dümdüz vazgeçmeyi seviyorlar. Hepsi aptal veri pipeline’ları; gerçek dünyadaki faaliyetleri modelleyen kod ise hiç yok.
  Hiçbir sistemde davranışı olan bir “uçuş planı” tipi ya da yol noktası tipleri kümesi gibi şeyler yok. Tip olsa bile C bakış açısından bir string struct’ı ve o struct’ın üyelerine her erişildiğinde bir kez değil, her seferinde yeniden ayrıştırılıyor. Yazıda söylendiği gibi, “programlama tarzı çok imperatif görünüyor” ifadesi doğru.

  • Doğrulama başarısız olduğunda vazgeçmek, yanlış yorumlanmış verilerin yayılıp çok daha karmaşık hatalara yol açmasını önlemek için standart bir yöntemdir. Erken doğrulamak, sıkı doğrulamak, hatayı raporlamak ve girdide neyin tuhaf olduğunu zorla yorumlamaya çalışmamak gerekir. “Akıllı” davranmaya çalıştığınız anda güvenlik açığı doğar.
    Kötü girdide ölmek hatadır; ama spesifikasyon olmadan doğrulanmamış verileri yorumlamaya çalışmak, sonrasında anlayış uyuşmazlıklarına, uyumluluk sorunlarına ve beklenmedik sınır koşullarına kolayca yol açar. Tam test edilmiş her durumu kapsayan sistemlere, hatalı girdi simülasyon araçlarına, ayrıştırıcıların ve ayrıştırıcı sonuçlarını kullanan tüm kodun biçimsel doğrulamasına kimse para ödemek istemiyor.
    Zaten uyumsuz, legacy ve hatalı veri göndericiler ile arayüz semantiği ve zamanlama karmaşıklığı yüzünden yeterince sorun var. Biçimi ya da kodlaması bozuk verilere akıllıca tepki vermeye çalışmak daha da tehlikeli hale gelir.
    Spesifikasyona göre çalışan sistem yapmak bile zor ve pahalı. Spesifikasyonda yer almayan davranışları daha hoşgörülü kabul eden ince varyasyonlar ya hata davet etmektir ya da satın alma fiyat kriterini aşan daha pahalı sistemler üretmektir.
  • Çok ilginç ve biraz da ürkütücü. Farklı sektörlerin pek de net olmayan nedenlerle kendilerine özgü farklı geliştirme kültürleri oluşturmuş olması ilginç.

• “Birleşik Krallık hava trafik kontrolü: Fransız hatasının arızaya yol açıp açmadığı araştırılıyor”
  Tabii ki hayır. Bu Birleşik Krallık sistemi; nasıl bir Fransız havayolunun suçu olabilir? Böyle sistemlerin yedekliliğe sahip hata önleyici mimariler olması gerekir.
  Tek bir kayıt kötüyse onu reddedip devam etmek bile yeterli olabilirdi.

  • Milliyetçi açıdan bakmak gerekirse, o yazılım Avusturya yapımıydı.

• Hatırlamak istemediğim bir gündü. Normalde 2 saatte varacağım yere 15 saat sürdü.
  Tren, otobüs, sonra tekrar tren yaptım; bilet aldıktan 30 dakika sonra iki günlük tüm biletler tükenmişti.

  • Uçağın iptal edildiğini ancak havalimanında 6 saat bekledikten sonra öğrendim ve yeniden rezervasyon yaptırmam gerekti. Ailemi görmek için New York’a gidiyordum; pek alternatif ulaşım seçeneği de yoktu.