Guadagni:
- Capacità di comprendere il ciclo di vita di un incidente (rilevamento, valutazione, mitigazione, risoluzione, post mortem), le metriche MTTD/MTTR e il principio "prima mitigare, indagare dopo"
- Capacità di utilizzare l'intelligenza artificiale per restringere il campo delle ipotesi al momento dell'incidente e produrre uno schizzo post-mortem irreprensibile, convalidando ciascuna causa principale con i dati
- Capacità di applicare la disciplina della scrittura in un linguaggio che non dia la colpa all'autopsia e di condividere i dati degli eventi mascherandoli.
Ogni sistema prima o poi crolla. La differenza sta nel modo in cui i buoni team si preparano per questo inevitabile evento e nel modo in cui imparano. L'incidente è un evento imprevisto che interrompe o minaccia di interrompere il servizio: un arresto anomalo del servizio, tempi di risposta alle stelle, una perdita di dati. Gestione degli incidenti significa rilevare, mitigare, risolvere l'incidente il più rapidamente possibile e quindi imparare da esso. Questa è la disciplina che guida giorno e notte i professionisti DevOps e SRE (Site Reliability Engineering).
Due parametri critici misurano la qualità dell'evento: MTTD (Mean Time To Detect) e MTTR (Mean Time To Recover). L’obiettivo è ridurli entrambi. L’intelligenza artificiale aggiunge qui due grandi valori: riassumere rapidamente registri e parametri al momento dell’evento per restringere la possibile causa principale e redigere rapidamente un postmortem (rapporto di indagine post-evento) dopo l’evento. Ma le decisioni sul corso degli eventi - quale servizio disattivare, ripristinare, cosa dire al cliente - spetta a te.
Ciclo di vita di un evento
- Rilevamento: suona un allarme o arriva un reclamo da parte del cliente. Prima è, meglio è.
- Triage: quanto è grave? Qual è il dominio? Vengono assegnati livelli di gravità: solitamente da SEV1 (più critico, intero sistema) a SEV4 (minore).
- Assembla la tua squadra di risposta. Negli incidenti critici, un comandante dell'incidente assume il coordinamento.
- Mitigare: fermare prima l'emorragia, spesso un rollback o la copertura di una bandiera. Troverai la causa principale più tardi.
- Risolvere: applicare una correzione permanente.
- Imparare (post-mortem): cosa è successo, perché è successo, come possiamo evitare che accada di nuovo?
Suggerimento: uno degli errori più costosi al momento dell'incidente è ritardare l'arresto dell'emorragia perché "arriviamo prima alla causa esatta". Regola: prima decrementare (ripristinare/ripristinare il servizio), poi informarsi. Il ripristino di una versione sicuramente valida è spesso la soluzione più rapida.
Cultura post-mortem senza sensi di colpa
La spina dorsale dei team sani è una cultura post-mortem irreprensibile: l'obiettivo non è "chi è stato", ma "quale sistema e processo ha permesso questo errore?" è la domanda. Le persone nascondono l'errore se sanno che saranno punite; L'errore nascosto si ripete. L'autopsia non è un rapporto di accusa, ma un documento di apprendimento.
Una buona autopsia include: riepilogo, impatto (quanti utenti, per quanto tempo, quanti soldi), cronologia, cause principali, cosa è andato bene/male e azioni: misure concrete, ciascuna con un proprietario e una data.
Attenzione: quando scrivi autopsie con l'intelligenza artificiale, assicurati di eliminare il linguaggio accusatorio (vale a dire "la persona X ha commesso un errore"). Inoltre, maschera gli ID client, gli IP interni e i segreti quando fornisci i dati degli eventi all'intelligenza artificiale: le autopsie sono spesso ampiamente condivise.
Analisi delle cause profonde: 5 perché e intelligenza artificiale
Una tecnica classica è "5 Whys": chiedi "perché?" ad un problema. Chiedendo ancora e ancora, arrivi dal sintomo superficiale alla vera radice. "Il servizio si è bloccato. Perché? Memoria esaurita. Perché? Si è verificata una perdita. Perché? Un aggiornamento della libreria..." L'intelligenza artificiale è rapida nel costruire questa catena e suggerire possibili diramazioni, ma è necessario verificare ciascun "perché" con i propri dati; L’intelligenza artificiale può anche costruire una catena ragionevole ma sbagliata.
Tabella di gravità
Livello
Impatto
esempio
intervento
SEV1
Intero sistema/perdita aziendale critica
Il pagamento è caduto completamente
Immediatamente, l'intera squadra, il comandante
SEV2
Disfunzione maggiore
Accessi non riusciti
Veloce, su chiamata + supporto
SEV3
Effetto parziale/limitato
Un rapporto è in ritardo
durante l'orario di lavoro
SEV4
piccolo/cosmetico
errore di battitura
coda di lavoro ordinaria
tre mini custodie
Caso 1 — MTTR da 45 minuti a 8 minuti. Il servizio di pagamento si è bloccato. L'ingegnere di turno ha fornito all'IA i registri mascherati e le informazioni sull'ultimo schieramento e ha chiesto "Qual è l'innesco più probabile negli ultimi 20 minuti?" chiese. L'intelligenza artificiale ha mostrato che il crollo è iniziato nello stesso minuto dell'ultimo schieramento. L'ingegnere ha immediatamente ripristinato quella versione; Il servizio è tornato in 8 minuti. La causa principale (un bug del pool di connessioni nella nuova versione) è stata quindi opportunamente indagata.
Caso 2: schizzo post-mortem tra 20 minuti. Dopo un SEV2, la squadra era stanca e non aveva la forza di scrivere un resoconto; spesso il rapporto veniva ritardato di settimane. Questa volta, hanno fornito la cronologia e le note dell'incidente all'IA e hanno prodotto uno schizzo post-mortem privo di crimini. L’intelligenza artificiale ha creato un quadro accurato per l’impatto, la sequenza temporale e gli elementi di azione; Il team lo ha riempito di fatti e lo ha pubblicato in 20 minuti. La lezione non è andata perduta.
Caso 3: individuata la causa principale errata. In un caso, l’intelligenza artificiale ha affermato che “la causa principale è il sovraccarico del database” e sembrava ragionevole. Ma l’ingegnere ha confermato i dati: al momento dell’incidente il carico del database era normale. La vera causa era un problema DNS esterno. L’ipotesi iniziale dell’IA era fluida ma sbagliata; La convalida con i dati ha impedito la pubblicazione del rapporto con una conclusione errata.
Quattro modelli copiabili
1) Triage rapido al momento dell'incidente:
Stiamo vivendo un evento di produzione. Sintomi mascherati: [SYMPTOM].Ultime modifiche: [LAST DEPLOY/CHANGE]. Dammi: (1) le 3 ipotesi di causa principale più probabili in ordine di probabilità, (2) il comando/metrica che verificherà ciascuna in 1 minuto, (3) il passaggio di mitigazione SAFE più veloce (ad esempio rollback). A rigor di termini; Premetto che devo verificare ogni ipotesi.
2) Schizzo post-mortem di un innocente:
Scrivi uno schizzo post-mortem irreprensibile dalle note dell'incidente riportate di seguito. Sezioni: Riepilogo, Impatto (utente/durata/costo), Cronologia, Cause principali, Cosa è andato bene, Cosa è andato male, Azioni (ciascuna con proprietario + campo data). Concentrarsi sulla denominazione, sul processo e sul sistema. Note: [MASCHERATO]
3) Analisi dei 5 perché:
Costruisci una catena di "5 Perché", iniziando con il seguente sintomo: [SYMPTOM].Mostra se c'è più di un possibile ramo ad ogni passaggio. Accanto a ogni "perché" scrivi le prove (log/metriche) che guarderò per verificarle. Alla fine segna quali passaggi non sono stati ancora verificati.
4) Creazione di elementi utilizzabili:
In base a questa causa principale, suggerire elementi attuabili che impediranno il ripetersi dello stesso evento. Classificare ciascun elemento per: (a) prevenzione, rilevamento o riduzione, (b) sforzo stimato, (c) impatto. Ordina in base al rapporto impatto/sforzo più elevato. Causa principale: [X]
Prompt debole / Prompt forte
Debole: "Il servizio è andato in crash, cosa devo fare?"
Risultato: nessun contesto; L'intelligenza artificiale può formulare raccomandazioni generali che non si adattano al tuo caso e può persino individuare una causa principale definitiva.
Forte: "Il servizio di pagamento della produzione ha concesso 5xx per 5 minuti. L'ultima implementazione è avvenuta 6 minuti fa. Fornisci le 3 ipotesi di causa principale più probabili in ordine di probabilità, comunica al comando che verificherà ciascuna di esse e suggerisci la mitigazione sicura più rapida. Non essere specifico, dichiara che devo verificare."
Differenza: il secondo prompt fornisce il sintomo, i tempi e l'ultima modifica; richiede ipotesi + verifica + riduzione e mantiene l'IA imprecisa.
Errori comuni
- Cercare la causa principale esatta prima di mitigare. Ritarda l'arresto del sanguinamento e aumenta l'MTTR.
- Pubblicare la prima ipotesi di AI senza verificarla. La radice fluida ma falsa causa perdite nel rapporto.
- Linguaggio accusatorio. L'autopsia scritta in modo anonimo favorisce l'occultamento e la ripetizione degli errori.
- Rapporto orientato all'azione senza elenchi puntati. Una proposta senza proprietario e senza data non verrà mai implementata.
- Condividere i dati degli eventi senza mascherarli. L'autopsia si rivolge a un vasto pubblico; vengono divulgati dati segreti/personali.
- Non preparare in anticipo il percorso di ripristino. Se l’inversione non è praticabile, la riduzione viene rallentata.
In sintesi
La gestione degli incidenti riguarda il rilevamento, la mitigazione, la risoluzione e l'apprendimento rapido da eventi inevitabili; MTTD e MTTR sono parametri chiave. La regola d'oro è "prima mitigare, poi indagare" e il ritorno alla versione nota è spesso la mitigazione più rapida. L’intelligenza artificiale ha un valore inestimabile nel riassumere i registri al momento dell’evento, restringere il campo delle ipotesi e produrre schizzi post-mortem irreprensibili dopo l’evento, ma è tua responsabilità convalidare ogni ipotesi sulla causa principale con dati, eliminare il linguaggio della colpa e mascherare i dati dell’evento.
Compito dell'applicazione
Considera un evento passato (o immaginario). (1) Far generare all’IA ipotesi e passaggi di verifica con il modello di “triage rapido sul posto”; Nota quale ipotesi può essere confermata dai dati. (2) Disegnare un rapporto utilizzando il modello "profilo post-mortem non colpevole" e riempirlo con i fatti. (3) Identificare almeno due elementi utilizzabili e assegnare un proprietario e una data a ciascuno.
lista di controllo
- [ ] Al momento dell'incidente, ho pensato innanzitutto a una mitigazione (rollback/spegnimento) e ho lasciato la causa principale per più tardi.
- [ ] Ho verificato ogni ipotesi di causa principale dell'IA con log/metrica.
- [ ] L'ho scritto in un linguaggio che non incolpa l'autopsia, concentrandomi sul processo e sul sistema.
- [ ] Ho assegnato a ciascun elemento utilizzabile un proprietario e una data.
- [] Ho mascherato le informazioni segrete e personali dai dati dell'evento che ho fornito all'IA.
- [ ] Ho assegnato correttamente il livello di gravità in base all'impatto.