10月23日，阿里旗下的在线文档服务品牌语雀发生重大服务故障，持续7个多小时才完全恢复。这个恢复时间，对于一个在线产品来说确实是太长了。每一次生产事故都是分析总结的最好时机，这次我也借着语雀的生产问题，来分析下整改措施是否到位。

处置过程分析

根据语雀官方提供的信息，整个事件的处置线是这样的：

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

改进措施

官方提出的改进措施为

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

分析讨论

从时间的处置线上来讲，官方提示14:07分收到告警，到14:15分，花了8分钟的时间已经定位到故障的原因并且开始采用第一时间的恢复方案。对于运维生产事件的处置指标，一般分为三个：第一个是故障发现时长、第二个是故障定位时长、第三个是故障恢复时长。从语雀官方提供的说明，我们仅能推断出，语雀故障定位所用的时间大概是8分钟。这个时间对标金融运维行业的1、5、10标准来说，离标准还有一定的距离。

回过头来说发现时间，发现时间一般是指故障发生到通过告警、巡检、报障等方式发现之间的时间。因为官方没有提供变更开始的时间，仅提供了告警的时间，所以没有办法推测出本次事件的发现时间。

接下来14:15一直到晚上22点故障彻底恢复，就是语雀本次事件的故障处置时间。这个处置恢复速度，如果发生在金融行业，那一定会成为行领导的巨大灾难。对照可用性停机时间的标准，语雀今年要想保住三个九的可用率，接下来的两个月可要好好做好计划了。

下面来看处置措施，这次第一个顶锅的是硬件版本和机型，这看着像是一个客观的结果，实际上应该是从运维管理层面避免的问题。倒腾过基础设施的同学应该清楚，如果你运维的设备厂家、型号、配置是五花八门的，那体验一定是非常酸爽。通常，规划运维机房区域的时候，都会采用相同的配置，同时预留一些应对意外情况的备件。对于设备的生命周期也要做好管理，快要到期的设备一定要提前规划用于周转替换的资源。

基础设施之上就是版本管理了，包括硬件设备的微码管理和操作系统版本管理。语雀这次，看上去就像是版本管理不一致造成影响。官方描述到「因村处系统使用的机器类别较老」，但是措施里提到通过「升级硬件版本和机型」这些措施已在本次故障中完成，能在几个小时内完成的，大概率就是版本升级了。

第二个措施更像是一个口号式的方案，这种措施在我们单位内部，大概率是无法过关的。

第三个措施有点对路，互联网企业的2c业务，其优点就在于能够根据用户灵活的设置灰度发布的时间和范围。但我觉得语雀的总结还不是非常到位，对于变更的窗口选择，选择在下午一个业务高峰时段进行变更，变更异常后产生的影响往往是非常大的。语雀这次变更，推测应该就是下午2点上班之后，运维工程师就开干了。没有将变更安排在业务低峰时段，我觉得是最大的错误。

第四点就不多说了，相信凭借阿里、蚂蚁的技术实力，一定是可以搞定异地灾备这种架构的，也希望语雀的服务能够越做越好，稳定的服务相关的人群，给大家提供良好的使用体验。