1、混沌工程實踐的可視化與平臺化概述課件混沌工程實踐的可視化與平臺化概述課件目錄故障簡史 阿波羅登月十年演進，重塑混沌混沌工程 從 1 到 100混沌工程實驗場景的模版化混沌工程的平臺化混沌工程的可視化混沌工程的游戲日計劃目錄故障簡史 阿波羅登月故障簡史 阿波羅登月故障簡史 阿波羅登月“ Everything fails, all the time ”- Werner, Vogels (CTO, A)source: /wiki/Werner_Vogels_(Informatiker)#/media/Datei:Wernervogels_ddp.jpg“ Everything fails, all

2、the ti 1970年阿波羅13號 2號氧氣罐的爆炸，所有氧氣存儲將在3個小時內消失， 同時也將失去水、電力和推進系統(tǒng)。19611972你永遠不知道會發(fā)生什么事- 吉姆洛威爾（Jim Lovell）source: /afj/ap13fj/08day3-problem.html 1970年阿波羅13號 2號氧氣罐的爆196119自我介紹最早提出軟件工程的概念，在阿波羅登月計劃中負 責軟件系統(tǒng)開發(fā)。有一次，她的女兒在模擬艙玩的時候不小心按錯了 鍵。她開始思考，既然故障總是會發(fā)生，提前進行 故障演練模擬就變得非常重要。類似的事在阿波羅8號發(fā)生之后，她開啟了最早的 故障場景模擬測試。瑪格麗特漢密爾頓

3、source: /wiki/File:Margaret_Hamilton_-_restoration.jpg自我介紹最早提出軟件工程的概念，在阿波羅登月計劃中負 責軟件十年演進，重塑混沌十年演進，重塑混沌十年前，混沌工程的先驅遇到了什么困境？十年后，為何我們開始熱烈地討論“混沌工程”？十年前，混沌工程的先驅遇到了什么困境？自我介紹由于施工導致光纖被切斷source: https:/AmazonWebServices/leadership-session-networking-net209l-aws-reinvent-2018自我介紹由于施工source: https:/www.sl自我介紹由于

4、垃圾箱火災 導致光纖被損壞source: https:/AmazonWebServices/leadership-session-networking-net209l-aws-reinvent-2018自我介紹由于垃圾箱火災 導致光纖被損壞source: htt軟件可以用新技術實現(xiàn)彎道超車入云階段 (Stage of Adoption)遷移基礎項目卸下技術欠債敏捷管理云原生架構DevOps實踐收益時間再造云上現(xiàn)代應用技術幾乎都是單流程的有狀態(tài)依賴的靜態(tài)的為預防設計比較復雜軟件變得分布式化無狀態(tài)化迭代演進快速變化非常復雜可是，故障不會 隨之，消失殆盡傳統(tǒng)的故障 防治方法落后傳統(tǒng)的故障防治法軟件可

5、以用新技術實現(xiàn)彎道超車入云階段 (Stage of A隨著敏捷開發(fā)、DevOps實踐、云原生架構和治理的出現(xiàn)，極大地提升了應 用交付的能力，縮短了業(yè)務上市周期。業(yè)務敏捷化、技術迭代化的同時，還必須保證業(yè)務持續(xù)的高可用性和穩(wěn)定性， 過去傳統(tǒng)的災備方式已無法跟上這個節(jié)奏?；煦绻こ陶且驊@個挑戰(zhàn)，主動注入故障，以期提前發(fā)現(xiàn)潛在問題，迭代 改進架構和運維方式，最終實現(xiàn)業(yè)務韌性?；煦绻こ痰臅r機與機遇隨著敏捷開發(fā)、DevOps實踐、云原生架構和治理的出現(xiàn)，極大如果你不提早發(fā)現(xiàn)和解決問題（引入混沌工程） 最后問題會來（周末半夜）解決你如果你不提早發(fā)現(xiàn)和解決問題（引入混沌工程） 最后問題會來（周系統(tǒng)架構的本

6、質演進脆弱系統(tǒng)難以修改。許多組織擁有無法更改 的應用程序，維護成本非常高，但是由于它 們對業(yè)務至關重要，因此仍然運行。健壯系統(tǒng)可承受一定程度的壓力而不會失去 其功能，但是如果壓力和變化繼續(xù)，則該系 統(tǒng)可能會帶來損失。韌性系統(tǒng)在設計和實現(xiàn)時考慮到壓力和適應 性特征，從而應對更大的壓力和變化，并最 大程度地提供價值。反脆弱系統(tǒng)是一個智能系統(tǒng)，構建復雜有難 度，但一旦建立起來，將基于變更來驅動業(yè) 務，甚至能提供創(chuàng)新變更。source: /blog/2016/07/20/from-fragile-to-antifragile-software/系統(tǒng)架構的本質演進脆弱系統(tǒng)難以修改。許多組織擁有無法更改

7、的混沌工程的目標冗余性擴展性不可變基礎設施無狀態(tài)應用基礎設施即代碼韌性架構避免級聯(lián)故障轉移重試超時冪等服務拒絕服務 切換退避機制操作降級服務熔斷混沌工程的目標冗余性擴展性不可變基礎設施無狀態(tài)應用基礎設施即引用自 Netflix 報告：The Business Case for Chaos Engineering, 2018Netflix 混沌工程的投資回報率模型過去一年中，混沌工程提前發(fā)現(xiàn)了2次大故障和8次小故障，避免了整個組織大約70萬美金的損失。 混沌工程團隊，總共3個成員，薪水支出15萬美金/人。開展混沌工程實驗，本身需要1萬美金的成本。 請問，投資回報率是多少？投資回報率= 700,0

8、00-10,000-3*150,00010,000+3*150,000= 52.17%5,600美元/分鐘IT 故障引發(fā)的損失引用自 Gartner 報告引用自 Netflix 報告：The Business Ca混沌工程：從 1 到 100混沌工程：從 1 到 100混沌工程從 0 到 1：持續(xù)迭代的閉環(huán)體系混沌工程從 0 到 1：持續(xù)迭代的閉環(huán)體系混沌工程：從 1 到 100混沌工程的實驗場景：從1個增加到100個實施混沌工程的業(yè)務應用數(shù)量：從1個增加到100個實施混沌工程的人員數(shù)量：從1位增加到100位混沌工程：從 1 到 100混沌工程的實驗場景：從1個增加到混沌工程：從 1 到 10

9、0混沌工程的實驗場景：從1個增加到100個實施混沌工程的業(yè)務應用數(shù)量：從1個增加到100個實施混沌工程的人員數(shù)量：從1位增加到100位混沌工程：從 1 到 100混沌工程的實驗場景：從1個增加到新挑戰(zhàn)：混沌工程實驗場景的管理實驗準備故障注入指標搜集結果判斷環(huán)境清理實驗準備故障注入指標搜集結果判斷環(huán)境清理實驗準備故障注入指標搜集結果判斷環(huán)境清理第1個實驗場景第2個實驗場景第100個實驗場景新挑戰(zhàn)：混沌工程實驗場景的管理實驗準備故障注入指標搜集結果判解決方案：混沌工程實驗場景的模版化模版類別（分類）合并同類項+（實驗場景模版）+（運行時配置）模版?zhèn)}庫（維護）模版類別實驗場景模板解決方案：混沌工程實

10、驗場景的模版化模版類別（分類）合并同類項以大文件故障注入場景為例混沌工程實驗名稱通用未完成是否自動回退？通用等待實驗完成的時間專有文件大小通用詳細日志輸出運行時配置以大文件故障注入場景為例運行時配置常見的混沌工程實驗場景模版模版類別具體的實驗場景模版（舉例）依賴型故障AWS 托管服務異常：ELBS3 / DynamoDBLambda 主機型故障EC2 實例異常終止，EC2 實例異常關閉，EBS 磁盤卷異常卸載，RDS 數(shù)據(jù) 庫實例故障切換，ElastiCache 實例故障切換，容器異常終止，容器異常關 閉，操作系統(tǒng)內故障CPU、內存、磁盤空間、IOPS 占滿或突發(fā)過高占用，大文件，只讀系統(tǒng)，

11、系統(tǒng)重啟，熵耗盡，網(wǎng)絡故障網(wǎng)絡延遲，網(wǎng)絡丟包，DNS 解析故障，DNS 緩存毒化，VIP 轉移，網(wǎng)絡黑 洞，服務層故障不正常關閉連接，進程被殺死，暫停啟用進程，內核奔潰，請求攔截型故障異常請求，請求處理延遲，常見的混沌工程實驗場景模版模版類別具體的實驗場景模版（舉例）新挑戰(zhàn)：混沌工程實驗數(shù)量級增長混沌工程實驗總數(shù) = 應用數(shù)量 X 每個應用的實驗數(shù)量2,00020100實驗總數(shù)的增加會帶來實驗的時間開銷實驗的資源開銷實驗的管理開銷新挑戰(zhàn)：混沌工程實驗數(shù)量級增長混沌工程實驗總數(shù) = 應用數(shù)量解決方案：混沌工程的平臺化混沌工程平臺化的功能要求（Goblin 實驗平臺）Goblin 是歐洲中世紀傳說

12、的一個小怪物，調皮且貪玩。 他們經(jīng)常具有類似于童話般的魔法能力。解決方案：混沌工程的平臺化混沌工程平臺化的功能要求基本要求業(yè)務指標觀測服務流量生成服務故障注入服務護欄服務暫停服務改進方案推薦服務流水線服務告警服務權限管理服務從1到100：混沌工程的平臺化基本要求從1到100：混沌工程的平臺化Goblin 實驗平臺* 基本要求能運行實驗能觀測指標失敗能警報可暫停實驗Goblin 實驗平臺* 基本要求能運行實驗可暫停實驗業(yè)務指標觀測服務業(yè)務指標觀測服務指標類型業(yè)務性指標：價值最大，探測難度最大應用層指標：健康狀況基礎設施指標：較易獲取，只反映基礎設施的運行狀況指標對照應定義指標的穩(wěn)定狀態(tài)進行對照如

13、無法準確定義穩(wěn)定狀態(tài)，則使用多個指標的閾值聯(lián)合進行對照指標觀測和記錄系統(tǒng)觀測指標的設計指標類型觀測指標的設計生產(chǎn)環(huán)境使用真實的用戶流量（或分支）非生產(chǎn)環(huán)境使用脫敏的用戶流量（鏡像）制造測試用的流量流量分支流量鏡像流量生成流量生成服務生產(chǎn)環(huán)境流量生成服務基于 Host 的 Agent基于 Guest OS 的 Agent基于 程序虛擬機 的 Agent（JVM）無 Agent（SSH，API Call 等等）故障注入服務基于 Host 的 Agent故障注入服務AWS上故障注入的簡單示例EC2RDSLinuxAWS 服務 API流水線配置JSONTemplates場景模版JSONAWS Syst

14、em ManagerAmazon Elasticsearch ServiceAmazon S3JenkinsChaos Toolkit運行時配置AWS上故障注入的簡單示例EC2RDSLinuxAWS 服務常見的護欄作用護欄，又稱“保護性防護”，在一般情況 下，是一個邊界部件，以防止危險或阻止 進入危險區(qū)域為主要目的?；煦绻こ讨械淖o欄服務故障注入時，護欄服務將偵測混沌工程實 驗的破壞程度，以最大程度地減小破壞半 徑為目標。當實驗幾乎要影響到真實用戶 體驗時，觸發(fā)混沌工程實驗的暫停服務。護欄服務常見的護欄作用護欄服務暫停服務啟動后，將停止混沌工程實驗：進行環(huán)境清理與恢復保障真實用戶的體驗最大程度地

15、減少破壞半徑與護欄服務配合使用暫停服務暫停服務啟動后，將停止混沌工程實驗：暫停服務混沌工程實驗的最終目標（優(yōu)化應用架構，促進業(yè)務韌性）沒有改進方案，等于實驗白做了（根本原因分析 改進方案推薦）改進方案推薦服務混沌工程實驗的最終目標改進方案推薦服務流程化自動化定期化透明化流水線服務流程化流水線服務告警服務告警服務權限管理是混沌工程的重中之重 !（混沌工程實驗會用于生產(chǎn)環(huán)境）混沌工程的主要權限管理范圍+（故障注入方式對資源的修改權限）+（指標收集和觀測權限）+（告警觸發(fā)權限）+（護欄服務和暫停服務觸發(fā)權限）+（流水線觸發(fā)和審批權限）+（ ）權限管理服務權限管理是混沌工程的重中之重 !權限管理服務G

16、oblin ArchitectureDev TeamApplication ServiceRegularlyGoblin Assessment ServiceGoblin ScenariosGoblin Guardian ServiceGlobal Monitoring ServiceGoblin Pipeline InterfaceGoblinLoad Generator ServiceGoblin Injection ServiceGlobal Pipeline ServiceRegularlyGoblin CoreGoblin Red TeamGlobalAnalytics Interf

17、aceGlobal Notification ServiceGlobal Permission Mgmt ServiceGoblin ArchitectureDev TeamApp混沌工程：從 1 到 100混沌工程的實驗場景：從1個增加到100個實施混沌工程的業(yè)務應用數(shù)量：從1個增加到100個實施混沌工程的人員數(shù)量：從1位增加到100位混沌工程：從 1 到 100混沌工程的實驗場景：從1個增加到新挑戰(zhàn)：混沌工程效果評估的復雜性混沌工程實驗結果數(shù) = 應用數(shù)量 X 每個應用的實驗結果數(shù)10,000100100實驗結果數(shù)的增加會帶來實驗效果評估的復雜度新挑戰(zhàn)：混沌工程效果評估的復雜性混沌工程實驗

18、結果數(shù) = 應用解決方案：混沌工程的可視化要求混沌工程的成熟度評估模型 混沌工程的自動式可視化Goblin 是歐洲中世紀傳說的一個小怪物，調皮且貪玩。 他們經(jīng)常具有類似于童話般的魔法能力。解決方案：混沌工程的可視化要求混沌工程的成熟度評估模型 混沌混沌工程可行性評估模型混沌工程可行性評估模型混沌工程實驗成熟度等級成熟度等級1級2級3級4級5級架構抵御故障的能力無抵御故障的能力一定的冗余性冗余且可擴展已使用可避免級聯(lián)故障的技術已實現(xiàn)韌性架構實驗指標設計無系統(tǒng)指標監(jiān)控實驗結果只反映系統(tǒng)狀 態(tài)指標實驗結果反映應用的健 康狀況指標實驗結果反映聚合的業(yè) 務指標可在實驗組和控制組之 間比較業(yè)務指標的差異實

19、驗環(huán)境選擇只敢在開發(fā)和測試環(huán)境 中運行實驗可在預生產(chǎn)環(huán)境中運行 實驗未在生產(chǎn)環(huán)境中，用復制的生產(chǎn)流量來運行實 驗在生產(chǎn)環(huán)境中運行實驗包括生產(chǎn)在內的任意環(huán) 境都可以運行實驗實驗自動化能力全人工流程利用工具進行半自動運 行實驗自助式創(chuàng)建實驗，自動 運行實驗，但需要手動 監(jiān)控和停止實驗自動結果分析，自動終 止實驗全自動的設計、執(zhí)行和 終止實驗實驗工具使用無實驗工具采用實驗工具使用實驗框架實驗框架和持續(xù)發(fā)布工 具集成工具支持交互式的比對 實驗組和控制組故障注入場景 爆炸半徑范圍只對實驗對象注入一些 簡單事件，如突發(fā)高 CPU高內存等等可對實驗對象進行一些 較復雜的故障注入，如 EC2實例終止、可用區(qū)

20、故障等等對實驗對象注入較高級 的事件，如網(wǎng)絡延遲對實驗組引入如服務級 別的影響和組合式的故 障事件可注入如對系統(tǒng)的不同 使用模式、返回結果和 狀態(tài)的更改等類型的事 件環(huán)境恢復能力無法恢復正常環(huán)境可手動恢復環(huán)境可半自動恢復環(huán)境部分可自動恢復環(huán)境韌性架構自動恢復實驗結果整理沒有生成的實驗結果， 需要人工整理判斷可通過實驗工具的到實 驗結果，需要人工整理、 分析和解讀可通過實驗工具持續(xù)收 集實驗結果，但需要人 工分析和解讀可通過實驗工具持續(xù)收 集實驗結果和報告，并 完成簡單的故障原因分 析實驗結果可預測收入損 失、容量規(guī)劃、區(qū)分出 不同服務實際的關鍵程 度混沌工程實驗成熟度等級成熟度等級1級2級3級

21、4級5級架構抵御混沌工程實驗接納指數(shù)接納指數(shù)描述1級公司重點項目不會進行混沌工程實驗； 只覆蓋了少量的系統(tǒng)；公司內部基本上對混沌工程實驗了解甚少； 極少數(shù)工程師嘗試且偶爾進行混沌工程實驗。2級混沌工程實驗獲得正式授權和批準； 由工程師兼職進行混沌工程實驗；公司內部有多個項目有興趣參與混沌工程實驗； 極少數(shù)重要系統(tǒng)會不定期進行混沌工程實驗。3級成立了專門的混沌工程團隊；事件響應已經(jīng)集成在混沌工程實驗框架中以創(chuàng)建對應的回歸實驗； 大多數(shù)核心系統(tǒng)都會定期進行混沌工程實驗；偶爾以Game Day的形式，對實驗中發(fā)現(xiàn)的故障進行復盤驗證。4級公司所有核心系統(tǒng)都會經(jīng)常進行混沌工程實驗； 大多數(shù)非核心系統(tǒng)也都

22、會經(jīng)常進行混沌工程實驗； 混沌工程實驗是工程師日常工作的一部分；所有系統(tǒng)默認都要參與混沌工程實驗，不參與需要特殊說明?；煦绻こ虒嶒灲蛹{指數(shù)接納指數(shù)描述公司重點項目不會進行混沌工程韌性（Resilience）是指軟件通過適度降級和快速恢復而在遇到故障 時保持可用性的能力。只能通過在遇到故障情況時分析應用程序的行為來衡量軟件的韌性?；煦绻こ虒嶒炗糜隍炞C是否已使用預防故障的最佳實踐以及軟件行為 是否已達到韌性目標。韌性分數(shù)是一種報告機制，用于衡量服務對故障的韌性。韌性分數(shù)最佳實踐采納情況 存在的可用性風險混沌工程實驗成熟度等級模型韌性（Resilience）是指軟件通過適度降級和快速恢復而混沌工程成

23、熟度等級- 量化蜘蛛圖Application InjectionAvailabilityEnvironment SelectionInfrastructure InjectionFrequencySecurity混沌工程成熟度等級- 量化蜘蛛圖Application I常見的混沌工程實驗場景模版模版類別具體的實驗場景模版（舉例）依賴型故障AWS 托管服務異常：ELBS3 / DynamoDBLambda 主機型故障EC2 實例異常終止，EC2 實例異常關閉，EBS 磁盤卷異常卸載，RDS 數(shù)據(jù) 庫實例故障切換，ElastiCache 實例故障切換，容器異常終止，容器異常關 閉，操作系統(tǒng)內故障C

24、PU、內存、磁盤空間、IOPS 占滿或突發(fā)過高占用，大文件，只讀系統(tǒng)， 系統(tǒng)重啟，熵耗盡，網(wǎng)絡故障網(wǎng)絡延遲，網(wǎng)絡丟包，DNS 解析故障，DNS 緩存毒化，VIP 轉移，網(wǎng)絡黑 洞，服務層故障不正常關閉連接，進程被殺死，暫停啟用進程，內核奔潰，請求攔截型故障異常請求，請求處理延遲，常見的混沌工程實驗場景模版模版類別具體的實驗場景模版（舉例）混沌工程可視化示例混沌工程可視化示例混沌工程：從 1 到 100混沌工程的實驗場景：從1個增加到100個實施混沌工程的業(yè)務應用數(shù)量：從1個增加到100個實施混沌工程的人員數(shù)量：從1位增加到100位混沌工程：從 1 到 100混沌工程的實驗場景：從1個增加到新挑

25、戰(zhàn)：混沌工程技能和流程培訓新挑戰(zhàn)：混沌工程技能和流程培訓混沌工程的“游戲日計劃”是一個基于 團隊的交互式和開放式的學習與練習。 旨在測試系統(tǒng)中模擬各種事件響應的流 程，比如故障發(fā)生、被侵入、擴展要求 等等。目的是訓練團隊的響應能力以及 建立如何應對的“肌肉記憶 ”。游戲日計劃（Game Day）AWS GameDay混沌工程的“游戲日計劃”是一個基于 團隊的交互式和開放式的學總結總結隨著敏捷開發(fā)、DevOps實踐、云原生架構和治理的出現(xiàn)，極大地提升了應 用交付的能力，縮短了業(yè)務上市周期。業(yè)務敏捷化、技術迭代化的同時，還必須保證業(yè)務持續(xù)的高可用性和穩(wěn)定性， 過去傳統(tǒng)的災備方式已無法跟上這個節(jié)奏?；煦绻こ陶且驊@個挑戰(zhàn)，主動注入故障，以期提前發(fā)現(xiàn)潛在問題，迭代 改進架構和運維方式，最終實現(xiàn)業(yè)務韌性?；煦绻こ痰臅r機和機遇隨著敏捷開發(fā)、DevOps實踐、云原生架構和治理的出現(xiàn)，極大模版類別（分類）合并同類項+（實驗