Template de análise retrospectiva de incidentes

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