语雀崩溃的原因找到了！运维的锅！
昨天晚上21点12分语雀在微博发布了一份正式的故障情况说明，大概说了下故障的原因、处理的流程，还说了以后怎么改进、给用户怎么赔偿，算是比较全面。
昨天晚上和今天白天我都没能抽出时间，所以没有及时跟进，现在正好在地铁上，就来给大家解读下。
事件经过
我们先来回顾下事情的经过。
- 10月23日下午14点左右语雀出现不能访问的问题，有用户开始在社区发问。
- 15点官方发了一份网络故障公告。
- 16点左右官方又发了一份公告，大概意思是数据不会丢失，因为网上已经开始讨论是不是有人删库跑路了，算是安抚了一下用户的焦躁心情。
- 晚上22点半左右，语雀发布公告说故障已经解决，服务已全部恢复，同时提到后续会给大家同步详细情况。
- 24日晚上21点左右，经过一天的漫长等待，官方发布了正式的故障复盘说明。
官方发布的故障总时长是7个多小时，用户实际受影响的时间应该比这要长点，因为系统不是一下就能完全恢复的，这有个过程。
故障解读
我们看下官方的说明，灰色的文字是我从语雀的公告中摘抄的内容，黑色的文字是我的评论。
10 月 23 日下午，服务语雀的数据存储运维团队在进行升级操作时，由于新的运维升级工具 bug，导致华东地区生产环境存储服务器被误下线。
语雀没有独立的数据存储运维团队，是外包的，实际上也没必要自己啥都干，特别语雀属于上层应用。可能外包给了阿里云，毕竟都是一个大体系中的，一来放心，二来照顾下生意。虽说阿里云去年在香港也出了很大的问题，运维水平应该有所改善，但是挡不住摊子太大，边边角角的还是照顾不到；加上不同的业务，人员之间的沟通可能也不是很顺畅。
这里没说是什么数据，无论是非结构化数据还是关系数据库数据，语雀没有使用公有云的存储服务，否则不应该受影响的只有它，应该是阿里云或者内部的其它团队搭建了一个独立的存储服务。这样做可能成本更低，也许还有一些业务上的特殊要求。
运维升级工具没有经过严格的测试，升级流程也可能有点随意，不确定是下午升级后立即出现问题的，还是运行到某个时候出现问题的。
其中提到华东地区，结合阿里云的节点分布，语雀的服务器在杭州或者上海，杭州的面大一些，大本营嘛，比较方便。
14:07 数据存储运维团队收到监控系统报警，定位到原因是存储在升级中因新的运维工具 bug 导致节点机器下线；
稍微大点的服务都会部署一套监控系统，可以监控硬件、操作系统、网络和应用服务出现的警告和故障，如果故障的指向性很明显，快速定位问题不难。
14:15 联系硬件团队尝试将下线机器重新上线；
这里没说清楚，按说存储应该也是多活的，一般为了高可用会将数据保存多份，保存到不同的机器节点，这个可以参考Hadoop，很成熟的方案了。难道所有的存储节点都下线了，还是说根本没有多活？对于专业的收费文档服务来说，没有多活有点说不过去。
下线可能是调用的API，但是存储团队不知道怎么上线，可能要做一些硬件配置才行，于是联系硬件团队。
15:00 确认因存储系统使用的机器类别较老，无法直接操作上线，立即调整恢复方案为从备份系统中恢复存储数据。
机器类别较老这个客观事实确实存在，我在阿里云上也遇到过几次因为硬件升级需要迁移服务器的情况
但是无法再次上线的原因这里没说，其中到底有什么难点？然后就立即调整方案去恢复数据了，就不等一下吗？
让人不免产生疑虑，是不是下线后数据自动清除了，所以才要恢复数据？当然我们还可以往好了猜测，重新上线需要的时间更长，那之前一直在线，为什么刚下线了就回不去了
15:10 开始新建存储系统，从备份中开始恢复数据，由于语雀数据量庞大，此过程历时较长，
还是多活的问题，存储系统还要重建，这有点让人无法释怀。还有不知道语雀是怎么备份的数据，可能备份数据的组织形式和生产环境不一样吧，又或者备份数据保存在低频类型的存储中，这类存储的成本更低，但是读写吞吐量不高，所以需要很长的时间把它们加载到生产环境中。
19 点完成数据恢复；同时为保障数据完整性，在完成恢复后，用时 2 个小时进行数据校验；
这个做法还是挺专业的。存储硬件错误或者网络传输都可能导致数据出现错误，一般硬盘上会有硬件级的校验修正机制，软件上也有类似的校验修正机制，这往往还需要多使用一些存储空间。举个例子，我们在网上下载的一些安装包，可以根据公开的算法算出一个签名，与官方的签名进行比对，从而确定安装包没有被篡改。
21 点存储系统通过完整性校验，开始和语雀团队联调，最终在 22 点恢复语雀全部服务。用户所有数据均未丢失。
存储恢复了，还不能确定整个系统是否都正常了，是不是还有衍生的其它问题，有些故障保护设置可能也要去掉，比如很多服务可能会宕掉，需要重启；还有之前很多用户看到的 too many directions 问题。
作为一个文档服务，数据就是语雀的命根，丢数据是万万不能发生的，所以语雀一直强调这个问题。
解决方案
针对其中存在的问题，语雀也提了一些解决方案，总结下就两点：加强管理和升级架构。
升级架构主要就是多活方案的建设，里边提到"从同 Region 多副本容灾升级为两地三中心的高可用能力"，按照我的理解，语雀当前只是部署在一个可用区，或者说一个机房，采取了一些硬件上的数据备份机制，所以无法做到快速故障恢复；以后它准备搞成两地三中心的金融级方案，这个确实能解决问题，但这个过程也不是一蹴而就的。
其它的我就不多说了，下图是官方的解决方案。
免费领会员
针对这次故障，语雀对所有个人用户免费赠送6个月的会员服务，这也算比较厚道了，许多同学看到这个都欣慰的笑了，大家快去领取吧。操作步骤如下图所示：
另外对于企业空间用户，语雀会单独制定赔偿方案，还需等待语雀的通知。
最后
作为蚂蚁集团的成员、阿里的小弟，支付宝的兄弟产品，语雀出现这样的问题，不免会影响到阿里的品牌价值，让大家多了那么一点点疑虑。
双十一临近，无论商家还是平台还是广大的吃瓜群众应该都在做一些准备吧，这个事件也算是给我们枯燥的生活增加了一些调味料，只是酸甜苦辣每个人都有不同的感受，我们还要努力过好自己的生活。
我注册了一个微/信/公/众/号：萤火架构，后续会分享很多架构方面的真实经验和认知，欢迎关注，以免错过精彩内容。