文章摘要
GPT 4
投诉

至暗时刻

2021年7月13日22:52，SRE收到大量服务和域名的接入层不可用报警，客服侧开始收到大量用户反馈B站无法使用，同时内部同学也反馈B站无法打开，甚至APP首页也无法打开。基于报警内容，SRE第一时间怀疑机房、网络、四层LB、七层SLB等基础设施出现问题，紧急发起语音会议，拉各团队相关人员开始紧急处理（为了方便理解，下述事故处理过程做了部分简化）。

初因定位

22:55 远程在家的相关同学登陆VPN后，无法登陆内网鉴权系统（B站内部系统有统一鉴权，需要先获取登录态后才可登陆其他内部系统），导致无法打开内部系统，无法及时查看监控、日志来定位问题。

22:57 在公司Oncall的SRE同学（无需VPN和再次登录内网鉴权系统）发现在线业务主机房七层SLB（基于OpenResty构建） CPU 100%，无法处理用户请求，其他基础设施反馈未出问题，此时已确认是接入层七层SLB故障，排除SLB以下的业务层问题。

23:07 远程在家的同学紧急联系负责VPN和内网鉴权系统的同学后，了解可通过绿色通道登录到内网系统。

23:17 相关同学通过绿色通道陆续登录到内网系统，开始协助处理问题，此时处理事故的核心同学（七层SLB、四层LB、CDN）全部到位。

故障止损

23:20  SLB运维分析发现在故障时流量有突发，怀疑SLB因流量过载不可用。因主机房SLB承载全部在线业务，先Reload SLB未恢复后尝试拒绝用户流量冷重启SLB，冷重启后CPU依然100%，未恢复。

23:22  从用户反馈来看，多活机房服务也不可用。SLB运维分析发现多活机房SLB请求大量超时，但CPU未过载，准备重启多活机房SLB先尝试止损。

23:23  此时内部群里同学反馈主站服务已恢复，观察多活机房SLB监控，请求超时数量大大降低，业务成功率恢复到50%以上。此时做了多活的业务核心功能基本恢复正常，如APP推荐、APP播放、评论&弹幕拉取、动态、追番、影视等。非多活服务暂未恢复。

23:25 - 23:55 未恢复的业务暂无其他立即有效的止损预案，此时尝试恢复主机房的SLB。

我们通过Perf发现SLB CPU热点集中在Lua函数上，怀疑跟最近上线的Lua代码有关，开始尝试回滚最近上线的Lua代码。
近期SLB配合安全同学上线了自研Lua版本的WAF，怀疑CPU热点跟此有关，尝试去掉WAF后重启SLB，SLB未恢复。
SLB两周前优化了Nginx在balance_by_lua阶段的重试逻辑，避免请求重试时请求到上一次的不可用节点，此处有一个最多10次的循环逻辑，怀疑此处有性能热点，尝试回滚后重启SLB，未恢复。
SLB一周前上线灰度了对 HTTP2 协议的支持，尝试去掉 H2 协议相关的配置并重启SLB，未恢复。

新建源站SLB

00:00  SLB运维尝试回滚相关配置依旧无法恢复SLB后，决定重建一组全新的SLB集群，让CDN把故障业务公网流量调度过来，通过流量隔离观察业务能否恢复。

00:20  SLB新集群初始化完成，开始配置四层LB和公网IP。

01:00  SLB新集群初始化和测试全部完成，CDN开始切量。SLB运维继续排查CPU 100%的问题，切量由业务SRE同学协助。

01:18  直播业务流量切换到SLB新集群，直播业务恢复正常。

01:40  主站、电商、漫画、支付等核心业务陆续切换到SLB新集群，业务恢复。

01:50  此时在线业务基本全部恢复。

恢复SLB

01:00 SLB新集群搭建完成后，在给业务切量止损的同时，SLB运维开始继续分析CPU 100%的原因。

01:10 - 01:27 使用Lua 程序分析工具跑出一份详细的火焰图数据并加以分析，发现 CPU 热点明显集中在对 lua-resty-balancer 模块的调用中，从 SLB 流量入口逻辑一直分析到底层模块调用，发现该模块内有多个函数可能存在热点。

01:28 - 01:38 选择一台SLB节点，在可能存在热点的函数内添加 debug 日志，并重启观察这些热点函数的执行结果。

01:39 - 01:58 在分析 debug 日志后，发现 lua-resty-balancer模块中的 _gcd 函数在某次执行后返回了一个预期外的值：nan，同时发现了触发诱因的条件：某个容器IP的weight=0。

01:59 - 02:06 怀疑是该 _gcd 函数触发了 jit 编译器的某个 bug，运行出错陷入死循环导致SLB CPU 100%，临时解决方案：全局关闭 jit 编译。

02:07 SLB运维修改SLB 集群的配置，关闭 jit 编译并分批重启进程，SLB CPU 全部恢复正常，可正常处理请求。同时保留了一份异常现场下的进程core文件，留作后续分析使用。

02:31 - 03:50 SLB运维修改其他SLB集群的配置，临时关闭 jit 编译，规避风险。

根因定位

11:40 在线下环境成功复现出该 bug，同时发现SLB 即使关闭 jit 编译也仍然存在该问题。此时我们也进一步定位到此问题发生的诱因：在服务的某种特殊发布模式中，会出现容器实例权重为0的情况。

12:30 经过内部讨论，我们认为该问题并未彻底解决，SLB 仍然存在极大风险，为了避免问题的再次产生，最终决定：平台禁止此发布模式；SLB 先忽略注册中心返回的权重，强制指定权重。

13:24 发布平台禁止此发布模式。

14:06 SLB 修改Lua代码忽略注册中心返回的权重。

14:30 SLB 在UAT环境发版升级，并多次验证节点权重符合预期，此问题不再产生。

15:00 - 20:00 生产所有 SLB 集群逐渐灰度并全量升级完成。