Küçük ve orta ekipler için incident response playbook

Olay sırasındaki roller

Net şekilde dağıtılmış roller kaosu ortadan kaldırır. Küçük bir ekibin bile en azından şu rollere ihtiyacı vardır:

• Incident Commander (IC) - olayı yönetir, karar verir ve eskale eder. Kendisi kod yazmaz.
• Technical lead - problem alanını bilen kişi. Fix'i yazar.
• Communications lead - status page'i günceller, müşterileri ve yönetimi bilgilendirir. Küçük bir ekipte IC ile aynı kişi olabilir.
• Scribe - timeline'ı tutar: kim, ne ve ne zaman yaptı. Post-mortem için kritik bir kaynak.

5 kişiye kadar olan ekipte genellikle IC ve Technical lead ayrılır, diğer rolleri IC üstlenir.

Severity seviyeleri

Önceden 3-4 ciddiyet seviyesi tanımlayın:

• SEV1 (Critical) - ana servis tamamen kullanılamaz. Hemen tepki verilir, gece de paging.
• SEV2 (Major) - önemli degradasyon (feature'ların bir kısmı, bazı kullanıcılar). Çalışma saatlerinde 30 dk içinde tepki, dışında 1 saat içinde.
• SEV3 (Minor) - küçük etki, workaround var. Sonraki iş gününe kadar tepki.
• SEV4 (Cosmetic) - user-facing etki yok, normal kuyruğa gider.

SEV1 prosedürü: ilk 15 dakika

1. 00:00 - Tespit. Uyarı monitoring'ten veya müşteriden gelir. On-call rotasyonundan biri sorunun gerçek olduğunu onaylar.
2. 00:02 - IC aktivasyonu. Adanmış bir iletişim kanalı açılır (Slack #incident-N veya Discord) ve Technical lead aranır.
3. 00:05 - İlk status update. Halka açık status page'de: "Investigating reports of [sorun]." Bilmesi gereken iç çalışanlara email.
4. 00:10 - Initial diagnostics. Son deploy'ları, monitoring grafiklerini ve error log'larını kontrol edin. Son 30-60 dakikada ne değişti?
5. 00:15 - Karar: rollback, hotfix veya workaround? Hemen net değilse, IC eskale eder veya daha fazla mühendis çağırır.

İletişim: "5 + 30" kuralı

SEV1 sırasında status page'i, yeni bilgi olmasa bile en az her 30 dakikada bir güncelleyin. "Hâlâ araştırıyoruz, ETA hâlâ bilinmiyor" sessizlikten daha iyi bir update'tir - müşteriler en azından birinin sorun üzerinde çalıştığını bilir.

İlk update, sebebi bilip bilmediğinizden bağımsız olarak, tespitten 5 dakika içinde gelmelidir.

Varsayılan olarak rollback

Bir deploy'dan kısa süre sonra başlayan SEV1'de rollback ilk seçimdir, hotfix değil. Gece baskı altında yazılan hotfix daha fazla bug kaynağıdır. Rollback bilinen iyi bir durumu geri yükler ve sabah sakin bir tanı için zaman verir.

Rollback'in ön koşulu:

• Deployment versiyonlama (Docker tag'leri, Git tag'leri, deployment artefakt)
• Backwards compatible database migration'lar (yeni sürüm bir sütunu drop ederse, eski sürüm onu geri getiremez)
• Belgelendirilmiş rollback prosedürü (komutlar, ne kadar sürer, kim çalıştırabilir)

48 saat içinde post-mortem

Her SEV1/SEV2 olayından sonra şu yapıda bir belge yazın:

1. Summary - ne oldu, ne kadar sürdü, kimi etkiledi - 2-3 cümle
2. Timeline - tespitin, anahtar aksiyonların ve çözümün kesin zamanları
3. Root cause - neden oldu (teknik ve prosedürel neden)
4. Impact - etkilenen müşteri sayısı ve business etkisi
5. What went well - iyi yaptığımız şey (ekibi takdir et)
6. What went wrong - nerede zaman kaybettik
7. Action items - owner ve deadline ile somut görevler ("daha iyi test et" değil, "payment flow için integration test 14 gün içinde ekle, owner: X" daha iyi)

Blameless post-mortem kuralı: Suçlu aramıyorsunuz, sistemik bir zayıflık arıyorsunuz. "John kötü sürüm deploy etti" yanlış sonuçtur - doğru olan "deploy süreci, tam rollout'tan önce bug'ı yakalayacak canary fazını içermiyordu".

On-call rotasyonu

24/7 ürünü olan ekip için:

• Haftalık rotasyonlar ideal dengedir - daha kısa olanlar tükenmişliğe yol açar, daha uzun olanlar birincil on-call'ı aşırı yükler
• Her zaman birincil + ikincil on-call bulundurun. Birincil 5 dk içinde tepki vermediğinde ikincil devralır.
• Gece ve hafta sonu paging'i telafi edin (ek ödeme veya izin)
• Aylık "on-call review" yapın - kim en sık uyandırıldı ve ne otomatikleştirilebilir

Araçlar

• Monitoring (ePulz.io, Datadog, New Relic) - tespit + alerting
• Paging (PagerDuty, Opsgenie, Better Stack) - eskalasyon, rotasyon, SMS/ses
• Status page (kendi, ePulz.io, Statuspage.io) - harici iletişim
• Runbook hosting (Notion, GitHub Wiki, internal docs) - playbook ve runbook'lar
• Postmortem şablonu (Confluence, Notion template) - standartlaştırma

Sonuç

Incident response baskı altında doğaçlama yapılamaz. Bir playbook yazmak için yatırılan 30 dakika ilk büyük kesintide geri döner - daha az kaos, daha kısa MTTR, müşterilerle daha iyi iletişim ve ne yapacağını bilen bir ekip.

Otomatik tespitle başlayın

ePulz.io incident response'un ilk dakikalarını çözer: e-mail, Telegram ve Slack / Discord / PagerDuty'ye webhook ile tespit + alerting.

İzlemeyi başlat →