《架構師》反思：系統可靠性

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

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

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

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）光纖通道雙機雙控叢集系統

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

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

随着硬體和網絡作業系統的發展。叢集技術将會在系統可用性、高可靠性和系統備援方面逐漸提高。

（如以後的叢集可以依靠叢集檔案系統實作對系統中所有檔案、裝置和網絡資源的全局通路，并且生成一個完整的系統映像。）

論文閱讀總結

可靠性工程

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

概念及發展

簡單的定義：基于軟體産品的可靠性進行預測、模組化、估計、度量及管理。

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

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

在軟體開發中的應用

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

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

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

1）确定功能概圖

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

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

3）确實使用者的可靠性需求

4）平衡性研究

5）建立可靠性名額

軟體設計和功能實作階段

該階段主要工作：

1）在子產品間配置設定可靠性名額

分解系統為多子產品，各子產品間配置設定名額，使得最後計算出的總名額滿足需求。

2）按可靠性名額進行設計

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

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

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

軟體審查（代碼稽核）、軟體測試（單元測試和內建測試）。

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

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

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

1）确實操作概圖

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

2）可靠性增強測試

系統測試、傳遞測試。

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

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

收集失效資料，規劃室額外的測試。

4）現場可靠性評估

分析資料，分析差異原因。

維護階段

主要工作：

1）規劃傳遞使用後的人員需求。

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

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

4）分析軟體傳遞後失效的産生原因，指導工程改進，降低引入類似錯誤的可能性。

成功案例

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

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

原因如下：

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

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

結束語

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

高可靠性測試

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

綜述

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

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

方案：軟體驗證技術 + 軟體确認技術 + 軟體測試管理。

<a href="http://images.cnblogs.com/cnblogs_com/zgynhqf/WindowsLiveWriter/665b60c74f1d_DB18/clip_image002_2.jpg"></a>

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

軟體确認技術則主要着眼于排除程式代碼中的錯誤。目前支援很好的自動化。

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

軟體驗證技術

主要包含以下方面：

需求規格說明驗證

保證使用者的所有需求（功能、業務、非功能、限制）都已經被配置設定到軟體需求規格說明的各需求項中。

設計規格說明驗證

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

代碼驗證

包括：代碼規範審查、代碼審查和代碼靜态分析。

傳遞驗證

在測試完成後，系統傳遞客戶前，需要進行傳遞驗證和測試。傳遞驗證包括安裝驗證和使用驗證兩部分，以確定軟體和使用者手冊比對。

軟體确認技術

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

單元測試（白盒）

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

內建測試（灰盒）

驗證各子產品組裝後的軟體是否能達到概要設計規格說明中子產品的設計目标；各子產品内部是否存在沖突，保子產品能否正常工作。一般采用自底向上按內建度由小到大進行內建測試。

系統測試（黑盒）

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

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

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

傳遞測試

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

軟體測試管理

軟體測試團隊組織管理

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

軟體測試計劃管理

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

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

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

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

軟體測試件管理

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

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

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

結語

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

本文轉自BloodyAngel部落格園部落格，原文連結：http://www.cnblogs.com/zgynhqf/archive/2010/08/16/1800767.html，如需轉載請自行聯系原作者