Agentes de monitoramento de SLA em provedores de internet devem relacionar eventos da rede, contratos e chamados para indicar qual incidente precisa de atenção e quem deve assumir a próxima ação. A IA pode resumir evidências e sugerir uma classificação. O cálculo de prazo, a mudança de responsável e o registro do escalonamento precisam de regras verificáveis.
Comece por um fluxo pequeno: detectar um evento, confirmar o serviço afetado, localizar a regra contratual aplicável, abrir ou atualizar o incidente e cobrar uma confirmação de atendimento. Um alerta enviado sem dono, prazo e acompanhamento de estado ainda deixa o NOC, o centro de operações de rede, dependente de acompanhamento manual.
Resumo rápido
- Separe alerta técnico, incidente operacional e chamado do cliente.
- Calcule o SLA a partir da versão correta do contrato e do calendário aplicável.
- Escalone por impacto, prazo restante e ausência de reconhecimento.
- Use IA para organizar contexto, mantendo decisões críticas sob controle humano.
- Registre transições, notificações e evidências para reconstruir cada atendimento.
1. Defina o que o agente realmente acompanha
Um equipamento pode produzir vários alertas durante a mesma indisponibilidade. Ao mesmo tempo, clientes diferentes podem abrir chamados sobre esse evento. Tratar cada mensagem como um incidente independente aumenta o ruído e dificulta entender o impacto. Crie uma ligação explícita entre evento técnico, incidente principal, serviços afetados e chamados associados.
O Alertmanager documenta agrupamento, deduplicação e roteamento de alertas, além de silenciamento e inibição. Esses mecanismos ajudam a organizar notificações, mas não substituem o inventário do provedor nem a interpretação de um contrato. O agente precisa consultar identificadores de circuito, ponto de presença e cliente, com permissões compatíveis com sua função.
Defina um identificador estável para cada incidente e preserve a origem de cada evidência. Uma mensagem do monitoramento deve carregar horário de observação, recurso afetado, tipo de verificação e referência ao evento original. A descrição produzida por IA pode mudar; o registro original deve continuar disponível para conferência.
Para o atendimento, diferencie indisponibilidade confirmada, degradação observada e relato ainda sem confirmação técnica. Essa distinção ajuda a explicar o que se sabe sem apresentar hipótese como diagnóstico. O roteiro de agentes de suporte com recuperação de contexto em logs complementa essa organização das evidências.
2. Transforme o contrato em regras de prazo auditáveis
SLA é o acordo de nível de serviço. Na operação, ele precisa virar uma regra que informe o que será medido, quando começa a contagem, quando pode haver pausa e qual evento encerra o relógio. Não use um prazo genérico para todos os clientes apenas porque compartilham a mesma infraestrutura.
Mantenha uma tabela de políticas com identificador, versão, vigência, serviço, calendário e responsáveis pela aprovação. Separe primeira resposta, atualização de comunicação e restabelecimento quando o acordo tratar essas obrigações de forma diferente. Um chamado respondido pode continuar com o serviço indisponível; marcar o primeiro compromisso como atendido não deve encerrar os demais.
As condições de pausa merecem atenção especial. O estado “aguardando cliente” não deve interromper automaticamente qualquer contagem. Aplique a pausa apenas quando houver previsão na política aplicável, motivo registrado e evidência suficiente. Guarde tanto o tempo corrido quanto o tempo considerado no cálculo para permitir revisão posterior.
Use horários com fuso definido e preserve o instante original de cada evento. Eventos recebidos com atraso não devem deslocar silenciosamente o início de um incidente. Quando houver divergência entre monitoramento e relato do cliente, mantenha ambos e peça uma decisão documentada sobre o marco contratual. Essa arquitetura organiza o acompanhamento; não permite prometer conformidade regulatória ou contratual por si só.
3. Modele os estados e a matriz de escalonamento
Uma máquina de estados define quais mudanças são permitidas e o que precisa ocorrer em cada etapa. O agente pode sugerir a transição, mas o sistema deve validar requisitos como existência de responsável, confirmação de recebimento e vínculo com o incidente. Evite um campo de status livre que cada integração interpreta de uma maneira.
| Estado | Evidência necessária | Próxima ação |
|---|---|---|
| Detectado | Evento e serviço identificados | Correlacionar e iniciar triagem |
| Em triagem | Impacto em verificação | Confirmar criticidade e responsável |
| Reconhecido | Pessoa ou equipe aceitou a tarefa | Acompanhar diagnóstico e prazo |
| Em tratamento | Ação técnica registrada | Atualizar situação e avaliar escalonamento |
| Restabelecido | Verificação de recuperação | Observar estabilidade e confirmar comunicação |
| Encerrado | Critérios de fechamento atendidos | Consolidar histórico e pendências |
Monte uma matriz que combine impacto no serviço, abrangência, risco conhecido e prazo restante. A classificação crítica deve ter critérios escritos. Uma conta comercial relevante não é automaticamente equivalente a um incidente de rede com grande abrangência; a matriz deve explicar como resolver esse tipo de conflito.
A documentação do Zabbix apresenta escalonamentos organizados em etapas. Use esse conceito para desenhar a política local: notificar a equipe de plantão, aguardar reconhecimento pelo intervalo definido e acionar a próxima responsabilidade quando a condição persistir. Os intervalos devem ser escolhidos pelo provedor, considerando seus compromissos e sua capacidade de resposta.
Diferencie entrega de mensagem e reconhecimento operacional. O serviço de comunicação aceitar uma notificação não prova que alguém assumiu o incidente. Registre confirmação explícita, substituto de plantão e caminho alternativo quando o canal principal estiver indisponível.
4. Integre a IA sem entregar o controle da rede
Uma arquitetura prática separa coleta, correlação, cálculo de prazo, resumo e execução. O componente de IA recebe um conjunto delimitado de fatos e produz um resumo com campos previstos: impacto observado, evidências, dúvidas e sugestão de encaminhamento. Ele não precisa de credenciais para alterar equipamentos ou modificar contratos.
Se o provedor usar um modelo da Google para redigir resumos, o catálogo de integrações do Google Gemini ajuda a organizar essa camada. A escolha do fornecedor deve considerar os dados enviados e o processo de aprovação. Remova informações pessoais que não sejam necessárias ao diagnóstico e evite incluir segredos presentes nos logs.
Implemente uma chave de idempotência por incidente, etapa e destinatário. Assim, a repetição de um evento pode atualizar o histórico sem disparar o mesmo escalonamento novamente. Para mensagens atrasadas ou recebidas fora da sequência, a orientação sobre reconciliação de webhooks fora de ordem oferece um ponto de partida.
Também defina o comportamento de falha. Se a IA estiver indisponível, o cálculo de prazo e o acionamento devem continuar com mensagens padronizadas. Se o sistema de chamados cair, preserve a fila de eventos e use o procedimento alternativo aprovado. Uma automação de suporte não pode depender de um único resumo para manter um incidente visível.
O capítulo de gestão de incidentes do Google SRE descreve responsabilidades distintas de coordenação, operação e comunicação. Adapte essa separação ao tamanho do ISP: uma pessoa pode acumular funções, desde que o registro mostre quem decide a intervenção e quem informa os envolvidos.
Exemplo: provedor regional em Campina Grande
Considere um exemplo explicitamente ilustrativo: um ISP de Campina Grande identifica perda de conectividade em um ponto de presença. Clientes residenciais e uma empresa com circuito dedicado abrem chamados. Não há aqui resultado observado nem promessa de redução de tempo; o caso serve para mostrar as decisões do fluxo.
O coletor registra os alertas de equipamentos e a triagem verifica se compartilham uma dependência. O agente sugere associá-los a um incidente principal, preservando os chamados individuais. Um técnico confirma a associação antes de aplicar uma comunicação comum, porque nem todo cliente da região necessariamente está afetado.
O motor de regras consulta o contrato do circuito dedicado e a política dos outros serviços. Cada compromisso fica associado ao seu relógio. O coordenador enxerga o incidente agregado e os prazos por serviço, evitando concluir que a recuperação de um equipamento resolveu todas as obrigações.
Na sequência, a equipe de plantão recebe uma mensagem com identificação do incidente, impacto confirmado, último teste e ação solicitada. Se não houver reconhecimento no intervalo da política, o sistema aciona o substituto. A IA prepara uma atualização dizendo o que foi confirmado e o que segue em apuração, sem inventar previsão de retorno.
Depois da intervenção, o monitoramento registra recuperação. O técnico valida os serviços pertinentes e registra a evidência usada para marcar restabelecimento. O atendimento verifica comunicações pendentes. Caso um circuito continue falhando, ele permanece aberto como ocorrência vinculada, com responsável e relógio próprios.
6. Teste o fluxo e acompanhe os resultados
Antes de liberar ações, rode o agente em modo de observação. Ele calcula prioridades e propõe mensagens, enquanto a equipe compara as sugestões com decisões humanas. Inclua incidentes simples, perda de comunicação com o próprio monitoramento, manutenção programada, erro de inventário e recuperação intermitente.
Simule reconhecimento seguido de troca de turno, notificação rejeitada e evento de recuperação recebido antes do evento de abertura. Confira se o sistema preserva evidências e evita encerramento indevido. O teste termina quando a pessoa de plantão consegue assumir a ocorrência usando apenas o contexto apresentado.
Acompanhe tempo até reconhecimento, tempo até restabelecimento e quantidade de escalonamentos sem resposta, com definições documentadas. A Atlassian explica que métricas de incidentes exigem atenção ao significado de cada intervalo. Para este projeto, apresente também a distribuição dos casos e o volume analisado, sem transformar uma média isolada em promessa comercial.
Faça uma revisão periódica dos incidentes classificados incorretamente e dos alertas que ninguém considerou úteis. Atualize regras e inventário antes de ajustar o texto do modelo. Muitas falhas atribuídas à IA começam em contratos desatualizados, vínculos ausentes ou listas de plantão que não correspondem à operação.
Erros comuns
Escalonar todos os alertas como críticos torna a fila menos informativa. Exigir diagnóstico completo antes de avisar o plantão também atrasa a resposta. Use uma triagem mínima para acionar quem pode verificar o impacto e registre a incerteza existente naquele momento.
Outro erro é deixar o modelo interpretar sozinho cláusulas e calcular prazos em linguagem natural. Faça a aprovação das regras fora do incidente e aplique cálculos determinísticos. Não aceite encerramento automático baseado apenas em uma frase do cliente ou em um único sinal de recuperação.
Por fim, evite automações sem trilha de decisão. Guarde a regra aplicada, a versão do resumo, o destinatário, a confirmação e o motivo de cada mudança. Isso permite corrigir o fluxo e explicar o atendimento sem depender da memória de quem estava no turno.
Perguntas frequentes
O agente pode substituir o plantonista?
O desenho proposto mantém o plantonista como responsável técnico. O agente organiza evidências, acompanha prazos e cobra reconhecimento. Intervenções com impacto na rede exigem o procedimento e a autorização definidos pelo provedor.
O SLA começa na abertura do chamado?
Depende da regra aplicável ao serviço. Cadastre o marco aprovado e registre as evidências que o sustentam. Não escolha automaticamente o horário mais conveniente quando existirem eventos anteriores relevantes.
É possível começar sem IA generativa?
Sim. Correlação básica, relógios e escalonamentos podem funcionar com regras. Acrescente geração de resumos quando os registros já estiverem estruturados e houver uma forma de conferir a qualidade do texto produzido.
Como evitar mensagens repetidas durante uma queda grande?
Agrupe eventos por incidente e aplique deduplicação por etapa de comunicação. Preserve os detalhes técnicos no histórico, mas envie notificações que indiquem claramente a mudança relevante e a ação esperada.
