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 partager leur expertise avec notre communauté.

Lors de l'animation de la revue d'apprentissage, des idées de changements ou de plans surgiront naturellement. Lors des revues d'incidents, les participants souhaitent trouver des solutions, souvent avant même que le problème ne soit pleinement compris. Résistez à cette tentation ! Au lieu de consacrer du temps à élaborer ces plans, idéalement, les actions à mener devraient être traitées séparément de la réunion principale. Nous recommandons une réunion distincte si possible. Cela permet de concentrer la revue d'apprentissage sur l'apprentissage. Si cela n'est pas possible, identifiez les points à traiter à la fin de la réunion et demandez à des personnes de poursuivre les discussions avec les parties prenantes concernées lors d'un moment et d'un espace dédiés. Mais commençons d'abord par définir les actions à mener.

Quelles sont les bonnes actions à entreprendre ?

Prenons l'exemple d'un incident : une modification a été apportée au service Gandalf, permettant aux clients d'effectuer une nouvelle action. Cette modification a augmenté le trafic vers le service Atlas, révélant un bug présent dans le code depuis des années. La réponse a été longue, car tout indiquait qu'Atlas était impacté. L'équipe a augmenté ses capacités, mais n'avait pas de contexte complet sur les modifications apportées à Gandalf. Il a fallu du temps pour réunir les bonnes personnes et il y a maintenant des tensions entre les équipes.

Où se situent les actions « correctes » ? S'assurer que l'équipe Gandalf informe toujours l'équipe Atlas avant toute modification ? Corriger ce bug dans le code ? Ajouter un moyen de le détecter dans une suite de tests ? Ajouter des alertes pour signaler aux clients l'exécution de cette action ? Adapter automatiquement la capacité à ce service ? Empêcher les clients d'effectuer cette action ? Il peut s'agir de tout cela, ou d'aucun d'entre eux. La seule réponse « correcte » est : cela dépend.

Lors de la création d'actions, il est primordial de comprendre 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 ? Par exemple, s'il existe des risques spécifiques à atténuer. S'agit-il de mieux comprendre la collaboration entre les personnes et les systèmes en cas de problème ?

Lorsque vous proposez des changements, il est préférable de se concentrer sur le système dans son ensemble plutôt que sur une partie (comme un individu). Si vous avez tendance à privilégier des solutions de type « commandement et contrôle », cela peut indiquer que vous êtes sur la mauvaise voie dans votre quête d'un changement systémique. C'est particulièrement vrai s'il s'agit, par exemple, d'un changement de politique après une erreur commise pour « ne plus reproduire l'erreur X ». Une telle mesure indique qu'il reste encore beaucoup à apprendre sur les circonstances de cette erreur et sur les options qui s'offrent aux personnes concernées.

Qui devrait prendre les mesures à prendre ? Qui devrait en être « responsable » ?

Les actions à entreprendre doivent être créées et gérées par les responsables de la mise en œuvre des plans et des travaux. Souvent, ces actions sont plus complexes qu'un simple ticket et nécessitent une réflexion approfondie lors de la planification des projets ou de la rédaction de propositions/plans de changement. Créer des actions à exécuter par d'autres est un moyen de générer confusion, débats et résistance. Si une action est nécessaire, 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 actions à entreprendre ne doivent pas nécessairement être intégrées à votre système de gestion des tickets ni à vos travaux d'ingénierie. Elles peuvent inclure la modification, la mise à jour, la suppression ou la création de nouveaux processus en fonction des retours de la revue. Il peut s'agir d'approfondir une technologie particulière, d'étudier une partie du système, voire de former d'autres personnes, par exemple en organisant une présentation de l'architecture pour réorienter la compréhension du fonctionnement des éléments.

Il peut être tentant d'assigner des dates d'échéance pour la réalisation des actions. Cette approche est raisonnable si le calendrier est déterminé par action en fonction de la charge de travail actuelle et du temps nécessaire au développement de la solution. Les SLA généraux pour la réalisation des actions n'ont qu'un seul objectif : dimensionner les actions spécifiquement pour qu'elles soient réalisées dans ce délai. À moins que vos chefs de projet et de produit ne prévoient que le travail résultant d'un incident soit immédiatement prioritaire sur toutes les échéances existantes, exiger que les actions liées à un incident soient réalisées dans un délai précis oblige les ingénieurs à faire des compromis par rapport à d'autres priorités essentielles.

Changer notre façon de penser aux mesures à prendre

Dans le domaine des incidents technologiques, l'accent est généralement mis davantage 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 qu'on le pense.

Après un incident, on a souvent le sentiment que l'objectif est d'empêcher qu'il ne se reproduise. En réalité, quoi que nous fassions, nous ne nous retrouverons probablement jamais avec un tel incident. Nous pouvons empêcher la répétition de scénarios d'incidents très spécifiques grâce à une série de mesures correctives techniques. En revanche, nous ne pouvons pas empêcher de nouveaux incidents, dont les facteurs contributifs peuvent être différents et avoir 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 impacte le fonctionnement du service, du système ou de la fonctionnalité. Même les mesures correctives techniques des incidents d'aujourd'hui peuvent contribuer à l'incident de demain.

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

Connaissances du système sociotechnique = véritable résilience

Lorsqu'un incident a un impact similaire à un incident précédent, ce ne sont probablement pas les mesures techniques correctives 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 connaissances 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 savoir 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 nous déterminons les voies à suivre pour la remédiation
• Comment savoir si la remédiation a été efficace
• Être capable d’avoir 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 dans le système.

Nos systèmes et nos collaborateurs sont en constante évolution. Les enseignements tirés de chaque incident nous permettent de continuer à mieux comprendre nos systèmes et nos collègues. En priorisant l'apprentissage comme réponse aux problèmes, nous nous concentrons sur la compréhension de ce que nous ignorions auparavant ou pendant le déroulement de l'incident, plutôt que de chercher immédiatement des solutions. Grâce à notre nouvelle perspective, plus éclairée, nous pouvons déterminer si des actions sont nécessaires et identifier les solutions possibles auprès des personnes les plus proches du problème.

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.