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

Kısaca: Cuma 23:30'da production sunucusu düştüğünde, sıfırdan prosedür uydurmak için zaman yok. Incident response playbook, ihtiyacınız olmadan önce rolleri, iletişimi ve prosedürleri tanımlayan bir belgedir. İşte 5-20 kişilik ekibe uygun minimum playbook.

Olay sırasındaki roller

Net 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, eskale eder. Kod yazmaz.
• Technical lead - problem alanını bilen kişi. Fix'i yazar.
• Communications lead - status page'i, müşterileri, yönetimi günceller. Küçük ekip için IC ile aynı olabilir.
• Scribe - timeline yazar, kim ne yaptı, ne zaman. Post-mortem için kritik.

5 kişiye kadar ekipte tipik olarak IC + Technical lead = 2 rol bölünür, diğerlerini IC alır.

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 rotasyonunda 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). 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 grafikleri, error log'ları 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 en az her 30 dakikada bir status page güncelleme, yeni info olmasa bile. "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 tespitten 5 dakika içinde olmalı. Sebebi bilip bilmediğinizden bağımsız.

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 hotfix daha fazla bug kaynağıdır. Rollback bilinen iyi bir durumu geri yükler ve sabah sakin tanı için zaman verir.

Rollback için sahip olmanız gerekenler:

• 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 kurtaramaz)
• 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 belge yazın:

1. Summary - ne oldu, ne kadar sürdü, kimi etkiledi - 2-3 cümle
2. Timeline - tespitin, anahtar aksiyonların, çözümün kesin zamanları
3. Root cause - neden oldu (teknik neden + prosedürel neden)
4. Impact - etkilenen müşteri sayısı, 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ç - 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 - daha kısa burnout yapar, daha uzun bağlam sürekliliği demektir
• Her zaman birincil + ikincil on-call. Birincil 5 dk içinde tepki vermediğinde ikincil devralır.
• Gece ve hafta sonu paging için tazminat (ekstra ödeme, time-off)
• Aylık "on-call review" - kim sık sık uyandırıldı, 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 →