Cet article a été initialement publié sur le blog de Jeli. Jeli a été racheté par PagerDuty en 2023 et nous le republions ici pour apporter leur leadership éclairé à notre communauté.

Au fur et à mesure que vous animez la revue d'apprentissage, des idées de changements ou de plans surgiront naturellement. Lors des revues d'incidents, les gens veulent trouver des solutions, souvent avant que le problème ne soit pleinement compris. Résistez à cette envie ! Au lieu de prendre le temps, lors de la revue d'apprentissage, de préciser à quoi devraient ressembler ces plans, les points d'action devraient idéalement être abordés séparément de la réunion principale de revue d'apprentissage. Nous recommandons d'organiser une réunion entièrement distincte si possible. Cela permet de garder l'accent de la revue d'apprentissage sur l'apprentissage. Si cela n'est pas possible, identifiez les éléments qui nécessitent une action à la fin de la réunion et demandez aux personnes de poursuivre les discussions avec les parties prenantes nécessaires à un moment et dans un espace dédiés ultérieurs. Mais commençons d'abord par déterminer quels sont les bons types de points d'action.

Quelles sont les bonnes actions à entreprendre ?

Prenons ce scénario d'incident : un changement a été introduit dans le service Gandalf qui permet aux clients d'effectuer une nouvelle action. Cela a augmenté le trafic vers le service Atlas, ce qui a révélé un bug présent dans le code depuis des années. La réponse a été longue car tous les signes indiquaient qu'Atlas était affecté, que l'équipe avait ajouté de la capacité, mais qu'elle n'avait pas de contexte complet sur les changements apportés à Gandalf. Il a fallu un certain temps pour réunir les bonnes personnes et il y a maintenant des conflits entre les équipes.

Où se trouvent les « bons » éléments d’action ? S’assurer que l’équipe Gandalf informe toujours l’équipe Atlas avant d’effectuer un changement ? Corriger ce bug dans le code ? Ajouter quelque chose pour détecter ce bug dans une suite de tests ? Ajouter des alertes pour indiquer quand les clients effectuent cette action spécifique ? Mettre automatiquement à l’échelle la capacité de ce service ? Empêcher les clients d’effectuer cette action ? Il peut s’agir de tous ces éléments, ou d’aucun d’entre eux. La seule « bonne » réponse ici est : cela dépend.

Lors de la création d'éléments d'action, il est primordial de comprendre quel est le résultat escompté. S'agit-il d'empêcher que certains aspects de ce scénario d'échec très spécifique ne se reproduisent ? Il peut s'agir, par exemple, de risques spécifiques à atténuer. S'agit-il d'avoir un aperçu de la façon dont les personnes et les systèmes travaillent ensemble lorsque quelque chose ne va pas ?

Lorsque vous proposez des changements, il est préférable de vous concentrer sur le système dans son ensemble plutôt que sur une partie seulement (comme un individu). Si vous constatez que vous recherchez des solutions de type commandement et contrôle, cela peut être le signe que vous n'êtes pas sur la bonne voie dans votre recherche d'un changement systémique. C'est particulièrement vrai si l'élément à l'étude consiste à modifier une politique après une erreur commise pour « ne plus commettre l'erreur X ». Un élément d'action comme celui-ci indique qu'il reste encore beaucoup à apprendre sur les circonstances entourant cette erreur et sur les options disponibles pour les individus dans cette situation.

Qui devrait prendre les mesures à prendre ? Qui devrait en être « propriétaire » ?

Les éléments d’action doivent être créés et gérés par les personnes chargées de mettre en œuvre les plans et d’effectuer les travaux. Ces éléments sont souvent plus complexes qu’un simple ticket et il faut réfléchir à la planification des projets ou à la rédaction de propositions/plans de changement. Créer des éléments d’action que d’autres doivent exécuter est un moyen de garantir la confusion, le débat et la résistance. Si quelque chose doit être mis en œuvre, les personnes qui travaillent quotidiennement dans ces domaines sont les mieux placées pour déterminer ce qui doit être fait, si cela doit être fait et comment y parvenir.

Les éléments d'action ne doivent pas nécessairement être intégrés à votre système de gestion des tickets ou à votre travail d'ingénierie. Ils peuvent consister à modifier, mettre à jour, supprimer ou créer de nouveaux processus en fonction des commentaires issus de la revue. Ils peuvent consister à en apprendre davantage sur une technologie particulière, à étudier une partie du système ou même à enseigner à d'autres personnes, par exemple en organisant une présentation de l'architecture pour réorienter la compréhension de la manière dont les éléments fonctionnent ensemble.

Il peut être tentant d'assigner des dates d'échéance pour l'achèvement des éléments d'action. Cela est raisonnable si le calendrier est déterminé par élément en fonction de la charge de travail actuelle et du temps nécessaire au développement de la solution. Les SLA généraux sur l'achèvement des éléments d'action n'accomplissent qu'une seule chose : les éléments d'action sont dimensionnés spécifiquement pour être terminés dans ce délai. À moins que vos chefs de projet et de produit prévoient que le travail résultant d'un incident ait immédiatement la priorité sur tous les délais existants, exiger que les éléments d'action liés à l'incident soient terminés dans un délai spécifique oblige les ingénieurs à faire des compromis par rapport à d'autres priorités essentielles.

Changer notre façon de penser les mesures à prendre

Dans le domaine des incidents technologiques, l'accent est davantage mis sur la réduction des erreurs que sur la génération d'informations. Cela est compréhensible car les erreurs sont déjà visibles et donc plus faciles à corriger, mais cela ne nous sert pas aussi bien que nous le pensons.

Après un incident, on a souvent le sentiment que l'objectif est d'empêcher que cet incident ne se reproduise. En réalité, quoi que nous fassions, nous ne nous retrouverons probablement jamais dans un tel cas. Nous pouvons empêcher que des scénarios d'incidents très spécifiques ne se reproduisent grâce à une série de mesures correctives techniques. Mais nous ne pouvons pas empêcher de nouveaux incidents qui peuvent avoir des facteurs contributifs différents avec un impact identique ou similaire. C'est la réalité des incidents dans des systèmes de plus en plus complexes : différents déclencheurs, facteurs contributifs et risques se combinent pour créer un problème nouveau et différent qui a un impact sur le fonctionnement de ce service, de ce système ou de cette fonctionnalité. Même les mesures correctives techniques des incidents d'aujourd'hui peuvent être un facteur contributif de l'incident de demain.

Cela ne veut pas dire que les mesures correctives techniques sont mauvaises ou inutiles. Il s'agit souvent de solutions immédiates nécessaires pour rétablir l'impact des opérations attendues, ou de problèmes évidents comme « l'outil ne confirme pas avant la suppression », qui peuvent être résolus. Cependant, si l'objectif est de construire un système plus résilient, les mesures correctives techniques ne suffisent pas.

Connaissances des systèmes sociotechniques = véritable résilience

Lorsqu'un incident a un impact similaire à un incident précédent, ce ne sont probablement pas les corrections techniques précédentes qui aideront à résoudre le nouveau problème, mais les connaissances acquises sur les systèmes sociotechniques à partir de cet incident qui nous aideront à mieux répondre à celui-ci.

Nous avons vu Learning Reviews générer des informations approfondies sur les systèmes sociotechniques à travers des discussions autour de :

• Comment nous accédons, surveillons et alertons sur les données système disponibles
• Comment déchiffrons-nous ces données et comment savons-nous ce qu'elles indiquent
• Comment savons-nous quelles personnes rassembler pour nous aider dans ce que nous voyons ?
• Comment nous parlons entre nous et avec nos clients de ce qui se passe
• Comment déterminons-nous les voies à suivre pour parvenir à la remédiation ?
• Comment savoir si l’assainissement a été efficace
• Être capable d’acquérir un aperçu de ces aspects (et d’autres) de la prestation de services est la façon dont nous découvrons les sources de résilience du système.

Nos systèmes et nos employés sont en constante évolution. Les connaissances que nous tirons de chaque incident nous permettent de continuer à apprendre pour mieux comprendre nos systèmes et nos collègues. Lorsque nous accordons la priorité à l'apprentissage comme réponse lorsque les choses tournent mal, nous nous concentrons sur la compréhension de ce que nous ne savions pas auparavant ou au fur et à mesure que l'incident se déroulait, au lieu de chercher immédiatement des solutions. Ensuite, à partir de notre nouvelle perspective, plus éclairée, nous pouvons déterminer si des actions sont nécessaires et nous adresser aux personnes les plus proches du problème pour déterminer à quoi pourraient ressembler les solutions.

Pour des informations plus détaillées sur ces sujets et d'autres, vous pouvez toujours consulter Howie : Le guide post-incident pour plus d'informations sur l'analyse des incidents.