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, sua função no processo de resposta a incidentes e quando você deve conduzir uma. Nesta unidade, você se aprofundará um pouco mais nos detalhes do que torna uma revisão pós-incidente mais eficaz.
Como os incidentes diferem, a composição exata das revisões pós-incidente também pode ser diferente. No entanto, há algumas características comuns e componentes 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 compõem uma boa revisão pós-incidente, você deve considerar o que ela não é.
- Não é um documento ou relatório. É fácil pensar em uma "revisão" como um resumo escrito e, de fato, um relatório de resumo geralmente segue uma revisão pós-incidente. No entanto, essas são duas partes diferentes e distintas da fase de análise do ciclo de vida da resposta a incidentes.
- Não é uma determinação de causalidade. Sua revisão analisa os fatores que contribuíram para a falha, mas a finalidade não é identificar um culpado (especialmente não uma única causa raiz; sistemas complexos quase sempre falham devido a um conjunto inteiro de fatores contribuintes). É pensar e compartilhar informações sobre todos os aspectos 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 você aprende na revisão, mas esse não é o foco. Se você não obtiver 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 os seus sistemas do que antes, a revisão obteve êxito.
A revisão de incidentes é, mais do que tudo, uma conversa. É um espaço definido no qual sua equipe pode examinar o que sabia na época e o que sabe agora e explorar e entender melhor como as partes do sistema, incluindo as partes humanas, fazem ou não trabalham juntas em resposta aos problemas.
Características e componentes
Como mencionamos na última unidade, uma revisão de incidentes não deve apontar culpados. Embora você precise examinar como as partes humanas do sistema interagem com ele, não faça isso para rotular uma pessoa como "culpada". O foco deve estar nas falhas da tecnologia e do processo, não das pessoas.
Formule suas perguntas para refletir isso, por exemplo:
- Qual foi o déficit em nosso monitoramento que não deu à 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 dão errado, pode ser tentador apontar o dedo. No entanto, você deve se lembrar deste ponto-chave:
Você não pode demitir pessoas para atingir 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, isso levará a uma equipe de operações inexperiente ou até mesmo vazia e pessoal que tem medo de agir.
Aborde a revisão como uma busca por conhecimento e contexto, não uma busca por quem fez o que e uma reação a isso.
Embora a revisão seja sobre as falhas da tecnologia, não é um processo técnico tanto quanto um processo de pessoas. Fale e, mais importante, ouça as pessoas envolvidas no incidente. Mantenha a mente aberta. Pessoas diferentes têm perspectivas diferentes e nem todos concordarão, e essa mistura de perspectivas é inestimável para o processo de aprendizagem.
Uma revisão pós-incidente é uma investigação honesta. Dessa forma, ele abraça esses componentes principais:
- Discussão
- Discurso
- Divergência
- Descoberta
Esses "4 Ds" criam uma estrutura na qual você pode criar 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.