A matemática da triagem: como um NOC prioriza incidentes
A priorização de incidentes no NOC não depende de quem grita mais alto, mas da análise cruzada de impacto e urgência. Entenda como aplicar essa matriz no dia a dia da operação de redes e provedores.
Você sabia que a matriz de priorização de incidentes que usamos hoje no NOC foi criada nos anos 80 pelo governo britânico? O CCTA (Central Computer and Telecommunications Agency) desenvolveu as bases do que viria a ser o ITIL para organizar o caos do suporte de TI. A premissa era simples, mas revolucionária: a prioridade de um problema não pode ser definida por quem reclama mais alto, mas pelo cruzamento objetivo entre Impacto e Urgência.
No dia a dia de um provedor ou de uma operação de rede corporativa, essa lógica é o que separa um NOC reativo de um NOC estruturado. Vamos desmontar como essa priorização acontece na prática.
A matriz de Impacto x Urgência
No NOC, todo incidente recebe uma classificação (P1, P2, P3, P4) baseada em duas variáveis:
- Impacto: Quantos usuários, serviços ou fluxos de receita estão afetados?
- Urgência: Quão rápido o negócio precisa que isso seja resolvido para evitar danos maiores?
Um exemplo clássico de operação de provedor: um rompimento de fibra óptica no tronco principal que derruba o acesso de três bairros inteiros. O impacto é altíssimo e a urgência é máxima. Isso é um Incidente Prioridade 1 (P1). Toda a equipe é mobilizada, e a comunicação com os clientes começa imediatamente.
Outro exemplo: uma sessão BGP com um peer de trânsito que está oscilando. Se esse peer carrega apenas 5% do tráfego total da rede e há rotas redundantes, o impacto é baixo. Se for o único peer da rede, o impacto é catastrófico. A urgência muda drasticamente dependendo da topologia.
O perigo do "achismo" e a pressão do SLA
Um dos maiores desafios na operação é alinhar a percepção de urgência do cliente com a realidade técnica da rede. É comum o gerente de TI de um cliente ligar no NOC exigindo um P1 porque um servidor interno parou de responder. Porém, se o problema está no firewall interno do cliente, o impacto na rede de transporte é zero.
O NOC precisa educar e alinhar expectativas. O contrato (SLA) dita o tempo de resposta, mas a matriz de priorização interna do NOC dita quem vai trabalhar nisso e como os recursos serão alocados. Misturar as coisas gera esgotamento da equipe técnica.
Correlação de alertas: a base da triagem
Hoje, não priorizamos olhando para alertas isolados. Um switch core que reinicia pode gerar centenas de alertas de porta down nos equipamentos de acesso. Se o NOC tratar cada alerta como um incidente, a matriz de priorização colapsa.
É aqui que a automação entra. Ferramentas de monitoramento e agentes de IA não servem para resolver sozinhos, mas para correlacionar. O sistema agrupa os alertas de queda de porta em um único incidente de falha de switch core. O impacto é recalculado automaticamente com base na topologia, e a prioridade é elevada antes mesmo de o primeiro cliente ligar para reclamar.
O fechamento prático
Para quem opera redes, a lição é clara: pare de tratar alertas como incidentes. Configure suas ferramentas de monitoramento para agrupar falhas por dependência topológica. Defina com a diretoria e com os clientes o que é, de fato, um P1. Quando você blinda o NOC do ruído, a equipe técnica ganha tempo para focar no que realmente mantém a rede em pé.