Resumo

  • Às 15h55min39s CET de 3 de novembro, a RIPE NCC abriu investigação sobre acesso intermitente a informações de recursos no LIR Portal. Às 16h50min45s, marcou o incidente como resolvido. O intervalo público entre avisos foi de aproximadamente 55 minutos.
  • No relatório das 17h17, a associação disse que o failover do balanceador afetou aplicações que usam o banco de dados. A remoção de conexões obsoletas foi a correção imediata; configuração do pool e monitoramento do uso de conexões ficaram na lista de melhorias.

Há uma diferença entre ter um caminho reserva e atravessá-lo. O relato oficial da RIPE NCC coloca essa diferença no centro do incidente. O balanceador de carga fez a troca, mas as aplicações que consultam o banco de dados conservaram conexões antigas. A equipe limpou essas conexões para restabelecer o acesso. O failover chegou à infraestrutura antes de chegar ao trabalho do associado.

O registro público começa com a investigação às 15:55:39.649 e termina com a marca de resolução às 16:50:45.437, horário da Europa Central. São 55 minutos e quase seis segundos entre duas atualizações, conforme a API do incidente. Não há uma série pública de consultas que falharam minuto a minuto. O número marca o período de comunicação do operador; não mede a interrupção individual de cada membro.

As informações atingidas têm utilidade direta. O LIR Portal é a porta pela qual associados veem seus recursos IPv4, IPv6 e ASNs. Em um texto de outubro sobre a futura experiência My Resources, a própria RIPE NCC explica por que os dados importam: hierarquias de alocações, registros, uso, objetos da base RIPE e informações de roteamento precisam ser compreensíveis para quem administra redes. A árvore e as verificações automáticas descritas ali ainda estavam sendo desenvolvidas e testadas. O trabalho de consultar recursos, porém, já existia.

A falha revela um elo fraco entre a guarda do registro e a disponibilidade de sua consulta. A associação não disse que perdeu dados. Disse que as aplicações foram afetadas após uma troca do balanceador e que conexões obsoletas precisaram ser apagadas. Isso permite uma cobrança precisa: o teste de recuperação tem de começar no pedido feito pelo associado, atravessar a aplicação e chegar ao banco. Se parar na lâmpada verde do balanceador, a instituição pode comemorar a parte errada da viagem.

A revisão anunciada se divide em comportamento e observação. Ajustar o pool de conexões pode fazer a aplicação abandonar sessões que não levam mais ao banco. Melhorar o monitoramento do uso dessas conexões pode revelar quando isso não aconteceu. O relatório não informa o que disparou o failover, quantos associados ou pedidos foram afetados nem quando as melhorias ficarão prontas. Esses dados e um teste posterior de acesso pelo portal estabeleceriam o alcance e a eficácia da correção.

Por enquanto, a sequência demonstrada é curta e importante: houve acesso intermitente, a equipe removeu conexões obsoletas e o incidente foi encerrado. O próximo comprovante deve mostrar que uma troca semelhante termina com recursos legíveis na tela do associado.

Fontes originais da RIPE NCC