第9章 軟件可靠性基礎知識 — 系統架構設計師學習筆記 本章是架構設計師考試的最核心章節沒有之一。幾乎每年必考選擇題案例分析題且分值占比極高。可靠性是衡量軟件系統能不能穩定運行的根本指標可靠性設計容錯、冗余、串并聯模型是案例分析題的常駐嘉賓。學完本章你需要能計算系統可靠性、設計容錯方案、分析故障樹、選擇可靠性策略。一、章節概覽1.1 本章地位與核心目標如果把軟件架構比作一棟大樓那可靠性就是這棟大樓的抗震等級。第8章講了什么樣的樓是好樓質量屬性第9章則講怎么讓樓不塌可靠性工程。本章是從理論到實踐的關鍵落地章節直接決定了你在案例分析題中能否拿到高分。本章圍繞四個核心問題展開什么是可靠性→ 可靠性的定義、核心指標MTTF/MTBF/MTTR怎么算可靠性→ 串聯、并聯、混聯系統的可靠性計算怎么設計可靠性→ 容錯設計、冗余策略、N版本程序、恢復塊怎么分析故障→ 故障樹分析FTA、可靠性框圖1.2 知識思維導圖第9章 軟件可靠性基礎知識 ├── 9.1 可靠性基本概念 │ ├── 可靠性的定義 │ ├── 可靠性的四個要素 │ ├── 失效Failure、故障Fault、錯誤Error │ └── 可靠性與可用性、健壯性的關系 ├── 9.2 可靠性指標與度量 │ ├── 失效率 λ(t) │ ├── 可靠度 R(t) │ ├── MTTF平均無故障時間 │ ├── MTTR平均修復時間 │ ├── MTBF平均故障間隔時間 │ └── 可用性 A ├── 9.3 系統可靠性模型★★★ 計算必考 │ ├── 串聯模型 │ ├── 并聯模型 │ ├── 混聯模型串并聯組合 │ ├── N模冗余NMR │ └── 表決系統k/n系統 ├── 9.4 軟件可靠性設計★★★ 案例必考 │ ├── 容錯設計 │ │ ├── 冗余設計硬件冗余、軟件冗余、信息冗余、時間冗余 │ │ ├── N版本程序設計NVP │ │ ├── 恢復塊設計RB │ │ └── 防衛式程序設計 │ ├── 故障檢測 │ │ ├── 心跳檢測 │ │ ├── 校驗機制 │ │ └── 異常監控 │ └── 故障恢復 │ ├── 重試機制 │ ├── 回滾機制 │ └── 降級策略 ├── 9.5 故障樹分析FTA │ ├── 故障樹的基本符號 │ ├── 與門、或門 │ ├── 最小割集 │ └── 故障樹定性/定量分析 └── 9.6 可靠性測試與評估 ├── 可靠性測試類型 ├── 可靠性增長模型 └── 可靠性評估方法二、核心知識點精講9.1 可靠性基本概念★ 基礎必背9.1.1 可靠性的定義概念定義軟件系統在規定條件和規定時間內無故障地執行指定功能的概率。通俗解釋就像買燈泡——商家說正常使用平均能用5000小時。這里的正常使用就是規定條件5000小時就是規定時間不壞的概率就是可靠性。可靠性的四個關鍵要素缺一不可要素含義舉例規定條件使用環境、負載、操作方式溫度40°C、并發1000規定時間運行的時間長度連續運行72小時規定功能系統應該完成的功能訂單處理、支付結算概率無故障的可能性0~1之間R(72h) 0.99??考點可靠性是一個概率值不是能或不能的絕對概念。R(t) 越接近1可靠性越高。9.1.2 失效、故障、錯誤的區別通俗解釋用人生病來類比——概念英文定義類比舉例錯誤ErrorError人的操作失誤或代碼編寫錯誤寫錯代碼的bug程序員寫了死循環故障FaultFault系統中存在的缺陷/隱患身體里的病毒代碼中存在空指針隱患失效FailureFailure系統不能執行規定功能病倒了系統崩潰/輸出錯誤結果三者關系鏈錯誤Error→ 故障Fault→ 失效Failure 原因 隱患 結果一句話記憶錯誤是因寫錯了故障是病有隱患了失效是果系統掛了。??易混淆點有故障不一定立即失效像體內有病毒但還沒發病但失效一定是由故障引起的。9.1.3 可靠性與相關概念的關系概念關注點核心問題類比可靠性Reliability持續運行不中斷能跑多久不出問題不生病可用性Availability需要時能用需要時能不能用病了能快速好健壯性Robustness異常情況下不崩潰遇到意外扛不扛得住抵抗力強不強安全性Safety故障時不造成危害出了問題傷不傷人摔倒了會不會骨折關鍵區別可靠性 vs 可用性可靠性關注不壞可用性關注壞了能快速修好可靠性 vs 健壯性可靠性關注正常情況穩定運行健壯性關注異常情況不崩潰通俗理解可靠性高 從來不感冒可用性高 感冒了吃顆藥第二天就好健壯性高 淋了雨也不會感冒9.2 可靠性指標與度量★★★ 計算必考9.2.1 核心指標一覽指標英文定義公式越大/越小越好失效率λ(t)單位時間內發生故障的概率λ 故障次數/總運行時間越小越好可靠度R(t)在時間t內無故障的概率R(t) e^(-λt)越大越好MTTFMean Time To Failure平均無故障時間MTTF 1/λ越大越好MTTRMean Time To Repair平均修復時間MTTR 總修復時間/故障次數越小越好MTBFMean Time Between Failures平均故障間隔時間MTBF MTTF MTTR越大越好可用性A (Availability)系統可用時間的比例A MTTF/(MTTFMTTR)越大越好9.2.2 指標詳解與計算1失效率 λ(t)通俗解釋就像燈泡的壞燈率——1000個燈泡跑了100小時壞了5個失效率 5/(1000×100) 0.00005/小時。失效率的三個階段浴盆曲線失效率 λ(t) ↑ │ ╲ ╱ │ ╲ ╱ ← 耗損期老化失效率上升 │ ╲ ╱ │ ￣￣￣￣ ← 偶然期穩定失效率恒定 │ ╱ │ ╱ ← 早期故障期磨合失效率下降 │ ╱ └──────────────→ 時間 t階段特點原因應對策略早期故障期失效率高逐漸下降設計/制造缺陷老化測試、燒機測試偶然故障期失效率低且恒定隨機因素冗余設計、容錯機制耗損故障期失效率急劇上升老化磨損預防性維護、定期更換記憶技巧浴盆曲線就像U形——早高、中穩、晚升像一個浴缸的橫截面。2可靠度 R(t)核心公式R(t)e?λtR(t) e^{-\lambda t}R(t)e?λt通俗解釋如果失效率 λ 0.01/小時運行10小時后的可靠度 e^(-0.01×10) e^(-0.1) ≈ 0.905即有90.5%的概率不出故障。3MTTF、MTTR、MTBF 的關系|←—— MTTF ——→|←— MTTR —→|←—— MTTF ——→|←— MTTR —→| | 正常運行 | 故障修復 | 正常運行 | 故障修復 | |←———————— MTBF ——————————→|關鍵公式MTBF MTTF MTTR可用性 A MTTF / (MTTF MTTR) MTTF / MTBF??高頻考點幾乎每年必考計算串行系統MTTF 1/(λ? λ? … λ?)并聯系統兩臺MTTF 1/λ? 1/λ? 1/(λ?λ?)不要求記理解原理即可4可用性等級速查等級可用性年停機時間典型系統99%99%3.65天普通內部系統99.9%99.9%8.76小時企業級應用99.99%99.99%52.6分鐘金融交易系統99.999%99.999%5.26分鐘電信核心系統9.3 系統可靠性模型★★★ 計算核心這是本章最重要的計算部分幾乎每年必考9.3.1 串聯系統概念定義系統中所有組件必須全部正常工作系統才能工作。任何一個組件故障系統就故障。通俗解釋就像一串鞭炮——任何一個響了壞了整串就斷了。又像老式圣誕燈串一個燈泡壞了全滅。可靠性計算R_串聯 R? × R? × R? × ... × R?特點串聯組件越多系統可靠性越低系統的可靠性低于任何一個組件的可靠性“最弱環節決定整體”——木桶效應舉例3個組件串聯可靠度分別為0.99、0.98、0.97R 0.99 × 0.98 × 0.97 0.9411→ 系統可靠性只有94.11%比最低的0.97還低9.3.2 并聯系統概念定義系統中只要有一個組件正常工作系統就能工作。所有組件都故障系統才故障。通俗解釋就像多個保安守門——只要有一個保安醒著正常門就有人守。所有保安都睡著了才出事。可靠性計算R_并聯 1 - (1-R?) × (1-R?) × (1-R?) × ... × (1-R?)特點并聯組件越多系統可靠性越高系統的可靠性高于任何一個組件的可靠性“人多力量大”——冗余帶來可靠性提升舉例2個組件并聯可靠度分別為0.9、0.8R 1 - (1-0.9) × (1-0.8) 1 - 0.1 × 0.2 1 - 0.02 0.98→ 系統可靠性98%比任何一個組件都高9.3.3 混聯系統串并聯組合概念定義系統中既有串聯部分又有并聯部分的組合。通俗解釋就像電路——有的燈串聯有的燈并聯組合在一起。計算方法先算并聯再算串聯分步化簡典型例題結構┌── R? ──┐ ──┤ ├── R? ── R? ── └── R? ──┘ 分析R?和R?并聯再與R?、R?、R?串聯 步驟 ① 先算并聯部分R?? 1 - (1-R?)(1-R?) ② 再算串聯R R? × R?? × R? × R???計算口訣“先并后串逐步化簡”——先把并聯部分合成一個等效組件再按串聯計算。9.3.4 N模冗余系統NMR概念定義N個模塊同時運行通過投票機制選出多數一致的結果作為輸出。通俗解釋就像三人裁判——3個裁判同時打分2個說好就算好1個說好不算。典型形式三模冗余TMR3個模塊2個一致即正確最常用五模冗余5MR5個模塊3個一致即正確可靠性計算以TMR為例3個相同模塊R_TMR 3R2 - 2R3 當各模塊可靠度相同時理解TMR中只要2個或以上模塊正確系統就正確。3個都對C(3,3)×R3 R32個對1個錯C(3,2)×R2×(1-R) 3R2(1-R)合計R3 3R2(1-R) 3R2 - 2R39.3.5 表決系統k/n系統概念定義n個模塊中至少k個正常工作系統才正常。通俗解釋就像班級投票——全班50人n50至少26人同意k26才能通過決議。可靠性計算各模塊可靠度相同為R時R_系統 Σ C(n,i) × R? × (1-R)^(n-i) i從k到n求和??考點串聯 n/n表決全部都要工作并聯 1/n表決至少1個工作。可靠性模型對比總結表模型條件計算公式特點生活類比串聯全部正常才工作R R?×R?×…×R?越多越不可靠一串鞭炮并聯至少1個正常就工作R 1-(1-R?)(1-R?)…(1-R?)越多越可靠多個保安混聯組合結構先并后串逐步化簡需要分析結構復雜電路N模冗余多數表決3R2-2R3TMR容錯性強三人裁判k/n表決至少k個正常二項式求和通用模型投票決議9.4 軟件可靠性設計★★★ 案例核心9.4.1 容錯設計概念定義系統在部分組件發生故障時仍能繼續正常運行或安全降級的能力。通俗解釋就像飛機有雙引擎——一個引擎壞了另一個還能飛不會墜機。四種冗余策略對比冗余類型含義實現方式優點缺點類比硬件冗余增加備用硬件雙機熱備、RAID磁盤物理層面保障成本高備胎輪胎軟件冗余多版本軟件并行N版本程序設計、恢復塊避免設計缺陷開發成本翻倍多人獨立翻譯同一本書信息冗余增加校驗信息校驗碼、CRC、奇偶校驗檢測數據錯誤占用額外存儲/帶寬快遞包裹加防震泡沫時間冗余重復執行操作重試機制、定時重發應對瞬時故障增加響應時間打電話斷了重新打N版本程序設計NVP—— 軟件冗余的核心方法概念定義由N個獨立團隊用不同的方法對同一需求分別編程實現運行時通過投票機制決定最終輸出。通俗解釋就像高考作文閱卷——3位老師獨立打分2位以上給的分一致才算最終分數。避免一個老師看走眼。工作流程┌── 版本1 ──→ 結果1 ──┐ 輸入 ──→ 需求規格 ──┼── 版本2 ──→ 結果2 ──┼──→ 投票器 ──→ 最終輸出 └── 版本3 ──→ 結果3 ──┘關鍵要點N個版本必須獨立開發不同團隊、不同方法目的是消除設計缺陷導致的共性錯誤投票器負責多數表決所有版本同時運行??考點NVP的所有版本是同時運行的不是輪流運行。恢復塊設計RB—— 另一種軟件冗余概念定義由一個團隊編寫多個版本運行時按順序執行每個版本執行后由驗收測試判斷結果是否正確不正確則切換到下一個版本。通俗解釋就像考試做題——先做第一種解法檢查發現不對驗收測試再換第二種解法再不對換第三種。工作流程輸入 → 版本1 → 驗收測試 → 通過→ 是 → 輸出 ↓ 否 版本2 → 驗收測試 → 通過→ 是 → 輸出 ↓ 否 版本3 → ...關鍵要點多個版本由同一團隊開發不同于NVP版本依次執行不同于NVP的同時運行每個版本后必須有驗收測試需要能回滾狀態恢復到現場NVP vs RB 對比高頻考點對比維度N版本程序設計NVP恢復塊設計RB開發團隊N個獨立團隊同一團隊運行方式同時運行依次運行決策機制投票表決驗收測試版本要求不同方法/算法不同實現即可狀態恢復不需要需要回滾開發成本高多人同時開發較低同一團隊運行開銷高同時運行N個較低只運行到通過為止適用場景安全性要求極高的系統一般容錯系統一句話記憶NVP 多人同時做投票選答案像高考閱卷RB 一個人輪流做做對就交卷像考試換解法防衛式程序設計概念定義在程序中對所有輸入進行合法性檢查對異常情況做出預防性處理即使部分功能失效也不影響整體。通俗解釋就像電梯——即使有人按了不存在的樓層非法輸入電梯不會崩潰而是忽略或提示錯誤。核心思想不信任任何外部輸入對所有輸入做校驗異常情況有兜底處理失敗時優雅降級不崩潰9.4.2 故障檢測機制檢測方式原理舉例適用場景心跳檢測定時發送我還活著信號主備服務器心跳線服務器/進程存活檢測校驗機制對數據做完整性校驗CRC校驗、MD5校驗數據傳輸/存儲完整性異常監控監控系統指標超閾值報警CPU90%報警系統運行狀態監控超時檢測等待響應超時視為故障接口調用超時3秒網絡通信/服務調用9.4.3 故障恢復策略恢復策略原理舉例適用場景重試失敗后重新執行網絡請求失敗重試3次瞬時故障回滾恢復到操作前的狀態數據庫事務回滾事務性操作降級關閉非核心功能保核心雙11關閉評論功能高并發/資源不足熔斷檢測到持續故障后斷開下游服務不可用時熔斷微服務調用鏈切換切換到備用組件主備數據庫切換主備架構記憶技巧重試 電話沒接再打一次回滾 寫錯字了用橡皮擦掉降級 錢不夠了先保吃飯不買衣服熔斷 保險絲燒斷了保護整個電路切換 主力受傷替補上場9.5 故障樹分析FTA★★ 常考概念定義從頂層故障事件出發逐層向下分析原因用邏輯門與門、或門連接形成樹狀圖。通俗解釋就像醫生診斷——“病人發燒了”頂層事件為什么“可能是感染或可能是免疫反應”或門再往下分析感染的原因…基本符號符號名稱含義圖形─ ─ ─與門AND所有輸入事件都發生輸出才發生半圓直線∨或門OR任一輸入事件發生輸出就發生弧線○基本事件最底層的故障原因圓形▽中間事件可繼續分解的故障事件矩形△頂事件分析的頂層故障矩形最上方與門 vs 或門對比與門AND或門OR邏輯A且B → 故障A或B → 故障含義所有條件都滿足才故障任一條件滿足就故障可靠性提高可靠性需要多個同時壞降低可靠性一個壞就完概率計算P P? × P?P 1-(1-P?)(1-P?)類比兩把鎖都打開才能進門任何一把鎖打開就能進門記憶技巧與門 串聯 都壞才壞 可靠性高像兩道門鎖或門 并聯 一個壞就壞 可靠性低像多個隱患任一觸發最小割集概念定義導致頂事件發生的最少基本事件組合。通俗解釋找出最少需要壞幾個零件系統就會出問題的組合。舉例系統故障頂事件 / \ 或門 或門 / \ / \ 事件A 與門 事件D 事件E / \ 事件B 事件C 最小割集{A}, {B,C}, {D}, {E} 含義A單獨壞就故障、B和C同時壞才故障、D單獨壞就故障、E單獨壞就故障??考點最小割集越少、包含的事件越多系統越可靠。單點故障只有一個事件的割集是最危險的9.6 可靠性測試與評估可靠性測試類型測試類型目的方法關注點可靠性驗證測試驗證是否達到可靠性指標在模擬環境下長時間運行是否達標可靠性增長測試發現缺陷并修復提升可靠性測試→修復→測試循環可靠性是否在提升壓力測試在極限條件下測試超負載、大數據量運行系統極限表現故障注入測試模擬故障測試容錯能力人為注入故障容錯和恢復能力可靠性增長模型通俗解釋就像打怪升級——每發現一個bug并修復可靠性就提升一點。可靠性 ↑ │ ╱──── 目標可靠性 │ ╱ │ ╱ │ ╱ ← 可靠性增長曲線 │ ╱ │╱ └──────────────→ 測試時間三、重點歸納 速記口訣3.1 必背要點清單編號要點重要度1可靠性的定義與四要素★★★★2失效-故障-錯誤的因果鏈★★★★3MTTF、MTTR、MTBF的定義與關系★★★★★4可用性計算公式 AMTTF/(MTTFMTTR)★★★★★5串聯系統可靠性計算 RR?×R?×…×R?★★★★★6并聯系統可靠性計算 R1-(1-R?)(1-R?)…★★★★★7混聯系統計算方法先并后串★★★★★8NVP與RB的區別★★★★★9四種冗余策略硬件/軟件/信息/時間★★★★10故障樹中與門、或門的含義★★★★11最小割集的概念★★★12浴盆曲線的三個階段★★★★3.2 速記口訣可靠性三兄弟因果鏈“錯→障→失”錯Error→障Fault→失Failure寫錯了 → 有故障了 →失敗了可靠性指標“失可靠MT三兄弟”失效率λ、可靠度R(t)MTTF無故障時間、MTTR修復時間、MTBF間隔時間MTBF MTTF MTTR串聯 vs 并聯“串聯相乘越來越小并聯互補越來越大”串聯R R?×R? → 越多越不可靠一串鞭炮并聯R 1-(1-R?)(1-R?) → 越多越可靠多個保安NVP vs RB“NVP多人同時投票選RB一人輪流做對交”NVP 高考閱卷多人獨立同時運行投票RB 考試換解法同一人依次運行驗收測試四種冗余“硬軟信時”硬件冗余、軟件冗余、信息冗余、時間冗余聯想“硬軟信時”→ 硬軟件信息時代故障樹“與門串聯都壞才壞或門并聯一壞就壞”浴盆曲線“早高中低晚又高中間穩定最可靠”四、歷年真題 考點映射4.1 近5年真題匯總年份題型分值考點內容2024選擇題2分串聯/并聯系統可靠性計算2024選擇題2分NVP與RB的區別2024案例分析25分給出系統架構要求設計容錯方案計算系統可靠性2023選擇題2分可用性計算MTTF/MTTR2023選擇題2分浴盆曲線三個階段2023案例分析25分故障樹分析求最小割集提出可靠性改進方案2022選擇題2分串聯系統可靠性計算2022選擇題2分冗余策略類型判斷2022案例分析25分混聯系統可靠性計算 容錯設計分析2021選擇題2分MTBF與MTTF的關系2021選擇題2分失效-故障-錯誤的關系2021案例分析25分給出系統可靠性需求設計冗余方案并計算2020選擇題2分并聯系統可靠性計算2020選擇題2分N版本程序設計的特點2020案例分析25分故障樹分析 可靠性分配2019選擇題2分可用性等級2019選擇題2分恢復塊設計的特點2019案例分析25分綜合題可靠性計算 容錯架構設計 故障分析4.2 出題規律分析規律說明必考計算題每年至少1道可靠性計算題串聯/并聯/混聯NVP vs RB 輪流出幾乎每年都考這兩個的區別選擇題或案例填空故障樹分析高頻案例分析中常考畫故障樹、求最小割集可用性計算必考MTTF/MTTR/MTBF的計算幾乎年年考容錯設計是案例核心案例分析題常要求設計容錯方案并說明理由浴盆曲線常出選擇三個階段的特點和應對策略五、典型例題 解析例題1選擇題題目某系統由3個組件組成組件A和B并聯后再與組件C串聯。已知A、B、C的可靠度分別為0.9、0.8、0.95則該系統的可靠度為 。A. 0.684B. 0.931C. 0.722D. 0.855答案B解析第一步計算A和B并聯的可靠度R_AB 1 - (1-0.9) × (1-0.8) 1 - 0.1 × 0.2 1 - 0.02 0.98第二步計算與C串聯的可靠度R R_AB × R_C 0.98 × 0.95 0.931答案選B例題2選擇題題目某系統MTTF為498小時MTTR為2小時則系統可用性約為 MTBF為 。A. 99.6%500小時B. 99.6%498小時C. 99.0%500小時D. 99.0%498小時答案A解析MTBF MTTF MTTR 498 2 500小時可用性 A MTTF / (MTTF MTTR) 498 / 500 0.996 99.6%答案選A例題3案例分析題題目某金融交易系統需要設計高可用架構系統可靠性要求達到99.99%。現有以下組件Web服務器可靠度0.99應用服務器可靠度0.98數據庫服務器可靠度0.97問題如果三個組件串聯系統可靠度是多少是否滿足要求如果不滿足請設計一個冗余方案使其滿足99.99%的要求。請說明NVP和RB在該系統中如何應用并分析哪種更適合。參考答案問題1R_串聯 0.99 × 0.98 × 0.97 0.9411 94.11%94.11% 遠低于 99.99% 的要求不滿足。問題2對每個組件增加一個熱備并聯形成雙機熱備方案Web服務器R_W 1 - (1-0.99)2 1 - 0.0001 0.9999 應用服務器R_A 1 - (1-0.98)2 1 - 0.0004 0.9996 數據庫服務器R_D 1 - (1-0.97)2 1 - 0.0009 0.9991串聯后R 0.9999 × 0.9996 × 0.9991 ≈ 0.9986 99.86%仍不滿足99.99%。需要對數據庫最薄弱環節增加更多冗余數據庫采用3節點1主2從 R_D 1 - (1-0.97)3 1 - 0.000027 0.999973 R 0.9999 × 0.9996 × 0.999973 ≈ 0.9995 ≈ 99.95%繼續優化應用服務器也采用3節點R_A 1 - (1-0.98)3 1 - 0.000008 0.999992 R 0.9999 × 0.999992 × 0.999973 ≈ 0.9999 ≈ 99.99% ?問題3對比維度NVP方案RB方案開發方式3個獨立團隊分別開發支付模塊同一團隊開發3個版本運行方式3個版本同時運行投票決定依次執行驗收通過后輸出適用性更適合本系統需要狀態回滾復雜度高推薦NVP理由金融系統對正確性要求極高NVP的投票機制能發現設計缺陷金融交易涉及資金安全需要多團隊獨立實現以降低共性錯誤風險雖然RB開發成本較低但金融交易的狀態回滾復雜RB實現難度大六、易錯點 避坑指南6.1 常見錯誤一覽錯誤正確理解糾正建議? “串聯越多越可靠”串聯越多越不可靠并聯越多才越可靠記住串聯鞭炮并聯保安? “MTBF MTTF”MTBF MTTF MTTRMTBF是間隔時間包含修復時間? “可用性 MTTR/MTBF”可用性 MTTF/MTBF分子是無故障時間好的時間? “NVP和RB是一樣的”NVP多人同時投票RB一人輪流驗收口訣NVP高考閱卷RB換解法? “故障樹中或門提高可靠性”或門意味著任一事件就故障降低可靠性與門都壞才壞安全或門一壞就壞危險? “有故障就一定會失效”有故障不一定失效像攜帶病毒但未發病錯誤→故障→失效是因果鏈不是等價? “并聯計算是R?×R?”并聯是 1-(1-R?)(1-R?)串聯才是R?×R?先分清串并聯再選公式? “可靠性高可用性高”可靠性高≠可用性高可能不壞但修得慢可靠不生病可用病了快好6.2 計算題答題模板可靠性計算題標準步驟第一步畫出系統可靠性框圖 第二步識別串并聯關系 第三步先算并聯部分 第四步再算串聯部分 第五步得出最終結果與要求對比案例分析題答題模板1. 分析可靠性需求目標值是多少 2. 計算當前可靠性串聯/并聯公式 3. 設計冗余方案對薄弱環節加并聯 4. 重新計算驗證是否達標 5. 說明選擇的容錯策略及理由本章小結本章的核心就是四件事——理解可靠性概念定義指標、會算可靠性串聯/并聯/混聯、會設計容錯方案NVP/RB/冗余策略、會分析故障故障樹最小割集。其中計算題和NVP vs RB是每年必考必須熟練掌握本文基于系統架構設計師考試大綱編寫適合備考復習使用。如有問題歡迎評論區交流討論 第9章 軟件可靠性基礎知識 — 系統架構設計師
第9章 軟件可靠性基礎知識 — 系統架構設計師學習筆記 本章是架構設計師考試的最核心章節沒有之一。幾乎每年必考選擇題案例分析題且分值占比極高。可靠性是衡量軟件系統能不能穩定運行的根本指標可靠性設計容錯、冗余、串并聯模型是案例分析題的常駐嘉賓。學完本章你需要能計算系統可靠性、設計容錯方案、分析故障樹、選擇可靠性策略。一、章節概覽1.1 本章地位與核心目標如果把軟件架構比作一棟大樓那可靠性就是這棟大樓的抗震等級。第8章講了什么樣的樓是好樓質量屬性第9章則講怎么讓樓不塌可靠性工程。本章是從理論到實踐的關鍵落地章節直接決定了你在案例分析題中能否拿到高分。本章圍繞四個核心問題展開什么是可靠性→ 可靠性的定義、核心指標MTTF/MTBF/MTTR怎么算可靠性→ 串聯、并聯、混聯系統的可靠性計算怎么設計可靠性→ 容錯設計、冗余策略、N版本程序、恢復塊怎么分析故障→ 故障樹分析FTA、可靠性框圖1.2 知識思維導圖第9章 軟件可靠性基礎知識 ├── 9.1 可靠性基本概念 │ ├── 可靠性的定義 │ ├── 可靠性的四個要素 │ ├── 失效Failure、故障Fault、錯誤Error │ └── 可靠性與可用性、健壯性的關系 ├── 9.2 可靠性指標與度量 │ ├── 失效率 λ(t) │ ├── 可靠度 R(t) │ ├── MTTF平均無故障時間 │ ├── MTTR平均修復時間 │ ├── MTBF平均故障間隔時間 │ └── 可用性 A ├── 9.3 系統可靠性模型★★★ 計算必考 │ ├── 串聯模型 │ ├── 并聯模型 │ ├── 混聯模型串并聯組合 │ ├── N模冗余NMR │ └── 表決系統k/n系統 ├── 9.4 軟件可靠性設計★★★ 案例必考 │ ├── 容錯設計 │ │ ├── 冗余設計硬件冗余、軟件冗余、信息冗余、時間冗余 │ │ ├── N版本程序設計NVP │ │ ├── 恢復塊設計RB │ │ └── 防衛式程序設計 │ ├── 故障檢測 │ │ ├── 心跳檢測 │ │ ├── 校驗機制 │ │ └── 異常監控 │ └── 故障恢復 │ ├── 重試機制 │ ├── 回滾機制 │ └── 降級策略 ├── 9.5 故障樹分析FTA │ ├── 故障樹的基本符號 │ ├── 與門、或門 │ ├── 最小割集 │ └── 故障樹定性/定量分析 └── 9.6 可靠性測試與評估 ├── 可靠性測試類型 ├── 可靠性增長模型 └── 可靠性評估方法二、核心知識點精講9.1 可靠性基本概念★ 基礎必背9.1.1 可靠性的定義概念定義軟件系統在規定條件和規定時間內無故障地執行指定功能的概率。通俗解釋就像買燈泡——商家說正常使用平均能用5000小時。這里的正常使用就是規定條件5000小時就是規定時間不壞的概率就是可靠性。可靠性的四個關鍵要素缺一不可要素含義舉例規定條件使用環境、負載、操作方式溫度40°C、并發1000規定時間運行的時間長度連續運行72小時規定功能系統應該完成的功能訂單處理、支付結算概率無故障的可能性0~1之間R(72h) 0.99??考點可靠性是一個概率值不是能或不能的絕對概念。R(t) 越接近1可靠性越高。9.1.2 失效、故障、錯誤的區別通俗解釋用人生病來類比——概念英文定義類比舉例錯誤ErrorError人的操作失誤或代碼編寫錯誤寫錯代碼的bug程序員寫了死循環故障FaultFault系統中存在的缺陷/隱患身體里的病毒代碼中存在空指針隱患失效FailureFailure系統不能執行規定功能病倒了系統崩潰/輸出錯誤結果三者關系鏈錯誤Error→ 故障Fault→ 失效Failure 原因 隱患 結果一句話記憶錯誤是因寫錯了故障是病有隱患了失效是果系統掛了。??易混淆點有故障不一定立即失效像體內有病毒但還沒發病但失效一定是由故障引起的。9.1.3 可靠性與相關概念的關系概念關注點核心問題類比可靠性Reliability持續運行不中斷能跑多久不出問題不生病可用性Availability需要時能用需要時能不能用病了能快速好健壯性Robustness異常情況下不崩潰遇到意外扛不扛得住抵抗力強不強安全性Safety故障時不造成危害出了問題傷不傷人摔倒了會不會骨折關鍵區別可靠性 vs 可用性可靠性關注不壞可用性關注壞了能快速修好可靠性 vs 健壯性可靠性關注正常情況穩定運行健壯性關注異常情況不崩潰通俗理解可靠性高 從來不感冒可用性高 感冒了吃顆藥第二天就好健壯性高 淋了雨也不會感冒9.2 可靠性指標與度量★★★ 計算必考9.2.1 核心指標一覽指標英文定義公式越大/越小越好失效率λ(t)單位時間內發生故障的概率λ 故障次數/總運行時間越小越好可靠度R(t)在時間t內無故障的概率R(t) e^(-λt)越大越好MTTFMean Time To Failure平均無故障時間MTTF 1/λ越大越好MTTRMean Time To Repair平均修復時間MTTR 總修復時間/故障次數越小越好MTBFMean Time Between Failures平均故障間隔時間MTBF MTTF MTTR越大越好可用性A (Availability)系統可用時間的比例A MTTF/(MTTFMTTR)越大越好9.2.2 指標詳解與計算1失效率 λ(t)通俗解釋就像燈泡的壞燈率——1000個燈泡跑了100小時壞了5個失效率 5/(1000×100) 0.00005/小時。失效率的三個階段浴盆曲線失效率 λ(t) ↑ │ ╲ ╱ │ ╲ ╱ ← 耗損期老化失效率上升 │ ╲ ╱ │ ￣￣￣￣ ← 偶然期穩定失效率恒定 │ ╱ │ ╱ ← 早期故障期磨合失效率下降 │ ╱ └──────────────→ 時間 t階段特點原因應對策略早期故障期失效率高逐漸下降設計/制造缺陷老化測試、燒機測試偶然故障期失效率低且恒定隨機因素冗余設計、容錯機制耗損故障期失效率急劇上升老化磨損預防性維護、定期更換記憶技巧浴盆曲線就像U形——早高、中穩、晚升像一個浴缸的橫截面。2可靠度 R(t)核心公式R(t)e?λtR(t) e^{-\lambda t}R(t)e?λt通俗解釋如果失效率 λ 0.01/小時運行10小時后的可靠度 e^(-0.01×10) e^(-0.1) ≈ 0.905即有90.5%的概率不出故障。3MTTF、MTTR、MTBF 的關系|←—— MTTF ——→|←— MTTR —→|←—— MTTF ——→|←— MTTR —→| | 正常運行 | 故障修復 | 正常運行 | 故障修復 | |←———————— MTBF ——————————→|關鍵公式MTBF MTTF MTTR可用性 A MTTF / (MTTF MTTR) MTTF / MTBF??高頻考點幾乎每年必考計算串行系統MTTF 1/(λ? λ? … λ?)并聯系統兩臺MTTF 1/λ? 1/λ? 1/(λ?λ?)不要求記理解原理即可4可用性等級速查等級可用性年停機時間典型系統99%99%3.65天普通內部系統99.9%99.9%8.76小時企業級應用99.99%99.99%52.6分鐘金融交易系統99.999%99.999%5.26分鐘電信核心系統9.3 系統可靠性模型★★★ 計算核心這是本章最重要的計算部分幾乎每年必考9.3.1 串聯系統概念定義系統中所有組件必須全部正常工作系統才能工作。任何一個組件故障系統就故障。通俗解釋就像一串鞭炮——任何一個響了壞了整串就斷了。又像老式圣誕燈串一個燈泡壞了全滅。可靠性計算R_串聯 R? × R? × R? × ... × R?特點串聯組件越多系統可靠性越低系統的可靠性低于任何一個組件的可靠性“最弱環節決定整體”——木桶效應舉例3個組件串聯可靠度分別為0.99、0.98、0.97R 0.99 × 0.98 × 0.97 0.9411→ 系統可靠性只有94.11%比最低的0.97還低9.3.2 并聯系統概念定義系統中只要有一個組件正常工作系統就能工作。所有組件都故障系統才故障。通俗解釋就像多個保安守門——只要有一個保安醒著正常門就有人守。所有保安都睡著了才出事。可靠性計算R_并聯 1 - (1-R?) × (1-R?) × (1-R?) × ... × (1-R?)特點并聯組件越多系統可靠性越高系統的可靠性高于任何一個組件的可靠性“人多力量大”——冗余帶來可靠性提升舉例2個組件并聯可靠度分別為0.9、0.8R 1 - (1-0.9) × (1-0.8) 1 - 0.1 × 0.2 1 - 0.02 0.98→ 系統可靠性98%比任何一個組件都高9.3.3 混聯系統串并聯組合概念定義系統中既有串聯部分又有并聯部分的組合。通俗解釋就像電路——有的燈串聯有的燈并聯組合在一起。計算方法先算并聯再算串聯分步化簡典型例題結構┌── R? ──┐ ──┤ ├── R? ── R? ── └── R? ──┘ 分析R?和R?并聯再與R?、R?、R?串聯 步驟 ① 先算并聯部分R?? 1 - (1-R?)(1-R?) ② 再算串聯R R? × R?? × R? × R???計算口訣“先并后串逐步化簡”——先把并聯部分合成一個等效組件再按串聯計算。9.3.4 N模冗余系統NMR概念定義N個模塊同時運行通過投票機制選出多數一致的結果作為輸出。通俗解釋就像三人裁判——3個裁判同時打分2個說好就算好1個說好不算。典型形式三模冗余TMR3個模塊2個一致即正確最常用五模冗余5MR5個模塊3個一致即正確可靠性計算以TMR為例3個相同模塊R_TMR 3R2 - 2R3 當各模塊可靠度相同時理解TMR中只要2個或以上模塊正確系統就正確。3個都對C(3,3)×R3 R32個對1個錯C(3,2)×R2×(1-R) 3R2(1-R)合計R3 3R2(1-R) 3R2 - 2R39.3.5 表決系統k/n系統概念定義n個模塊中至少k個正常工作系統才正常。通俗解釋就像班級投票——全班50人n50至少26人同意k26才能通過決議。可靠性計算各模塊可靠度相同為R時R_系統 Σ C(n,i) × R? × (1-R)^(n-i) i從k到n求和??考點串聯 n/n表決全部都要工作并聯 1/n表決至少1個工作。可靠性模型對比總結表模型條件計算公式特點生活類比串聯全部正常才工作R R?×R?×…×R?越多越不可靠一串鞭炮并聯至少1個正常就工作R 1-(1-R?)(1-R?)…(1-R?)越多越可靠多個保安混聯組合結構先并后串逐步化簡需要分析結構復雜電路N模冗余多數表決3R2-2R3TMR容錯性強三人裁判k/n表決至少k個正常二項式求和通用模型投票決議9.4 軟件可靠性設計★★★ 案例核心9.4.1 容錯設計概念定義系統在部分組件發生故障時仍能繼續正常運行或安全降級的能力。通俗解釋就像飛機有雙引擎——一個引擎壞了另一個還能飛不會墜機。四種冗余策略對比冗余類型含義實現方式優點缺點類比硬件冗余增加備用硬件雙機熱備、RAID磁盤物理層面保障成本高備胎輪胎軟件冗余多版本軟件并行N版本程序設計、恢復塊避免設計缺陷開發成本翻倍多人獨立翻譯同一本書信息冗余增加校驗信息校驗碼、CRC、奇偶校驗檢測數據錯誤占用額外存儲/帶寬快遞包裹加防震泡沫時間冗余重復執行操作重試機制、定時重發應對瞬時故障增加響應時間打電話斷了重新打N版本程序設計NVP—— 軟件冗余的核心方法概念定義由N個獨立團隊用不同的方法對同一需求分別編程實現運行時通過投票機制決定最終輸出。通俗解釋就像高考作文閱卷——3位老師獨立打分2位以上給的分一致才算最終分數。避免一個老師看走眼。工作流程┌── 版本1 ──→ 結果1 ──┐ 輸入 ──→ 需求規格 ──┼── 版本2 ──→ 結果2 ──┼──→ 投票器 ──→ 最終輸出 └── 版本3 ──→ 結果3 ──┘關鍵要點N個版本必須獨立開發不同團隊、不同方法目的是消除設計缺陷導致的共性錯誤投票器負責多數表決所有版本同時運行??考點NVP的所有版本是同時運行的不是輪流運行。恢復塊設計RB—— 另一種軟件冗余概念定義由一個團隊編寫多個版本運行時按順序執行每個版本執行后由驗收測試判斷結果是否正確不正確則切換到下一個版本。通俗解釋就像考試做題——先做第一種解法檢查發現不對驗收測試再換第二種解法再不對換第三種。工作流程輸入 → 版本1 → 驗收測試 → 通過→ 是 → 輸出 ↓ 否 版本2 → 驗收測試 → 通過→ 是 → 輸出 ↓ 否 版本3 → ...關鍵要點多個版本由同一團隊開發不同于NVP版本依次執行不同于NVP的同時運行每個版本后必須有驗收測試需要能回滾狀態恢復到現場NVP vs RB 對比高頻考點對比維度N版本程序設計NVP恢復塊設計RB開發團隊N個獨立團隊同一團隊運行方式同時運行依次運行決策機制投票表決驗收測試版本要求不同方法/算法不同實現即可狀態恢復不需要需要回滾開發成本高多人同時開發較低同一團隊運行開銷高同時運行N個較低只運行到通過為止適用場景安全性要求極高的系統一般容錯系統一句話記憶NVP 多人同時做投票選答案像高考閱卷RB 一個人輪流做做對就交卷像考試換解法防衛式程序設計概念定義在程序中對所有輸入進行合法性檢查對異常情況做出預防性處理即使部分功能失效也不影響整體。通俗解釋就像電梯——即使有人按了不存在的樓層非法輸入電梯不會崩潰而是忽略或提示錯誤。核心思想不信任任何外部輸入對所有輸入做校驗異常情況有兜底處理失敗時優雅降級不崩潰9.4.2 故障檢測機制檢測方式原理舉例適用場景心跳檢測定時發送我還活著信號主備服務器心跳線服務器/進程存活檢測校驗機制對數據做完整性校驗CRC校驗、MD5校驗數據傳輸/存儲完整性異常監控監控系統指標超閾值報警CPU90%報警系統運行狀態監控超時檢測等待響應超時視為故障接口調用超時3秒網絡通信/服務調用9.4.3 故障恢復策略恢復策略原理舉例適用場景重試失敗后重新執行網絡請求失敗重試3次瞬時故障回滾恢復到操作前的狀態數據庫事務回滾事務性操作降級關閉非核心功能保核心雙11關閉評論功能高并發/資源不足熔斷檢測到持續故障后斷開下游服務不可用時熔斷微服務調用鏈切換切換到備用組件主備數據庫切換主備架構記憶技巧重試 電話沒接再打一次回滾 寫錯字了用橡皮擦掉降級 錢不夠了先保吃飯不買衣服熔斷 保險絲燒斷了保護整個電路切換 主力受傷替補上場9.5 故障樹分析FTA★★ 常考概念定義從頂層故障事件出發逐層向下分析原因用邏輯門與門、或門連接形成樹狀圖。通俗解釋就像醫生診斷——“病人發燒了”頂層事件為什么“可能是感染或可能是免疫反應”或門再往下分析感染的原因…基本符號符號名稱含義圖形─ ─ ─與門AND所有輸入事件都發生輸出才發生半圓直線∨或門OR任一輸入事件發生輸出就發生弧線○基本事件最底層的故障原因圓形▽中間事件可繼續分解的故障事件矩形△頂事件分析的頂層故障矩形最上方與門 vs 或門對比與門AND或門OR邏輯A且B → 故障A或B → 故障含義所有條件都滿足才故障任一條件滿足就故障可靠性提高可靠性需要多個同時壞降低可靠性一個壞就完概率計算P P? × P?P 1-(1-P?)(1-P?)類比兩把鎖都打開才能進門任何一把鎖打開就能進門記憶技巧與門 串聯 都壞才壞 可靠性高像兩道門鎖或門 并聯 一個壞就壞 可靠性低像多個隱患任一觸發最小割集概念定義導致頂事件發生的最少基本事件組合。通俗解釋找出最少需要壞幾個零件系統就會出問題的組合。舉例系統故障頂事件 / \ 或門 或門 / \ / \ 事件A 與門 事件D 事件E / \ 事件B 事件C 最小割集{A}, {B,C}, {D}, {E} 含義A單獨壞就故障、B和C同時壞才故障、D單獨壞就故障、E單獨壞就故障??考點最小割集越少、包含的事件越多系統越可靠。單點故障只有一個事件的割集是最危險的9.6 可靠性測試與評估可靠性測試類型測試類型目的方法關注點可靠性驗證測試驗證是否達到可靠性指標在模擬環境下長時間運行是否達標可靠性增長測試發現缺陷并修復提升可靠性測試→修復→測試循環可靠性是否在提升壓力測試在極限條件下測試超負載、大數據量運行系統極限表現故障注入測試模擬故障測試容錯能力人為注入故障容錯和恢復能力可靠性增長模型通俗解釋就像打怪升級——每發現一個bug并修復可靠性就提升一點。可靠性 ↑ │ ╱──── 目標可靠性 │ ╱ │ ╱ │ ╱ ← 可靠性增長曲線 │ ╱ │╱ └──────────────→ 測試時間三、重點歸納 速記口訣3.1 必背要點清單編號要點重要度1可靠性的定義與四要素★★★★2失效-故障-錯誤的因果鏈★★★★3MTTF、MTTR、MTBF的定義與關系★★★★★4可用性計算公式 AMTTF/(MTTFMTTR)★★★★★5串聯系統可靠性計算 RR?×R?×…×R?★★★★★6并聯系統可靠性計算 R1-(1-R?)(1-R?)…★★★★★7混聯系統計算方法先并后串★★★★★8NVP與RB的區別★★★★★9四種冗余策略硬件/軟件/信息/時間★★★★10故障樹中與門、或門的含義★★★★11最小割集的概念★★★12浴盆曲線的三個階段★★★★3.2 速記口訣可靠性三兄弟因果鏈“錯→障→失”錯Error→障Fault→失Failure寫錯了 → 有故障了 →失敗了可靠性指標“失可靠MT三兄弟”失效率λ、可靠度R(t)MTTF無故障時間、MTTR修復時間、MTBF間隔時間MTBF MTTF MTTR串聯 vs 并聯“串聯相乘越來越小并聯互補越來越大”串聯R R?×R? → 越多越不可靠一串鞭炮并聯R 1-(1-R?)(1-R?) → 越多越可靠多個保安NVP vs RB“NVP多人同時投票選RB一人輪流做對交”NVP 高考閱卷多人獨立同時運行投票RB 考試換解法同一人依次運行驗收測試四種冗余“硬軟信時”硬件冗余、軟件冗余、信息冗余、時間冗余聯想“硬軟信時”→ 硬軟件信息時代故障樹“與門串聯都壞才壞或門并聯一壞就壞”浴盆曲線“早高中低晚又高中間穩定最可靠”四、歷年真題 考點映射4.1 近5年真題匯總年份題型分值考點內容2024選擇題2分串聯/并聯系統可靠性計算2024選擇題2分NVP與RB的區別2024案例分析25分給出系統架構要求設計容錯方案計算系統可靠性2023選擇題2分可用性計算MTTF/MTTR2023選擇題2分浴盆曲線三個階段2023案例分析25分故障樹分析求最小割集提出可靠性改進方案2022選擇題2分串聯系統可靠性計算2022選擇題2分冗余策略類型判斷2022案例分析25分混聯系統可靠性計算 容錯設計分析2021選擇題2分MTBF與MTTF的關系2021選擇題2分失效-故障-錯誤的關系2021案例分析25分給出系統可靠性需求設計冗余方案并計算2020選擇題2分并聯系統可靠性計算2020選擇題2分N版本程序設計的特點2020案例分析25分故障樹分析 可靠性分配2019選擇題2分可用性等級2019選擇題2分恢復塊設計的特點2019案例分析25分綜合題可靠性計算 容錯架構設計 故障分析4.2 出題規律分析規律說明必考計算題每年至少1道可靠性計算題串聯/并聯/混聯NVP vs RB 輪流出幾乎每年都考這兩個的區別選擇題或案例填空故障樹分析高頻案例分析中常考畫故障樹、求最小割集可用性計算必考MTTF/MTTR/MTBF的計算幾乎年年考容錯設計是案例核心案例分析題常要求設計容錯方案并說明理由浴盆曲線常出選擇三個階段的特點和應對策略五、典型例題 解析例題1選擇題題目某系統由3個組件組成組件A和B并聯后再與組件C串聯。已知A、B、C的可靠度分別為0.9、0.8、0.95則該系統的可靠度為 。A. 0.684B. 0.931C. 0.722D. 0.855答案B解析第一步計算A和B并聯的可靠度R_AB 1 - (1-0.9) × (1-0.8) 1 - 0.1 × 0.2 1 - 0.02 0.98第二步計算與C串聯的可靠度R R_AB × R_C 0.98 × 0.95 0.931答案選B例題2選擇題題目某系統MTTF為498小時MTTR為2小時則系統可用性約為 MTBF為 。A. 99.6%500小時B. 99.6%498小時C. 99.0%500小時D. 99.0%498小時答案A解析MTBF MTTF MTTR 498 2 500小時可用性 A MTTF / (MTTF MTTR) 498 / 500 0.996 99.6%答案選A例題3案例分析題題目某金融交易系統需要設計高可用架構系統可靠性要求達到99.99%。現有以下組件Web服務器可靠度0.99應用服務器可靠度0.98數據庫服務器可靠度0.97問題如果三個組件串聯系統可靠度是多少是否滿足要求如果不滿足請設計一個冗余方案使其滿足99.99%的要求。請說明NVP和RB在該系統中如何應用并分析哪種更適合。參考答案問題1R_串聯 0.99 × 0.98 × 0.97 0.9411 94.11%94.11% 遠低于 99.99% 的要求不滿足。問題2對每個組件增加一個熱備并聯形成雙機熱備方案Web服務器R_W 1 - (1-0.99)2 1 - 0.0001 0.9999 應用服務器R_A 1 - (1-0.98)2 1 - 0.0004 0.9996 數據庫服務器R_D 1 - (1-0.97)2 1 - 0.0009 0.9991串聯后R 0.9999 × 0.9996 × 0.9991 ≈ 0.9986 99.86%仍不滿足99.99%。需要對數據庫最薄弱環節增加更多冗余數據庫采用3節點1主2從 R_D 1 - (1-0.97)3 1 - 0.000027 0.999973 R 0.9999 × 0.9996 × 0.999973 ≈ 0.9995 ≈ 99.95%繼續優化應用服務器也采用3節點R_A 1 - (1-0.98)3 1 - 0.000008 0.999992 R 0.9999 × 0.999992 × 0.999973 ≈ 0.9999 ≈ 99.99% ?問題3對比維度NVP方案RB方案開發方式3個獨立團隊分別開發支付模塊同一團隊開發3個版本運行方式3個版本同時運行投票決定依次執行驗收通過后輸出適用性更適合本系統需要狀態回滾復雜度高推薦NVP理由金融系統對正確性要求極高NVP的投票機制能發現設計缺陷金融交易涉及資金安全需要多團隊獨立實現以降低共性錯誤風險雖然RB開發成本較低但金融交易的狀態回滾復雜RB實現難度大六、易錯點 避坑指南6.1 常見錯誤一覽錯誤正確理解糾正建議? “串聯越多越可靠”串聯越多越不可靠并聯越多才越可靠記住串聯鞭炮并聯保安? “MTBF MTTF”MTBF MTTF MTTRMTBF是間隔時間包含修復時間? “可用性 MTTR/MTBF”可用性 MTTF/MTBF分子是無故障時間好的時間? “NVP和RB是一樣的”NVP多人同時投票RB一人輪流驗收口訣NVP高考閱卷RB換解法? “故障樹中或門提高可靠性”或門意味著任一事件就故障降低可靠性與門都壞才壞安全或門一壞就壞危險? “有故障就一定會失效”有故障不一定失效像攜帶病毒但未發病錯誤→故障→失效是因果鏈不是等價? “并聯計算是R?×R?”并聯是 1-(1-R?)(1-R?)串聯才是R?×R?先分清串并聯再選公式? “可靠性高可用性高”可靠性高≠可用性高可能不壞但修得慢可靠不生病可用病了快好6.2 計算題答題模板可靠性計算題標準步驟第一步畫出系統可靠性框圖 第二步識別串并聯關系 第三步先算并聯部分 第四步再算串聯部分 第五步得出最終結果與要求對比案例分析題答題模板1. 分析可靠性需求目標值是多少 2. 計算當前可靠性串聯/并聯公式 3. 設計冗余方案對薄弱環節加并聯 4. 重新計算驗證是否達標 5. 說明選擇的容錯策略及理由本章小結本章的核心就是四件事——理解可靠性概念定義指標、會算可靠性串聯/并聯/混聯、會設計容錯方案NVP/RB/冗余策略、會分析故障故障樹最小割集。其中計算題和NVP vs RB是每年必考必須熟練掌握本文基于系統架構設計師考試大綱編寫適合備考復習使用。如有問題歡迎評論區交流討論