IBM Cloud 于周一遭遇了两周内的第二次重大故障，导致全球各地的用户无法登录、管理资源或访问基本服务。

此次事件影响了 41 项服务，包括 IBM Cloud、AI Assistant、DNS 服务、Watson AI、全球搜索服务、Hyper Protect Crypto Services、数据库以及 Security and Compliance Center。

该事件始于 UTC 时间周一上午 9:05，持续了数小时，于 UTC 时间周一晚上 11:10 得到解决。根据 IBM 的状态更新报告，用户无法通过控制台、命令行界面（CLI） 或 API 登录 IBM Cloud。在此期间，他们也无法管理或配置云资源。此外，还发生了 IAM 身份验证失败，对支持门户的访问中断，客户应用程序的数据路径也可能受到了影响。

IBM 开始了调查并启动了初步缓解措施，并于 UTC 时间 6 月 2 日晚上 07:42 开始进行受控恢复流程以恢复系统。到 UTC 时间晚上 11:12，IBM 已完成其核心恢复操作，允许用户对其应用程序执行健康检查。

该事件被归类为 Severity One (Sev-1) 一级严重事件，导致客户收到了有关 IAM 身份验证失败的电子邮件、无法访问支持门户处理支持案例，并对客户应用程序数据路径造成了潜在影响。

不仅仅是身份验证漏洞？

“云登录中断——即使是短暂的——也会延迟对关键应用程序的访问、拖慢内部协调并干扰自动化工作流程。影响用户登录或平台访问的云故障并不总是会立即引发混乱——但它们会迅速加剧摩擦，” Greyhound Research 首席分析师兼 CEO Sanchit Vir Gogia 表示。

Gogia 表示，多区域影响表明这可能不仅仅是一个身份验证漏洞——它通常指向一个共享的后端组件，如全局 DNS 解析层、编排控制器或遥测服务。“与往往局限于局部的计算或存储故障不同，控制平面的弱点会在各区域间产生连锁反应，使得故障更难控制，并且对管理分布式工作负载的企业团队更具破坏性。核心平台功能缺乏区域解耦，对于在合规性、性能和隔离之间权衡取舍的 CIO 来说仍然是一个令人担忧的问题，” Gogia 说。

就在两周前的 5 月 20 日，发生过一次类似事件，持续了两小时十分钟。它影响了 14 项服务，包括 IBM Cloud、Client VPN for VPC、Code Engine 和 Kubernetes Service 等。在此次全球云平台中断期间，用户尝试通过用户界面 (UI)、命令行界面 (CLI) 甚至基于 API 密钥的身份验证登录时都遭遇了失败。

“当登录或 IAM 服务发生故障时，关键任务工作负载可能会陷入停滞，引发跨服务和跨区域的连锁中断，” CMR 行业研究集团副总裁 Prabhu Ram 表示。

此类反复出现的中断凸显了其对企业 IT 战略的更广泛影响，常常导致企业将重点放在改进云弹性上，而不仅仅局限于供应商合同。

“要实现真正的弹性，组织必须优先考虑强有力的技术保障措施——例如多云策略和地理分布式架构，以及强有力的合同保护措施，包括全面的 SLA（服务等级协议）。虽然单次中断可能不会立即引发改变，但反复的故障或不充分的事件响应可能会迫使企业转向多元化的云提供商，” Ram 说。

Gogia 指出，如今构建弹性远不止备份存储和备用数据中心。“企业现在正在投资多层可观测性、跨平台编排工具以及即使在供应商平台中断期间仍可用的备用访问路径。这可能意味着在主要提供商之外托管轻量级管理门户、在单独区域部署镜像遥测或使用独立的 DNS 管理。”

最近的这些云中断示例——虽非灾难性的——却是有用的压力测试，有助于识别架构和政策中的薄弱环节。