栏目分类
产品中心 你的位置:东升盛世(北京)国际投资咨询有限公司 > 产品中心 > 照这样下去,“千年虫”还得再来十遍
照这样下去,“千年虫”还得再来十遍

发布日期:2022-08-03 16:49    点击次数:112


 

在 21 年前世纪之交,全球的计算机系统和互联网曾经出过一个重大事件:千年虫。

  当时的计算机系统处理年份的方式都是两位数(如 1998 年会被系统缩略成 98),而 2000 年在老系统里仍然以 00 显示,则会被系统当成 1900 年。

  然而谁都没想到的是,就在前几天,”千年虫“又重演了……

发生了什么?

  首先,幸运的是,这次的事故规模,并没有千年虫那次那么大。目前已知受到影响的,只有采用了微软 Exchange Server2016 和 2019 版本的企业本地邮件服务器。

  因为全球很多企业内部的电子邮件,采用的都是自主搭建的系统(而非基于 Gmail、网易、阿里云等云端邮件的方案),而微软的 Exchange 服务器 (Microsoft Exchange Server) 则是很多企业用户都在用的本地邮件系统。

  然而在 2021 年 12 月 31 日——去年的最后一天,在 IT 人员都已经放假的时候,微软突然推送了一个全新的 Exchange Server 版本,直接把所有企业客户的电子邮件系统都给搞宕机了,大量邮件积压在发送序列当中,却无法正常发送和接收。

  错误代码大概是下面这样的:

Log Name: Application Source: FIPFS  Logged: 1/1/2022 1:03:42 AM  Event ID: 5300  Level: Error  Computer: server1.contoso.com  Description: The FIP-FS "Microsoft" Scan Engine failed to load. PID: 23092, Error Code: 0x80004005. Error  Description: Can't convert "2201010001" to long. 

  一夜之间,大量的 IT 人员在 Reddit 和微软官方技术社区上大倒苦水。

“这玩意儿是怎么发布出来的?而且还是在新年夜???”

“电话都被打爆了。微软你弄啥嘞?”

  问题,出在微软推送的这次更新的版本号上。

  这次的更新,里面包含的电子邮件恶意软件扫描引擎的版本号是 2201010001,表示的是 2022年01月01日00点01分。

  微软的产品和系统在表示时间的时候,用的都是这种符号整数。然而,根据微软自己的开发文档,其系统能够接受的 Int32 符号整数的最大值是 2147483647。

  这个最大值的前两位是21。

  也就是说,采用这种整数方式来记录和表示时间,只能够正常覆盖到 2021 年的最后一秒。

  所以,当微软推送出这个 2201010001 版本的时候,版本数字超过了系统能够接受的整数最大值,结果就直接把 Exchange Server 邮件系统给搞崩溃了……

  目前,微软方面已经提供了修复此问题的方法,可以执行 PowerShell 脚本来自动修复,也可以用手动方法修复。修复必须在所有被波及的 Exchange Server 2016 或 2019 版本服务器上执行。

  很多被影响到的公司 IT,在修复过程中也遇到了各种各样的问题。总的来说,这次微软送的这个新年大礼包,让大家整个新年都没过好……

  在微软官方技术论坛上,一位用户发出了灵魂拷问:谁会在 12 月 31 日推送生产环境更新啊?

千年虫重演,原因依然很蠢

  这次微软邮件服务器的 bug,以及其它公司/产品发生的类似的日期时间处理错误,一起被命名为 Y2K22(也即 Year 2022 的缩写)。

  为什么这样命名?正是因为,导致这些 bug 出现的问题,和 21 年前的千年虫 (Y2K bug),几乎一模一样。

  文章开始提到,千年虫的出现,是因为当时一些相对比较古老的计算机系统,在处理年份的时候会采用两位数简写。

  当时的普通人压根想不到,新千年的到来会让计算机系统出故障——唯一有可能预知这种情况发生的,独到见解也就只有程序员了。

  而当千年虫事件即将发生的时候,那些已经投入使用十年甚至 20 年的系统,背后的 COBOL 程序员(大多已经或者快要退休了),又被请出山来修复他们当年“埋”下的这些漏洞……

  在当时,有两种修复的思路:

  1)全盘重写所有系统的代码,称为“expansion”;

  2)打个快速的补丁,让计算机能够将从 00 到 20 的数字,正确识别为 2000 年到 2020 年——这种方式也被称为“windowing”.

  具体来说,这个补丁让计算机系统将 1970 年 1 月 1 日 0 时 0 秒(也即程序员都非常熟悉的 Unix 时间戳)作为百年“时间窗口”的中间点,也即从 1920 年到 2020 年的任何一个时间点,在计算机系统里都可采用其到 Unix 时间戳的距离作为表示方法。

  “高性能计算机新闻网”的一篇发布于 1999 年的报道显示,在当时,大约有八成的系统最后都是用第二种快速补丁的方式修复的。相比一劳永逸的全盘重写,快速补丁的方式的成本优势非常明显,然而即便如此,全世界的预估修复成本加起来也高达 3000 亿美元……

  当面临一个足够大的问题的时候,相信一般人的正常反应,都是“这个问题迟早得彻底解决”,并且也会倾向于一劳永逸地解决问题。

  然而在当时,人们没有选择一劳永逸,而是选择了打补丁,还有另一层考虑,也即:这些系统已经足够老了,在未来的 20 年里总是要还的,所以没必要一劳永逸的重写了,反正到时候换新系统的时候,把日期时间的问题搞好,不就行了。

  对此,伦敦经济学院的 Dylan Mulvin 教授表示,“Windowing 即使在当时也是所有可选方案中最差的一个,它就是把皮球踢给后人的做法。”

  果不其然,当新系统替代旧系统的时候,当年的编程思路,仍然被继承了下来了……

  事实上,到了 2020 年的时候,一些千年虫修复过的系统,以及新安装的系统,都又一次出现了和千年虫几乎一样的问题:Y2K20 bug.

  比如,在当时有些用户惊讶地发现,他们从宽带公司收到的账单显示日期为 1920 年:

  游戏公司 2K 开发的摔角游戏《WWE 2K20》,也在游戏标题里这一年的第一天的第一秒就宕机了:

  当时纽约市的很多停车自动缴费机,也因为系统时间错误而触发了防火墙机制,无法接受信用卡支付:

  结果你猜怎么着?这些故障,很快就被修复了。

  至于他们采用了哪种思路——是一劳永逸,还是快速补丁——你应该也能猜出来了……

  如果说人类一定有什么做不到的话,那一定是从历史中吸取教训。

  紧接着,Y2K21 bug 又来了。比如,去年美国气象局 (NWS) 的官方数据库出现了重大误差,对外提供的接口的数据晚了足足一天,导致很多第三方机构的天气数据都出现了错误,影响了民航、海洋捕捞、畜牧养殖等诸多行业的正常运作。

  也有一些普通用户发现,自己的电脑梦回 1921 年了:

  再然后,2021 年也翻篇了,Y2K22 bug 也毫无悬念地按时来到了……

  除了这次微软 Exchange Server 出了故障之外,一些本田车主也发现,他们的车每天早上启动都会把时间自动跳回到 2002 年。

  汽车专业人士调查分析发现,本田车载系统的问题原因和微软一样,都是出在 Int32 整数上,开头 22 的字符串无法被读取,在本田这里就变成时间回退到 2002 年了……从 2004 到 2012 年的上百款车型都有较高几率遇到此问题。

  在公开场合,本田公司发言人表示,目前还在调查这个问题的具体原因。不过有车友在论坛上发帖表示,本田公司派人联系他们,说这个问题会在今年 8 月份自行消除……

  在可见的未来,Y2K23, 24, 25... 各种各样的问题还会陆续发生。

  并且,已经在各种计算机系统中广泛采用的 Unix 时间戳,还会在 32 位系统中导致一个问题,使得某些软件在 2038 年 1 月 19 日 3 时 14 分 07 秒后无法工作:

  对于”2038 年问题“,整个行业(特别是硬件寿命极长的嵌入式行业)的应对方式,和 21 年前如出一辙:反正到了 2038 年的时候,应该新系统又换了一茬了吧,到时候再说吧……

  看来,大家根本不想彻底解决”千年虫“以及其衍生问题。

  可这又是为什么?

“一劳永逸”,不如多劳多得?

  对于千年虫这样反复出现的情况,有人开玩笑说是程序员埋的坑

  至少在千年虫肆虐的时候,那些 COBOL 老古董程序员被请出山来修复问题的时候,就有人质疑:他们是不是当年故意给我们埋的坑啊?

  这种想法有它的道理:程序员的职业生涯是有限的,不是所有人都能升到高管。那么那些平庸的程序员,如何保证在自己临到退休的时候还能够被需要?

  埋个只有自己才懂得怎么修的漏洞,也没什么毛病?20 年一个周期,正好覆盖从大学毕业到中年不惑……

  当然,实际上,在具体操作中,大多数运作计算机系统的公司,在事故发生的时候,也一定会更倾向于选择速度快、见效快、成本低的修复方式。

  所以,程序员也不是什么阴谋家,因为他们不是决策者——他们只是在正确的时间,执行了对大家都合适的解决方案而已。



Powered by 东升盛世(北京)国际投资咨询有限公司 @2013-2022 RSS地图 HTML地图