# Salesforce 故障连带瘫痪了客户支持通道 **Summary:** 9 月 16 日 Salesforce 全球性故障影响了所有区域的实例，并导致部分客户无法提交支持工单。恢复通道不应依赖于可能失效的产品登录路径。 - Canonical: https://markhuang.ai/zh/news/salesforce-outage-took-support-with-it - Language: zh-CN - Author: [Mark Huang](https://markhuang.ai/about) - Published: 2026-09-16 - Section: News - Tags: Salesforce, 云服务中断, 事件响应, 服务可靠性, 客户支持 - Source: [Salesforce Trust](https://status.salesforce.com/products/all) - License: https://creativecommons.org/licenses/by-nc/4.0/ --- ![受损的云基础设施枢纽同时切断了企业工作站和紧急支持电话的电源](https://cdn.markhuang.ai/news/salesforce-outage-took-support-with-it/hero.webp) *只有当恢复路径能挺过引发客户求助的故障时，它才有用。* 2026 年 9 月 16 日，Salesforce 的[全产品状态页面](https://status.salesforce.com/products/all)将客户引导至事件编号 20004433。官方时间线显示，此次中断始于 UTC 时间 07:50，影响了所有区域的多个实例。客户遭遇严重延迟、间歇性错误和服务不可用。更糟的是，部分客户无法通过帮助门户创建新的支持工单。 我不会把支持入口绑在正在挂掉的登录链路上。状态页面能告诉我供应商已经知道出事了，但它替代不了一个独立渠道——用来报告你自己租户的紧急情况、提交现场证据、或者找人帮忙。 凡是用 Salesforce 跑销售、服务或日常运营的公司，都得正视这个缺口。故障本身是平台层面的事，但工单提交通道跟着一起挂掉，就变成了客户侧的应急设计问题。 ## 时间线指向了共享的故障路径 [Salesforce 的事件记录](https://status.salesforce.com/incidents/20004433)把调查过程一步步写了出来。UTC 08:45，Salesforce 说问题影响了所有区域的多个实例，部分客户无法提交工单。到 09:10，更新内容变成：请求在等待内部登录服务时卡住，把可用服务器资源都耗光了，工单创建依然受阻。 随后，官方说法变了。Salesforce 先说可能是旧版登录服务器的外部依赖出了问题，正在考虑屏蔽某个 API 端点。几分钟后又改口，说是一个核心系统组件负载飙升，请求处理能力丢了。作为外部人员，我不会试图去调和这两种说法。这是工程师在收集证据时实时调整的调查过程。 到 UTC 10:56，Salesforce 说已经在测试实例上验证了修复方案，正往所有受影响的实例上推。11:19，报告客户开始陆续恢复，工程师同时在写一个永久性的代码级补丁。恢复过程本身很清楚，但它留下的产品问题更棘手：为什么求助的路径也成了连带损伤？ ## 状态不等于支持 Salesforce 让客户用 Trust Status 来检查实例、查看事件、了解维护计划、订阅通知。[Trust Status 文档](https://help.salesforce.com/s/articleView?id=sf.trust_status_overview.htm\&language=en_US\&type=5)说支持近乎实时的邮件和短信提醒，状态 API 还暴露了事件、维护、产品、服务和实例状态。这个公共接口相当完整，9 月 16 日的时间线也比一个泛红的指示灯提供了更多信息。 状态推送和支持渠道回答的是两码事。状态推送能告诉你"大面积故障中"，但它不知道你的租户是不是还有自己的问题、你的队列数据要不要保住、你临时绕行的操作会不会越搞越糟。我仍然需要一条路，在出问题的登录组件之外，把这些情况报上去。 Salesforce 现在的[支持指南](https://help.salesforce.com/s/articleView?id=001116973\&language=en_US\&type=1)建议紧急的一级问题直接打电话。我会把这个备选方案写进运行手册，连同电话号码、组织 ID、支持计划详情、指定的升级联系人一起存好——存在 Salesforce 外面。等登录挂了再去翻这些资料，已经太晚了。 > **Info:** > > 我的故障应急规则：监控、事件通报和紧急支持通道，不能依赖那个可能正在挂掉的生产登录。联系方式和租户标识符，存在独立的运行手册里。 ## 绿灯只是其中一个信号 全产品状态页之所以有用，是因为它把一大堆服务塞进一个页面里看。但这种压缩也丢了细节。产品可能整体显示正常，但某个区域、某个实例、某条集成链路、或者某个客户的业务流程已经挂了。故障刚冒头的时候，供应商得先发现规律、查清楚情况，然后才能决定对外说什么。 [Reddit 上 Salesforce 管理员的讨论](https://www.reddit.com/r/salesforce/comments/1whr912/salesforce_down_for_maintenance/)在这里挺有用，但也有局限。有人报告多个区域都有间歇性访问问题，有人抱怨提不了工单。这些评论没法确定根本原因或总范围，但它们确实展示了官方仪表盘难以捕捉的东西：在大家统一认定"这是同一个故障"之前，那些散落在各处的客户症状。 对我来说，供应商页面只是确认了客户侧监控本就该自己发现的问题。模拟登录探测、API 错误率、集成队列深度、认证失败次数——这些指标能在状态页挂出红条之前，就告诉你业务流程已经出问题了。我在[Claude 服务故障](/news/claude-outage-dependency-test)那篇里也得出了同样的结论。云工具一旦嵌进你的工作流，它出故障就得有人管、有预案。靠"谁记得刷新一下浏览器标签"是不行的。 ## 个性化状态有帮助，但独立性更重要 Salesforce 已经在往更细粒度的可见性方向走了。[My Trust Center 公告](https://admin.salesforce.com/blog/2026/introducing-my-trust-center)说，公共站点只在通用实例级别报状态，而新服务能按客户自己的租户给出定制化的状态和维护信息。Salesforce 还表示，用了旧版 Trust API 做自动化的客户，在公共状态页下线之前会有时间迁移。 这应该能减少噪音告警，让事件视图更对得上号。但它不会自动解决共享依赖的问题。如果你的个性化状态页和出问题的服务走的是同一套身份系统，那最需要它的时候反而可能打不开。关键问题是：通信和升级路径能不能独立于故障系统而存活。 Salesforce 完全可以说公共事件页面尽到了它的职责。它承认了影响范围，记录了诊断的变化过程，也描述了全平台的修复推送。我同意。但我的批评更具体：一个好的状态页面应该配一个独立于产品之外的支持联系渠道，尤其是当事件本身就可能把工单入口一起搞挂的时候。 ## 下次中断前我会做哪些改变 我会把紧急路径当一个真实系统来演练。值班人员能不能脱离 Salesforce 找到租户 ID？能不能根据支持计划拨到对的电话线路？能不能通过产品之外的渠道收到状态更新？能不能用自己的监控数据分清"这是供应商全局故障"还是"这是本地配置问题"？ 我还会提前定好规矩：登录开始抖动的时候，哪些操作要停。自动化可能会不断重试，堆出一堆待处理的任务。销售和支持团队可能已经在别的地方记工单了。集成恢复后可能会把旧事件重新推一遍。运行手册里要给这些队列指定负责人，服务恢复后要有对账流程。 当我于 UTC 时间 11:19 查看事件时，Salesforce 正通过经过测试的全集群推出恢复服务。我仍会使用其状态页面。我只是不希望页面、支持渠道和产品都向同一个有问题的登录服务请求许可来帮我恢复。