Suçlamasız olay sonrası değerlendirme yazmak: şablon, dil ve takip

Postmortem neden yazılır, suçlamasız ne demek

Postmortem, bir olayın yazılı kaydıdır: etkisi, müdahale adımları, kök nedenleri ve tekrarını önleyecek aksiyonlar. Amacı olayı belgelemek, katkıda bulunan tüm nedenleri anlamak ve etkili önleyici aksiyonlar almaktır. Resmî bir öğrenme süreci yoksa aynı olay tekrar eder, karmaşıklaşır ya da zincirleme büyür.

Suçlamasız yaklaşım, katkıda bulunan nedenlere odaklanır ve belirli bir kişiyi ya da ekibi suçlamaz. Temel varsayım, herkesin iyi niyetle ve eldeki bilgiyle makul kararlar verdiğidir. Asıl soru, kişinin neden eksik ya da yanlış bilgiyle karar vermek zorunda kaldığıdır; çünkü insanlar düzeltilemez, ama sistemler ve süreçler düzeltilebilir. Suçlamasız olmak, sorunları gizlemek değil, iyileştirme noktalarını açıkça söylemek demektir. Doküman, öfkeyi boşaltma yeri olmamalıdır.

Ne zaman yazılır: tetikleyiciler önceden belirlenir

Her küçük aksaklık için postmortem yazmak ekibi yorar; hiç yazmamak ise öğrenmeyi öldürür. Bunun çözümü, tetikleyicileri önceden yazmaktır. Google'ın SRE kitabında örnek olarak şunlar geçer:

• Belirli bir eşiği aşan kullanıcıya görünür kesinti ya da bozulma.
• Herhangi bir veri kaybı.
• Nöbetçi müdahalesi gerektiren olay, örneğin sürümü geri alma ya da trafiği başka yere yönlendirme.
• Çözüm süresinin belirlenen sınırı aşması.
• İzleme hatası: olayın sistem tarafından değil, elle fark edilmesi.

Ayrıca ilgili herhangi bir paydaş postmortem talep edebilir. Kriterler yazılı olmazsa çalışanlar ne zaman yazılması gerektiğini bilemez ve süreç keyfileşir.

Postmortem içinde hangi bölümler olmalı

İyi bir şablon, yazarın neyi atladığını görünür kılar. Temel bölümler şunlardır: olayın kısa özeti; olay zaman çizelgesi; kullanıcıya ve işe etkisinin değerlendirmesi; etkiyi azaltmak ya da gidermek için yapılan müdahaleler; kök nedenler; öncelik atanmış takip aksiyonları; analiz ve eğilim için üstveri alanları.

Zaman çizelgesini yazarken olay kanalındaki mesajlar, uyarı kayıtları ve komut geçmişi kullanılır. Her kayıt saat bilgisi ve ne olduğu bilgisiyle verilir, değerlendirme cümlesi içermez. Etki bölümünde kaç kullanıcının, hangi işlevin, ne kadar süreyle etkilendiği sayılabilir birimlerle yazılır. Kök neden bölümünde tek bir neden değil, birlikte tetikleyen nedenler listelenir. Aksiyon bölümünde her maddenin sahibi, öncelik düzeyi ve hedef tarihi bulunur; sahipsiz aksiyon uygulanmaz.

Suçlamasız dil: aynı olay farklı biçimlerde yazılabilir

Dil, kültürün aynasıdır. Suçlayıcı bir cümle kişiyi merkeze alır: yeni mühendis yanlış komutu çalıştırdı. Suçlamasız sürüm sistemi sorgular: komut, onay adımı olmadan üretim ortamında çalışabiliyordu ve ortam adı komut satırında görünmüyordu. Bu cümle, bir aksiyon önerir: onay adımı ekle, ortam adını görünür kıl.

Yazarken şu pratikler yardımcı olur: özne olarak kişi yerine sistem, süreç ya da karar noktasını kullanın; mümkünse isim yerine rol yazın; neden sorusunun ardına sistem düzeyinde bir cevap verin; kararları o anki bilgiye göre değerlendirin, sonuç bilindikten sonraki bilgiyle değil. Duygusal ya da sert dil, hedefi zayıflatır. Hata yapan kişinin kendi anlatımı da çizelgeye bilgi olarak girer, hüküm olarak girmez.

Kök nedene gerçekten inmek

Yüzeysel analiz, en sık görülen eksikliktir. İnsan hatası, kök neden değildir; neden hata yapılabildiğini sormak gerekir. Neden sorusunu tekrarlayarak ilerleyin: sürüm neden hata verdi, test bunu neden yakalamadı, uyarı neden geç çaldı, geri alma neden uzun sürdü, kimse bu riski daha önce neden görmedi? Her cevap, sürecin ya da araçların bir zayıflığını gösterir.

Sonuçta kök nedenler şu türlere ayrılabilir: tetikleyici olay, savunmasız bırakan koşul ve olayın büyümesine izin veren eksik güvenlik önlemi. Her biri için bir aksiyon düşünün: engelle, daha erken tespit et, etkisini sınırla ya da daha hızlı geri dön. Aksiyonlar yalnızca yazılımla sınırlı değildir; belgelendirme, eğitim, nöbet süreci ve uyarı eşikleri de aksiyon alanıdır.

Gözden geçirme, yayımlama ve takip

Yazılmış ama gözden geçirilmemiş postmortem hiç yazılmamış gibidir. İlk taslak ekip içinde paylaşılır, kıdemli mühendisler tamlığını değerlendirir: kritik olay verisi toplanmış mı, etki değerlendirmesi eksiksiz mi, kök neden yeterince derin mi, aksiyon planı ve öncelikleri uygun mu, ilgili paydaşlara sonuç iletildi mi? Düzenli gözden geçirme toplantılarında açık yorumlar kapatılır ve belge son hâline getirilir.

Sonra belge daha geniş bir kitleye açılır ve ortak bir arşivde saklanır. Belgeye son kullanıcıyı tanımlayan bilgi girmemelidir. Takip kısmı en çok ihmal edilen yerdir: aksiyonların iş takip aracında kayıtlı olması, sahibinin ve tarihinin bulunması ve belirli aralıklarla tamamlanma durumunun gözden geçirilmesi gerekir. Aksiyonlar kapanmıyorsa, postmortem bir ritüele dönüşmüştür.

Sık hatalar ve kültür oluşturma

Başlıca anti-desenler: suçlama ve parmak göstermek, postmortem'i biçimsel bir zorunluluk saymak, kök neden analizini yüzeyde bırakmak, gözden geçirmemek, sık postmortem yazan kişileri damgalamak, şablonu aşırı ağır tutup zahmeti büyütmek ve iyi yazılmış postmortem'leri takdir etmemek. Sık yazanı cezalandırmak, olayların halının altına süpürülmesine yol açar.

Kültür oluşturmak için yönetimin gözden geçirmelere katılması, iyi yazılmış postmortem'lerin paylaşılması ve olayı iyi yöneten kişinin takdir edilmesi gerekir. Yeni ekip üyeleriyle geçmiş olayları rol oyunu olarak yeniden canlandırmak, hem öğretir hem kültürü yayar. Başlangıçta yalnızca birkaç başarılı örnekle deneme dönemi yapıp tetikleyicileri bu deneyimden çıkarmak makul bir yoldur.

Bu beceri Mindset programlarında nerede çalışılır

Site Reliability Engineering (SRE) Pratikleri programında Blameless Postmortem Kültürü, SRE Kültürü programında ise Olay Yönetimi ve Blameless Post-Mortem modülleri bu konuya ayrılmıştır. İçerik, nöbet tutan mühendisler, operasyon ve platform ekipleri ile olay sonrası öğrenmeyi kurumsal bir süreç hâline getirmek isteyen yöneticiler için uygundur; kurumsal ekipler şablonu ve tetikleyici kriterlerini birlikte çalışıp kendi ortamlarına uyarlayabilir.