Ce faci ca să previi ca același tip de incident să se întâmple a doua oară?

Question

Accepted Answer

Rulează un **postmortem fără vină (blameless)** care găsește cauza sistemică, apoi convertește-o în acțiuni **concrete, asumate și urmărite** — și verifică să se livreze cu adevărat. Scopul nu e să găsești pe cine să blamezi; e să schimbi sistemul astfel încât aceeași clasă de eșec să devină imposibilă sau auto-detectabilă.

## Bucla de bază

1. **Postmortem fără vină.** Construiește o cronologie sinceră: ce s-a întâmplat, când am detectat, cum am răspuns, care a fost impactul. Vina ucide adevărul de care ai nevoie.
2. **Sapă spre cauza sistemică**, nu declanșatorul. „Un inginer a împins un config defectuos” e un declanșator; „nu exista validare sau rollout etapizat pentru config-uri” e cauza. Folosește **Cele Cinci De Ce**, dar oprește-te la sistem, niciodată la o persoană.
3. **Generează straturi de prevenție**, nu o singură remediere:
   - **Previne** — fă eșecul imposibil (validare, tipuri, garduri de protecție).
   - **Detectează** — prinde-l mai devreme (alerte, SLO-uri, verificări sintetice).
   - **Mitighează** — limitează raza de explozie (rollback, flag-uri, circuit breakers).
4. **Alocă responsabili și termene.** O acțiune fără responsabil e o dorință. Urmărește-le ca pe muncă reală în backlog.
5. **Verifică și închide bucla.** S-a livrat remedierea? Ar fi prins-o pe cea originală? S-au îmbunătățit cu adevărat MTTR și detectarea?

## Compromisuri și capcane

- **Postmortem-uri care produc documente, nu schimbări** — cel mai frecvent eșec. Lipsa urmăririi înseamnă că vei reîntâlni același incident.
- **Supra-repararea simptomului specific** în timp ce clasa de bug rămâne deschisă. Repară categoria, nu doar această instanță.
- **Oboseală de alerte** din adăugarea de detectare fără reglare; alertele zgomotoase sunt ignorate și următorul incident scapă.
- **Cultura vinei** împinge raportarea în subteran; pierzi aproape-incidentele care sunt cele mai ieftine lecții ale tale.
- Tratează **incidentele repetate ca un semnal de eșec de proces**, nu ghinion — urmărește recurența ca metrică.

## De ce contează

Incidentele sunt taxă de școlarizare pe care ai plătit-o deja; singura risipă e să nu înveți din ele. O echipă care previne sistematic recurența devine mai fiabilă în fiecare trimestru, în timp ce o echipă care doar stinge incendii retrăiește aceleași căderi la nesfârșit. Construirea acestei bucle de învățare — și a siguranței de a fi sincer în ea — e unul dintre cele mai durabile lucruri pe care le poate lăsa în urmă un Tech Lead.