大家好，这里是码外生活，也可以叫我热爱分享的小码哥，希望能通过写文章的方式与大家一起学习一起进步！💖
众所周知在10月份语雀发生了一个宕机事件，作为旁观者，我们可以多了解一下事故的前因后果，在这个阶段中我们也能学习知识，吸取教训~
我们先阅读一下来自语雀官方的宕机事件总结。
各位语雀的用户：
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 日
事故复盘
抽取关键字，我们可以总结出这次事件的一些信息。
| 责任人 | 语雀的数据存储运维团队 |
|---|---|
| 故障等级 | P0 |
| 故障简述 | 由于新的运维升级工具 bug，导致华东地区生产环境存储服务器被误下线。 |
| 发现方式 | 监控系统报警 |
| 故障发现时间 | 10 月 23 日 下午 14:07 |
| 故障发生时间 | 10 月 23 日 下午 14:07 |
| 故障恢复时间 | 10 月 23 日 晚上 20:00 |
| 故障影响时长 | 大于等于8小时 |
业务影响
| 影响业务场景 | 投诉情况 |
|---|---|
| 💔无法工作 | 由于所有东西都在语雀上，语雀挂了没法干活了。 |
| 🤒态度消极 | 许多用户对于语雀的前景表达堪忧 |
问答
语雀遵循了什么模式？
这里科普一下常见的几种服务思想。
BaaS：（后端即服务，Backend as a Service），公司为移动应用开发者提供整合云后端的边界服务。
IaaS：（基础设施即服务，Infrastructure as a Service），要搭建上层数据应用，先得通过互联网获得基础性设施服务。
PaaS：（平台即服务，Platform-as-a-Service），搭建平台，集成应用产品，整合起来提供服务。
SaaS：（软件即服务，Software-as-a-Service），通过网络提供程序应用类服务。
如果看概念觉得难以理解和记忆，我们可以这样理解。
正常的软件开发流程中需要前端开发，后端开发，应用所需的运行，上线的服务器等，而不同的服务则是代表用户缺少什么，商家则为其补充什么。（例如用户自己有前端，那其他的需要商家提供，则可以选择BaaS服务），语雀遵循的是BaaS服务模式。
| 前端 | 后端 | 环境 | 服务器 | |
|---|---|---|---|---|
| SaaS | 商家提供 | 商家提供 | 商家提供 | 商家提供 |
| BaaS | 自己准备 | 商家提供 | 商家提供 | 商家提供 |
| PaaS | 自己准备 | 自己准备 | 商家提供 | 商家提供 |
| IaaS | 自己准备 | 自己准备 | 自己准备 | 商家提供 |
语雀技术栈是怎么样的？
语雀采用的是微服务架构。
由于语雀是一个在线文档应用，会有多人协同开发的场景，因此使用将协同服务和代理服务划分，有助于减轻负担。由于 node 不擅长 cpu 密集的场景，因此将其他需要大量 cpu 运算的功能使用函数计算解决。以上架构都可以使语雀这个应用更加稳定。
什么是可灰度，可监控，可回滚？
可灰度：将新版本的软件部署到一小部分用户或服务器上，然后逐步扩大范围， 直到所有用户都使用新版本。这种逐步发布的方式可以帮助开发团队及时发现和解决潜在的问题，同时减少对整个系统的风险影响。（相当于内测版本）
可监控：实时 收集、分析和展示系统的各种指标（如内存，cpu，带宽）和日志数据多方面的监测，并在出现异常情况时进行报警。
可回滚：如果出现问题或意外情况，可以快速恢复到之前的稳定版本。可回滚是一种应急措施，它可以提供一种安全的退路，使开发团队能够在出现问题时快速恢复并进行故障排除。
语雀为何连续宕机超过4个小时？
部分原因为猜测。
- 人才的流失——运维核心技术骨干，应用创始人的出走导致故障的定位，处理，解决速度缓慢。
- 决策的错误——大型应用必须每半年对这种大型事故进行排练，很可能平时没有演练，因此导致当事故发生时，人员们手足无措。
- 出走员工的一次损害行为（阴谋论）。
- 文档存放于语雀应用中，当语雀挂了后，内部员工只能通过看代码抢救。
语雀是如何处理的？
- 升级硬件版本和机型，实现离线后的快速上线。该措施在本次故障修复中已完成。
- 运维团队加强运维工具的质量保障与测试，杜绝此类运维 bug 再次发生。
- 缩小运维动作灰度范围，增加灰度时间，提前发现 bug。
- 从架构和高可用层面改进服务，为语雀增加存储系统的异地灾备。
- 每人赠送半年的会员。
语雀的前景？
功能与钉钉重合；不被重视的地位；核心骨干以及创始人出走；语雀的未来还是一片光明吗？若干年之后，会不会不再有语雀这个应用的存在？亦或是通过这个事故让管理层重视到应用的缺陷，重新投入资源，将语雀变得更好？
总结
对于语雀：事后的维护总体来说还是很成功的，没有数据的丢失，也做好了事后的公关作业（每人半年会员）。
对于我们： 作为一个普通人 ， 也许有的人会选择抱着吃瓜的心态浏览这个热点，但是这种重大事故的发生是不常见的事情，我们何不这个情景代入到自己，多从事故的起因，事故的修复，事故的公关作业等方面思考。常言道，我们要站在巨人的肩膀上看世界，但是一次认真的事故复盘又何尝不是站在巨人的肩膀之上呢？
👀最后
如果我的文章能帮到大家，希望大家能动动小指头给我个点赞吧~💐💖
