特來電混沌工程實踐

1、導語

隨着大型分佈式系統架構的演進和普遍應用，軟件工程的最佳實踐也隨之改變。
咱們經過分佈式、服務化、DevOps、敏捷開發，快速響應業務的需求變化，支持大規模分佈式應用。但這些作法帶來效益的同時，也帶來了另外一個緊迫問題：咱們到底有多少把握來確保線上複雜的系統可以正常工做呢？
即使是分佈式系統中每一個獨立的服務都正常工做，服務之間的相互調用也仍然可能形成不可預期的結果。這些結果在現實中可能不多發生，可是一旦發生就會影響整個生產環境，使得整個分佈式系統變得混亂不堪，甚至出現服務雪崩、系統全面宕機。

不是由你來選擇那一刻，而是那一刻來選擇你！
你只能選擇爲之作好準備。
　　　　　　　　　　 —消防隊長 Mike Burtch

所以，咱們有必要在線上事故出現以前，提早識別出系統的有哪些弱點、這些弱點的影響範圍。咱們須要一種方式來管控這些系統的固有混沌，在保證快速響應業務需求變化的同時，作到最後無論系統有多複雜，咱們的線上應用經得住各類「戳」。

經過應用一些經驗探索的原則，來觀察系統是如何反應的。這就跟科學家作實驗去學習物理定律同樣，經過作實驗去了解整個系統。咱們從受控的試驗中掌握分佈式系統運行行爲的過程，稱爲混沌工程。

混沌工程不是製造問題，而是揭示問題。
              —Nora Jones，Netflix 高級混沌工程師

混沌工程的典型實踐-Chaos Monkey，搗亂的猴子；拜 Netflix 所賜，如今大部分的混沌工程項目都叫作 Monkey，也就是一隻搗亂的猴子，在你的系統裏面上蹦下竄，不停搗亂，直到搞掛你的系統。

爲何須要混沌工程：

應用混沌工程能夠提高整個系統的彈性。經過設計而且進行混沌實驗，咱們能夠了解到系統脆弱的一面，在還沒出現線上事故以前，咱們就能主動發現這些問題，並儘量的解決這些問題。

混沌工程和測試有什麼區別：

雖然混沌工程跟傳統測試一般都會共用不少測試工具的，譬如都會使用錯誤注入工具，但：
混沌工程是經過實踐對系統有更新的認知，而傳統測試則是使用特定方式對某一塊進行特定測試。
譬如在傳統測試裏面，咱們能夠寫一個斷言，咱們給定特定的條件，產生一個特定的輸出，若是不知足斷言條件，測試就出錯了，這個實際上是具備很明確的特性。但混沌工程是試驗，而試驗會有怎樣的結果，咱們是不肯定的。
譬如咱們能夠進行下面的這些試驗：

• 模擬整個 IDC 宕機
• 選擇一部分網絡連鏈接注入特定時間的延遲
• 隨機讓一些函數拋出
• 異常強制 NTP 時間不一樣步
• 生成 IO 錯誤
• 榨乾 CPU

這些混沌試驗到底會有什麼樣的結果，有些咱們能夠預料，但有些可能咱們就不會預先知道，只有發生了，纔會驚訝，
「啊，怎麼會這樣！」

2、混沌工程的方法論

既然是工程，那麼就會有方法論，也就能詳細的概括總結出來實施的步驟
1. 混沌工程的通常實施步驟

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

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

2. 實施混沌工程的推薦原則
 2.1. 根據「穩定狀態下系統的特徵」作一個假設
 以充電爲例，充電服務可能包含了訂單服務，開啓充電、結束充電、電量更新服務，帳戶服務、計費策略服務，「假設」不是着眼於各個「螺絲釘」服務的具體狀態，而是着眼於整個充電系統正常運做下的外部表現(狀態)，如開啓充電TPS、正在充電中訂單數、電量更新 TPS、結束充電TPS、充電服務異常等等，這些監控指標曲線通常不會大起大落，其變化趨勢是能夠預期的。
 可是有一點須要特別注意，某些問題雖然不會怎麼影響總體監控指標，
 可是仍然須要監控系統中各個節點的微觀指標（如CPU、IO等）。

 2.2 事件是現實世界真的可能發生的
任何可能影響系統穩定狀態的均可以做爲事件，常見的，如
故障類：像服務器宕機、重啓、斷網等硬件故障、服務超時、Nginx不可用、核心應用未重啓等應用故障；
非故障事件：像流量激增
同時，還能夠分析曾經引發系統故障的事件的種類和頻次，針對性的排列優先級，並復現這些事件，避免系統再次出現這種故障。

 2.3. 在生產環境跑
根據第1條，通常只有生產環境的指標是可預測的，如每日充電訂單量、開啓充電量、電量更新TPS等。並且，因爲測試環境和生產環境不可能如出一轍，爲了真實反映系統的可靠性，通常推薦在生產環境實施混沌工程。

 2.4. 持續集成
線上應用天天都在更新，因此像跑持續集成同樣實施混沌工程，持續發現問題、解決問題。

 2.5. 最小化影響範圍
 混沌工程可能致使線上功能不可用，甚至形成宕機事故，因此在以找出系統弱點爲目的的前提下，須要最小化故障影響範圍，而且當出現嚴重問題時能夠迅速恢復，即故障是可控的。鑑於此，須要控制最小化影響範圍。

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

階段一：分佈式系統彈性化通常
以京東爲例，他們會在雙十一大促以前進行故障演練，將團隊分爲兩組，一組做爲故障的製造者，另一組做爲故障的解決者和響應者，來考察故障發生的時候，團隊對故障的檢測、響應、處理還有恢復能力。達到小的故障不須要人介入，大故障人工介入能夠快速處理的目的。經過在大促以前的兩個月期間密集的開展混沌工程，提升團隊對大規模故障的容錯能力。

階段二：分佈式系統彈性化成熟
以Netflix爲例，他們基本上已經在按照上述理想的步驟和原則實施混沌工程，工做日持續、自動的實施混沌工程，系統具有高度的可靠性，彈性伸縮。

3、混沌工程的成熟度模型

混沌工程成熟度模型，Netflix （網飛）總結了兩個維度，一個是複雜度，一個就是接受度。
前者表示的是混沌工程能有多複雜，然後者則表示的是混沌工程被團隊的接受程度。
複雜度分爲哪幾個階段：

 

接受度分爲哪幾個階段：

咱們目前處於起步發展階段，線上生產環境實施混沌工程，風險很大，也不可控，所以：

咱們在壓測模擬環境實施混沌工程，搭建相似生產的小型模擬環境，以正常、合理的測試結果，做爲基準「穩定狀態」。在模擬測試的過程當中，對系統實施各種混沌實驗後，經過觀察測試結果來評估系統的可靠性，從而尋找系統弱點，
登記Bug，進行修復。

同時，經過自動化運維平臺，實現混沌實驗異常注入和持續執行。

4、混沌工程的執行

1. 混沌工程的總體實施流程

2. 混沌事件注入

應用層的混沌事件

 

中間件層混沌事件

數據庫層和基礎實施層混沌事件

3. 混沌實驗閉環

全部的混沌實驗必須實現閉環，發現問題，分析問題，解決問題

所以咱們增長了一類單據統一管理混沌實驗，便於總結、分析、跟蹤

 

以上是咱們今年搞混沌工程，提高系統可用性的一些實踐，分享給你們。

 

周國慶

2019/3/9