Autópsia dos incidentes

O que é análise retrospectiva?

Uma autópsia é um registro por escrito de um incidente que descreve:

• O impacto do incidente.
• As ações tomadas para mitigar ou resolver o incidente.
• A causa-raiz do incidente.
• As ações de acompanhamento tomadas para evitar que o incidente ocorra novamente.

Na Atlassian, rastreamos todas as autópsias com itens Jira para garantir que elas sejam concluídas e aprovadas. Você pode decidir usar um sistema mais simples, como uma página do Confluence para cada autópsia, se suas necessidades forem mais simples.

Por que realizamos autópsias?

Os objetivos de uma autópsia são entender todas as causas-raiz contribuintes, documentar o incidente para referência futura e descoberta de padrões e direcionar ações preventivas efetivas para reduzir a probabilidade ou o impacto da recorrência.

Para que as análises retrospectivas sejam efetivas na redução da repetição de incidentes, o processo de revisão precisa incentivar as equipes a identificar as causas-raiz e corrigi-las. O método exato depende da cultura da equipe; na Atlassian, a gente encontrou uma combinação de métodos que funcionam para as equipes de resposta a incidentes:

• Reuniões presenciais ajudam a orientar análises adequadas e alinhar a equipe sobre o que precisa ser corrigido.
• Aprovações da autópsia pelos gestores da equipe de fornecimento e operações incentivam as equipes a concluir as autópsias.
• "Ações prioritárias" designadas têm um Objetivo de nível de serviço (SLO) acordado que é de 4 ou 8 semanas, dependendo do serviço, com lembretes e relatórios para garantir que elas sejam concluídas.

A participação neste processo e a garantia de sua efetividade requer o comprometimento da organização em todos os níveis. Nossos diretores e gestores de engenharia decidiram os aprovadores e SLOs para a resolução de ações em suas áreas. Este sistema apenas codifica e tente impor as suas decisões.

Quando é necessária uma autópsia?

Realizamos autópsias para incidentes de gravidade 1 e 2. Caso contrário, elas são opcionais.

Durante ou logo após a resolução do item, o proprietário da autópsia cria um novo item de autópsia.

Quem conclui a autópsia?

A equipe de fornecimento de serviço que falhou (a equipe proprietária do "Serviço com falha" no item do incidente) é responsável pela conclusão da autópsia. A equipe seleciona o proprietário da autópsia e designa a ele o item da autópsia.

• O proprietário da análise retrospectiva guia a análise durante a criação, aprovação e até que ela seja publicada. Elas são responsáveis pela conclusão da análise retrospectiva.
• Um ou mais aprovadores da autópsia a revisam e aprovam e devem priorizar as ações de acompanhamento em seus backlogs.

Temos uma página do Confluence, que lista os aprovadores da autópsia (obrigatórios e opcionais) por grupo de serviço, que geralmente corresponde a um produto da Atlassian (p. ex., Bitbucket Cloud).

Como são rastreadas as ações da autópsia?

Para cada ação que se origina na autópsia, nós:

• Criamos um item Jira no backlog da equipe que é proprietária dela. Todas as ações da autópsia devem ser rastreadas no Jira.
• Vinculamos as ações do item da autópsia como "Ação prioritária" (para correções de causa-raiz) ou "Ação de melhoria" (para melhorias sem ser de causa-raiz .

Criamos alguns relatórios personalizados usando as APIs REST do Jira para rastrear quantos incidentes de cada gravidade não tiveram suas causas-raiz corrigidas pelas ações prioritárias na autópsia. Os gestores de engenharia de cada departamento revisam esta lista regularmente.

Processo de autópsia

A execução do processo de autópsia inclui a criação de um item de autópsia, a realização de uma reunião sobre a autópsia, a captura de ações, a aprovação e (opcionalmente) a comunicação do resultado.

O proprietário da autópsia é responsável por executar as seguintes tarefas:

1. Criar uma autópsia e vinculá-la ao incidente.
2. Editar o item da autópsia, ler as descrições dos campos e preencher os campos.
3. Para determinar a causa-raiz do incidente, use a técnica dos "Cinco porquês" para analisar a cadeia causal até encontrar uma boa causa-raiz verdadeira.
4. Agendar uma reunião da autópsia. Convidar a equipe de fornecimento, as equipes afetadas e as partes interessadas, usando o modelo de convite.
5. Reunir-se com a equipe e seguir o cronograma da reunião abaixo.
6. Acompanhar os gerentes de desenvolvimento responsáveis para obter o comprometimento com ações específicas que evitarão esta classe de incidentes.
7. Criar um item Jira para cada ação nos backlogs da equipe proprietária. Vincular as ações do item da autópsia como "Ação prioritária" (para correções de causa raiz) ou "Ação de melhoria" (para melhorias sem ser de causa raiz).
8. Busque os aprovadores adequados no Confluence e adicione-os ao campo "Aprovadores" da análise retrospectiva.
9. Selecione a transição "Solicitar aprovação" para solicitar a aprovação dos aprovadores designados. A automação vai comentar sobre o item com instruções para os aprovadores.
10. Fazer o acompanhamento, conforme a necessidade, até que a autópsia seja aprovada.
11. Quando a autópsia for aprovada, teremos automação para criar um blog de rascunho da autópsia no Confluence para você editar e publicar. Postar suas autópsias no blog compartilha suas lições aprendidas com trabalho duro, o que multiplica o valor delas.

Depois que o processo de autópsia for realizado, as ações serão priorizadas pela equipe de desenvolvimento como parte de seu backlog normal, de acordo com o SLO da equipe.

Reuniões da autópsia

Descobrimos que reunir a equipe para discutir os aprendizados em conjunto resulta em uma análise mais detalhada nas causas-raiz. Geralmente, isto é feito por videoconferência devido à distribuição das nossas equipes e, às vezes, em grupos, quando os incidentes envolvem grupos grandes de pessoas.

Nossa pauta sugerida:

1. Lembrar a equipe que as autópsias são sem culpa e o porquê
2. Confirmar o cronograma dos eventos
3. Confirmar as causas-raiz
4. Gerar ações usando um "pensamento aberto" - "O que poderíamos fazer para evitar esta classe de incidentes no futuro?"
5. Perguntar à equipe "O que deu certo/O que poderia ter sido melhor/Onde tivemos sorte"

Template de reserva de calendário sugerido:

Participe comigo de uma autópsia sem culpa do , onde nós .

Os objetivos de uma autópsia são entender todas as causas-raiz contribuintes, documentar o incidente para referência futura e descoberta de padrões e direcionar ações preventivas efetivas para reduzir a probabilidade ou o impacto da recorrência.

Nesta reunião, a gente vai tentar determinar as causas-raiz e decidir ações para mitigá-las.

Se você não reunir os gestores de desenvolvimento responsáveis, evite comprometer-se com ações específicas na reunião, porque este é um contexto pobre para decisões de priorização. As pessoas se sentirão pressionadas a se comprometer e não terão as informações completas. Em vez disso, faça o acompanhamento dos gestores responsáveis após a reunião para obter o compromisso de corrigir as ações prioritárias identificadas.

Campos de problemas da autópsia

Nosso item da autópsia possui uma série de campos extensos para incentivar a coleta de todos os detalhes importantes sobre o incidente antes da realização da reunião da autópsia. Abaixo estão alguns exemplos de como preenchemos estes campos.

Causas-raiz e imediatas

Quando você estiver escrevendo ou lendo uma autópsia, é necessário distinguir entre as causas-raiz e causas imediatas.

• As causas imediatas são motivos que levaram diretamente a este incidente.
• As causas-raiz são motivos no local ideal da cadeia de eventos, onde realizar uma mudança evitará esta classe inteira de incidentes.

Uma análise retrospectiva busca descobrir as causas-raiz e decidir a melhor forma de mitigá-las. Encontrar aquele local ideal na cadeia de eventos é a verdadeira arte da uma análise retrospectiva. Use uma técnica como Os cinco porquês para "subir a cadeia" e encontrar as causas raiz.

Aqui estão alguns exemplos selecionados de causas-raiz e imediatas:

Categorias das causas-raiz e suas ações

A gente usa essas categorias para agrupar as causas raízes e discutir as ações apropriadas para cada uma.

Causas-raiz com dependências

Quando o seu serviço tem um incidente porque uma dependência falha, onde a falha reside e no quê a causa-raiz depende, se a dependência é interna à Atlassian ou a um terceiro e qual é a expectativa razoável do desempenho da dependência.

Se for um dependência interna, pergunte "qual é o Objetivo do nível de serviço (SLO) da dependência?":

• A dependência violou seu SLO?
  • A falha reside na dependência e ela precisa aumentar sua confiabilidade.
• A dependência permaneceu no SLO, mas o serviço falhou mesmo assim?
  • Seu serviço precisa aumentar sua resiliência.
• A dependência não tem um SLO?
  • Ela precisa de um!

Se for a dependência de um terceiro, pergunte "qual é nossa expectativa razoável* sobre a disponibilidade/latência/etc. da dependência do terceiro?"

• A dependência terceirizada excedeu nossa expectativa (em um dia ruim)?
  • A expectativa estava incorreta.
    • Nós estamos confiantes de que não acontecerá novamente? P. ex., nós revisamos e concordamos com o RCA deles. Neste caso, a ação é o RCA deles.
    • Ou precisamos ajustar nossas expectativas? Neste caso, as ações são aumentar nossa resiliência e ajustar nossas expectativas.
    • Nossas expectativas ajustadas são inaceitáveis? Neste caso, nós precisamos resolver a desconexão entre os requisitos e a solução de alguma forma, ex. encontrar outro fornecedor.
• A dependência terceirizada permaneceu dentro das expectativas, mas o serviço falhou mesmo assim?
  • Neste caso, seu serviço precisa aumentar sua resiliência.
• Nós não temos de fato uma expectativa?
  • O proprietário da dependência terceirizada precisa estabelecer isto e compartilhar com as equipes para que elas saibam qual nível de resiliência precisam construir em seus serviços dependentes.

*Por que "expectativa"? A gente não tem SLAs com terceiros? Na verdade, os SLAs contratuais com terceiros são muito baixos para serem úteis na determinação e mitigação de falhas. Por exemplo, o AWS quase não publica SLA para o EC2. Portanto, ao depender de um serviço terceirizado, a gente tem que tomar uma decisão sobre qual nível de confiabilidade, disponibilidade, desempenho ou outra métrica chave a gente deve esperar que eles forneçam.

Ações da autópsia

Sue Lueder e Betsy Beyer do Google possuem uma apresentação e um artigo excelentes sobre itens de ação da autópsia, que nós usamos na Atlassian para avisar a equipe.

Trabalhe as questões abaixo para ajudar a garantir que o PIR cubra as correções de curto e longo prazo:

"Mitigar incidentes futuros" e "Evitar incidentes futuros" são suas fontes de ação mais prováveis que abordam a causa-raiz. Certifique-se de obter pelo menos um deles.

Aprovações da autópsia

A Atlassian usa um fluxo de trabalho Jira com uma etapa de aprovação para garantir que as autópsias sejam aprovadas. Os aprovadores geralmente atendem os proprietários ou outros gestores responsáveis pela operação de um serviço. A aprovação de uma autópsia indica:

• Concordância com as descobertas da revisão pós-incidente, incluindo qual era a causa-raiz; e
• Concordância de que as "Ações prioritárias" relacionadas são uma forma aceitável de abordar a causa-raiz.

Nossos aprovadores geralmente solicitarão ações adicionais ou identificarão uma determinada cadeia causal que não esteja sendo abordada pelas ações propostas. Desta forma, nós vemos as aprovações adicionando muito valor ao nosso processo de autópsia na Atlassian.

Em equipes com menos incidentes ou uma infraestrutura menos complexa, as aprovações da autópsia talvez não sejam necessárias.

Autópsias sem culpa

Quando as coisas dão errado, é uma tendência natural do ser humano buscar um culpado. Porém, é interesse da Atlassian evitar que isto aconteça, então quando estiver executando uma autópsia, você precisa superar isso conscientemente. Nós supomos boas intenções da nossa equipe e nunca culpados pessoas pelas falhas. As necessidades da autópsia precisam examinar de forma honesta e objetiva as circunstâncias que levaram à falha, para que possamos encontrar a(s) causa(s) raiz verdadeira(s) e mitigá-la(s). Culpar pessoas coloca isto em risco, porque:

• Quando as pessoas sentem o risco de olhar nos olhos dos colegas ou arriscar suas perspectivas de carreira, isto geralmente supera "o melhor interesse do meu empregador" em sua hierarquia pessoal; então, eles naturalmente dissimulam ou escondem a verdade para proteger suas necessidades básicas.
• Mesmo se uma pessoa realizou uma ação que levou diretamente a um incidente, o que devemos perguntar não é "por que fulano fez isto?", mas "por que o sistema permitiu que alguém fizesse isso ou levou alguém a acreditar que isso era a coisa certa a se fazer?".
• Culpar as pessoas é destrutivo e, se ocorrer com frequência, vai criar uma cultura de medo e desconfiança.

Em nossas autópsias, usamos estas técnicas para criar segurança pessoal para todos os participantes:

• Abrir a reunião da análise retrospectiva declarando que esta é uma análise sem culpa e o porquê
• Referir-se às pessoas por função (p. ex., "o engenheiro de Widgets de plantão) em vez de pelo nome (mantendo-se claro e inequívoco sobre os fatos)
• Garantir que a linha do tempo, a cadeia causal e as mitigações da autópsia sejam enquadradas no contexto dos sistemas, processos e cargos, não pessoas.

Nossa inspiração para as autópsias sem culpa e o conceito útil de "segundas histórias" se originaram no artigo seminal de John Allspaw.