Comment exécuter un processus de gestion des incidents majeurs

Gérez et résolvez des incidents à très fort impact

La gestion des incidents majeurs (souvent simplement appelée gestion des incidents ici, chez Atlassian) est le processus utilisé par les équipes DevOps et informatiques opérationnelles pour répondre à un événement non planifié ou à une interruption de service et rétablir le service.

Qu'est-ce qu'un incident majeur ?

Alors, qu'est-ce qui constitue un incident majeur ? Un incident majeur est une panne ou une perte de service urgente.

La définition du niveau d'urgence varie d'une organisation à l'autre. Chez Atlassian, nous avons trois niveaux de gravité et les deux premiers (SEV 1 et SEV 2) sont tous deux considérés comme des incidents majeurs.

Si un service orienté client est en panne pour tous les clients Atlassian, il s'agit d'un incident SEV 1. Si le même service est en panne pour un sous-ensemble de clients, c'est un incident SEV 2. Tous deux relèvent de la catégorie des incidents majeurs et nécessitent une réponse immédiate de nos équipes de gestion des incidents.

Tout ticket qui n'interfère pas avec les tâches essentielles est considéré comme un SEV 3 et n'est pas un incident majeur.

Définissez votre processus de gestion des incidents majeurs

Le cycle de vie de l'incident (parfois appelé processus de gestion des incidents) est la voie que nous prenons pour identifier, résoudre les incidents, les comprendre et éviter de les répéter.

Les processus de gestion des incidents varient d'une entreprise à l'autre, mais la clé du succès de toute équipe est de définir et communiquer clairement les niveaux de gravité, les priorités, les rôles et les processus dès le début, avant qu'un incident majeur ne survienne.

Pour avoir une compréhension commune des priorités, des rôles et des processus, toute équipe qui élabore son processus de gestion des incidents majeurs ou le révise devrait commencer par obtenir des réponses claires aux questions suivantes :

• Qu'est-ce qui constitue un incident majeur pour notre entreprise/produit ?
• Comment définirons-nous les niveaux de gravité et de priorité des incidents ? En cas d'incidents majeurs multiples, comment saurons-nous lequel traiter en premier ?
• Qui est responsable de la gestion des incidents majeurs ? Quels rôles joueront les membres de l'équipe ? Comment ces rôles seront-ils définis et communiqués ?
• Quel processus les équipes vont-elles suivre en cas d'incident majeur ? Existe-t-il plus d'un processus, selon le type d'incident ?
• À quelle fréquence communiquerons-nous avec les parties prenantes, tant internes qu'externes ? Quel est notre plan de communication ?
• À quoi ressemblera notre planning d'astreinte pour les incidents majeurs ? Qui est responsable en cas d'incident à 2 h du matin ? Le week-end ? Pendant les vacances ?
• Quand et comment devrions-nous alerter notre gestionnaire d'incident d'astreinte, en priorisant la résolution rapide des incidents majeurs tout en évitant la fatigue d'alerte ?

Processus de gestion des incidents majeurs d'Atlassian

Chez Atlassian, notre processus de gestion des incidents comprend la détection, le signalement d'un nouvel incident, l'ouverture de canaux de communication, l'évaluation, l'envoi de communications initiales, la remontée, la délégation, l'envoi de communications de suivi, la révision et la résolution.

Détection

Tout d'abord, un incident est détecté soit par notre technologie, soit par les rapports des clients, soit par le personnel. La personne qui détecte l'incident (qu'il s'agisse d'un technicien qui remarque le problème ou d'un représentant du service client qui reçoit l'appel d'un client frustré) est chargée de consigner l'incident dans notre système et d'identifier un niveau de gravité.

Lorsqu'un incident arrive à nos équipes, un niveau de gravité 1, 2 ou 3 lui est déjà rattaché. Nous considérons les niveaux de gravité 1 et 2 comme des incidents majeurs, tandis que le niveau 3 indique un incident à plus faible impact.

Signalement d'un nouvel incident

Une fois qu'un ticket d'incident est créé, une notification est envoyée au professionnel d'astreinte responsable de ce service.

La page d'alerte que nous envoyons à Atlassian comprend des informations sur la gravité et la priorité de l'incident, ainsi qu'un résumé, permettant de savoir clairement et en un coup d'œil s'il s'agit d'une priorité absolue ou si cela peut attendre si un autre incident est en cours.

Ouverture de canaux de communication

Une fois que le gestionnaire d'incident reçoit une alerte, son premier objectif consiste à communiquer pour expliquer que l'incident est en cours de correction. Il passe l'incident à l'état « En cours de correction » et met en place les canaux de communication de l'équipe.

Il est essentiel de proposer des canaux de communication flexibles tout au long du processus de réponse aux incidents, permettant ainsi aux équipes d'utiliser leurs méthodes de communication préférées. Jira Service Management intègre plusieurs canaux de communication afin de réduire les temps d'arrêt. Entre autres, un widget d'état intégrable, une page d'état dédiée, les e-mails, les outils de chat, les réseaux sociaux et les SMS.

Évaluation

Le gestionnaire d'incident a été alerté, et les canaux de communication sont ouverts. Prochaine étape : évaluer l'incident lui-même.

Pour nos équipes, ce processus commence par une série de questions auxquelles elles doivent répondre :

• Quel est l'impact sur les clients et les employés d'Atlassian ?
• Que voient les clients ?
• Combien de clients sont touchés ? (Certains ? Tous ?)
• Quand l'incident a-t-il débuté ?
• Combien de dossiers de support ont été ouverts à propos de cet incident ?
• Y a-t-il d'autres facteurs en jeu qui impactent le niveau de gravité ou la priorité ou modifient la façon dont nous abordons l'incident ? (P. ex., problèmes de sécurité, crises RP sur les réseaux sociaux, etc.)

Une fois que nous aurons répondu à ces questions, nous pourrons avancer en toute confiance grâce aux diagnostics et aux corrections proposées ou modifier le niveau de gravité et de priorité d'un incident selon les besoins.

Envoi de communications initiales

Une fois que nous avons confirmé que l'incident est réel, la communication avec nos clients et nos employés devient une priorité absolue. Comme nous le disons dans notre manuel :

« L'objectif de la communication interne initiale est de concentrer la réponse aux incidents et de réduire la confusion. L'objectif de la communication externe est d'indiquer aux clients que vous êtes conscients d'une défaillance et que vous la traitez en urgence. »

Une communication rapide et précise aide à renforcer et à maintenir la confiance des clients.

Nous avons un plan stratégique de communication sur les incidents et nous fournissons des mises à jour d'état régulières dans un format simple. Nous envoyons également un e-mail à une liste de parties prenantes définie comprenant nos directeurs de l'ingénierie, responsables de la gestion des incidents majeurs ainsi que d'autres employés internes clés. Comme déjà mentionné, toutes ces méthodes de communication sont personnalisables dans Jira Service Management et peuvent être adaptées au plan de réponse aux incidents de n'importe quelle organisation.

Remontée

Parfois, un incident est résolu rapidement par l'équipe d'astreinte. Mais dans les cas où cela ne se produit pas, la prochaine étape consiste à faire remonter le ticket à un autre expert ou à une équipe d'experts plus apte à résoudre cet incident spécifique.

Dans Jira Service Management, les intervenants peuvent regrouper les tickets associés et ajouter des collaborateurs au ticket afin de coordonner les alertes. Ils peuvent également enregistrer automatiquement toutes les actions avec une chronologie d'incident détaillée, et accéder aux fonctions d'automatisation et à des articles de la base de connaissances pour examiner et résoudre rapidement les incidents.

Délégation

Une fois que le ticket a été remonté à une nouvelle personne, le gestionnaire d'incident lui délègue un rôle. Chez Atlassian, ces rôles sont prédéfinis, de sorte que les membres de l'équipe peuvent rapidement comprendre ce qu'on attend d'eux.

Parfois, les incidents majeurs nécessitent un seul gestionnaire d'incident et une petite équipe. D'autres fois, une situation peut exiger plusieurs responsables techniques ou même plusieurs gestionnaires d'incident. Le gestionnaire d'incident d'origine est chargé de déterminer quand c'est le cas et de faire appel aux personnes appropriées.

Envoi de communications de suivi

À mesure que l'incident progresse, d'autres communications en dehors de l'équipe technique aideront à garantir que les clients et les employés restent calmes, gardent confiance et sont informés. Ce processus est simple lorsque les collaborateurs peuvent gérer les alertes sur différentes plateformes de communication pour maîtriser la réponse aux incidents.

Révisez

Malheureusement, il n'existe pas de solution universelle pour résoudre les incidents. C'est pourquoi, à ce stade du processus, nous prenons le temps :

• d'observer ce qui se passe, et de partager et de vérifier les observations avec l'équipe ;
• de développer des théories relatives aux motifs de l'incident (et à la solution à apporter) ;
• de développer et de réaliser des expériences qui prouvent ou réfutent nos théories ;
• de répéter la procédure.

Tout au long de ce processus, le gestionnaire d'incident garde un œil attentif sur l'évolution de la situation. Des membres de l'équipe en particulier sont-ils surchargés ? Quelqu'un a-t-il besoin d'une pause ? Avons-nous besoin d'une nouvelle vision ? Si besoin, la délégation s'intensifie.

rapide

Selon notre manuel de gestion des incidents, un incident est résolu « lorsque l'impact sur l'activité actuelle ou imminente disparaît ».

À ce stade, l'urgence prend fin, et l'équipe passe à des tâches « de nettoyage » et aux post-mortems.

Post-mortems

Le cycle de vie de notre incident se termine lorsque l'incident est résolu. Mais chez Atlassian, notre processus ne s'arrête pas là. Nous voulons également faire tout ce qui est en notre pouvoir pour nous assurer qu'un incident ne se reproduise pas. C'est pourquoi l'étape suivante consiste en un post-mortem sans reproches conçu pour identifier la cause d'un incident et nous aider à réduire les risques à l'avenir.

Utilisez des modèles de post-mortem avec Jira Service Management pour créer et exporter facilement des rapports post-mortem (ainsi que les chronologies d'incident associées) vers Confluence afin que les intervenants puissent continuer à collaborer avec les équipes transverses pour surveiller les mesures de suivi et éviter des incidents similaires à l'avenir.

Rôles et responsabilités

Les rôles et responsabilités varient en fonction de la culture de votre organisation, de la taille de l'équipe, des plannings d'astreinte, et bien plus encore. Voici certains rôles communs liés aux incidents majeurs :

Gestionnaire d'incident : personne chargée de superviser la résolution de l'incident.

Responsable technique : technicien expérimenté chargé d'examiner la panne et le motif de cette dernière, de déterminer la meilleure marche à suivre et de diriger l'équipe technique.

Responsable des communications : professionnel de la communication (souvent membre des équipes de relations publiques ou de support client) chargé de communiquer avec les clients internes et externes touchés par l'incident.

Responsable du support client : personne chargée de s'assurer que les tickets, les tweets et les appels téléphoniques entrants reçoivent une réponse appropriée en temps opportun.

Responsable des réseaux sociaux : professionnel des réseaux sociaux chargé de communiquer à propos de l'incident sur les réseaux sociaux.

Citons encore quelques rôles communs :

Analyste des causes profondes ou gestionnaire des problèmes : personne responsable d'aller au-delà de la résolution de l'incident pour identifier la cause profonde et tout changement à apporter pour éviter que le problème ne se reproduise.

Comité d'enquête sur les incidents majeurs : groupe responsable des enquêtes et de la gestion des changements.

Une solution de gestion des incidents comme Jira Service Management vous aidera à chaque étape du processus de réponse, de l'organisation de votre planning d'astreinte et de vos alertes à l'unification des équipes pour optimiser la collaboration et à l'exécution des post-mortems d'incident.