最近系統學習了一個系統可靠性及其相關知識，今天在這總結一下。

首先，什么是系統的可靠性呢？系統的可靠性是指在規定的時間內及規定的環境下完成規定功能的能力，也就是系統的無故障運行概率。

我會從以下幾個方面來歸納主要內容：

1. 故障模型

2. 可靠性模型

3. 可靠性指標

4. 可靠性設計

故障模型

系統故障是指硬件或者軟件的錯誤狀態，一般引進故障的原因是這些：部件的失效、環境的物理干擾、操作錯誤或不正確的設計。

按照時間的長短，故障可以分為：永久性、間歇性、瞬時性。

故障的級別有：邏輯級故障、數據結構級故障、軟件故障和差錯故障、系統級故障。

可靠性模型

與故障模型想對應的，就是系統的可靠性模型。常用的有以下三種：時間模型、故障植入模型和數據模型。

這三種模型暫時還沒有看懂（暈）。

可靠性指標

可靠性指標，主要有以下幾個：

平均無故障時間（MTTF-Mean Time To Failure）

它表示一個系統平均情況下，正常運行的時間。

與它相關的指標是“失效率”U，關系： U = 1 / MTTF。

平均故障修復時間（MTTR-Mean Time To Fix/Repire）

平均每次修復所需要的時間

平均故障間隔時間（MTBF-Mean Time Between Failure）

一看就知道，MTBF = MTTF + MTTR。

在實際情況下，一般MTTR都會比較小，所以我們近似地認為MTBF = MTTF。

MTTF是用來說明一個軟件系統能夠正常運行的時間的指標。它越大，說明該系統越可靠。計算方法很簡單，

可靠性計算

一個系統的可靠性計算往往不能直接得出。這是因為計算機系統是一個復雜的系統，影響其可靠性的因素也非常復雜。所以我們需要為其建立適當的數據模型，把大系統劃分為若干子系統，然后再根據一定原則進行組合計算。

這種計算方法，可以簡化分析的過程。

對于系統的劃分，我們可以把它分為：串聯系統、并聯系統、模冗余系統、混聯系統。（其中模冗余系統是M個并聯的子系統中，需要有N個以上的子系統能正常工作，整個系統才能正常工作。這種系統，常在并聯后加上一個表決器。）

計算這些系統可靠性時，我們需要計算出每個子系統的失效率，然后根據概率的加法原則（串聯系統）和乘法原則（并聯系統）進行綜合運算，最后得出整個系統的可靠性。

可靠性設計

本小節是整單的重點。

提高系統可靠性的方法，主要是兩種：避錯和容錯。避錯主要是指提前做一些措施，避免系統在運行中出現錯誤。而容錯則是指系統在運行中部分組件出現錯誤，仍然不失效，可以繼續運行；或者當數據、文件損壞或丟失后，系統可以自動將這些數據恢復到以前的狀態，使系統能夠繼續正常運行。

測試就是最常用的一種避錯技術。而容錯則一般使用冗余來實現。

冗余技術

冗余技術是容錯的主要手段。主是通過對資源的冗余，包括硬件、軟件、信息、時間等，可以使系統的容錯性得到較大的提高。

結構冗余

這里又分靜態冗余和動態冗余。

靜態冗余一般是指增加同樣功能的部件，同時運行，最后由表決器對結果進行表決，以多數結果作為系統的最終結果。

動態冗余則是做一些多重的設備儲備，當系統檢測到某一部件失效時，啟用相應的新部件代替它進行工作。這里有檢測、切換和恢復的過程，所以稱之為動態冗余。這些多余的設備儲備，可與主模塊一起工作，也可以不工作，分別稱為熱備份和冷備份。冷備份缺點是當主模塊失效時，備份系統可能無法及時銜接上，因為備份機無法獲取到原來機器上所有的數據。

其實，我們還可以結合以上兩種冗余的優缺點，使用混合冗余的方式，對系統進行結構性冗余設計。

信息冗余

添加一些額外的信息用于保證其正確性。例如：糾錯碼。

時間冗余

類似結構冗余，不過這里是在同一設備上執行重復計算。

故障恢復策略

如果故障已經發生，則需要一定的方法來恢復故障。一般有兩種恢復策略：向前和向后。

向前恢復是指不停止當前的計算，而把系統從不連貫的狀態恢復為連貫的正確狀態，需要有錯誤的詳細說明。例如我們可以在系統發生故障時，把異常信息都捕獲到并存儲起來備案，然后盡量讓系統繼續執行。這也是平常最常用的策略。

后向恢復是把系統恢復到之前的一個狀態，然后繼續執行。這種方法比較簡單，但是卻造成程序運行的不連貫性，不適應一些高要求系統，如實時系統。

軟件容錯

主要有以下幾種方式：

恢復塊方法

這種方法是一種動態的故障屏蔽技術，采用的是后向恢復策略。它提供相同功能的主模塊和多個備用模塊，當主功能計算完成后需要進行驗證測試，如果測試沒有通過，則會使用備用模塊進行計算，如果還是沒有通過，則繼續使用下一個備用模塊。

設計時應該保證實現主塊和備用塊之間的獨立性，使其不會相互影響。

N版本程序設計

此法是一種靜態故障屏蔽技術，采用前向恢復策略。

采用多個相同功能的N份程序同時運行，使用表決器進行最后結果的表決。

重點在于：

N版本的程序設計應該使用不同的方法，如不同的設計語言、不同的開發環境和工具。

同時，由于N個程序同時運行，最后同時表決，所以需要解決多個程序間的并發性。

防衛式程序設計

此法的基本思想是在程序中包含錯誤檢測代碼。一旦錯誤發生，程序能撤銷錯誤狀態，恢復到一個已知和正確狀態中去。包括錯誤檢測、破壞估計和錯誤恢復三個方面。

這種方式主要是以軟件的形式來容錯，也就是說軟件自身有較強的容錯性，較為常用。

集群

集群是由兩個以上的節點機（一般是服務器）構成的一種松散耦合的計算節點集合，為用戶提供網絡服務或應用程序（包括數據庫、Web服務和文件服務等）的單一客戶視圖，同時提供接近容錯機的故障恢復能力。

一說到集群，一般會想到使用它來為應用程序提供一種可擴展的高性能設計。但是集群同時還可以為應用程序提供較高的容錯能力。以下是集群的分類：

高性能計算科學集群、負載均衡集群、高可用性集群

在實際應用中，這三種基本類型經常會混合使用。

硬件配置

（1）鏡像服務器雙機

使用兩臺單獨的服務器做鏡像服務器，之間使用鏡像軟件通過網絡同步數據。鏡像服務器的性能比單一服務器的性能要低，適用對集群系統要求不高的用戶，

特點：簡單、價格最低廉、可靠性較低、占用網絡資源、性能較低。

（2）雙機和磁盤陣列柜

此方式同樣使用雙服務器，同時后端的數據存儲使用磁盤陣列柜。陣列柜為雙機提供邏輯盤陣訪問，并不隨意擴展新的物理磁盤。

此方式不需要進行數據的同步，所以性能較鏡像服務器要高出很多。但是可能會導致“單點錯”，即系統中某一部件或某個應用程序發生故障時，導致所有系統全部宕機。如磁盤陣列如果出錯，可能會導致存儲的數據全部丟失。

特點：性能較高、可能導致單點錯誤。

（3）光纖通道雙機雙控集群系統

使用光纖來組建通道進行連接。允許鏡像配置。

特點：擴展性強、費用較高。

隨著硬件和網絡操作系統的發展。集群技術將會在系統可用性、高可靠性和系統冗余方面逐步提高。

（如以后的集群可以依靠集群文件系統實現對系統中所有文件、設備和網絡資源的全局訪問，并且生成一個完整的系統映像。）

---

論文閱讀總結

可靠性工程

原文鏈接： http://wenku.baidu.com/view/98b021225901020207409c76.html

該文從工程學的角度來說明了可靠性工程如何開展，并舉例說明如何在軟件開發過程中應用可靠性工程。

概念及發展

簡單的定義：基于軟件產品的可靠性進行預測、建模、估計、度量及管理。

其目標是提高軟件系統的可靠性。為達到這個目的，我們需要明白失效產生的原因。

核心問題：如何開發出高可靠性的軟件；另一問題：如何評估已有系統的可靠性。

在軟件開發中的應用

可靠性工程貫穿于軟件開發生命周期的各個階段。

項目開發計劃及需求分析階段

本階段中，主要是要明確可靠性需求，建立系統的可靠指標。一般情況下，可靠性工作可如下安排：

1）確定功能概圖

功能概圖主要描述系統中各功能及其使用環境和被使用的概率。

2）對失效進行定義和分類

3）確實用戶的可靠性需求

4）平衡性研究

5）建立可靠性指標

軟件設計和功能實現階段

該階段主要工作：

1）在模塊間分配可靠性指標

分解系統為多模塊，各模塊間分配指標，使得最后計算出的總指標滿足需求。

2）按可靠性指標進行設計

有關可靠性設計的內容，參見在上文中內容。

3）根據功能概圖集中資源配置

4）控制錯誤的引入和傳播

軟件審查（代碼審核）、軟件測試（單元測試和集成測試）。

5）測試現成軟件的可靠性

系統測試和現場試運行階段

該階段是保證可靠性的最后階段。主要工作：

1）確實操作概圖

操作概圖主要描述系統最后可以使用的各操作（命令）及其使用環境和被使用的概率。

2）可靠性增強測試

系統測試、交付測試。

按照操作概圖中的概率執行測試用例，模仿用戶的應用方式測試。

3）根據測試來證明是否已經達到可靠性指標

收集失效數據，規劃室額外的測試。

4）現場可靠性評估

分析數據，分析差異原因。

維護階段

主要工作：

1）規劃交付使用后的人員需求。

2）監視現場可靠性，并做出適當的調整。

3）監視并維護新功能引起的失效。

4）分析軟件交付后失效的產生原因，指導工程改進，降低引入類似錯誤的可能性。

成功案例

文中以一交換機的研發做為例子，說明可靠性工程的應用，給產品帶來了驚人的好處：

問題數下降、維護費用下降、測試件間隔縮短、引入新產品的間隔縮短、客戶滿意度提升。

原因如下：

⑴把可靠性作為確定是否發行的標準，可避免用戶在使用中反映過多問題和進行相應的維護工作。

⑵采用“操作概圖驅動”的測試方法，提高了測試效率；20%的操作覆蓋了95%的應用，20%的錯誤導致了95%的實效；先測試20%的使用最頻繁的操作可以加速可靠性的提高。

結束語

國內外還未能有系統化的可靠性工程學理論。我們需要不斷結合實踐進行研究和總結，為使可靠性工作成為有計劃、有組織和有目標的研究工作而努力。

---

高可靠性測試

原文鏈接： http://tech.it168.com/a2008/0829/202/000000202483.shtml

該文以作者參與的CraftGS系統為例，講述了如何在系統中應用測試技術保證軟件的高可靠性，這些技術包括：軟件驗證、軟件確認、軟件測試管理。

綜述

高可靠性軟件泛指一類軟件：該類軟件運行過程中若出現故障會引發重大災難性事故或經濟損失。通常航天型號軟件、銀行系統軟件、醫療行業軟件、通訊行業軟件等均屬此范疇。

作者的CraftGS系統就是可靠性要求較高的一個軟件系統，其中各子系統的可靠性指標都在0.95以上。

方案：軟件驗證技術 + 軟件確認技術 + 軟件測試管理。

驗證技術主要是人工完成，方法有：面對面質詢、文檔抽查、非正式會議、同行評審等等。

軟件確認技術則主要著眼于排除程序代碼中的錯誤。目前支持很好的自動化。

工程質量的把控，主要依靠測試管理，分為：“軟件測試團隊組織管理、軟件測試計劃管理、軟件缺陷（錯誤）跟蹤管理以及軟件測試件管理”四大部分。

軟件驗證技術

主要包含以下方面：

需求規格說明驗證

保證用戶的所有需求（功能、業務、非功能、約束）都已經被分配到軟件需求規格說明的各需求項中。

設計規格說明驗證

主要是逐步檢查概要設計和詳細是否全部分配了之前的分析成果。其中，還要進行數據庫設計的驗證。

代碼驗證

包括：代碼規范審查、代碼審查和代碼靜態分析。

交付驗證

在測試完成后，系統交付客戶前，需要進行交付驗證和測試。交付驗證包括安裝驗證和使用驗證兩部分，以確保軟件和用戶手冊匹配。

軟件確認技術

其實這里是測試技術。有：

單元測試（白盒）

建構樁模塊和驅動模塊以驅動被測單元（函數、類、模塊）運行，使用設計好的測試用例對各單元進行測試。

集成測試（灰盒）

驗證各模塊組裝后的軟件是否能達到概要設計規格說明中模塊的設計目標；各模塊內部是否存在沖突，保模塊能否正常工作。一般采用自底向上按集成度由小到大進行集成測試。

系統測試（黑盒）

檢測系統是否滿足軟件需求規格說明中的各需求項，包括：業務需求、功能需求、非功能需求（質量屬性）及約束。雖然不涉及代碼，但是由于需求項涉及的領域較廣，所以測試方法多而雜，如：

功能測試、執行路徑測試、可靠性測試、壓力測試、可恢復性測試、可移植性測試……等。

這些測試的特點：在一定環境條件下（如：模擬現場或極端條件），設計并運行各種測試用例，根據測試結果數據，評估軟件系統是否符合軟件需求項的各類要求。

交付測試

交付測試的主要參與者是目標客戶，客戶參與越多越好。主要進行：安裝測試、可用性測試、alpha測試、beta測試等。

軟件測試管理

軟件測試團隊組織管理

是否能組建一個合適的測試團隊，直接影響到測試工作的進展和質量。作者的CraftGS系統中的測試團隊，有資深測試專家、測試人員、兼職人員（同行評審）、測試新手。

軟件測試計劃管理

其實就是安排好測試的流程。

主要有：軟件測試策劃、軟件測試技術剪裁、測試進度管理、成本管理。

軟件缺陷（錯誤）跟蹤管理

跟蹤一個錯誤的全生命周期，確保每一個錯誤都能及時糾正及不引入新的錯誤。當測試人員提交錯誤后，需要督促開發團隊及時修正，并在修正完成后進行回歸測試。一般使用BUG管理系統即可。

軟件測試件管理

努力建設好測試團隊的財富庫并對測試團隊成員進行技能培訓以幫助他們能使用好這個財富庫。

測試件（Testware）是指測試工作形成的產品，包括：實踐中積累的經驗教訓、測試技巧、測試工具、規格文檔及一些通用腳本。

測試件管理工作主要是：建設與培訓。

結語

目前對高可靠性軟件如何實話軟件測試技術仍是一個頗不成熟的領域，缺少一種體系化的方法。

歡迎轉載，轉載請注明：

轉載自 胡慶訪[http://zgynhqf.cnblogs.com/]

總結

以上是生活随笔為你收集整理的《架构师》反思：系统可靠性的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。