混沌工程實(shí)踐的可視化與平臺(tái)化概述課件

1、混沌工程實(shí)踐的可視化與平臺(tái)化概述課件混沌工程實(shí)踐的可視化與平臺(tái)化概述課件目錄故障簡(jiǎn)史 阿波羅登月十年演進(jìn)，重塑混沌混沌工程 從 1 到 100混沌工程實(shí)驗(yàn)場(chǎng)景的模版化混沌工程的平臺(tái)化混沌工程的可視化混沌工程的游戲日計(jì)劃目錄故障簡(jiǎn)史 阿波羅登月故障簡(jiǎn)史 阿波羅登月故障簡(jiǎn)史 阿波羅登月“ 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號(hào) 2號(hào)氧氣罐的爆炸，所有氧氣存儲(chǔ)將在3個(gè)小時(shí)內(nèi)消失， 同時(shí)也將失去水、電力和推進(jìn)系統(tǒng)。19611972你永遠(yuǎn)不知道會(huì)發(fā)生什么事- 吉姆洛威爾（Jim Lovell）source: /afj/ap13fj/08day3-problem.html 1970年阿波羅13號(hào) 2號(hào)氧氣罐的爆196119自我介紹最早提出軟件工程的概念，在阿波羅登月計(jì)劃中負(fù) 責(zé)軟件系統(tǒng)開(kāi)發(fā)。有一次，她的女兒在模擬艙玩的時(shí)候不小心按錯(cuò)了 鍵。她開(kāi)始思考，既然故障總是會(huì)發(fā)生，提前進(jìn)行 故障演練模擬就變得非常重要。類(lèi)似的事在阿波羅8號(hào)發(fā)生之后，她開(kāi)啟了最早的 故障場(chǎng)景模擬測(cè)試?，敻覃愄貪h密爾頓

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

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

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

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

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

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

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

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

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

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

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

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

15、減少破壞半徑與護(hù)欄服務(wù)配合使用暫停服務(wù)暫停服務(wù)啟動(dòng)后，將停止混沌工程實(shí)驗(yàn)：暫停服務(wù)混沌工程實(shí)驗(yàn)的最終目標(biāo)（優(yōu)化應(yīng)用架構(gòu)，促進(jìn)業(yè)務(wù)韌性）沒(méi)有改進(jìn)方案，等于實(shí)驗(yàn)白做了（根本原因分析 改進(jìn)方案推薦）改進(jìn)方案推薦服務(wù)混沌工程實(shí)驗(yàn)的最終目標(biāo)改進(jìn)方案推薦服務(wù)流程化自動(dòng)化定期化透明化流水線服務(wù)流程化流水線服務(wù)告警服務(wù)告警服務(wù)權(quán)限管理是混沌工程的重中之重 !（混沌工程實(shí)驗(yàn)會(huì)用于生產(chǎn)環(huán)境）混沌工程的主要權(quán)限管理范圍+（故障注入方式對(duì)資源的修改權(quán)限）+（指標(biāo)收集和觀測(cè)權(quán)限）+（告警觸發(fā)權(quán)限）+（護(hù)欄服務(wù)和暫停服務(wù)觸發(fā)權(quán)限）+（流水線觸發(fā)和審批權(quán)限）+（ ）權(quán)限管理服務(wù)權(quán)限管理是混沌工程的重中之重 !權(quán)限管理服務(wù)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混沌工程的實(shí)驗(yàn)場(chǎng)景：從1個(gè)增加到100個(gè)實(shí)施混沌工程的業(yè)務(wù)應(yīng)用數(shù)量：從1個(gè)增加到100個(gè)實(shí)施混沌工程的人員數(shù)量：從1位增加到100位混沌工程：從 1 到 100混沌工程的實(shí)驗(yàn)場(chǎng)景：從1個(gè)增加到新挑戰(zhàn)：混沌工程效果評(píng)估的復(fù)雜性混沌工程實(shí)驗(yàn)結(jié)果數(shù) = 應(yīng)用數(shù)量 X 每個(gè)應(yīng)用的實(shí)驗(yàn)結(jié)果數(shù)10,000100100實(shí)驗(yàn)結(jié)果數(shù)的增加會(huì)帶來(lái)實(shí)驗(yàn)效果評(píng)估的復(fù)雜度新挑戰(zhàn)：混沌工程效果評(píng)估的復(fù)雜性混沌工程實(shí)驗(yàn)

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

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

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

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

22、會(huì)經(jīng)常進(jìn)行混沌工程實(shí)驗(yàn)； 混沌工程實(shí)驗(yàn)是工程師日常工作的一部分；所有系統(tǒng)默認(rèn)都要參與混沌工程實(shí)驗(yàn)，不參與需要特殊說(shuō)明?；煦绻こ虒?shí)驗(yàn)接納指數(shù)接納指數(shù)描述公司重點(diǎn)項(xiàng)目不會(huì)進(jìn)行混沌工程韌性（Resilience）是指軟件通過(guò)適度降級(jí)和快速恢復(fù)而在遇到故障 時(shí)保持可用性的能力。只能通過(guò)在遇到故障情況時(shí)分析應(yīng)用程序的行為來(lái)衡量軟件的韌性?；煦绻こ虒?shí)驗(yàn)用于驗(yàn)證是否已使用預(yù)防故障的最佳實(shí)踐以及軟件行為 是否已達(dá)到韌性目標(biāo)。韌性分?jǐn)?shù)是一種報(bào)告機(jī)制，用于衡量服務(wù)對(duì)故障的韌性。韌性分?jǐn)?shù)最佳實(shí)踐采納情況 存在的可用性風(fēng)險(xiǎn)混沌工程實(shí)驗(yàn)成熟度等級(jí)模型韌性（Resilience）是指軟件通過(guò)適度降級(jí)和快速恢復(fù)而混沌工程成

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

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

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