Pourquoi apprendre des incidents ?

Quand un incident se produit, votre première réaction n’est probablement pas : « Hurray, une opportunité d’apprentissage ! » Votre priorité immédiate consiste à déterminer ce qui s’est passé et à le corriger aussi rapidement que possible, afin de réduire l’impact sur vos clients et utilisateurs finaux, comme il le devrait être. Il s’agit du processus de réponse aux incidents que nous avons abordé dans un autre module de ce parcours d’apprentissage.

Toutefois, une fois l’incident résolu, il est important de suivre et de tirer parti de l’expérience. Si nous ne prenons pas le temps d’apprendre de l’incident, il reste juste une perte de temps, d’argent, de réputation, et ainsi de suite ; mais si cet incident peut être une source d’informations (de la façon dont aucune autre source ne peut) nous pouvons réellement en tirer parti.

L’examen post-incident fait partie de la phase d’analyse du cycle de vie de la réponse aux incidents. Tous les examens post-incident ne sont pas identiques à la base. Il existe différentes façons d’aborder le processus, et trop de focus sur certains aspects du problème ou l’encadrement des questions de manière incorrecte peut réduire la valeur de l’examen.

Dans cette unité, vous allez commencer à réfléchir non seulement à la raison, mais aussi à la façon dont vous pouvez mieux apprendre à partir d’incidents. Nous allons développer le « comment » dans les unités suivantes.

Échec des systèmes complexes

Vous devez « apprendre à apprendre » de l’échec non pas en cas d’échec de vos systèmes, mais parce qu’il s’agit d’une certitude que vos systèmes échouent .

Dans le monde moderne, la majorité des systèmes que nous travaillons aujourd’hui, en particulier dans un environnement cloud, sont complexes. Ils sont composés de nombreuses parties d’interconnexion qui doivent fonctionner ensemble, et le comportement global du système provient de l’interaction de ces parties autant que des parties individuelles elles-mêmes.

La fiabilité est le fil conducteur de ce parcours d’apprentissage, mais les systèmes complexes ne sont jamais fiables à cent pour cent. Ces systèmes se comportent de manière intéressante et contre-intuitive. Ils sont composés de nombreuses parties, et souvent le comportement du système provient des interactions entre ces parties autant que des parties elles-mêmes.

Pour une discussion plus approfondie de ce sujet, une bonne ressource est le document intitulé How Complex Systems Fail by Dr. Richard I. Cook. Il est anesthésiste et chercheur qui a passé des décennies à travailler sur la sécurité dans les systèmes complexes, en particulier la sécurité des patients dans le système de santé. Dans ce document, il explique ce qui est commun aux systèmes complexes dans tous les domaines de la santé aux opérations logicielles.

Certains de ses points clés sont particulièrement pertinents pour l’analyse des incidents et le processus de révision post-incident :

• Les systèmes complexes contiennent des mélanges changeants de défaillance latentes dans ces systèmes. Il est impossible que vos systèmes s’exécutent sans plusieurs défauts présents. Les défaillances changent constamment en raison de la modification de la technologie, de l’organisation du travail et des efforts visant à éradiquer l’échec. Votre système ne fonctionne jamais parfaitement.
• Les systèmes complexes s’exécutent en mode détérioré. Les systèmes complexes s’exécutent toujours en tant que systèmes « rompus ». Ils continuent de « fonctionner » dans cet état, car ils contiennent de nombreuses redondances, et les utilisateurs peuvent les maintenir opérationnels en dépit de la présence de nombreux défauts. Les opérations système sont dynamiques, les composants échouent continuellement et sont remplacés.
• La catastrophe est toujours juste autour du coin. La complexité de ces systèmes signifie que les défaillances majeures du système sont inévitables à long terme. Les systèmes complexes possèdent toujours le potentiel d’une défaillance catastrophique et peuvent se produire à tout moment. Il est impossible d’éliminer ce potentiel parce qu’il fait partie de la nature inhérente du système.

Prévention et réponse

Dans vos efforts pour atteindre votre niveau de fiabilité souhaité pour vos systèmes et services, vous faites tout ce qui est possible pour empêcher les incidents de se produire. Toutefois, en raison de la complexité de ces systèmes, comme expliqué précédemment, la prévention n’est pas toujours possible.

En raison de cette réalisation, nous devons adopter une approche à deux volets de l’échec : la prévention et, quand cela n’est pas possible, la préparation pour répondre rapidement et efficacement.

La prévention et la réponse sont entrelacées. Vous avez peut-être rencontré cela lorsque votre organisation a déployé une partie sophistiquée de l’automatisation qui a fonctionné la plupart du temps. C’était génial qu’il fonctionnait la plupart du temps, mais quand il a échoué, il a probablement échoué spectaculairement, et a rendu plus difficile pour les opérateurs de comprendre ce qui s’était mal passé.

Les systèmes sur lesquelles vous travaillez sont constitués de plus que la technologie. En fait, vous ne travaillez pas « sur » ou « avec » un système ; vous travaillez dans le système. Vous faites partie du système. Les systèmes complexes incluent à la fois des composants techniques (matériel, logiciel) et des composants humains (personnes et leurs personnalités, formation et connaissances). Nos systèmes incluent les humains, et la façon dont les humains réagissent quand les choses vont mal est aussi importante que d’empêcher les choses d'aller mal en premier lieu.

Langue

La langue est importante. Vous allez apprendre dans ce module que nous serons très précis sur les termes que nous utilisons et ceux que nous n’utilisons intentionnellement pas.

Les mots que nous utilisons affectent la façon dont nous réfléchissons à ce qui s’est passé dans un incident, et peuvent changer radicalement ce qui et combien nous apprenons. Cette conclusion provient de la recherche dans des secteurs critiques en matière de sécurité tels que l’aviation, la médecine, la recherche et le sauvetage, la lutte contre les incendies, etc.

Collectivement, ce domaine de recherche est devenu connu sous le nom d’ingénierie de résilience (RE).

Nous avons beaucoup à apprendre sur l’ingénierie de résilience dans le secteur technologique. Plus loin dans ce module, nous partagerons des choses vraiment utiles que nous avons apprises à partir de la littérature RE, y compris quatre des pièges les plus courants que les gens tombent lors de la tentative d’apprendre de l’échec ; mais d’abord, nous devons définir certains termes.