Close

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

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 em , usuários passaram por .

O evento foi disparado por em .

A continha .

Um bug neste código causou .

O evento foi detectado pelo . A equipe começou a corrigir o evento por meio de .

Este incidente de gravidade afetou dos usuários.

Houve um impacto adicional, conforme observado por foram levantados 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

, (), uma mudança foi introduzida em a fim de .

Essa mudança resultou em .

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:

respostas foram enviadas com erro para das solicitações durante .

Impacto

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

Exemplo:

Por entre em

, os usuários passaram por este incidente.

Este incidente afetou clientes (X% DOS USUÁRIOS DE ), que enfrentaram .

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 foi acionado e foi(ram) avisado(s).

Em seguida, foi avisado(a), porque não tinha propriedade do serviço de gravação no disco, atrasando a resposta em .

vai ser configurada por para que .

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 , ficou on-line às no .

Esse engenheiro não tinha experiência no , então um segundo alerta foi enviado às para que entrou na sala às .

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:

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
a seguir
Blameless