Caractéristiques et composants 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.

Étant donné que les incidents diffèrent, la composition exacte des révisions post-incident peut également être différente. 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 font d’une bonne révision post-incident, vous devez prendre en compte ce qui n’est pas le cas.

• 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 de la réponse 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.

La révision de l’incident est, plus que tout, une conversation. Il s’agit d’un espace défini dans lequel votre équipe peut examiner ce qu’elle savait au moment et ce qu’elle sait maintenant, et explorer et mieux comprendre comment les parties du système, y compris les parties humaines, font ou ne fonctionnent pas ensemble en réponse aux problèmes.

Caractéristiques et composants

Comme nous l’avons mentionné dans la dernière unité, un examen des incidents doit être sans blâme. Bien que vous deviez examiner la façon dont les parties humaines du système interagissent avec elle, vous ne le faites pas pour étiqueter quiconque « en panne ». L’accent devrait être mis sur les défaillances de la technologie et du processus, et non sur les gens.

Cadrez vos questions pour refléter cela, 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’exécuter cette fonction ?

Lorsque les choses vont mal, il peut être tentant de pointer les doigts. Toutefois, vous devez vous souvenir de ce point clé :

On ne peut pas licencier pour améliorer la fiabilité.

La honte et la culpabilité, ou une enquête visant à identifier et licencier la personne « responsable », ne conduiront 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.

Approchez l’examen comme une recherche de connaissances et de contexte, pas une chasse pour qui a fait quoi et une réaction à cela.

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 un esprit ouvert. Différentes personnes ont des perspectives différentes et tout le monde ne sera pas d'accord, et ce mélange de perspectives est inestimable pour le processus d’apprentissage.

Un examen post-incident est une enquête honnête. Par conséquent, il adopte ces composants clés :

• Discussion
• Débat
• Dissidence
• 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 notre unité suivante, nous allons en savoir plus sur le processus que vous pouvez suivre pour créer un examen post-incident efficace.