---
codigo: DOC-TEL-DIAG-003
tipo: diagnostico
dominio: Telecom
area: Fluxos de Diagnóstico
nivel_tecnico: Intermediário
tempo_medio: 10-15 min
status: validado
---

# Oscilação

> Diagnóstico confiável nasce da sequência: evidência observada, hipótese levantada, teste executado, resultado obtido e conclusão documentada.

## Objetivo do documento

Fornecer um fluxo operacional resumido para investigar Oscilação, evitando troca por tentativa e reduzindo escalonamentos sem evidência.

## Quando aplicar

- quedas intermitentes
- perda de pacote variável
- sinal alternando
- reconexões PPPoE ou rádio

## Pré-requisitos

- identificar cliente, equipamento, porta, placa, sistema ou chamado;
- confirmar o sintoma informado;
- conhecer o estado esperado do serviço ou equipamento;
- separar fato observado de hipótese;
- registrar horário, local e condição do teste.

## Ferramentas / Equipamentos

- multímetro, notebook, celular, fonte de bancada, analisador ou ferramenta de rede conforme o domínio;
- acesso ao equipamento, sistema, logs ou interface de gerência;
- checklist de atendimento ou ordem de serviço;
- câmera para fotos e prints.

## Procedimento prático

1. Registre a evidência inicial sem interpretar ainda.
2. Levante no máximo três hipóteses prováveis.
3. Execute o teste mais simples e menos invasivo primeiro.
4. Compare resultado obtido com valor esperado.
5. Descarte ou confirme a hipótese com base na evidência.
6. Só avance para ação corretiva quando houver causa provável documentada.
7. Valide o resultado após a correção.

## Primeiras verificações

- coletar horário das quedas
- verificar energia e conectores
- analisar logs de desconexão
- confirmar estabilidade física do enlace

## Testes de decisão

- ping prolongado
- consulta de logs
- medição óptica ou RSSI/SNR
- verificação de fonte e PoE

## Evidências obrigatórias

- foto, print, log ou medição do sintoma;
- valores antes e depois da intervenção;
- identificação do equipamento, porta, cabo, placa, cliente ou sistema;
- teste que confirmou ou descartou a hipótese principal;
- validação final;
- motivo de escalonamento, se houver.

## Erros comuns

- avaliar só no momento em que está funcionando
- ignorar fonte ou conector oxidado
- não correlacionar horário e evento
- trocar equipamento sem histórico

## Método RMEvolution de validação

Use a sequência abaixo para transformar sintoma em decisão operacional:

- **Evidência observada:** registre o fato bruto, com print, foto, log ou medição.
- **Hipótese levantada:** descreva a causa provável que será testada.
- **Teste executado:** informe ferramenta, condição do teste e valor esperado.
- **Resultado obtido:** registre o valor medido, resposta do sistema ou comportamento observado.
- **Hipótese descartada ou confirmada:** explique o motivo técnico da decisão.
- **Conclusão operacional:** defina correção, orientação, monitoramento ou escalonamento.
- **Nível de confiança:** use baixo, médio ou alto conforme a qualidade das evidências.

Quando não houver evidência suficiente, não encerre o diagnóstico como confirmado. Registre a pendência e escale com contexto.

## Checklist de validação

- a causa provável foi registrada?
- existe evidência que sustenta a conclusão?
- o teste final reproduz a condição real de uso?
- o cliente, usuário ou operação confirmou o resultado?
- ficou alguma ação preventiva pendente?

## Próximas ações

Se o sintoma persistir, reabra as hipóteses descartadas, colete nova evidência e escale com resumo técnico. Escalonamento sem evidência deve ser evitado.

## Documentos relacionados

- [POP - Diagnóstico Inicial em Campo](../Diagnósticos/POP - Diagnóstico Inicial em Campo.md)
- [POP - Validação Final do Atendimento](../Diagnósticos/POP - Validação Final do Atendimento.md)
- [Registro de Evidências](../Processos/Documentação/03 - Registro de Evidências.md)

## Resumo

Este fluxo ajuda a transformar sintoma em diagnóstico operacional: observar, testar, validar, documentar e decidir com nível de confiança suficiente.