混沌工程六個階段
從筆者所在團隊的實踐出發，我們將混沌工程總結爲六個階段，並對各個階段的落地過程加以總結，希望能夠對大家落地混沌工程有所幫助。今天主要是拋磚引玉，後續針對每個階段，陸續會有專門的文章進行介紹。而混沌工程理論相關的部分，大家可以參考由Netflix出版的《混沌工程》迷你書。
上述各階段涉及的部門和人員的數量，遠遠超過了當初的預估，因此該部分成爲我們確定順序的最主要因素，強烈建議大家實施混沌工程，一定要爭取來自於管理層的支持以及周邊團隊的理解和配合，否則很容易導致項目虎頭蛇尾。
單機破壞
重要性說明
以集羣選主機制爲例說明單機破壞的優先級和重要性，如果單機在某些場景異常後，集羣無法選主，進而導致系統整體不可用。該問題如果在單機房破壞場景時才發現，那系統整體不可用了，你還能找出啥別的問題呢？一個機房的破壞場景，往往涉及多個部門的聯動，大部分業務團隊的各類角色均會參與其中，難道最後就得到一個結論：選主機制有問題。如果真是這樣，你還打算繼續幹下去嗎？
排序考慮
單機破壞能夠在測試環境中發現絕大多數問題，並能掃清後續階段的阻塞點，因此排在首位可謂是當之無愧。
破壞手段
參考Chaos Monkey的代碼，注意單機破壞場景不要把自己”拒之門外”。舉個例子，把機器的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文件，沒有方便易用的方式，且本身存在較大的風險，很難進行大範圍推廣。下面是兩者的對比：
tc qdisc add dev eth0 root netem delay 1000ms 500ms
tc qdisc add dev eth0 root netem loss 7% 25
iptables -A INPUT -p udp -m udp --dport 53 -j DROP
iptables -A INPUT -p tcp -s 10.0.0.0/8 -m limit --limit 500/s --limit-burst 100 -j ACCEPT
echo "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/
參考文章：