Close

La voie vers une meilleure gestion des incidents
débute ici

Les rôles changeant de la gestion des incidents et des problèmes

Au cours de la dernière décennie, la gestion des incidents a bien évolué.

Les directives ITIL ont été actualisées. Les équipes informatiques ont commencé à partager leurs responsabilités avec les équipes DevOps et SecOps. Des systèmes toujours plus complexes ont conduit à une complexification des solutions de gestion des incidents. Et de nombreuses entreprises adoptent des post-mortems sans reproches et de nouvelles méthodes de mesure des performances.

La gestion des incidents continue d'évoluer tout comme sa cousine germaine, la gestion des problèmes, et la relation entre les deux pratiques.

Qu'est-ce qu'un problème et en quoi diffère-t-il d'un incident ?

Comme le définit ITIL, un problème est « une cause, ou une cause potentielle, d'un ou plusieurs incidents ».

Et un incident est un événement unique non planifié qui provoque une interruption de service.

En d'autres termes, les incidents sont les écueils que les employés d'astreinte s'efforcent de surmonter le plus rapidement et le plus exhaustivement possible. Et les problèmes sont la cause profonde de ces perturbations.

Un problème peut provoquer un ou plusieurs incidents. Et un incident peut avoir comme cause un voire plusieurs problèmes.

Colonne de serveurs avec un serveur basculant qui pose problème

Par exemple, la panne de 5 heures qui a coûté 150 millions de dollars à Delta Air Lines en 2016 était un incident. Le problème à l'origine de cet incident était une coupure de courant dans un centre d'opérations et, sans doute, l'absence de plan de secours en cas de coupure de courant.

De même, la panne de 12 heures de l'App Store qui a coûté à Apple environ 25 millions de dollars était un incident. Le problème derrière cette panne ? Un souci de DNS.

Pour utiliser des termes qui ne sont pas liés au monde de la technologie, se précipiter chez le médecin pour une migraine serait un incident. La cause de la migraine (allergies, problèmes de vue ou stress) serait le problème.

Gestion des problèmes et gestion des incidents

De toute évidence, les problèmes et les incidents sont inextricablement liés. L'un provoque l'autre et les équipes doivent être attentives aux deux.

Pour les équipes informatiques traditionnelles, les dernières directives ITIL demandent de gérer à la fois les problèmes et les incidents, mais séparément. La gestion des problèmes est une pratique axée sur la prévention des incidents ou la réduction de leur impact. La gestion des incidents est axée sur la résolution des incidents en temps réel.

L'avantage de l'approche ITIL est qu'elle priorise à la fois les objectifs principaux de la gestion des problèmes et de la gestion des incidents. En en faisant des pratiques distinctes à l'importance similaire, les directives tentent vraisemblablement d'éviter le problème courant des équipes informatiques qui résolvent constamment les incidents sans traiter la cause profonde.

Si le principal objectif d'un gestionnaire d'incidents est la résolution rapide des incidents et que celui d'un gestionnaire des problèmes est la prévention, la combinaison de ces rôles peut reléguer l'un de ces objectifs, qui sont tous deux essentiels pour une organisation, au second plan.

L'inconvénient de cette approche ? La séparation des deux pratiques, qui sont en réalité étroitement liées, peut créer des lacunes dans les connaissances ainsi qu'une rupture de la communication entre la résolution de l'incident et l'analyse de la cause profonde visant à identifier la cause sous-jacente.

DevOps et l'évolution des rôles de gestion des problèmes et des incidents

Comme d'habitude, le mouvement DevOps collaboratif a estompé les démarcations que l'on retrouve dans la pensée informatique traditionnelle, considérant la gestion des problèmes et des incidents non pas comme deux pratiques distinctes, mais comme les moitiés superposées d'une vision holistique.

Diagramme ITIL avec des cercles séparés pour la gestion des problèmes et des incidents, et diagramme DevOps avec diagramme de Venn pour la gestion des problèmes et des incidents

Ce changement découle non seulement du fait que les pratiques sont les deux revers d'une même médaille (prévenir et résoudre les incidents) mais aussi d'une approche DevOps qui affirme généralement ce qui suit :

  • Un incident a souvent plusieurs causes profondes
  • Les post-mortems doivent être sans reproches et inclure toute équipe impactée par un incident
  • La collaboration est au cœur de l'amélioration continue

Le chevauchement observé entre la gestion des problèmes et des incidents peut également être lié à l'évolution du secteur vers une approche « Vous le concevez, vous en êtes responsable ». À mesure que les équipes qui conçoivent les systèmes sont chargées de résoudre les incidents au sein de ces systèmes, il est logique qu'une même équipe soit responsable de l'exécution des post-mortems, de l'enquête pour déterminer la cause profonde d'un incident et de la formulation de recommandations pour prévenir ou atténuer l'impact des incidents futurs.

La passerelle entre la gestion des problèmes et des incidents est ici le post-mortem sans reproches, où, une fois l'urgence passée, les gestionnaires d'incidents se transforment en détectives et se tournent vers la gestion des problèmes et la prévention.

Le principal défi que devront relever les équipes DevOps qui ne font pas de véritable différenciation entre ces deux pratiques est de veiller à ce que la gestion des problèmes (et ses objectifs à long terme moins urgents, mais très précieux) ne soit pas reléguée au second plan par rapport à la gestion des incidents.

suivant
SRE