Benim 500 Milyon Dolarlık Mars Rover Hatası

 (chrislewicki.com)
1 puan yazan GN⁺ 2023-11-29 | 1 yorum | WhatsApp'ta paylaş
  • Şubat 2003'te JPL temiz odasında Spirit Mars Rover, fırlatma sahasına taşınmasına 2 hafta kala ve tek bir break-out-box bağlantı hatası 500 milyon dolarlık uzay aracını mahvetmiş olabilirdi
  • Spirit ve Opportunity, NASA'nın toplamda neredeyse 1 milyar dolar yatırdığı ikiz Mars rover göreviydi ve takvim nedeniyle büyük bir arızayı telafi edecek neredeyse hiç zaman yoktu
  • Elektrik darbesi motora değil uzay aracına girdikten hemen sonra telemetri kesildi, ancak hasarın olup olmadığı ve nedeni hemen kesinleştirilemedi
  • Ertesi gün, telemetri kaybının Fluke 87III multimetre probunun çıkarılmasından kaynaklandığı doğrulandı; gerçek surge ise H-Bridge motor sürücüsü kanal analizinin konusu olarak kaldı
  • Proje, birkaç haftalık analizin ardından donanımı Use As Is olarak değerlendirdi; prosedürleri düzelttikten sonra aynı testi sürdürdü ve Spirit'in ilgili motoru Mars'ta normal çalıştı

Fırlatma öncesi Spirit'te yaşanan test kazası

  • Şubat 2003'te, NASA JPL'in Building 179 High Bay 1 temiz odasında Spirit Mars Rover, Cape Canaveral'a taşınmasına 2 hafta kala bulunuyordu
  • Spirit ve Opportunity ikiz Mars rover görevleriydi ve o dönemde NASA'nın neredeyse 1 milyar dolar yatırdığı karmaşık uzay araçlarıydı
  • Montaj ve test aşamasında, uzay aracı Dünya'da son kez kapatılmadan önce tüm sistemlerin ayrıntılı biçimde test edilmesi ve normal çalıştığının doğrulanması gerekiyordu
  • İki roverda toplam 62 adet brushed-type motor bulunuyordu
    • Tekerlek sürüşü ve yönlendirme
    • Robot kol kontrolü
    • Kamera hedefleme
    • Dünya'ya dönük anten yönlendirmesi
    • İniş sonrası açılma ve konuşlanma hareketleri
  • O gece test edilen parça, Spirit'in robot kolunun ucundaki Rock Abrasion Tool(RAT) içindeki RAT-Revolve motoruydu
    • RAT-Revolve motoru, Mars kayaları üzerinde grinder ve brush'ı döndürme görevini üstleniyordu

Motor durumunu elektrik sinyaliyle doğrulama prosedürü

  • Her çevresel testten sonra motoru söküp içini incelemek pratik değildi
  • Bunun yerine motor uzay aracından ayrılıyor, harici güç kaynağına ve bir strip chart recorder'a bağlanarak elektriksel performansı doğrulanıyordu
  • Normal bir motorda spin-up sırasında akım düzgün bir üstel eğri şeklinde azalır; anormallik varsa sinyalde bir blip görünürdü
  • Testte bir break-out-box kullanılıyordu ve bağlantı yanlış yapılırsa büyük akım yanlış yere gidip ölümcül hasara yol açabilirdi
  • Ön kontrolde bağlantı arayüzü, güç kaynağı ayarları, strip chart ayarları ve referans motor üzerindeki kısa test darbesinin hepsinin normal olduğu doğrulandı

Yanlış yöne giden elektrik darbesi

  • RAT-Revolve motoruna enerji verildiği anda strip chart üzerinde alışılmadık bir sinyal belirdi ve bu, arızalı bir motora özgü tipik sinyalle de uyuşmuyordu
  • Kablolama izlenince, break-out-box hatası nedeniyle elektrik darbesinin motora değil, konektör arayüzünün ters yönünde uzay aracına doğru gittiği görüldü
  • Spirit, fırlatma hazırlığı için taşınmasına 2 hafta kalmış durumdaydı; büyük bir sorun çıkarsa toparlayacak zaman yoktu
  • Olay hemen test conductor Leo'ya bildirildi ve aynı anda uzay aracından telemetrinin kesildiği yanıtı geldi
  • Ekip derhal acil kapatma prosedürünü uyguladı ve olayın gidişatını ile hasar değerlendirmesini yapmak üzere temiz odadan çıkmaları istendi

Telemetri kaybı ve ilk değerlendirme

  • Olaydan hemen sonra doğrulanan iki gerçek vardı
    • Büyük bir elektrik darbesi amaçlanan yer dışında bir yere gitti
    • Uzay aracının telemetrisi durdu
  • Bu iki olay arasındaki bağlantı hemen net değildi
  • Ekip, elektrik surge'ünün H-Bridge motor sürücüsü devresine girmiş olma olasılığını yüksek gördü
    • H-Bridge, elektrik akışını kontrol eden bir devre olarak ele alınıyordu
    • back-EMF nedeniyle roverda ek enerjiyi tolere edecek şekilde tasarlanan bölümlerden biriydi
  • Uzay aracı zaten kapatılmıştı ve ekip, gücü yeniden verince sorunun düzelip düzelmeyeceğini kontrol etmeye karar verdi
  • Gece yarısına doğru olay raporu proje yöneticisi Pete'e kadar ulaştı ve yaklaşık 1.000 kişilik projenin yeniden planlanması ihtimali söz konusuydu

Yeniden başlatma başarısızlığı ve ertesi gün bulunan gerçek neden

  • Standart uzay aracı güç verme prosedürü yeniden uygulandı, ancak elektronikler ve yazılım devreye girdikten sonra bile telemetri geri gelmedi
  • Yer destek ekipmanı rafında, her clock cycle'da darbe alıp yanan kırmızı bir gösterge vardı ve bu saniyede 8 kez atan robotik bir kalp atışı gibi kullanılıyordu
  • Güç kaynağı tanıdık voltaj kademelerini ve akım değişimlerini gösterdi, ancak gösterge yanmadı ve telemetri de gelmedi
  • Ertesi gün olay sırası yeniden gözden geçirilirken, Fluke 87III dijital multimetre kilit ipucu oldu
  • Bir önceki gün test için gereken multimetre aranırken, uzay aracının yakınında bus voltajını izliyor gibi görünen multimetrenin probları çıkarılmıştı
    • Bu multimetre aslında uzay aracının yer test telemetri güç devresini tamamlıyordu
    • Problar çıkarıldığı anda telemetri güç bağlantısı kesildi

Spirit hayattaydı ve donanım olduğu gibi kullanıldı

  • Ekip, multimetreyi eski görevine geri döndürdü ve uzay aracına yeniden güç verdi
  • Telemetri yeniden canlandı ve Spirit'in ölmediği doğrulandı
  • Gerçek kayıp yalnızca birkaç saatti ve testler yeniden başladı
  • Sonraki birkaç hafta boyunca RAT-Revolve motorunun H-Bridge kanalı analiz edildi ve thin-film demetallization olasılığı üzerine ayrıntılı tartışmalar sürdü
  • Sonunda proje, ilgili donanımı Use As Is olarak değerlendirdi
  • Rover'ın fırlatma hazırlıkları sürdü ve Spirit Mars'a ulaştıktan sonra RAT-Revolve motoru normal çalıştı

Başarısızlık deneyimleriyle başa çıkma biçimi

  • Bu olay, başarısızlık deneyimlerini paylaşmanın hem anlatan hem dinleyen için öğrenme fırsatı olabileceği inancına yol açtı
  • Planetary Resources'ta işe alım sürecinde ve ekip kültüründe adaylardan kendi failure story'lerini paylaşmaları isteniyordu
  • Kriz sırasında Ernie, “Bir dahaki sefere bir şeyin sorun olmadığını onaylaman gerektiğinde bu duyguyu hatırla” dedi
  • Olaydan sonra bazıları bu tür riskli testlerin durdurulması gerektiğini düşündü, ancak motorun Mars'ta normal çalışıp çalışmayacağını doğrulayan testin önemi nedeniyle testler sürdürüldü
  • Proje yöneticisi Pete, aynı kişinin testi yönetmeye devam etmesini sağladı ve “Onun eğitim ücretini biz ödedik; bu hatayı tekrar yapma ihtimali en düşük kişi o” anlayışıyla karar verdi
  • Ardından aynı hatanın tekrarlanmaması için prosedürler düzeltildi ve aynı test birçok kez yeniden uygulandı
  • Bu deneyim, önemli bir onay ya da güvence verilirken o andaki korku ve pişmanlığı hatırlatan bir referans noktası haline geldi

İlgili okumalar

1 yorum

 
GN⁺ 2023-11-29
Hacker News yorumları

  • Yazı gerçekten çok iyi yazılmış
    Bir yazılım mühendisi olarak kariyerimin başlarında yaşadığım benzer bir olay hâlâ aklıma geliyor. Yaklaşık 10 yıl önce danışmanlık yaptığım bir müşterinin web servisinin yeni sürümünü birkaç ay boyunca geliştirmiştim ve çıkış günü dağıtımı ben üstlendim; o zaman geliştirme ve dağıtım süreçleri neredeyse tamamen manueldi. Mümkün olan kısımları script’ler ve SQL ile otomatikleştirmiştim; dağıtımdan hemen önce son testi yapmak için Enter’a bastığım anda, az önce production kimlik bilgilerine geçtiğimi fark ettim
    Hatalar birikmeye ve servis yanıt vermemeye başlayınca veritabanını uçurduğuma emin oldum; ama birkaç saat önce birinin çıkışa hazırlık için yedeği tamamlamış olması sayesinde çoğu şey geri yüklendi. Ondan sonra veritabanları ve production sistemleriyle çalışırken dikkatli olmak sözü yetersiz kalacak kadar hassaslaştım ve bunu bir daha asla yapmamaya yemin ettim

    • Biz de event sourcing mimarisi kullandığımız için production veritabanına doğrudan erişmemiz nadirdir. Gerektiğinde bir shell script’iyle bastion host üzerinden tünel açar ve Postgres istemci yapılandırması için standart ortam değişkenlerini dışa açarız
      Test suite, çalışırken tabloları silip yeniden oluşturur ya da boşaltır. Bir gün lead developer, production DB’de bir hata düzeltmesini araştırdıktan sonra make test çalıştırdı. Test kodu ortam değişkenlerini aynen izleyip Docker’a değil production’a bağlandı ve hemen o production tablolarını onlarca kez silip yeniden oluşturdu
    • Yaklaşık 10 yıl önce danışmanlık yaptığım bir yerde, başka bir üründen sorumlu şirket içi çalışan geliştirme DB’sine ve production DB’ye aynı anda farklı pencerelerden giriş yapmışken yanlışlıkla production veritabanını sildi. Geri yüklemeye çalışınca yedeklerin aylardır başarısız olduğu ortaya çıktı; yeni ürüne yardım edecek danışman tutmalarının nedeni de böylece netleşti
      Neyse ki her müşteri sitesinde merkezi DB ile senkronize olan yerel bir DB vardı; bağlantı koptuğunda bile ürün çalışıyordu. O da 3-4 gün boyunca uzun mesailer yaparak eski bir yedekle müşteri verilerini birleştirip master DB’yi yeniden kurdu
    • Bir keresinde Visual Studio içinde production veritabanına migration çalıştırmıştım. Geriye dönüp bakınca kurtarılabilir bir şeydi, ama VS ağaç görünümünde tüm tabloların kaybolmaya başladığı an kalbim duracak sandım
      Bir saniye sonra tekrar göründüler; meğer sadece görünüm yenilenmiş. Gerçekten berbat bir UI’dı
    • Yaklaşık 15 yıl önce, uzun bir hafta sonu öncesi işten çıkmaya hazırlanırken yakın olduğum bir pazarlama çalışanı müşteri sitesinde hızlı bir değişiklik istedi. Yaklaşık 15 kişilik küçük bir şirketti ve kaldıramayacağımız kadar çok müşterimiz vardı; bu yüzden sahip olmamam gereken production veritabanı erişim yetkisine sahiptim
      Ürün pazarlama metnini değiştirmek için kısa bir UPDATE sorgusu yazdım; anında bitmediği anda mahvolduğumu anladım ve koşul koymadan hepsini güncelleyip binlerce ürün açıklamasını değiştirmiş oldum. Yedeklere erişimi olan DB yöneticisi başka bir saat dilimindeydi ve çoktan işten çıkmıştı; bir saatten fazla telefon trafiğinden sonra geri yükleyebildik
      Çıkarken yapılacak hızlı bir değişiklik birkaç saatlik toparlama işine dönüştü. Pazarlama arkadaşım sürekli özür diliyordu ama hata benimdi. Müşterilerden pek ses çıkmamasının sebebinin, resmî tatil hafta sonundan önceki cuma günü saat 17.00 olması olduğunu düşünüyorum
    • Yaklaşık 20 yıl önce çalıştığım yerde, sudo komutu çalıştırırken Enter’a basmadan önce başka birinin komutu kontrol etmesi gerektiğine dair bir politika vardı. Production’da yapılan her iş için de benzer bir politika ya da teamül uygulanabilir

  • Aklıma şu cümle geliyor: Bir stajyer production veritabanını sildiyse, bu kötü stajyer değil kötü süreç demektir
    Bunun bir süreç sorunu mu yoksa insan sorunu mu olduğunu belirlemek, tam zamanlı çalışanlardan daha fazla beklenti olması nedeniyle kolay değil; ama onun yerine kendimi koyunca, ne olduğunu anladığı andaki korku ve acı okunuyor ve insanın boğazı düğümleniyor. Umut ışığının sönüp sonra yeniden canlanması hissi de dahil; bu kadar çok insanın bağlı olduğu bir projeyi hiç üstlenmedim
    Benim ölçütüme göre hepsi kahraman

    • Büyük bir aracı kurumda, bir test script’inin yanlışlıkla production’a dokunup milyonlarca dolarlık sahte döviz test işlemleri oluşturduğu olmuştu
      Olay sonrası analiz görüşmesindeki ilk söz şuydu: “Bu işlemleri oluşturan kişiyi suçlamayacağım. Dürüst bir hataydı. Bunun yerine bir geliştiricinin kimlik doğrulama olmadan production işlem API’sine neden erişebildiğini konuşalım.”
    • Bu tür kurumsal başarısızlıklarda birey suçlanmamalı. İki süreç sorunu görüyorum: Fiş ters bağlanabiliyorsa en baştan imkânsız hâle getirilmeli ya da risk belirlenip yönü en az iki kişinin doğrulaması sağlanmalıydı; kullanılan multimetre gibi araçlar da asla ayrılmamalı
      Bireyi suçlarsanız sadece o kişi kovulur ve kurumun tamamı zayıflar. Pahalı bir ders almış tek kişiyi göndermiş olursunuz. Bireyin sorumlu tutulması gereken zaman, yalnızca zarar verme niyeti olduğunda olmalı; o durumda da hukuk devreye girebilir
    • Okuldan sonraki ilk web geliştirme işimde, daha ilk gün production web sitesini çökerttim. On binlerce ziyaretçi etkilendi ve tüm satış lead’leri durdu; ama birkaç dakika içinde yeniden ayağa kaldırdım ve tüm ekibin, yan odadaki CEO’nun da izlediği zor bir anı atlattım
      Birkaç yıl sonra ayrıldığım sıralarda, o kırılgan ve istikrarsız siteyi otomatik testleri, çok aşamalı yedekleri, birden çok veri merkezine yayılan failover sistemi, yeni geliştirici eğitimi ve onboarding’i olan bir sisteme dönüştürmüştüm. AWS’in ilk dönemleriydi; production sitesinin tek tıkla dağıtıldığı zamanlar değildi
      Bu deneyim sayesinde düzgün sürüm kontrolünü, geliştirme ortamlarını, Redis’i, sharding ve clustering’i, VM’leri, Postgres ve MySQL replikasyonunu, wiki’leri, monit’i, DNS’i, load balancer’ları, reverse proxy’leri ve daha fazlasını öğrendim. Çünkü bir daha siteyi çökertmek istemiyordum
      Biraz WordPress deneyimi olan lise terk birine saatlik 15 dolar verip production web sitesini emanet eden küçük bir şirketti; ama hatadan sonra beni kovmadılar, sahada öğrenip sistemi iyileştirme özgürlüğü ve güveni verdiler. Bunun için hâlâ minnettarım
    • Bu durum farklı. Üzerinde ilk kez isim yazan özel yapım tek bir roverdı ve zaten her türlü süreç vardı; ama her şeyi öngörmek mümkün değil. Muhtemelen sonrasında süreci düzeltmişlerdir, fakat bunun onlar için de ilk deneyim olduğunu unutmamak gerekir
      Kuralların çok olması ve süreçlerin iyileşmesi her zaman iyi değildir. Bazen bürokrasi, zaten yavaş olan NASA’yı daha da yavaşlatır. Türünün ilk örneği görevlerde, sürece değil insanlara güvenmek ve risk almak gereken zamanlar olabilir
    • Rover gerçekten yok olsaydı ne olurdu diye düşünmeden edemiyorum. Bunun önlenmesi tamamen şans gibi görünüyor; koruma devresi olmayan başka bir yanlış uca da bağlamış olabilirdi
      Yani sonucun bir kısmı yazarın yeteneği dışında belirlenmişti ve korktuğu gibi rover’ı mahveden kişi olarak sonsuza dek hatırlanma olasılığı da aynı ölçüde vardı

  • Kendi deneyimimle de büyük ölçüde örtüşüyor. Büyük bir havayolu şirketinde en zor ve riskli projeleri seçip üstlenirdim; bunlardan biri de web sitesi için yeni ödeme sağlayıcısını hızla hayata geçirmekti. O site her gün milyonlarca avroluk bilet satıyordu.
    Yayına aldıktan birkaç saniye sonra test ortamı ile üretim ortamı arasındaki farkı gözden kaçırdığımı ve kritik bir değişkenin üretimde boş olduğunu fark ettik. Belgeleri daha fazla okuyup hazırlansaydım öngörülebilecek bir şeydi; satış tamamen durunca içim cız etti. Uzun bir rollback sürecinin ardından satışlar birkaç saat kesildi, öfkeli müşteriler yığıldı ve milyonlarca avro zarar oluştu.
    CEO’yu asansörde yakalayıp tamamen benim hatam olduğunu, işten çıkarılmak dâhil her türlü sonucu kabul edeceğimi söyledim. O ise gülerek “Seni neden göndereyim? Az önce seni eğitmek için milyonlar harcadık. Düne göre işini daha iyi yapar hâle geldin” tarzında yanıt verdi. Bu deneyim, gerçek liderlik dâhil pek çok açıdan beni şekillendirdi; sonrasında birçok yüksek riskli projeyi başarıyla tamamladım.

    • Cümleler fazla pürüzsüz; doğrudan CEO’ya gitmesi ya da “en iyi performans gösteren kişi” ile “şirket milyonlar kaybetti” gibi ayrıntıların bir arada geçmesi pek inandırıcı gelmiyor. LLM tarafından yazılmış ya da en azından uydurulmuş bir metin gibi hissettiriyor.
    • Havayolu bilet rezervasyon sayfalarının zamanın yarısından fazlasında bir yerlerinin bozuk olduğu hissine sık sık kapılıyorum. Tamamen boş ekran olmasa bile bilet rezervasyonu yapılamayacak kadar sık bozuluyorlar; bence boş ekran daha iyi olurdu. En azından 30 dakika boşa harcamazdım.
      İnternet genel olarak da sık sık bozuk. Black Friday’de ödeme sırasında Nike web mağazası hata veriyor, yardım masası çözümü de “uygulamayı kullanın” oluyor.
    • Zarar sanıldığı kadar büyük olmayabilir. Birkaç saat boyunca kimse bilet alamadığı için teorik olarak o saatlerin milyonlarca avroluk cirosu kaybedilmiş sayılır; ama bu, insanların daha sonra tekrar denemeyeceği varsayımına dayanır.
      Gerçekte kesinti süresinin birebir zarara dönüştüğünü sanmıyorum. İlk dönem Twitter, popülerliği ve mimarisi nedeniyle sık sık çöküyordu ama insanlar Twitter kullanmayı bırakmadı.
      Çevrimiçi hizmetlerde kesinti felaket ya da şirketin sonu değildir. Uzay ekipmanı ya da şirketi batırabilecek yüksek frekanslı işlem yazılımı söz konusuysa farklı; bu yüzden daha sıkı denetim mekanizmaları olmalı. Teoride böyle; pratikte ise uzay ve yüksek frekanslı işlem sektörlerinden öğrenilmiş en iyi uygulamalarla yapılmış özensiz CRUD web servislerinden bile kötü örnekler çıkabiliyor.
    • Havayolu tarafında sorumlu kişi olsaydım, tepkinin havacılık kazası sonrası analiz ruhuna daha yakın olmasını isterdim. Sistemsel nedenleri bulup düzeltme yaklaşımı olmalı.
      Üretim dağıtımlarında, yardımcı pilot gibi birlikte kontrol edecek ve rollout’u durdurma yetkisi olan birine ihtiyaç olabilir; sıradan DevOps koruma mekanizmaları da yanında olmalı.
    • “Neden işten çıkarayım? Az önce seni eğitmek için milyonlar harcadık!” diye biten eski fıkra aklıma geliyor.
      Yüksek riskli projeler üstlenen insanlar çoğu zaman hafife alınır. Birçok yönetici, beklenen değeri pozitif ama oynaklığı olan çalışan yerine, istikrarlı biçimde hiçbir değer üretmeyen çalışanı tercih eder.

  • TV sektöründe çalışıyorum. 30 yıl önce küçük bir yerel kanaldaki ilk işimde haber bültenlerinde teyp operatörü olarak eğitildim. Yayın kasetleri büyük yığınlar hâlinde dururdu ve dört adet oynatma VTR’i vardı. Benim işim her kaseti takıp 1 saniyelik preroll noktasına ayarlamaktı.
    Bir kasetin oynatımı bitip çıkarma zamanı geldiğinde, az önce biten VTR’in değil de o anda yayında olan VTR’in çıkarma düğmesine basmak çok kolaydı. Beni eğiten kişi, çıkarma düğmesine her uzandığımda dişlerini sıkarak yüksek sesle nefes alır, adeta alarm verirdi; o ses yüzünden durup iki, üç kez kontrol eder, sonra kaseti çıkarırdım.
    Gerçekten sinir bozucuydu ama dikkatli olmaya şartlandırmakta etkiliydi. Kanalın politikası, canlı yayın sırasında kaseti ilk kez çıkarırsan ücretsiz bir gün izin, ikincisinde denetimli çalışma, üçüncüsünde işten çıkarılma şeklindeydi. Bazı iş arkadaşları kronik dikkatsizlik yüzünden işlerini kaybetti ve haber bültenlerini mahvetti. O sinir bozucu eğitmen sayesinde kontrol edip tekrar kontrol etme alışkanlığı edindim; yayın sırasında hiçbir zaman kaset çıkarmadım.

    • 80’lerin başında TV’de popüler olan eski yayın kazaları derlemelerinin neden öyle olduğunu açıklıyor. Muhabir bir şeyler söylerken arka plandaki görüntünün tamamen alakasız bir sahne olması gibi.

  • Böyle bir hatayı yapan kişinin aynı hatayı bir daha yapmayacağına katılıyorum. Bu yüzden teknik olarak hata yapmış ve açıkça bunun acısını çeken birini işten çıkarmak genelde kötü bir tercihtir.
    Ama bunun “asıl” ders olduğunu düşünmüyorum. Maliyet ve risk düşünüldüğünde, büyük bir güç dalgalanmasıyla test edilen parçalara, duman çıkarmaya yatkın parçalarla uyumlu olmayan özel test konnektörleri verilmesi gerektiği dersini çıkarıyorum.
    Bu küçük bir breadboard projesi değil; resmî prosedürler yüzünden çok zaman ve para harcanan, bazen de alay konusu olan bir devlet kurumunda çok sayıda insanın yaptığı dev bir proje. “28 yaşındaki birine, eli kayarsa patlayabilecek 500 milyon dolarlık bir robotu emanet edelim” mantığı kulağa çok tuhaf geliyor.

    • Yanlış takılamayacak şekilde tasarlanması gerektiği doğru. Aslında çoğunun böyle tasarlandığını düşünüyorum, ancak tasarım aşamasında hesaba katılmamış hatalı konfigürasyonlar yine de ortaya çıkabilir.
      Özellikle test sırasında “normal konfigürasyon”dan farklı özel kablolar, konnektörler ve devrelerle uğraşmak sık görülür. Bence çıkarılacak ders, kritik işleri mümkün olduğunca 4-eyes ilkesiyle yapmaktır. Bir kişinin işi yapıp, başka bir kişinin de her adımı onayladıktan sonra devam edildiği yöntem, makaledeki gibi “akıl almaz hataları” yakalamakta çok etkilidir.
      Ancak takvim baskısı gibi nedenlerle her testte iki kişinin birden bulunması her zaman mümkün olmadığından, gerçek hayatta bu tür hatalar yaşanır. Tüm sistemi dayanıklı hâle getirmek gerekir.
    • Ben de başta böyle düşünmüştüm. Ancak yalnızca bir kez yapılan bir test döngüsünden geçen tek seferlik ekipman söz konusuysa bu kararı vermek zorlaşıyor.
      Bilgi işlemde de üretim veritabanı ya da yönlendirici ayarlarında, yükseltme veya geçişin bir parçası olarak tam bir kez yapılan benzer işler çok. Bazen emniyet mekanizması oluşturmanın maliyeti, en baştan dikkatli olmaktan daha yüksektir. Biz her zaman kusursuz dikkatli olamıyoruz; ama emniyet mekanizmalarını da her zaman kusursuz yapamıyoruz ve hatalı bir emniyet mekanizmasına güvenip benzer hatalar yapabiliyoruz.
      Hikâyedeki durumda, donanım versiyonu pair programming gibi, yazarın yaptığı her şeyin doğru olduğunu doğrulamaktan sorumlu bir partner olması gerekebilirdi. Mary gibi işi bölüşerek yardımcı olan bir yardımcı değil, tek görevi onu takip edip kontrol etmek olan biri olmalıydı.
    • Dikkatli okursanız, güç H-köprüsünün güç çıkış uçlarına girmiş; H-köprüsü de sağlam bir elektronik devre olduğu için sonuçta hiçbir şey zarar görmemiş. Kapatma bununla alakasızdı.
      Motor kontrolcüsünün veri hatlarına girseydi büyük olasılıkla bir şeyler yanardı. Konnektör tiplerinin farklı olup olmadığını tamamen dışlayamayız, ama yanlış bağlanan iki konnektörün aynı tip olarak atanmış olduğu doğru.
    • İnsanlık Ay’a ilk kez indiğinde Mission Control mühendislerinin ortalama yaşı 28’di.
    • Bu sektörde çalıştığım için böyle bir şeyin nasıl olabildiğini açıklayabilirim. Pahalı projelerde bile her yerde benzersiz konnektörleri zorunlu kılamazsınız. Çünkü gereksinimler birbiriyle rekabet eder.
      Özellikle konnektörlerde, hâlihazırda sertifikalı ürünler, belirli derating değerleri, pin aralığı, topraklanmış backshell gibi çok sayıda muhafazakâr gereksinim vardır. Sonunda kullanılan ve stokta tutulan konnektör serileri yalnızca birkaç taneyle sınırlı kalır; ne kadar para harcarsanız harcayın bunların hiç çakışmamasını sağlamak gerçekçi değildir. Genelde aynı sinyalleri standartlaştırmaya ya da çakışmayacak şekilde benzersiz hâle getirmeye çalışılır.
      Örneğin uzay aracının dış konnektörlerinde, elleçleme sırasında kısa devreyi önlemek için soket tipi konnektör gerekir; ara harness ise asla sökülmez ve pin tipi konnektörler simetrik olarak takılabilir. Sonra test için bir breakout box gerektiğinde, kutuyu ters takma ihtimali doğar.
      Ya da breakout box’ın bir tarafında 100 pinli konnektör, diğer tarafında ise 25 ayrı test cihazına bağlanması gereken uçlar olabilir. Seçilecek 25 farklı konnektör de yoktur; tüm test ekipmanlarına özel gereksinimler dayatmak da mümkün değildir.
      Uzay araçları giderek yerel mikrodenetleyicilere ve yerel tanılama sistemlerine kaydığı için tüm analog sinyaller için kullanılan bu tür test ekipmanları azalıyor. Günümüzde motorlar da büyük olasılıkla fırçasız olurdu ve böyle bir breakout box yerine hem testte hem uçuşta motor sürücüsünün telemetrisine güvenilirdi.
      Havacılık-uzay konnektörleri de diğer sektörlerde olduğu gibi sipariş anında daha yapılandırılabilir hâle geliyor; anahtarlar eklenerek “aynı” konnektörden 10 tane olsa bile yalnızca kendi yerine takılması sağlanabiliyor. Yine de tüm test ekipmanlarının böyle yapılandırılmasını istemek hâlâ gerçekçi değil.

  • Kayıtlara geçmesi için kendi hikâyemi de ekleyeyim. Üniversiteden sonraki ilk işim PHP ve PerconaDB (MySQL) kullanan bir içerik pazarlama startup’ındaydı; PHP deneyimim çok değildi ama yeni mezunlara özgü temelsiz bir özgüvenim vardı. Mezuniyetten sonra 6 ay iş bulamamıştım, bu yüzden iyi bir izlenim bırakma isteğim de büyüktü.
    Tüm müşteriler için yeni bir özelliği açıp, yalnızca açıkça kapatılmasını isteyen müşterileri hariç bırakacak şekilde bir feature flag’i güncelleme işi bana verildi. Flag’ler veritabanında, string dizisinin içinde 4 ve 5 tam sayıları olarak saklanıyordu.
    Gereken işi yapmak için PHP fonksiyonu array_reverse kullandım; ama dokümantasyonu okumadığım için ikinci argüman yoksa anahtarları değil yalnızca değerleri ters çevirdiğini bilmiyordum. Sonuçta veritabanı, gerekenin tam tersi şekilde bozuldu ve garip biçimde QA’dan geçti.
    Birkaç saat sonra fark edildi; o dönemde tek yön yaklaşık 3 saat işe gidip geliyordum, o sırada konu yönetime kadar taşınmıştı bile. Ters yönde çalışan bir script’le kolayca düzeltilebilirdi ama QA ve DB yedeği hatası gibi birden fazla sorun ortaya çıktı.
    Ertesi gün lead architect gelip bunun PHP ile çalışmanın bir tür geçiş ritüeli olan bir hata olduğunu, kendisinin de kariyerinin başında aynısını yaptığını söylemişti; bunu hâlâ hatırlıyor ve minnetle anıyorum. Sonuçta işten çıkarıldım; mühendis olarak gelişmeme yardımcı oldu ama o an ve sonraki birkaç hafta kesinlikle motivasyonumu kırdı.

    • Sırf o array_reverse hatası yüzünden mi işten çıkardılar?

  • Hikâye sürükleyici yazılmıştı ama kafa karıştırıcıydı da
    Bu ekip tek bir hata değil, birden çok hata yapmış gibi görünüyor. Bunun sonucunda uzay aracında gerçekten hasar oluşabilecek miydi, yoksa uzay aracının neden açılmadığı konusunda yalnızca zaman kaybı ve kafa karışıklığı mı yaşandı, bu da net değil
    İlk hata, multimetrenin yalnızca ölçüm yapmakla kalmayıp devreyi tamamladığını bilmemeleriydi. Bu gerçekten kötü bir tasarım gibi geliyor; eğer illa böyle olması gerekiyorsa o multimetreye kesinlikle dokunulmamalıydı. Bu tek bir kişinin hatası değil; en az iki kişi, onları yöneten kişi ve böyle bir sisteme izin veren sorumlu kişi de işin içinde
    İkinci hata breakout box tarafındaydı. Gücün yanlışlıkla uzay aracı tarafına gönderildiğini gördüler ve uzay aracı açılmayınca güç dalgalanmasının uzay aracına zarar verdiği sonucuna vardılar; ancak gerçekte akımın nereye aktığından ve neyin hasar gördüğünden emin değillerdi ve sonunda yanıldılar
    Uzay aracının açılmamasının nedeni, kazadan önce multimetreyi devreden çıkarmış olmalarıydı. RAT-Revolve motor H-köprüsü kanalıyla ilgili haftalar süren analizler ve ince film metal kaybı olasılığı tartışmaları yapıldığı cümlesi hâlâ kafa karıştırıyor; bu, yanlış güç dalgalanmasının o kanaldan akıp hasar vermiş olabileceğine karar verdikleri anlamına mı geliyor?

    • Telemetri sorumlusu Leo, anlatıcıya hata yaptığını söyleyene kadar telemetri kaybını bildirmemeleri de atlanmış. Telemetri geri gelene kadar tüm testleri iptal etmeleri gerekmez miydi?
    • Uzay aracının kendisi aslında gayet iyi açılmıştı. Multimetre telemetri devresini bağlı tuttuğu için, o devre onarılana kadar bilgi alamıyorlardı
      Güç gerçekten de o devreye girmişti ve hasar verip vermediğini anlamaya çalışıyorlardı. Ancak motor sürücüsünün motordan geri dönen güce dayanabilmesi gerektiğinden, muhtemelen hasar görmediğini düşündüler

  • Makine ve havacılık-uzay mühendisi olarak, en korkunç hikâyelerimin insansız 500 milyon dolarlık bir rover’ın ana bilgisayarının neredeyse kullanılamaz hâle gelmesi seviyesinde olmasını isterdim
    İnsan hayatı taşıyan şeyler için güvenlik açısından kritik onay veren kıdemli kişiydim. Bir kaza sonrası kırılmış parça fotoğraflarına bakarken “Ya bu benim hesabım yanlış olduğu içinse?”, “Ya benim eklemim kaydıysa?”, “Ya hızlandırılmış yorulma ömrü tahmini ya da gerilmeli korozyon çatlağıyla ilgili uygunsuz bir test prosedüründen kaynaklandıysa?”, “Ya üretime almayı aceleye getirirken sevkiyat öncesi yakalayamadığımız bir şeyse?” gibi duygularla baş etmek zorundaydım
    Benzer alanlardaki başarısızlık hikâyelerini okumak ilginç, ama HN’de açıkça paylaşılan hikâyeler bana iş kaynaklı PTSD’nin bir yarış olmadığını düşündürüyor. Bazı insanlar için sadece terapi masrafı daha fazla oluyor

    • Sevdiğim bir yazarın romanındaki bir cümle aklıma geliyor. Bir kaynak eğitmeninin, sahte güvenlik denetimleriyle ilgili epey kelimesi kelimesine bir post-mortem anekdotu anlattıktan sonra söylediği sözler

      Nefesini topladı. “Size şimdi söyleyeceğim şey, hayatım boyunca söyleyeceğim en önemli şey. İnsan zihni nihai test cihazıdır. Teknik veriler hakkında istediğiniz kadar not alabilirsiniz; unuttuğunuz her şeye yeniden bakabilirsiniz, ama bunun kalplerinize ateşten harflerle kazınması gerekir.

      “Eğittiğim kadın ve erkeklerde benim için onların mutlak kişisel dürüstlüğünden daha önemli hiçbir şey, hiçbir şey, hiçbir şey yoktur. Kaynakçı ya da denetçi olarak çalışmanız fark etmez; fizik yasaları amansız yalan dedektörleridir. İnsanları kandırabilirsiniz. Metali asla kandıramazsınız. Hepsi bu.”

      Nefesini verdi ve iyi mizacını yeniden kazanarak etrafına baktı. Quaddie öğrenciler bunu gerektiği kadar ciddiye alıyordu, güzel; arka sırada hastalıklı şakalar yapan sınıf soytarıları yoktu. Hatta oldukça sarsılmış görünüyor, ona korku dolu bir hayranlıkla bakıyorlardı.
      -- Lois McMaster Bujold, Falling Free

    • Son paragraf hakkında ben de aynı şeyi düşündüm. Özgün metinde “o ana anında geri dönüyorum — oda, ışıklar, oturduğum sandalye, masa, içimin çökmesi hissi…” diye yazdığı bölüm bir travma tepkisi gibi geliyordu
      O enerjiyi daha iyi olmaya yöneltebilmiş olması sevindirici, ama herkes travmaya aynı şekilde tepki vermiyor ve bu tepkileri karşılaştırmak da kolay değil. Örneğin bunu bir işe alım sorusu olarak kullanmak için fazla çok sosyal değişken olduğunu düşünüyorum
    • “Kaza sonrası kırılmış parça fotoğraflarına bakarken ‘Ya bu benim hesabım yanlış olduğu içinse?’ diye hissetmek zorunda kaldım” kısmının nihayetinde kaçınılmaz olarak birinin başına gelen bir şey olup olmadığını merak ediyorum
      Prosedürlerin yakalayamadığı bir ayrıntı olsa bile, iyi prosedürler oluşturmakla sorumlu olan biri vardır. Birden fazla etken olabilir, ama nihayetinde oldukça doğrudan sorumlu tutulan bir kişi ortaya çıkıyor gibi görünüyor
      Bunu, yazılım mühendisliğinde ya da toplumun genelinde olduğu gibi bireysel hataların kolektife atfedildiği bağlamlarda düşünmek ilginç
    • Havacılık-uzay sektöründe sizin gibi insanların daha çok, Boeing 737 MAX’in MCAS sistemini tasarlayan, uygulayan ve onaylayan insanların ise daha az olmasını içtenlikle dilerim
    • Mühendisler için grup terapisi olmaması şaşırtıcı; varsa bile bulması zor. Ben yüksek riskli alanlarda çalışmıyorum ama havacılık ya da demiryolu tarafındaki insanların hikâyelerini sık sık dinleyen bir konumdaydım
      Empati yeteneğiniz varsa ve “roket havalandıktan sonra nereye düşeceği benim bölümümün işi değil” tavrını almıyorsanız, bunun epey zor olabileceğini düşünüyorum. Güvenlik açısından kritik sistemler geliştiren ya da bunların yarattığı sonuçlarla uğraşan insanlar için akran destek grupları olsa iyi olurdu. Şirketler her zaman iyi danışmanlık sağlamıyor
      Mühendislik dernekleri ya da yetkili mühendis kuruluşları bunu üyelik aidatlarıyla sunabilir, ama insanlar lisanslarını ya da mesleki yetkinliklerini kaybetmekten korkup kullanmaktan çekinebilir. Eskiden belki meslektaşlarla barda sarhoş olup içini dökmek vardı, ama alkol bağımlılığı ya da ertesi gün iş performansının etkilenmesi iyi değil; bar kültürü de eskisi gibi değil

  • NOAA-N Prime uydusunun, test standına sabitlemek için yeterli cıvata olmadığı için devrildiği olay aklıma geliyor.
    Temel neden, yanılıyorsam düzeltin, uyduyu sabitlemek için kullanılan X-ray muayene cıvatalarının çok pahalı olması nedeniyle başka bir projeye “ödünç verilmiş” ve geri konmamış olmasıydı. Uydu yatay konuma çevrilirken yere düştü ve onarım maliyeti 135 milyon dolardı.
    https://en.m.wikipedia.org/wiki/NOAA-19

    • Çevirme prosedürünün errata’sına ya da ekine “cıvataları kontrol et” maddesi eklenirse, biraz iğnelemeye izin var mı?

  • En baştan kronolojik sıralama daha iyi yapılsaydı endişeden kaçınılabilecek olması ilginç. Test okumalarının zaman damgası ile telemetri sisteminin son zaman damgası karşılaştırılsaydı, test çalıştırılmadan önce telemetrinin zaten arızalandığı anlaşılabilirdi.
    “Az önce uzay aracının tüm telemetrisi kesilmiş gibi görünüyor” gibi belirsiz ifadeler yerine kesin zaman damgaları kullanılmaması da nedenlerden biriydi. Buradan alınacak ders, kaza sırasında olayların tam olarak nasıl bağlantılı olduğunu düzgünce doğrulamak gerektiği. İki farklı sinyale bakıp belirli bir yönde nedensellik varsaymak kolaydır, ama gerçekte bunun tersi olabilir.