Lecția 60 a fixat țintele. Lecția 61 a fixat verificările care produc măsurătorile. Lecția asta e despre ce se întâmplă când verificările eșuează. Burn rate-ul SLO-ului urcă. Alerta de prospețime se aude de nouăzeci de minute. Testul de reconciliere a eșuat cu o varianță de patru cifre față de sistemul sursă. Pager-ul inginerului on-call tocmai a sunat. Și acum?
Incident response este al treilea pilon al practicii de fiabilitate, alături de SLO-uri și testarea calității. Este disciplina care transformă alertele în recuperare și recuperarea în îmbunătățire sistemică. Făcută bine, micșorează raza de explozie a eșecurilor și captează învățarea organizațională. Făcută prost, produce cultura de erou, blam, postmortem-uri pe care nu le citește nimeni și uzura lentă a inginerilor on-call.
Framework-ul Google SRE oferă structura canonică (https://sre.google/sre-book/managing-incidents/, consultat 2026-05-01), dar framework-ul singur nu e suficient. Disciplinele culturale și operaționale din jurul lui sunt cele care determină dacă o echipă are incident response real sau doar hârțogărie.
Ce se consideră incident
Un incident este orice rupe (sau amenință să rupă) un SLO de nivel 1. Nu fiecare bug e un incident. Nu fiecare alertă e un incident. Semnalul este „angajamentul de fiabilitate convenit este în pericol dacă nu acționăm curând”.
Pragul contează pentru că incidentele au overhead. On-call-ul e paged. Alți ingineri pot fi trași înăuntru. Se înregistrează un timeline, se scrie un postmortem, se urmăresc action items. Acel overhead este justificat pentru evenimentele care contează și coroziv când e aplicat la evenimente care nu contează.
Două euristici practice. Dacă burn rate-ul SLO-ului peste următoarea oră va consuma mai mult de 1% din bugetul lunar, declară. Dacă eșecul e vizibil pentru clienții externi, declară. Un job ne-critic care s-a re-încercat cu succes, un check de nivel warning, o ruptură în mediul de dev: operațiuni, nu incidente.
Ciclul de viață
Google SRE descrie incident response ca pe un ciclu de viață cu cinci stadii. Fiecare stadiu are un scop, iar săritul peste unul este un mod comun de eșec.
Detection. O alertă se aude. Sursa poate fi o alertă de burn rate SLO, un eșec de test de calitate a datelor, un probe sintetic sau un tichet de la client. Mecanismul de detection contează pentru că timpul dintre eșecul real și alertă este timp de răspuns nerecuperabil. O echipă care află despre incidente din tichete de la clienți are o problemă de monitoring înainte să aibă o problemă de incident response.
Triage. On-call-ul confirmă pager-ul. Prima sarcină nu e să repare; e să decidă. E real sau o alertă falsă? Care e scopul? Cine trebuie implicat? Dacă runbook-ul îl acoperă, on-call-ul continuă. Dacă nu, începe escalation.
Mitigation. Oprește hemoragia. Restaurează SLO-ul. Mitigation rareori este reparația corectă; este acțiunea care aduce sistemul înapoi în banda verde cel mai rapid. Roll back la deploy. Dezactivează feature flag-ul. Redirectează trafic spre o regiune sănătoasă. Promovează o replică. Repornește job-ul eșuat cu sarcină redusă. Mitigation prioritizează restaurarea serviciului peste înțelegerea cauzei.
Resolution. Repară cauza rădăcină pentru ca mitigation-ul să poată fi îndepărtat. Bug-ul de schema-drift este merge-uit. Problema de capacitate primește o creștere permanentă. Resolution poate dura ore, zile sau săptămâni. Unele cauze rădăcină sunt grele (sistemul upstream e deținut de altă echipă; bug-ul e într-o bibliotecă third-party), iar mitigation-ul poate rămâne pe termen nedeterminat. Acceptabil, atâta timp cât gap-ul e urmărit.
Postmortem. Notează ce s-a întâmplat, de ce și ce schimbări previn recurența. Postmortem-ul transformă un singur incident în învățare organizațională. Fără el, fiecare incident este local.
Ciclul este secvențial în spirit dar suprapus în practică. Mitigation deseori începe înainte ca triage să fie complet. Investigația de postmortem deseori rulează în paralel cu resolution. Este o checklist, nu o ordine strictă.
Formatul de runbook
Un runbook e documentul după care întinde mâna on-call-ul când se aude alerta. Are o singură treabă: să ducă un inginer somnoros la 3 dimineața de la „pager-ul tocmai a sunat” la „am aplicat un mitigation și SLO-ul se recuperează” cât mai repede posibil. Formatul contează. Un runbook care e un zid de proză e inutil sub presiune; un runbook care e o checklist cu comenzi copy-paste-abile e aur.
Formatul care funcționează are cinci secțiuni.
Symptom. Cum arată alerta? Ce panouri de dashboard sunt roșii? Ce pattern-uri de log indică acest eșec specific? Exemple concrete, nu abstracțiuni. „SLO-ul customer_etl_freshness e la 95% cu burn rate-ul de 1 oră peste 14x” e util. „Pipeline-ul e lent” nu e. O secțiune de symptom bună permite on-call-ului să confirme în treizeci de secunde că e pe runbook-ul corect.
Likely causes. O listă ordonată a cauzelor istorice ale acestei alerte, cu frecvența. „1. Lag de Kafka upstream (cam 60% din incidente). 2. Regresie de model dbt dintr-un merge recent (cam 25%). 3. Contenție pe warehouse-ul Snowflake (cam 10%). 4. Necunoscut (cam 5%).” Ordonarea ajută on-call-ul să investigheze cauzele cu probabilitate mare mai întâi în loc să parcurgă posibilitățile alfabetic.
Mitigation steps. Pentru fiecare cauză probabilă, acțiunea care mitigează. Comenzi copy-paste-abile. Puncte de decizie unde se cere judecată, cu criteriile explicitate. „Dacă lag-ul consumatorului Kafka depășește 1 milion de mesaje, scalează grupul de consumatori: kubectl scale deploy customer-etl-consumer --replicas=8. Verifică dacă lag-ul începe să scadă în 5 minute.” Un pas de mitigation care cere traducerea prozei într-o comandă la 3 dimineața deja a eșuat.
Escalation paths. Pe cine să paged-ești dacă runbook-ul nu rezolvă incidentul, în ce ordine, cu ce context. „Dacă scalarea consumatorului nu se recuperează în 15 minute, page-uiește team lead-ul platformei de date. Dacă warehouse-ul e cauza suspectată, page-uiește on-call-ul de warehouse.” Escalation paths lipsesc deseori din runbook-uri, iar rezultatul sunt ingineri on-call care se zbat singuri dincolo de punctul în care ajutorul ar fi sosit mai repede.
Last reviewed. O dată și un proprietar. Runbook-urile învechite sunt mai rele decât niciun runbook pentru că conving on-call-ul să urmeze sfaturi care nu se mai aplică. Disciplina care ține runbook-urile proaspete este să le revizuiești după fiecare incident care le-a atins, și pe un program trimestrial chiar dacă niciun incident nu le-a atins. Un runbook revizuit ultima dată acum optsprezece luni este presupus greșit până la verificare.
Runbook-ul trăiește lângă cod, în același repository unde e definit serviciul. Inginerii de operațiuni care citesc runbook-ul ar trebui să poată citi codul. Dezvoltatorii care scriu codul ar trebui să actualizeze runbook-ul în același PR. Când runbook-urile trăiesc într-un wiki separat, derivează; când trăiesc lângă cod, drift-ul e vizibil în code review.
Postmortem-ul blameless
Postmortem-ul e locul unde trăiește partea culturală a incident response, și unde majoritatea organizațiilor o nimeresc greșit. Principiul e simplu de enunțat și greu de trăit: cauza rădăcină a unui incident nu este niciodată o persoană.
Mereu e tentant să identifici omul din lanț. Inginerul care a scris bug-ul. Reviewer-ul care a aprobat PR-ul. On-call-ul care a luat nouăzeci de minute să mitigheze. Product manager-ul care a insistat pe deploy înaintea weekend-ului de sărbători. Indicatul oricăreia dintre aceste persoane drept „cauza” este calea de cea mai mică rezistență, și e calea care distruge cultura de fiabilitate, pentru că următoarea persoană care face o greșeală o va ascunde în loc s-o raporteze, iar greșelile ascunse devin incidente mai mari.
Postmortem-ul blameless reformulează întrebarea. Cauza rădăcină nu este „inginerul a împins cod prost”. Cauza rădăcină este „sistemul a permis ca un cod prost să ajungă în producție fără să fie prins”. Acea reformulare produce action items utile: teste mai bune, CI mai rapid, deploy-uri canary, tooling de code review mai bun, PR-uri mai mici. Indicatul inginerului nu produce action items utile; produce o echipă mai tăcută și incidente mai rele.
Formatul care funcționează pentru postmortem-uri are șase secțiuni.
Summary. Două sau trei propoziții pe care le-ar putea citi un executive. Ce s-a întâmplat, când, care a fost impactul asupra utilizatorilor. Sumarul este partea pe care o citesc majoritatea oamenilor; restul există pentru ingineri și analiști care au nevoie de detalii.
Timeline. Log minut-cu-minut sau oră-cu-oră a ce s-a întâmplat, cu timestamp-uri și oamenii sau sistemele implicate. Timeline-ul e construit din log-urile de chat, timestamp-uri de alertă, înregistrări de deploy și memoria umană; este partea cea mai intensă în muncă a postmortem-ului și cea mai valoroasă, pentru că forțează analiza să fie specifică în loc de vagă.
Root cause analysis. Ce condiții subiacente au permis incidentul? Tehnica „cinci de ce” funcționează aici, dar disciplina e să continui să întrebi de ce până când răspunsul e o proprietate a sistemului, nu a unei persoane. De ce a ajuns bug-ul în producție? A trecut prin code review. De ce review-ul l-a ratat? Diff-ul avea 2.000 de linii. De ce avea diff-ul 2.000 de linii? Echipa nu are normă pentru mărimea PR-ului. Action item-ul este norma de mărime a PR-ului, nu „fii mai atent la review”.
Impact. Cine a fost afectat, pentru cât timp, cu ce consecință de business? Cuantificat unde e posibil: dashboard-ul a fost greșit timp de trei ore, afectând luarea deciziilor în două echipe regionale; SLO-ul a consumat 40% din bugetul lunar de erori. Încadrarea impactului ajută la prioritizarea action items: un incident cu impact mare justifică prevenție mai scumpă decât unul cu impact mic.
Action items. Specifice, deținute, cu termen. „Vom îmbunătăți procesele noastre” nu este un action item. „Vom adăuga o alertă de drift de count de rânduri cu prag de 10% la pipeline-ul customer_etl până la 2026-04-15, deținută de Maria” este un action item. Acțiunile care ies din postmortem-uri sunt produsul efectiv al practicii de incident response; fără ele, postmortem-ul e un exercițiu de scriere.
Lessons learned. Ce știe echipa acum ce nu știa înainte de incident? Uneori lecția e operațională („rotația on-call trebuie să includă pe cineva cu expertiză de warehouse”). Uneori arhitecturală („cuplajul dintre aceste două servicii e mai strâns decât am presupus”). Uneori culturală („trebuie să fim dispuși să declarăm incidente mai devreme”). Lessons learned sunt firul care conectează postmortem-ul ăsta de cele viitoare.
Cultura blameless nu poate fi declarată. Trebuie modelată, în special de leadership. Prima dată când numele unui inginer senior apare într-un timeline (și inginerii seniori cauzează incidente la aceeași rată ca cei juniori, pentru că sistemele subiacente sunt la fel de failibile de la tastatura oricui), echipa privește ce se întâmplă. Dacă numele e tratat ca dată, la fel ca al oricui altcuiva, cultura se ține. Dacă inginerul senior e trecut sub tăcere sau scuzat, cultura e performativă și toată lumea știe.
Disciplina de publicare contează și ea. Postmortem-urile sunt citite de-a lungul organizației. Alte echipe învață din analiză. Inginerii noi citesc postmortem-uri trecute în onboarding ca să înțeleagă cum eșuează sistemul. Postmortem-urile private capturează învățare locală; cele publicate capturează învățare colectivă.
Discipline de on-call
Incident response stă peste o rotație de on-call, iar rotația are propriile discipline care determină dacă inginerii rămân sănătoși.
Pager hygiene. Fiecare alertă care se aude trebuie să fie acționabilă. Alertele fără acțiune („coada e uneori adâncă, habar n-am ce să fac”) antrenează on-call-ul să ignore pager-ul, iar următorul incident real e întârziat pentru că on-call-ul a învățat să nu aibă încredere în alerte. Revizuiește fiecare page după faptă: a fost acționabilă? Dacă nu, tunează alerta sau șterge-o.
Hand-off. On-call-ul ieșind face brief-ul on-call-ului intrând: probleme deschise, incidente recente, investigații în curs, schimbări de runbook. Cincisprezece minute. Fără el, on-call-ul intrând intră rece și primul incident durează mai mult pentru că încă încarcă context.
Compensation. On-call este muncă reală, inclusiv munca de a fi disponibil în afara orelor de program. Echipele care pretind că on-call e un adaos gratuit își văd inginerii on-call plecând sau ardându-și. Compensarea poate fi timp liber, plată suplimentară sau ambele, dar trebuie să fie explicită.
Lungimea și frecvența rotației. O săptămână este rotația comună, două săptămâni maximum înainte să se instaleze oboseala. Rotația ar trebui să fie suficient de scurtă încât un inginer să fie on-call o dată la patru până la șase săptămâni. Echipele mai mici trebuie să facă compromisuri fie pe lungimea rotației, fie pe mărimea echipei (angajând sau extinzând bazinul).
Ciclul de viață într-o diagramă
flowchart TD
A[Alert fires] --> B[Detection]
B --> C[Triage: real or false?]
C -->|False| D[Tune alert, log]
C -->|Real| E[Mitigation: stop the bleeding]
E --> F[SLO recovering?]
F -->|No| G[Escalate]
G --> E
F -->|Yes| H[Resolution: fix root cause]
H --> I[Postmortem]
I --> J[Action items tracked]
J --> K[Runbook and tests updated]
K --> L[Next time: faster response or no incident]Săgeata de la K înapoi la detection (omisă pentru claritate) este bucla care face din incident response un sistem care învață. Fiecare incident produce actualizări: alerte mai bune, runbook-uri mai bune, teste mai bune, arhitectură mai bună. Următorul eșec similar fie nu se întâmplă, fie se întâmplă cu un răspuns mai rapid. Incidentele nu se opresc, dar costul per incident scade.
Cele trei lecții ale modulului ăstuia formează o buclă completă. SLO-urile definesc ce înseamnă fiabil. Testarea calității îl măsoară continuu. Incident response gestionează momentele când măsurarea spune că SLO-ul e în pericol. Modulul 8 continuă cu infrastructura de monitoring și disciplinele de securitate și confidențialitate care se suprapun cu fiabilitatea. O echipă cu SLO-uri, teste de calitate și o practică reală de incident response are aparatul de bază al unei platforme de date de producție; tot restul e stratificare.