FMEA:總監和架構師都在用的高可用架構分析方法

FMEA:總監和架構師都在用的高可用架構分析方法

記得之前準備春晚項目的時候,團隊成員在一起過架構,老闆最常問的問題是“這個組件掛了怎麼辦?有什麼影響?”,我當時還在心裏默默嘀咕:這咋都這麼容易掛呢?其他組件不做高可用的嗎?最近看到FMEA,我恍然大悟:哦,這原來不就是 FMEA 嗎?原來是我“有眼無珠,識不得真神啊”!

本篇來淺談一下高可用架構、FMEA 以及使用 FMEA 進行架構分析的改進,適合有一定項目經驗的工程師閱讀。

一、高可用架構

1.1 什麼是高可用

當我們談到高可用時,都會說到可用性。那麼,什麼是可用性?我們知道,任何東西都有不可用的時候,比如,法拉利也會有拋錨的時候;身體特別健康的人,也難免會頭疼感冒;即使是地球,也可能會有毀滅的一天;更何況是服務器/線上應用,硬件故障和軟件故障都可能導致不可用。可見,我們沒辦法做到東西的 100%可用性,只能做到高可用(可能無限接近但始終無法到達 100%)。

1.2 高可用的度量

我們如何來量化服務的“高”可用呢?爲了清晰描述高可用,於是就有了SLA(Service-Level Agreement,服務水平協議)的概念。SLA 是服務提供商與客戶之間定義的正式承諾。服務提供商與受服務用戶之間具體達成了承諾的服務指標——質量、可用性、責任。

那麼,SLA 該如何計算呢?

  • 通俗的定義:SLA =可用時長/(可用時長+不可用時長)。

  • 不通俗的定義:SLA =f(MTBF,MTTR)。

  • MTBF(Mean Time Between Failures):平均故障間隔,通俗一點就是一個東西多長時間壞一次。

  • MTTR(Mean Time To Repair or Mean Time To Recovery):平均修復時間,意思是一旦東西壞了,需要多長時間去修復或者恢復它。

可見,提高 SLA 只有兩個方法:一是提高系統的可用時長,二是降低系統的不可用時長。或者說,提高 MTBF,降低 MTTR。

1.3 高可用實現與架構之道

上述的提高高可用的方法只是理論層面的,在工程上其實也有相關的指導思想和架構方法。

當說起高可用實現的時候,浮現在腦海裏的是大約在大學時期讀過的一本自傳。這本自傳的書名記不清了,內容講述的關於李開復的。李開復在做語音識別的時候,需要向別人展示研究成果,但是機器的識別概率只有 80%,達不到目標。那怎麼辦呢?沒有什麼事情是一臺機器不能解決的,如果有,那就再加一臺:一臺機器識別的概率是 80%,那麼不能識別概率是 20%,兩臺機器同時不能識別的概率就是 20% * 20% = 4%,那麼識別的概率就是 96%。這種巧妙的方式讓我最早感受到了概率和高可用的神奇。

畢業工作後,我接觸到了業內五花八門的高可用方案,逐漸發現高可用實現方式其實是萬變不離其宗,不管是計算高可用還是存儲高可用;不管是異地多活、負載均衡、主備架構、主從架構等,本質上都是通過“冗餘”來實現高可用

用通俗點語言來講,就是一臺機器不夠就兩臺,兩臺不夠就四臺;一個機房可能故障斷網斷電,那就部署兩個機房;一條通道可能故障,那就用兩條,兩條不夠那就用三條(移動、電信、聯通一起上)。高可用的“冗餘”解決方案,其實是通過增加機器來“冗餘”處理單元的手段,來達到服務高可用的目的

二、初識 FMEA

當系統實現了一套高可用架構上線之後,從此就可以“高枕無憂”了嗎?其實不然,還需要擇時進行架構分析與改進(畢竟好的架構是演進出來的),FMEA 開始走到舞臺中央了。

2.1 什麼是 FMEA

失效模式與影響分析——FMEA(Failure Mode and Effects Analysis)也稱爲:潛在故障模式和影響分析,故障模式、影響和關鍵性分析 (FMECA),是由美國軍方於 20 世紀 40 年代開始使用的一種過程分析工具,用於識別設計、製造或裝配過程、產品或服務中所有可能的故障。

  • 失敗模式 :指的是某事物可能失敗的方式或模式。故障是指任何可能發生的錯誤或缺陷,可以是潛在的,也可以是實際的。
  • 影響分析 :指的是分析和研究發生失敗(或者故障)的造成的影響和後果。

雖然 FMEA 並不是爲軟件而生,但是同樣可以運用於軟件領域。通俗的來講,FMEA 就是一種分析方法,這種方法可以通過假設某組件故障,然後分析影響的途徑,從而可以及早發現和識別系統問題、更好地規劃後續工作、達到提高系統或者產品的可靠性的目的。

2.2 何時使用 FMEA

上面說的“擇時”,究竟是什麼時候呢?FMEA 可以在這些時候進行:

  • 當設計一個新系統或者重新設計系統架構的時候
  • 當現有系統或服務以新方式應用的時候
  • 當爲現有系統或服務規劃改進目標的時候
  • 在系統建設的整個生命週期中定期進行

三、FMEA 實戰

如何做 FMEA?這個問題應該在軟件領域應該還沒有一個業界認可的標準的流程。我翻閱了資料,找到一些我認爲比較靠譜的流程,在這裏分享一下,大佬可以評論區交流。

3.1 傳統制造流程如何做 FMEA

3.1.1 步驟總覽

典型的 FMEA 其實是一個團隊活動或者團隊會議。在會議上,可以開展以下幾個必要的步驟:

  • 定義失效模式——可能出現什麼樣的錯誤
  • 定義影響——誰(哪個模塊,功能,函數)會遭受牽連
  • 描述目標——出現失效模式會發生什麼樣的事
  • 尋找根因——爲什麼會發生這樣的事
  • 定義策略動作——如何避免
  • 定義當前預防&檢測措施——我們已經(尚未)做的措施
  • 重複開展以上步驟,並輸出到 FMEA 的表格中。

3.1.2 案例

下面是一個源自《Using FMEA to Improve Software Reliability》(鏈接放在文稿末尾,感興趣可自行閱讀)的例子,例子本身要做的事情是使用導熱膠帶將 PCB 板附着到金屬散熱片。對於這個生產流程來說我們應該不用過多瞭解,只需要通過這個例子熟悉下 FMEA 的步驟。

FMDA 表格如下:

翻譯爲中文是:

步驟編號 步驟名稱 失效模式 影響 目標 根因 S O D RPN 應對動作 當前方案
1 用酒精清理金屬片
2 把導熱膠鋪在邊緣
3 清理底座
4 用力按壓散熱片,使之貼到導熱膠帶上
5 用酒精清洗導熱槽
6 把 LED 燈帶放置在散熱片上,施重壓在燈帶外的區域
  1. 定義失效模式;

    可能的失效:金屬片可能沒有清理乾淨。

  2. 定義影響;

    直接結果:鋪上的導熱膠沒有完全黏着,導致熱膠路徑開裂,從而導致 PCB 過熱或直接整塊脫落。

  3. 描述目標;

    影響: 導熱膠沒有黏着,導熱路徑脫離,PCB 過熱
    誰會受到影響:過熱通常需要期間承受一定的壓力纔會出現,生產測試中可能發現不了;很有可能將該缺陷帶給客戶。

  4. 尋找根因;

    根因: 存在酒精無法溶解的污染物。 根因: 操作錯誤

  5. 列出風險的優先級;

    就是把失效模式和風險的優先級聯繫起來。每個失效被賦值爲 1-10 之間的三個指標。

  • 嚴重程度(S):1(無關緊要)到 10(災難性)
  • 出現的可能性(O): 1 ( 不可能 ) 到 10(不可避免)
  • 可檢測性(D):1(肯定能被檢測) 到 10(不可檢測)

這三個數乘起來就是 風險優先級參數(RPN)。RPN 越大,改善的必要性就越高。
S x O x D = RPN

影響: 導熱膠帶沒有完全黏住,導熱路徑脫離,PCB 過熱。

嚴重程度 6 縮短 PCB 組件壽命
可能性 2 經過恰當的訓練,這不太可能發生
可檢測性 3 在生產過程中很容易被檢測

RPN: 6 x 2 x 3 = 36

  1. 定義解決方案;

    失效模式:金屬薄片沒有清除乾淨。
    解決動作:操作員及時賦能培訓清理技巧。

  2. 描述當前預防和檢測方法;

    失效模式:金屬薄片沒有清除乾淨。
    當前方法:在產線上崗之前對操作員進行培訓、在生產中展示工作指南。

  3. 重複重複再重複;

    重複步驟 1-7,得到一個完整的表格。我們篩選出最有價值的措施來做系統設計和改造工作。

3.2 軟件如何做 FMEA

3.2.1 簡化的 FMEA

按照 FMEA 理論,FMEA 分析需要通過一次或多次會議完成,參與人應該包括:系統 Owner、項目 Leader、領域專家(架構師)參加、相關開發、測試等人員。當然這樣效果肯定是最好的,實際情況可能無法在同一時間召集大家都來參加會議。特別是在“降本增笑,開猿節流”的大背景下,我們日常的工作肯定是更捲了,時間變得更寶貴了。我根據日常工作經驗,結合 FMEA 核心思想和分析流程,總結出一個簡化版的流程和表格,供大家參考。自己在架構 Review 或者設計過程中可以先問自己幾個問題:

  1. 系統中的組件可能發生故障嗎?
  2. 如果發生了故障,有什麼影響?
  3. 故障發生的可能性有多大?影響是否嚴重?(可以使用 RPN 進行量化)
  4. 當前的解決方案或者預案是什麼?是立即優化還是排期後續優化?

3.2.2 案例

下面是一個簡單的例子來模擬一次 FMEA 分析。假設這是一個博客管理系統,具有最基礎的登錄註冊功能、發佈和查看博客等功能。其系統架構如圖:

下表是我分析的樣例,僅供參考。

序號 功能模塊 失效模式 故障影響 根本原因 風險等級評估(可使用 RPN 方式進行評估) 當前已有解決方案或預案 短期方案 長期方案
1 用戶登錄 MySQL 數據庫無法訪問 用戶無法登錄,頁面提示“系統異常” 數據庫服務器宕機 完善監控,若發現宕機聯繫 DBA 進行處理;補充備庫 故障時自動進行主備切換
2 用戶登錄 MySQL 數據庫響應時間達到 3s 用戶登錄體驗受影響 數據庫慢查詢 定期掃描慢查詢,進行治理 分庫分表等數據治理方案
3

四、總結

本文講述了高可用架構和一個能夠發現架構中隱藏高可用問題的方法:失效模式與影響分析(FMEA),通過硬件和軟件領域的兩個案例實戰了一波 FMEA,給出我心中的簡版的 FMEA,這其實就是我理解的 FMEA 的核心思想,希望對大家有幫助,之後工作和項目中也可以嘗試使用一下。

參考文獻

Using FMEA to Improve Software Reliability

一起學習

這裏是 James Shangguan,歡迎私信或者微信交流,在 2024 年裏面,我們一起提高認知。也歡迎大家關注我的公衆號或博客園,點贊、留言、轉發。你的支持,將是我更文的最大動力!

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章