本文首先介紹了美團目前資料庫運維現狀、遇到的問題，以及為什麼要建設資料庫攻防演練平台；其次，分享目前資料庫攻防演練平台的具體實踐；第三部分會介紹資料庫攻防演練在美團内部的落地情況；最後，會結合混沌工程的成熟度标準和成熟度等級，分享我們對未來工作的一些規劃。
- 01 背景
- 1.1 初識混沌工程
- 1.2 現狀
- 1.3 痛點&作用
- 02 建設實踐
- 2.1 體系架構
- 2.2 能力全景
- 2.3 故障注入能力
- 2.4 演練流程
- 2.5 爆炸半徑控制
- 2.6 演練複盤
- 2.7 随機、無通知演練
- 2.8 演練模式對比
- 2.9 演練營運體系
- 03 落地情況
- 3.1 演練推廣
- 3.2 實驗環境
- 3.3 演練規模
- 3.4 場景 & 等級
- 3.5 演練營運資料
- 3.6 防守體系能力驗證
- 3.7 業務演練收益
- 04 未來展望
- 4.1 混沌工程成熟度模型
- 4.2 混沌工程成熟度等級
- 4.3 具體規劃
01 背景
|1.1 初識混沌工程
首先我們先了解一下什麼是混沌工程？簡單而言，混沌工程是在系統上進行實驗的技術手段，目的是建立對系統抵禦生産環境中失控條件的能力以及信心。這主要展現在兩個方面，從系統角度來講，混沌工程可以提升我們架構的容錯能力和韌性，降低故障發生率和複發率，提升系統使用者在使用時的體驗；從人員角度來講，通過混沌工程我們可以加深對架構的了解，在處理故障時能提高整體的應急效率，并且能主動去探究系統中潛在的一些問題。
混沌工程最早可以追溯到2008年，當時奈飛公司（Netflix）因資料庫故障造成了一次巨大的損失，于是他們便圍繞着穩定性體系做出了一些探索和建設。直到2015年，混沌工程的理念才被奈飛正式的提出。2019年，阿裡雲推出了開源工具Chaos Blade；2020年，PingCAP開源了Chaos Mesh，這也标志着國内在混沌工程領域也有了成熟的産品。
來源：中國資訊通信研究院，2021年
|1.2 現狀
下面是目前美團資料庫運維的一些現狀，這裡從五個次元展開：首先叢集規模（包括叢集的大小和數量）的線性增長；第二，叢集通路量的持續增加，當然這也是美團業務增長的必然結果；第三，線上遇到的故障種類也越來越多；第四，機關時間故障的影響也越來越大；第五，一些小機率事件的發生也随着叢集規模的擴大成為了可能。
|1.3 痛點&作用
基于以上的問題，我們整體上對于資料庫叢集的穩定性要求也越來越高。是以，圍繞着穩定性建設，資料庫團隊在故障的預防、發現、分析、恢複以及事後複盤5個方面做了很多工作。其中在故障預防方面，我們會通過故障演練探索不同故障場景對我們業務的影響，提升故障發生時業務系統整體的容錯能力。早期的時候，我們通過人工的方式來做故障演練，但人工演練在以下四個方面存在很大的問題：
- 在演練場景方面，人工演練能演練的場景比較少，演練場景的複雜度也比較高；
- 在演練覆寫率方面，人工演練無法覆寫大多數的叢集，也就無法保證常态化的故障演練；
- 在演練規模方面，人工演練沒有辦法進行大規模演練，在遇到一些機房或者交換機級的故障時，切換能力無法得到有效驗證；
- 在影響範圍方面，人工演練在整個演練過程中不能很好地控制爆炸半徑，遇到問題不能快速止損。
基于人工演練的這些痛點問題，我們設計并建設了資料庫故障演練平台，這個平台的作用主要展現在以下四個方面：第一，驗證故障發生時元件的防守能力；第二，通過資料庫大規模容災演練，驗證資料庫叢集的容災能力；第三，可以驗證故障發生時相關預案（業務、DBA）的有效性；第四，可以預知故障對業務造成的各種影響。
02 建設實踐
|2.1 體系架構
目前，資料庫故障演練平台體系架構主要包括如下六個子產品：
- 權限管理，控制演練發起人，可以對哪些叢集發起故障演練；
- 演練評估，演練之前為了避免演練風險，會對叢集做一些檢查，比如叢集的高可用是否開啟，拓撲是否符合要求，演練時間是否處在叢集通路的高峰期等；
- 故障注入，在相關的檢查通過後，真正去執行故障的下發；
- 名額觀測，在整個演練期間會通過采集一些可以反映穩态的資料，比如以業務的通路成功率、業務的響應延遲等等，來分析故障演練對業務造成的影響；
- 終止注入，在演練過程中發現整體影響比較大，或者有一些非可控的影響，可以立刻終止故障演練，避免故障演練對線上業務造成的影響進一步擴大；
- 智能分析，在演練結束之後，可以通過采集一些反應故障注入或者是防守元件的相關資料判定本次故障演練是否符合預期。
目前故障注入支援的主機類型比較全面，可以在實體機、虛拟機、容器上做故障演練。
|2.2 能力全景
這部分主要介紹一下我們故障演練平台的能力全景，它主要規劃了我們目前資料庫故障演練平台的一些核心能力，整體的細節如下圖所示：
- 從支援的資料庫來看，目前我們主要支援MySQL的故障演練；
- 支援的資料庫元件有資料庫通路中間件、資料傳輸、高可用系統和Binlog Server，我們會在後續的疊代中逐漸支援，目前我們正在接入資料庫通路中間件的一些演練場景；
- 在整個故障演練過程中，我們會依賴高可用、容災管控、故障診斷、故障兜底以及拓撲自愈等多個方面的能力，主要是驗證上面提到的這些元件在整個演練過程中的表現是否符合預期；
- 目前，平台自身已經形成了從故障編排、故障注入、名額觀測、故障終止、分析複盤的一個閉環。
|2.3 故障注入能力
關于故障注入能力，目前支援的故障場景主要包括5個（如下圖所示），目前我們主要建設的是當機類（包括主庫當機、從庫當機）、主從延遲以及從庫活躍連接配接多，由于目前線上80%的故障都是由這幾個場景引起的，這也是我們目前沒有建設過多故障場景的主要原因。後面我們還會規劃建設高可用的鍊路故障，比如資料庫和高可用同時出問題時，高可用的表現是怎麼樣的，是否能夠順利的進行切換。
在故障編排方面，我們通過建立一個任務内的子任務間的串行故障和并行故障的編排機制，來實作演練任務的統一編排。
在并發能力上，目前故障演練平台保守的并發故障注入能力是在一分鐘實作5000+節點的故障注入，目前這個能力已經可以滿足我們對于大規模故障演練的整體需求。
|2.4 演練流程
整個演練流程主要分成三部分，演練前、演練中和演練後，同時我們也形成了風險評估、風險複核、一鍵終止、故障複盤的能力閉環。
在演練前，我們主要做三個方面的工作：
- 針對演練叢集做風險評估，比如演練叢集的高可用是否開啟、拓撲是否符合要求；
- 利用多級審批機制，讓業務和相關的DBA知曉整個演練的風險；
- 在演練前建立相關交流群，把故障演練相關的資訊在群裡進行周知。
在演練中，有兩方面的工作：
- 在故障注入前，做一下前置檢查，主要目的是在建立演練任務後和故障注入前這個時間段，防止因叢集拓撲變化産生風險，比如演練的場景是從庫當機，這種情況下如果發生切換，故障注入的節點很有可能變成了主庫；
- 如果一個任務裡含有多個子任務，而某一個子任務發生了故障注入失敗，那麼後續演練我們會自動終止。
在演練結束後，我們會進行故障清理，完成後做演練的資料收集，用于複盤，并據此完善相關的風險管控流程。
|2.5 爆炸半徑控制
提到混沌工程，就不得不提到爆炸半徑控制的問題，目前我們主要從兩個次元、三個方面做了一些控制。
第一個次元是實體隔離，它包含兩方面：
- 場景次元隔離，即在同一時間點、單個資料庫的叢集隻能注入單一類型的故障，主要是為了避免在單個演練任務中如果針對一個資料庫叢集注入多種故障，整體影響不容易被評估。
- 機器次元隔離，單個叢集故障注入隻能標明一個特定機器，而不能選擇多個機器。
第二個次元是流量控制，主要是通過中間件按權重下發少部分流量到演練節點實作，流量控制能從一個更精細的次元來控制演練的風險。
另外，我們在演練前、演練中和演練後都有相關的檢查或措施，能夠保證在演練期間出現問題後迅速把影響降到最低，這也是另外一種變相的爆炸半徑控制。本質上來說，爆炸半徑和通過演練發現的問題數量會有一個正比的關系，即爆炸半徑控制得越小，整個故障演練對業務的影響也就越小。但與此同時，整個故障演練暴露出來的問題，就會比較有限，是以在建設過程中要做一個取舍。如果想發現更多的問題，那爆炸半徑就要設計的大一些。目前，綜合考量多種因素，我們還是把爆炸半徑控制在一個相對合理範圍去進行故障演練，讓業務以一個更低的成本進行故障演練。
|2.6 演練複盤
當演練結束後，我們需要對整體的演練結果做客觀的評價分析，進而判斷這次演練整體是否達到預期。演練複盤内容包括演練整體流程、存在的問題以及針對問題形成的相關改進點，它可以用來指導後續的演練。如果本次演練不符合預期，我們會通過演練複盤功能打通故障演練平台和故障複盤兩大産品，自動生成演練相關的時間線，進而更好地進行人工複盤。
演練複盤主要是分為四部分：
- 第一部分是演練複盤的概覽資訊，它主要是包含六個方面：① 演練時長；② 本次演練涉及的叢集數；③ 演練場景數；④ 演練成功率，即故障注入的成功率；⑤ 演練過程中産生的告警數；⑥ 演練期間業務請求的成功率。
- 第二部分是關鍵步驟，這裡收集了在整個演練過程中非常關鍵、非常核心的步驟，以及它整體的名額資料，這些可以幫助我們分析平台本身亦或是防守元件的相關表現是否符合預期。
- 第三部分是在演練過程中涉及的核心防守元件的名額資料，比如針對主庫當機，我們主要關心兩方面資料：一是故障注入後，高可用元件用了多長時間才發現這個故障，二是在發現了這個故障後切換花了多長時間。通過這些資料，就可以知道在本次演練過程中防守元件的表現是否符合預期。
- 第四部分是演練詳情，它是針對單個叢集的演練過程繪制的完整的時間線資訊，可以通過這些資訊看到一個演練叢集從前置檢查到故障注入，到告警産生，到防守元件的介入，再到故障清理呈現出的一個非常詳細的時間線資料，如下圖所示：
|2.7 随機、無通知演練
從2022年開始，我們開始建設随機、無通知演練能力。之前故障演練平台主要是在特定時間、特定場景下的演練，并且在整個演練過程會組織相關的人員協同跟進整個演練過程。但是，故障的發生是一個非常随機的行為，它不會給人足夠的時間去準備、應對。而随機無通知演練功能，就是希望建設這樣的能力，可以在非特定時間、非特定叢集、非特定場景進行故障演練，在一定程度上填補了故障演練的空白，也是故障演練平台向混沌工程演進的一個裡程碑。整個演練過程主要分成三個部分：
第一部分是需要添加演練計劃，其主要内容包括三個方面：
- 可以通過叢集、場景、演練時間這3個次元，去控制哪些叢集可以演練哪些場景，在什麼時間可以進行随機無通知演練；
- 按叢集、場景次元組合去做相關風險檢查，以此來保證添加的這些叢集可以進行相關場景的演練；
- 和正常故障演練相似的是，它也提供了多元審批，可以讓相關業務人員或者DBA知曉個整個演練的風險。
第二部分是演練任務生成，有了演練計劃後，我們按演練計劃随機搭配生成演練任務并進行周知，和正常演練最大不同是我們不會周知演練的具體時間（會周知演練叢集、場景），主要是為了模拟故障發生的随機性。随着後面整體能力的更新疊代，我們會逐漸去掉在叢集、場景次元的周知。
第三部分是演練任務執行，它完全複用我們正常故障演練的功能，也可以在演練前取消、演練中終止，演練後可以自動恢複整個叢集的拓撲。
|2.8 演練模式對比
下面我們将正常故障演練、随機無通知演練以及混沌工程作一下對比，如下表所示：
- 首先從演練目的次元來看：正常故障演練目的性非常強，它主要是驗證已知的問題場景是否會再次造成生産上的事故；随機演練主要是在已知的故障場景、在有限的叢集範圍内，是否會産生問題；混沌工程的演練目的性最弱，它主要是檢驗未知的故障場景是否會造成問題。
- 從是否有人值守的次元來看：正常故障演練需要有人值守；随機無通知演練是朝着無人值守方向發展的，但目前鑒于我們的能力還在建設初期，是以也會增加一些相關的值守機制來控制演練風險；混沌工程是完全無人值守的，因為也無法去值守一個混沌工程的“混沌”實驗。
- 從事先周知的次元來看：正常故障演練需要明确進行周知；随機無通知演練目前在有限叢集和有限場景範圍内進行演練（會周知演練叢集、演練場景），不會周知具體的演練時間；混沌工程是完全無周知的演練形式。
|2.9 演練營運體系
下面是資料庫故障演練平台的營運體系的建設，主要關注四個部分：
首先是演練核心名額：
- 一是在一段時間内，共進行了多少次演練，涉及演練叢集數有多少個；
- 二是在一段時間内演練叢集和演練場景的覆寫率以及達标率；
- 三是故障演練結束後的回報，即演練是否符合預期。
第二部分是大規模演練的核心名額，我們主要關注三個方面：
- 第一方面是每次大規模演練的演練規模；
- 第二方面是故障注入的成功率；
- 第三方面是故障注入的耗時分布，主要統計在某一個時間點，完成了多少執行個體的故障注入。
第三部分是業務接入名額，一方面統計核心業務的接入情況，同時也會反映一下DBA在不同業務線的推廣情況。
第四部分是平台能力名額，一方面是平台接口成功率，另一方面是平台接口的相關耗時。
03 落地情況
|3.1 演練推廣
本部分會介紹故障演練平台在美團内部的落地情況。首先在推廣層面，我們主要采用三種形式：
- 第一種形式是故障驅動方式，如果線上發生了特定的故障場景，導緻業務損失，我們就會進行相關故障場景的容忍能力建設以及驗證。
- 第二種形式是主動演練，通過定期學習一些故障案例，判斷相關的故障案例中的相關故障場景是否會對目前負責的業務産生影響，也可以通過故障演練平台做簡單的摸底。
- 第三種形式是DBA主動策劃組織，比如2022年，我們進行了三次規模比較大的演練，主要驗證在特定故障場景下，業務的容錯能力、高可用的防守能力是否符合預期。
|3.2 實驗環境
在混沌實驗的環境選擇上，我們目前提供了三種不同的環境：
- 第一種是線下環境，主要是用來發現問題後進行相關預案的建設和驗證；
- 第二種是線上演練環境，主要是通過大規模的容災演練，去驗證防守元件的防守能力是否符合預期；
- 第三種是線上真實環境，就是我們真正的線上業務叢集，主要通過具體業務進行相關故障場景的演練，能夠更加真實、全面地驗證故障的影響，以及相關預案的有效性。
|3.3 演練規模
接下來是演練規模，演練的規模越大，影響的範圍越大。我們的演練規模可以劃分成三類：
- 第一類是單叢集演練，主要驗證故障影響及預案有效性；
- 第二類是中小規模演練，主要通過規模化的演練，去驗證特定故障場景對業務的影響；
- 第三類是大規模的叢集演練，主要驗證容災能力，以及相關防守元件的防守能力是否符合預期。
|3.4 場景 & 等級
在整體推進方面，我們目前會從兩個次元進行演練：
- 第一個次元，我們會根據故障影響的嚴重程度，做無損到有損場景的演練；
- 第二個次元，演練會從低等級叢集開始，最終過渡到高等級叢集，這樣做的目的是先給業務建立一個對于故障演練的信心，之後逐漸在高等級叢集中發揮故障演練的重要作用。
|3.5 演練營運資料
下面是正常故障演練、随機無通知演練以及大規模故障演練的一些相關資料：
- 從正常故障演練的資料可以看出，目前我們整體上的正常故障演練覆寫率是偏低的。
- 随機功能演練是2022年第四季度才建設完成的能力，到目前還是初級推廣階段，是以整體上演練次數比較少，2023年的主要目标是通過在核心業務線的推廣，不斷提高演練叢集的覆寫率，以期發現更多的問題。
- 大規模演練從2022年下半年開始，在演練頻次有非常大的提高，這主要是為了更好地驗證資料庫底層依賴的防守能力在面臨大規模故障時的表現。如果發現相關元件存在問題，我們也可以更好地輔助這些元件去做疊代，輔助建設相關的能力。上圖統計的是單任務演練規模超過100個叢集的資料，但如果按照20或50個叢集進行統計彙總，那麼大規模演練的任務次數還會更多。
|3.6 防守體系能力驗證
在防守體系能力建設層面，我們主要驗證防守元件的三個核心能力：
- 第一個從高用來看，主要驗證RTO和RPO是否符合預期，以及在大規模故障場景下，其切換能力是否達标。
- 第二個從彈性伸縮來看，主要驗證在單叢集或規模化演練前提下，整體彈性擴容決策能力是否達到期望，以及在小規模場景下實地驗證彈性擴容的并發能力。
- 第三個從觀測來看，主要驗證當大規模演練發生時，觀測工具的及時性以及準确性。
|3.7 業務演練收益
誠然，演練會對業務方造成一些“打擾”，但是業務方也會積極配合我們做這項工作，因為故障演練對業務方也有一些收益：一方面，業務方可以通過演練發現一些隐藏的問題，進而規避更大的風險；另一方面，我們在發現業務問題的同時，也能驗證相關防守元件的表現是否符合預期。更多的細節，大家可以參考下圖：
04 未來展望
|4.1 混沌工程成熟度模型
下圖是混沌工程成熟度模型（CEEM），右邊是我們目前的資料庫故障演練平台和标準的對比。可以明顯地看到，目前我們在一些次元上做的還不夠，比如目前故障場景的覆寫程度、穩态名額的覆寫程度、實驗觀測、文化建設等方面都存在一定的不足，而這些不足其實也是我們後續着重要改進的點。
|4.2 混沌工程成熟度等級
關于混沌工程成熟等級，我們也做了一些總結：
- 從開展程度來看，目前我們隻是在一些核心部門進行了故障演練，在穩定提升方面會有一些相關建設的成果；
- 從落地收獲來看，一是可以驗證故障的影響，二是可以提高業務系統對于故障的容忍度，三是可以通過資料庫故障演練平台，評估我們在穩定性建設方面的一些成果；
- 從整體評級來看，我們目前還處于基礎階段，後面也會繼續在公司更多的核心部門推廣資料庫故障演練平台，持續為業務系統穩定性提升做出更大的貢獻。
|4.3 具體規劃
在最後部分，我們分享一下關于未來的規劃。在具體路徑層面，我們會從五個方面進行開展工作：
- 第一，要降低單次演練成本，比如降低單次演練的介入率，無論是業務還是DBA。
- 第二，豐富故障演練場景，建設鍊路故障注入能力，從服務端故障向端到端故障做一個擴充。
- 第三，增強可觀測性，目前整個故障演練平台在觀測名額方面相對比較缺乏，後續我們希望通過引入更多的觀測名額，進而更好地觀測整個混沌工程的實驗過程。
- 第四，智能化，主要聚焦三方面：① 建設整個穩态系統，因為目前我們整個故障演練是否符合預期，主要還是通過人工或者DBA來進行判斷，有了穩态系統後，可以通過穩态系統去判斷；② 根據穩态系統相關名額建設故障自動終止能力；③ 建設相關的演練推薦能力，因為現在業務線推廣演練時，可能還不清楚我們該在哪些叢集演練哪些場景，當有了這個能力後，業務在演練時會有更強的針對性。
- 第五，希望能夠實作演練常态化，即通過常态化演練去發現業務端更多的隐患。
作者:占全
來源:微信公衆号:美團技術團隊
出處:https://mp.weixin.qq.com/s/hwTf4bDck9_tlFpgVDeIKg