Um chamado, cinco sistemas: como encontrar a causa provável?

O cliente tem uma conexão. O NOC tem cinco sistemas.

Às 15h03, um assinante abre um chamado relatando falta de internet. O ERP mostra contrato ativo; a OLT registra a ONT; o RADIUS mostra tentativa de autenticação; o ACS informa a última sessão de gerenciamento; o monitoramento tem um alerta da interface de agregação. Todas essas informações podem estar corretas e, ainda assim, ninguém conseguir responder ao cliente.

O problema não é a presença de cinco sistemas. É a falta de um caminho confiável entre evidências. Cada tela apresenta uma parte da história, com identificadores, relógios e limitações diferentes. Quando uma equipe precisa reconstruir tudo por prints, cada atendimento começa quase do zero.

O maior risco não é faltar dado. É ligar o dado errado.

Um cadastro de contrato, uma sessão PPPoE, um serial de ONT e uma caixa óptica pertencem a domínios diferentes. O fato de dois sistemas possuírem um campo chamado id_cliente não transforma os valores em uma identidade universal. Integração séria começa com chaves externas, origem, provedor e relações verificadas.

• Assinante e contrato: quem contratou, qual plano, que status comercial possui e quais permissões existem sobre seus dados.
• Serviço e equipamento: qual instância do serviço deve estar associada a determinado dispositivo e como esse vínculo foi comprovado.
• Dispositivo e topologia: OLT, slot, PON, CTO e porta, quando descobertos ou confirmados.
• Sessão de acesso: usuário, NAS/BNG, hora, IP ou prefixo e accounting, sem confundir uma sessão antiga com a atual.
• Incidente e execução: quais alarmes, leituras e ordens de serviço referem-se ao mesmo evento.

Se o vínculo é incerto, marque a relação como não conciliada. É operacionalmente mais seguro exibir uma lacuna do que orientar uma ação no equipamento de outra pessoa.

A ordem dos eventos muda a interpretação

Imagine uma queda registrada pelo RADIUS às 14h58. O coletor informou a ONT online às 15h20, mas o timestamp dessa leitura é 14h40. Uma tela que apresenta ambas as informações como “atuais” sugere contradição; uma linha do tempo revela que o registro de ONT está desatualizado.

Uma IA que resume dados sem verificar essa relação temporal pode produzir respostas convincentes e erradas. Portanto, a camada de evidências deve vir antes do resumo.

O que cada sistema realmente sabe?

A Lógica organiza esses componentes em produtos especializados: ERP, ACS, RADIUS, Flow, Monitoramento e FieldOps. O diagrama conceitual do ecossistema não representa integração automática universal: o funcionamento depende de implantação e testes.

Caso didático: três clientes reclamam da mesma rua

Suponha que três chamados cheguem com sintomas semelhantes dentro de vinte minutos. O primeiro relata intermitência, o segundo lentidão, o terceiro diz estar sem serviço. Um atendimento isolado tende a criar três diagnósticos e possivelmente três visitas independentes.

O exemplo mostra uma metodologia, não métricas ou resultados de clientes da Lógica. É comum precisar adaptar a investigação ao inventário, aos protocolos e aos equipamentos da operação.

Uma IA que recomenda não deve ganhar permissão de executar

A parte mais delicada de um sistema integrado é a transição entre leitura e ação. Uma IA pode resumir sessões, correlacionar horários, organizar histórico e sugerir testes. Mas autorização de usuário, escopo do tenant, validação do alvo e política de mudança precisam existir fora da resposta gerada pelo modelo.

• Consultas e alterações devem respeitar permissões efetivas do operador, não apenas linguagem natural.
• Mudanças em massa precisam de pré-visualização, limites de alcance, aprovação e rollback quando aplicável.
• A identificação do alvo deve ser exata; não execute comandos por similaridade lexical de nomes ou IPs.
• Registre transação, evidências, parâmetros efetivos e resultados; falhas devem aparecer como falhas.
• Dados comerciais, credenciais e informações pessoais devem obedecer às políticas de acesso e retenção.

Um bom sistema não precisa fingir que sabe tudo: declarar “não foi possível concluir” com o motivo é mais útil do que oferecer uma resposta confiante que provoca incidente.

Como começar sem reconstruir sua empresa inteira

Depois dessa prova de conceito, a equipe estará melhor posicionada para decidir quais APIs, eventos e tarefas merecem prioridade.

Oito perguntas que revelam maturidade técnica

• Como o sistema distingue entidades iguais em provedores ou unidades diferentes?
• O que acontece quando RADIUS responde e ACS não responde?
• O status mostrado é do equipamento ou do coletor?
• Qual componente controla permissões para operações de escrita?
• Onde estão logs de execução, origem da evidência e timestamps?
• Há políticas para ações críticas, limites e rollback?
• Qual versão e qual fabricante foram efetivamente homologados?
• Posso demonstrar um caso em que a plataforma não consegue concluir a causa?

Continue aprofundando