Questo documento nel framework dell'architettura Google Cloud fornisce le best practice per gestire i servizi e definire i processi per rispondere agli incidenti. Gli incidenti si verificano in tutti i servizi, per cui è necessaria una procedura ben documentata per rispondere in modo efficiente a questi problemi e mitigarli.
Panoramica della gestione degli incidenti
È inevitabile che il tuo sistema ben progettato non riesca a soddisfare gli SLO. In assenza di uno SLO, i clienti definiscono in modo generico il livello di servizio accettabile in base alla loro esperienza passata. I clienti passano all'assistenza tecnica o a gruppi simili, indipendentemente dai termini dello SLA (accordo sul livello del servizio).
Per servire correttamente i tuoi clienti, stabilisci e testa regolarmente un piano di gestione degli incidenti. Il piano può essere tanto breve quanto un elenco di controllo di una sola pagina, con dieci elementi. Questo processo consente al tuo team di ridurre i tempi di rilevamento (TTD) e di mitigazione (TTM).
Il valore TTM è preferito rispetto al TTR, in cui la R per la riparazione o il ripristino è spesso utilizzata per indicare una correzione completa anziché la mitigazione. TTM pone l'accento sulla mitigazione rapida per porre fine rapidamente all'impatto di un'interruzione sul cliente e per poi avviare un processo spesso molto più lungo per risolvere completamente il problema.
Un sistema ben progettato in cui le operazioni sono eccellenti aumenta il tempo tra gli errori (TBF). In altre parole, i principi operativi per l'affidabilità, compresa una buona gestione degli incidenti, mirano a ridurre la frequenza degli errori.
Per eseguire servizi affidabili, applica le seguenti best practice nel processo di gestione degli incidenti.
Assegna chiaramente la proprietà del servizio
Tutti i servizi e le loro dipendenze critiche devono avere proprietari chiari responsabili della conformità ai rispettivi SLO. In caso di riorganizzazioni o abbandono di team, i responsabili tecnici devono assicurarsi che la proprietà venga trasferita esplicitamente a un nuovo team, insieme alla documentazione e alla formazione necessarie. I proprietari di un servizio devono essere facilmente rilevabili dagli altri team.
Riduci il tempo di rilevamento (TTD) con avvisi ottimizzati
Prima di ridurre il TTD, rivedi e implementa i suggerimenti nella sezione Sviluppa l'osservabilità nella tua infrastruttura e nelle tue applicazioni e definisci gli obiettivi di affidabilità della categoria di affidabilità del framework dell'architettura. Ad esempio, puoi distinguere tra problemi delle applicazioni e problemi cloud sottostanti.
Un insieme ottimizzato di SLI avvisa il tuo team al momento giusto senza sovraccarico di avvisi. Per ulteriori informazioni, consulta la sezione Creare avvisi efficienti della categoria di affidabilità del framework dell'architettura o Ottimizzare le metriche SLI: lezioni sulla vita di CRE.
Riduci i tempi di mitigazione (TTM) con i piani di gestione degli incidenti e la formazione
Per ridurre il tempo di attenuazione, definisci un piano di gestione degli incidenti documentato e ben esercizio. Disporre di dati facilmente reperibili su ciò che è cambiato nell'ambiente. Assicurati che i team conoscano le mitigazioni generiche che possono applicare rapidamente per ridurre al minimo il tempo di attenuazione. Queste tecniche di mitigazione includono lo svuotamento, il rollback delle modifiche, l'aumento delle dimensioni delle risorse e il degrado della qualità del servizio.
Come discusso in un altro documento della categoria di affidabilità del framework dell'architettura, crea processi operativi e strumenti affidabili per supportare il rollback rapido e sicuro delle modifiche.
Progetta layout e contenuti della dashboard per ridurre al minimo il tempo di attenuazione
Organizza il layout e la navigazione della dashboard dei servizi in modo che un operatore possa determinare in un paio di minuti se il servizio e tutte le sue dipendenze critiche sono in esecuzione. Per individuare rapidamente le potenziali cause dei problemi, gli operatori devono essere in grado di analizzare tutti i grafici della dashboard per cercare rapidamente grafici che cambiano in modo significativo al momento dell'avviso.
Il seguente elenco di grafici di esempio potrebbe essere presente nella tua dashboard per aiutarti a risolvere i problemi. Chi risponde agli incidenti dovrebbe essere in grado di vederli da un'unica vista:
- Indicatori del livello del servizio, ad esempio le richieste andate a buon fine diviso per il numero di richieste valide totali
- Configurazione e implementazioni binarie
- Richieste al sistema al secondo
- Risposte di errore al secondo dal sistema
- Richieste al secondo dal sistema alle sue dipendenze
- Risposte di errore al sistema al secondo dalle sue dipendenze
Altri grafici comuni per facilitare la risoluzione dei problemi includono latenza, saturazione, dimensione della richiesta, dimensione della risposta, costo delle query, utilizzo del pool di thread e metriche delle macchine Java virtuali (JVM), se applicabili. La saturazione si riferisce all'intero contenuto entro un limite, ad esempio la quota o la dimensione della memoria di sistema. L'utilizzo del pool di Thread cerca regressioni dovute all'esaurimento del pool.
Testa il posizionamento di questi grafici rispetto ad alcuni scenari di interruzione per assicurarti che i grafici più importanti siano vicini alla parte superiore e che l'ordine dei grafici corrisponda al tuo flusso di lavoro diagnostica standard. Puoi anche applicare il machine learning e il rilevamento di anomalie statistiche per far emergere il sottoinsieme corretto di questi grafici.
Documenta le procedure diagnostiche e la mitigazione per gli scenari di interruzione noti
Scrivi playbook e inserisci link nelle notifiche di avviso. Se questi documenti sono accessibili dalle notifiche di avviso, gli operatori possono ottenere rapidamente le informazioni di cui hanno bisogno per risolvere e mitigare i problemi.
Utilizzare i dati post mortem senza attribuzione delle colpe per apprendere dalle interruzioni ed evitare che si ripetano
Stabilisci una cultura post mortem senza attribuzione di colpe e un processo di revisione degli incidenti. Senza attribuzione di colpe significa che il tuo team valuta e documenta gli errori in modo oggettivo, senza la necessità di attribuire la colpa.
Gli errori sono opportunità per imparare, non motivo di critica. Cerca sempre di rendere il sistema più resiliente, in modo che possa recuperare rapidamente dall'errore umano o, ancora meglio, rilevare e prevenire errori umani. Estrai il maggior numero di informazioni possibile da ogni post mortem ed esegui un follow-up diligente su ogni attività post mortem al fine di rendere le interruzioni meno frequenti, con un conseguente aumento del TBF.
Esempio di piano di gestione degli incidenti
Sono stati rilevati problemi di produzione, ad esempio tramite un avviso o una pagina, o riassegnati a me:
- Devo delegare a qualcun altro?
- Sì, se tu e il tuo team non riuscite a risolvere il problema.
- Il problema è una violazione della privacy o della sicurezza?
- In caso affermativo, delega il compito al team addetto alla privacy o alla sicurezza.
- Il problema è un'emergenza o sono a rischio gli SLO?
- In caso di dubbi, consideralo come un'emergenza.
- Devo coinvolgere più persone?
- Sì, se interessa più del X% dei clienti o se la risoluzione richiede più di Y minuti. In caso di dubbi, coinvolgi sempre più persone, soprattutto durante l'orario di lavoro.
- Definisci un canale di comunicazione principale, come IRC, Hangouts Chat o Slack.
- Delega i ruoli definiti in precedenza, ad esempio:
- Incident Commander, responsabile del coordinamento generale.
- Responsabile delle comunicazioni responsabile delle comunicazioni interne ed esterne.
- Responsabile operativo responsabile della mitigazione del problema.
- Definisci quando l'incidente è terminato. Questa decisione potrebbe richiedere il riconoscimento di un rappresentante dell'assistenza o di altri team simili.
- Collabora all'azione post mortem senza attribuzione di colpe.
- Partecipa a una riunione di revisione degli incidenti post mortem per discutere delle azioni da intraprendere per il personale.
Suggerimenti
Per applicare al tuo ambiente le indicazioni fornite nel framework dell'architettura, segui questi suggerimenti:
- Stabilisci un piano per la gestione degli incidenti e forma i tuoi team a utilizzarlo.
- Per ridurre il tempo di rilevamento, implementa i suggerimenti per integrare l'osservabilità nella tua infrastruttura e nelle tue applicazioni.
- Crea una dashboard "Che cosa è cambiato?" da poter dare un'occhiata quando si verifica un incidente.
- Snippet di query sul documento o crea una dashboard di Looker Studio con query di log frequenti.
- Valuta Firebase Remote Config per mitigare i problemi di implementazione delle app mobile.
- Testa il ripristino da errori, incluso il ripristino dei dati dai backup, per ridurre il tempo di attenuazione per un sottoinsieme di incidenti.
- Progetta e testa configurazione e rollback binari.
- Replica i dati in diverse regioni per il ripristino di emergenza e utilizza i test di ripristino di emergenza per ridurre il tempo di attenuazione dopo interruzioni a livello di regione.
- Progetta un'architettura multiregionale per la resilienza alle interruzioni regionali se l'esigenza aziendale di alta disponibilità giustifica il costo, per aumentare il TBF.
Passaggi successivi
Scopri di più su come creare un processo collaborativo di gestione degli incidenti con le seguenti risorse:
- Dashboard dello stato di Google Cloud
- Gestione degli incidenti in Google
- Processo di risposta agli incidenti relativi ai dati
- Capitolo del libro SRE sulla gestione degli incidenti
Esplora altre categorie nel framework dell'architettura come progettazione del sistema, eccellenza operativa e sicurezza, privacy e conformità.