Modelo de análise pós-incidente e RCA para equipes de TI

Então, veja como a Zylker realizou a análise pós-incidente. A equipe de TI da Zylker iniciou o processo de análise pós-incidente, designando John Clarke como responsável pela documentação. John fez parte da equipe de resposta ao incidente e possuía conhecimento direto sobre a falha ocorrida. A seguir, está o documento de análise pós-incidente preparado por ele.

Uma das etapas mais importantes na análise pós-incidente é a análise de causa raiz (RCA).

A RCA é um método sistemático para identificar as causas subjacentes de um incidente. A equipe coleta e analisa todas as informações disponíveis, como logs de eventos, configurações de servidores e outros dados relevantes, para identificar a causa raiz. Esse processo permite que a organização aprenda com o incidente e tome medidas para evitar a ocorrência de problemas semelhantes no futuro.

Métodos de análise de causa raiz usados pela Zylker:

Método dos cinco porquês

O método dos cinco porquês é uma técnica de análise de incidentes que consiste em fazer repetidamente a pergunta "por quê?" até que a causa raiz seja identificada, o que ocorre geralmente após cinco iterações.

No caso da Zylker, veja como a equipe de TI identificou a causa raiz:

• Por que os clientes não conseguiram realizar pedidos? Porque o sistema de gerenciamento de pedidos estava indisponível.
• Por que o sistema de gerenciamento de pedidos estava indisponível? Porque o servidor de database estava desconectado dos servidores da aplicação.
• Por que ocorreu a desconexão? Porque a versão atualizada do Microsoft SQL Server era incompatível com a base de código da aplicação.
• Por que o database foi atualizado sem análise adequada? Porque a CMDB não foi atualizada para refletir as últimas relações de dependência, o que fez com que a análise realizada não refletisse o ambiente real.
• Por que a CMDB não foi atualizada com as últimas relações de dependência? Porque falhas de comunicação dentro da equipe levaram à descontinuação do procedimento operacional padrão para mapeamento de dependências.

Diagrama de causa e efeito

Também conhecida como diagrama de Ishikawa, esta ferramenta visual identifica fatores potenciais, categorizados por causas raiz como pessoas, processos, tecnologia e ambiente.

A equipe de resposta a incidentes criou um diagrama de causa e efeito com o problema central sendo a "Falha no sistema de gerenciamento de pedidos". Cada uma das ramificações representaria uma categoria de causa raiz potencial:

Método Kepner-Tregoe (KT)

É um método estruturado de resolução de problemas que utiliza uma série de perguntas para definir o problema, analisar causas potenciais e desenvolver ações corretivas.

Veja como o modelo KT foi aplicado para identificar a causa raiz:

• Definir o problema: O sistema de gerenciamento de pedidos sofreu uma falha, resultando em uma perda significativa de receita.
• Analisar causas potenciais: Com base nas informações coletadas na análise pós-incidente e nas conclusões após a análise do diagrama de causa e efeito, a equipe identificou causas potenciais, como falhas de comunicação e análise incompleta da configuração.
• Desenvolver e testar soluções: A equipe avaliou e priorizou soluções para cada causa potencial. Isso pode envolver a implementação de uma CMDB em tempo real, com mapeamento granular de dependências, atualização das políticas do CAB, revisão dos workflows de gerenciamento de mudanças e a implementação de janelas de congelamento de mudanças.

Ao empregar esses três métodos de RCA, a Zylker conseguiu identificar a causa raiz da falha. Lembre-se de que a RCA é uma etapa muito importante na análise pós-incidente e orienta os esforços de gerenciamento de problemas que serão adotados em casos de incidentes repetidos ou falhas graves.

Nas organizações que não realizam uma análise pós-incidente abrangente, as equipes de TI perdem a valiosa oportunidade de revisar suas ações durante a resposta ao incidente e identificar insights que podem fazer toda a diferença em suas estratégias de gerenciamento de incidentes e problemas. No entanto, nas equipes que realizam análises pós-incidente, o exercício pode facilmente se transformar em um jogo de culpa, com acusações sobre as falhas. Para que uma análise pós-incidente e uma RCA sejam realmente valiosas, as equipes de TI precisam conduzir ambos os processos de forma objetiva, sem atribuição de culpa, e usar a experiência do incidente como aprendizado para fortalecer a resiliência dos seus serviços de TI.