Runbook kelimesi çoğu ekipte ya “hiç yok”tur ya da “kimsenin okumadığı uzun doküman”dır. Oysa iyi runbook’un hedefi bilgi depolamak değil, incident anında karar üretmektir.
Benim sahada en çok iş yapan yaklaşım şu: Runbook’u “Minimum Viable” seviyeye indir, ama içine mutlaka karar eşikleri koy. Aksi hâlde runbook, kronoloji yazıp kimseyi kurtarmayan bir metne dönüşür.
1) Minimum Viable Runbook (MVR) nedir?
MVR şu sorulara 3 dakikada cevap veriyorsa yeterlidir:
- Bu alarm neyi ifade ediyor? (etki)
- İlk 5 dakikada hangi kanıt toplanır? (triage)
- Hangi noktada hangi aksiyon alınır? (eşik/karar)
- Müdahale sonrası neyle doğrularız? (verification)
- Yanlış gittiğinde nasıl geri alırız? (rollback)
2) Şablon: tek sayfada runbook
Aşağıdaki şablonu olduğu gibi kopyalayabilirsin:
Başlık
- Servis / bileşen adı
- Alarm adı ve seviyesi (P1/P2)
- Sahip ekip ve escalation kanalı
Etki tanımı
- Kullanıcı etkisi (ne bozulur?)
- Blast radius (hangi bölgeler/tenant’lar?)
- SLO/SLI (hangi metrik ihlal olur?)
Triage (0–5 dakika)
- İlk bakılacak dashboard link’leri
- İlk bakılacak log sorguları
- Kanıt listesi (mutlaka topla)
Karar eşikleri (en kritik bölüm)
Örnek:
- Eğer hata oranı > %5 ve latency p95 > 2s ise → trafik azalt
- Eğer DB connection wait > 1s ise → retry’ı düşür ve concurrency limit uygula
- Eğer deploy sonrası başladıysa → rollback değerlendirmesi
Mitigasyon merdiveni (düşük risk → yüksek risk)
- Trafiği düşür (rate limit / degrade)
- Cache/queue ile baskıyı azalt
- Rollback / feature flag kapat
- Failover / bölge izolasyonu
Doğrulama
- Hangi metrik normale dönünce “incident bitti” denir?
- Ne kadar süre gözlem yapılır? (örn. 15 dk)
Rollback
- Tek komut / tek PR / tek toggle
- Geri dönüş sonrası doğrulama
İletişim
- Status update periyodu (örn. 15 dk)
- Kimin bilgileneceği (iç/dış)
3) Karar noktalarını netleştirme: ekipleri sakinleştiren şey budur
Runbook’un “liderlik” tarafı burada başlar: belirsizliği azaltmak.
Pratik karar soruları:
- “Şu an müşteri kaybı var mı, yoksa sadece sinyal mi?”
- “Bu değişiklik geri alınırsa daha büyük risk üretir mi?”
- “Trafiği azaltmak hangi kullanıcıyı etkiler, hangisini korur?”
En yaygın hata:
- Her şeyi aynı anda denemek.
En iyi refleks:
- Bir hipotez → bir müdahale → bir doğrulama döngüsü.
4) Runbook’u yaşat: tatbikat ve güncelleme ritmi
MVR’in ölmemesi için iki basit kural:
- Her P1/P2 sonrası runbook’a 10 dakikalık “patch” yapılır.
- Ayda bir 30 dakikalık küçük tatbikat yapılır (sadece triage bile yeter).
5) Kapanış: runbook, operasyonel sakinlik üretir
Kurumların olgunluğu, en iyi günlerinde değil en kötü günlerinde ölçülür. Incident anında runbook’un amacı kahraman çıkarmak değil; ekibin aynı dili konuşmasını, aynı eşiklerle karar vermesini ve daha az panikle daha hızlı toparlanmasını sağlamaktır.