Pourquoi des thèmes ?

Nous pensons que l'analyse post-incident doit aller au-delà de l'analyse des causes profondes. Nous préconisons l'étude des thèmes de l'incident afin d'approfondir votre compréhension de votre travail – autrement dit, l'analyse thématique.

Mais qu'entend-on par thèmes ? Les thèmes sont les principaux enseignements tirés d'un incident et de l'analyse qui s'en est suivie. En se concentrant sur ces enseignements, plutôt que sur la seule et unique cause profonde ou en passant directement aux actions à entreprendre, les enquêteurs peuvent tirer des leçons de l'investissement que représente cet incident. Se focaliser sur ces autres éléments peut mener à… faux sentiment de sécurité ou d'accomplissement , laissant encore beaucoup à apprendre.

Par exemple, sans analyse thématique, on pourrait croire avoir tiré tous les enseignements d'un incident simplement parce qu'on a corrigé un bug et demandé d'éviter toute nouvelle interruption de production. Or, l'analyse thématique nous permet d'examiner les conditions qui ont permis à certains de provoquer ces interruptions, ou encore la manière dont les ingénieurs perçoivent l'impact des modifications apportées. Ce type de connaissance et de compréhension permet aux ingénieurs d'être mieux préparés à gérer les imprévus futurs, tout en minimisant le mode de défaillance spécifique observé lors de l'incident.

Comment les repérer

Dans le Guide Howie Nous encourageons les gens à « considérer leurs thèmes comme les sujets d'intérêt qui ont émergé tout au long de l'enquête : ce qui vous a surpris, ce que vous pensez que les autres devraient savoir de plus, ce qui est commun à d'autres incidents. »

Il est difficile de définir précisément ce qu'est un thème. Franchement, les repérer relève souvent de l'intuition. C'est pourquoi nous pensons que le récit est si important dans l'analyse des incidents. Nous aimons entendre les personnes impliquées raconter l'incident de leur point de vue, les laisser s'interroger mutuellement, puis poser les nôtres. Les éléments que les participants ont trouvés fascinants ou dignes d'être résumés peuvent constituer des thèmes. Ce sont des sujets de conversation, que l'on aborde lors de la fête de fin d'année ou des mois plus tard en discutant du travail avec un nouveau collègue. Ce sont autant d'enseignements importants et de thèmes potentiels pour l'enquête.

Jeli est conçu pour ce type d'analyse narrative d'incidents. Notre chronologie vous permet de visualiser précisément le déroulement de l'incident, offrant ainsi un excellent point de départ pour que chacun puisse partager son expérience. Lors de la préparation d'une analyse d'incident, vous pouvez consulter la transcription Slack des événements, commencer à construire un récit et noter vos questions. Ensuite, examinez ces questions et organisez-les par thèmes communs.

• Y a-t-il eu un élément technologique que nous n'avons pas compris lors de l'incident (ou dont je ne suis pas sûr en tant qu'enquêteur) ?
• Les gens étaient-ils incertains de l'impact ? Les personnes occupant différents postes au sein de l'organisation avaient-elles une perception différente de cet impact ?
• Les intervenants étaient-ils confus quant aux signaux qui leur étaient présentés ?
• Y a-t-il eu des incohérences dans la manière dont l'incident a été communiqué ?
• Est-ce que quelqu'un a fait quelque chose de vraiment génial lors du dépannage ?

Dans l'exemple ci-dessus, nous n'évoquons même pas les technologies impactées ; cela ne signifie pas pour autant que nous n'en tirons aucun enseignement. Nous pouvons aborder les facteurs contributifs et les mesures d'atténuation lors de la réunion d'analyse et dans le rapport d'incident ; chacun en apprendra davantage sur ses systèmes et pourra appliquer ces connaissances à son travail. Mais nous devons également examiner les thèmes spécifiques qui ont conduit à ce que l'incident se produise de cette manière. Cela permet une compréhension plus approfondie de l'incident, ce qui, à son tour, renforcera la résilience future.

Qu'est-ce qui n'est pas un thème ?

Bien qu'il n'existe pas de définition précise des thèmes d'incidents, il y a un certain nombre d'écueils à éviter lorsque vous découvrez les thèmes de votre incident.

• Actions à entreprendre. Si le problème peut être résolu par une pull request, il n'est pas considéré comme résolu. Cela ne signifie pas que nous négligeons les bugs lors d'une revue d'incident ; nous ne nous arrêtons simplement pas là.
• Accuser ou pointer du doigt. Lors de votre réunion d'évaluation, vous avez peut-être appris qu'une personne ou une équipe était à l'origine de l'incident. S'il est facile de dire « untel ne sait pas faire son travail », il est contre-productif d'interrompre l'enquête à ce stade, car cela risque de nuire à la confiance dans le processus post-incident. Nous cherchons plutôt à comprendre comment les événements ont conduit cette personne ou cette équipe à déclencher l'incident. Ont-ils hérité d'une nouvelle technologie qu'ils ne maîtrisent pas complètement ? Le processus d'intégration présente-t-il des lacunes ? Le système d'astreinte tient-il compte des cloisonnements de connaissances ?
• Tout ce qui est trop vague est à proscrire. Bien que le thème d'un incident puisse s'appliquer à d'autres incidents, technologies, voire à d'autres organisations, il doit toujours nous permettre d'en tirer des enseignements ! Il y a une différence entre « des incidents surviennent pendant le gel du code » et « l'urgence pour les ingénieurs de publier rapidement avant la période de gel du code peut les amener à précipiter les choses sans les contrôles habituels et appropriés, ce qui entraîne une augmentation des incidents ».

Que faire de ces thèmes ?

Maintenant que vous comprenez mieux ce que nous entendons par thèmes et comment les repérer, vous devriez partager vos connaissances.

Partagez-les !

Comme pour tout enseignement tiré d'un incident, il ne suffit pas de l'identifier. Votre travail portera ses fruits lorsque vous le partagerez. J'aime inclure les principaux enseignements thématiques dans tous mes rapports d'incident. Lors de la rédaction d'un résumé, je les intègre généralement à l'impact de l'incident et aux actions à entreprendre. Si vous rédigez un rapport d'incident, assurez-vous d'y inclure une section dédiée aux enseignements. Abordez-les lors des points hebdomadaires, des rétrospectives de sprint et des sessions d'intégration !

Repérez-les dans d'autres incidents

L'analyse croisée des incidents semble être au cœur des préoccupations actuelles. Plutôt que de s'attarder sur le délai moyen de résolution des incidents du trimestre précédent, il convient d'examiner les points communs entre eux. Combien d'incidents sont liés à une mauvaise compréhension des dépendances ? Quels impacts n'avons-nous pas pu appréhender faute de données suffisantes ? Nous approfondirons l'analyse croisée des incidents dans un prochain article, mais une analyse individuelle rigoureuse de chaque incident est indispensable pour tirer des enseignements de cette approche.

Commencer!

L'analyse thématique est une compétence nouvelle, différente de l'analyse traditionnelle des causes profondes ou des revues axées sur les actions à entreprendre. Le meilleur moyen de la maîtriser est de la pratiquer ; elle ne sera peut-être pas facile ni parfaite (la perfection n'est d'ailleurs pas nécessaire pour être utile) au début, mais l'analyse des incidents est comme un muscle : plus vous l'utilisez, plus elle se développe ! Ainsi, pour votre prochaine revue, prenez le temps (une trentaine de minutes) d'examiner le récit, notez vos questions et essayez de dégager deux ou trois thèmes à aborder en groupe.

Bonne analyse !