时间线

根据公告中关于故障的时间点梳理如下：

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

剖析

多从别人的事故中总结经验教训，学习避坑指南。

1. 14:07，数据存储运维团队收到了健康系统的报警，然后开始定位问题。微博第一条热搜出现为14:14，说明监控明比用户早感知了7分钟，任何服务公司对于监控都是非常重视的，我所在的公司公司，一切生产问题，只要是有监控手段、是通过监控系统自主发现的、上报故障时间早于用户反馈的，不管最后的情况又多严重，都会一定程度上的减轻惩罚力度。
   – 监控的重要性
2. 14:15 初步制定解决方案
3. 15:00 初步方案实践失败。讨论新方案
4. 15:10 评估新方案，开始执行
5. 19:00 故障修复
6. 21:00 测试
7. 22:00 服务恢复

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

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

心得

1. 处理生产事件，大家都是火急火燎的，这个时候出来一个说话有分量的人说：大家千万别急，既然事情已经发生了，我们就一点点的把事情做好，不要引入新的问题，防止事态进一步扩散。这个人，他简直就是在发光。
2. 这里面以这次故障为抓手，结合各团队通力协作，上下游拉通对齐，打出了一套组合拳，对焦本次事故，沉淀出了一份可复用的方法论，想要给系统更好的赋能：
   • 保命箴言：可监控，可灰度，可回滚
   • 能力建设：从同 Region 多副本容灾升级为两地三中心的高可用能力
   • 定时演练：进行定期的容灾应急演练
3. 在改进措施的部分，我建议所有开发，运维，包括测试同学，都应该把“可监控，可灰度，可回滚”这九个字贴在工位上，刻在脑子里，做方案、写代码、提测前、上线前都把这九个字拿出来咂摸一下。