前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >(译)Cloudflare 的部署失误导致了全球故障

(译)Cloudflare 的部署失误导致了全球故障

作者头像
崔秀龙
发布2019-07-22 15:28:39
5910
发布2019-07-22 15:28:39
举报
文章被收录于专栏:伪架构师伪架构师

这篇博客是个占位符,后续会用完整的检验报告进行替换,来披露今天的发生的问题。

今天有大概 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 规则。

我们了解这次事故对用户来说非常痛苦。我们测试过程的不足导致了这一故障,我们正在审查并更改我们的测试和部署流程,来避免此类问题的再次发生。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2019-07-03,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 伪架构师 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • UTC 2009 更新
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档