Un piano di gestione degli incidenti per un piccolo team software

Un piano per la gestione degli incidenti deve aiutare il team a gestire con ordine il lavoro interrotto. Scelga un flusso importante del software e descriva come se ne riconosce il guasto, chi decide e quale verifica serve per riprendere l’attività.

Identificare il flusso interessato

Nell’esempio inventato, l’incidente I-72 riguarda un portale clienti. La pagina iniziale risponde, ma le nuove richieste non possono essere salvate interamente con un allegato. La richiesta A-72 e il file F-72 sono soltanto esempi di test. Non si tratta di un’interruzione operativa osservata qui.

In questo caso la sola disponibilità della pagina iniziale non costituisce il criterio di chiusura. Il piano indica il flusso completo della richiesta, compresi archiviazione del file, verifica dei ruoli e attività successive. Registra inoltre quali modifiche sono consentite durante l’intervento.

Compilare una scheda di intervento con i ruoli

Google SRE descrive ruoli chiari, un registro di lavoro aggiornato e passaggi di consegne confermati. Nei piccoli team una persona può ricoprire più ruoli. Deve comunque restare chiaro chi coordina, chi modifica il sistema e chi comunica le informazioni.

La tabella descrive passaggi pianificati, non un ripristino eseguito. Definisca un sostituto e un contatto di escalation raggiungibile. Il documento di lavoro deve essere disponibile anche quando il portale non funziona.

Pianificare la comunicazione come attività distinta

Indichi chi informa le persone interessate e i servizi coinvolti. Un aggiornamento di stato riporta l’impatto noto, lo stato dell’intervento e il prossimo momento di aggiornamento concordato. Una causa presunta viene indicata come ipotesi; un tempo di ripristino non fondato non viene comunicato come promessa.

Se durante l’incidente cambia la persona incaricata, lo stato corrente viene trasmesso e la presa in carico confermata. Il passaggio comprende anche azioni non riuscite e verifiche ancora aperte. Un messaggio inviato non basta a dimostrare che il nuovo coordinamento sia stato assunto.

Distinguere la ripresa dalle attività successive

Prima della ripresa il team verifica il flusso interessato in un ambiente adeguato con i casi di test concordati. La possibilità di tornare a uno stato precedente dipende anche dai dati modificati nel frattempo; un riavvio da solo non prova il ripristino.

Registri chi autorizza la ripresa e quali attività aperte restano sotto osservazione. La successiva analisi delle cause può migliorare il piano, senza essere equiparata alla prima stabilizzazione. Provi la scheda con uno scenario approvato e corregga contatti, accessi o passaggi di verifica mancanti.

Fonti

• Google SRE: Managing Incidents