Kesintileri Önleyen Etkili Olay Sonrası Analizi (Postmortem) Nasıl Yazılır?
Teknoloji dünyasında, sistem kesintileri (outage) kaçınılmaz bir gerçektir. Ancak önemli olan, bir kesinti yaşandığında ne yaptığımızdır. Birçok ekip, yaşanan olaydan sonra hızlıca bir rapor hazırlar ve rafa kaldırır. Ne yazık ki, bu tür yaklaşımlar genellikle aynı sorunların tekrar etmesine yol açar. Peki, gerçekten gelecekteki kesintileri önleyebilen, öğrenme odaklı ve eyleme dönük bir olay sonrası analizi (postmortem) nasıl yazılır? Bu makale, sizi bu süreçte adım adım yönlendirerek, ekibinizin hatalardan ders çıkararak sistem güvenilirliğini artırmasını sağlayacak etkili postmortem pratiklerini ele alacaktır.
Olay Sonrası Analizi (Postmortem) Nedir ve Neden Hayatidir?
Olay sonrası analizi veya yaygın adıyla “postmortem”, bir sistem kesintisi, performans düşüşü veya hizmet kesintisi gibi istenmeyen bir olayın ardından yapılan detaylı bir inceleme ve değerlendirme sürecidir. Bu süreç, olayın nedenlerini anlamak, etkilerini belirlemek ve gelecekte benzer olayların yaşanmasını önlemek veya etkilerini azaltmak için atılması gereken adımları tespit etmek amacıyla gerçekleştirilir. Postmortem, sadece bir rapor yazmaktan ibaret değildir; aynı zamanda bir organizasyonun öğrenme kültürünü (learning culture) geliştirmesinin ve operasyonel mükemmelliğe ulaşmasının temel bir aracıdır.
Peki, postmortem neden bu kadar hayati? İlk olarak, olayların kök nedenlerini (root causes) ortaya çıkarır. Bir kesintinin sadece yüzeydeki belirtilerine odaklanmak yerine, olayın tetikleyicilerini, katkıda bulunan faktörleri ve temel zayıflıkları derinlemesine incelememizi sağlar. Örneğin, bir sunucunun çökmesi basit bir donanım arızası gibi görünebilir, ancak derinlemesine bir analiz, yetersiz yedekleme stratejileri, eski yazılım sürümleri veya yanlış yapılandırma gibi daha derin sorunları ortaya çıkarabilir. Bu kök nedenleri anlamadan, geçici çözümler (workaround) üretmekten öteye geçemeyiz ve sorunlar kaçınılmaz olarak tekrar edecektir.
İkinci olarak, postmortem süreci, suçlama kültüründen (blame culture) uzaklaşarak öğrenme ve gelişim odaklı bir yaklaşımı teşvik eder. Olaylar genellikle tek bir kişinin hatasından değil, karmaşık sistemlerin, süreçlerin ve insan faktörlerinin etkileşiminden kaynaklanır. Etkili bir postmortem, kişileri değil, süreçleri ve sistemleri eleştirir. Bu, ekip üyelerinin korkmadan bilgi paylaşmasını, hataları kabul etmesini ve çözüm odaklı düşünmesini sağlar. Bir hata yaptığında cezalandırılmayacağını bilen bir mühendis, gelecekte benzer durumları önlemek için daha proaktif davranacaktır. Bu, güvenilir mühendislik (reliability engineering) kültürünün temelini oluşturur.
Üçüncü olarak, postmortem, gelecekteki kesintileri önlemek için somut, eyleme dönük adımlar belirler. Sadece “ne oldu” sorusuna değil, “neden oldu” ve “bunu nasıl önleriz” sorularına da odaklanır. Bu adımlar, yazılım yamaları (patches), altyapı iyileştirmeleri, izleme (monitoring) araçlarının güncellenmesi, otomasyon (automation) senaryoları veya eğitim programları gibi çeşitli şekillerde olabilir. Her bir eylem maddesi için sorumlu bir kişi ve bir bitiş tarihi atanması, bu adımların gerçekten hayata geçirilmesini sağlar. Aksi takdirde, postmortem sadece bir belgeden ibaret kalır.
Son olarak, postmortem, kurum içi bilgi birikimini artırır ve ekipler arası iletişimi güçlendirir. Bir olayın tüm detaylarını belgelemek, gelecekte benzer olaylarla karşılaşan ekipler için değerli bir referans noktası oluşturur. Ayrıca, farklı ekiplerden (operasyon, geliştirme, ağ vb.) kişilerin bir araya gelerek olayı tartışması, onların birbirlerinin işleyişini ve zorluklarını anlamalarına yardımcı olur. Bu, siloları yıkar ve daha entegre, işbirlikçi bir çalışma ortamı yaratır. Kısacası, postmortem, bir kriz anını bir öğrenme fırsatına dönüştürmek için vazgeçilmez bir araçtır.
Etkili Bir Postmortem Yazımının Temel İlkeleri Nelerdir?
Etkili bir olay sonrası analizi (postmortem) yazmak, sadece teknik detayları listelemekten çok daha fazlasını gerektirir. Bu süreç, bir dizi temel ilke üzerine kuruludur ve bu ilkeler, postmortem’in gerçekten gelecekteki kesintileri önlemesini ve organizasyonel öğrenmeyi sağlamasını garanti eder. Bu ilkeleri anlamak ve uygulamak, postmortem dokümanınızın sadece bir rapor olmaktan çıkıp, değerli bir öğrenme ve iyileştirme aracı haline gelmesini sağlayacaktır.
İlk ve en önemli ilke, suçlama yapmama (no-blame) kültürüdür. Bir kesinti yaşandığında, doğal insan tepkisi suçlu aramaktır. Ancak etkili bir postmortem, bireyleri değil, sistemleri, süreçleri ve çevresel faktörleri inceler. Amaç, kimin hata yaptığını bulmak değil, hatanın neden yapıldığını ve gelecekte nasıl önlenebileceğini anlamaktır. Bu yaklaşım, ekip üyelerinin korku duymadan olayın tüm detaylarını, kendi katkıları dahil olmak üzere, şeffaf bir şekilde paylaşmasını teşvik eder. Eğer insanlar hata yapmaktan çekinirlerse, değerli bilgiler gizli kalır ve gerçek kök nedenlere ulaşılamaz. Bu ilke, postmortem toplantısının moderasyonu ve belgenin dili açısından kritik öneme sahiptir. Örneğin, “Operatör X, yanlış komutu çalıştırdı” yerine, “Operatörün yanlış komutu çalıştırmasına neden olan süreç adımları ve araç arayüzündeki eksiklikler incelenmelidir” gibi bir ifade kullanılmalıdır.
İkinci ilke, objektiflik ve kanıta dayalı analizdir. Postmortem, duygusal yorumlardan veya varsayımlardan arındırılmış, somut verilere dayanmalıdır. Olay günlükleri (logs), izleme (monitoring) grafikleri, performans metrikleri, hata mesajları ve diğer sistem kayıtları gibi kanıtlar, olayın kronolojisini ve nedenlerini doğrulamak için kullanılmalıdır. “Sanırım…” veya “Bence…” gibi ifadelerden kaçınılmalı, bunun yerine “Log kayıtlarına göre…”, “Grafikler gösteriyor ki…” gibi ifadelerle desteklenmelidir. Bu, analizin güvenilirliğini artırır ve gelecekteki kararların sağlam verilere dayanmasını sağlar.
Üçüncü olarak, detaylı ancak özlü bir anlatım esastır. Postmortem, olayın tüm kritik detaylarını içermeli, ancak gereksiz ayrıntılardan arındırılmış olmalıdır. Okuyucuların, olayın ne zaman, nasıl ve neden gerçekleştiğini, etkilerinin neler olduğunu ve ne gibi önleyici adımlar atılacağını net bir şekilde anlaması gerekir. Çok uzun ve karmaşık bir belge, okunmayabilir veya anlaşılması zor olabilir. Bu nedenle, teknik jargonun açıklanması, net ve anlaşılır bir dil kullanılması önemlidir. Kronoloji bölümü, olay anında alınan aksiyonları, ilgili zaman damgaları (timestamps) ile birlikte adım adım listelemelidir.
Dördüncü ilke, eyleme dönüklük ve hesap verebilirlik (accountability). Bir postmortem’in en önemli çıktısı, gelecekteki benzer olayları önleyecek veya etkilerini azaltacak somut eylem maddeleridir. Bu eylem maddeleri, spesifik, ölçülebilir, ulaşılabilir, ilgili ve zamana bağlı (SMART) olmalıdır. Her eylem maddesi için net bir sorumlu kişi veya ekip ve bir hedef tamamlanma tarihi belirlenmelidir. Bu, eylemlerin gerçekten hayata geçirilmesini sağlar ve postmortem’in sadece bir belge olarak kalmasını engeller. Örneğin, “İzleme sistemini iyileştir” yerine, “Ekip A, sunucu CPU kullanımının %90’ı aştığında uyarı verecek yeni bir Prometheus kuralı tanımlayacak ve 2 hafta içinde devreye alacak” şeklinde daha spesifik bir eylem maddesi yazılmalıdır.
Beşinci ilke, şeffaflık ve paylaşım. Postmortem, ilgili tüm paydaşlarla (geliştirme, operasyon, ürün, hatta bazen müşteriler) paylaşılmalıdır. Bu, herkesin olayın nedenlerini ve alınan dersleri anlamasını sağlar. Şeffaflık, organizasyon genelinde bir öğrenme kültürünü destekler ve farklı ekiplerin birbirlerinin deneyimlerinden faydalanmasına olanak tanır. Açık iletişim, güveni artırır ve gelecekteki işbirliğini güçlendirir. Bu, özellikle büyük ve karmaşık organizasyonlarda, farklı departmanlar arasında bilgi akışını sağlamak için kritik öneme sahiptir.
Bu ilkeler, bir postmortem’in sadece bir evrak işi olmaktan çıkıp, gerçek bir değişim ve gelişim aracı haline gelmesini sağlar. Her bir postmortem’i bu çerçevede ele almak, ekibinizin ve sistemlerinizin sürekli olarak iyileşmesine yardımcı olacaktır.
Postmortem Sürecine Adım Adım Yaklaşım: Hazırlık ve Veri Toplama
Etkili bir postmortem süreci, olay sona erer ermez başlar ve dikkatli bir hazırlık ile veri toplama aşamasını içerir. Bu aşama, postmortem toplantısının verimli geçmesi ve doğru sonuçlara ulaşılması için temel taşıdır. Yetersiz veri veya eksik hazırlık, analizi sığlaştırabilir ve önemli kök nedenlerin gözden kaçmasına neden olabilir. Bu bölüm, postmortem sürecinin ilk ve en kritik adımlarına odaklanarak, doğru bilgileri nasıl toplayacağınızı ve toplantıya nasıl hazırlanacağınızı detaylandıracaktır.
1. Olayın Sona Ermesi ve İlk Değerlendirme:
Olay kontrol altına alınıp hizmetler eski haline döndüğünde, ilk olarak olayın ne zaman başladığı, ne zaman sona erdiği ve hangi hizmetlerin etkilendiği gibi temel bilgileri not alın. Bu, daha detaylı analiz için bir başlangıç noktası oluşturacaktır. Bu aşamada, olayı yöneten ekip üyeleri, ilk gözlemlerini ve aldıkları aksiyonları kısaca belgelemelidir.
2. Veri Toplama Planı Oluşturma:
Postmortem toplantısından önce, hangi verilerin toplanması gerektiğini belirlemek için bir plan yapılmalıdır. Bu plan, aşağıdaki kategorilerdeki verileri içermelidir:
* Zaman Çizelgesi (Timeline) Verileri: Olayın başlangıcından bitişine kadar geçen süredeki kritik olaylar, alınan aksiyonlar ve bunların zaman damgaları.
* Sistem Metrikleri: CPU kullanımı, bellek, disk I/O, ağ trafiği, veritabanı bağlantıları, kuyruk uzunlukları gibi performans verileri.
* Uygulama Logları: Hata logları, erişim logları, debug logları ve özel uygulama logları.
* Altyapı Logları: Sunucu logları, ağ cihazı logları, güvenlik duvarı (firewall) logları.
* İzleme (Monitoring) ve Uyarı (Alerting) Verileri: Hangi uyarıların tetiklendiği, ne zaman tetiklendiği ve kimlere ulaştığı.
* Konfigürasyon Değişiklikleri: Olaydan kısa bir süre önce yapılan kod dağıtımları (deployments), yapılandırma değişiklikleri veya altyapı güncellemeleri.
* İletişim Kayıtları: Olay sırasında kullanılan iletişim kanallarındaki (Slack, e-posta, telefon) önemli mesajlar ve kararlar.
3. Verilerin Toplanması ve Düzenlenmesi:
Planlanan verileri çeşitli kaynaklardan (izleme sistemleri, log yönetim araçları, versiyon kontrol sistemleri) toplayın. Bu verileri okunabilir ve analiz edilebilir bir formatta düzenlemek önemlidir. Özellikle zaman çizelgesi için, tüm olayları kronolojik sıraya koymak, olay akışını anlamak için kritik öneme sahiptir.
Bu tür sorgular, olay anındaki kritik logları hızlıca filtreleyerek zaman çizelgesine entegre etmenizi sağlar.# Örnek Log Sorgusu (Elasticsearch/Kibana için) GET /_search { "query": { "bool": { "must": [ { "range": { "@timestamp": { "gte": "2023-10-26T10:00:00Z", "lte": "2023-10-26T12:00:00Z" } } }, { "match": { "message": "error OR failed OR exception" } } ] } }, "sort": [ { "@timestamp": { "order": "asc" } } ] }4. Olay Zaman Çizelgesi (Timeline) Oluşturma:
Toplanan verileri kullanarak detaylı bir zaman çizelgesi oluşturun. Bu, olayın başlangıcından itibaren yaşanan her önemli olayı, tetiklenen uyarıları, yapılan müdahaleleri ve bunların etkilerini saat ve dakika hassasiyetinde listelemelidir. Zaman çizelgesi, postmortem toplantısının temelini oluşturur ve tüm katılımcıların olay akışını aynı şekilde anlamasını sağlar.
Örnek bir zaman çizelgesi girdisi:
* 10:00: Kullanıcılar X hizmetine erişimde yavaşlık bildirmeye başladı.
* 10:05: İzleme sistemi, Y servisinde %80 CPU kullanım uyarısı tetikledi.
* 10:10: On-call ekip üyesi (Ahmet), uyarıyı aldı ve incelemeye başladı.
* 10:15: Ahmet, Y servisi loglarında "Veritabanı bağlantı havuzu dolu" hatasını tespit etti.
* 10:20: Ahmet, Z veritabanı sunucusunun bağlantı sayısını kontrol etti ve anormal bir artış gördü.
* 10:30: Ekipten Ayşe, Z veritabanı sunucusunda yeni bir indeksleme işleminin başladığını fark etti.
* 10:45: İndeksleme işlemi durduruldu.
* 10:50: Z veritabanı bağlantı sayısı normale döndü, Y servisi performansı düzeldi.
* 11:00: Hizmet tamamen eski haline döndü.5. Katılımcıları Belirleme ve Davet Etme:
Postmortem toplantısına kimlerin katılması gerektiğini belirleyin. Bu genellikle olaya doğrudan müdahale edenler, ilgili sistemlerin geliştiricileri, ürün sahipleri ve potansiyel olarak gelecekte benzer olayları önleyebilecek diğer ekip üyeleridir. Toplantı davetine, toplanan verilerin ve zaman çizelgesinin bir ön taslağını ekleyerek katılımcıların hazırlıklı gelmesini sağlayın.6. Ön Analiz ve Hipotez Geliştirme:
Toplantıdan önce, toplanan verileri ve zaman çizelgesini gözden geçirerek olası kök nedenler hakkında bazı ön hipotezler geliştirebilirsiniz. Bu, toplantı sırasında tartışmayı yönlendirmeye yardımcı olur. Ancak bu hipotezlere sıkı sıkıya bağlı kalmamak ve toplantıdaki yeni bilgilere açık olmak önemlidir. Ön analiz, toplantının daha odaklı ve verimli olmasını sağlar.Bu hazırlık adımları, postmortem toplantısının sadece bir "dedikodu" seansı olmaktan çıkıp, yapılandırılmış, veriye dayalı ve sonuç odaklı bir analiz platformu haline gelmesini sağlar. Doğru verilerle donanmış bir ekip, olayın gerçek nedenlerini çok daha etkili bir şekilde ortaya çıkarabilir.
Postmortem Toplantısını Verimli Kılmak: Modere Etme ve Tartışma
Postmortem sürecinin kalbi, olayın tüm yönlerinin açıkça tartışıldığı ve kök nedenlerin belirlendiği toplantıdır. Bu toplantı, doğru yönetilmezse verimsiz tartışmalara, suçlamalara veya önemli noktaların gözden kaçmasına neden olabilir. Bu nedenle, toplantının etkili bir şekilde modere edilmesi ve katılımcılar arasında yapıcı bir tartışma ortamının sağlanması hayati öneme sahiptir. Bu bölümde, postmortem toplantısını nasıl verimli hale getireceğinizi ve tartışmayı nasıl yöneteceğinizi ele alacağız.
1. Toplantı Ortamını Hazırlama ve Gündemi Belirleme:
Toplantı başlamadan önce, rahat ve açık bir iletişim ortamı sağlayın. Fiziksel bir toplantıysa beyaz tahta veya dijital bir araç (Miro, Jamboard gibi) hazırlayın. Uzaktan yapılıyorsa, ekran paylaşımı ve not alma araçlarının hazır olduğundan emin olun. Toplantının başında, gündemi ve ana hedefleri (olayın kronolojisini anlama, kök nedenleri belirleme, eylem maddeleri oluşturma) net bir şekilde belirtin. Ayrıca, "suçlama yapmama" ilkesini yeniden vurgulayarak herkesin kendini güvende hissetmesini sağlayın.2. Kronolojinin Gözden Geçirilmesi ve Anlaşılması:
Toplantının ilk ve en önemli adımı, önceden hazırlanan olay zaman çizelgesini (timeline) tüm katılımcılarla birlikte gözden geçirmektir. Moderatör, her bir olayı ve aksiyonu kronolojik sırayla okumalı ve katılımcılardan eksik veya yanlış bilgileri düzeltmelerini istemelidir. Bu aşamada, "Ne oldu?", "Ne zaman oldu?", "Kim fark etti?", "Ne yapıldı?" gibi sorularla detayları netleştirin. Bu, herkesin olayın akışı hakkında ortak bir anlayışa sahip olmasını sağlar. Özellikle kilit anlarda, "Bu noktada ne düşündün?", "Elinizde hangi bilgiler vardı?" gibi sorularla karar alma süreçlerini anlamaya çalışın.
Örneğin:
* Moderatör: "Saat 10:05'te Y servisinde %80 CPU kullanımı uyarısı tetiklenmiş. Bu uyarıyı alan ekip üyesi kimdi ve ne hissetti?"
* Ahmet (On-call): "Ben aldım. Önceki hafta da benzer bir uyarı almıştık ama kendiliğinden düzelmişti, bu yüzden ilk başta çok endişelenmedim."
* Moderatör: "Anlıyorum. Peki sonraki aksiyonun ne oldu?"
Bu tür diyaloglar, sadece teknik detayları değil, aynı zamanda olayın insan faktörlerini de anlamaya yardımcı olur.3. Kök Neden Analizi (Root Cause Analysis):
Kronoloji üzerinde mutabık kalındıktan sonra, olayın nedenlerine inme zamanı gelir. Burada en etkili tekniklerden biri 5 Neden (5 Whys) tekniğidir. Olayın ilk belirtisinden başlayarak, "Neden?" sorusunu art arda beş kez (veya gerçek kök nedene ulaşana kadar) sorarak derinlemesine inilir.
Örnek 5 Neden Uygulaması:
* Olay: Müşteriler X hizmetine erişemedi.
* Neden 1: Uygulama sunucusu çöktü.
* Neden 2: Uygulama sunucusu belleği tükendi.
* Neden 3: Bellek sızıntısı (memory leak) olan bir kod parçası vardı.
* Neden 4: Bu kod parçası son dağıtımda (deployment) devreye alındı ve yeterince test edilmedi.
* Neden 5: Dağıtım öncesi test süreçlerinde otomasyon eksikliği ve performans testlerinin yetersizliği vardı.
Bu teknik, yüzeydeki sorunlardan sistemik zayıflıklara kadar inmenizi sağlar. Balık Kılçığı Diyagramı (Fishbone Diagram) veya FMEA (Failure Mode and Effects Analysis) gibi diğer teknikler de kullanılabilir, ancak 5 Neden genellikle daha hızlı ve pratik bir başlangıç noktasıdır.4. Katılımcıları Tartışmaya Dahil Etme ve Yönlendirme:
Moderatörün görevi, tüm katılımcıların fikirlerini ifade etmelerini sağlamak ve tartışmayı doğru yolda tutmaktır.
* Aktif Dinleme: Katılımcıların söylediklerini dikkatlice dinleyin ve anladığınızı teyit edin.
* Açık Uçlu Sorular: "Bu konuda başka kimin bir fikri var?", "Bu durumun başka hangi olası nedenleri olabilir?", "Bunu nasıl farklı yapabilirdik?" gibi sorularla daha fazla düşünceyi teşvik edin.
* Odaklanmayı Sağlama: Tartışma ana konudan sapmaya başladığında, nazikçe konuya geri dönülmesini sağlayın. "Şu an kök nedenleri tartışıyoruz, eylem maddelerine birazdan geleceğiz" gibi ifadeler kullanılabilir.
* Suçlamaları Engelleme: Herhangi bir suçlama eğilimi fark edildiğinde, "Amacımız bireyleri değil, sistemleri ve süreçleri anlamak" diyerek müdahale edin.5. Öğrenilen Dersleri ve Gelişim Alanlarını Belirleme:
Kök nedenler belirlendikten sonra, toplantının en önemli çıktısı olan öğrenilen dersler (lessons learned) ve gelişim alanları üzerinde durulmalıdır. Bu, sadece teknik sorunlar değil, aynı zamanda süreç, iletişim veya araçlardaki eksiklikler de olabilir.
Örnek öğrenilen dersler:
* İzleme sistemimizde bellek sızıntılarını erken tespit edecek metrikler eksik.
* Dağıtım öncesi performans testleri, yeni kod değişikliklerinin potansiyel etkilerini yeterince kapsamıyor.
* Olay anında farklı ekipler arasındaki iletişim kanalları net değildi.Bu aşamalar, postmortem toplantısının sadece bir bilgi paylaşım seansı olmaktan çıkıp, gerçek bir problem çözme ve iyileştirme platformu haline gelmesini sağlar. Doğru moderasyon ve yapılandırılmış bir tartışma, ekibinizin her olaydan değerli dersler çıkarmasına ve daha güçlü sistemler inşa etmesine olanak tanır.
Eylem Planı Oluşturma ve Takip Etme: Gerçek Önleyici Adımlar
Bir postmortem toplantısının tüm amacı, gelecekteki benzer olayları önlemek veya etkilerini azaltmak için somut eylem adımları belirlemektir. Kök nedenler ve öğrenilen dersler ne kadar iyi belirlenirse belirlensin, eğer bu bilgiler eyleme dönüşmezse, postmortem süreci boşa harcanmış bir çaba olur. Bu bölüm, postmortem'in en kritik çıktısı olan eylem planının nasıl oluşturulacağını, önceliklendirileceğini ve takip edileceğini detaylandıracaktır.
1. Eylem Maddelerini Tanımlama:
Postmortem toplantısının sonunda veya hemen ardından, belirlenen kök nedenlere ve öğrenilen derslere dayanarak bir dizi eylem maddesi (action items) tanımlanmalıdır. Her eylem maddesi, belirli bir sorunu ele almalı ve gelecekteki bir olayı önlemeye veya hafifletmeye yönelik olmalıdır. Bu maddeler, basit düzeltmelerden (örneğin, bir yapılandırma dosyasını güncelleme) daha büyük sistemik iyileştirmelere (örneğin, yeni bir izleme aracı entegre etme) kadar değişebilir.2. SMART Hedefler Belirleme:
Her eylem maddesi, SMART (Specific, Measurable, Achievable, Relevant, Time-bound) kriterlerine uygun olmalıdır. Bu, eylem maddelerinin net, takip edilebilir ve gerçekçi olmasını sağlar.
* Specific (Belirli): Ne yapılacağı net olmalı. "İzlemeyi iyileştir" yerine "Veritabanı bağlantı havuzu kullanımı için yeni bir uyarı kuralı ekle."
* Measurable (Ölçülebilir): Başarının nasıl ölçüleceği belli olmalı. "Uyarı kuralı eklenecek ve 2 hafta boyunca test edilecek."
* Achievable (Ulaşılabilir): Görev, mevcut kaynaklarla ve becerilerle gerçekleştirilebilir olmalı.
* Relevant (İlgili): Eylem maddesi, olayın kök nedenleriyle doğrudan ilgili olmalı ve gelecekteki kesintileri önlemeye yardımcı olmalı.
* Time-bound (Zaman Sınırlı): Bir tamamlama tarihi veya zaman çerçevesi olmalı. "30 Kasım 2023 tarihine kadar tamamlanacak."Örnek bir SMART eylem maddesi:
"Geliştirme ekibinden Ayşe, bellek sızıntısı tespit edilenDataProcessormodülündeki hatayı düzeltecek ve düzeltmeyi içeren yeni sürümü (v1.2.3) 15 Kasım 2023 tarihine kadar test ortamına dağıtacak."3. Sorumlu Atama ve Önceliklendirme:
Her eylem maddesine net bir sorumlu kişi veya ekip atanmalıdır. Sorumlu atanmayan bir eylem maddesi genellikle tamamlanmaz. Ayrıca, tüm eylem maddeleri aynı öneme sahip değildir. Bunları aciliyet ve etki (impact) açısından önceliklendirmek önemlidir. Yüksek riskli ve kolayca uygulanabilir maddeler öncelikli olmalıdır.
Yaygın önceliklendirme yöntemleri:
* Aciliyet/Etki Matrisi: Eylem maddelerini aciliyet ve potansiyel etki (gelecekteki olayları önleme veya hafifletme potansiyeli) ekseninde sınıflandırın.
* Çaba/Fayda Matrisi: Uygulama için gereken çaba ile sağlayacağı faydayı karşılaştırın. Düşük çaba, yüksek fayda maddeleri ilk sıralarda yer almalıdır.4. Eylem Planının Belgelenmesi:
Tüm eylem maddeleri, sorumluları, öncelikleri ve hedef tarihleri ile birlikte merkezi bir yerde belgelenmelidir. Bu, bir proje yönetim aracı (Jira, Trello, Asana), bir wiki sayfası veya basit bir elektronik tablo olabilir. Önemli olan, herkesin erişebileceği ve güncelleyebileceği bir kaynak olmasıdır. Postmortem belgesinin kendisi de bu eylem planına bir referans içermelidir.5. Takip ve İlerlemenin İzlenmesi:
Eylem planı oluşturulduktan sonra, en kritik adım düzenli takiptir. Sorumluların görevlerini zamanında tamamladığından emin olmak için periyodik kontroller yapılmalıdır. Bu, haftalık ekip toplantılarında bir gündem maddesi olarak veya özel bir takip toplantısıyla gerçekleştirilebilir. Tamamlanan maddeler işaretlenmeli ve geciken maddeler için yeni bir plan yapılmalıdır.html
| Eylem Maddesi | Sorumlu | Hedef Tarih | Öncelik | Durum |
|---|---|---|---|---|
| Veritabanı bağlantı havuzu için uyarı kuralı ekle | Ahmet Yılmaz (DevOps) | 2023-11-15 | Yüksek | Tamamlandı |
| Bellek sızıntısı fix’ini test ortamına dağıt | Ayşe Demir (Geliştirme) | 2023-11-20 | Yüksek | Devam Ediyor |
| Olay iletişim protokolünü güncelle | Canan Korkmaz (Operasyon) | 2023-12-01 | Orta | Başlamadı |
Bu tür bir tablo, ilerlemeyi görselleştirmek ve herkesi bilgilendirmek için çok