Postmortem Süreci: Review Toplantısı, Action Item Takibi ve Incident Metriklerinin Sınırları

Sürüm notu: Bu yazıdaki örnekler .NET 10 (file-based app olarak çalışan iki küçük araç) ile denenmiştir. Incident metrikleri hesabındaki veri bir alıştırma verisidir; gerçek bir ekibin kaydı değildir.

Önce Tahmin Et

Bookstore (sitedeki serilerin ortak örnek uygulaması, bir online kitapçı) ekibi her çeyreğin sonunda incident sayılarına bakıyor. İkinci çeyrekte 7 incident var ve ortalama mitigation süresi 61 dakika; üçüncü çeyrekte 8 incident var ve ortalama 38 dakikaya inmiş. Yönetici sunumuna "MTTM (etkinin ortalama durdurulma süresi) yüzde 38 iyileşti" yazmak üzeresin. Bu iyileşme gerçek mi, yoksa iki çeyrek arasındaki fark tesadüfle de çıkabilir mi? Tahminini bir yüzdeyle söyle: aynı ekip hiçbir şeyi değiştirmeseydi, bu büyüklükte bir fark kaç çeyrek çiftinde görülürdü? İkinci soru: geçen ayki ödeme sağlayıcısı incident'ının postmortem'inde 4 action item yazıldı. Bunların kaçının hâlâ açık olduğunu bugün kim, nereden biliyor? Cevaplar yazının ikinci yarısında, gerçek bir hesapla.

Hangi Incident Postmortem İster?

Postmortem, bir incident'tan sonra ne olduğunu, neden olduğunu ve tekrar etmemesi için ne yapılacağını yazıya döken doküman. Debugging ve Problem Çözme serisinin "Root Cause Analysis: 5 Whys, Fishbone ve Blameless Postmortem" yazısı dokümanın içini anlattı: blameless (suçlu aramayan) dil, zaman çizelgesi, 5 Whys ve fishbone ile sebep analizi, şablon. Bu yazı dokümanın etrafındaki süreçle ilgileniyor: hangi incident'a postmortem yazılır, taslak nasıl review'dan geçer, action item'lar nasıl takip edilir ve incident metrikleri neyi gösterir, neyi gösteremez.

Her incident'a postmortem yazmak ekibi yorar ve dokümanları formaliteye çevirir; hiçbirine yazmamak ise aynı arızayı üçüncü kez yaşamak demek. Bu yüzden kriterler önceden yazılı olmalı. Google'ın SRE (Site Reliability Engineering; güvenilirliği yazılım mühendisliğiyle yönetme disiplini) kitabının "Postmortem Culture" bölümü tipik tetikleyicileri sayıyor: belirli bir eşiği aşan kullanıcıya görünür kesinti, her türlü veri kaybı, nöbetçinin rollback gibi elle müdahalesi, eşiği aşan çözüm süresi ve arızayı monitoring yerine bir insanın bulması. Aynı bölüm, herhangi bir paydaşın bir olay için postmortem isteyebileceğini de ekliyor. Bookstore'un kriterleri docs/postmortems/README.md dosyasında:

## When a postmortem is required
- SEV1 or SEV2.
- More than 20 % of a 30-day error budget spent by one incident (`docs/slo/error-budget-policy.md`).
- Any data loss, any wrong charge, or a security-relevant finding.
- A customer or support found it before an alert did.
- Production was changed by hand (rollback, lever in `docs/incidents/levers.md`, manual data fix).
- Anyone asks for one, including for a near miss.

Son iki madde en çok atlananlar. "Bir müşteri bizden önce fark etti" maddesi, monitoring'in kör noktasını; "production elle değiştirildi" maddesi ise bir önceki yazıda eklediğimiz switches.json gibi kolların ne sıklıkta ve neden kullanıldığını görünür kılıyor. Serinin üçüncü yazısındaki error budget policy'den gelen kriter de burada: tek başına 30 günlük bütçenin yüzde 20'sinden fazlasını harcayan incident, seviyesi ne olursa olsun postmortem alıyor.

Taslaktan Yayına

Postmortem'in kendi zaman çizelgesi de olmalı; yoksa "bu hafta yazarız" iki ay sürer ve insanlar ayrıntıları unutur. Bookstore'un akışı:

## Flow and deadlines
| Step | Who | When |
|---|---|---|
| Draft (timeline from the incident document, impact in numbers, contributing factors, action items) | IC picks an author, usually the ops lead | within 3 working days |
| Review meeting (45 minutes) | author, IC, people who were in the incident, owner of each affected service; facilitator is not the author | within 5 working days |
| Publish (merge to `main`, post the link in #engineering) | author | after the review |
| Action items tracked | each owner; `postmortem-lint` in CI lists overdue ones | until done |

Yazar, incident dokümanındaki zaman çizelgesinden başlıyor; bir önceki yazıdaki tabletop'un scribe notları bu yüzden UTC (eşgüdümlü evrensel saat) saatli ve tek satırlık olgulardan oluşuyordu. Tabletop'un postmortem'i docs/postmortems/2026-11-14-payment-provider-tabletop.md olarak repoda. Etki ve katkıda bulunan faktörler bölümü:

## Impact
- 22:09:47–22:27:47 UTC (18 minutes). Customer-visible: checkout.
- 1,598 orders cancelled; each cancelled order also deleted the customer's cart.
- 1,380 checkouts answered 503 by the kill switch (carts kept), 456 of them while the provider was already healthy.
- 5 minutes of checkouts at about 4 s (latency SLO), 0 errors in that phase.

## Contributing factors
- The payment timeout was fixed at startup; there was no lever until this incident's preparation added one.
- A failed payment cancels the order after the cart has been deleted, so a provider problem costs customers their carts.
- With the kill switch on, Bookstore.Api makes no calls to the provider, so our metrics cannot show its recovery.
- The page does not tell whether a mitigation works: 503s from the kill switch count as failures like 502s.

İki ayrıntıya dikkat. Etki sayılarla yazılıyor: "bazı müşteriler etkilendi" değil, "1.598 sipariş iptal edildi, her biri bir sepet". Katkıda bulunan faktörlerde ise kişi yok, sistem var: "Emre kill switch'i geç kapattı" yerine "kill switch açıkken metric'lerimiz sağlayıcının düzeldiğini gösteremiyor". İkisi aynı olayı anlatıyor, ama yalnız ikincisi bir action item'a dönüşebiliyor. "Where we got lucky" bölümü de bilinçli: işler kötü gitmediği için değil, şans eseri kötü gitmediği için iyi biten şeyleri yazmak, bir sonraki incident'ın adayını gösteriyor.

Review Toplantısını Yönetmek

Taslağı genellikle incident'ın ops lead'i yazıyor, çünkü zaman çizelgesini en iyi o biliyor. Review toplantısının amacı taslağı onaylamak değil, onu sınamak: zaman çizelgesi doğru mu, etki sayılarla mı yazılmış, sebep yeterince derin mi, action item'lar bu incident'ı gerçekten engelliyor ya da küçültüyor mu? Google'ın SRE kitabı da review'da benzer kriterlere bakıyor: kritik veriler toplanmış mı, etki değerlendirmesi tamam mı, root cause yeterince derin incelenmiş mi, action plan ve önceliklendirme uygun mu, sonuç paydaşlarla paylaşılmış mı.

Toplantıyı yönetmenin birkaç kuralı var. Kolaylaştırıcı (facilitator) yazar olmamalı; yazar kendi metnini savunmaya geçer. Toplantıda yeni debugging yapılmaz; eksik bilgi varsa bir action item olur. Sorular "neden yaptın?" değil "o anda elindeki bilgiyle bu neden mantıklıydı?" biçiminde sorulur; ilki savunma, ikincisi bilgi üretir. Bookstore'da gündem 45 dakika ve docs/postmortems/README.md dosyasında yazılı:

## Review meeting agenda
1. (5 min) The facilitator reads the impact and the timeline summary. No new debugging in the meeting.
2. (15 min) Timeline questions: when did we know, what did we believe, why did that make sense at the time?
3. (15 min) Contributing factors and action items: does each item make this incident less likely, find it sooner
   or make it smaller? One owner, a date, a ticket.
4. (5 min) What went well and should be kept.
5. (5 min) Decide: severity confirmed, postmortem approved or a second round.

"What went well" maddesi göründüğünden önemli. Tabletop'ta kill switch'in sepetleri koruması ya da runbook'un sebebi bir dakikada göstermesi bir sonraki incident'ta da yapılması gereken şeyler; yazılmazsa bir sonraki "iyileştirme" onları farkında olmadan bozabilir.

Action Item'lar: Sahip, Tarih, Sınıf

Postmortem'in bıraktığı kalıcı iz action item'lar. Google'ın SRE Workbook'unun "Postmortem Culture" bölümü kötü action item'ı tanımlıyor: "iyileştir", "daha iyi yap" gibi belirsiz fiiller, sahipsiz ve önceliksiz maddeler, yalnız mitigation olan listeler. İyi bir action item'ın tek bir sahibi, bir takip kaydı (ticket), bir önceliği ve doğrulanabilir bir bitiş durumu var. Aynı bölüm Ben Treynor Sloss'tan bir cümle aktarıyor: "a postmortem without subsequent action is indistinguishable from no postmortem." (Google SRE Workbook, "Postmortem Culture: Learning from Failure", 2018). Takip edilmeyen action item, postmortem'i bir anı yazısına çeviriyor.

Bookstore action item'ları dört sınıfa ayırıyor: prevent (aynı tetikleyici artık bu sonucu doğuramaz), detect (daha erken fark ederiz), mitigate (tekrar olursa etki daha küçük ya da kısa olur) ve process (on-call, iletişim, review). Sınıf yazmak bir denge kontrolü: yalnız mitigate ve process içeren bir liste, aynı incident'ın tekrar olacağını kabul ediyor demek. Workbook da yalnız mitigation'dan oluşan listelere karşı uyarıyor.

Kurallar yazılı olunca kontrolü bir araca bırakmak kolay. tools/postmortem-lint/postmortem-lint.cs, .NET 10'un file-based app özelliğiyle (proje dosyası olmadan dotnet run dosya.cs) çalışan küçük bir program: docs/postmortems/ altındaki her dosyanın "Action items" tablosunu okuyor, sınıfı, sahibi, tarihi ve ticket'ı olmayan maddede hata veriyor, açık ve tarihi geçmiş maddeleri listeliyor. Kodun çekirdeği:

string[] classes = ["prevent", "detect", "mitigate", "process"];
string[] notAnOwner = ["", "team", "everyone", "tbd", "?"];
...
foreach (string[] c in rows)
{
    // Sütunlar: | ID | Action | Class | Owner | Due | Ticket | Status |
    total++;
    string id = c[0];
    if (!classes.Contains(c[2].ToLowerInvariant()))
    {
        Report(file, id, $"class '{c[2]}' is not one of {string.Join("/", classes)}");
    }
    if (notAnOwner.Contains(c[3].ToLowerInvariant()))
    {
        Report(file, id, "needs one named owner");
    }
    if (!Regex.IsMatch(c[5], @"^[A-Z]+-\d+$"))
    {
        Report(file, id, $"needs a ticket (got '{c[5]}')");
    }
    bool isOpen = !c[6].Equals("done", StringComparison.OrdinalIgnoreCase);
    if (!DateOnly.TryParseExact(c[4], "yyyy-MM-dd", CultureInfo.InvariantCulture, DateTimeStyles.None, out DateOnly due))
    {
        Report(file, id, $"due date '{c[4]}' is not yyyy-MM-dd");
    }
    else if (isOpen && due < today)
    {
        overdue++;
        Console.WriteLine($"OVERDUE {Path.GetFileName(file)} {id}: {c[1]} (owner {c[3]}, due {due:yyyy-MM-dd}, {today.DayNumber - due.DayNumber} days late)");
    }
    ...
}

Review'dan önceki ilk taslak tipik hatalar içeriyordu: "iyileştir" fiili, sınıf yerine "fix", sahip olarak "team", tarih olarak "soon". Lint ilk taslakta şunu söyledi:

dotnet run tools/postmortem-lint/postmortem-lint.cs -- docs/postmortems 2026-11-17
ERROR 2026-11-14-payment-provider-tabletop.md PM-1: class 'fix' is not one of prevent/detect/mitigate/process
ERROR 2026-11-14-payment-provider-tabletop.md PM-2: needs one named owner
ERROR 2026-11-14-payment-provider-tabletop.md PM-2: needs a ticket (got '')
ERROR 2026-11-14-payment-provider-tabletop.md PM-2: due date 'soon' is not yyyy-MM-dd
ERROR 2026-11-14-payment-provider-tabletop.md PM-3: needs a ticket (got '')
3 action items, 3 open, 0 overdue, 5 problems

Çıkış kodu 1 olduğu için aynı komut CI pipeline'ında bir adım olarak, eksik action item'lı bir postmortem'in main'e girmesini engelliyor. Review'dan çıkan son hâl dört madde (her sınıftan bir tane); aynı komutu iki farklı günde çalıştırınca takip kısmı da görünüyor:

## Action items
| ID | Action | Class | Owner | Due | Ticket | Status |
|---|---|---|---|---|---|---|
| PM-1 | Keep the cart when a payment fails: delete it only after the payment succeeded | mitigate | Ayse | 2026-11-27 | BOOK-412 | open |
| PM-2 | Synthetic payment probe that also runs while checkout is paused; ticket alert "provider healthy, checkout paused for 5 minutes" | detect | Emre | 2026-11-24 | BOOK-413 | open |
| PM-3 | Runbook: when to raise the timeout and when to use the kill switch; check the provider every 5 minutes while paused | process | Emre | 2026-11-18 | BOOK-414 | done |
| PM-4 | Validate switches.json in the pipeline before it is shipped (keys, types, ranges) | prevent | Selin | 2026-12-01 | BOOK-415 | open |

dotnet run tools/postmortem-lint/postmortem-lint.cs -- docs/postmortems 2026-11-20
4 action items, 3 open, 0 overdue, 0 problems

dotnet run tools/postmortem-lint/postmortem-lint.cs -- docs/postmortems 2026-11-30
OVERDUE 2026-11-14-payment-provider-tabletop.md PM-1: Keep the cart when a payment fails: delete it only after the payment succeeded (owner Ayse, due 2026-11-27, 3 days late)
OVERDUE 2026-11-14-payment-provider-tabletop.md PM-2: Synthetic payment probe that also runs while checkout is paused; ticket alert "provider healthy, checkout paused for 5 minutes" (owner Emre, due 2026-11-24, 6 days late)
4 action items, 3 open, 2 overdue, 0 problems

İkinci çalıştırma, Önce Tahmin Et'teki ikinci sorunun cevabı: açık action item'ları kimse hatırlamak zorunda değil, araç her gün söylüyor. Bookstore bu çıktıyı haftalık on-call handoff notuna ekliyor; serinin beşinci yazısındaki şablonda "Still open" bölümü tam bunun için var. Tarihi geçen bir madde ya yapılır ya da review'da bilinçli olarak yeni bir tarih alır; sessizce eskimez.

Near-Miss'lerden Öğrenmek

Near-miss (az kalsın incident olacak ama olmayan olay), postmortem'in en ucuz kaynağı. Kimse etkilenmediği için suçluluk duygusu yok, baskı yok, ama aynı zayıflık orada. Örneğin yanlış ortama gitmeye başlayıp pipeline'daki onay adımında duran bir deploy bir near-miss; serinin beşinci yazısında runbook'u denerken bulduğumuz, yanlış process'e bağlanabilen komut da öyle. Bunlar için tam bir postmortem gerekmiyor; yarım sayfalık bir not ("ne oldu, neden kötü bitmedi, bir dahaki sefere ne olabilirdi") ve gerekiyorsa bir action item yeterli. README'deki "anyone asks for one, including for a near miss" maddesi bunu açıkça izinli kılıyor.

Incident Metrikleri ve Sınırları

Incident'ları sayıya dökmek doğal bir istek: MTTD (Mean Time to Detect; bir arızanın ortalama fark edilme süresi), MTTM (Mean Time to Mitigate; etkinin ortalama durdurulma süresi) ve MTTR (bir arızanın ortalama düzeltilme süresi). Sorun şu ki incident süreleri çok çarpık dağılıyor: çoğu incident birkaç on dakika sürerken arada bir saatler süren biri çıkıyor ve ortalamayı tek başına belirliyor. Az örnekle (bir çeyrekte 7–8 incident) bu ortalamanın çeyrekten çeyreğe değişimi çoğunlukla gürültü. Štěpán Davidovič'in Google için yazdığı "Incident Metrics in SRE" raporu (O'Reilly, 2021) bunu Monte Carlo simülasyonuyla gösteriyor: hiçbir şey değişmeden de MTTR'de büyük iyileşmeler ve kötüleşmeler görmek mümkün.

Bunu Bookstore'un örnek verisiyle kendimiz denedik. tools/incident-metrics/sample-history.csv, iki çeyreklik uydurma ama gerçekçi bir incident listesi (alıştırma verisi, gerçek bir ekibin kaydı değil). incident-metrics.cs her çeyrek için medyan tespit süresini, mitigation süresinin ortalamasını, medyanını ve en büyüğünü, müşterinin fark ettiği incident sayısını ve harcanan bütçeyi (her incident'ın 30 günlük bütçeden harcadığı yüzdelerin toplamı) yazıyor; sonra bootstrap (gözlenen veriden tekrar tekrar örnek çekerek bir farkın şansla ne sıklıkta çıkacağını ölçme) ile farkı sınıyor:

// Bootstrap: iki çeyreği birleştirilmiş incident'lardan yeniden çek (hiçbir şey değişmemiş gibi) ve iki ortalama
// arasındaki farkın gözlenen fark kadar büyük çıkma sıklığını say.
string[] quarters = [.. incidents.Select(i => i.Quarter).Distinct().Order()];
double[] a = [.. incidents.Where(i => i.Quarter == quarters[0]).Select(i => i.MinutesToMitigate)];
double[] b = [.. incidents.Where(i => i.Quarter == quarters[1]).Select(i => i.MinutesToMitigate)];
double[] pooled = [.. a, .. b];
double observed = Math.Abs(a.Average() - b.Average());
Random random = new(2026);
const int Runs = 100_000;
int asLarge = 0;
for (int run = 0; run < Runs; run++)
{
    double meanA = Enumerable.Range(0, a.Length).Average(_ => pooled[random.Next(pooled.Length)]);
    double meanB = Enumerable.Range(0, b.Length).Average(_ => pooled[random.Next(pooled.Length)]);
    if (Math.Abs(meanA - meanB) >= observed)
    {
        asLarge++;
    }
}

dotnet run tools/incident-metrics/incident-metrics.cs -- tools/incident-metrics/sample-history.csv
quarter  n  detect(median)  mitigate(mean / median / max)  by customer  budget spent
2026-Q2  7         7 min        61.1 / 35 / 240 min        2 of 7        92%
2026-Q3  8         6 min        37.6 / 38 / 61 min        2 of 8        66%
MTTM 2026-Q2 → 2026-Q3: 61.1 → 37.6 min (-38%)
A difference this large appears by chance in 39.6% of 100,000 resampled quarter pairs.

Ortalama yüzde 38 düşmüş, ama medyan 35'ten 38 dakikaya çıkmış: tipik bir incident'ın süresi değişmemiş, yalnız üçüncü çeyrekte 240 dakikalık tek bir SEV1 (en ağır severity seviyesi) yok. Bootstrap'in cevabı da net: iki çeyrek aynı dağılımdan gelseydi, bu büyüklükte bir fark 100.000 denemenin yüzde 39,6'sında görülecekti. Önce Tahmin Et'teki sorunun cevabı bu: "MTTM yüzde 38 iyileşti" cümlesi bu veriyle savunulamaz. Hedef hâline getirildiğinde ise daha kötüsü olur: iktisatçı Charles Goodhart'ın adıyla anılan yasaya göre ölçü hedef olunca iyi bir ölçü olmaktan çıkar. MTTR hedefi olan bir ekip incident'ı erken kapatmayı, ya da hiç ilan etmemeyi öğrenir.

Bu, sayılara hiç bakmamak demek değil. Daha az yanıltan sinyaller var: incident sayısı severity'ye göre, müşterinin bizden önce fark ettiği incident'ların oranı (tablodaki "by customer"; monitoring'in kör noktasını gösterir), incident başına harcanan error budget (kullanıcı etkisini doğrudan ölçer) ve action item'ların zamanında kapanma oranı (öğrenmenin gerçekleşip gerçekleşmediğini gösterir). Deploy'lardan doğan arızalar için DORA'nın (DevOps Research and Assessment; yazılım teslim performansını ölçen araştırma programı) change failure rate ve 2023'te adı failed deployment recovery time olarak değiştirilen recovery metrikleri var; CI/CD Temelleri serisinin "Pipeline'ı Ölçmek ve Hızlandırmak: DORA Metrikleri, Cache ve Paralellik" yazısı bunları anlattı. Onlar da aynı uyarıyla okunmalı: eğilime uzun dönemde bak, tek çeyreğe değil.

Postmortem'i Paylaşmak

Postmortem'in değeri onu okuyan kişi sayısıyla büyüyor. Google'ın SRE kitabı bunun için kullanılan yolları anlatıyor: ayın postmortem'ini bültende paylaşmak, ekiplerin postmortem okuma kulüpleri ve eski bir postmortem'in rollerle yeniden oynandığı "Wheel of Misfortune" egzersizi. Bookstore gibi küçük bir ekipte karşılığı basit: yayınlanan her postmortem'in linki ekip kanalına gidiyor ve ayda bir sprint review'un son 15 dakikası bir postmortem'i (gerekirse başka bir şirketin yayımladığı bir postmortem'i) konuşmaya ayrılıyor. Serinin sekizinci ve dokuzuncu yazıları bu ikinci türden.

Kültürün turnusol testi "human error" (insan hatası) ifadesi. Bir postmortem'in root cause'u "insan hatası" diye bitiyorsa analiz bitmemiştir: insanın hata yapmasını mümkün kılan, hatayı fark ettirmeyen ve etkisini büyüten sistem hâlâ yerinde. Google'ın SRE Workbook'u da insan davranışını değiştirmeye çalışmanın, otomasyonu ve süreci değiştirmekten daha az güvenilir olduğunu vurguluyor. Tabletop'taki ilk taslağın "switches.json'u değiştirirken daha dikkatli ol" maddesi bu yüzden review'da "dosyayı pipeline'da doğrula" maddesine dönüştü.

Üretimde Dikkat

Postmortem'e bir son tarih ver ve sahibini incident kapanırken belirle. Tabletop'un incident dokümanının son satırı "Postmortem owner: Emre, draft by 2026-11-17" idi; o satır yazılmasaydı postmortem büyük ihtimalle hiç yazılmazdı.

Action item'lar ekibin normal iş takip aracında yaşasın. Postmortem dokümanındaki tablo bir özet; asıl takip ticket'ta. Lint'in ticket ID'si istemesi bu bağı zorunlu kılıyor.

Postmortem'ler güvenlik ve gizlilik açısından da okunmalı. Paylaşılan dokümanda müşteri verisi, iç IP adresi ya da secret olmamalı; geniş paylaşım bunu gerektiriyor.

Sık Düşülen Tuzaklar

Postmortem'i ceza gibi kullanmak. Postmortem yazılan ekip "kötü iş yapmış" sayılıyorsa ekipler incident ilan etmemeyi öğrenir. Kriterler yazılı ve nesnel olmalı.

Yalnız mitigation içeren action item listesi. Her maddesi "runbook'a ekle" olan bir postmortem, aynı incident'ın tekrar olacağını kabul ediyor. En az bir prevent ya da detect maddesi ara.

Tek çeyreğin MTTR'sine göre karar vermek. Az örnek ve çarpık dağılımla ortalama, tek bir uzun incident'ın gölgesi.

Review'u yazarın yönetmesi. Kendi metnini yöneten kişi itirazları savunmaya döner; kolaylaştırıcı başka biri olmalı.

Küçük Bir Deneme

★☆☆ Son yaşadığın bir incident'ın (ya da serinin altıncı yazısındaki tabletop'un) action item'larını dört sınıfa ayır. Hiç prevent ya da detect maddesi yoksa bir tane yaz.

★★☆ postmortem-lint.cs'e iki kural ekle: "Improve", "Better" gibi belirsiz fiille başlayan maddeyi reddetsin ve hiç prevent ya da detect sınıfı olmayan postmortem'de uyarı versin. Testini sahte bir postmortem dosyasıyla yap.

★★★ incident-metrics.cs'e medyan için de bootstrap ekle ve iki çeyreğin medyan farkının şansla ne sıklıkta çıktığını hesapla. Sonra örnek veriye her çeyrekte birer incident daha ekleyerek sonucun ne kadar oynadığına bak.

Kendi postmortem'lerimiz bize kendi sistemimizi öğretiyor; başkalarınınki ise henüz yaşamadığımız arızaları. Bir sonraki yazıda Cloudflare'in Kasım 2025, Google Cloud'un Haziran 2025 ve CrowdStrike'ın Temmuz 2024 kesintilerini şirketlerin kendi postmortem'lerinden okuyor ve ortak pattern'i, global yayılan config'i, Bookstore'un switches.json'unda deniyoruz.