Guia explicativo · Análise de causa raiz
Como funciona análise de causa raiz: etapas e entregas para provedores
Como funciona análise de causa raiz: o provedor preserva os registros da falha, libera um acesso de leitura e conta o que aconteceu; o Especialista monta a linha do tempo, testa as explicações e entrega a causa provada com as ações. A investigação só fecha depois que as correções rodam por um período e a falha não volta.
Resumo
- A primeira etapa acontece antes de qualquer contrato, que é copiar logs e saídas de diagnóstico antes que um reinício apague a prova.
- O caminho do dado vai do equipamento a um coletor externo e dali para uma linha do tempo com um só relógio.
- Hipóteses e testes costumam ser a etapa mais longa, e nenhum teste em produção acontece sem janela aprovada pelo provedor.
- No fim chegam relatório técnico, pacote de evidências e ações com dono, e o caso fecha só depois da conferência.
Como funciona análise de causa raiz, do pedido ao fechamento
A análise de causa raiz funciona em sete etapas, que começam com a preservação dos registros e terminam com a conferência das ações. As primeiras só leem dados; mexer na rede fica para o fim, sempre em janela.
Análise de causa raiz é uma investigação feita depois que o serviço voltou, para descobrir o que permitiu a falha e não só o que a disparou. Ela não substitui o atendimento da queda: primeiro a rede volta, depois alguém olha com calma para o que ficou registrado.
A Táquion Tech faz a análise de causa raiz remotamente para provedores de todo o Brasil, com acesso de leitura aos equipamentos envolvidos e sem alterar a produção nas etapas de leitura. A ordem das etapas é a mesma em qualquer falha, seja na borda, na OLT ou no concentrador.
1 · Equipamento
O evento vira linha de log
Roteador, OLT ou concentrador gera mensagem, alarme ou contador no instante da falha, com o horário do próprio relógio.
2 · Coletor
A linha sai do equipamento
Syslog remoto, gráficos de SNMP e registros de fluxo guardam o evento fora da memória local, onde o reinício não alcança.
3 · Exportação
O período vai para o Especialista
O provedor exporta as horas em volta da falha, ou libera leitura ao coletor, sem entregar a senha de administrador.
4 · Linha do tempo
Fontes alinhadas no mesmo minuto
Cada evento entra com horário corrigido e origem anotada, e a ordem real dos fatos fica visível.
5 · Relatório
A evidência acompanha a conclusão
O trecho de log ou o gráfico que prova cada afirmação vai anexado, junto com o comando que o gerou.
Quando o registro para na etapa 1, a investigação precisa recriar a prova em teste.
A tecnologia que sustenta a investigação
Nenhuma ferramenta acha a causa sozinha, mas cada uma responde uma pergunta diferente sobre a falha.
- Syslog: as mensagens de cada equipamento, como sessão que caiu, porta que oscilou ou processo que reiniciou.
- NTP: o protocolo que acerta os relógios, sem o qual dois logs de equipamentos diferentes não se comparam.
- SNMP e telemetria: os gráficos de tráfego, CPU, memória, temperatura e potência óptica ao longo dos dias.
- NetFlow e IPFIX: os fluxos de tráfego, que separam um pico legítimo de um ataque ou de um loop.
- Cópias de configuração: versões guardadas que permitem comparar a rede de antes com a de depois da falha.
Quando o provedor não tem uma dessas fontes, a etapa correspondente fica mais lenta, mas não impossível. O guia de monitoramento de rede mostra como montar a coleta que a próxima investigação vai usar.
Etapas da análise de causa raiz e o peso de cada uma no prazo
São sete etapas, e a mais longa costuma ser a de hipóteses e testes, porque é a única que pode depender de a falha acontecer de novo. O prazo exato de cada uma depende dos registros disponíveis e vai escrito na proposta.
| Etapa | O que acontece | Peso no prazo | O que o provedor faz |
|---|---|---|---|
| 1. Preservação | Cópia de logs e configuração antes de qualquer reinício | Minutos, durante a própria queda | Executa os comandos de cópia |
| 2. Abertura | Descrição da falha, escopo e acesso de leitura | Curta | Cria o usuário e indica um contato |
| 3. Coleta e entrevista | Exportação do período e conversa com quem atendeu | Curta a média | Exporta os dados e reserva a equipe |
| 4. Linha do tempo | Eventos alinhados minuto a minuto, com a fonte | Média | Esclarece mudanças e horários |
| 5. Hipóteses e testes | Explicações confrontadas com os dados e testadas | A mais longa e incerta | Aprova as janelas de teste |
| 6. Leitura do relatório | Reunião com causa, provas e ações | Curta | Leva quem vai executar as ações |
| 7. Conferência | Acompanhamento depois das correções | Período combinado no calendário | Aplica as ações e avisa se a falha voltar |
A conferência é medida no calendário: só termina quando passa um intervalo maior do que o costume de repetição da falha. Prazo típico de cada etapa na Táquion Tech: [PREENCHER prazos por etapa].
Primeiras horas: preservar a prova antes do reinício
A etapa mais curta é também a que mais decide o resultado, porque muitos equipamentos guardam o log só na memória. Se der para copiar o que está lá antes do reboot, a investigação já começa com metade da prova.
# MikroTik RouterOS v7: grava log e configuração em arquivo antes do reboot
/log print file=falha-log
/system resource print
/interface print stats
/routing bgp session print
/export file=falha-config
# Huawei VRP: salve a saída de cada comando num arquivo do seu computador
display logbuffer
display trapbuffer
display cpu-usage
display memory-usage
display interface brief
display bgp peer
display current-configurationEsses comandos só leem. Durante a queda, trazer o serviço de volta vem primeiro, e o roteiro de o que fazer quando a rede do provedor caiu mostra onde encaixar essa cópia sem atrasar a volta.
Coleta e entrevista com quem atendeu a queda
A coleta junta os arquivos; a entrevista recupera o que não está em arquivo nenhum, como o comando digitado às pressas ou o cabo trocado no POP. Ela acontece logo no começo, enquanto a memória da equipe está fresca.
- O que cada um viu primeiro: o alarme, o chamado de assinante ou o gráfico que chamou a atenção.
- O que cada um fez: comandos, reinícios e trocas, na ordem em que aconteceram.
- O que mudou antes: manutenção, firmware, link novo, obra no prédio ou ajuste de energia nos dias anteriores.
A conversa não procura culpado. Quem teme ser acusado esconde justamente o detalhe que fecharia o caso.
O que o provedor prepara antes de a investigação começar?
O provedor prepara acesso, registros e pessoas, e quanto mais disso estiver pronto no primeiro dia, mais cedo a linha do tempo fica de pé. A lista abaixo serve também para descobrir o que falta na sua rede.
Marque o que já está pronto antes de abrir a investigação
- Um usuário só de leitura nos equipamentos envolvidos, separado da senha de administrador.
- Um diagrama da rede, mesmo simples, mostrando por onde passa o tráfego da área afetada.
- Os números de chamado já abertos com operadora ou fabricante sobre a mesma falha.
- A lista de alterações feitas nas duas semanas anteriores, inclusive as da própria equipe.
- Uma pessoa da casa com tempo reservado para responder dúvidas durante a coleta.
- Uma janela de manutenção pré-aprovada para o caso de algum teste em produção.
Quatro marcas ou mais deixam a coleta pronta logo depois da abertura. Com menos de três, a primeira tarefa vira montar o que falta.
O que não precisa vir pronto é o diagnóstico. A suspeita do provedor entra na lista de hipóteses como as outras, sem preferência.
Tem uma falha que volta e os registros ainda estão no equipamento?
Na análise de causa raiz da Táquion Tech, um Especialista orienta a cópia dos registros, monta a linha do tempo e entrega a causa com as provas anexadas.
O que o provedor recebe quando a análise termina
O provedor recebe quatro entregas: o relatório técnico, o pacote de evidências, a lista de ações e os alertas recomendados. O caso é encerrado depois da conferência, com uma nota final dizendo se a falha voltou ou não.
- Relatório técnico: resumo da falha, linha do tempo, hipóteses descartadas com o motivo, causa e grau de certeza.
- Pacote de evidências: trechos de log, gráficos e saídas de comando que sustentam cada conclusão, prontos para fabricante ou operadora.
- Lista de ações: cada correção com responsável, data e a forma de conferir que ela funcionou.
- Alertas recomendados: o que monitorar para perceber a mesma condição antes que ela vire queda de novo.
O relatório técnico é escrito para quem opera a rede. Quando a diretoria ou um cliente empresarial precisa da história contada em outra linguagem, essa versão é o relatório pós-incidente, que usa a causa encontrada aqui.
A análise não inclui a execução das correções, que fica com a sua equipe ou entra como trabalho à parte. Para entender como isso aparece numa proposta, veja quanto custa uma análise de causa raiz.
Toda análise termina com a causa provada?
Nem toda investigação termina com certeza total, e o relatório diz isso com todas as letras, para que uma suspeita não seja tratada como fato.
| Grau | O que significa | O que acontece depois |
|---|---|---|
| Provada | Os dados mostram a condição e o teste reproduziu a falha | As ações atacam a causa e a conferência confirma o resultado |
| Provável | Os dados apontam numa direção, mas não houve como reproduzir | As ações seguem, com coleta extra para confirmar na próxima ocorrência |
| Em aberto | Faltam registros para escolher entre duas ou mais explicações | A rede é instrumentada e a investigação continua quando a falha voltar |
Erros em cada etapa e como perceber que algo saiu do trilho
Cada etapa tem um erro típico, e quase todos dão sinal antes do relatório final. Perceber cedo permite corrigir o rumo sem recomeçar a investigação.
| Etapa | O que dá errado | Como se percebe |
|---|---|---|
| Preservação | O equipamento foi reiniciado antes da cópia | O log começa no horário do boot, sem nada da falha |
| Coleta | Relógios desencontrados entre equipamentos | A queda da sessão aparece antes do alarme que a provocou |
| Entrevista | Uma alteração feita na véspera fica de fora do relato | A configuração atual difere da última cópia e ninguém explica por quê |
| Linha do tempo | Buraco sem registro justo no minuto que importa | Gráficos com intervalo de coleta longo demais, que achatam o pico |
| Hipóteses | Uma suspeita é aceita sem teste | O relatório parcial traz causa sem evidência anexada |
| Conferência | As ações não foram aplicadas por completo | A falha volta e a lista de ações ainda tem itens abertos |
O sinal mais fácil de ver é o relógio. Se o mesmo evento aparece com horários diferentes em dois equipamentos, a primeira correção é o NTP, e a análise só avança depois disso.
Exemplo: como funciona análise de causa raiz numa sessão BGP que caía de madrugada
O caso é ilustrativo e percorre as etapas numa falha comum de borda, do primeiro pedido ao fechamento. O detalhe que resolveu estava fora do roteador.
Um provedor perdia a sessão BGP com uma das operadoras por volta das 3h, três vezes no mesmo mês. O tráfego ia para o outro link e voltava sozinho minutos depois, mas os assinantes que jogam online reclamavam toda vez.
- Preservação: na terceira queda, o técnico copiou o log e as interfaces antes de mexer em qualquer coisa e notou erros de CRC subindo na porta da operadora.
- Abertura e coleta: o Especialista recebeu acesso de leitura, os gráficos de três meses e os chamados abertos com a operadora, que dizia não ver nada do lado dela.
- Linha do tempo: com os relógios conferidos, ficou claro que os erros na porta começavam cerca de uma hora antes da queda da sessão, sempre depois das 2h.
- Hipóteses e testes: link saturado foi descartado porque o tráfego era baixo no horário, e a leitura do transceptor mostrou a temperatura subindo junto com os erros.
- Causa: o ar-condicionado do POP tinha um temporizador de economia que o desligava às 2h, e o transceptor perto do limite térmico passava a errar até a sessão cair.
- Ações e conferência: temporizador removido, transceptor trocado, alerta de temperatura criado e acompanhamento por um período maior que o intervalo entre as quedas.
A leitura de potência e temperatura do transceptor, chamada DOM (monitoramento digital do óptico), costuma ficar fora dos gráficos e foi o que ligou a borda ao ar-condicionado.
Quedas de sessão com outras causas, como limite de prefixos ou filtro errado, seguem o mesmo método. O guia sobre BGP caindo no provedor lista os sintomas de cada uma.
Perguntas frequentes
A rede precisa ficar parada durante a análise de causa raiz?
Não. As etapas de coleta, entrevista e linha do tempo só leem dados, com a rede funcionando normalmente. Testes que exigem mudança acontecem em janela aprovada pelo provedor, com reversão preparada.
Quem da minha equipe precisa participar da investigação?
Quem atendeu a queda participa da entrevista, e um técnico da casa acompanha a coleta para responder dúvidas. Na leitura do relatório, vale levar quem vai executar as ações, para que nenhuma fique sem dono.
O que acontece se a causa não for encontrada?
O relatório diz isso com clareza, separa o que foi descartado do que continua possível e aponta quais registros faltaram. A rede passa a coletar esses dados, e a investigação é retomada quando a falha voltar.
Dá para começar a investigação com a queda ainda acontecendo?
A investigação começa depois que o serviço volta, porque restaurar vem primeiro. Durante a queda, o que se faz é copiar logs e saídas de diagnóstico, e o atendimento da parada fica com o suporte emergencial.
Os registros da minha rede ficam com a Táquion Tech depois da análise?
Os registros pertencem ao provedor e são usados só na investigação. O que fica guardado depois do encerramento, e por quanto tempo, segue o combinado na proposta [CONFIRMAR política de retenção de dados].
Responsável técnico da Táquion Tech · Registro profissional [PREENCHER]
Mais de 15 anos em operações de rede, com gestão de infraestruturas de TI, administração de data centers e condução de equipes em migrações de TI e telecomunicações, com foco em alta disponibilidade e segurança.
A Táquion Tech é uma empresa de engenharia de redes de Balneário Camboriú (SC) que projeta, opera e dá suporte a redes de provedores de internet e de empresas.
Fontes
- Root cause analysis (Wikipédia em inglês): definição de análise de causa raiz e dos métodos usados para chegar da falha à causa
- RFC 5905, Network Time Protocol Version 4 (IETF): protocolo que sincroniza os relógios dos equipamentos, base para alinhar a linha do tempo
- RFC 7011, IPFIX Protocol Specification (IETF): padrão de exportação de fluxos de tráfego usado para separar pico legítimo, ataque e loop
