O que é a análise de causa raiz
"A análise de causa raiz (Root Cause Analysis, RCA) é um conjunto de técnicas usadas para identificar a origem real de um problema, em vez de tratar apenas os seus sintomas."
A RCA parte de um princípio simples: resolver um problema sem perceber o que o originou apenas garante que o problema volta a acontecer. Em vez de aplicar soluções temporárias - os chamados workarounds - a análise de causa raiz procura o factor sistémico subjacente que, se eliminado, evita a recorrência.
Originária da indústria transformadora (Toyota, anos 1930), a metodologia expandiu-se para a aviação, saúde e, nas últimas décadas, para as tecnologias de informação. Em TI, a RCA é um componente central da gestão de problemas, permitindo transformar incidentes recorrentes em melhorias permanentes dos serviços. Um aspecto importante: a RCA foca-se em causas sistémicas, não em culpados individuais.
Métodos de análise de causa raiz
Existem vários métodos de RCA, cada um adequado a diferentes tipos de problemas. A escolha do método depende da complexidade do problema, dos dados disponíveis e da experiência da equipa.
6 métodos de análise de causa raiz
Os 5 porquês na prática
Os 5 porquês são o método mais simples e mais usado em TI. A ideia é questionar cada resposta com um novo "porquê?" até chegar ao factor que, se corrigido, elimina o problema na origem. O número cinco é indicativo - por vezes chegamos à causa raiz em 3 iterações, outras precisamos de 7.
O exemplo seguinte mostra como aplicar os 5 porquês a um problema real de serviços de TI:
Os utilizadores não conseguem aceder à aplicação CRM.
| Pergunta | Resposta |
|---|---|
| Porquê o CRM está inacessível? | O servidor de aplicação não responde. |
| Porquê o servidor não responde? | O disco ficou sem espaço. |
| Porquê o disco ficou sem espaço? | Os ficheiros de log cresceram sem controlo. |
| Porquê os logs cresceram sem controlo? | A rotação de logs não estava configurada. |
| Porquê a rotação não estava configurada? | O procedimento de instalação não incluía esta configuração. |
O procedimento de instalação do servidor não contempla a configuração de rotação de logs.
Acção correctiva: Actualizar o procedimento de instalação para incluir a configuração automática de rotação de logs em todos os servidores. Note-se que a causa raiz não é "o disco ficou sem espaço" (isso é o sintoma) nem "o operador não configurou a rotação" (isso seria culpar uma pessoa). A causa raiz é sistémica: o processo de instalação tem uma lacuna.
O diagrama de Ishikawa
O diagrama de Ishikawa - também chamado diagrama de espinha de peixe ou diagrama de causa-efeito - organiza as causas potenciais de um problema em categorias. O problema é colocado na "cabeça do peixe" e as causas ramificam-se como espinhas.
O modelo original usa 6 categorias, conhecidas como os "6M". Adaptadas para TI, ficam assim:
- Formação insuficiente
- Erro humano
- Falta de pessoal
- Fadiga ou sobrecarga
- Processos não documentados
- Procedimentos desactualizados
- Falta de testes antes do deployment
- Ausência de plano de rollback
- Hardware obsoleto
- Falha de rede ou switch
- Capacidade insuficiente
- Falta de redundância
- Software desactualizado
- Dados corrompidos
- Licenças expiradas
- Dependências incompatíveis
- Monitorização insuficiente
- Métricas incorrectas
- Alertas mal configurados
- Thresholds desajustados
- Temperatura da sala de servidores
- Falha de energia
- Desastres naturais
- Falha do fornecedor de telecomunicações
Na prática, a equipa começa por identificar o problema central e depois debate possíveis causas dentro de cada categoria. As causas com maior evidência são então investigadas com mais profundidade - muitas vezes combinando o Ishikawa com os 5 porquês para cada ramo relevante.
A análise de causa raiz no ITIL 4
No ITIL 4, a análise de causa raiz é um elemento central da prática de gestão de problemas. Um problema, na linguagem ITIL, é a causa de um ou mais incidentes - e a RCA é o principal instrumento para investigá-lo.
A prática de gestão de problemas no ITIL 4 estrutura-se em três fases distintas, cada uma com um propósito diferente:
Identificação de problemas
Os problemas são detectados através da análise de tendências de incidentes, monitorização proactiva e informação de fornecedores. Um incidente recorrente é sinal claro de um problema por resolver.
Controlo de problemas
Esta fase inclui a investigação e diagnóstico usando técnicas de RCA. Documenta-se o workaround (se existir) e prioriza-se o problema por impacto e probabilidade de recorrência.
Controlo de erros
Gestão dos erros conhecidos (known errors). Avalia-se o custo e benefício de soluções permanentes e, quando adequado, submetem-se RFCs (Requests for Change) para eliminar a causa raiz.
Uma nota importante: nem todos os problemas justificam uma análise de causa raiz completa. O esforço de investigação deve ser proporcional ao impacto do problema. Um incidente major que afecte centenas de utilizadores merece uma RCA detalhada com equipa multidisciplinar; um problema menor de baixo impacto pode ser resolvido com uma análise mais rápida. Esta proporcionalidade é um dos princípios orientadores do ITIL 4.
Como conduzir uma análise de causa raiz
Independentemente do método escolhido, uma RCA eficaz segue sempre um processo estruturado. Os cinco passos abaixo aplicam-se a qualquer contexto de TI.
Definir o problema
Descrever o problema com factos: o quê, quando, onde, quem é afectado, qual o impacto. Evitar suposições. Uma definição precisa orienta toda a investigação subsequente.
Recolher dados
Reunir logs, métricas, cronologias e testemunhos. Quanto mais dados disponíveis, mais fundamentada será a análise. Os dados devem cobrir o período antes, durante e após o problema.
Identificar factores causais
Usar um ou mais métodos de RCA (5 porquês, Ishikawa, Pareto). Envolver pessoas de diferentes áreas para obter perspectivas diversas e evitar pontos cegos técnicos ou organizacionais.
Determinar a causa raiz
Validar a causa raiz com evidências. Perguntar: "Se eliminarmos esta causa, o problema deixa de ocorrer?" A resposta deve ser claramente afirmativa para confirmar que encontrámos a causa raiz.
Implementar e verificar
Definir acções correctivas concretas, implementá-las, e monitorizar para confirmar que o problema não reaparece. Documentar o processo e os resultados para aprendizagem organizacional.
Erros comuns na análise de causa raiz
Mesmo com boa intenção, as equipas cometem erros recorrentes que comprometem a qualidade da análise. Conhecer estes erros é o primeiro passo para os evitar.
Aceitar a primeira resposta como causa raiz sem investigar mais fundo. "O disco ficou sem espaço" é um sintoma, não a causa raiz. A investigação deve continuar até encontrar o factor sistémico.
A RCA procura falhas sistémicas, não culpados individuais. "O operador enganou-se" raramente é a causa raiz. A pergunta certa é: porque é que o sistema ou processo permitiu que o erro ocorresse?
Basear a análise em suposições em vez de evidências concretas - logs, métricas, cronologias. Sem dados, a RCA torna-se um exercício de opinião que confirma as ideias pré-existentes da equipa.
Envolver apenas uma pessoa ou área. As causas raiz cruzam frequentemente fronteiras organizacionais - um problema em TI pode ter origem em processos de negócio ou em decisões de gestão.
Identificar a causa raiz mas não agir. O relatório vai para a gaveta. Uma RCA sem acção correctiva implementada e verificada não tem valor - é apenas documentação de um problema por resolver.
Dois eventos ocorrerem ao mesmo tempo não significa que um cause o outro. A actualização do sistema e a falha do serviço podem ter acontecido simultaneamente por coincidência. As evidências devem confirmar a relação causal.
Quer dominar a gestão de problemas?
Na formação ITIL 4 Foundation, aprende as técnicas de análise de causa raiz e todas as práticas de gestão de serviços.
Ver formação ITILPerguntas frequentes
A causa imediata (ou sintoma) é o que se observa directamente. A causa raiz é o factor subjacente que, se corrigido, evita que o problema volte a ocorrer. Por exemplo, o servidor reiniciar é o sintoma; a falta de monitorização de memória é a causa raiz. Tratar apenas o sintoma - reiniciar o servidor manualmente - não evita que o problema volte a acontecer.
Sempre que um incidente grave ocorre, quando o mesmo problema se repete, quando os custos de um problema justificam a investigação, ou como parte da prática de gestão de problemas do ITIL 4. A regra prática: se a recorrência do problema custar mais do que a investigação, a RCA compensa.
Depende da complexidade. Um problema simples pode ser analisado em 30 minutos com os 5 porquês. Problemas complexos - como um incidente major que afectou múltiplos serviços - podem exigir dias ou semanas de investigação com uma equipa multidisciplinar. O importante é que o esforço seja proporcional ao impacto do problema.
Uma equipa multidisciplinar com conhecimento técnico e de processo. Tipicamente inclui o gestor de problemas, técnicos que trataram o incidente, e representantes das áreas afectadas. Para problemas complexos, pode ser útil envolver o modelo RACI para clarificar quem tem que papel na investigação.
Não existe um método universalmente melhor. Os 5 porquês são ideais para problemas simples com uma cadeia causal clara. O diagrama de Ishikawa funciona bem para problemas com múltiplas causas potenciais. A análise de Pareto ajuda a priorizar quando há muitos problemas em simultâneo. Muitas equipas combinam vários métodos na mesma investigação.
O ITIL 4 recomenda a análise de causa raiz como parte da prática de gestão de problemas, mas não a torna obrigatória para todos os problemas. O esforço de análise deve ser proporcional ao impacto do problema - um dos princípios orientadores do ITIL 4 é "começar onde está" e aplicar o nível de rigor adequado a cada situação.