Perché hai bisogno di un piano scritto
Durante un incidente, il tuo cervello non funziona a piena capacità. Lo stress restringe la concentrazione. Dimentichi i passaggi. Salti la comunicazione. Risolvi il sintomo ma non la causa.
Un piano scritto di risposta agli incidenti toglie il pensiero dai primi 10 minuti. Segui una checklist. Sai cosa fare e in quale ordine. Il piano gestisce il processo in modo che il tuo cervello possa gestire il debugging.
Questo modello è progettato per piccoli team (2-10 persone). Presuppone che tu non abbia un team SRE dedicato o una rotazione di reperibilità con 15 persone. Presuppone che la persona che viene allertata sia anche quella che risolve il problema.
Il piano di risposta agli incidenti
Fase 1: Rilevare
Il tuo strumento di monitoraggio ti avvisa. Ricevi una notifica: “Monitor [nome] è giù. 3 fallimenti consecutivi. HTTP 500.”
Niente panico. Prenditi 30 secondi per verificare. Controlla il sito tu stesso. Controlla la dashboard di monitoraggio per altri alert. Un singolo monitor giù potrebbe essere un falso allarme. Più monitor giù significa un vero incidente.
Se usi PingWatchdog, gli incidenti vengono creati automaticamente quando i monitor vanno giù. Ottieni una cronologia di cosa è successo e quando. Questo è il tuo punto di partenza per il debugging.
Fase 2: Dichiarare
Se si tratta di un vero incidente (non un falso allarme o un evento pianificato), dichiaralo. Informa il tuo team. Informa i tuoi utenti.
Per il tuo team: Pubblica nel canale designato per gli incidenti (Slack, Discord, Teams). Includi ciò che sai: quali monitor sono giù, quando sono andati giù, quali errori stai vedendo. Tagga chiunque potrebbe dover essere coinvolto.
Per i tuoi utenti: Aggiorna la tua pagina di stato. Pubblica un aggiornamento “In investigazione”. Non devi conoscere la causa principale. Devi solo riconoscere il problema. “Stiamo esaminando segnalazioni di errori API elevati. Prossimo aggiornamento tra 15 minuti.”
La tua pagina di stato dovrebbe aggiornarsi automaticamente dai tuoi dati di monitoraggio. Se un monitor è giù, la pagina di stato dovrebbe mostrarlo. L’aggiornamento manuale dice agli utenti che ci stai lavorando.
Fase 3: Investigare
Inizia con la spiegazione più semplice. Hai distribuito di recente? Una dipendenza è cambiata? Un servizio di terze parti ha avuto un incidente?
Controlla i tuoi dati di monitoraggio. Quali errori stanno segnalando le sonde? Connessione rifiutata? Fallimento DNS? Timeout? HTTP 500 con un messaggio di errore specifico? I dati delle sonde mostrano ciò che vede il mondo esterno.
Controlla i tuoi log. Log dell’applicazione, log del database, log del server web. Cerca errori che sono iniziati più o meno nello stesso momento in cui il monitor è andato giù.
Controlla la tua infrastruttura. Il server è attivo? Il database accetta connessioni? L’uso di memoria o disco sta aumentando? L’utilizzo della CPU è anomalo?
Fase 4: Mitigare
Una volta che sai cosa non va, ferma l’emorragia. Questa potrebbe non essere la soluzione permanente. Va bene. L’obiettivo è ripristinare prima il servizio, poi risolvere la causa principale.
Mitigazioni comuni:
- Eseguire un rollback: Se un deploy recente ha causato il problema, torna alla versione precedente. Distribuisci la correzione dopo la risoluzione dell’incidente.
- Riavviare un servizio: I pool di connessioni al database, i server di cache e le code di messaggi a volte hanno bisogno di un riavvio. Riavvia il servizio e monitora il ripristino.
- Aumentare le risorse: Se il problema è l’esaurimento delle risorse (CPU, memoria, connessioni), scala verso l’alto. Puoi scalare verso il basso dopo l’incidente.
- Failover: Se un singolo server o regione è interessato, instrada il traffico altrove.
Fase 5: Comunicare
Durante la mitigazione, pubblica un altro aggiornamento di stato. “Problema identificato come esaurimento del pool di connessioni al database. Stiamo distribuendo una correzione.”
Dopo il deploy della correzione, pubblica di nuovo. “Correzione distribuita. Monitoraggio del ripristino.”
Dopo aver confermato il ripristino, pubblica l’aggiornamento finale. “Servizio ripristinato. Durata dell’incidente: 23 minuti.”
Non lasciare passare più di 30 minuti senza un aggiornamento, anche se l’aggiornamento è “Ancora in investigazione. Abbiamo circoscritto il problema al livello database.” Il silenzio crea incertezza. Gli aggiornamenti creano fiducia.
Fase 6: Risolvere
Attendi che i tuoi monitor confermino il ripristino. Non dichiarare l’incidente risolto basandoti su un rapido controllo manuale. Lascia che i controlli automatizzati verifichino che il servizio sia stabile.
PingWatchdog risolve automaticamente gli incidenti quando i monitor tornano allo stato “up” per un periodo prolungato. Questo garantisce che tu non chiuda un incidente prematuramente.
Fase 7: Post-mortem
Entro 24 ore dall’incidente, scrivi un breve post-mortem. Non deve essere un documento formale. Un messaggio su Slack o un breve documento va bene. Rispondi a queste domande:
- Cosa è successo? Descrivi l’incidente in linguaggio semplice.
- Qual è stato l’impatto? Per quanto tempo i servizi sono stati interessati? Quali servizi? Quanti utenti?
- Qual è stata la causa principale? Cosa ha specificamente innescato il guasto?
- Come è stato rilevato? Il monitoraggio l’ha intercettato? Un utente l’ha segnalato?
- Come è stato risolto? Quali passaggi sono stati intrapresi per risolverlo?
- Cosa impedirà il ripetersi? Quali azioni scaturiscono da questo?
L’obiettivo del post-mortem non è attribuire colpe. È imparare e migliorare. Ogni incidente è un’opportunità per rendere il tuo sistema più affidabile.
Configurare il tuo kit di strumenti per gli incidenti
Per eseguire questo piano, hai bisogno di alcune cose predisposte prima che si verifichi un incidente:
Monitoraggio: Monitoraggio dell’uptime, monitoraggio SSL e monitoraggio heartbeat. Devi sapere dei problemi prima che gli utenti li segnalino. Configura il monitoraggio PingWatchdog.
Alerting: Alert instradati ai canali giusti. I monitor critici vanno a PagerDuty o notifiche telefoniche. Quelli non critici vanno a Slack. Configura i canali di alert.
Pagina di stato: Una pagina di stato pubblica dove gli utenti possono controllare lo stato dei servizi. Gli aggiornamenti durante gli incidenti devono essere rapidi e onesti. Configura una pagina di stato.
Gestione degli incidenti: Incidenti creati automaticamente con cronologie. Quando inizia un incidente, non dovresti dover creare manualmente un ticket. Lo strumento di monitoraggio dovrebbe farlo per te. Scopri di più sulla gestione degli incidenti.
Canali di comunicazione: Un canale Slack designato, una stanza Discord o un canale Teams per gli incidenti. Tutti sanno dove andare durante un incidente.
Esercitati con il piano
Fai un’esercitazione antincendio. Scegli un servizio non critico. Mettilo giù intenzionalmente. Segui il piano. Cronometra quanto tempo richiede ogni passaggio.
La maggior parte dei team scopre che la parte più difficile non è la correzione tecnica. È la comunicazione. “Ho risolto il problema in 5 minuti ma ho passato 15 minuti a capire cosa dire sulla pagina di stato.” La pratica rende la comunicazione più veloce.
Inizia a costruire il tuo piano
Il modello qui sopra funziona così com’è. Personalizza i nomi dei canali, i percorsi di escalation e i riferimenti agli strumenti per il tuo team. Mantienilo breve. Se il piano è più lungo di una pagina, il tuo team non lo leggerà durante un incidente.
Inizia il monitoraggio gratuito con PingWatchdog. Ogni piano include la gestione degli incidenti con creazione e risoluzione automatica degli incidenti.