Contesto:
🎫 NHIT-3401 — DB lock cascade prod-eu-1
🏢 NHIT
⏱ Incident 2h 14m
Modello:
👤
Stamattina abbiamo avuto un blackout di 2h sull'ambiente prod-eu-1. Mi serve un'RCA completa con timeline, 5-why e raccomandazioni. Tutto pronto per la post-incident review delle 14:00.
🧬
Ho ricostruito l'incidente NHIT-3401 incrociando ticket, event log, CMDB e change audit. Riepilogo:
08:42:13
Deploy automatico
order-svc v2.14.0 in prod-eu-1 (change CHG-2891)08:43:07
Connection pool DB sale a 95% (alert P3 ignorato)
08:44:51
Primo timeout
SELECT ... FOR UPDATE · cascade lock detected [1]08:46:22
Alert P1 auto-trigger · NOC L2 ingaggia (3 min response time) [2]
10:56:48
Rollback CHG-2891 completato · prod-eu-1 ripristinato
5-Why chain (root cause):
1.Perché blackout? Cascade lock su
orders.items ha bloccato 47 transazioni.2.Perché cascade lock? Nuova query in v2.14.0 fa
SELECT FOR UPDATE senza index sul filter.3.Perché senza index? Migration
0142_add_status_idx.sql esiste ma non applicata in prod-eu-1.4.Perché non applicata? Step "DB migrate" del pipeline di deploy è marcato
continue-on-error: true.5.Perché continue-on-error? Workaround del 2024-11 per un bug oggi risolto, mai rimosso (technical debt). ← ROOT CAUSE
🐟 Fish-bone — contributing factors
PeopleReviewer change non ha visto missing migration nel diff
ProcessNessun gate "migrations applied" pre-deploy
Technology
continue-on-error in pipeline (debt 2024)Environmentprod-eu-1 unico ambiente con questa config (drift da prod-us-1)
MeasurementAlert pool 95% era P3, sotto-soglia paging
🛠 Corrective actions suggerite
1. Rimuovere continue-on-error dallo step DB migrate (immediate, P1)
2. Aggiungere gate "migrations applied" obbligatorio pre-deploy (1 sprint, P2)
3. Allineare config prod-eu-1 ↔ prod-us-1 (drift remediation, P2)
4. Alzare soglia alert pool a 80% con escalation P2 (configurable, P3)
5. KB article "Migration gate workaround removal" — propongo bozza