Incident Sonrası Postmortem ve Root-Cause Analizi Nasıl Yapılır?

Q: Root-cause analizi nasıl yapılır (5 Why vb.)?

Önce timeline ile olayı netleştirip trigger’ı yazın. 5 Why veya Fishbone ile sistemik zayıflığı bulun, kanıtlarla destekleyin ve preventive aksiyonlara bağlayın.

Q: Otel ve B2B projelerinde iyi bir postmortem örneği nasıl görünür?

Otel tarafında rezervasyon ve entegrasyon etkisi, B2B tarafında ödeme/raporlama ve SLA etkisi net ölçülür; kanıt (log/metrics) ve preventive aksiyonlar dokümanın merkezinde olur.

1. Incident Nedir, Ne Zaman Postmortem Yapılır?

Timeline ve RCA akışı, amaç kök nedeni bulma, operasyon ve IT bağlamı

Incident; kullanıcı deneyimini, geliri veya operasyonu etkileyen beklenmedik bir kesinti/bozulmadır. Otel tarafında “rezervasyon akmıyor”, “ödeme adımı hata veriyor”, “site yavaşlayıp çöküyor” gibi durumlar; B2B tarafında “raporlama çalışmıyor”, “ödeme/checkout hatası”, “kritik form gönderilmiyor” gibi durumlar incident kategorisine girer.

Hangi olaylar postmortem gerektirir?

•Gelir etkisi olan kesintiler (rezervasyon/ödeme/funnel)
•Güvenlik olayı veya veri riski doğuran durumlar
•Tekrar eden aynı sınıf hatalar (örn. her kampanya döneminde çökme)
•SLA ihlali veya müşteri şikâyeti yaratan performans düşüşleri

Soru : Postmortem nedir, ne zaman yazılmalıdır?

Cevap: Postmortem, incident sonrası olayın timeline’ını ve etki analizini çıkarıp root-cause’u belirleyen; corrective/preventive aksiyonları sahip/tarih ile takip eden öğrenme dokümanıdır. Gelir, güvenlik veya tekrar riski olan her olaydan sonra yazılmalıdır.

Ne yapmalıyım?

• “Incident” tanımını ekipte netleştir: hangi eşikte postmortem zorunlu?
• Postmortem’i “suçlu bulma” değil “sistem öğrenmesi” olarak çerçevele.
• Her postmortem’i bakım/backlog ritmine bağla (aksi halde raf dokümanı olur).

2. Root-Cause vs Trigger

Bu ayrım yapılmadığında postmortem’ler “neden” yerine “ne oldu” anlatımına sapar.

•Trigger: Olayı başlatan kıvılcım (örn. deploy, config değişimi, trafik artışı).
•Root-cause: Sistemik zayıflık (örn. eksik test, yanlış cache stratejisi, izleme eksikliği, hatalı dependency yönetimi).

Mini örnek (otel)

•Trigger: Kampanya landing’ine yeni script eklendi.
•Root-cause: Third-party script envanteri yönetimi yok + performans bütçesi/alarmlar tanımsız.

Mini örnek (B2B)

•Trigger: Ödeme servisinde API gecikmesi arttı.
•Root-cause: Circuit breaker/timeout politikası yok + hata bütçesi izlenmiyor.

Soru : Root-cause analizi nasıl yapılır (5 Why vb.)?

Cevap: Önce trigger’ı ve timeline’ı netleştir, sonra 5 Why veya Fishbone ile “sistemik zayıflığı” yakala; root-cause’u aksiyonlara bağlayıp tekrar olasılığını düşürecek önleyici adımları planla.

Ne yapmalıyım?

• Trigger’ı kabul et ama root-cause’u sistem düzeyinde ara.
• “İnsan hatası” diyorsan, o hatayı mümkün kılan sistem boşluğunu yazmadan kapatma.
• RCA’yı tek yöntemle değil, olaya göre 5 Why + Fishbone gibi araçlarla doğrula.

3. Postmortem Dokümanı Nasıl Yazılır?

Postmortem şablon bölümü, amaç standardizasyon, otel ve B2B ekip bağlamı

Postmortem dokümanı iki işe yarar: (1) olayı herkes için anlaşılır kılar, (2) aksiyonları “takip edilebilir” hale getirir. Türkiye’de birçok ekip postmortem’i ya hiç yazmaz ya da “özet mail” seviyesinde bırakır. Burada hedef, otel ve KOBİ/B2B ekipleri için uygulanabilir bir standart oluşturmaktır.

Postmortem şablonunun zorunlu başlıkları

•Özet (Executive Summary): Ne oldu? Kullanıcıya etkisi neydi? Ne kadar sürdü?
•Etki Analizi (Impact): Etkilenen akışlar + tahmini gelir/lead kaybı (trend/sınıflama olabilir)
•Timeline (Zaman Çizelgesi): T0 ilk sinyal → T1 tespit → T2 müdahale → T3 geçici çözüm → T4 kalıcı düzeltme/doğrulama
•Root-cause (RCA): Trigger + root-cause ayrımı + kanıt (log/metrics/tracing/deploy kayıtları)
•Aksiyonlar (Corrective/Preventive): Her aksiyon için sahip + tarih + doğrulama kriteri
•Öğrenimler ve Süreç Güncellemesi: runbook/alarmlar/test kapsamı güncellendi mi?

Örnek postmortem şablonu (tablo görünümü)

Tablo: Postmortem şablonu (tek tabloda, ekiplerin kopyalayıp kullanacağı format)

Bölüm	Ne yazılacak?	Örnek çıktı
Özet	Olayın 2–3 cümle özeti	“Rezervasyon akışı 38 dk hata verdi.”
Etki	Etkilenen kullanıcı/akış/KPI	“Fiyat görüntüleme düştü, çağrı arttı.”
Timeline	Dakika dakika akış	“10:12 alarm → 10:20 müdahale …”
RCA	Trigger + root-cause + kanıt	“Trigger deploy; root-cause cache kuralı”
Aksiyon	CAPA listesi	“Preventive: test + alarm + runbook”
Öğrenim	Süreç güncellemesi	“Release gate eklendi.”

Ne yapmalıyım?

• Postmortem’i “tek şablon” haline getir: her olayda aynı başlıklar.
• Timeline olmadan RCA yazma: önce olayın gerçek akışını netleştir.
• Aksiyonları backlog’a bağla; “tamamlandı” kriteri olmadan kapatma.

4. Otel ve B2B İçin Örnek Incident Senaryoları

Incident’lar sektörler arası benzer görünür; fark, kritik akışlardadır.

Otel senaryosu: rezervasyon sistem kesintisi

•Belirti: “Rezervasyon motoru açılmıyor / tarih seçince hata”
•Etki: yüksek sezonda doğrudan gelir riski + çağrı merkezi yükü
•RCA odakları: entegrasyon (PMS/OTA), cache/CDN, third-party script, rate limit, izleme eksikleri

B2B senaryosu: raporlama/ödeme hatası

•Belirti: “Dashboard veri göstermiyor / ödeme başarısız”
•Etki: müşteri güveni + SLA + tahsilat riski
•RCA odakları: API timeouts, veri pipeline, auth/permission, dependency güncelleme, test kapsamı

Key Statistics / Data Point (yumuşatılmış): Postmortem kültürü oturan ekiplerde, benzer tipte olayların tekrarlama sıklığı ve etki süresi genelde belirgin şekilde azalır; çünkü aksiyonlar “kişiye” değil “sisteme” bağlanır.

Incident KPI skor kartı, amaç etkiyi ölçme, yönetim raporu bağlamı

Ne yapmalıyım?

• Sektöre göre “kritik akış” playbook’u yaz: olay olunca ilk nereye bakılır?
• Etkiyi “KPI diliyle” anlat: yönetim ve teknik ekip aynı sayfada buluşsun.
• Her senaryo için runbook + alarm eşiği + test senaryosu güncelle.

5. Süreç ve Altyapıya Geri Besleme

Postmortem’in gerçek değeri, olaydan sonra “sistem güncellemesi” yapmasındadır. Aksi halde doküman, güzel bir rapor olarak kalır. Burada hedef, corrective ve preventive aksiyonları bakım döngüsüne eklemek ve ölçülebilir hale getirmektir.

Aksiyon yönetimi: CAPA’yı backlog’a bağlama

•Corrective Actions (Düzeltici): bug fix, config düzeltme, rollback
•Preventive Actions (Önleyici): test genişletme, monitoring/alerting, release gate, runbook, eğitim

“Önleyici aksiyon”u gerçekten önleyici yapan şey

•Sahip ve bitiş tarihi
•Başarı kriteri (örn. “aynı hata sınıfı için alarm 2 dk içinde tetiklensin”)
•Doğrulama (re-test, chaos test, yük testi, dry-run)

Ne yapmalıyım?

• Postmortem aksiyonlarını /tr/yazilim/bakim-ve-destek süreçlerine bağla: rutin kontrol listesine girsin.
• Güvenlik/altyapı aksiyonlarını /tr/yazilim/sunucu-guvenlik ile ilişkilendir.
• Etki ölçümü ve raporlama düzenini /tr/veri-analiz-ve-raporlama ile birleştir.

6. Predictive Keywords ve Competitor Gap’i Kapatan “Incident Öğrenme Modeli”

TR’de içerikler çoğu zaman “postmortem nedir?” seviyesinde kalır. Fark yaratan katman; incident’ı bir öğrenme modeli olarak ele alıp (blameless culture + structured RCA + CAPA + backlog) sürdürülebilir rutin haline getirmektir. “Postmortem nasıl yazılır” aramasında aranan şey aslında tek doküman değil, işleyen bir sistemdir.

Mini model (AIO: entity + semantic theme)

•Entity seti: incident → timeline → root-cause → corrective/preventive actions → backlog
•Semantic theme: learning from incidents, blameless culture, structured RCA
•Çıktı: her incident sonrası aynı şablon + aynı takip ritmi

Postmortem çıktıları kartı, amaç güven ve öğrenme, ajans ve işletme bağlamı

Ne yapmalıyım?

• Postmortem’i “tek sefer” değil, aylık/çeyreklik bakım ritminin parçası yap.
• Root-cause için 5 Why’ı standartlaştır, gerektiğinde Fishbone ile doğrula.
• CAPA takip tablosunu ekip görünür alanına taşı (dashboard/board).

7. Postmortem Şablonu & Incident Sonrası Aksiyon Planı İndir

TEMPLATEv1.0Checklist + Sprint

Postmortem Şablonu & Incident Sonrası Aksiyon Planı İndir — Yazılım / Incident Öğrenme Modeli (v1.0)

Bu şablon, incident sonrası postmortem’i “rapor” olmaktan çıkarıp, timeline + RCA + CAPA aksiyonlarıyla ölçülebilir bir öğrenme sistemine dönüştürmek için tasarlanmıştır. Otel ve B2B projelerinde aynı sınıf olayların tekrarını azaltmaya odaklanır. Aksiyonların bakım/backlog ritmine bağlanmasını kolaylaştırır.

Kim Kullanır?

Otel ve B2B projelerinde ürün/operasyon lideri + teknik lider + ajans/IT sorumlusu.

Nasıl Kullanılır?

Incident biter bitmez 24–72 saat içinde timeline ve impact kısmını doldurun.
5 Why/Fishbone ile root-cause’u kanıtlarıyla yazın, trigger’dan ayırın.
Corrective/preventive aksiyonları sahip/tarih/başarı kriteriyle CAPA tablosuna girin ve bakım planına ekleyin.

Ölçüm & Önceliklendirme (Kısa sürüm)

▢ ✅ Trigger ve root-cause net ayrıldı
▢ ✅ RCA kanıtlarla desteklendi (log/metrics/deploy)
▢ ✅ Preventive aksiyonların başarı kriteri ölçülebilir
▢ ✅ Aksiyonlar bakım/backlog ritmine bağlandı
▢ ✅ Yönetim özeti 1 sayfaya indirgenebiliyor

PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu

Şablonu İndir ↓Ücretsiz • PDF / Excel

Aksiyon ve geri besleme bölümü, amaç süreç olgunluğu, bakım ve destek bağlamı

Bir Sonraki Adım

Incident sonrası RCA’yı netleştirip preventive aksiyonları bakım/backlog sistemine bağlamak isteyen otel ve B2B ekipleri için.

Incident Sonrası Postmortem & Root-Cause Analizi Talep Et →

Sık Sorulan Sorular

Postmortem nedir, ne zaman yazılmalıdır?▾

Postmortem; incident sonrası timeline, etki analizi ve root-cause’u ortaya koyup corrective/preventive aksiyonları takip eden öğrenme dokümanıdır. Gelir, güvenlik veya tekrar riski olan her olaydan sonra yazılmalıdır.

Root-cause analizi nasıl yapılır (5 Why vb.)?▾

Önce timeline ile olayı netleştirip trigger’ı yazın. Sonra 5 Why ile “sistemik zayıflığa” ulaşın; gerekiyorsa Fishbone ile süreç/teknoloji/veri boyutlarını doğrulayın. Sonuç mutlaka preventive aksiyona bağlanmalıdır.

Incident sonrası hangi başlıklar raporlanmalı?▾

Özet, impact, timeline, RCA (trigger vs root-cause), corrective/preventive aksiyonlar ve süreç güncellemeleri (alarm/runbook/test) raporlanmalıdır. Aksiyonlar sahip ve tarihle takip edilmelidir.

Otel ve B2B projelerinde iyi bir postmortem örneği nasıl görünür?▾

Otelde rezervasyon akışı, PMS/OTA ve çağrı merkezi etkisi net; B2B’de ödeme/raporlama ve SLA etkisi ölçülür. Her iki durumda da “kanıt” (log/metrics) ve preventive aksiyonlar (izleme/test/runbook) dokümanın merkezindedir.

“Suçlu arama” yerine nasıl blameless kültür kurulur?▾

Diliniz süreç odaklı olsun (“hangi kontrol yoktu?”), kanıta dayalı RCA yapın, aksiyonları kişiye değil sisteme bağlayın. Postmortem’leri düzenli ritimle (aylık) gözden geçirerek standardı koruyun.

İlgili İçerikler

İlgili Yazılar