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