Hataları Kimin Yaptığını Değil, Neden Yaşandığını Anlamak

Bir cuma akşamı, herkes hafta sonu planlarını yaparken production ortamında kritik bir problem yaşandığını düşünün. Bir deploy sonrasında ödeme servisi çalışmayı durduruyor. Kullanıcılar ödeme yapamıyor, destek ekibine şikâyetler gelmeye başlıyor ve mühendislik ekibi acil müdahale için yeniden bilgisayarlarının başına geçiyor.

Ekip hızlıca harekete geçiyor. Loglar inceleniyor, son deploy geri alınıyor ve yaklaşık bir saat sonra sistem normale dönüyor.

Problem çözülmüş gibi görünüyor. Ancak asıl problem henüz başlamadı.

Pazartesi sabahı yapılan toplantıda ilk soru şu oluyor:

“Bu deploy’u kim yaptı?”

Birisi sorumluluğu üzerine alıyor. Başka birisi kod incelemesinin yeterince iyi yapılmadığını söylüyor. Bir diğeri testlerin eksik olduğunu hatırlatıyor. Toplantı kısa sürede teknik bir değerlendirmeden çıkıp insanların kendilerini savunduğu bir ortama dönüşüyor.

Peki gerçekten ne öğrendik?

Deploy’u yapan kişinin kim olduğunu öğrendik. Ancak aynı problemin bir sonraki deploy’da tekrar yaşanmasını engelleyecek bir şey yaptık mı?

İşte Blameless Postmortem kültürü tam olarak bu noktada devreye giriyor.

Hata yapmak mı, hatadan öğrenememek mi?

Yazılım geliştirme süreçlerinde hata kaçınılmazdır. Ne kadar deneyimli bir ekip kurarsanız kurun, ne kadar kapsamlı testler yazarsanız yazın veya ne kadar gelişmiş deployment süreçleri tasarlarsanız tasarlayın production ortamında beklenmedik durumlarla karşılaşabilirsiniz.

Çünkü production, geliştirme ortamından çok daha karmaşıktır. Gerçek kullanıcı davranışları, beklenmeyen trafik artışları, üçüncü parti servisler, veri tutarsızlıkları ve birbirine bağımlı sistemler her zaman yeni riskler oluşturur.

Burada önemli olan bir hatanın yaşanması değil, organizasyonun bu hataya nasıl tepki verdiğidir.

Bir organizasyon hataları kişisel başarısızlık olarak görüyorsa insanlar zamanla hata yapmaktan değil, hata yaptıklarının ortaya çıkmasından korkmaya başlar.

Bu korku oldukça tehlikelidir.

Mühendisler riskli gördükleri değişiklikleri paylaşmak istemez, emin olmadıkları kararları tartışmaya açmaz ve bir problem yaşandığında ilk refleksleri çözüm üretmek yerine kendilerini korumak olur.

Sonuçta organizasyon hataları azaltmak yerine hatalar hakkında konuşmayı zorlaştırır.

Blameless Postmortem yaklaşımı ise farklı bir bakış açısı sunar:

Bir incident yaşandığında amacımız suçlu bulmak değil, sistemin bu hatanın yaşanmasına nasıl izin verdiğini anlamaktır.

Bu, kimsenin sorumluluk almayacağı anlamına gelmez. Tam tersine, sorumluluğu kişilerin üzerinden alıp organizasyonun öğrenme ve iyileştirme sorumluluğuna taşımaktır.

Blameless olmak, sorumluluksuz olmak değildir

Bu kavram bazen yanlış anlaşılabiliyor.

Blameless denildiğinde insanların aklına hataların görmezden gelindiği, kimsenin hesap vermediği veya herkesin yaptığı işten bağımsız olarak değerlendirildiği bir ortam gelebiliyor.

Oysa burada bahsedilen şey hesap verebilirliği ortadan kaldırmak değil, suçlama kültürünü ortadan kaldırmaktır.

Aradaki fark oldukça önemli.

Bir mühendis yanlış bir konfigürasyonu production ortamına göndermiş olabilir. Bunu tespit etmek ve anlamak elbette önemlidir. Ancak yalnızca bu kişinin yaptığı hataya odaklanmak, problemin tamamını anlamamızı sağlamaz.

Şu soruları da sormamız gerekir:

• Bu konfigürasyon neden otomatik olarak doğrulanmadı?
• Deployment sürecinde ikinci bir kontrol mekanizması var mıydı?
• Code review sırasında bu değişiklik neden fark edilmedi?
• Geri dönüş mekanizması neden yeterince hızlı çalışmadı?
• Sistem neden bu değişikliği erken aşamada tespit edemedi?

Belki de bir mühendisin yaptığı küçük bir hata, aslında eksik tasarlanmış bir deployment sürecinin sonucuydu.

İnsanlar hata yapabilir. İyi tasarlanmış sistemler ise insanların yapabileceği hataların etkisini sınırlandırmalıdır.

Blameless yaklaşımının temelinde bu düşünce vardır.

Aynı hata neden tekrar yaşanıyor?

Bir incident sonrasında ekiplerin sıklıkla yaptığı şeylerden biri, problemi çözen kişiyi veya değişikliği bulduktan sonra konuyu kapatmaktır.

Örneğin bir API servisi yüksek trafik nedeniyle cevap veremez hale geldiğinde ekip hızlıca instance sayısını artırır. Sistem normale döner ve herkes işine devam eder.

Ancak birkaç hafta sonra aynı problem tekrar yaşanır.

Çünkü ilk incident sırasında yalnızca semptom çözülmüştür. Problemin temel nedeni araştırılmamıştır.

Belki servisin connection pool ayarları yetersizdir. Belki veritabanı tarafında yanlış bir sorgu indekslenmiştir. Belki de trafik artışını karşılayabilecek bir autoscaling mekanizması yoktur.

Bir incident’ın çözülmesi ile bir incident’tan öğrenmek aynı şey değildir.

Blameless Postmortem toplantılarının amacı da burada ortaya çıkar. Yaşanan olayın arkasındaki teknik ve organizasyonel koşulları anlamak, benzer bir problemin tekrar yaşanma ihtimalini azaltacak iyileştirmeleri belirlemektir.

İyi bir Postmortem nasıl olmalı?

Bir postmortem toplantısı, olayın kronolojik olarak anlatıldığı ve herkesin kendi yaptığı işleri savunduğu bir toplantı olmamalıdır.

Öncelikle olayın kendisini anlamamız gerekir.

Incident ne zaman başladı? İlk belirtiler neydi? Hangi servisler etkilendi? Kullanıcılar nasıl etkilendi? Ekip problemi ne zaman fark etti ve nasıl müdahale etti?

Bu soruların cevapları mümkün olduğunca objektif verilerle desteklenmelidir.

Örneğin:

Yanlış yaklaşım:

“Deploy’u yapan mühendis gerekli kontrolleri yapmadığı için ödeme servisi çöktü.”

Doğru yaklaşım:

“Deploy sonrasında ödeme servisinin kullandığı conn pool yapılandırmasında beklenmeyen bir değişiklik oluştu. Mevcut deployment kontrolleri bu değişikliği tespit edemedi ve servis yaklaşık 45 dakika boyunca ödeme taleplerine cevap veremedi.”

İki cümle de aynı olayı anlatıyor gibi görünebilir. Ancak ilkinde bir kişi problem olarak konumlandırılırken ikincisinde sistemin nasıl başarısız olduğu anlatılır.

İyi bir postmortem şu temel sorulara cevap vermelidir:

1. Ne oldu? Incident’ın kapsamı, etkisi ve süresi nedir?
2. Neden oldu? Olayın ortaya çıkmasına neden olan teknik ve organizasyonel koşullar nelerdir?
3. Nasıl fark edildi? Monitoring, alerting veya kullanıcı bildirimleri bu süreçte nasıl çalıştı?
4. Nasıl müdahale edildi? Problemin çözülmesi ne kadar sürdü ve hangi aksiyonlar alındı?
5. Ne öğrendik? Hangi varsayımlarımız yanlış çıktı, hangi süreçlerimiz yetersiz kaldı?
6. Ne değiştireceğiz? Benzer bir problemin tekrar yaşanmasını engellemek için hangi aksiyonları alacağız?

Burada özellikle son soru kritik.

Postmortem toplantısından onlarca aksiyon çıkabilir. Ancak bunların hiçbiri hayata geçirilmiyorsa yapılan çalışma yalnızca dokümantasyondan ibaret kalır.

Psychological safety olmadan Blameless kültür olmaz

Blameless Postmortem kültürünü oluşturmak için yalnızca bir toplantı formatı veya doküman şablonu hazırlamak yeterli değildir.

Asıl ihtiyaç duyulan şey psikolojik güvenliktir.

Bir mühendis yaptığı değişikliğin production ortamında probleme neden olduğunu rahatlıkla söyleyebilmeli. Bir takım lideri verdiği teknik kararın yanlış olduğunu kabul edebilmeli. Bir mühendislik yöneticisi ise kendi oluşturduğu süreçlerin yetersiz olduğunu tartışmaya açabilmelidir.

Bunlar kolay şeyler değil.

Özellikle hata yapan kişinin kariyerinin, performans değerlendirmesinin veya organizasyon içerisindeki itibarının bu olaydan olumsuz etkileneceğini düşündüğü bir ortamda açık iletişim beklemek gerçekçi değildir.

Çünkü insanlar kendilerini güvende hissetmedikleri ortamlarda gerçekleri değil, duymak istenenleri anlatırlar.

Bu nedenle Blameless kültürün en önemli sorumluluğu yöneticilere düşer.

Bir incident sonrasında yöneticinin ilk tepkisi “Bunu kim yaptı?” olursa ekip bir sonraki olayda daha dikkatli davranıp hatalarını gizlemeyi öğrenir.

Ancak ilk soru “Bu problemin yaşanmasına hangi koşullar neden oldu?” olursa ekip çözüm üretmeye odaklanır.

Liderlerin verdiği bu küçük tepkiler, zaman içerisinde organizasyonun kültürünü oluşturur.

Postmortem’in gerçek çıktısı: Aksiyon almak

Bir postmortem’in başarısını kaç sayfa doküman hazırlandığıyla veya kaç kişinin toplantıya katıldığıyla ölçmemek gerekir.

Asıl başarı, incident sonrasında sistemin daha dayanıklı hale gelip gelmediğidir.

Örneğin bir deploy sonrasında production ortamında problem yaşandıysa şu aksiyonlar gündeme gelebilir:

• Kritik konfigürasyon değişiklikleri için otomatik doğrulama eklemek.
• Deployment öncesinde smoke test çalıştırmak.
• Canary deployment kullanarak değişiklikleri kademeli yayınlamak.
• Servislerin hata oranlarını ve latency değerlerini takip eden yeni alarmlar oluşturmak.
• Otomatik rollback mekanizmasını iyileştirmek.
• Kritik servisler için runbook hazırlamak.

Burada dikkat edilmesi gereken bir başka konu da aksiyonların kişilere değil, iyileştirmelere odaklanmasıdır.

“Ali bundan sonra deploy öncesinde daha dikkatli olacak” bir iyileştirme değildir.

“Deployment pipeline, kritik konfigürasyon değişikliklerini otomatik olarak doğrulayacak” gerçek bir iyileştirmedir.

İlk yaklaşım insan davranışının değişmesini bekler. İkincisi ise sistemin daha güvenli hale gelmesini sağlar.

Elbette insan dikkati ve teknik disiplin önemlidir. Ancak sürdürülebilir mühendislik kültürü, her problemin çözümünü insanların daha dikkatli olmasına bağlamaz.

Sonuç: Hataların olmadığı değil, hatalardan öğrenen organizasyonlar

Hiç incident yaşamayan bir mühendislik organizasyonu oluşturmak gerçekçi bir hedef değildir.

Önemli olan, yaşanan incident’ların organizasyonu nasıl değiştirdiğidir.

Bir ekip aynı problemi sürekli yaşıyor ama her seferinde farklı bir kişiyi sorumlu tutuyorsa burada teknik bir problemden çok daha büyük bir organizasyonel problem vardır.

Blameless Postmortem kültürü, hataları normalleştirmek veya beklentileri düşürmek anlamına gelmez. Tam tersine, mühendislik standartlarını yükseltmenin ve daha dayanıklı sistemler oluşturmanın yollarından biridir.

Çünkü iyi mühendislik organizasyonları yalnızca başarılı deploy’lar yaparak gelişmez. Başarısız olduklarında nasıl davrandıklarını öğrenerek de gelişirler.

Belki de bir incident sonrasında sormamız gereken en önemli soru şudur:

“Bu hatayı kim yaptı?” değil, “Bir sonraki sefer aynı hatanın yaşanmasını önlemek için sistemimizde neyi değiştirmeliyiz?”

İşte Blameless Postmortem kültürü budur.

Hataları saklamadan konuşabilmek, insanları suçlamadan sorumluluk alabilmek ve yaşanan her problemden organizasyon olarak biraz daha iyi çıkabilmek.