乾貨|混沌工程落地的六個階段

從筆者所在團隊的實踐出發，咱們將混沌工程總結爲六個階段，並對各個階段的落地過程加以總結，但願可以對你們落地混沌工程有所幫助。今天主要是拋磚引玉，後續針對每一個階段，陸續會有專門的文章進行介紹。而混沌工程理論相關的部分，你們能夠參考由 Netflix 出版的《混沌工程》迷你書。

混沌工程落地的六個階段

上述各階段涉及的部門和人員的數量，遠遠超過了當初的預估，所以該部分紅爲咱們肯定順序的最主要因素，強烈建議你們實施混沌工程，必定要爭取來自於管理層的支持以及周邊團隊的理解和配合，不然很容易致使項目有始無終。

單機破壞

重要性說明

以集羣選主機制爲例說明單機破壞的優先級和重要性，若是單機在某些場景異常後，集羣沒法選主，進而致使系統總體不可用。該問題若是在單機房破壞場景時才發現，那系統總體不可用了，你還能找出啥別的問題呢？一個機房的破壞場景，每每涉及多個部門的聯動，大部分業務團隊的各種角色均會參與其中，難道最後就獲得一個結論：選主機制有問題。若是真是這樣，你還打算繼續幹下去嗎？

排序考慮

單機破壞可以在測試環境中發現絕大多數問題，並能掃清後續階段的阻塞點，所以排在首位可謂是當之無愧。

破壞手段

在測試環境下，先從重啓服務器開始，而後是關機，資源異常（如 CPU 打滿）等場景。注意單機破壞場景不要把本身」拒之門外」。舉個例子，把機器的 CPU 打滿，可是沒有設置打滿的時長，結果本身也沒法登陸機器了，只能重啓。https://github.com/Netflix/SimianArmy/tree/master/src/main/resources/scripts

落地建議

• 初期僅在測試環境中進行，僅進行重啓場景的驗證就足以發現不少問題；

• 給出單機破壞的所有場景和驗收方法，由各個團隊自行落地；

• 不戀戰，只要問題不阻塞單機房破壞環節，不影響黃金流程便可進入下階段。

單機房破壞

重要性說明

單機房故障是形成服務總體崩潰的主要緣由之一，全球互聯網巨頭大多發生過單機房故障致使服務崩潰的情形。諸如外網出口異常，內網跨機房專線異常，機房核心交換機異常，各類網絡抖動和擁塞，IDC 供電設備異常等等，相信你們都不陌生，所以其重要性可見一斑。

排序考慮

高頻故障場景，故障後影響較爲嚴重，業界有較多的最佳實踐可供參考，模擬單機房破壞的難度和風險均較低，所以緊隨單機破壞其後。

重破壞手段

將跨機房的專線端口關閉便可，恢復則是將端口從新 up 便可，整個耗時能夠控制在秒級。演練前，業務方須要提早將流量遷移到其餘機房，觀察跨機房的殘餘流量符合預期後再進行操做，不然就對殘餘流量進行排查，從而避免發生較爲嚴重的故障。

落地建議

• 若是近期公司內部發生相似的單機房故障，那是單機房破壞發起的最佳時機；

• 經過數據分析來揭示風險，如跨機房交互的模塊數量及比例，跨機房的流量帶寬的增加趨勢、使用率和成分分析，每次機房級網絡調整各個業務受影響程度的統計，各個業務方對較大網絡操做的接受度等；

• 藉助網絡調整的機會，來間接實現第一次單機房破壞；

• 若是僅僅破壞部分機房（如全部在線機房）是不足以發現全部的問題和隱患的，須要對全部機房逐一進行一次演練，才能發現一些潛藏的依賴和問題；

• 單機房破壞的時間點儘可能參照網絡調整的時間點，大多數在凌晨 1 點左右進行。

依賴治理

重要性說明

依賴主要是第三方依賴和基礎設施，包括但不限於 Mysql、Redis、K8S、DNS、LB、ELK、Hadoop 等，上述任何服務的故障，對業務影響都極爲嚴重。以近期發生的 AWS 的 DNS 故障爲例，持續 15 小時，多個業務受損。

排序考慮

基礎設施可謂是牽一髮動全身，故障頻率低，故障影響大，所以依賴治理放在了單機和單機房以後。

破壞手段

基礎服務和通常的業務場景無區別，主要也是經過單機破壞和單機房破壞等通用手段來進行快速的問題識別。

落地建議

• 對於依賴的破壞，爲了減小對業務方的影響，初期能夠經過業務方的測試 / 預發環境 + 依賴的正式環境組合來進行破壞，也能夠在離線機房對基礎設施進行破壞；

• 基礎設施很大佔比是開源軟件，進行 Trace 的改形成本較高，所以要了解第三方依賴內部的關鍵點，並針對性的進行破壞演練。以 Mysql 爲例來講，通常 Mysql 前面都會有一層 Proxy，若是 Proxy 正常，而 Mysql 異常會發生什麼問題呢？事實證實，不少坑都在這個地方，而要想發現這個坑，那必然須要對 Mysql 的業務有必定的理解，也就是所謂的白盒；

• 攘外必先安內，各種依賴大部分都是其餘部門提供的服務，溝通成本和配合度上會有區別，所以須要先搞定自身的問題，而後再來進行第三方的依賴治理，否則很容易被人懟回去，畢竟不少依賴屬於基礎設施，牽一髮動全身，人家配合的成本也是極大的；

• 對於循環依賴須要在架構層面明確原則，而後再進行總體的改造。

全鏈路故障注入

重要性說明

所謂的精準注入，隻影響特定的客戶 ID、地域、設備類型、接口，還能夠對注入的行爲和比例等進行精準控制，從而大幅縮小故障範圍，將故障的風險收斂到最小。由於是精準注入，所以必須具有全鏈路的觀測能力，纔可以將上述的細微的注入影響進行描述，不然，你可能很難回答，延時增長了 3s，是哪些模塊的做用致使的。

傳統的破壞方式，粒度只能控制在單機級別，不少影響非預期且及不可控。以 TC 命令爲例，若是是按照必定比例進行破壞，你沒法精準控制哪些請求會受到影響，運氣足夠差的狀況下，也許你不但願被影響的請求全軍覆沒，而你指望被影響的請求則無一命中。另外，傳統的破壞方式也沒有統一的標準，有些須要用 tc 命令，有些是 iptables 命令，有些是寫死 /etc/hosts 文件，沒有方便易用的方式，且自己存在較大的風險，很難進行大範圍推廣。下面是二者的對比：

1tc qdisc add dev eth0 root netem delay   1000ms  500ms
2tc qdisc add dev eth0 root netem loss    7%      25
3iptables -A INPUT -p udp -m udp --dport 53 -j DROP
4iptables -A INPUT -p tcp -s 10.0.0.0/8  -m limit --limit 500/s --limit-burst 100 -j ACCEPT 
5echo "127.0.0.1 s3.amazonaws.com" >> /etc/hosts

排序考慮

全鏈路追蹤能力是故障注入的基礎，須要全部的模塊所有進行適配改造，不然調用鏈就會在某個階段中斷，進而致使不可徹底追蹤。同時對於一些開源軟件，也須要進行適配，其成本是前四個階段中最高的，耗時最長的，所以，故障注入每每會放在後期。

破壞手段

微服務化通常是基於 Istio 進行注入，或者在接入層進行注入都可。此處咱們也在 Istio 的緊張改造中，後面能夠給你們寫專門的文章進行分享。

落地建議

對系統進行分級，首先將黃金流程進行改造，確保最核心的功能具有了能力，而後慢慢外擴到全部功能

CI/CD 整合

上述的四個手段，只能解決線上的存量問題，但沒法阻止增量問題。所以，還須要將上述的各類能力，整合在 CI/CD 過程中，在測試階段進行攔截，從而完全杜絕這類問題在線上發生的可能性。該部分目前咱們也正在逐步建設和完善中，所以各類坑後續慢慢交流。

產品化

雖然經過 CI/CD 階段的整合，能夠將問題攔截在測試階段，但這時候，每次都是測試階段發現問題後讓研發返工，對於研發就形成了極大的資源浪費。所以，須要將混沌工程造成的各類標準和規範，以產品化的形式交給研發同窗使用，進而讓你們都滿意。

以單機起停腳本爲例進行說明，每一個模塊的研發不一樣，可能存在的問題也不同，這時候，發現問題後進行修改，不如提供一個統一的服務起停管理工具給研發使用，從而完全解決該問題。開源軟件相似 Systemd，Supervisor 和 Monit 均可以很好的解決這類問題，且對程序沒有侵入性，不存在什麼改形成本。

再高階一些，就能夠參考 Netflix 開源的各類軟件 https://github.com/Netflix/

參考文章：

• Chaos Monkey 升級了(https://www.infoq.cn/article/2016/11/chaos-monkey-upgrade)

• Gremlin 發佈面向混沌實驗的應用級故障注入（ALF）平(https://www.infoq.cn/article/2018/10/gremlin-alfi)

 

點擊「連接」參與京東雲優惠活動！

歡迎點擊「京東雲」瞭解更多精彩內容。