« 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 générale. »

Malheureusement, c'est la réalité de gestion du cycle de vie des incidents C'est le cas pour beaucoup trop d'entreprises de logiciels et de services informatiques, mais il n'est pas nécessaire qu'il en soit ainsi. En réalité, une gestion proactive et authentique du cycle de vie des incidents permet d'éviter que les équipes de réponse aux incidents ne sombrent 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 traiter, de résoudre et de documenter les incidents afin de les gérer efficacement, de minimiser les interruptions de service et d'assurer un suivi rigoureux. Un cadre de résolution des incidents de bout en bout est essentiel au maintien des services critiques.

Gestion des incidents centrée sur le client

La plupart des systèmes modernes de gestion des incidents s'appuient, à des degrés divers, sur le modèle ITIL, initialement développé dans les années 1980 par la Central Computing and Telecommunications Agency (CCTA) du gouvernement britannique. Le modèle ITIL est axé sur la continuité des services aux clients, plutôt que sur la maintenance des systèmes critiques selon des spécifications techniques strictes. C'est ce qui 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 aux utilisateurs est primordiale, les éléments les plus importants du modèle ITIL à prendre en compte lors de la mise en place d'un cadre de gestion du cycle de vie des incidents sont :

Réponse initiale

C’est la phase durant laquelle les alertes entrantes sont enregistrées, catégorisées et acheminées vers les équipes concerné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 que les problèmes sont détectés et filtrer le bruit (alertes non exploitables), définissez les priorités et déterminez où chaque alerte doit être acheminée.

Un défaut de gestion adéquate de cette partie du processus peut entraîner le non-détection d'alertes importantes, leur traitement à un niveau de priorité trop faible ou leur acheminement vers les mauvais intervenants, ainsi qu'un déséquilibre de la charge de travail des équipes d'intervention.

Réponse de niveau 1

Une fois l'alerte catégorisée, elle est transmise à une équipe d'intervention de niveau 1. Ces équipes interviennent en premier ; leur mission est de résoudre l'incident à la satisfaction du client, généralement dans un délai imparti. L'équipe de niveau 1 enquête sur l'incident, identifie le problème à la source et applique, dans la mesure du possible, les solutions connues ou recommandées.

Le support de niveau 1 assure également le suivi de l'état de l'incident, notamment en ce qui concerne son escalade. Une autre responsabilité essentielle du support de niveau 1 est de maintenir la communication avec le client concerné et de fournir des mises à jour régulières, conformément aux modalités contractuelles ou aux politiques de l'entreprise. Ceci permet de garantir un canal de communication et un support continus, même si l'incident a été transféré à un niveau de support supérieur.

Réponse de niveau 2

Si un incident dépasse les capacités 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 de mobiliser davantage de ressources et d'expérience.

Les équipes de niveau 2 peuvent également faire appel à des services d'assistance spécialisés et à des prestataires externes (fabricants, fournisseurs, etc.). L'objectif principal de l'assistance de niveau 2 reste le même que celui du niveau 1 : rétablir le service pour le client le plus rapidement possible.

Rapports et examens post-résolution

Le modèle ITIL formel décompose cela en deux processus : la clôture et l’évaluation, et la gestion des incidents et leur signalement. 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 bilan post-résolution consistent à vérifier, consigner et évaluer la résolution (ou son absence), et à rendre compte intégralement des détails de l'incident (généralement avec un rapport détaillé). rapport d'autopsie ). Incident post-mortem Les rapports doivent être saisis dans une base d'informations accessible aux équipes d'intervention et aux responsables, 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 points clés

Outre les é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 présentent une menace grave et immédiate pour le fonctionnement ou la sécurité des infrastructures essentielles ou des services critiques. L'objectif reste de rétablir le système au plus vite, mais la priorité et le niveau de réponse initial peuvent être nettement plus élevés. Un incident majeur peut être pris en charge directement au niveau 2, par une équipe de support spécialisée, voire par un prestataire externe (par exemple, en cas de panne d'un composant matériel essentiel).

Chaque organisation peut avoir ses propres critères pour définir ce qui constitue un incident majeur, mais pour la plupart des organisations, il est important de reconnaître que les incidents majeurs forment une catégorie à part, avec un niveau de priorité et de réponse nettement supérieur.

Solutions de contournement

L'une des priorités absolues de la gestion des incidents dans le modèle ITIL étant de maintenir ou de rétablir le service client le plus rapidement possible, la résolution initiale peut impliquer des solutions de contournement, comme une restauration. Ceci est valable à tous les niveaux. Le raisonnement est simple : si vous rétablissez le service client immédiatement, vous résolvez le problème immédiat et… IL ou équipe de développement peuvent 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 signalement des incidents 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 avec la durée du retard de paiement. Cela signifie que les solutions de contournement résultant de réponse aux incidents Il convient de les remplacer dès que possible par des solutions conformes aux normes de conception des systèmes. À 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 pérennes.

Il n'est absolument pas nécessaire que votre équipe d'intervention en cas d'incident fonctionne en mode survie au quotidien. 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, une telle situation introduit le chaos et l'anxiété dans l'équation.

Avec un cadre de gestion du cycle de vie des incidents Adaptée aux besoins de votre organisation, cette solution vous permet de maintenir la disponibilité de vos applications et infrastructures critiques avec un minimum d'interruptions de service et de stress. La mise en œuvre d'un cycle de vie des incidents conforme aux meilleures pratiques est essentielle à la fiabilité, et cette dernière est un service indispensable qui contribuera à votre succès à long terme.