Características e componentes de uma boa revisão pós-incidente
- 3 minutos
Agora você sabe o que é uma revisão pós-incidente, seu papel no processo de resposta a incidentes e quando deve conduzi-la. Nesta unidade, você mergulhará um pouco mais nos detalhes do que torna uma revisão pós-incidente mais eficaz.
Como os incidentes são diferentes, a composição exata das avaliações pós-incidente também pode ser diferente. No entanto, existem algumas características e componentes comuns de uma boa revisão que podem fornecer uma base sólida para a realização do processo.
O que não é
Antes de se entender as características de uma boa revisão pós-incidente, deve-se considerar o que não é.
- Não é um documento ou relatório. É fácil pensar em uma "avaliação" como um resumo escrito e, de fato, um relatório resumido geralmente segue uma revisão pós-incidente. No entanto, estas são duas partes diferentes e distintas da fase de análise do ciclo de vida de resposta a incidentes.
- Não é uma determinação de causalidade. Sua análise analisa os fatores que contribuíram para a falha, mas o objetivo não é identificar um culpado (especialmente não uma única causa raiz; sistemas complexos quase sempre falham devido a todo um conjunto de fatores contribuintes). É pensar e compartilhar informações sobre todos os aspetos do incidente para aprender e melhorar. Não é uma lista de itens de ação. Você pode acabar com essa lista como resultado do que aprendeu na avaliação, mas esse não é o foco. Se você não sair com uma lista de itens numa fila de tickets ou relatórios de bugs num sistema de reporte de bugs, mas souber mais sobre os seus sistemas do que antes, a revisão foi bem-sucedida.
A revisão do incidente é, acima de tudo, uma conversa. É um espaço definido dentro do qual sua equipe pode rever o que sabia na época e o que sabe agora, e explorar e entender melhor como as partes do sistema, incluindo as partes humanas, trabalham ou não juntas em resposta a problemas.
Características e componentes
Como referimos na última unidade, uma análise de incidentes tem de ser irrepreensível. Embora você precise examinar como as partes humanas do sistema interagiram com ele, você não faz isso para rotular ninguém como "culpado". O foco deve ser nas falhas da tecnologia e do processo, não nas pessoas.
Enquadre suas perguntas para refletir isso, por exemplo:
- Qual foi o défice no nosso acompanhamento que não conseguiu dar à pessoa no teclado o contexto necessário para tomar a decisão certa?
- Por que havia uma opção "destruir todo o banco de dados" na ferramenta?
- Ou, melhor ainda: por que a ferramenta não pediu confirmação antes de executar essa função?
Quando as coisas correm mal, pode ser tentador apontar o dedo. No entanto, você deve se lembrar deste ponto-chave:
Não se pode despedir para alcançar a fiabilidade.
Humilhar e culpar ou uma investigação que visa encontrar e demitir a pessoa que é "responsável" não levará a sistemas mais confiáveis. Em vez disso, levará a uma equipe de operações inexperiente ou mesmo vazia e pessoal que tem medo de agir.
Considere a revisão como uma procura por conhecimento e contexto, não uma investigação sobre quem fez o quê e uma reação a isso.
Embora a revisão seja sobre as falhas da tecnologia, não é um processo técnico, mas sim um processo de pessoas. Fale – e, mais importante, ouça – as pessoas envolvidas no incidente. Mantenha a mente aberta. Pessoas diferentes têm perspetivas diferentes e nem todos concordarão, e essa mistura de perspetivas é inestimável para o processo de aprendizagem.
Uma revisão pós-incidente é uma investigação honesta. Como tal, abrange estes componentes-chave:
- Discussão
- Discurso
- Dissidência
- Descoberta
Esses "4 Ds" criam uma estrutura na qual você pode construir uma revisão pós-incidente que pode resultar em sistemas mais confiáveis e equipes mais produtivas que trabalham juntas.
Em nossa próxima unidade, falaremos mais sobre o processo que você pode seguir para criar uma revisão pós-incidente eficaz.