Análise de impacto de falha na rede óptica: por que mapear importa

Uma máquina de terraplanagem corta um cabo troncal às sete da manhã, e em cinco minutos o telefone da central começa a tocar sem parar. O atendente sabe que "tem gente sem internet", mas não sabe se são 15 clientes de uma rua ou 800 clientes de três bairros inteiros — e essa diferença muda tudo: quantas pessoas mobilizar, o que informar no grupo de WhatsApp da equipe, e o que dizer pro cliente que liga puto perguntando quando volta. Reagir a uma falha de rede sem saber o tamanho real do estrago é operar no escuro justamente no momento em que mais precisa de clareza.

O que muda quando você sabe o impacto antes de sair de carro

Analisar o impacto de uma falha significa cruzar o ponto exato da rede que caiu com a topologia documentada — quais splitters, quais CTOs e, por consequência, quais clientes dependem daquele trecho específico. Com essa informação em mãos assim que o alarme dispara, a equipe sabe se está lidando com um incidente pontual (uma CTO, um punhado de clientes) ou um evento de grande escala (um troncal que alimenta várias CTOs e centenas de casas). Essa diferença determina se a resposta é uma equipe só ou um mutirão, e se vale a pena mandar aviso proativo em massa antes que o volume de ligações trave a central de atendimento.

Os elementos que entram na análise de impacto

• Ponto de falha: onde exatamente na rede o rompimento ou a queda de sinal ocorreu — troncal, distribuição secundária ou drop individual.
• Árvore de dependência: quais splitters e CTOs estão a jusante daquele ponto, ou seja, dependem dele pra receber sinal.
• Contagem de clientes ativos: quantos clientes reais (não só portas ocupadas) estão ligados a cada CTO afetada.
• Redundância existente: se existe rota alternativa ou anel que pode reduzir o número de clientes realmente impactados, mesmo com o rompimento.
• Severidade por região: se a falha atinge concentração residencial, comercial ou um cliente corporativo com SLA mais rígido, o que muda a ordem de prioridade do atendimento.

Passo a passo de resposta usando análise de impacto

1. Identifique o ponto exato da rede onde o alarme ou a reclamação indica a falha.

2. Consulte a topologia documentada pra ver o que está a jusante daquele ponto — quais CTOs e quantos clientes dependem dele.

3. Classifique a severidade: poucos clientes de um trecho isolado, ou volume grande espalhado por vários bairros.

4. Priorize o despacho da equipe de acordo com o volume de clientes afetados e a presença de cliente corporativo ou com SLA.

5. Dispare comunicado proativo (SMS, WhatsApp ou aviso no portal do cliente) para os afetados, evitando volume de ligação simultânea na central.

6. Registre o incidente com o número real de clientes impactados, pra alimentar o histórico e melhorar a resposta na próxima falha parecida.

Por que a contagem de clientes muda a prioridade da equipe

Duas falhas podem parecer tecnicamente parecidas — mesmo tipo de rompimento, mesma distância até o ponto — e ainda assim ter urgência completamente diferente. Um rompimento numa CTO de 8 portas com 5 clientes ativos é bem menos urgente do que um rompimento num troncal que alimenta seis CTOs de 32 portas quase lotadas. Sem essa contagem automática, a tendência natural é despachar equipe pela ordem de chegada da reclamação — o que às vezes significa atender primeiro um caso pequeno só porque o cliente ligou primeiro, enquanto um bairro inteiro sem sinal ainda nem gerou volume de ligação suficiente pra central perceber a escala real do problema.

Redundância: quando o impacto real é menor do que parece

Nem toda falha visível na rede se traduz em cliente sem sinal. Se o trecho rompido tem uma rota alternativa configurada — um anel de fibra entre dois pontos de distribuição, por exemplo — o sistema pode reencaminhar o tráfego automaticamente e o impacto real fica restrito a uma janela curta de instabilidade, não a uma interrupção total. É por isso que a análise de impacto precisa considerar a topologia completa, não só o ponto isolado da falha: sem enxergar a redundância existente, a equipe pode tratar como emergência algo que o próprio desenho da rede já absorveu parcialmente.

Mito: "se o NOC não recebeu alarme, não caiu nada"

Monitoramento de enlace detecta queda de porta ou de interface, mas nem sempre captura degradação parcial — um cabo com fusão comprometida por causa da máquina que passou perto, sem cortar de vez, pode gerar perda de sinal intermitente que não dispara alarme de queda total. Nesses casos, a reclamação do cliente chega antes do alarme técnico, e a análise de impacto precisa funcionar também a partir da reclamação, não só do monitoramento automático — cruzando endereço do cliente que reclamou com a topologia pra descobrir se existe um padrão geográfico por trás de queixas aparentemente isoladas.

O custo de não ter essa análise disponível

Provedor que responde a falha sem saber a extensão real do impacto tende a subdimensionar ou superdimensionar a resposta com a mesma frequência: manda uma equipe só pra um problema que precisava de três, ou mobiliza a operação inteira pra um problema que era pontual. Os dois erros custam caro — o primeiro em tempo de reparo e insatisfação do cliente, o segundo em recurso mal alocado que podia estar atendendo outra demanda. Interrupções de grande escala também entram no radar regulatório: a continuidade do serviço faz parte das obrigações de qualidade que a Anatel fiscaliza junto às prestadoras de SCM, disponíveis para consulta no portal da agência, então documentar a extensão real de cada incidente ajuda inclusive a sustentar um histórico de resposta consistente caso o volume de interrupções vire objeto de fiscalização.

Antes do próximo rompimento de troncal

Quando um ponto da rede cai, o tempo que a equipe leva pra entender quantos clientes foram afetados é o que separa uma resposta organizada de uma manhã de caos na central de atendimento. O ZISP calcula automaticamente, a partir do mapa de rede documentado, o que aconteceria — e quem seria afetado — se um ponto específico da fibra falhasse, antes mesmo de a equipe sair pra campo. Veja como funciona em sistema.zisp.com.br.