« Gestion du cycle de vie des incidents ? Si nous parvenons à survivre d'un incident à l'autre, c'est une bonne journée. Les mauvais jours, c'est la panique. »

Malheureusement, c'est la réalité de gestion du cycle de vie des incidents Pour beaucoup trop d'entreprises de logiciels et d'informatique, il n'est pas nécessaire que cela se passe ainsi. La vérité est qu'une gestion du cycle de vie des incidents authentique et proactive peut empêcher les équipes de réponse aux incidents de tomber dans un mode de survie chronique ou de panique.

La gestion du cycle de vie des incidents est un cadre permettant de catégoriser, de répondre, de résoudre et de documenter les incidents afin qu'ils puissent être traités efficacement avec une perte de services minimale et un suivi bien organisé. Un cadre de résolution des incidents de bout en bout est essentiel pour maintenir les services critiques.

Gestion des incidents centrée sur le client

La plupart des systèmes modernes de gestion des incidents sont basés à un degré ou à un autre sur le modèle ITIL, développé pour la première fois dans les années 1980 par l'Agence centrale de l'informatique et des télécommunications du gouvernement britannique. Le modèle ITIL est centré sur le maintien des services aux clients et aux consommateurs, par opposition au maintien des systèmes clés strictement selon les spécifications techniques. Cela en fait un modèle idéal modèle de réponse aux incidents dans les applications orientées vers l'extérieur, où la maintenance des services utilisateur est d'une grande importance. Les éléments les plus importants du modèle ITIL à garder à l'esprit lors de la mise en place d'un cadre de gestion du cycle de vie des incidents sont les suivants :

Réponse initiale

Il s'agit de la phase au cours de laquelle les alertes entrantes sont enregistrées, catégorisées et acheminées vers les équipes appropriées. À bien des égards, il s'agit de la partie la plus importante du cycle de vie de la gestion des incidents, car c'est à ce moment-là que vous détectez les problèmes et que vous les résolvez. filtrer le bruit (alertes non exploitables), définissez les priorités et déterminez où chaque alerte doit être acheminée.

Une mauvaise gestion de cette partie du processus peut entraîner l’oubli d’alertes importantes, leur traitement avec une priorité trop faible ou leur acheminement vers les mauvais intervenants, ainsi que des charges de travail déséquilibrées pour les équipes d’intervention.

Réponse de niveau 1

Une fois qu'une alerte a été catégorisée, elle est envoyée à une équipe d'intervention de niveau 1. Les équipes de niveau 1 sont les premiers intervenants ; leur tâche consiste à résoudre l'incident à la satisfaction du client, généralement dans un délai spécifié. L'équipe de niveau 1 enquêtera sur l'incident, déterminera le problème de base et appliquera les mesures correctives connues ou recommandées dans la mesure du possible.

Le support de niveau 1 surveille également l'état de l'incident, notamment en ce qui concerne l'escalade. Une autre responsabilité clé du support de niveau 1 est de maintenir la communication avec le client concerné et de fournir des mises à jour de l'état à des intervalles qui peuvent être définis par contrat ou par les politiques de l'organisation. Cela permet de maintenir un canal de communication et de support cohérent, même si l'incident a été transmis au support de niveau supérieur.

Réponse de niveau 2

Si un incident dépasse la capacité de diagnostic et de résolution rapide du support de niveau 1, il est généralement transmis à une équipe de support de niveau 2, qui sera généralement en mesure d'apporter davantage de ressources et d'expérience.

Les équipes de niveau 2 peuvent également faire appel à un support spécialisé et tiers (fabricants, fournisseurs, etc.). L'objectif de base du support de niveau 2 reste le même que celui du niveau 1 : rétablir le service au client le plus rapidement possible.

Rapport et examen post-résolution

Le modèle formel ITIL décompose ce processus en deux processus : clôture et évaluation, et reporting de gestion des incidents. Pour de nombreuses organisations, notamment les plus petites, il peut être plus pratique de les combiner en un seul processus.

Les éléments clés de tout récapitulatif post-résolution sont de vérifier, d'enregistrer et d'évaluer la résolution (ou son absence) et de signaler pleinement les détails de l'incident (généralement avec un rapport d'autopsie ). Incident post-mortem les rapports devraient être saisis dans une base d’informations accessible aux équipes d’intervention et aux gestionnaires, et suffisamment indexée et consultable pour servir de source d’information facilement accessible pour répondre aux incidents futurs (et, espérons-le, les prévenir).

Autres questions clés

En plus des éléments énumérés ci-dessus, le modèle ITIL inclut deux autres facteurs qui entrent en jeu dans tout système réaliste de gestion du cycle de vie des incidents :

Gestion des incidents majeurs

Les incidents majeurs sont généralement ceux qui représentent une menace immédiate et grave pour le fonctionnement ou la sécurité de l'infrastructure de base ou des services clés. L'objectif est toujours de remettre le système en marche le plus rapidement possible, mais la priorité et le niveau de réponse initial peuvent être beaucoup plus élevés. Un incident majeur peut être directement transmis au niveau 2, à une équipe d'assistance spécialisée, voire à une assistance tierce (par exemple, si un composant important de l'infrastructure matérielle tombe en panne).

Chaque organisation peut avoir ses propres normes concernant ce qui constitue un incident majeur, mais pour la plupart des organisations, il est important de reconnaître que les incidents majeurs forment leur propre catégorie, avec un niveau de priorité et de réponse nettement plus élevé.

Solutions de contournement

Étant donné que l'une des principales priorités de la gestion des incidents dans le modèle ITIL est de maintenir ou de restaurer le service client le plus rapidement possible, la résolution initiale peut impliquer des solutions de contournement, par exemple une restauration. Cela est vrai à tous les niveaux. La logique est simple : si vous restaurez le service client maintenant, vous avez résolu le problème immédiat et le IL ou équipe de développement peut alors prendre tout le temps nécessaire pour résoudre les problèmes sous-jacents.

Il est important de consigner et d'identifier toutes les solutions de contournement, à la fois dans le système de rapport d'incident et lors de la planification des mises à jour informatiques et de développement, car chaque solution de contournement entraîne dette technique , dont le coût augmente généralement à mesure que le délai de paiement se prolonge. Cela signifie que les solutions de contournement résultant de Réponse aux incidents doivent être remplacés par des solutions conformes aux normes de conception du système dès qu'il est possible de le faire. À bien des égards, un incident n'est pas entièrement résolu tant que les solutions de contournement n'ont pas été remplacées par des solutions plus permanentes.

Il n’est pas vraiment nécessaire que votre équipe d’intervention en cas d’incident fonctionne en mode survie au jour le jour. Dans un monde où il n’a jamais été aussi coûteux de ne pas être préparé aux problèmes ayant un impact sur les clients, cela introduit le chaos et l’anxiété dans l’équation.

Avec un Cadre de gestion du cycle de vie des incidents Adapté aux besoins de votre organisation, vous pouvez maintenir les applications et infrastructures critiques en fonctionnement avec un minimum d'interruptions de service et de stress. La mise en œuvre des meilleures pratiques en matière de cycle de vie des incidents est la clé de la fiabilité, et la fiabilité elle-même est un service indispensable qui contribuera à définir votre réussite à long terme.