ITIL, Italia

Il processo Event Management nasce con ITIL v3. Si inserisce nella fase Service Operation del modello di lifecycle dei servizi IT in ITIL v3.  In ITIL v2, l'event management era trattato, ma solo parzialmente, nel contesto del processo di incident management, ove gli eventi erano considerati un input al processo. Se ne parlava un po' piu' diffusamente nel libro ICT Infrastructure Management.

In ITIL v3, l'event management finalmente assurge al ruolo di processo indipendente. In parte questo e' dovuto al fatto che si sono moltiplicati i tool che permettono di gestire gli eventi in modo appropriato.

Un evento, in ITIL v3, e' definito come un cambio di stato che ha rilevanza ai fini della gestione di un Configuration Item o di un servizio IT. Un evento potrebbe indicare un malfunzionamento di una parte dell'infrastruttura, e quindi esere un trigger per la generazione di un incidente. Gli eventi, comunque, possono anche indicare un andamento normale delle attivita' oppure la finalizzazione di un intervento di routine (es. il cambiamento di un tape).

Il processo di event management si basa ovviamente su dei sistemi di monitoraggio,  ma differisce dal normale monitoraggio in quanto l'event management genera ed  identifica eventi (cambi di stato), mentre i sistemi di monitoraggio controllano i componenti dell'infrastruttura anche in assenza di eventi. I sistemi di monitoraggio su cui si basa l'event management sono normalmente di due tipi:

• Sistemi di monitoraggio attivi, che attivamente vanno in poilling sui Configuration Items
• Sistemi di monitoraggio passivi che rilevano e mettono in correlazione notifiche operative e comunicazioni generate dai CI stessi

Dopo che l'evento e' stato identificato, esso si puo' trasformare in un incidente, un problema, un RFC, oppure semplicemente registrato per futura analisi.

In ultima analisi, il core business del processo di event management e' quello di identificare gli eventi, capirne il senso e determinare l'azione piu' appropriata (creazione di incident secondo i canali regolari, notifica immediata via SMS nel caso di major incidents, etc...)

In aggiunta a quanto detto sopra, l'event management puo' anche essere utile per automatizzare delle attivita' di routine, quali azionare in automatico l'avvio di script se determinate condizioni si verificano, etc...

Le attivita' tipiche dell'event management sono schematizzate nel workflow mostrato in basso. Le principali sono:

• Generazione dell'Evento, un cambio di stato nell'inftastruttura IT, trigger del workflow.
• Notifica dell'evento, la maggior parte dei CI possono essere configurati per generare eventi o su richiesta (interrogazione) o sulla base di determinate condizioni. Parte dell'event management e' determinare quali eventi devono generare notifiche.
• Identificazione dell'evento, non appena una notifica e' stata generata, va inoltrata al sistema di gestione degli eventi apposito
• Filtraggio degli eventi, come detto in precedenza solo gli eventi degni di nota vanno processati, gli altri possono essere scartati (magari scrivendolo in un log di sistema)
• Valutazione dell'evento (Importanza), gli eventi vanno valutati per poter poi decidere le azioni appropriate. Normalmente si usano almento tre livelli: Informativo, warning, eccezione.
• Correlazione degli eventi, se e' un evento e' significativo, bisognerebbe cercare di capire il contesto nel quale e' stato generato: e' la prima volta che si presenta? ci sono eventi correlati che ne arricchiscono l'informazione?. Questo normalmente avviene attraverso un "correlation engine" che permette di stabilire con maggiore precisione l'importanza dell'evento.
• Trigger, se a valle della correlazione ci si rende conto che l'evento e' significativo, fa definita una risposta, che potrebbe essere la creazione di un incidente, di una RFC o altro.
• Review delle azioni, non e' normalmente possibile fare la review di tutte le azioni effettuate come risposta agli eventi, avrebbe pero' senso assicurarsi che almento gli eventi significativi siano stati trattati opportunamente.
• Chiusura dell'evento, normalmente avviene non appena la risposta e' stata avviata