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

本文涉及的产品
Serverless 应用引擎 SAE,800核*时 1600GiB*时
云原生网关 MSE Higress,422元/月
函数计算FC,每月15万CU 3个月
简介: 现在想来“客户第一”真的是一件很难的事情,说着虽然简单,但是站在用户视角不是一个口号,它需要管理的手段、产品的理念、研发的视线、运维的自动化去协同,我们要暂时放下部门的隔阂、放下旧的用户遗留的定位、放下研发技术手段的局限,真正站在一起去考虑才能形成合力。这个过程,我们有很多阻碍——持续商业化和变现压力、部门的拉扯、人力的变更、繁重的产品设计任务、改不完的bug、做不完的需求、甩不完的锅,还有当下不景气的整体经济现状和已过巅峰、不在风口、进入存量竞争的互联网行业大背景。

重阳节这天,知名笔记软件语雀突然崩了,官方网站、客户端软件持续七个多小时无法使用。大家都在讨论事故的缘由,吐槽对生产的影响,也开始慢慢在质疑语雀文档的数据安全性。作为大厂旗下的产品,事故的修复耗时如此之久,实属罕见。虽然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、做不完的需求、甩不完的锅,还有当下不景气的整体经济现状和已过巅峰、不在风口、进入存量竞争的互联网行业大背景。但是好在我们也能得到一些启示或者诀窍,就是作为身处其中的任何一个角色,想想一款软件、一款产品的本质是什么,客户在怎么用,我们的底线是什么,大家保持对齐,共同发力!

目录
相关文章
|
3月前
|
缓存 运维 监控
运维之道:从故障响应到系统优化的实战之旅
在信息技术飞速发展的今天,高效、可靠的系统运维已成为企业IT部门的核心任务。本文将通过一系列真实案例分析,深入探讨运维团队如何从日常的故障响应出发,逐步过渡到系统性能的深度优化。我们将一起探索运维的最佳实践,包括自动化工具的应用、性能监控的重要性以及如何构建一个弹性和高可用性的系统架构。文章旨在为读者提供一套完整的运维解决方案,帮助他们在面对复杂多变的技术环境时,能够迅速定位问题并实施有效的解决策略。
189 0
|
25天前
|
存储 弹性计算 运维
自动化监控和响应ECS系统事件
阿里云提供的ECS系统事件用于记录云资源信息,如实例启停、到期通知等。为实现自动化运维,如故障处理与动态调度,可使用云助手插件`ecs-tool-event`。该插件定时获取并转化ECS事件为日志存储,便于监控与响应,无需额外开发,适用于大规模集群管理。详情及示例可见链接文档。
|
2月前
|
机器学习/深度学习 运维 监控
智能化运维:机器学习在故障预测和自动化响应中的应用
【8月更文挑战第2天】 本文探讨了将机器学习技术应用于IT运维领域,特别是在故障预测和自动化响应方面的潜力与挑战。通过分析机器学习如何优化传统运维流程,我们揭示了数据驱动的决策制定对提升系统稳定性和效率的影响。文章进一步讨论了实施机器学习模型时可能遇到的技术和非技术性问题,并提出了相应的解决策略。最后,我们反思了这一转变对IT专业人员技能要求的影响,以及如何在不断变化的技术环境中维持竞争力。
|
2月前
|
机器学习/深度学习 数据采集 运维
预见未来:机器学习引领运维革命——故障预测与自动化响应的新篇章
【8月更文挑战第2天】智能化运维:机器学习在故障预测和自动化响应中的应用
43 1
|
3月前
|
机器学习/深度学习 人工智能 弹性计算
智能化运维:AI在故障预测与自我修复系统中的应用
随着技术的不断进步,传统的运维模式已逐渐不能满足现代企业的需求。本文将探讨如何通过人工智能技术,特别是机器学习和深度学习算法,实现对IT系统的实时监控、故障预测以及自动化修复。我们将分析AI技术在智能运维中的具体应用案例,并讨论其带来的效率提升和成本节约效果。文章旨在为读者提供一种全新的运维视角,展示AI技术在提高系统稳定性和减少人工干预方面的潜力。
|
3月前
|
缓存 Java Linux
开发与运维内存问题之线上遇到故障,使用jstat命令发现Old区持续增长如何解决
开发与运维内存问题之线上遇到故障,使用jstat命令发现Old区持续增长如何解决
38 2
|
3月前
|
机器学习/深度学习 人工智能 运维
智能化运维:利用机器学习优化故障预测与响应
【7月更文挑战第23天】本文深入探讨了智能化运维的前沿技术,特别是机器学习在故障预测和响应中的应用。文章首先介绍了智能化运维的概念及其对现代IT运维的重要性,随后详细阐述了机器学习模型如何被训练来识别潜在的系统故障并提前预警。通过分析真实案例,我们展示了机器学习算法在实际运维中的有效性,以及如何通过这些算法减少系统停机时间,提高运维效率。最后,文章讨论了实施智能化运维时可能遇到的挑战及应对策略,为读者提供了一套实用的智能化运维解决方案。
|
3月前
|
机器学习/深度学习 数据采集 弹性计算
智能化运维:机器学习在故障预测中的应用
随着信息技术的飞速发展,系统运维面临着数据量激增、故障类型复杂化等挑战。传统的运维手段已难以满足现代企业的需求,智能化运维应运而生。本文重点探讨机器学习在智能化运维中的故障预测应用,通过案例分析展示其在提升运维效率、降低维护成本方面的显著作用,并讨论实施智能化运维时可能遇到的挑战与对策。
|
3月前
|
机器学习/深度学习 数据采集 运维
智能化运维:机器学习在故障预测中的应用
【7月更文挑战第16天】随着信息技术的飞速发展,企业对IT系统的依赖程度不断加深。传统的运维模式已经难以满足现代业务的需求,智能化运维应运而生。本文将探讨如何通过机器学习技术提高故障预测的准确性,减少系统停机时间,并提升运维效率。我们将分析机器学习在故障预测中的具体应用案例,讨论实施过程中的挑战与对策,以及评估机器学习模型的性能。文章旨在为运维人员提供一种全新的视角和方法,以期达到优化系统稳定性和提升用户体验的目的。
|
3月前
|
机器学习/深度学习 运维 监控
智能化运维:机器学习在故障预测和自动化修复中的应用
随着信息技术的迅猛发展,企业对运维工作的效率和准确性要求越来越高。传统的运维模式已难以应对日益复杂的系统环境和数据量。本文将探讨如何利用机器学习技术提升运维工作的智能化水平,实现故障的早期预测和自动化修复,从而减少系统停机时间,提高企业运营效率。通过分析机器学习在运维领域的应用实例,揭示其在实际工作中的有效性和潜力。
55 0
下一篇
无影云桌面