Fechar
Manual de incidentes da Atlassian

Autópsia dos incidentes

Autópsia dos incidentes

Praticamos autópsias sem culpa na Atlassian para garantir que entendemos e remediamos a causa-raiz de cada incidente com um nível de gravidade de 2 ou mais. Aqui está uma versão resumida da nossa documentação interna que descreve como nós executamos as autópsias na Atlassian.

Visão geral

Definindo incidentes e os valores relacionados a incidentes. Conheça as ferramentas corretas e as funções da equipe.

Respondendo a um incidente

O processo de resposta e as etapas a serem seguidas assim que for detectado um incidente.

O que é uma autópsia?

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 autópsias 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 sua equipe; na Atlassian, nós encontramos uma combinação de métodos que funcionam para as nossas 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 autópsia guia a autópsia durante a criação, aprovação e até que ela seja publicada Elas são responsáveis pela conclusão da autópsia. 

  • 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, deve usar 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. Buscar os aprovadores adequados no Confluence e adicioná-los ao campo "Aprovadores" da autópsia. 

  9. Selecionar a transição "Solicitar aprovação" para solicitar a aprovação dos aprovadores designados. A automação 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"

Modelo de reserva de calendário sugerido:

Participe comigo de uma autópsia sem culpa do <link do incidente>, onde nós <resumo do incidente>.

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, procuraremos 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.

Campo

Instruções

Example

Resumo do incidente

Resuma o incidente em algumas frases. Inclua a gravidade, o porquê e por quanto tempo durou.

Entre <intervalo de tempo do incidente, ex. 14:30 e 15:00> no dia <data><número> clientes passaram pelos <sintomas do evento>. O evento foi desencadeado por uma implementação às <hora da implementação ou mudança que causou o incidente>. A implementação continha uma mudança de código para <descrição ou motivo da mudança>. O bug nesta implementação causou <descrição do problema>

O evento foi detectado pelo <sistema>. Nós mitigamos o evento ao <ações de resolução tomadas>.

Este incidente <nível de gravidade> afetou X% dos clientes.

<Número de chamados de suporte e/ou posts em mídias sociais> foram criados sobre este incidente. 

Precedentes

Descreva as circunstâncias que levaram a este incidente, por exemplo, mudanças anteriores que introduziram bugs latentes.

Às <hora> no dia <data>, (<quantidade de tempo antes do impacto ao cliente>), foi introduzida uma mudança ao <produto ou serviço> para... <descrição das mudanças que levaram ao incidente>. A mudança causou... <descrição do impacto das mudanças>

Falha

Descreva o que não funcionou como esperado. Anexe capturas de tela de gráficos relevantes ou dados mostrando a falha.

<Número> respostas foram enviadas incorretamente a X% das solicitações durante o período de <período de tempo>.

Impact

Descreva o que os clientes internos e externos viram durante o incidente. Inclua quantos casos de suporte foram criados.

Durante <número de horas> entre <intervalo de tempo> no dia <data>, os clientes passaram por <resumo do incidente>.

Isto afetou <número> clientes (X% de todos os clientes do <sistema ou serviço> ), que encontraram <descrição dos sintomas que os clientes experimentaram>.

<Número de chamados de suporte e posts em mídias sociais> foram criados.

Detection

Como e quando a Atlassian detectou o incidente?

Como o tempo de detecção poderia ser melhorado? Como exercício mental, como você reduziria o tempo pela metade?

O incidente foi detectado quando o <tipo de alerta> foi acionado e <equipe ou pessoa chamada> foi chamado. Então, eles tiveram que chamar <pessoa ou equipe de resposta secundária> , porque eles não eram proprietários da gravação do serviço no disco, atrasando a resposta em <número de horas>.

<Descrição da melhoria> será definida pela <equipe proprietária da melhoria> para que <impacto da melhoria>

Response

Quem respondeu, quando e como? Houve algum atraso ou barreira à nossa resposta?

Depois de ser chamado às 14:34 UTC, o engenheiro de KITT ficou online às 14:38 na sala de chat do incidente. Porém, o engenheiro de plantão não tinha experiência suficiente no escalonador automático Escalator, então mais um alerta foi enviado às 14:50 e trouxe o engenheiro sênior de KITT na sala às 14:58.

Recovery

Descreva como e quando o serviço foi restaurado. Como você chegou ao ponto onde sabia como mitigar o impacto?

Perguntas adicionais para fazer, dependendo do cenário: Como o tempo da mitigação poderia ser melhorado? Como exercício mental, como você reduziria o tempo pela metade?

A recuperação foi uma resposta tripla:

  • Aumentar o tamanho do BuildEng EC2 ASG para aumentar o número de nós disponíveis para atender a carga de trabalho e reduzir a probabilidade de agendamento em nós com excesso de inscrições

  • 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

Forneça uma linha do tempo detalhada sobre o incidente, em ordem cronológica, com data, hora e fusos horários. 

Inclua quaisquer precedentes; o início do impacto; o tempo de detecção; os escalonamentos, as decisões e mudanças e o final do impacto.

Todos os horários estão em UTC.

11:48 - Atualização do K8S 1.9 do plano de controle finalizada 
12:46 - Atualização do Goliath para V1.9 concluída, incluindo o escalonador automático de cluster e a instância do agendador BuildEng 
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 nó específico 
14:49 - O BuildEng relata o problema como afetando mais do que apenas um nó. 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 300 módulos falharam 
16:00 - O BuildEng elimina todos os builds com falha com relatórios OutOfCpu 
16:13 - O BuildEng relata que as falhas são recorrentes de forma consistente com novos builds e não são apenas temporárias. 
16:30 - O KITT reconhece as falhas como um incidente e as executa com 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.

Os cinco porquês

Use a técnica de identificação da causa-raiz.

Comece com o impacto e pergunte por que isso aconteceu e por que teve o impacto que teve. Continue perguntando por que até chegar à causa-raiz.

Documente seus "porquês" em forma de lista aqui ou em um diagrama anexo ao item.

  1. O serviço ficou inativo porque o banco de dados foi bloqueado

  2. Porque havia muitas gravações no banco de dados

  3. Porque foi feita uma mudança no serviço e o aumento não era esperado

  4. Porque nós não temos um processo de desenvolvimento estabelecido sobre quando devemos testar as mudanças em relação à carga

  5. Nós nunca realizamos teste de carga e eles estão atingindo novos níveis de escala

Causa-raiz

Qual era a causa-raiz? É isto que precisa mudar para impedir a recorrência desta classe de incidentes.

Um bug na manipulação do pool de conexões do <causa do bug ou serviço onde ele ocorreu> levou a conexões vazadas sob condição de falha, combinadas com uma falta de visibilidade no estado da conexão.

Verificação do backlog

Existe alguma coisa no seu backlog que poderia ter evitado ou reduzido muito o impacto do incidente? Caso afirmativo, por que não foi feito?

Uma avaliação honesta aqui ajuda a esclarecer as decisões passadas sobre prioridade e risco.

Não especificamente. As melhorias aos tipos de fluxo eram tarefas contínuas que tinham rituais estabelecidos (ex. adicionar tipos de fluxo ao modificar/criar um arquivo). Os chamados para corrigir os testes de integração foram realizados, mas não foram bem-sucedidos quando tentados

Recorrência

Este incidente (com a mesma causa-raiz) já ocorreu antes? Caso afirmativo, por que ele ocorreu de novo?

Esta mesma causa-raiz resultou em incidentes HOT-13432, HOT-14932 e HOT-19452.

Lições aprendidas

O que aprendemos?

Discuta o que deu certo, o que poderia ter sido melhor e onde tivemos sorte de encontrar oportunidades de melhoria.

  1. Precisa de um teste da unidade para verificar se o limitador de taxa para o trabalho foi mantido da forma correta

  2. As cargas de trabalho de operação em massa, que são anormais na operação comum, devem ser revisadas

  3. 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

O que nós faremos para garantir que esta classe de incidentes não ocorra mais? Quem tomará as ações e quando? 

Crie links do item "Ação prioritária" para itens que rastreiam cada ação. 

  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

  4. As migrações grandes precisam ser coordenadas, uma vez que o AWS ES não escalona automaticamente.

  5. A verificação da pesquisa Stride ainda é classificada como Nível 2

  6. Arquivar um chamado para pf-directory-service para falhar parcialmente em vez de falhar totalmente quando xpsearch-chat-searcher falhar.

  7. Alerta do Cloudwatch para identificar um problema de IO alto no cluster ElasticSearch

 

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 autópsia 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 autópsia. 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:

Cenário Causa imediata e ação Causa-raiz Mitigação da causa-raiz

Os serviços da equipe "Red Dawn" do Stride não tinham monitores Datadog e alertas de plantão para seus serviços ou não foram configurados corretamente. 

Os membros da equipe não configuraram o monitoramento e alerta para os novos serviços.

Configure-os para estes serviços.

Não existe um processo para propor novos serviços, o que inclui monitoramento e alertas.

Crie um processo para propor novos serviços e ensinar a equipe a segui-lo.

O Stride inutilizável no IE11 devido a uma atualização do Fabric Editor que não funciona nesta versão do navegador.

Atualização de uma dependência.

Reverta a atualização.

Falta de um teste de compatibilidade entre os navegadores.

Automatize o teste contínuo de compatibilidade entre os navegadores.

Os logs de micros da UE não estavam alcançando o serviço de criação de log.

A função fornecida aos micros para enviar logs estava incorreta.

Corrija a função.

Não temos como saber quando uma criação de log de um ambiente não está funcionando.

Adicione monitoramento e alertas nos logs ausentes para qualquer ambiente.

Acionado por um incidente anterior do AWS, os nós Vertigo do Confluence esgotaram seu pool de conexão com a mídia, levando a um anexação intermitente e erros de mídia para os clientes.

Falha no AWS.

Obtenha a autópsia do AWS.

Um bug na manipulação do pool de conexões do Confluence levou a conexões vazadas sob condição de falha, combinadas com uma falta de visibilidade no estado da conexão.

Corrija o bug e adicione um monitoramento que detectará situações futuras semelhantes antes que elas causem impacto.

 

Categorias das causas-raiz e suas ações

Usamos estas categorias para agrupar as causas-raiz e discutir as ações adequadas para cada uma delas.  

Categoria

Definition

O que você deve fazer sobre isto?

Bug

Uma mudança de código feita pela Atlassian (este é um tipo específico de mudança)

Teste. Canary. Execute implementações incrementais e as assista. Use sinalizadores de recurso. Converse com o seu engenheiro de qualidade.

Mudança

Uma mudança feita pela Atlassian (além do código)

Melhore a forma que você realiza as mudanças, por exemplo, suas revisões de mudança ou processos de gerenciamento de mudanças. Tudo que pareça com "bug" também se aplica.

Escale

Falha em escalonar (p. ex., cega a restrições de recurso ou falta de planejamento da capacidade)

Quais são as restrições de recurso do seu serviço? Eles são monitorados e alertados? Se você não tiver um plano de capacidade, crie um. Se você tiver um, quais novas restrições você precisa considerar?

Architecture

Desalinhamento do projeto com as condições operacionais

Revise o seu projeto. Você precisa mudar de plataforma?

Dependência

Falha no serviço de terceiros (sem ser da Atlassian)

Você está gerenciando o risco de falha de um terceiro? Nós fizemos decisões de negócios de aceitar um risco ou precisamos criar mitigações? Consulte "Causas-raiz com dependências" abaixo.

Desconhecido

Indeterminável (a ação é aumentar a capacidade de diagnóstico)

Melhore a observabilidade do seu sistema adicionando criação de logs, monitoramento, depuração e coisas similares.

 

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 seu 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)?

    • Nossa 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 nossas expectativas, mas seu 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"? Nós não temos 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, quando dependemos de um serviço terceirizado, nós temos que tomar uma decisão sobre qual nível de confiabilidade, disponibilidade, desempenho ou outra métrica chave nós devemos esperar razoavelmente 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.

Categoria Perguntas a fazer Examples

Investigar este incidente

"O que aconteceu para causar este incidente e por quê?" Determinar a causa-raiz é seu principal objetivo.

análise de logs, diagramação do caminho da solicitação, revisão de despejos da pilha

Mitigar este incidente

"Quais ações imediatas nós tomamos para resolver e gerenciar este evento específico?"

retrocedendo, escolhendo com cuidado, empurrando configurações, comunicando-se com os usuários afetados

Reparar o dano deste incidente

"Como nós resolvemos danos imediatos ou colaterais deste incidente?"

restaurando dados, corrigindo máquinas, removendo novas rotas de tráfego

Detectar futuros incidentes

"Como podemos reduzir o tempo para detectar de forma precisa uma falha semelhante?"

monitoramento, alertas, verificações plausíveis na entrada e saída

Mitigar futuros incidentes

"Como nós podemos reduzir a gravidade e/ou duração de futuros incidentes como este?"

"Como podemos reduzir a porcentagem de usuários afetados por esta classe de falhas da próxima vez que acontecer?"

degradação graciosa; eliminação de resultados não críticos; falha aberta; aumentando as práticas atuais com painéis ou guias; mudanças no processo do incidente

Evitar futuros incidentes

"Como podemos prevenir a recorrência deste tipo de falha?"

melhorias na estabilidade da base de código, testes unitários mais completos, validação das entradas e robustez a condições de erro, provisionamento de mudanças

Nós também usamos o conselho de Lueder e Beyer sobre como anunciar as ações das nossas autópsias.

Anunciando as ações da autópsia:

O vocabulário correto para a ação da autópsia pode fazer a diferença entre uma conclusão fácil e um atraso indefinido devido à falta de viabilidade ou procrastinação. Uma ação de autópsia bem trabalhada deve ter estas propriedades:

  • Acionável: formule cada ação como uma frase começando com um verbo. A ação deve gerar um resultado útil, não um processo. Por exemplo, "Enumerar a lista de dependências críticas" é uma boa ação, enquanto "Investigar dependências" não é.

  • Específica: defina o escopo de cada ação da forma mais restrita possível, esclarecendo o que está incluso no trabalho e o que não está.

  • Delimitada: formule cada ação para indicar como dizer quando terminar, em oposição a deixar a ação em aberto ou em andamento.

De... Para...

Investigar o monitoramento deste cenário.

(Acionável) Adicionar alerta para todos os casos em que este serviço retornar > 1% de erro.

Corrigir o problema que causou a falha.

(Específica) Lidar com segurança com o código postal inválido na entrada do formulário de endereço do usuário.

Certifique-se de que o engenheiro verifique se o esquema do banco de dados pode ser analisado antes da atualização.

(Delimitada) Adicionar uma verificação anterior ao envio para as mudanças no esquema.

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 repetidamente, 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 autópsia declarando que esta é uma autópsia 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.

Mantenha a calma e continue...

Você chegou ao final do nosso manual de incidentes. Obrigado pela leitura!

Se você tem algum comentário ou sugestão, envie um e-mail para nós em incident-handbook@atlassian.com.

Visão geral

Definindo incidentes e os valores relacionados a incidentes. Conheça as ferramentas corretas e as funções da equipe.

Respondendo a um incidente

O processo de resposta e as etapas a serem seguidas assim que for detectado um incidente.

Está procurando uma ferramenta para auxiliar na execução de um processo de gerenciamento de incidentes?