Producția arde în dezvoltare — ce este, cauze și algoritm de acțiune

Ce înseamnă „producția arde” și ce tipuri de defecțiuni există

Expresia „producția arde” (production is on fire, everything is down) descrie o situație în care mediul de producție funcționează incorect, iar acest lucru a afectat utilizatorii. Defecțiunea se poate manifesta ca indisponibilitate totală a aplicației (blank screen, eroare 502), indisponibilitate parțială (modulul de plată nu funcționează, dar celelalte funcții sunt disponibile) sau degradare a performanței (încărcare extrem de lentă). Severity incidentului este determinată de procentul utilizatorilor afectați și durata defecțiunii.

Conform Atlassian Statuspage (2025), downtime-ul mediu pentru aplicațiile mobile în 2024 a fost de 27 de minute per incident. Cele mai frecvente cauze: regresie de cod după deploy (34%), căderea furnizorului de cloud (22%), probleme cu baza de date (18%), erori de configurare (15%) și atacuri DDoS (11%). Concluzia cheie: majoritatea defecțiunilor sunt legate de modificări făcute chiar de echipă, nu de factori externi.

Este important să se facă distincția între crash (căderea aplicației pe client) și backend outage (indisponibilitatea serverului). Crash-ul se remediază de obicei printr-un hotfix al codului client, iar backend outage-ul prin modificări de infrastructură sau redeploy al serviciului. Metrici de urmărire: pentru client — crash-free rate, pentru server — error rate 5xx și p95 latency. APM (Application Performance Monitoring) — Sentry, New Relic, Datadog — ajută la identificarea rapidă a tipului de defecțiune.

Nivelurile de severity ale incidentelor: P0, P1, P2 și criterii de clasificare

Clasificarea unitară a severity este baza unei reacții rapide. Fără ea, echipa pierde timp discutând „cât de urgent este” în loc să acționeze. Scala clasică: P0 (critical) — aplicația este complet indisponibilă sau datele utilizatorilor sunt compromise, timp de reacție — imediat; P1 (high) — funcționalitatea critică nu funcționează pentru 50%+ dintre utilizatori, timp de reacție — 15 minute; P2 (medium) — funcționalitatea necritică este indisponibilă pentru o parte dintre utilizatori, timp de reacție — 1 oră.

P0 necesită escaladare imediată: inginerul de serviciu întrerupe orice lucru curent și se ocupă de incident. Dacă după 10 minute problema nu este rezolvată — intervine tech lead-ul. Dacă după 30 de minute — escaladare către engineering manager. Pentru incidentele P0 este permisă încălcarea oricăror procese: hotfix fără code review complet, deploy direct în producție, ignorarea regulilor de branch protection. Emergency override trebuie să fie agreat în prealabil la nivelul echipei.

Tabel severity

Este extrem de important să nu greșești severity în jos. P0 + P1 clasificate ca P2 duc la o reacție întârziată și creșterea downtime-ului. Regulă: dacă ai îndoieli — setează P0. Over-classification este mai bună decât under-classification: mai bine să convoace o întâlnire în plus decât să pierzi o oră de recuperare.

Primele 10 minute: algoritmul de acțiune la o defecțiune

Timer starts: din momentul în care sosește alerta sau mesajul de la utilizator. Primele 10 minute — cele mai importante. Algoritm: 1) confirm the issue — asigură-te că problema este reală (nu un fals alarm); 2) stop the bleeding — reduce imediat impactul (rollback, feature toggle, blocare endpoint); 3) communicate — scrie pe canalul general #incident statusul: ce s-a întâmplat, severity, ce se face. Primele 10 minute nu se pierd pe analiza cauzei principale.

Paralel cu oprirea sângerării, un inginer începe diagnosticarea, al doilea — comunicarea. Canale de comunicare: Slack #incident channel (pentru echipă), pagină de status (pentru utilizatori), email/SMS escaladare (pentru management). La fiecare 15 minute — actualizare de status cu informații: ce se știe, ce se face, ETA de recuperare. Status page (StatuPage, Statuspal) afișează uptime-ul și istoricul incidentelor pentru utilizatorii externi.

Cum să oprești sângerarea: rollback, feature toggle și hotfix

Prima și cea mai importantă regulă: nu încerca să repari problema în producție. Dacă noul release a cauzat defecțiunea — rollback la versiunea stabilă anterioară. Dacă defecțiunea este cauzată de o funcție specifică dezactivată printr-un feature toggle — doar dezactivează toggle-ul. Dacă nici rollback, nici toggle nu sunt disponibile — hotfix cu un diff minim. Rollback — cea mai sigură opțiune, pentru că revenim la o stare care a funcționat deja.

Feature toggle (aka feature flag) — un instrument puternic pentru stop-the-bleeding fără deploy. Dacă modulul de plată a căzut, dar este dezactivat printr-un toggle — utilizatorii pur și simplu nu văd butonul de plată, nu primesc un ecran de eroare. Toggle-ul nu necesită construirea unui build, nu necesită review din magazin, se activează în câteva secunde. Fiecare funcție critică ar trebui să fie sub un feature toggle cu posibilitatea de dezactivare la nivel de server (remote config). Feature flag — prima linie de apărare.

Dacă rollback-ul este imposibil (de exemplu, din cauza unei migrări ireversibile a BD) și toggle-ul nu este prevăzut — ultima soluție: hotfix cu o remediere minimă. Hotfix-ul se creează de la ultimul tag de release, conține doar liniile necesare pentru eliminarea defecțiunii și urmează un deploy fast-track (vezi articolul „Hotfix — remedieri urgente”). Golden rule: după stabilizare, fă întotdeauna o root cause analysis, chiar dacă pare că cauza este evidentă.

Diagnosticarea cauzelor: loguri, metrici și alarme

După oprirea sângerării (sau în paralel, dacă numărul de ingineri permite) începe diagnosticarea. Prima sursă — logurile. Logarea centralizată (ELK, Grafana Loki, Datadog Logs) permite găsirea erorii după timestamp, ID utilizator sau ID cerere. Important: logurile trebuie să fie structurate (JSON) pentru ca grep să funcționeze rapid. Structured logging — o cerință obligatorie pentru toate serviciile.

A doua sursă — metricile. Grafana, Datadog, New Relic arată când a avut loc un spike de erori, pe ce endpoint-uri, cu ce coduri de status. Compararea metricilor înainte și după deploy ajută la localizarea problemei până la un anumit serviciu sau endpoint. RED metrics (Rate, Errors, Duration) — standardul de monitorizare a microserviciilor.

A treia sursă — distributed tracing. Jaeger, Zipkin, Datadog APM arată traseul cererii prin microservicii și identifică unde exact a apărut întârzierea sau eroarea. Tracing-ul este deosebit de util în cazul defecțiunilor în cascadă, când o eroare într-un serviciu cauzează erori în toate serviciile dependente. Trace ID trebuie transmis de la client la toate serviciile backend.

# Exemplu rapid de diagnosticare folosind kubectl și loguri
# Listează podurile cu erori
kubectl get pods --field-selector=status.phase!=Running

# Verifică logurile podului prăbușit
kubectl logs --previous pod/auth-service-7f4b9c5d6-abc12

# Caută erori în serviciu în ultimele 30 de minute
kubectl logs deployment/api-gateway --since=30m
  | grep "5[0-9][0-9]" | head -50

Important: nu încerca să diagnostichezi cauza înainte de a opri sângerarea. Dacă 50% dintre utilizatori văd un crash — mai întâi rollback, apoi analiză. Excepție: dacă rollback-ul ar dura mai mult decât un hotfix direct (de exemplu, în caz de incompatibilitate a datelor). În acest caz, hotfix-ul se aplică imediat, iar post-mortem-ul se face după stabilizare. Diagnosis before fix — un model periculos care crește downtime-ul.

Post-mortem: cum să analizezi incidentele fără a căuta vinovați

Post-mortem (numit și incident review) — o analiză structurată a incidentului efectuată la 24-72 de ore după rezolvarea acestuia. Scopul: să înțelegi de ce s-a produs defecțiunea, de ce monitorizarea și testele nu au prins-o înainte de producție și ce să schimbi în procese pentru a preveni repetarea. Blameless culture — principiul fundamental: post-mortem-ul discută procese, instrumente și comunicare, nu greșelile unor persoane specifice.

Structura documentului post-mortem: timeline (cronologia evenimentelor cu timestamp-uri), impact (utilizatori afectați, durată, pierderi financiare), root cause (cauza tehnică principală), detection (cum a fost descoperit, de ce nu a fost prins mai devreme), response (ce s-a făcut, ce s-ar fi putut face mai repede), action items (sarcini concrete cu persoane responsabile și termene limită). Action items trebuie să fie S.M.A.R.T.: specific, measurable, assignable, realistic, time-bound.

Action items tipice după o defecțiune de producție: adăugare monitorizare și alertă pentru metrica care era tăcută; extinderea acoperirii testelor pentru cazul omis; adăugarea unei pagini în runbook cu algoritmul pas cu pas pentru o situație similară; organizarea unui training al echipei pentru instrumentul care a fost folosit incorect. Fiecare action item este o schimbare concretă care reduce probabilitatea repetării incidentului.