语雀故障事件——P0级别事故启示录 & 发生肾么事了？ 怎么回事？

前言

最近，阿里系的语雀出了一个大瓜，知名在线文档编辑与协同工具语雀发生故障，崩溃近10小时。。。。最后，官方发布了一则公告，我们一起来看看这篇公告，能不能有所启发。

引出

---

1.在保证分区容错下，无法同时做到一致性和可用性。系统设计时只能选择一个目标，在P一定会出现的情况下，A和C之间只能实现一个，这就是CAP定理。

• CP: 强一致性，弱可用性，牺性部分机器的可用性，保证数据一致性，如zookeeper、es、Naocs
• AP: 强可用性，弱一致性，牺牲一致性，保证可用性，如Eureka

2.可监控，可灰度，可回滚

一、语雀P0故障回顾

1、发生肾么事了？？？

2、官方公告说了啥？

各位语雀的用户：

10 月 23 日语雀出现重大服务故障，且持续 7 个多小时才完全恢复，给用户使用造成极大不便，对此我们深感抱歉。经过复盘，我们在这里向大家进一步说明故障原因、修复过程和改进措施。

故障原因及处理过程：

10 月 23 日下午，服务语雀的数据存储运维团队在进行升级操作时，由于新的运维升级工具 bug，导致华东地区生产环境存储服务器被误下线。受其影响，语雀数据服务发生严重故障，造成大面积的服务中断。为了尽快恢复服务，我们和数据存储运维团队全力进行数据恢复工作，但受限于恢复方案、数据量级等因素，整体用时较长。具体过程如下：

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

改进措施：

通过这次故障我们深刻认识到，语雀作为一款服务千万级客户的文档产品，应该做到更完善的技术风险保障和高可用架构设计，尤其是面向技术变更操作的“可监控，可灰度，可回滚”的系统化建设和流程审计，从同 Region 多副本容灾升级为两地三中心的高可用能力，设计足够的数据和系统冗余实现快速恢复，并进行定期的容灾应急演练。只有这样，才能提升严重基础设施故障时的恢复速度，并从根本上避免这类故障再次出现。为此我们制定了如下改进措施：

1、升级硬件版本和机型，实现离线后的快速上线。该措施在本次故障修复中已完成；

2、运维团队加强运维工具的质量保障与测试，杜绝此类运维 bug 再次发生；

3、缩小运维动作灰度范围，增加灰度时间，提前发现 bug；

4、从架构和高可用层面改进服务，为语雀增加存储系统的异地灾备。

赔偿方案：

为了表达我们的歉意，我们将向所有受到故障影响的用户提供如下赔偿方案：

针对语雀个人用户，我们赠送 6 个月的会员服务。操作流程：进入工作台「账户设置」，点击左侧「会员信息」，在会员信息页面点击「立即领取」，即可获得赠送服务。

针对语雀空间用户，由于情况比较复杂，我们会单独制定赔偿方案。请空间管理员留意语雀站内信。

这次的故障让我们深切地感受到了用户对语雀的依赖以及语雀肩上的重大责任。再次向所有语雀用户表达我们诚挚的歉意。我们将持续提升语雀的服务质量和服务稳定性，不辜负每一位用户的信任！

语雀团队

2023 年 10 月 24 日

二、解构官方公告

1、怎么回事？

10 月 23 日下午，服务语雀的数据存储运维团队在进行升级操作时，由于新的运维升级工具 bug，导致华东地区生产环境存储服务器被误下线。

• 14:07 数据存储运维团队收到监控系统报警，定位到原因是存储在升级中因新的运维工具 bug 导致节点机器下线；【说明人家有运维监控系统】

• 14:15 联系硬件团队尝试将下线机器重新上线；15:00 确认因存储系统使用的机器类别较老，无法直接操作上线，立即调整恢复方案为从备份系统中恢复存储数据。【有备份系统，保存所有历史数据】

• 15:10 开始新建存储系统，从备份中开始恢复数据，由于语雀数据量庞大，此过程历时较长，19 点完成数据恢复；

  • 同时为保障数据完整性，在完成恢复后，用时 2 个小时进行数据校验；【数据校验，数据完整性】
  • 21 点存储系统通过完整性校验，开始和语雀团队联调，最终在 22 点恢复语雀全部服务。【数据恢复，开始联调】
  • 用户所有数据均未丢失。【硬件有价，数据无价】

2、解构改进措施

通过这次故障我们深刻认识到，语雀作为一款服务千万级客户的文档产品，应该做到更完善的技术风险保障和高可用架构设计，尤其是面向技术变更操作的“【【可监控，可灰度，可回滚】】”的系统化建设和流程审计，从同 Region 多副本容灾升级为两地三中心的高可用能力，设计足够的数据和系统冗余实现快速恢复，并进行定期的容灾应急演练。只有这样，才能提升严重基础设施故障时的恢复速度，并从根本上避免这类故障再次出现。为此我们制定了如下改进措施：

1、升级硬件版本和机型，实现离线后的快速上线。该措施在本次故障修复中已完成；
2、运维团队加强运维工具的质量保障与测试，杜绝此类运维 bug 再次发生；
3、缩小运维动作灰度范围，增加灰度时间，提前发现 bug；
4、从架构和高可用层面改进服务，为语雀增加存储系统的异地灾备。

我们看到事故复盘中，出现了**【【可监控，可灰度，可回滚】】**，这是什么意思，可监控如何实现？可灰度是啥意思，实际怎么操作？可回滚是啥？我们会在下一章分析。

另外，这里反复提到了容灾、高可用，这和CAP理论息息相关，1998年，加州大学的计算机科学家Eric Brewer提出，分布式系统有三个指标。

• Consistency(一致性)
• Availability(可用性)
• Partition tolerance(分区容错性)

其中最为重要的是Partition tolerance(分区容错性)，也是所有分布式系统必须满足的条件：

• Partition(分区)：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。

• Tolerance(容错)：容错表示在集群出现分区时，整个系统也要持续对外提供服务。

在保证分区容错下，无法同时做到一致性和可用性。系统设计时只能选择一个目标，在P一定会出现的情况下，A和C之间只能实现一个，这就是CAP定理。

• CP: 强一致性，弱可用性，牺性部分机器的可用性，保证数据一致性，如zookeeper、es、Naocs
• AP: 强可用性，弱一致性，牺牲一致性，保证可用性，如Eureka

通过上面的分析，我们看到语雀采用的是高可用容灾的策略，也就是AP模式，保证强的可用性，本次事件就是造成了大面积的不可用。

详细的CAP理论可参考下面博客：

分布式事务——CAP理论 & 解决分布式事务的思路 & Seata组件初识 和 部署

三、聚焦 “可监控，可灰度，可回滚”

1、可监控

监控（Monitoring）：收集、分析和使用信息来观察一段时间内的运行进度，并且进行相应的决策管理的过程。监控侧重于观察特定指标。

可观测性（Observability）：通过分析系统生成的数据理解推演出系统内部的状态。

可使用的工具JVisualVM、JConsole、skywalking、Prometheus和Grafana来实现Java Web应用程序的监控

JVisualVM：https://visualvm.github.io/

参考文章：
https://zhuanlan.zhihu.com/p/512714915#

2、可灰度

什么是灰度发布？

• 灰度发布，又名金丝雀发布，或者灰度测试，是指在黑与白之间能够平滑过渡的一种发布方式。在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。

灰度发布是对某一产品的发布逐步扩大使用群体范围，也叫灰度放量。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。

灰度期：灰度发布开始到结束期间的这一段时间，称为灰度期。

灰度发布的意义
灰度发布能及早获得用户的意见反馈，完善产品功能，提升产品质量，让用户参与产品测试，加强与用户互动，降低产品升级所影响的用户范围。

灰度发布的策略

1. 按照流量阶段性发布，先随机给5%的用户使用新版本，没问题后，再依次给20%、50%、75%的用户使用新版本，最后100%；
2. 按照用户的业务属性灰度，VIP优先等…

3、可回滚

就是想git一样，可以把版本进行回退。

总结

1.在保证分区容错下，无法同时做到一致性和可用性。系统设计时只能选择一个目标，在P一定会出现的情况下，A和C之间只能实现一个，这就是CAP定理。

• CP: 强一致性，弱可用性，牺性部分机器的可用性，保证数据一致性，如zookeeper、es、Naocs
• AP: 强可用性，弱一致性，牺牲一致性，保证可用性，如Eureka

2.可监控，可灰度，可回滚