Resumen

  • El 23 de diciembre de 2019, una avería de hardware junto con una configuración incorrecta hizo fracasar el intento de conmutar las máquinas virtuales de ARIN. El sitio web público y la aplicación ARIN Online se restauraron por separado.
  • Después, el consejo pidió informes de infraestructura, un plan de corrección y una evaluación del tiempo de inactividad. El registro muestra un seguimiento más ordenado, pero no certifica que todo riesgo desapareciera ni que se cumpliera un objetivo medido de recuperación.

La diferencia entre tener respaldo y poder recuperarse

El 23 de diciembre, a las 12:35 p. m., los sistemas de monitoreo de ARIN alertaron sobre varias máquinas virtuales que daban soporte a servicios para clientes. El personal intentó trasladarlas manualmente a hardware de reserva. El intento no funcionó y, a las 12:55, el sitio web y ARIN Online quedaron fuera de servicio. El informe público identifica esas dos superficies; no declara el estado de todos los demás servicios del registro.[4]

La investigación apuntó al acceso al almacenamiento compartido del clúster. En la revisión posterior, ARIN describió una falla de hardware combinada con un error de configuración en el dispositivo de almacenamiento; juntos impidieron que el motor de virtualización funcionara. El componente defectuoso se reemplazó, el proveedor validó la configuración corregida y el clúster volvió a operar.[4]

La combinación importa. Si la máquina principal y la de reserva dependen del mismo almacenamiento, ese almacenamiento es un punto común de falla aunque haya redundancia en los servidores. La conmutación puede ejecutarse correctamente y aun así no producir una aplicación funcional. La redundancia protege frente a los fallos que la arquitectura separa; no frente a una dependencia compartida que permanece dentro de ambos caminos.

El informe distingue la caída del sitio y de ARIN Online. No permite decir que Whois, RDAP, DNS, el IRR, RPKI o los datos de registro estuvieran también fuera de servicio; tampoco demuestra que siguieran disponibles. El silencio sobre una función no prueba ni su caída ni su buen estado. Esa cautela es esencial cuando se evalúa la continuidad de una infraestructura pública.[4]

Un antecedente distinto: la interrupción de DNSSEC

En una reunión de enero de 2019, el consejo revisó una interrupción del dominio ARIN.NET para quienes validaban DNSSEC. John Curran presentó el post mortem e indicó que se reuniría con Mark Kosters, director de tecnología, para alinear los sistemas críticos para la misión. La presidencia del consejo pidió un informe una vez concluido ese trabajo. El acta no aporta duración, causa ni resultado final.[3]

No hay base para unir ese episodio con la caída de almacenamiento de diciembre. Las fuentes no indican una causa común. Sí muestran que los límites del servicio importan: una interrupción que afecta a validadores DNSSEC no es lo mismo que la pérdida del clúster que alojaba el sitio y la aplicación de clientes. Curran informó al consejo en ambos casos, pero esa coincidencia no convierte los incidentes en uno solo.

Dos relojes de recuperación

A las 3:30 p. m. del 23 de diciembre, ante una reparación incierta, el personal decidió trasladar el sitio web al centro de recuperación ante desastres. El sitio volvió a las 4:00 p. m.; ARIN Online, a las 5:10 p. m. La diferencia de setenta minutos muestra por qué “ARIN volvió” es una descripción demasiado amplia: la página pública y la aplicación que usan los clientes tenían tiempos distintos.[4]

El 2 de enero se reemplazó el componente fallido y el clúster afectado volvió a funcionar. Como regresar el sitio web al centro de datos principal implicaba otra interrupción, ARIN coordinó ese cambio con una ventana de mantenimiento prevista para el 25 de enero. Son hitos distintos: volver a ofrecer un servicio, sustituir una pieza, regresar al entorno primario y cerrar todas las medidas correctivas no significan lo mismo.[4]

La decisión de usar el centro de recuperación evitó esperar indefinidamente a una reparación cuyo plazo no se conocía. ARIN dijo que esa capacidad se mantenía y se probaba. La publicación, sin embargo, no incluye un objetivo de recuperación expresado en minutos ni explica el umbral usado para ordenar el cambio. El registro es preciso sobre la secuencia y las horas; es menos específico sobre cómo se mediría el éxito frente a un objetivo previo.

El lugar de John Curran, sin atribuirle la reparación

ARIN describe una división formal de responsabilidades. El consejo mantiene autoridad sobre la misión y el alcance de la organización y participa en la orientación estratégica y financiera. El presidente y CEO, junto con el personal, ejecuta esa dirección mediante la gestión operativa. El presidente es seleccionado por el consejo, supervisa al personal de operaciones, forma parte del propio consejo y sirve de enlace con el Consejo Asesor.[1][2]

La biografía de Curran recoge su trabajo previo como CTO en varias compañías de Internet y su pertenencia al consejo fundador de ARIN desde 1997. Presidió ese consejo hasta 2009 y ese mismo año pasó a ser presidente y CEO.[1] Ese recorrido da contexto a su experiencia, pero no demuestra que diagnosticara el almacenamiento ni que realizara la conmutación. El relato técnico de diciembre lo escribió Richard Jimmerson, director de operaciones, y atribuye las alertas, las conversaciones con proveedores y la restauración a Operaciones y al personal.[4]

Las actas sitúan a Curran en otra parte de la cadena. En enero de 2020 aportó información adicional al consejo. Los trustees solicitaron un informe de infraestructura, acelerar medidas de largo plazo, reforzar la recuperación ante desastres y recibir una evaluación del riesgo de indisponibilidad.[5] Esta atribución acotada permite evaluar su liderazgo sin convertir el episodio en la historia de un ejecutivo que “salvó” un sistema por sí solo.

De la explicación a la supervisión recurrente

El 25 de marzo de 2020, el director de operaciones dijo que se preparaba una actualización completa, que la fecha objetivo para la remediación era el final del año y que el trabajo iba según lo previsto.[6] En mayo, el acta registró que el COO había terminado el informe sobre la remediación y un suplemento de infraestructura. El consejo pidió conectar los sistemas con las funciones del negocio, fijar fechas de inicio y cierre y mantener informes trimestrales.[7]

Ese paso cambia la pregunta. Después de una falla no basta con preguntar qué componente se rompió; también importa qué función dependía de él, quién es responsable de corregirlo y cómo se demostrará que el cambio funcionó. Curran dijo estar preparando principios y plazos para evaluar la externalización de soluciones técnicas. Las actas muestran una decisión de gestión sobre cómo hacer que la condición de los sistemas sea comprensible para quienes asignan recursos.[7]

En febrero de 2021, el consejo pidió métricas más útiles sobre desempeño de sistemas y atención al cliente, consideró indicadores de nivel de servicio y solicitó un mapa de dependencias que mostrara los sistemas cruciales. Curran quedó encargado de analizar esas métricas y el marco de disponibilidad, fiabilidad y consistencia.[8] El registro muestra una dirección de trabajo; no publica un objetivo numérico de recuperación para el incidente de 2019 ni contiene todos los documentos técnicos que recibieron los trustees.

Visibilidad no es disponibilidad

ARIN anunció en abril de 2021 una página pública de estado que separaba ARIN Online, el aprovisionamiento, Whois, RDAP, RPKI, IRR, informes y el sitio web. Permitía recibir avisos por correo, mensaje de texto, Slack u otros canales. La nota dice que la página respondía a la propuesta comunitaria ACSP 2020.5 y está firmada por el CTO Mark Kosters.[9]

La página responde a “¿qué servicio dice ARIN que está afectado?” No sustituye al centro de recuperación, no mide el tiempo de actividad y no equivale a un SLA. Tampoco se debe afirmar que se creó únicamente por la falla de diciembre: la fuente la vincula a una solicitud de la comunidad. Su valor es más concreto: permite seguir servicios separados en un canal distinto de los debates sobre políticas.[9]

En 2022, el COO dijo al consejo que los cambios organizativos y las mejoras de infraestructura habían mitigado el riesgo anterior relacionado con NetApp y que ARIN había migrado a otros proveedores.[10] Es una declaración de gestión recogida en acta, no una auditoría independiente de todos los controles de 2019. El informe anual de 2025 mantiene la prestación consistente de servicios entre los objetivos de ARIN, pero no aporta una medición retrospectiva de aquella recuperación.[1][11]

Una conclusión proporcionada por la evidencia

Las fuentes públicas permiten reconstruir una cadena: falló el intento de conmutar las máquinas virtuales; el sitio y ARIN Online quedaron fuera; un centro de recuperación distinto restauró primero el sitio y después la aplicación; se sustituyó el componente y se corrigió la configuración; el consejo pidió informes y análisis de riesgo; más tarde se organizaron reportes recurrentes y una página de estado.[4][5][6][7][8][9]

La documentación no demuestra que todos los servicios estuvieran afectados, que ninguno más se afectara, que cada medida se cerrara dentro del plazo o que un tercero validara la reducción del riesgo. Esa limitación no es una acusación ni una garantía; es el perímetro de lo que las fuentes revisadas permiten afirmar.

Para los operadores de redes, esa distinción ayuda a decidir qué hacer. Un sitio, una aplicación de cuentas, una interfaz de aprovisionamiento, una publicación RPKI y una base de registro pueden tener dependencias distintas. Los equipos que dependen de esos servicios pueden documentar qué operaciones requieren acceso en tiempo real, qué datos pueden mantenerse en caché y qué procesos conviene pausar durante una interrupción. Esa preparación no sustituye la responsabilidad de ARIN; evita que el estado de una interfaz se use como sustituto del estado de otra.

El papel de Curran debe medirse por los mecanismos que aparecen en el registro: que las dependencias lleguen al consejo, que la deuda técnica tenga fechas, que los objetivos de recuperación se prueben y que los clientes distingan cada servicio. Las fuentes muestran una mejora en los informes y la visibilidad después de 2019, pero no un cuadro público que cierre cada objetivo. El trabajo de operación fue de los equipos técnicos; el del CEO es asegurar que la institución haga visibles la responsabilidad, el riesgo y la evidencia.[5][6][7][8][9]

La lección final es sencilla: la autoridad de un registro y su fiabilidad operativa son preguntas distintas. Para hablar de continuidad hay que nombrar el servicio, la dependencia que falló, la ruta de recuperación, el momento de regreso y la prueba de que la corrección se sostuvo. ARIN documentó varios de esos elementos y dejó otros sin resolver en el expediente público. La resiliencia se demuestra servicio por servicio, no por reputación ni por una etiqueta de alta disponibilidad.

Fuentes

  1. ARIN Board of Trustees and John Curran biography
  2. ARIN Organization Structure & Staff
  3. Board of Trustees Meeting Minutes — 16 January 2019
  4. Richard Jimmerson, “Operations at ARIN: New Blog Series and Recent Outage Information,” 19 March 2020
  5. Board of Trustees Meeting Minutes — 22–23 January 2020
  6. Board of Trustees Meeting Minutes — 25 March 2020
  7. Board of Trustees Meeting Minutes — 21 May 2020
  8. Meeting of the ARIN Board of Trustees — 3 February 2021
  9. ARIN, “New ARIN Service Status Page Available,” 5 April 2021
  10. Meeting of the ARIN Board of Trustees — 4 August 2022
  11. ARIN 2025 Annual Report
  12. Referencia visual de identidad únicamente: fotografía oficial de John Curran publicada por ARIN. Se usa solo para fundamentar la identidad del retrato editorial generado con IA; no es evidencia de los hechos operativos.