創投圈大小事，你都能盡在掌握
騰訊創業 | ID：qqchuangye
作者 / 杜晨
編輯 / VickyXiao
在21年前世紀之交，全球的計算機系統和網際網路曾經出過一個重大事件：千年蟲。
當時的計算機系統處理年份的方式都是兩位數（如1998年會被系統縮略成98），而2000年在老系統裡仍然以00顯示，則會被系統當成1900年。
然而誰都沒想到的是，就在前幾天，”千年蟲“又重演了……
1
發生了什麼？
首先，幸運的是，這次的事故規模，并沒有千年蟲那次那麼大。目前已知受到影響的，隻有采用了微軟 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
一夜之間，大量的 IT 人員在 Reddit 和微軟官方技術社群上大倒苦水。
“這玩意兒是怎麼釋出出來的？而且還是在新年夜？？？”
“電話都被打爆了。微軟你弄啥嘞？”
問題，出在微軟推送的這次更新的版本号上。
這次的更新，裡面包含的電子郵件惡意軟體掃描引擎的版本号是 2201010001，表示的是2022年01月01日00點01分。
這個最大值的前兩位是21。
也就是說，采用這種整數方式來記錄和表示時間，隻能夠正常覆寫到2021年的最後一秒。
是以，當微軟推送出這個 2201010001 版本的時候，版本數字超過了系統能夠接受的整數最大值，結果就直接把 Exchange Server 郵件系統給搞崩潰了……
目前，微軟方面已經提供了修複此問題的方法，可以執行 PowerShell 腳本來自動修複，也可以用手動方法修複。修複必須在所有被波及的 Exchange Server 2016 或 2019版本伺服器上執行。
很多被影響到的公司 IT，在修複過程中也遇到了各種各樣的問題。總的來說，這次微軟送的這個新年大禮包，讓大家整個新年都沒過好……
在微軟官方技術論壇上，一位使用者發出了靈魂拷問：誰會在12月31日推送生産環境更新啊？
2
千年蟲重演，原因依然很蠢
這次微軟郵件伺服器的 bug，以及其它公司/産品發生的類似的日期時間處理錯誤，一起被命名為 Y2K22（也即 Year 2022 的縮寫）。
為什麼這樣命名？正是因為，導緻這些 bug 出現的問題，和21年前的千年蟲 (Y2K bug)，幾乎一模一樣。
文章開始提到，千年蟲的出現，是因為當時一些相對比較古老的計算機系統，在處理年份的時候會采用兩位數簡寫。
當時的普通人壓根想不到，新千年的到來會讓計算機系統出故障——唯一有可能預知這種情況發生的，也就隻有程式員了。
而當千年蟲事件即将發生的時候，那些已經投入使用十年甚至20年的系統，背後的 COBOL 程式員（大多已經或者快要退休了），又被請出山來修複他們當年“埋”下的這些漏洞……
在當時，有兩種修複的思路：
1）全盤重寫所有系統的代碼，稱為“expansion”；
2）打個快速的更新檔，讓計算機能夠将從00到20的數字，正确識别為2000年到2020年——這種方式也被稱為“windowing”.
具體來說，這個更新檔讓計算機系統将1970年1月1日0時0秒（也即程式員都非常熟悉的 Unix 時間戳）作為百年“時間視窗”的中間點，也即從1920年到2020年的任何一個時間點，在計算機系統裡都可采用其到 Unix 時間戳的距離作為表示方法。
“高性能計算機新聞網”的一篇釋出于1999年的報道顯示，在當時，大約有八成的系統最後都是用第二種快速更新檔的方式修複的。相比一勞永逸的全盤重寫，快速更新檔的方式的成本優勢非常明顯，然而即便如此，全世界的預估修複成本加起來也高達3000億美元……
當面臨一個足夠大的問題的時候，相信一般人的正常反應，都是“這個問題遲早得徹底解決”，并且也會傾向于一勞永逸地解決問題。
然而在當時，人們沒有選擇一勞永逸，而是選擇了打更新檔，還有另一層考慮，也即：這些系統已經足夠老了，在未來的20年裡總是要還的，是以沒必要一勞永逸的重寫了，反正到時候換新系統的時候，把日期時間的問題搞好，不就行了。
對此，倫敦經濟學院的 Dylan Mulvin 教授表示，“Windowing 即使在當時也是所有可選方案中最差的一個，它就是把皮球踢給後人的做法。”
果不其然，當新系統替代舊系統的時候，當年的程式設計思路，仍然被繼承了下來了……
事實上，到了2020年的時候，一些千年蟲修複過的系統，以及新安裝的系統，都又一次出現了和千年蟲幾乎一樣的問題：Y2K20 bug.
比如，在當時有些使用者驚訝地發現，他們從寬帶公司收到的賬單顯示日期為1920年：
遊戲公司 2K 開發的摔角遊戲《WWE 2K20》，也在遊戲标題裡這一年的第一天的第一秒就當機了：
當時紐約市的很多停車自動繳費機，也因為系統時間錯誤而觸發了防火牆機制，無法接受信用卡支付：
結果你猜怎麼着？這些故障，很快就被修複了。
至于他們采用了哪種思路——是一勞永逸，還是快速更新檔——你應該也能猜出來了……
如果說人類一定有什麼做不到的話，那一定是從曆史中吸取教訓。
緊接着，Y2K21 bug 又來了。比如，去年美國氣象局(NWS)的官方資料庫出現了重大誤差，對外提供的接口的資料晚了足足一天，導緻很多第三方機構的天氣資料都出現了錯誤，影響了民航、海洋捕撈、畜牧養殖等諸多行業的正常運作。
也有一些普通使用者發現，自己的電腦夢回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年的時候，應該新系統又換了一茬了吧，到時候再說吧……
看來，大家根本不想徹底解決”千年蟲“以及其衍生問題。
可這又是為什麼？
3
“一勞永逸”，不如多勞多得？
對于千年蟲這樣反複出現的情況，有人開玩笑說是程式員埋的坑
至少在千年蟲肆虐的時候，那些 COBOL 老古董程式員被請出山來修複問題的時候，就有人質疑：他們是不是當年故意給我們埋的坑啊？
這種想法有它的道理：程式員的職業生涯是有限的，不是所有人都能升到高管。那麼那些平庸的程式員，如何保證在自己臨到退休的時候還能夠被需要？
埋個隻有自己才懂得怎麼修的漏洞，也沒什麼毛病？20年一個周期，正好覆寫從大學畢業到中年不惑……
當然，實際上，在具體操作中，大多數運作計算機系統的公司，在事故發生的時候，也一定會更傾向于選擇速度快、見效快、成本低的修複方式。
是以，程式員也不是什麼陰謀家，因為他們不是決策者——他們隻是在正确的時間，執行了對大家都合适的解決方案而已。
注：封面圖來自于Business Insider，版權屬于原作者。如果不同意使用，請盡快聯系我們，我們會立即删除。
END
你認為程式員的職業生涯是什麼？
歡迎評論區留言，與大家分享。