Pourquoi apprendre des incidents ?
Quand un incident se produit, votre première réaction n’est probablement pas « Génial, une opportunité d’apprentissage ! ». Votre priorité immédiate consiste, à juste titre, à déterminer le problème et à le résoudre le plus rapidement possible, afin de réduire l’impact sur vos clients et les utilisateurs finaux. 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 tirer parti de l’expérience qu’il a procurée. 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 des réponses aux incidents. Tous les examens post-incident ne sont pas identiques à la base. Il existe différentes façons d’aborder le processus, et le fait de trop se concentrer sur certains aspects du problème ou de mal formuler les questions 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.
Les systèmes complexes échouent
Vous devez « apprendre à apprendre » d’un échec, non pas au cas où vos systèmes échoueraient, mais parce qu’il est certain que vos systèmes vont échouer.
Dans le monde moderne, la majorité des systèmes que nous utilisons aujourd’hui, surtout dans un environnement cloud, sont complexes. Ils sont composés de nombreux éléments interconnectés qui doivent fonctionner ensemble, et le comportement global du système résulte de l'interaction de ces éléments autant que des éléments individuels eux-mêmes.
La fiabilité est le fil conducteur de ce parcours d’apprentissage, mais les systèmes complexes ne sont jamais fiables à 100 %. De tels systèmes se comportent de manière intéressante et non intuitive. Ils sont composés de nombreux éléments interconnectés qui doivent fonctionner ensemble, et le comportement global du système résulte de l'interaction de ces éléments autant que des éléments individuels eux-mêmes.
Pour une discussion plus approfondie de ce sujet, n’hésitez pas à consulter le document How Complex Systems Fail, rédigé par Richard I. Cook. Ce dernier est anesthésiste et chercheur, et a passé des dizaines d’années à 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, allant de la santé au fonctionnement des logiciels.
Certains des points clés qu’il souligne sont particulièrement pertinents pour l’analyse des incidents et le processus d’examen post-incident :
- Les systèmes complexes contiennent des combinaisons fluctuantes d’échecs latents. Il est impossible que vos systèmes fonctionnent sans qu’ils comportent plusieurs défauts. Les échecs évoluent constamment, car la technologie, l’organisation du travail et les efforts visant à les éradiquer changent aussi. Votre système ne fonctionne jamais parfaitement.
- Les systèmes complexes fonctionnent en mode dégradé. Les systèmes complexes fonctionnent toujours en tant que systèmes « cassés ». 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, avec des composants qui échouent et sont remplacés en permanence.
- Une catastrophe est toujours imminente. En raison de leur complexité, ces systèmes sont appelés à connaître des échecs majeurs à long terme. Les systèmes complexes peuvent à tout moment être victimes d’un échec majeur. Il est impossible d’éliminer ce risque, car il est inhérent au système.
Prévention et réponse
Dans vos efforts pour atteindre le niveau de fiabilité souhaité pour vos systèmes et services, vous faites tout ce qui est en votre pouvoir pour éviter que des incidents ne se produisent. Toutefois, en raison de la complexité de ces systèmes, comme expliqué précédemmentt, la prévention n’est pas toujours possible.
Face à ce constat, nous devons adopter une double approche de l’échec : prévention et, quand celle-ci n’est pas possible, préparation à la réponse, rapidement et efficacement.
La prévention et la réponse sont liées entre elles. Vous l’avez peut-être constaté si votre organisation a déployé un élément d’automatisation sophistiqué qui fonctionnait la plupart du temps. La plupart du temps, à votre grande satisfaction, il fonctionnait très bien, mais quand il échouait, cela devait probablement être spectaculaire, au point que les opérateurs devaient avoir du mal à comprendre ce qui s’était passé.
Les systèmes sur lesquels vous travaillez ne sont pas qu’un concentré de technologie. De 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 des composantes techniques (matériels, logiciels) et des composantes humaines (personnes, avec leurs personnalités, formations et connaissances). Nos systèmes sont des systèmes qui incluent des êtres humains, et la façon dont ces derniers réagissent en cas de problème est aussi importante que la prévention des problèmes eux-mêmes.
Langage
Le langage est important. Dans ce module, vous allez découvrir que le choix des termes que nous utilisons et des termes que nous écartons délibérément ne doit rien au hasard.
Les mots que nous utilisons affectent la manière dont nous pensons à ce qui s’est produit au cours d’un incident, et peuvent changer radicalement ce que nous apprenons et l’ampleur de l’apprentissage. Cette découverte est le fruit de recherches dans les secteurs critiques pour la sécurité tels que l’aviation, la médecine, les services de recherche et de sauvetage, la lutte contre les incendies, etc.
Ce large domaine de recherche s’appelle l’ingénierie de la résilience (RE).
Nous avons beaucoup à apprendre sur l’ingénierie de la résilience dans le secteur des technologies. 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.