混沌工程 - 軟件系統高可用、彈性化的必由之路

隨着摩爾定律的終結，單機計算性能已達到了極限，然而，咱們的軟件系統不管是規模仍是複雜度一直在增加，因此軟件系統都不約而同的朝着分佈式化方向發展。近年來，隨着雲服務、容器的出現，某些分佈式系統也更容易微服務化。拋開這些形形色色的分佈式技術，咱們對系統可靠性的述求倒是一致的：分佈式系統須要高可用，即便出現了單點或集羣故障，也但願系統具有自我恢復或優雅降級的彈性能力、容錯能力。咱們在合理的架構，高質量的代碼，完善的測試等等方面作了不少努力，然而不少分佈式系統仍舊達不到高可用、彈性化，爲了儘量發掘系統中存在的弱點，不少大型軟件公司都引入了混沌工程，如國外的谷歌、網飛，國內的京東等等。哪些能夠稱之爲系統弱點呢，好比

• 外部系統故障，致使內部系統連鎖故障，我司即出現過由於七牛服務故障致使的內部故障
• 服務不可用時，不合適的降級方案
• 不合適的超時機制，致使請求錯誤時無限次重試

混沌工程的定義：

經過觀察分佈式系統在受控的故障注入測試中的行爲變化發掘系統弱點，並針對性的改進，從而提升系統可靠性，創建系統抵禦失控條件的能力的信心。因此，混沌工程並非一個新概念，常見的異地容災測試也是混沌工程的一種應用。

混沌工程的通常實施步驟

• 尋找一些系統正常運行狀態下的可度量指標，做爲基準的「穩定狀態」
• 假設實驗組和對照組都能繼續保持這個「穩定狀態」
• 對實驗組進行事件注入，如服務器崩潰、硬盤故障、網絡鏈接斷開等等
• 比較實驗組和對照組「穩定狀態」的差別，推翻上述第2條的假設

若是混沌工程實施下來二者的「穩定狀態」一致，則能夠認爲系統應對這種故障是彈性的，從而對系統創建更多信心。相反的，若是二者的穩定狀態不一致，那咱們就找到了一個系統弱點，從而能夠修復它，提升系統可靠性。

混沌工程的理想原則：

1）根據「穩定狀態下系統的特徵」作一個假設

以電商下單爲例，下單系統可能包含了商品服務，交易服務，支付服務，「假設」不是着眼於各個「螺絲釘」服務的具體狀態，而是着眼於整個下單系統正常運做下的外部狀態，以下單量、成交金額、系統吞吐量、延時、錯誤率等等，這些指標通常會有大盤監控，並且除非遇到促銷活動，這些指標曲線通常不會大起大落，其變化趨勢是能夠預期的。可是有一點須要特別注意，某些問題雖然不會怎麼影響大盤數據（如緩存失效、一個CDN節點失效等等），可是咱們仍舊須要監控系統中各個節點的微觀指標（如CPU、IO等）以期發現這類問題（緩存失效可能致使Mysql集羣壓力增大，CPU/IO等壓力變大）。

2）事件是現實世界真的可能發生的

任何可能影響系統穩定狀態的均可以做爲事件，常見的，如

• 故障類：像服務器宕機、斷網等硬件故障，像七牛等外部服務不可用的軟件故障
• 非故障事件：像流量激增

咱們還能夠分析曾經引發系統故障的事件的種類和頻次，針對性的排列優先級，並實施這些事件，避免系統再次出現這種故障。

3）在生產環境跑

根據第1條，通常只有生產環境的指標是可預測的，如新用戶日註冊量，用戶日下單量。並且，因爲測試環境和生產環境不可能如出一轍，爲了真實反映系統的可靠性，通常推薦在生產環境實施混沌工程。

4）持續集成

互聯網軟件天天都在更新，因此像跑持續集成同樣實施混沌工程具備現實意義。

5）最小化影響範圍

根據第3條，混沌工程可能致使線上功能不可用，甚至形成資損，因此在以找出系統弱點爲目的的前提下，須要最小化故障影響範圍，而且當出現嚴重問題時能夠迅速恢復，即故障是可控的。鑑於此，有時候能夠引入A/B測試，最小化影響範圍。

上面是最理想狀況下的混沌工程，現實中咱們須要根據現有軟件成熟度有階段的實施混沌：

階段一：分佈式系統彈性化通常

• 以京東爲例，他們會在雙十一大促以前進行故障演練，將團隊分爲兩組，一組做爲故障的製造者，另一組做爲故障的解決者和響應者，來考察故障發生的時候，團隊對故障的檢測、響應、處理還有恢復能力。達到小的故障不須要人介入，大故障人工介入能夠快速處理的目的。經過在大促以前的兩個月期間密集的開展混沌工程，提升團隊對大規模故障的容錯能力。
• 以有贊爲例，因爲咱們纔剛剛開始，爲了控制風險，起初只會在測試環境實施混沌工程，因此暫時沒有能夠參考的準確大盤數據，即合適的基準「穩定狀態」。但也不是不可能，觀察大盤數據能夠認爲反映的是系統宏觀指標，從微觀角度來說，咱們能夠篩選出一批直接影響核心大盤數據（如註冊量、下單量等）的接口，在對系統實施混沌後執行這些接口的場景化集成測試，經過觀察測試結果來評估系統的可靠性，從而尋找系統弱點，這在測試環境是可行的。

此外，混沌工程能夠認爲是通用型異常不定時不定目標不定異常類型的自動化實現，若是拋開這層，手動對目標機器注入特定的一種或多種異常，並輔以對應的異常恢復手段，那咱們就能夠在通用異常測試中應用。

階段二：分佈式系統彈性化成熟

• 以網飛爲例，他們基本上已經在按照上述理想的步驟和原則實施混沌工程，工做日持續、自動的實施混沌工程，系統具有高度的可靠性，彈性伸縮。

有贊混沌工程的實現：

因爲混沌工程主要是注入特定的事件並引發系統故障，既然是「幹壞事」的，因此咱們將其命名成了「威震天」（變形金剛中的反派Boss）。因爲咱們還處於第一階段，因此故障的注入主要是人爲控制，目前已實現的故障類型有：

• CPU高負載
• 磁盤高負載：頻繁讀寫磁盤
• 磁盤空間不足
• 優雅的下線應用：使用應用的stop腳本平滑的中止應用
• 經過kill進程直接中止應用，可能形成數據不一致
• 網絡惡化：隨機改變一些包數據，使數據內容不正確
• 網絡延遲：將包延遲一個特定範圍的時間
• 網絡丟包：構造一個tcp不會徹底失敗的丟包率
• 網絡黑洞：忽略來自某個ip的包
• 外部服務不可達：將外部服務的域名指向本地環回地址或將訪問外部服務的端口的OUTPUT數據包丟棄

參考文獻
PRINCIPLES OF CHAOS ENGINEERING

個人其餘博客
異步系統的兩種測試方法

個人開源項目 —— 方便產品、開發、測試三方協同自測的管理工具
捉蟲記

ps：
有贊測試組在持續招人中，大量崗位空缺，只要你來，就能幫你點亮全棧開發技能樹，有意向換工做的同窗能夠發簡歷到 sunjun@youzan.com