Como funciona relatório pós-incidente: do aviso às ações no provedor

Como funciona relatório pós-incidente: o texto nasce dos registros

O relatório é montado a partir do que a rede, o atendimento e a equipe registraram durante a queda. Quem escreve não inventa nada: organiza, confere e traduz.

Um relatório pós-incidente é o documento que conta uma queda já encerrada para quem não estava na rede. A parte visível é o texto, mas a maior parte do trabalho acontece antes, cruzando fontes que raramente concordam entre si logo de início.

A Táquion Tech faz o relatório pós-incidente de forma remota para provedores de todo o Brasil, com uma versão técnica e uma para leitores de fora saídas da mesma linha do tempo. O diagrama mostra por onde cada informação passa até virar frase no documento.

Os quatro horários que todo relatório mede

Os horários são a espinha do documento, e cada intervalo entre eles revela uma coisa diferente sobre a operação. Por isso cada um vem com a fonte de onde saiu.

• Início: o primeiro sinal anormal registrado, mesmo que ninguém tenha visto na hora.
• Detecção: quando alguém da equipe ou um alerta percebeu o problema; a distância até o início mede o monitoramento.
• Volta parcial: quando parte dos assinantes recuperou o serviço, comum em quedas que voltam por região.
• Volta total: quando o último grupo afetado voltou, que é o horário usado para medir a duração contra o contrato.

Do intervalo entre detecção e volta total sai o tempo de restauração, que muitos contratos chamam de prazo de reparo. O SLA de cada cliente empresarial diz qual desses horários conta para o desconto.

As etapas do relatório pós-incidente, uma depois da outra

São sete etapas, do aviso curto à última ação cumprida, e as que mais tomam tempo são a contagem do impacto e o rascunho técnico. O aviso inicial é a mais rápida e não espera a causa.

1. Aviso curto: logo depois da volta, o cliente recebe poucas linhas dizendo o que se sabe, o que ainda está em análise e quando chega o relatório.
2. Congelar os dados: alarmes, gráficos, conversas e sessões do período são exportados antes que a retenção dos sistemas os apague.
3. Contar o impacto: sessões encerradas e lista de contratos são cruzadas para chegar a números por serviço e por região.
4. Rascunho técnico: linha do tempo, causa, ações tomadas durante a queda e ações futuras, com equipamentos e comandos.
5. Revisão com quem atendeu: o técnico lê o rascunho e corrige horário, ordem ou ação que não bate com o que viveu.
6. Versão para fora: o texto é reescrito na linguagem do leitor e revisado para não expor endereço, topologia ou senha.
7. Entrega e acompanhamento: documento enviado e lista de ações conferida item por item até a última data.

Em proporção, o aviso leva horas, o congelamento dos dados é curto, e contagem e rascunho ocupam a maior fatia. A revisão e a versão externa dependem de quantos leitores existem. Prazo típico de cada etapa na Táquion Tech: [PREENCHER prazos por etapa].

Como contar quem ficou sem serviço?

O número confiável sai das sessões PPPoE ou IPoE encerradas no período, guardadas pelo servidor de autenticação. Contar ligações no atendimento subestima a queda, porque muita gente não liga.

-- Assinantes distintos que perderam a sessão no concentrador 192.0.2.1
-- entre o início e a volta total da queda
SELECT COUNT(DISTINCT username) AS afetados
FROM radacct
WHERE nasipaddress = '192.0.2.1'
  AND acctstoptime BETWEEN '2026-10-14 20:20:00' AND '2026-10-14 21:25:00'
  AND acctterminatecause IN ('Lost-Carrier', 'Lost-Service', 'NAS-Reboot', 'Admin-Reset');

-- Quanto tempo cada um ficou sem sessão até reconectar
SELECT a.username,
       MIN(b.acctstarttime) - a.acctstoptime AS tempo_sem_servico
FROM radacct a
JOIN radacct b ON b.username = a.username AND b.acctstarttime > a.acctstoptime
WHERE a.nasipaddress = '192.0.2.1'
  AND a.acctstoptime BETWEEN '2026-10-14 20:20:00' AND '2026-10-14 21:25:00'
GROUP BY a.username, a.acctstoptime;

Depois, os nomes de usuário são cruzados com o sistema de gestão para separar residenciais de clientes com contrato. Quando o provedor usa o próprio sistema de gestão como servidor de autenticação, a mesma consulta costuma existir como relatório pronto no painel dele.

Como funciona relatório pós-incidente quando a causa ainda está aberta?

O relatório sai com a causa marcada como em investigação e uma data para a atualização. Escrever uma causa suposta e trocá-la depois custa mais confiança do que admitir que a investigação continua.

A investigação em si segue outro processo, com coleta, hipóteses e testes, descrito no guia de como funciona análise de causa raiz. Quando ela termina, o relatório ganha uma revisão curta com a causa provada.

O que a equipe do provedor separa para o relatório?

A equipe separa dados, contratos e conversas, e quase tudo pode ser exportado no dia seguinte à queda. O que demora a ser separado costuma ser justamente o que some primeiro.

Informe também quem vai ler. Saber de antemão se o documento vai para a diretoria, um hospital ou uma prefeitura muda o tom do rascunho desde a primeira linha.

O que chega às mãos do provedor no fim

Chegam a versão técnica, a versão para leitores de fora, um anexo por cliente com contrato e a lista de ações. O acompanhamento dessa lista é o que encerra o trabalho.

O anexo por cliente compara a duração medida para aquele contrato com o prazo de reparo da cláusula dele. É o papel que a área comercial usa para discutir o desconto com base em números.

Quem precisa estimar esse trabalho antes de pedir encontra os fatores no guia de quanto custa o relatório pós-incidente, que trata de leitores, versões e prazo.

Acompanhamento das ações depois da entrega

A lista de ações vai numa planilha ou no sistema de chamados, com dono, data e forma de conferir. A cada data vencida, a ação é marcada como feita, adiada com motivo ou cancelada com justificativa.

O registro de cada queda vira histórico consultável, como propõe a gestão de incidentes do ITIL [CONFIRMAR na norma]. O guia sobre ITIL na operação de rede mostra como levar isso à rotina.

Onde o relatório dá errado, etapa por etapa

Cada etapa tem uma falha típica, e a maioria aparece como uma pergunta do cliente que o documento não sabe responder. Perceber cedo evita mandar uma segunda versão corrigida.

• Aviso curto: promete uma causa antes da hora; percebe-se quando o relatório final contradiz o aviso.
• Congelamento: a lista de alarmes foi limpa; percebe-se pela linha do tempo com horários vindos só da memória.
• Contagem: o impacto saiu das ligações; percebe-se quando o cliente cita um número de afetados maior que o seu.
• Rascunho: a causa está escrita como certa sem evidência; percebe-se pela falta de anexo que a sustente.
• Revisão: o técnico não leu o texto; percebe-se quando ele mesmo discorda do documento numa reunião.
• Versão externa: sobrou um IP ou o nome de um equipamento; percebe-se lendo o texto como um concorrente leria.

E se o horário do cliente não bater com o seu?

Cliente empresarial com monitoramento próprio vai comparar os horários, e diferença sem explicação derruba o documento inteiro. Antes de enviar, confira o relógio dos seus equipamentos e o fuso de cada exportação.

Se a diferença persistir, o relatório informa as duas medições e a fonte de cada uma. Um relógio desacertado por falta de NTP costuma virar, ele próprio, uma das ações da lista.

Exemplo: relatório de uma queda de energia num POP de bairro

O caso é ilustrativo e mostra a linha do tempo como ela aparece na versão técnica. A lição principal estava num alarme que tocou antes da queda.

Numa noite de semana, um POP de bairro perdeu a energia da concessionária. O nobreak segurou a carga por um tempo, o gerador não partiu e a OLT desligou, levando junto o link dedicado de uma clínica com contrato.

A queda de serviço durou 55 minutos, mas o primeiro sinal veio 45 minutos antes, num alarme que não acionava ninguém. Na versão para a clínica, isso virou uma frase simples: a falta de energia foi registrada e não gerou aviso à equipe a tempo.

• Ação 1: alarme de energia do POP passa a acionar quem está de sobreaviso, com dono e data.
• Ação 2: bateria de partida do gerador trocada e teste de partida incluído na rotina mensal.
• Ação 3: anexo da clínica com a duração medida comparada ao prazo de reparo do contrato dela.

Uma queda geral com outra origem, como a descrita no guia de PPPoE caindo para todos os clientes, segue a mesma estrutura de horários, fontes e ações.

Perguntas frequentes

Thiago Manoel

Responsável técnico da Táquion Tech · Registro profissional [PREENCHER]

Mais de 15 anos em operações de rede, com gestão de infraestruturas de TI, administração de data centers e condução de equipes em migrações de TI e telecomunicações, com foco em alta disponibilidade e segurança.

A Táquion Tech é uma empresa de engenharia de redes de Balneário Camboriú (SC) que projeta, opera e dá suporte a redes de provedores de internet e de empresas.

Conheça a equipe da Táquion Tech