摘要：那么這么一套保證飛行安全的系統(tǒng)和空難有什么關(guān)系呢事實上系統(tǒng)工作得非常好，根據(jù)波音自己的統(tǒng)計，系列已經(jīng)完成了數(shù)十萬次的安全起降。

隨著阿里技術(shù)的發(fā)展，我們的技術(shù)系統(tǒng)越來越成為社會的基礎(chǔ)設(shè)施，對于這些系統(tǒng)的可靠性要求也就越來越高。但是實際上很多的基礎(chǔ)的產(chǎn)品和系統(tǒng)確仍然會出現(xiàn)一些穩(wěn)定性問題，那么如何才能構(gòu)建可靠的系統(tǒng)呢？是不是制定非常嚴格而細致的規(guī)則就可以做出可靠的系統(tǒng)呢？

航空業(yè)的教訓

在回答這個問題之前，我們先來看看對于系統(tǒng)可靠性要求非常高的航空業(yè)是怎么做的？美國的FAA是在航空安全領(lǐng)域事實上的權(quán)威，為了保證航空器的安全，F(xiàn)AA制訂了非常詳細而復雜的航空器認證規(guī)則，而這些規(guī)則是否就保證了航空器的安全了呢？

讓我們來了解一下最近的兩起空難：

2019年3月10日，埃塞俄比亞航空ET302航班在起飛六分鐘后墜毀，飛機上載有149名乘客和8名機組人員。

2018年10月29日，印尼獅航JT610航班在起飛后約十分鐘墜毀，飛機上載有181名乘客，和8名機組人員。

幾百條鮮活生命的消逝，這是多么嚴重的后果??！究竟是什么原因?qū)е铝诉@樣的災難呢？

這兩起空難的共同點是都是波音的737MAX機型，并且都是在起飛后不久發(fā)生的空難。那么這個背后的原因是什么呢？雖然官方的調(diào)查還沒有結(jié)束，但是民間的分析指向了同一個原因，那就是這款機型的設(shè)計問題。

上圖展示了Boeing 737 MAX的CFM LEAP引擎，值得注意的是和一般民航飛機不同的是，引擎的上沿和機翼平面幾乎齊平。為什么會這么設(shè)計呢？這是因為波音737系列最早是上世紀60年代設(shè)計的，當時的引擎的直徑小很多，外形更加細長，而機翼的高度是和引擎直徑相匹配的。但是隨著技術(shù)的發(fā)展，更新更省油的引擎直徑變得越來越大，這時候原來的機翼高度無法滿足更大直徑引擎的安裝空間，要想調(diào)整機翼的高度則需要改變起落架的設(shè)計，改變起落架的設(shè)計則需要改變起落架收起時相關(guān)機體位置的設(shè)計，而機體設(shè)計的變化會帶來更多的變化從而會被FAA認為是一款全新型號的飛機，而全新型號的飛機則需要經(jīng)歷完整的FAA認證流程，會帶來巨大的時間和經(jīng)濟成本。為了避免這樣的成本波音選擇了將引擎前移并且提升高度，但是這樣帶來了另外一個問題，由于空氣動力學方面的原因，飛機會變得靜不穩(wěn)定，特別是在起飛階段，引擎的推力會導致飛機迎角過高進入危險的失速狀態(tài)。為了回避這個問題，波音引入了一個自動控制程序MCAS，通過讀取迎角傳感器的數(shù)據(jù)判斷飛機是否迎角過高，如果過高的話自動控制飛機降低迎角，從而保證飛機的安全。

那么這么一套保證飛行安全的系統(tǒng)和空難有什么關(guān)系呢？事實上MCAS系統(tǒng)工作得非常好，根據(jù)波音自己的統(tǒng)計，Boeing 737 MAX系列已經(jīng)完成了數(shù)十萬次的安全起降。但是問題在于當傳感器工作不正常時，MCAS有可能會根據(jù)錯誤的迎角數(shù)據(jù)做出錯誤的判斷和動作，也就是在不應該降低迎角的時候降低迎角，導致飛機直沖地面。

一起后果擴大的故障

回到我們的工作中，前不久我們碰到了一起系統(tǒng)故障，其過程有一定典型的意義，為了描述方面，這里隱去一些具體細節(jié)，簡單說一下故障的過程。
開始的時候，由于某些原因?qū)е戮彺婷新视兴陆?，而緩存命中率下降導致了?shù)據(jù)庫load升高，而數(shù)據(jù)庫load升高以及可能的慢SQL導致了部分請求在獲取DB connection的時候超時，從而引發(fā)了exception。當exception發(fā)生的時候，為了保證系統(tǒng)的可用性，系統(tǒng)邏輯進入了一段兜底邏輯，而這段兜底邏輯在特定的條件下產(chǎn)生了錯誤的返回，從而導致線上臟數(shù)據(jù)，而這些臟數(shù)據(jù)帶來了業(yè)務資損和大量的人工訂正數(shù)據(jù)的成本。

這個故障處理的過程并不是重點所以不再贅述，我們要問的是為什么一個簡單的exception會導致這么嚴重的后果呢？

兩個事例的共同點

如果我們仔細去觀察上述兩個事例，我們會發(fā)現(xiàn)其中有如下幾個共同點：

為了好的目的而引入了非常簡單的備用邏輯直接保證“效果”

這些備用邏輯在絕大部分情況下都能正常工作

但是在極端情況下這樣的邏輯失效了，并且產(chǎn)生了嚴重的后果

換句話說，系統(tǒng)設(shè)計者在嘗試用非常簡單的邏輯去解決一個實際上復雜的問題，雖然實際上并沒有完全解決問題，但是因為這樣的邏輯能夠通過大量的測試（或者合規(guī)檢查），所以系統(tǒng)設(shè)計者“假定”問題得到了解決，從而放心地應用到了生產(chǎn)環(huán)境。

那么一個非常復雜的問題是否真的能夠通過一個簡單巧妙的辦法解決嗎？

沒有銀彈

在系統(tǒng)設(shè)計領(lǐng)域，我們通常會把問題的復雜性分為兩類，分別是偶得復雜性，實質(zhì)復雜性。

偶得復雜性 Accidental Complexity

所謂偶得復雜性是指由開發(fā)者自己在嘗試解決問題時引入的復雜性挑戰(zhàn)，一般而言是由解決問題的方法和手段帶來的，對于特定的問題，不同的方法會帶來不同的偶得復雜性。

實質(zhì)復雜性 Essential Complexity

所謂實質(zhì)復雜性是由事務本身所決定的，和解決方法無關(guān)。

對于偶得復雜性，通過變換解決辦法是有可能用簡單的辦法來解決的，但是對于實質(zhì)復雜性，我們是無法通過改變手段來解決的，而必須采用相應復雜的方法來解決問題。換句話說對于實質(zhì)復雜的問題，不要指望有銀彈。

上述事例中，實際的環(huán)境和問題是存在比較大的實質(zhì)復雜性的，然而我們卻試圖通過一些非常簡單的邏輯去解決問題，從而帶來了嚴重的后果。

快速失敗 Fail Fast

那么要想防止這類問題，設(shè)計高可靠的系統(tǒng)要怎么做呢？
這里我想介紹一條反直覺的軟件設(shè)計原則，快速失?。‵ail Fast）：

In systems design, a fail-fast system is one which immediately reports at its interface any condition that is likely to indicate a failure.

這是一條反直覺的原則，大部分人聽說這條原則的第一反應是這樣不是讓系統(tǒng)變得更加脆弱了嗎？

實際上并不是，原因在于我們不能停留在某一次的失敗（failure），而是需要觀察完整的過程，如下圖所示：

當問題發(fā)生時，系統(tǒng)立即停止工作，由人工介入找到并以合理的方式解決根本的問題，然后系統(tǒng)恢復運作。通過這樣的選擇，我們就能夠更早更容易地暴露問題，每當系統(tǒng)發(fā)生問題之后，真正的根因會更快得以解決，所以最后我們就能得到一個更加可靠的系統(tǒng)。

需要說明的是，快速失敗不是說系統(tǒng)設(shè)計不處理任何問題到處失敗，而只是在面對essential complexity的時候，不要嘗試用一個簡單粗暴的方案去解決，要么就用一套合理的機制設(shè)計去解決它，要么就fail fast把控制權(quán)交給系統(tǒng)上層決策，通常來說最終可能會回歸到人，由人來分析和處理問題。

根據(jù)實際的工作經(jīng)驗，我還發(fā)現(xiàn)一個有意思的現(xiàn)象，很多系統(tǒng)的設(shè)計者往往高估一些能輕易想到的問題的嚴重性，而低估那些想不到的問題的嚴重性。上述的軟件系統(tǒng)故障的例子中，如果異常往外拋出，問題的后果可能僅僅是某些操作人員的部分操作失敗，用戶可能會重試，也可能會開工單把問題反饋上來。只要我們處理工單的同學及時響應并且解決根本問題，這個問題就不會演變成一個比較嚴重的問題。但是不拋出異常通過備用邏輯來兜底一旦失敗，會導致比較嚴重的后果。如果系統(tǒng)的設(shè)計者能夠認真衡量和計算這些后果的差別，就會做出更加合理的選擇。

當然還有一點就是快速失敗會把更多數(shù)量的問題暴露在用戶面前，讓用戶在心理層面有不好的影響，但是需要注意的是不暴露問題不等于解決問題，暴露問題只是讓大家看到了問題而已。為了更好更早地暴露問題，一方面我們需要引入更完備的測試防止問題進入生產(chǎn)環(huán)境，另外一方面也需要引導系統(tǒng)使用者以更加客觀實際的心態(tài)來接受系統(tǒng)中的問題。

不要重復自己 Don"t Repeat Yourself

和構(gòu)建穩(wěn)定系統(tǒng)相關(guān)的另外一條原則是軟件工程中常說的DRY原則，也就是：

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

這一條和穩(wěn)定系統(tǒng)的關(guān)系在于，通過合理的復用設(shè)計，能夠大幅度提高系統(tǒng)的可測性，降低調(diào)試問題的難度，提高系統(tǒng)的可維護性，背后的邏輯還是比較簡單的，這里不再贅述。

如何實踐上述原則

那么要想實踐上述原則構(gòu)建可靠的系統(tǒng)需要注意哪些方面呢？
結(jié)合自己的工作經(jīng)驗，我認為主要是這么幾個方面：

所有的原則都是有代價的

世界上沒有免費的午餐，借用之前Choice課程老師的一句話，堅持價值觀都是有代價的，我們也可以說
堅持原則都是要付出代價的。
這里的代價包括工作量，短期結(jié)果，解決問題的難度，帶來的項目風險等等，系統(tǒng)的設(shè)計者需要做出合理的權(quán)衡，付出一定的代價才可能應用上述的原則。

刨根問底，5 whys找到根因

當問題發(fā)生時，最重要的事情在于找到問題的根因，只有我們解決了根本的問題，系統(tǒng)才會真正變得健壯起來，否則都只是假象。我們可以用?5 whys?的辦法來找到問題的根本原因。

回歸測試保障

個人認為自動化回歸測試相當于汽車的安全帶，我們需要構(gòu)建覆蓋度高的自動化回歸測試保障體系，從而更早更好地發(fā)現(xiàn)問題，減少對于最終用戶的沖擊，把問題扼殺在萌芽狀態(tài)。

讓團隊養(yǎng)成好的習慣

不管是一個開發(fā)者，還是一個開發(fā)團隊，堅持原則并不是臨時起意，而需要成為習慣。只有把原則變成習慣的個人或者團隊，才能夠真正貫徹這些原則。所以平常工作中某些看起來沒有必要的堅持原則，實際上有助于習慣的養(yǎng)成，而當原則成為了團隊的習慣，這些原則才能在需要的時候得以實踐，獲得回報。

不要把fail fast曲解為快速試錯

可能有人會認為fail fast就是快速試錯，也就是不斷嘗試，碰到正確的為止。需要強調(diào)的是快速失敗需要很好的設(shè)計和機制保證。

后記

以上是我對于構(gòu)建可靠系統(tǒng)的思考與實踐總結(jié)，最近做了一次分享但是感覺沒有講好所以寫下來，歡迎討論和拍磚。

參考文檔

Fail Fast

Software Won"t Fix Boeing"s "Faulty" Airframe

Gregory Travis"s article about Boeing 737 MAX

閱讀原文

本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。