Gestao de problemas e RCA: como parar de apagar incendio recorrente na TI

Por que o mesmo incidente volta toda semana

Toda equipe de TI conhece a cena: o servidor de arquivos trava na sexta-feira à tarde, alguém reinicia o serviço, o usuário volta a trabalhar e o chamado é fechado como "resolvido". Duas semanas depois, o mesmo servidor trava de novo. Novo chamado, novo reinício, novo fechamento. Ao longo de um ano, esse ciclo consome dezenas de horas de técnico, gera atrito com o negócio e — o mais grave — nunca produz aprendizado. O incidente foi encerrado, mas o problema continua vivo.

Isso acontece porque a maioria das operações de TI opera exclusivamente em modo de gestão de incidentes. Incidente é interrupção não planejada de um serviço, e o objetivo da gestão de incidentes é claro e legítimo: restaurar o serviço o mais rápido possível. Reiniciar, aplicar workaround, liberar espaço em disco — tudo isso é correto dentro do escopo do incidente. O erro está em achar que restaurar o serviço equivale a eliminar a causa.

A disciplina que fecha essa lacuna é a gestão de problemas. No vocabulário do ITIL, "problema" é a causa (ou causa potencial) de um ou mais incidentes. Enquanto o incidente pergunta "como volto a funcionar agora?", o problema pergunta "por que isso aconteceu e o que impede que aconteça de novo?". São processos com objetivos, prazos e indicadores diferentes — e tratar os dois como se fossem um só é a origem do apagar incêndio recorrente.

Incidente, problema e erro conhecido: a separação que muda tudo

Antes de aplicar qualquer técnica de análise de causa raiz, a operação precisa ter clareza sobre três objetos distintos que costumam ser confundidos no dia a dia:

• Incidente — interrupção ou degradação não planejada de um serviço. Tem SLA de restauração, é medido em tempo de resposta e tempo de solução. Fecha quando o usuário volta a trabalhar.
• Problema — a causa subjacente de um ou mais incidentes. Não tem SLA de usuário, tem prioridade de investigação. Fecha quando a causa é eliminada ou mitigada de forma permanente.
• Erro conhecido — problema cuja causa raiz já foi identificada e para o qual existe um workaround documentado, mas cuja correção definitiva ainda não foi aplicada (por custo, janela, dependência de fornecedor).

A separação é operacionalmente decisiva. Quando um incidente vira um registro de problema, ele deixa de disputar o SLA de atendimento e passa a ter tempo de investigação próprio. Isso evita a armadilha clássica: o técnico que tenta fazer análise de causa raiz com o usuário parado do outro lado da linha — e que, na prática, sempre escolherá o workaround, porque essa é a escolha certa naquele momento.

O registro de erro conhecido, por sua vez, é o ativo mais subestimado da operação. Uma base de erros conhecidos bem alimentada transforma um chamado de 40 minutos em um de 4 minutos, porque o primeiro nível já abre o chamado com o workaround na mão. Em operações maduras, é comum que 30% a 40% dos chamados recorrentes sejam resolvidos no primeiro contato apenas por existir essa base — sem nenhuma mudança técnica na infraestrutura.

Como fazer análise de causa raiz sem virar reunião de culpados

Análise de causa raiz (RCA, de root cause analysis) não é um ritual de auditoria nem um tribunal. É um método estruturado para responder por que uma falha ocorreu, até o ponto em que uma ação corretiva se torna possível. Três técnicas cobrem a maior parte dos casos em TI corporativa:

1. 5 Porquês — parte do sintoma e pergunta "por quê?" sucessivamente até chegar a uma causa acionável. Simples, rápida, ideal para incidentes de escopo delimitado. O risco é parar cedo demais na primeira resposta plausível.
2. Diagrama de Ishikawa (espinha de peixe) — organiza causas possíveis em categorias (pessoas, processo, tecnologia, ambiente, fornecedor, dados). Útil quando há múltiplas hipóteses concorrentes e a equipe precisa varrer o espaço de causas sem viés.
3. Análise cronológica (timeline) — reconstrói minuto a minuto o que aconteceu, com evidência de log, monitoramento e mudanças. Indispensável em incidentes graves, porque revela não só a causa técnica, mas também as falhas de detecção e de resposta.

Um exemplo concreto de 5 Porquês bem conduzido: o serviço de e-mail ficou indisponível. Por quê? O servidor ficou sem espaço em disco. Por quê? O log de transações cresceu 80 GB em dois dias. Por quê? O backup que trunca o log falhou. Por quê? O job de backup falha desde uma troca de senha da conta de serviço. Por quê? Não existe alerta de falha de job de backup, então ninguém percebeu. A causa raiz não é o disco cheio — é a ausência de monitoramento sobre a saúde do backup. Corrigir só o disco garante o retorno do incidente.

Se a ação corretiva que saiu da sua RCA é "orientar o usuário" ou "ter mais atenção", você parou antes da causa raiz. Causa raiz verdadeira gera mudança em processo, configuração, automação ou monitoramento — nunca só em intenção.

Um cuidado cultural importa tanto quanto o método: RCA precisa ser blameless. No momento em que a análise vira busca por culpado, as pessoas param de reportar o que realmente aconteceu, os relatos ficam defensivos e a evidência se degrada. A pergunta correta nunca é "quem errou", e sim "que condição do sistema permitiu que esse erro humano derrubasse o serviço".

Reativo x proativo: os dois modos da gestão de problemas

A gestão de problemas tem duas frentes, e a maioria das operações só pratica a primeira.

A gestão reativa de problemas parte de incidentes que já ocorreram. O gatilho pode ser um incidente crítico isolado (um P1 sempre deveria gerar registro de problema) ou a recorrência de incidentes menores. É a porta de entrada natural, mas por definição opera depois do dano.

A gestão proativa de problemas parte da análise de tendências, antes que a falha aconteça. Ela olha para dados que a operação já possui e procura padrões: categorias de chamado que crescem mês a mês, ativos com múltiplos incidentes no trimestre, alertas de disco que se repetem, erros recorrentes em logs de aplicação, equipamentos fora do ciclo de vida. Um servidor que gerou onze chamados nos últimos noventa dias é um problema, mesmo que nenhum desses chamados isoladamente tenha sido grave.

Para tornar isso rotina, três indicadores bastam para começar:

• Taxa de recorrência — percentual de chamados que são repetição de sintoma já visto nos últimos 90 dias. É o termômetro direto do incêndio recorrente.
• Top ativos por volume de incidentes — ranking mensal de máquinas, serviços ou integrações que mais geram chamado. Concentração é sinal de problema estrutural.
• Incidentes evitados — quantos chamados deixaram de ocorrer após o fechamento de um problema. É a métrica que justifica o investimento em RCA para a diretoria.

Sem instrumentação, nada disso existe. A gestão de problemas depende de que os chamados sejam categorizados com consistência, que o ativo afetado seja registrado e que exista histórico de mudanças correlacionável com a linha do tempo do incidente. Não é preciso ferramenta cara — é preciso disciplina de registro. Uma base de chamados com categoria "Outros" em 60% dos tickets torna a análise de tendência estatisticamente inútil.

Implantando o processo em uma operação que já está sobrecarregada

A objeção mais comum é legítima: "a equipe não dá conta nem dos incidentes, como vai fazer RCA?". A resposta é que a gestão de problemas se paga em poucos ciclos, desde que a implantação seja gradual e com escopo fechado. Um roteiro realista:

1. Defina gatilhos objetivos. Todo incidente P1 vira problema. Todo sintoma que se repetir três vezes em 30 dias vira problema. Sem critério escrito, nada é escalado.
2. Limite o trabalho em progresso. No máximo três a cinco problemas abertos por vez. Fila de problema infinita é fila morta.
3. Atribua dono e prazo de investigação. Problema sem responsável nominal não avança. O prazo é de investigação, não de solução.
4. Reserve tempo protegido. Duas a quatro horas semanais fora da fila de atendimento. Se o tempo de RCA disputar com o SLA de incidente, ele sempre perde.
5. Feche o ciclo com mudança. Toda RCA concluída gera um item de mudança, automação, monitoramento ou documentação — com data e responsável. RCA que termina em relatório não elimina incidente.
6. Revise mensalmente. Uma reunião curta com os três indicadores acima e o status dos problemas abertos. Trinta minutos por mês sustentam o processo.

Um detalhe que costuma decidir o sucesso da implantação: correlacionar incidentes com o histórico de mudanças. Uma parcela expressiva dos incidentes em ambientes corporativos tem origem em mudança recente — atualização, alteração de política, troca de certificado, mudança de regra de firewall. Se o registro de mudanças estiver íntegro, muitas RCAs se resolvem em minutos, não em dias, apenas cruzando a linha do tempo do incidente com o que mudou nas 72 horas anteriores.

Quando faz sentido apoiar-se em um parceiro de TI

Manter gestão de problemas funcionando exige três coisas que equipes internas enxutas raramente conseguem sustentar ao mesmo tempo: instrumentação consistente do ambiente, tempo protegido para investigação e repertório técnico acumulado sobre falhas semelhantes em outros ambientes. Esse último ponto é o mais difícil de construir sozinho — uma equipe interna vê apenas o próprio ambiente, enquanto uma operação que atende dezenas de empresas reconhece o padrão de falha na primeira ocorrência.

É exatamente aí que a Duk Informática & Cloud atua. São mais de 18 anos de experiência e mais de 550 empresas atendidas, com uma base histórica de incidentes e erros conhecidos que atravessa ambientes Microsoft 365, infraestrutura on-premises, virtualização, backup e redes corporativas. Como Microsoft Gold Partner, a Duk combina esse repertório operacional com acesso direto aos canais de escalonamento do fabricante quando a causa raiz está no produto, não no ambiente do cliente.

Na prática, isso significa monitoramento que gera dado utilizável em vez de ruído, chamados categorizados de forma consistente desde a abertura, base de erros conhecidos ativa e revisão periódica de tendências com o cliente — com SLA e suporte 24/7 sustentando a camada de incidentes enquanto a camada de problemas trabalha em paralelo. O resultado que importa não é o número de chamados atendidos: é a curva de chamados recorrentes caindo mês a mês, porque as causas estão sendo efetivamente eliminadas em vez de contornadas.

Se a sua operação reconhece o padrão descrito no início deste artigo — o mesmo incidente voltando em intervalos previsíveis, sempre com o mesmo workaround —, o caminho não é contratar mais horas de atendimento. É mudar a pergunta que a TI faz quando o chamado abre.