Mettre en place une Gestion des Problèmes dans un service informatique est une évidence. Analyser clairement leurs impacts sur l’organisation est plus complexe. La définition ITIL d’un problème est : “la cause d’un ou plusieurs incidents”. L’enjeu de la gestion des problèmes est donc d’éliminer les causes des incidents, que ce soit de manière réactive ou proactive. Mais un incident n’est pas toujours le symptôme d’un problème …. Combien d’incidents faut-il pour considérer avoir un problème ? Jusqu’où tirer la pelote ? Aujourd’hui, nous allons nous pencher sur ces questions et voir comment gérer ce type de situations de manière efficace.
Soyez clair sur votre terminologie métier
L’objet principal d’ITSM est la gestion des services informatiques, mais les service desks dépendent plus des processus métiers internes que de la technologie, surtout quand ils sont externalisés.
Première question : connaissez-vous la différence entre un incident et un problème ? Ou plutôt, quelle est la définition d’un incident et d’un problème dans votre entreprise ?
Une interruption de service est un incident. Lorsqu’un système tombe en panne, votre équipe se concentre sur sa remise en marche et sur la restauration du service dans le cadre du Service Level Agreement (SLA) que vous avez signé avec vos clients. Cette correction peut être temporaire ou un peu “bricolée”, mais elle restaure le service.
Un exemple de problème est un défaut de fonctionnement du nœud A dans un cluster, provoquant une ou plusieurs interruptions de service. Le problème est lié à plusieurs incidents, et peut rester ouvert en arrière-plan, alors que l’incident est déjà résolu. Il faudra pourtant corriger le problème si on veut une solution pérenne pour que les incidents ne se produisent plus.
Définissez une stratégie de gestion des problèmes
Afin d’assurer une transition optimale des incidents aux problèmes, vous devez décider si vous gérerez vos problèmes de manière active ou proactive. Plus précisément :
- La gestion active (ou plutôt réactive) des problèmes correspond à une résolution de problèmes en réponse à un ou de plusieurs incidents. Dans l’exemple ci-dessus, lorsqu’un ou plusieurs services tombent, vous les restaurez, mais devriez créer aussi un ticket “problème” en parallèle, pour évaluer la cause de l’incident, par exemple « nœud A » et la corriger.
- La gestion proactive des problèmes a lieu quand vous identifiez ou résolvez un problème potentiel ou une erreur connue afin d’éviter des incidents futurs. En analysant le problème dans l’exemple mentionné plus haut, vous réalisez que le nœud A est lié au nœud B. Pour vous assurer que le nœud B n’aura pas de défaillance causant d’autres interruptions du service, vous modifiez rapidement les nœuds et vérifiez que la défaillance du nœud A n’impacte pas le nœud B. En procédant de la sorte, vous prenez de l’avance, et vous réduisez la probabilité d’autres interruptions du service.
Il est essentiel de mettre en place une stratégie d’entreprise combinant ces deux méthodes de gestion des problèmes. Beaucoup d’entreprises n’ont pas de stratégie, ou ne suivent qu’une seule méthode, ce qui n’est pas optimal pour le traitement des défaillances. En définissant une stratégie avant de mettre en œuvre des processus ITIL, vos équipes peuvent plus facilement assurer la transition des incidents aux problèmes, lorsque c’est nécessaire.
Pilotez le processus de transition
Le processus de transition est principalement axé sur la gestion réactive des problèmes. Mais une fois que l’entreprise a atteint un certain niveau de maturité, la gestion peut devenir proactive : c’est ce que nous allons explorer dans la section suivante.
Une fois vos services restaurés en appliquant un correctif dans le cadre de votre SLA, vous devez quand même enquêter pour savoir ce qui a provoqué l’incident. Surtout si des incidents sont liés ou s’il existe plusieurs incidents du même type. Vous devez créer un ticket “problème” et fournir autant de détails que possible : les résolutions de problèmes demandent de la minutie plutôt que de la vitesse.
Il est essentiel de catégoriser et de hiérarchiser les problèmes pour les confier aux équipes les plus à même de les résoudre dans les délais impartis. Après avoir étudié le problème de manière approfondie, vous documenterez les informations et les détails et chercherez à appliquer une solution permanente.
Bien souvent, la correction peut entraîner une demande de modification, qui peut être standard, urgente ou normale, en fonction de l’urgence et de l’impact de la correction requise.
Partagez des bonnes pratiques
Le partage des bonnes pratiques est le facteur clé qui permet d’assurer une transition en douceur des incidents aux problèmes de manière organisée, autrement dit, une gestion proactive des problèmes.
Comme indiqué plus haut, une fois que vous aurez détaillé l’erreur et sa correction, vous commencerez à créer une KEDB – Known Error DataBase (une base de données des erreurs connues).
Elle vous permettra de structurer les liens entre incidents et problèmes, et comprendra les informations suivantes :
- Informations / liens sur les incidents passés
- Catégorie : classification des informations facilitant leur récupération
- Cause première : la raison initiale d’un incident ou d’un problème
- Erreur : le défaut à résoudre
- Contournement : la correction temporaire
- Résolution : la solution définitive, incluant souvent des informations sur la demande de changement.
Si le même incident ou des incidents similaires se produisent à l’avenir, vous et votre équipe saurez-vous les résoudre et restaurer les services plus rapidement ? À chaque fois, mettez à jour la KEDB, au fur et à mesure que vous traitez les incidents ou identifiez de nouveaux problèmes. Lorsque vous disposerez de suffisamment d’information, vous pourrez identifier des tendances. Par exemple : si la mise à jour trimestrielle d’un logiciel donné est connue pour provoquer des bugs, vous saurez quelle solution alternative appliquer pour éviter des incidents. Vous aurez également mis en place un processus de modification standard, pour planifier et appliquer un correctif à long terme pendant les temps d’arrêt.
Lorsque de nouveaux incidents se produisent, le processus se répète, en passant de plus en plus de réactif à proactif, ce qui permet d’améliorer les transferts entre incidents et problèmes.
Conclusion
Valiantys a tiré profit de son expérience client et de son expertise de pointe pour élaborer une solution parfaitement adaptée à ces scénarios, reposant sur Jira Service Desk et Confluence. Nous avons également intégré des améliorations basées sur Opsgenie et Statuspage pour proposer des processus de gestion des incidents à une plus large échelle.
Pour mettre en place une relation efficace et symbiotique entre la gestion des incidents et celle des problèmes, il faut disposer d’une stratégie métier adaptée, des outils adéquats et des bonnes personnes. Améliorer la disponibilité du service, en réduisant le nombre d’incidents et leur temps de résolution augmente la satisfaction client. Plus globalement, cela permet aux entreprises d’être plus agiles et compétitives, grâce à une disponibilité élevée de leurs services, ce qui en fin de compte, génère de la valeur pour toutes les parties prenantes.
Améliorer ma satisfaction client
