Llevar los elementos de acción de un postmortem hasta su cierre: bugs de seguimiento, un único responsable y revisión por antigüedad

Objetivo

Asegurar que los cambios que promete un postmortem realmente se llevan a cabo, y hacer visible cuando no ocurre así, de modo que el mismo incidente no pueda repetirse con un documento que ya lo predecía.

Requisitos previos

Una práctica de postmortems que produzca elementos de acción, un rastreador de issues que use todo el equipo, y una reunión periódica de operaciones o de fiabilidad.

Pasos

1. En la revisión del postmortem, reescribir cada elemento hasta que nombre un cambio de sistema con un criterio de cierre. El ejemplo de mal postmortem del workbook usa frases como "mejorar" y "hacerlo mejor" y enumera elementos sin responsable; cada uno de esos se devuelve.
2. Asignar a cada elemento exactamente un responsable, una prioridad, un tipo (la tabla de ejemplo del workbook usa investigar, prevenir, mitigar, reparar y detectar) y un bug de seguimiento. El libro de SRE indica que, una vez que las personas implicadas están conformes con el documento y sus elementos de acción, el postmortem se añade a un repositorio de incidentes pasados; enlazar el bug desde el documento y el documento desde el bug antes de que eso ocurra.
3. Marcar al menos un elemento como la corrección preventiva del desencadenante; si ninguna es viable, el documento debe decirlo y explicar por qué. El workbook señala que cambiar el comportamiento humano es menos fiable que cambiar sistemas automatizados, de modo que los elementos del tipo "tener más cuidado" no cuentan.
4. Fijar fechas límite según la prioridad. El workbook cita la regla de que todos los postmortems posteriores a una interrupción que afecta a usuarios deben tener asociado al menos un bug P0 o P1; adoptar un equivalente local.
5. Revisar los elementos abiertos cada dos o cuatro semanas en la reunión periódica, ordenados por antigüedad. Para cada elemento que ha superado su fecha, elegir una de estas opciones: hacerlo ahora, redefinir su alcance, o cerrarlo como "no se hará" con el motivo anotado tanto en el bug como en el postmortem. Dejarlo en la lista sin cambios no es una opción.
6. Cuando un elemento se cierra, registrar en el postmortem qué cambió y cómo se verificó: la nueva alerta se disparó en una prueba, el runbook se usó en un simulacro, el límite se aplica mediante configuración.
7. Trimestralmente, contar los elementos abiertos, cerrados y descartados, y revisar juntos los descartados; un patrón de elementos preventivos descartados es en sí mismo un hallazgo.

Resultado esperado

Un archivo de postmortems en el que cada elemento está hecho, rechazado de forma explícita o visiblemente vencido, y un equipo capaz de decir qué cambió a raíz de un incidente.

Límites y base de verificación

Los elementos grandes (reescrituras, migraciones) pertenecen a la hoja de ruta, con el postmortem enlazando a ellos; llevarlos como elementos de acción produce líneas permanentemente vencidas. El procedimiento sigue los capítulos citados; no se afirma ninguna tasa de cierre.