Heroku 将所有客户放在同一个 AWS 区域运行——随后 EBS 故障持续了 80 小时

2011 年 4 月 21 日 8:15 UTC，Heroku 各处响起监控警报：其 Web、缓存和路由服务开始出现超时。触发点在上游——据 AWS 自己的说明，太平洋夏令时凌晨 12:47，AWS 在美国东部一个可用区进行网络变更，将主 EBS 流量转移到容量较低的复制网络上，导致 EBS 节点被隔离，并引发一场重新镜像风暴，使该可用区 13% 的卷卡死。

EC2 本身约 12 小时后就恢复了，但 EBS 的降级状态持续了 80 多个小时。Heroku 的整个平台都运行在美国东部，数据库也放在 EBS 上，因此无处可切换：它没有第二个区域。大多数应用在 16 小时内恢复；共享数据库服务器上的免费应用最长花了三天。

Heroku 的事后复盘拒绝接受那个显而易见的借口：“Heroku 对影响客户的服务中断承担 100% 的责任。”它总结出三条教训：同一区域内的可用区并不能像团队此前以为的那样隔离风险；块存储不是一种对云友好的技术；而一个承诺将基础设施抽象掉的平台，当基础设施发生故障时，就要承担后果。

大多数应用在 16 小时内恢复；共享数据库上的免费应用最长宕机 3 天；美国东部 EBS 降级持续 80 多个小时

整个平台都运行在同一个 AWS 区域，而其可用区最终被证明共享着 Heroku 原以为已被隔离的故障模式。

有状态服务依赖 EBS，而 EBS 在 EC2 恢复后很久仍然故障——这是 Heroku 在事故期间既无法绕过也无法替换的依赖。

标准应对手册——杀掉不健康的实例、替换它们、等待 AWS——假设中断只持续一两个小时。这次却持续了数天。

多区域多年来一直被降级处理，被视为一个收益甚微的大项目。四月的这次中断在一个周末内就重新估算了它的价值。

同一个云区域内的可用区并不等于冗余。如果所有客户都在同一区域、使用同一块存储运行，那么上游的一次网络失误就会变成所有人的中断。

Heroku 表示将把多区域列为优先级高得多的任务，并减少对 EBS 的依赖，同时开始进行架构调整，意在让平台能够承受 IaaS 层面的故障。AWS 对该事件的总结成为业界流传最广的故障分析之一，“不要把一切都放在一个区域”也成为标准的云建议。尽管如此，Heroku 在此后多年仍保持强烈的单区域姿态，而它所识别出的集中化问题在后来的事故中不断重现。