Major incident (SEV-1/SEV-0) yaşandığında herkes “teknik çözüm”e odaklanmak ister. Ama büyük kesintilerde en hızlı kaybedilen şey çoğu zaman koordinasyondur:
- Aynı işi iki ekip paralel yapar
- Yanlış hipotez etrafında toplanılır
- Müşteri iletişimi gecikir
- Riskli değişiklikler “hızlıca” prod’e girer
Bu yazıda; Incident Commander (IC) rolü, iletişim ritmi ve runbook pratikleriyle, kesintilerde MTTR’ı düşürmek için sahada işe yarayan yaklaşımı anlatıyorum.
Incident Commander ne yapar?
IC’nin görevi “en iyi troubleshooting yapan kişi olmak” değildir. IC’nin görevi:
- Tek bir durum resmi (single source of truth) oluşturmak
- Öncelikleri ve kararları netleştirmek
- İletişimi yönetmek (iç/dış)
- Riskli değişiklikleri kontrol etmek
IC teknik de olabilir ama “debugger” rolünü başka birine devrettiğinde daha etkili olur.
Rol dağılımı: IC + Tech Lead + Comms
Pratikte üç rol major incident’i çok rahatlatır:
- IC: Koordinasyon, karar, zaman çizelgesi
- Tech Lead: Teknik yön, hipotez, çözüm planı
- Comms Lead: İç/dış iletişim, status page, müşteri mesajları
Küçük ekipte tek kişi iki rolü taşıyabilir; ama üç rolün sorumlulukları ayrışmalı.
10 dakikalık ritim: “Durum güncelleme” alışkanlığı
Olay anında zaman algısı bozulur. IC’nin en güçlü aracı ritimdir.
Benim önerim: her 10 dakikada bir kısa update:
- Şu anki semptom (müşteri etkisi)
- En güçlü hipotez (ve neden)
- Yapılan aksiyonlar (son 10 dk)
- Sonraki 10 dk planı
- Riskli değişiklik var mı?
Bu ritim, ekiplerin “aynı odada” kalmasını sağlar.
Runbook: “Komut listesi” değil “karar ağacı”
Kötü runbook; 200 satır komut, kimse okumaz. İyi runbook; karar ağacıdır:
- Semptom → muhtemel nedenler
- Hangi metrik/log ile doğrularım?
- “Güvenli” aksiyonlar (geri alınabilir)
- “Riskli” aksiyonlar (IC onayı şart)
Runbook’un hedefi: en iyi mühendis gibi düşünmek değil; ortalama bir on-call mühendisin doğru yola girmesini sağlamak.
Değişiklik kontrolü: Incident sırasında “deploy” nasıl yönetilir?
Incident sırasında değişiklik yapmak kaçınılmaz olabilir. Ama kontrol yoksa risk büyür.
Benim sahada kullandığım basit kural seti:
- Her deploy bir “hipotez”e bağlı olmalı (neden çözsün?)
- Aynı anda birden fazla büyük değişiklik yok
- Rollback hazır değilse deploy yok
- IC onayı olmadan prod’de “kalıcı” değişiklik yok
İletişim: Status page “PR” gibi yazılır
Status update, sadece “down” demek değildir. İyi bir status mesajı:
- Etkiyi net söyler (hangi kullanıcılar, hangi bölge)
- Ne zaman başladı (tahmini)
- Geçici çözüm var mı?
- Bir sonraki güncelleme zamanı
İç iletişimde de aynı disiplin: Slack mesajları değil, timeline tutun.
Postmortem: Suçlu aramak değil, sistem düzeltmek
Major incident sonrası postmortem’in hedefi:
- Root cause (teknik + süreç)
- Detection gap (neden geç fark ettik?)
- Mitigation gap (neden yavaş çözdük?)
- Action item’lar (owner + tarih)
Burada en değerli sonuç: Runbook ve alarm setinin güncellenmesi.
Kapanış: Koordinasyon teknik bir yetkinliktir
Major incident’te “en iyi engineer” kazanmaz; en iyi koordinasyon kazanır.
Başlamak için küçük bir adım:
- IC rolünü ve 10 dakikalık ritmi standartlaştırın
- Her kritik servis için 1 sayfalık karar ağacı runbook çıkarın
- Riskli değişiklikler için “IC onayı” kuralı koyun