架構的保障：質量與風險

內建質量體系

成本理論告訴我們，設計和開發是成本控制的源頭，一般而言，成本隨著專案的推進，在不同的階段會呈現幾何級的增長。實踐證明，如果在前期設計時沒有考慮周全，則使用者往往抱怨不斷，甚至導致專案返工。所以如何實現前期預防，對專案的成功至關重要，我們將 這 種 前 期 預 防 的 質 量 管 理 模 式 稱 為 “ 內 建 質 量 （ Built-inQuality）”。

內建質量是所有質量思維中最難實現的，也是質量挑戰的終極目標。舉個例子，一個簡單的排線聯結器是有正反兩面的，如果將其正反面裝反，則需要到電流測試時才能發現該問題，但如果將接頭做成不對稱的形狀，在裝反時讓插頭插不進去，就可以預防該問題的發生。這種防呆裝置在組裝設計上使用普遍，其實就屬於內建質量的範疇。

每個公司都希望以最快的速度可持續地交付新功能，並應對瞬息萬變的商業環境，這些都有賴於解決方案的質量。內建質量則有助於減少需求召回、返工及缺陷修復相關的延遲成本，非常適用於大規模系統，並且是強制性實施的。

內建質量強調“三不原則”：不接受不良品，不設計或製造不良品，不流出不良品，如圖6.1所示。其特定範圍可大可小，小到一個人，大到一個工廠。在流水線生產模式下，要想做到每個工位的內建質量是非常困難的，所以其下游佈置了許多檢測來找出這些不良品。

從整個工廠來看，如果這些不良品都能被攔下來，不流到客戶端，則也算是工廠整體做到了內建質量。雖然搭建一套真正持續有效的內建質量體系是極其困難的，但即便是一個很難企及的目標，我們也不該放棄。

圖6.1

內建質量思維就是激發全員追求完美的工匠精神，唯有所有環節的人（包括企業家、領導）都能找回這種帶有某種偏執狂的執著、認真、負責、追求完美的精神，才能將內建質量思維落實到業務當中，將其轉化為企業的核心價值觀。內建質量思維只有體現在產品和服務上，能讓客戶感受到，才能成為競爭對手極難模仿和跨越的核心競爭力。

“早發現、早解決”的難點在於發現而不是解決，質量管理的基本思路是上游管控，但要建立有效的“早發現、早解決”機制並不那麼容易。就拿生產來說，對來料的抽檢不能保證100%上線的料沒有不良品；生產線上的工人也不可能不出錯；機器用久了更不會沒有瑕疵；測試儀器也有校準或量測不到位的時候；品檢也有眼花誤判的時候，等等，這些都會導致不良品的流出。要想杜絕不良品的流出，就得從頭到尾設定許多風險預警、識別裝置等。

“早發現、早解決”體現在能夠在表面正常的情況下嗅到發生危機的風險，從而及早採取防範或應變措施，大大降低發生損害的程度。所以，從事質量工作的人除了要能解決問題，還要能識別發生質量風險的徵兆。

雖然質量改進永遠不能停止，但是追求持續改進不能操之過急，應從小處著手，慢慢擴充套件。PDCA迴圈正是推動持續改進的重要方法之一，如圖6.2所示。

圖6.2

PDCA代表了持續改進的如下4個主要步驟。

（1）P（Plan）：指仔細分析現狀，並將現狀與目標進行對比，看看缺口在哪裡，然後詳細規劃改善的步驟。可以分幾個步驟：一是將問題和目標定義清楚；二是利用各種工具，例如作業流程圖、魚骨圖等，將問題相關的流程和因素梳理出來，定下優先順序；三是進一步拆解流程，仔細分析各個步驟，看看問題可能出在哪裡。

（2）D（Do）：指根據計劃動手改進。需要事先想好退出計劃，在動手時應從小處切入，謹防破壞現有流程，造成系統癱瘓。如果解決方案不止一個，就應該設計一個實驗，評估各方案的優劣。

（3）C（Check）：指監控改進過程。需要確認測量工具和方法維持不變，否則可能誤判。在結果資料出來後，需要仔細分析，看看哪種方案比較有效，而且對原來流程的變更幅度最小。

（4）A（Act）：指確認改善的確有效，在不良和缺陷已經消除後，匯入及固化流程，改寫規範。若改善無效，則檢討原因、修改計劃，重新啟動一輪PDCA迴圈。

PDCA迴圈是爬樓梯上升式的迴圈，每轉動一週，質量就提高一步。在一輪迴圈結束後，也許只解決了一部分問題，或者在解決的過程中又衍生出新的問題，因此必須再進行一輪PDCA迴圈。如此迴圈迭代，不斷提高軟體的質量。

對於整個軟體開發生命週期而言，軟體質量貫穿於各個環節當中，從需求分析開始，一直到釋出上線，PDCA迴圈則是專案迭代順利完成的重要保障，如圖6.3所示。

圖6.3

從黑天鵝事件到墨菲定律

軟體系統的穩定性，主要取決於整體的系統架構設計，然而也不可忽略程式設計的細節，所謂“千里之堤，毀於蟻穴”，一旦考慮不周，看似無關緊要的程式碼片段便可能導致軟體系統的整體崩潰。

本節主要介紹幾個重要的理論，分別是黑天鵝事件、蝴蝶效應和墨菲定律。這些理論在軟體開發領域尤其是質量方面都至關重要。在瞭解這幾個理論後，我們會發現，保證軟體系統的質量其實並不容易。

黑天鵝事件

黑天鵝寓意不可預測的重大稀有事件，它在意料之外，卻又改變著一切。人類總是過度相信經驗，殊不知其實一隻“黑天鵝”的出現就足以顛覆一切。所以，黑天鵝事件一般指難以預測且不尋常的通常會引起市場連鎖負面反應甚至顛覆的事件。泰坦尼克號沉沒、9·11事件、美國的次貸危機、2008年中國的雪災，都是比較典型的黑天鵝事件。

黑天鵝事件通常具備如下三個特點：

（1）稀缺、史無前例（Rarity）；（2）影響很極端（Extreme Impact）；

（3）具有意外性，但人的本性促使我們在事後為它的發生編造理由，並且或多或少認為它是可解釋和可預測的。

“黑天鵝”存在於各個領域，無論是金融市場、商業、經濟還是個人生活，都有它的蹤跡。最近幾年發生的幾個IT領域相關的黑天鵝事件如下。

◎ 2015年5月27日下午5點左右，某支付平臺出現網路故障，導致賬號無法登入，無法完成線上支付。後經證實，該故障是由於杭州市蕭山區某地光纖被挖斷導致的，這一事件造成部分使用者無法使用該支付平臺，其影響輻射到全國範圍內的各個領域。

◎ 2016年3月15日，Google DeepMind公司開發的圍棋人工智慧程式AlphaGO和韓國著名的圍棋專業選手李世石進行了對決。最終雙方總比分為4：1，AlphaGo取得了人機圍棋對決的勝利。2017年5月23日，AlphaGo再次與人類圍棋高手柯潔展開對決，最終柯潔中盤投子認輸。

賽後柯潔表示：“它太完美，我看不到希望。”

◎ 2017年5月，一種名“WannaCry”的蠕蟲式勒索病毒利用NSA（National Security Agency，美國國家安全域性）洩露的危險漏洞EternalBlue（永恆之藍）進行傳播，全球150多個國家和地區超過30萬臺電腦遭到了勒索病毒攻擊，影響到金融、能源、醫療、教育等眾多行業，損失高達80億美元。

◎ 2018年6月10日，韓國交易所Coinrail宣佈其系統檢測到駭客攻擊，NPXS已經受損，被盜虛擬貨幣的價值達到400億韓元（約人民幣2.4億元）。CoinMarketCap的資料顯示，從交易量來看，Coinrail剛排進全球前100名，但是其被駭客攻擊所導致的影響是非常巨大的。

在Coinrail遭受攻擊後的24小時內，市值前100的加密貨幣有99種價格下跌，總市值縮水約316億美元，首當其衝的比特幣跌破7000美元，比特幣的價格在三個交易日下跌了近12%，引發了價值460億美元的拋售，並將自2018以來比特幣的跌幅擴大至50%以上。近三年來，在IT領域比較大的4起黑天鵝事件中，有3起是因為軟體系統的可用性、安全性等受到挑戰導致的，後果相當嚴重。

英國著名哲學家弗朗西斯·培根就曾發出這樣的警告：我們要當心被自己思想的絲線束縛。無論是泰坦尼克的沉沒，還是中興被制裁，如果業界沒有類似的案例，那麼幾乎無從借鑑。即使有業界案例，不同的組織、公司未必有相應的處理經驗，所以自己的思想、經驗也是非常有侷限性的。有時我們太看重自己知道的事，卻沒發現我們不知道的事比我們知道的事更有意義，所以只有反常地思考一切，才有可能發現更多的“我們不知道的事”。

蝴蝶效應

20世紀70年代，美國氣象學家洛倫茲在解釋空氣系統理論時說：“亞馬孫雨林中的一隻蝴蝶偶爾振動翅膀，也許會引起兩週後美國得克薩斯州的一場龍捲風。”

這就是著名的蝴蝶效應，意思是初始條件十分微小的變化經過不斷放大，也許會對未來造成極大的影響。

圖靈獎得主Tony Hoare在Null References：The Billion DollarMistake文章中寫到：“我將 Null 引用稱為自己的 10 億美元錯誤，它的發明是在 1965 年，那時我用一種面嚮物件語言（ALGOL W）設計了第1個全面的引用型別的系統，目的是確保所有引用的使用都是絕對安全的，編譯器會自動進行檢查。但是我未能抵禦住誘惑，加入了Null 引用，僅僅因為實現起來非常容易。Null引用導致了數不清的錯誤、漏洞和系統崩潰，可能會在之後40年裡造成10億美元的損失。”

Null引用在 Java中的表現就是可能丟擲 NullPointerException異常，這是一種非預期的異常。對於 IT 系統而言，還有很多非預期的錯誤及異常，都可能是蝴蝶效應引起的大故障，例如非預期error、非預期的呼叫抖動、極少數場景下的規則未被正確處理、錯誤的優惠處理邏輯、未正確設定的營銷活動，等等。如果不具備快速、智慧的感知能力，那麼可能影響更多的使用者，使資金損失增加、業務不可用時間變長，等等。

墨菲定律

“墨菲定律”是一種心理學效應，由愛德華·墨菲（EdwardA.Murphy）提出。它的原句描述為：如果有兩種或兩種以上的方式去做某件事情，而其中一種選擇方式將導致災難，則必定有人做出這種選擇。

墨菲定律（Murphy’s Law）的主要內容如下：

◎ 任何事都沒有表面看起來那麼簡單；

◎ 做所有的事花費的時間都會比你預期的時間長；

◎ 會出錯的事總會出錯；

◎ 如果你擔心某種情況會發生，它就更有可能發生。

愛德華·墨菲是美國愛德華茲空軍基地的上尉工程師。1949年，他和他的上司斯塔普少校參加美國空軍進行的 MX981 火箭減速超重實驗。這個實驗用於測定人類對加速度的承受極限。其中有一個實驗專案是將 16 個火箭加速度計懸空裝置在受試者上方，當時有兩種方法可以將加速度計固定在支架上，而不可思議的是，竟然有人有條不紊地將 16 個加速度計全部裝在錯誤的位置。於是墨菲做出了這一著名的論斷，意思是如果做某項工作有多種方法，而其中有一種方法將導致事故，那麼一定有人按這種方法去做。

在IT系統中有很多關於墨菲定律的案例，接下來會列舉其中的兩個案例。

這裡列舉第1個案例。筆者曾遇到一位經驗豐富的架構師，他對系統遷移過程中的自校驗、核對、切流策略、灰度能力、回滾機制、容錯處理等都進行了充分考慮，但未充分考慮老系統的一種流程處理缺陷的備案或者處理方案，因為老系統在上線的一年內只發生了1起相關故障。但該缺陷的影響在新系統中被無限放大，很快就導致1起嚴重的線上故障。

這裡列舉第2個案例。很久以前，筆者所在的公司來了一位專家級別的開發人員，他面對的第1個小需求就是把搜尋結果列表從每頁10條改為每頁50條。他認為只改一個分頁的pageSize就可以了，於是很快就改完了，並且沒經過測試就釋出到線上，結果導致公司整個網站的搜尋結果跌零。

後來經排查發現，因為老系統的效能不高，所以開發人員做了一個設定：當搜尋結果不少於 50 條的時候，就直接返回 0條搜尋結果。暫且不論這種設定是否合理，這種故障之所以發生，就是因為開發人員過於自信，疏忽了重要的測試環節。所以，在軟體測試方面，沒有經過測試的功能往往會出問題。

由於認知的侷限性、驕傲心態、問題域的複雜性及不可把握性等因素，軟體行業發生問題的機率很高。墨菲定律告訴我們：事情往往會朝著我們所能想到的不好的方向發展，只要存在這種可能性。所以，無論是開發人員還是測試人員，都需要謹記墨菲定律，莫存僥倖心理，要把自己的系統設計得足夠強壯。