Close

O caminho para um gerenciamento de incidentes melhor começa aqui

Buscar tópicos

Template de análise retrospectiva de incidentes

Uma documentação clara é a chave para um processo de análise retrospectiva de incidente eficaz. Muitas equipes usam um template abrangente para coletar dados consistentes durante cada revisão de análise retrospectiva.


Abaixo está um exemplo de um template de análise retrospectiva de incidente, com base na análise retrospectiva descrita no Manual de incidentes. Você pode recortar e colar para documentar as próprias análises retrospectivas.

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 {intervalo de tempo do incidente, por exemplo, 15:45 e 16:35} em {DATA}, {NÚMERO} usuários passaram por {SINTOMAS DO EVENTO}.

O evento foi acionado por {ALTERAÇÃO} às {HORA DA ALTERAÇÃO QUE CAUSOU O EVENTO}.

A {ALTERAÇÃO} continha {DESCRIÇÃO OU MOTIVO DA ALTERAÇÃO, como uma alteração no código para atualizar um sistema}.

Um bug neste código causou {DESCRIÇÃO DO PROBLEMA}.

O evento foi detectado pelo {SISTEMA DE MONITORAMENTO}. A equipe começou a corrigir o evento por meio de {AÇÕES DE RESOLUÇÃO TOMADAS}.

Este incidente {NÍVEL DE GRAVIDADE} afetou {X%} dos usuários.

Houve um impacto adicional, conforme observado por {por exemplo, NÚMERO DE TICKETS DE SUPORTE ENVIADOS, MENÇÕES NAS REDES SOCIAIS, LIGAÇÕES PARA GERENTES DE CONTA} em relação a este 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 {DD/MM/AA}, ({TEMPO ANTES DO IMPACTO NOS CLIENTES, por exemplo, 10 dias antes do incidente em questão}), uma alteração foi introduzida em {PRODUTO OU SERVIÇO} a fim de {AS ALTERAÇÕES QUE LEVARAM AO INCIDENTE}.

Essa alteração resultou em {DESCRIÇÃO DO IMPACTO DA ALTERAÇÃO}.

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:

{NÚMERO} respostas foram enviadas com erro para {XX%} das solicitações durante {PERÍODO}.

Impacto

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

Exemplo:

Por {XX horas e XX minutos} entre {XX:XX UTC e XX:XX UTC} em {DD/MM/AA}, {RESUMO DO INCIDENTE} os usuários passaram por este incidente.

Este incidente afetou {XX} clientes (X% DOS USUÁRIOS DO {SISTEMA OU SERVIÇO}), que enfrentaram {DESCRIÇÃO DOS SINTOMAS}.

{XX NÚMERO DE TICKETS DE SUPORTE E XX NÚMERO DE PUBLICAÇÕES EM REDES SOCIAIS} 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:

Este incidente foi detectado quando o {TIPO DE ALERTA} foi acionado e a {EQUIPE/PESSOA} foi avisada.

Em seguida, {PESSOA SECUNDÁRIA} foi avisada, porque {PRIMEIRA PESSOA} não tinha propriedade do serviço em gravação no disco, atrasando a resposta em {XX MINUTOS/HORAS}.

{DESCREVA A MELHORIA} vai ser configurada por {PROPRIETÁRIO DA EQUIPE DA MELHORIA} para que {MELHORIA ESPERADA}.

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 mensagem em {XX:XX UTC}, {ENGENHEIRO DE PLANTÃO} ficou on-line em {XX:XX UTC} em {SISTEMA ONDE AS INFORMAÇÕES DO INCIDENTE SÃO CAPTURADAS}.

Este engenheiro não tinha experiência no {SISTEMA AFETADO}, então um segundo alerta foi enviado às {XX:XX UTC} para {ENGENHEIRO DE ESCALONAMENTO DE PLANTÃO} 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:

{DESCREVA A AÇÃO QUE MITIGOU O PROBLEMA, POR QUE ELA FOI REALIZADA E O RESULTADO}

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.

Linha do tempo

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 no tratamento do pool de conexão levou a conexões perdidas em condições de falha, juntamente com a falta de visibilidade do estado da conexão.

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