Yazılım hatalarından ders almak Bölüm 10: Daha iyi bir dijital gelecek için yazılım

Yazılım endüstrisi “yeni zorluklar” hakkında konuşmayı seviyor. İster bulut tabanlı mimariler, ister mikro hizmetler, makine öğrenimi veya uç bilişim: her teknoloji dalgası, görünüşte benzersiz moda sözcükleri ve sorunları beraberinde getirir. Ancak son birkaç on yılın büyük yazılım felaketlerini inceleyen herkes, bunların kalıplarının zamansız olduğunu hemen fark eder.

Bölüm 10: Tekrarlayan suç işleyenlerden öğrenen organizasyonlara: yazılım endüstrisi derslerini nasıl alıyor?

Mars Climate Orbiter, 1999 yılında sürücü değişimi nedeniyle yanmıştı. Ariane 5, 1996 yılında taşma nedeniyle patladı. Knight Capital, kusurlu dağıtım süreci nedeniyle 2012 yılında 440 milyon dolar kaybetti. Therac-25, 1980'li yıllarda ırksal koşullar nedeniyle insanları öldürüyordu. Bu olaylar birbirinden onlarca yıl uzakta, tamamen farklı geçmişlerden geliyor ve yine de aynı temel hatalara dayanıyor.

Bu durum rahatsız edici bir soruyu gündeme getiriyor: Sebeplerini biliyorsak, çözümleri belgelenmişse ve araçlar mevcutsa, neden bu hatalar hala ortaya çıkıyor? Cevap sizi düşündürüyor: Çünkü teknik bilgi tek başına yeterli değil. Bilinen hataların tekrarlanması teknik bir sorun değil, organizasyonel ve kültürel bir sorundur.

Teknik çözüm yanılsaması

Her muhteşem yazılım çökmesinden sonra aynı ritüel takip edilir: analizler yazılır, öğrenilen dersler belgelenir, yeni araçlar geliştirilir. Heartbleed'den sonra daha iyi tüylendirme araçları vardı. Knight Capital'ın ardından dağıtım otomasyonu konuşuldu. Mars Climate Orbiter'ın ardından insanlar tip sistemlerinden ve birim kütüphanelerinden bahsetti. Tüm bu teknik gelişmeler değerli ve gereklidir. Ancak nedeni tedavi etmeden her zaman yalnızca semptomlara odaklanırlar:

• Ariane 5 testleri gerçekleştirdi ancak bunlar ilgili senaryoları kapsamıyordu.
• Knight Capital'ın uygulama süreçleri vardı ancak zaman kısıtlaması nedeniyle bunlar takip edilmiyordu.
• Therac-25 modern, yazılım kontrollü bir sistem olarak kabul edildi ve donanım kilitleri ortadan kaldırıldığı için sorun tam da bu oldu.

Teknik seviye şüphesiz en basit olanıdır. Modern programlama dilleri, derleme zamanında birim hatalarını yakalayan güçlü tip sistemler sağlar. Statik analiz ve linter araçları, kod yürütülmeden önce olası boş işaretçi istisnalarını yakalar. Özellik bazlı testler sınır değeri sorunlarını ortaya çıkarır. Fuzzing, bellek bozulması hatalarını bulur. Bu araçların tümü güçlüdür, ancak yalnızca kullanılırsa. Ve asıl sorun da tam olarak burada başlıyor: organizasyonel düzeyde.

Her yazılım ekibi iyi niyetli süreçlerin farkındadır. En az iki geliştiricinin incelediği kod incelemeleri. Kritik kod yolları için programlamayı eşleştirin. Ayrıntılı test kapsamı, her olaydan sonra kusursuz otopsiler, belgelenmiş yaşam döngüsüne sahip işlevsellik göstergeleri, otomatik geri alma mekanizmalarına sahip dağıtım hattı vb. Bunların hepsi en iyi uygulamalardır: Sayısız en iyi uygulama kılavuzunda bulunurlar, konferanslarda tartışılırlar ve çok sayıda iş ilanında istenirler. Ancak son teslim tarihi yaklaştığında, müşteri acil olduğunda veya rakip daha hızlı olduğunda ilk kurbanlar bu süreçler olur.

“Daha sonra inceleyeceğiz”, “Hiç incelemedik” olur. “Hala ayrıntılı olarak test ediyoruz”, “Mutlu yolda çalıştı” olur. “Özellik bayrağını belgeleyelim”, “Bir yerlerde bununla ilgili kesinlikle bir şeyler var.” Bu mekanizma o kadar öngörülebilir ki yazılım geliştirmenin neredeyse doğal bir kanunudur: Teknik olarak uygulanmayan süreçler zamanın baskısı altında zayıflar. Knight Capital felaketi bunun harika bir örneğidir. Şirketin uygulamalara yönelik süreçleri vardı. Ancak yeni sürüm piyasaya sürüldüğünde geride bir sunucu kaldı. Eski bir özellik bayrağına sahip unutulmuş tek bir sunucu ve 45 dakika sonra 440 milyon dolar kaybedildi. Sebebi bilgi eksikliği değil, uygulamadaki disiplin eksikliğiydi.

Burada temel bir model ortaya çıkıyor: Kalite güvencesini sözde çok pahalı olduğu için hoş karşılanan bir şey olarak gören kuruluşlar, bunun bedelini ancak daha sonra ve genellikle çok daha pahalı bir şekilde ödemeye devam ediyor. Bu sorunla mücadele etmek için otomasyon çok önemlidir. Teknik olarak dayatılanlar unutulamaz. Ancak manuel olarak kontrol edilmesi gerekenler er ya da geç gözden kaçacak ya da unutulacaktır. Bu, örneğin şu anlama gelir:

• Tüm sunucuların güncellendiği veya hiç güncellenmediği atomik dağıtımlar.
• Açıkça boş değer işleme olmadan kodu reddeden derleyiciler.
• Testler eksikse derlemeyi durduran CI/CD işlem hatları.
• Sistem kontrol ünitesi tipi.

Bu mekanizmalar taciz değil, yazılım hayat sigortasıdır. Ancak üçüncü seviye eksikse en iyi otomasyon bile işe yaramaz: kültürel seviye, yani bir organizasyonun hatalarla başa çıkma şekli.

Hafife alınan boyut: hata kültürü ve psikolojik güvenlik

Teknik ve prosedür düzeyi nispeten kolaylıkla ölçülebilir ve geliştirilebilir. Ancak kültürel düzey daha incelikli ve aynı zamanda çok önemlidir. Pek çok kurumda suçlama kültürü hâlâ mevcut. Bir şeyler ters gittiğinde suçluyu ararız. “Kim uyguladı?”, “Kim inceledi?” veya “Bunu kim görmeliydi?” Bu sorular insanlar tarafından anlaşılabilir, ancak verimsizdir ve verimsizdir.

Bunun nedeni basit: Hataların bireyler açısından sonuçları olduğunda, bunlar açıkça tartışılmak yerine gizlenir. Geliştiriciler artık endişelerini dile getirmeye cesaret edemiyor. Hiç kimse bir engel olarak görülmek istemediği için kod incelemeleri giderek daha yüzeysel hale geliyor. Sorunlar büyüyene kadar gizlenir. Bunun alternatifi Suçsuz Ölüm Sonrası'dır: saha güvenilirliği mühendisliği kültüründen doğan bir uygulama. Temel fikir, bir kazadan sonra suçluları değil, sistemin zayıf noktalarını aramaktır. Yani “Hatayı kim yaptı?” değil, “Bu hatayı hangi koşullar mümkün kıldı?”

Bu tutum zayıf gibi görünse de son derece pragmatiktir. Çünkü gerçek şu ki neredeyse her büyük yazılım arızası bireysel bir arıza değil, bir sistem arızasıdır. Tek bir geliştirici bir hata ortaya çıkarırsa, bir incelemeci onu bulamazsa, bir test bulamazsa ve bir dağıtım onu ​​üretime itebilirse, o zaman sorun insanlarda değil, sistemdedir. Therac-25 bunun şok edici bir örneğidir. İnsanları öldüren ırksal durum incelikliydi ve yeniden üretilmesi zordu. Bu durum yalnızca kullanıcılar girişleri çok hızlı yaptığında meydana geldi. Bu özel durumu test etmek zorunda kaldıkları için geliştiricileri suçlamak adil olur mu? Yoksa güvenlik açısından kritik donanım kilitlerini, resmi doğrulama olmadan, bağımsız denetimler olmadan, yedek bir güvenlik katmanı olmadan yazılım kontrolleriyle değiştiren bir tasarım hatası mı?

İyi bir hata kültürüne sahip organizasyonlar, yaşadıkları olayları detaylı bir şekilde belgeliyor, tüm ekibin erişimine sunuyor ve bunlardan somut iyileştirmeler elde ediyor. Birisi potansiyel bir hatayı erken bildirdiğinde bunu kutlarlar. Teknik borç ve yeniden düzenleme için açıkça zaman ayırdılar. Rahatsız olsalar bile uzmanların uyarılarını ciddiye alırlar. Yunan mitolojisinde her zaman gerçeği gören ama kimsenin ona inanmadığı Cassandra vardı. Her kuruluşun kendi Cassandra'ları vardır: Risklere karşı uyarıda bulunan, teknik borçlara dikkat çeken, “Bir noktada işler ters gidecek” diyen geliştiriciler. Kuruluşun bu uyarıları ciddiye alıp almaması onun olgunluğunun bir ölçüsüdür.

Bu kültürel boyutun maliyetler üzerinde doğrudan etkisi vardır. Olağanüstü vakalar, hatalardan ders almamanın ne kadar maliyetli olduğunu dramatik bir şekilde gösteriyor. Bu rakamlar etkileyici ama buzdağının sadece görünen kısmını gösteriyor. Çoğu yazılım hatası büyük felaketlere değil, kademeli hasara yol açar: Planlı geliştirme yerine sürekli yangın söndürücüler, yüksek dalgalanmalarla hayal kırıklığına uğrayan ekipler, müşteriler arasında güven kaybı, kaçırılan pazar fırsatları, katlanarak biriken teknik borç. Çok sayıda çalışma, düşük yazılım kalitesinin maliyetinin yılda yüz milyarlarca ila trilyonlarca dolar arasında olduğunu tahmin ediyor. Bu soyut bir sayı değil, her gün meydana gelen milyonlarca irili ufaklı hatanın toplamıdır.