Dernière mise à jour le : 24 octobre 2023
Dans le contexte économique dynamique actuel, des incidents majeurs peuvent frapper à l'improviste, nuisant à la productivité et la satisfaction client. Quel que soit le secteur, il s’avère essentiel d’établir des plans de reprise et de créer une culture de résilience pour assurer la continuité d’activité en cas de crise. Considérons une compagnie aérienne. Le transport aérien est complexe, de nombreux acteurs agissant de concert pour assurer l'efficacité. Les systèmes informatiques jouent un rôle clé dans le respect des horaires de vol. Les problèmes informatiques perturbent donc beaucoup d’utilisateurs. Par exemple, Zylker Airlines a récemment connu une interruption informatique, importunant des milliers de passagers.
Examinons la cause et les événements de l’interruption chez Zylker.
Cause de l’interruption
Les opérations aériennes de Zylker ont été paralysées par une interruption informatique. Le site Web de la compagnie affichait une erreur 502 : mauvaise passerelle, créant des problèmes de réservation, d’enregistrement, d’annulation et autres. La cause première de l’interruption informatique fut attribuée à une défaillance de pare-feu tiers.
Pour répondre à de nouvelles vulnérabilités et menaces, l’équipe du fournisseur publiait de nouvelles règles dans le pare-feu pour applications Web (WAF) à intervalle régulier, puis diffusait la mise à jour mondialement. Lors d’une mise à jour, un ingénieur de l’équipe a effectué une modification mineure qui a par erreur presque doublé l’utilisation du processeur dédié au service du trafic HTTP et HTTPS sur le réseau. Cela a rendu le site Web de la compagnie et les systèmes clés inaccessibles quelques heures.
Événements menant
à l’interruption
Dans la fenêtre de maintenance, les règles WAF mises à jour ont été appliquées, le système semblant fonctionner normalement. Plusieurs heures après la mise à jour, les utilisateurs ont commencé à signaler des problèmes d’accès au site Web. La DSI a décidé de rechercher la cause et, après 13 minutes, a déclaré un incident majeur et averti les intéressés. Entre-temps, il y eut un grand nombre d’appels signalant le problème.
Des membres de plusieurs équipes ont été réunis pour former une équipe d’intervention 33 minutes après que l’incident a eu lieu. L’équipe a étudié des hypothèses de cyberattaque. Il a fallu 53 minutes pour écarter la possibilité d’une cyberattaque, la cause première restant non identifiée.
Un examen plus poussé a permis à l’équipe de déterminer que l’on pouvait attribuer la cause de l’interruption à Ia mise à jour des règles WAF gérées. Elle a donc commencé à annuler Ia mise à jour pour rétablir le service. Le retour au fonctionnement normal a pris 78 minutes après l’interruption de l’application Web de la compagnie.
Malgré l’emploi de plusieurs applications et outils d’analyse, Zylker a commis des erreurs et n’a pas su bien faire face à la situation. Cet incident a mis en lumière le besoin d’un solide processus de gestion des incidents majeurs et de protocoles de communication efficaces pour atténuer l’impact de futures interruptions.
Création d’un
cycle de vie des demandes pour gérer les incidents majeurs dans ServiceDesk Plus
Voyons à présent ce qu’il serait advenu si Zylker Airlines avait adopté un processus de gestion des incidents simplifié et l’avait déployé avec ServiceDesk Plus. Elle aurait contenu l’interruption due à la mise à jour des règles WAF et atténué plus efficacement l’impact sur ses clients.
- ServiceDesk Plus permet à Zylker de suivre un cadre de bonnes pratiques (Fig. 1) pour veiller à parer efficacement aux incidents majeurs.
Fig. 1 : cadre de bonnes pratiques
Pour déployer ce cadre en temps réel, ServiceDesk Plus utilise un cycle de vie des demandes (RLC). On définit le cycle complet d’un ticket visuellement avec un simple canevas par glisser-déplacer. Cela subdivise le cycle de vie d’un ticket en divers états et transitions. Chaque ticket de ServiceDesk Plus passe par divers états comme ouvert, en attente, résolu et fermé. Un RLC sert à définir la séquence des états ainsi que les conditions et les actions (transitions) qu’exige chaque changement d’état par simple glisser-déplacer des états dans le canevas (Fig. 1.1).
Fig. 1.1 : canevas RLC à glisser-déplacer
Les transitions sont les actions requises pour que le ticket passe d’un état à un autre. À chaque étape, les transitions guident les techniciens dans les actions conditionnelles pour avancer à l’état suivant. Un technicien ne peut modifier l’état que via les transitions indiquées dans la page Détails du ticket d’incident (Fig. 1.2). Il existe trois étapes de transition : AVANT, PENDANT et APRÈS. Cela permet de définir de nombreuses options pour régir le changement d’état selon la réalisation des conditions prévues (Fig. 1.3). On peut associer le RLC à un ou plusieurs modèles d’incident.
Fig. 1.2 : page Détails d’incident
Fig. 1.3 : étapes de transition
Examinons la façon dont la fonction RLC aurait aidé Zylker à contenir l’incident majeur.
- Dans la fenêtre de maintenance, la mise à jour des règles WAF s’applique. ServiceDesk Plus s’intègre à plusieurs produits ITOM, dont ManageEngine OpManager, pour analyser les réseaux et les services. Lorsqu’OpManager identifie une anomalie des services, il enregistre automatiquement une alerte sous forme de ticket d’incident dans ServiceDesk Plus avec tous les détails afférents, comme la date et l’heure de l’interruption, les systèmes ou les applications touchés et les messages d’erreur reçus.
- Ce ticket utilise automatiquement le modèle d’incident majeur via une simple automatisation sans code, basée sur des règles. Une fois le ticket enregistré avec le modèle, le RLC d’incident majeur associé au modèle s’active instantanément et commence à guider le processus.
- Dans les trois minutes suivantes, l’agent d’assistance de Zylker évalue l’impact de l’incident pour éviter une fausse alarme et désigne le ticket comme un incident majeur en cliquant sur l’action de transition Déclarer dans la page Détails du ticket d’incident. Cela actualise l’état du ticket et l’affecte automatiquement à l’équipe d’intervention (IRT). Une notification instantanée est alors envoyée à tous les intéressés. On configure ces actions via les trois étapes de transition d’un RLC, expliquées ci-dessous.
Action AVANT :
Zylker a limité l’accès au bouton de transition Déclarer aux agents d’assistance ayant des rôles précis pour lesquels il faut afficher ce bouton, en ajoutant des conditions pour déterminer s’il doit figurer dans la page Détails de l’incident (Fig. 2). Si le type de demande est incident, le bouton de transition Déclarer ne s’affiche dans la page Détails d’incident que pour les techniciens jouant un rôle technique IT ou IRT.
Fig. 2 : action AVANT
Action PENDANT :
Lorsqu’on exécute la transition Déclarer, le champ S’agit-il d’un incident majeur ? est obligatoire, que l’agent d’assistance désigne ou pas le ticket comme un incident majeur. Si on le désigne comme un incident majeur, le champ Groupe de la page Détails de l’incident prend la valeur IRT (Fig. 3), transférant le ticket à la liste de l’équipe IRT.
Fig. 3 : action PENDANT
Action APRÈS :
Une fois la transition Déclarer exécutée, une notification personnalisée est automatiquement envoyée à l’équipe IRT (Fig. 4) pour l’informer de l’incident majeur. Outre les notifications, des webhooks, des tâches et des fonctions personnalisées peuvent aussi se déclencher selon les conditions. À l’exécution de la transition, l’état du ticket d’incident devient en-cours.
Fig. 4 : Action APRÈS
L’étape suivante consiste à effectuer un processus de triage. Pour la transition Collaborer avec IRT, Zylker a configuré une notification et ajouté une fonction personnalisée (Fig. 5) à l’action de transition APRÈS. ServiceDesk Plus s’intègre alors à Microsoft Teams pour créer un lien de centre de crise virtuel. Un clic sur la transition dans la page Détails de l’incident déclenche la notification personnalisée avec le lien de centre de crise virtuel à envoyer à l’équipe IRT distribuée, facilitant la collaboration entre les équipes travaillant en mode hybride. L’état du ticket prend automatiquement la valeur Triage.
Fig. 5 : fonctions personnalisées
- Lors du triage, les clients sont informés de l’interruption via la fonction d’annonce de ServiceDesk Plus pour éviter qu’ils n’inondent l’assistance de nouveaux tickets.
L’analyse des causes premières (RCA) démarre alors. Dans la transition d’analyse RCA (Fig. 6), des tâches déjà affectées à un technicien ou un groupe donné sont ajoutées à l’action APRÈS pour analyser la cause première.
Fig. 6 : transition d’analyse RCA
En cinq minutes, l’équipe IRT identifie la mise à jour des règles WAF comme la cause première et informe les acteurs concernés. De même, Zylker a configuré trois actions de transition à divers états du cycle de vie des incidents majeurs (Fig. 7) selon ses besoins.
Fig. 7 : cycle de vie des incidents majeurs de Zylker
- Une fois la cause première trouvée, le ticket d’incident est délégué à l’équipe concernée pour annuler la mise à jour des règles WAF. L’un des techniciens de Zylker annule la mise à jour et rétablit les services en 28 minutes. Toute l’équipe a pu identifier la cause première et résoudre le problème avant un impact notable.
- Une fois le problème résolu, les intéressés sont informés et la solution enregistrée dans la base de connaissances pour aider des techniciens à l’avenir.
Ainsi, les cycles dans le cadre de la gestion des incidents majeurs offrent une approche structurée pour remédier aux incidents critiques, protégeant l’entreprise des conséquences catastrophiques d’une interruption. Découvrez en détail la fonction RLC de ServiceDesk Plus ici.