FMEA方法，排除架構可用性隱患的利器

我在前面的專欄分析高可用複雜度的時候提出了一個問題：高可用和高性能哪一個更復雜，大部分同窗都分析出了正確的答案：高可用更復雜一些，主要緣由在於異常的場景不少，只要有一個場景遺漏，架構設計就存在可用性隱患，而根據墨菲定律「可能出錯的事情最終都會出錯」，架構隱患總有一天會致使系統故障。所以，咱們在進行架構設計的時候必須全面分析系統的可用性，那麼如何才能作到「全面」呢？

我今天介紹的FMEA 方法，就是保證咱們作到全面分析的一個很是簡單可是很是有效的方法。

FMEA 介紹

FMEA（Failure mode and effects analysis，故障模式與影響分析）又稱爲失效模式與後果分析、失效模式與效應分析、故障模式與後果分析等，專欄採用「故障模式與影響分析」，由於這個中文翻譯更加符合可用性的語境。FMEA 是一種在各行各業都有普遍應用的可用性分析方法，經過對系統範圍內潛在的故障模式加以分析，並按照嚴重程度進行分類，以肯定失效對於系統的最終影響。

FMEA 最先是在美國軍方開始應用的，20 世紀 40 年代後期，美國空軍正式採用了 FMEA。儘管最初是在軍事領域創建的方法，但 FMEA 方法如今已普遍應用於各類各樣的行業，包括半導體加工、餐飲服務、塑料製造、軟件及醫療保健行業。FMEA 之因此可以在這些差別很大的領域都獲得應用，根本緣由在於 FMEA 是一套分析和思考的方法，而不是某個領域的技能或者工具。

回到軟件架構設計領域，FMEA 並不能指導咱們如何作架構設計，而是當咱們設計出一個架構後，再使用 FMEA 對這個架構進行分析，看看架構是否還存在某些可用性的隱患。

FMEA 方法

在架構設計領域，FMEA 的具體分析方法是：

• 給出初始的架構設計圖。

• 假設架構中某個部件發生故障。

• 分析此故障對系統功能形成的影響。

• 根據分析結果，判斷架構是否須要進行優化。

FMEA 分析的方法其實很簡單，就是一個 FMEA 分析表，常見的 FMEA 分析表格包含下面部分。

1.功能點

當前的 FMEA 分析涉及的功能點，注意這裏的「功能點」指的是從用戶角度來看的，而不是從系統各個模塊功能點劃分來看的。例如，對於一個用戶管理系統，使用 FMEA 分析時 「登陸」「註冊」纔是功能點，而用戶管理系統中的數據庫存儲功能、Redis 緩存功能不能做爲 FMEA 分析的功能點。

2.故障模式

故障模式指的是系統會出現什麼樣的故障，包括故障點和故障形式。須要特別注意的是，這裏的故障模式並不須要給出真正的故障緣由，咱們只須要假設出現某種故障現象便可，例如 MySQL 響應時間達到 3 秒。形成 MySQL 響應時間達到 3 秒可能的緣由不少：磁盤壞道、慢查詢、服務器到 MySQL 的鏈接網絡故障、MySQL bug 等，咱們並不須要在故障模式中一一列出來，而是在後面的「故障緣由」一節中列出來。由於在實際應用過程當中，無論哪一種緣由，只要現象是同樣的，對業務的影響就是同樣的。

此外，故障模式的描述要儘可能精確，多使用量化描述，避免使用泛化的描述。例如，推薦使用「MySQL 響應時間達到 3 秒」，而不是「MySQL 響應慢」。

3.故障影響

當發生故障模式中描述的故障時，功能點具體會受到什麼影響。常見的影響有：功能點偶爾不可用、功能點徹底不可用、部分用戶功能點不可用、功能點響應緩慢、功能點出錯等。

故障影響也須要儘可能準確描述。例如，推薦使用「20% 的用戶沒法登陸」，而不是「大部分用戶沒法登陸」。要注意這裏的數字不須要徹底精確，好比 21.25% 這樣的數據實際上是沒有必要的，咱們只須要預估影響是 20% 仍是 40%。

4.嚴重程度

嚴重程度指站在業務的角度故障的影響程度，通常分爲「致命 / 高 / 中 / 低 / 無」五個檔次。嚴重程度按照這個公式進行評估：嚴重程度 = 功能點重要程度 × 故障影響範圍 × 功能點受損程度。一樣以用戶管理系統爲例：登陸功能比修改用戶資料要重要得多，80% 的用戶比 20% 的用戶範圍更大，徹底沒法登陸比登陸緩慢要更嚴重。所以咱們能夠得出以下故障模式的嚴重程度。

• 致命：超過 70% 用戶沒法登陸。

• 高：超過 30% 的用戶沒法登陸。

• 中：全部用戶登陸時間超過 5 秒。

• 低：10% 的用戶登陸時間超過 5 秒。

• 中：全部用戶都沒法修改資料。

• 低：20% 的用戶沒法修改頭像。

對於某個故障的影響到底屬於哪一個檔次，有時會出現一些爭議。例如，「全部用戶都沒法修改資料」，有的人認爲是高，有的人可能認爲是中，這個沒有絕對標準，通常建議相關人員討論肯定便可。也不建議花費太多時間爭論，爭執不下時架構師裁定便可。

5.故障緣由

「故障模式」中只描述了故障的現象，並無單獨列出故障緣由。主要緣由在於無論什麼故障緣由，故障現象相同，對功能點的影響就相同。那爲什麼這裏還要單獨將故障緣由列出來呢？主要緣由有這幾個：

• 不一樣的故障緣由發生機率不相同

例如，致使 MySQL 查詢響應慢的緣由多是 MySQL bug，也多是沒有索引。很明顯「MySQL bug」的機率要遠遠低於「沒有索引」；而不一樣的機率又會影響咱們具體如何應對這個故障。

• 不一樣的故障緣由檢測手段不同

例如，磁盤壞道致使 MySQL 響應慢，那咱們須要增長機器的磁盤壞道檢查，這個檢查極可能不是當前系統自己去作，而是另外運維專門的系統；若是是慢查詢致使 MySQL 慢，那咱們只須要配置 MySQL 的慢查詢日誌便可。

• 不一樣的故障緣由的處理措施不同

例如，若是是 MySQL bug，咱們的應對措施只能是升級 MySQL 版本；若是是沒有索引，咱們的應對措施就是增長索引。

6.故障機率

這裏的機率就是指某個具體故障緣由發生的機率。例如，磁盤壞道的機率、MySQL bug 的機率、沒有索引的機率。通常分爲「高 / 中 / 低」三檔便可，具體評估的時候須要有如下幾點須要重點關注。

• 硬件

硬件隨着使用時間推移，故障機率會愈來愈高。例如，新的硬盤壞道概率很低，但使用了 3 年的硬盤，壞道概率就會高不少。

• 開源系統

成熟的開源系統 bug 率低，剛發佈的開源系統 bug 率相比會高一些；本身已經有使用經驗的開源系統 bug 率會低，剛開始嘗試使用的開源系統 bug 率會高。

• 自研系統

和開源系統相似，成熟的自研系統故障機率會低，而新開發的系統故障機率會高。

高中低是相對的，只是爲了肯定優先級以決定後續的資源投入，沒有必要絕對量化，由於絕對量化是須要成本的，並且不少時候都無法量化。例如，XX 開源系統是 3 個月故障一次，仍是 6 個月才故障一次，是沒法評估的。

7.風險程度

風險程度就是綜合嚴重程度和故障機率來一塊兒判斷某個故障的最終等級，風險程度 = 嚴重程度 × 故障機率。所以可能出現某個故障影響很是嚴重，但其機率很低，最終來看風險程度就低。「某個機房業務癱瘓」對業務影響是致命的，但若是故障緣由是「地震」，那幾率就很低。例如，廣州的地震機率就很低，5 級以上地震的 20 世紀才 1 次（1940 年）；若是故障的緣由是「機房空調燒壞」，則機率就比地震高不少了，多是 2 年 1 次；若是故障的緣由是「系統所在機架掉電」，這個機率比機房空調又要高了，多是 1 年 1 次。一樣的故障影響，不一樣的故障緣由有不一樣的機率，最終獲得的風險級別就是不一樣的。

8.已有措施

針對具體的故障緣由，系統如今是否提供了某些措施來應對，包括：檢測告警、容錯、自恢復等。

• 檢測告警

最簡單的措施就是檢測故障，而後告警，系統本身不針對故障進行處理，須要人工干預。

• 容錯

檢測到故障後，系統可以經過備份手段應對。例如，MySQL 主備機，當業務服務器檢測到主機沒法鏈接後，自動鏈接備機讀取數據。

• 自恢復

檢測到故障後，系統可以本身恢復。例如，Hadoop 檢測到某臺機器故障後，可以將存儲在這臺機器的副本從新分配到其餘機器。固然，這裏的恢復主要仍是指「業務」上的恢復，通常不太可能將真正的故障恢復。例如，Hadoop 不可能將產生了磁盤壞道的磁盤修復成沒有壞道的磁盤。

9.規避措施

規避措施指爲了下降故障發生機率而作的一些事情，能夠是技術手段，也能夠是管理手段。例如：

• 技術手段：爲了不新引入的 MongoDB 丟失數據，在 MySQL 中冗餘一份。

• 管理手段：爲了下降磁盤壞道的機率，強制統一更換服務時間超過 2 年的磁盤。

10.解決措施

解決措施指爲了可以解決問題而作的一些事情，通常都是技術手段。例如：

• 爲了解決密碼暴力破解，增長密碼重試次數限制。

• 爲了解決拖庫致使數據泄露，將數據庫中的敏感數據加密保存。

• 爲了解決非法訪問，增長白名單控制。

通常來講，若是某個故障既能夠採起規避措施，又能夠採起解決措施，那麼咱們會優先選擇解決措施，畢竟能解決問題固然是最好的。但不少時候有些問題是系統本身沒法解決的，例如磁盤壞道、開源系統 bug，這類故障只能採起規避措施；系統可以本身解決的故障，大部分是和系統自己功能相關的。

11.後續規劃

綜合前面的分析，就能夠看出哪些故障咱們目前還缺少對應的措施，哪些已有措施還不夠，針對這些不足的地方，再結合風險程度進行排序，給出後續的改進規劃。這些規劃既能夠是技術手段，也能夠是管理手段；能夠是規避措施，也能夠是解決措施。同時須要考慮資源的投入狀況，優先將風險程度高的系統隱患解決。

例如：

• 地震致使機房業務中斷：這個故障模式就沒法解決，只能經過備份中心規避，儘可能減小影響；而機櫃斷電致使機房業務中斷：能夠經過將業務機器分散在不一樣機櫃來規避。

• 敏感數據泄露：這個故障模式能夠經過數據庫加密的技術手段來解決。

• MongoDB 斷電丟數據：這個故障模式能夠經過將數據冗餘一份在 MySQL 中，在故障狀況下重建數據來規避影響。

FMEA 實戰

下面我以一個簡單的樣例來模擬一次 FMEA 分析。假設咱們設計一個最簡單的用戶管理系統，包含登陸和註冊兩個功能，其初始架構是：



初始架構很簡單：MySQL 負責存儲，Memcache（如下簡稱 MC）負責緩存，Server 負責業務處理。咱們來看看這個架構經過 FMEA 分析後，可以有什麼樣的發現，下表是分析的樣例（注意，這個樣例並不完整，感興趣的同窗能夠自行嘗試將這個案例補充完整）。

通過上表的 FMEA 分析，將「後續規劃」列的內容彙總一下，咱們最終獲得了下面幾條須要改進的措施：

• MySQL 增長備機。

• MC 從單機擴展爲集羣。

• MySQL 雙網卡鏈接。

改進後的架構以下：



小結

今天我爲你講了 FMEA 高可用分析方法，而且給出了一個簡單的案例描述如何操做。FMEA 是高可用架構設計的一個很是有用的方法，可以發現架構中隱藏的高可用問題，但願對你有所幫助。

這就是今天的所有內容，留一道思考題給你吧，請使用 FMEA 方法分析一下 HDFS 系統的架構，看看 HDFS 是如何應對各類故障的，而且分析一下 HDFS 是否存在高可用問題。