浩鲸科技基于ChaosBlade的混沌工程实践
作者介紹:
葉文宸,浩鯨科技云原生技術專家,開源 chaosBlade 社區貢獻者,多年分布式系統架構和穩定性建設經驗,致力于穩定保障(SRE)、IT藍軍建設和運維數字化提升。
前言
1、敏捷開發,DevOps 的穩定性痛點
隨著業務規模的快速擴張,敏捷開發、DevOps 實踐、云原生架構和治理的出現,極大地提升了應用交付的能力,縮短了業務上市周期。且與之帶來的微服務治理復雜度呈指數級擴大,業務敏捷和技術迭代的難度也在不斷加大,同時還必須保證業務持續的高可用性和穩定性,面對故障過去傳統的災備方式已無法跟上這個節奏。
減少故障的最佳方法就是用反脆弱的思路來管理故障,將故障發生視為常態,通過不斷重復異常過程,持續提升系統的容錯和彈性能力。混沌工程正是因應這個挑戰,主動注入故障,提前發現潛在問題,迭代改進架構和運維方式,最終實現業務韌性。
2、混沌工程需求
混沌工程是一套通過在分布式系統上進行實驗,主動找出系統中的脆弱環節的方法學,最早由 Netflix 及相關團隊提出。它旨在將故障扼殺在襁褓之中,也就是在故障造成中斷之前將它們識別出來。通過主動制造故障,測試系統在各種壓力下的行為,識別并修復故障問題,避免造成嚴重后果。2012年,Netflix 開源了 Chaos Monkey。今天,許多公司(包括谷歌,亞馬遜,IBM,耐克等)都采用某種形式的混沌工程來提高現代架構的可靠性。
浩鯨科技在海量互聯網服務以及當前爆炸式增長的流量場景實踐過程中,沉淀出了包括,鏈路壓測,流控管理,動態擴縮容,故障演練等高可用核心技術,并通過云上服務化、平臺化和工具化的形式,幫助內部產品研發部門以及客戶,提高開發效率,提升業務穩定性。
為了打通故障發現,故障管理,故障演練,應急響應等多方高可用措施,形成穩定性建設的完整鏈路。浩鯨科技組建 IT 藍軍,實施演練突襲,質量控制,聯合作訓。自2019年開始建設 IT 藍軍隊伍,重點圍繞生產環境,開展混沌工程實踐,以推動代碼、基礎設施、流程、人員、監控上的提升。自今年起,深化演練力度,演練常態化、周期化,不斷提高 SRE 單兵作戰能力。
故障演練平臺
1、搭建故障演練平臺
基于這個指導思想,浩鯨科技決定建立故障演練平臺,基于工具化故障注入和平臺化故障演練管理來實現標準化,周期性的故障演練,從而提高產品韌性。
平臺目標:
- 提供自動化,可視化,可編排,無侵入的故障注入能力;
- 作為高可用演練,故障測試的統一入口;
- 積累沉淀高可用測試用例,建立量化的穩定性評估體系;
功能目標:
- 適配目前JVM、CPP、容器化、K8S等故障場景;
- 故障注入自動化,具備故障生命周期管理能力;
- 故障爆炸范圍可控;
- 故障注入類型具備良好的擴展性;
2、故障注入工具選型
目前業內模擬故障的工具比較多樣化,支持的功能和場景也各有優劣。通過對比來看,chaosblade 支持功能和場景比較豐富,同時社區也是比較活躍的。我們在充分驗證了大部分注入功能后,選擇了它作為底層注入的核心模塊。
混沌工程開源工具對比
3、故障演練步驟
結合 chaosblade 的混沌工程模型,我們將整個故障注入標準化,劃分為五個步驟:
4、平臺模塊
作為故障演練的核心組件和故障注入引擎,平臺的模塊構建圍繞服務業務演練展開。
故障演練
1、演練過程詳解
我們實際實施故障演練時,涉及環境準備、故障注入任務編排、實施故障注入、故障復盤、問題改進等一系列操作。
- 演練方案確認
實施故障演練之前,確認實施故障注入的目標服務/節點,并確認納入故障演練平臺管理。確認故障實施的時間,地點,干系人,服務穩態,演練預期,觀測指標及完整的演練執行順序。
- 故障演練用例編排
基于高可用演練工具 HATT ,完成自動化演練任務編排、并實施演練全流程操作。
- 演練實施
通過演練工具監控演練全生命周期并獲取演練結果。演練過程中出現的告警、監控異常,穩定性指標同步至演練執行結果,驗證穩定性預期。
- 演練完結/復盤
基于故障演練平臺輸出當次演練結果,演練報告,基于指標分析輸出演練問題復盤報告。
- 穩定性改進
基于演練復盤報告,確定穩定性改進建設方案,并跟蹤執行。便于下次演練的故障回歸。
故障演練用例則作為當前業務的建設資產沉淀在故障演練平臺內,通用的還可予以復用。
2、從1-100
穩定性建設從不是一蹴而就的事,混沌工程旨在建設一個穩固的 PDCA 循環,促使 SRE 們在快速迭代的產品研發周期中不停驗證,優化產品穩定性,跟上產品 DevOps 的腳步。而面臨大量、反復、周期化的故障演練,標準化、自動化執行和演練過程固化沉淀成了提效利器。
在完成演練方案設計及對接后,利用平臺,做到了單個 IT 藍軍即可完成全部自動化演練過程。
典型案例
驗證消息隊列單節點假死 hang 住時服務的可用性。
- 演練場景:
消息隊列單個 Broker 節點 hang 住,驗證消息收發是否正常。
- 穩定性預期:
單個 broker 異常不影響其他節點消息發送,故障節點將被排除出可用節點列表。短暫 tps 下降后,消息發送恢復正常 tps。
- 演練中穩定性異常:
節點 hang 住后,tps 驟降為 0,不符合預期;
- 改進成果:
1. 客戶端引入熔斷機制,消息發送重試失敗后不再嘗試往故障節點發送消息,避免了持續不可用;
2. namesrv 路由服務主動將 broker 失效信息推送至客戶端,減少故障恢復時長。
浩鯨混沌工程實踐
基于混沌工程實踐,我們意識到,故障演練屬于穩定性建設中的一環,而要做到穩定性提升,故障的應急響應處理是一個環環相扣的鏈條,任一環節的缺失,影響總體的穩定性質量。建立故障協同處理響應鏈還是一個長足發展的過程。
目前,我們在:
- 規劃層面,推動故障演練能力分層;
- 平臺層面,致力于打通架構感知及運維組件的聯動協調;
- 制度層面,建立故障應急協同響應鏈;
- 演練實施層面,將故障演練從測試預生產環境向生產環境邁進;
- 積極貢獻力量,回饋開源社區,隨著底層注入工具chaosblade的蓬勃發展,引入更豐富的故障類型和靈活的注入方式。
以浩鯨科技內部混沌工程實踐為例,對 30+ 重要產品線編排實施各種類型的演練,形成 月/季度 周期性故障演練累計 200+ 用例,以確保整個產品線能應對業務極端條件下的壓力。全面提升開放平臺應用服務水平,為浩鯨云系統架構的持續優化、產品的快速創新提供堅實支撐。
原文鏈接:https://developer.aliyun.com/article/788867?
版權聲明:本文內容由阿里云實名注冊用戶自發貢獻,版權歸原作者所有,阿里云開發者社區不擁有其著作權,亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容,填寫侵權投訴表單進行舉報,一經查實,本社區將立刻刪除涉嫌侵權內容。總結
以上是生活随笔為你收集整理的浩鲸科技基于ChaosBlade的混沌工程实践的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 云原生编程挑战赛--Serverless
- 下一篇: 如何用 Nacos 构建服务网格生态?