Resumen

  • DigitalOcean advirtió de errores al crear clústeres Managed Databases mediante el panel de control y la API; al principio usó un componente Global y dijo que había varias regiones afectadas.
  • Las actualizaciones de las 11:30 y las 14:33 UTC situaron la reparación y la resolución en NYC1 y NYC3, sin explicar si el alcance se había reducido, si otras regiones se recuperaron antes o si la etiqueta inicial era amplia.

El perímetro de un incidente no siempre se conoce cuando aparece la primera alerta. En el caso “Managed Databases Creation” de DigitalOcean, la descripción pública recorrió tres escalas: un componente Global, una mención a varias regiones y, finalmente, dos regiones concretas de Nueva York. Convertir esa secuencia en un único mapa retrospectivo produciría más certeza de la que publicó el proveedor.

El registro comenzó a las 05:11:37 UTC del 23 de agosto. DigitalOcean dijo que investigaba un problema con su producto Managed Database y que los usuarios podían encontrar errores al crear clústeres tanto en el Cloud Control Panel como mediante solicitudes de API. El componente Managed Databases - Global pasó de operacional a rendimiento degradado.

A las 07:06:56, la empresa indicó que el problema de creación afectaba a varias regiones. Sus ingenieros estaban implementando una mitigación para restablecer el aprovisionamiento normal. El mensaje no enumeró regiones, no dio tasas de error y tampoco afirmó que cada solicitud o cada cuenta estuviera afectada.

La actualización de las 11:30:34 cambió el nivel de detalle. DigitalOcean dijo haber aplicado las correcciones necesarias que afectaban a la creación de clústeres en NYC3 y NYC1. Según el proveedor, los usuarios ya debían poder crear clústeres nuevos, mientras el equipo vigilaba la estabilidad.

A las 14:33:31, el incidente quedó resuelto. El texto final señaló que el problema que impedía crear clústeres en NYC3 y NYC1 había terminado y que los clientes podían volver a crearlos con normalidad. La ficha quedó con impacto minor y estado resolved.

La cronología medida desde el registro público ofrece tres intervalos. Del inicio a la vigilancia transcurrieron 6 horas, 18 minutos y 57,959 segundos. La fase de vigilancia duró 3 horas, 2 minutos y 56,760 segundos. Del inicio a la resolución fueron 9 horas, 21 minutos y 54,719 segundos.

Ninguno de esos números es un tiempo universal de indisponibilidad. DigitalOcean no publicó cuántos clientes intentaron crear clústeres, qué proporción de solicitudes falló, si hubo ventanas intermitentes ni cuánto duró el problema para cada cuenta. La precisión de las marcas temporales no crea un denominador que el registro no contiene.

Tampoco debe elegirse a posteriori una de las tres descripciones geográficas como si invalidara las otras. El documento no aclara si la investigación descartó regiones, si algunas se recuperaron antes de las 11:30 o si el componente Global servía como contenedor para un incidente aún no delimitado. La incertidumbre es parte del dato operativo.

El servicio afectado también necesita una definición exacta. Todos los avisos públicos hablaron de crear nuevos clústeres. No describieron pérdida de datos, interrupción de consultas, fallo de copias de seguridad o indisponibilidad de todos los clústeres existentes. Llamarlo “caída de bases de datos” mezclaría el plano de control de aprovisionamiento con el plano de datos que sirve cargas ya desplegadas.

La documentación de DigitalOcean muestra las vías normales de creación. Un cliente puede usar el panel de control, doctl o la API. El endpoint documentado es POST /v2/databases, y la solicitud debe seleccionar parámetros como el motor, la región y el tamaño.

Después de una respuesta aceptada todavía queda trabajo. La biblioteca de DigitalOcean describe una nueva base con estado inicial creating; el recurso pasa a online cuando está listo para recibir tráfico. La guía de PostgreSQL advierte que el aprovisionamiento suele tardar cinco minutos o más.

Por eso, “ya se pueden crear clústeres” a las 11:30 no significa que todos estuvieran inmediatamente listos. Una solicitud puede ser rechazada antes de crear el recurso, aceptarse y quedar en formación, llegar a online o fallar después en el camino de conexión. Cada transición requiere su propia observación.

La salud de clústeres anteriores es otra pregunta. El registro no demuestra que sufrieran una interrupción, pero tampoco ofrece una certificación individual de que ninguno tuviera problemas. Lo verificable es que el incidente público identificó la creación como la operación afectada y no amplió formalmente el alcance al servicio de datos existente.

Incluso las filas de componentes requieren contexto. En las dos últimas actualizaciones, NYC1 y NYC3 aparecen de operational a operational mientras el relato habla de reparar y resolver la creación. El color agregado de una región puede seguir verde aunque una transacción específica del plano de control esté degradada.

DigitalOcean no reveló la causa. No identificó validación de solicitudes, capacidad, planificación, red, almacenamiento, motor, puerta de enlace u orquestación. Las páginas de producto describen el contrato general de aprovisionamiento, pero no autorizan a escoger una de esas capas como culpable.

Para el operador, conservar la evolución del alcance evita decisiones equivocadas en ambos sentidos. La primera etiqueta amplia puede justificar comprobaciones regionales, pero no una migración de todas las cargas. La mención final de NYC1 y NYC3 permite enfocar pruebas, pero no borra lo observado antes en otra ubicación.

La conclusión responsable es limitada y útil: DigitalOcean resolvió un fallo de creación de nuevos clústeres, descrito primero en términos globales y multirregionales y después en NYC1 y NYC3. El registro no permite convertir esa evolución en una topología real, una causa o un impacto homogéneo.

Fuentes