语雀P0级故障复盘，有9个字亮了

大家好，我是洋子

最近语雀不是出了个号称 “载入史册” 的 P0 级事故嘛 —— 连续宕机接近8个小时无法使用，作为一个大厂知名产品，这个修复速度属实让人无法理解

故障公告原文：https://mp.weixin.qq.com/s/WFLLU8R4bmiqv6OGa-QMcw

很快，官方就发布了《故障公告》。有一说一，这个公告写得还是挺不错的，按照时间线梳理出了各时间节点的处理过程

• 14:07 数据存储运维团队收到监控系统报警，定位到原因是存储在升级中因新的运维工具 bug 导致节点机器下线；
• 14:15 联系硬件团队尝试将下线机器重新上线；
• 15:00 确认因存储系统使用的机器类别较老，无法直接操作上线，立即调整恢复方案为从备份系统中恢复存储数据；
• 15:10 开始新建存储系统，从备份中开始恢复数据，由于语雀数据量庞大，此过程历时较长；
• 19:00 完成数据恢复，同时为保障数据完整性，在完成恢复后，用时 2 个小时进行数据校验；
• 21:00 存储系统通过完整性校验，开始和语雀团队联调。
• 22:00 恢复语雀全部服务，用户所有数据均未丢失。

在改进措施一栏中，先不说具备两地三中心的高可用能力，洋子发现了9个核心关键字可监控，可灰度，可回滚，可以说是维持系统可用性的最基本的保命措施

先举个例子，讲一下这三种能力的用处

可灰度

将系统的新版本全量部署给所有用户之前，先仅对一小部分用户进行试用。这样可以通过收集这部分用户的反馈和监控数据就能评估新版本的稳定性，并及时进行调整和修复，从而减少对全体用户的潜在风险。

灰度发布又有很多策略。比如经典的按流量阶段性发布，先随机给 5% 的用户使用新版本，验证没问题后，再给 20%、50%、75% 的用户使用新版本逐渐放量，直到覆盖 100% 的用户。

还有很多策略，列举几个常见的：

1）按照用户的业务属性灰度，比如 VIP 用户先用、老用户先用。

2）按人群灰度，比如特定地域、特定年龄、特定偏好、特定客户端的用户。

3）按渠道灰度，比如通过某平台注册的用户先体验等等。

灰度做的好，可以避免很多线上问题，及时控制影响。因此很多知名产品发布时都会采用灰度或者内测的策略，这也就是为什么有些同学能第一时间体验到微信新功能，有些同学却没有

可监控

可监控是指能够实时地收集和展示系统运行时的数据和指标，以便开发和运维同学可以及时发现系统问题、更快进行故障排查和性能调优。需要监控的信息可以包括系统性能指标（内存、CPU、带宽等）、业务日志、错误信息等。

可回滚

线上系统出现问题时，可以将已经部署的新版本回退到之前的稳定版本。这样做可以快速恢复系统，减少对用户的影响，并给开发同学足够的时间来排查和修复问题

如果我们的系统具备这样的能力，按照一般的研发测试流程，在我们测试完成测试后，如果是服务端，则进入上线阶段，如果是客户端，则进入发版阶段。在上线和发版阶段，一般来说都是需要先进去一个小流量的范围，先影响一小部分用户，若期间测试验证没有问题，则扩大范围，直到全量，这就是灰度发布的意思，如果灰度期间有监控报警，则可以及时回滚止损，回退到线上的历史版本，避免影响线上用户

如果我们的系统不具备这样的灰度的能力，一方面只能一次性推全新版本，看起来省了不少事，但一旦出现问题，影响线上的全部用户。如果没有监控，出现问题后，我们无法第一时间及时感知，只能被动等着线上用户来反馈问题。如果没有回滚能力，有Bug只能等着再次上线修复，也会拉长造成影响的时间

语雀作为阿里旗下的产品，有千万级用户的体量，内部不应该没有这样的监控平台、灰度发布和部署管理平台，总之令人匪夷所思，另外这次Bug的原因是由于运维工具有Bug，是否经过充分的测试？该不会又有个小同学背锅了

最后，面对这样超级严重的事故，我想说一定要牢记，先止损！先止损！语雀给的赔偿方案还是比较有诚意的，直接给六个月会员，用语雀的小伙伴可以去领取了