2014年集歇,Netflix團(tuán)隊(duì)創(chuàng)建了一種新的角色绍刮,叫作混沌工程師(Chaos Enigneer)温圆,并開(kāi)始向工程社區(qū)推廣。項(xiàng)目目標(biāo)孩革、業(yè)務(wù)場(chǎng)景岁歉、人員結(jié)構(gòu)、實(shí)施方式的不同導(dǎo)致了對(duì)于穩(wěn)定狀態(tài)行為的定義不太標(biāo)準(zhǔn)膝蜈。
多元化的業(yè)務(wù)場(chǎng)景锅移、規(guī)模化的服務(wù)節(jié)點(diǎn)及高度復(fù)雜的系統(tǒng)架構(gòu)饱搏,每天都會(huì)遇到各式各樣的故障非剃。這些故障信息就是最真實(shí)的混沌工程變量。為了能夠更體感推沸、有效率地描述故障备绽,優(yōu)先分析了P1和P2的故障,提出一些通用的故障場(chǎng)景并按照IaaS層鬓催、PaaS層肺素、SaaS層的角度繪制了故障畫(huà)像。
混沌工程到底是什么?
根據(jù) Netflix 的解釋?zhuān)煦绻こ處熗ㄟ^(guò)應(yīng)用一些經(jīng)驗(yàn)探索的原則宇驾,來(lái)學(xué)習(xí)觀察系統(tǒng)是如何反應(yīng)的倍靡。這就跟科學(xué)家做實(shí)驗(yàn)去學(xué)習(xí)物理定律一樣,混沌工程師通過(guò)做實(shí)驗(yàn)去了解系統(tǒng)飞苇。
上圖就是混沌工程的典型代表 - 猴子菌瘫。拜 Netflix 所賜,現(xiàn)在大部分的混沌工程項(xiàng)目都叫做 Monkey布卡,也就是一只討厭的猴子雨让,在你的系統(tǒng)里面上蹦下竄,不停搗亂忿等,直到搞掛你的系統(tǒng)栖忠。
然后,我們需要知道贸街,為什么需要混沌工程庵寞。應(yīng)用混沌工程能提升整個(gè)系統(tǒng)的彈性。通過(guò)設(shè)計(jì)并且進(jìn)行混沌實(shí)驗(yàn)薛匪,我們可以了解到系統(tǒng)脆弱的一面捐川,在還沒(méi)出現(xiàn)對(duì)用戶造成傷害之前,我們就能主動(dòng)發(fā)現(xiàn)這些問(wèn)題逸尖。
混沌工程其實(shí)是很重要的古沥,但我之前一直以為混沌工程就是測(cè)試瘸右,但它們還是有區(qū)別的。雖然混沌工程跟傳統(tǒng)測(cè)試通常都會(huì)共用很多測(cè)試工具的岩齿,譬如都會(huì)使用錯(cuò)誤注入工具太颤,但混沌工程是通過(guò)實(shí)踐對(duì)系統(tǒng)有更新的認(rèn)知,而傳統(tǒng)測(cè)試則是使用特定方式對(duì)某一塊進(jìn)行特定測(cè)試盹沈。譬如在傳統(tǒng)測(cè)試?yán)锩媪湔拢覀兛梢詫?xiě)一個(gè)斷言,我們給定特定的條件乞封,產(chǎn)生一個(gè)特定的輸出做裙,如果不滿足斷言條件,測(cè)試就出錯(cuò)了肃晚,這個(gè)其實(shí)是具有很明確的特性菇用。但混沌工程是試驗(yàn),而試驗(yàn)會(huì)有怎樣的新信息生成陷揪,我們是不確定的。譬如我們可以進(jìn)行下面的這些試驗(yàn):
- 模擬整個(gè) IDC 當(dāng)?shù)?/li>
- 選擇一部分網(wǎng)絡(luò)連連接注入特定時(shí)間的延遲
- 隨機(jī)讓一些函數(shù)拋出異常
- 強(qiáng)制 NTP 時(shí)間不同步
- 生成 IO 錯(cuò)誤
- 榨干 CPU
這些試驗(yàn)到底會(huì)有什么樣的結(jié)果杂穷,有些我們可以預(yù)料悍缠,但有些可能我們就不會(huì)預(yù)先知道,只有發(fā)生了耐量,才會(huì)恍然大悟飞蚓,有一種『喔,這也會(huì)出現(xiàn)廊蜒!』的感嘆趴拧。
原則
在開(kāi)始應(yīng)用混沌工程之前,我們必須確保系統(tǒng)是彈性的山叮,也就是當(dāng)出現(xiàn)了系統(tǒng)錯(cuò)誤我們的整個(gè)系統(tǒng)還能正常工作著榴。如果不能確保,我們就需要先考慮提升整個(gè)系統(tǒng)的健壯性了屁倔,因?yàn)榛煦绻こ讨饕怯脕?lái)發(fā)現(xiàn)系統(tǒng)未知的脆弱一面的脑又,如果我們知道應(yīng)用混沌工程能導(dǎo)致顯而易見(jiàn)的問(wèn)題,那其實(shí)就沒(méi)必要應(yīng)用了锐借。
雖然 chaos 有混亂的意思问麸,但混沌工程并不是制造混亂。相反钞翔,我們可以認(rèn)為混沌工程是用經(jīng)驗(yàn)的方法來(lái)定位問(wèn)題的一門(mén)實(shí)驗(yàn)學(xué)科严卖。譬如,我們可以思考:『如果我們?cè)谙到y(tǒng)里面注入混亂了布轿,這個(gè)系統(tǒng)會(huì)怎樣哮笆?』来颤,或者『我們系統(tǒng)離混亂的邊界還有多遠(yuǎn)?』疟呐。所以脚曾,為了更好的進(jìn)行混沌試驗(yàn),我們需要有一些原則來(lái)進(jìn)行指導(dǎo)启具。
假定穩(wěn)定狀態(tài)
在一個(gè)復(fù)雜系統(tǒng)里面本讥,我們有特別多的組件,有很多不同的輸入輸出鲁冯,我們需要有一個(gè)通用的方式來(lái)區(qū)別系統(tǒng)哪些行為是可以接受的拷沸,而哪一些則是不合適的。我們可以認(rèn)為當(dāng)系統(tǒng)處于正常操作時(shí)候的狀態(tài)就是穩(wěn)定狀態(tài)薯演。
通常我們可以通過(guò)自己測(cè)試撞芍,來(lái)確定一個(gè)系統(tǒng)的穩(wěn)定狀態(tài),但這個(gè)方法當(dāng)然是比較低效的跨扮,另一種更常用的做法就是收集 metric 信息序无,不光需要系統(tǒng)的 metric,也需要服務(wù)自身的 metric衡创,但收集 metric 需要注意實(shí)時(shí)性的問(wèn)題帝嗡,你如果收集一個(gè)每月匯總的 metric 信息,其實(shí)沒(méi)啥用璃氢,畢竟系統(tǒng)是實(shí)時(shí)變化的∮寸瑁現(xiàn)在市面上面有很多不錯(cuò)的開(kāi)源 metric 系統(tǒng),譬如我們就在用的 Prometheus一也。
當(dāng)我們能收集到信息之后巢寡,就需要用這些信息去描述一個(gè)穩(wěn)定狀態(tài)。這個(gè)難度比較大椰苟,因?yàn)椴煌臉I(yè)務(wù)是不一樣的抑月,即使是同一個(gè)業(yè)務(wù),不同時(shí)間也可能變化很大尊剔。但也有一些方法爪幻,譬如我們可以根據(jù)前面一段時(shí)間譬如上周的 metric 的曲線得到一個(gè)大概合理的穩(wěn)定狀態(tài),也可以自己做很多壓力測(cè)試须误,得到相關(guān)的數(shù)據(jù)挨稿。
當(dāng)有了 metric 以及知道穩(wěn)定狀態(tài)對(duì)應(yīng)的 metric 是怎樣之后,我們就可以通過(guò)這些來(lái)考慮混沌實(shí)驗(yàn)了京痢。思考當(dāng)我們注入不同的事件到系統(tǒng)中的時(shí)候奶甘,穩(wěn)定狀態(tài)會(huì)如何變化,然后我們就會(huì)開(kāi)始做實(shí)驗(yàn)來(lái)驗(yàn)證這個(gè)假設(shè)祭椰。
變更真實(shí)世界事件
在真實(shí)的世界中臭家,我們可能遇到各種各樣的問(wèn)題疲陕,譬如:
- 硬件故障
- 網(wǎng)絡(luò)延遲和隔離
- 資源耗盡
- 拜占庭錯(cuò)誤
- 下游依賴故障
做混沌試驗(yàn)的時(shí)候需要模擬這些故障,來(lái)看系統(tǒng)的狀態(tài)钉赁。但從成本上面考慮蹄殃,我們并不需要模擬所有的故障,僅僅需要考慮那些會(huì)比較頻繁發(fā)生你踩,而且模擬之后會(huì)很有效果的诅岩。在 TiDB 里面,我們主要就是模擬的網(wǎng)絡(luò)带膜,文件系統(tǒng)的故障吩谦,但現(xiàn)在看起來(lái)還是不夠,后面會(huì)逐漸的添加更多膝藕。
在生產(chǎn)中進(jìn)行試驗(yàn)
要看混沌試驗(yàn)有沒(méi)有效果式廷,在真實(shí)生產(chǎn)環(huán)境中進(jìn)行驗(yàn)證是最好的方法。但我相信大部分的廠商還沒(méi)這么大的魄力芭挽,這方面 Netflix 就做的很猛滑废,他們竟然能夠直接停掉 Amazon 上面的一個(gè) Zone。
如果不能再生產(chǎn)環(huán)境中試驗(yàn)袜爪,一個(gè)可選的方法就是做 shadow策严,也就是通常的錄制生產(chǎn)環(huán)境的流量,然后在測(cè)試中重放饿敲。或者模擬生產(chǎn)環(huán)境逛绵,自己造數(shù)據(jù)測(cè)試怀各。
自動(dòng)化持續(xù)執(zhí)行
最開(kāi)始執(zhí)行混沌試驗(yàn),我們可能就是人工進(jìn)行术浪,試驗(yàn)進(jìn)行的過(guò)程中瓢对,看 metric,試驗(yàn)結(jié)束之后胰苏,通過(guò)收集的 metric 在對(duì)比硕蛹,看系統(tǒng)的狀態(tài)。這個(gè)過(guò)程后面完全可以做成自動(dòng)化的硕并,也就是定期執(zhí)行法焰,或者系統(tǒng)發(fā)布的時(shí)候執(zhí)行等。
如果能做到自動(dòng)化執(zhí)行試驗(yàn)倔毙,已經(jīng)很不錯(cuò)了埃仪,但我們可以做的更多,甚至有可能根據(jù)系統(tǒng)的狀態(tài)自動(dòng)化的生成相關(guān)的試驗(yàn)陕赃,這個(gè) Netflix 已經(jīng)做了很多研究卵蛉,但我們這邊還處于初級(jí)階段颁股,沒(méi)考慮過(guò)自動(dòng)化生成的問(wèn)題。
最小化影響范圍
在進(jìn)行混沌試驗(yàn)的時(shí)候傻丝,一定要注意影響的范圍甘有,如果沒(méi)預(yù)估好,把整個(gè)服務(wù)搞掛了葡缰,導(dǎo)致所有的用戶都沒(méi)法使用亏掀,這個(gè)問(wèn)題還是很?chē)?yán)重的。
通常都會(huì)使用一種 Canary 的方法运准,也就是類(lèi)似 A/B 測(cè)試幌氮,或者灰度發(fā)布這種的,在 Canary 集群這邊做很多試驗(yàn)胁澳。也就是說(shuō)该互,如果真的搞壞了,那也只是一小部分用戶被搞壞了韭畸,損失會(huì)小很多宇智。
在 Canary 里面還有一個(gè)好處,因?yàn)槲覀冎勒麄€(gè)系統(tǒng)的穩(wěn)定狀態(tài)胰丁,即使不做混沌測(cè)試随橘,也可以觀察 Canary 里面的狀態(tài)是不是跟之前的穩(wěn)定狀態(tài)一致的,如果不一致锦庸,那也可能有問(wèn)題机蔗。
實(shí)踐
上面我們說(shuō)了相關(guān)的原則,那么如何開(kāi)始進(jìn)行一次混沌試驗(yàn)?zāi)馗氏簦科鋵?shí)很簡(jiǎn)單萝嘁,只要做到如下步驟就可以:
- 選擇一個(gè)假設(shè)
- 選擇試驗(yàn)的范圍
- 明確需要觀察的 metric 指標(biāo)
- 通知相關(guān)的團(tuán)隊(duì)
- 執(zhí)行試驗(yàn)
- 分析結(jié)果
- 增大試驗(yàn)的范圍
- 自動(dòng)化
譬如對(duì)于 TiDB 來(lái)說(shuō),譬如我們可以選擇驗(yàn)證網(wǎng)絡(luò)隔離對(duì)系統(tǒng)的影響扬卷,我們會(huì):
- 假設(shè)一臺(tái)機(jī)器的網(wǎng)絡(luò)隔離對(duì)整個(gè)系統(tǒng)不會(huì)造成影響
- 將一個(gè)用戶一臺(tái) TiKV 進(jìn)行網(wǎng)絡(luò)隔離
- 觀察 QPS牙言,latency,等指標(biāo)
- 通知負(fù)責(zé)這個(gè)用戶的 OPS 同學(xué)
- 斷網(wǎng)
- 一段時(shí)間之后分析 metric
- 在多個(gè)集群測(cè)試
- 將這個(gè)流程自動(dòng)化
上面只是一個(gè)簡(jiǎn)單的例子怪得,實(shí)際還會(huì)復(fù)雜很多咱枉,但通過(guò)這種方式做了操作了很多次之后,大家都會(huì)更加熟悉自己的系統(tǒng)徒恋。
混沌成熟度模型
這里在簡(jiǎn)單說(shuō)說(shuō)混沌成熟度模型蚕断,Netflix 總結(jié)了兩個(gè)維度,一個(gè)是復(fù)雜度入挣,一個(gè)就是接受度基括。前者表示的是混沌工程能有多復(fù)雜,而后者則表示的是混沌工程被團(tuán)隊(duì)的接受程度财岔。
復(fù)雜度分為幾個(gè)階段:
-
初級(jí)
- 試驗(yàn)沒(méi)有在生產(chǎn)中進(jìn)行
- 進(jìn)程被收工管理
- 結(jié)果只反映系統(tǒng) metric风皿,沒(méi)有業(yè)務(wù)的
- 只有簡(jiǎn)單的事件進(jìn)行試驗(yàn)
-
簡(jiǎn)單
- 試驗(yàn)可以在類(lèi)生產(chǎn)環(huán)境中進(jìn)行
- 能自動(dòng)啟動(dòng)執(zhí)行河爹,但需要人工監(jiān)控和終止
- 結(jié)果能反應(yīng)一些聚合的業(yè)務(wù) metric
- 一些擴(kuò)展的事件譬如網(wǎng)絡(luò)延遲可以進(jìn)行試驗(yàn)
- 結(jié)果可以手工匯總和聚合
- 試驗(yàn)是預(yù)先定義好的
- 有一些工具能進(jìn)行歷史對(duì)照
-
復(fù)雜
- 試驗(yàn)直接在生產(chǎn)環(huán)境中進(jìn)行
- 啟動(dòng),執(zhí)行桐款,結(jié)果分析咸这,終止都是自動(dòng)完成
- 試驗(yàn)框架集成在持續(xù)發(fā)布
- 業(yè)務(wù) metrics 會(huì)在實(shí)驗(yàn)組和控制組進(jìn)行比較
- 一些組合錯(cuò)誤或者服務(wù)級(jí)別影響的事件可以進(jìn)行試驗(yàn)
- 結(jié)果一直可以追蹤
- 有工具可以更好的交互式的對(duì)比試驗(yàn)和控制組
-
高級(jí)
- 試驗(yàn)在每個(gè)開(kāi)發(fā)步驟和任意環(huán)境都進(jìn)行
- 設(shè)計(jì),執(zhí)行和提前終止這些全部都是自動(dòng)化的
- 框架跟 A/B 或者其他試驗(yàn)系統(tǒng)整合
- 一個(gè)事件譬如更改使用模式和返回值或者狀態(tài)變更開(kāi)始進(jìn)行試驗(yàn)
- 試驗(yàn)包括動(dòng)態(tài)作用域和影響魔眨,可以找到突變點(diǎn)
- 通過(guò)試驗(yàn)結(jié)果能保護(hù)資產(chǎn)流失
- 容量預(yù)測(cè)可以通過(guò)試驗(yàn)分析提前得出
- 試驗(yàn)結(jié)果可以區(qū)分不同服務(wù)的臨界狀態(tài)
而接受度也有幾個(gè)階段:
-
在暗處
- 相關(guān)項(xiàng)目不被批準(zhǔn)
- 很少系統(tǒng)被覆蓋
- 很少或者沒(méi)有團(tuán)隊(duì)有意識(shí)
- 早期接受者不定期的進(jìn)行試驗(yàn)
-
有投入
- 試驗(yàn)被被官方批準(zhǔn)
- 部分資源被用于實(shí)踐
- 多個(gè)團(tuán)隊(duì)有興趣并投入
- 少部分關(guān)鍵服務(wù)不定期進(jìn)行試驗(yàn)
-
接受
- 有專(zhuān)門(mén)的 team 進(jìn)行混沌工程
- 應(yīng)急響應(yīng)被集成到框架媳维,從而可以創(chuàng)建回歸試驗(yàn)
- 多數(shù)關(guān)鍵系統(tǒng)定期進(jìn)行混沌試驗(yàn)
- 一些試驗(yàn)驗(yàn)證會(huì)在應(yīng)急響應(yīng)或者游戲時(shí)間被臨時(shí)執(zhí)行
-
文化
- 所有關(guān)鍵服務(wù)都有頻繁的混沌試驗(yàn)
- 大多數(shù)非關(guān)鍵服務(wù)定期進(jìn)行
- 混沌試驗(yàn)已經(jīng)是工程師的日常工作
- 默認(rèn)所有系統(tǒng)組件都必須參與,如果不想進(jìn)行遏暴,需要有正當(dāng)?shù)睦碛?/li>
混沌工程是不是與你有關(guān)侄刽?
Netflix工程師創(chuàng)建了Chaos Monkey,使用該工具可以在整個(gè)系統(tǒng)中在隨機(jī)位置引發(fā)故障朋凉。正如GitHub上的工具維護(hù)者所說(shuō)州丹,“Chaos Monkey會(huì)隨機(jī)終止在生產(chǎn)環(huán)境中運(yùn)行的虛擬機(jī)實(shí)例和容器≡优恚”通過(guò)Chaos Monkey墓毒,工程師可以快速了解他們正在構(gòu)建的服務(wù)是否健壯,是否可以彈性擴(kuò)容亲怠,是否可以處理計(jì)劃外的故障所计。
2012年,Netflix開(kāi)源了Chaos Monkey团秽。今天主胧,許多公司(包括谷歌,亞馬遜习勤,IBM讥裤,耐克等),都采用某種形式的混沌工程來(lái)提高現(xiàn)代架構(gòu)的可靠性姻报。 Netflix甚至將其混沌工程工具集擴(kuò)展到包括整個(gè)“Simian Army(中文可以譯為猿軍)”,用它攻擊自己的系統(tǒng)间螟。
混沌工程屬于一門(mén)新興的技術(shù)學(xué)科吴旋,行業(yè)認(rèn)知和實(shí)踐積累比較少,大多數(shù)IT團(tuán)隊(duì)對(duì)它的理解還沒(méi)有上升到一個(gè)領(lǐng)域概念厢破。阿里電商域在2010年左右開(kāi)始嘗試故障注入測(cè)試的工作荣瑟,希望解決微服務(wù)架構(gòu)帶來(lái)的強(qiáng)弱依賴問(wèn)題。
混沌工程摩泪,是一種提高技術(shù)架構(gòu)彈性能力的復(fù)雜技術(shù)手段笆焰。Chaos工程經(jīng)過(guò)實(shí)驗(yàn)可以確保系統(tǒng)的可用性〖樱混沌工程旨在將故障扼殺在襁褓之中嚷掠,也就是在故障造成中斷之前將它們識(shí)別出來(lái)捏检。通過(guò)主動(dòng)制造故障,測(cè)試系統(tǒng)在各種壓力下的行為不皆,識(shí)別并修復(fù)故障問(wèn)題贯城,避免造成嚴(yán)重后果。
它霹娄,被描述為“在分布式系統(tǒng)上進(jìn)行實(shí)驗(yàn)的學(xué)科能犯,目的是建立對(duì)系統(tǒng)承受生產(chǎn)環(huán)境中湍流條件能力的信心∪埽”踩晶。
Chaos Engineering is the discipline of experimenting on a systemin order to build confidence in the system’s capabilityto withstand turbulent conditions in production.
它也可以視為流感疫苗,故意將有害物質(zhì)注入體內(nèi)以防止未來(lái)疾病枕磁,這似乎很瘋狂渡蜻,但這種方法也適用于分布式云系統(tǒng)⊥傅洌混沌工程會(huì)將故障注入系統(tǒng)以測(cè)試系統(tǒng)對(duì)其的響應(yīng)晴楔。這使公司能夠?yàn)殄礄C(jī)做準(zhǔn)備,并在宕機(jī)發(fā)生之前將其影響降至最低峭咒。
如何知道系統(tǒng)是否處于穩(wěn)定狀態(tài)呢税弃?通常,團(tuán)隊(duì)可以通過(guò)單元測(cè)試凑队、集成測(cè)試和性能測(cè)試等手段進(jìn)行驗(yàn)證则果。但是,無(wú)論這些測(cè)試寫(xiě)的多好漩氨,我們認(rèn)為都遠(yuǎn)遠(yuǎn)不夠西壮,因?yàn)殄e(cuò)誤可以在任何時(shí)間發(fā)生,尤其是對(duì)分布式系統(tǒng)而言叫惊,此時(shí)就需要引入混沌工程(Chaos Engineering)款青。
故障演練:目標(biāo)是沉淀通用的故障模式,以可控成本在線上重放霍狰,以持續(xù)性的演練和回歸方式運(yùn)營(yíng)來(lái)暴露問(wèn)題抡草,不斷推動(dòng)系統(tǒng)、工具蔗坯、流程康震、人員能力的不斷前進(jìn)。
Chaos Engineering is a helpful tool in understanding your system’s unknowns, but it is not the means to an end for achieving resilience. Instead, it helps to instill higher confidence in the ability to cope and be resilient in the face of inevitable failures.
混沌工程宾濒、故障注入和故障測(cè)試在關(guān)注點(diǎn)和工具中都有很大的重疊腿短。
混沌工程和其他方法之間的主要區(qū)別在于,混沌工程是一種生成新信息的實(shí)踐,而故障注入是測(cè)試一種情況的一種特定方法橘忱。當(dāng)想要探索復(fù)雜系統(tǒng)可能出現(xiàn)的不良行為時(shí)赴魁,注入通信延遲和錯(cuò)誤等失敗是一種很好的方法。但是我們也想探索諸如流量激增鹦付,激烈競(jìng)爭(zhēng)尚粘,拜占庭式失敗,以及消息的計(jì)劃外或不常見(jiàn)的組合敲长。如果一個(gè)面向消費(fèi)者的網(wǎng)站突然因?yàn)榱髁考ぴ龆鴮?dǎo)致更多收入郎嫁,我們很難稱(chēng)之為錯(cuò)誤或失敗,但我們?nèi)匀粚?duì)探索系統(tǒng)的影響非常感興趣祈噪。同樣泽铛,故障測(cè)試以某種預(yù)想的方式破壞系統(tǒng),但沒(méi)有探索更多可能發(fā)生的奇怪場(chǎng)景辑鲤,那么不可預(yù)測(cè)的事情就可能發(fā)生盔腔。
混沌工程以實(shí)驗(yàn)發(fā)現(xiàn)系統(tǒng)性弱點(diǎn)。這些實(shí)驗(yàn)通常遵循四個(gè)步驟:
1.定義并測(cè)量系統(tǒng)的“穩(wěn)定狀態(tài)”月褥。首先精確定義指標(biāo)弛随,表明您的系統(tǒng)按照應(yīng)有的方式運(yùn)行。 Netflix使用客戶點(diǎn)擊視頻流設(shè)備上播放按鈕的速率作為指標(biāo)宁赤,稱(chēng)為“每秒流量”舀透。請(qǐng)注意,這更像是商業(yè)指標(biāo)而非技術(shù)指標(biāo);事實(shí)上决左,在混沌工程中愕够,業(yè)務(wù)指標(biāo)通常比技術(shù)指標(biāo)更有用,因?yàn)樗鼈兏m合衡量用戶體驗(yàn)或運(yùn)營(yíng)佛猛。
2.創(chuàng)建假設(shè)惑芭。與任何實(shí)驗(yàn)一樣,您需要一個(gè)假設(shè)來(lái)進(jìn)行測(cè)試继找。因?yàn)槟阍噲D破壞系統(tǒng)正常運(yùn)行時(shí)的穩(wěn)定狀態(tài)遂跟,你的假設(shè)將是這樣的,“當(dāng)我們做X時(shí)婴渡,這個(gè)系統(tǒng)的穩(wěn)定狀態(tài)應(yīng)該沒(méi)有變化幻锁。”為什么用這種方式表達(dá)缩搅?如果你的期望是你的動(dòng)作會(huì)破壞系統(tǒng)的穩(wěn)定狀態(tài)船万,那么你會(huì)做的第一件事會(huì)是修復(fù)問(wèn)題娜膘。混沌工程應(yīng)該包括真正的實(shí)驗(yàn)倘感,涉及真正的未知數(shù)。
3.模擬現(xiàn)實(shí)世界中可能發(fā)生的事情堂鲤,目前有如下混沌工程實(shí)踐方法:模擬數(shù)據(jù)中心的故障亿傅、強(qiáng)制系統(tǒng)時(shí)鐘不同步、在驅(qū)動(dòng)程序代碼中模擬I/O異常瘟栖、模擬服務(wù)之間的延遲葵擎、隨機(jī)引發(fā)函數(shù)拋異常。通常半哟,您希望模擬可能導(dǎo)致系統(tǒng)不可用或?qū)е缕湫阅芙档偷膱?chǎng)景酬滤。首先考慮可能出現(xiàn)什么問(wèn)題,然后進(jìn)行模擬寓涨。一定要優(yōu)先考慮潛在的錯(cuò)誤盯串。 “當(dāng)你擁有非常復(fù)雜的系統(tǒng)時(shí),很容易引起出乎意料的下游效應(yīng)戒良,這是混沌工程尋找的結(jié)果之一体捏,”“因此,系統(tǒng)越復(fù)雜糯崎,越重要几缭,它就越有可能成為混沌工程的候選對(duì)象∥帜兀”
4.證明或反駁你的假設(shè)年栓。將穩(wěn)態(tài)指標(biāo)與干擾注入系統(tǒng)后收集的指標(biāo)進(jìn)行比較。如果您發(fā)現(xiàn)測(cè)量結(jié)果存在差異樟插,那么您的混沌工程實(shí)驗(yàn)已經(jīng)成功 - 您現(xiàn)在可以繼續(xù)加固系統(tǒng)韵洋,以便現(xiàn)實(shí)世界中的類(lèi)似事件不會(huì)導(dǎo)致大問(wèn)題』拼福或者搪缨,如果您發(fā)現(xiàn)穩(wěn)定狀態(tài)可以保持,那么你對(duì)該系統(tǒng)的穩(wěn)定性大可放心鸵熟。
各式各樣的故障副编。這些故障信息就是最真實(shí)的混沌工程變量。
如果你是一名系統(tǒng)架構(gòu)師流强、測(cè)試人員痹届、SRE 人員,那你需要關(guān)注混沌工程打月。
那么队腐,企業(yè)如何確定自己是否適合混沌工程?滿足一下部分特征的企業(yè)奏篙,都適合實(shí)施混沌工程:
對(duì)于資損或 SLA 有極高要求的行業(yè)(金融柴淘、電商迫淹、醫(yī)療、游戲为严、公共等)
有較大的系統(tǒng)改造(比如:系統(tǒng)重構(gòu)敛熬、微服務(wù)化、容器化第股、遷云)
業(yè)務(wù)發(fā)展快应民,穩(wěn)定性積淀少
人員流動(dòng)快,或 SRE 團(tuán)隊(duì)規(guī)模較小
對(duì)于使用混沌工程的團(tuán)隊(duì)夕吻,我建議:
要先從文化上讓團(tuán)隊(duì)認(rèn)可實(shí)施混沌工程的必要性和方法論诲锹。
重點(diǎn)關(guān)注實(shí)驗(yàn)方案的評(píng)估,明確定義系統(tǒng)穩(wěn)態(tài)和終止條件梭冠。
嘗試通過(guò)一些簡(jiǎn)單的場(chǎng)景開(kāi)始嘗試辕狰,增加大家對(duì)系統(tǒng)和過(guò)程的信心。
與其他團(tuán)隊(duì)進(jìn)行合作控漠,通過(guò)混沌工程配合其他穩(wěn)定性手段蔓倍,達(dá)成整體目標(biāo)(如:監(jiān)控發(fā)現(xiàn)率、故障改進(jìn)覆蓋率盐捷、系統(tǒng)自愈有效性等)偶翅。
下面我要說(shuō)的很重要。
在使用混沌工程之前碉渡,我們需要準(zhǔn)備三點(diǎn):
思想上要準(zhǔn)備好聚谁。要意識(shí)到系統(tǒng)故障是可以通過(guò)周期性的引入一些實(shí)驗(yàn)變量來(lái)提前暴露和解決的。不論是否實(shí)施混沌工程滞诺,系統(tǒng)的隱患或 Bug 都客觀存在形导。
系統(tǒng)穩(wěn)態(tài)和實(shí)驗(yàn)方案的仔細(xì)評(píng)估。對(duì)于實(shí)驗(yàn)方案進(jìn)行推演习霹,如果已經(jīng)可以預(yù)想到一些問(wèn)題朵耕,那么修正后再進(jìn)行新的實(shí)驗(yàn)。
提升系統(tǒng)的可觀測(cè)性淋叶。對(duì)于系統(tǒng)穩(wěn)態(tài)阎曹,要有配套的監(jiān)控或觀測(cè)工具,否則會(huì)影響混沌工程的實(shí)施效果煞檩。
你知道的处嫌,實(shí)踐出真知。
作為第一批吃螃蟹的斟湃,我們也做了將近十年了熏迹,阿里在故障模擬、爆炸半徑的控制凝赛、產(chǎn)品化方面出了一些成績(jī)注暗。業(yè)務(wù)方基本可以做到很低成本使用我們的產(chǎn)品厨剪,DevOps 同學(xué)基本已經(jīng)可以實(shí)現(xiàn)自助演練。
從 2016 年到現(xiàn)在友存,看到大家對(duì)領(lǐng)域的認(rèn)可度逐年變高,演練覆蓋的應(yīng)用規(guī)模和發(fā)現(xiàn)問(wèn)題的數(shù)量已經(jīng)翻了幾倍陶衅,幫助業(yè)務(wù)方識(shí)別了很多潛在故障和改進(jìn)點(diǎn)屡立,很多高速發(fā)展的領(lǐng)域,比如新零售搀军,也是通過(guò)實(shí)施混沌工程來(lái)快速的落地和改進(jìn)穩(wěn)定性膨俐,我還挺高興的。
雖然混沌工程在行業(yè)內(nèi)沒(méi)有一個(gè)比較廣的認(rèn)知罩句,但除去 Netflix 和阿里之外焚刺,國(guó)內(nèi)外也有不少公司在做這個(gè)。
比如门烂,國(guó)外有 Gremlin乳愉、ChaosIQ 這樣專(zhuān)門(mén)實(shí)施 Resilience as a Service 的商業(yè)公司。像一些中屯远、大型公司也都有實(shí)施混沌工程團(tuán)隊(duì)蔓姚,比如 Linkedin、Uber慨丐、Google 等等坡脐。
混沌工程原則 (PRINCIPLES OF CHAOS ENGINEERING)
混沌工程是在分布式系統(tǒng)上進(jìn)行實(shí)驗(yàn)的學(xué)科, 目的是建立對(duì)系統(tǒng)抵御生產(chǎn)環(huán)境中失控條件的能力以及信心。
大規(guī)模分布式軟件系統(tǒng)的發(fā)展正在改變軟件工程房揭。作為一個(gè)行業(yè)备闲,我們很快采用了提高開(kāi)發(fā)靈活性和部署速度的實(shí)踐。緊隨著這些優(yōu)點(diǎn)的一個(gè)迫切問(wèn)題是:我們對(duì)投入生產(chǎn)的復(fù)雜系統(tǒng)有多少信心捅暴?
即使分布式系統(tǒng)中的所有單個(gè)服務(wù)都正常運(yùn)行, 這些服務(wù)之間的交互也會(huì)導(dǎo)致不可預(yù)知的結(jié)果恬砂。 這些不可預(yù)知的結(jié)果, 由影響生產(chǎn)環(huán)境的罕見(jiàn)且破壞性的事件復(fù)合而成,令這些分布式系統(tǒng)存在內(nèi)在的混沌伶唯。
我們需要在異常行為出現(xiàn)之前觉既,在整個(gè)系統(tǒng)內(nèi)找出這些弱點(diǎn)。這些弱點(diǎn)包括以下形式:
- 當(dāng)服務(wù)不可用時(shí)的不正確回滾設(shè)置;
- 不當(dāng)?shù)某瑫r(shí)設(shè)置導(dǎo)致的重試風(fēng)暴;
- 由于下游依賴的流量過(guò)載導(dǎo)致的服務(wù)中斷;
- 單點(diǎn)故障時(shí)的級(jí)聯(lián)失敗等乳幸。
我們必須主動(dòng)的發(fā)現(xiàn)這些重要的弱點(diǎn)瞪讼,在這些弱點(diǎn)通過(guò)生產(chǎn)環(huán)境暴露給我們的用戶之前。我們需要一種方法來(lái)管理這些系統(tǒng)固有的混沌, 通過(guò)增加的靈活性和速率以提升我們對(duì)生產(chǎn)環(huán)境部署的信心, 盡管系統(tǒng)的復(fù)雜性是由這些部署所導(dǎo)致的粹断。
我們采用基于經(jīng)驗(yàn)和系統(tǒng)的方法解決了分布式系統(tǒng)在規(guī)模增長(zhǎng)時(shí)引發(fā)的問(wèn)題, 并以此建立對(duì)系統(tǒng)抵御這些事件的能力和信心符欠。通過(guò)在受控實(shí)驗(yàn)中觀察分布式系統(tǒng)的行為來(lái)了解它的特性,我們稱(chēng)之為混沌工程瓶埋。
混沌工程實(shí)踐
為了具體地解決分布式系統(tǒng)在規(guī)模上的不確定性希柿,可以把混沌工程看作是為了揭示系統(tǒng)弱點(diǎn)而進(jìn)行的實(shí)驗(yàn)诊沪。這些實(shí)驗(yàn)遵循四個(gè)步驟:
- 首先,用系統(tǒng)在正常行為下的一些可測(cè)量的輸出來(lái)定義“穩(wěn)定狀態(tài)”曾撤。
- 其次端姚,假設(shè)這個(gè)在控制組和實(shí)驗(yàn)組都會(huì)繼續(xù)保持穩(wěn)定狀態(tài)。
- 然后挤悉,在實(shí)驗(yàn)組中引入反映真實(shí)世界事件的變量渐裸,如服務(wù)器崩潰、硬盤(pán)故障装悲、網(wǎng)絡(luò)連接斷開(kāi)等昏鹃。
- 最后,通過(guò)控制組和實(shí)驗(yàn)組之間的狀態(tài)差異來(lái)反駁穩(wěn)定狀態(tài)的假說(shuō)诀诊。
破壞穩(wěn)態(tài)的難度越大洞渤,我們對(duì)系統(tǒng)行為的信心就越強(qiáng)。如果發(fā)現(xiàn)了一個(gè)弱點(diǎn)属瓣,那么我們就有了一個(gè)改進(jìn)目標(biāo)载迄。避免在系統(tǒng)規(guī)模化之后被放大抡蛙。
高級(jí)原則
以下原則描述了應(yīng)用混沌工程的理想方式宪巨,這些原則基于上述實(shí)驗(yàn)過(guò)程。對(duì)這些原則的匹配程度能夠增強(qiáng)我們?cè)诖笠?guī)模分布式系統(tǒng)的信心溜畅。
建立一個(gè)圍繞穩(wěn)定狀態(tài)行為的假說(shuō)
要關(guān)注系統(tǒng)的可測(cè)量輸出, 而不是系統(tǒng)的屬性捏卓。對(duì)這些輸出在短時(shí)間內(nèi)的度量構(gòu)成了系統(tǒng)穩(wěn)定狀態(tài)的一個(gè)代理。 整個(gè)系統(tǒng)的吞吐量慈格、錯(cuò)誤率怠晴、延遲百分點(diǎn)等都可能是表示穩(wěn)態(tài)行為的指標(biāo)。 通過(guò)在實(shí)驗(yàn)中的系統(tǒng)性行為模式上的關(guān)注, 混沌工程驗(yàn)證了系統(tǒng)是否正常工作, 而不是試圖驗(yàn)證它是如何工作的浴捆。
多樣化真實(shí)世界的事件
混沌變量反映了現(xiàn)實(shí)世界中的事件蒜田。 我們可以通過(guò)潛在影響或估計(jì)頻率排定這些事件的優(yōu)先級(jí)⊙⌒海考慮與硬件故障類(lèi)似的事件, 如服務(wù)器宕機(jī)冲粤、軟件故障 (如錯(cuò)誤響應(yīng)) 和非故障事件 (如流量激增或伸縮事件)。 任何能夠破壞穩(wěn)態(tài)的事件都是混沌實(shí)驗(yàn)中的一個(gè)潛在變量页眯。
在生產(chǎn)環(huán)境中運(yùn)行實(shí)驗(yàn)
系統(tǒng)的行為會(huì)依據(jù)環(huán)境和流量模式都會(huì)有所不同梯捕。 由于資源使用率變化的隨時(shí)可能發(fā)生, 因此通過(guò)采集實(shí)際流量是捕獲請(qǐng)求路徑的唯一可靠方法。 為了保證系統(tǒng)執(zhí)行方式的真實(shí)性與當(dāng)前部署系統(tǒng)的相關(guān)性, 混沌工程強(qiáng)烈推薦直接采用生產(chǎn)環(huán)境流量進(jìn)行實(shí)驗(yàn)窝撵。
持續(xù)自動(dòng)化運(yùn)行實(shí)驗(yàn)
手動(dòng)運(yùn)行實(shí)驗(yàn)是勞動(dòng)密集型的, 最終是不可持續(xù)的傀顾。所以我們要把實(shí)驗(yàn)自動(dòng)化并持續(xù)運(yùn)行,混沌工程要在系統(tǒng)中構(gòu)建自動(dòng)化的編排和分析碌奉。
最小化爆炸半徑
在生產(chǎn)中進(jìn)行試驗(yàn)可能會(huì)造成不必要的客戶投訴短曾。雖然對(duì)一些短期負(fù)面影響必須有一個(gè)補(bǔ)償, 但混沌工程師的責(zé)任和義務(wù)是確保這些后續(xù)影響最小化且被考慮到寒砖。
混沌工程是一個(gè)強(qiáng)大的實(shí)踐, 它已經(jīng)在世界上一些規(guī)模最大的業(yè)務(wù)系統(tǒng)上改變了軟件是如何設(shè)計(jì)和工程化的。 相較于其他方法解決了速度和靈活性, 混沌工程專(zhuān)門(mén)處理這些分布式系統(tǒng)中的系統(tǒng)不確定性嫉拐。 混沌工程的原則為我們大規(guī)模的創(chuàng)新和給予客戶他們應(yīng)得的高質(zhì)量的體驗(yàn)提供了信心哩都。
在生產(chǎn)中進(jìn)行試驗(yàn)可能會(huì)造成不必要的客戶投訴,但混沌工程師的責(zé)任和義務(wù)是確保這些后續(xù)影響最小化且被考慮到婉徘。對(duì)于實(shí)驗(yàn)方案和目標(biāo)進(jìn)行充分的討論是減少用戶影響的最重要的手段茅逮。但是從實(shí)際的實(shí)施角度看,最好還是通過(guò)一些技術(shù)手段去最小化影響判哥。Chaos Engineering和Fault Injection Test的核心區(qū)別在于:是否可以進(jìn)一步減小故障的影響,比如微服務(wù)級(jí)別碉考、請(qǐng)求級(jí)別甚至是用戶級(jí)別塌计。在MonkeyKing演進(jìn)的中期階段,已經(jīng)可以實(shí)現(xiàn)請(qǐng)求級(jí)別的微服務(wù)故障注入侯谁。雖然那個(gè)時(shí)候演練實(shí)施的主要位置在測(cè)試環(huán)境锌仅,但初衷也是為了減少因?yàn)樽⑷牍收隙鴮?dǎo)致的環(huán)境不穩(wěn)定問(wèn)題。除了故障注入墙贱,流量路由和數(shù)據(jù)隔離技術(shù)也是減少業(yè)務(wù)影響的有效手段热芹。
chaos-engineering 的一些開(kāi)源工具
開(kāi)源工具:
kube-monkey、PowerfulSeal惨撇、ChaosIQ伊脓,提供了一些容器層面的故障注入能力。詳細(xì)可以看:https://github.com/dastergon/awesome-chaos-engineering
近期阿里會(huì)開(kāi)源一款混沌工程測(cè)試工具 ChaosBlade魁衙,提供基礎(chǔ)資源报腔、應(yīng)用服務(wù)、容器等多維度的故障模擬能力剖淀。
商業(yè)化工具:
Gremlin 提供一款商用的故障注入平臺(tái)纯蛾,部分功能免費(fèi),目前在公測(cè)中纵隔。
阿里云 - 應(yīng)用高可用服務(wù)(AHAS):AHAS 供了基于混沌工程原則的完整的實(shí)現(xiàn)翻诉,除了提供常見(jiàn)的故障注入能力,默認(rèn)也打通了一些常見(jiàn)的云服務(wù)捌刮,提升系統(tǒng)的可觀測(cè)性和自動(dòng)化能力碰煌。目前免費(fèi)公測(cè)中(支持非阿里云機(jī)器公網(wǎng)使用)。
隨著企業(yè)云化绅作,一定會(huì)有越來(lái)越多的公司開(kāi)始關(guān)注和實(shí)施混沌工程拄查。我希望可以有更多的公司分享思考和實(shí)踐,并結(jié)合領(lǐng)域場(chǎng)景產(chǎn)出一些最佳的實(shí)踐棚蓄。
居安思危堕扶,思則有備碍脏,有備無(wú)患。這是《左傳·襄公十一年》說(shuō)的稍算。
此前典尾,有人認(rèn)為,混沌工程是一種在故障發(fā)生之前發(fā)現(xiàn)故障的技術(shù)糊探,但也是一種心態(tài)钾埂。
我覺(jué)得這句話還是有道理的】破剑混沌工程是一種驗(yàn)證系統(tǒng)對(duì)非預(yù)期情況防御有效性的實(shí)驗(yàn)思想褥紫,任何依照”混沌工程原則”進(jìn)行的探索,都是有效實(shí)踐瞪慧。
系統(tǒng)架構(gòu)可能會(huì)很復(fù)雜髓考,比如采用了微服務(wù)、Docker弃酌、K8s氨菇,甚至函數(shù)計(jì)算類(lèi)似的技術(shù),需要實(shí)驗(yàn)項(xiàng)目也涉及很多門(mén)類(lèi)妓湘。為了更有效地實(shí)施混沌工程查蓉,就需要借助一些場(chǎng)景豐富、操作簡(jiǎn)便榜贴、模型標(biāo)準(zhǔn)的工具或技術(shù)了豌研。
混沌工程技術(shù)會(huì)隨著其他技術(shù)發(fā)展而演進(jìn),混沌工程會(huì)與融入到每個(gè)領(lǐng)域的最佳實(shí)踐中唬党。
今年開(kāi)始聂沙,我開(kāi)始在一些場(chǎng)合將自己稱(chēng)呼為” 混沌工程布道師”。
布道師初嘹,聽(tīng)起來(lái)好像有點(diǎn)“忽悠”及汉。
不過(guò),你知道皮埃羅·斯加魯菲(PieroScaruffi)嗎屯烦?這位全球人工智能及認(rèn)知科學(xué)專(zhuān)家坷随,被譽(yù)為永遠(yuǎn)站在時(shí)代前面的硅谷精神布道者,我很敬佩他驻龟。推動(dòng)技術(shù)傳播温眉,推動(dòng)技術(shù)落地,推動(dòng)行業(yè)變革翁狐,這就是布道者的意義之所在类溢。
Chaos Monkey - A resiliency tool that helps applications tolerate random instance failures.
The Simian Army - A suite of tools for keeping your cloud operating in top form.
orchestrator - MySQL replication topology management and HA.
kube-monkey - An implementation of Netflix's Chaos Monkey for Kubernetes clusters.
Gremlin Inc. - Failure as a Service.
Pumba - Chaos testing and network emulation for Docker containers (and clusters).
Chaos Toolkit - A chaos engineering toolkit to help you build confidence in your software system.
ChaoSlingr - Introducing Security Chaos Engineering. ChaoSlingr focuses primarily on the experimentation on AWS Infrastructure to proactively instrument system security failure through experimentation.
PowerfulSeal - Adds chaos to your Kubernetes clusters, so that you can detect problems in your systems as early as possible. It kills targeted pods and takes VMs up and down.
drax - DC/OS Resilience Automated Xenodiagnosis tool. It helps to test DC/OS deployments by applying a Chaos Monkey-inspired, proactive and invasive testing approach.
Wiremock - API mocking (Service Virtualization) which enables modeling real world faults and delays
MockLab - API mocking (Service Virtualization) as a service which enables modeling real world faults and delays.
Pod-Reaper - A rules based pod killing container. Pod-Reaper was designed to kill pods that meet specific conditions that can be used for Chaos testing in Kubernetes.
Muxy - A chaos testing tool for simulating a real-world distributed system failures.
Toxiproxy - A TCP proxy to simulate network and system conditions for chaos and resiliency testing.
Blockade - Docker-based utility for testing network failures and partitions in distributed applications.
chaos-lambda - Randomly terminate ASG instances during business hours.
Namazu - Programmable fuzzy scheduler for testing distributed systems.
Chaos Monkey for Spring Boot - Injects latencies, exceptions, and terminations into Spring Boot applications
Byte-Monkey - Bytecode-level fault injection for the JVM. It works by instrumenting application code on the fly to deliberately introduce faults like exceptions and latency.
GomJabbar - ChaosMonkey for your private cloud
阿里開(kāi)源混沌工程工具 ChaosBlade
https://github.com/chaosblade-io/chaosblade
ChaosBlade: 一個(gè)簡(jiǎn)單易用且功能強(qiáng)大的混沌實(shí)驗(yàn)實(shí)施工具
項(xiàng)目介紹
ChaosBlade 是阿里巴巴開(kāi)源的一款遵循混沌工程原理和混沌實(shí)驗(yàn)?zāi)P偷膶?shí)驗(yàn)注入工具,幫助企業(yè)提升分布式系統(tǒng)的容錯(cuò)能力,并且在企業(yè)上云或往云原生系統(tǒng)遷移過(guò)程中業(yè)務(wù)連續(xù)性保障闯冷。
Chaosblade 是內(nèi)部 MonkeyKing 對(duì)外開(kāi)源的項(xiàng)目砂心,其建立在阿里巴巴近十年故障測(cè)試和演練實(shí)踐基礎(chǔ)上,結(jié)合了集團(tuán)各業(yè)務(wù)的最佳創(chuàng)意和實(shí)踐蛇耀。
ChaosBlade 不僅使用簡(jiǎn)單辩诞,而且支持豐富的實(shí)驗(yàn)場(chǎng)景,場(chǎng)景包括:
- 基礎(chǔ)資源:比如 CPU纺涤、內(nèi)存译暂、網(wǎng)絡(luò)、磁盤(pán)撩炊、進(jìn)程等實(shí)驗(yàn)場(chǎng)景外永;
- Java 應(yīng)用:比如數(shù)據(jù)庫(kù)、緩存拧咳、消息伯顶、JVM 本身、微服務(wù)等呛踊,還可以指定任意類(lèi)方法注入各種復(fù)雜的實(shí)驗(yàn)場(chǎng)景;
- C++ 應(yīng)用:比如指定任意方法或某行代碼注入延遲啦撮、變量和返回值篡改等實(shí)驗(yàn)場(chǎng)景谭网;
- Docker 容器:比如殺容器、容器內(nèi) CPU赃春、內(nèi)存愉择、網(wǎng)絡(luò)、磁盤(pán)织中、進(jìn)程等實(shí)驗(yàn)場(chǎng)景锥涕;
- 云原生平臺(tái):比如 Kubernetes 平臺(tái)節(jié)點(diǎn)上 CPU、內(nèi)存狭吼、網(wǎng)絡(luò)层坠、磁盤(pán)、進(jìn)程實(shí)驗(yàn)場(chǎng)景刁笙,Pod 網(wǎng)絡(luò)和 Pod 本身實(shí)驗(yàn)場(chǎng)景如殺 Pod破花,容器的實(shí)驗(yàn)場(chǎng)景如上述的 Docker 容器實(shí)驗(yàn)場(chǎng)景;
將場(chǎng)景按領(lǐng)域?qū)崿F(xiàn)封裝成一個(gè)個(gè)單獨(dú)的項(xiàng)目疲吸,不僅可以使領(lǐng)域內(nèi)場(chǎng)景標(biāo)準(zhǔn)化實(shí)現(xiàn)座每,而且非常方便場(chǎng)景水平和垂直擴(kuò)展,通過(guò)遵循混沌實(shí)驗(yàn)?zāi)P驼玻瑢?shí)現(xiàn) chaosblade cli 統(tǒng)一調(diào)用峭梳。目前包含的項(xiàng)目如下:
- chaosblade:混沌實(shí)驗(yàn)管理工具,包含創(chuàng)建實(shí)驗(yàn)蹂喻、銷(xiāo)毀實(shí)驗(yàn)葱椭、查詢實(shí)驗(yàn)捂寿、實(shí)驗(yàn)環(huán)境準(zhǔn)備、實(shí)驗(yàn)環(huán)境撤銷(xiāo)等命令挫以,是混沌實(shí)驗(yàn)的執(zhí)行工具者蠕,執(zhí)行方式包含 CLI 和 HTTP 兩種。提供完善的命令掐松、實(shí)驗(yàn)場(chǎng)景踱侣、場(chǎng)景參數(shù)說(shuō)明,操作簡(jiǎn)潔清晰大磺。
- chaosblade-spec-go: 混沌實(shí)驗(yàn)?zāi)P?Golang 語(yǔ)言定義抡句,便于使用 Golang 語(yǔ)言實(shí)現(xiàn)的場(chǎng)景都基于此規(guī)范便捷實(shí)現(xiàn)。
- chaosblade-exec-os: 基礎(chǔ)資源實(shí)驗(yàn)場(chǎng)景實(shí)現(xiàn)杠愧。
- chaosblade-exec-docker: Docker 容器實(shí)驗(yàn)場(chǎng)景實(shí)現(xiàn)待榔,通過(guò)調(diào)用 Docker API 標(biāo)準(zhǔn)化實(shí)現(xiàn)。
- chaosblade-operator: Kubernetes 平臺(tái)實(shí)驗(yàn)場(chǎng)景實(shí)現(xiàn)流济,將混沌實(shí)驗(yàn)通過(guò) Kubernetes 標(biāo)準(zhǔn)的 CRD 方式定義锐锣,很方便的使用 Kubernetes 資源操作的方式來(lái)創(chuàng)建、更新绳瘟、刪除實(shí)驗(yàn)場(chǎng)景雕憔,包括使用 kubectl、client-go 等方式執(zhí)行糖声,而且還可以使用上述的 chaosblade cli 工具執(zhí)行斤彼。
- chaosblade-exec-jvm: Java 應(yīng)用實(shí)驗(yàn)場(chǎng)景實(shí)現(xiàn),使用 Java Agent 技術(shù)動(dòng)態(tài)掛載蘸泻,無(wú)需任何接入琉苇,零成本使用,而且支持卸載悦施,完全回收 Agent 創(chuàng)建的各種資源并扇。
- chaosblade-exec-cplus: C++ 應(yīng)用實(shí)驗(yàn)場(chǎng)景實(shí)現(xiàn),使用 GDB 技術(shù)實(shí)現(xiàn)方法抡诞、代碼行級(jí)別的實(shí)驗(yàn)場(chǎng)景注入拜马。
使用文檔
你可以從 Releases 地址下載最新的 chaosblade 工具包,解壓即用沐绒。如果想注入 Kubernetes 相關(guān)故障場(chǎng)景俩莽,需要安裝 chaosblade-operator,詳細(xì)的中文使用文檔請(qǐng)查看 chaosblade-help-zh-cn乔遮。
chaosblade 支持 CLI 和 HTTP 兩種調(diào)用方式扮超,支持的命令如下:
- prepare:簡(jiǎn)寫(xiě) p,混沌實(shí)驗(yàn)前的準(zhǔn)備,比如演練 Java 應(yīng)用出刷,則需要掛載 java agent璧疗。例如要演練的應(yīng)用名是 business,則在目標(biāo)主機(jī)上執(zhí)行
blade p jvm --process business
馁龟。如果掛載成功崩侠,返回掛載的 uid,用于狀態(tài)查詢或者撤銷(xiāo)掛載坷檩。 - revoke:簡(jiǎn)寫(xiě) r却音,撤銷(xiāo)之前混沌實(shí)驗(yàn)準(zhǔn)備,比如卸載 java agent矢炼。命令是
blade revoke UID
- create: 簡(jiǎn)寫(xiě)是 c系瓢,創(chuàng)建一個(gè)混沌演練實(shí)驗(yàn),指執(zhí)行故障注入句灌。命令是
blade create [TARGET] [ACTION] [FLAGS]
夷陋,比如實(shí)施一次 Dubbo consumer 調(diào)用 xxx.xxx.Service 接口延遲 3s,則執(zhí)行的命令為blade create dubbo delay --consumer --time 3000 --service xxx.xxx.Service
胰锌,如果注入成功骗绕,則返回實(shí)驗(yàn)的 uid,用于狀態(tài)查詢和銷(xiāo)毀此實(shí)驗(yàn)使用资昧。 - destroy:簡(jiǎn)寫(xiě)是 d酬土,銷(xiāo)毀之前的混沌實(shí)驗(yàn),比如銷(xiāo)毀上面提到的 Dubbo 延遲實(shí)驗(yàn)榛搔,命令是
blade destroy UID
- status:簡(jiǎn)寫(xiě) s诺凡,查詢準(zhǔn)備階段或者實(shí)驗(yàn)的狀態(tài)东揣,命令是
blade status UID
或者blade status --type create
- server:?jiǎn)?dòng) web server践惑,暴露 HTTP 服務(wù),可以通過(guò) HTTP 請(qǐng)求來(lái)調(diào)用 chaosblade嘶卧。例如在目標(biāo)機(jī)器xxxx上執(zhí)行:
blade server start -p 9526
尔觉,執(zhí)行 CPU 滿載實(shí)驗(yàn):curl "http:/xxxx:9526/chaosblade?cmd=create%20cpu%20fullload"
以上命令幫助均可使用 blade help [COMMAND]
或者 blade [COMMAND] -h
查看,也可查看新手指南芥吟,或者上述中文使用文檔侦铜,快速上手使用。
快速體驗(yàn)
如果想不下載 chaosblade 工具包钟鸵,快速體驗(yàn) chaosblade钉稍,可以拉取 docker 鏡像并運(yùn)行,在容器內(nèi)體驗(yàn)棺耍。
操作步驟如下:
下載鏡像:
docker pull chaosbladeio/chaosblade-demo
啟動(dòng)鏡像:
docker run -it --privileged chaosbladeio/chaosblade-demo
進(jìn)入鏡像之后贡未,可閱讀 README.txt 文件實(shí)施混沌實(shí)驗(yàn),Enjoy it。
面向云原生
chaosblade-operator 項(xiàng)目是針對(duì)云原生平臺(tái)所實(shí)現(xiàn)的混沌實(shí)驗(yàn)注入工具俊卤,遵循混沌實(shí)驗(yàn)?zāi)P鸵?guī)范化實(shí)驗(yàn)場(chǎng)景嫩挤,把實(shí)驗(yàn)定義為 Kubernetes CRD 資源,將實(shí)驗(yàn)?zāi)P陀成錇?Kubernetes 資源屬性消恍,很友好的將混沌實(shí)驗(yàn)?zāi)P团c Kubernetes 聲明式設(shè)計(jì)結(jié)合在一起岂昭,依靠混沌實(shí)驗(yàn)?zāi)P捅憬蓍_(kāi)發(fā)場(chǎng)景的同時(shí),又可以很好的結(jié)合 Kubernetes 設(shè)計(jì)理念狠怨,通過(guò) kubectl 或者編寫(xiě)代碼直接調(diào)用 Kubernetes API 來(lái)創(chuàng)建约啊、更新、刪除混沌實(shí)驗(yàn)取董,而且資源狀態(tài)可以非常清晰的表示實(shí)驗(yàn)的執(zhí)行狀態(tài)棍苹,標(biāo)準(zhǔn)化實(shí)現(xiàn) Kubernetes 故障注入。除了使用上述方式執(zhí)行實(shí)驗(yàn)外茵汰,還可以使用 chaosblade cli 方式非常方便的執(zhí)行 kubernetes 實(shí)驗(yàn)場(chǎng)景枢里,查詢實(shí)驗(yàn)狀態(tài)等。具體請(qǐng)閱讀:云原生下的混沌工程實(shí)踐
編譯
此項(xiàng)目采用 golang 語(yǔ)言編寫(xiě)蹂午,所以需要先安裝最新的 golang 版本栏豺,最低支持的版本是 1.11。Clone 工程后進(jìn)入項(xiàng)目目錄執(zhí)行以下命令進(jìn)行編譯:
make
如果在 mac 系統(tǒng)上豆胸,編譯當(dāng)前系統(tǒng)的版本奥洼,請(qǐng)執(zhí)行:
make build_darwin
如果想在 mac 系統(tǒng)上,編譯 linux 系統(tǒng)版本晚胡,請(qǐng)執(zhí)行:
make build_linux
也可以選擇性編譯灵奖,比如只需要編譯 cli、os 場(chǎng)景估盘,則執(zhí)行:
make build_with cli os
# 如果是 mac 系統(tǒng)瓷患,執(zhí)行
make build_with cli os_darwin
# 如果是 mac 系統(tǒng),想選擇性的編譯 linux 版本的 cli遣妥,os擅编,則執(zhí)行:
ARGS="cli os" make build_with_linux
缺陷&建議
歡迎提交缺陷、問(wèn)題箫踩、建議和新功能爱态,所有項(xiàng)目(包含其他子項(xiàng)目)的問(wèn)題都可以提交到Github Issues
你也可以通過(guò)以下方式聯(lián)系我們:
- 釘釘群(推薦):23177705
- Gitter room: https://gitter.im/chaosblade-io/community
- 郵箱:chaosblade.io.01@gmail.com
- Twitter: chaosblade.io
參與貢獻(xiàn)
我們非常歡迎每個(gè) Issue 和 PR,即使一個(gè)標(biāo)點(diǎn)符號(hào)境钟,如何參加貢獻(xiàn)請(qǐng)閱讀 CONTRIBUTING 文檔锦担,或者通過(guò)上述的方式聯(lián)系我們。
企業(yè)登記
我們開(kāi)源此項(xiàng)目的初衷是降低混沌工程在企業(yè)中落地的門(mén)檻慨削,所以非扯从妫看重該項(xiàng)目在企業(yè)的使用情況鱼的,歡迎大家在此 ISSUE 中登記,登記后會(huì)被邀請(qǐng)加入企業(yè)郵件組痘煤,探討混沌工程在企業(yè)落地中遇到的問(wèn)題和分享落地經(jīng)驗(yàn)凑阶。
未來(lái)規(guī)劃
- 增強(qiáng)云原生領(lǐng)域場(chǎng)景
- Golang 應(yīng)用混沌實(shí)驗(yàn)場(chǎng)景
- NodeJS 應(yīng)用混沌實(shí)驗(yàn)場(chǎng)景
- 故障演練控制臺(tái)
- 完善 ChaosBlade 各項(xiàng)目的開(kāi)發(fā)文檔
- 完善 chaosblade 工具的英文文檔
License
Chaosblade 遵循 Apache 2.0 許可證,詳細(xì)內(nèi)容請(qǐng)閱讀 LICENSE
參考資料
https://github.com/chaosblade-io/chaosblade
https://www.sohu.com/a/301663472_355140
http://www.reibang.com/p/4bd4f88e24e4
https://blog.csdn.net/b0Q8cpra539haFS7/article/details/86698060
https://zhuanlan.zhihu.com/p/90294032
https://www.infoq.cn/article/EEKM947YbboGtD_zQuLw
https://www.gremlin.com/community/tutorials/chaos-engineering-the-history-principles-and-practice/
https://www.oschina.net/news/105679/alibaba-opensource-chaosblade
https://github.com/dastergon/awesome-chaos-engineering
Kotlin開(kāi)發(fā)者社區(qū)
專(zhuān)注分享 Java衷快、 Kotlin宙橱、Spring/Spring Boot、MySQL蘸拔、redis师郑、neo4j、NoSQL调窍、Android宝冕、JavaScript、React邓萨、Node地梨、函數(shù)式編程、編程思想缔恳、"高可用宝剖,高性能,高實(shí)時(shí)"大型分布式系統(tǒng)架構(gòu)設(shè)計(jì)主題歉甚。
High availability, high performance, high real-time large-scale distributed system architecture design万细。
分布式框架:Zookeeper、分布式中間件框架等
分布式存儲(chǔ):GridFS纸泄、FastDFS赖钞、TFS、MemCache聘裁、redis等
分布式數(shù)據(jù)庫(kù):Cobar雪营、tddl、Amoeba咧虎、Mycat
云計(jì)算卓缰、大數(shù)據(jù)计呈、AI算法
虛擬化砰诵、云原生技術(shù)
分布式計(jì)算框架:MapReduce、Hadoop捌显、Storm茁彭、Flink等
分布式通信機(jī)制:Dubbo、RPC調(diào)用扶歪、共享遠(yuǎn)程數(shù)據(jù)理肺、消息隊(duì)列等
消息隊(duì)列MQ:Kafka摄闸、MetaQ,RocketMQ
怎樣打造高可用系統(tǒng):基于硬件妹萨、軟件中間件年枕、系統(tǒng)架構(gòu)等一些典型方案的實(shí)現(xiàn):HAProxy、基于Corosync+Pacemaker的高可用集群套件中間件系統(tǒng)
Mycat架構(gòu)分布式演進(jìn)
大數(shù)據(jù)Join背后的難題:數(shù)據(jù)乎完、網(wǎng)絡(luò)熏兄、內(nèi)存和計(jì)算能力的矛盾和調(diào)和
Java分布式系統(tǒng)中的高性能難題:AIO,NIO树姨,Netty還是自己開(kāi)發(fā)框架摩桶?
高性能事件派發(fā)機(jī)制:線程池模型、Disruptor模型等等帽揪。硝清。。
合抱之木转晰,生于毫末芦拿;九層之臺(tái),起于壘土查邢;千里之行防嗡,始于足下。不積跬步侠坎,無(wú)以至千里蚁趁;不積小流,無(wú)以成江河实胸。