Cum construiești un playbook de incident response care funcționează la 3 dimineața

Monitorizarea se face roșie. PagerDuty sună. Este 3:14 dimineața și tu ești inginerul on-call. Ce faci mai întâi?

Dacă răspunsul este „depinde” sau „stai să mă gândesc” — nu ai un playbook, ai o strategie de incident response bazată pe speranță. Hai să rezolvăm asta.

De ce contează playbook-urile

În timpul unui incident, capacitatea de gândire este afectată. Stresul, lipsa somnului și presiunea impactului asupra clienților fac dificilă gândirea limpede. Un playbook elimină nevoia de a te gândi la proces, ca să te poți concentra pe problemă.

Cele mai bune playbook-uri au trei calități:

1. Acționabile — Fiecare pas este o acțiune concretă, nu o sugestie vagă
2. Accesibile — Un singur click de la alertă la playbook
3. Actuale — Actualizate după fiecare incident (altfel se degradează)

Niveluri de severitate ale incidentelor

Folosim patru niveluri de severitate. Fiecare alertă corespunde unuia:

Nivel	Criterii	Timp de răspuns	Notificare
SEV1	Întrerupere vizibilă pentru clienți, risc de pierdere de date	Imediat	Trezește pe toată lumea
SEV2	Serviciu degradat, întrerupere parțială	15 min	On-call + backup
SEV3	Sistem necritic căzut, fără impact asupra clienților	1 oră	Doar on-call
SEV4	Problemă minoră, informativă	Următoarea zi lucrătoare	Ticket

Decizia-cheie: cine este trezit? Escaladarea excesivă produce oboseală de alerte. Escaladarea insuficientă prelungește întreruperile. Noi preferăm să escaladăm în exces la prima apariție, apoi ajustăm.

Cronologia unui incident

Fiecare incident urmează același ciclu de viață:

Detection → Triage → Mitigation → Resolution → Post-mortem
   │          │          │             │            │
   │          │          │             │            └── Within 48 hours
   │          │          │             └── Root cause fix
   │          │          └── Stop the bleeding (even if ugly)
   │          └── What's broken? Who's affected? What severity?
   └── Alert fires or customer reports

Faza 1: Detecție (0-2 minute)

Monitorizarea automată ar trebui să prindă peste 90% dintre incidente înainte ca clienții să observe. Stack-ul nostru de detecție:

• Prometheus — Metrici + reguli de alertare
• Alertmanager — Deduplicare, rutare, silențiere
• PagerDuty — Escaladare + programare on-call
• Verificări de uptime — Monitorizare sintetică externă din mai multe regiuni

Fiecare alertă include:

• Ce este stricat (numele serviciului, componenta)
• Link către dashboard-ul Grafana relevant
• Link către playbook-ul pentru acea alertă
• Modificări recente (ultimele 3 deploy-uri)

Faza 2: Triaj (2-10 minute)

Prima sarcină a inginerului on-call nu este să rezolve problema. Este să evalueze:

1. Care este impactul asupra clienților? Verifică ratele de erori, percentilele de latență, tichetele de suport
2. Care este raza de impact? Un client, o regiune sau toată lumea?
3. Este o problemă cunoscută? Verifică runbook-ul, incidentele recente, canalul #incidents
4. Atribuie severitatea — Aceasta determină cine mai este chemat

Faza 3: Mitigare (10-60 minute)

Mitigarea nu este același lucru cu rezolvarea. Mitigarea înseamnă a opri hemoragia:

• Rollback la ultimul deploy
• Scalează dacă este o problemă de capacitate
• Failover către o regiune sau instanță de backup
• Comută un feature flag pentru a dezactiva funcționalitatea defectă
• Blochează traficul dacă este un DDoS sau abuz

Scopul: reducerea impactului asupra clienților cât mai rapid posibil. Un fix improvizat care restabilește serviciul în 5 minute bate un fix elegant care durează 2 ore.

Faza 4: Rezolvare

Odată ce incidentul a fost mitigat, fix-ul corect poate fi făcut în programul de lucru, cu mintea limpede. Acesta poate fi:

• Un fix în cod pentru bug-ul care a cauzat incidentul
• O modificare de configurare care previne repetarea
• O schimbare de infrastructură (mai multă capacitate, redundanță mai bună)

Faza 5: Post-mortem

Aici eșuează majoritatea echipelor. Fie sar peste post-mortem-uri, fie le transformă în ședințe de căutat vinovați.

Template-ul nostru de post-mortem:

## Incident: [Title]
**Date:** [Date]  **Duration:** [X minutes]  **Severity:** [SEV1-4]

## Summary
[2-3 sentences: what happened, who was affected, what was the impact]

## Timeline
[Minute-by-minute account of detection, triage, mitigation, resolution]

## Root Cause
[Technical root cause — not "human error"]

## Contributing Factors
[What made this worse? Missing monitoring? No runbook? Slow rollback?]

## Action Items
| Action | Owner | Due Date | Status |
|--------|-------|----------|--------|
| [Specific, measurable action] | [Name] | [Date] | Open |

## Lessons Learned
[What did we learn? What will we do differently?]

Blameless este nenegociabil. Dacă cineva se teme să spună „am rulat comanda greșită”, va ascunde informații care ar putea preveni următorul incident.

Automatizarea răspunsului

Runbook-urile manuale sunt un punct de plecare. Următorul nivel este automatizarea răspunsurilor frecvente:

• Auto-scaling la vârfuri de trafic
• Auto-rollback când ratele de erori depășesc pragurile după deploy
• Auto-failover când health check-urile eșuează
• Self-healing cu probe-uri de liveness/readiness în Kubernetes

Ne-am redus timpul mediu până la mitigare (MTTM) de la 23 de minute la 4 minute automatizând cele mai frecvente tipuri de incidente.

Tooling-ul pe care îl folosim

• PagerDuty — Alertare și escaladare
• Grafana — Dashboard-uri și investigație
• Loki — Explorarea log-urilor în timpul incidentelor
• Teleport — Acces securizat la producție (cu audit trail)
• GitHub Issues — Urmărirea post-mortem-urilor și a acțiunilor de făcut

Începe simplu

Nu ai nevoie de toate acestea din prima zi. Începe cu:

1. Definește nivelurile de severitate
2. Scrie un playbook pentru primele 3 alerte ca frecvență
3. Fă un post-mortem după fiecare SEV1/SEV2

Playbook-ul se îmbunătățește cu fiecare incident. Cel mai prost playbook este cel pe care nu l-ai scris niciodată. Vorbește cu noi dacă vrei ajutor în construirea practicii tale de incident response.