Quando se observa a rotina posterior a uma grande parada de sistema, a análise de causa raiz é a etapa que Rolando Bonaccorsi, executivo de operações e delivery em tecnologia, descreve como a mais negligenciada de todo o ciclo de resposta. O relatório é produzido com rigor, circula entre as áreas envolvidas, recebe elogios pela clareza e termina guardado em uma pasta, sem gerar uma única mudança no modo de operar.
Documentar incidente virou prática comum em empresas de qualquer porte, por exigência de auditoria ou por amadurecimento da própria área de tecnologia. O que ainda falta, com frequência, é a diferença entre registrar o que aconteceu e entender por que foi possível acontecer naquele ambiente. A primeira resposta encerra o assunto, enquanto a segunda cobra decisão, prazo e responsável, por isso incomoda mais.
O que um relatório de incidente deveria responder?
Linha do tempo, impacto e ações de contenção formam a parte fácil do documento, porque são fatos observáveis registrados pelas próprias ferramentas de monitoramento. A parte difícil começa na pergunta sobre qual condição permitiu a falha chegar até a produção sem ser percebida por nenhuma barreira anterior, seja teste automatizado, revisão de mudança ou alerta configurado para aquele serviço.
Conforme pondera Rolando Bonaccorsi, um relatório útil precisa explicar também o que atrasou a percepção do problema dentro da operação. Tempo entre falha e detecção, tempo entre detecção e acionamento correto e tempo entre acionamento e primeira ação eficaz revelam mais sobre a maturidade da equipe do que a descrição técnica do defeito que derrubou o serviço.
Como a causa raiz é encontrada na prática?
A técnica mais usada consiste em repetir a pergunta sobre o motivo até que a resposta deixe de ser técnica e passe a ser organizacional. Certificado expirado derruba o serviço em produção, só que a causa raiz mora no processo de renovação, que não tinha dono definido, aviso prévio confiável nem verificação automática de validade em nenhuma etapa.
Investigação madura separa gatilho, causa e fator contribuinte desde o início. O gatilho é o evento visível, a causa é a condição estrutural que permitiu o evento e os fatores contribuintes explicam por que a recuperação demorou mais do que deveria. Rolando Bonaccorsi esclarece a distinção como fundamento da análise, já que corrigir apenas o gatilho devolve o sistema ao ar e mantém o risco intacto.
Sintoma corrigido e problema preservado
Reiniciar serviço, aumentar memória e limpar fila resolvem a crise do dia e deveriam ser registrados como contenção, nunca como solução definitiva de engenharia. O problema aparece quando a contenção é tratada como fim da história, de modo que a mesma falha retorna semanas depois com outro rótulo, outro horário e outra equipe na linha de frente do atendimento.
A reincidência é o indicador que denuncia o ciclo com mais clareza em qualquer operação. Na análise conduzida por Rolando Bonaccorsi, incidentes repetidos com causas aparentemente distintas quase sempre compartilham uma origem comum que ninguém investigou, porque cada ocorrência foi encerrada dentro do próprio prazo de atendimento e nunca olhada em conjunto com as anteriores.
O que muda quando a análise gera ação?
Relatório que vira ação tem três características bastante simples de verificar em qualquer empresa, independentemente do tamanho da equipe técnica. Cada recomendação possui responsável nomeado, prazo definido e critério de verificação, de forma que alguém consegue dizer, semanas depois, se a mudança foi implantada de fato e se o risco original diminuiu em alguma medida mensurável pela própria operação.
Operações que seguem esse caminho acumulam conhecimento em vez de acumular arquivos sem uso. O acervo de análises bem feitas tem valor que Rolando Bonaccorsi realça com frequência, uma vez que orienta prioridade de investimento técnico, revisão de arquitetura e treinamento das equipes que atuam sob pressão durante a próxima parada relevante do ambiente.
