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

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

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

发生了什么？

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

因为全球很多企业内部的电子邮件，采用的都是自主搭建的系统，而微软的Exchange服务器则是很多企业用户都在用的本地邮件系统。

然而在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。

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

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

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

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

在当时，有两种修复的思路：

1）全盘重写所有系统的代码，称为“expansion”；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

也有一些普通用户发现，自己的电脑梦回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年一个周期，正好覆盖从大学毕业到中年不惑……

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

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