Mühendislik Postmortem Şablonu (Suçlamasız, Uygulanabilir)

Postmortemler neden suçlama seanslarına dönüşür

Postmortemler belirli bir şekilde başarısız olur: oda, ortak bir zaman çizelgesine sahip olmadan neden atamaya başlar. Biri, dağıtım zamanı teyit edilmeden önce "bunun nedeni dağıtımdı" der. Bir başkası, uyarının o senaryo için yapılandırılıp yapılandırılmadığını bilmeden "uyarı tetiklenmedi" der. Konuşma, aslında ne olduğu ve hangi sırada olduğu ortaya konmadan önce nedensellik üzerine bir tartışmaya dönüşür.

Çözüm yapısaldır: kimse kök neden belirtmeden önce, postmortemin başında olay zaman çizelgesini birlikte oluşturun. Tüm oda olay dizisine baktığında — ne, ne zaman değişti, kim, hangi anda ne gördü — nedeni tartışmak çok daha kolay ve suçlamaya dönüşme olasılığı çok daha düşüktür. Çoğu şablonun yaptığı sıralama hatası budur: kök nedeni zaman çizelgesinden önce koyarlar çünkü şablon kök neden içindir. Oysa kök nedeni dürüst kılan şey zaman çizelgesidir.

Gündem (kopyala-yapıştır)

Süre: Basit bir olay için 60 dakika; karmaşık çok sistemli arızalar için 90 dakika
Format: Yönetilir; tüm müdahale edenler ve nöbetçi mühendis hazır bulunur; ön okuma belgesiyle asenkron hazırlanın


Bölüm 1 — Olay özeti (5 dk)

  • Olayın tarihleri ve süresi
  • Önem derecesi sınıflandırması ve etkilenen sistemler
  • Kim tespit etti ve nasıl (müşteri bildirimi, uyarı, mühendis, izleme)
  • Bu bölüm yalnızca olgusaldır; henüz analiz yok

Bölüm 2 — Zaman çizelgesi (20 dk)

  • Zaman çizelgesini ekranda ortaklaşa oluşturun — önceden yazılmış bir belge değil
  • Dizilim: ne değişti, ne gözlemlendi, kim harekete geçti, ne kararlaştırıldı
  • Her zaman damgasının bir kaynağı olmalı (log satırı, PagerDuty, Slack mesajı)
  • Zaman çizelgesi tamamlandığında sorun: herkes bunun olan biten olduğunda hemfikir mi? Devam etmeden önce anlaşmazlıkları çözün

Bölüm 3 — Etki özeti (5 dk)

  • Müşteri etkisi: kim, ne kadar süreyle, ne şekilde etkilendi
  • İş etkisi: gelir, SLA, itibar
  • İç etki: nöbet saatleri, ekip aksaması
  • Bunu olgusal tutun; yorum katmadan "ne kadar kötüydü" sorusunu çıpalar

Bölüm 4 — Kök neden ve katkıda bulunan faktörler (20 dk)

  • Kök neden: olayı mümkün kılan en yakın değişiklik veya koşul
  • Katkıda bulunan faktörler: onu daha kötü, tespit edilmesi daha zor veya çözülmesi daha yavaş hale getiren koşullar
  • En faydalı postmortemler, kök nedenin yanında 3-5 katkıda bulunan faktör belirler; yalnızca kök nedeni düzeltmek çoğu zaman sistemik koşulları kaçırır
  • Her faktör için sorun: herhangi bir kişi veya ekip, mevcut bilgiler ışığında makul görünen bir karar verdi mi? Cevap evet ise, faktör kişisel değil, sistemiktir

Bölüm 5 — İyi giden şeyler (5 dk)

  • Hangi tespit veya müdahale beklenenden daha iyi işledi?
  • Hangi mevcut süreç veya araç etki alanını sınırladı?
  • Bunlar resmileştirmeye değer uygulamalardır — çalışma kılavuzu (runbook) 20 dakika kazandırdıysa, kılavuzun bakımının yapılması için bunu not edin

Bölüm 6 — Aksiyon maddeleri (15 dk)

  • Her aksiyon maddesi bir kök nedeni veya katkıda bulunan faktörü ele alır — genel bir iyileştirmeyi değil
  • Madde başına bir sorumlu; aciliyeti yansıtan bir teslim tarihi
  • Sınıflandırın: daha erken tespit et / daha hızlı toparlan / tekrarı önle
  • Kapsamlı bir güvenilirlik yol haritası değil, ekibin bir sonraki olaydan önce gerçekçi biçimde tamamlayabileceği aksiyonlarla sınırlayın

Postmortem şablonlarını neyin başarısız kıldığı

Kök neden öncelikli sıralama ana yapısal sorundur — yukarıda zaten ele alındı. İkincisi, "aksiyon maddeleri"ni tek bir kategori olarak ele almaktır. Tespit iyileştirmeleri, kurtarma iyileştirmeleri ve önleme iyileştirmeleri farklı sorumlular ve farklı zaman çizelgeleri gerektirir. Bunları karıştırmak, altı aya ve üç ekibe yayılan bir liste üretir ki bu da hesap verebilirliğin dağılması ve hiçbirinin teslim edilmemesi anlamına gelir.

Üçüncü başarısızlık kalıbı, bir olaydan sonra uygunsuz bir iyimserlik gibi hissettirdiği için "iyi giden şeyler"i atlamaktır. Değildir — bu, baskı altında işe yarayan uygulamaları belirlemenin ve resmileştirmenin tek sistematik yoludur. Sorunu yakalayan izleme, kimsenin yol haritasında oluşturulacak bir şey değildiyse, önemli olduğunu öğrenmek belgelenmeye değerdir. Aksi halde olay unutuldukça önceliği düşürülür ve bir sonraki sefere karşı kör kalırsınız.

Katkıda bulunan faktörlerin ele alınmadığı olayların ve işe yarayıp da bakımı yapılmayan çalışma kılavuzlarının birikimli maliyeti hızla artar. Toplantı vergisi, tekrarlayan toplantı yükünün ve olay inceleme borcunun nasıl etkileştiğini ele alır.

Postmortem yakalaması neden benzersiz derecede zor

Postmortem tartışmaları hızla yoğun, yapılandırılmamış içerik üretir: zaman çizelgesi yeniden kurgusu, rakip yorumlar, çok kişili aksiyon maddesi atamaları, bağlam olmadan bir dökümde anlam ifade etmeyecek teknik ayrıntılar. Hafızadan ya da düzenlenmiş sesten yazılan bir postmortem özeti neredeyse her zaman eksiktir ve eksik postmortem kayıtları, olaylar arası örüntü tanıma için işe yaramaz.

Pavleur, tüm postmortem tartışmasını yakalar ve raporu otomatik olarak oluşturur — yeniden kurgulandığı şekliyle zaman çizelgesi, belirtildiği şekilde katkıda bulunan faktörler, toplantıda ifade edildiği şekliyle sorumluları ve kategorileriyle aksiyon maddeleri. Biri ekranını paylaşıp bir log çıktısı, bir izleme grafiği veya tetiklenmeyen uyarı yapılandırmasını gösterdiyse, o görsel raporun bir parçasıdır. Yalnızca sese dayalı araçlar bunu tamamen kaçırır; grafikleri olmayan bir postmortem kaydı, kanıtı olmayan bir kayıttır. Ekipteki herkes — olaydan sonra katılan mühendisler dahil — birinin yeniden kurgulamasını istemeden tam, görsel bağlamlı kaydı okuyabilir. Bu konuda diğer araçlarla doğrudan bir karşılaştırma için: Pavleur ve alternatifleri.

Postmortem sıklığı üzerine

Postmortem'i, ayrıntılar tazeyken olay çözümünden sonraki 48 saat içinde yürütün. Ne kadar beklerseniz, zaman çizelgesi yeniden kurgusu o kadar loglardan çok hafızaya dayanır ve hafıza stres altında güvenilmezdir. Yüksek önem dereceli olaylar için 24 saat daha iyidir. Küçük olaylar için, asenkron postmortemler — yapılandırılmış sorularla paylaşılan bir belge, senkron olarak incelenen — tam bir toplantıdan daha verimli olabilir. Toplantı formatı en çok, olay belirsiz veya ortak yorumun önemli olacağı kadar yüksek riskli olduğunda değerlidir.

Mühendislik Postmortem Şablonu (Suçlamasız, Uygulanabilir) | Pavleur