每年的雙十一都是電商行業程式設計師們的一次大考。今年的雙十一剛剛過去不久，在雙十一之前的那一週，我幾乎每天都會想一個問題：如果系統會發生故障，那麼可能會在哪裡？

雙十一前一個月，是為數不多能暫緩業務需求，集中進行系統檢修的機會，在這期間會發現之前積累下來的各類隱患和小缺陷，並進行集中修復，然後上線壓測。雖然這已經是我經歷的第八次雙十一，各類備戰準備流程已經輕車熟路，一套架勢打下來，基本也算相對比較全面了。但還是沒有百分百的把握，因為事故，特別是工程上的事故總是發生在你想不到的地方。

就怕想不到，不怕做不到；備戰期間，專門找了一些工程上的失敗事故來看看，啟發一下思維路徑。這些工程事故都不是軟體開發方面的，而是更廣泛的傳統工程行業，但其事故影響也更加觸目驚心。每讀完一個事故的描述，我心下都是一驚，一回味，似乎類似的錯誤，要麼自己犯過，要麼碰到過。

簡單分享一些其中的事故。

量級問題

1940 年，美國華盛頓州的塔科馬海峽大橋，在一次大風中坍塌。

塔科馬海峽大橋是當時最長的懸索橋，橋樑設計師複製了現有結構較小的懸索橋，簡單構建了一個更長的懸索橋。這種結構在短跨度的橋上已經得到了驗證，工程師未經仔細計算想當然地擴大到了長跨度的橋上。後來，一天海上颳起了強烈的大風，橋開始波動並扭曲，隨後坍塌了。

曾經我在程式實現中就碰到過一個類似的場景：一個字串替換函式的實現。這是一個公共的工具函式，但其實現並不合理，當字串的長度比較小的時候，比如說 50K 以內吧，它的執行耗時對整個系統的影響幾乎感覺不出來。但一旦字串比較大了以後，效能會急劇下降。

而系統中確實偶爾就會出現超大的字串輸入，達到 100K～200K，這時這個函式的執行耗時會高出一個量級，系統的並行吞吐能力就瞬間下降很多，感覺非常明顯了。

這就是典型的量級問題，跨越了某個量級的邊界，邏輯就可能變了，而預期結果也不一樣了。

實施偏差

1981 年，美國堪薩斯市凱悅酒店，酒店大堂懸在半空中的走廊，在開業聚會上，人們在上面跳舞，產生了坍塌，導致 100 多人死亡。

空中走廊的固定方案，設計師的意圖在實施時卻變了樣。因為承包施工方不知道整體結構的設計影響，而為了趕工期急於完成這項工作，對設計方案的施工作了看似無關緊要，但卻最終致命的修改。

這在程式設計與實現中，簡直太常見了。軟體工程相比建築工程，其從設計到實施的嚴謹性，規範性相差可以說是天壤之別。建築工程中尚且無法完全避免，軟體工程中簡直是家常便飯了。

實施中，很可能為了便利的選擇，從而減弱了設計的初衷。

這有好的辦法來控制這個過程，減小實施偏差嗎？Code Review 算是一種吧，屬於實施走查，可以降低偏差的概率。但它也有成本，相對來說越是核心關鍵系統的程式碼，實施 Code Review 即使成本很高，也更容易推行。

比如說，底層儲存類資料庫系統，如果引發災難級事故，其影響很可能是不可逆的，那麼再高的成本也得承擔。但更多的業務類程式碼，業務本身在探索、演變和進化，而業務錯誤大部分也不是難以承擔的不可逆錯誤，所以在效率和成本之間就需要經常去平衡了。

現實中確實有這種情況，我們在寫程式碼實現時也許能發現更好的方法路徑，但做出這種改變時，要特別反思一下當初設計的初衷，是否把所有的點都考慮全面了。

場景缺失

1968 年 1 月，挑戰者號太空梭升空後不久爆炸。

挑戰者號是在美國佛羅里達肯尼迪航天中心發射的，爆炸的原因是太空梭的多節推進器連線的 O 形密封圈破裂，火焰從裂開的密封圈噴出並點燃了相鄰的燃料箱。

為什麼會破裂呢？因為這個密封圈缺乏在 0 度環境以下的測試。發射當天，氣溫很低，達到了 -2 攝氏度，這對於處在亞熱帶地區的佛羅里達是一個異常的低溫。過度冰冷的密封圈變得太脆，從而發生了低溫破裂。

我再想，如果當時發射時間選在春夏季節，也許就不會發生這次事故，但這個隱患可能很久都無法被發現。有些 Bug 會隱藏很久，但該來的總會到來。

大概是在上一次雙十一吧，我們的系統中就埋藏了類似這樣一個 Bug，那次公司在電視上作了互動，整點通過開啟 App 搖一搖來抽獎。本以為這個場景和我們沒啥關係，但沒想到在程式碼層面真有了關係，每次搖動的使用者都和我們系統建立連線併發起了登入，這部分流量完全在我們的預估之外，導致了系統訪問量比預估的最大量還高了十多倍，直接引發了限流，降低了使用者可用性和體驗。

這就是場景考慮缺失的問題，佛羅里達也許很少有這樣的低溫天氣，而我們也沒想到還有這樣一個場景。

想不到的，才是最危險的。

有什麼好辦法來預防嗎？也許可以讓團隊來開一個事故頭腦風暴會，把大家各自掌握的資訊和思維路徑都分享碰撞以下，也許會有一些啟發。

…

今天寫不完了，還有一些其他頗有啟示的事故案例，下次續一篇再聊。

寫點文字，畫點畫兒，記錄成長瞬間。
微信公眾號「瞬息之間」，既然遇見，不如同行。