谷歌和 Facebook 披露全球大宕机事件原因

谷歌和Facebook 分别发布3月13日出现的全球服务大宕机原因。

谷歌在云状态页面 (Google Cloud Status Dashboard) 发布了事故原因说明。全文如下：

2019年3月12日（美国/太平洋时间），谷歌的内部 blob （大型数据对象）存储服务中断了4小时10分钟。我们对服务或应用受此事件影响的客户深表歉意。我们了解客户对 Google Cloud Platform (GCP) 服务的依赖与信任，我们正在采取措施改进服务的可用性并阻止类似事件的再次发生。

太平洋时间2019年3月12日周二18:40至22:50期间，谷歌的内部 blob 服务经历了错误率的提升。在此期间，出错率平均为20%，而且曾达到31%的峰值并在短期内持续。用户可见的谷歌服务包括使用 blob 存储服务的 Gmail、Photos 和 Google Drive 的出错率提升，尽管（Google Cloud Service即 GCS的情况也如此）这些服务中的内置缓存和冗余大大降低了对用户的影响。我们将单独出具关于受此次事件影响的非 GCP 服务的事件报告。

受影响最严重的 GCP 服务包括：

谷歌云储存 (GCS) 的长尾延迟较高，平均出错率为4.8%。所有存储桶位置和存储类别均受影响。依赖于云存储的谷歌云平台 (GCP) 服务也受影响。

Stackdriver Monitoring 服务在检索历史时间序列数据时经历了最高5%的出错率。最近的时间序列数据已为可用状态。警报 (Alerting) 服务未受影响。

App Engine 的 Blobstore API 经历了较高的延迟和出错率，在获取 blob 数据时出错率达到峰值21%。App Engine 的部署的出错率提升至90%。App Engine 提供的静态文件出现的出错率也有所提升。

2019年3月11日周一，谷歌 SRE 收到警报称，内部 blob 服务使用的元数据存储资源大幅增加。3月12日周二，为了减少资源使用，SRE 进行了配置修改，但这样做产生的副作用是过载系统的一个关键部分以查看 blob 数据的位置。增加的加载最终导致级联故障。

SRE 在太平洋时间18:56收到服务中断警报并立即终止配置更改任务。为了修复级联故障，SRE 手动降低了 blob 服务的流量水平，以允许任务启动不会因高负载问题而崩溃。

为了防止类似服务中断事件的发生，我们将改进存储服务区域之间的隔离，以便降低故障产生全球影响的可能性。我们将提升更快配置资源的能力，以便解决由高加载问题导致的级联故障问题。我们将采取软件方面的措施以阻止因配置更改造成系统关键部分过载的问题。我们将改进元数据存储系统的减载行为，以便它能够在过载时以适当的方式降级。

Facebook 的一名发言人否认了网传谷歌和 Facebook 宕机是遭受 DDoS 攻击的说法。

在昨天的文章中，我们提到网络管理公司 Netscout 认为造成宕机的原因可能是 BGP 路由泄漏问题，然而，云监控公司 ThousandEyes 表示，很可能是应用层除了问题，和路由没关系。

该公司指出，“我们在调查 Facebook 问题的过程中并未看到影响连接的任何 BGP 更改、数据包丢失或延迟问题。由于 Facebook 使用了自己的骨干网络，因此尚不清楚外部传输路由问题为何会触发 Facebook 内部网络的服务中断问题。”

该公司还提到，“如果路由泄漏影响从互联网访问 Facebook 的用户访问权限，那么它很可能是因为路径变更的结果，和去年11月份谷歌的用户访问权限遭路由泄漏影响的情况一样。我们在那次事件中捕捉到了路径更改问题，但在 Facebook 这个案例中并未找到相关证据。”

继服务中断14小时之后，Facebook 服务恢复正常。

Facebook 指出，大宕机的原因是“服务器配置更改”。大宕机涉及 Messenger、Instagram 和 WhatsApp 等。但除此以外，Facebook 并未给出更多具体解释。

有意思的是，就在大宕机期间，Telegram 的创始人 Pavel Durov 表示，一天之内竟然有3亿人注册了 Telegram 服务。Telegram 这一次算是事件的最大受益者了。

在Facebook 服务发生大宕机事件的同一天，《纽约时报》报道称，美国联邦机构正在对Facebook 与150家公司达成的数据交易进行刑事调查，交易方包括索尼、Netflix、Spotify 和亚马逊。

报道称，这些公司能够访问 Facebook 公司此前曾表示无法访问的用户数据。亚马逊据称能够查看用户的通讯信息，而 Spotify 和 Netflix 据称能够查看用户的私聊信息。