语雀故障事件——P0级别事故启示录 &amp； 发生肾么事了？ 怎么回事？_p0事故 处理思路(1)

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

• 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应用程序的监控

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取

5%以上软件测试知识点，真正体系化！**

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取