1、云原生架構下的混沌工程實踐阿里云智能事業群-高可用架構團隊目錄混沌工程三連問混沌工程是什么?為什么要實施混沌工程?怎樣實施混沌工程?落地案例介紹未來展望混沌工程的概念2017.8月出版PRINCIPLES OF CHAOS ENGINEERINGChaos Engineering is the discipline of experimenting on a distributed systemin order to build confidence in the systems capabilityto withstand turbulent conditions in production
2、.混沌工程是在分布式系統上進行實驗的學科,目的是建立對系統抵御生產環境中失控條件的能力以及信心。預計2019.6月上市我對混沌工程的理解一種擁抱失敗的技術文化一套抽象嚴謹的實踐原則一種主動防御的穩定性手段一個高速發展的技術領域混沌工程的起源數據中心單點故障業務上云水平擴展能力基礎設施運維可靠第三方節點數增加故障率升高ChaosMonkey驗證韌性能力源自Chaos Engineering書籍在過去五年左右的時間里,只有僅有的一次節點掉線影響了我們的服務。當時正是混亂猴子終止了一個由于部署失誤而沒有冗余的服務節點造成了問題。幸運的是,這個故障發生在白天工作時間,在這個故障的服務剛剛部署不久后,對
3、用戶的影響也非常小?;靵y猴子的美妙之處就在于此,它能盡可能地將服務節點失效的痛苦提到最前,同時讓所有工程師在構建一個具有足夠彈性應對失敗的系統上,達成一個一致的目標?;煦绻こ淘瓌t從故障驅動到故障驅動故障管理活動保障故障應急穩定性度量混沌工程持續集成監控發現限流預案資損防控架構治理一個高速發展的技術領域小結混沌工程作為一個蓬勃發展的技術領域,體現了一種反脆弱的技術思想,提供了一套嚴謹的實踐原則,幫助企業更主動的提升穩定性云遷移(Cloud-Migrate)云就緒(Cloud-Ready)云原生(Cloud-Native)企業上云的幾個階段打法保留原有系統,搭建新系統支持新業務平滑遷移原有系統正常
4、運行,逐漸進行優化和改造不破不立利用新技術和新思路搭建系統,替換老系統顧舊立新挑戰穩定的服務質量友好的錯誤體驗企業利益避免重大故障的發生提升組織的效能技術積累構建更具韌性的系統更快速的技術演進客戶責任為什么要實施混沌工程減小業務損失,讓重大風險在可控范圍提前暴露提升系統彈性,持續驗證系統對極端場景的容錯能力增強團隊信心,驗證穩定性措施有效性,量化團隊價值混沌工程的引入(0-1)結合技術架構,選擇實驗工具最小爆炸半徑,控制實驗風險混沌工程的推廣(1-N)建立面向失敗設計的技術文化圍繞戰略制定目標,圍繞目標設計組織復用成熟產品,提升效能企業如何開始實施混沌工程?一款好的實驗工具需要滿足哪些條件?豐
5、富度資源、主機、容器、應用 易用性開發框架、實驗工具、產品平臺開放程度閉源、OpenAPI、支持擴展、開源集成方式代碼依賴、架構依賴、無依賴多語言Java、Go、C+、語言無關 活躍狀態已停滯、維護、活躍阿里混沌工程的技術演進路線延伸閱讀:阿里電商故障治理和故障演練實踐開源工具混沌之刃(ChaosBlade)ChaosBlade是一款遵循混沌實驗模型,提供豐富故障場景實現,幫助分布式系統提升容錯性和可恢復性的混沌工程工具,它的特點是操作簡潔、無侵入、擴展性強。GitHub 地址:https:/ create dubbo delay-time 3000-consumer-service com.
6、example.HelloService-version 1.0.0blade create cpu fullload-cpu-count 4結束示例:blade destroy 6435335635bbaca5(實驗ID)code:200,success:true,result:command:cpu fullload-cpu-count 4-debug false-help false控制爆炸半徑,減小實施風險建立面向失敗設計的技術文化面向失敗設計,因為每一塊硬盤,每一個業務系統,每一種技術組件都有出錯的可能!分布式系統需要制定分級策略,防止非核心業務拖垮核心業務!工具系統需要優先實現容災
7、!故障處理流程和人員能力也非常重要!圍繞企業戰略制定項目目標 服務可用性 異常體驗滿意度 API成功率 服務體驗故障預防事故處理系統韌性 資損故障預防 歷史故障覆蓋率 監控發現率 故障處理時長 預案有效性 架構容災 依賴治理 故障自愈 結合項目目標,設計組織結構強弱依賴破壞性測試資損演練容災演練紅藍對抗故障演練預案演練突襲演練SRE測試研發技術支持項目經理運營GameDay通過平臺能力,標準化實驗流程準備(PAREPARE)執行(EXECUTE)驗證(CHECK)恢復(RECOVER)計劃PLAN執行DO記錄RECORD分析ANALYSIS觀察OBSERVE還原RECOVER混沌工程插件架構評
8、估、流量導入 實驗場景模擬穩態數據拉取、驗證實驗恢復建設實驗平臺,提升規?;芰π〗Y引入和推廣混沌工程,您需要結合企業特點,選擇適合當下的工具或產品;最小爆炸半徑,控制實驗風險;建立面向失敗的技術文化,接受不確定性;圍繞企業戰略,有針對性的設計組織和實施;建設實驗平臺,提升規?;芰?;新零售云服務云業務落地場景舉例新零售業務穩定性的挑戰挑戰線下場景,用戶對故障容忍度低無法徹底規避網絡問題,尤其是門店網絡要求云端服務要具備較高的可用性終端的異常提示要面向用戶友好現場人員要熟悉處理手段難點如何證明穩定性措施有效性?如何減少實驗對業務帶來的影響?如何常態化的實施實驗?最小化爆炸半徑,實現常態化的實驗
9、企業級分布式應用服務A企業級分布式應用服務A企業級分布式應用服務B分布式關系型數據庫服務應用配置分布式關系型數據庫服務分布式關系型數據庫服務企業級分布式應用服務B應用配置企業級分布式應用服務D企業級分布式應用服務企業級分布式應用服務B企業級分布式應用服務D統一接入層統一接入層統一接入層統一接入層親橙里店POS A親橙里店POS B慶春店POS A云服務穩定性專有云混沌工程實踐運行態運行態特定流不通黑洞/隨機丟包系統異常內核異常服務交互運行環境運行時服務器交換機網絡層網絡層系統系統層層硬件硬件層層設備級別流量黑洞設備級別流量黑洞 SLOT級別流量黑洞級別流量黑洞隨機流量丟棄隨機流量丟棄網絡延遲、
10、包亂序、丟包 NTP/YUM/DNS 異常文件系統ReadOnly內存頁分配錯誤內核futex死鎖模擬 Kernel Panic系統配置異常系統權限異常DPDK 網絡異常網絡異常磁盤磁盤IO Hang CPU/MEM/磁盤Inode 各類資源耗盡系統Load高 OOM用戶態用戶態CPU異常異常服務強制退出服務強制退出服務優雅退出服務優雅退出整機故障整機故障異常重啟異常重啟交換機交換機 上行上行/下行下行 端口(端口(RANGE)異常異常 服務器宕機服務器宕機/掉盤掉盤NVME SSD 異常異常PCIE Degrade特定流五元組流量不通特定流五元組流量不通特定特定IP流量不通流量不通 特定源和
11、目的訪問單通特定源和目的訪問單通Request 參數空參數空/特殊特殊Query/協議錯誤協議錯誤用戶流量徒增用戶流量徒增/雪崩雪崩Connect 超時超時/失敗失敗Connect 連接數滿連接數滿Response 異常異常系統參數異常系統參數異常網絡設備單端口擁塞網絡設備單端口擁塞K8S異常仿真異常仿真ECS IOhang 模擬模擬Docker異常仿真異常仿真內核級函數錯誤模擬內核級函數錯誤模擬RMDA 異常異常SPDK 異常異常云業務穩定性保障的挑戰微服務容器開源組件云服務有什么有哪些第三方組件,用了哪些云服務,有哪些自開發的應用服務,他們之間的關系是什么樣的,他們和底層的容器,云服務器的關系是什么樣子的?做什么我的第三方組件,云服務和應用服務需要具備哪些高可用能力怎么做如何提高這些組件的高可用能力面向云業務的高可用服務阿里云菜單搜索 AHAS,免費公測中云業務混沌實驗方案云原生業務(穩態分析)架構感知&組件識別架構組件分析云原生業務(穩態驗證)白屏化式實驗未來規劃開源連接特性容器服務日志服務云監控其他架構感知方案故障演練限流降級高可用分析幫助云原生業務提升高可用能力的云服務(AHAS)社區建設口令:chaos