Hastanelerde ve acil tıp kliniklerinde, beklenmedik bir hasta kaybının veya ağır bir tıbbi komplikasyonun ardından kapalı kapılar ardında yapılan çok özel bir toplantı vardır: M&M (Morbidity and Mortality) Konferansı.

Bu toplantı bir mahkeme salonu değildir. Orada bir savcı oturup "Hastanın ölümünden hangi hemşire veya doktor sorumlu, hemen diplomasını iptal edelim" demez. Eğer tıp dünyası yüzyıllardır bu mantıkla çalışsaydı, bugün dünyada tek bir cerrah veya hekim bile kalmazdı.

M&M masasına bir vaka yatırıldığında, cerrahından stajyerine, eczacısından başhemşiresine kadar herkes aynı soğukkanlılıkla tek bir sorunun peşine düşer: Sistem nerede açık verdi?

Hemşire ilacı yanlış dozda mı hazırladı? Peki neden?
İlaç dolabındaki iki farklı ilacın kutu tasarımı ve yazı tipi birbirine mi benziyordu?
O gece acil serviste personel eksikliği mi vardı ve o hemşire 28 saattir aralıksız mı nöbetteydi?
Acil çağrı zili çaldığında alarm sesleri birbirine mi karışıyordu?
Doktorun yazdığı el yazısı reçete protokol kurallarına uygun değil miydi?

İşte bu, bir hatayı kişiselleştirmek yerine sistemi otopsiye almaktır. James Reason'ın meşhur "İsviçre Peyniri Modeli" tam olarak bunu anlatır: Felaketler tek bir insanın aptallığından değil; sistemdeki küçük deliklerin (güvenlik açıklarının, yorgunluğun, kötü tasarımın) tesadüfen aynı hizaya gelmesinden doğar.

Peki yazılım dünyası bu olgunluğun neresinde?

Yazılımın Sahte "Blameless" Tiyatrosu

Son yıllarda DevOps kültürünün yaygınlaşmasıyla birlikte teknoloji şirketlerinin diline pelesenk olmuş bir kavram var: "Blameless Post-Mortem" (Suçlamasız Olay Sonrası İnceleme).

Teoride kulağa ne kadar modern ve çağdaş geliyor değil mi? Bir kriz çıkar, sistem çöker, ardından ekip toplanır ve "Kimseyi suçlamıyoruz, sadece süreçleri iyileştireceğiz" denir. Google'ın SRE (Site Reliability Engineering) kitaplarından alıntılar yapılır.

Ama gelin o toplantı odasının kapısını aralayıp gerçekte ne olduğuna bakalım.

Şirketin ana veritabanı silinmiştir veya son güncelleme bütün ödeme akışını kilitlemiştir. Masada oturan yöneticilerin gözlerinde tek bir soru parıldar: "Bunu kim yaptı?"
Toplantı raporuna resmi olarak "Bir operasyonel aksaklık yaşandı" yazılır; ama toplantı biter bitmez kahve köşelerinde, özel Slack mesajlarında fısıltılar başlar:
"Ahmet yine migration script'ini canlıda çalıştırmış..."
"Mehmet PR'ı test etmeden merge'lemiş..."

Sonuç? Ahmet günah keçisi ilan edilir, belki performansı düşürülür veya şirketten kovulur. Ekip rahat bir nefes alır: "Suçlu bulundu ve bertaraf edildi."

Ve altı ay sonra, yeni işe giren Ayşe aynı hatayı birebir tekrarlar.

Neden mi? Çünkü siz Ahmet'i kovdunuz; ama Ahmet'in tek bir tuşa basarak tüm şirketi yok edebildiği o çürük zemini olduğu gibi bıraktınız.

Ahmet Suçlu Değil, Senin Sistemin Özürlü

Yazılım liderlerinin ve sistem mimarlarının anlamakta en çok zorlandığı gerçek şudur:
Eğer bir mühendis, tek bir terminal komutuyla, tek bir kontrolsüz tıklamayla veya tek bir dalgınlıkla tüm sistemi çökertebiliyorsa; suç o mühendiste değil, o yetkiyi oraya kontrolsüzce bırakan sistemdedir.

Bir insan yorulabilir. Bir insanın sevgilisiyle kavga ettiği bir gün olabilir, bebeği bütün gece uyumamış olabilir, dikkati saniyenin onda biri kadar dağılabilir. İnsanoğlu biyolojik olarak hata yapmaya programlanmış kusurlu bir varlıktır.

Mühendisliğin tek varoluş sebebi ise, bu kusurlu insanın etrafına çelikten bariyerler (Poka-Yoke) örmektir.

Eğer sizin canlı (production) veritabanınıza bir geliştirici doğrudan SSH ile bağlanıp DROP TABLE yazabiliyorsa; orada suç Ahmet'in klavyesinde değil, o veritabanına doğrudan yazma izni veren DevOps mimarisindedir.
Eğer bir kod, otomatik testlerden, statik analizden ve kademeli dağıtım (canary deployment) aşamasından geçmeden canlıdaki kullanıcılara ulaşıyorsa; suç o PR'ı açan stajyerde değil, o dağıtım boru hattını (pipeline) kurmayan kıdemli mühendistedir.

Tıpta buna "Hataya Dayanıklı Tasarım" denir. Örneğin, hastanelerdeki oksijen tüplerinin ve azot protoksit gazı hortumlarının bağlantı uçları fiziksel olarak birbirinden tamamen farklı üretilir. Dünyanın en dikkatsiz, en yorgun hemşiresi bile istese de oksijen prizine anestezi gazı hortumunu takamaz; çünkü metal yuvalar birbirine uymaz.

Peki sizin yazılım mimarinizde, yanlış hortumu yanlış yere takmayı engelleyen kaç tane fiziksel kilit var?

Gerçek Bir Otopsi Nasıl Yapılır?

Bir olay sonrası analiz (post-mortem), suçlu avlamak için değil, mimarinin zayıf halkalarını güçlendirmek için bir fırsattır. Eğer bir krizin ardından toplantı yapıyorsanız, şu üç soruyu masaya koymak zorundasınız:

Görünürlük (Observability): Bu hatayı biz kendimiz mi fark ettik, yoksa Twitter'da müşteriler dalga geçmeye başladığında mı uyandık? Sistem neden kendi kendine kanadığını bize önceden haber vermedi?
Kapsama Alanı (Blast Radius): Tek bir servisteki hata neden domino taşı gibi tüm platformu devirdi? Servisler arasındaki yalıtım (circuit breaker / isolation) neden çalışmadı?
Geri Dönüş Hızı (Recovery Time): Hatayı fark ettikten sonra sistemi 5 dakika içinde bir önceki stabil duruma getirebilecek bir geri alma (rollback) mekanizmamız neden yoktu?

Bu soruların hiçbirinde bir insan ismi geçmez. Bu soruların tamamı mimarinin, süreçlerin ve araçların sağlığıyla ilgilidir.

Hatayı insanda aramak tembelliktir. Birini suçlayıp rahatlamak, sorunu çözmüş gibi hissettiren en ucuz uyuşturucudur.

Ama eğer gerçekten ayakta kalan, kurşun geçirmez sistemler inşa etmek istiyorsanız; insanları cezalandırmayı bırakın. Masaya neşteri koyun ve sistemi otopsiye alın. Çünkü sistem iyileşmediği sürece, sedyeye yatacak bir sonraki kurban sadece bir zaman meselesidir.

sistem-tasarimi

Post-Mortem Değil, Otopsi: Hatayı Kişide Değil, Sistemde Aramayı Acil Servisten Öğrenmek