可靠性測試竟如此容易

2021-09-26 22:21:56 字數 2714 閱讀 6922

隨著網際網路的快速發展,傳統的單工程的效能瓶頸越發明顯,分布式系統的優點越發突出。分布式系統具有廉價高效的特點,利用效能相對一般的pc橫向擴充套件,提公升伺服器效能,通過軟體來保障系統的高可靠性。

由於分布式系統存在api介面通訊、微服務架構、節點規模大等特點,增加了系統的複雜性和出錯的概率,從而很難確保系統的容錯機制得到充分的驗證,依賴自動化工具來完成對系統端到端驗證是不可避免的。

在業界,混沌工程被定義為「在分布式系統上進行實驗, 以建立對系統抵禦生產環境中失控條件的能力的信心」

基於華為在ict領域10多年的實踐積累和數百產品的實際應用的沉澱,電信領域軟體的高要求,我們通過正向分析、事故分析、業界案例分析三個維度建立全面的故障模式庫。

我們通過軟體模擬各種硬體故障,對應用無侵入,而且跟應用的實現語言無關。

我們實現了智慧型識別故障物件,而且全自動化執行,自動度量kpi,自動實現風險評估,生成測評報告,測試工程可反覆執行。防止失敗的最佳方法就是經常失敗。在真實環境測試,而不是模擬環境。通過我們的端到端全自動化測評,可以實現這個目標。

功能:提供對kubernetes集群、彈性雲伺服器的單業務例項、單故障模式的注入。

適用場景:開發人員針對確定故障的自驗證;測試人員針對可靠性問題回歸驗證等。

特點:操作簡單,故障注入/清除結果及系統的表現清晰可見。

手工注入是混沌工程的入門級功能,操作非常容易,結果直接清晰。

全流程視覺化操作,只用滑鼠點點點就可以了;簡單易用,使用門檻低,非常方便開發者和測試人員進行基本的可靠性測試。

功能:提供對單工作負載的隨機故障注入,預置了多種入門級和高階級演練場景。

適用場景:線下隨機故障注入測試;線上例行故障演練、專項演練等。

特點:模型化的場景定義、靈活的編排排程、豐富的評估報告。

故障演練主要使用場景是線上例行故障演練和專項演練。相比於手工注入,故障演練會提供多種入門級和高階級的演練場景。上圖為傳統的手工演練流程,與混沌工程提供的故障演練能力對比。

三、四年前我們還處於傳統手工演練階段,全流程的手工進行,後續逐步演變為現在混沌工程提供的全自動化故障演練能力,經我們自己實際使用對比,現在的自動化演練過程比手工更準確和規範,避免人為導致的差錯;可靠性專項測試人員投入的時間可以減少80%,端到端效率提公升10倍以上。

我們提供如下的預置模板,同時也支援自定義演練任務。

功能:提供對多工作負載全量的可靠性測評,即將支援

適用場景:雲服務的全量可靠性測評;不同服務、不同版本的可靠性能力對比。

特點:智慧型物件識別、自動用例生成、無指令碼化執行、自動kpi度量、豐富的評估報告。

自動測評最大的特點就是智慧型物件識別、自動用例生成、無需定製指令碼的全自動化執行、自動kpi度量生成豐富的評估報告,可以對不同服務、不同版本的可靠性能力進行對比。

自動測評服務的智慧型物件識別能力,保證了故障物件覆蓋的全面性,能有效避免人工測試出現的遺漏。自動用例生成與無指令碼化執行,大幅節省了用例設計和自動化指令碼編寫的工作,同時降低了自動化可靠性測試對人員技能的要求。

系統預置了3種常見場景模板,同時支援使用者自定義。既可以用預置目標快速建立任務,也可以靈活的定製任務。

混沌工程通過結合華為雲上的cce、ecs、cpts、aom、apm等服務,提供了一套完整的端到端的可靠性測試解決方案,解決了測什麼、如何測、如何評價的問題。

可靠性質量評估架構

在華為雲上,雲服務部署的載體要麼是ecs的彈性雲伺服器,要麼是cce的容器集群,我們現在已經支援對cce容器集群和彈性雲伺服器ecs(linux)進行故障注入。

cpts服務可以實現對應用介面的壓測,在故障注入的同時執行,通過cpts的報告用來評估故障對業務的影響。

aom可以完成對容器、主機的資源監控,以及自定義閾值告警,故障注入後相關的監控資料和告警資料會被寫入混沌工程測試任務的報告中,然後根據可靠性質量評估方法實現自動kpi度量,生成評估報告。

apm提供了呼叫鏈功能,在故障注入後,利用呼叫鏈可以快速完成問題定位分析。

可靠性質量評估方法上,我們採用的是基於可靠性關鍵質量屬性的kpi評估方式,如下圖。從故障模式維度測試物件維度對kpi進行分析,可以針對自己的服務特性,自主調整評估的引數,然後生成測評報告。

評估屬性和方法

戳→傳送門

可靠性測試學習 可靠性測試理解

最近測試可靠性,參考了業界的一些思維,有些想法和建議 先說說軟體可靠性的定義,根據我測試的體會和思考,我覺得軟體的可靠性就是軟體系統發生故障後自動恢復或者人工干預使其能恢復到正常狀態的能力 業界的測試有些把容錯測試和可靠性測試搞混淆,其實兩者不一樣,容錯測試是通過模擬一些可能發生的已知的異常操作而檢...

可靠性測試

在產品前期各個版本中已經分層進行過如下可靠性測試 基於特性的功能可靠性測試 1 首先分析清楚本特性詳細的處理流程,包括涉及的所有部件和協議,訊息的詳細互動過程 如訪問多少次db,每次記錄什麼資料,失敗後如何回滾等,考慮各種異常處理分支 部件間超時配合等 2 針對處理流程考慮如下可靠性因素,主要包括 ...

可靠性測試

可靠性是最初是確定乙個系統在乙個特定的執行時間內有效執行的概率的乙個標準。可靠性的衡量需要系統在某段時間內保持正常的執行。目前,使用最為廣泛的乙個衡量可靠性的引數是,mttf mean time to failure,平均失效等待時間 定義為隨機變數 出錯時間等的 期望值 但是,mttf經常被錯誤地...