这篇博客是个占位符，后续会用完整的检验报告进行替换，来披露今天的发生的问题。
今天有大概 30 分钟，Cloudflare 网站的浏览者收到了 502 错误，起因是我们网络中的 CPU 使用率飙升。这个 CPU 的峰值是由一个错误的软件部署造成的，这一错误已经回滚，回滚后，服务恢复正常，Cloudflare 返回到了正常的通信水平。
这并不是一次攻击（有人如此猜测），我们对此事故深表抱歉。我们正在开会和编写完整的调查报告来理解问题的来龙去脉，并在未来防止同类问题的再次发生。
UTC 2009 更新
在今天的 UTC 1342，我们经历了一次全网范围内的故障，所有访问被 Cloudflare 代理的域都显示 502 错误（“Bad Gateway”）。在一次 Cloudflare 防火墙（WAF）规则的例行部署中，一条配置错误的规则引发了这次问题。
这个新规则的作用是屏蔽一条用于攻击的 inline JavaScript。这些规则用一种虚拟方式进行部署，这样一来新规则会识别问题并进行记录，但不会阻断用户的流量，这样我们就可以对误报率进行测量，以保障新规则进行全面生产部署时不会出现问题。
不幸的是，这些规则中有一条包含了一个正则表达式，导致 CPU 使用率升到 100%。这个 CPU 高峰导致用户看到了 502 错误。最差的情况下有 82% 流量被丢弃。
下面的图示表明了 CPU 的使用情况。
这对我们来说是一个全新体验，因为我们之前没有经历过全球 CPU 耗尽的事故。
我们持续的在网络上进行软件部署，用自动系统运行测试，并且有渐进的部署过程来预防事故。很不巧，WAF 规则是一次性的全球部署的，这是今天事故的主因。
在 UTC 1402，我们认识到了问题所在，决定在 WAF 上来一次全局 kill，这一对策让 CPU 用量恢复正常，在 UTC 1409 解决了问题。
我们接下来对相关的 PR 进行评审，对特定规则进行回滚，测试变更内容以保证我们对问题的修复，并在 UTC 1452 重新启用 WAF 规则。
我们了解这次事故对用户来说非常痛苦。我们测试过程的不足导致了这一故障，我们正在审查并更改我们的测试和部署流程，来避免此类问题的再次发生。
本文分享自微信公众号 - 伪架构师（fake-architect）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。