计算机系|照这样下去，“千年虫”还得再来十遍

在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 程序员（大多已经或者快要退休了），又被请出山来修复他们当年“埋”下的这些漏洞……