Un incidente risolto in fretta è una buona notizia. Lo stesso incidente risolto in fretta ogni lunedì, però, è un segnale che stiamo diventando efficienti nel ripetere un errore.
Ripristinare non significa eliminare la causa
Immaginiamo un’applicazione che si blocchi durante l’elaborazione degli ordini. Il team riavvia un componente, verifica che gli utenti possano lavorare e chiude il ticket. Ha fatto ciò che serviva nell’immediato: ridurre l’impatto e ripristinare il servizio. Nelle guide ITIL usate come riferimento, questo è lo scopo della gestione degli incidenti; la gestione dei problemi mira invece a individuare cause effettive o potenziali e a ridurre probabilità e impatto di nuovi incidenti.
Le due attività non competono. Durante il fermo, la priorità può essere rimettere in funzione gli ordini. Dopo il ripristino, serve capire perché il componente si blocca: capacità insufficiente, modifica recente, dipendenza esterna? Finché la causa non è chiarita, il riavvio resta una soluzione temporanea, utile ma non definitiva.
Dal ripristino alla ricerca della causa
Per evitare che l’analisi si perda, bastano poche informazioni raccolte nel momento giusto: servizio e utenti coinvolti, orario, sintomi osservati, intervento eseguito, verifiche che hanno confermato il ripristino. Poi si collega l’incidente ad altri episodi simili e si assegna un responsabile dell’analisi, con una data per decidere il passo successivo. La documentazione del rimedio temporaneo permette al supporto di riutilizzarlo senza scambiarlo per una correzione permanente.
Non ogni ticket richiede un’indagine estesa. La ripetizione, l’impatto sul lavoro e l’incertezza sulla causa aiutano a scegliere dove investire tempo. Se emerge una correzione, va valutata e pianificata; se non emerge, è comunque utile esplicitare il rischio residuo e chi lo accetta.
La domanda giusta per chi governa l’IT
Il dato «tempo medio di ripristino» racconta solo metà della storia. Accanto a esso, chiediamoci quante interruzioni si ripresentano e quanta energia del team va nella lotta agli stessi problemi invece che nel miglioramento. Il principio operativo resta semplice: un servizio riparte davvero quando si riduce anche la probabilità che si fermi di nuovo.