一、背景
從 2010 年 Netflix 上線 Chaos Mokey 的第一個版本到現(xiàn)在，雖然混沌工程發(fā)展已歷時十年，但其實只在少數(shù)大廠里面有較成熟的落地，對絕大部分研發(fā)同學(xué)來說，混沌工程還是一個比較陌生的領(lǐng)域。
分布式和微服務(wù)化已經(jīng)成為主流的系統(tǒng)架構(gòu)設(shè)計方案，大規(guī)模分布式系統(tǒng)的可用性保障能力越來越成為關(guān)注的重點。混沌工程也開始如雨后春筍般在各大企業(yè)內(nèi)部萌芽生長，但大部分還處于初期的探索階段，在實踐過程中也遇到了這樣或那樣的問題，有技術(shù)上也有認知層面上的，這些問題難免會對混沌工程的快速落地產(chǎn)生阻力。
下面介紹一下字節(jié)跳動在混沌工程實踐過程中的一個關(guān)鍵階段：場景化主動實驗。希望本文可以幫助大家加深對混沌工程價值的了解，對設(shè)計混沌工程實驗、落地混沌工程建設(shè)提供更多的思路。
二、什么是場景化主動實驗
混沌工程的高級原則要求能夠在生產(chǎn)環(huán)境自動的運行實驗，這個目標(biāo)并不是一蹴而就的。
根據(jù)混沌工程成熟度模型(CMM)[4]說明，要分別從“熟練度”和“應(yīng)用度”兩個維度同時進行建設(shè)。其中，“熟練度”體現(xiàn)了混沌工程系統(tǒng)的有效性和安全性，“應(yīng)用度”衡量了混沌工程實驗覆蓋的廣度和深度。在混沌工程建設(shè)的中前期，這兩點都是混沌工程成功落地的關(guān)鍵路徑。
在混沌工程的初級階段，通常都會建設(shè)一個故障注入測試平臺（FIT，F(xiàn)ault Inject Testing），集成一些常見的故障場景或異常事件的模擬能力，由業(yè)務(wù)或 QA 同學(xué)設(shè)計并執(zhí)行實驗來驗證系統(tǒng)的韌性能力。
在這個階段，基礎(chǔ)架構(gòu)和業(yè)務(wù)系統(tǒng)的實現(xiàn)都可能處于比較粗放狀態(tài)，混沌工程平臺的故障注入能力需要兼容各種業(yè)務(wù)架構(gòu)的實現(xiàn)方案和軟硬件環(huán)境，執(zhí)行實驗時，業(yè)務(wù)同學(xué)不僅要設(shè)計實驗的故障場景（機房網(wǎng)絡(luò)故障、下游服務(wù)宕機等）、配置演練環(huán)境（目標(biāo)服務(wù)、實驗集群等控制實驗的爆炸半徑），還要找到能夠描述實驗時服務(wù)狀態(tài)的穩(wěn)定性的指標(biāo)（如 metrics、日志或告警等），然后手動啟動實驗，執(zhí)行人還要不停的觀察穩(wěn)定性指標(biāo)的變化，判斷系統(tǒng)的容災(zāi)邏輯或彈性策略是否被正確觸發(fā)、業(yè)務(wù)系統(tǒng)的表現(xiàn)是否符合預(yù)期等等。如果在執(zhí)行過程中發(fā)現(xiàn)異常，需要立刻終止實驗，收斂實驗影響。
整個實驗過程的人力成本較高，實驗的操作門檻也較高，再加上這個階段業(yè)務(wù)同學(xué)對混沌工程價值和理念的認知還處于較初級水平，很難會主動對自己的服務(wù)設(shè)計實驗，更無法保證實驗的常態(tài)化執(zhí)行。因此，混沌工程實驗的時效性和業(yè)務(wù)系統(tǒng)的彈性容災(zāi)策略持續(xù)有效就比較難以保證了。
如何突破這個階段、成功抵達混沌工程的終極目標(biāo)呢？
通過不斷的思考，我們認為混沌工程建設(shè)需要一個過渡階段，即場景化主動演練。
所謂場景化主動演練，就是在明確混沌工程的終極建設(shè)目標(biāo)的前提下，以終為始，分階段去設(shè)計混沌工程的實驗標(biāo)準(zhǔn)、定義技術(shù)規(guī)范，搭配工程化能力，逐步將人和業(yè)務(wù)引導(dǎo)到混沌工程建設(shè)的高速公路上，共同推進 CMM 模型的熟練度和應(yīng)用度。
(CMM是指“能力成熟度模型”，其英文全稱為Capability Maturity Model for Software，英文縮寫為SW-CMM，簡稱CMM。它是對于軟件組織在定義、實施、度量、控制和改善其軟件過程的實踐中各個發(fā)展階段的描述。CMM的核心是把軟件開發(fā)視為一個過程，并根據(jù)這一原則對軟件開發(fā)和維護進行過程監(jiān)控和研究，以使其更加科學(xué)化、標(biāo)準(zhǔn)化、使企業(yè)能夠更好地實現(xiàn)商業(yè)目標(biāo)。此外還是化妝品的名字。)
所以，場景化主動實驗是通向混沌工程自動化建設(shè)的關(guān)鍵路徑。
三、如何建設(shè)場景化主動實驗
首先需要明確混沌工程的最終目標(biāo)，以終為始，反推當(dāng)前階段應(yīng)該建設(shè)什么樣的技術(shù)規(guī)范和標(biāo)準(zhǔn)能力。
然后，根據(jù)業(yè)務(wù)當(dāng)前的基礎(chǔ)架構(gòu)現(xiàn)狀和實驗訴求構(gòu)建一個通用的實驗場景，由混沌工程平臺方在保證實驗風(fēng)險可控的條件下主動對業(yè)務(wù)系統(tǒng)進行實驗。這樣，在滿足業(yè)務(wù)需要的同時又可以推動相關(guān)技術(shù)規(guī)范和基礎(chǔ)能力的建設(shè)，而且對業(yè)務(wù)同學(xué)的資源依賴較少。
以字節(jié)跳動為例，要實現(xiàn)在生產(chǎn)環(huán)境自動的執(zhí)行可控的混沌工程實驗，當(dāng)前階段應(yīng)該具備的能力包括：
能夠在生產(chǎn)環(huán)境持續(xù)的運行實驗并具備實驗爆炸半徑的控制能力
選定一個命中業(yè)務(wù)痛點且通用的實驗場景，構(gòu)建通用的自動化執(zhí)行實驗?zāi)芰?/p>
能夠描述服務(wù)穩(wěn)定性的通用指標(biāo)
自動檢測穩(wěn)定性指標(biāo)的變化
自動終止實驗【在實驗爆炸半徑可控的情況下，非必須】
四、主動實驗
FIT 平臺需要業(yè)務(wù)同學(xué)分析業(yè)務(wù)容災(zāi)場景并制定實驗，然后執(zhí)行實驗進行驗證，混沌工程平臺方只是給予一些技術(shù)支持和建議。在業(yè)務(wù)同學(xué)對混沌工程認知度不高情況下，實驗的主動性、覆蓋率、時效性都很難保證，如果再想讓業(yè)務(wù)同學(xué)去配合建設(shè)一些混沌工程的基礎(chǔ)能力難度就可想而知。
轉(zhuǎn)換一下思路，將業(yè)務(wù)主動改為平臺主動！由混沌平臺針對業(yè)務(wù)系統(tǒng)的某個場景主動執(zhí)行混動實驗來驗證服務(wù)的彈性能力，業(yè)務(wù)同學(xué)只需關(guān)注實驗結(jié)果。只要實驗場景契合業(yè)務(wù)痛點、實驗結(jié)果對業(yè)務(wù)構(gòu)建彈性系統(tǒng)有意義，業(yè)務(wù)同學(xué)自然會認可混沌工程的價值，也會更加積極的參與混沌工程實驗和混沌工程的基礎(chǔ)建設(shè)。
五、實驗場景
混沌工程的價值是發(fā)現(xiàn)業(yè)務(wù)系統(tǒng)中潛在薄弱環(huán)節(jié)，提升業(yè)務(wù)系統(tǒng)韌性能力，即服務(wù)可用性和穩(wěn)定性，所以主動實驗場景也應(yīng)該滿足這個前提。
在字節(jié)跳動，主動實驗落地的第一個場景是驗證服務(wù)調(diào)用鏈的強弱依賴關(guān)系。所謂強弱依賴關(guān)系，就是當(dāng)訪問的下游服務(wù)異常（服務(wù)宕機、響應(yīng)超時、接口返回失敗等）時，調(diào)用方的穩(wěn)定性和可用性是否會受到影響。例如，查詢緩存 miss 或失敗后可以繼續(xù)回源訪問數(shù)據(jù)庫，緩存的問題并不會影響服務(wù)可用性，這個緩存就是個弱依賴。
為什么要選擇這個場景呢？公司的很多線上運營事故都是因為不合理的依賴關(guān)系導(dǎo)致的。字節(jié)跳動有很多高 QPS 的海量服務(wù)系統(tǒng)，為了保證用戶體驗，對高可用高穩(wěn)定性的要求很高，會通過各種緩存、服務(wù)兜底、數(shù)據(jù)兜底等容災(zāi)策略來減少強依賴服務(wù)的數(shù)量。另外，在字節(jié)跳動的服務(wù)治理體系中，會根據(jù)服務(wù)間的強弱依賴調(diào)用關(guān)系為某些故障場景預(yù)設(shè)自動容災(zāi)降級的策略。比如，當(dāng)服務(wù)治理系統(tǒng)檢測到系統(tǒng)負載過高時，能夠自動對弱依賴的下游執(zhí)行降級，通過 FailFast 來緩解系統(tǒng)的負載。因此，業(yè)務(wù)負責(zé)人通常都會比較關(guān)注服務(wù)的強弱依賴關(guān)系。
六、自動化
主動設(shè)計和執(zhí)行實驗意味著將業(yè)務(wù)側(cè)的人力成本轉(zhuǎn)嫁給了混沌平臺，混沌平臺必須要借助通用化、自動化的執(zhí)行能力來降低人力成本。需要強調(diào)的是，這里的通用化和自動化一定是和混沌工程的終極目標(biāo)一致的，能夠承載過渡階段的職責(zé)。
可以從混沌工程的高級原則[2]進行剖析：
服務(wù)的穩(wěn)定狀態(tài)假設(shè)：找出能夠描述服務(wù)穩(wěn)定狀態(tài)的通用指標(biāo)，可以是 metrics、告警等。執(zhí)行實驗前，這些穩(wěn)定狀態(tài)指標(biāo)應(yīng)處于穩(wěn)定狀態(tài)；執(zhí)行實驗時，如果服務(wù)的可用性或穩(wěn)定性受到影響時，穩(wěn)定性指標(biāo)會發(fā)生變化，比如 metrics 曲線的劇烈波動、觸發(fā)告警等；當(dāng)實驗結(jié)束后，穩(wěn)定性指標(biāo)又會恢復(fù)到之前的穩(wěn)定狀態(tài)。如果執(zhí)行實驗時，穩(wěn)定狀態(tài)假設(shè)發(fā)生了變化，說明這是個強依賴。
https://www.cnblogs.com/MrRightZhao/p/10975107.html
在應(yīng)用程序中，通常會記錄日志以便事后分析，在很多情況下是產(chǎn)生了問題之后，再去查看日志，是一種事后的靜態(tài)分析。在很多時候，我們可能需要了解整個系統(tǒng)在當(dāng)前，或者某一時刻運行的情況，比如一個系統(tǒng)后臺服務(wù)，我們可能需要了解一些實時監(jiān)控的數(shù)據(jù)例如
1、每秒鐘的請求數(shù)是多少（TPS）？
2、平均每個請求處理的時間？
3、請求處理的最長耗時？
4.? 請求處理的響應(yīng)的直方圖？
5、請求處理正確響應(yīng)率？
6、等待處理的請求隊列長度？
7、查看整個系統(tǒng)的的CPU使用率、內(nèi)存占用、jvm運行情況；以及系統(tǒng)運行出錯率等等一系列的實時數(shù)據(jù)采集時，最簡單的方法就是在系統(tǒng)的入口、出口和關(guān)鍵位置設(shè)置埋點，然后將采集到的信息發(fā)送到實時監(jiān)控平臺或者存入到緩存和DB中做進一步的分析和展示。
Metrics作為一款監(jiān)控指標(biāo)的度量類庫，提供了許多工具幫助開發(fā)者來完成各項數(shù)據(jù)的監(jiān)控。
詳見官方文檔：https://metrics.dropwizard.io/3.1.0/manual/core/
生產(chǎn)環(huán)境運行實驗：在風(fēng)險可控的條件下推薦在生產(chǎn)環(huán)境運行實驗，因為系統(tǒng)的行為會根據(jù)環(huán)境和流量模式的不同而有所不同，系統(tǒng)用戶也不會像你所預(yù)期的那樣與你的系統(tǒng)進行交互。當(dāng)然，在生產(chǎn)環(huán)境執(zhí)行混沌工程實驗很可能是有損的，為了避免對用戶體驗產(chǎn)生較大影響，一定要控制好實驗的爆炸半徑，比如篩選出少量的實驗流量，這就要求混沌平臺具備實驗流量篩選與調(diào)度的能力。
多樣化現(xiàn)實世界事件：也就是各種故障的模擬能力。因為是場景化實驗，所以對多樣化的訴求倒不像 FIT 那樣強烈。
最小化“爆炸半徑”：如果選擇在線上環(huán)境執(zhí)行實驗，需要具備篩選實驗流量的能力，即篩選出滿足實驗所需的最小流量即可，嚴(yán)格控制“爆炸”的影響范圍。
持續(xù)自動化運行實驗：通過工程化能力將實驗?zāi)繕?biāo)過濾、實驗流量篩選、執(zhí)行實驗、穩(wěn)定狀態(tài)檢測、生成實驗報表、實驗結(jié)果反饋收集等流程串聯(lián)成自動化的執(zhí)行流，減少人力依賴。另外，混沌工程實驗從來都不是一錘子買賣，應(yīng)該通過常態(tài)化的運行實驗來持續(xù)的保證服務(wù)的高可用和彈性機制符合預(yù)期。
七、服務(wù)標(biāo)準(zhǔn)與技術(shù)規(guī)范
一個公司內(nèi)部通常會有很多條產(chǎn)品線，每個產(chǎn)品又會包含很多微服務(wù)，還會依賴到中臺服務(wù)或基礎(chǔ)組件，這些不同模塊的開發(fā)語言、服務(wù)框架、技術(shù)棧等可能五花八門。要想實現(xiàn)混沌工程通用化與自動化的能力，就必須制定一些通用的服務(wù)標(biāo)準(zhǔn)和技術(shù)規(guī)范。
混沌工程不僅需要了解業(yè)務(wù)系統(tǒng)當(dāng)前的技術(shù)棧，還要能夠預(yù)測未來的技術(shù)發(fā)展趨勢，幫助業(yè)務(wù)提前規(guī)劃切實可行的技術(shù)規(guī)范并協(xié)助進行建設(shè)。
舉個例子，如何定義服務(wù)的穩(wěn)定狀態(tài)？
在字節(jié)跳動，我們以調(diào)用方視角定義了一個服務(wù)級別的 metrics 指標(biāo)來描述服務(wù)的穩(wěn)定性狀態(tài)：
被調(diào)方在響應(yīng)包中添加一個通用的 stability 字段來標(biāo)識本次請求的處理結(jié)果是否成功
調(diào)用方從響應(yīng)包中解析出 stability 字段并上報 metrics。某些異常場景（如被調(diào)方無響應(yīng)）導(dǎo)致調(diào)用方無法解析出 stability 字段，會上報一個特殊的不穩(wěn)定值。
之所以要在響應(yīng)包中單獨定義一個 stability 字段是為了區(qū)分開系統(tǒng)錯誤和業(yè)務(wù)錯誤。因為業(yè)務(wù)錯誤并不表示服務(wù)出現(xiàn)了問題，所以我們更關(guān)注系統(tǒng)錯誤。舉個例子，刪除好友時被調(diào)方返回好友不存在的錯誤，這個錯誤并不表示系統(tǒng)的穩(wěn)定性出現(xiàn)了問題。
這個規(guī)范最開始只在字節(jié)跳動的少數(shù)核心服務(wù)中使用，其他服務(wù)通常都有自己的穩(wěn)定性指標(biāo)，有些服務(wù)可能需要多個 metrics 指標(biāo)一起來描述服務(wù)的穩(wěn)定性。因為混沌工程的通用性要求應(yīng)該具備一種通用的指標(biāo)來描述所有服務(wù)的穩(wěn)定性狀態(tài)，經(jīng)過評估，我們將 stability metrics 作為了混沌工程的服務(wù)通用穩(wěn)定性描述指標(biāo)，并計劃將其推廣到全公司的業(yè)務(wù)，無論什么服務(wù)框架和開發(fā)語言都可以低成本的快速實現(xiàn)。
八、字節(jié)跳動的混沌工程概況
字節(jié)跳動的混沌工程體系主要包括場景化主動實驗平臺、FIT 平臺和紅藍對抗平臺。
場景化主動實驗平臺：以平臺視角主動對業(yè)務(wù)發(fā)起混沌實驗，在驗證業(yè)務(wù)系統(tǒng)的高可用和彈性能力的同時推動服務(wù)標(biāo)準(zhǔn)化和技術(shù)標(biāo)準(zhǔn)化建設(shè)，提升混沌工程價值產(chǎn)出和影響力，為實現(xiàn)混沌工程的終極目標(biāo)做好鋪墊。
FIT 平臺：業(yè)務(wù)同學(xué)自助驗證服務(wù)容災(zāi)機制的正確性，具備各種異常事件和故障模擬能力，提供了靈活的可視化實驗編排能力。
紅藍對抗平臺：以第三方視角，用系統(tǒng)化、隨機化的對抗實驗方式來驗證業(yè)務(wù)系統(tǒng)的高可用水平、監(jiān)控和告警的有效性，以及異常情況下人工介入時機、故障定位和故障恢復(fù)時間是否達標(biāo)等。
九、字節(jié)跳動的場景化主動實驗建設(shè)方案
1. 實驗?zāi)繕?biāo)
同時推進混沌工程建設(shè)的“熟練度”和“應(yīng)用度”，以生產(chǎn)環(huán)境自動執(zhí)行混沌工程實驗為目標(biāo)構(gòu)建場景化主動實驗的流程和標(biāo)準(zhǔn)，實驗場景選定為驗證服務(wù)間的強弱依賴調(diào)用關(guān)系，可自動化運行實驗，具備實驗爆炸半徑控制能力。
通過驗證強弱依賴調(diào)用關(guān)系的正確性反推服務(wù)的穩(wěn)定性指標(biāo)是否規(guī)范，推動穩(wěn)定性指標(biāo)的規(guī)范落地。
2. 實驗對象
優(yōu)先在字節(jié)跳動的核心服務(wù)落地，樹立模范標(biāo)桿，然后擴展到更大范圍。
3. 穩(wěn)定性指標(biāo)&波動自動化檢測
穩(wěn)定指標(biāo)：
因為 stability metrics 已經(jīng)被多數(shù)核心服務(wù)當(dāng)做通用的穩(wěn)定性描述指標(biāo)，所以場景化主動演練將 stability metrics 作為穩(wěn)定性描述的核心指標(biāo)，同時輔助判斷接口成功 qps、失敗 qps、調(diào)用下游成功 qps、失敗 qps、pct99 等指標(biāo)。
指標(biāo)波動檢測方案：
自動化執(zhí)行實驗要求混沌平臺能夠自動檢測穩(wěn)定性指標(biāo)的變動，因為不同服務(wù)的指標(biāo)曲線是不一樣的，同一服務(wù)的不同時刻的指標(biāo)曲線也是不一樣的，所以預(yù)置曲線波動的閾值上限的效果肯定不會太好。因此，在項目啟動階段我們就直接探索自動化的動態(tài)檢測 metrics 曲線波動的方案：
一種是 Netflix 介紹的 AB test 方案，對比實驗曲線和樣本曲線的差異
一種是實時計算曲線的變化趨勢
由于方案一要求具備更靈活的流量篩選能力和實驗環(huán)境隔離能力，當(dāng)前階段的建設(shè)難度和成本較高，所以我們選擇了方案二。
自動化波動檢測：
起初我們參考線上報警的檢測方案：在執(zhí)行主動演練時，先通過機器學(xué)習(xí)為穩(wěn)定性指標(biāo)實時訓(xùn)練檢測模型，然后用模型實時檢測指標(biāo)曲線的變化。但是，因為主動實驗的時間較短（一個實驗節(jié)點只有 60~120 秒）、metrics 數(shù)據(jù)點稀疏（一個節(jié)點的實驗時間只能采集到 2~4 個數(shù)據(jù)點）、實驗流量較低（爆炸半徑控制在 5~10 QPS），所以基于機器學(xué)習(xí)的檢測效果并不理想。
于是，我們改成組合多種統(tǒng)計規(guī)則的檢測算法，根據(jù)最近一段時間的歷史數(shù)據(jù)動態(tài)生成曲線的合理波動范圍閾值，然后在實驗過程中實時檢測增量數(shù)據(jù)點的波動范圍。如果數(shù)據(jù)點超出了波動范圍閾值，就被判定為不穩(wěn)定。
經(jīng)過不斷調(diào)優(yōu)，最終把這個場景下的指標(biāo)檢測效果優(yōu)化到了預(yù)期水平。
優(yōu)化方案：
在實踐中，我們發(fā)現(xiàn)單個穩(wěn)定性指標(biāo)的曲線會偶現(xiàn)非預(yù)期的波動噪音，這些噪音會影響曲線檢測結(jié)果的準(zhǔn)確率。
于是，我們增加了一個噪音過濾策略：通過對比有相關(guān)性的多條穩(wěn)定性指標(biāo)曲線的波動相似度來過濾噪音。舉個例子，對下游依賴服務(wù)注入故障后，調(diào)用下游服務(wù)失敗的 metrics 曲線會上升，如果穩(wěn)定性指標(biāo)曲線也上升，而且這兩個曲線的變化趨勢也相似時，才會認為曲線變化是受實驗的影響。這個策略能夠比較有效的過濾掉偶現(xiàn)的曲線波動噪音。
具備了穩(wěn)定狀態(tài)的檢測能力，在場景化主動實驗時就可以根據(jù)穩(wěn)定狀態(tài)的檢測結(jié)果自動推斷下游依賴服務(wù)是強依賴還是弱依賴。
4. 最小化爆炸半徑控制
為了保證實驗的通用性和降低構(gòu)造實驗流量的成本，我們選定在生產(chǎn)環(huán)境執(zhí)行實驗，因此最小化爆炸半徑控制能力就非常重要了。
字節(jié)跳動的生產(chǎn)環(huán)境有個用于服務(wù)灰度上線的金絲雀集群，在服務(wù)上線時會先升級這個集群來驗證服務(wù)的正確性。這個集群的實例比較少，且支持通過修改集群權(quán)重來調(diào)整進入集群流量。
經(jīng)過驗證，實驗流量在 5~10QPS 時就可以保證穩(wěn)定性 metrics 指標(biāo)檢測的準(zhǔn)確率。所以，執(zhí)行實驗時，先從服務(wù)的金絲雀集群中隨機選擇一個實例作為實驗?zāi)繕?biāo)，計算實例流量與預(yù)期流量的偏差重新生成權(quán)重值，然后通過修改集群權(quán)重來調(diào)整實例流量。
5. 驗證方式
字節(jié)跳動的微服務(wù)管理平臺通過聚合服務(wù)的 Trace 日志生成了服務(wù)間的調(diào)用拓撲圖，通過 OpenAPI 可以查詢到某個服務(wù)的所有一級下游依賴服務(wù)列表。
然后，逐個對下游依賴服務(wù)注入一段時間的宕機故障，同時檢測服務(wù)的穩(wěn)定性指標(biāo)是否出現(xiàn)異常波動來推斷下游依賴服務(wù)是強依賴還是弱依賴。
需要注意的是，因為是逐個對下游依賴服務(wù)執(zhí)行實驗，為了避免前一個實驗對下一個實驗產(chǎn)生干擾，我們在兩次實驗間增加了一個間隔時間，具體的間隔時長依賴所使用的指標(biāo)檢測算法。
6. 實驗報告
實驗執(zhí)行結(jié)束，平臺會將下游依賴服務(wù)的強弱依賴推斷結(jié)果、執(zhí)行上下文、穩(wěn)態(tài)指標(biāo)監(jiān)控視圖和檢測結(jié)果等匯總成一個實驗報告發(fā)送給服務(wù)負責(zé)人。
服務(wù)負責(zé)人確認實驗報告，如果發(fā)現(xiàn)實驗結(jié)果不符合預(yù)期，可以通過執(zhí)行上下文和監(jiān)控視圖等信息來輔助定位問題。同時，可以在實驗報告中備注不符合預(yù)期原因、問題修復(fù)方案和修復(fù)進度等，平臺會定時跟進修復(fù)進度并提醒服務(wù)負責(zé)人更新結(jié)果。
如果實驗結(jié)果符合預(yù)期或問題已完成修復(fù)，實驗報告會進入結(jié)單狀態(tài)，同時記錄服務(wù)的強弱依賴推斷結(jié)果，并輸出給服務(wù)治理平臺，應(yīng)用于服務(wù)在線治理。
7. 實驗結(jié)果自動保準(zhǔn)
業(yè)務(wù)系統(tǒng)是持續(xù)迭代的，下游依賴關(guān)系也是動態(tài)變化的。如果非預(yù)期的引入了強依賴，會給系統(tǒng)增加可用性風(fēng)險，因此場景化主動實驗也需要常態(tài)化執(zhí)行。
已完成的主動實驗都可以開啟試驗結(jié)果自動保準(zhǔn)，每隔一定時間會自動執(zhí)行實驗驗證下游依賴服務(wù)的強弱依賴關(guān)系，并與歷史實驗結(jié)果進行對比，并將變動的部分通過實驗報告發(fā)送給服務(wù)負責(zé)人。
經(jīng)過服務(wù)負責(zé)人確認后，新的驗證結(jié)果會被更新到存儲和發(fā)送給服務(wù)治理平臺。
8. 完整的實驗流程
十、場景化主動實驗的價值
我們的驗證范圍從核心服務(wù)開始、逐漸向外圍服務(wù)擴張。
核心服務(wù)的驗證結(jié)果基本符合預(yù)期，但還是有少數(shù)個案存在穩(wěn)定性指標(biāo)不規(guī)范、容災(zāi)邏輯不符合預(yù)期的情況。通過實驗結(jié)果自動保準(zhǔn)機制，也多次及時發(fā)現(xiàn)因代碼變更所導(dǎo)致的容災(zāi)邏輯失效情況。
外圍服務(wù)驗證出來的問題就比較多了，穩(wěn)定性指標(biāo)嚴(yán)重不規(guī)范導(dǎo)致無法評估服務(wù)的穩(wěn)定性、容災(zāi)邏輯覆蓋率低導(dǎo)致過多的強依賴使得服務(wù)可用性風(fēng)險較高等等。需要持續(xù)的推動業(yè)務(wù)進行優(yōu)化升級，并給予一些高可用彈性系統(tǒng)的建設(shè)思路或參考方案。
十一、場景化主動實驗近期工作
最近，我們新上線了在結(jié)果保準(zhǔn)時自動對弱依賴服務(wù)注入隨機故障來進一步探索弱依賴的抗風(fēng)險能力。我們認為弱依賴服務(wù)在任何故障場景下都不應(yīng)該影響服務(wù)的可用性。
另外，場景化主動實驗還接入了服務(wù)的上線流程，在服務(wù)灰度上線時就觸發(fā)實驗，讓服務(wù)負責(zé)人能夠更及時的發(fā)現(xiàn)不符合預(yù)期的系統(tǒng)變更，如果有必要可立刻終止或回滾上線變更。
十二、場景化主動實驗的未來規(guī)劃
通過場景化主動實驗，我們已具備持續(xù)保障字節(jié)跳動核心服務(wù)的穩(wěn)定性、指標(biāo)規(guī)范性、強弱依賴正確性，以及弱依賴的抗風(fēng)險能力等等。
接下來，我們會把場景化主動實驗擴展到更大服務(wù)范圍和更多業(yè)務(wù)場景，讓場景化主動實驗發(fā)揮出更大的價值。
另外，我們也在思考打通服務(wù)上下游，從點到線再到面，以更高維度的系統(tǒng)視角來探索啟發(fā)式的智能混沌實驗。
