Peculiaridades y componentes de una revisión posterior al incidente adecuada
Ya sabemos qué es una revisión posterior al incidente, nuestro cometido en el proceso de respuesta al incidente y cuándo debe realizarse. En esta unidad, profundizaremos un poco más en algunos detalles que hacen que una revisión posterior al incidente sea más eficaz.
Dado que cada incidente es diferente, la composición exacta de las revisiones posteriores al incidente también puede serlo, Pero hay algunas peculiaridades y componentes comunes de toda buena revisión que nos pueden proporcionar una base sólida para llevar a cabo este proceso.
Lo que una revisión posterior al incidente no es
Para comprender las peculiaridades que hacen que una revisión posterior al incidente sea buena, antes debemos evaluar qué no es.
- No es un documento ni un informe. Es fácil pensar en una "revisión" como en un resumen escrito y, de hecho, un informe de resumen suele ser algo que se elabora tras una revisión posterior al incidente. Pero estas son dos cosas distintas y diferenciadas de la fase de análisis dentro del ciclo de vida de respuesta a incidentes.
- No es una averiguación de la causalidad. En una revisión se examinan los factores que han contribuido al error, pero el objetivo no es señalar al culpable (especialmente, no una causa raíz única, ya que los errores en los sistemas complejos casi siempre se deben a un conjunto diverso de factores que contribuyen). Se trata de pensar y compartir información sobre todos los aspectos del incidente de cara a aprender y mejorar. No es una lista de elementos de acción. Puede que acabemos elaborando una lista de este tipo como resultado de lo que hemos aprendido en la revisión, pero esto no es lo primordial. Si no confeccionamos una lista de los elementos de una cola de vales o de los informes de error de un sistema de notificación de errores, pero en cambio sabemos más que antes sobre esos sistemas, la revisión habrá sido un éxito.
La revisión posterior al incidente es, ante todo, una conversación . Se trata de un espacio demarcado en el que nuestro equipo puede revisar lo que sabía en aquel momento y lo que sabe ahora, así como explorar y comprender mejor cómo las partes del sistema (incluida la humana) funcionan de manera conjunta en respuesta a un problema.
Peculiaridades y componentes
Tal y como dijimos en la última unidad, una revisión posterior al incidente no debe ser acusatoria. Aunque necesitemos analizar el modo en que la parte humana del sistema ha intervenido en él, no debemos hacerlo para etiquetar a nadie como "culpable". Debemos centrarnos en los errores de la tecnología y el proceso, no de las personas.
Formulemos pues nuestras preguntas para reflejar esto, por ejemplo:
- ¿Qué ha faltado en nuestra supervisión para que la persona encargada no haya tenido el contexto necesario a fin de tomar la decisión correcta?
- ¿Por qué había una opción del tipo "destruir la base de datos completa" en la herramienta?
- O mejor aún: ¿Por qué la herramienta no pidió confirmación antes de realizar esta función?
Cuando hay algún problema, resulta muy tentador señalar con el dedo, pero conviene siempre recordar este punto clave:
La fiabilidad no se logra despidiendo a gente.
Poner en evidencia y culpar a alguien, o realizar una investigación dirigida a hallar y despedir a la persona "responsable", no nos llevará a obtener un sistema más fiable. Solo nos dará un equipo de operaciones sin experiencia o incluso mermado y un personal temeroso de actuar.
Debemos plantear la revisión como una búsqueda de conocimiento y contexto, no como una cacería en busca de quien haya hecho algo y como una reacción ante el asunto.
Aunque este tipo de revisiones está relacionado con los errores de tecnología, no es tanto un proceso técnico como un proceso sobre las personas. Hablemos con las personas involucradas en el incidente. Mejor aún, escuchémoslas. Seamos abiertos de mente. Cada persona tiene un punto de vista distinto y habrá desacuerdos, y es esa combinación de puntos de vista lo que aporta tantísimo valor al proceso de aprendizaje.
Una revisión posterior al incidente es una consulta honesta y, como tal, abarca los siguientes componentes clave:
- Debate
- Diálogo
- Desacuerdo
- Detección
Estas "4 D" crean un marco en el que podemos crear una revisión posterior al incidente que dé como resultado unos sistemas más fiables y unos equipos más productivos que trabajan conjuntamente.
En la siguiente unidad, hablaremos con mayor detalle del proceso que podemos seguir para crear una revisión posterior al incidente efectiva.