淺談云上可靠性測試
引言
疫情之下,科技支撐有目共睹,多個產業迎來逆勢增長。科技創新賦能的“云技術”,不再僅僅是戰“疫”的重要工具,更將帶動全社會的數字化轉型,對產業發展產生深遠的意義。而在產品上云之前,云上數據的可信(安全性、可靠性等)一直是大家關注的重點。
近年來,云上可靠性事故的案例層出不窮。如:
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過載等。
網絡
版權聲明:本文內容由網絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容,請聯系我們jiasou666@gmail.com 處理,核實后本網站將在24小時內刪除侵權內容。
版權聲明:本文內容由網絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容,請聯系我們jiasou666@gmail.com 處理,核實后本網站將在24小時內刪除侵權內容。