Questo documento del framework dell'architettura Google Cloud fornisce best practice per gestire i servizi e definire le procedure per rispondere agli incidenti. Gli incidenti si verificano in tutti i servizi, quindi hai bisogno di una procedura ben documentata per rispondere in modo efficiente a questi problemi e mitigarli.
Panoramica della gestione degli incidenti
È inevitabile che un sistema ben progettato non riesca a soddisfare i propri SLO. In assenza di uno SLO, i clienti definiscono in modo approssimativo il livello di servizio accettabile in base alla loro esperienza passata. I clienti riassegnano la richiesta all'assistenza tecnica o a un gruppo simile, indipendentemente da quanto indicato nel tuo SLA.
Per offrire un servizio adeguato ai tuoi clienti, stabilisci e testa regolarmente un piano di gestione degli incidenti. Il piano può essere breve come un elenco di controllo di una pagina con dieci voci. Questa procedura aiuta il team a ridurre il tempo di rilevamento (TTD) e il tempo di attenuazione (TTM).
Il TTM è preferito rispetto al TTR, dove la R per repair o recovery è spesso utilizzata per indicare una correzione completa rispetto alla mitigazione. Il tempo di risposta medio si basa su una mitigazione rapida per eliminare rapidamente l'impatto di un'interruzione sui clienti e poi avviare la procedura, spesso molto più lunga, per risolvere completamente il problema.
Un sistema ben progettato in cui le operazioni sono eccellenti aumenta il tempo tra i guasti (TBF). In altre parole, i principi operativi per l'affidabilità, tra cui una buona gestione degli incidenti, mirano a ridurre la frequenza degli errori.
Per eseguire servizi affidabili, applica le seguenti best practice alla procedura di gestione degli incidenti.
Assegna la proprietà del servizio
Tutti i servizi e le relative dipendenze critiche devono avere proprietari chiari responsabili del rispetto degli SLO. In caso di riorganizzazioni o perdita di personale, gli engineering lead devono assicurarsi che la proprietà venga trasferita esplicitamente a un nuovo team, insieme alla documentazione e alla formazione, come richiesto. I proprietari di un servizio devono essere facilmente rilevabili dagli altri team.
Riduci il tempo di rilevamento (TTD) con avvisi ottimizzati
Prima di poter ridurre il TTD, esamina e implementa i consigli nelle sezioni Integra funzioni di osservabilità nell'infrastruttura e nelle applicazioni e Definire gli obiettivi di affidabilità. Ad esempio, distingui tra problemi dell'applicazione e problemi del cloud sottostanti.
Un insieme ben calibrato di SLI avvisa il team al momento giusto senza un sovraccarico di avvisi. Per ulteriori informazioni, consulta Creare avvisi efficienti e Scopri come ottimizzare le tue metriche SLI con le "lezioni di vita" del team CRE.
Riduci il tempo di attenuazione (TTM) con piani e formazione per la gestione degli incidenti
Per ridurre il tempo di attenuazione, definisci un piano di gestione degli incidenti documentato e ben esercitato. Avere dati prontamente disponibili su cosa è cambiato nell'ambiente. Assicurati che i team conoscano le mitigazioni generiche che possono applicare rapidamente per ridurre al minimo il TTM. Queste tecniche di mitigazione includono il svuotamento, il rollback delle modifiche, l'aumento delle risorse e il degrado della qualità del servizio.
Come discusso altrove nell'Architecture Framework, crea procedure e strumenti operativi affidabili per supportare il rollback sicuro e rapido delle modifiche.
Progetta layout e contenuti delle dashboard per ridurre al minimo il tempo di attenuazione
Organizza il layout e la navigazione della dashboard del servizio 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 esaminare tutti i grafici della dashboard per cercare rapidamente i 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. Gli addetti alla gestione degli incidenti devono essere in grado di dare un'occhiata in una sola visualizzazione:
- Indicatori del livello del servizio, ad esempio le richieste andate a buon fine divise per le richieste valide totali
- Configurazione e implementazioni di file binari
- Richieste al secondo al sistema
- Risposte di errore al secondo dal sistema
- Richieste al secondo dal sistema alle sue dipendenze
- Risposte di errore al secondo inviate al sistema dalle relative dipendenze
Altri grafici comuni utili per la risoluzione dei problemi includono latenza, saturazione, dimensione della richiesta, dimensione della risposta, costo della query, utilizzo del pool di thread e metriche della Java Virtual Machine (JVM) (se applicabili). Per saturazione si intende la completezza in base a un limite, ad esempio la quota o le dimensioni della memoria di sistema. Utilizzo del pool di thread cerca le regressioni dovute all'esaurimento del pool.
Testa il posizionamento di questi grafici in base ad alcuni scenari di interruzione per assicurarti che i grafici più importanti siano in alto e che l'ordine dei grafici corrisponda al tuo flusso di lavoro di diagnostica standard. Puoi anche applicare il machine learning e il rilevamento di anomalie statistiche per visualizzare il sottoinsieme corretto di questi grafici.
Documenta le procedure di diagnostica e mitigazione per scenari di interruzione noti
Scrivi playbook e inserisci un link per accedervi dalle 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.
Utilizza i post mortem senza attribuzione delle colpe per imparare dalle interruzioni ed evitare che gli errori si ripetano
Stabilisci una cultura post-mortem senza attribuzione di colpe e un processo di revisione degli incidenti. Blameless significa che il team valuta e documenta cosa è andato storto in modo oggettivo, senza dover assegnare responsabilità.
Gli errori sono opportunità di apprendimento, non motivo di critiche. Cerca sempre di rendere il sistema più resiliente in modo che possa riprendersi rapidamente dagli errori umani, o, ancora meglio, rilevare e prevenire gli errori umani. Estrai il maggior numero possibile di informazioni da ogni post mortem e segui diligentemente ogni punto di azione post mortem per ridurre la frequenza delle interruzioni, aumentando così il TBF.
Esempio di piano di gestione degli incidenti
Sono stati rilevati problemi di produzione, ad esempio tramite un avviso o una pagina, o sono stati riassegnati a me:
- Dovrei delegare a qualcun altro?
- Sì, se tu e il tuo team non riuscite a risolvere il problema.
- Si tratta di una violazione della privacy o della sicurezza?
- In caso affermativo, riassegna la richiesta al team dedicato alla privacy o alla sicurezza.
- Si tratta di un'emergenza o gli SLO sono a rischio?
- In caso di dubbio, trattala come un'emergenza.
- Devo coinvolgere altre 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 apertura.
- Definisci un canale di comunicazione principale, ad esempio 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.
- Operations lead responsabile dell'attenuazione del problema.
- Definisci quando l'incidente è terminato. Questa decisione potrebbe richiedere un conferma da parte di un rappresentante dell'assistenza o di altri team simili.
- Collabora all'analisi post mortem senza attribuzione delle colpe.
- Partecipa a una riunione di revisione post-mortem degli incidenti per discutere e definire le attività del personale.
Consigli
Per applicare le indicazioni del framework dell'architettura al tuo ambiente, segui questi consigli:
- Stabilisci un piano di gestione degli incidenti e forma i tuoi team per utilizzarlo.
- Per ridurre il TTD, implementa i consigli per integrare funzioni di osservabilità nell'infrastruttura e nelle applicazioni.
- Crea una dashboard "Cosa è cambiato?" che puoi consultare rapidamente in caso di incidente.
- Documenta gli snippet di query o crea una dashboard di Looker Studio con query sui log frequenti.
- Valuta Firebase Remote Config per ridurre i problemi di implementazione per le applicazioni mobile.
- Test di recupero in caso di errore, incluso il ripristino dei dati dai backup, per ridurre il TTM per un sottoinsieme di incidenti.
- Progetta e testa la configurazione e i rollback binari.
- Replica i dati tra le regioni per il ripristino di emergenza e utilizza test di ripristino di emergenza per ridurre il TTM dopo le interruzioni regionali.
- Progetta un'architettura multiregionale per la resilienza alle interruzioni regionali se la necessità aziendale di disponibilità elevata 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:
Esplora i consigli negli altri pilastri del Framework dell'architettura.