Fastly宕机 - 一个Bug的故事
本周二，包括CNN、纽约时报、卫报等大量英语网站一度无法打开。用户访问这些网页时，页面上显示的都是服务器端错误状态代码503，原因是美国云端运算服务商Fastly出现故障造成的。
Fastly是什么？CDN是什么？503又是什么？
Fastly成立于2011年，为世界各大网站提供CDN服务，以加快网民浏览速度和体验。业内有规模的竞争对手不多，计有阿卡迈科技（Akamai Technologies）、Cloudera和亚马逊网络服务（Amazon Web Services, AWS）。
CDN的中文意思就是内容分发网络（Content Delivery Network）。其目的是在现有的网络中增加一层网络架构，将网站的内容发布到最接近用户的网络“边缘”，使用户可以就近取得所需的内容，提高用户访问网站的响应速度。国内主要的CDN厂商有阿里云，腾讯云。
503 Service Unavailable 是一种HTTP协议的服务器端错误状态代码，它表示服务器尚未处于可以接受请求的状态。通常造成这种情况的原因是由于服务器停机维护或者已超载。通常应该同时发送一个对用户友好的页面来解释问题发生的原因。
一个Bug，一个客户
让我们一起来看看Fastly工程部资深总裁提供的宕机总结。5月12号的时候，Fastly部署中引入了一个Bug，埋下了一枚核地雷。这个Bug只会在某种特定情况下的某个特定配置才会触发。
不幸的是，6月8日，某个客户修改了配置，而这个配置修改出发了这个bug。也就是说某一个客户的小小的配置修改，触发了这枚核地雷，整个互联网世界垮掉了。
Fastly的事故分析报告对Bug的具体细节语焉不详，我个人估计应该是个比较低级的错误，以至于Fastly对细节无法启齿。我猜测一个可能的原因就是某个特定的配置会引起cache eviction，但是代码中未能将eviction正确的限制在站点一级，导致了全局的cache eviction，于是互联网世界就503了。个人瞎猜，完全不负任何责任。
教训
Fastly 宕机的范围广大，但并非每个使用 Fastly 的站点都受到严重影响。利用多个 CDN 的客户受到的影响相对较小，他们最终依靠其他CDN提供商来提供服务。使用 Fastly 作为唯一CDN的客户都完全离线，其中有些客户能够将用户重定向到他们的源服务器，但手动过程不可避免带来了较长的服务中断，以及直接访问源服务器带来的延迟。
CDN 是交付 Web 内容的关键基础设施，需要仔细考虑CDN中断如何影响您的在线服务和应用。
这次中断是一个重要的提醒，提醒每个关键依赖项都需要冗余。以下是一些要点：
- 使您的服务依赖多样化，避免单点失效——正如冗余 DNS 是最佳实践一样，考虑使用两个或多个 CDN 以确保最佳交付并减少任何一个 CDN 遇到服务中断的影响。
- 制定停机（不可避免）发生时的备份计划——并确保充分了解早期预警指标，以及何时可能需要激活备份方案。
- 了解您的所有依赖项——甚至是间接的、“隐藏的”依赖项，例如 DNS、托管服务等等，以便确保它们也具有弹性。
- 持续评估在线服务交付的可用性和性能，确保您对潜在问题有积极的认识，并使您能够快速响应以解决这些问题。
一些感想
当今的云计算发展中出现了两极分化的趋势。一方面是各种SaaS服务，移动互联网，人工智能应用如雨后春笋般蓬勃发展，层出不穷。另一方面在云计算，互联网基础架构方面却出现了向大厂高度集中，有向垄断发展，出现数字霸权的趋势。
希望大厂能保持初心，对技术充满敬畏，尽全力保证基础架构的高可用性与弹性，不负所托。希望各个应用厂商结合自己的状况，对基础设施提供方保留一份怀疑，准备B计划并不时演练，毕竟人不能在一棵树上吊死。
