语雀宕机有感

type

status

date

slug

summary

引言

前两天语雀发生了非常严重的生产事故，导致用户无法登陆使用软件，不可用时间达到了7个小时之久，对于这件事情产生了一些关于笔记、可用性的想法，这里做下记录。

事件记录

事故公告

事件官方复盘

下面是语雀官方在服务恢复之后作出的复盘，我直接摘抄过来引用下。
各位语雀的用户：
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 个月的会员服务。操作流程：进入工作台「账户设置」，点击左侧「会员信息」，在会员信息页面点击「立即领取」，即可获得赠送服务。
针对语雀空间用户，由于情况比较复杂，我们会单独制定赔偿方案。请空间管理员留意语雀站内信。
这次的故障让我们深切地感受到了用户对语雀的依赖以及语雀肩上的重大责任。再次向所有语雀用户表达我们诚挚的歉意。我们将持续提升语雀的服务质量和服务稳定性，不辜负每一位用户的信任！
语雀团队

高可用的思考

个人笔记的高可用

笔记作为个人的想法记录，试想如果这次语雀的事故造成了数据丢失，或者说你的笔记选择了其他的平台例如有道云笔记、坚果云笔记、notion等，发生了数据丢失的问题，对于你会不会产生转移平台的动摇呢？

（其实我注册语雀的时间也很早，不过使用了一段时间后忘记了什么原因转移到了其他平台）

上面提到的这些软件或多或少我都使用过，其实在某些场景下我是遇到过在多个设备上编辑造成数据丢失情况的，当我的笔记数据丢失后，我的第一想法就是难受，因为梳理想法的时间很宝贵，而且更重要的是，你可能很难回忆起之前梳理好的所有想法，这也就意味着你需要重新去梳理去总结。

一些个人建议

选择笔记软件的一些考量因素：

功能丰富，参考语雀、飞书、notion等提供的功能；

支持云同步，可以是官方提供的功能或者是官方提供了扩展使用第三方的插件能够实现同步，基于同步机制的不同，笔记可能存储到软件官方的云端，也可能是上传到个人的GitHub仓库、亚马逊S3等；

多设备终端支持，意味着你能够在移动端、家庭、公司等环境无缝切换

支持本地离线编辑，其实这点语雀也是支持的，但是在出现故障之后所有本地设备也变得无法使用

支持导出导入，这意味着你可以方便地在各个软件之间进行存储，或者至少支持你不只是软件自身提供的功能来存储数据。

笔记软件的选择没有对错，要根据自己的喜好以及取舍来决定，只要能够用着舒心，不会因为担心数据丢失等问题闹心，我还是那个观点，笔记软件只是载体，好用可能让你的想法能够输出的更加自然，更重要的，还是你脑海里的那些宝贵观点。

公司产品的高可用

无论是2C场景的产品还是2B场景的企业或者工业产品，基本上都会有可用性的要求(SLA)，下面列一些我能够想到的因素：

分场景讨论，对于2C产品来说一般是自有服务部署，对外提供服务，也就是说对外提供的是发行软件包，用户通过网络来访问公司产品提供的服务；而对于2B场景来说，一般是公司提供软件、硬件给企业，可能需要将服务部署到客户要求的云环境或者自有机房。

软件高可用

测试覆盖：基础单元测试、集成测试、压力测试、自动化测试等

服务监控与告警：监控软件的请求量、失败请求、内存压力、CPU压力等

服务水平扩展与自动降级：水平扩展是在服务压力增加时能够自动扩展节点，避免服务请求积压；自动降级则是当某个服务出现故障后能够自动根据失败请求比例选择短路，避免拖垮其他服务；

灰度发布：或者金丝雀发布，新版本的升级需要先将少量请求切换到新版本服务，验证无误后再逐步升级

依赖环境的高可用部署方案：例如数据存储采用MySQL，缓存方案采用Redis，那么需要根据服务需要结合这些软件的手册，部署高可用方案（主从、哨兵、分片+副本等）

硬件高可用

硬盘存储：重要数据节点，采取RAID多硬盘同步数据

电源：紧急供电电源UPS、多电源供电方案等

基础设施的高可用

集群部署（摆脱单机故障）

多机房部署：避免网络故障、机房断电等问题

多区域部署：避免区域性灾难，多数据中心存储

多云存储：公有云与私有云结合、多家云环境部署等

上述只是目前我能够想到的一些支撑产品高可用的想法，后续随着我的阅历增加也可能在回头补充，或者另外专门整理一篇关于高可用的总结。

低可用性带来的负面影响

语雀的这次事故对于一款已经非常成熟的笔记软件来说，可谓是非常严重的生产事故，虽然事故发生后，官方给予了所有用户6个月的会员时长，可谓是诚意很足，但是就我从互联网🛜上了解到的很多想法，从这次事故来看，很多用户已经对语雀的可靠性产生了动摇，考虑将个人的数据转移到其他平台，更何况目前其实有很多公司也将语雀作为了团队知识库进行协作，这意味着这场事故对2b2c用户都造成了或大或小的影响。

公司资产损失

出现可用性事故后，像语雀这次给予用户会员补偿，其实损失的也是自己的未来收益；而对于我经历过的工业级软件的可用性事故，可能会直接面对客户的经济索赔；这些都是可预见的收益流失，但相对这种财富损失来说，更可怕的是现有客户资源以及潜在用户的流失，这意味着未来机会的丧失。

产品形象降低

在市场环境竞争的情况下，一款产品出现可用性问题，意味着产品可能在公司内部存在着诸多问题：是否缺乏故障演练、没有部署高可用方案、没有设计快速的故障恢复方案等等；一旦这种问题出现，意味着用户一定会对你的产品产生怀疑态度，甚至可能会因为这个产品而对公司产生不好的印象，这些都会或多或少降低公司产品的竞争力，而要改变客户的看法，可能需要很长时间的发展，这意味着可能会错过很多机会。

其他随笔

别把鸡蛋放在同一个篮子，因为篮子可能坏，而且你的鸡蛋可能被人惦记。狡兔还知道刨三窟呢；

其实做笔记的过程，谁说不是高可用的过程呢，我们因为某件事而产生的感悟，可能转瞬即逝，只有把想法记录下来，才不会让这种宝贵的精神财富流失；

笔记是想法的文字体现，照片、视频是美好记忆的媒介存储，所有这些内容的特征之一在于，一旦丢失后，很难再去制造出一份一模一样的内容，毕竟，记忆是难以复制的。

经历的或者看的这种事故多了，或者说你的笔记（照片）等数据丢失几次之后，相信我，你一定会自发养成高可用的习惯，包括不限于多设备同步、云盘备份、本地存储设备备份等。

希望我们都能从这些事件里，考虑一下自己的数据怎么保证不被丢失，尽可能让自己的财富不会流失。

参考链接

[语雀对于宕机事故的官方说明](https://mp.weixin.qq.com/s/WFLLU8R4bmiqv6OGa-QMcw)