Blog/Artigos · Operações
Incidente contra problema, análise de causa raiz, os cinco porquês, Ishikawa e a base de erros conhecidos, com ITIL 4.
Iyov fala em achar a raiz da questão, não a folha que balança na superfície. Operação imatura vive arrancando folhas: o mesmo incidente volta toda semana, e toda vez alguém apaga o fogo, comemora e vai embora, até o fogo voltar. Gestão de problemas é a disciplina de parar de arrancar folhas e ir à raiz. Incidente é o sintoma que dói agora; problema é a causa que produz o sintoma de novo e de novo. Enquanto a raiz está viva, o incidente sempre brota outra vez.
O ITIL separa os dois com precisão que salva operação. Incidente é uma interrupção não planejada: o serviço caiu, restaure já. Problema é a causa subjacente de um ou mais incidentes: por que ele cai toda segunda de manhã. A gestão de incidentes tem pressa e mira restaurar; a gestão de problemas tem calma e mira eliminar a causa. Confundir os dois é a origem da operação que vive exausta apagando o mesmo fogo.
A relação entre eles é temporal e cultural. No incidente, você mitiga sem entender, porque o cliente sofre. Depois, com o serviço restaurado, o problema entra em cena para perguntar com calma por que aconteceu e como impedir a recorrência. O time que só faz gestão de incidentes fica preso num ciclo reativo eterno; o que investe em gestão de problemas reduz o volume de incidentes na fonte, e é essa redução que libera o time do modo pânico permanente.
A técnica mais simples e mais subestimada de análise de causa raiz nasceu na Toyota, com Taiichi Ohno: os cinco porquês. Diante de um sintoma, pergunte por quê, e à resposta pergunte por quê de novo, cinco vezes ou até chegar a uma causa que, se removida, impede a recorrência. O número cinco não é mágico; é um lembrete de que a primeira resposta quase nunca é a raiz, é só a folha um pouco mais funda.
O erro clássico é parar cedo, na causa técnica imediata, e perder a causa sistêmica. O servidor caiu. Por quê? Ficou sem memória. Por quê? Um vazamento no código. Muitos param aqui e corrigem o vazamento, mas a raiz está mais fundo: por que o vazamento chegou à produção? Porque não havia teste de carga. Por quê? Porque não era exigido no processo. A raiz acionável quase sempre é de processo, não de código, e é ela que impede a família inteira de incidentes semelhantes.
Parar no vazamento conserta um caso; chegar ao processo impede a família inteira de incidentes semelhantes.
Nem todo problema tem uma linha única de porquês. Incidentes complexos costumam ter causas que se combinam, e para esses o diagrama de Ishikawa, ou espinha de peixe, criado por Kaoru Ishikawa, organiza a investigação por categorias de causa: pessoas, processo, tecnologia, dado, ambiente externo. Em vez de uma cadeia, você mapeia todas as contribuições possíveis e depois pondera quais de fato conspiraram para o incidente.
O valor do Ishikawa é combater o viés da causa única, aquela vontade de encontrar o culpado e fechar o caso. Incidentes graves quase nunca têm uma causa; têm uma cadeia de pequenas fragilidades que, sozinhas, seriam inofensivas, e que juntas produziram a falha. Mapear as categorias evita a conclusão preguiçosa e revela que fechar uma única fragilidade da cadeia já teria evitado o incidente, o que orienta onde investir o conserto com mais retorno.
Nem todo problema se resolve na hora; alguns exigem tempo, orçamento ou uma mudança grande. Para esses, o ITIL define o erro conhecido: um problema com causa raiz identificada e uma solução de contorno documentada, guardado numa base de erros conhecidos (KEDB). Quando o incidente relacionado volta, o plantão aplica o contorno em minutos em vez de investigar do zero, e o MTTR despenca. A KEDB é a memória que impede o time de redescobrir a mesma causa toda vez.
O nível mais maduro é a gestão proativa de problemas: em vez de esperar o incidente para investigar, analisar tendências, alertas recorrentes e near misses para achar a raiz antes que ela cause estrago. É o que separa a operação que reage da que antecipa. Foi nessa direção que, na CRDC, o recorrente de nove ocorrências em 34 dias teve a causa raiz confirmada por análise forense read-only com AIOps e RAG: o problema foi tratado na raiz, e a KEDB registrou o contorno para não recomeçar do zero.
Gestão de problemas é ir à raiz para o incidente não brotar de novo: separar sintoma de causa, cavar com os cinco porquês até a raiz de processo, usar Ishikawa quando a causa é combinada, e guardar o erro conhecido para cortar o MTTR do recorrente. O ITIL 4 dá o método, e o nível maduro é achar a raiz antes do incidente. A IA agrupa incidentes num problema, sustenta os porquês com dados e mantém a KEDB viva, mas decidir qual raiz vale arrancar continua sendo julgamento de quem opera. Enquanto a raiz vive, a folha volta.
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros. Trabalho com tecnologia desde 2009 e com cibersegurança em tempo integral desde 2015, em infraestrutura crítica, fintech e banking. Escrevo sobre o que eu opero: confiabilidade, segurança, governança e IA que passa por gate antes de chegar em produção.
Operaçõesחֲצֹצְרֹת
No incidente, a prioridade é restaurar, não achar culpado. Papéis claros, severidade objetiva, comando único e postmortem blameless são o que transformam o caos em processo.
Operaçõesגֶּשֶׁר
Toda mudança é uma travessia de risco, e a maioria dos incidentes graves nasce de uma. GMUD controla a travessia sem matar a velocidade: tipos de mudança, aprovação proporcional e a métrica que importa.
