Manuel de gestion

des incidents
Si vous faites partie d'une équipe de
développement ou opérationnelle,
responsable de services pour des clients
nécessitant une disponibilité 24 h/24 et
7 j/7, ce manuel est fait pour vous.

Vous avez des questions ?

Contactez-nous à l'adresse [email protected]
Sommaire

5 Avant-propos 41 Chapitre 3 : Post-mortems des

Ou : Comment j'ai appris à arrêter de incidents
m'en faire et à aimer les astreintes 42 Qu'est-ce qu'un post-mortem ?
42 Pourquoi réalisons-nous des post-
11 Chapitre 1 : Présentation des incidents mortems ?
12 Présentation 43 Quand un post-mortem est-il requis ?
12 À qui est destiné ce guide ? 43 Qui réalise un post-mortem ?
13 Qu'est-ce qu'un incident ? 44 Pourquoi les post-mortems doivent-ils
13 Nos valeurs en matière d'incidents être sans reproche ?
16 Exigences relatives aux outils 45 Aperçu du processus de post-mortem
17 Une remarque sur le suivi des incidents 47 Champs d'un ticket post-mortem
18 Gestionnaire d'incident 54 Causes directes et profondes
56 Catégories de causes et mesures
19 Chapitre 2 : Réponse aux incidents associées
20 Détection 57 Causes profondes avec dépendances
22 Communication ouverte externes
25 Évaluation 60 Mesures post-mortem
27 Envoi des communications initiales 62 Réunions post-mortem
29 Comment communiquez-vous 65 Approbations de post-mortem
avec vos clients lors d'une panne ? 65 Comment sont suivies les mesures
31 Remontée post-mortem ?
31 Délégation
33 Envoi de communications de suivi 68 Aide-mémoire du gestionnaire
35 Itération d'incident
36 Résolution
38 Astuces pour bien rédiger un rapport
d'incident

3
4 MANUEL DE GESTION DES INCIDENTS ATLASSIAN
Avant-propos
Ou : Comment j'ai appris à arrêter de m'en faire et à aimer
les astreintes

PAR JIM SEVERINO, DEVELOPMENT SR. TEAM LEAD, ATLASSIAN

Au début de l'année 2014, sous l'impulsion de l'évolution du secteur vers la

technologie SaaS, la suite Atlassian Cloud est passée d'un ensemble bricolé
de nos logiciels téléchargeables à un véritable système « cloud natif ».
Ce grand bouleversement a nécessité une planification et une exécution
minutieuses dans la majeure partie de l'entreprise. Pendant huit mois, une
équipe s'est employée à faciliter la gestion des utilisateurs et des groupes
pour nos clients Cloud en les standardisant pour tous nos produits. Ainsi,
au lieu de devoir gérer les utilisateurs et les groupes séparément dans
chaque produit, chaque client aurait un ensemble unique d'utilisateurs et de
groupes et une seule interface pour les gérer.

« Au début, tout se passait bien… jusqu'à

ce dossier de support pour le moins
intéressant.
Finalement, nous étions prêts. Pendant plusieurs semaines, nous avons
progressivement déployé le changement auprès de tous nos clients. Au début,
tout se passait bien… jusqu'à ce dossier de support pour le moins intéressant.
Un client affirmait que ses utilisateurs pouvaient voir des contenus auxquels
ils n'auraient pas dû avoir accès. Après enquête, nous avons réalisé que
dans certains cas extrêmes, le déploiement avait reconfiguré les groupes de
certains clients et supprimé des contrôles d'accès existants. Certains de ces
utilisateurs avaient ainsi pu accéder à des contenus censés leur être interdits.

AVANT-PROPOS 5
Nous avons immédiatement compris qu’il s’agissait là d’un problème très
grave et nous avons réagi sans délai. Compte tenu de son impact et bien
qu'il ait touché un nombre relativement limité de clients, nous avons traité
ce problème comme une priorité absolue. Nous avons rapidement publié
un correctif… du moins, c'est ce que nous pensions (et je parie que vous
devinez la suite). Il s'est avéré que ce « correctif » avait en fait aggravé le
problème : nous avions par inadvertance maximisé l'impact d'un ordre de
grandeur. Désormais, le problème ne se limitait plus à quelques utilisateurs
d'un nombre limité de clients : des milliers d'utilisateurs chez des centaines
de clients pouvaient voir du contenu auquel ils n'auraient pas dû avoir accès.
C'était un imbroglio impliquant une configuration incorrecte des contrôles
d'accès, et certains de nos meilleurs clients étaient furieux, ce qui est
compréhensible.

« Une fois l'incident résolu et l'ordre rétabli,

nous avons commencé à nous interroger :
qu'est-ce qui avait mal tourné pour en
arriver là ?
L'incident qui s'en est suivi a demandé des semaines de travail à bon
nombre d'équipes, nécessité plusieurs nuits blanches et le recours à du
personnel allant de l'ingénierie aux relations publiques. Les plans existants
ont été mis à la poubelle, les vacances annulées et les salles de réunion
bouclées en tant que « salles de crise » pendant des semaines. Une fois
l'incident résolu et l'ordre rétabli, nous avons commencé à nous interroger :
qu'est-ce qui avait mal tourné pour en arriver là ? Comment aurions-nous pu
éviter cette situation ou améliorer notre réponse à cet incident ? Pourquoi
n'avions-nous pas tiré de leçons d'incidents similaires dans le passé ?
Les réponses à ces questions nous ont permis de définir les processus de
réponse aux incidents et de post-portem présentés dans ce manuel.

6 MANUEL DE GESTION DES INCIDENTS ATLASSIAN

De nombreuses organisations découvrent la nécessité des processus de
réponse aux incidents et de post-mortem de la même manière : elles sont
confrontées à un incident majeur qui tourne mal, et elles décident de ne
plus jamais le laisser se reproduire. Dans cette situation, il est tentant de
concevoir un processus de réponse aux incidents visant à éradiquer les
incidents. Après tout, les incidents doivent être évités, non ? À choisir, nous
préférerions ne jamais en rencontrer, alors pourquoi ne pas essayer de les
éviter tous ?

Pour tenter d'éliminer les incidents, les organisations introduisent souvent

des barrières de sécurité, des points de contrôle et d'autres freins dans leurs
processus de conception, de développement et de livraison de logiciels.
Elles tentent de prévenir ou de bloquer les incidents en introduisant
des comités consultatifs sur les changements (CAB) et des réunions
hebdomadaires de livraison pour scruter le moindre changement afin
qu'aucun bug ne puisse s'immiscer. C'est une réaction compréhensible
aux incidents, mais ce n'est pas la meilleure. Les barrières et les points
de contrôle des changements ralentissent le rythme de changement de
l'organisation, ce qui tend à réduire le taux d'incidents à court terme, mais
surtout à freiner votre dynamique. Souvent, les changements dans le
backlog s'accumulent derrière les barrières établies, avec pour conséquence
des lots de changements plus importants et moins fréquents, donc plus (et
non moins !) risqués. Votre entreprise devient alors incapable de procéder
à des changements aussi rapidement qu'avant, les freins se multiplient, et
vous rencontrez toujours des incidents. Cette situation a tendance à frustrer
toutes les parties impliquées. Vous êtes passé de l'inconscience à l'excès de
prudence.

L'intention, vouloir réduire l'impact des incidents, est louable, mais viser
l'absence d'incident est une erreur. La seule façon d'empêcher totalement
les incidents consiste à arrêter tous les changements. Mais pour rester
compétitives et survivre, les organisations doivent procéder à des
changements, et ces derniers comportent automatiquement des risques.

AVANT-PROPOS 7
Par conséquent, notre objectif est de réduire les risques de manière à
pouvoir continuer à progresser. C'est pour cette raison que nous avons
inventé les airbags et les détecteurs de fumée plutôt que d'arrêter de
fabriquer des voitures et de construire des bâtiments. Pouvoir effectuer
davantage de changements avec un taux de risque identique ou moindre
constitue un avantage concurrentiel. Nous pouvons adopter des pratiques
comme les « canary release » et les flags de fonctionnalité, qui réduisent
le risque par changement, mais il subsiste toujours une part risque qui
ne disparaît jamais vraiment. La « tolérance au risque » désigne le niveau
de risque qui convient à votre organisation et à ses activités : elle varie
en fonction de la nature de l'activité et des services proposés. Plus une
organisation peut apporter de changements dans le cadre de sa « tolérance
au risque », plus elle peut se révéler compétitive. Ce concept est bien
exprimé dans le chapitre 3, « Embracing Risk » (Accepter le risque), de
l'eBook Google sur l'ingénierie de fiabilité du site (SRE).

« L'intention, vouloir réduire l'impact

des incidents, est louable, mais viser
l'absence d'incident est une erreur.
Le changement est donc synonyme de risque, et le risque est synonyme
d'incidents. Si les incidents sont une réalité de la vie, alors que devons-nous
faire ? Devons-nous simplement les accepter ?

D'une certaine manière, oui. Vous devez accepter qu'en présence d'un risque,
des incidents surviennent tôt ou tard, et qu'un incident ne signifie pas un
échec permanent. Un incident doit être considéré, à juste titre, comme
le début d'un processus d'amélioration. Votre objectif devrait être de le
réaliser de la meilleure façon possible. Lorsque vous avez compris cela,
vous pouvez vous concentrer sur deux choses importantes entièrement
sous votre contrôle : la réponse de votre organisation aux incidents et les
enseignements tirés.

8 MANUEL DE GESTION DES INCIDENTS ATLASSIAN

Un bon processus de réponse aux incidents est rapide et prévisible. Il
transforme rapidement la détection en réaction, assure une remontée
aux bonnes personnes de la manière la plus directe possible, permet une
communication claire et veille à la bonne information des clients. Il doit
être suffisamment simple pour être suivi en situation de stress, mais assez
développé pour couvrir les divers types d'incidents que vous rencontrerez.
Le but premier d'un processus de réponse aux incidents est une résolution
rapide ; la vitesse et la simplicité sont donc primordiales. Le processus de
réponse aux incidents décrit dans ce manuel est identique à celui que nous
n'avons cessé de développer et d'utiliser chez Atlassian au fil des ans.

« Un bon processus de réponse aux

incidents est rapide et prévisible.
Votre processus de réponse aux incidents est la première partie de
l'équation : votre réaction. La seconde partie, les enseignements tirés, est
liée à votre processus de post-mortem.

L'objectif premier d'un processus de post-mortem est d'éviter toute

reproduction d'un problème en tirant des leçons de nos incidents et
quasi-incidents. Un bon post-mortem suit un processus structuré pour
examiner l'incident sous toutes ses coutures, en tirer des enseignements et
déterminer où appliquer idéalement des mesures d'atténuation. Les post-
mortems peuvent être délicats, car l'être humain peine généralement à
identifier les causes systémiques. Nous tendons naturellement vers la vision
rétrospective 20/20, la rationalisation post-facto et la recherche de bouc
émissaire. Il est donc souvent plus facile (et, ironiquement, plus sûr)
de procéder de la sorte et de passer à autre chose que d'examiner
honnêtement les lacunes de votre entreprise et de vous engager à les
combler. Aucune entreprise n'est parfaite à cet égard (même Atlassian), mais
le processus exposé dans ce manuel est un recueil des meilleures méthodes
que nous avons trouvées pour y parvenir.

AVANT-PROPOS 9
J'ai déjà entendu des gens décrire les incidents comme des
« investissements imprévus dans la fiabilité de vos services ». Cette
définition me semble tout à fait exacte. Partant du principe que des
incidents surviendront, que nous le voulions ou non, votre mission en tant
que propriétaire d'un incident et du processus de post-mortem consiste à
rendre cet « investissement » aussi bon marché que possible (en termes
de réduction de l'impact et de la durée de l'incident), et d'extraire jusqu'à
la dernière goutte de valeur de chaque incident rencontré (sous forme
d'enseignements et de mesures d'atténuation). Comme beaucoup de choses
dans ce monde, cela se résume à une question de minimisation des coûts et
de maximisation des bénéfices.

« Un bon post-mortem suit un processus

structuré pour examiner l'incident
sous toutes ses coutures, en tirer des
enseignements et déterminer où
appliquer idéalement des mesures
d'atténuation.
J'espère que ce manuel vous apportera beaucoup de valeur à moindre
coût, et qu'un jour vous aussi pourrez arrêter de vous en faire et que vous
apprendrez à aimer les astreintes.

10 MANUEL DE GESTION DES INCIDENTS ATLASSIAN

 CHAPITRE 1

Présentation des incidents

Présentation
Les équipes responsables de services technologiques
devraient être disponibles 24 h/24 et 7 j/7.
En cas de problème (panne ou bug de fonctionnalité), les membres
de l'équipe doivent réagir immédiatement et restaurer le service.
Ce processus, appelé gestion des incidents, est un défi permanent et
complexe pour les entreprises de toute taille.

Nous voulons aider les équipes partout dans le monde à améliorer

leur gestion des incidents. Inspirés par des équipes comme celle
de Google, nous avons créé ce manuel pour résumer le processus
de gestion des incidents d'Atlassian. Voici les enseignements que
nous avons tirés de plus de dix années de réponse aux incidents.
Bien que ce manuel repose sur notre cas unique et nos propres
expériences, nous espérons que vous pourrez l'adapter aux besoins
de votre équipe. Tout au long de ces écrits, vous trouverez des encarts
contenant d'autres options populaires pour des pratiques spécifiques.

À qui est destiné ce guide ?

Si vous faites partie d'une équipe de développement ou
opérationnelle, responsable de services pour des clients nécessitant
une disponibilité 24 h/24 et 7 j/7, ce manuel est fait pour vous.

12 MANUEL DE GESTION DES INCIDENTS ATLASSIAN

Qu'est-ce qu'un incident ?
Nous définissons un incident comme un événement ayant provoqué
une perturbation ou une réduction de la qualité d'un service et
nécessitant une réponse d'urgence. À la place, les équipes qui adoptent
les pratiques ITIL ou ITSM préfèrent le terme « incident majeur ».

Un incident est résolu lorsque le service affecté fonctionne de

nouveau de manière habituelle. Cela inclut uniquement les tâches
requises pour restaurer toutes les fonctionnalités, et exclut les
tâches de suivi telles que l'identification des causes profondes et les
mesures d'atténuation, qui font partie du post-mortem.

Le post-mortem de l'incident est réalisé après l'incident pour en

déterminer la cause profonde et assigner des mesures afin de la
corriger avant qu'elle ne provoque un nouvel incident.

Nos valeurs en matière d'incidents

Un processus de gestion des incidents ne saurait couvrir toutes les
situations possibles, c'est pourquoi nous fournissons à nos équipes
des conseils généraux sous forme de valeurs. À l'instar des valeurs
d'entreprise d'Atlassian, nos valeurs en matière d'incident sont
conçues pour :

· guider une prise de décisions autonome par les personnes et les

équipes responsables des incidents et des post-mortems ;
· développer une culture d'identification, de gestion et
d'apprentissage des incidents cohérente entre les équipes ;
· aligner les équipes quant à l'attitude à adopter aux étapes
d'identification, de résolution et d'analyse des incidents.

CHAPITRE 1 : PRÉSENTATION DES INCIDENTS 13

 Valeur relative Valeur liée à
Étape aux incidents Atlassian Justification

1. Détection Atlassian sait Savoir conjuguer Un service équilibré

avant ses passion et inclut suffisamment
clients équilibre de surveillance et
d'alertes pour détecter
les incidents avant nos
clients. Les meilleurs
outils de surveillance
nous préviennent des
problèmes avant même
qu'ils ne deviennent des
incidents.

2. Réponse Faites Miser sur l'esprit Nul ne se plaindra d'être

remonter, d'équipe réveillé au sujet d'un
faites incident pour lequel
remonter, son aide n'est pas
faites nécessaire. En revanche,
remonter tout un chacun se
plaindra s'il n'a pas été
réveillé lors d'un incident
où son aide était
requise.

Nous n'avons pas

toujours toutes
les réponses, donc
« n'hésitez pas à faire
remonter ».

14 MANUEL DE GESTION DES INCIDENTS ATLASSIAN

 Valeur relative Valeur liée à
Étape aux incidents Atlassian Justification

3. Restauration Quand c'est Ne pas baratiner Nos clients ne veulent

la cata, la le client pas savoir pourquoi leur
solution doit service ne fonctionne
être rapide pas, tout ce qu'ils
souhaitent c'est que
nous le restaurions aussi
vite que possible.

Agissez rapidement
pour résoudre un
incident au plus vite afin
de réduire son impact
sur nos clients.

4. Apprentissage Toujours sans Oui à la Les incidents font

reproche transparence, partie de l'exécution
non au baratin de services. Nous
améliorons nos services
en responsabilisant nos
équipes, pas en rejetant
la faute sur autrui.

5. Amélioration Évitez la Incarner le Identifiez la cause

répétition changement visé profonde et les
du même changements qui
incident empêcheront cette
classe entière
d'incidents de se
reproduire.

Engagez-vous
à apporter des
changements
spécifiques à des dates
précises.

CHAPITRE 1 : PRÉSENTATION DES INCIDENTS 15

Exigences relatives aux outils
Le processus de gestion des incidents décrit ici a recours à plusieurs
outils actuellement utilisés chez Atlassian et pouvant être remplacés
selon les besoins :

· Gestion des alertes et des astreintes : nous utilisons Opsgenie

pour gérer les rotations des astreintes et les remontées.
· Groupe de discussion : un canal de communication écrite en
temps réel est fondamental pour diagnostiquer et résoudre
l'incident en équipe. Chez Atlassian, nous utilisons Slack.
· Chat vidéo : pour de nombreux incidents, un chat vidéo d'équipe
comme Zoom peut vous aider à discuter et à vous mettre
d'accord sur les approches en temps réel.
· Suivi des incidents : chaque incident est suivi sous la forme d'un
ticket Jira, et un ticket de suivi est créé pour suivre l'achèvement
des post-mortems.

Tout au long du manuel, nous inclurons quelques recommandations et conseils

qui méritent d'être explorés.

Solution recommandée : Bon nombre de nos clients développent leur

processus de réponse aux incidents autour d'Opsgenie. Cela les aide à réagir
rapidement aux incidents, à les résoudre et à en tirer des enseignements.
Opsgenie simplifie la collaboration en affichant automatiquement des
informations sur les outils de discussion instantanée comme Slack et
Microsoft Teams, et en créant une salle de crise virtuelle avec un pont de
conférence vidéo natif. Les intégrations profondes avec Jira Software et
Jira Service Desk offrent une visibilité sur toutes les tâches post-incident.

· Outil de documentation : nous utilisons Confluence pour

documenter l'état de l'incident et partager des post-mortems via
des blogs.

16 MANUEL DE GESTION DES INCIDENTS ATLASSIAN

 · Statuspage : communiquer l'état aux parties prenantes internes
et aux clients via Statuspage permet de tenir en permanence
tout le monde au courant.

Remarque sur le suivi des incidents

Chaque incident est suivi sous la forme d'un ticket Jira, et un ticket
de suivi est créé pour suivre l'achèvement des post-mortems.

Dans Jira, nous utilisons un simple workflow « En attente ->

En cours de correction -> Résolu » pour suivre les incidents. Avoir un
workflow simple est une bonne chose, car nous voulons minimiser
la complexité lors des incidents. L'utilisation d'un ticket Jira pour
le suivi de nos incidents fonctionne bien pour nous, car cela nous
permet de suivre les incidents de manière cohérente, mais avec un
riche ensemble de données. Nous pouvons même étendre cela grâce
à l'automatisation et à de bonnes fonctionnalités de reporting et de
visualisation.

CHAPITRE 1 : PRÉSENTATION DES INCIDENTS 17

Gestionnaire d'incident
Chaque incident est géré par un gestionnaire d'incident qui dispose
d'une responsabilité et d'une autorité globale sur l'incident. Cette
personne est indiquée par le responsable sur le ticket de l'incident.
Lors d'un incident majeur, le gestionnaire d'incident est habilité à
prendre toutes les mesures nécessaires pour résoudre l'incident,
ce qui implique notamment de contacter des intervenants
supplémentaires de l'organisation et de veiller à ce que les personnes
impliquées dans un incident restent concentrées sur une restauration
du service aussi rapide que possible.

Le gestionnaire d'incident est un rôle, plutôt qu'une personne

spécifique. Définir des rôles lors d'un incident s'avère bénéfique, car
cela rend les personnes interchangeables. Tant qu'une personne
donnée sait jouer un certain rôle, elle peut jouer ce rôle pour
n'importe quel incident.

18 MANUEL DE GESTION DES INCIDENTS ATLASSIAN

 CHAPITRE 2

Réponse aux incidents

Les sections suivantes décrivent le processus de réponse
aux incidents d'Atlassian. Le gestionnaire d'incident pilote
l'équipe dans la série d'étapes allant de la détection à la
résolution de l'incident.

Réponse aux incidents

État de l'incident

NOUVEAU EN COURS DE CORRECTION RÉSOLU

Comm.
Détection Évaluation Communication Remontée Délégation Résolution
ouverte

Activité du gestionnaire d'incident

Détection
Les employés de votre entreprise peuvent prendre conscience des
incidents de plusieurs manières. Ils peuvent être alertés par une
surveillance, par des rapports de clients ou via une observation
directe. Même si un incident se produit, la première mesure prise par
l'équipe consiste à le consigner dans un ticket d'incident (dans notre
cas, un ticket Jira).

Nous utilisons une URL courte et facile à retenir, qui redirige les
équipes Atlassian vers un portail Jira Service Desk interne. Les
équipes Atlassian peuvent vérifier si un incident est déjà en cours en
consultant un tableau de bord Jira ou notre Statuspage interne. Des
équipes telles que notre support client disposent de tableaux de bord
accessibles à des emplacements connus pour surveiller les incidents
en cours.

20 MANUEL DE GESTION DES INCIDENTS ATLASSIAN

Nous renseignons les champs suivants pour chaque incident :

Champ Jira Type Texte d'aide

Résumé Texte Quelle est l'urgence ?

Description Texte Quel est l'impact sur les clients ?

Incluez vos coordonnées pour que
les intervenants puissent vous
contacter.

Gravité Sélection (Lien hypertexte vers une

unique page Confluence avec notre échelle
de gravité) Sélectionner une gravité
de 2 ou 1 signifie que vous croyez
que le problème doit être résolu
immédiatement (les personnes
adéquates seront contactées).

Service défaillant Sélection Le service dont la panne provoque

unique l'incident. En cas de doute, indiquez vos
suspicions. Sélectionnez « Inconnu » si
vous n'en avez aucune idée.

Produits concernés Cases à Quels produits sont concernés par

cocher cet incident ? Sélectionnez toutes les
réponses qui s'appliquent.

Lorsque l'incident est créé, sa clé de ticket (p. ex.,« HOT-12345 ») est
utilisée dans toutes les communications internes relatives à l'incident.

Les clients ouvriront souvent des dossiers de support au sujet

d'un incident qui les affecte. Lorsque nos équipes de support client
déterminent que ces dossiers sont tous liés à un même incident, ils
les étiquettent via la clé de ticket de l'incident afin de suivre l'impact
sur le client et de simplifier le suivi des clients affectés lors de la
résolution de l'incident.

CHAPITRE 2 : RÉPONSE AUX INCIDENTS 21

Lorsque le ticket d'incident a été créé, mais n'a pas encore été assigné
à un gestionnaire d'incident, l'incident est à l'état « En attente ». Il s'agit
de l'état initial dans notre workflow de réponse aux incidents Jira.

Nous disposons d'un service qui reçoit les webhooks Jira et déclenche
une alerte lorsqu'un incident majeur est créé. Celle-ci prévient un
gestionnaire d'incident d'astreinte pour le « service défaillant »
sélectionné lors de la création du ticket. Par exemple, pour un incident
affectant Bitbucket, un gestionnaire d'incident Bitbucket sera informé.

Autre option :
Dans Opsgenie, vous pouvez utiliser des modèles d'incident pour des équipes
ou des services spécifiques afin de mettre en place le flux de communication
entre les responsables, les intervenants et les parties prenantes d'un incident.

L'alerte inclut la clé de ticket, la gravité et le résumé de l'incident, qui

indique au gestionnaire d'incident où commencer à gérer l'incident
(un lien vers le ticket Jira), le problème dans les grandes lignes et sa
gravité.

Communication ouverte
La première action du gestionnaire d'incident lorsqu'il se connecte
consiste à s'auto-assigner le ticket, puis à le passer à l'état « En cours
de correction » pour indiquer que l'incident est activement géré. Le
champ du responsable du ticket Jira indique toujours l'identité du
gestionnaire d'incident actuel. Dans une intervention d'urgence, il est
très important de connaître clairement le responsable. Nous devons
donc veiller à ce que ce champ soit exact.

22 MANUEL DE GESTION DES INCIDENTS ATLASSIAN

Ensuite, le gestionnaire d'incident configure les canaux de
communication de l'équipe chargée de l'incident. De la même manière
que nous déclenchons des alertes grâce aux webhooks Jira, nous
utilisons un webhook envoyé par une transition « Configuration
d'incident » pour créer automatiquement ces canaux. L'objectif à ce
stade est d'établir et de concentrer dans des emplacements connus
toutes les communications des équipes en cas d'incident.

Nous utilisons normalement trois méthodes de communication en

équipe, chacune étant représentée par un champ sur le ticket Jira,
pour chaque incident :

· Groupe de discussion dans Slack ou un autre service de

messagerie. Il permet à l'équipe responsable de l'incident de
communiquer, de partager des observations, des liens et des
captures d'écran de manière horodatée et protégée. Nous
attribuons automatiquement au canal de chat le même nom
que la clé de ticket de l'incident (par exemple, #HOT-1234), ce qui
permet aux intervenants de le trouver plus facilement.
· Chat vidéo dans une app de conférence comme Skype, Zoom
ou similaire ; ou, si vous êtes tous au même endroit, rassemblez
l'équipe dans une salle physique. La communication synchrone
en face à face permet aux équipes d'avoir une compréhension
commune de la situation et de prendre des décisions plus
rapidement.
· Une page Confluence, appelée « document d'état de l'incident »,
où nous suivons les changements (par exemple, un tableau
indiquant qui a changé quoi, quand, pourquoi, comment annuler,
etc.), plusieurs workflows ou une chronologie plus longue.
Lorsque des personnes modifient simultanément la même
page, elles peuvent voir quelles informations sont ajoutées
et modifiées en temps réel. Un document d'état d'incident est
extrêmement utile comme source de référence lors d'incidents
complexes ou prolongés.

CHAPITRE 2 : RÉPONSE AUX INCIDENTS 23

Nous avons constaté que l'utilisation synchrone du chat vidéo et
du groupe de discussion était plus efficace lors de la plupart des
incidents, car les deux sont optimisés pour différentes choses.
Le chat vidéo permet de créer rapidement une représentation
mentale partagée de l'incident par le biais de discussions de groupe,
tandis que le groupe de discussion est idéal pour conserver un
enregistrement horodaté de l'incident, des liens partagés vers des
tableaux de bord, des captures d'écran et d'autres URL. Vu comme
cela, le chat vidéo et le groupe de discussion sont complémentaires
et non exclusifs.

Un groupe de discussion dédié peut également être utilisé pour

consigner des observations importantes, des changements et des
décisions qui se produisent dans des conversations non enregistrées.
Pour ce faire, le gestionnaire de l'incident ou tout autre membre de
l'équipe consigne simplement, en temps réel, les observations,
les changements et les décisions. Ce n'est pas grave si les gens
semblent se parler à eux-mêmes ! Ces remarques sont extrêmement
utiles pendant le post-mortem lorsque les équipes doivent
reconstituer la chronologie de l'incident et déterminer sa cause.

La plupart des systèmes de chat disposent d'une fonctionnalité de

sujet du groupe. Notre automatisation des communications met à
jour le sujet du groupe avec des informations sur l'incident et des
liens utiles, entre autres :

· le résumé et la gravité de l'incident ;

· qui occupe quel rôle, en commençant par le gestionnaire de
l'incident ;
· des liens vers le ticket d'incident, le groupe de discussion vidéo et
le document d'état de l'incident.

24 MANUEL DE GESTION DES INCIDENTS ATLASSIAN

N'oubliez pas que nous avons automatiquement nommé le canal de
chat en fonction de la clé de ticket de l'incident (par exemple, HOT-
1234), que notre système d'automatisation des alertes inclut cette
clé dans les alertes, et que toutes nos communications internes sur
l'incident (couvertes plus loin) incluent la même clé. Cette cohérence
a du bon : toute personne possédant cette clé peut facilement trouver
le groupe de discussion sur l'incident et se tenir informée.

Enfin, le gestionnaire de l'incident définit son propre statut de chat

personnel en fonction de la clé de ticket de l'incident qu'il gère. Ainsi,
ses collègues savent qu'il est occupé à gérer un incident.

Évaluation
Une fois que l'équipe responsable de l'incident a mis en place ses
canaux de communication, l'étape suivante consiste à évaluer la
gravité de l'incident afin que l'équipe puisse déterminer le niveau de
réponse approprié.

Pour cela, nous nous posons les questions suivantes :

· Quel est l'impact pour les clients (internes ou externes) ?

· Que voient les clients ?
· Combien de clients sont concernés (certains ou tous) ?
· Quand l'incident a-t-il débuté ?
· Combien de dossiers de support les clients ont-ils ouverts ?
· Y a-t-il d'autres facteurs (par exemple, attention du public,
sécurité ou perte de données) ?

CHAPITRE 2 : RÉPONSE AUX INCIDENTS 25

En fonction de l'impact commercial de l'incident, nous assignons l'un
des niveaux de gravité suivants :

Gravité Description Exemples

1. Un incident 1. Un service orienté client, comme

critique à fort Jira Cloud, est en panne pour tous les
impact clients.
2. Une violation de la confidentialité ou
de la vie privée est constatée.
3. Perte de données client.

2. Un incident 1. Un service orienté client n'est pas

majeur disponible pour un sous-ensemble de
avec impact clients.
significatif 2. Une fonctionnalité principale (par
exemple, git push, création de ticket)
est considérablement affectée.

3. Un incident 1. Un inconvénient mineur pour les

mineur avec un clients, solution de contournement
faible impact disponible.
2. Dégradation des performances utiles.

Une fois que vous avez déterminé l'impact de l'incident, ajustez ou

confirmez la gravité du ticket d'incident et communiquez-la à l'équipe.

Chez Atlassian, les incidents de gravité 3 sont assignés aux équipes

responsables pour être résolus selon les besoins (normalement,
pendant les heures de travail), tandis que les incidents de gravité 1 et
2 nécessitent une réponse immédiate et une gestion continue 24 h/24
et 7 j/7, jusqu'à leur résolution. La différence de réponse entre la
gravité 1 et 2 est plus nuancée et dépend du service concerné.

26 MANUEL DE GESTION DES INCIDENTS ATLASSIAN

Votre matrice de gravité doit être documentée et acceptée par toutes
vos équipes de sorte à fournir une réponse cohérente aux incidents en
fonction de l'impact sur l'entreprise.

Envoi de communications initiales

Lorsque vous êtes raisonnablement sûr que l'incident est réel,
vous devez le communiquer en interne et en externe. L'objectif de
la communication interne initiale est de canaliser 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. Communiquer
rapidement sur les nouveaux incidents aide à instaurer la confiance
avec votre personnel et vos clients.

Nous utilisons Statuspage pour les communications relatives aux

incidents, à la fois en interne et en externe. Nous avons des pages
d'état distinctes pour le personnel interne de l'entreprise et les clients
externes. Nous parlerons plus en détail de la manière de les utiliser
ultérieurement, mais pour le moment, l'objectif est d'envoyer les
communications initiales le plus rapidement possible. Pour cela, nous
utilisons les modèles suivants :

Statuspage interne Statuspage externe

Nom de <Clé de ticket de l'incident> – Examen des tickets grâce à

l'incident <Gravité> – <Résumé de <produit>
l'incident>

Message Nous examinons un incident Nous examinons les tickets

affectant <produit x>, <produit y> liés à <produit> et nous
et <produit z>. Nous fournirons fournirons prochainement
des mises à jour par e-mail et via des mises à jour ici.
Statuspage sous peu.

CHAPITRE 2 : RÉPONSE AUX INCIDENTS 27

 Astuce :
Dans Statuspage, vous pouvez créer des modèles de communication sur
les incidents à utiliser comme point de départ. Les champs tels que le nom
et le message seront prérenseignés et prêts à être contrôlés rapidement
avant l'envoi à vos clients. Vous pouvez ainsi gagner du temps et atténuer
partiellement le stress lié à un incident.

En plus de créer un incident sur notre Statuspage interne, nous

envoyons un e-mail à une liste de diffusion des incidents, qui inclut
notre direction technique, les principaux gestionnaires des incidents
et d'autres personnes intéressées. Le contenu de cet e-mail est
identique à celui de la Statuspage interne de l'incident. L'e-mail
permet au personnel de répondre et de poser des questions, tandis
que la Statuspage est davantage une communication à sens unique.

Notez que nous incluons toujours la clé du ticket Jira de l'incident

dans toutes les communications internes concernant l'incident, afin
que chacun sache comment en savoir plus ou rejoindre l'incident
(rappelez-vous que le groupe de discussion est automatiquement
nommé d'après la clé du ticket Jira).

28 MANUEL DE GESTION DES INCIDENTS ATLASSIAN

Comment communiquez-vous
avec vos clients lors d'une panne ?
PAR NICK COATES, PRODUCT OWNER CHEZ SYMANTEC

Le portail de votre entreprise tombe en panne. Vous passez

immédiatement en mode extinction des incendies pour essayer de
corriger le bug afin de restaurer le portail. Mais êtes-vous transparent
avec vos clients ? Vos équipes de support commencent-elles à voir les
files d'attente se remplir de tickets et de tweets ?

Une bonne réponse aux incidents ne consiste pas seulement à

rétablir rapidement les services, il s'agit d'être honnête et de tenir
fréquemment vos clients informés.

Nous avons plus de 30 produits Enterprise Cloud chez Symantec.

Notre équipe de communication des incidents travaille avec plus
de 20 équipes d'ingénierie. Les enjeux sont importants, et le risque
qu'une mauvaise communication se répercute négativement sur nos
activités est réel.

Nous avons récemment décidé de prendre du recul, d'examiner nos

performances en matière de communication sur les incidents et de
voir où nous pouvons nous améliorer.

J'ai eu la chance qu'un employé Atlassian m'aide à exécuter plusieurs

scénarios du Playbook de l'équipe Atlassian pour nos équipes de
service ici à Reading, au Royaume-Uni. Compte tenu de la réaction
positive, je savais que les playbooks étaient la voie à suivre. Nous
avons décidé d'exécuter le scénario « Communications sur la
réponse aux incidents » pour analyser nos pratiques en matière de
communication sur les incidents.

CHAPITRE 2 : RÉPONSE AUX INCIDENTS 29

Pour lancer le processus, j'ai collaboré avec l'un de nos responsables
de la communication sur les incidents afin d'examiner les incidents des
30 derniers jours. Nous voulions nous concentrer sur un seul incident
terminé que nous pourrions analyser. Parmi la poignée d'incidents, nous
en avons choisi un et nous avons commencé à rassembler les détails le
concernant en collaborant sur une page Confluence.

En tant qu'équipe distante, nous avons fait apparaître la chronologie

de l'incident sur un écran partagé et avons collaboré sur cet écran en
utilisant la fonction de notes de notre logiciel de vidéoconférence.
L'un des membres de l'équipe prenait des notes et les ajoutait à la
chronologie sur l'écran.

L'équipe s'est concentrée sur l'ensemble de l'incident du début à la

fin : depuis le moment où l'ingénierie a reçu la première alerte de
surveillance jusqu'à notre dernière mise à jour client.

Après que l'équipe a évalué l'incident, nous avons mis en place un

plan d'action comprenant des mesures portant sur les personnes,
les processus et les technologies. Nous avons assigné à chaque
mesure un « propriétaire » et une recommandation quant aux étapes
suivantes. Quelques semaines plus tard, nous nous sommes réunis,
et les propriétaires ont présenté l'état actuel des mesures, ce qui a
amélioré nos communications futures.

Mais cet exercice n'est pas ponctuel. Nous le répétons tous les
quelques mois pour nous aider à affiner et à améliorer notre
processus de communication sur les incidents. Un bon plan de
communication sur les incidents est un parcours, et non une
destination. Il peut être amélioré en permanence et faire l'objet
d'itérations. Si vous êtes prêt à entamer ce parcours, cet exercice est
un excellent début.

Nick Coates est Product Owner chez Symantec. Pour retrouver ce scénario et
bien d'autres du Playbook de l'équipe, consultez la page
atlassian.com/fr/team-playbook.

30 MANUEL DE GESTION DES INCIDENTS ATLASSIAN

Remontée
Vous avez pris le contrôle de l'incident, vous avez établi la
communication avec l'équipe, évalué la situation, et informé le
personnel et les clients qu'un incident était en cours. Et maintenant ?

Vos intervenants d'urgence peuvent être les seules personnes dont

vous avez besoin pour résoudre l'incident, mais bien souvent, vous
devez impliquer d'autres équipes dans l'incident en les appelant.
Nous appelons ce processus la remontée.

Le système clé à cette étape est un outil d'alerte et de création de

listes comme Opsgenie. Opsgenie et les produits similaires vous
permettent de définir des listes d'astreinte de sorte à mettre en
place une rotation du personnel pour chaque équipe et à pouvoir
contacter ses membres en cas d'urgence. Cette méthode est bien
plus efficace que le recours systématique à une personne spécifique
(« Rappeler Bob »), car celle-ci ne sera pas toujours disponible (elle
a tendance à partir en vacances à l'occasion, à changer d'emploi ou
à s'épuiser quand on l'appelle trop). Elle est également supérieure
aux « meilleurs efforts » des groupes d'astreinte, car elle détermine
clairement qui est chargé de répondre.

Nous indiquons toujours la clé de ticket Jira d'un incident dans une
alerte. La personne recevant l'alerte l'utilise pour rejoindre le groupe
de discussion sur l'incident.

Délégation
Lorsque vous avez fait remonter le ticket à une personne et qu'elle se
connecte, le gestionnaire de l'incident lui délègue un rôle. Tant qu'elle
comprend ce qui est attendu d'elle, elle pourra travailler rapidement
et efficacement au sein de l'équipe responsable des incidents.

CHAPITRE 2 : RÉPONSE AUX INCIDENTS 31

Chez Atlassian, nous formons nos intervenants aux rôles à jouer en
cas d'incident et à leurs responsabilités en combinant la formation
en ligne, la formation en face à face, la documentation et l'expérience
pratique de « mise en situation ».

Les rôles que nous utilisons chez Atlassian sont les suivants :

· Gestionnaire d'incident, décrit dans la section « Présentation ».

· Responsable technique, un intervenant technique senior. Il
est chargé de développer des théories sur les défaillances et
leurs causes, de décider des changements et de piloter l'équipe
technique. Il travaille en étroite collaboration avec le gestionnaire
d'incident.
· Responsable de la communication, une personne expérimentée
en matière de communication publique, éventuellement issue de
l'équipe de support client ou des relations publiques. Il est chargé
de la rédaction et de l'envoi des communications internes et
externes sur l'incident.

Le gestionnaire d'incident peut également créer et déléguer des rôles

selon les besoins de l'incident, par exemple, plusieurs responsables
techniques si plusieurs workflows sont en cours ou des responsables
distincts pour les communications internes et externes.

Dans le cas d'incidents complexes ou de grande ampleur, il est

conseillé de faire appel à un autre gestionnaire d'incident qualifié en
guise de « vérificateur » de secours pour le gestionnaire d'incident.
Il peut se concentrer sur des tâches spécifiques qui libèrent le
gestionnaire d'incident, notamment le contrôle de la chronologie.

Nous utilisons le sujet du groupe de discussion pour indiquer qui

occupe actuellement quel rôle et nous le mettons à jour si les rôles
changent au cours d'un incident.

32 MANUEL DE GESTION DES INCIDENTS ATLASSIAN

Envoi de communications de suivi
Vous avez déjà envoyé des communications initiales. Une fois que
l'équipe responsable de l'incident est en place, vous devez informer le
personnel et les clients de l'incident, puis les tenir au courant de son
évolution.

Il est essentiel d'informer régulièrement le personnel interne, car

cela crée une référence commune et cohérente sur l'incident. En cas
de problème, les informations sont souvent rares, en particulier aux
premiers stades. Et, si vous n'établissez pas une source de référence
fiable sur ce qui s'est passé et sur la réponse apportée, les gens ont
tendance à tirer leurs propres conclusions, ce qui amène son lot de
confusion.

Pour nos communications internes, nous suivons ce modèle :

· Nous communiquons via notre Statuspage interne et par e-mail,

comme décrit dans la section « Communications initiales »
ci-dessus.
· Utilisez la même convention pour le format du nom de l'incident
et de l'objet des e-mails (<Clé de ticket de l'incident> – <Gravité> –
<Résumé de l'incident>).
· Commencez par un résumé d'une à deux phrases de l'état actuel
et de l'impact de l'incident.
· Une section « État actuel » avec une liste à puces contenant deux
à quatre points.
· Une section « Étapes suivantes » avec une liste à puces
contenant deux à quatre points.
· Indiquez quand et par quel biais les prochaines communications
seront envoyées.

CHAPITRE 2 : RÉPONSE AUX INCIDENTS 33

En suivant ce modèle pour les communications internes, il est plus
facile et plus fiable de générer et d'utiliser des informations sur les
incidents. En cas d'urgence, c'est important. Avant tout envoi, nous
vérifions l'exhaustivité de nos communications grâce à la liste de
contrôle suivante :

· Avons-nous décrit l'impact actuel sur les clients ?

· Avons-nous dit combien de clients internes et externes
sont affectés ?
· La cause profonde est-elle connue ? De quoi s'agit-il ?
· Disposons-nous d'une date approximative de restauration ?
Quelle est-elle ?
· Quand et où se fera la prochaine mise à jour ?

Lors d'un incident, les informations sont souvent rares, et il

est important d'être clair sur ce que nous savons ou non. Nous
encourageons nos gestionnaires d'incident à indiquer clairement
les inconnues dans leurs communications internes. Cela permet de
réduire l'incertitude. Par exemple, si vous ignorez encore quelle est la
cause profonde, il est de loin préférable de dire « la cause profonde
est à l'heure actuelle encore inconnue » plutôt que de ne pas en
parler du tout. Cela montre clairement que nous ne connaissons
pas la cause profonde et ne laisse pas la place aux conjectures (par
exemple, nous savons peut-être, mais nous ne disons rien).

Il est important de tenir les clients externes informés régulièrement,

car cela renforce la confiance. Même s'ils sont peut-être concernés, au
moins ils savent que nous corrigeons actuellement le problème, et ils
peuvent s'occuper d'autres choses, en sachant que nous les tiendrons
au courant.

Pour les communications externes, nous mettons simplement à jour

l'incident que nous avons ouvert précédemment sur la Statuspage
externe, en modifiant son état si nécessaire. Nous essayons de fournir
des mises à jour « brèves et concises », parce que les clients externes

34 MANUEL DE GESTION DES INCIDENTS ATLASSIAN

ne s'intéressent généralement pas aux détails techniques d'un
incident, ils veulent juste savoir s'il est déjà corrigé ou, si ce n'est pas
le cas, quand il le sera. Généralement, une ou deux phrases suffisent.

Les communications sur les incidents sont tout un art, et plus

vous le pratiquez, plus vous le maîtriserez. Dans notre formation
destinée aux gestionnaires d'incident, nous simulons une situation
d'incident hypothétique pour lequel nous rédigeons des ébauches
de communication que nous lisons au reste du groupe. C'est un
bon moyen de développer cette compétence avant de l'utiliser en
situation réelle. Il est également conseillé de demander à une autre
personne de relire vos communications à titre de « deuxième avis »
avant de les envoyer.

Itération
Il n'existe pas de processus normatif unique pour résoudre tous les
incidents :
si c'était le cas, nous l'automatiserions tout simplement, et ce serait
réglé. À la place, nous itérons sur le processus suivant pour nous
adapter rapidement à divers scénarios de réponse aux incidents :

· Observez ce qui se passe. Partagez et vérifiez vos observations.

· Développez des théories sur les motifs de l'incident.
· Développez des expériences qui valideront ou invalideront ces
théories. Réalisez ces expériences.
· Répétez la procédure.

Par exemple, vous pouvez observer un taux d'erreur élevé dans un

service en raison d'une panne que votre fournisseur d'infrastructures
régional a publiée sur sa Statuspage. Vous pourriez imaginer que
la panne est isolée dans cette région, décider de basculer vers une
autre région et observer les résultats. Les aficionados du processus

CHAPITRE 2 : RÉPONSE AUX INCIDENTS 35

reconnaîtront qu'il s'agit d'une généralisation du cycle de Deming
« Planifier-Faire-Contrôler-Agir », du cycle « Observer-Orienter-
Décider-Agir » ou simplement de la méthode scientifique.

Les plus grands défis pour le gestionnaire de l'incident, à ce stade,

concernent le maintien de la discipline de l'équipe :

· L'équipe communique-t-elle efficacement ?

· Quels sont les observations, théories et workflows actuels ?
· Notre prise de décisions est-elle efficace ?
· Les changements que nous apportons sont-ils intentionnels et
réfléchis ? Savons-nous quels changements nous apportons ?
· Les rôles sont-ils clairement définis ? Tout le monde fait-il son
travail ? Devons-nous faire remonter l'incident à davantage
d'équipes ?

Quoi qu'il arrive, ne paniquez pas, cela n'aide pas. Restez calme et
l'équipe réagira comme vous.

Le gestionnaire d'incident doit surveiller l'état de fatigue de l'équipe

et prévoir les changements nécessaires. Une équipe dédiée risque de
s'épuiser lors de la résolution d'incidents complexes. Les gestionnaires
d'incident doivent savoir depuis combien de temps les membres
sont éveillés, depuis combien de temps ils travaillent, et doivent leur
désigner des remplaçants.

Résolution
Un incident est résolu lorsque l'impact actuel ou imminent sur
l'activité disparaît. À ce stade, la réponse d'urgence prend fin, et
l'équipe passe à toutes les tâches de nettoyage et au post-mortem.

36 MANUEL DE GESTION DES INCIDENTS ATLASSIAN

Les tâches de nettoyage peuvent être facilement associées et suivies
sous forme de liens à partir du ticket Jira de l'incident.

Chez Atlassian, nous utilisons les champs personnalisés Jira pour

suivre à quel moment débute l'impact de chaque incident, le moment
de sa détection et quand s'achève son impact. Nous utilisons ces
champs pour calculer le délai de restauration, qui est l'intervalle entre
le début et la fin, et le délai de détection, qui est l'intervalle entre le
début et la détection. La répartition des délais de restauration et de
détection de vos incidents est souvent un indicateur important pour
votre entreprise.

Nous envoyons des communications internes et externes finales

lorsque l'incident est résolu. Les communications internes récapitulent
l'impact et la durée de l'incident, y compris le nombre de dossiers
de support créés et d'autres aspects importants de l'incident. En
outre, elles indiquent clairement que l'incident est résolu et qu'aucune
communication ultérieure ne sera faite sur le sujet. Les communications
externes sont généralement brèves, indiquant aux clients que le service
a été rétabli et que nous allons réaliser un post-mortem.

La responsabilité finale du gestionnaire d'incident est d'assurer

l'exécution du post-mortem. Reportez-vous au chapitre suivant pour
découvrir comment faire…

CHAPITRE 2 : RÉPONSE AUX INCIDENTS 37

Astuces pour bien rédiger un
rapport d'incident
PAR JOHN ALLSPAW, CO-FONDATEUR D'ADAPTIVE CAPACITY LABS

Vous trouverez ci-dessous une réponse à une session « Ask Me Anything »

(Posez-moi vos questions) avec John Allspaw sur la communauté Atlassian John
est le co-fondateur d'Adaptive Capacity Labs et l'ancien DSI d'Etsy.

QUESTION :

Quels conseils donneriez-vous pour rédiger un bon rapport post-

mortem ? La structure des post-mortems est un sujet qui semble
poser problème à de nombreuses entreprises, comme, par exemple,
les éléments à inclure et ce qui ferait vraiment la différence.

JOHN ALLSPAW :

Je pense que vous avez saisi un défi essentiel auquel font face les
personnes qui analysent les incidents : les données et le contexte
pouvant être intégrés dans le rapport écrit d'un incident sont sans
fin ou presque ! Les éléments à inclure, les éléments sur lesquels
se concentrer ou à mettre en évidence, les éléments à survoler ou
à négliger, car peu importants… voilà des décisions qui doivent être
prises par le ou les auteurs de ces documents.

Pour répondre brièvement, je dirais :

· Tenez compte du public auquel s'adresse ce document. S'agit-

il de spécialistes dans les « tranchées » des systèmes de
production ? S'agit-il du grand public ou de clients sous contrat ?
S'agit-il de dirigeants, de membres de conseils d'administration
ou d'investisseurs ? La réponse à cette question détermine
presque chaque partie de la structure du document.

38 MANUEL DE GESTION DES INCIDENTS ATLASSIAN

 · Il n'existe pas de « structure unique et complète » d'un document
de revue post-incident ; pour chaque incident, les points à mettre
en évidence sont différents. Il revient donc à la personne qui
analyse les incidents de reconnaître ce que chaque cas peut
révéler sur les équipes, le contexte, les systèmes, etc., et de se
concentrer sur ces points.
· Pour bien y parvenir (pas seulement rédiger des documents
post-incident, mais aussi collecter des données, réaliser des
entretiens de groupe, etc.), beaucoup de temps et de pratique
sont nécessaires.
· Pour le reste de la réponse, on va supposer que le public se
compose d'ingénieurs de terrain internes. :) Très souvent, ces
rapports sont considérés comme un simple « véhicule » sur lequel
sont placées des mesures de « remédiation » ou de suivi. C'est
une erreur et une occasion manquée.

« Compiler les tâches qui pourraient être

utiles à l'avenir est important, mais pas
suffisant pour permettre un véritable
apprentissage.
Il est essentiel de retenir que ces documents doivent être rédigés en
tenant compte du lecteur final.

Qu'est-ce que le lecteur voudra savoir sur le contexte de l'incident ?

On pourrait imaginer qu'en indiquant le moment où une panne s'est
produite (Cyber Monday ? Le jour de votre introduction en bourse ?
Lorsque votre PDG donne une interview sur scène ?) pourrait être
important dans certains cas et pas vraiment dans d'autres, par
exemple.

CHAPITRE 2 : RÉPONSE AUX INCIDENTS 39

Quels aspects de la gestion de l'incident serait-il important de
préciser au lecteur ? Par exemple : parfois, la résolution d'incidents
nécessite les connaissances obscures d'ingénieurs chevronnés,
eux seuls à même de comprendre les comportements étranges
de ces technologies héritées qui, en général, « se contentent
de fonctionner ». Dans ce cas, il pourrait être très important
d'indiquer qui sont ces ingénieurs et ce qu'ils savent. Peut-être
que tous les ingénieurs requis pour répondre à l'incident assistent
à une conférence à ce moment-là ? Compiler ces données dans
un document peut être très utile pour les lecteurs du rapport qui
n'étaient pas présents à l'époque ou qui aimeraient connaître le
pourquoi d'une telle technologie.

Pour analyser efficacement les incidents, il faut développer

(et entretenir !) les compétences requises pour non seulement
rédiger ces rapports, mais aussi savoir quelles données recueillir,
quelles personnes interroger, quels diagrammes inclure, etc. Les
organisations qui reconnaissent cette expertise et investissent
pour s'améliorer dans ce domaine s'apercevront qu'elle constitue un
avantage concurrentiel.

40 MANUEL DE GESTION DES INCIDENTS ATLASSIAN

 CHAPITRE 3

Post-mortems des incidents

C'est grâce au post-mortem sans reproche qu'un incident
qui vous a laissé un souvenir amer se pare d'un doux
manteau fait de résilience. Nous utilisons cette technique
pour tirer des enseignements et déterminer des mesures
d'atténuation de l'incident. Voici une version résumée de
notre documentation interne décrivant la méthode de
post-mortem Atlassian.

Qu'est-ce qu'un post-mortem ?

Un post-mortem est un rapport écrit d'un incident qui décrit :

· l'impact de l'incident ;
· les mesures prises pour atténuer ou résoudre l'incident ;
· les causes de l'incident ;
· les mesures de suivi prises pour éviter que l'incident ne
se reproduise.

Opsgenie peut automatiquement générer des rapports post-mortem

en utilisant des modèles prédéfinis. Chez Atlassian, nous utilisons
essentiellement Jira Software pour consigner toutes les mesures de
suivi et les rapports post-mortem.

Pourquoi réalisons-nous des post-mortems ?

Un post-mortem vise à maximiser la valeur d'un incident en
comprenant toutes les causes impliquées, en documentant l'incident
pour référence future et identification de schémas, et en mettant en
place des mesures préventives efficaces pour réduire la probabilité ou
l'impact d'un nouvel incident de ce type.

42 MANUEL DE GESTION DES INCIDENTS ATLASSIAN

Si vous considérez un incident comme un investissement imprévu
dans la fiabilité de votre système, alors le post-mortem vous
permettra de maximiser le retour sur cet investissement.

Quand un post-mortem est-il requis ?

Nous réalisons toujours des post-mortems pour les incidents de
gravité 1 et 2 (les incidents « majeurs »). Pour les incidents mineurs,
ils sont facultatifs. Nous vous encourageons à lancer le processus de
post-mortem pour toute situation où il serait utile.

Qui réalise un post-mortem ?

En général, l'équipe qui fournit le service à l'origine de l'incident est
chargée de réaliser le post-mortem correspondant. Elle désigne une
personne responsable de la réalisation du post-mortem, et le ticket
lui est assigné. Cette personne est appelée « postmortem owner »
(ou propriétaire du post-mortem) et gère le post-mortem depuis sa
rédaction et son approbation, jusqu'à sa publication.

Les incidents au niveau des infrastructures et des plateformes ont

souvent un impact sur un échantillon représentatif de l'entreprise,
ce qui rend leurs post-mortems plus compliqués et plus exigeants.
C'est pourquoi nous assignons parfois un gestionnaire de programme
dédié comme propriétaire des post-mortems d'infrastructures ou de
plateformes, car par nature, cette personne est plus apte à travailler
en groupe et est capable de fournir le niveau d'effort requis.

CHAPITRE 3 : POST-MORTEMS DES INCIDENTS 43

Pourquoi les post-mortems doivent-ils être sans
reproche ?
Lorsque les choses tournent mal, la réaction naturelle de l'homme
est de se demander « qui est responsable » et de se soustraire aux
reproches. Mais les reproches compromettent en fait le succès du
post-mortem pour les raisons suivantes :
· Lorsque les personnes craignent que leur image soit ternie aux
yeux de leurs collègues ou que leurs perspectives de carrière
soient bouchées, cette crainte prend le pas sur « les meilleurs
intérêts de leur employeur » dans leur hiérarchie personnelle.
C'est à ce moment-là qu'elles dissimulent la vérité afin de
protéger leurs besoins fondamentaux.
· Le blâme est une approche cruelle et, en cas de répétitions
fréquentes, il crée une culture empreinte de peur et de méfiance.
· Même si l'action d'une personne a provoqué un incident, nous ne
devons pas nous demander « pourquoi X a fait ce qu'il fait », mais
plutôt « pourquoi le système lui a permis de le faire ou lui a laissé
entendre que c'était la meilleure chose à faire ».

En tant que responsable du post-mortem, vous devez travailler

activement contre cette tendance naturelle à faire des reproches.
Le post-mortem doit examiner de façon honnête et objective les
circonstances qui ont entraîné l'erreur, de sorte à trouver la ou les
véritables causes et à les éliminer. Nous prêtons de bonnes intentions
à notre personnel et nous ne blâmons jamais les personnes
pour leurs erreurs.

Dans nos post-mortems, nous utilisons ces techniques pour garantir

la sécurité personnelle de tous les participants :

· Durant la réunion, commencez par préciser que ce post-mortem

est sans reproche et expliquez pourquoi.

44 MANUEL DE GESTION DES INCIDENTS ATLASSIAN

 · Adressez-vous aux personnes par leur rôle (par exemple,
« l'ingénieur d'astreinte pour les widgets ») et non par leur nom
(tout en restant clair et sans ambiguïté quant aux faits).
· Assurez-vous que la chronologie du post-mortem, la chaîne de
causalité et les atténuations sont encadrées dans le contexte
des systèmes, des processus et des rôles, et non des individus.

Notre inspiration pour les post-mortems sans reproche et le

concept utile de « second stories » nous vient de l'article phare de
John Allspaw*.

Présentation du processus de post-mortem

Pour que les post-mortems soient efficaces, le processus doit
permettre aux équipes d'identifier facilement les causes et de les
éliminer. Les méthodes exactes utilisées dépendent de la culture de
votre équipe. Chez Atlassian, nous avons trouvé une combinaison de
méthodes qui fonctionnent pour nos équipes de réponse aux incidents :
· Un point de contact unique pour les résultats des post-mortems
permet de clarifier les responsabilités. Le responsable du ticket
post mortem est toujours la personne en charge.
· Utilisez les réunions en face à face pour accélérer l'analyse, créer
rapidement une compréhension commune et convenir en équipe
des points à corriger.
· La revue et l'approbation du post-mortem par notre équipe de
direction de l'ingénierie aident à fixer le bon niveau de rigueur et
de priorité.
· La réalisation des mesures d'atténuation importantes est
soumise à un objectif de niveau de services ou SLO convenu
(8 semaines dans la plupart des cas) avec des rappels et des
rapports pour s'assurer qu'elles sont mises en œuvre.
* « Blameless PostMortems and a Just Culture » par John Allspaw :
https://codeascraft.com/2012/05/22/blameless-postmortems/

CHAPITRE 3 : POST-MORTEMS DES INCIDENTS 45

L'exécution du processus de post-mortem comprend le
renseignement d'un ticket post-mortem, l'organisation d'une réunion
de post-mortem, la compilation d'actions, l'obtention de l'approbation
et la communication du résultat.

Si vous êtes propriétaire du post-mortem, procédez comme suit :

1. Créez un ticket post-mortem et associez-le au ticket de l'incident.

2. Modifiez le ticket post-mortem, lisez les descriptions des champs

et complétez-les (les champs que nous utilisons chez Atlassian
sont indiqués sous « Champs d'un ticket post-mortem » ci-dessous).

3. Utilisez la technique des « Cinq pourquoi » pour parcourir la chaîne

de causalité et découvrir les causes sous-jacentes de l'incident.
Préparez une théorie comparant la réalité à la séquence idéale
d'événements, et dressez la liste des mesures d'atténuation
proposées pour les causes que vous avez identifiées.

4. Planifiez la réunion post-mortem. Invitez l'équipe de livraison,

les équipes concernées et d'autres parties prenantes, à l'aide du
modèle d'invitation à la réunion.

5. Réunissez l'équipe et parcourez les points des réunions ci-dessous

(voir « Réunions post-mortem » ci-dessous).

6. Assurez un suivi avec les responsables de l'ingénierie afin

d'obtenir un engagement défini dans le temps pour les mesures
convenues lors de la réunion.

7. Si les équipes participantes ne l'ont pas encore fait, créez un

ticket Jira pour chaque action dans les backlogs des équipes qui
en sont responsables. Associez-le au ticket post-mortem.

8. Ajoutez le ou les responsables de l'ingénierie du ou des groupes

appropriés dans le champ « Approbateurs » du post-mortem.

46 MANUEL DE GESTION DES INCIDENTS ATLASSIAN

9. Quand vous pensez que le ticket post-mortem est prêt
pour approbation, sélectionnez la transition « Demande
d'approbation » pour demander l'approbation des approbateurs
désignés. Une fonction automatique commentera le ticket avec
des instructions pour les approbateurs.

10. Assurez le suivi auprès des approbateurs et des autres parties

prenantes, le cas échéant. Cela implique souvent de répondre à
des questions et de prendre des décisions.

11. Une fois le post-mortem approuvé, nous voulons multiplier sa

valeur en partageant ce que nous avons appris avec l'ensemble
de l'entreprise. À cette fin, nous disposons d'une automatisation
qui permet de créer une ébauche de billet de blog dans
Confluence lorsque le ticket post-mortem est approuvé. Suivez le
lien « Ébauche de billet de blog » sur le ticket post-mortem pour
éditer et publier le billet de blog.

Champs d'un ticket post-mortem

Notre ticket post-mortem comporte une série de champs
personnalisés pour collecter tous les détails importants avant la
réunion post-mortem.

Autre option :
Si vous suivez et collaborez sur des incidents dans Opsgenie, vous pouvez
générer automatiquement un rapport post-mortem en utilisant un modèle
prédéfini. Toutes les actions critiques qui ont eu lieu pendant l'incident sont
documentées dans une chronologie, et les tickets Jira correspondants sont
inclus à titre de référence et pour remédiation.

CHAPITRE 3 : POST-MORTEMS DES INCIDENTS 47

Vous trouverez ci-dessous une liste de ces champs et quelques
exemples de la manière dont nous les remplissons.

Champ Instructions Exemples

Résumé de Résumez l'incident Entre <intervalle de l'incident,

l'incident en quelques phrases. par exemple, 14 h 30 et 15 h 00>
Incluez sa gravité, les le <date>, <nombre> clients ont
raisons et la durée de été confrontés à <symptômes de
l'impact. l'événement>. L'événement a été
déclenché par un déploiement
à <date/heure du déploiement
ou du changement à l'origine
de l'incident>. Le déploiement
contenait un changement de
code pour <description du motif
du changement>. Le bug dans le
déploiement a provoqué <description
du problème>.
L'événement a été détecté par
<système>. Nous avons réduit
l'impact de l'événement en <mesures
de résolution adoptées>.
Cet incident de niveau <niveau de
gravité> a affecté X % des clients.
<Nombre de tickets de support et/
ou de publications sur les réseaux
sociaux> ont été créés au sujet de cet
incident.

Prémices Décrivez les À <heure> le <date>, (<durée

circonstances qui ont avant l'impact sur le client>), un
entraîné l'incident, changement a été apporté à <produit
par exemple, des ou service> pour… <description
changements des changements qui ont entraîné
antérieurs qui ont l'incident>. Le changement a
introduit des bugs provoqué… <description de l'impact
latents. des changements>.

48 MANUEL DE GESTION DES INCIDENTS ATLASSIAN

 Champ Instructions Exemples

Panne Décrivez ce qui n'a pas <Nombre> réponses ont été envoyées
fonctionné comme à X % des demandes par erreur
prévu. Joignez des durant <période>.
captures d'écran
des données ou des
graphiques pertinents
sur la panne.

Impact Décrivez ce que les Pour <durée> entre <intervalle>

clients internes et le <date>, <résumé de l'incident>
externes ont vu lors a été constaté. Ceci a affecté
de l'incident. Incluez le <nombre> clients (X % de tous
nombre de dossiers de les clients <système ou service>),
support créés. qui ont constaté <description des
symptômes constatés par les
clients>. <Nombre de tickets de
support et de publications sur les
réseaux sociaux> ont été créés.

Détection Comment et quand L'incident a été détecté lorsque le

Atlassian a-t-il <type d'alerte> a été déclenché et
détecté l'incident ? que <équipe ou personne appelée>
Comment le délai de a été appelée. Cette personne
détection pourrait-il ou équipe a ensuite dû appeler
être amélioré ? À titre <personne ou équipe de réponse
d'exercice de réflexion, secondaire> car elle ne possédait pas
comment réduiriez- le service écrivant sur le disque,
vous ce délai de retardant la réponse de <durée>.
moitié ? <Description de l'amélioration> sera
définie par <équipe responsable de
l'amélioration> pour que <impact de
l'amélioration>.

49
CHAPITRE 3 : POST-MORTEMS DES INCIDENTS
 Champ Instructions Exemples

Réponse Qui a répondu, quand Après avoir été appelé à 14 h 34

et comment ? Y a-t- (UTC), l'ingénieur KITT s'est connecté
il eu des retards ou à 14 h 38 dans le groupe de
des obstacles à notre discussion sur l'incident. Cependant,
réponse ? l'ingénieur d'astreinte n'avait pas
suffisamment d'informations sur
l'outil de scalabilité automatique
Escalator ; une autre alerte a
donc été envoyée à 14 h 50 et un
ingénieur KITT senior a rejoint le
groupe à 14 h 58.

Restauration Décrivez comment et La restauration du service a nécessité

quand le service a été une réponse en trois volets :
rétabli. Comment en · Augmentation de la taille
êtes-vous arrivé au du groupe de scalabilité
stade où vous avez automatique (ASG) EC2 de
compris comment BuildEng afin d'augmenter le
réduire l'impact ? nombre de nœuds disponibles
Comment améliorer le pour traiter la charge de travail
délai d'atténuation ? et réduire la probabilité de
À titre d'exercice de planification sur des nœuds
réflexion, comment sursouscrits.
réduiriez-vous ce délai · Désactivation de l'outil de
de moitié ? scalabilité automatique Escalator
pour empêcher toute réduction
agressive du cluster.
· Retour à la version précédente du
planificateur BuildEng.

50 MANUEL DE GESTION DES INCIDENTS ATLASSIAN

 Champ Instructions Exemples

Chronologie Fournissez une Toutes les heures correspondent au

chronologie fuseau UTC.
détaillée des 11 h 48 : Mise à niveau K8S 1.9 du plan de
contrôle terminée.
incidents, horodatée
12 h 46 : Mise à niveau de Goliath vers la
avec les fuseaux V1.9 terminée, y compris la mise à l'échelle
horaires. Indiquez automatique du cluster et l'instance du
toutes les prémices ; planificateur BuildEng.
début de l'impact ; 14 h 20 : BuildEng signale un problème
délai de détection ; à l'équipe Technologie d'infrastructure
Kubernetes (KITT) perturbée.
remontées,
14 h 27 : L'équipe KITT perturbée commence
décisions et à enquêter sur les pannes d'une
changements ; et fin instance EC2 spécifique (ip-203-153-8-204).
de l'impact. 14 h 42 : Il isole le nœud spécifique.
14 h 49 : BuildEng signale que le problème
affecte plusieurs nœuds. 86 instances du
problème montrent que les pannes sont
plus systémiques.
15 h 00 : L'équipe KITT perturbée suggère
de passer au planificateur standard.
15 h 34 : BuildEng signale la panne de
300 pods.
16 h 00 : BuildEng arrête tous les
builds défaillants, qui renvoient des
rapports OutOfCpu.
16 h 13 : BuildEng signale que les pannes
sont récurrentes avec les nouveaux builds,
et pas seulement transitoires.
16 h 30 : L'équipe KITT reconnaît les pannes
comme un incident et les gère en tant que
telles.
16 h 36 : L'équipe KITT désactive l'outil de
scalabilité automatique Escalator pour
l'empêcher de retirer de la capacité de
calcul afin de résoudre le problème.
16 h 40 : L'équipe KITT confirme que l'ASG
est stable, la charge du cluster est normale
et l'impact sur le client est résolu.

CHAPITRE 3 : POST-MORTEMS DES INCIDENTS 51

 Champ Instructions Exemples

Cinq pourquoi Utilisez la technique 1. Le service a été interrompu, car la

d'identification de la base de données était verrouillée.
cause profonde des 2. Parce que le nombre d'écritures
« Cinq pourquoi ». dans les bases de données était
Commencez par trop important.
l'impact, et demandez- 3. Parce qu'un changement a
vous pourquoi été apporté au service et que
l'incident s'est produit l'augmentation n'était pas prévue.
et pourquoi il a eu cet 4. Parce que nous n'avons pas de
impact. Continuez processus de développement
à vous poser cette configuré pour les moments
question jusqu'à ce où nous devons charger les
que vous arriviez à changements test.
la cause profonde. 5. Nous n'avons jamais effectué de
Documentez vos test de charge et atteignons de
« pourquoi » sous nouveaux niveaux d'échelle.
forme de liste ici ou
dans un diagramme
joint au ticket.

Cause Quelle était la cause Un bug dans la gestion du pool de

profonde profonde ? C'est ce connexions <cause du bug ou service
qui doit changer pour où le bug est survenu> a entraîné une
empêcher que cette fuite de connexions lors de la panne,
classe d'incident ne se ainsi qu'un manque de visibilité sur
reproduise. l'état des connexions.

Contrôle du Un élément de votre Pas spécifiquement. Les

backlog backlog aurait-il pu améliorations apportées au typage
empêcher l'incident ou des flux concernaient des tâches en
réduire son impact ? cours connues, pour lesquelles des
Si oui, pourquoi n'a-t-il rituels étaient en place (par exemple,
pas été exécuté ? ajouter des types de flux lorsque
Ici, une évaluation vous modifiez/créez un fichier).
honnête aide à clarifier Des tickets de correction des tests
les décisions passées d'intégration ont été créés, mais
en matière de priorité n'ont pas eu les résultats attendus.
et de risque.

52 MANUEL DE GESTION DES INCIDENTS ATLASSIAN

 Champ Instructions Exemples

Récurrence Cet incident (avec La même cause profonde a provoqué les

la même cause incidents HOT-13432, HOT-14932 et
profonde) s'est- HOT-19452.
il déjà produit
auparavant ?
Le cas échéant,
pourquoi s'est-il de
nouveau produit ?
Enseigne- Qu'en avons-nous 1. Nécessité de développer un test unitaire
ments appris ? pour vérifier que la limite de vitesse
tirés Discutez de ce qui d'exécution des tâches a été correctement
s'est bien passé, observée
de ce qui aurait 2. Les charges de travail en masse atypiques
par rapport au fonctionnement normal
pu aller mieux et
doivent être examinées.
des possibilités
3. Les opérations groupées devraient
d'amélioration que démarrer lentement et être surveillées,
nous avons eu la et augmenter lorsque les métriques de
chance d'identifier. service semblent minimes.
Mesures Qu'allons-nous 1. Limite manuelle du taux de mise à l'échelle
correctives faire pour nous automatique utilisée temporairement pour
assurer que limiter les défaillances.
cette classe 2. Test unitaire et réintroduction de la
d'incident ne se limitation de la vitesse des tâches.
3. Introduction d'un mécanisme secondaire
reproduise plus ?
pour collecter des informations sur la
Qui va prendre
vitesse distribuée à travers le cluster afin
les mesures et d'orienter les effets de mise à l'échelle.
quand ? 4. Les migrations volumineuses doivent
Créer des liens vers être coordonnées, car AWS ElasticSearch
les tickets de suivi n'effectue pas automatiquement la mise à
de chaque mesure. l'échelle.
5. Vérifier que la recherche est toujours
classée comme Tier-2.
6. Créer un ticket sur pf-directory-service pour
une panne partielle au lieu d'une panne
complète lorsque xpsearch-chat-searcher
échoue.
7. Alerte Cloudwatch pour identifier un
problème d'E/S élevé sur le cluster
ElasticSearch.

53
CHAPITRE 3 : POST-MORTEMS DES INCIDENTS
Causes directes et profondes
Lorsque vous rédigez ou lisez un post-mortem, il est nécessaire
de faire la distinction entre les causes immédiates et les causes
profondes.

· Les causes immédiates sont des raisons qui ont directement

conduit à cet incident.
· Les causes profondes sont des points de la chaîne d'événements
auxquels apporter un changement pour éviter toute cette classe
d'incidents.

Un post-mortem cherche à découvrir les causes profondes et

à déterminer la meilleure façon de les éliminer. Tout l'art d'un
post-mortem consiste à trouver le point optimal de la chaîne
d'événements. Utilisez une technique comme celle des Cinq pourquoi
pour « remonter la chaîne » et identifier des causes profondes.

Voici quelques exemples de causes immédiates et profondes :

Cause
immédiate et Atténuation des
Scénario mesure Cause profonde causes profondes

L'équipe « Red Les membres de Il n'existe pas de Créez un

Dawn » ne l'équipe n'ont processus pour processus de
disposait pas pas configuré la créer des services, mise en place de
de moniteurs surveillance et notamment de nouveaux services
et d'alertes les alertes pour surveillance et et apprenez à
d'astreinte pour les nouveaux d'alerte. l'équipe à le
ses services, ou services. suivre.
ils n'étaient pas Configurez-les
correctement pour ces services.
configurés.

54 MANUEL DE GESTION DES INCIDENTS ATLASSIAN

 Cause
immédiate et Atténuation des
Scénario mesure Cause profonde causes profondes

Le site était La mise à Absence de test de Automatisez

inutilisable sur niveau d'une compatibilité entre les tests de
IE11 en raison dépendance. navigateurs. compatibilité
d'une mise à Annulez la mise à entre navigateurs
niveau vers niveau. en continu.
Fabric Editor qui
ne fonctionne pas
sur cette version
du navigateur.
Les journaux de Le rôle donné Nous ne pouvons Ajoutez la
Micros EU ne aux micros pour pas savoir quand surveillance et
parvenaient pas envoyer des la journalisation les alertes sur
au service de journaux était depuis un les journaux
journalisation. incorrect. environnement ne manquants
Corrigez le rôle. fonctionne pas. pour tous les
environnements.
Déclenchés Panne AWS. Un bug dans la Corrigez le bug
par un incident Récupérez le post- gestion du pool et ajoutez une
AWS antérieur, mortem AWS. de connexions surveillance
les nœuds Confluence a qui détectera
Confluence entraîné une fuite les situations
Vertigo ont de connexions lors similaires futures
épuisé leur pool de la panne, ainsi avant qu'elles
de connexions à qu'un manque de n'aient un impact.
Media, entraînant visibilité sur l'état
des erreurs des connexions.
intermittentes de
pièces jointes et
de médias pour
les clients.

CHAPITRE 3 : POST-MORTEMS DES INCIDENTS 55

Catégories de causes et mesures associées
Chez Atlassian, nous trouvons utile de regrouper les causes des
incidents en catégories. Cela nous aide à nous orienter dans la bonne
direction lorsque nous décidons de mesures d'atténuation et nous
permet d'analyser les tendances des incidents. Par exemple, si nous
constatons un nombre élevé d'incidents liés à l'échelle dans un
groupe, cela pourrait nous inciter à comparer les stratégies de mise à
l'échelle avec d'autres groupes.

Les catégories que nous utilisons sont adaptées à notre propre

activité en tant qu'éditeur de logiciels. Vous constaterez peut-être
que d'autres catégories fonctionnent mieux pour votre entreprise.

Catégorie Définition Que devriez-vous faire à ce sujet ?

Bug Un changement de Test. « Canary release ». Effectuez

code réalisé par des déploiements incrémentiels et
Atlassian (il s'agit d'un surveillez-les. Utilisez des flags de
type de changement fonctionnalité.
spécifique)

Changement Un changement Améliorez la façon dont vous

apporté par Atlassian apportez les changements,
(autre que des par exemple, vos revues des
changements apportés changements ou vos processus de
au code, qui sont des gestion des changements. Tout ce qui
bugs) se rapproche d'un « bug » s'applique
également ici.

Déploiement à Échec de la mise à Quelles sont les contraintes liées aux

grande échelle l'échelle (par exemple, ressources de votre service ? Sont-
non-respect des elles surveillées et contrôlées par des
contraintes liées aux alertes ? Si vous ne disposez pas d'un
ressources ou manque plan des capacités, élaborez-en un.
de planification des Si vous en avez un, quelle nouvelle
capacités) contrainte devez-vous prendre en
compte ?

56 MANUEL DE GESTION DES INCIDENTS ATLASSIAN

 Catégorie Définition Que devriez-vous faire à ce sujet ?

Architecture Mauvais alignement Révisez votre conception. Devez-vous

de la conception changer de plateforme ?
avec les conditions
opérationnelles

Dépendance Panne de service Gérez-vous les risques de panne

tiers (non fourni par tierce ? Avons-nous pris la décision
Atlassian) métier d'accepter un risque
ou devons-nous élaborer des
mesures d'atténuation ? Reportez-
vous à « Causes profondes avec
dépendances » ci-dessous.

Inconnu Indéterminable (une Améliorez l'observabilité de

mesure consiste à votre système en ajoutant des
augmenter la capacité fonctionnalités de journalisation,
de diagnostic) de surveillance, de débogage et
d'autres fonctions similaires.

Causes profondes avec dépendances externes

Avec l'avènement du SaaS et de l'IaaS, les entreprises sont plus que
jamais dépendantes de leurs fournisseurs. Des entreprises comme
AWS, Google, Microsoft et Salesforce fournissent une grande partie
de l'infrastructure qui alimente les services modernes. Lorsqu'ils
rencontrent une panne et que vous en subissez les conséquences,
comment pouvez-vous tirer parti du post-mortem ?

Lorsque votre service rencontre un incident en raison d'une panne

d'une dépendance externe, la responsabilité et les mesures
d'atténuation appropriées dépendent de ce que vous pouvez
raisonnablement attendre du service externe. C'est qui est parfois
qualifié d'« attentes de niveau de service » (Service Level Expectation
ou SLE).

CHAPITRE 3 : POST-MORTEMS DES INCIDENTS 57

Pourquoi parle-t-on ici d'« attente » ou de SLE par opposition à un
« engagement » ou « SLA » ? En réalité, les SLA publiés ou acceptés
par les fournisseurs sont presque toujours trop bas ou vagues pour
être utiles. En d'autres termes, les engagements légalement acceptés
par un fournisseur seront si minimes qu'ils seront inutiles dans la
pratique. Sinon, les conséquences d'une violation du SLA seront si
minimes qu'elles ne dissuaderont pas réellement de la violation. Et
ce, tout simplement parce que les fournisseurs, comme nous tous,
doivent survivre dans un monde concurrentiel et chercher à minimiser
leur exposition aux risques. Enfin, même si vous obtenez d'un
fournisseur qu'il accepte des conditions que vous jugez appropriées,
vous pouvez fréquemment vous retrouver dans une « zone grise » où
un problème n'a pas techniquement affecté le SLA convenu, mais vous
a néanmoins touché en tant que client.

La définition et la communication d'une SLE relèvent de la

responsabilité de la personne « propriétaire » du service externe. Il
peut s'agir d'un responsable informatique, d'un ingénieur principal
ou de la personne qui a signé le contrat. Tout comme le propriétaire
d'un service interne, cette personne doit communiquer au reste de
l'organisation ce qu'elle peut attendre du service externe.

58 MANUEL DE GESTION DES INCIDENTS ATLASSIAN

Une fois que vous avez déterminé ce qu'est une « attente
raisonnable », vous pouvez l'utiliser pour décider où appliquer des
mesures d'atténuation après un incident :

Dans cet incident,

les SLE ont été… … donc nous devrions :

Dépassées : le service externe a Obtenir et examiner ce post-mortem.

été moins performant que ce à Nous déterminerons peut-être que le service
quoi nous nous attendions. a correctement identifié et éliminé les
causes de l'incident, auquel cas nous aurons
terminé.

Il se peut aussi que nous devions ajuster nos

attentes à la baisse et trouver des moyens
d'accroître notre résistance aux défaillances
externes en fonction de ces nouvelles
attentes.

Enfin, si nos nouvelles attentes ne sont

pas acceptables, nous devons résoudre ce
problème d'une manière ou d'une autre, par
exemple en changeant de fournisseur de
services.

Respectées : les performances du Améliorer notre résilience face à des pannes

service externe correspondaient de ce type. Le service externe s'est comporté
à nos attentes, mais nous avons comme prévu. Nous devons donc soit faire
quand même été touchés. preuve de résilience face à cette situation,
soit accepter le risque et prévoir des
interruptions occasionnelles.

Nulles : nous n'avions pas La personne responsable de l'utilisation de

vraiment d'attentes ! la dépendance tierce doit établir des SLE et
les partager avec les équipes afin qu'elles
connaissent le niveau de résilience dont
elles ont besoin pour intégrer les services
dépendants.

CHAPITRE 3 : POST-MORTEMS DES INCIDENTS 59

 Mesures post-mortem
Sue Lueder et Betsy Beyer de Google ont rédigé une excellente
présentation et un brillant article sur les mesures post-mortem.
Chez Atlassian, nous nous en servons pour interpeller l'équipe. Cette
section repose sur leurs suggestions.* Répondez aux questions ci-
dessous pour vous assurer que le post-mortem couvre des corrections
à court et à long terme :

Catégorie Question à poser Exemples

Examiner cet « Qu'est-ce qui a provoqué Analyses de journaux,

incident cet incident et pourquoi ? » schématisation du parcours
Déterminer les causes de la requête, examen des
profondes est votre but « heap dumps »
ultime.

Atténuer cet « Quelles mesures Annulation d'un

incident immédiates avons-nous changement, sélection,
prises pour résoudre et gérer push de configurations,
cet événement spécifique ? » communication avec les
utilisateurs concernés

Réparer les « Comment réparer les Restauration des

dommages dommages directs ou données, réparation des
causés par cet collatéraux causés par cet machines, suppression des
incident incident ? » réacheminements du trafic

Détecter les « Comment réduire le délai Surveillance, alerte, contrôles

incidents nécessaire pour détecter de vraisemblance sur les
futurs précisément un incident entrées/sorties
similaire ? »

*
Consultez le site https://www.usenix.org/conference/srecon17americas/program/presentation/lueder pour tous les
documents source.

60 MANUEL DE GESTION DES INCIDENTS ATLASSIAN

 Catégorie Question à poser Exemples

Réduire le « Comment limiter la Dégradation progressive,

nombre gravité et/ou la durée des abandon des résultats non
d'incidents incidents similaires futurs ? » critiques, authentification
futurs « Comment réduire le sans mot de passe,
pourcentage d'utilisateurs augmentation des pratiques
affectés par cette classe actuelles grâce à des
d'incident lors de la prochaine tableaux de bord ou des
occurrence ? » playbooks, changements
apportés aux processus de
réponse aux incidents

Prévenir les « Comment éviter la Améliorations de la stabilité

incidents récurrence de ce type de la base de code, tests
futurs d'incident ? » unitaires plus approfondis,
validation des entrées et
résistance aux erreurs,
changements apportés au
provisionnement

« Atténuer les futurs incidents » et « Prévenir les futurs incidents »

sont vos sources d'actions les plus probables pour éliminer la cause
profonde. Assurez-vous d'en mettre en place au moins une.

Nous suivons aussi les conseils de Sue Lueder et de Betsy Beyer sur la
manière de formuler nos mesures post-mortem :

La formulation adaptée pour une mesure post-mortem peut faire la

différence entre une exécution simple et un report indéfini en raison
de l'infaisabilité de la mesure ou par procrastination. Une mesure
post-mortem bien conçue devrait présenter ces propriétés :
· Exploitable : indiquez chaque mesure sous forme de phrase
commençant par un verbe. La mesure doit se traduire par un
résultat utile, et non un processus. Par exemple, « Énumérer la
liste des dépendances critiques » est une mesure adaptée, alors
que « Examiner les dépendances » n'en est pas une.

CHAPITRE 3 : POST-MORTEMS DES INCIDENTS 61

 · Spécifique : définissez le périmètre de chaque mesure le plus
précisément possible, en clarifiant ce qui est compris ou non
dans le travail.
· Limité : formulez chaque mesure pour préciser comment savoir
qu'elle est finie, de sorte que son état ne soit pas indéterminé ou
perpétuellement en cours.

Hier… Demain…

Examinez la surveillance pour ce (Exploitable) Ajoutez une alerte pour tous

scénario. les cas où ce service renvoie plus de 1 %
d'erreurs.

Corrigez l'erreur qui a entraîné la (Spécifique) Gérez le code postal non valide
panne. dans le formulaire d'adresse de l'utilisateur
en toute sécurité.

Assurez-vous que l'ingénieur (Limité) Ajoutez un contrôle automatisé

vérifie que le schéma de base de avant la soumission pour les changements
données peut être analysé avant de schéma.
la mise à jour.

Réunions post-mortem
Le propriétaire du post-mortem convoque une réunion post-mortem
une fois qu'il a rempli les champs du ticket et élaboré une théorie
solide quant aux causes de l'incident et aux mesures d'atténuation
appropriées.
Chez Atlassian, nous constatons que les réunions en face à face
permettent une communication plus efficace et plus rapide, une
analyse plus approfondie et un apprentissage plus utile. Nous
encourageons les équipes à utiliser ce type de réunion autant que
possible. Cependant, il est parfois impossible de réunir tout le
monde en même temps en raison de contraintes géographiques ou
temporelles, de sorte qu'il faut parfois prévoir plusieurs réunions ou
obtenir des contributions de manière asynchrone.

62 MANUEL DE GESTION DES INCIDENTS ATLASSIAN

Bien que nous utilisions le terme « face à face », ces réunions se
déroulent souvent par vidéoconférence, puisque nos équipes sont
distribuées. Parfois, elles impliquent un large public de parties
prenantes intéressées.
Le programme de notre réunion post-mortem standard est le suivant :
1. Rappeler à l'équipe que tous les post-mortems doivent être sans
reproche, et pourquoi (voir « Pourquoi les post-mortems doivent-
ils être sans reproche ? » ci-dessus).
2. Parcourir la chronologie des événements. Ajouter ou modifier des
éléments si nécessaire.
3. Présenter votre théorie sur les causes de l'incident et les
domaines dans lesquels vous pensez que des mesures
d'atténuation pourraient être appliquées pour éviter ce type
d'incident à l'avenir. Discuter avec les participants et essayer de
développer une compréhension commune de ce qui s'est passé,
des raisons de l'incident, et de ce que nous devons généralement
faire dans cette situation.
4. Déterminer des mesures en utilisant la « réflexion ouverte »
(par exemple, « Que pourrions-nous faire pour empêcher cette
catégorie d'incidents ? ») et essayer d'éviter la « réflexion
fermée » (par exemple, « Pourquoi n'avons-nous pas surveillé le
système x ? »). Une réflexion ouverte permet de générer des idées
nouvelles, « sortant des sentiers battus », parce que vous ne
limitez pas la réflexion des participants à l'état actuel des choses.
5. Demander à l'équipe : « Qu'est-ce qui s'est bien passé ? Qu'est-ce
qui aurait pu aller mieux ? Où avons-nous eu de la chance ? »
Ces questions permettent de repérer les quasi-incidents, les
enseignements, les mesures d'atténuation et les mesures qui
se situent en dehors de la zone d'influence directe de l'incident.
N'oubliez pas que notre objectif est d'extraire le plus de valeur
possible étant donné que nous avons déjà payé le prix d'un incident.
6. Terminer en remerciant chacun pour son temps et sa participation.

CHAPITRE 3 : POST-MORTEMS DES INCIDENTS 63

Voici un modèle que vous pouvez utiliser lorsque vous invitez des
participants :

Joignez-vous à moi pour un post-mortem sans reproche de <lien vers l'incident>,

où nous <résumé de l'incident>.

Un post-mortem vise à maximiser la valeur d'un incident en comprenant

toutes les causes impliquées, en documentant l'incident pour référence future
et identification de schémas, et en mettant en place des mesures préventives
efficaces pour réduire la probabilité ou l'impact d'un nouvel incident de ce type.

Lors de cette réunion, nous passerons en revue l'incident, nous déterminerons

ses principales causes et nous déciderons de mesures à prendre pour les
éliminer.

Une bonne réunion post-mortem donnera lieu à de nombreuses mesures

d'atténuation et autres actions. C'est une bonne chose, mais souvent,
les réunions post-mortem sont un mauvais contexte pour les décisions
importantes de hiérarchisation des priorités, parce que vous ne disposez
pas du bon contexte (par exemple, le reste du backlog et d'autres tâches
prévues auxquelles il faudra également consacrer du temps).

C'est pourquoi il est généralement plus efficace, dans la pratique,

d'assurer un suivi auprès des responsables après la réunion pour
obtenir des engagements plus fermes et limités dans le temps en ce
qui concerne les mesures que vous avez identifiées lors de la réunion,
puis d'indiquer ces informations dans le ticket post-mortem.

64 MANUEL DE GESTION DES INCIDENTS ATLASSIAN

Approbations de post-mortem
Atlassian utilise un workflow Jira avec étape d'approbation pour
garantir l'approbation des post-mortems. Les approbateurs sont
généralement des Service Owners ou d'autres responsables chargés
de la gestion d'un service. L'approbation d'un post-mortem indique ce
qui suit :

· Accord sur les résultats de la revue post-incident, notamment sur

la nature de la cause profonde ; et
· Accord sur le fait que les « mesures prioritaires » associées
constituent une bonne façon d'éliminer la cause profonde.

Souvent, nos approbateurs exigeront des mesures supplémentaires

ou identifieront un certain lien de causalité non traité par les mesures
proposées. De cette façon, nous constatons que les approbations
génèrent une forte valeur ajoutée dans notre processus de post-
mortem chez Atlassian.

Dans les équipes rencontrant moins d'incidents ou utilisant une

infrastructure moins complexe, les approbations de post-mortem ne
sont pas forcément nécessaires.

Comment sont suivies les mesures post-mortem ?

Pour chaque mesure tirée d'un post-mortem, nous :

· créons un ticket Jira dans le backlog de l'équipe appropriée.

Nous suivons toutes nos mesures post-mortem dans Jira ;
· associons les mesures issues du ticket post-mortem comme
« Mesure prioritaire » (pour les atténuations significatives) ou
« Mesure d'amélioration » (pour les autres mesures issues du
ticket post-mortem).

CHAPITRE 3 : POST-MORTEMS DES INCIDENTS 65

Nous distinguons les mesures « prioritaires » des mesures
« d'amélioration » afin de pouvoir indiquer, à tout moment, les
incidents qui ont vu leurs causes importantes éliminées, et ceux qui
représentent encore un risque de récurrence. Cela nous donne une
idée de l'ampleur du risque de répétition des incidents que courent
nos différents groupes.

Nous utilisons les liens vers des tickets Jira pour suivre les mesures.
En effet, nos équipes exploitent de nombreuses instances différentes
de Jira Cloud et Server, mais nous devons quand même suivre ces
données et en rendre compte. Pour ce faire, nous avons développé
des outils personnalisés, qui permettent d'établir des liens entre
les tickets distants et de renseigner les résultats dans une base de
données. Cela nous permet de suivre l'évolution des choses dans le
temps et de créer des rapports détaillés.

Restez calme et poursuivez…

Vous êtes arrivé au bout de notre manuel de gestion des incidents.
Nous vous remercions de l'avoir lu.

Pour nous faire part de votre feedback ou de vos suggestions, écrivez-

nous à l'adresse suivante [email protected].

66 MANUEL DE GESTION DES INCIDENTS ATLASSIAN

CHAPITRE 3 : POST-MORTEMS DES INCIDENTS 67
Aide-mémoire du gestionnaire
d'incident
Nous aimerions conclure avec une version de l'aide-mémoire que
nous fournissons à nos gestionnaires d'incidents majeurs. Il décrit
les responsabilités du gestionnaire d'incident de la manière la
plus simple possible, et indique d'autres documents et ressources
pertinents.

Nous utilisons des URL internes courtes pour fournir un accès rapide
et faciliter leur mémorisation. Par exemple, l'URL courte de cette page
est « go/mimcheatsheet ». La plupart de ces URL redirigent vers une
page Confluence interne. Beaucoup de nos gestionnaires d'incidents
impriment cet aide-mémoire et le suspendent dans leur bureau.

68 MANUEL DE GESTION DES INCIDENTS ATLASSIAN

Aide-mémoire du gestionnaire
d'incident
Connexion Remontée
· Connectez-vous au VPN · De qui d'autre avons-nous besoin pour
· Résolvez la page résoudre ce problème ?
· Assignez-vous le ticket HOT (Nous – Équipe de plateforme ou
utilisons « HOT » comme clé de ticket d'infrastructure, autres produits ?
pour les tickets d'incident dans Jira. go/oncall
Par exemple, un ticket d'incident peut – Vous avez besoin d'un responsable
s'appeler « HOT-1234 ». Par conséquent, dédié à la communication externe ?
les équipes Atlassian appellent go/externalcomms
souvent les incidents des HOT) – Incident de sécurité ? go/
– Les systèmes d'incident sont en pagesecint
panne ? – Besoin de plus de gestionnaires
go/backups d'incidents majeurs ? go/imoc
Communication ouverte – AWS ? go/awshelp
– Responsable de l'ingénierie/DSI/
· Cliquez sur « Configuration de Fondateurs ?
l'incident » dans le HOT · Quelqu'un d'autre ?
· Réunissez l'équipe dans Slack et Zoom · Annuaire
Évaluation · Liste des utilisateurs d'Opsgenie
· Les fournisseurs sont repris dans
· Évaluez la gravité go/severity Service Central
– Quel est l'impact sur les clients ?
– Que voient les clients ? Délégation
– Combien de clients sont affectés ? · Déléguez explicitement ces rôles :
– Quand l'incident a-t-il débuté ? – Responsable(s) technique(s)
– Combien de tickets de support – Communications internes
existe-t-il ? – Communications externes
– Autres facteurs ? (Twitter, perte de
données, sécurité) Tâches périodiques
· Confirmez les produits concernés par · Mise à jour des communications go/
le HOT communicate
· Confirmez la gravité du HOT · L'impact a-t-il changé ?
· Publiez rapidement des – Quelles sont les observations ?
communications initiales (<=30 min) Enregistrement avec horodatage
– Internes : go/internalcomms – La gravité a-t-elle changé ?
– Externes : go/externalcomms
· Durée de l'incident : qui doit être
relevé ?
· Incident de sécurité ? Page SecInt
– Qui reprendra quels rôles à qui,
go/pagesecint quand ?
– go/handover
Communication Résolution
· Publiez régulièrement des · Vérifiez auprès de CSS que le service
communications de mise à jour est restauré
– Intervalle maximal de 180 min – Feedback des clients
· Suivez cette liste de contrôle en – Observations directes
cinq points pour les communications : – Fournisseurs externes
– Quel est l'impact actuel sur les · Mise à jour finale des communications
clients ? internes et externes
– Combien de clients internes et – Résolvez les incidents Statuspage
externes sont affectés ? – Fermez l'incident dans go/
– Une cause profonde est-elle multistatuspageupdater
connue ? De quoi s'agit-il ? – Résolvez le HOT ; définissez
– Disposons-nous d'une date l'impact et les délais de détection
approximative de restauration ?
Quelle est-elle ?
– Créez un PIR et obtenez la
responsabilité de son achèvement
– Quand et où se fera la prochaine
mise à jour ? Relève
Correction · Gestionnaire d'incident majeur
sortant : appel en privé avec le
· Quel est le comportement observé par gestionnaire d'incident majeur entrant
rapport au comportement attendu ?
· Tout changement (par exemple,
– Qui quitte un rôle et qui le reprend ?
déploiements, flags de fonctionnalité)
– Quels sont les théories et
workflows actuels ?
go/changedashboard
· Partagez vos observations :
– Quand est prévue la prochaine
relève et qui s'en charge ?
graphiques, journaux, tickets GSAC, etc.
· Développez des théories sur la
· Gestionnaire d'incident majeur
entrant : soyez les premiers à vous
situation
tenir au courant
· Prouvez ou réfutez les théories
– Posez beaucoup de questions !
· Quels sont les workflows ?
· Qui est le responsable technique pour Systèmes de sauvegarde
chaque workflow ?
· Communications : Zoom IM ;
· Quelles sont les étapes actuelles et Google Hangouts pour la vidéo
les prochaines étapes pour chacun
d'entre eux ?
· Documents : « MIM Offline Material »
dans Google Drive
· Comment ces étapes nous mènent-
· ISD : Google Docs
elles à la résolution ?
· Suivez les changements, les décisions
· Ticket HOT : projet Hello/J IMFB

et les observations

Responsabilité et comportement du gestionnaire d'incident

Un incident majeur est plus prioritaire que toute autre activité entreprise par
Atlassian. En tant que gestionnaire d'incidents majeurs, vous pouvez et devez
anticiper toutes les tâches en cours et prévues pour réunir la meilleure équipe
et la pousser à résoudre l'incident. Votre rôle est de commander, de prendre les
choses en main et de mettre de l'ordre dans le chaos.
 Manuel de gestion
des incidents
Si vous faites partie d'une équipe de
développement ou opérationnelle,
responsable de services pour des clients
nécessitant une disponibilité 24 h/24 et
7 j/7, ce manuel est fait pour vous.

Vous avez des questions ?

Contactez-nous à l'adresse [email protected]