#Cloudflare事故

avatar
Folyd
10小时前
cloudflare 事故报告出来了，一行 rust 代码 panic 瘫痪了全球一半流量，具体细节 AI 有解释，但是最重要的是 CloudFlare 内部 code style 很不规范啊，线上的 unwrap() 是一定要完全禁止的，这个世界就是一个巨大的草台班子，非常惨痛的教训
#Cloudflare事故 #Rust panic #流量瘫痪 #代码规范 #草台班子
avatar
估计很多人在等我的技术复盘，那么聊聊 开宗明义，我们应该是目前 All in Cloudflare 公司中这次事故中恢复的最快的一批 Cloudflare 这次的事故其实应该分为两个 Part 来说，DNS 面和数据面。这次炸的实际上是数据面 早在10月20多号，Cloudflare 因为机房在维护而导致流量切换的时候，我们的跨洋访问线路就出现了问题。当时讨论后，我和同事达成一致，决定开始着手将我们的 DNS 和 CDN 分离开来，切换到不同的 vendor 上。 对我们来说 CDN 是 Cloudfront我们在某次冒烟的1h内完成了一条关键链路的迁移。实际上这为我们今天的处理奠定了一个良好的基础 而在本周一，我完成了我们核心域名 Cloudflare 上 DNS record 的 terraform 化。 所以回到事故本身，不同于 AWS 事故我们能做的会相对更少，而 Cloudflare 事故中，我们能尝试做的事情很多。所以我们按照预案，有 Plan A/B A. DNS 和 CDN 双切 B. 在 Cloudflare API 面恢复后仅切换 CDN 我们最后得出结论，选择 Plan B。当然我们也在 Route53 上做好了 Plan A 的准备 而之前准备的 Terraform 实际上在此时帮上了忙，在 Cloudflare API 恢复的第一时间，实际上 Dashboard 和 2FA 等 Auth 还是 failure 的状态。Terraform 帮助我们第一时间完成了切换。同时同事能帮我进行很严谨的 cross check。 分享一些能高效处理事故的 tips 吧 1. 及时拉会，我们事故处理会是一个全员 open 的会 2. 需要有人来承担一号位的职责，负责控场 3. 越忙越容易出错，所有变更一定要同步+cross check，我自己习惯是两次确认“同步：我将变更xx，内容为xxx，请xx帮我确认”，“确认执行，请xx协助验证” 4. 设置关键的时间点，并定时更新时间点。比如我们最开始切换 CDN 时间点定为 , 然后因为临时原因延后。而我们最开始对外恢复公告的时间点定为 UTC+8 ，然后结束前半小时我 reset timer ，定位 UTC+8 。明确的时间点能协助同事更明确知道我们当前在做什么，需要做什么，以及下一步做什么 说实话今晚再一次感受到了有一群很棒的同事是很爽的一件事。我们共同决策，执行指令，处理 corner case，制定接下来的 48h 的 action item，乃至考虑要不要升级数据库（不是（。 期间我有很多在我规划的预案中没有 cover 的部分，而每个同事都在帮助我查漏补缺，这无疑是非常爽的一件事。 如同我们结束了 5h 的全程 follow up 的事故复盘会后，CTO 发的全员感谢信一样“无论是在事先预案和技术实施文档上，还是在应急决策的果断和集体决策（快速信息补齐，临时分工合作，互相 review 找 bug），体现出来的专业性，技术能力，合作精神，都比之前上了不小的台阶” 是的，每个良好的团队，都会随着每一次事故而成长。 最后打个小广告，鄙司目前诚招前/后端/推荐算法/推理加速/infra 等方向的人，如果你想和我们一起成长，欢迎聊聊
#Cloudflare事故 #DNS/CDN分离 #快速恢复 #团队合作 #事故复盘