Resumo

  • Às 09h19 CEST de 7 de setembro, RIPE NCC marcou o incidente do RRC18 como resolvido após reiniciar dois serviços de backend, embora a causa ainda não estivesse clara e a investigação fosse continuar.
  • Às 09h33 CEST, informou que o RRC24 havia parado de publicar arquivos update e bview, descreveu o caso como semelhante ao RRC18, suspeitou de uma raiz comum ainda não identificada e não descartou outros RRCs.

Há exatamente 801 segundos entre as duas mensagens públicas. O número é sólido; a narrativa causal que ele pode sugerir, não. As marcações indicam quando RIPE NCC publicou a resolução do RRC18 e quando abriu a investigação do RRC24. Não indicam quando o segundo problema começou, nem demonstram que o reinício do primeiro esteja ligado ao segundo.

O que o registro permite dizer é suficiente: o RRC18 recuperou a função de publicar, mas não uma explicação definitiva. Quatorze minutos depois, a hipótese que permanecera aberta apareceu em outro coletor, agora acompanhada do alerta de que o perímetro poderia crescer.

O conteúdo preciso da recuperação

O primeiro aviso do RRC18 data de 4 de setembro, às 18h14 CEST. Update e bview deixavam de ser publicados. O último update citado era updates.20260904.1335.gz; o último bview, bview.20260904.0800.gz. Esses nomes dão referências temporais para os objetos apontados pelo operador. Não revelam a hora de detecção, o total de arquivos envolvidos ou a condição de todas as formas de acesso ao RIS.

Em 5 de setembro, RIPE NCC comunicou que uma análise detalhada do processamento de mensagens do RRC18 ainda não havia encontrado a origem. Mais tarde, informou que os updates e bviews ausentes tinham sido publicados, o fluxo estava restaurado e a situação passara a monitoramento. No dia 7 veio a ação concreta: dois serviços de backend foram reiniciados. A mesma nota manteve a investigação aberta porque a causa não estava clara.

“Resolvido” descreveu corretamente a disponibilidade naquele momento. Não certificou que a condição responsável pela interrupção estivesse identificada ou contida. O próprio texto de RIPE NCC impede essa leitura mais ampla.

Dois coletores, uma pergunta de domínio

A documentação do RIS classifica o RRC18 como coletor ligado ao CATNIX, em Barcelona, Espanha. O RRC24 é multihop, hospedado pelo LACNIC em Montevidéu, Uruguai, com alcance regional. A diversidade não prova que uma camada compartilhada falhou. Ela torna necessário registrar quais componentes ou coortes de implantação podem atravessar caminhos tão diferentes.

O aviso do RRC24 ficou no terreno correto da hipótese. O sistema havia parado de publicar update e bview; o comportamento espelhava o RRC18; uma causa comum era suspeita, mas ainda desconhecida. RIPE NCC acrescentou que outros RRCs não podiam ser excluídos nas horas ou dias seguintes. Na captura preservada, o incidente continuava em investigação.

Nada disso autoriza uma afirmação de perda de BGP. Os documentos oficiais explicam que o RIS organiza dados MRT por coletor, produz bviews do estado de roteamento a cada oito horas e updates de mudanças a cada cinco minutos. Esses arquivos são usados como evidência por pesquisadores e operadores, por isso uma interrupção na publicação importa. Ela não demonstra impacto no roteamento, dados capturados corrompidos, perda definitiva ou indisponibilidade de toda interface RIS.

Também não há prova de que qualquer outro RRC tenha sido afetado. “Não podemos excluir” é uma declaração sobre o alcance da vigilância, não uma lista de danos.

Por que reiniciar e fechar pode ter sido correto

Uma equipe de operações deve poder conter o sintoma antes de conhecer a causa. Manter a publicação parada enquanto se busca certeza total seria uma escolha pior para os usuários. RIPE NCC republicou os objetos ausentes do RRC18, restabeleceu o fluxo, informou a ação de recuperação, admitiu a incerteza, manteve o diagnóstico ativo e alertou sobre RRC24 e um possível alcance mais amplo.

Deixar o RRC18 sinalizado como indisponível depois do retorno também distorceria o presente. Uma página de status responde primeiro se o serviço está funcionando agora. Dentro de um sistema com uma única cor, o encerramento operacional pode ter sido a descrição mais honesta disponível.

A fragilidade está nesse “único”. A frase “a causa não está clara” passa a viver dentro de uma página fechada. O trabalho causal perde um estado próprio, um prazo observável e uma forma pública de ser corrigido. O RRC24 devolveu visibilidade à pergunta por acaso, ao reproduzir o sintoma.

Um recibo que separa duas conclusões

É possível melhorar o registro sem expor hosts, topologia ou configuração. Um recibo curto vincularia identificador do incidente, coletor e classe de sintoma à ação tomada e à hora em que o serviço foi restaurado. Em outra coluna, manteria o estado da causa: não identificada, hipótese em teste, sustentada, rejeitada ou confirmada.

Quando a equipe suspeitasse de conexão entre casos, um token estável e não sensível poderia indicar uma mesma coorte de implantação, dependência ou failover. O recibo declararia o alcance da observação de recorrência, sua data final, a pessoa ou função responsável, o encerramento causal e quaisquer correções.

Essa estrutura não converte suspeita em diagnóstico. Ela preserva duas verdades simultâneas: o RRC18 voltou a publicar; a condição que talvez ligasse RRC18 e RRC24 não tinha sido encerrada. Uma conclusão de independência poderia ser anexada depois. Uma camada comum poderia ligar os casos sem alterar seus registros originais.

Em 25 de agosto, outro incidente informou que bviews tinham sido gerados, mas não publicados por uma configuração incorreta após failover, e reconheceu uma lacuna de monitoramento. Esse evento sustenta uma tese diferente, sobre geração, entrega e conferência por arquivo. Não é evidência da causa em setembro. O objeto deste artigo começa após a entrega voltar: como manter visível a investigação do domínio de falha?

Fontes