Processo de post-mortem de incidentes: acompanhe, documente e melhore

Principais conclusões

• Os post-mortems de incidentes ajudam as equipes a entender o que aconteceu, por que aconteceu e o que precisa ser alterado para evitar que os problemas se repitam.

• Usar o Jira Service Management, o Confluence e o Jira juntos cria um fluxo de trabalho conectado para resposta, documentação e acompanhamento.

• Um template de post-mortem consistente facilita a documentação, comparação e aprendizado com as revisões de incidentes ao longo do tempo.

• Transformar ações corretivas em tickets do Jira com proprietários e prazos ajuda as equipes a converter lições aprendidas em melhorias reais. 

Quando algo dá errado na produção, a correção é apenas o começo. Tão importante quanto é compreender por que esse problema aconteceu e garantir que não se repita da mesma forma. 

Um post-mortem de incidente é uma análise estruturada do incidente do início ao fim, cobrindo o que falhou, como a equipe respondeu e o que precisa ser alterado daqui para frente.

Com um template de plano de resposta a incidentes orientando o processo, sua equipe pode documentar cada incidente com consistência, para que nada importante seja perdido e cada análise resulte em melhorias reais.

Como funciona: execução de incidentes e reunião de post-mortems

Um bom gerenciamento de incidentes não se resume apenas a apagar incêndios. É preciso criar um sistema em que cada incidente contribua para melhorar os processos, as ferramentas e a preparação para a próxima vez. Usar o Jira Service Management, o Confluence e o Jira juntos oferece à sua equipe um fluxo de trabalho conectado que abrange todo o ciclo de vida da resposta a incidentes, desde o momento em que um alerta é disparado até o post-mortem e o trabalho de acompanhamento. 

Essa abordagem mantém a documentação consistente entre incidentes e estabelece uma cadeia clara de responsabilidade. Em vez de os dados dos incidentes ficarem espalhados por mensagens no Slack, e-mails e na memória de alguém, tudo fica reunido em um único ecossistema integrado, onde pode ser analisado, consultado e utilizado para tomar medidas. Com essa consistência, seu template de plano de resposta a incidentes permanece central ao processo, em vez de ser algo que a equipe preenche quando tem tempo. 

Veja como o processo se divide em cada etapa:

Execute o incidente no Jira Service Management

O Jira Service Management é onde sua resposta a incidentes começa. Assim que um item chegar, registre ele no JSM, defina o nível de gravidade e atribua os responsáveis adequados. 

Durante o incidente, as equipes podem usar o JSM para:

• Acompanhar ações, decisões e escalonamentos em tempo real

• Manter um registro claro de quem esteve envolvido e o que foi alterado

• Reunir as informações que mais à frente vão dar suporte ao post-mortem

• Manter a liderança informada sem interromper os responsáveis

Uma vez que o JSM se integra ao Confluence e ao Jira, os dados coletados durante o incidente podem fluir direto para a documentação de post-mortem e o trabalho de acompanhamento. Para equipes que usam o JSM como parte de uma configuração mais ampla de software de ITSM, os dados do incidente também alimentam o panorama geral de gestão de serviços.

O JSM também oferece suporte a uma forte comunicação de incidentes durante toda a resposta, ajudando as equipes a:

• Manter clientes, equipes de suporte e partes interessadas atualizados

• Reduzir a confusão durante incidentes ativos

• Oferecer visibilidade sobre status e impacto

• Manter uma comunicação mais clara durante eventos de alta gravidade ou cenários de gestão de crises

Quando o incidente é resolvido, a equipe já tem um registro minucioso de como tudo aconteceu, o que torna o post-mortem mais fácil de documentar e mais útil para melhorias futuras.

Reunir o post-mortem no Confluence

Depois que o incidente for resolvido, ele deve ser documentado enquanto as informações ainda estão frescas na memória — de preferência, dentro de 24 a 48 horas. Quanto mais você espera, mais contexto se perde, e menos útil o post-mortem se torna. 

Crie uma página dedicada do Confluence usando um template de post-mortem de incidente e trabalhe em cada seção: cronograma, análise de causa raiz, avaliação de impacto e lições aprendidas. O template de resposta a incidentes incluído nesta página oferece uma estrutura completa que sua equipe pode copiar e preencher para cada novo incidente, para que você não precise decidir o que documentar do zero todas as vezes.

Manter post-mortems no Confluence oferece vários benefícios práticos:

• Visibilidade para toda a equipe: qualquer pessoa, da engenharia à liderança, pode rever o que aconteceu sem precisar correr atrás da pessoa de plantão para um resumo verbal.

• Identificação de padrões: quando cada incidente é documentado no mesmo formato, fica muito mais fácil identificar falhas recorrentes e fraquezas sistêmicas ao longo dos trimestres.

• Documentação sem culpabilização: um template estruturado de resposta a incidentes mantém a conversa focada em sistemas e processos em vez de apontar culpados, o que leva a relatórios mais honestos e úteis.

• Integração mais rápida para novos funcionários: novos membros da equipe podem ler post-mortems anteriores para entender como seus sistemas se comportam sob pressão e o que a equipe já aprendeu com incidentes anteriores.

Para um guia mais minucioso sobre como conduzir revisões de post-mortem produtivas, leia o manual de post-mortem de incidentes.

Monitore os acompanhamentos como tickets do Jira

Um post-mortem só é útil na medida das ações que ele gera. Toda ação corretiva e item recorrente identificado durante a revisão deve ser convertido em um ticket do Jira com um proprietário e um prazo claros. 

Esta é a etapa que separa as equipes que melhoram de verdade daquelas que continuam enfrentando os mesmos problemas. Quando as ações corretivas existem como itens de ticket rastreáveis no Jira, os gerentes podem monitorar o progresso, e as equipes podem responsabilizar umas às outras por concluir as melhorias que concordaram em fazer. Também ajuda com a priorização. Quando tickets orientados por incidentes ficam junto com o resto do seu backlog, fica mais fácil os avaliar em relação a outras prioridades, em vez de os deixar cair para o final da lista sem ninguém perceber.

As ferramentas de gerenciamento de incidentes certas conectam todo esse fluxo de trabalho de ponta a ponta. Quando seus sistemas de resposta, documentação e acompanhamento estão integrados, a lacuna entre detectar um problema e impedir que ele se repita fica muito menor.

Template de resposta a incidentes

Abaixo está um template de plano de resposta a incidentes que sua equipe pode copiar e adaptar para cada novo incidente. Ele percorre todas as fases de um post-mortem, desde o resumo inicial e o cronograma até a análise da causa raiz, lições aprendidas e ações corretivas. Usar uma estrutura consistente para cada incidente garante que nada seja esquecido e que seus post-mortems sejam fáceis de comparar ao longo do tempo.

Os exemplos no template são um ponto de partida, não um roteiro rígido. Ajuste o idioma e o nível de informações para corresponder ao modo como sua organização opera. A meta é documentar contexto suficiente para que qualquer pessoa que ler o post-mortem meses depois possa entender com exatidão o que aconteceu e o que a equipe fez a respeito.

Resumo do incidente

Escreva um resumo do incidente em algumas frases. Inclua o que aconteceu, o motivo, a gravidade do incidente e quanto tempo o impacto durou.

Exemplo:

Entre a hora de {time range of incident, e.g. 15:45 and 16:35} em {DATE}, {NUMBER} usuários encontraram {EVENT SYMPTOMS}. 

O evento foi acionado por {CHANGE} às {TIME OF CHANGE THAT CAUSED THE EVENT}. 

{CHANGE} continha {DESCRIPTION OF OR REASON FOR THE CHANGE, such as a change in code to update a system}. 

Um erro nesse código causou {DESCRIPTION OF THE PROBLEM}. 

O evento foi detectado por {MONITORING SYSTEM}. A equipe começou a trabalhar no evento com base em {RESOLUTION ACTIONS TAKEN}.

Esse incidente {SEVERITY LEVEL}  afetou {X%} dos usuários.

Houve um impacto adicional, conforme observado por {e.g. NUMBER OF SUPPORT TICKETS SUBMITTED, SOCIAL MEDIA MENTIONS, CALLS TO ACCOUNT MANAGERS} , em relação a esse incidente. 

Precedentes

Descreva a sequência de eventos que levaram ao incidente, por exemplo: mudanças anteriores que introduziram erros que ainda não tinham sido detectados.

Exemplo:

Às {16:00}, em {MM/DD/YY}, ({AMOUNT OF TIME BEFORE CUSTOMER IMPACT, e.g. 10 days before the incident in question}), uma alteração foi introduzida em {PRODUCT OR SERVICE} a fim de {THE CHANGES THAT LED TO THE INCIDENT}. 

Essa alteração resultou em {DESCRIPTION OF THE IMPACT OF THE CHANGE}.

Falha

Descreva como a mudança que foi implementada não funcionou conforme o esperado. Se disponível, anexe capturas de tela de visualizações de dados relevantes que ilustram a falha.

Exemplo:

{NUMBER} respostas foram enviadas com erro para {XX%} das solicitações. Isso continuou por {TIME PERIOD}.

Impacto

Descreva como o incidente impactou os usuários internos e externos durante o incidente. Inclua quantos casos de suporte foram levantados.

Exemplo:

Por {XXhrs XX minutes}, entre {XX:XX UTC and XX:XX UTC} em {MM/DD/YY}, nossos usuários enfrentaram este incidente: {SUMMARY OF INCIDENT}.

Esse incidente afetou {XX} clientes (X% DOS USUÁRIOS DE {SYSTEM OR SERVICE}), que experimentaram {DESCRIPTION OF SYMPTOMS}.

{XX NUMBER OF SUPPORT TICKETS AND XX NUMBER OF SOCIAL MEDIA POSTS} foram enviados.

Detecção

Quando a equipe detectou o incidente? Como eles sabiam que ele estava acontecendo? Como podemos melhorar o tempo de detecção? Pense no seguinte: como poderíamos ter reduzido esse tempo pela metade?

Exemplo:

O incidente foi detectado quando {ALERT TYPE} foi acionado e {TEAM/PERSON} foi notificado. 

Em seguida, {SECONDARY PERSON} foi notificado, porque {FIRST PERSON}  não era responsável pelo serviço que gravava no disco, atrasando a resposta em {XX MINUTES/HOURS}.

{DESCRIBE THE IMPROVEMENT} será configurado por {TEAM OWNER OF THE IMPROVEMENT} para que {EXPECTED IMPROVEMENT}.

Resposta

Quem respondeu ao incidente? Quando foi a resposta e o que a pessoa fez? Mencione quaisquer atrasos ou obstáculos para responder.

Exemplo:

Depois de receber uma página às {XX:XX UTC}, {ON-CALL ENGINEER} ficou online às {XX:XX UTC}  em {SYSTEM WHERE INCIDENT INFO IS CAPTURED}. 

Esse engenheiro não tinha experiência na área de {AFFECTED SYSTEM}, portanto um segundo alerta foi enviado às {XX:XX UTC} para {ESCALATIONS ON-CALL ENGINEER}, que entrou na sala às {XX:XX UTC}.

Recuperação

Descreva como o serviço foi restaurado e o incidente foi considerado encerrado. Fale mais sobre como o serviço foi restaurado com sucesso e como você sabia que etapas precisavam executar para a recuperação. 

Dependendo do cenário, considere estas perguntas: como otimizar o tempo para mitigação? Como cortar esse tempo pela metade?

Exemplo:

Usamos uma abordagem de três pontas para a recuperação do sistema: 

{DESCRIBE THE ACTION THAT MITIGATED THE ISSUE, WHY IT WAS TAKEN, AND THE OUTCOME} 

Exemplo: aumentando o tamanho do ASG do BuildEng EC3 para aumentar o número de nós disponíveis para suportar a carga de trabalho e reduzir a probabilidade de agendamento em nós com excesso de assinatura

• Desativação do escalonador automático Escalator para evitar que o cluster escalonasse para baixo de forma agressiva

• Reversão do agendador Build Engineering para a versão anterior.

Cronograma

Fale mais sobre o cronograma do incidente. Recomendamos usar UTC para padronizar os fusos horários.

Inclua todos os eventos de preparação relevantes, inícios de atividade, o primeiro impacto conhecido e escalonamentos. Anote todas as decisões ou mudanças feitas e, ao finalizar o incidente, todos os eventos pós-impacto dignos de nota. 

Exemplo:

Todos os horários estão em UTC.

11:48 - O upgrade do K8S 1.9 do plano de controle foi concluído. 

12:46 - Upgrade para V1.9 concluído, incluindo escalonador automático do cluster e a instância BuildEng Scheduler. 

14:20 — O Build Engineering relata um problema ao KITT afetado

14:27 - O KITT afetado começa a investigar as falhas de uma instância específica do EC2 (ip-203-153-8-204). 

14:42: O KITT afetado isola o ponto central. 

14:49: O BuildEng relata o problema como afetando mais do que apenas um ponto central. 86 instâncias do problema mostram que as falhas são mais sistêmicas. 

15:00: O KITT afetado sugere alternar para o agendador padrão. 

15:34: O BuildEng relata que 200 pods falharam. 

16:00 - O BuildEng elimina todos os builds com falha com relatórios OutOfCpu. 

16:13: O BuildEng relata que as falhas continuam ocorrendo em novos builds e não são apenas temporárias. 

16:30 - O KITT reconhece as falhas como um incidente e as executa como um incidente. 

16:36 - O KITT desativa o escalonador automático Escalator para evitar que ele remova computações para aliviar o problema.

16:40 - O KITT confirma que o ASG está estável, que a carga de cluster está normal e que o impacto ao cliente foi resolvido.

TEMPLATE:

XX:XX UTC - ATIVIDADE DO INCIDENTE; AÇÃO REALIZADA

XX:XX UTC - ATIVIDADE DO INCIDENTE; AÇÃO REALIZADA

XX:XX UTC - ATIVIDADE DO INCIDENTE; AÇÃO REALIZADA

Identificação da causa-raiz: os cinco porquês

Os cinco porquês são uma técnica de identificação da causa raiz. Veja a seguir como usar:

• Comece com a descrição do impacto e pergunte por que ele ocorreu. 

• Observe o impacto causado.  

• Pergunte por que ele aconteceu e por que resultou nesse impacto. 

• Depois continue perguntando "por que" até chegar à causa raiz.

Liste os "porquês" na documentação de análise retrospectiva.

Exemplo:

1. O aplicativo teve uma interrupção porque o banco de dados estava bloqueado

2. O banco de dados estava bloqueado porque houve excesso de gravações nele

3. Porque enviamos uma mudança para o serviço e não esperávamos as gravações elevadas

4. Porque não temos um processo de desenvolvimento estabelecido para alterações de teste de carga

5. Porque nunca pensamos que o teste de carga era necessário até atingirmos este nível de dimensão.

Causa-raiz

Observe a causa-raiz final do incidente, a coisa identificada que precisa mudar para evitar que essa classe de incidente aconteça de novo.

Exemplo:

Um bug em

Verificação do backlog

Revise o backlog de engenharia para descobrir se houve algum trabalho não planejado que poderia ter evitado esse incidente ou pelo menos reduzido o impacto. 

Uma avaliação clara do backlog pode lançar luz sobre decisões anteriores relacionadas a prioridade e risco.

Exemplo:

Nenhum item específico no backlog que poderia ter melhorado este serviço. Há uma observação sobre melhorias na digitação de fluxo e essas eram tarefas em andamento com fluxos de trabalho implementados.  

Tickets foram feitos para melhorar os testes de integração, mas até agora eles não foram bem-sucedidos.

Recorrência

Agora que você conhece a causa-raiz, consegue olhar para trás e ver outros incidentes que poderiam ter essa mesma causa? Se sim, observe qual resolução foi tentada nesses incidentes e pergunte-se por que o incidente ocorreu de novo.

Exemplo:

Esta mesma causa-raiz resultou em incidentes HOT-13432, HOT-14932 e HOT-19452.

Lições aprendidas

Discuta o que deu certo na resposta a incidentes, o que poderia ter sido melhorado e onde existem oportunidades de melhoria.

Exemplo:

• Precisa de um teste da unidade para verificar se o limitador de taxa para o trabalho foi mantido da forma correta

• As cargas de trabalho de operação em massa, que são anormais na operação comum, devem ser revisadas

• As operações em massa devem começar devagar e serem monitoradas, aumentando quando as métricas de serviço parecerem nominais

Ações corretivas

Descreva a ação corretiva ordenada para evitar esta classe de incidente no futuro. Observe quem é o responsável, quando ele(a) tem que concluir o trabalho e onde esse trabalho está sendo rastreado.

Exemplo:

1. Limite de taxa de escalonamento automático manual colocado em vigor temporariamente para limitar falhas

2. Teste de unidade e reintrodução da limitação da taxa de trabalho

3. Introdução de um mecanismo secundário para coletar informações sobre a taxa distribuída no cluster para guiar os efeitos do escalonamento