Os action items de um postmortem travam porque escrever o documento encerra o assunto na cabeça de todo mundo. A correção cai num backlog sem dono, sem data e sem prioridade sobre as features. Daí vêm os incidentes repetidos. A saída é dar a cada item preventivo um dono com data e uma revisão que chegue antes do próximo incidente.
O livro de SRE do Google define o postmortem como um registro escrito do incidente. Esse registro termina com as ações de acompanhamento para que o incidente não volte. Ou seja, o documento existe para gerar trabalho. E esse trabalho é justamente o que fica pelo caminho. Se ninguém no seu time cuida do backlog de confiabilidade entre um incidente e outro, essa é a lacuna que um serviço de SRE e observabilidade existe para fechar.
Por que os action items do postmortem nunca são feitos?
Porque nada obriga esses itens a competir com o roadmap em pé de igualdade. O incidente tinha urgência. Usuários foram afetados, alguém foi acionado e o relógio estava visível para todo mundo. Os action items não herdam nada disso. Eles caem no backlog ao lado dos tickets de feature. Cada ticket de feature tem um product manager defendendo. O action item não tem ninguém.
O livro de SRE do Google é direto sobre o resultado. Sem um processo formal para aprender com os incidentes, eles podem se repetir indefinidamente. A palavra importante ali é processo. Um documento de postmortem sozinho não executa nada. Ele fica parado na wiki enquanto o mesmo fator contribuinte espera a próxima sexta-feira corrida.
Quatro padrões bastam para travar um action item. Nenhum deles precisa de má intenção.
O primeiro é a falta de clareza. Um item como melhorar o monitoramento não tem linha de chegada, então nunca termina. O segundo é a culpa disfarçada. A AWS lista como anti-pattern identificar só erro humano sem oferecer treinamento nem automação que evite esse erro. Tomar mais cuidado é um desejo. Ninguém consegue fechar isso.
O terceiro é o item que pertence a um time inteiro. Quando o dono é o time de plataforma, na prática o dono é quem tiver uma tarde livre. O quarto é a falta de revisão. Se ninguém olha os itens abertos até o próximo alerta, o próximo alerta vira a revisão.
O que faz um action item de postmortem valer a pena?
Um bom action item muda o sistema para que o mesmo fator contribuinte não consiga causar o mesmo impacto de novo. E ele está escrito de um jeito que uma pessoa consegue terminar e outra consegue verificar.
O exemplo público mais claro está no workbook de SRE do Google. Um descomissionamento de rack de rotina encontrou um bug na automação de manutenção. Parte do processo tinha falhado, então o time rodou de novo. Na segunda execução a lista de máquinas veio vazia. A API tratava uma lista vazia como ausência de filtro. Em minutos, os discos de todas as máquinas satélite do mundo foram apagados. Graças a um bom planejamento de capacidade, pouquíssimos usuários perceberam durante os dois dias de reinstalação.
O que veio depois não teve nada de glamoroso. O time passou várias semanas auditando a automação. Adicionou sanity checks para deixar o fluxo de descomissionamento idempotente. Três anos depois, um incidente parecido drenou vários satélites. O Google atribui aos action items do postmortem original uma redução enorme no que aconteceu da segunda vez.
É isso que se ganha quando o action item é terminado. O retorno pode chegar anos depois de todo mundo ter esquecido o ticket. Uma correção que mora na automação não depende de alguém lembrar do incidente.
A AWS acrescenta uma checagem que vale rodar em todo postmortem. Pergunte por que os testes existentes não pegaram o problema. Se não existe um teste para esse caso, adicione. Assim um incidente vira uma proteção permanente.
Antes de publicar o postmortem, eu reescreveria itens fracos assim:
| Action item fraco | Versão mais forte | Por que se sustenta |
|---|---|---|
| Tomar mais cuidado ao rodar a automação de novo | Deixar o fluxo idempotente e rejeitar uma lista de alvos vazia | A proteção mora no código e sobrevive à rotatividade do time |
| Melhorar o monitoramento | Alertar no sintoma que o usuário viu, para o on-call achar antes do cliente | O Google trata uma falha de monitoramento que obrigou descoberta manual como gatilho de postmortem |
| Adicionar mais testes | Adicionar um teste que reproduz a entrada exata deste incidente | A AWS pede para entender por que os testes existentes não pegaram o problema |
| Compartilhar os aprendizados | Levar o padrão para o checklist de pré-deploy que outros times usam | A AWS recomenda transformar padrões em guias de desenvolvimento e checklists |
| Investigar mais a causa raiz | Nomear a dúvida que sobrou, com um dono e uma data para trazer a resposta | Pergunta aberta ganha data de fim em vez de ficar aberta para sempre |
Quem deve ser dono dos action items do postmortem?
Uma pessoa específica por item, mais um responsável pelo acompanhamento de todos eles. São trabalhos diferentes.
O Well-Architected da AWS pede uma responsabilidade clara pelo processo de análise pós-incidente. Também recomenda designar um time ou uma pessoa para supervisionar as investigações e os follow-ups. Atribuir cada ticket é a metade fácil. Se você faz só essa metade, os itens apodrecem em silêncio. Cada dono acha que o próprio item está bem, e ninguém enxerga a pilha.
Quem cuida do acompanhamento não faz o trabalho. Essa pessoa garante que a lista reflita a realidade. Eu daria duas coisas para ela. A primeira é um espaço fixo na reunião semanal de planejamento. A segunda é autoridade para escalar qualquer item preventivo que passe da data duas vezes.
Se a sua empresa ainda está definindo onde termina SRE e onde começa plataforma, essa divisão está em engenharia de plataforma vs DevOps vs SRE. O responsável pelo acompanhamento pode existir antes desse debate terminar. Eu não esperaria.
A cultura blameless também pesa aqui. O livro de SRE do Google diz que um postmortem sem culpa parte do princípio de que todos agiram com boa intenção e fizeram o certo com a informação que tinham. Se os action items parecem castigo, as pessoas negociam até eles virarem nada. O alvo do item é o sistema, nunca uma pessoa.
Como priorizar action items do postmortem frente às features?
Pelo custo da próxima ocorrência, com a decisão tomada na revisão do postmortem e o dono do roadmap na sala. Se quem define a prioridade das features nunca vê os action items, eles perdem antes de entrar na disputa.
Nem todo item merece ser construído. O livro de SRE do Google lembra que o postmortem tem um custo real de tempo e esforço. Por isso o time escolhe com cuidado quando escrever um. Aplique a mesma disciplina aos itens. Cada um deve sair da revisão com um de dois destinos. Ou ganha dono, data e lugar no plano, ou é fechado como risco aceito com o motivo por escrito. Qualquer um dos dois é honesto. Um item aberto há dois trimestres não é nenhum dos dois.
Eu ordenaria os candidatos com uma pergunta por item. Se esse fator contribuinte disparar de novo no mês que vem, quanto custa em impacto para o usuário e em horas de on-call? Itens que evitam perda de dados ou indisponibilidade visível vêm primeiro. Itens que só encurtam a detecção vêm depois. O Google cita perda de dados de qualquer tipo e indisponibilidade visível para o usuário acima de um certo limite entre os gatilhos comuns de postmortem. É uma boa pista de onde colocar o peso.
Depois, proteja uma fatia pequena e fixa de cada ciclo de planejamento para os itens que sobreviveram. Combine o tamanho antes do próximo incidente, enquanto ninguém está com a cabeça quente. Uma fatia negociada na semana do outage é trocada por outra coisa na semana seguinte.
Como saber se os seus postmortems estão evitando incidentes repetidos?
Veja se os incidentes novos compartilham um fator contribuinte com algum postmortem antigo que ainda tem itens abertos. Se compartilham, você já tem a resposta para a liderança.
A AWS nomeia esse modo de falha sem rodeios. Sem um mecanismo para guardar as lições aprendidas, os times acabam com incidentes repetidos. E a causa raiz é a mesma, ou muito parecida.
Alguns números simples dizem mais do que redesenhar um dashboard. Conte quantos incidentes do último trimestre batem com o fator contribuinte de um postmortem anterior. Anote a idade do item preventivo aberto mais antigo. Compare os itens fechados como feitos com os fechados como risco aceito. Se o risco aceito está ganhando, diga isso em voz alta na revisão.
Se você já acompanha as métricas DORA, mantenha. Elas mostram que algo está errado. Elas não dizem qual postmortem você ignorou.
Vale também ampliar o que conta como incidente. A AWS lembra que um incidente não precisa de uma queda. Um quase incidente também conta. Quase incidentes são repetições baratas. Registre de forma curta e compare com os itens abertos do mesmo jeito.
Por último, compartilhe os resultados além do time que foi acionado. A AWS observa que compartilhar a análise permite que outros workloads mitiguem o risco quando têm os mesmos fatores contribuintes. Uma correção que vive no backlog de um time protege só esse time.
Comece pelo último incidente repetido
Pegue o incidente sobre o qual a liderança perguntou mais recentemente. Abra os postmortems do último ano e procure o mesmo fator contribuinte. Reserve 30 minutos para isso. Se encontrar um postmortem anterior com um item preventivo aberto, você tem a resposta honesta para a repetição. Leve esse item para a próxima reunião de planejamento com o nome de um dono e uma data do lado. Depois peça para o dono do roadmap encaixar o item antes de a reunião acabar.
Fontes
- sre.google, consultada em 29 de outubro de 2026 (sha256 ef876f0a0f09).
- sre.google, consultada em 29 de outubro de 2026 (sha256 25b55c64c879).
- docs.aws.amazon.com, consultada em 29 de outubro de 2026 (sha256 942fdbe73578).