在數字經濟快速穩定發展背景下，云計算已經成為企業數字化轉型的基石。

應用層追求更全面、更便利、更快捷的服務，逆向推動技術層面系統越來越龐大，持續維護系統的難度與日俱增，故障的發生不可避免，如何保障業務持續的高可用性和穩定性成為了大家面臨的挑戰！

在穩定性保障能力建設方面，互聯網公司的思考及實踐已較為深入，從混沌工程到可觀測性、從全鏈路壓測到應用多活。相對而言大部分國內傳統企業還處于大型機到分布式、云原生化改造的階段，對穩定性保障能力建設的路徑、障礙并不清晰，對穩定性保障技術價值仍不明。

針對可靠性測試的挑戰，混沌工程在一定程度上給出了解法，但如何運用平臺的工具進行可靠性測試實踐？ 為此PerfMa混沌工程產品負責人葉青山先生，將從可靠性問題分析、可靠性測試方案、尋找可靠性分母、構建可靠性用例、可靠性用例執行等維度，全方位給大家演示如何推進企業系統穩定性能力建設。

可靠性問題分析

隨著IT和互聯網行業的快速發展，軟件系統的復雜度逐步增加，分布式技術架構成為主流。微服務，數據庫，緩存，對象存儲，消息等各種分布式組件構建成復雜的分布式系統。大型的分布式系統會有成千上萬的節點，這些節點在長期運行的時候，會不可避免的出現匿機、斷網、磁盤損壞等各種故障。

分布式組件一般都面向故障進行相關的可靠性設計，通過主備、集群、鏡像、哨兵等多種方式保障系組件的分布式可靠性，那么在實際部署運行環境，如何確保這些設計依然是有效的就會是一個具備一定挑戰性的測試工作。

故障根因分類

目前主流的分布式系統的可靠性分析一般從設施層，數據層，操作系統&語言層，中間件層，服務層進行分層分析。

可靠性測試方案

可靠性測試方案三大步驟：

1. 對業務系統進行可靠性風險分析，構建風險場景庫
2. 根據風險場景，構造可靠性用例
3. 基于混沌工程進行可靠性用例執行

可靠性測試目標：提升SLA

可靠性測試分母

下圖是一種風險場景分類，一般來說，每個中間件都會有對應的一類風險場景。

而且我們中間件在做風險分析的時候，會取決于它的一些部署架構，你的一些主從部署跟集群部署，或者你采用哨兵模式，他解析出來整個風險場景是都會有他自己的一些具體的風險項。所以我們這邊也是大致做了一些分類，就是不同的中間件有自己的一些風險庫 

風險項模型

1. 定義狀態指標，狀態指標是可以定衡量的一個系統都可以衡量的一個東西，最好是一個量化的。
2. 正常運行狀態，作為穩態的描述，我們定義了一個資源，指標是什么，范圍區間是什么？那包括這個穩態如果被破壞以后，它可能產生什么樣的風險和故障。
3. 我們如何去保障穩態，它應該在什么范圍內，用什么技術手段去保障它的運行
4. 就是，我定義的一些穩態，一些技術上我的驗證手段是什么 ，我怎么去這驗證的更多是一些破壞性能，就是我如何破壞這個穩態，那混沌工程是一種手段，剛才我們說的一些壓測或者人為破壞也好，手段不限，只要你把它能破壞掉就可以。
5. 發現能力，風險巡檢包括這個度量能力息息相關的。
6. 應急能力，應急里面可能是定義了一些你的自愈能力的要求。

風險項巡檢流程

一個風險項巡檢的例子

假設支付結果頁對廣告投放是個弱依賴，那么在對下游廣告投放服務進行故障注入后，整體的業務成功率沒有變化，耗時增長。整個演練流程如下：

仿真環境需要具備：

• 和線上環境部署架構一致的業務系統
• 規則完善的監控系統
• 具備應急能力的運維平臺
• 具備故障注入能力的混沌工程平臺

具體執行步驟：

混沌工程介紹

混沌工程平臺能力

• 混沌工程平臺底層故障注入能力豐富
• 平臺具備專家場景，便于測試團隊人員快速落地。
• 可應用在可靠性測試，應急驗證，攻防演練等多種場景。

可靠性測試未來展望

隨著混沌工程理念在國內的發展，逐漸有測試團隊進行引入和應用，但是整體還是偏工具使用，缺乏體系化和完善的方法論。目前來看，未來可以從以下一些方面進行發展。

相關可靠性測試體系的建立

基于混沌工程的可靠性測試，從用例設計，用例執行，故障注入，測試分析等方面看，目前還沒有一個行業通用的標準和規范。隨著行業的發展，相信相關的標準和規范也會產出。

可靠性測試平臺的建設

對比功能測試，性能測試，行業內已經有很多成熟的工具平臺提供。目前混沌工程的工具平臺也比較多了，但是基于混沌工程的可靠性測試工具平臺市場上還沒有，相信在不久的將來，隨著基于混沌工程的可靠性測試越來越多的落地實踐，相關的工具平臺必然會產出。

前端可靠性測試

移動互聯網時代早已到來，但是目前主流的混沌工程還是偏服務端應用，從完整的技術鏈路來看，在前端進行可靠性測試也是一個發展方向。