Bir büyük incident sonrası iki tip ekip görürsünüz:
- Postmortem yazar, birkaç aksiyon açar, sonra “normal işlere” döner.
- Bir hafta boyunca sadece stabilizasyona odaklanır ve aynı sınıf olayın tekrarını zorlaştırır.
Ben ikinci yaklaşımı savunuyorum. Çünkü incident sonrası sistemin “operasyonel borcu” artar: alert gürültüsü, eksik runbook, belirsiz ownership, riskli değişiklik backlog’u… Bunlar temizlenmezse ekip bir sonraki olayda daha yorgun yakalanır.
Stabilizasyon sprint’i ne zaman başlar?
Benim tetikleyicilerim:
- Sev2+ olay yaşandıysa
- Müşteri etkisi olduysa
- “Bu alarm niye çalmadı?” sorusu çıktıysa
- MTTR beklentinin üstündeyse
Amaç suçlu aramak değil; gelecek baskısını azaltmak.
7 günün hedefi: 4 somut çıktı
Sprint sonunda şu dört çıktı yoksa, “stabilizasyon” sadece toplantı kalabalığı olur:
- Alert temizlik listesi (noise azaltma)
- Runbook kapanışları (eksik adımların tamamlanması)
- Top 5 risk azaltma (tekrar olasılığını düşüren değişiklikler)
- İletişim şablonu (bir sonraki olayda daha hızlı mesajlaşma)
Gün gün plan (pratik)
Gün 1 — Triyaj ve ownership
- Incident aksiyonlarını “iş tipi”ne ayır: alert, observability, kapasite, config, süreç
- Her aksiyonun owner’ı ve “done” tanımı olsun
- 30 dakikalık günlük checkpoint planla (uzatma yok)
Gün 2 — Alert gürültüsü temizliği
Hedef: On-call’ın bir sonraki haftası daha sakin olsun.
- Duplicate alert’leri birleştir
- Threshold’ları gerçek baseline’a çek
- “Actionable olmayan” uyarıyı ya kaldır ya da seviyesi düşür
Gün 3 — Runbook kapanışı
Bu gün “dokümantasyon günü” değildir; olay anında kullanılacak net adımlar günüdür.
Runbook kontrol listem:
- İlk 5 dakika: neye bakılır?
- Tek komutla sağlık kontrolü var mı?
- Rollback/prosedür net mi?
- Kimin aranacağı net mi?
Gün 4 — Risk azaltma değişiklikleri (Top 5)
Top 5’i seçerken kriter:
- Etki büyük, maliyet düşük
- Sık tekrar eden hata sınıfını hedefliyor
- Geri dönüşü kolay
Örnekler:
- Rate limit / load shedding guardrail
- Connection pool limit + backpressure
- Canary ring genişletme
- Circuit breaker default’ları
Gün 5 — Gözlemlenebilirlik kapanışları
Bu günün çıktısı:
- “Olayda görmek istediğimiz ama göremediğimiz” 3 panel
- Kritik log alanları (correlation id gibi)
- Trace sampling ayarı (olay anında artırma düğmesi)
Gün 6 — Tatbikat ve iletişim
- 30 dakikalık masa başı tatbikat (aynı senaryo)
- İletişim şablonu: iç ekip, yönetim, müşteri
Gün 7 — Kapanış ve “stabil”
Sprint bittiğinde:
- Açık aksiyon bırakma (kapat ya da yeniden planla)
- “Stabil” kararı için net kriter yaz
- Bir sonraki ay için “önleyici” 2 iş çıkar
Stabilizasyon sprint’i liderlik sınavıdır
Bu sprint, teknik kadar liderlik işidir:
- İnsanları “normal işten” çekip odağa sokmak
- “Nice to have” işleri park etmek
- Risk azaltma işlerini savunmak
Kapanış cümlem: Bir incidentin gerçek maliyeti, olay sırasında değil, olaydan sonra ne yaptığınızla belirlenir.