在其旗舰活动Dreamforce如火如荼进行之际，Salesforce在周三经历了长达约七个半小时的服务中断，导致用户访问受阻，并出现"严重延迟"和间歇性错误。部分客户还无法提交新的支持工单。
此次服务中断始于美国东部时间凌晨3点50分，Salesforce报告称影响"所有区域的多个实例"。故障在东部时间下午3点左右被标记为已解决，此前经过数小时监控以确认修复措施是否成功。
Salesforce最初将问题归因于影响其旧版登录服务器的"外部依赖故障"。一个核心系统组件负载增加，限制了其处理请求的能力。该公司确认第三方基础设施没有出现问题。
除了这次中断恰好发生在Dreamforce期间带来的尴尬之外，一位分析师指出，此次事件凸显的是云韧性问题，而非纯粹的遗留系统问题。
Info-Tech Research Group首席顾问总监阿巴斯·贾弗里表示："云并不能消除架构依赖关系，它有时反而会让这些依赖变得不那么可见。当该平台是你的系统记录时，这些隐藏的依赖关系就会变成企业风险，而不仅仅是技术风险。"
滚动重启，全天持续存在的问题
Salesforce于9月16日美国东部时间凌晨3点50分开始出现服务问题，初步调查确定，请求在等待内部登录服务响应时出现停滞，该服务耗尽了可用的服务器资源。
最初，Salesforce屏蔽了应用程序编程接口（API）端点，并尝试通过滚动重启来恢复服务，随后逐个区域推出修复措施。到早上7点20分，部分客户看到服务恢复正常，Salesforce正在开发"代码级永久修复方案"。
然而，该修复方案并未在多个实例中全部完成部署，部分自动化修复也未能完全解决问题。例如，客户报告称即使服务已恢复，计划任务仍未按预期运行。Salesforce手动重启了这些实例。
Salesforce随后报告称，影响范围"比最初了解的要窄"，到东部时间上午11点左右出现恢复迹象，大多数客户已恢复在线。
Hyperforce的一个子集实例是最后恢复的。到东部时间上午11点39分，所有实例都已采取缓解措施，Salesforce继续监控该问题，直到东部时间下午2点59分将事件标记为已解决。
Salesforce在其事件博客上发文称："对于此次事件给您和您的业务带来的影响，我们深表歉意。我们将对该事件进行全面调查，确定技术触发因素、根本原因，并制定预防措施，避免未来再次发生。"
制造"时序性"数据问题
对于将Salesforce作为系统记录的客户而言，数小时的身份验证和服务中断可能会造成"时序性数据问题"，Info-Tech的贾弗里解释道。他表示："本应在不同时间点发生的事件，可能会延后发生、完全失败，或者以错乱的顺序到达。"
例如，客户可能通过其他渠道进行了互动，而此时Salesforce不可用，导致通常用于记录或传播该事件的集成、工作流或计划任务无法运行。
贾弗里表示，这会带来若干潜在后果：交易和客户服务流程被延迟；API和中间件可能会累积重试、超时和队列；记录可能会暂时出现不一致；计划任务和工作流可能被遗漏；即使底层数据没有丢失，员工也可能失去对客户历史或工单状态的可见性，从而产生"数据分歧"。
他指出，第一个错误就是仅仅因为用户能够登录，就认为事件已经结束。贾弗里建议："企业应立即进入对账和完整性核查阶段。"这不仅意味着要验证交互式访问，还要验证API、集成、计划任务、队列、工作流、自动化、身份验证流程以及下游系统。
企业应该询问：在中断期间，哪些交易失败、部分完成或被重复处理？哪些计划或异步流程未能执行？集成是否成功重试，还是造成了积压或重试风暴？下游系统现在是否与Salesforce保持一致？
贾弗里解释说，安全团队还应验证身份验证和会话行为、特权访问、集成凭证以及恢复期间所做的任何紧急变更。他表示："最重要的问题不仅仅是'Salesforce恢复了吗？'，而是'企业原本期望在中断期间发生什么，我们能否证明这些确实发生了？'"
事后报告应关注哪些内容
贾弗里表示，一份可信的Salesforce事后事件审查报告应当建立完整的因果链：触发因素、依赖故障、技术传播过程、客户影响、检测、缓解措施、恢复以及永久性纠正措施。
他说，该公司应能回答以下问题：
实际的初始故障是什么？为何该故障会传播至登录路径？
为何受影响的依赖项能够消耗足够的资源以影响核心服务？
为何隔离机制或故障转移未能阻止影响扩大？
为何初步补救措施未能成功？为何后续的推出还需要额外干预？
正在添加哪些防护措施以防止此类事件再次发生？
Salesforce将如何证明其纠正措施在故障情况下确实有效？
他指出，服务恢复只是告诉客户："我们已经让它重新运转起来了。"但根本原因分析则是告诉客户："我们理解它为何失败，理解我们的控制措施为何未能阻止它，也理解发生了哪些变化，从而使同样的故障模式不太可能再次出现。"
不仅仅是技术栈中的"遗留"部件问题
贾弗里指出，一个架构层面的教训是：遗留组件不必规模庞大才能变得关键。一项较旧的身份验证服务可能仍然是现代技术栈的一部分，因此会成为新服务的依赖项。
他表示："该组件的年龄远不如它在依赖关系图中的位置、其影响半径以及隔离和故障处理的质量重要。"他指出了此次事件的发展过程：请求因内部登录服务资源消耗增加而停滞，进而引发对外部依赖故障的调查，随后发现影响波及了一个遗留登录服务器。最后，Salesforce表示，"核心系统组件负载增加，限制了其处理请求的能力"。
贾弗里指出，这是一个经典的韧性问题：一个依赖项中的故障能否被限制在该依赖项内部，还是会演变成平台级的全面故障？
他指出，现代化程度不应仅仅通过替换了多少旧技术来衡量，还应衡量依赖集中度、隔离性、"优雅降级"能力、恢复路径以及故障影响半径。
他表示："对于企业架构师而言，这才是真正的启示。"
或由智能体AI引发，裁员加剧了问题
Beauceron Security首席执行官戴维·希普利指出，目前尚无明显迹象表明这是一起安全事件。"就目前来看，这完全符合更新出现严重问题的所有特征。"
他提到了2025年12月发生的一起事件，当时亚马逊内部的AI编码智能体Kiro导致AWS中国大陆某区域出现长达13小时的宕机，他表示："如果我们在这类大规模故障中看到某种智能体的身影，我不会感到惊讶。"
他还补充说，Salesforce过去几年的大规模裁员也可能对此次中断和恢复产生了负面影响。他表示："这次故障恰好发生在Dreamforce期间，对他们的销售和客户支持团队来说，这无疑是一场噩梦。他们现在要在面对面的场合重新修补客户关系，向他们致以慰问。"
Q&A
Q1：Salesforce此次宕机的原因是什么？
A：Salesforce最初将问题归因于影响旧版登录服务器的"外部依赖故障"，一个核心系统组件负载增加，限制了其处理请求的能力，随后确认第三方基础设施没有问题，目前没有明显迹象表明这是安全事件。
Q2：Salesforce此次宕机持续了多久，影响范围有多大？
A：此次服务中断从美国东部时间凌晨3点50分持续到下午近3点，长达约七个半小时，影响了所有区域的多个实例，导致用户访问受阻、严重延迟和间歇性错误，部分客户还无法提交新的支持工单。
Q3：企业在类似云服务中断后应该做什么？
A：专家建议企业不能仅因用户能登录就认为事件结束，应立即进入对账和完整性核查阶段，验证API、集成、计划任务、工作流、身份验证流程等是否恢复正常，确认哪些交易在中断期间失败或重复处理。
