本文来自微信公众号:硅星人(ID:guixingren123),作者:光谱 杜晨,题图来自:视觉中国


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


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


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


发生了什么?


首先,幸运的是,这次的事故规模,并没有千年虫那次那么大。目前已知受到影响的,只有采用了微软 Exchange Server 2016 和 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.comDescription: 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),几乎一模一样。


文章开始提到,千年虫千禧年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年一个周期,正好覆盖从大学毕业到中年不惑……


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


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


本文来自微信公众号:硅星人(ID:guixingren123),作者:光谱 杜晨