哈哈，这个前几天我们公司内部技术群也有在传。整个过程和原因复盘都非常详细，很值得学习。

明天下午还有个复盘和优化分享会 hhh

业内一股清流 当可以直面问题 将事故原委 处理流程分享出来 可以更好的防微杜渐 也可以为业内做个标杆 点赞~

这种怎么测试呢?看蒙了

非常干的文章。
值得细致一看

学习学习！

吸引技术同学最好的作用就是技术公关，这一次 B 站很成功，看得上头

学习了。这都能复盘出来，NB。

看完后，有个疑惑，为啥不做 SLB 的 cpu 的监控告警。。。CPU 使用率达到 100% 才导致服务不可用，优化改进也没看到监控的优化项。

定位问题的能力和方法，还有问题产生后的补救和思考都好值得学习啊

有可能 CPU 升的很快，根因是个递归函数，很短时间就会死循环

其实可以看到，没出事之前，容灾，熔断，都没有演练过，重建也没有演练过，这种东西平时如果有节奏定期演练，事故是可以很快恢复的。

对测试的要求是很高的，然后发现其实大部分都是找开发做的测开，给大家的警示可能是，未来如果所有业务全面上云了，测试该具备怎样的能力？

是的，其实告警等于没有，靠得用户反馈，以及 CPU 报错 100% 才发现，为什么不在 80% 就有预警，可以提前扩容或者降级熔断？SRE 的 KPI 肯定是完不成的。

有好有坏，得辩证分析，取其精华去其糟粕。

描述上看不出是短时间，看描述是小概率会触发到权重为 0 的场景，再经过一段时间才慢慢打到 100% 的

根因人家说的很清楚了：

• Lua 是动态类型语言，常用习惯里变量不需要定义类型，只需要为变量赋值即可。

• Lua 在对一个数字字符串进行算术操作时，会尝试将这个数字字符串转成一个数字。

• 在 Lua 语言中，如果执行数学运算 n % 0，则结果会变为 nan（Not A Number）。

• _gcd 函数对入参没有做类型校验，允许参数 b 传入："0"。同时因为"0" != 0，所以此函数第一次执行后返回是 _gcd("0",nan)。如果传入的是 int 0，则会触发 [ if b == 0 ] 分支逻辑判断，不会死循环。

• _gcd("0",nan) 函数再次执行时返回值是 _gcd(nan,nan)，然后 Nginx worker 开始陷入死循环，进程 CPU 100%。

晓光说这个问题是业务发展发展带来的技术债的累积，其实这是个很宏观的认知，从微观上来说，我觉得可以提示我们几点：

• 弱类型的语言往往依靠更高的单体技术能力和更加充分的团队沟通，靠团队的知识传承（不管是文档还是口头）来获取【参数 b 不要传："0"】这个约定，而如果你用 C# 或者 Java，int b 的定义，传"0"直接编译就过不了，所以弱类型语言更适合精英小团队，注意……不是说它们不行，而是说它们需要被更好的掌控，不要曲解；
• 对基础设施，比如文中提到的 OpenResty（核心是 nginx），往往需要更高的性能和可靠性，这部分功能应该是部分资深核心工程师才可以碰的东西，不能随便拿来交给新人去实施，哪怕 ta 的技术很好，也难免考虑不全周边的影响；
• 性能（要求）越高的程序，对质量要求越高，这个契合晓光观点的说法。一般来说，性能越高，一旦出错，造成的损失越大，可以参考历史上各种高频交易的故障案例。所以这种基础设施模块、涉费模块，都需要一整套的质量保障手段，从 CR、静态扫描到单元测试、系统、性能测试，从安全测试到故障注入和混沌模拟，都得老实认真上……只考虑实现、够用，最终会死得很惨~

不愧是槽神大佬 hhh

这是什么，先看看再说话

复盘了一年时间吗？