Postmortem Kültürü: Veri Platformunda Suçlamasız Vaka Analizi Nasıl Kurulur?
Veri olaylarında postmortem’i bir formaliteden ekibin öğrenme mekanizmasına dönüştürmek: kapanış kriteri, suçlamasız dil çevirisi, katkı faktörleri modeli, kabul kanıtı olan aksiyonlar ve 90 günlük plan.
▸ Kısa Açıklama ve Yönetici Özeti
Bir veri olayı kapandığında iki şey aynı anda doğru olabilir: sistem tekrar çalışıyor ve ekip hiçbir şey öğrenmedi. Fark, postmortem'in nasıl yazıldığında ortaya çıkar.
Veri platformlarında postmortem iki nedenle zorlaşır. Birincisi, hatalı veri sessizdir — bir mikroservis çökerse alarm çalar, ama yanlış hesaplanmış bir net_revenue kolonu günlerce "çalışan" bir sistemde yaşayabilir. İkincisi, hata insanın değil, pipeline'ın bir yerindedir ve bu yeri bulmak için "kim yaptı" sorusundan "hangi kontrol eksikti" sorusuna geçmek gerekir.
Bu kılavuz şu soruyu yanıtlar: *"Bir veri olayı sonrası ekibimizin gerçekten öğrendiğini nasıl garanti ederim; suçlamadan konuşan bir dil nasıl kurarım, aksiyonlarımı hangi kritere göre kapatırım ve postmortem kalitesini nasıl ölçerim?"*
Temel sav üç maddede:
- 1Postmortem bir doküman değil, bir kapanış koşuludur. Olay ancak eylemlerin *kabul kanıtı* üretildiğinde kapanır. "Postmortem yazıldı" bir kanıt değildir.
- 2İnsan adı bir kök neden değildir. "Ayşe dalgınlığı" sistemin yapısı hakkında hiçbir şey söylemez; "iki onaylı deployment checklist'i yoktu" söyler.
- 3Tek kök neden çoğu zaman bir kurgudur. Veri olayları zincirleme gelir; "katkı faktörleri" (contributing factors) modeli, tek neden aramanın yarattığı yanlış kesinliği ortadan kaldırır.
1. "Postmortem yazıldı" neden kapanış kanıtı değildir
Biten bir vaka sonrası yazılan belgenin varlığı hiçbir şeyi garanti etmez. Gerçek bir olayda öğrenmeyi engelleyen sorunlar genellikle belgenin dışındadır:
- Postmortem olay kapandıktan 3 hafta sonra yazılır; detaylar çoktan kaybolmuştur.
- Aksiyon maddeleri "iyileştirme" gibi yazılır: *"monitoring geliştirilecek"*. Sahibi ve tarihi yoktur.
- Aksiyonlar hiçbir taahhüt değişikliğine bağlanmaz; aynı olay 6 ay sonra tekrarlar.
- Belge suçlu bulmak için kullanılır; bir sonraki olayda kimse konuşmaz.
- Asıl soru hiç sorulmaz: *neden sistem bu hatayı fark edecek telemetriye sahip değildi?*
Bunların hiçbiri belgenin kendisinde görünmez. Yalnızca vaka kapanış kriteri bunları ortaya çıkarır.
▸Kapanış kriteri: zayıf → güçlü
| Zayıf kapanış | Güçlü kapanış |
|---|---|
| "Postmortem dokümanı oluşturuldu" | Her aksiyonun kabul kanıtı üretildi, değişiklik numarası belgeye bağlandı |
| "Monitoring iyileştirilecek" | "Exporter durduğunda absent() alarmı P1 olarak çalacak" + alarm testi kanıtı |
| "Daha dikkatli olacağız" | "PR şablonuna zorunlu data_contract_version alanı eklendi" |
| "Ekip bilgilendirildi" | "Runbook'a 'sık yapılan 3 hata' bölümü eklendi, başka biri tatbikatla doğruladı" |
Kapanış kriterinin tek cümlesi: Olay, aynı olay tekrarlandığında tespit süresini (MTTD) veya müdahale süresini belirgin biçimde kısaltacak en az bir kontrol sisteme girdiyse kapanır.
2. Olgunluk değerlendirmesi: ekibiniz nerede?
Her seviyeye geçmek için o seviyedeki tüm koşulların sağlanması gerekir.
| Seviye | Ad | Koşullar |
|---|---|---|
| 0 | Formalite | Olay kapandıktan sonra postmortem yazılıyor; içerik "ne oldu" anlatımıyla sınırlı. Aksiyonlar çoğunlukla "monitoring geliştirilecek". |
| 1 | Yapılandırılmış | Sabit bir şablon var (zaman çizelgesi, etki, katkı faktörleri). Aksiyonların sahibi ve tarihi var. Suçlayan dil hâlâ görülüyor. |
| 2 | Suçlamasız | Ekip suçlayan ifadeyi sistemik ifadeye çevirebiliyor. Aksiyonlar "kabul kanıtı" tanımıyla yazılıyor. Postmortem 5 iş günü içinde yayınlanıyor. |
| 3 | Ölçülen ve bağlanan | Postmortem kalitesi ölçülüyor (aksiyon kapatma oranı, tekrar oranı). Aksiyonlar taahhüt değişikliklerine (CI kuralı, alarm, runbook, sözleşme) dönüşüyor. Olay tekrar oranı düşüyor. |
| 4 | Öngörülü | Tekrarlayan katkı faktörü kümeleri tema analiziyle sistematik yatırıma dönüşüyor. Postmortem'ler tatbikat senaryolarını besliyor; "neredeyse olay" (near-miss) kayıtları da işleniyor. |
Pratik hedef: İlk 90 günde Seviye 2, ilk yılda Seviye 3. Seviye 4 ayrı bir olgunluk programı gerektirir.
▸▸ Hızlı öz değerlendirme
Her "evet" 1 puan. 0–3: Seviye 0–1 · 4–7: Seviye 2 · 8–10: Seviye 3+
- Yazılı, ekipçe erişilebilir bir postmortem şablonumuz var
- Son olayda postmortem 5 iş günü içinde yayınlandı
- Postmortem'de kişi adı geçmiyor, rol adı geçiyor
- Her aksiyonun tek bir sahibi var
- Her aksiyonun bitiş tarihi var
- Aksiyonlar "monitoring geliştirilecek" gibi soyut değil, test edilebilir
- Aksiyonların en az biri bir CI kuralı, alarm veya sözleşme değişikliğine dönüştü
- Kapanan aksiyonların kanıtı (PR no, alarm testi, runbook linki) belgeye işlendi
- Postmortem etkilenen tüm ekiplerle birlikte yazıldı (veri + uygulama)
- Son 90 gün içinde tekrarlayan bir olay yaşanmadı
8–10 puan: Seviye 3. Aksiyon kapatma oranını ölçmeye geçin. 4–7 puan: Seviye 2. Kapanış kriterini katılaştırın. 0–3 puan: Seviye 0–1. Önce şablonu ve suçlamasız dil rehberini yayınlayın.
3. Hangi olay postmortem hak eder?
Her küçük uyarı için postmortem yazmak, postmortem'i değersizleştirir. Hiç yazmamak ise tekrarları garantiler. Aradaki eşik etki × kapsam ile çizilir.
| Sınıf | Tanım | Postmortem |
|---|---|---|
| P1 — Kritik | Kullanıcıya görünen veri hatası; finansal mutabakat bozukluğu; BI panosu saatlerce yanlış sayı gösterdi; veri kaybı | Zorunlu, 5 iş günü içinde |
| P2 — Yüksek | Tek bir domain etkilendi; SLA ihlali gerçekleşti ama müşteriye yansımadı; manuel müdahale gerekti | Zorunlu, 10 iş günü içinde |
| P3 — Orta | Alarm çaldı, müdahale otomatikti; ihlal süresi for: 5m penceresinde söndü; etki ölçülemedi | Hafif postmortem (tek sayfa) |
| P4 — Düşük / near-miss | Eşiğe 1 dakika kala durdu; runbook ilk denemede çalışmadı ama olay çıkmadı | Kayıt (issue), aylık tema analizinde değerlendirilir |
▸Zorunlu kapsam kontrolü
Postmortem açmadan önce üç soruyu yanıtlayın:
- 1Veri mi, süreç mi? Hatalı veri üretimde yaşıyor mu, yoksa yalnızca süreç uzadı mı?
- 2Kim fark etti? Alarm mı, kullanıcı mı, analist mi? *Kullanıcı fark ettiyse* bu tek başına bir P1 sinyalidir.
- 3Kaç downstream nesne etkilendi? Tek tablo mu, yoksa
exposuresüzerinden BI panosu + ML feature'ı + sözleşme mi?
4. Suçlamasız dil: çeviri tablosu
Blameless kültürü, kötü niyet hoşgörüsü değildir. Suçlamadan öğrenmek, insan davranışını sistemin bir çıktısı olarak görmektir. Ekiplerin çoğu bu geçişi bir tabloyla yapar.
| Suçlayan ifade | Sistemik karşılığı |
|---|---|
| "Ayşe migration'ı yanlış çalıştırdı" | "Migration'ı çalıştıran kişi geri alınamaz komut olduğunu gösteren bir uyarı görmedi" |
| "Ekip testi unuttu" | "PR şablonunda test zorunluluğu yoktu; CI yeşil olduğunda merge engellenmiyordu" |
| "Kimse fark etmedi" | "Freshness sinyali izlenmiyordu; absent() alarmı tanımlı değildi" |
| "Dikkatsizlik" | "Aynı isimli iki toggle arasındaki fark dokümante edilmemişti" |
| "Yine aynı hata" | "Önceki postmortem'in aksiyonu kapatıldı olarak işaretlendi, ancak kabul kanıtı üretilmemişti" |
| "Sorumlusu belli" | "Katkı faktörleri: onaysız deploy, eksik telemetri, belgelenmemiş varsayım" |
| "Ekip yetersiz kaldı" | "Nöbet rotasyonu 3 kişiydi ve ikisi aynı hafta izinliydi" |
▸Konuşma kuralları
- 1Rol adı, kişi adı değil. "Producer Squad" yazın, "Mehmet" yazmayın.
- 2"Neden" yerine "nasıl". "Neden bunu yaptın?" savunmaya iter; "Bu karar hangi bilgiyle alındı?" açar.
- 3Karar anını ayır. Olay anında makul görünen şeyi, sonradan bakınca neden yanlış olduğunu iki ayrı paragrafta yazın (hindsight bias'ı azaltır).
- 4Toplantıda "kim" sorusunu yasaklayın. Moderatör bunu açıkça duyurur.
- 5Taslak, olaydan etkilenen ekiplerle birlikte yazılır. Veri ekibi tek başına yazarsa uygulama tarafındaki katkı faktörü görünmez kalır.
5. Zaman çizelgesi disiplini: veri olaylarında ne kaydedilir
Uygulama olaylarında zaman çizelgesi "deploy → alarm → rollback" şeklindedir. Veri olaylarında en kritik iki an farklıdır: hatalı verinin üretildiği an ile hatalı verinin fark edildiği an. Aradaki fark, gerçek tespit sürenizdir.
▸Veri olayı zaman çizelgesi alanları
| Alan | Neden gerekli |
|---|---|
T_bad_write | Hatalı kaydın sisteme yazıldığı ilk an (event time) |
T_detect | Alarmın veya insanın fark ettiği an |
T_contain | Akışın durdurulduğu / DLQ'ya alındığı an |
T_remediate | Düzeltilmiş partinin yeniden işlendiği an |
T_verify | Downstream tutarlılığın matematiksel doğrulandığı an |
T_close | Vaka kapanış koşullarının sağlandığı an |
detection_lag | T_detect − T_bad_write ← asıl ölçmek istediğiniz |
impact_window | T_contain − T_bad_write (ne kadar veri kirli kaldı) |
recovery_window | T_verify − T_contain |
detection_lag saat veya gün mertebesindeyse, olayın teknik kök nedeni ne olursa olsun asıl kök neden telemetri yokluğudur.▸Zaman damgası kaynağı kuralı
Zaman çizelgesinde tek bir saat kaynağı kullanın (UTC, tek NTP kaynağı). Olay anında toplanan zaman damgaları, postmortem yazılırken yeniden üretilmez — incident kanalına yazıldığı andaki kayıtlar kullanılır. Sonradan hatırlanan saatler postmortem'i sessizce yanlışlar.
6. Kök neden: "5 Whys" tuzağı ve katkı faktörleri
Klasik "5 Whys" tekniği tek bir neden zinciri arar. Veri platformlarında bu genellikle yanıltıcıdır:
amount sent yerine dolar gönderildi → çünkü servis güncellemesi deploy edildi → çünkü test yoktu → çünkü zaman yoktu → kök neden: "zaman yokluğu"Bu sonuç eyleme dönüşmez. "Daha fazla zaman" bir aksiyon maddesi değildir.
▸Katkı faktörleri modeli
Bunun yerine olayı birden fazla bağımsız katkı faktörünün kesişimi olarak yazın. Her faktör ayrı ayrı düzeltilebilir bir sistem özelliğidir.
| Kategori | Örnek katkı faktörü | Düzeltilebilir mi |
|---|---|---|
| Teknik — kod | Birim dönüşümü (sent/dolar) sözleşmede tanımlı değildi | ✅ Sözleşmeye semantik kural |
| Teknik — telemetri | amount_scale_anomaly metriği yoktu | ✅ Alarm kuralı |
| Teknik — CI | Semantik tüketici testi pipeline'da çalışmıyordu | ✅ CI adımı |
| Süreç | Sözleşme BACKWARD_TRANSITIVE kontrolünden geçti ama iş anlamı denetlenmedi | ✅ İnceleme adımı |
| Organizasyon | Producer ve consumer ekibi aynı incelemeye katılmıyordu | ✅ RACI güncellemesi |
| Bilgi | Yeni mühendis, amount'ın sent cinsinden olduğunu bilmiyordu | ✅ Runbook/onboarding |
| Zamanlama | Olay çeyrek sonu mali kapanış penceresine denk geldi | ❌ Kontrol edilemez → telafi mekanizması |
Kural: Katkı faktörlerinin en az biri teknik, en az biri süreç kategorisinde olmalıdır. Hepsi "insan hatası" çıkıyorsa analiz durmuştur.
▸Katkı faktörü yazım kalıbı
*Örnek:* Teknik — CI · Schema Registry pipeline — Semantik birim (sent/dolar) kontrolü yoktu → hata sözdizimsel doğrulamadan geçti ve 18 saat boyunca sessiz kaldı.
7. Aksiyon maddeleri: "kabul kanıtı" standardı
Postmortem'in değeri aksiyonlarının kalitesine eşittir. Kaliteyi belirleyen tek şey: kapatıldığını nasıl anlayacaksınız?
▸Zayıf → güçlü aksiyon
| ❌ Zayıf | ✅ Güçlü (kabul kanıtı ile) |
|---|---|
| "Monitoring geliştirilecek" | "data_contract_violation_total metriği eklenecek. Kanıt: staging'de ihlal enjekte edilip P2 alarmının çaldığı ekran görüntüsü" |
| "Testler eklenecek" | "CI'a semantik birim testi eklenecek. Kanıt: kasıtlı hatalı PR'ın pipeline'da kırmızıya döndüğü run linki" |
| "Ekip eğitilecek" | "Runbook'a 'sık yapılan 3 hata' bölümü eklenecek. Kanıt: yazar dışında birinin bu bölümle müdahaleyi tamamladığı tatbikat kaydı" |
| "Süreç iyileştirilecek" | "PR şablonuna zorunlu contract_version alanı eklenecek. Kanıt: alan boş bırakıldığında merge butonunun pasif olduğu kayıt" |
| "Alert eşiği ayarlanacak" | "Lag alarmına for: 5m eklenecek. Kanıt: batch spike'ta çalmadığını, sürekli bozulmada çaldığını gösteren iki test" |
▸Aksiyon sınıflandırması
| Tip | Örnek | Kalıcılık |
|---|---|---|
| Önleyici (Prevent) | CI kalite kapısı, sözleşme kuralı, şema kilidi | Yüksek — hatayı oluşmadan durdurur |
| Tespit edici (Detect) | Alarm kuralı, absent() kontrolü, anomali eşiği | Yüksek — MTTD'yi düşürür |
| Azaltıcı (Mitigate) | DLQ karantinası, devre kesici, otomatik rollback | Orta |
| Telafi edici (Compensate) | Runbook adımı, kontrol listesi, eğitim | Düşük — insan disiplinine bağlı |
Kural: Her P1 postmortem'de en az bir Önleyici ve bir Tespit edici aksiyon olmalıdır. Yalnızca telafi edici aksiyon içeren bir postmortem, sistemi değiştirmemiştir.
▸Aksiyon tablosu (şablonda zorunlu alanlar)
| # | Aksiyon | Tip | Sahip (rol) | Bitiş | Kabul kanıtı | Durum | Kanıt linki |
|---|---|---|---|---|---|---|---|
| 1 | Sent/dolar semantik testi CI'a eklenecek | Prevent | Data Platform | 2026-11-14 | Hatalı PR kırmızı | Açık | — |
| 2 | absent() telemetri alarmı eklenecek | Detect | SRE | 2026-11-10 | Exporter durdurma testi | Açık | — |
| 3 | DLQ karantina politikası yazılacak | Mitigate | Data Quality | 2026-11-21 | Sözleşme sayfası yayında | Açık | — |
Açık · Kapandı · Reddedildi (gerekçeli).
Kapandı statüsü yalnızca kanıt linki doldurulduğunda seçilebilir. Bu kuralı bir otomasyonla zorlayın — aksi halde 3 ay içinde herkes bu kuralı atlar.8. Metrikler: postmortem kalitesini nasıl ölçersiniz?
Olay sayısını ölçmek kolaydır ve yanıltıcıdır. Ölçülmesi gereken öğrenmenin gerçekleşip gerçekleşmediğidir.
| Metrik | Tanım | İyi sinyal |
|---|---|---|
| Postmortem kapsama oranı | Postmortem yazılan P1/P2 olay ÷ toplam P1/P2 olay | %100'e yakın |
| Zamanında yayın oranı | 5 iş günü içinde yayınlanan ÷ toplam | Yükselen trend, hedef %90+ |
| Aksiyon kapatma oranı | Kanıtlı kapatılan ÷ toplam aksiyon | Yükselen, 90 günde %70+ |
| Aksiyon yaşı | Açık aksiyonların medyan yaşı | 30 günü geçmeyen |
| Kanıtsız kapanış sayısı | Kanıt linki olmadan Kapandı işaretlenen aksiyon | 0 (hedef sıfır) |
| Olay tekrar oranı | Aynı katkı faktörü kümesiyle tekrarlayan ÷ toplam olay | Düşen trend |
| MTTD trendi | T_detect − T_bad_write medyanı | Düşen trend |
| Near-miss kayıt sayısı | P4 kayıtları ÷ çeyrek | Yükselen (kültür sağlığı) |
▸Aylık tema analizi (Seviye 4 pratiği)
Her ay tüm postmortem'lerin katkı faktörü etiketlerini tek tabloda toplayın ve en sık tekrarlayan 3 kümeyi çıkarın.
| Katkı faktörü kümesi | Görülme | Önerilen sistematik yatırım |
|---|---|---|
Eksik telemetri (absent() yok) | 7 | Telemetri varlık kontrolünü tüm exporter'lara standart şablon yap |
| Semantik sözleşme kontrolü yok | 5 | CI'a zorunlu semantik adım |
| Runbook'ta geri alma adımı eksik | 4 | Tüm runbook'lara "rollback" bölümü zorunlu |
Bu tablo, tek tek postmortem'lerin üretebileceğinden daha büyük bir kaldıraç sağlar: aynı hatayı 7 kez ayrı ayrı düzeltmek yerine bir kez sistematik olarak çözersiniz.
9. İlk 90 gün planı
▸1 — 1–2. hafta: Temel
- Postmortem şablonunu yayınlayın (bölüm 10'daki şablonu kullanın).
- Severity matrisini (P1–P4) yazılı hale getirin ve incident kanalına sabitleyin.
- Suçlamasız dil çeviri tablosunu (bölüm 4) ekip wiki'sine ekleyin.
- Son 6 aydaki olayları geriye dönük tarayın: kaç tanesi için postmortem var?
▸2 — 3–4. hafta: İlk uygulama
- İlk P1/P2 olayda şablonu birlikte doldurun (veri + uygulama ekibi aynı odada).
- Her aksiyona tek sahip + bitiş tarihi + kabul kanıtı yazın.
- Aksiyon kuralını (kanıtsız kapatma yok) duyurun — ilk hafta elle denetleyin.
▸3 — 5–8. hafta: Ölçüm
- 8 metrikten 4'ünü seçip ilk kez ölçün (öneri: kapsama, zamanında yayın, kapatma oranı, kanıtsız kapanış).
- Aksiyon kapatma durumunu izleyen basit bir pano kurun.
- İlk near-miss kaydını açın ve nasıl karşılandığını gözlemleyin.
▸4 — 9–12. hafta: Sistematikleştirme
- İlk aylık tema analizini yapın; en sık 3 katkı faktörü kümesini çıkarın.
- Bu 3 kümeden en az birini CI kuralı / alarm / sözleşme olarak sisteme gömün.
- Postmortem'lerden çıkan senaryoları tatbikat takvimine ekleyin.
- Olgunluk seviyesini yeniden puanlayın.
Kabul kriteri (90. gün): Son 90 günde en az bir P1 olayında Önleyici + Tespit edici aksiyon kanıtıyla kapatılmış, kanıtsız kapanış sayısı sıfır, ve aylık tema analizi bir kez yapılmış olmalı.
10. Kopyalanabilir postmortem şablonu
# POSTMORTEM — [DQ-INCIDENT-YYYYMMDD-XXX]
**Severity:** P[1-4]
**Durum:** Taslak / İncelemede / Yayınlandı
**Incident Commander:** [rol]
**Yazarlar:** [roller — kişi adı değil]
**Olay tarihi (UTC):** YYYY-MM-DD HH:MM
**Yayın tarihi:** YYYY-MM-DD (hedef: olaydan ≤5 iş günü)
---
## 1. Özet (3 cümle)
Ne oldu, kim etkilendi, ne kadar sürdü. Jargon yok — yönetici okuyacak.
## 2. Etki
| Boyut | Değer |
|---|---|
| Etkilenen veri ürünleri | [tablo / sözleşme / pano] |
| Etkilenen downstream | [BI panosu, ML feature, fatura API] |
| Etkilenen kayıt sayısı | [n] |
| Etkilenen zaman aralığı | [başlangıç – bitiş UTC] |
| Finansal / regülatif etki | [varsa] |
| Müşteriye yansıdı mı? | Evet / Hayır |
## 3. Zaman çizelgesi (UTC)
| Zaman | Olay |
|---|---|
| T_bad_write | İlk hatalı kayıt yazıldı |
| T_detect | Alarm çaldı / fark edildi |
| T_contain | Akış durduruldu / DLQ'ya alındı |
| T_remediate | Düzeltilmiş parti işlendi |
| T_verify | Downstream tutarlılık doğrulandı |
| T_close | Vaka kapandı |
**detection_lag:** [süre] · **impact_window:** [süre] · **recovery_window:** [süre]
## 4. Katkı faktörleri
> Format: [Kategori] · [Sistem bileşeni] — [Eksik kontrol] → [Sessiz kalma nedeni]
1. …
2. …
## 5. Ne iyi gitti
En az 2 madde. (Öğrenme tek yönlü olmamalı.)
## 6. Ne şans eseri kötüleşmedi
"Near-miss" anları. Bunlar bir sonraki olayın habercisidir.
## 7. Aksiyonlar
| # | Aksiyon | Tip | Sahip (rol) | Bitiş | Kabul kanıtı | Durum | Kanıt linki |
|---|---|---|---|---|---|---|---|
| 1 | | Prevent | | | | Açık | |
## 8. Sözleşme / SLO etkisi
- İhlal edilen SLO: [varsa]
- Error budget tüketimi: [%]
- Sözleşme güncellemesi gerekiyor mu? Evet/Hayır
## 9. Ekler
- İlgili runbook linki
- İlgili sözleşme / blueprint
- Triad karşılıkları (dbaguide / dataxtools)11. Kaynaklar ve ilgili rehberler
Bu sayfanın dayandığı kaynaklar
- Google SRE Book — *Postmortem Culture: Learning from Failure*
- Google SRE Workbook — *Postmortem Culture: How You Can Support It*
- John Allspaw — *Blameless PostMortems and a Just Culture* (Etsy Code as Craft)
- Etsy Debriefing Facilitation Guide
dataopsphere iç bağlantılar
- Veri Kalitesi Hatasına Müdahale & Karantina Yönetimi — Soru 7: kapanış kanıtı ve postmortem kaydı
- Replication Lag Alarmından Müdahaleye: Eskalasyon Runbook'u — Olay sonrası aksiyon tablosu örneği
- Backup Başarısından Kurtarma Hazırlığına: Restore Tatbikatı — Tatbikat rapor şablonu
- Uçtan Uca Data Observability — Tespit edici aksiyonların teknik temeli
▸▸ 3 SİTELİ TRİAD: Postmortem ve Olay Kültürü
Aynı konuyu üç farklı açıdan ele alan dataiotech yayınları:
- dbaguide.com · Teknik Runbook — *Olay sonrası teşhis komutları*: kök nedeni SQL ve log ile doğrulama adımları.
- dataxtools.com · Araç Matrisi — *Olay yönetimi araçları*: PagerDuty, Incident.io, Opsgenie ve postmortem şablonlarının karşılaştırması.
- dataopsphere.com · Operasyonel Olgunluk — *Bu sayfa*: ekip kültürü, kapanış kriteri, ölçüm ve 90 gün planı.
Restore Tatbikatı & Kurtarma Deneyiminizi Paylaşın
Altyapınızdaki gerçek tatbikat sonuçlarını, RTO/RPO hedeflerinizi ve karşılaştığınız operasyonel engelleri anonim veya isimli olarak paylaşın. Sektör benchmark'ına katkıda bulunun.
Bu mimariyi üretimde test etmek ister misiniz?
DataOpsphere CI/CD şablonlarını ve Docker Compose ortamlarını kopyalayıp hemen çalıştırabilirsiniz.