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. 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.