Joindre l'ITIL à l'agréable...

Bonjour,

J'ai entamé un article détaillé concernant une migration de serveur, mais cet article étant très long à écrire, je fais une petite pause pour vous parler de quelque chose de très intéressant, j'ai nommé ITIL.

Dans ITIL il y a des concepts fondamentaux qui sont immuables. Par exemple le fait que dans ITIL tout doit avoir de la valeur, ou encore qu'un service n'a aucune valeur si il n'a pas de garantie associée. Je dirais que dans la vie d'un informaticien il y a le avant ITIL, et l'après ITIL.

 Cet article concerne plus précisément le cœur d'ITIL, le service desk!

Oui, on ne parle pas de helpdesk, on parle service (mot que beaucoup ont oubliés, malheureusement).
Cela tombe bien, ITIL est centré sur le service.

Pour bien comprendre cet article, il est important de préciser la terminologie ITIL, terminologie que tout bon informaticien devrait connaître.

Appelons un chat un chat!

ITIL étant un référentiel bien pensé, il existe des termes différents pour des situations différentes.
Pour bien comprendre ces termes, il faut avoir à l'esprit que ITIL est centré sur le service rendu, contractualisé par le SLA (ou l'OLA, mais là on sort du sujet de l'article).
Donc le SLA (Service Level Agreement), c'est le contrat concernant le service qui doit être rendu aux utilisateurs. Ce service peut être rendu indifféremment en interne, ou en externe.

Donc revenons à nos moutons (nos chats en l’occurrence), il existe trois termes, événement, incident, et problème.

En fait, pour faire simple, un événement est n'importe quel événement n'impactant pas le SLA.

Prenons l'exemple d'un prestataire externe, à qui on garanti via le SLA la mise à disposition d'un portail applicatif disponible 24/24-7/7.

Une météorite tombe sur terre, et rase la moitié de la terre, cela reste un événement du moment que notre portail applicatif est accessible à notre client! Ce n'est pas un problème! (Oui oui je sais, j'ai des exemples imagés, je pousse l'explication à l’extrême pour bien comprendre).

Un incident quand à lui est n'importe quel événement qui a un impact, ou aura un impact sur le SLA, et dont la cause est connue!
En gros le service rendu est ou va être interrompu. Pour reprendre mon exemple précédent (oui j'insiste!), si la météorite tombe sur mon data center lorsque je suis dedans, cela reste un incident! On connaît la cause, la météorite! Je meurs écrasé, mais ce n'est pas un problème! :)

Un problème quand à lui, est n'importe quel événement qui impacte le SLA, mais dont la cause est inconnue!

Hormis le fait qu'on connaisse désormais la différence entre ces terminologies, les processus de traitement sont différents, ce qui in fine est le but!

La même en images:

Maintenant que nous comprenons la terminologie, voici un petit schéma pour comprendre le cycle de traitement ITIL d'un événement qui va impacter le SLA.

Cycle de traitement d'un incident ou d'un problème dans ITIL.

 
Un événement survient, il n'impacte ou ne vas pas impacter le SLA, il reste un événement et n'est pas pris en compte.
Si par contre il impacte ou va impacter le SLA, il devient automatiquement un incident. Cet incident peut indifféremment être déclenché par un événement constaté par le service IT, par une supervision du SI, ou encore par l'appel d'un utilisateur.
Dans ITIL il y a la notion de SPOC (Single Point of Contact), on n'utilise qu'un seul et unique point d'entrée pour toutes les demandes de services.
Le service desk niveau 1 vérifie donc l'incident, et regarde dans la CMDB voir quel élément (actif, software, hardware) est en cause, pour avoir toutes les informations sur celui-ci (garanties, notices, ...).
Il existe un lien entre ces élément, la KEDB, qui a pour fonction de voir si des problèmes sont déjà connus, et si il existe un ticket en cours concernant cet incident. Il existe également un lien avec l'historique des incidents et problèmes, afin de vérifier si cet incident a déjà été traité, et quelle solution a été mise en place, soit de manière définitive, soit de manière temporaire (workaround).
Un lien est fait avec le SLA, voir quel est l'impact de l'incident sur le SLA. Il y aura évidemment un niveau de priorité sur les incidents!

Si le technicien niveau 1 ne trouve aucune information et n'est pas en mesure de solutionner l'incident, alors que la cause est inconnue, cet incident se transforme en problème, et passe au niveau 2 et niveau 3.
Sur le même principe, les niveau 2 et 3 font le lien avec la CMDB pour rechercher des informations.
Ils lancent une RFC (Request For Change), afin de faire une demande de changement, pour résoudre définitivement le problème.
C'est l'ECAB (Emergency Change Advisory Board) qui a la charge de valider ou non la demande de changement. Il existe également le CAB qui est le pendant de l'ECAB, quand les cas ne sont pas urgents. Les personnes composant le CAB ou le ECAB peuvent être les mêmes, ou des personnes différentes. Pour faire partie du ECAB il faut évidemment être disponible souvent et rapidement, et avoir un pouvoir de décision.

La demande validée par l'ECAB, le changement passe au service conception, afin de "créer" le bout de code qui va solutionner le problème, ou alors planifier la mise en place de l'infrastructure nécessaire à la résolution du problème.
Le service conception créé le SDP (Service Design Package), qu'il va transmettre au service transition, qui a à charge la préparation de la mise en production dans de bonnes conditions du nouvel élément.
On réalise une revue post implémentation (PIR pour Post Implementation Review) pour vérifier que les actions ont eu l'effet attendu, et que cela fonctionne.

Nous mettons à jour la CMDB, ainsi que l'historique des incidents et problèmes.
Nous clôturons la Request For Change, car le changement a été implémenté, nous clôturons le problème, qui redeviens un incident, ensuite nous clôturons l'incident, et nous en informons le technicien niveau 1.
Charge ensuite au niveau de communiquer aux utilisateurs impactés, et à l'utilisateur qui a déclenché l'incident le cas échéant, la bonne résolution de celui-ci.

Voilà de manière schématique le cycle de vie d'un incident, ou d'un problème.
Je ne saurais que vous conseiller de vous former à ITIL, pour avoir des information exhaustives et complètes, et comprendre réellement ce qu'ITIL apporte dans une organisation informatique!

Je ferai un zoom sur d'autres spécificité d'ITIL plus tard, prochaine étape, notre migration d'infrastructure!


Pierre