Olay Sonrası Aksiyon Maddeleri: Neden Hep Açık Kalır?
Summary
Post-mortem aksiyon maddelerinin çoğu hiç tamamlanmıyor. Nedeni kültür ya da bağlılık değil -- süreç: belirsiz maddeler, isimli mühendis yerine ekiplere atılan görevler ve sprint iş akışına bağlanmayan dokümanlar. Kapanan aksiyon maddelerinin üç ortak özelliği vardır: adlandırılmış bir mühendis, somut bir tamamlanma kriteri ve toplantı bitmeden oluşturulan bir ticket. Bu rehber, tamamlanma oranlarını %42'den %75'in üzerine taşıyan düzeltmeleri ele alıyor.
Geçen Salı post-mortem yaptınız. Altı aksiyon maddesi yazdınız. Şu an belki ikisinin Jira ticket'ı var. Birinin sahibi başka bir yangınla meşgul. Üçü hâlâ Google Doc'ta, "Takip Edilecekler" başlığı altında, dokunulmamış.
Olay sonrası aksiyon maddeleri, post-mortemlerin ya gerçek değer ürettiği ya da yalnızca seremoni yaptığı noktadır. Çoğunlukla ikinci seçenek gerçekleşir. incident.io araştırması, tamamlanma oranını medyan SRE ekiplerinde %50'nin altında gösteriyor. Bu, ortalama bir post-mortemin değişiklik üretme kapasitesinin retrospektif sticker oylamasıyla neredeyse aynı düzeyde olduğu anlamına geliyor -- süreç işliyor, suçlamalar blameless kalıyor ve aynı hata modu altı hafta sonra yeniden üretim ortamına çıkıyor.
Çözüm daha iyi bir şablon değil. Çözüm, bir aksiyon maddesini gerçek kılan şeyin farklı anlaşılmasıdır.
Çoğu Aksiyon Maddesinin Yapısal Olarak Neden Bozuk Olduğu
"Monitoring'i iyileştir" yazmak post-mortemde üretken hissettiriyor. Bu bir aksiyon maddesi değil -- sahibi, son tarihi ve tamamlanma kriteri olmayan bir iş kategorisidir.
Etkili aksiyon maddelerinin üç değişmez parçası vardır: ne yapılacak (spesifik ve ölçülebilir), kimin sahibi olduğu (bir takım değil, isimli bir mühendis) ve ne zamana kadar (belirli bir tarih, "Q3" değil). Bu üç parçadan herhangi biri eksikse, maddenin kapanma ihtimali düşüktür -- çünkü belirsiz maddeler öncelik sırasından düşürülmez, sadece çözülür. Kimse aktif olarak yapmamaya karar vermez. Sprint planlamasının gerçekleştiği yerlerde hiç görünmezler.
Fark düşündüğünüzden daha nettir. "Rate limiting'i geliştir" kurgusaldır. "Checkout path'teki upstream search API çağrılarına circuit breaker ekle -- @anya sahibi, hedef: 2026-09-19'a kadar merge" bir aksiyon maddesidir. Biri standup'ta görünür. Diğeri görünmez.
Yapısal başarısızlık, mühendislerin yorgun olduğu, toplantının uzadığı ve "bitirelim" baskısının "kesin olalım" baskısından fazla olduğu o an gerçekleşir. Tam da o an kesinlik en çok önem taşıyor -- çünkü bağlam hızla bozunuyor ve saat 23:00'de atladığınız detay, @anya'nın üç hafta sonra sormak zorunda kalacağı detaydır.
Her Ekip Liderini Rahatsız Etmesi Gereken Rakam
Tipik SRE ekiplerinde post-mortem aksiyon maddelerinin %50'den fazlası hiç tamamlanmıyor. Zayıf olay kültürüne sahip organizasyonlarda bu rakam %70'i geçiyor.
Bunun ölçekte güvenilirlik açısından ne anlama geldiğini düşünün. Post-mortemleriniz başına dört aksiyon maddesi ve çeyrek başına on olay üretiyorsa, 40 madde üretip 20'sinden azını kapatıyor ve büyüyen, düzeltilmemiş hata modları birikimi taşıyorsunuz. Bir sonraki olayın, daha önce teşhis ettiğiniz bir şeyin varyantı olma istatistiksel olasılığı yüksek.
DORA araştırması sürekli olarak şunu bulguluyor: yüksek performanslı mühendislik organizasyonlarının change failure rate'leri daha düşük -- daha iyi post-mortem yazdıkları için değil, aksiyon maddelerini kapattıkları için. Belge iş değildir. Ticket iştir.
Tamamlanma oranı %50'nin altına düştüğünde post-mortemler tiyatroya dönüşür -- bir süreci tatmin etmek için yazılır, bir şeyi değiştirmek için değil. Ekip bunu biliyor. Dikkatli maddeler yazan mühendisler onların çürüdüğünü izliyor. Sonunda, yazılan maddelerin kalitesi tamamlanma oranıyla örtüşecek şekilde düşüyor. Hâlihazırda mevcut olanları kimse kapatmıyorken neden kesin, sahiplenebilir bir madde yazasınız ki?
Azaltıcı ve Önleyici Aynı Kuyruk Değildir
Post-mortem aksiyon maddeleri iki kategoriye ayrılır ve bunları özdeş şekilde ele almak zamanla birikerek kötüleşen bir planlama hatasıdır.
Azaltıcı (mitigative) maddeler, kök nedeni ortadan kaldırmadan önce bir sonraki oluşumun blast radius'ını küçültür. Fallback ekle. Timeout ayarla. Circuit breaker yerleştir. Bu maddeler neredeyse her zaman acildir ve bir sprint içinde -- ideal olarak yeterince küçüklerse post-mortem toplantısı kapanmadan önce -- üretim ortamına çıkmalıdır.
Önleyici (preventative) maddeler hata modunu tamamen ortadan kaldırır: kuyruk consumer'ını yeniden yaz, retry mantığını yeniden tasarla, bu olayın burn rate alert'inizin önünden geçmesine izin veren SLO boşluğunu enstrüman et. Bunlar daha uzun sürer, tasarım incelemesi gerektirir ve doğrudan feature çalışmasıyla rekabet eder.
Her ikisini tek bir "post-mortem aksiyonları" etiketinde karıştırmak, uzun önleyici maddelerin listede o kadar sürüklenmesine yol açar ki ekip neden yazıldıklarını unutur; azaltıcı maddeler ise önlerindeki kuyruğu bekler. Bunları açıkça ayırın. Azaltıcı maddeler, planlama kapanmadan önce mevcut sprinte girer. Önleyici maddeler, kapanmış bir olaya yapıştırılmış post-it notları gibi değil, diğer güvenilirlik yatırımları gibi ele alınarak roadmap'e göre ayrı programlanır.
Aksiyon Maddeleri Nerede Ölüyor?
En yaygın mezarlık Google Doc'tur.
Ekipler post-mortemleri paylaşılan dokümanlarda taslaklar -- çünkü dokümanlar olay sırasında düşük sürtünmelidir. Sorun şu ki doküman, mühendislik işinin yaşadığı yer değildir. Jira orada. Linear orada. GitHub Issues orada. Sprint planlamanızın gerçekleştiği yer -- aksiyon maddesinin post-mortem toplantısı bitmeden önce gitmesi gereken yer orasıdır.
Entegrasyon boşluğu, tüm iş akışındaki en öngörülebilir başarısızlık noktasıdır. Olay gerçekleşir. Post-mortem yapılır. İyi aksiyon maddeleri yazılır. Sonra birisinin onları manuel olarak bir ticket sistemine kopyalaması gerekir. Bu kopyalama adımının, bunu otomatikleştirmeyen veya zorunlu kılmayan ekiplerde tamamlanma oranı yaklaşık %40'tır.
Çözüm yeni bir araç değil -- post-mortem dokümanı ile sprint sistemi arasındaki boşluğun kaldırılmasıdır. Birkaç olay yönetim platformu artık post-mortem şablonlarından doğrudan Jira veya Linear ticket'ları yazıyor. Sahibi olan yapılandırılmış maddeler üretip tracker'ınızla entegre olan not alma araçları da aynı işlevi görüyor. Temel ilke şudur: Hiçbir mühendisin, 90 dakikalık bir inceleme toplantısının ardından nöbet vardiyasının sonunda bir doc'tan ticket sistemine kopyala-yapıştır yapmaması gerekir.
Toplantıda Buharlaşmadan Önce Aksiyon Maddelerini Yakalamak
Göz ardı edilen bir sorun: post-mortem toplantısında yazılan aksiyon maddeleri her zaman belgede sonuçlanmaz.
Zorlu bir olayın ardından nefes alan dört mühendisin bulunduğu bir odada, en önemli maddeler çoğunlukla kimse laptop'unu açmadan önce konuşma sırasında ortaya çıkar. "Bunu canary'de yakalamamız gerekiyordu" -- bu bir aksiyon maddesi mi? Kimin duyduğuna, yazıp yazmadığına ve toplantı moderatörünün kapanışta sormayı hatırlayıp hatırlamadığına bağlı.
Post-mortemdeki moderatör rolü göründüğünden zordur. Grup dinamiklerini yönetiyorsunuz, zaman çizelgesini dürüst tutuyorsunuz, odayı atıf kayması için izliyorsunuz ve aynı zamanda ortaya çıkan her takibi kaydetmeniz gerekiyor. Bir şeyler kaçıyor. Bu ihmal değil; bilişsel yük.
Toplantı transkriptlerinden yapılandırılmış maddeleri arka planda çalışıp yüzeyleyen yapay zeka not alma araçları bu sorun için pratik bir çözüme dönüştü. Mühendislerden daha akıllı oldukları için değil -- yorgun olmadıkları, odayı yönetmedikleri ve belgeleme ile moderasyon arasında bağlam değiştirmedikleri için. Çıktının yine de insan incelemesine ihtiyacı var. Ancak 45. dakikadaki o gelişigüzel yorum dahil, tam konuşmadan elde edilen maddelerin ilk taslağına sahip olmak, toplantıdan ne kurtulduğunu değiştiriyor.
Sahip Sorunu: Ekipler Görevi Tamamlamaz
Bir aksiyon maddesini bir ekibe atamak, organizasyonel açıdan kimseye atamakla eşdeğerdir.
Ekiplerin takvim hatırlatıcısı olmaz. Jira'da bayraklanmazlar. Bir madde geciktiğinde standup'ta görünmezler. "Platform ekibi"nin bildirim gelen kutusu yok. @carlos'un var.
İsimli sahipler önemli, ancak bağlamı olan isimli sahipler daha da önemli. "@carlos'a: payments-worker'daki SQS consumer'a exponential backoff ekle -- 14:23 UTC'de gerçekleşen burst pattern için olay zaman çizelgesine bak. Hedef: 2026-09-26 sprint kapanışından önce merge, Jira: PAY-2891" @carlos'un ek konuşma gerekmeden çalıştırabileceği bir şeydir.
Post-mortem, bağlamın en yüksek olduğu andır. O anda yazdığınız madde kapanan maddedir. "Sonra düzgünce yazarız" denen madde ise sahipsiz kalır. 48 saat içinde, odadakiler olayı tetikleyen spesifik burst pattern'i unutmuş olacak. İki hafta içinde olay arka plan gürültüsüdür. Post-mortem toplantısının sonunda tam bağlamla yazılan madde, kapanan maddedir.
Gözlemlenebilirlik Boşlukları Özel Bir Durumdur
Post-mortem aksiyon maddelerinin önemli bir kısmı gözlemlenebilirlik boşluklarını içerir: enstrümanlanmamış bir metrik, çok gevşek bırakılmış bir alert eşiği, var olan ama runbook'tan bağlantı verilmemiş bir dashboard, kullanıcılar fark etmeden önce bozulmayı yakalamak için çok geniş bırakılmış bir SLO penceresi.
Bu maddelerin öngörülebilir bir başarısızlık örüntüsü var. Monitoring stack'inize erişim gerektiriyorlar. Olay kapandıktan ve anlık yangın söndükten sonra acil değiller. Ve genellikle olayı yaşayan ürün ekibi ile gözlemlenebilirlik araçlarına sahip platform ekibi arasında koordinasyon gerektiriyorlar -- bu el değiştirme noktası, çoğunlukla hiç kimsenin kapanışı resmen sahiplenmemesi anlamına geliyor.
Çözüm, gözlemlenebilirlik aksiyon maddelerini olayı yaşayan ürün ekibine değil, platform ekibinde doğrudan bir sahibi olan birinci sınıf bir kategori olarak ele almaktır. "search-service checkout path'e p99 gecikme alert'i ekle" -- alert kuralını gerçekten yazabilecek erişim ve bağlama sahip, gözlemlenebilirlik platformunuzda birisinin sahibi olması gerekiyor; başlamadan önce üç soru sormak zorunda kalacak bir ürün mühendisinin değil.
Kimsenin Kapatmadığı Geri Bildirim Döngüsünü Kapatmak
Tamamlanmanın ardından çoğu ekibin tamamen atladığı bir adım var: bunu görünür kılmak.
Post-mortem #47'deki bir aksiyon maddesi, #58. olay haline gelecek bir tekrarı engellediğinde, bu bağlantı görünür hale getirilmelidir. Olay kanalınıza yazın. Bir sonraki genel mühendislik güncellemesine koyun. PAY-2891'in sahibi olan nöbet mühendisine, circuit breaker'ın geçen Perşembe bir burst'ü absorbe ettiğini ve hiçbir şeyin paging'lenmediğini bildirin.
Mühendislik ekipleri, işlerinin meyvesini gördüklerinde daha fazla aksiyon maddesi tamamlıyor. Kimsenin geri dönüp bakmadığı bir dokümanın içine madde yazan ekipler, sonunda onları ciddiyetsizce yazmaya başlıyor -- format kalıyor ama kalite algılanan etkiyle örtüşecek şekilde düşüyor. Blameless post-mortem kültürünün hâlâ belleği olmayan bir güvenilirlik kültürü üretebileceği yol budur.
Geri bildirim döngüsü, post-mortem kültürlerini geliştirenleri sadece performans sergileyenlerden ayıran şeydir. Sabah 3'te, geçen çeyrek bir timeout'u düzelten nöbet mühendisi -- o mühendis işin ne için olduğunu tam olarak biliyor. Bu bağlantıyı, yalnızca düzeltmenin değerini kanıtladığı anda nöbette bulunan kişi için değil, tüm ekip için açık hale getirin.
İşleyen Bir Aksiyon Maddesi Nasıl Görünür?
Tutarlı şekilde kapanan biçimin yedi alanı vardır: kimin sahibi olduğu, tam olarak ne yapılacağı, neden önemli olduğu (bağlam alanı), hangi sprint'te teslim edileceği, Jira/Linear ticket referansı, maddenin azaltıcı mı yoksa önleyici mi olduğu ve açık herhangi bir bağımlılık.
"Bağlam" alanı isteğe bağlı değildir. Post-mortem ile @danielle'in sonunda bant genişliğine sahip olacağı sprint arasındaki üç haftalık boşluğu aşan şey budur. Bu alan olmadan, madde hikayesi olmayan bir görevdir. Bu alanla, @danielle PAY-2891'i soğuk açabilir ve tam olarak ne inşa ettiğini ve neden önemli olduğunu bilir.
Mühendislik Liderinden Gereken Şey
Aksiyon maddesi tamamlama oranı, bir mühendis metriği değil, ekip lideri metriğidir.
Mühendisler maddeleri yazar. Lider, kapanmalarını sağlayan sistemi kurmaktan sorumludur. Bu dört şey anlamına gelir.
Birincisi, planlama başlamadan önce azaltıcı maddeler için ayrılan sprint kapasitesi -- ekip velocity'sini feature çalışmasına bağladıktan sonra değil. Azaltıcı maddeler artık için rekabet etmek zorunda kalırsa kaybeder.
İkincisi, haftalık ekip senkronizasyonunda açık post-mortem maddelerinin beş dakikalık sabit incelemesi. Seremoni değil. Sadece bir tarama: 14 günden eski olan ama ticket'ta bulunmayan herhangi bir şey, gecikmesi bir karar gerektiren herhangi bir şey.
Üçüncüsü, gerçekten yapılamayacak bir şeyin açıkça önceliksizleştirilmesi. "PAY-2891'i bu çeyrekte yapmıyoruz çünkü Q4'te ödemeler yeniden yapılanması başlıyor ve bu gereksiz hale geliyor" bir karardır. "PAY-2891 üç aydır backlog'da" bir süreç başarısızlığıdır.
Dördüncüsü, aksiyon maddesi tamamlama oranının deployment frequency ve MTTR'nin yanında bir ekip sağlığı metriği olarak takip edilmesi. Bunu ölçen ekipler, deliberate süreç olmadan ortalamanın yaklaşık %42'de olduğunu buluyor. İsimli sahipler, sprint entegrasyonu ve haftalık inceleme ile bu rakam iki çeyrek içinde %75'in üzerine çıkıyor. Güvenilirlik açısından fark, on olay ritmiyle çalışan bir ekip için çeyrek başına yaklaşık bir büyük olayı daha önlemeye eşdeğerdir.
Post-mortem neyin bozulduğunu söyledi. Aksiyon maddesi onu düzeltme sözleşmesidir. Bu sözleşmenin kapanıp kapanmaması, bir belge kalite sorunu değil, bir yönetim kararıdır.