昨天晚上语雀发布了关于 10 月 23 日的故障公告，公告中关于故障的时间点梳理如下：

这是公告链接：https://mp.weixin.qq.com/s/WFLLU8R4bmiqv6OGa-QMcw

关于语雀 23 日故障的公告

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

我们一起盘一下这个时间点，多从别人的事故中总结经验教训，学习避坑指南。

14:07

首先第一个时间点，14:07，数据存储运维团队收到了健康系统的报警，然后开始定位问题。

我翻了一下微博，这个时间点几乎和微博话题“#语雀崩了#”下的一条微博的时间点能对应上，而且还早了 7 分钟。

不要小看这 7 分钟，这说明系统人员先于用户感知到了问题的存在，说明监控系统的预警是有效的。

不知道在其他公司是什么规定，但是在歪师傅所在的公司，一切生产问题，只要是有监控手段、是通过监控系统自主发现的、上报故障时间早于用户反馈的，不管最后的情况又多严重，都会一定程度上的减轻惩罚力度。

甚至对于一些属于严重 BUG 但是没有造成严重后果的，因为有监控的存在，监控及时生效，出了问题你立马就监控出来了的，是可以免责的。

监控，全方面、细粒度、低噪音、高触达的监控，非常非常重要。

这一点，从公告上来，语雀的运维团队是做到了。