Acompanhar as ações de um postmortem até o fechamento: tracking bugs, responsável único e revisão por idade

Objetivo

Garantir que as mudanças prometidas por um postmortem realmente aconteçam e tornar visível quando não acontecem, para que o mesmo incidente não volte a ocorrer com um documento que já o previa.

Pré-requisitos

Uma prática de postmortem que produza ações (action items), um issue tracker que todos usem e uma reunião recorrente de operações ou confiabilidade.

Passos

1. Na revisão do postmortem, reescreva cada item até que indique uma mudança em um sistema, com um critério de conclusão. O exemplo de postmortem ruim do workbook usa expressões como "improve" e "make better" e lista itens sem responsáveis; todos esses itens são devolvidos.
2. Atribua a cada item exatamente um responsável, uma prioridade, um tipo (a tabela de exemplo do workbook usa investigate, prevent, mitigate, repair e detect) e um tracking bug. O livro SRE afirma que, quando os envolvidos estão satisfeitos com o documento e suas ações, o postmortem é adicionado a um repositório de incidentes passados; antes que isso aconteça, vincule o bug ao documento e o documento ao bug.
3. Marque pelo menos um item como correção preventiva para o gatilho do incidente; se nenhuma for viável, o documento deve dizer isso e explicar por quê. O workbook observa que mudar o comportamento humano é menos confiável do que mudar sistemas automatizados, portanto itens do tipo "ter mais cuidado" não contam.
4. Defina os prazos de acordo com a prioridade. O workbook cita a regra de que todo postmortem posterior a uma indisponibilidade que afete usuários deve ter pelo menos um bug P0 ou P1 associado; adote um equivalente local.
5. Revise os itens abertos a cada duas a quatro semanas, na reunião fixa, ordenados por idade. Para cada item com prazo vencido, escolha uma das opções: fazer agora, redefinir o escopo ou encerrar como "will not do" (não será feito), com o motivo registrado tanto no bug quanto no postmortem. Deixar o item na lista sem alteração não é uma opção.
6. Quando um item for fechado, registre no postmortem o que mudou e como isso foi verificado: o novo alerta disparou em um teste, o runbook foi usado em um exercício simulado, o limite é imposto por configuração.
7. Trimestralmente, conte os itens abertos, fechados e descartados e leia juntos os descartados; um padrão de itens preventivos descartados é, por si só, uma constatação.

Resultado esperado

Um arquivo de postmortems em que cada item está concluído, explicitamente recusado ou visivelmente atrasado, e uma equipe capaz de dizer o que um incidente mudou.

Limites e base de verificação

Itens grandes (reescritas, migrações) pertencem ao roadmap, e o postmortem deve apontar para eles; acompanhá-los como ações gera linhas permanentemente atrasadas. O procedimento segue os capítulos citados; nenhuma taxa de conclusão é afirmada.