Una guida completa alla gestione degli incidenti gravi in ITIL

È lunedì mattina e tutto procede come al solito al tuo service desk. All’improvviso, arriva un ticket ad avvisarti che un servizio critico è inattivo e, nel giro dei successivi 15 minuti, il flusso di ticket che segnalano il medesimo problema non fa che aumentare. Potrebbe trattarsi del tuo sito web diventato irraggiungibile o del tuo software di gestione del punto vendita che ha smesso di funzionare oppure potrebbe essere successo qualcosa su più vasta scala, come un’interruzione imprevista degli scambi in Borsa o del traffico aereo. Quando la tua azienda subisce un danno ingente a causa di un problema IT, che si traduce in una perdita di fatturato o di reputazione, possiamo certamente parlare di incidente grave.

Sarà la tua reazione agli incidenti gravi a fare tutta la differenza, in termini di contenimento dell’impatto dell’incidente e di ripristino rapido dei servizi. Il detto “il tempo è denaro”, in questo caso, non potrebbe essere più appropriato. Se la tua organizzazione è attrezzata con un processo di gestione degli incidenti gravi (MIM), potrai occupartene repentinamente e risolverli. Se, invece, non hai ancora implementato tale processo, è venuto il momento di impostare un piano di risposta alle emergenze, noto anche come processo di risposta agli incidenti gravi.

La posta in gioco in caso di incidenti gravi non è mai stata così alta, secondo uno studio redatto da Information Technology Intelligence Consulting, il 98 percento delle organizzazioni perde almeno 100.000 $ per ogni ora di inattività. Ciò conferma l’importanza di implementare un processo MIM che possa contrastare in modo efficiente ed efficace qualsiasi incidente grave.

Ogni organizzazione mira a eliminare gli incidenti gravi, ma la verità è che questo tipo di incidenti è impossibile da prevedere completamente: l’unica cosa da fare è essere pronti ad affrontarli.

In questa guida, ci occuperemo di come configurare un processo MIM efficace, di quali sono gli errori comuni che possono indebolire il MIM della tua organizzazione e le best practice per migliorarlo.

Innanzitutto, che caratteristiche deve avere un incidente per essere grave?

Un incidente grave è un problema urgente e ad alto impatto, che tipicamente coinvolge l’intera organizzazione o la maggior parte di essa. Un incidente grave comporta quasi sempre l’interruzione dei servizi dell’organizzazione, che si trova ad assorbire un colpo con effetti sulla propria stabilità finanziaria. Sono principalmente due le modalità in cui un incidente grave può impattare sui servizi di un’organizzazione:

• Impedendo ai clienti di accedere ai servizi dell’organizzazione. Il blackout che ha interessato Cloudflare nel luglio 2019 è un esempio di come la clientela possa venire colpita da un incidente grave. Si è trattato di un’interruzione grave che ha interessato quasi metà del traffico internet e ha impedito a milioni di utenti di accedere a vari servizi.
• Interferendo con la capacità dei dipendenti di completare il proprio lavoro in tempo, causando una battuta d’arresto dell'attività. Il blackout della compagnia aerea IndiGo, a novembre 2019, ha interessato il processo di elaborazione dei check-in e causato lunghi ritardi, che hanno colpito migliaia di passeggeri.

Un service desk ben preparato è equipaggiato per valutare la portata degli incidenti gravi e ideare una soluzione definitiva o un’alternativa (workaround) per ridurre e controllare l’impatto di un incidente grave.

Avere un processo di MIM (major incident management) è un’assoluta necessità per un’organizzazione, dato che aiuta a minimizzare l’impatto sull’azienda di un incidente grave. Il processo MIM consiste principalmente nei seguenti passi:

1. Identificazione

Dichiarare la presenza di un incidente grave:

Il primo passo è identificare i possibili incidenti gravi. È importante per l’organizzazione che siano configurati molteplici metodi per l’identificazione delle minacce. Gli incidenti gravi possono essere segnalati dai tecnici che si trovano alle prese con un ticket insolito, oppure possono essere rilevati da strumenti di monitoraggio di rete, in grado di segnalare automaticamente un problema alla rete e creare un ticket per allertare il service desk. Le organizzazioni possono inoltre implementare una linea di comunicazione dedicata, tramite la quale il personale del service desk possa segnalare ogni sospetto incidente grave.

Informare le parti in causa:

Una volta identificato un incidente grave, questo va comunicato a tutti gli attori chiave. Possiamo individuare quattro gruppi che devono essere informati in caso di incidente grave:

• Team di assistenza tecnica: è importante informare immediatamente il team di assistenza tecnica in modo che possa iniziare a decidere le azioni da intraprendere per risolvere il problema.
• Management: informare i superiori, come il direttore informatico (CIO), a proposito degli incidenti gravi aiuta con la gestione delle responsabilità. Le organizzazioni dovrebbero anche mantenere aggiornata la dirigenza riguardo a tutti i passi intrapresi per risolvere l’incidente.
• Attori chiave: in caso di incidenti gravi, vanno informati anche i capi reparto e il personale addetto alla gestione aziendale dei livelli di servizio, fornendo loro regolari aggiornamenti.
• Utenti: gli utenti devono sapere quali servizi potrebbero non essere disponibili a causa di un incidente grave.

2. Contenimento

Formazione di un team per gli incidenti gravi:

Un team dedicato agli incidenti gravi, detto anche major incident team (MIT), è formato da tecnici, capi della gestione dei livelli di servizio e altri attori chiave; per contrastare un incidente grave, potrebbe essere coinvolto anche del personale esterno altamente qualificato. I membri del MIT collaborano per trovare una correzione per l’incidente grave e riportare la situazione alla normalità.

Implementare un bridge di conferenza:

Un bridge di conferenza, comunemente noto come teleconferenza, aiuta a migliorare l’efficacia dell’analisi dell’incidente e a centralizzare le comunicazioni. Opera come canale di comunicazione rapido e trasparente tra i membri del MIT.

Scegliere una “war room”:

Avere una “war room” ben definita consente ai membri del MIT di riunirsi e affrontare insieme l’analisi dell’incidente. In questo modo si favorisce la collaborazione, che porterà il MIT a ideare più in fretta una soluzione.

Creare un ticket per identificare le problematiche di fondo:

La creazione di un problem ticket può servire a rivelare e comprendere la causa alla radice dell’incidente grave. Occuparsi delle cause di fondo potrà aiutare a evitare simili incidenti gravi in futuro.

4. Manutenzione

Effettuare una revisione post-implementazione:

Passato un certo lasso di tempo, è importante fare il punto della situazione riguardo all’incidente per assicurarsi che sia davvero risolto. Se le problematiche di fondo rimanessero irrisolte, potrebbero causare un ulteriore incidente grave.

Produrre una documentazione chiara:

Documentare l’intero processo di risoluzione di un incidente grave aiuta l’organizzazione a essere più preparata a incidenti simili in futuro. Grazie a un’appropriata documentazione degli incidenti passati, l’organizzazione potrà rapidamente implementare una soluzione già collaudata quando si troverà ad affrontare un incidente grave similare, riducendone l’impatto.

Misurazione delle metriche:

La misurazione delle prestazioni del service desk aiuta a valutare l’efficacia di tale servizio e del processo MIM. Alcune metriche importanti da misurare sono il tempo medio di riconoscimento (mean time to acknowledge - MTTA), il tempo medio di risoluzione (mean time to resolution - MTTR), il numero totale di incidenti gravi e la media del tempo di inattività per tali incidenti.

Un incidente grave richiede l’intervento di personale specializzato per essere affrontato e risolto. I ruoli del MIM comprendono:

Tecnici del service desk

I tecnici del service desk sono la prima linea di difesa contro gli incidenti gravi. Analizzano i ticket relativi agli incidenti e li riassegnano all’incident manager. I tecnici del service desk sono inoltre coinvolti nell’implementazione delle risoluzioni.

Major incident manager

Il major incident manager è il titolare dell’incidente grave. Sarà compito suo definire che si tratta di un incidente grave, assicurarsi che venga seguito il processo MIM e che l’incidente sia risolto al più presto. Opera come principale punto di contatto per qualsiasi informazione riguardo all’incidente grave e gestisce il MIT.

MIT

Il MIT è un team specializzato responsabile dell’analisi dell’incidente grave e della formulazione di un piano di azione per la gestione della minaccia. Idealmente, il MIT è costituito da tecnici del service desk, personale della gestione dei livelli di servizio, staff tecnico, altri attori chiave e, se la situazione lo richiede, anche da consulenti esterni.

Staff tecnico

Il personale specializzato responsabile del mantenimento dell’infrastruttura e delle operazioni, compresi sysadmin, amministratori di rete, e staff della sicurezza informatica, che forma il normale staff tecnico di un’organizzazione. Lo staff tecnico aiuta nell’analisi dell’incidente grave ed è il principale responsabile dell’implementazione della risoluzione dell’incidente.

Change manager

Il change manager è il titolare del cambiamento creato per implementare la correzione per l’incidente grave. Il change manager si assume la piena responsabilità del ticket di cambiamento ed è tenuto a risponderne (accountable).

Problem manager

Se viene creato un problem (problema) in risposta a un incidente grave, il problem manager è il titolare del rispettivo ticket. Il problem manager tenta di accertare le cause alla radice dell’incidente e si assicura che non capiti nuovamente o, per lo meno, che l’organizzazione sia preparata ad affrontarlo in caso si ripeta.

Consulenti esterni o fornitori di terze parti

In alcuni casi, l’analisi di un incidente grave potrebbe richiedere l’intervento di personale altamente specializzato. Il major incident manager identifica il personale necessario e lo aggiunge al MIT per aiutare a ridurre l’impatto dell’incidente grave.

Ecco i 5 errori comuni che possono ostacolare il processo MIM:

1. Comunicazione manuale ed escalation:

   La sfida di gran lunga più grande in ambito MIM è la comunicazione. Quando si verifica un incidente grave, sono numerose le parti in causa da informare riguardo allo stato di tale incidente, alla sua gravità e alle misure intraprese per risolverlo. Comunicare tutte queste informazioni manualmente è una scomoda incombenza e può generare incomprensioni che peggiorerebbero la situazione. Automatizzando il processo, gli attori chiave ricevono notifiche durante l’intero ciclo di vita del ticket e il major incident manager può concentrare la propria attenzione alla correzione del problema.

2. Canali inefficaci per la segnalazione degli incidenti gravi:

   Ogni service desk riceve decine o addirittura centinaia di ticket al giorno, che spaziano dal malfunzionamento di un portatile aziendale alla richiesta di servizi; in questa montagna di ticket, potrebbero esserci anche un paio di incidenti gravi. La mancata configurazione di un canale separato per la segnalazione di incidenti gravi non fa che ritardarne l’identificazione.

3. Dispersione degli sforzi:

   L’incapacità di delegare i compiti in maniera organizzata può causare una dispersione degli sforzi all’interno del MIT. È importante ottimizzare l’assegnazione dei compiti e informare il MIT sugli obiettivi di ogni membro.

4. Documentazione scarsa:

   La mancanza di una documentazione appropriata costringerà il MIT a reinventare la ruota ogni volta che si ripete un incidente grave già incontrato, causando un ritardo nella risoluzione di tale incidente e un incremento ingiustificato del tempo di inattività.

5. Mancata analisi delle cause alla radice:

   Come nel caso della gestione degli incidenti, il MIM può essere miope nei suoi propositi, dato che si concentra principalmente sulla correzione dell’errore e sul ripristino dei servizi nel minor tempo possibile. Se non viene affiancato dal problem management per l’identificazione delle problematiche di fondo, la causa alla base di un incidente grave continuerà a rendere l’organizzazione vulnerabile a quel tipo di incidente.

Ecco le modalità migliori per affrontare il processo MIM.

1. Abilitare più canali per la segnalazione degli incidenti gravi:

   Quando si tratta di gestire gli incidenti gravi, il tempo è prezioso. È vitale per le organizzazioni identificare e classificare gli incidenti gravi non appena questi vengono rilevati. Offrire agli utenti vari modi per segnalare gli incidenti renderà l’intero processo più veloce e accessibile. È possibile abilitare la creazione di ticket tramite e-mail o portali web, o persino implementare una linea di comunicazione dedicata alla segnalazione di ogni sospetto incidente grave. La configurazione di un software di monitoraggio della rete per rilevare le anomalie può aiutare a fronteggiare in modo proattivo gli incidenti gravi.

2. Automatizzare i processi di service desk:

   Velocità ed efficienza giocano un ruolo vitale nel controllare l’impatto di un incidente grave e automatizzare i vari processi del service desk aiuta a raggiungere l’obiettivo, svincolando i tuoi tecnici dalle attività ripetitive come il mantenere informate le parti in causa. L’automazione del sistema di notifica e la configurazione di un flusso di lavoro in caso di incidenti gravi sono ottime modalità di automatizzare i processi di service desk per migliorare il tempo di risoluzione e strutturare il tuo processo MIM.

3. Impegnarsi per una comunicazione pertinente e immediata:

   È importante che la dirigenza della tua organizzazione e le fondamentali parti in causa siano informate a proposito di ogni incidente grave. Mantenere aggiornata la dirigenza aiuta a ottenere le approvazioni necessarie e i permessi richiesti per la correzione dell’incidente grave. Una comunicazione immediata assicura che tutto il personale coinvolto nell’incidente grave abbia accesso alle stesse informazioni e consente una collaborazione più chiara ed efficace; inoltre, informa gli utenti sugli eventuali periodi di inattività, in modo che possano correre ai ripari.

4. Creare una documentazione chiara:

   Una documentazione chiara aiuta il major incident manager ad attestare tutto il lavoro fatto per correggere l’incidente grave, l’impatto che esso ha avuto sui servizi e altre informazioni chiave a riguardo. Questa documentazione è importante per dimostrare alla dirigenza i vantaggi dell’implementazione di un processo MIM, compreso il relativo ROI. Una documentazione chiara aiuterà anche nella gestione di eventuali incidenti simili in futuro.

5. Utilizzare l’integrazione avanzata con un software ITOM:

   Una forte integrazione con un software ITOM consente al reparto IT di affrontare gli incidenti gravi in modo proattivo. L’identificazione degli incidenti gravi con approccio reattivo si basa su un flusso di ticket in ingresso capaci di segnalare la presenza di tale incidente grave. D’altro canto, un processo MIM proattivo che sfrutta le integrazioni ITOM può contare su un monitoraggio di reti e servizi in grado di segnalare automaticamente le anomalie che potrebbero rivelarsi incidenti gravi.

È importante ribadire che non tutti gli incidenti ad alta priorità sono incidenti gravi. Dato che il processo MIM comporta un considerevole impiego di risorse come l’implementazione di un MIT separato, è importante classificare con attenzione gli incidenti gravi.

Fonte: https://blog.cloudflare.com/details-of-the-cloudflare-outage-on-july-2-2019/

Il blackout dei servizi Cloudflare nel 2019 è un ottimo esempio di cosa si definisce incidente grave. In questo caso, la procedura operativa standard di aggiornamento di una regola gestita per web application firewall (WAF) causò un’impennata nell’utilizzo delle CPU dedicate alla gestione del traffico HTTP/HTTPS in quasi il 100 percento dei server nella rete Cloudflare. Il blackout risultante ebbe come conseguenza una riduzione dell’80 percento del traffico di Cloudflare, interessando milioni di utenti di internet nel mondo.

Impatto: Grande

A causa del blackout, i clienti di Cloudflare (e i loro rispettivi clienti) visualizzavano una pagina con l’errore 502 ogni volta che tentavano di visitare un dominio Cloudflare. L’errore 502 era generato dai server web front-end di Cloudflare che avevano ancora core disponibili nelle CPU, ma non erano in grado di raggiungere i processi di gestione del traffico HTTP/HTTPS. È stato stimato che almeno metà di tutto l’internet sia stato inaccessibile durante i ventisette minuti di tempo di inattività.

Urgenza: Elevata

Tutti i siti web che si appoggiavano a Cloudflare erano inaccessibili, il che ha causato interruzioni ai servizi di migliaia di organizzazione e milioni di utenti. Il blackout colpì anche le operazioni interne di Cloudflare, impedendo ai suoi dipendenti di accedere a vari servizi come lo strumento di gestione dei cambiamenti dell’azienda e il pannello di controllo interno. Per poter ripristinare la normale operatività, era necessario prima affrontare il blackout.

Cronologia degli eventi dalla rilevazione alla soluzione:

La regola gestita WAF venne distribuita alle 13:42; tre minuti più tardi, gli strumenti di monitoraggio delle operazioni di rete di Cloudflare cominciarono a segnalare un crollo nel traffico, numerosi altri test end-to-end dei servizi di Cloudflare iniziarono a fallire, gli utenti finali continuavano a visualizzare pagine di errore 502 e Cloudflare riceveva costanti report di esaurimento CPU dai suoi point of presence nelle città di tutto il mondo.

Il site reliability engineering team, l’engineering team di Londra e altri team chiave furono riuniti insieme per l’analisi della situazione e l’ideazione di una soluzione. Alle 14:00 il WAF venne identificato come causa dell’incidente. Alle 14:07, venne implementato uno stop di emergenza per il WAF, in modo da riportare i livelli di traffico nella norma.

Alle 14:52, il personale di Cloudflare era sicuro al 100 percento di aver capito la causa del blackout ed era soddisfatto della soluzione implementata, quindi il WAF venne riabilitato su scala globale.

Cambiamento

Aggiunta, modifica o rimozione di qualsiasi cosa possa avere un effetto diretto o indiretto sui servizi.

Gestione dei cambiamenti

Processo con cui si portano a compimento i cambiamenti, minimizzando interruzioni e conflitti.

Escalation

Trasferimento di proprietà di un ticket in base a una logica funzionale o gerarchica.

Evento

Occorrenza significativa per la gestione di un servizio o di una risorsa.

Errore

Occorrenza in cui un servizio o una risorsa non operano secondo gli SLA concordati.

Escalation gerarchica

Trasferimento verticale della proprietà di un ticket a un tecnico del service desk di livello più elevato o all’opportuna autorità.

Impatto

Misura della gravità di un incidente.

Incidente

Interruzione non pianificata o riduzione della qualità di un servizio IT. Anche l’errore di un elemento di configurazione, anche se non ha ancora avuto ripercussioni su alcun servizio, è considerato un incidente (es. errore di uno dei dischi usato per il mirroring).

Gestione degli incidenti

Gestione del ciclo di vita di tutti gli incidenti per ripristinare la normale operatività del servizio nel modo più rapido possibile e ridurre al minimo l’impatto sull’attività.

Assegnazione della priorità all’incidente

Assegnazione della priorità agli incidenti e definizione di ciò che costituisce un incidente grave.

Incidente grave

Incidente che abbia grande impatto e urgenza elevata, tanto da richiedere un processo separato dalla normale gestione degli incidenti.

Major incident manager

Persona responsabile del MIT e dell’implementazione del processo MIM.

Tempo medio di riconoscimento (MTTA)

Misura della velocità di riconoscimento di un incidente da parte del service desk.

Tempo medio di rilevazione (MTTD)

Misura della velocità di rilevazione di una potenziale minaccia al servizio o a un elemento di configurazione.

Tempo medio tra guasti (MTBF)

Misura della frequenza con cui un servizio o una risorsa subiscono dei guasti.

Tempo medio di riparazione/risoluzione/risposta/recupero (MTTR)

Misura della velocità con cui un servizio viene ripristinato dopo il guasto.

Normale operatività del servizio

Operatività del servizio che rispetta il contratto di servizio (SLA).

Problem

Causa o possibile causa di uno o più incidenti.

Matrice RACI

Definisce ruoli e responsabilità in processi e progetti interfunzionali o tra vari reparti.

Service desk

Punto di comunicazione tra il provider dei servizi e gli utenti dell’organizzazione.

Manager del service desk

Chi si occupa di supervisionare le attività quotidiane del service desk ed è responsabile della sua performance.

Obiettivo di livello di servizio (SLO)

Definisce l’obiettivo del provider dei servizi ed è un modo per misurarne la performance.

SLA (Contratto di servizio)

Accordo tra il provider dei servizi e il cliente riguardo ai livelli di servizio attesi e alle tempistiche di fornitura accettabili.

Urgenza

Misura della velocità con cui un incidente deve essere risolto.