• Azure Databricks 报告称，9 月 5 日美国中部区域发生两起独立事件，均影响计算资源启动和作业
  • 两起事件均已解决，现有状态报告并未证明二者原因相同

事实

Azure Databricks 报告称，9 月 5 日其美国中部区域发生了两起独立的服务事件。第一起事件 ES-2194668 影响了 Classic Compute、Declarative Pipelines 和 Jobs。已报告的问题包括集群启动失败、集群卡在 Pending 或 Starting 状态、笔记本无法附加，以及作业或管道失败或持续延迟。状态跟踪记录显示，该事件持续了两个多小时。

随后，第二起事件 ES-2195009 影响了美国中部区域的 Compute 和 Unity Catalog。客户再次遇到集群启动失败、笔记本附加错误，以及在计算资源启动期间作业失败或停滞。该事件在一小时内得到解决。报告没有说明两起事件具有相同的根本原因。两起事件分别得到解决，应视为两起独立的服务事件，而非一次持续性服务中断。

评估

两起事件都在 Databricks 必须提供计算资源的环节中断了工作。客户的数据、代码和笔记本可能仍保留在平台中，但如果对应集群一直处于 Pending 或 Starting 状态，定时作业就无法运行。这使集群启动成为一项独立于平台数据存储的依赖。

对于短时中断，重试作业可能就足够了。如果无法等待区域计算资源恢复，有明确时限的工作负载就需要另一套方案。这可能意味着准备经过测试的替代运行方案，或将作业设计为在延迟启动后能够恢复执行。现有信息尚未证明两起事件原因相同，因此目前不能假定一种技术修复可以同时解决二者。对 BTW 读者而言，使用托管计算服务的团队需要明确哪些作业可以等待、哪些不能。这一判断决定了简单重试是否足够，还是需要提前为另一区域做好准备。

关注重点

需关注 ES-2194668 和 ES-2195009 各自的根本原因信息、美国中部区域后续是否出现更多计算服务事件，以及 Databricks 是否发布有关重试或区域恢复的指导。对客户而言，真正有用的证据在于，关键作业能否在中断后顺利重启，或在计算资源仍无法启动时转移到另一区域。