定義必要的可靠性南大計算機系

定義必要的可靠性南大計算機系第一頁，共四十頁，2022年，8月28日可靠性的定量定義使我們能夠精確地平衡客戶對可靠性，交付日期和成本的要求，并更加有效地開發(fā)和測試產品。第二頁，共四十頁，2022年，8月28日失效/錯誤失效(failure)是指系統運行的行為對用戶要求的偏離，是面向用戶的概念。只有在系統運行的時候才可能有失效。錯誤(fault)是指在系統運行時引發(fā)或可能潛在地引發(fā)失效的缺陷。是面向開發(fā)的概念。第三頁，共四十頁，2022年，8月28日失效嚴重程度類別（1）失效嚴重程度類別一組單個出現時對用戶產生相同影響的失效。指定失效的嚴重程度，主要是為了結合失效頻率來解決失效的優(yōu)先級。分級標準人員生命，成本，系統能力的影響。還可能包括一些子標準：額外的運行成本，修復和恢復成本，…。第四頁，共四十頁，2022年，8月28日失效嚴重程度類別（2）不可能精確估算失效的影響。根據成本劃分的失效嚴重程度類以10倍的關系劃分。通常不超過四個級別。失效嚴重程度類定義1>100000210000-10000031000-100004<1000第五頁，共四十頁，2022年，8月28日失效嚴重程度類（3）根據對系統能力的影響劃分失效嚴重程度類。失效嚴重程度類定義1用戶不能進行一項/多項關鍵操作。2用戶不能進行一項/多項重要操作3用戶不能進行一項/多項操作，但是有不久方法4一項或多項操作中的小缺陷第六頁，共四十頁，2022年，8月28日失效強度（1）失效強度是表示可靠性的一種簡單直觀的方式。起初是指單位時間內出現失效的次數。對于軟件來說，執(zhí)行時間是軟件的度量方式。雖然使用執(zhí)行指令數目來度量軟件的失效強度更加準確，但是和系統其他部分的度量不兼容。第七頁，共四十頁，2022年，8月28日失效強度（2）有時，將失效強度表示為每個自然單位出現的失效數目更加方便。比如打印機輸出的頁數，交易數目，電話呼叫次數等。每打印10000頁出現一次失敗，每100000次電話出現電話掉線，…失效強度的單位也可以用來表示可靠性。第八頁，共四十頁，2022年，8月28日失效強度（3）如果系統的成功執(zhí)行要求所有組件的成功執(zhí)行，那么系統失效強度就是所有組件的失效強度的總和。第九頁，共四十頁，2022年，8月28日過程（1）為了為每個產品系統分析定義必要的可靠性，我們需要為產品定義進行了嚴重程度分類的失效為所有相關的系統選擇一種通用的度量為每個測試的系統建立失效強度目標。對于所開發(fā)的軟件產品，針對該軟件我們必須找出所開發(fā)軟件的失效強度目標。指定策略以滿足所開發(fā)軟件的失效強度目標第十頁，共四十頁，2022年，8月28日定義失效根據用戶的需要，對程序行為創(chuàng)建消極需求。通過說明系統不應該做的事情來給出失效的定義。這些消極需求（錯誤的行為）應該根據失效嚴重程度類別列出。而這些類的劃分方法對每個項目都有所不同。我們可以根據情況選擇特定的嚴重程度類劃分標準。第十一頁，共四十頁，2022年，8月28日定義失效Fonefollower的失效嚴重程度類失效嚴重程度類定義1導致不能轉發(fā)呼叫的失效。2導致不能輸入要轉發(fā)的呼叫號碼的失效3使系統管理困難，但是可以用別的方法代替的失效4引起不方便的失效第十二頁，共四十頁，2022年，8月28日選擇通用度量可靠性的度量方式可以選擇自然單元。一個產品可能具有多種自然單元，每個自然單元和一組重要的功能相聯系。此時可以選擇時間作為失效強度的基礎。一般時間？執(zhí)行時間？如果平均計算機使用時間的變化不大，可以使用一般時間來替代執(zhí)行時間。否則可以將執(zhí)行時間調整為一般時間。第十三頁，共四十頁，2022年，8月28日建立失效強度目標(FIO)需要給每一個被測試的系統建立相應的失效強度目標。對超系統（或獨立的產品），直接設定失效強度目標。對于某個組件，將超系統的FIO減去其他組件的FIO，得到它的FIO。如果組件屬于多個系統，那么取最小值為其FIO。為每個采辦組件建立FIO。第十四頁，共四十頁，2022年，8月28日建立失效強度目標（2）超系統（或獨立產品）的FIO的確定依賴于產品特性，用戶/客戶的具體需求和期望。需要考慮實效強度（可靠性），開發(fā)時間，開發(fā)成本等?？紤]和這個產品競爭的產品。考慮和這個產品相關的其他系統的FIO。第十五頁，共四十頁，2022年，8月28日建立失效強度目標（3）對于某個版本，根據當前的開發(fā)技術水平，以及新功能的個數，失效強度，開發(fā)時間，開發(fā)成本的乘積基本上是一個常量。需要在這三者之間取得平衡。同時，對于不同的產品，這三者之間的關系未必一樣。可以通過以往的數據來知道三者之間的精確關系，以指導決策。第十六頁，共四十頁，2022年，8月28日建立失效強度目標（4）建立失效強度目標時的參考信息。失效影響FIO時間數百人死亡，10億美元以上損失10-9114000年1-2人死亡，1百萬美元左右的損失10-6114年大約1000美元的經濟損失10-36周大約100美元的經濟損失10-2100小時大約10美元的經濟損失10-110小時大約10美元的經濟損失11小時第十七頁，共四十頁，2022年，8月28日建立失效強度目標（5）一般用單個用戶的方式給出可靠性數據，便于市場開發(fā)專家將它和需求聯系起來。對于FoneFollower，我們可以定為每10000個呼叫有一次失效。如果用戶用最嚴重的失效（1類失效）表示需要的失效強度，那么應該將用戶的SFIO除以最嚴重失效的比率。（因為經驗顯示這樣的比率是確定的）FIO是對所有的操作而言的，而不是對于少數關鍵操作而言的。第十八頁，共四十頁，2022年，8月28日建立失效強度目標（6）在規(guī)劃FIO的時候，需要用戶的參與?？梢允褂脩舾械綕M意；可以更加準確地了解用戶的需求。如果產品的客戶數量少，那么可以要求客戶一起工作。如果產品有大量的小用戶，則需要對用戶隨機采樣，提供一定的鼓勵等。第十九頁，共四十頁，2022年，8月28日可靠性和失效強度的關系有時，需要在可靠性與失效強度之間進行轉換 =-lnR/t R=exp(-t)如果R>0.95，那么近似計算

=(1-R)/t R=1-t其中表示失效強度，R表示可靠性，t表示時間。第二十頁，共四十頁，2022年，8月28日可靠性和失效強度的關系如果要起8小時的可靠性為0.992，那么失效強度應該為每1000小時1個失效。每1000頁打印出現1次失效，可以轉換為8頁打印的可靠性為0.992。第二十一頁，共四十頁，2022年，8月28日可用性和失效強度（1）可用性A表示在一段時間內，系統以可接受的狀態(tài)工作的時間和總時間的比率 A=tu/(tu+td)Tu表示正常運行的時間，td表示downtime. Td=tmtu，其中tm表示每個失效導致的平均停機時間。第二十二頁，共四十頁，2022年，8月28日可用性和失效強度（2）A=1/(1+tm)=(1-A)/Atm比如：如果產品的可用性必須達到99%，并且停機時間為6分鐘，那么失效強度目標大概是每小時0.1個失效。第二十三頁，共四十頁，2022年，8月28日確定被開發(fā)軟件的FIO（1）如果產品需要開發(fā)軟件組件，那么需要為這個組件設定FIO。首先找出系統中預期的采辦組件的FI。根據操作數據，提供商擔保，專家經驗來估計。通過從對應的系統FIO減去采辦組件的FI，得到每個系統自記開發(fā)的軟件的FIO。第二十四頁，共四十頁，2022年，8月28日確定被開發(fā)軟件的FIO（2）以FoneFollower為例，如果從硬件提供商那里得到數據，硬件組件的FI是每小時0.1個失效；操作系統在每小時10萬次呼叫的情況下，每小時0.4個失效。轉換之后得到，采辦組件的失效強度為每百萬次5次失效。如果產品的FIO和采辦組件的FI有比較大的差別，可以考慮使用其他的組件來替代。直接累加采辦組件的失效強度可以得到總采辦FI。是一種近似的計算方法，但是比較有效。實際的FI低于計算得到的FI。第二十五頁，共四十頁，2022年，8月28日指定策略以滿足FIO（1）選擇正確的可靠性策略，在時間和金錢允許的情況下，盡可能提高滿足目標的可能性。可靠性策略的實施主要由系統工程師和系統架構師完成，但是該策略對測試的影響也非常大。三種策略：錯誤預防，錯誤清除，容錯。第二十六頁，共四十頁，2022年，8月28日指定策略以滿足FIO（2）錯誤預防應用適當的需求獲取方法，進行需求審查，實現設計方法進行設計復查，建立和執(zhí)行各種標準，使用好的需求獲取工具和設計工具等。錯誤預防的有效性通過估計進行預防活動之后的剩余錯誤的比例來度量。第二十七頁，共四十頁，2022年，8月28日指定策略以滿足FIO（3）錯誤清除通過代碼審查和測試清除錯誤。代碼審查的有效性由審查之后遺留錯誤的比例確定。也許可以通過某種數據模型來估算剩余錯誤數量。測試的有效性可以通過測試之前的FI和測試之后的FI的比例來度量。這樣的度量可以改進我們的測試方法。第二十八頁，共四十頁，2022年，8月28日指定策略以滿足FIO（4）容錯容錯必須通過設計來實現。通過預測系統可能會出現哪些失效，并通過冗余設計來對抗這些失效。第二十九頁，共四十頁，2022年，8月28日指定策略以滿足FIO（5）理論上，應該通過平衡各種因素來選擇適當的策略：策略的開銷，有效性，使用的范圍等。一般可以根據經驗選擇策略。超可靠性：每1000小時<0.1失效；使用容錯技術，廣泛的需求和設計評審高度可靠：每1000小時0.1-10失效；要求相當廣泛的需求和設計評審，可能需要一些容錯。商品化：每1000小時10-2000失效；指導需求或帶有操作剖面和評判標準的設計評審。原型：每1000小時>2000失效；一般測試第三十頁，共四十頁，2022年，8月28日指定策略以滿足FIO（6）通過操作剖面(Operationprofiles)，可以確定將策略的重點放在哪里。通過產品的前面一個版本的實際失效強度，和FIO比較以確認工作的重點。投入一定的工作量來改進開發(fā)過程。第三十一頁，共四十頁，2022年，8月28日特殊情況失效的其他劃分方法為組件分配失效強度目標軟件安全性和超可靠性第三十二頁，共四十頁，2022年，8月28日失效的其他劃分方法為滿足特殊的目的，可以根據其他的特征對失效進行分組。組件操作組失效類別作業(yè)角色第三十三頁，共四十頁，2022年，8月28日為組件分配FIO（1）由采辦軟件組件的FI以及產品的FIO來確定開發(fā)部件的失效強度。一般沒有折衷過程。但是，如果有多個不同層次的可選組件，那么我們可以考慮在不同的組件之間進行FI和資金的分配。首先，將系統劃分為適當的組件；確定組件的失效目標。第三十四頁，共四十頁，2022年，8月28日為組件分配FIO（2）劃分組件主要依據系統配置的性質，項目管理問題以及管理較多組件的可靠性所需要的工作量或成本。應該盡可能將系統劃分為與現有可以重用的組件相似的組件。（可以更多地重用更加可靠的系統）第三十五頁，共四十頁，2022年，8月28日為組件分配FIO（3）確定FIO估計已知的組件值逐步分配組件的失效強度目標以縮短系統開發(fā)時間，降低開發(fā)風險或成本根據組件的FIO，計算系統的FI并和需求比較修改組件的FIO，直到滿足需求。第三十六頁，共四十頁，2022年，8月28日為組件分配FIO（4）以FoneFollower為例將整個系統分割成為3個部分：硬件，操作系統，應用程序。已經確定系統的FIO為100失效/百萬次呼叫。硬件的可靠性為1失效/百萬次呼叫所以操作系統+應用程序的總FI不超過99失效。對于不同的FIO，同樣的軟件需要不同的成本和時間。根據選擇不同的開發(fā)成本和周期，可以得到適當的每個組件的FIO。第三十七頁，共四十頁，2022年，8月28日安全性與超可靠性（5）軟件安全性是軟件可靠性的一個子集。安全性表示避免災難，而災難顯然是一種特殊的失效。軟件可靠性的理論，方法也都適用于軟件安全性。（容錯，統計模型，…）軟件安全性和超可靠性密切相關。第三十八頁，共四十頁，2022年，8月28日安全性與超可靠性（6）超可靠性一般指每