Qu'est-ce que la gestion des incidents ?

Types de processus de gestion des incidents

Selon leur type, les entreprises ont tendance à s'orienter vers différents types de processus de gestion des incidents. Il n'existe pas de processus unique qui convienne à toutes les entreprises, c'est pourquoi il est probable que les approches varient d'une entreprise à l'autre.

De nombreuses équipes s'appuient sur un processus de gestion des incidents de type informatique plus traditionnel, tel que ceux décrits dans les certifications ITIL. D'autres équipes s'orientent vers un processus de gestion des incidents plus proche de celui de l'ingénieur chargé de la fiabilité du site (SRE) ou de DevOps.

Processus de gestion des incidents informatiques

Un processus de gestion des incidents aide les équipes informatiques à enquêter, à consigner et à résoudre les interruptions ou les pannes de service. Le workflow de gestion des incidents ITIL vise à réduire les temps d'arrêt et à minimiser l'impact sur la productivité des employés en cas d'incident. En utilisant des modèles conçus pour gérer les incidents, vous pouvez créer un workflow de gestion des incidents reproductible, qui garantit que les équipes consignent, diagnostiquent et résolvent les incidents et disposent d'un enregistrement de leurs activités.

Le framework (ou référentiel) ITIL est principalement utilisé par les équipes informatiques qui fournissent des services au sein des entreprises. En général, les équipes prennent ce dont elles ont besoin dans ITIL, qui couvre presque tous les types d'incidents et de problèmes et processus auxquels les équipes informatiques peuvent être confrontées, et laissent le reste. ITIL est idéal lorsque les équipes doivent se concentrer sur l'instauration d'une culture de résolution active des problèmes. Les processus prescrits aident les équipes à suivre les incidents et les actions de manière cohérente, ce qui améliore les rapports et analyses, et peut conduire à un service plus sain et à une équipe plus performante.

Étapes du processus de gestion des incidents informatiques

Identifier un incident et le consigner

Un incident peut avoir de multiples causes : un employé, un client, un fournisseur, des systèmes de surveillance. Quelle que soit la source, les deux premières étapes sont simples : une personne identifie un incident et une autre le consigne. Ces journaux d'incident (c.-à-d. les tickets) comprennent généralement ce qui suit :

• le nom de la personne qui signale l'incident ;
• la date et l'heure de signalement de l'incident ;
• une description de l'incident (le composant en panne ou qui ne fonctionne pas correctement) ;
• un numéro d'identification unique assigné à l'incident, pour le suivi.

Catégoriser

Assignez une catégorie logique et intuitive (et une sous-catégorie, selon les besoins) à chaque incident. Cela vous permet d'analyser vos données pour rechercher des tendances et des schémas, une étape indispensable à une gestion efficace des problèmes et à la prévention d'incidents futurs.

Définir des priorités

Chaque incident doit se voir assigner une priorité. Commencez par évaluer son impact sur l'entreprise, le nombre de personnes qui seront touchées, tout SLA applicable, ainsi que les répercussions potentielles en termes de finances, de sécurité et de conformité. Comparez cet incident à tous les autres incidents ouverts pour déterminer sa priorité relative.

Répondre

• Diagnostic initial : dans l'idéal, votre équipe de support de première ligne peut suivre un incident depuis le diagnostic jusqu'à sa clôture. Cependant, si elle n'y parvient pas, l'étape suivante consiste à consigner toutes les informations pertinentes et à les faire remonter à l'équipe du tier suivant.
• Remontée : l'équipe suivante prend les données consignées et poursuit le processus de diagnostic, et, si cette équipe ne peut pas diagnostiquer l'incident, elle passe la main à l'équipe suivante.
• Communication : l'équipe partage régulièrement des mises à jour avec les parties prenantes internes et externes impactées.
• Enquête et diagnostic : le processus se poursuit jusqu'à ce que la nature de l'incident soit identifiée. Les équipes font parfois appel à des ressources extérieures ou à des membres d'autres services internes pour aider à la résolution.
• Résolution et récupération : lors de cette étape, l'équipe établit un diagnostic et suit les étapes nécessaires pour résoudre l'incident. La récupération implique simplement le temps nécessaire pour reprendre le cours normal des opérations, car certaines corrections (comme les corrections de bug, par exemple) peuvent nécessiter des tests et un déploiement, et ce, même après que la résolution appropriée a été identifiée.
• Clôture : si l'incident a fait l'objet d'une remontée, il est ensuite renvoyé au centre de services pour être clôturé. Afin de maintenir la qualité et d'assurer un processus en douceur, seuls les employés du centre de services sont autorisés à clôturer les incidents. En outre, le propriétaire de l'incident devrait vérifier auprès de la personne qui l'a signalé que la résolution est satisfaisante et que l'incident peut réellement être clôturé.

Incidents, problèmes et changements : quelle est la différence ?

Les équipes informatiques rencontrent généralement différents types de tickets. Nous les classons afin de pouvoir leur appliquer les techniques de gestion appropriées.

• Demande de service : une demande formelle venant d'un client pour la fourniture de quelque chose, un nouvel ordinateur portable, par exemple.
• Incident : toute interruption non planifiée d'un service informatique ou réduction de la qualité d'un service (la panne du site web, par exemple).
• Problème : un problème est la cause profonde sous-jacente d'un incident (mauvaise configuration d'un serveur, par exemple). C'est ce que vous souhaitez maîtriser afin d'éviter les incidents.
• Changement : une action que vous entreprenez. Il existe trois types de changement : standard, normal ou urgent. Un changement standard a une procédure établie. Un changement normal est souvent non banal et doit passer par un processus d'approbation. Un changement urgent est mis en place immédiatement et, idéalement, testé avant d'être déployé.

Processus de gestion des incidents DevOps et SRE

Grâce à une approche DevOps ou SRE de la gestion des incidents, l'équipe qui conçoit le service l'exécute et le corrige également en cas de problème. Cette approche a explosé en popularité parallèlement à la croissance des services cloud disponibles en continu, des apps web consultées à l'international, des microservices et des logiciels en tant que service.

De plus en plus, les logiciels sur lesquels vous comptez pour vivre et travailler ne sont plus hébergés sur un serveur au même endroit que vous. C'est comme une app déployée sur un data center et accessible sur le Web par des milliers ou des millions d'utilisateurs à travers le monde. Pour les équipes chargées d'exécuter ces services, l'agilité et la vitesse sont primordiales. De plus, tout temps d'arrêt peut affecter des milliers d'organisations, pas seulement une.

Un des avantages de l'approche « you build it, you run it » (Vous le concevez, vous en êtes responsable) ? Elle offre la flexibilité dont les équipes Agile ont besoin. Cependant, elle peut aussi être floue quant aux responsabilités de chacun et aux délais. Les équipes DevOps peuvent être à l'aise et réussir grâce à des processus de développement moins structurés. Il est cependant préférable de standardiser un ensemble de processus de base pour la gestion des incidents. Ainsi, vous n'aurez aucun doute sur la manière de répondre à un incident, et vous pourrez suivre les tickets et créer des rapports sur leur résolution.

Trois croyances des équipes de gestion des incidents DevOps

• Soyez d'astreinte à tour de rôle : plutôt que de laisser certains membres de l'équipe se spécialiser dans les astreintes, les équipes DevOps alternent généralement selon un planning d'astreinte dans lequel tous leurs membres partagent le fardeau d'être potentiellement réveillé en pleine nuit pour répondre à un incident.
• L'ingénieur qui a développé la fonctionnalité est la meilleure personne pour corriger le bug : l'idée centrale de la philosophie « you build it, you run it » est que les personnes les plus familières avec le service (les développeurs) sont les plus à même de corriger une panne.
• Développez rapidement, mais soyez responsable : lorsque les ingénieurs et les membres de leur équipe savent qu'ils doivent assumer les pannes, ils vous incitent d'autant plus à déployer un code de qualité.

Cette approche garantit des temps de réponse rapides et un feedback accéléré aux équipes qui ont besoin de savoir comment développer un service fiable.

Nous présentons une approche de la gestion des incidents compatible avec DevOps dans notre manuel de gestion des incidents Atlassian.

Outils de gestion des incidents

La gestion des incidents ne se fait pas uniquement grâce à un outil, mais en associant les bons outils, les bonnes pratiques et les bonnes personnes. Voici certaines des catégories d'outils les plus courantes pour une gestion des incidents efficace :

• Suivi des incidents : chaque incident doit être suivi et documenté afin que vous puissiez identifier les tendances et faire des comparaisons au fil du temps.
• Groupe de discussion : une communication écrite en temps réel est fondamentale pour diagnostiquer et résoudre l'incident en équipe. De plus, elle offre un riche ensemble de données pour l'analyse ultérieure des réponses.
• Chat vidéo : le chat vidéo complète le chat écrit pour de nombreux incidents. Le chat vidéo d'équipe peut permettre d'aborder les résultats et de cartographier une stratégie de réponse.
• Système d'alerte : un outil comme Opsgenie s'intègre à votre système de surveillance et gère les rotations d'astreinte et les remontées.
• Outil de documentation : un outil tel que Confluence peut consigner les documents d'état d'incident et les post-mortems.
• Statuspage : communiquer l'état aux parties prenantes internes et aux clients via Statuspage permet de tenir en permanence tout le monde au courant.