Resumen

  • APNIC programó tres horas de mantenimiento de red en Brisbane y advirtió de posibles interrupciones de hasta cinco minutos en 15 componentes.
  • La configuración de su página de estado excluye el mantenimiento del cálculo de disponibilidad; el porcentaje no prueba que no hubiera interrupciones.

El aviso fija un máximo posible, no un resultado

APNIC publicó el aviso de servicio el 13 de octubre. Anunció actualizaciones de seguridad críticas en equipos de red de sus centros de datos de Brisbane para el jueves 15 de octubre, de 06:00 a 09:00 UTC+10: una ventana de tres horas. El aviso señala que los servicios enumerados podían sufrir interrupciones de hasta cinco minutos. Es una posibilidad comunicada, no una duración de caída observada.

El aviso agrupa once familias de servicios: el portal MyAPNIC, registry-api.apnic.net, la web y el blog de APNIC, APNIC Academy, Orbit, FTP, los servicios RPKI, DASH, REx y Whois Oceania. La página pública de estado desglosa el trabajo en 15 componentes, con entradas separadas para repositorios RPKI, RRDP, AS0, el protocolo de publicación y el verificador RSC. Una sola etiqueta de mantenimiento cubre componentes con funciones distintas.

El porcentaje responde a una pregunta más limitada

A las 09:16 UTC+10, dieciséis minutos después del final previsto, la página aún mostraba el evento en “Upcoming Maintenance”. El historial indicaba que no se habían comunicado incidentes el 14 de octubre, y las filas de componentes mostraban un 100 % en la columna Uptime. Eso no demuestra que todos los servicios siguieran accesibles sin interrupciones: el mantenimiento planificado y los incidentes no planificados se registran por separado.

La configuración pública incluye ignore_maintenance_for_uptime_calculation: true y show_status_history_uptime: true. La referencia de la API StatusIQ documenta ese ajuste; la ayuda de Site24x7 explica que los periodos de mantenimiento pueden quedar fuera de los cálculos de indisponibilidad y disponibilidad. La página limita además a dos días el historial visible. Por tanto, el 100 % no es un comprobante específico de esas tres horas.

En las fuentes revisadas, APNIC aún no había publicado un registro por componente con interrupciones reales, horas de recuperación o impacto para los usuarios. Los registros confirman el trabajo previsto y la posibilidad de interrupciones de hasta cinco minutos; no confirman que se alcanzara ese límite ni que el impacto fuera cero.

Fuentes: aviso de servicio de APNIC del 15 de octubre, estado de los servicios de APNIC, referencia de la API StatusIQ de Site24x7 y guía de Site24x7 sobre disponibilidad. las actualizaciones de servicio de APNIC; Site24x7 sobre cómo excluir el mantenimiento programado de los informes SLA de disponibilidad.