La caída de 61 horas de KDDI convirtió el control de cambios en una prueba de responsabilidad

Resumen

• KDDI dice que la caída de la comunicación comenzó a la 1:35 a. m. JST del 2 de julio de 2022 y que el uso del servicio se recuperó al nivel de la semana anterior a las 3:00 p. m. del 4 de julio. El periodo de efecto notificado fue de 61 horas y 25 minutos, en todo Japón. [1][5][7]
• La interrupción iniciadora fue mucho más breve. Durante el mantenimiento de un router de la red de transporte nacional en el centro de red Tama, una configuración de ruta incorrecta interrumpió el tráfico durante aproximadamente quince minutos. La reversión del ajuste no puso fin al incidente. [1][5]
• Los dispositivos y equipos volvieron a enviar reiteradamente solicitudes de registro de ubicación. Los nodos VoLTE se saturaron, el procesamiento distribuido extendió la presión a otros sitios, y el tráfico de autenticación repetido sobrecargó la base de datos de abonados. [1][5][9]
• KDDI estimó que unos 22,78 millones de usuarios de voz y al menos 7,65 millones de usuarios de datos se vieron afectados en una base no consolidada. Incluyendo a Okinawa Cellular, las estimaciones fueron de unos 23,16 millones de usuarios de voz y al menos 7,75 millones de usuarios de datos. Son estimaciones de impacto del servicio, no recuentos de personas únicas. [1][5][14]
• La respuesta de noviembre ante la guía administrativa indica que el trabajo utilizó un documento de procedimiento incorrecto, y que los controles de aprobación y rollback requerían revisión; el control automático de congestión fue insuficiente, el estado de respaldo dañado afectó algunos reinicios y las inconsistencias de sesión de abonados complicaron la recuperación. [8][9]
• El acta oficial de la Dieta indica que 119 volúmenes de llamadas originadas en KDDI estaban alrededor de un 63 por ciento por debajo de lo normal y 110 volúmenes de llamadas de un 45 por ciento por debajo de lo normal durante el incidente, mientras otras rutas transportaban más llamadas. Son cambios de volumen observados, no prueba de que cada llamada de emergencia intentada falló. [20]
• KDDI anunció reembolsos con condiciones y reembolsos por disculpa y estimó un efecto financiero de aproximadamente 7,5 mil millones de yenes. Las cuentas de reembolso, estimaciones de impacto de servicio, suscripciones y personas únicas deben mantenerse como medidas separadas. [1][11]
• La responsabilidad no termina con identificar un ajuste incorrecto. Continúa con el control práctico sobre la custodia del procedimiento, la revisión experta, la evidencia de aprobación, el tiempo de rollback, las pruebas de estado anómalo, la observabilidad de la congestión, la integridad de copias de seguridad, la recuperación del estado de abonados y la prueba de restauración específica por servicio.
• KDDI publicó muchas medidas correctivas, incluyendo controles de procedimiento más estrictos, herramientas de congestión, control de flujo habilitado, cambios de topología, automatización de recuperación, mejoras de gobernanza de calidad y mejoras de comunicación. La publicación de una medida es evidencia de un compromiso o una afirmación de implementación, no prueba independiente de que se eliminó toda clase de fallo relevante. [9][10][15][17]
• El posterior servicio de roaming de emergencia de Japón crea una vía alternativa durante grandes caídas. Debe evaluarse como un control de resiliencia acotado, no como sustituto de corregir la fragilidad dentro de la propia red del operador ni como política causada únicamente por este evento. [22]

El primer hecho de responsabilidad es la diferencia temporal

La cronología pública de KDDI contiene dos relojes muy distintos.

El primer reloj cubre la interrupción de enrutamiento inicial. Durante el mantenimiento de un router en la red de transporte nacional, una configuración de ruta incorrecta provocó que parte del tráfico que atravesaba ese router se detuviera. KDDI describe la interrupción como de aproximadamente quince minutos. La configuración se revirtió. [1][5]

El segundo reloj cubre el efecto en clientes y servicios. KDDI indica que la caída de comunicación comenzó el sábado 2 de julio de 2022 a la 1:35 a. m. Dice que el uso de voz y datos volvió a un nivel comparable con el mismo periodo de la semana anterior el lunes 4 de julio a las 3:00 p. m. Esto equivale a 61 horas y 25 minutos. El 5 de julio se comunicó una revisión adicional de uso y normalidad del tráfico a nivel agregado. [1][7]

Llamarlo error de enrutamiento de 61 horas sería falso. Llamarlo una caída de quince minutos también sería falso.

El error de ruta fue el disparador. El incidente prolongado fue un problema de recuperación que implicó carga de señalización, nodos VoLTE, autenticación de abonados, estado inconsistente, material de respaldo dañado y decisiones operativas sobre qué componentes aislar y cuándo. La distinción es central porque la responsabilidad por un disparador y la de la amplificación no son necesariamente idénticas.

Un operador puede cometer un cambio incorrecto y aún contenerlo con rapidez si el cambio está acotado, los supuestos de rollback son realistas y los sistemas aguas abajo toleran la fallibilidad temporal. También puede hacer un error de corta duración que crea una condición persistente en otra parte. Los dispositivos reintentan. Las colas crecen. Las bases de datos reciben consultas repetidas. El estado replicado diverge. Las propias acciones de recuperación agregan carga. Los componentes reinician en estado anómalo. La observabilidad se degrada porque todas las alarmas se activan a la vez.

La pregunta de rendición de cuentas, por tanto, no es meramente: ¿quién introdujo el ajuste incorrecto?

Es:

• ¿Quién aprobó el trabajo y con qué evidencia?
• ¿Qué modelo de impacto fijó el límite de rollback?
• ¿Qué comportamientos descendentes se habían probado?
• ¿Qué telemetría mostró que el rollback no había restaurado el servicio?
• ¿Quién tenía autoridad para aislar nodos y aliviar la carga?
• ¿Qué estado conocido y bueno estaba disponible para recuperar?
• ¿Qué pruebas de servicio definieron la restauración?

Una indagación centrada en culpables tiende a reducir esta cadena a la persona más cercana a la terminal de comando. Una indagación centrada en control examina las instituciones que diseñaron el trabajo, aprobaron el riesgo, construyeron el comportamiento de estado anómalo y decidieron cuándo podía informarse al cliente que el servicio estaba restaurado.

El informe propio de respuesta regulatoria de KDDI apunta en esa dirección. Describe la gestión documental de procedimientos, verificaciones expertas, evidencia de aprobación, criterios de rollback, diseño de congestión, procedimientos de recuperación y gobernanza de calidad. [9] Por ello, el propio relato del operador respalda una lección más amplia: un cambio de red no es el golpe de teclado de un solo técnico. Es un objeto de control organizativo.

Cómo un cambio de ruta se convirtió en una cascada de señalización

El servicio móvil depende de una gran cantidad de señalización que los clientes no ven.

Un teléfono debe establecer que está adjunto a la red y registrar el área en la que puede ser localizado. Un servicio de voz con VoLTE necesita que la red sepa dónde está registrado el abonado y qué funciones de control pueden establecer una llamada entrante o saliente. El servicio de datos también depende de la autenticación de abonados y del estado de sesión. Estas operaciones implican mensajes entre dispositivos, funciones de red móvil, nodos VoLTE y bases de datos de abonados.

Bajo condiciones normales, esa señalización es una fracción pequeña del valor que percibe el cliente. El servicio visible es una llamada, mensaje o sesión de datos. El prerrequisito oculto es una secuencia de registros, autenticaciones, políticas y enrutamientos exitosos.

La versión técnica de KDDI dice que la configuración de ruta incorrecta hizo que las solicitudes de registro de ubicación se abandonaran. Los dispositivos y equipos volvieron a enviarlas. Las retransmisiones aumentaron rápidamente. Los nodos VoLTE en Tama se congestionaron, y el procesamiento distribuido por la red de transporte nacional extendió la presión a nodos VoLTE de otros sitios. [1][5]

Luego la base de datos de abonados pasó a formar parte de la cascada. KDDI explica que los nodos VoLTE y los equipos de red móvil consultan la base de datos para autenticación. La señalización repetida creó, por tanto, tráfico de base de datos repetido. El sistema no tenía simplemente demasiadas llamadas de clientes; tenía demasiadas peticiones de control generadas por registro incompleto y comportamiento de reintento.

Esta distinción importa para ingeniería y rendición de cuentas.

La planificación de capacidad ordinaria puede preguntar cuántas llamadas simultáneas, sesiones de datos o abonados puede soportar un nodo. La planificación de estado anómalo pregunta cómo se comporta el sistema cuando los mensajes fallan a mitad de una transacción y son reintentados por millones de dispositivos. Esta última puede producir una forma de carga distinta de la demanda máxima de clientes.

Un mecanismo de reintento suele ser una característica de fiabilidad. Protege a usuarios de un paquete perdido o una interrupción temporal. A escala nacional, reintentos sincronizados o insuficientemente acotados pueden convertirse en multiplicador de carga. Una solicitud falla; el dispositivo lo intenta de nuevo; la función de red lo intenta otra vez; la base de datos observa tráfico de autenticación repetido; respuestas lentas mantienen más transacciones abiertas, y la cola creciente produce más tiempos de espera y reintentos.

Por eso, el fallo atraviesa varias superficies de control:

1. Control de enrutamiento:si el tráfico alcanza la ruta prevista.
2. Control de reintento:cómo reaccionan dispositivos y sistemas cuando las respuestas esperadas no llegan.
3. Control de admisión:si los nodos saturados rechazan, retrasan o modelan de forma segura el trabajo nuevo.
4. Protección de base de datos:si autenticación y sistemas de estado de abonados limitan demanda repetida.
5. Control de distribución:si el reparto de carga contiene el fallo o lo propaga.
6. Control de recuperación:si los responsables pueden identificar y aislar las fuentes de señalización excesiva.

KDDI indica que se aplicaron controles de tasa de flujo para reducir la congestión de la base de datos, pero la señalización excesiva continuó. Finalmente separó seis de los dieciocho nodos VoLTE asociados a las solicitudes anómalas persistentes. [1][5]

Ese acto ilustra una compensación de recuperación difícil. Quitar capacidad puede reducir carga dañina si nodos concretos la generan, pero también deja menos capacidad para el servicio legítimo. La decisión requiere telemetría fiable y autoridad. Los responsables deben saber si un nodo es víctima de congestión aguas abajo, fuente de solicitudes repetidas o ambos.

El registro público no revela cada ruta de paquete, temporizador o umbral. Sí establece que el comportamiento de estado anómalo del sistema fue decisivo. El incidente pertenece a la rendición de cuentas de infraestructura de red porque el daño siguió la interacción de enrutamiento de transporte, control de señalización, funciones de voz y estado de abonados.

Por qué revertir la ruta no fue recuperación

El rollback se trata a menudo como la respuesta más segura ante un cambio fallido. El incidente de KDDI muestra por qué esa suposición necesita un límite.

Revertir una configuración puede restablecer la condición que existía antes del cambio. No puede borrar automáticamente el estado creado mientras el cambio estuvo activo.

Durante la interrupción, dispositivos y sistemas experimentaron registros incompletos y generaron reintentos. Las colas y la carga de la base de datos cambiaron. Algunos nodos entraron en congestión. La información de sesión de abonados quedó inconsistente. En la respuesta posterior de KDDI se señala que algunos nodos VoLTE cargaron ficheros de respaldo dañados y reiniciaron en condición anómala, lo que provocó nuevos reintentos de registro de ubicación. [9]

La red después del rollback, por tanto, no era la red de antes del cambio.

Esta es una propiedad general de infraestructura con estado. Una entrada de ruta sin estado puede restaurarse rápido, pero los servicios dependientes de esa ruta pueden retener:

• transacciones pendientes;
• temporizadores de reintento;
• sesiones obsoletas;
• réplicas inconsistentes;
• estado de autenticación parcial;
• colas corruptas;
• fallos en caché;
• procesos sobrecargados;
• acciones de recuperación ya en curso.

Los planes de cambio deben distinguir rollback de configuración de rollback de servicio.

Una prueba de rollback de configuración pregunta si se restauró la configuración antigua. Una prueba de rollback de servicio pregunta si los usuarios pueden volver a registrarse, autenticarse, hacer llamadas y establecer sesiones de datos sin error o carga anómala. Una prueba de rollback de estado pregunta si bases de datos, colas, cachés y copias de respaldo de nodos son coherentes para sostener ese servicio.

Esas pruebas pueden producir respuestas distintas al mismo tiempo.

Las medidas publicadas por KDDI incluyen revisar el tiempo permitido antes del rollback para tener en cuenta la congestión en servicios aguas abajo. [9] Eso sí es un cambio de control significativo. Reconoce que esperar demasiado puede permitir que una condición inicialmente reversible cree una crisis de estado con memoria.

Sin embargo, un umbral de rollback más temprano no es suficiente por sí solo.

El operador también necesita un modelo de lo que puede acumularse durante el intervalo permitido. ¿Cuántos reintentos de registro pueden generarse? ¿Qué base de datos llega primero a saturación? ¿Qué porción de red puede aislarse? ¿Qué servicio permanece disponible durante el aislamiento? ¿Qué ocurre cuando la ruta vuelve pero millones de dispositivos reintentan a la vez?

El plan de recuperación debería definir disparadores basados en salud del servicio, no solo en estado de router:

• pérdida repentina de éxito de registro;
• crecimiento de solicitudes incompletas;
• profundidad de cola en nodos VoLTE;
• tiempo de respuesta de base de datos de abonados;
• tasa de rechazo de autenticación;
• volumen de reintentos por región o nodo;
• establecimiento y finalización de llamadas;
• establecimiento de sesiones de datos;
• éxito en llamadas de emergencia.

El rollback sigue siendo esencial. La lección es que su alcance debe coincidir con el sistema.

Para una red móvil nacional con estado, "la ruta antigua está de nuevo" es un hecho técnico intermedio. No es un certificado de restauración.

Un documento de procedimiento es parte del plano de control de producción

El informe de KDDI de noviembre indica que se utilizó un procedimiento de trabajo incorrecto. Describe revisiones en la gestión documental de procedimientos, revisión experta y aprobación del trabajo. [9]

Esto puede parecer administrativo. Es concreto en términos operativos.

El comando introducido durante el mantenimiento se genera mediante una cadena:

• un resultado de red previsto;
• una solicitud de diseño o cambio;
• una plantilla de procedimiento;
• instrucciones específicas por dispositivo;
• revisión de pares o experta;
• aprobación;
• programación;
• ejecución;
• verificación;
• rollback.

Si se puede seleccionar el procedimiento incorrecto, el sistema de producción queda expuesto antes de que alguien inicie sesión en el router. La custodia del documento forma parte, por tanto, del plano de control.

Un sistema procedimental fiable debería responder:

• ¿Qué plantilla era la autorizada?
• ¿Qué modelo de red y versión de software asumía?
• ¿Quién creó y revisó las instrucciones finales?
• ¿Qué cambió respecto de la última versión aprobada?
• ¿Qué dispositivo o topología cubría el procedimiento?
• ¿Qué evidencia mostró que los resultados de simulación o laboratorio coincidían con producción?
• ¿Qué clase de riesgo y nivel de aprobación se aplicó?
• ¿Qué comprobaciones debían superarse antes del siguiente paso?
• ¿Cómo se detendría o revertiría el procedimiento?

La palabra importante es evidencia.

Una segunda revisión puede volverse ceremonial si el revisor ve solo un documento final sin el estado previsto, topología, diferencia o resultados esperados. La aprobación puede volverse ceremonial si el aprobador ve una casilla marcada en vez de las consecuencias del fallo.

KDDI dice que cambió el proceso para que el personal con conocimientos revise procedimientos, conserve evidencia de esa revisión y permita que los aprobadores confirmen esa evidencia. También describió trabajo sobre un sistema de gestión de procedimientos. [9]

Esas medidas deben evaluarse por lo que previenen.

Un sistema de gestión debe dificultar:

• usar un procedimiento para la clase de dispositivo incorrecta;
• ejecutar una versión obsoleta;
• omitir la revisión experta requerida;
• aprobar una secuencia de comandos no probada;
• cambiar instrucciones tras la aprobación sin invalidar esa aprobación;
• seguir cuando los resultados esperados difieren;
• perder el registro de lo que realmente se ejecutó.

El trabajo de alto impacto también necesita una capa verificable por máquina en la medida de lo práctico. Los cambios de ruta previstos pueden compararse con la topología y las políticas. Las diferencias de configuración pueden validarse con linting. Pruebas de laboratorio o gemelos digitales pueden ejercer rutas esperadas y anómalas. Probes pre y post-cambio pueden automatizarse. Los límites pueden impedir comandos que toquen más nodos o prefijos de los autorizados.

La automatización no elimina la responsabilidad humana. Cambia la evidencia disponible para los humanos.

El operador sigue siendo responsable de decidir qué debe probar el control automático, cómo se autorizan excepciones y qué ocurre cuando el estado observado difiere del plan. Un sistema que confirme solo sintaxis puede seguir aprobando una ruta semánticamente peligrosa.

El evento de KDDI vuelve visible la gobernanza del procedimiento como gobernanza de infraestructura. El documento no fue un papel periférico a la red. Fue la descripción ejecutable de la autoridad operativa.

La clasificación de riesgo debe seguir el radio de impacto, no la familiaridad del mantenimiento

Una tarea rutinaria puede comportar riesgo excepcional.

Un trabajo puede ser familiar para un equipo experimentado, usar un comando conocido y darse en una ventana de mantenimiento programada. Ninguno de esos hechos determina el impacto potencial al cliente.

KDDI dice que revisó la evaluación de riesgo de trabajo y los niveles de aprobación según la escala de daño si una tarea fallaba. También amplió periodos en los que cierto trabajo se suprimiría alrededor de eventos importantes. [9]

Este es un giro importante: de la probabilidad sola a la consecuencia.

La clasificación de riesgo para un router de transporte nacional debería considerar:

• el número y tipo de servicios que lo atraviesan;
• si el fallo puede afectar registro o autenticación;
• cómo se propagan los reintentos;
• si la distribución de carga propaga el fallo;
• la independencia de rutas redundantes;
• dependencias de llamadas de emergencia;
• dependencias de MVNO y empresa;
• la capacidad de observar y aislar el cambio;
• el tiempo antes de que el estado sea difícil de recuperar;
• la capacidad de fallback probada.

Un cambio con baja probabilidad estimada de error puede exigir el máximo nivel de aprobación y pruebas si su fallo puede crear daño común a escala nacional.

La clasificación también debe contemplar el riesgo temporal. Una ventana elegida por bajo tráfico ordinario no necesariamente minimiza el riesgo de señalización. Muchos dispositivos pueden reaccionar a un fallo al mismo tiempo independientemente de que la gente esté haciendo llamadas activas. Una hora tranquila en uso del cliente no siempre es una hora tranquila para tormentas de registro.

Del mismo modo, un calendario de supresión por eventos es solo un control. Grandes eventos públicos, clima severo o elecciones pueden aumentar las consecuencias de una caída, pero las noches ordinarias siguen teniendo llamadas de emergencia, logística, dispositivos conectados, operaciones de transporte y atención esencial.

El control más fuerte es un presupuesto explícito de radio de impacto.

Antes de iniciar el trabajo, el operador debería declarar:

• máximo de nodos afectados;
• máximo de geografía afectada;
• máxima interrupción de servicio;
• máximo de fallos de registro;
• máximo de tiempo a rollback;
• máximo de tiempo de recuperación aguas abajo;
• condiciones que exijan aislamiento inmediato;
• capacidad de respaldo disponible durante el trabajo.

Las métricas observadas deberían compararse con ese presupuesto en tiempo real. Si el cambio supera cualquier límite, la continuación debería requerir autoridad nueva en lugar de suponer que la aprobación original sigue vigente.

Este enfoque convierte el "mantenimiento rutinario" en un experimento acotado. Reconoce que el público no experimenta la familiaridad de la tarea. Experimenta si la red funciona.

El control de congestión debe probarse en el estado que crea el fallo

El informe de KDDI dice que el control automático de congestión no funcionó como se requería durante la condición anómala. Más tarde habilitó o revisó funciones de control de flujo, desarrolló herramientas de detección más detalladas y cambió el diseño de tráfico y capacidad VoLTE pertinente. [9][10]

El control de congestión no puede evaluarse solo bajo carga alta ordinaria.

El tráfico pico normal contiene muchas solicitudes válidas con temporización y distribución esperadas. Un incidente puede producir solicitudes repetidas, incompletas o correlacionadas. Puede enviar media transacción por una ruta y perder la respuesta. Puede concentrar carga en componentes que el reparto normal distribuye con uniformidad. Puede hacer que varias funciones de red reintenten contra la misma base de datos de abonados.

Por eso las pruebas deberían incluir semántica de fallo:

• pérdida parcial de ruta;
• alcance asimétrico;
• respuestas retrasadas;
• solicitudes duplicadas;
• reintentos de dispositivos sincronizados;
• fallo de una de dos rutas;
• latencia e inconsistencia de base de datos;
• reinicio de nodos en alta carga;
• monitorización perdida;
• contenido de herramientas de recuperación.

El objetivo es degradación gradual.

Cuando una red no puede atender cada solicitud, debería proteger funciones de control esenciales y preservar capacidad suficiente para recuperar. Puede rechazar trabajo temprano, aplicar retroceso, separar regiones, priorizar servicio de emergencia o aislar un dominio defectuoso.

KDDI informó que cambió un esquema VoLTE relevante de una configuración de malla nacional completa a un diseño separado este-oeste y habilitó una función de regulación de flujo para reducir la probabilidad de propagación de congestión. [9]

El principio es contención de fallos.

La distribución puede mejorar la resiliencia cuando crea capacidad independiente. Puede empeorarla cuando cada nodo participa del mismo fallo. Una malla completa puede ofrecer muchas rutas normales mientras permite que la señalización anómala se propague nacionalmente. La separación regional puede sacrificar algo de flexibilidad a cambio de un dominio común de fallo más pequeño.

El informe público no prueba la topología completa actual ni el resultado de cada prueba. Sí identifica una pregunta de remediación medible:

Si se repite ahora la misma pérdida de ruta parcial, ¿cuántos nodos, regiones y abonados pueden entrar en congestión antes de que se activen los límites de control?

Una respuesta con responsabilidad incluiría condiciones de prueba, umbrales observados, comportamiento de rechazo, rendimiento de servicio de emergencia y tiempo máximo para aislar el dominio afectado.

Sin esa evidencia, "hemos cambiado la topología" es una declaración de diseño. Con ella, el cambio se convierte en control de resiliencia.

La integridad de las copias de seguridad y el estado de abonados pertenecen a la planificación de caídas

Las copias de seguridad suelen tratarse como control de ciberseguridad o prevención de pérdida de datos. La respuesta de KDDI muestra su papel en la disponibilidad de red.

El informe de noviembre dice que algunos nodos VoLTE leyeron ficheros de respaldo dañados y arrancaron en una condición anómala. También describe inconsistencias de sesión de la base de datos de abonados. [9]

Eso vuelve central la procedencia del estado de recuperación.

Un nodo de red no recupera solo porque se reinicia. Recupera cuando el software, la configuración y el estado operativo cargados en el reinicio son conocidos, buenos y compatibles con el resto del sistema.

Un proceso de recuperación confiable debería establecer:

• cuándo se creó la copia;
• qué versiones de software y configuración contiene;
• si se produjo durante congestión o fallo parcial;
• si su integridad fue verificada;
• si es coherente con nodos pares y estado de abonados;
• quién autorizó su uso;
• qué pruebas de servicio superó tras la carga.

Las copias de seguridad creadas automáticamente durante un incidente pueden preservar ese incidente.

Si un nodo escribe un estado anómalo y ese estado pasa a ser la siguiente imagen de recuperación, reiniciar puede reproducir la falla. Si las bases de datos de abonados replicadas divergen, restaurar una copia puede invalidar sesiones o provocar más registros. Si los responsables no pueden determinar qué estado es autorizador, cada acción correctiva incorpora nuevo riesgo.

La respuesta no es eliminar el respaldo automatizado. Es distinguir puntos de control operativo de puntos de recuperación validados de forma independiente.

Las funciones críticas de red deberían disponer de:

• configuración conocida y confiable inmutable o protegida contra escritura;
• manifiestos de software y configuración firmados;
• comprobaciones de coherencia sobre estado replicado;
• cuarentena para copias creadas durante condiciones anómalas;
• procedimientos de reinicio probados;
• una vía de gestión limpia;
• reinicio por fases con sondas de servicio;
• rollback explícito desde la acción de recuperación misma.

KDDI dice que revisó procedimientos de reinicio de nodos y desarrolló herramientas para detectar y aliviar congestión en múltiples nodos VoLTE. [9] Esas medidas abordan la rapidez de recuperación. La obligación de evidencia es demostrar que también protegen la integridad del estado.

Para un operador móvil, configuración, estado de abonados y autoridad de recuperación son todos activos de disponibilidad. Una copia de seguridad que no es confiable bajo estrés no constituye inventario de resiliencia.

Las cifras de impacto necesitan interpretación disciplinada

Los incidentes grandes producen varias cifras grandes. Responden preguntas distintas.

KDDI estimó unos 22,78 millones de usuarios de voz afectados y al menos 7,65 millones de usuarios de datos afectados en base no consolidada. Con Okinawa Cellular incluido, las estimaciones fueron de unos 23,16 millones de usuarios de voz y al menos 7,75 millones de usuarios de datos. El operador explica que las estimaciones de voz y datos usan métodos distintos basados en diferencias de llamadas o registros frente a un periodo de comparación. [1][5][14]

Estas cifras no deben sumarse para reclamar más de treinta millones de personas únicas.

Una persona puede usar voz y datos. Una cuenta puede contener varias líneas. Una estimación de impacto de datos basada en diferencias de registro no es idéntica a un recuento de clientes que intentaron y fallaron en una sesión. "Afectado" puede cubrir degradación, intermitencia o indisponibilidad y no una condición uniforme.

Las cifras de reembolso responden otra pregunta.

KDDI anunció reembolsos por condiciones para 2,71 millones de clientes de KDDI y 70.000 clientes de Okinawa Cellular que cumplieron condiciones de servicio específicas. También anunció un reembolso de disculpa de 200 yenes para 35,89 millones de clientes de KDDI y 660.000 de Okinawa Cellular en clases de servicio cubiertas. [1]

Esas poblaciones reflejan decisiones contractuales y de política. No son una medida técnica del impacto simultáneo del fallo.

El efecto financiero de aproximadamente 7,5 mil millones de yenes divulgado por KDDI es otra medida más. [11] Captura la consecuencia empresarial esperada bajo sus supuestos contables y de reembolso. No mide cada transacción perdida, cada contacto de emergencia fallido, entrega retrasada, dispositivo conectado interrumpido o costo de tiempo del cliente.

Un informe de impacto sólido conserva las cuatro dimensiones:

1. Impacto de servicio:qué funciones estaban indisponibles o degradadas.
2. Uso observado:llamadas, registros y transacciones comparados con la normalidad.
3. Remedio para clientes:qué cuentas calificaron para qué reembolso.
4. Consecuencia económica:coste directo del operador y pérdida social más amplia.

Inflar una cifra debilita el análisis. La conclusión sólida no necesita inflarse.

El incidente fue nacional, prolongado y con consecuencias porque una falla de control central afectó servicios móviles críticos y los sistemas que dependían de ellos. La medición exacta debe hacer más creíble esa conclusión, no menos dramática.

Las llamadas de emergencia convierten la disponibilidad en deber público

Las caídas móviles se convierten en eventos de seguridad pública cuando la gente no puede llegar con fiabilidad a servicios de emergencia.

El registro oficial de la Dieta aporta evidencia concreta. Dice que los volúmenes de llamadas 119 desde KDDI estaban alrededor de un 63 por ciento por debajo de lo normal durante el incidente. Las llamadas desde móviles no KDDI y otras rutas aumentaron. Dice que los volúmenes de llamadas 110 desde KDDI estaban alrededor de un 45 por ciento por debajo de lo normal, mientras las llamadas de otros operadores y teléfonos públicos aumentaron. [20]

Esos datos exigen lenguaje cuidadoso.

Muestran un gran cambio en volúmenes de llamadas observadas por vía de origen. No revelan cada llamada intentada, la intención del llamante, si un dispositivo mostró error, si cada llamada alternativa conectó o el resultado de cada emergencia.

Sin embargo demuestran dependencia.

Cuando una red móvil nacional falla, la demanda de emergencia no desaparece. Algunos usuarios toman otro teléfono, usan un fijo o acuden a un teléfono público. Otros pueden no tener alternativa. La carga adicional en redes sobrevivientes y centros de atención puede convertirse en riesgo secundario.

La continuidad de llamadas de emergencia necesita evidencia más allá de la disponibilidad ordinaria de voz:

• configuración de llamada a 110, 118 y 119;
• gestión de localización del llamante;
• capacidad de devolución de llamada;
• priorización y tratamiento de congestión;
• acceso desde MVNO;
• accesibilidad para personas con discapacidad;
• rendimiento geográfico;
• instrucciones de usuario cuando falla la red principal;
• carga transferida a redes alternativas.

KDDI describe en su respuesta una comunicación más fuerte con organismos de llamadas de emergencia y participación en trabajo sobre comunicaciones alternativas y roaming inter-operador. [9][10]

Esos controles abordan problemas distintos.

Mejor notificación ayuda a autoridades y usuarios a comprender la falla. Las rutas alternativas ayudan a que las llamadas salgan de la red fallida. Ninguna de las dos elimina la responsabilidad del operador de mantener resiliente su propia vía de llamada de emergencia.

El estándar de rendición de cuentas pública debería ser proporcional a la consecuencia. Un operador puede reportar restauración comercial de voz mientras ubicación, callback o congestión de emergencia siguen deteriorados. La matriz de servicio debe aislar la funcionalidad de emergencia en vez de tratarla como una sola fila dentro del tráfico total de voz.

El control práctico estuvo dividido, pero no de forma uniforme

Los incidentes de red involucran muchos actores. La responsabilidad debe seguir lo que cada uno pudo prevenir, detectar, limitar, divulgar o reparar.

KDDI

KDDI controló el proceso de mantenimiento, la custodia del procedimiento, la aprobación del trabajo, la configuración de ruta, los criterios de rollback, la monitorización de red, operación de nodos VoLTE, recuperación de la base de datos de abonados, medición de servicio, comunicación con clientes y evidencia enviada al regulador.

Eso no significa que KDDI controlara cada comportamiento de producto o pudiera prevenir cada fallo. Significa que el operador sostuvo la autoridad práctica más amplia sobre el entorno de producción y la recuperación.

Proveedores de equipos y software

Los proveedores pueden haber controlado software de nodos, comportamiento de base de datos, características de reintento, documentación de alta carga, formatos de respaldo y soporte técnico. La respuesta de KDDI dice que obtuvo información de proveedores y probó el comportamiento bajo alta carga. [9]

El registro congelado no revela el mapa completo de proveedores, contratos o hallazgos de defectos. Sería irresponsable atribuir culpa a un proveedor nombrado. La exigencia de responsabilidad es que el operador conozca qué evidencia del proveedor necesita y mantenga autoridad para proteger el servicio cuando un producto se comporta de forma inesperada.

Ministerio y organismos de revisión

El Ministerio de Asuntos Internos y Comunicaciones recibió el informe de accidente grave, emitió la guía administrativa y usó estructuras de revisión para examinar el incidente y problemas más amplios de accidentes de telecomunicaciones. [3][8][9][21]

La autoridad regulatoria incluye exigir evidencia, fijar expectativas de reporte y desarrollar reglas de resiliencia del sector. No opera los routers de KDDI ni recupera el estado de abonados.

Servicios de emergencia, MVNO y empresas

Estos actores sostienen evidencia de dependencia e impacto. Un MVNO puede observar la incapacidad de sus usuarios para adjuntarse o llamar. Una empresa puede reportar dispositivos conectados o funciones logísticas fallidas. Organismos de emergencia pueden medir cambios de llamadas y localizaciones.

No controlan el núcleo de KDDI fallido. Su planificación de continuidad puede reducir daño, pero no transfiere la responsabilidad primaria de infraestructura fuera del operador.

Clientes

Los usuarios pueden mantener métodos alternativos de contacto donde sea práctico, pero muchos no pueden duplicar económicamente un servicio móvil nacional. Los teléfonos públicos, Wi-Fi, un segundo operador o una línea fija pueden ayudar. Son mitigaciones acotadas, no una respuesta justa a una caída sistémica central.

Esta asignación evita dos errores.

El primero es culpar a la persona o componente más cercano para un sistema definido por muchas decisiones de control. El segundo es dispersar tanto la responsabilidad que ninguna institución quede a cargo.

KDDI llevó la carga de responsabilidad más fuerte para mostrar por qué un problema de enrutamiento breve se convirtió en un incidente nacional prolongado y cómo ahora esa cadena está acotada.

La remediación debe probarse como un paquete de evidencia enlazado

KDDI publicó un programa de correcciones sustancial. El informe de noviembre y las divulgaciones posteriores describen:

• gestión más estricta de documentos de procedimiento;
• revisión experta con evidencia preservada;
• métodos revisados de aprobación;
• criterios más claros de normalidad de servicio;
• tiempo de rollback que considere congestión;
• clasificación de riesgo de trabajo basada en impacto;
• reglas de supresión de trabajo más amplias;
• herramientas detalladas de detección de congestión;
• cambios de ruta de tráfico y topología;
• control de flujo habilitado;
• inspección de otros sistemas móviles por modos de fallo similares;
• procedimientos de reinicio y recuperación revisados;
• herramientas multi-nodo de alivio de congestión;
• cambios de gobernanza de calidad;
• ejercicios a gran escala;
• comunicación pública y con partes interesadas mejorada. [9][10][15][17]

La lista es significativa. No debe confundirse con prueba por enumeración.

Los controles interactúan. Un proceso de procedimiento más sólido puede prevenir el mismo error de ruta pero no un comando semánticamente distinto. El control de flujo puede proteger nodos VoLTE pero no otro sistema con comportamiento de reintento similar. La separación regional puede reducir propagación y dejar intacta una base de datos compartida o una identidad de gestión común. Una herramienta de recuperación puede actuar más rápido pero cargar el mismo estado no confiable.

El paquete de remediación debe conectar cada fallo observado con un control y una prueba:

La evidencia debe ser actual y vinculada a despliegue.

Una política aprobada tras el incidente no prueba que la red de producción la implemente. Una prueba de laboratorio de una versión de software no prueba una topología posterior. Un registro de asistencia a formación no prueba que los operadores puedan aislar nodos bajo telemetría ambigua.

La evidencia útil incluye:

• versiones de procedimiento firmadas;
• registros de aprobación;
• hashes de configuración y topología;
• manifiestos de prueba;
• resultados de inyección de fallos;
• sondas por servicio;
• mediciones de tiempo de recuperación;
• registros de excepciones;
• revisión independiente;
• decisiones de riesgo residual.

El dilema no es secreto absoluto frente a divulgación total. KDDI puede mantener privada la sintaxis de comandos, credenciales y topologías sensibles mientras publica clase de fallo, objetivo de control, alcance de prueba y resultado de aseguramiento.

Para un operador nacional, la reparación duradera debería ser legible para reguladores, ejecutivos, equipos técnicos y clientes críticos. Debe seguir siendo comprensible cuando cambien personal y proveedores.

La etiqueta \"restaurado\" necesita una matriz específica por servicio

KDDI utilizó niveles de tráfico comparados con el mismo periodo de la semana anterior como parte de su confirmación de recuperación. [1][7]

Eso es útil e incompleto.

El tráfico agregado puede volver mientras transacciones importantes siguen degradadas. El volumen de datos puede parecer normal porque los usuarios que funcionan generan más tráfico, aunque ciertos dispositivos no puedan registrarse. Los minutos de voz pueden recuperarse mientras la configuración de llamadas falla en una región o la devolución de llamada de emergencia sigue afectada.

Una matriz nacional de restauración debería incluir:

Cada dominio debe disponer de umbrales funcionales y de capacidad.

La recuperación funcional significa que una transacción representativa termina con éxito. La recuperación de capacidad significa que el servicio soporta la carga esperada sin colas inestables o degradación repetida. La estabilidad significa que el resultado persiste. La remediación significa que la clase de fallo iniciadora se abordó y se reprodujo en prueba.

Esas etapas no deben compartir un único timestamp.

La observación independiente también es importante. Si el sistema de monitorización depende de la misma base de datos de abonados o del plano de gestión que se está recuperando, puede mostrar una vista parcial. Sondeos externos, mediciones de MVNO, operadores interconectantes, organismos de emergencia y transacciones muestreadas de usuarios aportan evidencia independiente.

La descripción actual de calidad de red de KDDI dice que las condiciones nacionales se monitorizan desde centros de operación y que aplica estándares de capacidad, redundancia y instalaciones distribuidas. [19] La pregunta de responsabilidad no es si esos controles generales existen, sino cómo midieron esta clase de fallo específica tras la remediación.

El objetivo no es negar la recuperación hasta que cada cliente confirme el servicio. Es definir un umbral estadística y operativamente creíble.

Cuando el público oye que \"la red volvió\", esa frase debe significar más que que el tráfico está creciendo. Debe significar que las funciones críticas superaron pruebas identificadas, la capacidad es estable y las excepciones residuales están visibles.

El roaming de emergencia es un respaldo, no absolución

En marzo de 2026, los principales operadores móviles de Japón anunciaron un servicio nacional de roaming de emergencia para grandes desastres y caídas. El servicio incluye un modo completo con voz, datos limitados y SMS, y un modo solo para llamadas de emergencia. [22]

Esto es evidencia de resiliencia posterior.

Crea una ruta alternativa cuando la red de un operador no está disponible. Puede reducir la probabilidad de que un cliente con una suscripción quede completamente aislado. También reconoce un hecho público expuesto por varios incidentes: la competencia minorista no garantiza que cada usuario tenga acceso redundante.

El servicio tiene límites.

Un operador alternativo debe tener cobertura y capacidad. Los dispositivos deben soportar el comportamiento requerido. El servicio de roaming puede ofrecer menor velocidad de datos. El modo solo de emergencia tiene funciones limitadas y no contempla retorno de llamada en la ruta saliente descrita. La activación exige coordinación e información pública. Un desastre puede afectar a varias redes a la vez.

El roaming de emergencia tampoco repara la red fallida.

No debe debilitar:

• los controles internos de cambio;
• la protección de congestión;
• la recuperación del estado de abonados;
• el diseño del servicio de emergencia;
• la evidencia de restauración;
• la responsabilidad del operador por la caída primaria.

El registro público no establece que el evento de KDDI de 2022 por sí solo causara el servicio de 2026. El registro de la Dieta muestra que el roaming interoperator se discutió tras grandes incidentes telecom y el lanzamiento posterior refleja trabajo multianual, multioperador y gubernamental. [20][22]

La visión de responsabilidad trata al roaming como una capa dentro de una cartera:

1. prevenir cambios inseguros;
2. contener el fallo dentro de la red principal;
3. recuperar un estado confiable;
4. preservar el servicio prioritario;
5. ofrecer una ruta alternativa independiente;
6. comunicar con claridad sus limitaciones.

El respaldo es más valioso cuando se prueba bajo las mismas condiciones de congestión y demanda pública que lo hacen necesario.

Lo que el registro público congelado no puede probar

Las fuentes sustentan un análisis de control detallado. No sostienen una postmortem privado completa.

No pueden probar:

• los comandos exactos de ruta;
• cada prefijo o ruta de paquete afectada;
• la identidad o proceso decisorio del operador que ejecutó el trabajo;
• la cadena completa de aprobación;
• el proveedor y versión de cada nodo o base de datos afectados;
• si un defecto de proveedor contribuyó;
• todos los temporizadores de reintento y umbrales de congestión;
• la disponibilidad por región;
• todas las llamadas de emergencia intentadas;
• el impacto completo de MVNO, roaming, IoT y empresa;
• la pérdida exacta de clientes;
• la configuración actual de producción;
• la eficacia independiente de cada remediación anunciada.

Esas lagunas no deben cubrirse con especulación.

Las preguntas abiertas pueden probarse con evidencia como:

• tickets de cambio versionados y diferencias de procedimiento;
• simulación de topología y políticas de ruta;
• telemetría de señalización por nodo;
• registros de coherencia de base de datos;
• hashes de respaldo y resultados de validación;
• registros de soporte de proveedores;
• sondas por servicio;
• informes de inyección de fallo;
• seguimiento regulatorio posterior.

La incertidumbre no es motivo para abandonar la rendición de cuentas. Define la solicitud de evidencia.

Una prueba reutilizable de responsabilidad en cambios de red móvil

El evento de KDDI sustenta un estándar práctico para trabajo telecom de alto impacto.

1. Vincular la intención a un cambio ejecutable.
La intención aprobada, el modelo de topología, el procedimiento, los objetivos de dispositivo y la diferencia de configuración exacta deben formar un único objeto versionado.

2. Hacer que la revisión experta sea evidencial.
El revisor debe ver el estado de red previsto, rutas anómalas esperadas, resultados esperados y condiciones de rollback, no solo una lista de comandos.

3. Clasificar por daño máximo.
La profundidad de aprobación debe seguir el impacto potencial de servicio, geografía, emergencias y efecto de modo común.

4. Definir un presupuesto de radio de impacto.
Antes de ejecutar, fijar máximo de nodos, regiones, usuarios, tiempo y estado aguas abajo.

5. Probar fallo parcial.
Ejercitar solicitudes descartadas, enrutamiento asimétrico, señalización duplicada, respuestas lentas y pérdida de una de dos rutas.

6. Proteger señalización e identidad.
Acuarar reintentos, admisión y demanda de base de datos para que una interrupción breve no se vuelva congestión autosostenida.

7. Crear dominios de fallo reales.
La distribución debe contener carga anómala, no solo repartir carga normal.

8. Hacer el rollback consciente del servicio.
Los criterios de rollback deben incluir registro, llamadas, datos y salud de base de datos, no solo la configuración de router restaurada.

9. Conservar estado conocido y bueno.
Software, configuración y recuperación esencial de abonados requieren integridad y procedencia independientes.

10. Dar autoridad limitada a los equipos de respuesta.
Los equipos deben saber cuándo pueden aislar nodos, aliviar carga, separar regiones y activar respaldo.

11. Definir restauración por transacción.
Medir separadamente registro, voz, llamadas de emergencia, datos, SMS, MVNO, IoT, empresa, roaming y funciones de soporte.

12. Observar desde fuera.
Usar sondeos y socios que no dependan del plano de control que se está reparando.

13. Recrear la clase de incidente.
Probar variantes semánticas del fallo, no solo el comando exacto que lo desencadenó.

14. Vincular remediación al estado desplegado.
Las políticas y diagramas deben apuntar a configuración actual, resultados de prueba, excepciones y decisiones de riesgo residual.

15. Mantener una ruta alternativa acotada.
Un roaming de emergencia, otro operador, red fija, Wi-Fi o teléfonos públicos pueden reducir daño, pero su capacidad y límites deben probarse y comunicarse.

16. Publicar una aseguración proporcionada.
Explicar qué falló, qué clase de control cambió, cómo se probó y qué sigue incierto sin exponer comandos o arquitectura sensibles.

Este estándar no exige que una red nacional nunca falle. Exige que la autoridad se ajuste al radio de impacto y que las afirmaciones de restauración puedan examinarse.

Conclusión

La caída de 61 horas de KDDI en julio de 2022 comenzó con una configuración de ruta incorrecta durante mantenimiento. La configuración se revirtió tras una interrupción breve. El incidente continuó porque la red cambió de estado.

Las solicitudes de registro de ubicación se repitieron. Los nodos VoLTE se congestionaron. El tráfico de autenticación de abonados creció. La base de datos de abonados se volvió sobrecargada e inconsistente. Parte del estado de recuperación se dañó. Se aislaron seis de dieciocho nodos mientras los equipos trabajaban para reducir la presión de señalización. Los clientes experimentaron un efecto declarado de 61 horas y 25 minutos en servicios de voz y datos a escala nacional. [1][5][9]

La lección responsable no es que una sola persona cometió un único error.

Es que un cambio de red nacional es una cadena de controles institucionales. La custodia del procedimiento, la revisión experta, la aprobación, el análisis de radio de impacto, el tiempo de rollback, el diseño de estado anómalo, la observabilidad de congestión, la integridad de respaldos, la autoridad de recuperación y la medición de servicio determinan si un error breve permanece breve.

KDDI publicó medidas correctivas en toda esa cadena. Esas medidas merecen reconocimiento y verificación. El servicio de roaming de emergencia posterior aporta una vía alternativa valiosa con límites claros. Ni una lista extensa ni una red de respaldo sustituyen evidencia de que la clase de fallo primaria quedó contenida.

Para infraestructura móvil crítica, restaurar la ruta anterior no basta. El operador debe demostrar que el sistema de señalización es estable, que el estado de abonados es confiable, que las llamadas esenciales funcionan, que el respaldo es real y que el próximo cambio de alto impacto no cruza la misma frontera sin detectarse.

Ese es el estándar de responsabilidad creado por las 61 horas después de que la ruta ya había vuelto.

Fuentes

1. https://www.kddi.com/english/important-news/20220729_01/
2. https://www.kddi.com/important-news/20220729_01/
3. https://news.kddi.com/kddi/corporate/english/ir-news/2022/08/05/6189.html
4. https://news.kddi.com/kddi/corporate/newsrelease/2022/07/29/6183.html
5. https://www.kddi.com/extlib/files/english/corporate/ir/library/presentation/2023/pdf/kddi_220729_e_shougai_qe3B6V.pdf
6. https://www.kddi.com/extlib/files/corporate/ir/library/presentation/2023/pdf/2023/220729-shougai.pdf
7. https://www.notice.kddi.com/news/mainte/content/syougai/fre_00034454.html
8. https://news.kddi.com/kddi/corporate/newsrelease/2022/11/02/6361.html
9. https://news.kddi.com/kddi/corporate/newsrelease/2022/11/02/pdf/press_20221102.pdf
10. https://news.kddi.com/kddi/corporate/english/ir-news/2022/11/02/pdf/kddi_221102_e_main_nQWHTi.pdf
11. https://news.kddi.com/kddi/corporate/english/ir-news/2022/07/29/pdf/kddi_220729_e_statement_full_jOLDLZ.pdf
12. https://www.kddi.com/english/corporate/ir/ir-library/sustainability-integrated-report/2022-online/
13. https://www.kddi.com/extlib/files/english/corporate/ir/ir-library/sustainability-integrated-report/2022-online/pdf/kddi_sir2022_e06.pdf
14. https://www.kddi.com/extlib/files/english/corporate/ir/ir-library/sustainability-integrated-report/pdf/kddi_sir2022_e_p.pdf
15. https://www.kddi.com/extlib/files/english/corporate/ir/ir-library/sustainability-integrated-report/pdf/kddi_sir2023_e_p.pdf
16. https://www.kddi.com/english/corporate/ir/ir-library/sustainability-integrated-report/2022-online/ceo_message_lookback/
17. https://newsroom.kddi.com/news/detail/kddi_pr-907.html
18. https://www.kddi.com/english/corporate/sustainability/governance/risk-management/
19. https://www.kddi.com/english/corporate/sustainability/society/network/
20. https://www.shugiin.go.jp/internet/itdb_kaigiroku.nsf/html/kaigiroku/009421020221027002.htm
21. https://public-comment.e-gov.go.jp/pcm/download?seqNo=0000251103
22. https://newsroom.kddi.com/english/news/detail/kddi_nr-958_4373.html