Salesforce大宕机暴露云服务的隐性风险

本周三，在旗舰活动 Dreamforce 正如火如荼进行之际，Salesforce 却在紧急处置一场持续约七个半小时的服务中断。此次中断影响了用户访问，造成"严重延迟"和间歇性报错，部分客户还无法提交新的支持工单。

据 Salesforce 通报，服务中断始于美国东部时间凌晨 3:50，波及"所有区域的多个实例"。经过数小时监控以确认修复措施有效后，该事件在美国东部时间下午 3 点左右被标记为已解决。

Salesforce 最初将问题归因于影响传统登录服务器的"外部依赖故障"。一个核心系统组件的负载升高，限制了其处理请求的能力。该公司确认，第三方基础设施没有问题。

除了在 Dreamforce 期间宕机带来的明显尴尬之外，一位分析师表示，这起事件凸显的是云韧性问题，而不单纯是遗留系统问题。

"云端并不会消除架构依赖，"Info-Tech Research Group 首席咨询总监 Abbas Jaffery 说，"它有时只是让这些依赖变得更难被看见。而当平台本身就是你的记录系统时，这些隐性依赖就变成了企业风险，而不只是技术风险。"

滚动重启，问题持续一整天

Salesforce 于 9 月 16 日美国东部时间凌晨 3:50 开始出现服务问题，初步调查确定：请求在等待一个内部登录服务的响应时陷入停滞，而该服务正在耗尽可用的服务器资源。

起初，Salesforce 封堵了 API 端点并尝试滚动重启以恢复服务，随后按区域逐个推送修复。到早上 7:20，部分客户的服务已恢复正常，Salesforce 也正在着手"代码层面的永久性修复"。

然而，该推送并未在所有实例上完成，一些自动化修复也没有完全解决问题。例如，客户反映即使服务已恢复，计划任务仍未按预期运行。Salesforce 随后手动重启了这些实例。

Salesforce 之后通报称，影响范围"比最初理解的更窄"，并在美国东部时间上午 11 点左右看到恢复迹象，大多数客户已重新上线。

一部分 Hyperforce 实例最晚恢复。到美国东部时间上午 11:39，所有实例均已落实缓解措施，Salesforce 继续监控该问题，直至下午 2:59 将该事件标记为已解决。

"对本次事件给您和您的业务造成的影响，我们深表歉意，"Salesforce 在其事件博客上写道，"我们将对本次事件展开全面调查，确定技术触发点、根本原因，并采取预防措施以避免未来重演。"

制造出"时间性"数据问题

Info-Tech 的 Jaffery 解释说，对于把 Salesforce 当作记录系统的客户来说，数小时的认证与服务中断会制造出一个"时间性数据问题"。"本应在不同时间点发生的事件，可能会延后发生、彻底失败，或者以错乱的顺序抵达，"他说。

举例来说，在 Salesforce 不可用期间，客户互动可能通过其他渠道发生了，但通常负责记录或传播该事件的集成、工作流或计划流程却无法运行。

Jaffery 表示，这会产生若干潜在后果：交易与客户服务流程被延误；API 和中间件可能累积重试、超时与队列堆积；记录可能暂时出现不一致；计划任务与工作流可能被漏掉。员工可能失去对客户历史或工单状态的可见性——即便底层数据并未丢失——从而形成"数据分歧"。

他指出，第一个错误就是以为只要用户能登录，事件就算过去了。"企业应立即进入对账与完整性核查阶段，"Jaffery 建议。这意味着不仅要验证交互式访问，还要验证 API、集成、计划任务、队列、工作流、自动化、认证流程以及下游系统。

企业应当追问：中断期间哪些交易失败了、部分完成了或被重复执行了？哪些计划性或异步流程没有执行？集成是成功重试了，还是产生了积压甚至重试风暴？下游系统现在与 Salesforce 是否一致？

Jaffery 解释说，安全团队还应核验认证与会话行为、特权访问、集成凭证，以及恢复期间所做的任何紧急变更。"最重要的问题不是简单的'Salesforce 恢复了吗？'，而是'中断期间业务本应发生什么，我们能否证明它确实发生了？'"

事后报告应该看什么

Jaffery 表示，一份可信的事后复盘应当建立起完整的因果链：触发点、依赖故障、技术传播、客户影响、检测、缓解、恢复以及永久性纠正措施。

他说，该公司应当能够回答以下问题：最初的故障究竟是什么，为什么该故障会传播到登录路径上？为什么受影响的依赖能够消耗足以影响核心服务的容量？为什么隔离或故障转移未能阻止影响？为什么最初的补救尝试失败，为什么随后的推送还需要额外人工干预？正在增加哪些防护措施以防止再次发生？Salesforce 将如何证明这些纠正措施在故障条件下真正有效？

他指出，仅仅"服务已恢复"只是告诉客户："我们把它重新弄好了。"而根因分析才是告诉客户："我们理解它为什么失败、我们的控制措施为什么没能阻止它，以及发生了什么变化，使得同样的故障模式更不容易重演。"

问题不只是技术栈里的"遗留"零件

Jaffery 指出，一个架构层面的教训是：遗留组件不必体量很大，也可以很关键。一个较老的认证服务可以继续留在现代技术栈中，并因此成为更新服务的依赖项。

"组件有多老，不如它在依赖图中的位置、它的影响范围（blast radius），以及它的隔离与故障处理质量来得重要，"他说。他援引本次事件的发展链条指出：请求因某个内部登录服务资源消耗升高而停滞（等待），引发了对"外部依赖故障"的调查，进而暴露出对一台遗留登录服务器的影响；最终 Salesforce 表示，"核心系统组件经历了负载升高，限制了其处理请求的能力"。

Jaffery 指出，这是经典的韧性问题：一个依赖中的故障，能否被限制在那个依赖之内，还是会演变成整个平台的故障？

他指出，现代化不应仅仅以"替换掉了多少老技术"来衡量，还应衡量依赖集中度、隔离能力、"优雅降级"、恢复路径以及故障影响范围。

"对企业架构师而言，这才是真正的要点，"他说。

或许由智能体AI驱动，又因裁员而加剧

Beauceron Security 首席执行官 David Shipley 指出，目前没有明显迹象表明这是一起安全事件。"眼下这一切都带着'一次更新彻底搞砸了'的特征。"

他提到 2025 年 12 月的一起事件：亚马逊内部的 AI 编码智能体 Kiro 曾导致 AWS 在中国大陆某区域中断 13 小时。他说："如果最后发现这类规模的灾难里有某种智能体的角色，我不会感到震惊。"

他补充说，Salesforce 过去几年的大规模裁员，也可能对本次中断及恢复造成了负面影响。"不过这事发生在 Dreamforce 期间，对他们的销售和客户支持团队来说绝对是地狱般的经历，"他说，"在他们忙着面对面重建客户关系的时候，为他们默默举杯吧。"