一个潜伏的缺陷让Gmail的例行数据中心维护演变为长达三小时的全球性中断

2009年2月24日，Gmail在全球范围内对用户中断。谷歌面向Apps客户的事件报告称，中断时间约为格林尼治标准时间上午9点至中午12点——约三小时——恢复是分批进行的，因此各个用户失去访问权的时长各不相同。没有数据丢失。

其机制是两项近期决策相互作用的结果。谷歌部署了新软件，以优化用户数据的存放位置。当天早上，工程师开始在一个欧洲数据中心进行例行维护——这项操作本应是无形的，因为流量会自动转移到其他地方。但这次转移触发了新的本地性代码中的一个潜伏缺陷：目标数据中心过载，而随着流量被自动再次转移，过载便从一个数据中心向下游级联到另一个数据中心。工程师花了约一小时才控制住级联，而重新平衡一切则花了更长时间。

谷歌处理善后的方式在当时颇为罕见地公开：Gmail站点可靠性经理Acacio Cruz当天在官方Gmail博客上解释了这次级联，谷歌也为Apps客户发布了一份正式的事件报告。它还承诺为该服务构建一件当时尚不存在的东西——一个公开状态仪表板——承认云服务提供商在中断期间有义务向客户提供快速信息，而不只是沉默和修复。

2009年2月24日，Gmail无法访问长达三小时，恢复按数据中心分批进行；没有数据丢失

故障转移路径——将流量转移到第二个数据中心——从未针对新的数据本地性软件进行过演练，因此该潜伏缺陷只在维护期间被触发。

过载响应放大了故障：随着用户被自动再次转移，每个目标都遭遇同样的过载状况，并将其向下游扩散。

维护设计假定数据中心之间能够干净地交接，但新的优化代码改变了故障转移所依据的假设。

沟通滞后于事件：谷歌自己的事后分析承认，它需要快速确认中断，这直接促成了Apps状态仪表板的诞生。

故障转移路径应当像主路径一样接受充分测试：重新安排数据位置的新代码把例行维护变成了级联故障。而云服务中断需要发布事件报告。

谷歌修复了该缺陷并推送了更改，发布了事件报告，并在数周后推出了Google Apps状态仪表板，将公开的中断沟通制度化。“gfail”事件成为云服务事件报告的早期范本——一份面向客户的、关于原因和补救措施的正式说明——而当时大多数消费级网络服务根本不提供任何解释。