An image to describe post 比嘲笑更重要的——我看大连车务段Flash事故

大连车务段Flash事故的原文,我看到的时候阅读数大概有七千多。当时我就有两个感觉:第一,这种主要面向单位内部的公众号文章,平时阅读量肯定不会这么高,所以一定发生了“意料之外”的传播;第二,当时在多个群里已经有传播,普遍反应是“看哪,竟然会这样”,所以估计还会引起广大范围的传播。

第二天再看,原文就删除了。之后再看,就是各路段子手一拥而上,变着花样的嘲讽。许多IT业内的朋友纷纷在说“不可思议,怎么会这样的低级错误”。说实话,我觉得这多少有点“站着说话不腰疼”的嫌疑:以我的经历,哪怕是IT大厂也免不了“低级错误”——甚至就是这种“技术过时”的错误也不罕见。不过事后诸葛亮总是容易的,真正重要的不是去指责“低级错误”,而是能从中吸取教训,避免再犯同样的错误。

对于这次的Flash事故,我们应当如何避免犯同样的错误?这恰恰是各种“不可思议”惊叹文中缺失的部分。

在我看来,在当时的情况下,“降级使用Flash”确实是最现实的解决方案了,既没有影响到系统的其它部分,又保证了原有系统的稳定运行,而且避免发生生产事故。我不知道多少人有过“生产系统排障”的经历,而且与互联网常见的生产系统不同,故障影响的不只是用户的登录和浏览,而是列车编组,排障的压力显然要大很多。“奋战一昼夜”能解决问题,没有什么可以苛责的。

那么,这次的事故可以避免吗?要我说,也可以,也不可以。

虽然Adobe公司早在若干年前就宣布Flash要寿终正寝,但是平心而论,一般情况下,还真不了解系统的技术依赖情况。技术发展往往追求对用户透明,也就是说,不管底层用什么技术实现,用户的感知是不变的。这当然方便了用户,但它也把普通用户和技术实现隔离开来,尤其是在技术飞速发展的今天。

许多人大概还记得这么一则新闻,前几年,美国高薪招聘COBOL程序员。COBOL属于“上古”语言,在业界早就属于“无人问津”的类型,懂得它的程序员平均年龄已经六十岁,属于“古董”级别。但是,它开发的软件仍然在支撑着重要的业务。

类似的例子还有很多。直到2019年,美国空军才真正停止在核武器发射系统中使用8英寸软盘传递指令,这是诞生于上世纪70年代的技术。在2019年的另一条新闻里,3D打印解救了美国空军的轰炸机和运输机。因为这些飞机的服役寿命很长,早年生产时的供应商早已经不存在,如今的零件补给成了问题。如今,重新制造C-5运输机的一个厕所盖板就需要8500美元,还好,依靠3D打印技术,它只需要300美元。

如果用户有责任保持成型系统的技术“与时俱进”,早就应该逐渐替换掉这些系统。不幸的是,一般用户是没有这个责任的,相反,一般用户看中的是稳定,稳定之后就尽量不要改变。在这一点上,不管是美国联邦政府,是世界五百强,还是美国军方,都是相同的。

但是,技术,尤其是IT技术的“稳定”,却是一个动态的概念。这种稳定需要恰当的硬件环境,恰当的软件环境,还有恰当的人才——否则,新硬件运行不了老软件,新软件不支持老硬件,系统还在却找不到能开发的人。此外,技术的飞速更迭也带来成本的变化,“成本合算”的方案往往以当时的技术水平能大规模生产为基础,然而时过境迁,当年“合算”的方案往往成为历史包袱,被新的浪潮所抛弃,这也是许多“恐龙级”系统一直保留到今天的原因之一。

退一步讲,即便平时留心测试,本次“忽然无法使用”的故障大概也很难通过提前测试发现。造成事故的这个“到期无法运行”的版本最早发布于2018年,可以说,两年多以前,系统里就悄无声息地埋下了这颗“逻辑炸弹”,各种测试都很难发现,这也是本次故障能最终解决的原因——将Flash版本回退到之前就不会有这种逻辑锁。

我相信,平时也一定有人关注到了“Adobe将在2020年底停止支持Flash”的新闻,但是,大家未必详细了解“停止支持”的含义。许多人对于软件产品的认知还停留在实物产品的阶段,认为自己拥有绝对所有权,因此“修修补补还能用”,“不用新功能就无所谓”。

可是,几年前微软三番五次通知之后,让盗版Windows“黑屏”(后来受到巨大舆论压力才撤回),当时许多人捶胸顿足,哭天喊地。可是今天再看,Windows XP,Windows 7早就被官方宣布“停止支持”了,不少人不是照样用得很欢,丝毫无所谓吗?

所以,以旁观者角度,想当然指责“脱离潮流,落后业界主流水平”是容易的,搞清楚问题到底在哪里,如何从根本上解决,才是真正有价值的。那么,这类问题到底要如何解决呢?、

老实说,很长时间里我都是做开发,所以总觉得出现这些问题是开发做得不够好。后来才知道,原来公司里还应该有专门的“技术保障”团队,它的职责不限于传统的运维,还需要对系统的技术实现有全方位的了解,结合业界最新动态,不断分析现状、指明风险、提出改进。换句话说,保证技术层面的“与时俱进”,把风险保持在最低状态。

说起来,技术保障挺重要,但实际工作中,它往往两头不讨好。对开发团队而言,除了定期的检查、备案,还有不定期的升级版本、打补丁,甚至紧急修复,这都是与“新功能”无关的任务,多少让人厌烦。对业务团队而言,“系统用得好好的”,却总提出耸人听闻的风险,这里要花时间,那里要花钱,纯粹增加成本。

该如何看待这种困境?我觉得一个朋友说得挺好:如果企业真的重视技术、珍视技术,就应当理解,技术中存在许多“重要但不紧急”的事项,不解决它们,终将落入持续救火的境地。但是,这部分工作如果没有从上到下的规划和长期思考,是无法推动的。

总而言之我认为,与其去花式嘲讽、苛责一篇半公开的内部宣传稿,不如认真讨论如何做好技术保障才能杜绝此类事故,哪怕提出一两个有用的点也非常有价值。这也恰恰是最难的,不客气地说,就我所见,不少夸夸其谈“竟然还在用Flash”的开发工程师,真到了工作中,让他遵守依赖管理的统一规范,都相当有难度呢。

An image to describe post 比嘲笑更重要的——我看大连车务段Flash事故

如果喜欢本文,欢迎长按识别二维码订阅。