Blameless postmortem canvas template

Canvas de postmortem sem culpas

Este template de post-mortem "sem culpa" ajuda você a reunir informações sobre incidentes que ocorreram em produção.

Este template de Post-Mortem "sem culpa" ajuda você a reunir informações sobre incidentes que ocorreram em produção. Seguir esse processo significa que os engenheiros cujas ações contribuíram para um acidente podem dar um relato detalhado de:

  • quais ações eles tomaram e em que horário,

  • quais efeitos eles observaram,

  • expectativas que eles tinham,

  • suposições que fizeram,

  • seu entendimento da Timeline dos eventos conforme ocorreram.

  • e que possam fornecer este relato detalhado sem medo de punição ou retaliação.

O post-mortem sem culpa inclui as seguintes seções

Passo 1: Resumo (preencher antes da reunião)

Um resumo de alto nível do item, focando no que se sabe até agora e no impacto que causou ao cliente. Mantenha isso em uma ou duas frases.

Passo 2: Rascunho do Timeline (preencher antes da reunião)

Um cronograma aproximado do item. Dependendo de quão rápido o item se movimentou, esta Timeline pode abranger de poucos minutos a algumas horas ou alguns dias. Se o seu foco principal é melhorar os tempos de resposta do time durante emergências, você vai querer isso calculado até o segundo.

Ao capturar o timeline, certifique-se de incluir:

  • Quando o item foi relatado e por quem/qual processo

  • Quais ações foram tomadas

  • Quando a comunicação foi feita dentro e fora do time

Ideias de Remediação

  • Quando vocês se reunirem para discutir o item, convide todos que trabalharam no item. Isso inclui o time de suporte à produção, bem como os membros do time de suporte ao cliente que possam ter sido envolvidos.

  • Revise o resumo, revise a linha do tempo e adicione quaisquer partes que estejam faltando, depois passe para as ideias de remediação.

  • Essas perguntas são formuladas para ajudar o time a assumir a responsabilidade pelo problema. Existem alguns problemas que parecem estar fora do controle do time (o centro de dados perde energia, etc). Mas mesmo em eventos como esses, o time ainda pode melhorar sua reação ao desastre.

Passo 3: Detectar – Como detectamos este problema ou um problema assim mais cedo?

Assuma que esse problema ou um problema muito parecido com ele acontecerá novamente. Como o time de suporte pode detectar esse problema mais rapidamente e encontrá-lo antes que um cliente o faça?

Passo 4: React – Como podemos melhorar nossa reação a itens como esses?

Assuma que o item foi relatado. Quão rápida foi a reação? Foram perdidos minutos enquanto as pessoas enviavam e-mails tentando fazer alguém olhar o problema?

Como o time pode reagir de forma mais rápida ou mais organizada da próxima vez que esse item ocorrer?

Passo 5: Solução Rápida – Como parar o sangramento mais rapidamente?

Quando isso acontecer novamente, existe uma solução alternativa pronta que possamos fornecer ao cliente para reduzir o impacto do problema?

Se isso é algo que piora com o tempo (como um ataque DDoS), temos uma maneira rápida de fechar as comportas enquanto descobrimos a causa raiz?

Passo 6: Prevenção – Como evitamos ou reduzimos o impacto de itens assim no futuro?

Esta é frequentemente a única pergunta que os times fazem em um post-mortem. É uma pergunta importante e você deve gastar bastante tempo aqui. No entanto, se você se limitar a perguntar apenas como prevenir um item, isso faz com que você não assuma nenhuma responsabilidade pelas coisas sob seu controle (como a forma de detectar, reagir ou resolver rapidamente um item).

À medida que você faz brainstormings de ideias, não se limite a soluções técnicas. Melhor monitoramento, melhores caminhos de comunicação, melhor treinamento, garantindo que as pessoas no suporte ao cliente conheçam as pessoas no suporte à produção pelo nome, etc.

Passo 7: Outras áreas de risco – Quais outras áreas compartilham essa mesma vulnerabilidade?

Todo item é uma dica de onde seu sistema é fraco. As chances são de que, para cada item que você encontrar, há dezenas espreitando nas sombras, ainda por serem encontrados.

É como se você visse um rato na sua cozinha. Você não tem um problema de "mouse", você tem um problema de "mice".

É provável que existam outras partes do sistema que compartilhem os mesmos pressupostos de design ou, em alguns casos, o mesmo código (não que alguém vá copiar/colar código).

Reserve alguns minutos para fazer um brainstorming sobre outros locais que sejam vulneráveis de forma semelhante.

Quando os times estão estressados e sobrecarregados, eles pulam esta etapa. Acho que esta é a pergunta mais importante a fazer para colocar o time em uma mentalidade proativa e reduzir a ocorrência de itens no futuro.

Passo 8: Próximos passos (Ações)

Depois de identificar todas as possíveis ações que você pode realizar para melhorar como os itens são detectados, solucionados rapidamente e prevenidos... e você encontrou outras áreas do seu aplicativo que precisam de atenção... passe para decidir quais ações tomar.

A forma como você prioriza isso depende de você. Mas tenho alguns conselhos.

Obtenha um nome e uma data para cada ação que planeja realizar antes de sair da reunião.

Se alguém na reunião estiver interessado em assumir uma das ações, incentive-o a fazê-lo, mesmo que você ache que pode não ser a coisa mais importante a resolver.

Nomes e datas

Geralmente, eu descobri que os times gostam deste exercício (desde que você possa criar um ambiente de reunião sem culpabilização). Eles gostam de dissecar o problema e fazer um brainstorming de soluções. No entanto, todos se sentem ocupados e sobrecarregados. A menos que esta reunião finalize com titulares e datas ao lado das coisas que precisam ser feitas, a maior probabilidade é que nenhuma das melhorias aconteça.

O que acontecerá é que daqui a 3 semanas, quando o mesmo problema ocorrer na produção (mas desta vez de forma mais intensa), alguém dirá: "ah sim, falamos sobre consertar isso." Não é um ótimo lugar para estar.

Para combater isso, simplesmente certifique-se de que haja um nome e uma data ao lado de cada ação que o grupo deseja realizar.

Baseado no Canvas de Pós-Morte Sem Culpas de David Frink.

Canvas de postmortem sem culpas

Comece com esse modelo agora mesmo.

Modelos Relacionados
5Gs Retrospective
Visualizar
Retrospectiva 5Gs
Taco Tuesday Retrospective
Visualizar
Retrospectiva de Taco Tuesday
Cost Benefit Analysis Thumbnail
Visualizar
Modelo para Análise de Custo-Benefício
design-sprint-kit-thumb-web
Visualizar
Template para Design Sprint Kit
soccer-retrospective-template-thumb
Visualizar
Retrospectiva de Soccer
Miro Basics Guide for New Participants template thumb
Visualizar
Noções básicas do Miro: Guia para Novos Participantes