内存缺陷击垮Salesforce核心交换机及其故障转移——90万用户被锁在系统之外

2009年1月6日，salesforce.com陷入瘫痪。从UTC 20:39（太平洋时间约中午）开始，客户无法登录，也无法访问其CRM数据；据The Register报道，超过90万订阅用户被锁在他们赖以经营业务的应用程序之外。Business Insider称整次中断持续了30至40分钟。对于一家宣称企业可以将其最重要的数据托付给其云端的公司而言，将近一小时的全线故障恰好发生在工作时段。

Salesforce事后发布的官方解释称：“一台核心网络设备因内存分配错误而失效。该故障导致它停止传递数据，但未能正确触发向冗余系统的平滑故障转移，因为故障转移系统上同样存在内存分配错误。”换言之，冗余设备以与主设备相同的方式失效，平台不得不通过手动步骤恢复。

此次事件还暴露了次生故障。Salesforce对外宣传其可靠性的“信任”状态仪表板——那个用于营销其可靠性的页面——也随产品一同宕机，客户无法判断自己是否是唯一受影响的人。数百人转向Twitter确认这次中断，这早期表明：当SaaS平台失效时，其沟通层也会随之失效，除非有意将其置于故障影响范围之外。

超过90万订阅用户在业务时段中途遭遇约40分钟的全线服务故障，且故障转移完全失效。

故障转移设备带有与失效主设备相同的内存分配缺陷，因此“冗余”路径从未接管流量。

故障转移未能平滑触发；恢复完整服务需要运维团队手动执行恢复步骤。

对外信任仪表板位于同一故障域内，使客户无从得知情况，只能自行在Twitter上诊断这次中断。

由相同部件构建的冗余会继承相同的缺陷。如果备用设备带有与主设备相同的缺陷，那它只是一面镜子，而非余量——应使故障转移路径多样化。

Salesforce在信任站点上发布了其解释，称根本原因已“通过变通方案得到处理”，并表示其团队将继续与硬件供应商合作，详查根本原因并确定进一步的修补措施。The Register和商业媒体将此次中断描述为云计算的“暗衬里”，对一家将可用性作为其相对于本地部署CRM软件核心优势来销售的公司而言尤为如此。可靠性观察者得出了不同的教训：一切都会失效，而区分运营者的，是客户能否得知正在发生什么——失败在于沟通，而非正常运行时间。