Guia de preço · Análise de causa raiz
Quanto custa análise de causa raiz: o que muda o preço no provedor
Quanto custa análise de causa raiz depende menos do tamanho do provedor e mais do que a rede registrou antes da falha: logs, relógios sincronizados, gráficos e histórico de mudanças. Com esses dados guardados, a investigação lê o que já existe; sem eles, precisa recriar a prova em teste, e o preço sobe.
Resumo
- O trabalho tem quatro partes pagas, que são coleta, linha do tempo, hipóteses e testes, e cada uma pode crescer.
- Um Syslog remoto e relógios acertados por NTP encurtam a investigação mais do que qualquer outro fator.
- Falha intermitente, várias camadas da rede envolvidas e fabricante no caso são o que mais alonga o prazo.
- A conta que decide é o preço da análise contra o custo de cada nova repetição da mesma queda.
Quanto custa análise de causa raiz no provedor?
O valor sai de uma proposta feita depois de ver quais dados a rede guardou sobre a falha. Não há tabela oficial nem pesquisa independente de preço para esse serviço, então qualquer número solto na internet descreve o escopo de quem o publicou.
Uma análise de causa raiz custa mais quando a falha atravessa várias partes da rede e quando quase nada foi registrado no momento da queda. Custa menos quando o problema fica num equipamento só e os registros estão inteiros, com horário confiável.
A Táquion Tech faz a análise de causa raiz com o valor fechado antes de começar, depois de olhar o que existe de logs e gráficos do período. Faixa de preço da Táquion Tech para essa investigação: [PREENCHER faixa de preço da Táquion Tech].
Este guia trata só do preço da investigação. Para os modelos de contrato do suporte sênior como um todo, como avulso, banco de horas e mensalidade, veja quanto custa o suporte N3 para provedor.
O que entra no trabalho que você paga
A investigação tem quatro partes, e o preço é a soma do tempo gasto em cada uma. Saber qual delas vai crescer no seu caso é o que permite ler uma proposta.
1 · Coleta
Juntar o que a rede registrou
Logs, alarmes, gráficos de tráfego e CPU, cópias de configuração e o relato de quem atendeu a queda.
2 · Linha do tempo
Pôr tudo no mesmo relógio
Cada evento recebe horário e fonte, do primeiro sinal anormal até a volta completa do serviço.
3 · Hipóteses
Listar as explicações possíveis
Configuração, firmware, energia, link, capacidade e mudança recente entram na lista, sem descartar nenhuma cedo.
4 · Testes
Provar ou derrubar cada uma
O que os registros não resolvem vai para teste em janela ou laboratório, e essa é a parte de prazo mais incerto.
As duas primeiras partes dependem quase só dos dados guardados. As duas últimas crescem quando faltam dados, porque o que não foi registrado precisa ser reproduzido.
Por que o preço depende do que foi guardado antes da falha
Porque a investigação reconstrói o passado, e cada registro que falta vira hora de teste ou de espera pela próxima queda. O mesmo problema pode levar poucas horas de leitura ou semanas de tentativa, conforme o que ficou salvo.
O Syslog é o padrão de mensagens de log dos equipamentos de rede, descrito na RFC 5424. Quando ele fica só na memória do roteador ou da OLT, um reinício apaga exatamente as linhas que explicariam o reinício.
| Registro | Se existe | Se falta |
|---|---|---|
| Syslog remoto | As mensagens dos minutos anteriores à queda estão disponíveis para leitura | O reinício apagou o log local e a sequência de eventos precisa ser deduzida |
| Relógio por NTP | Eventos de equipamentos diferentes se alinham no mesmo minuto | Cada equipamento conta uma hora, e a ordem dos fatos fica em dúvida |
| Gráficos com histórico | Dá para ver se CPU, memória ou tráfego subiam dias antes | Não há como saber se a falha foi súbita ou anunciada |
| Cópia da configuração | A versão de antes e a de depois podem ser comparadas linha a linha | Uma mudança recente vira suspeita sem prova a favor ou contra |
| Registro de mudanças | Fica claro o que foi alterado na semana da falha e por quem | A equipe depende da memória de cada técnico |
| Fluxos de tráfego | Um pico anormal ou um ataque aparece com origem e destino | Ataque e saturação ficam indistinguíveis de defeito |
O fator que mais encarece é o tempo entre a falha e o pedido. Muitos equipamentos guardam pouco histórico local, e quem chama a investigação semanas depois pode descobrir que a prova já foi sobrescrita.
Quanto custa análise de causa raiz feita sem logs?
Costuma custar mais e terminar com menos certeza, porque a causa precisa ser provocada de novo para ser vista. Em falha intermitente, isso pode significar instrumentar a rede e esperar a próxima ocorrência.
Por isso uma das primeiras ações de quase toda análise é passar a guardar logs fora dos equipamentos. O monitoramento de rede contínuo deixa a próxima investigação com dados desde o primeiro dia.
Na prática: o que configurar hoje para a próxima análise sair mais curta
Dois ajustes simples, log remoto e relógio sincronizado, mudam o custo de qualquer investigação futura. O exemplo usa endereços de documentação e precisa ser adaptado à sua rede.
# MikroTik RouterOS v7
/system ntp client set enabled=yes servers=192.0.2.10
/system logging action add name=remoto target=remote remote=192.0.2.20 remote-port=514
/system logging add topics=critical action=remoto
/system logging add topics=error action=remoto
/system logging add topics=warning action=remoto
# Huawei VRP
ntp-service unicast-server 192.0.2.10
info-center enable
info-center loghost 192.0.2.20O servidor que recebe os logs precisa ter disco e retenção combinados com a equipe. Guardar algumas semanas já cobre a maioria dos pedidos de análise feitos logo depois de uma queda.
Fatores que mudam o preço da análise de causa raiz
Além dos dados guardados, pesam a quantidade de camadas da rede envolvidas, a frequência da falha e quem mais precisa participar. A tabela mostra de que lado cada fator empurra o valor.
| Fator | Encurta a análise | Alonga a análise |
|---|---|---|
| Tempo desde a falha | Pedido feito nos primeiros dias, com registros ainda inteiros | Pedido semanas depois, com histórico local já sobrescrito |
| Camadas envolvidas | A falha fica num equipamento, como uma OLT ou um concentrador | A queda cruza rede óptica, concentrador e borda ao mesmo tempo |
| Repetição | A falha volta com hora marcada ou com um gatilho conhecido | Acontece uma vez por mês, sem padrão visível |
| Acesso aos equipamentos | Usuário de leitura próprio para o Especialista | Tudo passa pelo técnico da casa, um comando de cada vez |
| Terceiros | A causa está dentro da rede do provedor | Operadora ou fabricante precisam abrir chamado e devolver dados |
| Entregável | Relatório técnico com causa e ações | Inclui conferência depois das ações e pacote de evidências para fornecedor |
Repare que o número de assinantes não aparece na tabela. Uma rede pequena com uma falha intermitente e sem logs pode exigir mais horas do que uma rede grande com uma falha bem registrada.
Exemplo: duas quedas de concentrador, dois orçamentos
Dois provedores perderam o concentrador PPPoE numa noite de sexta, com o mesmo sintoma. O exemplo é ilustrativo e mostra qual fator decidiu a diferença de escopo.
- Provedor A: logs enviados a um servidor externo, relógios acertados, gráficos de memória de três meses e uma atualização de firmware anotada na semana anterior.
- Provedor B: log só na memória do equipamento, apagado no reinício, horários desencontrados entre os equipamentos e nenhuma anotação de mudança.
No provedor A, a leitura dos gráficos mostrou memória subindo desde a atualização, e a análise fechou com poucas horas de trabalho. No provedor B, foi preciso ativar coleta, esperar a falha voltar e testar versões, e o fator que pesou foi a ausência de registro, não o porte da rede.
Quando a análise mais em conta sai cara?
Sai cara quando termina na causa imediata, sem prova e sem ação com dono, porque a queda volta e a investigação precisa ser paga de novo. O valor menor só vale se o relatório fecha a porta por onde a falha entrou.
Sinais de que a proposta mais em conta vai custar mais depois
- A conclusão prometida é o equipamento travou, sem dizer o que fez ele travar.
- Não há etapa de teste, e hipóteses aparecem no relatório como se fossem causa.
- O fornecedor não pede logs nem gráficos antes de dar o preço.
- As ações recomendadas vêm sem responsável, sem prazo e sem forma de conferir.
- Nada é dito sobre acompanhar a rede depois que as correções forem aplicadas.
- A análise aponta um culpado na equipe em vez de configuração, processo ou equipamento.
Duas marcas ou mais indicam que o trabalho deve parar na superfície. Peça que a proposta descreva cada etapa e o que é entregue ao final dela.
Quer saber o que a sua falha vai exigir?
Na análise de causa raiz da Táquion Tech, um Especialista confere primeiro os registros disponíveis e devolve escopo, prazo e valor fechados antes de começar.
Custos que a investigação puxa depois de aprovada
Alguns custos não estão na investigação, mas surgem por causa dela. Pergunte sobre cada um antes de aprovar, para não ser surpreendido no meio.
- Execução das correções: atualizar firmware, mudar configuração ou trocar peça costuma ser feito pela sua equipe ou cobrado em horas à parte.
- Laboratório: reproduzir um defeito de versão fora da produção soma horas e às vezes exige equipamento emprestado.
- Tempo com fabricante: quando a causa é defeito conhecido, o suporte do fabricante pede dados extras e o prazo passa a depender dele.
- Documento para clientes: a versão escrita para diretoria e clientes empresariais é o relatório pós-incidente, um serviço separado.
- Coleta permanente: o servidor de logs e os gráficos que faltaram viram um custo novo, recorrente, de monitoramento.
Quanto custa não investigar a falha que volta?
Custa uma queda inteira a cada repetição, mais o tempo da equipe e o desgaste com os assinantes. A conta abaixo usa os seus números e compara o preço da análise com o custo acumulado das próximas ocorrências.
- Repetições: conte quantas vezes a mesma falha aconteceu nos últimos seis meses.
- Duração: anote quanto tempo cada ocorrência levou, do primeiro chamado até a volta do serviço.
- Alcance: estime quantos assinantes ficaram sem serviço em cada uma e quantos eram empresariais com contrato.
- Perda por hora: some cancelamentos atribuídos às quedas, descontos devidos a clientes e horas extras da equipe, dividindo pelo total de horas paradas.
- Projeção: multiplique a perda por hora pela duração média e pelas repetições esperadas no próximo semestre.
Se a projeção passa do valor da proposta, a investigação se paga antes de a falha voltar mais uma vez. A calculadora de custo da queda ajuda a fazer essa conta em reais.
Uma OLT que reinicia de tempos em tempos é o exemplo clássico de custo que se repete sem aparecer na planilha; o guia sobre OLT reiniciando sozinha mostra as causas que costumam estar por trás.
Como escolher entre propostas de análise de causa raiz
Mande a mesma descrição da falha a todos os fornecedores e compare método, entregável e conferência, não só o valor. Proposta que não pergunta pelos dados guardados não tem como saber quanto trabalho vai dar.
O que confirmar em cada proposta antes de aprovar
- Quais métodos serão usados, como cinco porquês, diagrama de Ishikawa ou linha do tempo com evidência.
- Que tipo de acesso o Especialista precisa e se ele é só de leitura nas primeiras etapas.
- Se testes em produção acontecem apenas em janela aprovada por você.
- O que acontece se a causa não for provada no prazo previsto.
- Se o relatório separa causa provada de hipótese ainda aberta.
- Por quanto tempo a rede é acompanhada depois que as ações forem aplicadas.
Uma proposta que responde a todos os itens por escrito é comparável com outra. Se faltam três ou mais, o preço baixo pode estar vindo de etapas que não serão feitas.
A separação entre restaurar o serviço e remover a causa é a mesma da gestão de problemas do ITIL [CONFIRMAR na norma]. O guia de gestão de problemas no NOC mostra como levar essa disciplina para a rotina da equipe.
Erros comuns ao pedir a análise
Os erros que mais encarecem acontecem antes de a proposta chegar. Quase todos têm a ver com dados que se perdem ou com informação que não foi passada.
Evite ao pedir uma análise de causa raiz
- Esperar a terceira queda: cada semana de espera é histórico local sendo sobrescrito nos equipamentos.
- Reiniciar sem copiar nada: salve a saída dos comandos de diagnóstico e o log antes do reboot.
- Omitir a mudança da véspera: a alteração feita pela própria equipe é uma hipótese como qualquer outra.
- Pedir preço por telefone: sem ver os registros, o fornecedor só consegue estimar ou se proteger com margem.
Perguntas frequentes
A análise de causa raiz é cobrada por hora ou por valor fechado?
Os dois formatos existem no mercado. O valor fechado depende de o fornecedor ver os registros antes, e a cobrança por hora deixa com você o risco de a falha ser difícil de reproduzir.
Dá para usar horas do contrato de suporte para pagar a análise?
Em muitos casos, sim, quando o provedor já tem banco de horas ou contrato de suporte sênior. Confirme na proposta se a investigação consome horas ou se é tratada como serviço separado.
Quanto tempo depois da queda ainda vale pedir a investigação?
Quanto antes, melhor para o preço, porque o histórico local dos equipamentos é curto. Se os logs foram enviados a um servidor externo, ainda dá para investigar semanas depois.
A análise inclui corrigir o problema encontrado?
Normalmente não: ela entrega a causa provada e as ações, cada uma com dono e prazo. A execução fica com a equipe do provedor ou entra como trabalho à parte.
Meu provedor é pequeno; a investigação sai mais em conta?
Não necessariamente, porque o porte pesa menos do que os registros disponíveis e a repetição da falha. Uma rede pequena sem logs pode dar mais trabalho do que uma grande bem registrada.
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, como cinco porquês e diagrama de Ishikawa
- RFC 5424, The Syslog Protocol (IETF): padrão das mensagens de log enviadas pelos equipamentos a um servidor externo
- RFC 5905, Network Time Protocol Version 4 (IETF): protocolo que mantém o relógio dos equipamentos sincronizado, base da linha do tempo da investigação
