Confiabilidade e Manutenção · 6 min de leitura
Cybersecurity tem um nome para o conjunto de pontos por onde um ataque pode entrar: superfície de ataque. Confiabilidade não tem equivalente, e essa ausência de vocabulário tem custo. Existe um conjunto de condições na camada de rede que decide, em silêncio, se um ativo confiável vai se comportar de forma confiável em produção. Chamamos isso de superfície de confiabilidade.
Um conceito que a segurança já tem e a confiabilidade não
Quando uma equipe de segurança avalia uma planta, ela pergunta quais portas estão abertas, quais acessos remotos existem, quais ativos estão expostos. O resultado é uma lista que tem dono, prazo e lugar no registro de risco. A superfície de ataque virou um objeto de gestão.
Com confiabilidade, a conversa costuma parar no ativo. O drive tem MTBF conhecido, o CLP tem redundância, o instrumento foi calibrado. Mas o comportamento desses ativos em produção depende de um meio que ninguém lista como risco: a rede que os conecta. Um ativo excelente sobre uma rede com condições degradadas se comporta como um ativo ruim.
A superfície de confiabilidade é o conjunto dessas condições. Não é um equipamento, nem um defeito isolado. É a soma de estados da rede que, sem gerar alarme, determinam se a linha vai rodar o turno inteiro ou parar sem explicação.
Onde ela fica: entre a camada física aprovada e a aplicação
Existe uma camada que quase nenhuma rotina de manutenção enxerga. Abaixo dela está o meio físico, que foi certificado no comissionamento e recebeu um laudo de aprovado. Acima dela estão as aplicações que a operação vê: a IHM, o supervisório, o historiador, o alarme.
Entre as duas fica o comportamento real da rede em operação: quantas vezes o anel reconfigura, quantos frames chegam corrompidos, como o switch trata multicast quando um dispositivo novo entra. O laudo físico não mede isso porque foi feito em outro momento. A aplicação não mostra isso porque, na maior parte do tempo, o protocolo absorve o erro.
É nessa faixa intermediária que a confiabilidade é decidida. E é a única que ninguém mede como rotina. A manutenção cuida do ativo, a TI cuida do servidor, o integrador entregou a rede aprovada e foi embora. O comportamento da rede sob carga real não tem dono.
Três padrões que encontramos em campo
Os padrões abaixo aparecem em plantas diferentes, de setores diferentes. Nenhum deles gera chamado de rede. Todos acabam gerando chamados de equipamento.
- O anel que funciona: reconfigurações MRP ou RSTP acontecem toda semana, abaixo do limiar de alarme, sem ninguém registrar. Até que uma delas cai numa janela crítica do processo e vira um trip inexplicado.
- O segmento Profibus com 20% de erro CRC: a operação se acostumou, o mestre repete os telegramas, a linha segue rodando. O número deixou de ser lido como problema e passou a ser tratado como característica daquele trecho.
- O firmware de switch com bug de IGMP: tudo estável por meses. Uma câmera de inspeção nova entra no anel, o tratamento de multicast falha e o anel colapsa em broadcast storm.
Por que essas condições ficam invisíveis
Os três padrões têm a mesma assinatura: o sistema continua funcionando enquanto a condição existe. Um anel com reconfiguração frequente ainda passa tráfego. Um segmento com CRC alto ainda entrega dados, só que com repetição. Um switch com bug latente de IGMP opera normalmente até que o gatilho apareça.
O protocolo industrial foi feito para ser tolerante, e essa tolerância esconde a degradação. Retries, redundância e reconvergência são mecanismos de proteção. Quando operam o tempo todo, deixam de ser proteção e passam a ser sintoma. Só que ninguém conta quantas vezes eles atuaram.
Quando a falha finalmente aparece, ela aparece no ativo. O drive desarmou, o CLP perdeu comunicação, a câmera travou. O CMMS registra o nome do equipamento, a equipe troca o componente e a condição na rede continua lá, esperando a próxima janela crítica.
Como medir a superfície de confiabilidade
Medir essa superfície é transformar condições silenciosas em números com data. Não exige tecnologia nova. Exige tratar a rede como um ativo com estado próprio, e não como um meio que simplesmente existe.
Na prática, o levantamento que fazemos nas auditorias cobre quatro frentes, sempre com a planta em produção real:
- Contagem e horário das reconfigurações de anel (MRP, RSTP), com identificação da perna que caiu e correlação com o horário de eventos de processo.
- Taxa de erro por segmento e por enlace (CRC, FCS, retries), lida contra um baseline e não contra a sensação de que sempre foi assim.
- Inventário de firmware de cada switch cruzado com bugs conhecidos, com atenção especial a IGMP snooping e convergência.
- Topologia real comparada ao desenho, para confirmar que o anel é de fato um anel e que a raiz do Spanning Tree é quem deveria ser.
Um campo novo no registro de risco
As plantas que reduzem a frequência de paradas são as que têm a superfície de confiabilidade medida, documentada e auditada. Não porque tenham equipamentos melhores, mas porque sabem quais condições da rede estão consumindo margem antes que elas virem parada.
Para a gestão, a mudança é de linguagem antes de ser de orçamento. Enquanto a rede aparece apenas como infraestrutura, ela disputa verba com tudo o que é visível. Quando aparece como uma lista de condições com risco associado, ela passa a ser comparável a qualquer outro item do plano de confiabilidade. O gerente de manutenção consegue explicar por que um trip inexplicado aconteceu, e o diretor consegue decidir se aceita aquele risco ou paga para removê-lo.
Nossa proposta é simples: incluir a superfície de confiabilidade como campo padrão no registro de risco, ao lado da superfície de ataque. Com o mesmo tratamento: inventário, responsável, revisão periódica e plano de ação. O que tem nome entra na pauta. O que entra na pauta recebe orçamento.
Artigo desenvolvido a partir das publicações de Darwin Anastacio Junior no LinkedIn.