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é.

Il existe un vieux dicton selon lequel le meilleur outil pour une tâche est celui dont vous disposez. De même, la meilleure analyse d'incident pour votre organisation est celle que les gens effectueront réellement. Il n'existe pas de solution universelle. Bien sûr, ce serait formidable si nous pouvions consacrer deux semaines à l'enquête sur chaque incident, mais ce n'est probablement pas réaliste.

Chaque incident est unique. Même si un incident semble similaire ou se répète, il est arrivé à des personnes différentes à des moments différents. Il y a presque toujours quelque chose de nouveau à apprendre. Le temps, l'attention et les efforts que vous consacrez à l'analyse d'un incident doivent être basés sur son potentiel à révéler des informations sur les pratiques, les systèmes, l'historique ou l'expertise de votre organisation. Nous ne voulons pas et n'avons pas besoin de faire le même niveau d'analyse pour chaque incident.

Il est donc utile de développer les compétences nécessaires pour reconnaître les incidents susceptibles de révéler des informations précieuses et ceux qui ne méritent pas qu'on y consacre autant de temps. Pour ceux qui méritent une analyse plus approfondie, nous voulons en tirer le meilleur parti possible et investir le temps, l'attention et les efforts que nous avons mentionnés plus haut afin que notre organisation en tire le meilleur parti possible. Mais comment développer ces compétences de repérage d'informations ?

Il y avait plusieurs équipes (>2) impliquées

La coordination entre les équipes peut accroître les difficultés de gestion des incidents lorsque des équipes qui n’ont jamais travaillé ensemble doivent le faire sous pression, dans l’incertitude et sous la pression du temps. Les difficultés peuvent être amplifiées si les intervenants ne comprennent pas tous comment travailler ensemble efficacement. Cela peut signifier ne pas savoir qui sait quoi sur les différentes parties du problème, qui a (ou n’a pas) accès aux informations nécessaires, et même des choses simples comme la façon de réunir tout le monde pour travailler ensemble sur le problème (par exemple en étant dans des espaces de travail Slack différents ou sur des appels Zoom distincts). Les difficultés de gestion augmentent souvent à mesure que le nombre d’équipes, de personnes et de logiciels différents impliqués augmente.

L’enquête sur ce type d’incidents peut aider à identifier les sources d’expertise approfondie au sein de l’entreprise, ce qui n’est pas forcément représenté par les organigrammes ou la composition des équipes. Se concentrer sur la coordination entre les équipes est un investissement rentable, car des études ont montré que la connaissance organisationnelle tacite est essentielle pour une réponse fluide aux incidents.

Un nouveau service ou une interaction entre services était impliqué

Les interactions imprévues entre les composants logiciels peuvent être source de confusion lorsque ce que le répondant pensait devoir se produire ne se produit pas. En d'autres termes, leurs modèles mentaux internes sur le système sont différents de ce qu'il est réellement. Dans ces cas, les modèles mentaux sont partiels, incomplets ou erronés, une caractéristique très courante du travail au sein de systèmes complexes et changeants.

Enquêter sur ce type d’incidents peut aider toutes les parties (les intervenants eux-mêmes, les lecteurs des rapports d’incident ou les participants aux autopsies) à mettre à jour leurs propres modèles mentaux similaires ou à partager des informations qui pourraient être utiles aux autres.

Cela impliquait l’utilisation ou la mauvaise utilisation de quelque chose qui semblait simple ou sans intérêt.

De même, les modèles mentaux peuvent être bogués ou erronés en raison de simplifications excessives. L’utilisation d’heuristiques – ou de raccourcis mentaux – est courante, même dans les performances des experts. L’ingénierie logicielle implique souvent de développer une compréhension du fonctionnement du système au fil du temps à travers un ensemble d’expériences du système dans des conditions de fonctionnement variables.

Les simplifications excessives sont facilement perçues comme telles avec le recul, après l'incident. Une enquête doit être menée pour révéler ce qui a semblé logique aux intervenants pour voir les choses telles qu'elles étaient. révèle souvent plusieurs autres personnes qui pensaient la même chose ! Ces incidents sont donc une opportunité d'apprendre quand et comment les simplifications sont utilisées par vos ingénieurs et de discuter du comportement prévu et attendu pour augmenter le partage des connaissances.

L'événement impliquait un cas d'utilisation auquel on n'avait jamais pensé (indication d'une surprise)

Tout logiciel contient un modèle de ses utilisateurs : il s'agit des hypothèses formulées par les développeurs sur les compétences et les capacités des utilisateurs et sur la manière dont ils pourraient utiliser le logiciel. Un logiciel bien conçu tente de prendre en compte les cas d'utilisation imprévus en échouant de manière élégante. Une mauvaise conception entraîne une baisse des performances lorsque le logiciel est utilisé en dehors des conditions de fonctionnement prévues.

L'enquête sur ce type d'incidents peut révéler des informations importantes sur la manière dont les clients utilisent le logiciel, sur la manière dont les intervenants en cas d'incident raisonnent sur une utilisation imprévue et sur la meilleure façon de soutenir la réponse aux incidents en cas de défaillance où il existe un degré élevé d'incertitude.

L’événement a failli être vraiment grave, autrement dit un « quasi-accident »

Un « presque incident » est un incident qui aurait pu se passer très différemment si quelqu'un n'avait pas remarqué « par hasard » un tableau de bord bancal ou un ingénieur qui « par hasard » regardait les journaux. Ces erreurs apparemment « chanceuses » révèlent souvent des informations importantes sur les performances quotidiennes normales du système. Il peut s'agir de personnes clés qui, sans y être invitées, recherchent systématiquement les problèmes ou de quelqu'un qui écoute les conversations du support client pour détecter les premiers signaux de problèmes.

L’étude de ces « presque » événements peut permettre de découvrir ces comportements utiles et de les codifier pour renforcer la résilience. Ces types d’incidents sont souvent évoqués dans des conversations informelles, soit en raison de la peur qu’ils suscitent (« cela aurait pu être si mal ! »), soit de la curiosité qu’ils suscitent (« je me demande pourquoi cela n’a pas fini par être pire ? »).

Cela ressemble à un incident « répété »

Personne n’aime vivre deux fois le même incident : cela peut démoraliser les ingénieurs, frustrer les managers, mettre en colère les clients ou attirer l’attention des régulateurs.

Des analyses plus approfondies d'incidents apparemment répétés peuvent être utiles pour mettre en évidence des différences subtiles mais non négligeables qui ont rendu la gestion de l'incident particulièrement difficile pour les intervenants. Elles peuvent également aider à comprendre quels types de pressions organisationnelles (comme des équipes surchargées) et de contraintes (comme des limitations dans le code) ont empêché l'application d'une mesure corrective antérieure.

Les exemples que nous voyons dans l’ensemble du secteur peuvent inclure couramment des « expirations de certificats » ou des « modifications de configuration ». De tels exemples peuvent généralement refléter un problème systémique plus profond qui rend ces erreurs susceptibles d’être fréquentes.

Il y a beaucoup de discussions autour de l'incident dans les canaux Slack ou au bureau

Un intérêt ou une attention continue sur un incident peut indiquer une curiosité, une surprise ou un malaise face à certains aspects de l'événement. Les détails techniques peuvent être intéressants ou importants pour d'autres travaux d'ingénierie. Il peut s'agir d'un problème latent de longue date qui continue de provoquer des perturbations et qui n'est pas traité en raison de facteurs organisationnels tels que le cloisonnement, le refus de collaborer, des équipes surchargées ou des opinions divergentes sur la priorité des travaux nécessaires pour le résoudre.

Enquêter sur ce type d’incidents peut constituer un excellent développement professionnel pour l’équipe d’ingénierie afin d’approfondir sa compréhension des différents types de logiciels ou une chance de réparer ou de développer des relations interfonctionnelles.

Il y a eu une certaine confusion exprimée au cours ou autour de l'événement

Un certain degré de confusion sur ce qui se passe lors d'un événement est normal en cas de défaillance de systèmes complexes. Des périodes prolongées d'incertitude ou des difficultés à formuler des hypothèses sur la source des problèmes ou les mesures potentielles à prendre pour obtenir plus d'informations peuvent être le signe d'un déficit de connaissances. Cependant, identifier un manque de connaissances comme étant la cause d'un incident signifie que des détails importants sur l'intégration et la formation, les transferts, les révisions de code, la mise à jour continue et le partage des connaissances ne sont pas examinés.

Nous aimons particulièrement enquêter sur ce type d’incidents pour offrir des opportunités de micro-apprentissage3 où les participants partagent leur expertise et posent des questions de clarification pour aider à améliorer la compréhension.

L'incident a eu lieu lors d'un événement important (c'est-à-dire une « conférence téléphonique sur les résultats »)

Les incidents qui surviennent lors d'événements à haute visibilité, malgré les tests et les mesures d'atténuation proactives, peuvent être atroces en raison de leur impact plus important sur l'entreprise.

Enquêter sur ces incidents peut contribuer à restaurer la confiance des clients ou des dirigeants et aider les équipes d’ingénierie à faire face à des incidents potentiellement traumatisants en fournissant des réflexions transparentes et réfléchies sur les facteurs contributifs.

Il existe un intérêt à approfondir cette question (par exemple, gros client, préoccupation de la direction, etc.)

Les fonctions extérieures à l’ingénierie (support client, marketing ou cadres supérieurs) peuvent exprimer un intérêt pour mieux comprendre un événement. Engager l’organisation dans la pratique de l’analyse des incidents est un excellent moyen de générer un soutien pour les activités d’apprentissage post-incident et d’encourager les différentes parties de l’organisation à apporter leurs points de vue, élargissant ainsi encore l’impact du temps et des efforts consacrés à l’enquête.

L'apprentissage est le but

Bien que les éléments ci-dessus représentent des pistes prometteuses pour les recherches à mener, de nombreuses entreprises ont leurs propres critères internes et nous constatons au fil du temps que les ingénieurs développent un sens aigu de ce qui apportera de la valeur à leur équipe ou à leur entreprise. Au fil du temps, il devient plus facile et plus efficace de déterminer les éléments à étudier. C'est la même chose pour le développement de logiciels : un ingénieur plus expérimenté peut écrire du code plus précieux en moins de temps qu'un ingénieur qui apprend simplement à utiliser le système. Au fur et à mesure que vous continuez à enquêter sur vos incidents et vos quasi-accidents, votre organisation apprendra à affiner davantage les types d'incidents qui font l'objet d'une enquête et à contribuer à une culture d'ingénierie plus proactive et plus résiliente.

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