Resumen

  • DigitalOcean abrió un incidente crítico en MKC1 a las 11:10 UTC del 19 de agosto y restauró durante el día el plano de control regional y una amplia lista de servicios CPU y de plataforma.
  • Al marcarlo resuelto a las 19:34, la empresa aún indicaba que los GPU Droplets estaban afectados y que seguía recuperando nodos; las siguientes noticias para esos clientes pasaron a Slack y correo electrónico.

La palabra resolved cerró un expediente regional, no todos los trabajos de recuperación. Esa es la lectura precisa de la última actualización de DigitalOcean sobre MKC1: el estado cambió a resuelto, los servicios compartidos estaban sanos, pero la misma nota mantenía a los GPU Droplets entre los recursos afectados.

La secuencia comenzó a las 11:10:06 UTC. DigitalOcean informó de un problema en varias filas de racks y nodos de Kansas City, con posibles interrupciones en cargas GPU y nodos de trabajo de DigitalOcean Kubernetes, o DOKS, que podían pasar a NotReady. La plataforma asignó impacto crítico al incidente.

A las 12:22 la compañía dijo haber identificado la causa raíz y estar aplicando medidas correctivas. No explicó públicamente esa causa. La actualización sí amplió el mapa operativo: además de GPU y Serverless Inference, algunos nodos DOKS podían seguir sin estar listos, y ciertos clientes podían perder acceso a los endpoints de la API de Kubernetes o a las operaciones de administración de sus clústeres. A las 15:28 continuaba la restauración de conectividad y nodos, sin cifras de infraestructura ni clientes.

La situación cambió de forma desigual. A las 18:59, DigitalOcean declaró totalmente sano el plano de control regional. CPU Droplets, Managed Databases, Load Balancers, Block Storage y Spaces funcionaban con normalidad. También estaban disponibles la creación, el cambio de tamaño y otras operaciones de gestión de Droplets, y los planos de control DOKS eran accesibles.

La capacidad acelerada seguía otra trayectoria. Los GPU Droplets de MKC1 permanecían fuera de línea o eran inalcanzables; nodos GPU de DOKS podían continuar en NotReady; y endpoints de inferencia sustentados por GPU podían seguir sin servicio. DigitalOcean anunció que vigilaría brevemente el plano de control y cerraría el incidente regional. A partir de ese momento, la información para clientes GPU sería personalizada y circularía por Slack y correo, no por la página de estado.

El cierre llegó a las 19:34:54. La empresa volvió a enumerar los servicios generales que operaban normalmente, pero añadió que los GPU Droplets continuaban afectados y que sus equipos intentaban restaurar todos los nodos. Por eso, las 8 horas, 24 minutos y 48 segundos del registro público no equivalen a una caída uniforme de todos los productos. Son el intervalo administrativo de un incidente cuyo alcance se redujo y cambió a medida que se recuperaban capas distintas.

MKC1 se había estrenado solo quince días antes. El anuncio del 4 de agosto presentaba Kansas City como un centro de datos completamente refrigerado por líquido, con GPU NVIDIA B300 y una cartera conjunta de cómputo, Kubernetes, bases de datos, almacenamiento, red y funciones de aplicaciones. El incidente no demuestra que la refrigeración o los aceleradores provocaran el fallo. Sí convierte la respuesta en una primera prueba pública de puesta en servicio para una región donde el producto GPU forma parte central de la propuesta comercial.

La arquitectura de DOKS ayuda a interpretar la diferencia. El proveedor gestiona el plano de control; las cargas del cliente viven en nodos de trabajo. Recuperar la API y la gestión permite observar y dirigir el clúster, pero no devuelve por sí mismo un GPU alojado en un nodo que todavía aparece NotReady. DigitalOcean documenta una remediación automática capaz de reemplazar trabajadores, aunque es una función opcional en vista previa pública y depende de reglas, tiempos de gracia, acciones y límites de trabajos en curso. El expediente no dice que estuviera activada en los clústeres afectados.

También hay límites importantes. DigitalOcean afirmó conocer la causa y habló después de trabajo conjunto con la instalación, pero no publicó el mecanismo. No puede deducirse si fue electricidad, refrigeración, red, hardware, software u otra cosa. Tampoco hay número de clientes, hora pública de recuperación total de GPU, conclusión sobre pérdida de datos o integridad de cargas, ni plan detallado para evitar una repetición. El color operativo posterior de un componente no llena esos vacíos históricos.

La decisión útil para un operador es medir cada capa. Hay que comprobar el plano de control, el estado de los trabajadores, la asignación de aceleradores, la respuesta de los endpoints y los objetivos de la aplicación. El 19 de agosto, varias de esas señales volvieron antes que otras. El registro de DigitalOcean lo dice con suficiente claridad: la recuperación regional había cruzado su umbral de cierre, mientras la recuperación de una clase de infraestructura con alto valor y pocas sustituciones seguía en una cola aparte.

Fuentes