A importância de um processo de análise retrospectiva de incidentes

Os benefícios de uma análise retrospectiva de incidente

Você pode ficar tentado a não fazer uma reunião de análise retrospectiva formal nem escrever um relatório sobre o incidente, ainda mais se tiver certeza do que causou o incidente e de que corrigiu o item.

Pode até ser verdade para você. Mas pode haver pessoas na equipe que não internalizaram o que aconteceu para causar o incidente e que poderiam se beneficiar da compreensão clara, melhorando o serviço para a equipe e para os clientes.

Reunir pessoas para se envolver em um processo estruturado e colaborativo permite que todos contribuam com o que aprenderam e pode construir confiança e resiliência na equipe. Além disso, documentar o incidente e como a equipe o corrigiu pode informar como futuros incidentes serão tratados.

Você também pode decidir publicar resultados da análise retrospectiva de incidente com clientes ou o resto da empresa, o que pode ajudar muito a ganhar de novo a confiança de pessoas que podem não ter estado muito envolvidas no momento do incidente. Outras equipes da empresa, em especial a liderança, podem precisar ver mais informações sobre o problema e quais etapas foram tomadas para resolvê-lo para evitar qualquer questionamento da equipe no futuro.

Parceiros, clientes e usuários finais também podem querer saber o que aconteceu e quais etapas você executou para melhorar a experiência deles. Disponibilizar a análise retrospectiva de incidente em seu site público pode não ser apropriado em todos os casos, mas sua equipe de marketing ou relações públicas pode ajudá-lo a elaborar a linguagem para que as pessoas obtenham as informações de uma forma que seja informativa e gere confiança em seus serviços.

Práticas recomendadas para uma análise retrospectiva de incidente

A maneira como você aborda a análise retrospectiva de incidente é tão importante quanto a checklist das etapas que você executa. As tensões podem aumentar após um incidente. A chave para fazer com que as pessoas cheguem ao processo engajadas e prontas para enfrentar um problema difícil é passar uma sensação de segurança psicológica.

Estabeleça uma cultura sem apontar culpados

O antigo CTO da Etsy, John Allspaw, escreveu um artigo seminal sobre “análises retrospectivas sem apontar culpados”. Essa abordagem para a investigação de um incidente permite que as pessoas envolvidas em um incidente prestem contas de todas as ações, o impacto e o que sabiam e quando, sem medo de punição ou retaliação.

Essa abordagem é a chave para garantir que as equipes compartilhem abertamente informações e cheguem à causa-raiz de um incidente. Alguém que teme ser repreendido pode ocultar informações ou tentar redirecionar a culpa. Quando essa situação acontece, as pessoas perdem a confiança umas nas outras e a empresa perde a oportunidade de criar resiliência nas equipes e nos sistemas. Muitas equipes, inclusive aqui na Atlassian e no Google, adotaram os benefícios da análise retrospectiva sem apontar culpados, a fim de evitar essas armadilhas.

Evite apontar o dedo e mantenha as críticas construtivas

Na reunião de análise retrospectiva — e mais tarde, ao escrever as descobertas — evite linguagem que destaque os indivíduos como pessoalmente responsáveis pelo incidente. Em vez disso, foque em ações, resultados e impacto.

Embora seja importante manter a conversa segura e objetiva, chegar à causa-raiz do incidente é fundamental para resolvê-lo. Você pode usar uma técnica na reunião chamada “Os 5 porquês”. Comece certificando-se de que todos concordam sobre qual é o problema. Em seguida, pergunte por que ele aconteceu e, em seguida, pergunte “por que?” para a resposta a essa pergunta. Repita a pergunta pelo menos cinco vezes para certificar-se de descobrir todos os fatores profundos que contribuem para o problema. Esteja atento para que a sala não tente se afastar de uma verdade incômoda ou chegar a um consenso fácil. Você pode aprender mais sobre a abordagem "Os 5 porquês" com a tática do Esquema Tático aqui.

Revise cada análise retrospectiva e incorpore essa prática no processo

Um relatório de análise retrospectiva de incidente não revisado poderia muito bem nunca ter sido escrito. Depois que um relatório de análise retrospectiva de incidente é elaborado, é importante revisá-lo para fechar quaisquer problemas não resolvidos, capturar ideias a serem consideradas no futuro e finalizar o relatório. Você pode até dizer que o incidente não foi mesmo resolvido até que esta revisão ocorra.

Como fazer acontecer? Agende uma reunião recorrente com o departamento de engenharia (e qualquer outra pessoa que possa ter interesse, como suporte ao cliente ou gerentes de conta), pelo menos uma vez por mês, para revisar os relatórios de análise retrospectiva de incidentes. Você pode optar por revisar relatórios recentes ou talvez revisar relatórios mais antigos e compartilhar lições que ainda são relevantes hoje.

Um plano eficaz de análise retrospectiva de incidente

Para que as análises retrospectivas sejam eficazes — e permitirem que você crie uma cultura de melhoria contínua — você deve implementar um processo simples e repetível do qual todos possam participar. Como você vai fazer esse processo vai depender da cultura e da equipe. A Atlassian desenvolveu um método que funciona para a gente e você pode ler mais sobre o assunto no manual de incidentes.

Aqui estão algumas dicas para começar:

Dica 1: defina um limite

Os incidentes na empresa devem ter níveis de gravidade claros e mensuráveis. Esses níveis de gravidade podem ser usados para acionar o processo de análise retrospectiva. Por exemplo, qualquer incidente Grav-1 ou superior aciona o processo de análise retrospectiva, enquanto essa análise pode ser opcional para incidentes menos graves. Considere permitir que os líderes de equipe ou a gerência tenham a oportunidade de solicitar uma análise retrospectiva para qualquer incidente que não atenda ao limite.

Dica 2: não procrastine

É importante fazer uma pausa e descansar um pouco depois de um incidente, mas não demore a escrever a análise retrospectiva do incidente. Se esperar muito tempo, informações importantes podem ser perdidas ou esquecidas. No cenário ideal, ela é elaborada logo após uma reunião de revisão pós-incidente a ser realizada dentro de 24-48 horas após a resolução do incidente e não mais do que cinco dias úteis.

Dica 3: atribua funções e proprietários

Uma reunião de revisão pós-incidente é onde você discute os dados que vão ser registrados na análise retrospectiva do incidente. É bom delegar o rascunho dessa análise a uma pessoa específica, de preferência alguém familiarizado com o incidente e que tenha o nível necessário de conhecimento técnico e organizacional para entender as causas e as resoluções.

Dica 4: trabalhe com base em um template

Um template pode evitar que você omita informações importantes e é uma ótima maneira de manter a uniformidade em todas as suas análises retrospectivas.

Dica 5: inclua um cronograma

Um cronograma é uma ajuda muito útil na documentação de incidentes. Muitas vezes, é o primeiro lugar para onde os olhos dos leitores saltam quando tentam avaliar com rapidez o que aconteceu. Tente ser o mais claro e específico possível. Por exemplo, “11h14, horário padrão do Pacífico” e não “por volta das 11h”. Ser específico com carimbos de data/hora permite mapear uma cadeia de eventos de alta fidelidade, o que é útil para identificar áreas de melhoria. Por exemplo, você pode identificar que o intervalo entre quando o impacto começou e quando os clientes foram notificados foi muito longo.

Tempos importantes a serem incluídos.

• Primeiro alerta ou ticket
• Primeiro anúncio de comunicações (interno e/ou externo)
• Horários das atualizações da página de status
• Horário de qualquer tentativa de correção (reversões de código, etc.)
• Tempo de resolução

Dica 6: informações, informações, informações

Ignorar informações é um caminho rápido para escrever análises retrospectivas inúteis e pouco claras. Adicione o máximo possível de informações sobre o que aconteceu e o que foi feito durante o incidente. Em vez de "então ocorreu o comunicado público", diga "A gente enviou o comunicado público inicial anunciando o incidente na página de status pública e conta no Twitter".

Sempre que possível, inclua links e nomes, links para tickets e atualizações de status, links para documentos de estado de incidente e gráficos de monitoramento. Não tenha medo de adicionar capturas de tela de gráficos ou painéis relevantes também. Um gráfico do sistema de monitoramento que mostra com clareza os horários de início e término do incidente (por exemplo, uma queda na taxa de solicitação seguida de um retorno ao normal) é muito valioso porque é inequívoco. Ele se torna ainda mais poderoso quando combinado com gráficos que mostram o que estava acontecendo nos bastidores durante esse tempo, por exemplo, conexões de banco de dados, estado de link de rede ou CPU/memória/io/consumo de largura de banda no mesmo período.

Dica 7: capture métricas de incidente

Quando você captura métricas na análise retrospectiva de incidente, aplica dados concretos aos problemas e os impactos que eles têm. Ter esses pontos de dados ajuda a determinar se a equipe está indo na direção certa e reduzindo o número de incidentes, a gravidade e o tempo de inatividade. Com métricas consistentes sendo medidas, você pode dar um passo para trás e olhar para as tendências de incidentes ao longo do tempo.

Algumas métricas a serem consideradas no rastreamento de análise retrospectiva do incidente:

• O número de minutos de tempo de inatividade, para que você possa rastrear se esse número está indo para cima ou para baixo
• A gravidade do incidente para que você possa determinar a confiabilidade relativa dos sistemas.
• Tempo médio de resolução (MTTR), que mede o tempo médio necessário para resolver um incidente, a partir de quando foi relatado pela primeira vez.

A dica mais importante? Não pule nenhuma etapa. A chave para a realização de análises retrospectivas de incidente que ajudem você a melhorar a equipe e os sistemas é ter e cumprir um processo.

Use um template de análise retrospectiva de incidente para simplificar o processo

Para garantir que a equipe desenvolva uma cultura em torno das revisões de análises retrospectivas de incidentes, facilite a captura de informações, agende reuniões e publique o relatório final com checklists e templates reutilizáveis. Um processo repetível proporciona uniformidade e ajuda as pessoas a saber o que esperar, fazendo com que entrem no processo com uma mentalidade produtiva.

Itens típicos da lista de verificação para um processo de análise retrospectiva de incidente:

Reuniões que precisam ser realizadas:

• Reunião de coleta de informações
• Revisão do relatório
• Apresentação do relatório

Informações que precisam ser coletadas antes do tempo:

• Agendas padrão para cada reunião
• Participantes, partes interessadas, revisores
• Padronizar a redação de relatórios de análise retrospectiva de incidentes com um template