潜伏缺陷在等待合适的触发条件
这个缺陷已在生产环境中存在近四周,直到某位客户的配置恰好将其激活——这提醒我们,"目前尚未出事"并不等于"不存在风险"。
速览要点
一张表看懂事情经过。
Fastly从未公布这一事件的财务损失数字,这一点本身就值得注意——收录这一案例是因为它展示了响应速度的价值,而非其损失金额。
日期
2021年6月8日,大约从美国东部时间05:50持续到06:45。
故障原因
5月12日的一次软件部署引入了一个潜伏缺陷,该缺陷只有在特定客户配置下才会被触发。6月8日,一位客户推送了一次有效的配置变更,恰好符合了这些确切条件,据Fastly官方总结所述。
影响规模
Fastly约85%的网络开始返回错误,导致Reddit、Twitch、Spotify、PayPal、Shopify、Stripe、英国政府网站(gov.uk)以及各大新闻媒体纷纷下线,其中包括CNN、《卫报》和《纽约时报》——这些网站彼此毫无关联,唯一的共同点就是使用同一家CDN服务商。
恢复情况
Fastly在一分钟内检测到了故障,识别并禁用了触发条件,并在49分钟内让95%的网络恢复正常运行——是本清单中从全球性大规模中断恢复速度最快的案例之一。
公布的成本
与本清单中的其他案例不同,Fastly从未公开披露过这一事件的总体财务损失,也没有第三方对其进行独立估算——这提醒我们,许多高知名度的中断事件从始至终都不会产生一个可引用的具体金额。
为何扩散得如此之快
缺陷是旧的,触发条件是新的。
这起事件既揭示了共享基础设施的风险,也展示了一次训练有素的事件响应应有的样子。
一位客户的操作,所有人的中断
仅一个租户的一次有效、被允许的配置变更,就足以让共享平台对其他所有客户产生性能下降——多租户基础设施需要有独立于任何单一客户"保守行事"的爆炸半径控制机制。
快速检测改变了整条成本曲线
一分钟的检测时间加上49分钟的恢复时间,让这起事件的持续时间短到似乎没有任何一家受影响的公司披露过具体损失——这证明了对平均修复时间(MTTR)的投入,恰恰会在最需要的时候得到回报。
常见问题
关于Fastly中断事件的解答。
在CDN依赖或事件响应案例中引用此事件时常见的问题。
这是一次网络攻击吗?
不是——Fastly将其归因于一次由合法客户配置变更触发的软件缺陷,而非任何外部攻击。
为何这起事件没有公布成本数字?
Fastly和受影响的客户网站均未公开披露财务影响——中断持续时间较短,可能降低了公开量化损失的动机或必要性。
为何这么多互不相关的网站会同时瘫痪?
它们都使用Fastly作为内容分发网络,因此Fastly共享基础设施中的一个故障,会影响所有依赖同一受影响容量的客户,无论每个网站自身的可靠性实践如何。
这一事件如何映射到计算器中?
可以使用网站停机计算器,输入一个较短的MTTR数值,看看快速恢复能在多大规模上限制总体损失。
轮到您了