Resumen

  • Azure Databricks informó de dos incidentes independientes en Central US el 5 de septiembre; ambos afectaron al inicio de los recursos de computación y a los trabajos
  • Ambos incidentes se resolvieron y los informes de estado disponibles no permiten establecer que tuvieran la misma causa

Los hechos

Azure Databricks informó de dos incidentes de servicio independientes en su región Central US el 5 de septiembre. El primero, ES-2194668, afectó a Classic Compute, Declarative Pipelines y Jobs. Los problemas notificados incluyeron fallos al iniciar clústeres, clústeres bloqueados en los estados Pending o Starting, fallos al adjuntar cuadernos y trabajos o canalizaciones que fallaban o seguían retrasados. El seguimiento del estado registró el incidente durante más de dos horas.

Un segundo incidente, ES-2195009, afectó posteriormente a Compute y Unity Catalog en Central US. Los clientes volvieron a encontrar fallos al iniciar clústeres, errores al adjuntar cuadernos y trabajos que fallaban o quedaban bloqueados mientras se iniciaban los recursos de computación. El incidente se resolvió en menos de una hora.

Los informes no indican que los dos incidentes tuvieran la misma causa raíz. Ambos se resolvieron por separado y deben considerarse dos eventos de servicio, no una única interrupción continua.

La evaluación

Ambos incidentes paralizaron el trabajo en la fase en la que Databricks debía proporcionar recursos de computación. Los datos, el código y los cuadernos de un cliente podían seguir presentes, pero un trabajo programado no podía ejecutarse si su clúster permanecía en Pending o Starting. Esto convierte el inicio del clúster en una dependencia distinta del mero hecho de tener datos almacenados en la plataforma.

En interrupciones breves, puede bastar con reintentar un trabajo. Las cargas de trabajo sujetas a plazos necesitan un plan distinto si no pueden esperar a que se recuperen los recursos de computación de la región. Esto podría implicar disponer de una forma probada de ejecutarlas en otro lugar o diseñar los trabajos para que puedan reanudarse tras un inicio retrasado. No se ha demostrado que los dos incidentes compartan una causa, por lo que todavía no puede darse por hecho que una única corrección técnica resuelva ambos.

Para los lectores de BTW, los equipos que usan recursos de computación gestionados deben saber qué trabajos pueden esperar y cuáles no. Esa decisión determina si bastan los reintentos sencillos o si hay que preparar otra región con antelación.

Qué observar

Habrá que prestar atención a la publicación de información separada sobre la causa raíz de ES-2194668 y ES-2195009, a otros incidentes de computación en Central US y a cualquier orientación de Databricks sobre reintentos o recuperación regional. Para los clientes, la evidencia útil será comprobar si los trabajos críticos pueden reiniciarse correctamente tras una interrupción o trasladarse a otra región cuando el inicio de los recursos de computación siga sin estar disponible.

Fuentes