Características e componentes de uma boa análise pós-incidente
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 diferem, a composição das análises pós-incidente também pode diferir. 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 entender as características que tornam uma boa revisão pós-incidente, você deve 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 distintas da fase de análise do ciclo de vida de resposta ao incidente.
- 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 em uma fila de tíquetes ou relatórios de bugs em um sistema de relatório de bugs, mas souber mais sobre 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.
Estruture as suas perguntas para refletir este objetivo, 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 algo falha, pode haver tendência para indicar um culpado. No entanto, tem de se lembrar deste aspeto importante:
Você não pode disparar seu caminho para a confiabilidade.
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.
Encare a análise como um método de obter conhecimentos e contexto e não como uma forma de descobrir responsáveis e reagir a esta descoberta.
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-se de espírito aberto. Diferentes pessoas terão diferentes perspetivas e nem todas estarão de acordo. Esta multiplicidade de perspetivas é valiosa para o processo de aprendizagem.
Uma análise pós-incidente é uma investigação honesta. Como tal, inclui estes componentes principais:
- Debate
- Discurso
- Dissidência
- Deteção
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.
Na próxima unidade, vamos continuar a abordar o processo que pode seguir para criar uma análise pós-incidente eficaz.