譯者 | 劉汪洋

審校 | 重樓

“錯誤是成長的階梯”和“失敗乃成功之母”——這些諺語為我們在犯錯時提供慰藉。程序員熱衷于創新，對追求新技術趨勢保持著高度的熱情，這就要求他們必須不斷學習。基于這些觀點、虛構的情節，再加上我的七年程序開發經驗以及與同行的交流，我認為程序員經常會犯錯。

為了發現或預防這些錯誤，我們采取了自動化測試、代碼審查、環境隔離和灰度發布、執行數據備份、與質量工程師合作，還有利用多種工具來盡早發現問題。

即便實行了這些預防措施，偶爾還是會有漏洞在測試環節被漏掉，進而進入生產環境。這時候，我們該怎么辦？我們會迅速定位問題所在，進行修復，并盡快將修改部署到生產環境。我們的目標是盡可能降低受影響用戶的數量。另一方面，錯誤在生產環境中存在的時間越長或影響越大，就越能引起公司內部更多的討論。

然而，某些錯誤因其巨大的規模或特殊的情況，不止在經歷過這些錯誤的人群中引發討論。這些錯誤可能會成為新聞頭條、報紙的熱門話題，有些甚至擁有獨立的維基百科頁面，一些錯誤發生 60 年后也仍然歷歷在目。在本文中，我們將探討一些這類重大錯誤，了解它們是如何發生的，以及我們能從中學到什么。

Mariner 1：世界上最昂貴的破折號錯誤

1962 年，NASA 發射了首艘前往其他行星的探測器 Mariner 1，計劃飛往金星并測量其溫度、磁場等科學家感興趣的數據。然而意外發生了：發射不久后，探測器開始偏離預定軌道。為了避免對地球造成潛在的風險，最終決定啟動自毀程序。

人們普遍認為，這次失敗是由編程錯誤導致的。具體來說，是由于代碼中缺少了一個破折號。事實是什么呢？在代碼中，存在一個涉及符號“R”代表半徑的數學運算。正確的表示應為平均半徑“R-bar”，在物理學中表示為 R?。然而，這不僅僅是關于“一個破折號”的問題。這個錯誤導致銷毀了價值兩千萬美金航天器。

既是一個物理和數學上的錯誤，為何仍然被歸結為編程錯誤呢？這個錯誤最初出現在計算過程中，程序員只是將其轉換成了代碼。在理想狀態下，這種錯誤應該通過測試發現，或者在程序員與數學家或物理學家的合作中被識別。程序員經常為不同領域編寫代碼，雖然不用成為該領域專家就可以開發應用，但掌握基礎知識并和該領域的專家合作是很重要的，這樣才能開發出可測試的代碼場景（最好是能通過自動化測試進行驗證）。

我們能從 Mariner 1 的故障中學到什么呢？

首先，對代碼進行充分測試是非常必要的。在跨領域的大型項目中，團隊合作至關重要。同樣，總是準備一個備用計劃是明智的，雖然可能不需要 NASA 那樣的自毀系統，但制定出錯時的應對策略總是好的。

千年蟲（Y2K）問題

所有經歷過 2000 年新年夜的人都記得，在午夜來臨時人們擔心電腦是否會癱瘓、銀行數據是否會丟失、飛機是否會墜落。然而，午夜來臨后，幾乎沒有什么災難性的事情發生。確實有幾起計算機系統故障的報告，但它們很快就被解決了。

為了向未經歷過千年蟲問題的年輕一代以及那些90年代末忙于其他事務僅略有所聞的人提供一些背景信息：
在 20 世紀 50 年代，計算機內存的成本極為昂貴，大約為每位 1 美元，也就是每字節 8 美元。這就是為什么那個時代的編程語言，比如 COBOL，僅用兩位數字來存儲年份。程序默認年份的前兩位數字為“19”。

因此，程序員通過節省幾個字節的方式來降低成本。他們預計計算機內存的價格最終會降低，卻沒想到幾乎花了50年時間才解決這個問題。雖然他們的預測正確，但問題在于推遲了采取行動。

像 Bob Bemer 這樣的先驅從 60 年代開始就已經討論采取的措施，并在 70 年代撰寫了相關文章。但直到 1994 年，人們才開始采取行動。那時，存在該問題的系統已經非常普遍，基于這一問題開發的新軟件也非常多，以至于糾正這一問題所需的工作量非常巨大。據估計，解決這個問題的總成本超過了 3000 億美元。

我們從 Y2K 錯誤中學到了什么？

我們將在 2038 年見證，當到了面臨 Y2K38 錯誤（也稱為 Epochalypse）挑戰的時刻。這關系到將在 2038 年 1 月 19 日遇到相似問題的 Unix 32 位時間戳，屆時它的時間位將耗盡。推遲問題的解決并非總是壞事，因為在某些情況下這可能帶來好處。但無論何時推遲，都必須確保任務能及時完成。在代碼中添加“待辦”注釋時，標明負責人和預定的完成截止日期顯得尤為重要。

魔獸世界腐化之血事件

《魔獸世界》是一款在 2005 年極受歡迎的電腦游戲，它吸引了大量玩家在同一服務器上聯機游戲。游戲中的一項任務要求玩家團隊合作挑戰地下城并擊敗其中的敵人。2005 年 9 月，一個新地下城的終極 Boss 釋放了一種名為腐化之血的法術，它能對受擊的玩家造成持續傷害，并傳染給附近的玩家。原本這種效果應在玩家離開地下城后消失，但一個代碼漏洞導致這種效果通過玩家的寵物在游戲世界其他地方傳播。

腐化之血疫情在《魔獸世界》中迅速擴散，首當其沖的是人口密集的大城市。玩家角色可以隨著時間被治愈或通過死亡復活，而非玩家角色（NPC）卻持續處于感染狀態，這加劇了病毒的傳播。一些玩家試圖治療其他受感染的玩家，或者在城市外警告他人，以阻止疫情的擴散。然而，也有些玩家卻發現傳播疫情很有趣。

開發團隊迅速察覺到這一問題，并開始尋找解決方案。他們嘗試了多種補丁，但都未能徹底消滅病毒，因為病毒總是能在某個地方存活并再次傳播。經過近一個月的嘗試后，他們決定重置服務器到發布該地下城前的狀態。

從《魔獸世界》腐化之血 bug 中，我們能學到什么？

其中一個教訓是在編程時需要考慮到所有可能的邊界情況。將虛擬“病毒”像傳播真實病毒一樣傳播給玩家的概念，在電腦游戲中實現是非常有創意的。有趣的是，這一事件后來被一些玩家回憶起，并請求開發商再次實現類似情況（這次是有意為之）。這個 bug 的發生讓一些程序員對其背后的混亂情況感到好奇，并思考什么導致了需要將服務器回滾至一個月前的狀態。值得一提的是，免疫學家也對這一案例很感興趣，因此他們將這一事件作為大流行模擬的研究對象，既研究病毒的傳播也研究了特定情況下的人類行為。

心臟滴血漏洞

OpenSSL 是一個開源加密庫，它提供了一系列工具，用來創建符合行業安全標準的服務器與客戶端加密連接。開發者要遵守這些安全標準時，不必從頭開始打造解決方案，可以將這個庫直接集成進項目中，借助其現成的功能確保通信安全。

然而，當這樣一個旨在增強安全的代碼庫出現安全漏洞時，問題就顯得格外嚴重。OpenSSL 因一個實現 TLS 心跳擴展的錯誤而導致本應受保護的信息被泄露，由于這個漏洞的嚴重性，人們給它起了個別稱“心臟出血漏洞”。

隨著時間的推移，這個問題最終得到了解決。但是，所有使用了 OpenSSL 庫 2011 年至 2014 年間發布版本的用戶都必須通過升級到最新版本來消除這一安全隱患。據估計，2014 年時，高達三分之二的活躍網站依賴 OpenSSL，尤其是因為它在 Apache 和 Nginx 等流行的開源網絡服務器上得到了廣泛應用。

我們能從“心臟滴血”漏洞中學到什么教訓？

對于現代程序員而言，使用開源庫是日常工作的一部分。如果對每個問題都從零開發，忽視了現成的解決方案，編程效率將會大大降低。然而，每當向系統中引入一個新的庫時，都應該保持警惕，不能僅僅因為某個庫廣受歡迎就認為它絕對安全。

GitLab備份事件

GitLab 是一個深受歡迎的軟件開發協作平臺，用戶約有 3000 萬。

2017 年 1 月，GitLab 的工程師發現數據庫負載突然激增。在嘗試診斷問題并恢復正常運行的過程中，他們遇到了一系列困難。因此，決定手動同步部分數據庫。然而在操作過程中，他們發現一個錯誤，盡管幾秒內就停止了操作，卻仍然導致了 300 GB 用戶數據的丟失。

面臨這一挑戰時，GitLab 所依賴的備份系統發揮了關鍵作用。然而，當他們嘗試使用備份恢復數據時，發現恢復過程存在缺陷，且沒有可用的最新備份。最終，他們只能使用六小時前轉移到測試環境中的數據進行恢復。對于一個擁有 3000 萬用戶的平臺來說，六小時的數據丟失絕非小事，這種情況暴露了緊急情況下備份和數據恢復流程的不足，這無疑令人感到沮喪。

我們能從這個事件中學到什么？

作為開發者，我們都知道處理數據時備份的重要性。這起事件警示我們，僅僅擁有備份遠遠不夠，備份策略需要根據系統的實際情況、數據類型以及用戶需求來制定。此外，定期測試備份及恢復流程的有效性也是至關重要的。

從這些編程錯誤中，我們能得出什么結論？

有哲學家說過：“不從歷史中汲取教訓的人，注定會重蹈覆轍。”幸運的是，對于我們程序員而言，需要重點關注的歷史始自 20 世紀，回顧起來也不算繁瑣。這既是優勢，也伴隨著挑戰，因為哪怕是微不足道的錯誤——例如在游戲中引入一種魔法病毒——也可能讓你在 18 年后依然被人銘記。

在你讀到某公司出錯的案例時，我建議你想一想自己如果處在那種境地，會如何應對，并且從他們的錯誤中學到教訓。

譯者介紹

劉汪洋，51CTO社區編輯，昵稱：明明如月，一個擁有 5 年開發經驗的某大廠高級 Java 工程師，擁有多個主流技術博客平臺博客專家稱號。

原文標題: Famous Programming Errors That Everyone Should Learn From，作者:Rino Kova?evi?