軟體質量穩定性之殤

黑天鵝事件告訴我們要走出經驗主義，不要將自己知道的東西太當回事，我們不知道的事比我們知道的事更有意義。蝴蝶效應告訴我們要及時感知問題，止損和熔斷，避免問題範圍擴大甚至傳染到其他相關領域。墨菲定律告訴我們，我們知道的但是忽略的地方終究會出問題。

一言以蔽之，要將軟體研發中的質量搞好並非易事。導致軟體質量問題難以把控的原因還有很多，本節會詳細進行分析。

業務高速發展帶來的變化

在很多年前就有人想將軟體從業者變成製造工人，不斷進行流水線工作。但這幾乎沒什麼可能，因為軟體從業者要解決的問題域太複雜。雖然業界有很多規範、標準、套裝軟體，但是仍然未解決問題的萬分之一。

阿里巴巴的電商業務在最近幾年呈指數級增長，業務的發展速度驚人。阿里巴巴內部有一句話說：雙11是業務的狂歡、技術的盛宴。

到目前為止，阿里巴巴做了10年雙11，雙11交易額從2009年的5.9億元增長到2018年的2135億元，實現了355倍的增長，交易峰值也從2009年的400筆每秒，增長到2018的49.1萬筆每秒，系統規模也有幾十倍、上百倍的增長，如圖6.4所示。

圖6.4

隨著業務的高速發展，技術挑戰越來越大，有些挑戰甚至是無法借鑑的，只能靠自我創新。阿里巴巴面對的雙 11 技術挑戰，可以說是世界性的，特別是如何在零點峰值到來時確保系統穩定。

問題域的複雜性

IBM大型機之父佛瑞德·布魯克斯在《沒有銀彈：軟體工程的本質性與附屬性工作》論文中提到：軟體開發是極其困難的，這些困難分為兩類：本質性的和附屬性的；附加性的困難會隨著工具的改善逐漸淡化，本質性的困難是最難解決的，其要點是問題域的複雜性。

問題域，就是針對現實世界中某個特定問題的所有相關方面的抽象。現實世界中的某些特定問題本來就是極其複雜的，根據這些問題做的抽象，問題域自然不會簡單。因為不同的人看問題的角度可能不一樣，所以抽象出的結果可能大不相同。

系統的複雜性

隨著業務的發展，人們對可用性的訴求越來越高，但是可用性的提高必然導致系統的複雜度攀升。為了提升系統的可用性，應用的部署就可能從單機部署演化成叢集部署。而叢集部署在初期可能採用同城多機房的容災方案，慢慢又會演化成異地多機房的容災方案。而隨著方案越來越複雜，多個機房之間的負載均衡、容災方案等挑戰也會越來越大。這還只是考慮了線上生產環境中的機器情況，再加入測試環境、灰度環境、預釋出環境等，就會更加複雜。

除了叢集部署，為了提升可用性等問題，我們也會將單體應用拆分成分散式應用，進而演化成微服務，各個應用之間透過RPC、非同步訊息等方式進行通訊，這就會引入更多的資料一致性等問題。

舉個例子，有一個主要用於支付鏈路的規則決策的系統，該系統起初可能只有4萬行程式碼，後來增加到 8 萬行程式碼，現在又增加到 10萬行程式碼。程式碼行增加了，該應用的功能也增加了，同時系統的呼叫邏輯及運算的複雜度必然增加，那麼如何保持對外 API 的TPS不降低，RT不降低？

技術債問題

技術債務是由Ward Cunningham在1992年創造的一個比喻，被定義為我們有意或無意中做了錯誤的或不理想的技術決策所累積的債務。

Steve McConnell將技術債務分為如下兩類。

◎ 無意的：由於經驗的缺乏導致初級開發者編寫了質量低劣的程式碼。

◎ 有意的：團隊根據當前而非未來進行了設計選型，這種方式可能很快解決了當前的問題，但很拙劣。

隨著技術團隊人員的能力提升，無意的技術債務可能會越來越少。但是在很多時候，我們欠下的技術債務往往是有意的，隨著業務的高速發展，還會帶來很多變化。為了快速實現業務的功能及驗證商業決策，開發人員大多會採用很多臨時方案。毫不客氣地說，這些臨時方案其實就是技術債。

臨時方案的可怕之處，不僅僅在於其不全面，更在於如果不對其及時處理，可能就永遠“臨時”下去了。隨著團隊成員的不斷更替，慢慢地就沒人記得這個臨時方案了。一個說好只支撐兩個月的臨時程式碼，可能兩年後還在線上機器裡執行著。

隨著系統中的臨時方案越來越多，我們需要還的技術債也越來越多。欠債並不可怕，可怕的是沒有償還計劃。其實，任何系統都無法避免技術債，因為業務在不斷髮展，總需要做些妥協，這都無可厚非，但是一定要注意如下幾點。

◎ 透過人員培訓、程式碼審查等方式杜絕無意的技術債。

◎ 要儘量避免有意的技術債。

◎ 如果一定要引入技術債，則一定不要引入不計後果的技術債。

◎ 要記錄所有欠下的技術債，並且有償還計劃。

技術債務和金融債務非常相似。一個人貸了款就會產生債務，如果可以定期還款，則所欠的債務是可以接受的，不會產生進一步的問題；但是，如果不還款，就會以利息作為懲罰，利息還會隨著不還款次數的增加而增加。如果這個人在很長一段時間內不能支付任何款項，那麼應計利息會使他更難以償還債務。在極端情況下，這個人就不得不宣佈自己破產。技術債務也一樣，如果越積越多，最終也會導致非常嚴重的後果。

人、流程、文件的博弈

面對複雜的問題域，人們都有簡單化思考的傾向。比如某開發人員將手工修改的程式碼透過自動生成工具覆蓋了，這時會有兩種選擇，一個是透過兩個目錄來區分，一個是開發一款檢查工具來做合併前的稽核。這些做法都沒有問題，但是不要靠腦子去記。對於一個存在3年以上的產品，當有新人到來的時候，他們總會在第1個月提這樣的問題：“這個產品怎麼採用這樣的技術啊？理解成本這麼高，一點文件都沒有！只能看程式碼，程式碼寫得還不怎麼樣……”當新人成了“老人”，他們會對更新的新人說：“我們當年更慘，只有看程式碼是靠譜的。對了，有某位專家非常瞭解相關內容，有問題找他，比看文件有用。”

總之，我們不得不承認的事實包括：

◎ 無論寫多少文件，如何維護“活文件”（一個特別熟悉程式碼的人）都是一個大問題；

◎ 關鍵時刻要靠人傳、幫、帶，要靠傳承。

採用不能掌控的工具和框架

技術人員大多有采用新工具、新語言、新開源產品的追求。當全棧、多語言風潮席捲各社群的時候，不羅列一堆名詞真心不好意思跟人交流。這還涉及技術帶頭人的偏好問題。

在前面的章節中，我們鼓勵開發者學習新技術、新語言等。但是不得不說，有很多線上故障都是由於開發者對所使用的新技術不瞭解導致的。所以，對於新技術、新語言，我們應該充滿期待，但是在真正將其引入日常工作中的時候，一定要考慮整個團隊對於這項技術的接受程度及掌握程度。

質量意識

經過分析，80%的線上問題並不那麼難以解決，其本質是未遵循規定的動作。比如修改了程式碼且未充分驗證，認為就修改了幾行程式碼，咋看都不會出錯。從內建質量的角度來看，我們一般有多條質量防線，一個問題被遺留到線上，往往有3個以上的措施都失守了。很多故障的發生，都是因為質量意識的薄弱導致的。無論是開發人員還是測試人員，都應該對線上環境保持敬畏之心。前面提到過墨菲定律、蝴蝶效應及黑天鵝事件等，都是希望提醒讀者們，尤其是開發者，要對自己的每一行程式碼都保持敬畏之心。

有一篇關於如何規範飛行員作風的文章提到的如下經驗頗有借鑑意義。

◎ 不忘初心，嚴格遵守SOP（標準操作程式）。

◎ 減少僥倖心理，增強風險意識。

◎ 狠抓作風養成。

◎ 嚴厲處罰無後果違章，既要結果，又要過程正確。