首页科技快讯我看大连车务段Flash事故：比嘲笑更重要的是什么？

我看大连车务段Flash事故：比嘲笑更重要的是什么？

来源：晰数塔互联网快讯时间：2021年01月19日 06:00

本文来自微信公众号：余晟以为（ID：yurii-says），作者：余晟，原文标题：《比嘲笑更重要的——我看大连车务段Flash事故》，头图来自：《武林外传》剧照截图

大连车务段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”的开发工程师，真到了工作中，让他遵守依赖管理的统一规范，都相当有难度呢。

本文来自微信公众号：余晟以为（ID：yurii-says），作者：余晟