Mencionamos isso em um módulo anterior neste roteiro de aprendizagem, mas como uma revisão rápida, os incidentes têm um ciclo de vida semelhante a este:

Um incidente passa por estas fases:

• Detecção: quando notamos pela primeira vez que há um problema (idealmente do nosso sistema de monitoramento antes que um cliente observe ou reclame);
• Resposta: Entramos em ação, envolvemos nosso processo de resposta a incidentes, tentamos triagem da situação e respondemos com urgência.
• Correção: trabalhamos para determinar o problema e trabalhar para trazer o sistema ou o serviço de volta à ordem de trabalho.
• Análise: após o incidente, tentamos aprender com a experiência, talvez determinando coisas que talvez queiramos mudar no sistema ou em nosso processo.
• Preparação: fazemos alterações com base no que aprendemos que podem melhorar nossa confiabilidade e o contexto (processos e assim por diante) em torno dele.

O tópico deste módulo ocorre em grande parte durante a fase de análise. Aprendemos com incidentes realizando uma revisão pós-incidente.

Você deve fazer uma revisão pós-incidente após cada incidente significativo.

Embora a revisão formal ocorra após as fases de resposta e correção, você começa a definir o estágio para sua análise assim que receber um alerta acionável de que ocorreu um incidente, informar os membros da equipe e iniciar uma conversa em torno do incidente.

Definindo a revisão pós-incidente

Nem todos usam exatamente o mesmo idioma para se referir a esse processo. Algumas pessoas chamam isso:

• Revisão pós-incidente
• Revisão de aprendizagem pós-incidente
• Análise posterior
• Retrospectiva

Neste módulo, usaremos o termo "revisão pós-incidente".

Além disso, nem todo mundo faz exatamente da mesma maneira. Por exemplo, muitas pessoas começam colocando todos que tinham qualquer conexão com o incidente em uma sala, enquanto outras pessoas optam por criar a revisão por meio de entrevistas individuais e, em seguida, relatar de volta ao grupo.

O último método geralmente funciona melhor quando as configurações de grupo em sua organização dificultam uma única reunião maior. Por exemplo, se a dinâmica de grupo, as personalidades, a natureza distribuída de uma equipe distribuída por fusos horários interferirem em ter esse tipo de reunião, talvez seja mais fácil trabalhar na revisão de uma maneira diferente. Você deve fazer o que funciona melhor para sua equipe e as circunstâncias.

Seja lá como você o chamar e de qualquer forma que você o organize, há três pontos-chave.

• Você deve tentar incluir todos os envolvidos na resposta a incidentes na revisão pós-incidente. Incluir todas essas vozes é importante porque pessoas diferentes terão diferentes perspectivas e lembranças do mesmo evento.
• Você deve executar a revisão pós-incidente dentro de 24 a 36 horas após o evento, se possível. A neurociência confirmou que a memória humana é notoriamente não confiável; as pessoas esquecem as coisas. Quanto mais tempo passa após um evento, as memórias menos detalhadas e específicas tendem a ser.
• Uma revisão de incidente deve ser isenta de culpas. Falaremos mais sobre isso na próxima unidade.

Finalidade da revisão pós-incidente

O objetivo da revisão pós-incidente é que sua equipe possa aprender e melhorar. Você quer aprender sobre os sistemas e sobre as coisas que você colocou no lugar que funcionaram ou não funcionaram, para que você possa fazer melhorias.

Ao mesmo tempo, você deve lembrar que os itens de ação gerados — relatórios, tarefas, relatórios de bugs, tíquetes, comentários — são úteis, mas são periféricos ao ponto do processo, que é aprender e melhorar. A geração de uma lista de itens de ação é, na melhor das hipóteses, uma meta secundária.