Üretimde bir sorun oluştu. Müşteriye yönelik bir özellik devre dışı kaldı, veriler bozuldu veya dağıtım gece saat 02.00'de aksadı. Adrenalin azaldı. Düzeltme geldi. Şimdi ne olacak?
Bu, çoğu takımın boşa harcadığı an. Ya geçmişe dönük değerlendirmeyi tamamen atlıyorlar ("bunu zaten düzelttik, hadi devam edelim") ya da bunu yapmamış gibi yaparak sessizce suçu atayan bir değerlendirme yürütüyorlar. İkisi de bir sonraki olayı engellemez.
Gerçekten suçsuz bir otopsi, bir ürün ekibinin gerçekleştirebileceği en yüksek fayda sağlayan faaliyetlerden biridir. İyi uygulandığında acı verici bir olayı sistemik bir iyileşmeye dönüştürür. Kötü uygulandığında ekibinize sorunları gizlemeyi öğretir.
Gerçekte işe yarayan olay geriye dönük incelemelerinin nasıl yürütüleceği burada açıklanmıştır.
"Suçsuz" Neden Sadece Hoş Bir Kelime Değildir
Suçsuzluğun ne anlama geldiği konusunda açık konuşalım çünkü ekipler bu konuda sürekli yanlış anlıyor.
Suçsuzluk, "kimsenin olaya karışmadığı" veya "kimsenin hata yapmadığı" anlamına gelmez. Bu, olaya karışan kişilerin o sırada bildikleri, maruz kaldıkları baskı ve sahip oldukları araçlar göz önüne alındığında makul kararlar verdiklerini kabul ettiğiniz anlamına gelir. Soru "kim batırdı?" sorusuna doğru değişiyor. "Peki ya sistemimiz bu başarısızlığın muhtemel olmasını sağladı?"
Bu, pratik bir nedenden dolayı önemlidir: İnsanlar cezadan korkarlarsa sorunları gizlerler. Gizli sorunlar birleşiyor. Erken yakalanabilecek, ancak bunun yerine acil duruma dönüşene kadar büyüyen olaylarla karşı karşıya kalıyorsunuz.
Amaç, sorunları ortaya çıkarmanın ekibinizde bir kişinin yapabileceği en güvenli şey olmasını sağlamaktır.
Olay Geçmişe Dönük Olarak Ne Zaman Çalıştırılmalı
Her hatanın resmi bir otopsiye ihtiyacı yoktur. Bu ölçütlerden en az birini karşılayan olaylara ilişkin sürecin tamamını kaydedin:
- Müşteri etkisi -- Kullanıcılar hizmet kalitesi düşüklüğü, veri kaybı veya kesinti yaşadı
- Kısa süreler -- Hiçbir şey bozulmadı, bunun tek nedeni birisinin onu zamanında yakalamasıydı
- Yinelenen kalıplar -- Aynı sorun kategorisi daha önce de ortaya çıkmıştı
- Ekipler arası katılım -- Olay, birden fazla ekibin koordinasyonunu gerektirdi
- Yeni başarısızlıklar -- İzleme veya süreçlerinizin öngörmediği bir şey oldu
Geriye dönük incelemeyi ayrıntılar henüz tazeyken 48 saat içinde çalıştırın. Bir hafta beklemek herkesin hafızasının sonradan gözden geçirildiğini garanti eder.
Zaman Çizelgesi: En Önemli Eseriniz
Herhangi bir şeyi analiz etmeden önce gerçekte ne olduğunu yeniden yapılandırın. Bu, sanıldığından daha zordur çünkü insanların olaylara ilişkin anıları güvenilmezdir; stres zamanı sıkıştırır ve bozar.
Nesnel kaynakları kullanarak paylaşılan bir zaman çizelgesi oluşturun:
- Uyarıları ve kontrol panellerini izleme -- Metrikler gerçekte ne zaman değişti?
- Günlükleri dağıtma -- Neler ve ne zaman gitti?
- Sohbet kayıtları -- İnsanlar Slack'da veya olay kanalınızda ne dedi?
- Müşteri raporları -- İlk şikayet ne zaman geldi?
- Çağrı kayıtları -- Kime çağrı yapıldı ve ne zaman yanıt verdiler?
Bunları kronolojik olarak sıralayın. Editörlük yapmayın. Zaman çizelgesi, kahramanlar ve kötü adamlarla dolu bir anlatı değil, gerçeklere dayalı bir anlatım gibi okunmalıdır.
Bu zaman çizelgesi tek başına çoğu zaman gerçek sorunu ortaya çıkarır. Dağıtımın 14:03'te gerçekleştiğini ancak uyarının 14:47'ye kadar tetiklenmediğini keşfedebilirsiniz; bu, izleme sisteminizin 44 dakikalık bir kör noktaya sahip olduğu anlamına gelir. Bu boşluk, soruna neden olan kod değişikliğinden daha önemlidir.
Temel Neden Analizi: Açık Olanın Ötesine Geçmek
Geçmişe dönük olaylarda en yaygın başarısızlık, bulduğunuz ilk nedende durmaktır. Bir sunucunun belleği yetersiz kaldı. Boş bir kontrol eksikti. Bir yapılandırma değeri yanlıştı. Bunların hepsi doğru ve hepsi yetersiz.
5 Neden yöntemi işe yarar çünkü sizi bariz olanı aşmaya zorlar.
Olayla başlayın ve "neden?" diye sorun. tekrar tekrar:
- API 20 dakika boyunca 500 hata döndürdü. Neden?
- Veritabanı bağlantı havuzu tükendi. Neden?
- Bir sorgu zaman aşımı olmaksızın ve bağlantıları bekletmeden çalışıyordu. Neden?
- Sorgu, performans incelemesi olmadan yakın zamanda yapılan bir PR'ye eklendi. Neden?
- Veritabanına dokunan değişiklikler için gerekli performans inceleme adımı yoktur. Neden?
Artık sistem düzeyinde eyleme geçirilebilecek bir şeyiniz var: Yalnızca bunu yazan geliştiriciye bir hatırlatma değil, sorgular için bir inceleme kapısı ekleyin.
5 Neden hakkında bir uyarı: Bu yöntem, tek bir nedensel zincir olduğunda iyi çalışır. Pek çok olayın bir araya gelen birden fazla katkıda bulunan faktörü vardır. Bu durumlarda, bir balık kılçığı diyagramı veya basit bir "katkıda bulunan faktörler" listesi, her şeyi tek bir zincire sığdırmaktan daha dürüsttür.
Geriye Dönük Oturumun Yapılandırılması
Burada, 60 dakikalık bir olay retrospektifi için iyi çalışan bir format bulunmaktadır. Zamanlamayı ciddiyete göre ayarlayın.
1. Zaman çizelgesinde izlenecek yol (15 dakika)
Yeniden oluşturulan zaman çizelgesini sunun. Katılımcılardan düzeltmelerini veya ekleme yapmalarını isteyin. Henüz nedenleri tartışmayın; yalnızca gerçekleri ortaya koyun.
2. Etki değerlendirmesi (10 dakika)
Olanları sayısallaştırın. Kaç kullanıcı etkilendi? İşletme maliyeti ne kadardı? Herhangi bir veri kaybedildi mi? Bu, konuşmayı gerçeğe dayandırır ve yanıtın önceliklendirilmesine yardımcı olur.
3. Katkıda bulunan faktörler (20 dakika)
Bu temel analizdir. Olayın her aşaması için (neden, tespit, tepki, çözüm) şunu sorun: Durumu olması gerekenden daha kötü yapan neydi? Bunu daha iyi yapan neydi?
Yararlı istemler:
- İnsanlar karar verirken hangi bilgilere sahip değildi?
- Araçlarımız veya izlememiz nerede yetersiz kaldı?
- Yanıt sırasında hangi süreçler iyi çalıştı?
- Algılamayı daha hızlı hale getirecek ne olabilirdi?
- Dağıtımlar nerede bozuldu?
4. İşlem öğeleri (15 dakika)
Belirli, sahip olunan, zamana bağlı iyileştirmeler oluşturun. Bunları kategorilere ayırın:
- Anında düzeltmeler -- bozulan belirli bir şeyi düzeltin (bunların zaten yapılmış olması gerekir)
- Algılama iyileştirmeleri -- bu sınıftaki sorunları tespit etmeye yönelik daha iyi uyarılar, kontrol panelleri veya testler
- Süreç değişiklikleri -- geçitleri, runbook güncellemelerini veya yükseltme yolu iyileştirmelerini gözden geçirin
- Sistemik yatırımlar -- bu risk kategorisini azaltan daha büyük mimari veya alet çalışmaları
Kendinizi 3-5 eylem öğesiyle sınırlayın. 15 eylem öğesi oluşturan bir ölüm sonrası bunlardan sıfırını tamamlayacaktır. Acımasızca öncelik verin.
Suçsuzluğun Dili
Dil, kültürü politikalardan daha fazla şekillendirir. İşte somut değişiklikler:
Yerine Deneyin "John hatalı bir dağıtım sağladı" "14:03'teki dağıtım gerilemeyi beraberinde getirdi" "Takımın bunu yakalaması gerekirdi" "İnceleme sürecimiz bu tür değişiklikleri işaretlemedi" "Birisi yapılandırmayı güncellemeyi unuttu" "Yapılandırma, dağıtım sürecinin bir parçası olarak güncellenmedi" "Neden kimse fark etmedi?" "Bunun daha erken görünür olmasını ne sağlardı?"Model: Kişileri ve onların başarısızlıklarını değil, olayları ve sistemleri tanımlayın. Bu belirsiz olmakla ilgili değil. Bireysel hatadan bahsetmeden neyin yanlış gittiği konusunda son derece spesifik olabilirsiniz.
Olay Retrolarını Zayıflatan Yaygın Tuzaklar
Yakın neden üzerinde duruluyor. Düzeltme yapıldı, hata düzeltildi ve tamamlandı. Burada durursanız farklı özelliklerde benzer olaylar yaşamaya devam edeceksiniz.
Kimsenin takip etmediği eylem öğeleri oluşturma. Sahibi ve son tarihi olmayan bir eylem öğesi bir dilektir. Her yeni otopsi başlangıcında önceki olaylardaki eylem öğesinin tamamlandığını inceleyin.
Liderlik için geriye dönük olarak arındırma. Yazılı kayıtlar direktörlere veya Başkan Yardımcılarına ulaşmadan önce daha iyi görünecek şekilde düzenlenirse, güven sorununuz var demektir. Önemli olan şeffaflıktır.
Bunları yalnızca kesintiler için çalıştırmak. Riskin daha düşük olması ve insanların daha özgürce konuşması nedeniyle kıl payı atlatılan durumların analiz edilmesi genellikle daha değerlidir. Bir dağıtım neredeyse kesintiye neden oluyorsa ancak birisi bunu kanarya sırasında fark ettiyse bu da anlamaya değer.
Bunu bir durum toplantısına dönüştürmek. Retrospektif, analiz ve öğrenme amaçlıdır. Olay sırasında kimin ne yaptığını özetlemeye izin vermeyin. Zaman çizelgesi zaten bunu kapsıyor.
Olay Bilgi Tabanı Oluşturma
Bireysel postmortemler faydalıdır. İçinde arama yapılabilen bir postmortem kitaplığı dönüşümseldir.
Altı aylık belgelenmiş olaylara sahip olduğunuzda şu tür sorular sormaya başlayabilirsiniz: Olaylarımızın yüzde kaçı dağıtımla ilgili? Tespit için ortalama süremiz nedir? Eylem öğelerimiz gerçekten tamamlanıyor mu?
Olayların karşılaştırılabilir olması için tutarlı bir format tutun. Bunları kategoriye göre etiketleyin (dağıtım, altyapı, veriler, üçüncü taraf bağımlılığı). Bunları bir ekip wiki'sine kilitlenmek yerine, kuruluştaki herkesin erişebilmesini sağlayın.
Zamanla bu kitaplık, en değerli mühendislik varlıklarınızdan biri haline gelir. Yeni ekip üyeleri, sistemlerinizi herhangi bir mimari belgenin onlara öğretebileceğinden daha iyi anlamak için geçmiş olayları okuyabilir.
Yapışmasını Sağlama
Olaylardan ders alan ekipler ile bunları tekrarlayan ekipler arasındaki fark, takip etmeyle ilgilidir.
Her olayda önceki eylem öğelerini geriye dönük olarak inceleyin. Katkıda bulunan aynı faktör iki kez ortaya çıkarsa durumu artırın. Bu, iyileştirme sürecinizin iyileştirilmesi gerektiğinin bir işaretidir.
Sorunları erkenden ortaya çıkaran kişileri tanıyın. Birisi bir olayı önleyecek bir endişesini dile getirirse, bunu kamuoyu önünde kutlamaya değer. İstediğiniz davranışı güçlendiriyorsunuz.
Ve olayların yaşanacağını kabul edin. Hedef sıfır olay değil. Amaç, her olayın yeni olması; yeni ve ilginç şekillerde başarısız olmanız, aynı başarısızlıkları bir döngüde tekrarlamamanızdır.
NextRetro'yi ücretsiz deneyin -- Yerleşik şablonları ve anonim kart koleksiyonunu kullanarak ekibinizle birlikte yapılandırılmış, suçsuz olay retrospektifleri çalıştırın.
Son Güncelleme: Şubat 2026
Okuma Süresi: 7 dakika
