可靠性測試技術(shù)

DependabilityBasicConceptsandTaxonomyofDependableandSecureComputingDependabilityavailability:readinessforcorrectservice.reliability:continuityofcorrectservice.safety:absenceofcatastrophicconsequencesontheuser(s)egrity:absenceofimpropersystemalterations.maintainability:abilitytoundergomodificationsandrepairs.Faultprevention:

topreventtheoccurrenceorintroductionoffaults.Faulttolerance:

toavoidservicefailuresinthepresenceoffaults.Faultremoval:toreducethenumberandseverityoffaults.Faultforecasting:

toestimatethepresentnumber,thefutureincidence,andthelikelyconsequencesoffaults.Fault:Theadjudgedorhypothesizedcauseofanerroriscalledafault.ItscanbeinternalorexternalofasystemError:

isthepartofthetotalstateofthesystemthatmayleadtoitssubsequentservicefailure.Failure:isaneventthatoccurswhenthedeliveredservicedeviatesfromcorrectserviceFaultDevelopmentfaults:thatincludeallfaultclassesoccurringduringdevelopmentPhysicalfaults:thatincludeallfaultclassesthataffecthardwareInteractionfaults:thatincludeallexternalfaults.FailureContentfailures:Thecontentoftheinformationdeliveredattheserviceinterface(i.e.,theservicecontent)deviatesfromimplementingthesystemfunction.Timingfailures:Thetimeofarrivalorthedurationoftheinformationdeliveredattheserviceinterface(i.e.,thetimingofservicedelivery)deviatesfromimplementingthesystemfunction.Haltfailure:whentheserviceishalted(theexternalstatebecomesconstant,i.e.,systemactivity,ifthereisany,isnolongerperceptibletotheusers);aspecialcaseofhaltissilentfailure,orsimplysilence,whennoserviceatallisdeliveredattheserviceinterface(e.g.,nomessagesaresentinadistributedsystem).Erraticfailures:whenaserviceisdelivered(nothalted),butiserratic(e.g.,babbling).FaultTolerancefaultpreventionandfaultremovalintofaultavoidance,i.e.,howtoaimforfault-freesystems,faulttoleranceandfaultforecastingintofaultacceptance,i.e.,howtolivewithsystemsthataresubjecttofaults.Fault

Removal:開發(fā)階段：代碼走讀以及各種測試活動等運行階段：監(jiān)控，巡檢、更換、隔離等維護性活動Fault

Forecasting:定性評估：FMEA、RBD、FTA等等模型定量評估：Reliabilitygrowth模型，馬爾科夫鏈等可靠性系統(tǒng)產(chǎn)生不可靠的機理可描述在可靠性工程領(lǐng)域：錯誤error→缺陷defect→故障fault→失效failure錯誤：是指在系統(tǒng)生存期內(nèi)的不希望或不可接受的人為錯誤，其結(jié)果是導(dǎo)致缺陷的產(chǎn)生?？梢姡e誤是一種人為過程，相對于系統(tǒng)本身，是一種外部行為。缺陷：缺陷是存在于系統(tǒng)（文檔、數(shù)據(jù)、程序、硬件等）之中的那些不希望或不可接受的偏差，如少一個逗號、多一語句等。其結(jié)果是系統(tǒng)運行于某一特定條件時出現(xiàn)故障（這時稱缺陷被激活）故障：故障是指系統(tǒng)運行過程中出現(xiàn)的一種不希望或不可接受的內(nèi)部狀態(tài)。譬如，軟件處于執(zhí)行一個多余循環(huán)過程時，我們說軟件出現(xiàn)故障。此時若無時當(dāng)?shù)拇胧ㄈ蒎e）加以及時處理，便產(chǎn)生軟件失效。顯然，故障是一種動態(tài)行為失效：失效是指系統(tǒng)運行時產(chǎn)生的一種不希望或不可接受的外部行為結(jié)果。系統(tǒng)不出現(xiàn)問題出現(xiàn)問題后不影響業(yè)務(wù)客戶角度看可靠性出現(xiàn)問題后影響業(yè)務(wù)后，能夠快速恢復(fù)錯誤和缺陷都被消滅，就不會發(fā)生故障，也就不會有失效。代碼檢視以及各種常規(guī)測試活動都是為此而努力的針對各種故障，系統(tǒng)要具備相應(yīng)的容錯手段以確保業(yè)務(wù)的連續(xù)性，常用方法就是故障管理（故障檢測、定位、上報、恢復(fù)等），冗余設(shè)計。這是可靠性設(shè)計活動的重心（目標(biāo)：系統(tǒng)中不存在單點故障，同時單點故障不影響業(yè)務(wù)），同時也是可靠性測試的重點自動容錯的能力總是有限的，主要能解決單點故障場景，對于多點的故障場景或者涉及到硬件損壞的場景則可能無能為力了（例如存儲的多副本同時故障），這時候需要人工介入進行故障的恢復(fù)，此處的核心要求就是要速度快(S)FMEA：（軟件）失效模式影響分析，是一種自下而上的故障分析方法論FTA：故障樹分析，是一種自上而下的故障分析方法論主要的可靠性分析設(shè)計方法論(S)FIT：（軟件）故障注入測試：模擬FMEA、FTA分析出來的故障來驗證故障容錯機制的正確性場景故障已知故障已知場景未知故障已知場景未知故障未知場景已知故障未知場景測試類型長時間穩(wěn)定性測試極限壓力測試流控測試故障注入測試故障注入測試可靠性預(yù)計與建模故障注入故障處理代碼產(chǎn)品功能代碼產(chǎn)品代碼概念：對故障處理代碼的功能測試，測試故障處理代碼對產(chǎn)品功能代碼的接口方法：通過修改系統(tǒng)內(nèi)的各層次的對象的信息來實現(xiàn)故障的模擬，這些對象可以是CPU寄存器里面的信息，內(nèi)存里面的內(nèi)容，網(wǎng)絡(luò)上傳輸?shù)臄?shù)據(jù)，硬盤上的數(shù)據(jù)等這些對外不可見的信息，也可以是進程，網(wǎng)卡，文件，服務(wù)器，硬盤等這些可見的對象；對于不見對象的修改，往往是采用隨機修改的方式，例如業(yè)界的NFTAPE工具等；對于可見對象的修改往往采用精準(zhǔn)的方式進行；例如業(yè)界的ChaosMonkey等。對于內(nèi)部不可見對象的修改，如果要精準(zhǔn)修改的話，一般是采用函數(shù)跳轉(zhuǎn)與替換的方式來實現(xiàn)的（改變函數(shù)的返回值，參數(shù)，變量等）業(yè)界信息ChaoesMonkeyChaosMonkey是一種服務(wù)，用于將系統(tǒng)分組，并隨機終止屬于某個分組中的系統(tǒng)中的一部分；ChaosMonkey屬于Netflix公司的SimianArmy產(chǎn)品中的一員；SimianArmy由一組軟件工具構(gòu)成，用于測試AWS基礎(chǔ)設(shè)施；該軟件開源，可用于其他云服務(wù)用戶進行相應(yīng)測試使用；ChaosMonkey的原則：避免大多數(shù)失效的主要方式就是經(jīng)常失效；ChaosMonkey，可以隨機關(guān)閉生產(chǎn)環(huán)境中的實例，確保網(wǎng)站系統(tǒng)能夠經(jīng)受故障的考驗，同時不會影響客戶的正常使用。LatencyMonkey，在RESTful服務(wù)的調(diào)用中引入人為的延時來模擬服務(wù)降級，測量上游服務(wù)是否會做出恰當(dāng)響應(yīng)。通過引入長時間延時，還可以模擬節(jié)點甚至整個服務(wù)不可用。ConformityMonkey，查找不符合最佳實踐的實例，并將其關(guān)閉。例如，如果某個實例不在自動伸縮組里，那么就該將其關(guān)閉，讓服務(wù)所有者能重新讓其正常啟動。DoctorMonkey，查找不健康實例的工具，除了運行在每個實例上的健康檢查，還會監(jiān)控外部健康信號，一旦發(fā)現(xiàn)不健康實例就會將其移出服務(wù)組。JanitorMonkey，查找不再需要的資源，將其回收，這能在一定程度上降低云資源的浪費。SecurityMonkey，這是ConformityMonkey的一個擴展，檢查系統(tǒng)的安全漏洞，同時也會保證SSL和DRM證書仍然有效。10-18Monkey，進行本地化及國際化的配置檢查，確保不同地區(qū)、使用不同語言和字符集的用戶能正常使用Netflix。ChaosGorilla，ChaosMonkey的升級版，可以模擬整個AmazonAvailabilityZone故障，以此驗證在不影響用戶，且無需人工干預(yù)的情況下，能夠自動進行可用區(qū)的重新平衡。業(yè)界信息LinuxFault-InjectionLinux內(nèi)核集成了一個比較實用的功能“Fault-injection”來幫助我們進行故障注入，從而可以構(gòu)建一些通用的內(nèi)核異常場景。它能夠模擬內(nèi)存slab分配失敗、內(nèi)存頁分配失敗、磁盤IO錯誤、磁盤IO超時、futex鎖錯誤以及專門針對mmc的IO錯誤，用戶也可以利用該機制設(shè)計增加自己需要的故障注入Fault-injection默認(rèn)實現(xiàn)了6種錯誤注入方式，分別是failslab、fail_page_alloc、fail_futex、fail_make_request、fail_io_timeout和fail_mmc_request。它們分別的功能如下：1）failslab：注入slab分配器內(nèi)存分配錯誤，主要包括kmalloc()、kmem_cache_alloc()等等。2）fail_page_alloc：注入內(nèi)存頁分配錯誤，主要包括alloc_pages()、get_free_pages()等等（較failslab更為底層）。3）fail_futex：注入futex鎖死鎖和uaddr錯誤。4）fail_make_request：注入磁盤IO錯誤。它對塊核心層的generic_make_request()函數(shù)進行故障注入，可以通過/sys/block/<device>/make-it-fail或者/sys/block/<device>/<partition>/make-it-fail接口對指定的磁盤或分區(qū)進行注入。5）fail_io_timeout：注入IO超時錯誤。它對IO處理流程中的IO處理完成blk_complete_request()函數(shù)進行故障注入，忽略IO完成“通知”。僅對使用通用超時處理流程的drivers有效，例如標(biāo)準(zhǔn)的scsi流程。6）fail_mmc_request：注入mmc數(shù)據(jù)錯誤，僅對mmc設(shè)備有效，通過對mmccore返回dataerror進行錯誤注入，從而可以測試mmc塊設(shè)備驅(qū)動的錯誤處理流程以及重試機制，可通過/sys/kernel/debug/mmcx/fail_mmc_request接口進行設(shè)置。可靠性測試技術(shù)全景圖基礎(chǔ)數(shù)據(jù)業(yè)務(wù)中斷頻次統(tǒng)計業(yè)務(wù)中斷時長統(tǒng)計軟件類故障概率統(tǒng)計網(wǎng)絡(luò)類故障概率統(tǒng)計硬件類故障概率統(tǒng)計系統(tǒng)類故障概率統(tǒng)計業(yè)務(wù)失敗統(tǒng)計系統(tǒng)告警統(tǒng)計系統(tǒng)重啟時間進程重啟時間節(jié)點重啟時間數(shù)據(jù)重建時間主備切換時間業(yè)務(wù)中斷時間實驗室測試數(shù)據(jù)現(xiàn)網(wǎng)統(tǒng)計數(shù)據(jù)故障檢測率故障定位率故障恢復(fù)率業(yè)務(wù)成功率進程類故障模擬工具資源類故障模擬工具數(shù)據(jù)類故障模擬工具硬盤類故障模擬工具網(wǎng)絡(luò)類故障模擬工具主機類故障模擬工具關(guān)鍵故障模擬工具塊存儲業(yè)務(wù)流量工具對象存儲業(yè)務(wù)流量工具文件存儲業(yè)務(wù)流量工具塊存儲一致性校驗工具對象存儲一致性校驗工具文件存儲一致性校驗工具業(yè)務(wù)流量模擬工具測試工具平臺可靠性測試評估基線可靠性測試特性樹可靠性測試白皮書基礎(chǔ)框架可靠性測試設(shè)計指導(dǎo)書系統(tǒng)穩(wěn)定性評估指導(dǎo)書進程類故障模擬技術(shù)數(shù)據(jù)類故障模擬技術(shù)網(wǎng)絡(luò)類故障模擬技術(shù)資源類故障模擬技術(shù)硬盤類故障模擬技術(shù)硬盤類故障模擬技術(shù)系統(tǒng)穩(wěn)定性評估技術(shù)穩(wěn)定性測試設(shè)計指導(dǎo)書故障檢測能力評估技術(shù)故障定位能力評估技術(shù)故障恢復(fù)能力評估技術(shù)系統(tǒng)流控能力評估技術(shù)數(shù)據(jù)一致性評估技術(shù)數(shù)據(jù)一致性校驗技術(shù)客戶業(yè)務(wù)模擬技術(shù)精準(zhǔn)故障觸發(fā)技術(shù)關(guān)鍵測評技術(shù)可靠性能力評估指導(dǎo)書穩(wěn)定性測試檢測標(biāo)準(zhǔn)故障注入測試檢測標(biāo)準(zhǔn)工程指導(dǎo)系統(tǒng)亞健康測試指導(dǎo)書系統(tǒng)應(yīng)急預(yù)案測試指導(dǎo)書系統(tǒng)極限壓力測試指導(dǎo)書系統(tǒng)資源搶占測試指導(dǎo)書系統(tǒng)高危操作測試指導(dǎo)書系統(tǒng)人因差錯測試指導(dǎo)書可靠性測試方案可靠性測試用例可靠性測試報告可靠性網(wǎng)上問題分析改進報告可靠性測試腳本關(guān)鍵交付件可靠性測試策略測試實踐1可靠性測試是圍繞故障展開的，那么所有故障的集合在業(yè)界就成為故障模式庫1從設(shè)計開發(fā)的視角構(gòu)建的故障模式庫（模式庫1）2從測試的視角構(gòu)建的故障模式庫（模式庫2），模式庫2>=模式庫1測試視角的故障模式庫也是可靠性測試基礎(chǔ)架構(gòu)，和可靠性測試特性樹合一，因此也叫作可靠性測試特性樹。基于FTA分析思路從系統(tǒng)架構(gòu)層面抽象出故障模式一級分類，總共分為軟件、硬件、網(wǎng)絡(luò)、系統(tǒng)四大部分

基于FMEA分析思路從系統(tǒng)微架構(gòu)層面抽象出了每個一級故障模式下的二級、三級、四級、五級故障模式基于網(wǎng)上問題的分析，對各層級故障模式進行補充完善優(yōu)化

在實際的應(yīng)用中，這些通用故障模式和產(chǎn)品內(nèi)部的軟件、硬件、網(wǎng)絡(luò)等實體對象相結(jié)合，產(chǎn)生產(chǎn)品化的故障模式（產(chǎn)品對象+通用故障模式：例如OSD進程異常退出）測試實踐2故障模式庫主要為可靠性測試提供了測試輸入，定義了測試范圍，但是我們還需要定義測試驗收標(biāo)準(zhǔn)，這樣才能構(gòu)成完成的可靠性測試，這就是在我們的實踐中稱之為可靠性測試評估基線測試實踐3有了故障模式庫和可靠性測試驗收標(biāo)準(zhǔn)，可靠性測試在技術(shù)層面已經(jīng)具備了可行性，但是在實際操作層面還缺乏一定的可行性，因此我們需要一個工程指導(dǎo)來告訴我們?nèi)绾螌⒖煽啃詼y試活動融入到研發(fā)流程中去，以及通用故障模式和產(chǎn)品對象進行結(jié)合的方法，這就是在我們的實踐中稱之為可靠性測試指導(dǎo)書測試實踐4故障模式庫+可靠性測試評估基線+可靠性測試指導(dǎo)書已經(jīng)可以讓我們順利開展可靠性測試，但是測試完成后，如何評估產(chǎn)品的可靠性能力呢，這就引出了可靠性的量化評價指標(biāo)體系：故障定位率、故障恢復(fù)率、系統(tǒng)啟動時間等等故障定位率：能夠自動定位的故障模式數(shù)/系統(tǒng)總的故障模式數(shù)（產(chǎn)品自己的故障模式庫）自動定位：硬件類故障定位到可更換的單元FRU（例如硬盤，具體的槽位信息）；軟件類故障定位到具體的業(yè)務(wù)模塊或者進程；網(wǎng)絡(luò)類故障定位到具體的網(wǎng)絡(luò)接口和網(wǎng)絡(luò)設(shè)備故障恢復(fù)率：能夠自動恢復(fù)的故障模式數(shù)/系統(tǒng)總的故障模式數(shù)（產(chǎn)品自己的故障模式庫）自動恢復(fù)：指通過重啟或者冗余倒換的方式恢復(fù)業(yè)務(wù)處理能力，自身的故障不一定恢復(fù)，特別是硬件，是需要后續(xù)進行更換的故障定位時長：從某對象故障發(fā)生到用戶或者系統(tǒng)感知并定位該對象故障的持續(xù)時間故障恢復(fù)時長：從系統(tǒng)感知到某對象故障到該故障對象所承載的業(yè)務(wù)恢復(fù)所持續(xù)的時長系統(tǒng)流控能力：業(yè)務(wù)流量在系統(tǒng)最大流量的2/3/5/10/64/100倍時候的業(yè)務(wù)成功率（相對于1倍業(yè)務(wù)流量的成功率）系統(tǒng)啟動時間：整個系統(tǒng)從接通電源到可以提供完整業(yè)務(wù)所持續(xù)的的時長測試實踐5在業(yè)界的測試類型里面，并無穩(wěn)定性測試一說，從業(yè)借來看，包含壓力測試，長時間測試，負載測試等等，我們在測試實踐中將這些測試進行了統(tǒng)一，統(tǒng)稱為長穩(wěn)測試，并對長穩(wěn)測試的范圍進行了定義，長穩(wěn)測試分為四個階段：第一階段常規(guī)壓力測試，業(yè)務(wù)壓力為系統(tǒng)最大負載的70%，至少運行一周，退出條件是業(yè)務(wù)性能指標(biāo)穩(wěn)定，資源占用穩(wěn)定。這是后續(xù)幾個階段測試的基礎(chǔ)。第二階段是極限壓力測試，結(jié)合系統(tǒng)的流控能力，將系統(tǒng)的壓力逐步增大（一直增加，一般情況下20倍即可，最大100倍），保證系統(tǒng)不能死（保持一定的成功率，壓力下降后，快速回到100%成功狀態(tài)），該場景運行一般也是一周左右。此處的極限壓力也包含系統(tǒng)內(nèi)部局部的高壓力第三階段是高壓力下的故障容錯能力，將系統(tǒng)業(yè)務(wù)壓力保持在90%-100%之間，隨機注入故障（至少保證所有故障都覆蓋一次），一般測試5-10天左右

第四階段是長時間常規(guī)壓力測試，業(yè)務(wù)壓力一般保持在80%-90%左右，至少穩(wěn)定運行2周以上，此處不要求業(yè)務(wù)都是100%成功，而且需要構(gòu)造部分的業(yè)務(wù)失敗。此測試主要是驗證系統(tǒng)運行的累積效應(yīng)測試實踐6業(yè)界出現(xiàn)的影響范圍較大的事故中，人因差錯導(dǎo)致的占較大的比例。因此在可靠性測試中專項開展人因差錯和高危操作測試測試，人為進行一些不按照正常步驟進行的操作人因差錯：包含如下的場景1）

熱拔插的硬件插錯槽位或者插錯服務(wù)器2）

配置錯誤：配置缺失，配置不一致，配置非法等3）日常運維中人為誤刪除系統(tǒng)的信息或和用戶數(shù)據(jù)4）人為誤操作導(dǎo)致的資源沖突（IP地址沖突），非法節(jié)點等高危操作：主要包含如下幾類操作：1）

系統(tǒng)內(nèi)部自動刪除系統(tǒng)對象或者用戶對象的2）

用戶主動刪除系統(tǒng)對象或者用戶對象3）一次性查詢大量信息的4）變更系統(tǒng)配置或者用戶業(yè)務(wù)配置的自動化邏輯視圖SSH協(xié)議接口telnet協(xié)議接口HTTP(S)協(xié)議接口日志管理機制并發(fā)調(diào)度機制文件操作機制環(huán)境清理機制通用機制XXXX業(yè)務(wù)接口XXXX業(yè)務(wù)接口安裝部署接口XXXX業(yè)務(wù)接口安全紅線接口安全攻防接口軟件類故障接口硬件類故障接口系統(tǒng)類故障接口網(wǎng)絡(luò)類故障接口計算面業(yè)務(wù)流量接口存儲面業(yè)務(wù)流量接口網(wǎng)絡(luò)面業(yè)務(wù)流量接口操作運維接口功能類接口升級補丁接口故障類接口專項業(yè)務(wù)流量接口業(yè)務(wù)壓力類接口系統(tǒng)狀態(tài)采集