(ITIL Service Operation) KEDB in ITIL è un database contenente tutti i record di errori noti. Questo database viene creato come parte del processo di gestione dei problemi ed è utilizzato dai processi di gestione degli incidenti e dei problemi. La base di errore nota può essere parte di un sistema di gestione della configurazione o altrimenti far parte di un sistema di gestione della conoscenza del servizio.
Capire cos'è un KEDB e quanto sia importante per un Team IT e clienti in generale, diamo un'occhiata ad alcuni termini ITIL. (Ricorda, ITIL era precedentemente noto come Information Technology Infrastructure Library. ITIL fornisce best practice dettagliate per la gestione dei servizi IT, noto come ITSM.)
Un incidente è un'interruzione non pianificata di un servizio IT. Ciò potrebbe significare che il servizio di posta elettronica è stato interrotto senza preavviso, potrebbe significare che il software non è più connesso ad altri software, ecc.
Una volta identificato il problema, non è più un problema ma un bug noto: il team IT sa cosa sta causando un incidente e qual è il problema, ma non è stato ancora risolto.
La differenza tra incidente e problema è significativa: molti utenti segnalano interruzioni o guasti, ma l'IT potrebbe non conoscere il problema e la causa sottostante. Quando l'IT è in grado di scoprire il problema che ha causato l'incidente, può iniziare a risolverlo, con una soluzione alternativa a breve termine o una soluzione a lungo termine.
Un database di bug noti quindi tiene traccia di tutti i bug noti nell'ambito dell'IT, che è tipicamente un intero sistema o anche un'organizzazione. Idealmente, il KEDB include:
Una volta che l'IT è in grado di determinare il problema di un incidente, ha due approcci.
Il primo è trovare una soluzione a lungo termine e permanente. A seconda di quanto sia complicato il problema e se si è già verificato, l'IT deve dare priorità al tempo e alle risorse necessarie per trovare una soluzione permanente, nonché alla distribuzione e alla gravità del problema. Ciò può significare che ad alcuni problemi non viene assegnata la priorità.
Il secondo modo è trovare una soluzione alternativa a breve termine. Una soluzione alternativa è una soluzione temporanea che consente di eseguire il lavoro fino a quando il problema non viene risolto definitivamente. Le soluzioni alternative sono fondamentali in quanto l'IT deve dare la priorità a come impiegare tempo e denaro per risolvere i problemi.
Situazioni ridotte dalla necessità di una soluzione a lungo termine significa che gli utenti possono continuare a sperimentare l'incidente. Se gli utenti riscontrano ripetutamente l'incidente, una soluzione al problema assicurerà che l'utente abbia un'interruzione minima del lavoro produttivo.
In che modo esattamente un'azienda giustifica il capitale del database e i costi operativi?
Per tornare all'incidente e-mail, supponiamo che il servizio critico fosse in modalità di sospensione dopo una serie di diagnosi e test. Una volta identificata, la soluzione potrebbe essere stata più rapida se il servizio fosse stato interrotto e riavviato. Ma ci sono voluti molti sforzi per arrivare alla soluzione e, cosa più importante, è costato tempo prezioso. Il servizio di posta elettronica era inattivo durante l'applicazione della diagnosi e della risoluzione. Ciò potrebbe comportare sanzioni per i clienti e perdite non patrimoniali come future opportunità di business e soddisfazione del cliente.
Tuttavia, questa organizzazione, che fornisce servizi di posta elettronica ai propri clienti, mantiene un KEDB e questo particolare incidente è stato registrato. Se il servizio di posta elettronica si interrompe di nuovo, il team di supporto tecnico può semplicemente fare riferimento all'interruzione precedente nel KEDB e avviare la diagnostica con il servizio che ha causato il problema l'ultima volta. Ora, se il servizio stesso sta causando il problema, verrà risolto in una frazione del tempo. Come puoi vedere, questo riduce notevolmente i tempi di inattività e tutti gli altri effetti negativi delle interruzioni del servizio. Questo è KEDB in azione!
Un record KEDB contiene i dettagli dell'incidente, quando si è verificato l'errore e cosa è stato fatto per aggiustarlo. Per una rapida risoluzione, tuttavia, il KEDB deve essere abbastanza potente da recuperare i record rilevanti utilizzando filtri e termini di ricerca. Senza un KEDB, le organizzazioni di gestione dei servizi tendono a continuare a reinventare la ruota invece di lavorare per costruire un'organizzazione matura che dedichi le proprie risorse al miglioramento dei servizi.
In caso di un'interruzione del servizio, ci sono due modi per ripristinarla. La prima e più ideale è una soluzione permanente. Una soluzione permanente include una correzione che non garantisce più il fallimento, almeno in una certa misura. Il secondo e più comune tipo di ripristino è la soluzione alternativa, che cerca una soluzione alternativa. Dopo una soluzione alternativa, di solito viene identificata e implementata una soluzione permanente in un secondo momento.
Se l'e-mail il servizio non funziona, riavviare il servizio è una soluzione alternativa. Lo staff tecnico sa che questo risolverà il problema sul posto (che è di grande importanza), ma si ripeterà in futuro. Prima che l'incidente si ripeta, il team tecnico deve indagare sul motivo per cui il servizio non risponde e trovare una soluzione permanente.
Diamo un'occhiata a un altro esempio classico che ho usato più e più volte nei corsi di formazione: questo porta davvero a casa i concetti di soluzione alternativa e permanente. Immagina se la stampante nel tuo cubicolo ha smesso di funzionare e ti serve subito. Stai registrando un incidente con il tuo staff tecnico che ti informa che stai per entrare in un incontro con un cliente e per stampare alcuni documenti. L'agente di supporto scopre che non può riparare la stampante in modo tempestivo e ti offre una soluzione alternativa per inviare i tuoi file a una stampante condivisa nella hall.
La soluzione alternativa aiuta perché il tuo obiettivo è ottenere le stampe e partecipare a una riunione. Tuttavia, non è necessario eseguire questa operazione ogni volta che è necessario stampare. Quindi, quando la riunione è finita, spingi per una soluzione permanente. Quando torni, la tua stampante funziona e ci sarà una notifica dal personale di supporto che il cavo di alimentazione era difettoso ed è stato sostituito. Questa è una soluzione permanente. E anche se c'è la possibilità che anche il nuovo cavo si rompa, le probabilità sono buone.
In breve , la soluzione alternativa è una soluzione temporanea. Come suggerisce il termine, la soluzione permanente è permanente.
Perché ho discusso di una soluzione alternativa e permanente in un post rivolto a KEDB? Ci sono bug noti perché la correzione è "temporanea". Il database dei bug noti è costituito da record per i quali non esiste una soluzione permanente ma una soluzione alternativa. Se è necessario implementare una soluzione permanente su un record con un bug noto, il record può essere eliminato o archiviato per prove. I record di errore noti con una soluzione permanente implementata non devono necessariamente far parte del KEDB.
Questo concetto è esplorato ulteriormente nella sezione successiva, che discute i vari alberi dei processi per la creazione, l'utilizzo e l'archiviazione di record di errori noti.
