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