Gkirito

估计很多人在等我的技术复盘，那么聊聊 开宗明义，我们应该是目前 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 等方向的人，如果你想和我们一起成长，欢迎聊聊

搬家魅力时刻 +1

国内前端面试最多的就是问 vue 源码 react 源码，放十年前就是 jQuery 源码，我就想知道，你这么爱做阅读理解，学没上够就滚回去上学吧，没必要出来工作，框架作者辛辛苦苦写出来是为了让你少写点，给你节省时间，不是让你节省的时间去读源码，去做阅读理解，这段代码表达了作者什么感情，大部分中国上班的开发是不是魔怔了，自己淋过雨，必须把别人伞折了？不知道这风气谁带出来的，还有那个逼框架，来来回回问你妈呢，你工作离不开这 b 框架写不了还是你只会用框架写页面？没其他技能了？这么爱看源码你怎么不去问 v8 chromium 源码，有这时间，你真不如多学一门语言

我用过多个国内公有云、AWS、Google Cloud，但登录azure云后，我居然花了5分钟在他们的页面上，还没有找到如何创建一台虚拟机的方法。。。我是不是有点菜。