1 Chaos體系
1.1 Chaos之混沌工程
混沌工程是在分佈式系統上進行實驗的學科,通過一系列可控的實驗和執行實驗的原則，揭示出分佈式系統中隨時或天災或人爲發生的各類事件是如何逐步導致系統整體不可用的，目的是建立對系統抵禦生產環境中失控條件的能力以及信心。最近2年國內著名互聯網公司已經開始意識並逐步實施，提高系統服務質量。
1.2 混沌的框架原則的理解
愛奇藝金融科技團隊的混沌原則更多的是應對不可預知場景下系統架構、人員架構對於問題的應對能力，如隔離、告警、自我修復能力等，主要傾向工程層面、架構層面、研發流程體系層面、災難預警恢復層面等。
1.3 Chaos - Monkey
理想的Chaos Monkey是Chaos體系的執行者，是基於場景爲某個特定目標而生的，是一種可執行、可按預期銷燬的手段。它主要負責尋找系統中任意一個盲區，並且利用盲區對系統實現某種程度並且可控的破壞。
2 矛盾大戰的目的和設計
愛奇藝金融科技團隊在高安全、高併發、高可用上遇到了很多挑戰，同時金融系統相比於常規系統，在用戶隱私、資金安全、敏感數據上有極高的要求，因此我們構建Chaos攻防模型，不斷實施攻防對抗，逐步提高系統健壯性，爲業務保駕護航。
目標如下：
- 建立Chaos Monkey的攻擊能力、執行流程來輔助及驗證服務架構的實施效果，從而給架構演進提供指導和參考價值；
- 建立架構與業務的生產關係，達到架構與業務的雙向促進，提高系統穩定性、可用性、健壯性；
- 通過架構與業務生產關係的良性循環，提高技術同學對整個系統的掌控力、技術實力更好的爲業務服務。
混沌工程自循環之生產關係：
- Chaos攻擊能力的建設及升級：
按照不同時期、不同要求、不同目標訓練建設Chaos Monkey的可實施、可落地的攻擊能力。
- 制定計劃及設置風險範圍：
Chaos Monkey能力訓練滿足要求後，按照假定目標制定整個實施計劃，包括執行時間、執行過程、影響範圍、執行手段、結果預期、故障恢復、是否靜默執行等，最後進行自動化實施準備。
- 執行與反饋：
執行前check無異常後開始實施同時觀察監控系統、業務系統、告警系統，實施結束後恢復當前系統並給出相應反饋包括詳細描述，優化建議等。
- 系統優化及能力提升：
業務owner收到結果反饋後需對已存問題進行review、評估整改方案、修復計劃並檢查同類問題，最後進行系統升級。
- 修復驗證及業務需求：
收到業務系統升級上線通知後再次與業務review預期目標，然後進行驗證性攻擊檢驗修復效果同時記錄case庫。
業務owner也可以向Chaos Monkey申請攻擊來驗證當前系統的真實情況。
3 Chaos 攻防的拷問及設計實施原則
Chaos 攻防的拷問：
-
支付、金融 架構設計 是否存在問題？
原來的架構設計是不是不再符合我們的預期了？
設計方案和當前生產系統實現之間差了多少？
-
支付、金融 服務底線 都是什麼，支付、金融服務的隔離顆粒度？
我們能承受哪些，能承受多長時間，我們不能承受哪些？
-
我們 系統的高可用程度 ？
高可用節點切換過程會發生什麼？
HA的切換手段、切換(不可用)的間隔？
切換成功的時間和一致性的時間是不是有關？等等。
設計實施原則：
- 爲設計漏洞、代碼缺陷而生同時面向生產環境，做到要發現問題更要可控;
- 不拘於手段和形式。不論是使用開源工具，還是切斷網線、偷偷殺掉進程、還是進程植入，內存數據篡改都是一種面向某個目的可實施手段;
- 監控告警輔助支撐，最大化風險評估，細化到流量的損失控制等。
4 攻防戰績
4.1 執行大類分佈
4.2 已執行攻防case分類列表
4.3 實戰案例舉例
例1：驗證支付系統微服務Spring Cloud套件的高可用機制
涉及Eureka Server、Client、Ribbon LB及當前業務對配置掌握的合理性。
- 驗證結果： 當前架構能在30s內應對下游節點的無前兆故障。
- 優化建議： 調整LB的探測時間，Eureka Client、Ribbon Cache緩存時間，服務心跳續約，Eureka Server服務剔除、數據同步時間等加強架構對故障的應對能力同時減少類似問題對業務的影響。
例2：攻擊金融業務系統中非核心依賴的中間件
暴露發現系統設計的健壯性問題。
- 執行結果： 非核心依賴中間件發生服務抖動、服務故障時系統無降級策略，直接導致整個業務無法服務，不符合架構原則。
- 優化建議： 業務系統增加對非核心依賴故障的降級及切換策略。優化連接池配置來應對當非核心依賴中間件出現問題時降低性能損耗及減少切換的時間差。
5 思考總結
5.1 總結
隨着Chaos體系的逐漸成熟，體系內自驅力逐漸減少，Chaos會進入一個新的階段就是常態化。這個階段不再是以暴露發現系統現有實施問題爲主，而是面向系統架構的將來以及系統健壯性、可用性的穩固。主要有以下幾點：
（1）自動化安全巡視
Chaos將進入不定期按照已經積累case庫進行自動化巡檢。
（2）基礎架構高可用由誰來監控
Chaos進行不定期面向架構層面進行實彈演習，檢驗他們的戰備值班能力。
（3）新技術、中間件的探索驗證
對於新技術、新中間件甚至是自研的中間件可利用Chaos Monkey進行符合業務需求的健壯性、可用性探測驗證。
（4）舉一反三
建立線上故障case庫，定時重播線上故障。
5.2 思考
（1）讓業務能更直觀的感覺到他守護的東西及帶來的價值；
（2）增加覆蓋面，有的放矢，針對實際情況調整目標及方向；
（3）建立可視化、模板化能力。豐富case庫並支持重複攻擊演練及跟蹤。
本文轉載自公衆號愛奇藝技術產品團隊（ID：iQIYI-TP）。
原文鏈接：