Caractéristiques et composantes d’un bon examen post-incident
Vous savez maintenant ce qu’est une révision post-incident, son rôle dans le processus de réponse aux incidents et quand vous devez en effectuer un. Dans cette unité, vous allez explorer un peu plus en détail ce qui rend un examen post-incident le plus efficace.
En raison de la diversité des incidents, la composition exacte des examens post-incident peut également varier. Toutefois, il existe certaines caractéristiques et composants communs d’une bonne révision qui peuvent vous fournir une base solide pour mener à bien le processus.
Ce qu’il n’est pas
Avant de comprendre les caractéristiques qui constituent un bon examen post-incident, vous devez réfléchir à ce qui ne l'est pas.
- Il ne s’agit pas d’un document ou d’un rapport. Il est facile de considérer un « examen » comme un résumé écrit, et en effet, un rapport de synthèse suit souvent un examen post-incident. Toutefois, il s’agit de deux parties différentes et distinctes de la phase d’analyse du cycle de vie des réponses aux incidents.
- Ce n’est pas une détermination de la causalité. Votre examen examine les facteurs qui ont contribué à l’échec, mais l’objectif n’est pas d’identifier un coupable (en particulier pas une cause racine unique ; les systèmes complexes échouent presque toujours en raison d’un ensemble complet de facteurs contributeurs). Il s’agit de réfléchir et de partager des informations sur tous les aspects de l’incident afin d’apprendre et d’améliorer. Il ne s’agit pas d’une liste d’éléments d’action. Vous pouvez vous retrouver avec une telle liste à la suite de ce que vous apprenez dans la révision, mais ce n’est pas le focus. Si vous ne venez pas avec une liste d’éléments dans une file d’attente de tickets ou des rapports de bogues dans un système de rapports de bogues, mais que vous savez plus sur vos systèmes que précédemment, la révision a réussi.
L’examen d’un incident est, plus que tout, une conversation. Il s'agit d'un espace défini dans lequel votre équipe peut revoir ce qu'elle savait à l'époque et ce qu'elle sait maintenant, et explorer et mieux comprendre comment les parties du système, y compris les parties humaines, fonctionnent ou non ensemble en réponse aux problèmes. .
Caractéristiques et composantes
Comme nous l’avons mentionné dans la dernière unité, l’examen d’un incident doit être exempt de reproche. Bien que vous deviez examiner la manière dont les parties humaines du système ont interagi avec celui-ci, vous ne le faites pas dans le but de qualifier quiconque de « fautif. » Il convient de se concentrer sur les échecs de la technologie et du processus, et non sur celles des personnes.
Formulez vos questions en conséquence, par exemple :
- Quel est le déficit dans notre surveillance qui n’a pas donné à la personne au clavier le contexte nécessaire pour prendre la bonne décision ?
- Pourquoi y avait-il une option « détruire toute la base de données » dans l’outil ?
- Ou, mieux encore : Pourquoi l’outil n’a-t-il pas demandé de confirmation avant d’effectuer cette fonction ?
En cas de problème, il peut être tentant de pointer quelqu’un du doigt. Toutefois, vous devez garder à l’esprit le point clé suivant :
Vous ne pouvez pas déclencher votre moyen de fiabilité.
La honte et le blâme ou une enquête visant à trouver et à licencier la personne « responsable » ne mèneront pas à des systèmes plus fiables. Au lieu de cela, il mène à une équipe d’opérations inexpérimentée ou même vide et au personnel qui ont peur d’agir.
Considérez l’examen comme la recherche de connaissances et de contexte, et non comme la recherche des actions des uns et des autres et des mesures qu’elles appellent.
Bien que l’examen concerne les défaillances de la technologie, ce n’est pas un processus technique autant qu’il s’agit d’un processus de personnes. Parlez—et plus important, écoutez—les personnes impliquées dans l’incident. Gardez l’esprit ouvert. Chaque personne a son point de vue et tout le monde n’est pas d’accord, et cette combinaison de points de vue est inestimable pour le processus d’apprentissage.
Un examen post-incident est une enquête honnête. En tant que tel, il s’appuie sur les composantes clés suivantes :
- Discussion
- Débat
- Désaccord
- Découverte
Ces « 4 Ds » créent un framework sur lequel vous pouvez créer une révision post-incident qui peut entraîner des systèmes plus fiables et des équipes plus productives qui travaillent ensemble.
Dans le cadre de notre prochaine unité, nous aborderons plus en détail le processus que vous pouvez suivre pour créer un examen post-incident efficace.