Resumo

  • Em 23 de dezembro de 2019, uma falha de hardware combinada com uma configuração incorreta do armazenamento impediu a migração de máquinas virtuais. O site da ARIN e o ARIN Online foram restabelecidos por caminhos distintos e em horários diferentes.
  • Os registros do conselho mostram pedidos de relatório de infraestrutura, correção, avaliação de risco de indisponibilidade e melhores indicadores. Eles documentam acompanhamento mais estruturado, não uma auditoria que certifique a eliminação de todo risco ou o cumprimento de um objetivo de recuperação.

O teste não foi apenas se havia um ambiente secundário

Às 12h35 de 23 de dezembro, os sistemas de monitoramento da ARIN alertaram sobre várias máquinas virtuais que sustentavam serviços usados por clientes. A equipe tentou transferi-las manualmente para hardware de contingência. A tentativa falhou. Vinte minutos depois, às 12h55, o site público da ARIN e o aplicativo ARIN Online estavam indisponíveis.[4]

Esse intervalo de vinte minutos dá ao incidente uma borda verificável. Não é preciso transformar a indisponibilidade numa crise abstrata de “toda a Internet” nem atribuir à diretoria cada decisão de operação para perceber o que o registro demonstra: a primeira alternativa prevista não funcionou e duas superfícies importantes para o relacionamento com membros e usuários ficaram inacessíveis.

O relato publicado em março de 2020 é de Richard Jimmerson, então diretor de operações. Ele descreve uma falha de hardware acompanhada por um erro de configuração no equipamento de armazenamento, combinação que fez o mecanismo de virtualização falhar. O armazenamento compartilhado do cluster foi apontado como provável fator inicial enquanto a equipe investigava. O relato atribui o diagnóstico, o contato com fornecedores e a recuperação às equipes de operações, não a John Curran pessoalmente.[4]

A distinção importa porque “havia redundância” é uma descrição de inventário, não um teste de independência. Se máquinas primárias e a alternativa de failover dependem do mesmo domínio de armazenamento, um problema nessa dependência pode atravessar as duas rotas. A questão operacional não é apenas quantos servidores existem; é quais falhas conseguem atingir simultaneamente o caminho ativo e o caminho de recuperação.

O relato identifica o site da ARIN e o ARIN Online como indisponíveis. Ele não informa se Whois, RDAP, IRR, RPKI, DNS ou outros serviços ficaram fora do ar, nem afirma que permaneceram disponíveis. Não se deve preencher esse silêncio com uma suposição. Para clientes, o estado de cada serviço e a consequência para cada fluxo de trabalho precisam ser verificados separadamente.[4]

Uma interrupção anterior não é a mesma falha

Em janeiro de 2019, quase onze meses antes do incidente de armazenamento, o conselho discutiu uma interrupção do domínio ARIN.NET que afetou partes que validavam DNSSEC. A ata registra que Curran revisou o pós-mortem com os conselheiros e que pretendia alinhar com o CTO quais sistemas eram essenciais à missão. O presidente do conselho pediu que o relatório fosse apresentado quando estivesse concluído.[3]

Essa passagem é relevante para compreender o tipo de informação que a direção levava ao conselho, mas não para fundir as duas ocorrências. O registro de janeiro não fornece uma causa técnica, a duração da indisponibilidade ou o resultado do acompanhamento. O relato de dezembro identifica armazenamento, virtualização e failover. As fontes consultadas não dizem que os episódios compartilharam causa, componente ou correção.

Há uma diferença entre repetir uma categoria — “serviço da ARIN indisponível” — e demonstrar uma causa comum. A primeira pode orientar uma pergunta de supervisão. A segunda exige evidência. Sem ela, a cronologia sustenta a existência de dois problemas distintos e a expectativa de acompanhamento; não sustenta uma teoria sobre uma única fragilidade persistente.

O relógio do site não era o do aplicativo

Às 15h30 de 23 de dezembro, a equipe decidiu transferir o site para o ambiente de recuperação de desastres. O relato diz que o site voltou às 16h. O ARIN Online retornou às 17h10. Uma diferença de setenta minutos separou a recuperação da página pública da retomada da aplicação usada por clientes.[4]

O intervalo não deve ser tratado como detalhe. Um visitante pode conseguir ler o site enquanto um cliente ainda não consegue realizar operações pelo ARIN Online. A disponibilidade de um ponto de entrada público não demonstra a disponibilidade da interface transacional, e tampouco informa por si só o estado de outros sistemas. Para medir o impacto, é preciso relacionar cada horário a uma função concreta.

O caminho de recuperação foi escolhido quando a duração do reparo no ambiente principal deixou de ser previsível. A ARIN informou que o local de recuperação era mantido e testado. Isso é uma evidência útil de uma rota alternativa, mas o relato não publica um objetivo numérico de tempo de recuperação, um limiar formal de failover ou o resultado de um exercício que reproduzisse exatamente a combinação de falha observada em dezembro.

O componente com defeito foi substituído em 2 de janeiro. O cluster afetado voltou à operação. O retorno do site ao centro de dados principal foi programado para a janela de manutenção de 25 de janeiro, porque fazê-lo antes exigiria outra interrupção. Esses eventos representam marcos diferentes: recuperar o serviço, trocar o componente, corrigir a configuração, regressar ao local primário e encerrar ações corretivas não são sinônimos.[4]

A função de Curran aparece na prestação de contas

A ARIN descreve o conselho como responsável pela missão, pela direção estratégica e pela supervisão da organização. O presidente e CEO conduz as operações com a equipe, nomeia e supervisiona responsáveis operacionais e atua como ligação com o conselho consultivo. Curran ingressou no conselho fundador da ARIN em 1997, presidiu-o até 2009 e então se tornou presidente e CEO.[1][2]

Esse histórico situa a autoridade executiva de Curran, mas não o transforma no engenheiro que identificou a falha ou comandou a migração. O relato técnico é assinado por Jimmerson, que era COO, e descreve o trabalho da equipe. A forma mais precisa de avaliar Curran é acompanhar como a direção fez o episódio atravessar a fronteira entre operações e governança: quais informações foram levadas ao conselho, quais ações foram solicitadas e que tipo de visibilidade passou a ser cobrado.

Em janeiro de 2020, Jimmerson apresentou detalhes técnicos ao conselho e Curran complementou a exposição. O conselho pediu um relatório de infraestrutura, aceleração de medidas corretivas, reforço da recuperação de desastres e uma avaliação dos riscos de indisponibilidade antes de abril. A ata registra tanto a solicitação de supervisão quanto a necessidade de uma resposta executável.[5]

O relato do COO e a complementação do CEO são papéis diferentes. Um descreve o mecanismo e o trabalho feito na operação; o outro coloca a questão dentro da prestação de contas executiva. A evidência disponível não mostra que Curran tenha escolhido o equipamento, alterado a configuração ou coordenado os comandos da restauração. A atribuição correta preserva a responsabilidade de liderança sem apagar o trabalho técnico.

A resposta tornou-se uma sequência, não uma nota isolada

Em março de 2020, a ata registrou que um relatório mais completo seria apresentado em abril, que os documentos estavam em preparação e que o prazo pretendido para as ações corretivas era o fim daquele ano. O COO informou que o trabalho estava no cronograma.[6] Em maio, os conselheiros receberam um relatório concluído de correção da interrupção e um suplemento de infraestrutura.[7]

Mais importante que a existência de um documento é a forma como o conselho pediu que as informações fossem estruturadas. Os sistemas deveriam ser associados às funções do negócio; as medidas deveriam ter datas; e o acompanhamento deveria voltar trimestralmente. Um inventário de equipamentos não explica, sozinho, qual serviço depende de quê, quem é responsável pela correção ou qual teste permite considerar uma ação encerrada.

Curran também apresentou princípios e prazos para examinar a terceirização de soluções técnicas. Isso não prova que a terceirização tenha ocorrido, nem que fosse a única saída. Mostra uma pergunta de gestão: quais capacidades devem permanecer sob controle direto, quais dependem de fornecedores e como a direção compara custo, conhecimento interno e risco de continuidade.[7]

Em fevereiro de 2021, o conselho voltou a pedir métricas mais úteis de desempenho de sistemas e atendimento, discutiu a possibilidade de níveis de serviço e solicitou uma estrutura de disponibilidade e confiabilidade junto com um mapa de dependências. Essa ata prolonga a conversa sobre como tornar a operação avaliável; não fornece um tempo objetivo de recuperação que possa ser atribuído ao incidente de 2019.[8]

A prestação recorrente reduz um problema comum da supervisão: uma falha recebe atenção intensa enquanto está recente, mas os compromissos seguintes desaparecem de vista. Datas, responsáveis, função afetada e atualização periódica deixam mais claro se o trabalho continua, mudou de rumo ou foi concluído. Ainda assim, as atas são a trilha de governança. Elas não substituem os relatórios técnicos integrais nem os resultados de testes que não estão reproduzidos nelas.

Visibilidade pública responde a outra pergunta

Em abril de 2021, a ARIN anunciou uma página pública de status que separava famílias de serviço como ARIN Online, provisionamento, Whois, RDAP, RPKI, IRR, relatórios e site. Usuários podiam receber notificações por e-mail, SMS, Slack e outros canais. O anúncio diz que a iniciativa atendia à proposta comunitária ACSP 2020.5 e foi publicado pelo CTO Mark Kosters.[9]

O painel responde “qual serviço a organização informa que está afetado e que atualização publicou?”. Ele pode melhorar a decisão de quem depende de um sistema e reduzir a confusão entre uma homepage acessível e um aplicativo fora do ar. Mas não é, por si só, uma rota de recuperação, um teste de failover, um SLA ou um histórico independente de disponibilidade. A cronologia também não prova que a página foi criada exclusivamente por causa da falha de dezembro; a própria ARIN a relaciona a uma proposta comunitária.

Em 2022, o COO relatou ao conselho que mudanças de liderança e infraestrutura haviam mitigado riscos anteriormente associados ao ambiente NetApp, com migração para outros fornecedores.[10] Essa é uma informação de gestão registrada em ata, e não uma auditoria independente de cada ação de 2019. O relatório anual de 2025 mantém a prestação de serviços consistentes como objetivo estratégico, mas não oferece uma métrica de recuperação daquele incidente.[11]

Cada fonte fecha uma pergunta diferente. A nota de incidente fornece horários e causa; as atas mostram a supervisão e os compromissos relatados; o status público ajuda a observar incidentes futuros; o relatório anual descreve objetivos mais amplos. Juntas, elas indicam uma resposta mais estruturada. Não autorizam converter transparência em garantia técnica.

A fronteira de serviço é parte da resiliência

Para um cliente, “ARIN está fora do ar” pode ser uma descrição ampla demais para orientar uma decisão. Whois e RDAP servem à consulta; RPKI e IRR participam de fluxos diferentes; provisionamento e ARIN Online podem suportar operações de registro; o site público informa e orienta. Dependências e consequências não são idênticas. A fonte de 2019 não permite dizer quais desses serviços foram afetados, de modo que clientes não devem usar o retorno do site como proxy para todos eles.

Uma organização dependente pode mapear seu próprio trabalho para os serviços publicados, anotar qual fonte de status consultou e definir o que pode continuar usando dados em cache. Essas ações não corrigem o ambiente da ARIN. Elas reduzem o risco de que um cliente tome uma decisão irreversível com base em uma leitura errada de disponibilidade.

Do lado da ARIN, uma medida de resiliência por serviço exigiria pelo menos dependências explícitas, objetivos definidos, testes datados e resultados observáveis. Uma taxa agregada de disponibilidade pode esconder que uma aplicação crítica falhou enquanto a página de informação permaneceu acessível. Um resultado de failover também precisa especificar qual falha foi ensaiada e que operações foram exercitadas; “o segundo local iniciou” pode não significar que clientes conseguiram concluir uma transação.

O que os registros deixam em aberto

É possível afirmar que o failover de máquinas virtuais falhou, que o site e o ARIN Online ficaram indisponíveis, que o site de recuperação trouxe o primeiro de volta antes da aplicação, que houve substituição de componente e correção de configuração e que o conselho pediu relatórios, cronograma, avaliação de risco e melhores métricas.[4][5][6][7][8]

Não é possível afirmar com as fontes aqui reunidas que todo serviço da ARIN parou, que todos os serviços continuaram funcionando, que cada ação corretiva foi encerrada na data prevista, que cada rota foi testada contra o mesmo modo de falha ou que um objetivo público de recuperação foi atingido. Também não é possível atribuir a página de status somente à ocorrência de dezembro.

Isso não é acusação nem atestado. É uma fronteira de evidência. Uma ata pode demonstrar que o conselho pediu um mapa; para confirmar a qualidade do mapa, seria necessário ver o próprio material. Um relatório pode registrar que a configuração foi corrigida; para testar a afirmação, é preciso conhecer o teste e seu resultado. Um estado “normal” pode descrever a observação presente, sem demonstrar como o sistema se comportará na próxima combinação de falhas.

O desempenho executivo de Curran deve ser lido nessa mesma chave. A documentação o coloca no nível em que operações são apresentadas, riscos se tornam decisões de recursos e a supervisão ganha uma cadência. O registro público evidencia uma continuidade maior na conversa com o conselho. Não expõe todos os artefatos necessários para medir, de forma independente, quanto do risco foi reduzido.

Conclusão: recuperação precisa ser demonstrada por serviço

O episódio de 23 de dezembro revelou um limite concreto: componentes descritos como redundantes não impediram que uma dependência de armazenamento comprometesse o failover. O site e o ARIN Online retornaram por etapas; o conselho pediu explicações, correções, avaliação de risco e acompanhamento. A direção posteriormente publicou uma página de status e continuou discutindo indicadores e dependências.[4][5][7][8][9]

John Curran importa para esta história por sua função executiva e de prestação de contas, não por uma participação técnica que as fontes não demonstram. O COO e as equipes operacionais aparecem no diagnóstico e na recuperação. Curran complementou informações no conselho e participou do processo pelo qual as consequências do incidente foram transformadas em relatórios e supervisão.[1][2][5][7]

A lição mais útil não é que toda organização deve evitar qualquer interrupção, nem que um painel público resolva uma arquitetura compartilhada. É que uma afirmação de resiliência precisa nomear o serviço, a dependência que falhou, o caminho que o trouxe de volta, o tempo observado e a prova do teste posterior. A ARIN tornou partes dessa cadeia mais visíveis. As fontes públicas examinadas não fecham todas as demais. Uma conclusão disciplinada preserva as duas coisas ao mesmo tempo.

Fontes

  1. ARIN Board of Trustees e biografia de John Curran
  2. Estrutura organizacional e equipe da ARIN
  3. Ata do Conselho — 16 de janeiro de 2019
  4. Richard Jimmerson, “Operations at ARIN: New Blog Series and Recent Outage Information”, 19 de março de 2020
  5. Ata do Conselho — 22–23 de janeiro de 2020
  6. Ata do Conselho — 25 de março de 2020
  7. Ata do Conselho — 21 de maio de 2020
  8. Ata do Conselho — 3 de fevereiro de 2021
  9. ARIN, “New ARIN Service Status Page Available”, 5 de abril de 2021
  10. Ata do Conselho — 4 de agosto de 2022
  11. Relatório anual da ARIN de 2025
  12. Referência visual de identidade apenas: foto oficial de John Curran publicada pela ARIN. Usada somente para fundamentar a identidade do retrato editorial gerado por IA; não é evidência dos fatos operacionais.