​​​​​​​​​​​​​摘要：在產品上雲之前，雲上資料的可信（安全性、可靠性等）成為大家關注的重點。

引言

疫情之下，科技支撐有目共睹，多個產業迎來逆勢增長。科技創新賦能的“雲技術”，不再僅僅是戰“疫”的重要工具，更將帶動全社會的數字化轉型，對產業發展產生深遠的意義。而在產品上雲之前，雲上資料的可信（安全性、可靠性等）一直是大家關注的重點。

近年來，雲上可靠性事故的案例層出不窮。如：

2018年7月XX雲因儲存空間使用率過高發起搬遷擴容。為加快速度，運維人員手動關閉了搬遷過程的資料校驗，並在搬遷完成後立即釋放了源資料空間。由於物理硬碟韌體版本缺陷導致的靜默錯誤，檔案系統元資料損壞，導致租戶資料丟失；

2018年9月4日清晨因雷電導致XX雲中南美Region機房製冷異常，引起部分裝置損壞/自動關閉，大部分雲伺服器中斷超24小時；

2018年10月21日晚，GitHub對故障的100G光纖裝置維護更換導致東海岸資料中心網路中斷43秒，由此引發資料庫異常，服務降級持續24小時11分鐘；

2019年X月，XX雲某region因程式碼缺陷導致包週期EIP出現大量退訂，引起客戶業務故障引發客戶強烈不滿。恢復丟失資源約花費XX分鐘。

“雲技術”帶來了數字化變革，但云上的可靠性問題又一次次讓客戶膽戰心驚，下面重點談談如何做雲上的可靠性測試。

1、什麼是可靠性測試

可靠性測試就是採用特定的方法啟用系統中的各種故障（FAULT），透過觀察失效（FAILURE）的發生情況來對系統容錯能力（故障定位、故障恢復、故障報告等）進行評估並利用該評估結果來推動產品持續減少失效的一種測試活動。

產品的可靠效能力主要體現在防錯能力、容錯能力和糾錯能力。因此可靠性測試也主要圍繞產品的這三大能力進行測試。

防錯能力主要考察服務的故障預警能力，如CPU、記憶體、磁碟等的容量監控告警能力。

容錯能力主要考察服務故障後的故障隔離、故障自恢復的能力以及隔離時間。

糾錯能力則主要考察業務故障後告警能力以及故障修復文件的可操作性。

2、可靠性測試設計

可靠性測試設計主要從產品故障模式庫和業務流程兩方面著手進行分析：

故障模式考慮的因素包括外部因素和內部因素。內部因素包括軟體，硬體，網路和資料。外部因素包括人，負載，災難，電力，環境等。

流程驅動主要從異常邏輯、異常事件、業務執行環境三方面來分析：

異常邏輯主要包括（1）流程處理邏輯結果不符合預期；（2）流程處理邏輯過程中所發生的非期望事件。

異常事件對業務流程的影響最終也會體現到邏輯上來，產生異常或不產生異常與切入點有關，需要透過多次反覆操作增加衝突機率。

業務執行環境不穩定對業務的影響，主要指周邊服務/鏈路狀態不穩定，系統資源佔用不穩定等對業務流程的影響。

無論從哪個角度出發，均屬於抽取式分析。無法達到故障模式和業務流程的完全組合覆蓋。產品故障模式庫例項化無法考慮所有業務流程，業務流程可靠性分析也不會考慮所有故障模式。故障場景分析即是將測試物件分析結果與故障模式相結合，將系統結構、組網架構、業務場景和關鍵資料融入到故障模式和業務流程的分析中，分別生成故障模式用例、功能測試異常用例、效能測試異常用例，共同構成可靠性用例。

3、可靠性測試框架

一個完整的可靠性測試框架主要由四部分組成，業務背景流量、啟用故障的平臺或工具、被測物件及故障後的監控平臺（主要用於監控故障注入後的告警、隔離恢復時間）。

可靠性測試框架：

業務背景流量是由業務的基本功能或效能場景組成的，主要是用來在故障注入前和故障注入後檢測業務是否正常，故障注入前需保證業務0錯誤才能準確看到故障注入後系統的反應；故障注入後檢查業務背景流量主要是為了觀察故障後業務的隔離恢復時間。

啟用故障的方式有兩種，（1）透過業務場景的構造觸發故障自然發生；（2）故障注入測試：直接模擬某種故障，屬人為產生故障。

業務場景構造測試方法：

壓力測試：透過使系統達到一定的負荷狀態(或超過其設計的最大負荷)，用以檢驗系統在資源利用率高的情況下的工作狀況；

長穩測試：在一定的壓力狀況下系統持續較長時間執行能力的測試；

異常業務場景測試：透過異常操作、業務配置、異常業務流量等構造異常業務場景進行測試，主要有：主備倒換、插拔網線、觸發時序類問題等。

故障注入測試方法：

網路級故障注入：覆蓋網路組網相關的介面、鏈路、物理連線、時間時鐘等故障物件的故障模式；

系統級故障注入：覆蓋單系統內的鏈路、時間時鐘等故障物件的故障模式的模擬；

資源類故障注入：覆蓋程序在使用記憶體類（動態記憶體、訊息包、訊息佇列）、CPU、硬碟/FLASH等

系統資源類故障物件的故障模式；

資料類故障注入：覆蓋資料庫、檔案等資料類故障物件的故障模式；

介面健壯性測試：覆蓋系統中的各種介面協議訊息及其對應的故障模式；

硬體故障注入：覆蓋硬體平臺中的單板、硬碟、記憶體、網絡卡晶片、CPU、匯流排、控制器等故障物件的故障模式。

被測物件系統即為將要注入故障的受體。

故障後的監控手段通常也叫做運維可靠性主要包括告警、故障恢復時間、故障恢復指南、日誌定位能力等，用於檢測系統在故障後的糾錯能力。

4、結束語

可靠性測試的關鍵是瞭解業務組網、架構和業務場景。基於業務組網和架構選擇合適的故障模式，在合理的點注入故障，然後得到預期的效果。可靠性測試分析既要求測試人員瞭解客戶應用場景，又要求熟悉系統業務流程，所以需要測試人員和開發人員共同完成。

從客戶應用的角度進行：客戶應用場景是測試人員擅長的，對指導測試也比較直接。主要有：大業務壓力、長時間執行、業務疊加、多服務同時操作裝置、流量模型、異常報文、業務配置順序、異常操作等。

從系統實現的角度進行：需要開發和測試團隊合作進行分析。主要有：時序問題、記憶體洩漏、元件失效、CPU過載等。