照這樣下去，“千年蟲”還得再來十遍
在 21 年前世紀(jì)之交，全球的計(jì)算機(jī)系統(tǒng)和互聯(lián)網(wǎng)曾經(jīng)出過一個(gè)重大事件：千年蟲。
當(dāng)時(shí)的計(jì)算機(jī)系統(tǒng)處理年份的方式都是兩位數(shù)（如 1998 年會(huì)被系統(tǒng)縮略成 98），而 2000 年在老系統(tǒng)里仍然以 00 顯示，則會(huì)被系統(tǒng)當(dāng)成 1900 年。
然而誰都沒想到的是，就在前幾天，”千年蟲“又重演了……
發(fā)生了什么？
首先，幸運(yùn)的是，這次的事故規(guī)模，并沒有千年蟲那次那么大。目前已知受到影響的，只有采用了微軟 Exchange Server2016 和 2019 版本的企業(yè)本地郵件服務(wù)器。
因?yàn)槿蚝芏嗥髽I(yè)內(nèi)部的電子郵件，采用的都是自主搭建的系統(tǒng)（而非基于 Gmail、網(wǎng)易、阿里云等云端郵件的方案），而微軟的 Exchange 服務(wù)器 (Microsoft Exchange Server) 則是很多企業(yè)用戶都在用的本地郵件系統(tǒng)。
然而在 2021 年 12 月 31 日——去年的最后一天，在 IT 人員都已經(jīng)放假的時(shí)候，微軟突然推送了一個(gè)全新的 Exchange Server 版本，直接把所有企業(yè)客戶的電子郵件系統(tǒng)都給搞宕機(jī)了，大量郵件積壓在發(fā)送序列當(dāng)中，卻無法正常發(fā)送和接收。
錯(cuò)誤代碼大概是下面這樣的：
- 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 和微軟官方技術(shù)社區(qū)上大倒苦水。
“這玩意兒是怎么發(fā)布出來的？而且還是在新年夜？？？”
“電話都被打爆了。微軟你弄啥嘞？”
問題，出在微軟推送的這次更新的版本號上。
這次的更新，里面包含的電子郵件惡意軟件掃描引擎的版本號是 2201010001，表示的是 2022年01月01日00點(diǎn)01分。
微軟的產(chǎn)品和系統(tǒng)在表示時(shí)間的時(shí)候，用的都是這種符號整數(shù)。然而，根據(jù)微軟自己的開發(fā)文檔，其系統(tǒng)能夠接受的 Int32 符號整數(shù)的最大值是 2147483647。
這個(gè)最大值的前兩位是21。
也就是說，采用這種整數(shù)方式來記錄和表示時(shí)間，只能夠正常覆蓋到 2021 年的最后一秒。
所以，當(dāng)微軟推送出這個(gè) 2201010001 版本的時(shí)候，版本數(shù)字超過了系統(tǒng)能夠接受的整數(shù)最大值，結(jié)果就直接把 Exchange Server 郵件系統(tǒng)給搞崩潰了……
目前，微軟方面已經(jīng)提供了修復(fù)此問題的方法，可以執(zhí)行 PowerShell 腳本來自動(dòng)修復(fù)，也可以用手動(dòng)方法修復(fù)。修復(fù)必須在所有被波及的 Exchange Server 2016 或 2019 版本服務(wù)器上執(zhí)行。
很多被影響到的公司 IT，在修復(fù)過程中也遇到了各種各樣的問題。總的來說，這次微軟送的這個(gè)新年大禮包，讓大家整個(gè)新年都沒過好……
在微軟官方技術(shù)論壇上，一位用戶發(fā)出了靈魂拷問：誰會(huì)在 12 月 31 日推送生產(chǎn)環(huán)境更新??？
千年蟲重演，原因依然很蠢
這次微軟郵件服務(wù)器的 bug，以及其它公司/產(chǎn)品發(fā)生的類似的日期時(shí)間處理錯(cuò)誤，一起被命名為 Y2K22（也即 Year 2022 的縮寫）。
為什么這樣命名？正是因?yàn)椋瑢?dǎo)致這些 bug 出現(xiàn)的問題，和 21 年前的千年蟲 (Y2K bug)，幾乎一模一樣。
文章開始提到，千年蟲的出現(xiàn)，是因?yàn)楫?dāng)時(shí)一些相對比較古老的計(jì)算機(jī)系統(tǒng)，在處理年份的時(shí)候會(huì)采用兩位數(shù)簡寫。
當(dāng)時(shí)的普通人壓根想不到，新千年的到來會(huì)讓計(jì)算機(jī)系統(tǒng)出故障——唯一有可能預(yù)知這種情況發(fā)生的，也就只有程序員了。
而當(dāng)千年蟲事件即將發(fā)生的時(shí)候，那些已經(jīng)投入使用十年甚至 20 年的系統(tǒng)，背后的 COBOL 程序員（大多已經(jīng)或者快要退休了），又被請出山來修復(fù)他們當(dāng)年“埋”下的這些漏洞……
在當(dāng)時(shí)，有兩種修復(fù)的思路：
1）全盤重寫所有系統(tǒng)的代碼，稱為“expansion”；
2）打個(gè)快速的補(bǔ)丁，讓計(jì)算機(jī)能夠?qū)?00 到 20 的數(shù)字，正確識別為 2000 年到 2020 年——這種方式也被稱為“windowing”.
具體來說，這個(gè)補(bǔ)丁讓計(jì)算機(jī)系統(tǒng)將 1970 年 1 月 1 日 0 時(shí) 0 秒（也即程序員都非常熟悉的 Unix 時(shí)間戳）作為百年“時(shí)間窗口”的中間點(diǎn)，也即從 1920 年到 2020 年的任何一個(gè)時(shí)間點(diǎn)，在計(jì)算機(jī)系統(tǒng)里都可采用其到 Unix 時(shí)間戳的距離作為表示方法。
“高性能計(jì)算機(jī)新聞網(wǎng)”的一篇發(fā)布于 1999 年的報(bào)道顯示，在當(dāng)時(shí)，大約有八成的系統(tǒng)最后都是用第二種快速補(bǔ)丁的方式修復(fù)的。相比一勞永逸的全盤重寫，快速補(bǔ)丁的方式的成本優(yōu)勢非常明顯，然而即便如此，全世界的預(yù)估修復(fù)成本加起來也高達(dá) 3000 億美元……
當(dāng)面臨一個(gè)足夠大的問題的時(shí)候，相信一般人的正常反應(yīng)，都是“這個(gè)問題遲早得徹底解決”，并且也會(huì)傾向于一勞永逸地解決問題。
然而在當(dāng)時(shí)，人們沒有選擇一勞永逸，而是選擇了打補(bǔ)丁，還有另一層考慮，也即：這些系統(tǒng)已經(jīng)足夠老了，在未來的 20 年里總是要還的，所以沒必要一勞永逸的重寫了，反正到時(shí)候換新系統(tǒng)的時(shí)候，把日期時(shí)間的問題搞好，不就行了。
對此，倫敦經(jīng)濟(jì)學(xué)院的 Dylan Mulvin 教授表示，“Windowing 即使在當(dāng)時(shí)也是所有可選方案中最差的一個(gè)，它就是把皮球踢給后人的做法。”
果不其然，當(dāng)新系統(tǒng)替代舊系統(tǒng)的時(shí)候，當(dāng)年的編程思路，仍然被繼承了下來了……
事實(shí)上，到了 2020 年的時(shí)候，一些千年蟲修復(fù)過的系統(tǒng)，以及新安裝的系統(tǒng)，都又一次出現(xiàn)了和千年蟲幾乎一樣的問題：Y2K20 bug.
比如，在當(dāng)時(shí)有些用戶驚訝地發(fā)現(xiàn)，他們從寬帶公司收到的賬單顯示日期為 1920 年：
游戲公司 2K 開發(fā)的摔角游戲《WWE 2K20》，也在游戲標(biāo)題里這一年的第一天的第一秒就宕機(jī)了：
當(dāng)時(shí)紐約市的很多停車自動(dòng)繳費(fèi)機(jī)，也因?yàn)橄到y(tǒng)時(shí)間錯(cuò)誤而觸發(fā)了防火墻機(jī)制，無法接受信用卡支付：
結(jié)果你猜怎么著？這些故障，很快就被修復(fù)了。
至于他們采用了哪種思路——是一勞永逸，還是快速補(bǔ)丁——你應(yīng)該也能猜出來了……
如果說人類一定有什么做不到的話，那一定是從歷史中吸取教訓(xùn)。
緊接著，Y2K21 bug 又來了。比如，去年美國氣象局 (NWS) 的官方數(shù)據(jù)庫出現(xiàn)了重大誤差，對外提供的接口的數(shù)據(jù)晚了足足一天，導(dǎo)致很多第三方機(jī)構(gòu)的天氣數(shù)據(jù)都出現(xiàn)了錯(cuò)誤，影響了民航、海洋捕撈、畜牧養(yǎng)殖等諸多行業(yè)的正常運(yùn)作。
也有一些普通用戶發(fā)現(xiàn)，自己的電腦夢回 1921 年了：
再然后，2021 年也翻篇了，Y2K22 bug 也毫無懸念地按時(shí)來到了……
除了這次微軟 Exchange Server 出了故障之外，一些本田車主也發(fā)現(xiàn)，他們的車每天早上啟動(dòng)都會(huì)把時(shí)間自動(dòng)跳回到 2002 年。
汽車專業(yè)人士調(diào)查分析發(fā)現(xiàn)，本田車載系統(tǒng)的問題原因和微軟一樣，都是出在 Int32 整數(shù)上，開頭 22 的字符串無法被讀取，在本田這里就變成時(shí)間回退到 2002 年了……從 2004 到 2012 年的上百款車型都有較高幾率遇到此問題。
在公開場合，本田公司發(fā)言人表示，目前還在調(diào)查這個(gè)問題的具體原因。不過有車友在論壇上發(fā)帖表示，本田公司派人聯(lián)系他們，說這個(gè)問題會(huì)在今年 8 月份自行消除……
在可見的未來，Y2K23, 24, 25... 各種各樣的問題還會(huì)陸續(xù)發(fā)生。
并且，已經(jīng)在各種計(jì)算機(jī)系統(tǒng)中廣泛采用的 Unix 時(shí)間戳，還會(huì)在 32 位系統(tǒng)中導(dǎo)致一個(gè)問題，使得某些軟件在 2038 年 1 月 19 日 3 時(shí) 14 分 07 秒后無法工作：
對于”2038 年問題“，整個(gè)行業(yè)（特別是硬件壽命極長的嵌入式行業(yè)）的應(yīng)對方式，和 21 年前如出一轍：反正到了 2038 年的時(shí)候，應(yīng)該新系統(tǒng)又換了一茬了吧，到時(shí)候再說吧……
看來，大家根本不想徹底解決”千年蟲“以及其衍生問題。
可這又是為什么？
“一勞永逸”，不如多勞多得？
對于千年蟲這樣反復(fù)出現(xiàn)的情況，有人開玩笑說是程序員埋的坑
至少在千年蟲肆虐的時(shí)候，那些 COBOL 老古董程序員被請出山來修復(fù)問題的時(shí)候，就有人質(zhì)疑：他們是不是當(dāng)年故意給我們埋的坑啊？
這種想法有它的道理：程序員的職業(yè)生涯是有限的，不是所有人都能升到高管。那么那些平庸的程序員，如何保證在自己臨到退休的時(shí)候還能夠被需要？
埋個(gè)只有自己才懂得怎么修的漏洞，也沒什么毛?。?0 年一個(gè)周期，正好覆蓋從大學(xué)畢業(yè)到中年不惑……
當(dāng)然，實(shí)際上，在具體操作中，大多數(shù)運(yùn)作計(jì)算機(jī)系統(tǒng)的公司，在事故發(fā)生的時(shí)候，也一定會(huì)更傾向于選擇速度快、見效快、成本低的修復(fù)方式。
所以，程序員也不是什么陰謀家，因?yàn)樗麄儾皇菦Q策者——他們只是在正確的時(shí)間，執(zhí)行了對大家都合適的解決方案而已。
