语雀生产事故不该只是运维的锅

重阳节这天，知名笔记软件语雀突然崩了，官方网站、客户端软件持续七个多小时无法使用。大家都在讨论事故的缘由，吐槽对生产的影响，也开始慢慢在质疑语雀文档的数据安全性。作为大厂旗下的产品，事故的修复耗时如此之久，实属罕见。虽然 23 日语雀发了相关的公共说明，复盘了整个故障过程，似乎原因都离不开运维 bug、运维数据库备案，但是我细细品来，这场事故网络的发酵以及炸裂的影响，不该只是运维一方应该被背的锅。

1 回顾事故历程-网友视角

以下是我个人作为普通网友看到的这场事故的一个大致经历：

• 10.23 日 14:00 后有网友在用户交流群反馈，语雀软件故障无法打开；

• 15:00 语雀官方发布微博，服务器故障正在紧急修复中；

• 18:00 语雀故障仍未恢复，用户交流群、网络一片沸腾，语雀故障一度冲上热搜。还有网友怒改语雀百度百科，头条记录相关故障。

• 22:25 官方助理在群内通知故障恢复

• 10.24 日 21:00 语雀官方发布故障公告进行了故障复盘，并给出相关补偿方案

2 故障复盘-官方视角

下面是官方对于故障原因复盘和改进措施：

仔细看这些关键词，大致可以看到官方对这场事故的定性：

• 故障发生的“锅”：运维升级脚本 bug 导致数据存储服务下线

• 故障恢复慢的“锅”：没有做好足够冗余备份、机器较老

• 故障未来的改善：升级硬件、保障运维脚本质量、增加灰度和异地灾备

似乎这些事情都是运维层面需要的事情，也说的都有道理，提高运维代码质量、提升硬件性能、提升升级容错性、做好灾备，但是这场事故如此长的时间、如此大的影响，我想他不简单只是改善运维层面可以搞定的，公司代码管理、流程管理、风险管理、产品定位和交互体验、研发设计理念其实都是一些挑战，都值得做一次深刻复盘。

3 探索背锅侠

首先我想提到的是管理的锅，这里有三个关键词：代码管理、流程管理和风险管理。我们都知道业务代码在大部分公司都是有很完善的管理流程的，特别是一些核心的业务代码，走读是常有的事，灰度是必然的抉择。但是有多少公司对运维脚本这一类真正有用心，这个我是存在质疑的，不谈自动化，代码审查走读、项目归档、结构化存储，已经是很多公司的对于运维代码上限了。但是实际上运维脚本也是代码，甚至有些也是常年在钢丝线上活动，比如重置主机、批量修改配置等都不再话下。不要把运维脚本不当代码，也不要期望代码不出事故，这是我们对于代码管理和流程管理都要有的预期，所以加强运维脚本的代码管理和审核以及运维操作灰度和流程就是两个必经之路。还有一个要点便是风险管理，七个小时的恢复时长，我想这在 sre 领域应该是很炸裂的故障恢复时间了，很明显公司在风险管理上对于这场事故是缺乏预案的，笔记软件的核心资产是是什么？对于核心资产面临的风险问题有哪些场景？面对场景我们应该预留哪些方案即使应对？用户群体有哪些使用风险，如何降低对相关风险的敏感？我想这些都是管理者后续需要思考的风险管理的问题，不能等风险出现了再改进，更重要的是提前考虑和规避风险。好在语雀似乎守住了底线，数据资产至少没丢。

第二个拉出来的我觉得是产品。语雀的产品设计一度是让我非常欣赏的，它的“结构化知识库管理”定位以及简约不简单的风格，曾让我在印象笔记还有半年会员期的时候经过体验后直接弃坑转投语雀，因为他确实看着美，用着顺手，也不似印象那般臃肿还总是发着各种让你续订的广告。然而结构化知识库只是语雀在对比其他笔记软件定位上的一个差异化和一个局部定位，它的身份本质上面向个人用户是一个笔记工具，面向企业它是一个协同工具，总得来说它就是个人和企业的生产工具。作为生产工具网络应该不是必备条件、中心化存储也只该是技术实现，不应该暴露给用户，而语雀在端上把这些都强制暴露给了用户。没有网！对不起工作不了！存储故障，对不起客户端也得停着。打在这里的时候，笔者断网打开了三款笔记软件，只有语雀在界面上把后端的响应打出来了，而且再不支持后续的一切操作。我想可能若干年前语雀是阿里内部研发自研的一个产品，不存在没有网络、存储故障的问题，但是从它商业化的那一刻，它的定位就变了，而这些产品思维，我想大概现在产品还没有完全转变过来。比如这里的错误码、比如脱网后完全不可用的现状，这会让用户一下子发现原来你公司软件或者服务器出故障了，咱们先不谈离线存储，哪怕优化一下离线访问也好，不要让用户在网络不好、电脑异常的时候也一下就看到这些错误码，不要让用户因为未知的网络主机问题，影响到浏览（对我说的是浏览，作为技术出身我知道集中存储难的是写，那好歹能缓存一部分让我看），如果不做这些事情，从此一切故障的锅都成了软件记本身的锅，用户自己没网费了、家里路由器故障了、运营商故障了、阿里云故障了、硬件故障、dns 故障了，用户都会因这些意外无法生产，细细想来这是多么可怕的事情，而简单一个访问跳过，别人就会觉得你靠谱不少，对于这些故障的敏感就会少不少。这便是此次事件我认为最大的锅，产品没有及时转换定位，过度地把技术细节暴露给用户，让一款生产工具因为外部原因直接不可用还主动揽了一堆锅，这就是不可接受的！

最后一个我想谈谈的是研发，前面我已经提到个人认为的最大背锅侠是语雀对于产品的定位、对于客户端的设计的思路没有及时切换，没有站在用户角度考虑生产不可用的问题，然而我相信离线存储、离线编辑不可能是没有用户反馈也没有用户提的，github 上一堆的语雀导入导出工具就能看到这个需求是有市场的。为啥没做？大致能脑补出来一个画面，产品给研发提了一个离线存储的需求，直接被研发打回了。对不起，做不了，咱们这个是前端架构 nodejs 的客户端软件，要的就是集中化存储，这样无论多少个客户端版本（比如 ios、安卓、mac、weindows、浏览器）才能保持统一的代码。我承认离线存储在当前这种客户端形式上是有点难做的，但是好歹我们可以做一些离线缓存的优化，大的架构不用动，至少不要用户没有网就进不去了，或者进去至少可以本地缓存个最近 10 篇、100 篇编辑的笔记，不用编辑也行，把结构展示出来，让我们看看部分文档。新起一个守护进程，做做这种离线检测、实时备份、模式切换，我认为是不难的，而一旦有了这些，你下线 10 个小时，我们也是能接受的，至少用的时候用户感知不到。离线存储在当前这个技术架构上是难做，但是离线笔记和离线浏览在我看来是代价很小的。与其花大价钱去扩容、翻新机器，不如在技术实现上再往前走一步，不要一开始就一句做不了，搞不定，技术架构是为产品和用户去服务的，我们追求技术的完美，但是不能牺牲了客户的需求。有时候逐步演进，换种思路去实现也未尝不可。有时候技术要追求完美，但是好的技术一定是全力满足客户需求前提下，再去提高扩展性、架构完整性的。

4 最后的总结

终于打完这篇分析，按理说似乎这场事故与我们无关，但是其实对每个互联网从业者，这都是一个深切的教训。打这些字的时候我还在用着语雀，因为它文档化的知识库暂时还是我舍弃不了的。其实写文章的时候我表面在找着背锅侠，内心则是想着未来我遇到这些问题的时候应该如何去应对。

现在想来“客户第一”真的是一件很难的事情，说着虽然简单，但是站在用户视角不是一个口号，它需要管理的手段、产品的理念、研发的视线、软件的运维都去协同，我们要暂时放下部门的隔阂、放下旧的用户遗留的定位、放下研发技术手段的局限，真正站在一起去考虑才能形成合力。这个过程，我们有很多阻碍——持续商业化和变现压力、部门的拉扯、人力的变更、繁重的产品设计任务、改不完的 bug、做不完的需求、甩不完的锅，还有当下不景气的整体经济现状和已过巅峰、不在风口、进入存量竞争的互联网行业大背景。但是好在我们也能得到一些启示或者诀窍，就是作为身处其中的任何一个角色，想想一款软件、一款产品的本质是什么，客户在怎么用，我们的底线是什么，大家保持对齐，共同发力！