混沌工程和軟件系統穩定性實踐在技術大會上沒啥可講的?

什么是混沌工程?用一句簡單的話來解釋,就是使用科學方法,用做有對照組的實驗,來實證復雜的分布式軟件系統,能夠在生產環境抵御來自現實世界不可預知的各種狀況。

混沌工程在官網(PRINCIPLES OF CHAOS ENGINEERING)的正式定義,是一門對軟件系統進行實驗的學科,目的是建立對系統承受生產環境中動蕩條件的能力的信心。

承受生產環境中動蕩條件

根據InfoQ最近3年推出的DevOps和云技術趨勢鴻溝曲線顯示,在國外,混沌工程實踐已經在2022年跨過早期采納者和早期大眾之間的鴻溝,進入業界主流。因為國內業界對于創新工程實踐的采納相對滯后,估計混沌工程在國內應該有3~5年左右就能跨過鴻溝,進入主流。

2021年混沌工程實踐停留在鴻溝曲線的早期采納者區間
2022年混沌工程實踐首次進入鴻溝曲線的早期大眾區間
2023年混沌工程實踐保持在鴻溝曲線的早期大眾區間

混沌工程在Thoughtworks公司的技術雷達上的位置,也能從側面印證這一點。

技術雷達可視化了該公司以企業定制化軟件開發見長的開發人員所遠離和青睞的各種最新的軟件開發技術和過程。雷達從外到內,分為4個環。最外的暫緩環中的技術,是開發人員所遠離的。之后從外到內依次是評估環、試點環和采納環。越往圓心的環中的技術,開發人員越青睞。

混沌工程在2017年首次進入技術雷達,就進入了試點環。此后的兩年,就一直停留在這個環。與混沌工程相關的安全混沌工程,2018年首次進入技術雷達,是在評估環。同年晚些時候,又移動到了試點環。

在Thoughtworks于2019年4月發布的技術雷達中,混沌工程保持在試點環

技術雷達的評估環,可以對應鴻溝曲線的創新者(Innovators)區間;試點環對應早期采納者(Early Adopters)區間;采納環對應早期大眾(Early Majority)和后期大眾(Late Majority)區間。

喜歡應用新技術的Thoughtworks的開發人員,目前應該屬于鴻溝曲線的早期采納者,正向早期大眾轉化。

最近我在K+全球軟件研發行業創新峰會2023北京大會中,做“混沌工程應用”專題的出品人。在收集和篩選演講話題時,發現一些企業,不太愿意來分享。原因是前兩年在國內“混沌工程”早期試點階段,他們已經在大會上分享過這個話題了。最近也沒有什么新的內容可講。

具體來說,根據我在之前所參與的相關咨詢項目中的觀察,大部分企業實踐混沌工程,主要集中在兩個方面。

第一,構建工具平臺。包括工具平臺的建設過程,以及相關的系統架構。

第二,故障注入實驗。包括故障庫、故障注入編排和故障注入演練。其中故障庫中的原子故障,主要是針對基礎設施層和容器平臺層的虛擬機、容器、pod和node。如果是甲方購買了乙方的虛擬機和容器平臺,然后再在上面做相關的故障注入實驗,本質上是甲方再次花錢為乙方做回歸測試。

企業一旦在上面兩個方面開展混沌工程應用工作,過程就相對固化下來。自然在分享了一次之后,就沒有什么可再分享的新內容了。另外,這兩個方面,是不是給你一個在小池塘中蕩舟的四平八穩的感覺,而不是混沌工程本應有的面對大海般動蕩和不確定的生產環境事件的感覺。

混沌工程和軟件系統穩定性工程實踐,如何做得有好內容可講?

可以做下面兩類更有意思的實踐。

第一,人的協作相關的實踐。比如可以問自己下面的問題。

1 企業各個角色,如業務人員、開發人員、測試人員、運維人員、平臺團隊,在混沌工程應用中的協作機制是什么樣的?

2 你們用了什么機制,保障所注入的故障能反映多樣化的生產環境的現實世界的動蕩情況?比如是否歸納了以往生產系統停機的原因并將其納入故障庫?是否實踐了藍軍行動?藍軍小組由哪個部門牽頭領導?是公司級別的?還是部門級別的?還是開發組級別的?藍軍與紅軍是如何協作的?能否舉一個紅藍軍協作開展混沌工程實驗(從測試環境到生產環境)的整個過程的例子?

3 你們在實踐混沌工程時,遇到了什么阻力?你們是如何應對阻力的?

4 企業內的分布式系統一般會由多個開發團隊維護。即使分布式系統中的所有單個服務都正常運行,這些服務之間的交互也可能會導致不可預測的結果。這些結果,再加上影響生產環境的罕見但具有破壞性的現實世界的事件,使得這些分布式系統本質上是混沌的。你們的混沌工程實踐,是否主要是集中于單個團隊所維護的單個服務?如果涉及兩個團隊所維護的兩個服務之間的交互的故障注入實驗,你們是如何協調這兩個團隊進行實驗的?

第二,有挑戰的技術和過程相關的實踐。比如可以問自己下面的問題。

1 故障注入實驗是否經常在生產環境執行?還是只在測試或準生產環境執行?如果從未在生產環境執行,顧慮是什么?

2 你們所實踐的混沌工程應用,與傳統的測試團隊的軟件測試,以及與運維部門的傳統故障演練,有什么區別?差異化優勢在哪里?

3 如何保障故障注入后的最小化爆炸半徑?

4 你們所開展的故障注入實驗,是否主要針對基礎設施層或容器平臺層?是否有針對應用服務層做故障注入實驗?比如服務不可用時的后備設置不當,由于超時調整不當而導致用戶的重試風暴,當所依賴的服務接收過多流量時發生延時、服務中斷或返回錯誤碼,單點故障崩潰時的所導致的級聯故障等等。

5 你們向領導匯報混沌工程成效時,具體使用了哪些指標?成效數據前后是如何對比的?

你可以思考上面這9組問題。選出一個能啟發你把混沌工程和軟件系統穩定性工程實踐做得有意思的,并嘗試解決該問題。在這個過程中,相信你會有好內容可講。

我已經在知乎開設了“吾真本說軟件系統穩定運行”專欄,并建了相關的討論小組。如果你對混沌工程和軟件系統穩定性工程實踐感興趣,歡迎在知乎我的專欄里給我留言“混沌討論”,我會告訴你我的聯系方式,拉你進入討論小組,一起討論。

企業生意蒸蒸日上,軟件系統穩定運行。這就是“吾真本說軟件系統穩定運行”專欄所關注的。

?著作權歸作者所有,轉載或內容合作請聯系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 227,702評論 6 531
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,143評論 3 415
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 175,553評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,620評論 1 307
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,416評論 6 405
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 54,940評論 1 321
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,024評論 3 440
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,170評論 0 287
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,709評論 1 333
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,597評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,784評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,291評論 5 357
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,029評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,407評論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,663評論 1 280
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,403評論 3 390
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,746評論 2 370

推薦閱讀更多精彩內容