语雀服务宕机带来的稳定性思考

前天下午语雀服务宕机的事情，圈子里传的很火，影响范围挺大，很不幸，我就是那个被影响的渺小之一。

经常看我文章的同学应该都知道，我更新频次算是很高的。作为语雀的深度使用用户，日常我创作的内容，基本都是在语雀里写好，然后复制到公众号等平台进行发布。

本来昨天应该更新的内容，由于语雀服务宕机的事情，只能放到明天再推送了。今天这篇文章，聊聊这次语雀服务宕机给我带来的一些思考。

宕机事故开始时间大概是周一下午 14 点 10 分，我正在写一篇技术实践类的文章。

最初只是不断弹窗提示登录认证的 auth 过期，刷新无果后我尝试退出重新登录，结果页面直接无响应，我就猜到可能语雀的服务出问题了，还和一个认识的阿里技术大佬开玩笑说，你们的服务挂了，但我估计很快就能恢复。

为什么这么说？首先阿里作为互联网大厂，监控告警肯定做的很完善了，出了问题很快就能监控发现并告警。其次在稳定性保障领域的技术实践中，阿里提出的 1-5-15 机制(1 分钟发现问题，5 分钟介入问题修复，15 分钟故障恢复)很知名，出于对大厂技术能力和应急机制的信任，也是我觉得会很快就能恢复服务的重要原因。最后一点原因则是，语雀现在也有付费会员和企业付费的业务，这种面向几百上千万用户的付费产品，对产品稳定性的要求会很高。

但最终的结果却很惨，故障导致的服务不可用时长超过 8 小时，对企业级千万用户规模的产品来说，这是不可接受的。无论是个人用户还是企业用户，由此导致的直接和间接损失会很大。

像我这种个人用户还好，顶多只是个人的文章创作要延后发布。但很多企业用户的需求文档，技术方案甚至与合作伙伴的沟通对接文档，都无法按时对接，甚至会导致整个项目的进度延期，进而导致合作关系和信任程度的丧失。

事后语雀也发布了事故复盘报告和后续的改进措施：

1、升级硬件版本和机型，实现离线后的快速上线。该措施在本次故障修复中已完成；

2、运维团队加强运维工具的质量保障与测试，杜绝此类运维 bug 再次发生；

3、缩小运维动作灰度范围，增加灰度时间，提前发现 bug；

4、从架构和高可用层面改进服务，为语雀增加存储系统的异地灾备。

对于个人用户，赔偿力度相对来说诚意很大：

针对语雀个人用户，我们赠送 6 个月的会员服务。操作流程：进入工作台「账户设置」，点击左侧「会员信息」，在会员信息页面点击「立即领取」，即可获得赠送服务。

但对于企业用户来说，故障造成的直接和间接损失，以及信任度的下降，则是不可估量的。

近几年业内对于系统稳定性保障的技术实践案例有很多，比如：生产全链路压测、异地多活、混沌工程、SRE。很多的线上故障都是由变更导致的，在涉及线上变更操作时，业内也有很经典的三可：可监控+可灰度+可回滚。

可监控：线上服务和业务的各项活动指标都纳入监控范围，指标数值出现异常能及时发现并快速进行介入修复。这方面的建设，除了技术上不断完善之外，良好的 oncall 机制和灾备演练也需要长期的建设过程。

可灰度：线上的变更首先在灰度环境进行，小范围小批次进行变更，然后观察一段时间，确认无误再进行更大范围的变更操作，然后持续观测，确保变更不会对线上服务的正常运行造成影响。

可回滚：如果变更后线上出现异常则及时介入，判断能否快速修复。如不能，则对变更的操作进行回滚，即让系统回到变更前的稳定状态。相比于修复问题，线上服务的正常运行无疑是最重要的，因此也有了所谓的“线上出现问题，首先保障业务止血恢复运行，再进行分析定位和修复验证”的实践准则。

当然，只要是人构建的系统，或多或少都会出问题。作为工程师要考虑的，一方面是降低出问题的概率和影响范围；另一方面则是即使出问题也要做到尽快发现和修复。其中还包含一个前提和一个兜底：前提是优先保障业务正常运行，兜底是要线上服务要时刻有应急措施和手段，即所谓的应急预案来作为服务稳定性保障的兜底。