Résumé

  • Azure Databricks a signalé deux incidents distincts dans la région Central US le 5 septembre, tous deux ayant affecté le démarrage des ressources de calcul et les tâches
  • Les deux incidents ont été résolus, et les rapports d’état disponibles n’établissent pas qu’ils avaient la même cause

Les faits

Azure Databricks a signalé deux incidents de service distincts dans sa région Central US le 5 septembre. Le premier, ES-2194668, a touché Classic Compute, Declarative Pipelines et Jobs. Les problèmes signalés comprenaient des échecs de lancement de clusters, des clusters bloqués dans les états Pending ou Starting, des échecs de rattachement des notebooks ainsi que des tâches ou des chaînes de traitement qui échouaient ou restaient retardées. Le suivi de l’état a enregistré l’incident pendant plus de deux heures.

Un second incident, ES-2195009, a ensuite touché Compute et Unity Catalog dans la région Central US. Les clients ont de nouveau rencontré des échecs de lancement de clusters, des erreurs de rattachement de notebooks et des tâches qui échouaient ou restaient bloquées pendant le démarrage des ressources de calcul. L’incident a été résolu dans l’heure.

Les rapports n’indiquent pas que les deux incidents avaient la même cause racine. Les deux incidents ont été résolus séparément et doivent être considérés comme deux événements de service, et non comme une seule panne continue.

L’analyse

Les deux incidents ont interrompu l’activité au moment où Databricks devait fournir les ressources de calcul. Les données, le code et les notebooks d’un client pouvaient toujours se trouver sur la plateforme, mais une tâche planifiée ne pouvait pas s’exécuter si son cluster restait à l’état Pending ou Starting. Le démarrage des clusters constitue donc une dépendance distincte du simple stockage de données sur la plateforme.

Pour de brèves interruptions, relancer une tâche peut suffire. Les charges de travail soumises à des échéances ont besoin d’un autre plan si elles ne peuvent pas attendre le rétablissement de la capacité de calcul régionale. Il peut s’agir d’une méthode testée pour les exécuter ailleurs ou d’une conception permettant aux tâches de reprendre après un démarrage retardé. Il n’a pas été démontré que les deux incidents avaient la même cause; on ne peut donc pas encore supposer qu’un même correctif technique réglera les deux.

Pour les lecteurs de BTW, les équipes qui utilisent des ressources de calcul gérées doivent savoir quelles tâches peuvent attendre et lesquelles ne le peuvent pas. Ce choix détermine si de simples relances suffisent ou s’il faut préparer une autre région à l’avance.

À surveiller

Il faudra surveiller la publication d’informations distinctes sur les causes racines d’ES-2194668 et d’ES-2195009, de nouveaux incidents liés au calcul dans la région Central US et toute recommandation de Databricks concernant les relances ou la reprise régionale. Pour les clients, les preuves utiles seront celles montrant si les tâches critiques peuvent redémarrer correctement après une interruption ou basculer vers une autre région lorsque le démarrage des ressources de calcul reste indisponible.

Sources