如何讓混沌工程實驗降本增效

“混沌工程實驗價效比太低了。測試、研發和運維三個部門都投入了大量人力物力，在準生產環境做了不少故障注入實驗。但發現的問題還是比較少。”在一次混沌工程實踐回顧會上，一位測試人員如是說。

近十幾年來，隨著企業業務不斷微服務化，並遷移到複雜分散式的雲生產環境，雲上各個微服務業務系統之間相互訪問的穩定性，以及與所依賴的第三方系統之間相互訪問的穩定性，都會受到錯綜複雜的雲生產環境的未知暗債(“暗債”是 IT 系統中具有以下特點的漏洞——在引發故障之前，這些漏洞不為人知或不可見。"暗債“源自物理學術語“暗物質”，兩者都能影響世界，但人們卻無法直接檢測或看到它們。)的影響，而損害業務連續性。混沌工程就是業界在應對上述問題的過程中孕育而生的良好實踐。

透過在測試環境和生產環境上，注入經過精心設計並控制好爆炸半徑的故障，進行故障注入實驗，就可以觀察和學習複雜分散式系統的執行模式和失效模式，從而提升團隊的系統穩定性設計，讓團隊能夠快速應對業務系統在雲環境上的未知故障。

我們知道，要想保持業務系統在雲環境上執行的穩定性，離不開包括業務、研發、測試和運維部門的密切協作。這家企業的這4個部門的協作情況是怎樣的呢?

最先響應運維部門實踐混沌工程召喚的，是測試部門。測試部門認為混沌工程的故障注入實驗，能豐富他們的壓力測試和探索性測試的場景，從而發現更多軟體缺陷。

然而相比之下，研發和業務部門的一線人員對此的參與度卻不夠高。他們認為，混沌工程的故障注入實驗，其實就是另一種測試而已。

確實，測試部門就是把混沌工程故障注入實驗，當作探索性測試來做的。“混沌工程實驗，類似於探索性測試。實驗本身沒有明確的輸入和預期的結果，而是透過對系統和服務的干預，來觀察系統的反應。”測試人員在測試總結中這樣寫道。

缺乏明確的穩態行為假說

由於測試人員使用探索性測試的方法，來實踐混沌工程故障注入實驗，所以在實驗結果報告中，找不到“系統穩態行為假說”的字眼。只是在“風險問題”的以下描述中，隱約看到穩態行為假說的影子：“預期主節點的docker服務關閉後，kubelet/api/etcd/controllers等pod會失效，之後這些核心服務的程式會重啟，能繼續提供服務”。

隱含的穩態行為假說沒有反映使用者價值

從上面的描述能看出，這個混沌工程實驗的穩態行為假說，並不是沒有，而是隱含存在的，即“能繼續提供服務”。那如何才算“能繼續提供服務”呢?這一點可以從測試方案的監控方式中，看出一點線索。即對於所有實驗，無論注入的故障是什麼，測試人員只關注3類指標：

系統業務指標：

如系統業務交易的錯誤率

系統效能指標：

如系統業務交易的TPS(每秒事務處理量)和響應時長的變化趨勢

系統資源指標：

如系統的CPU、記憶體、磁碟IO和網路資源指標的變化趨勢

看到這3類指標，我產生了一個疑問：“使用者真的在乎業務交易錯誤率和TPS變化趨勢嗎?”我相信，使用者會更在乎自己下的訂單，是否能在3秒內成功處理。這一點所有人都能很好理解。那未能反映使用者價值的穩態行為假說，會導致什麼後果呢?或許這種充滿技術細節的穩態行為假說，不便於業務人員和領導直觀感知其業務影響，吸引不了他們的注意，從而喪失了獲得他們支援的機會，並弱化了實驗的價值。

隱含的穩態行為假說不夠量化

再看上面這個透過觀察TPS變化趨勢來判斷是否“能繼續提供服務”的例子。如果這個實驗是由測試人員手工執行的，憑藉豐富的經驗，測試人員是能判斷系統是否“能繼續提供服務”的。但如果將這個實驗自動化，用工具在晚上自動執行實驗，那麼工具該如何界定系統是否“能繼續提供服務”呢?所以要想實現自動化，必須要把穩態行為的假說進行量化，以便工具自動執行實驗。

良好穩態行為假說示例

這裡試著給出一個能反映使用者價值，且有量化指標的穩態行為假說的示例：

即使在例項失效的條件下，系統仍然能在3秒之內，完成已受理的使用者的交易，否則也能在5秒之內提示使用者業務暫時不可用。

這個穩態行為假說，不僅體現了成功場景，也體現了失敗場景。

良好穩態行為假說能節省實驗成本

如何設計一個能節省實驗成本的穩態行為假說呢?讓我們看看發生在這家企業測試人員身上的故事。

這些測試人員正在使用一款開源工具，來進行混沌工程故障注入實驗。由於這款工具，提供了5種可供注入的原子故障，於是測試人員也就設計了5個實驗。如果用上述示例的寫法，來編寫穩態行為假說的話，會是這個樣子：

實驗1的穩態行為假說：

即使在例項中止的條件下，系統仍然能在3秒之內，完成已受理的使用者的交易，否則也能在5秒之內提示使用者業務暫時不可用。

實驗2的穩態行為假說：

即使在例項CPU爆滿的條件下，系統仍然能在3秒之內，完成已受理的使用者的交易，否則也能在5秒之內提示使用者業務暫時不可用。

實驗3的穩態行為假說：

即使在例項記憶體爆滿的條件下，系統仍然能在3秒之內，完成已受理的使用者的交易，否則也能在5秒之內提示使用者業務暫時不可用。

實驗4的穩態行為假說：

即使在例項磁碟爆滿的條件下，系統仍然能在3秒之內，完成已受理的使用者的交易，否則也能在5秒之內提示使用者業務暫時不可用。

實驗4的穩態行為假說：

即使在關閉例項網路的條件下，系統仍然能在3秒之內，完成已受理的使用者的交易，否則也能在5秒之內提示使用者業務暫時不可用。

如果手工執行每個實驗平均花30分鐘，那麼執行這5個實驗，要花150分鐘。

等一下!我們是企業的測試人員，不是開源混沌工程工具的測試人員!這5個原子故障好比病毒，它們所導致的症狀都是同一個——例項失效。而對於企業的測試人員，只要從上述5個故障中任選一個注入，就能達成讓例項失效的目的。畢竟測試人員只須關注業務系統在例項失效後，是否能繼續提供服務。換句話說，這5個原子故障，同屬一個等價類。對於等價類，我們只要注入一個原子故障就夠了。如果一定要全面注入這5個原子故障，那麼可以在以後的各輪迴歸實驗中，每輪實驗依次輪流選擇一種不同的原子故障注入即可。這樣對於“例項失效”的實驗，我們就能節省80%的實驗成本。這下你就知道上面的良好穩態行為假說示例，為何要寫“症狀”了——“即使在例項失效的條件下”。這也在某種程度上，揭示了文章一開頭測試人員所抱怨的混沌工程實驗“價效比太低”的原因。

這個故事給我們的啟發是，如果針對“症狀”而不是“病毒”來設計系統穩態行為假說，就能幫助我們識別等價類，從而只選擇少量的“病毒”注入，達成同樣“症狀”的效果，進而降低實驗成本。

總結

編寫反映使用者價值、便於量化且針對“症狀”的系統穩態行為假說，能讓混沌工程實驗的價值更容易讓業務人員和領導理解，從而獲得他們的支援，也能更有利於自動化，並能透過等價類劃分，來降低實驗成本，進而達成降本增效的目的。