2021.10.08 宕机事件的深度复盘

修改于2021/11/083098 浏览综合

各位 Taper，

今天是 11月08日，一个月前的今天，上午10点，由于英雄联盟手游的开启，瞬间涌入了大量的玩家，但是 TapTap 却发生了严重的宕机故障：

1. 整站长达 42 分钟的宕机。表现为首页无法打开，下载页面无法打开，玩家收到预约通知后，无法打开下载页面，打开页面也无法下载英雄联盟。

2. 英雄联盟手游的下载直到 11:07 才生效，比官方延迟了 67 分钟。

1. 深层原因

腾讯在10月08日凌晨0点宣布将于当日上午10点开启不删档测试，在我们团队内部，社区与开发者运营的同学立刻通知了技术。但万分遗憾的是，运营与技术同学对于英雄联盟手游上线时的瞬间峰值流量没有进行定量的确认，只是定性地通知了“当日用户数会创新高“、”下载流量会跑满”，而运维同学严重低估了 10:00 的峰值 QPS，于是造成一系列的准备不足：

1. 服务器相关资源准备不足。由于 TapTap 的生产环境已大量基于容器技术，随着流量高峰与低谷，整个系统可自动拓展和回收资源。当时已经知道会迎来史上最大的访问量了，技术同事的关注点只聚焦于预先申请足够的计算资源，以防自动扩展时整个机房无可用资源。

2. 重视程度不足。当时正值国庆长假结束，而我们团队多位负责人仍在休假，当日凌晨才知道游戏上线，已没有余地重新安排及时回到公司。在多位负责人不在现场的情况下，各团队间的沟通明显不足，故障发生后大家只能远程接入电话，拖慢了整个信息的沟通和决策，最终造成 42 分钟的故障时间与 67 分钟的游戏传包延迟。

2. 当日时间线

- 10:00：收到阿里云与监控宝的报警，报主站 API 500和超时。此时因为我们运营管理员的后台与主站 API 共用一套资源，造成我们管理员也无法打开后台操作。直至 10:40 左右与主站 API 一同恢复。

- 10:10：发现多个阿里云 SLB 达到 QPS 峰值上线，开始紧急扩容。- 10:24：SLB 扩容后，502 错误仍然持续，发现是 nginx 报错，于是临时增加所有 nginx 容器的 workers 数量。扩容后，502 错误消失，500 错误出现。

- 10:37：发现某数据库的读写分离中间件所在容器的 CPU 达到 100%。紧急扩容后，500 错误开始逐渐消失。

- 10:42：整站恢复正常。运营开始操作管理后台，上传英雄联盟手游的下载包体。

- 11:07：经过上传、包体自动检测、测试，游戏下载页正式开放下载。

包体上传属于低级的决策失误，完全可以从服务器直接下载。但是这个直接贴连接下载的工具平时极少使用，运营同学不知道是否可靠，不敢尝试，而使用人工下载再上传的方式，拖慢了恢复周期。

3. 事故后果

今年全站核心业务模块的 SLA（服务等级协议）的既定目标是 99.99%，即，全年故障时间不超过 52 分钟。然而，加上今年 07月13日 14:26 ~ 14:38 ，由于线上生产环境配置错误，全站 502 错误持续 12 分钟，合并本次 42 分钟的故障时间后，2021 全年已累计核心服务不可用 54 分钟，全年 SLA 既定目标已经失败。

虽然全年宕机时间并没有大幅超过 SLA，但是这种玩家关注度极高的时刻，我们失去的是第一时间想到来 TapTap 的玩家们的信任。特别是当看到10点整的服务请求量像一根直线一样上升，我们看到的是 TapTap 长期积累的玩家信任。

4. 整改措施与进度

重要的是，如何重获大家的信任！这次教训，让我们发现在服务稳定性的整条链路上还有很多缺失的环节，另外团队内的充分沟通显得尤为重要。

- 「Closed」管理后台与主站资源分离，意外出故障时可保证管理后台是可用的。

- 「Closed」还不具备自动扩展的资源，比如这次的网关，都已做好充分的扩容，和后续继续扩容的准备。

- 「Closed」定期执行用户侧核心流量链路的压测。

- 「In Progress」定期执行全链路压测。

- 「In Progress」多层级的服务降级预案。

- 管理上，重大事件在团队内形成项目，通过立项来拉起从运营到研发的服务保障团队，确保提前准备好充分的备案，即使发生故障时，也能以最快速度沟通解决。