21年前的世纪之交，全球计算机系统和互联网发生了一件大事：千年虫。 当时的计算机系统用两位数字来处理年份（比如1998会被系统简写为98），而2000年在旧系统中仍然显示为00，会被视为1900由系统。 然而，谁也没想到的是，就在几天前，“千年虫”又发生了……到底发生了什么？ 首先，还好这次事故的规模没有千年虫那么大。目前已知受到影响的只有使用MicrosoftExchangeServer2016和2019版本的企业本地邮件服务器。 因为全球很多公司的内部邮件使用的是自建系统（而不是基于Gmail、网易、阿里云等云邮件的解决方案），而MicrosoftExchangeServer（微软ExchangeServer）是很多的企业用户使用的本地邮件系统。 然而，在2021年12月31日——去年的最后一天，IT人员已经放假的时候，微软突然推新版ExchangeServer，直接导致所有企业客户的邮件系统宕机，一大波发送顺序中积压多封邮件，无法正常收发。 错误代码大概如下：LogName:ApplicationSource:FIPFSLogged:1/1/20221:03:42AMEventID:5300Level:ErrorComputer:server1.contoso.comDescription:TheFIP-FS"Microsoft"ScanEnginefailedtoload.PID:23092,ErrorCode:0x80004005.ErrorDescription:Can'tconvert"2201010001"tolong. 一夜之间，大量IT人员向Reddit和微软官方技术社区泼了苦水。“这东西怎么放出来的？而且还是大年三十？？？”“电话在嗡嗡作响。微软你在做什么？” 问题出在微软推送的这次更新的版本号上。 本次更新包含的邮件恶意软件扫描引擎版本号为2201010001，即2022年1月1日00:01。 微软的产品和系统在表示时间时都使用这个符号整数。但是根据微软自己的开发文档，它的系统可以接受的一个Int32有符号整数的最大值是2147483647。 这个最大值的前两位是21。 也就是说，用这个整数记录和表示时间的方法一般只能覆盖2021年的最后一秒。 所以，当微软推出这个2201010001版本时，版本号超过了系统可以接受的最大整数值，因此，Exchange服务器邮件系统直接崩溃了... 目前微软已经提供了修复这个问题的方法，可以执行PowerShell脚本自动修复，也可以手动修复。必须对所有受影响的ExchangeServer2016或2019服务器执行修复。 许多受影响的IT企业在修复过程中也遇到了各种问题。总的来说，这次微软送出的这个新年大礼包，让大家过了一个不愉快的新年…… 微软官方技术论坛上，有用户发来了一个灵魂拷问：12月31日是谁？推送生产环境更新？千年虫又来了，原因还很蠢 这次微软邮件服务器的bug，和其他公司/产品类似的日期时间处理错误，被命名为Y2K22（也是Year2022的缩写）。 为什么会这样命名呢？正是因为导致这些bug的问题与21年前的Y2Kbug几乎一模一样。 文章开头提到，千年虫的出现是因为当时一些比较老旧的计算机系统在处理年份时使用了两位数的缩写。 当时没有任何普通人能够想象到新千年的到来会导致计算机系统出现故障——能够预见到这种情况发生的只有程序员。 在Y2K事件即将发生之际，系统背后使用了十年甚至二十年（大部分已经退休或即将退休）的COBOL程序员被请出山去维修他们把这些漏洞“埋”在了... 当时有两种修复思路： 1）重写所有系统代码，称为“扩容”；,正确识别为2000年到2020年-这种方法也称为“窗口化”。 具体来说，补丁让计算机（大家非常熟悉的Unix时间戳）作为百年“时间窗”的中点，即1920年到2020年的任意一个时间点，与Unix时间戳的距离可以作为计算机系统中的一种表示方法。 HPCNews1999年发表的一篇报道显示，当时大约80%的系统最终通过第二种快速补丁方式修复。与一劳永逸的完全重写相比，快速打补丁方式的成本优势非常明显。然而，即便如此，全球范围内的维修费用预估也高达3000亿美元…… 当面对一个足够大的问题时，相信大多数人的正常反应是“这个问题迟早会彻底解决的”稍后”，他们也倾向于一劳永逸地解决问题。 不过当时人们并没有选择一劳永逸，而是选择了打补丁，还有一个考虑，就是：这些系统已经够老了，总是要还的未来20年，所以不需要一劳永逸地重写。反正到了换新系统的时候，把日期和时间的问题搞定，就没事了。 对此，伦敦政治经济学院教授迪伦穆尔文表示，“即使在当时，开窗也是所有选择中最糟糕的，它是把球踢给后代的做法。”当系统换掉旧系统的时候，还是继承了当年的编程思想... 其实在2020年，一些被千年虫修复过的系统和新装的系统又会出现几乎一样的问题如Y2K：Y2K20bug。 例如，有用户惊讶地发现，他们从宽带公司收到的账单上显示的日期是1920年： 游戏公司2K开发了一款摔跤游戏，也死机在游戏名称中的第一天的第一秒： 当时纽约很多自动停车缴费机也因为系统时间错误触发了防火墙机制，无法接受信用卡缴费： 结果，你猜怎么着？这些错误很快就被修复了。 至于他们采用的是什么idea——一劳永逸，还是快速打补丁——大家应该能猜到吧…… 如果有什么事情是人类做不到的，那一定是学习了历史课。 紧接着，Y2K21的bug又来了。比如去年国家气象局（NWS）官方数据库出现重大错误，对外接口提供的数据晚了整整一天，导致很多第三方机构的天气数据出现错误，这影响了民用航空、海洋渔业和畜牧业。养殖业等众多行业正常运转。 一些普通用户还发现自己的电脑梦回了1921年： 然后，2021年也翻开了这一页，Y2K22bug毫无悬念的准时到来了... 除了这次微软之外对于ExchangeServer故障，一些本田车主还发现，他们的汽车每天早上启动时会自动跳回2002年。 经过汽车专业人士调查分析发现，本田车机系统出现问题的原因与微软相同。都是Int32整数造成的。好吧...从2004年到2012年的数百个模型很有可能出现此问题。 在公开场合，本田发言人表示，具体问题原因还在调查中。不过有车友在论坛发帖说本田派人联系他们，说这个问题会在今年8月自己解决。。。 遥遥无期，Y2K23、24、25……各种问题会继续发生。 另外，在各种计算机系统中广泛使用的Unix时间戳，在32位系统中也会出现问题，导致某些软件在2038年1月19日03:14:07后无法运行： 关于“problemof2038》，整个行业（尤其是硬件寿命极长的嵌入式行业）的反应和21年前如出一辙：反正到了2038年，又要换新系统了好吧，以后再说... 似乎大家都不想彻底解决“千年虫”及其衍生问题。 但是为什么呢？“一劳永逸”，是不是多劳多得？ 对于千禧年的反复出现，有人戏称这是程序员埋的坑。难道他们当年是故意给我们埋坑的？ 这种想法有它的道理：程序员的职业生涯是有限的，并不是每个人都能升到高层。那么那些平庸的程序员如何确保在他们即将退休时仍然需要他们呢？ 埋一个只有自己知道怎么补的漏洞有什么不好？一个20年的周期正好涵盖了从大学毕业到人到中年…… 当然，在实际操作中，大部分运营电脑系统的公司肯定会更倾向于选择快速、有效、低成本的修复方式。 所以，程序员不是阴谋家，因为他们不是决策者——他们只是在正确的时间为每个人实施了正确的解决方案。
