這是一篇較為詳細的混沌工程調研報告,包含了背景,現狀,京東混沌工程實踐,希望幫助大家更好的了解到混沌工程技術,通過混沌工程實驗,更好的為系統保駕護航,
一、概述
1.1 研究背景
Netflix公司最早系統化地提出了混沌工程的概念,2008年8月,Netflix公司由于資料庫發生故障,導致了三天時間的停機,使得DVD在線租賃業務中斷,造成了巨大的經濟損失,于是Netflix公司開始嘗試利用混沌工程優化穩定性保障體系,2010年,Netflix公司開發了混沌工程程式Chaos Monkey,于2012年在Simain Army專案中開源,該程式的主要功能是隨機終止在生產環境中運行的虛擬機實體和容器,模擬系統基礎設施遭到破壞的場景,從而檢驗系統服務的健壯性,2019年,阿里巴巴開源了ChaosBlade混沌工程程式,該程式可以結合阿里云進行混沌工程實驗,2020年,PingCap 作為國內優秀的資料庫領域開源公司,開源了其公司內部的混沌工程實踐平臺ChaosMesh,
基于以上開源專案,混沌工程專案在國內受到了多家公司的關注,越來越多的公司開始引入混沌工程進行系統穩定性保障作業,通過混沌工程主動注入故障的方式,避免軟體系統帶來的未知危機,圖1.1展示了軟體系統穩定性危機與對策發展時間線的對應關系,可以發現,隨著軟體系統規模的擴大,系統復雜度的增長及開發周期縮短,陸續爆發了多次軟體危機,同時,每次的軟體危機都促進了軟體系統穩定性保障措施的不斷完善,而當下的軟體系統的規模,復雜度和開發敏捷程度再次邁入了一個新的階段,導致系統的穩定性面臨著新的挑戰,此時,主動發現系統穩定性缺陷的混沌工程應運而生,再次彌補了當下系統穩定性保障方式的短板,
圖1.1 軟體系統穩定性危機和對策發展時間線圖 [來源:中國資訊通信研究院]
1.2 研究目的
塔勒布曾經在《反脆弱》一書中闡述了“系統如何在不確定性中獲益”的思想,混沌工程基于這一偉大思想,提倡使用一系列實驗來真實地驗證系統在各類故障場景下的表現,通過頻繁地進行大量實驗,使得系統本身的反脆弱性持續增強,每一次故障中的獲益,讓系統不斷進化,形成正向回圈,逐步提高系統的質量,保證系統的健壯性,因此,混沌工程研究的首要目的就是主動發現系統的穩定性缺陷,表1-1列舉了近幾年比較嚴重的幾個系統穩定性故障事件,從側面反映了系統穩定性保障的重要性,
表1-1 系統穩定性故障事件
| 公司名稱 | 發生時間 | 持續時長 | 影響范圍 | 故障原因 |
|---|---|---|---|---|
| 嗶哩嗶哩 | 2021年7月 | 約1小時 | 影響了視頻播放、直播等多個核心服務 | 機房故障,災備系統失效 |
| 滴滴 | 2021年2月 | 約1小時 | 滴滴打車APP | 系統內部錯誤 |
| 谷歌 | 2020年12月 | 約1小時 | 谷歌旗下多個業務 | 存盤超出限額 |
| 亞馬遜 | 2020年11月 | 約5小時 | 部分服務器無法訪問 | 不當的運維操作觸發了系統漏洞 |
| 微軟 | 2020年9月 | 約5小時 | Microsoft Office 36辦公軟體和Azure云產品 | 流量激增導致服務中斷 |
當混沌工程成為常態化的系統穩定性的保障手段后,系統的整體穩定性將得到進一步提升,通過混沌工程平臺,主動向系統注入故障,驗證和評估系統抵抗故障并保持正常運行的能力,提前識別未知的缺陷并進行修復,保障系統更好得抵御生產環境中的失控條件,有效提升系統的整體穩定性,
1.3 研究意義
混沌工程的主要研究意義在于提高系統的穩定性,通過主動向系統中注入故障的方式,研究和提高系統的健壯性,在一定程度上彌補了系統發生故障時被動回應的短板,降低了系統應對故障的風險和成本,表1-2列舉了使用混沌工程前后的系統穩定性保障方式的對比,可以發現,使用混沌工程后,系統穩定性的保障方式更加出色,
表1-2 使用混沌工程前后的系統穩定性保障方式對比
| 對比內容 | 使用混沌工程前 | 使用混沌工程后 |
|---|---|---|
| 發現缺陷的方式 | 線上缺陷發生時才開始識別 | 主動注入故障發現系統缺陷 |
| 應對缺陷的方式 | 被動回應,缺陷應對的開始時間取決于故障何時發生 | 主動回應,缺陷應對的開始時間取決于混沌工程的實驗時間 |
| 識別缺陷的效率 | 較低,對于觸發條件苛刻的潛在缺陷可能需要很長時間 | 較高,通過主動注入故障,使得潛在缺陷盡快暴露 |
| 回應缺陷的成本 | 可控性較差 | 可控性良好 |
另外,實踐混沌工程對不同職位的作業人員也有著各自的意義,如表1-3所示,混沌工程有助于幫助系統相關人員發現潛在的脆弱點,降低系統穩定性缺陷可能造成的損失,同時,通過混沌工程注入故障,可以有效鍛煉團隊發現和定位問題并快速恢復系統的能力,
表1-3 實踐混沌工程對不同職位的意義
| 職位 | 實踐混沌工程的意義 |
|---|---|
| 軟體開發工程師 | 進一步加深對系統的理解,驗證系統架構的容錯能力 |
| 測驗開發工程師 | 彌補傳統測驗方法留下的空白,更主動的方式發現系統的問題 |
| 運維開發工程師 | 提高系統故障的應急效率,實作故障告警、定位、恢復的有效應對 |
| 產品經理 | 了解產品在突發情況下的表現,提升客戶在突發情況下的產品使用體驗 |
1.4 研究方法
圖1.2 混沌工程實踐體系和軟體開發一般流程聯系圖 [來源:中國資訊通信研究院]
根據調研的混沌工程實踐經驗,混沌工程的研發方法可以概括為圖1.2中的混沌工程實踐體系,其中,混沌工程實踐配套是混沌工程成功實踐的關鍵,因此要求實踐團隊做好混沌工程實踐的戰略規劃,培養混沌工程實踐相關人員,形成混沌工程文化,識別應對潛在的風險并對混沌工程實踐做出有效的評估,在此基礎上,混沌工程實驗是混沌工程研究的核心作業,即混沌工程以實驗為最小單元研究發現系統的穩定性缺陷,實驗的一般流程是:實驗設計、實驗實施和結果分析,具體內容一般包括:實驗需求和物件、實驗可行性評估、觀測指標設計、實驗場景環境設計、實驗工具平臺框架選擇、實驗計劃和溝通、實驗執行及指標收集、環境清理與恢復、實驗結果分析、問題追蹤、自動化持續進行驗證,當通過混沌工程發現了系統穩定性缺陷時,需要根據實際情況給出對應的解決方案,如果存在架構的缺陷,則需針對性得采用韌性設計對穩定性缺陷進行改進,其他如邊界條件和極端情況未考慮或者編碼錯誤的缺陷,若占比較高且反復出現,則需要評估是否需要在制度規范上對軟體開發程序進行更好的管控,
關于更加具體理的論和混沌工程的一般實驗步驟,可以從該書《混沌工程:Netflix系統穩定性之道》中獲取到,電子版書籍見本報告附錄,該書對混沌工程進行了非常詳細的闡述,圖1.3為該書的目錄結構,
圖1.3 《混沌工程:Netflix系統穩定性之道》目錄
二、研究現狀
2.1 業界混沌工程工具
目前業界使用的混沌工程工具的種類很多,表2-1匯總了本次調研中發現的業內保持維護更新的幾個工具,不同工具側重于不同種類的故障注入,
表2-1 混沌工程工具匯總
| 工具名稱 | 最新版本 | 核心語言 | 包含場景 | 特定依賴 |
|---|---|---|---|---|
| ChaosBlade | 1.7.0 | Go | 實驗框架,支持系統資源、網路、應用層面等多種故障的注入 | 無特定依賴 |
| ChaosMesh | 2.3.1 | Go | 實驗框架,支持系統資源、網路、應用層面等多種故障的注入 | 依賴于K8s集群 |
| ChaosToolkit | 1.12.0 | Python | 實驗框架,可集成多個IaaS或PaaS平 臺,可使用多個故障注入工具定制場景, 可與多個監控平臺合作觀測和記錄指標資訊 | 通過插件形式支持多個IaaS、PaaS,包括 AWS/Azure/Goog le/K8s |
| orchestrator | 3.2.6 | Go | 純MySQL集群故障場景 | 無特定依賴 |
| powerfulseal | 3.3.0 | Python | 終止 K8s、Pods,終止容器,終止虛擬機 | 支持 OpenStack/AWS/ 本地機器 |
| toxiproxy | 2.5.0 | Go | 網路代理故障,網路故障 | 無特定依賴 |
2.2 業界混沌工程實踐平臺
業內的混沌工程平臺一般由:用戶界面、任務調度模塊、故障注入、監控告警系統四個部分組成,
用戶界面: 為實驗平臺提供混沌工程實驗任務的編排和配置服務,使得用戶方便管理各類混沌工程實驗任務,當混沌工程實驗開始后,用戶可以通過任務進度條、服務器指標等展示圖實時的查看實驗進度和系統指標情況,當混沌工程實驗結束后,用戶可以看到最后的混沌工程實驗報告,
任務調度模塊: 該模塊負責用戶界面和故障注入之間的互動,核心功能是實作混沌工程任務的批量下發和調度,
故障注入: 故障注入負責接收任務調度模塊下發的故障注入任務,實作相應的故障注入事件,并反饋故障注入任務的執行狀態,
監控告警系統: 該系統負責記錄和管理系統產生的所有資料,生成告警和相關統計并反饋給用戶,
2.3 混沌工程實踐能力評估
混沌工程實踐能力的評估可以幫助團隊更好地了解混沌工程實踐的狀況,表2-2列舉了混沌工程實驗成熟度的等級,該等級可以用來評估當前系統進行混沌工程實踐的能力,主要反映執行混沌工程實踐的可行性、有效性和安全性,等級越高則說明可實踐混沌工程的能力越強,
表2-2 混沌工程實驗成熟度等級
三、京東混沌工程實踐
泰山混沌工程平臺是基于業界成熟解決方案ChaosBlade并結合京東業務特色設計并落地實作的一款自助式故障演練平臺,用戶可根據自身服務特點有針對性的場景編排、故障注入,對服務容災能力進行評估,通過實驗探究的方式建立對系統行為重新的認知理解,推動建立混沌文化,通過主動探索的方式發現系統中潛在的、可以導致災難的、讓我們的客戶受損的脆榷訓節,消滅它們,讓我們的系統更加健壯有韌性,
圖3.1展示了泰山混沌工程演練的流程圖,基于泰山混沌平臺,紅方的任務是:
(1)創建演練計劃:通過訪問泰山平臺,進入路徑:安全生產-混沌工程頁面,頁面提供“創建演練計劃”按鈕,點擊即可進入演練配置頁面,
(2)演練配置:點擊創建演練計劃按鈕后,進入演練配置頁面,可錄入演練基本資訊及任務配置項(演練配置-應用相關(型別、方式、場景)、演練配置-執行相關),圖3.1中紅色字體為本次演練重點配置項,
(3)執行演練:演練任務創建保存后,生成一條待執行的演練任務,手工點擊執行按鈕執行演練,
藍方的任務是:
(1)故障排查:在演練執行中,藍方通過報警資訊,先下掉報警機器,進行排查,
(2)恢復方案:演練中發現問題要及時恢復,演練后要重啟恢復演練機器,確保機器正常運行
實驗完成后需要進行演練復盤,即對演練中發現問題總結及分析,確保不再出現類似風險問題,
圖3.1 泰山混沌工程演練流程圖【來源:全渠道混沌工程實踐文章】
3.1 核心能力
平臺的核心能力可以用四化一靈活概括,即:
一、自動化:演練程序全程自動調度、插件部署、故障注入、現場恢復,
二、可視化:演練期間,可實時觀測MDC指標變化、UMP業務監控指標變化以及故障注入進度等,
三、精準化:可通過指定IP、分組、機房、網路POD,針對演練影響范圍進行明確限制,演練效果更貼合實際場景,
四、規模化:平臺設計目標支持單任務1000+演練目標、多演練任務同時調度的能力,為集團范圍內各種預案演練、攻防演練、常態化混沌測驗提供強有力的支持,
五、靈活控制:在演練程序中可靈活進行取消、終止、全部終止等操作;針對故障場景可多維度進行配置提調整;演練時長、調度方式執行時可調整,
3.2 支持故障注入型別
泰山混沌工程實驗平臺支持豐富的混沌場景能力,表3-1列舉了平臺支持的基礎資源類故障場景,主要驗證基礎資源或者業務監控告警的及時性、有效性(干預手段),從而優化資源規格、部署規模和跨機房部署,同時希望增加行程存活、URL存活的監控,表3-2列舉了平臺支持的JAVA行程故障和中間件依賴故障場景,主要驗證業務、JVM監控告警的及時性、有效性(干預手段),從而調整JVM引數、使用合理垃圾回收器等,同時調整中間件集群配置、治理降級方案、優化快取策略等,通過演練也可以進一步理解系統架構,梳理強弱依賴、治理服務性能和評估下游服務能力,
表3-1 基礎資源類故障場景
| 混沌場景 | 演練目的 | 實作原理 |
|---|---|---|
| CPU高負載 | 關注對業務處理吞吐率的影響 | 消耗CPU時間片 |
| 記憶體占用 | - | 采用代碼申請記憶體實作 |
| 磁盤IO高負載 | 評估對磁盤讀寫敏感的業務的影響 | 使用dd命令實作 |
| 磁盤填充 | 主要驗證如日志目錄打滿對服務的影響 | 使用fallocate、dd命令實作 |
| 網路延遲 | 評估業務對網路延遲的容忍程度,評估超時、重試機制設定是否合理,防止級聯事故 | 使用tc命令實作 |
| 網路丟包 | 評估業務對網路丟包的容忍程度 | 使用tc命令實作 |
| 行程假死 | 觀測負載均衡時效性、業務敏感性 | kill -STOP |
| 行程終止 | 觀測負載均衡時效性、業務敏感性(Nginx&Tomcat) | kill -9 |
表3-2 JAVA行程故障和中間件依賴故障場景
| 型別 | 混沌場景 | 演練目的 |
|---|---|---|
| JAVA行程故障 | 行程CPU滿載 | 評估服務節點CPU滿載時對服務的影響 |
| 記憶體溢位 | 評估GC對服務的影響 | |
| 介面延遲 | 評估介面故障對整體SLA的影響 | |
| 介面拋例外 | 評估介面故障對整體SLA的影響 | |
| 介面回傳值篡改 | 評估針對非預期介面回傳的處理 | |
| 執行緒池打滿 | 評估執行緒池打滿對服務的影響 | |
| 中間件依賴故障 | JSF請求延遲 | 評估中間件故障對自身的影響 |
| JSF請求拋例外 | 評估中間件故障對自身的影響 | |
| JIMDB請求延遲 | 評估中間件故障對自身的影響 | |
| JIMDB請求拋例外 | 評估中間件故障對自身的影響 | |
| MYSQL請求延遲 | 評估中間件故障對自身的影響 | |
| MYSQL請求拋例外 | 評估中間件故障對自身的影響 |
表3-3匯總了泰山混沌實驗平臺的故障使用統計表,從使用情況上可以看出,目前基礎資源類故障場景使用居多,圖3.2更加直觀的展示出泰山混沌工程實踐平臺的故障使用型別為基礎資源類故障,
表3-3 泰山混沌工程實驗平臺故障型別使用統計表
| 故障型別 | 演練占比 |
|---|---|
| 網路故障 | 31% |
| 記憶體耗盡 | 13% |
| CPU打滿 | 23% |
| 磁盤故障 | 9% |
| 行程例外 | 3.5% |
| Java行程故障 | 6.5% |
| 外部依賴故障 | 14% |
3.3 常見問題
通過調研泰山混沌工程的實踐,可以匯總一些常見問題如下:
(1)報警未配置(MDC、UMP、存活);
(2)報警閾值不合理、間隔時長不合理、聯系人缺失、聯系人授權不足;
(3)行程假死未報警,需配置URL存活報警;
(4)暫停了告警,未及時開啟;
(5)值班人員對預案處理不熟練,內部系統工具使用不熟練(加強內部培訓);
(6)群組內反饋問題后,未有相關同事進行處理,職責分工不明確;
(7)內部工具設計不合理,無法應對不同場景(比如:多機房分組出例外);
(8)忽視偶發問題,后期范圍擴大不易處理(比如:低版本Linux內核處理),
四、總結和思考
4.1 調研總結和思考
本次調研涵蓋了混沌工程的起源,發展,以及在京東的落地情況,通過研究,我進一步體會到:(1)混沌工程最先進的,是它大膽超前的思維理念和安全受控的方法論,(2)故障注入只是手段,而不是混沌工程的全部,場景再多,也不代表韌性就夠好,(3)如果只是根據穩態假說,寫測驗用例,然后再使用故障注入工具進行試驗,最后結果驗證,這只能算是混沌工程最基本的內容,(4)混沌工程的使命是探索問題,而不僅僅是驗證問題,總體而言,混沌工程的核心就是增強系統信心,保證系統在某個場景下的能力不退化,
4.2 混沌工程未來發展
混沌工程的目標是主動發現問題,因此,未來依然離不開這個核心目標,但是在未來,可以使得這個目標更加智能化的實作,通過調研發現,業界中部分企業已經開始探索將混沌工程和人工智能、機器學習等領域相結合,通過注入故障時系統指標的變化和定位的歷史資料進行相關模型的訓練,使得模型可以通過指標變化自動識別故障,這將有助于解決混沌工程在結果分析和故障恢復環節的自動化問題,其次,當下的混沌工程演練平臺的互動性和可視化等能力在未來可以做到更好,此外,混沌工程的量化指標也需要進一步完善,
參考文獻
1.ChaosMesh https://github.com/chaos-mesh/chaos-mesh
2.ChaosBlade https://github.com/chaosblade-io/chaosblade
3.ChaosToolkit https://github.com/chaostoolkit/chaostoolkit
4.orchestrator https://github.com/openark/orchestrator
5.powerfulseal https://github.com/powerfulseal/powerfulseal
6.toxiproxy https://github.com/Shopify/toxiproxy
7.混沌工程深度實戰專場 https://live.juejin.cn/4354/xdc2021-01
作者:京東零售 賈安
來源:京東云開發者社區
轉載請註明出處,本文鏈接:https://www.uj5u.com/qiye/554663.html
標籤:訊息安全
上一篇:使用THREEJS實作一個可調節檔位、可搖頭的電風扇
下一篇:返回列表
