中國信通院：分布式系統穩定性建設指南（2022年）（98頁）.pdf

1、 分布式系統穩定性分布式系統穩定性建設指南建設指南 （2022 年）年）中國信息通信研究院云計算與大數據研究所中國信息通信研究院云計算與大數據研究所 2022022 2 年年 6 6 月月 編制說明編制說明 本建設指南自 2022 年 1 月啟動編制，在前期研究、框架設計、文稿起草、征求意見和修改完善等五個重要階段，均面向分布式系統穩定性領域的技術提供方、產品服務方、行業應用方開展了深度訪談、意見征集等工作。參與編制的單位說明如下： 牽頭單位：中國信息通信研究院云計算與大數據研究所； 聯合單位：阿里云計算有限公司、華為云計算技術有限公司、北京百度網訊科技有限公司、北京銀行、杭州笨馬網絡技術有限

2、公司、思特沃克軟件技術（北京）有限公司、中國農業銀行、中國科學院計算技術研究所、中信銀行、華泰證券股份有限公司、中國工商銀行、上海浦東發展銀行、螞蟻科技集團股份有限公司、中移（杭州）信息技術有限公司、深圳市騰訊計算機系統有限公司、建信金融科技有限責任公司、北京火山引擎科技有限公司、浩鯨云計算科技股份有限公司、南京爭鋒信息科技有限公司、中電金信軟件有限公司、 四川省農村信用社聯合社、 北京同創永益科技發展有限公司、中電云數智科技有限公司、安信證券股份有限公司、北京永輝科技有限公司、京東科技信息技術有限公司、南方電網數字電網研究院有限公司、陽光保險集團股份有限公司、上海鈞正網絡科技有限公司、北京云

3、杉世紀網絡科技有限公司、深圳市金證科技股份有限公司、中國銀行、中國移動信息技術中心、招商銀行、中移（蘇州）軟件技術有限公司、天翼云科技有限公司。 前前 言言 隨著分布式成為主流的系統架構設計方案，業務系統的迭代速度越來越快，后端系統架構變得越發復雜，單一節點問題可能被無限放大，大規模分布式系統的穩定性保障能力越來越成為業界關注的重點；與此同時，在技術角色分工越來越細，技術專業化程度越來越深的大背景下，分布式系統的架構特性為其穩定性建設中的架構設計、組織設計等也帶來了新的挑戰。 穩定的系統是產品提供服務的基本前提，但是當前很多企業缺乏解決分布式架構下的系統穩定性、服務高可用建設相關問題的經驗。

4、中國混沌工程調查報告（2021） 調查結果顯示， “較多服務的穩定性相對較差，月事故率差強人意” ；線下調研結果提示，SRE 團隊幾乎都是從零開始摸索穩定性建設，在此過程中存在關鍵技術的建設路徑不清晰、建設思路不明確的問題。 針對上述分布式系統穩定性的痛點問題，本文希望形成一份總體性的穩定性建設指南，從全局角度出發對分布式系統穩定性建設工作進行拆解和分析，力求務實、有效地輸出有價值的觀點。本指南期待能比較全面的幫助中國企業在分布式系統建設、配套組織、運營機制設計層面進行指導落地，實現國內軟件發展向更高目標邁進。 目目 錄錄 一、系統穩定性建設概述 . 1 （一）分布式系統面臨穩定性保障新挑戰

5、. 1 （二）政策引導 IT 系統穩定性建設平穩推進 . 3 二、分布式系統穩定性建設總體視圖 . 6 三、分布式系統穩定性建設目標 . 8 （一）穩定性建設目標 . 8 （二）穩定性評價指標 . 9 四、分布式系統穩定性建設模式 . 11 （一）架構設計 . 11 （二）容量設計 . 23 （三）運維方案設計 . 28 （四）安全設計 . 43 五、分布式系統穩定性建設路徑 . 46 （一）穩定性建設需求分析 . 46 （二）穩定性建設實現分析 . 47 （三）穩定性建設活動 . 48 （四）穩定性建設工具 . 54 六、分布式系統穩定性建設行業特點 . 71 （一）互聯網業 . 71 （二

6、）銀行業 . 73 （三）證券業 . 75 （四）通信業 . 76 （五）云服務業 . 78 （六）零售業 . 79 （七）能源業 . 81 七、分布式系統穩定性建設展望 . 83 （一）人才、生態、標準亟待關注，多重措施提升穩定性發展水平 . 83 （二）順應時代發展需求，推動穩定性建設進入新階段 . 85 附錄 1 . 88 附錄 2 . 89 圖圖 目目 錄錄 圖 1 運維復雜度示意圖 . 2 圖 2 分布式系統穩定性建設總體視圖 . 6 圖 3 穩定性建設目標視圖 . 8 圖 4 中國信通院“穩保計劃” . 51 圖 5 項目開展前穩定性體檢視圖 . 52 圖 6 項目開展中穩定性測試

7、視圖 . 53 圖 7 分布式系統穩定性度量模型 . 53 圖 8 混沌工程成熟度模型 . 54 圖 9 分布式系統穩定性建設工具關系圖 . 55 圖 10 穩定性管理建設架構 . 56 圖 11 可觀測能力框架圖 . 58 圖 12 變更管理能力建設框架圖 . 60 圖 13 容量管理能力建設框架圖 . 61 圖 14 全鏈路壓測能力框架圖 . 63 圖 15 混沌工程平臺能力建設框架圖 . 65 圖 16 混沌工程與軟件完整生命周期對應圖 . 66 圖 17 應急平臺能力框架圖 . 67 圖 18 容災管理能力建設框架圖 . 69 圖 19 應用多活能力框架圖 . 70 表表 目目 錄錄

8、表 1 國內推動系統穩定性建設的相關政策 . 3 表 2 容錯等級設計 . 21 表 3 系統觀測覆蓋資源 . 35 表 4 穩定性風險基準表格示例 . 42 表 5 安全漏洞類型及防范措施 . 44 表 6 中美穩定性工具開源情況 . 86 表 7 穩定性守護者列表 . 88 表 8 混沌工程實驗室成員列表 . 89 分布式系統穩定性建設指南（2022 年） 1 一、系統穩定性建設概述 在技術變更、業務挑戰加劇以及良好政策引導的背景下，系統穩定性能力建設成為企業等機構組織提升業務連續性能力的核心關注點。系統的穩定性，表示系統在遭受外界擾動偏離原來的平衡狀態，而在擾動消失后系統自身仍有能力恢復

9、到原來平衡狀態的一種頑性。系統穩定性能力建設是一個系統性工程， 需要從企業工程建設的全環節進行設計和實施，充分利用以混沌工程、全鏈路壓測為代表的分布式系統穩定性保障技術，建設保障能力、改造運營流程、推進穩定性文化， 保障企業系統穩定性、 提升業務連續性、 促進行業高質量發展。 （一）分布式系統面臨（一）分布式系統面臨穩定性保障新挑戰穩定性保障新挑戰 在 20 世紀 60 年代，大型主機憑借其超強的計算和 IO 處理能力以及在穩定性和安全性方面的卓越表現，引領了計算機行業的發展，集中式的計算機系統架構也成為了主流。 隨著計算需求的增長和計算場景的多樣化，集中式的處理模式越來越顯得捉襟見肘，同時隨

10、著PC 技術的成熟和普及，計算機網絡化和微型化的發展趨勢在近年不斷演進發展，整個分布式計算的理論和實踐也走向成熟，計算機系統也開始從集中式向分布式架構的演進。分布式架構在其經濟性、自主性、靈活性、擴展性層面較集中式架構有較為突出優勢，是近年來各企業進行 IT 系統建設的首選。 分布式系統穩定性建設指南（2022 年） 2 來源：公開資料整理 圖 1 運維復雜度示意圖 分布式系統是由一組通過網絡進行通信、 為了完成共同的任務而協調工作的計算機節點組成的系統。系統中有大量的服務器及設備，各模塊之間存在錯綜復雜的依賴關系，存在更多的不確定性。整個系統的故障率會隨設備的增加而呈指數級增加， 單一節點問

11、題可能會被無限放大，日常運行過程中一定會伴隨“異?！卑l生；同時，分布式系統節點分布范圍更加廣，節點數量更多，物理位置不統一，非常依賴于網絡，這對日常運維過程中的日志采集、變更升級等都帶來了新的挑戰；并且，隨著技術角色分工越來越細，技術專業化程度運來越深，分布式系統穩定性落地因其架構特性對架構設計思路、組織設計等帶來了新的挑戰。 要保障分布式架構下的系統穩定性， 需要系統化地探討穩定性建設新模式。 分布式系統穩定性建設指南（2022 年） 3 （二）政策引導（二）政策引導 IT 系統穩定性建設平穩推進系統穩定性建設平穩推進 為加強企業 IT 系統風險管理，提高業務連續性管理能力，保障國家和人民生

12、命、財產安全，國家對各行業的軟件質量及系統穩定性提出了更高的標準、更嚴的要求，如中華人民共和國突發事件應對管理法中要求“完善應急保障制度” ；國務院公布的關鍵信息基礎設施安全保護條例指出“建立健全監測預警制度、明確網絡安全事件應急處置要求” ；工業和信息化部發布的 “十四五”軟件和信息技術服務業發展規劃中強調“提升軟件質量管理能力和軟件價值保障能力” ，極大鼓勵軟件高質量發展；中國人民銀行印發金融科技發展規劃（2022-2025 年） ，強調高質量推進金融數字化轉型；證監會科技監管局組織編寫的證券期貨業科技發展“十四五”規劃則強調遵循四項原則，其中第一項為“穩字當頭、穩中求進” ，等等。由此觀

13、之， 政策鼓勵各行業的研發運維團隊培養良好的穩定系統建設觀念，在工程設計與實現上規避風險，持續交付高質量軟件。 表 1 國內推動系統穩定性建設的相關政策 時間時間 機構機構 政策名稱政策名稱 相關內容相關內容 2021 年12月24 日 第十三屆全國人大常委會第三十二次會議審議 中華人民共和國突發事件應對法 新增“管理體制”一章，修訂內容包括：完善應急保障制度；加強突發事件應對管理能力建設。 2021 年 4 月27 日 國務院 關鍵信息基礎設施安全保護條例 條例對制定行業安全保護規劃、建立信息共享機制、建立健全監測預警制度、明確網絡安全事件分布式系統穩定性建設指南（2022 年） 4 應急處

14、置要求、組織安全檢查檢測、提供技術支持和協助等作了規定。 2021 年11月30 日 工業和信息化部 “十四五”軟件和信息技術服務業發展規劃 提升軟件質量管理能力。支持配置管理、代碼審查、測試驗證、質量分析等工具研發，提升質量監控、預警和評價能力。 2022年1月4日 中國人民銀行 金融科技發展規劃（20222025) 強調高質量推進金融數字化轉型 2021 年10月21 日 中國證監會科技監管局 證券期貨業科技發展“十四五”規劃 強調遵循四項原則，其中第一項為“穩字當頭、穩中求進” 2011 年12月28 日 中國銀行保險監督管理委員會 商業銀行業務連續性監管指引 商業銀行應當將業務連續性管

15、理納入全面風險管理體系。 2021 年11月26 日 中國銀行保險監督管理委員會 關于銀行業保險業支持高水平科技自立自強的指導意見 堅持風險可控。統籌發展與安全，完善風險控制機制，提升科技金融風險管理能力。 2018 年 5 月21 日 中國銀行保險監督管理委員會 銀行業金融機構數據治理指引 銀行業金融機構應當建立數據應急預案，根據業務影響分析，組織開展應急演練，完善處置流程，保證在系統服務異常以及危機等情景下數據的完整、準確和連續。 分布式系統穩定性建設指南（2022 年） 5 2008 年 4 月23 日 中國銀行保險監督管理委員會 銀行業重要突發事件應急管理規范（試行） 對商業銀行的業務

16、連續性作出了明確要求。 來源：公開資料整理 分布式系統穩定性建設指南（2022 年） 6 二、分布式系統穩定性建設總體視圖 系統穩定性是產品能力的基本要求，保障產品的穩定性，就需要開展穩定性能力建設。穩定性能力建設是一個系統化工程，從硬件到軟件，從人員到機制，內容涉及組織內多部門協作、穩定性流程規范制定、體系化技術實現、穩定性文化建設等一系列工作集合。本章將圍繞分布式系統穩定性建設模式，結合分布式系統穩定性建設目標，給出分布式系統建設路徑， 并提出圖 2 所示的分布式系統穩定性建設總體視圖。 來源：中國信息通信研究院 圖 2 分布式系統穩定性建設總體視圖 穩定性建設目標：穩定性工作貫穿軟件生命

17、周期的全過程，從故障的視角來看穩定性建設的最終目標是“降發生”和“降影響” ，穩定性建設目標可以通過評價指標實現量化。 分布式系統穩定性建設指南（2022 年） 7 穩定性建設模式：圍繞上述穩定性建設目標，我們認為系統穩定性建設思路包括了 4 大建設模式：良好的系統架構和實現、完備的容量規劃設計、優秀的運維方案設計，以及規范的安全設計。 穩定性建設路徑： 分布式系統穩定性建設需要從企業工程建設的全環節進行設計和實施， 穩定性需要作為核心考量內建于企業軟件工程的全生命周期并佐以建設活動，從流程機制、制度文化層面鞏固穩定性優先的戰略思想， 最后通過穩定性建設工具將穩定性保障工作落到實處。 分布式系

18、統穩定性建設指南（2022 年） 8 三、分布式系統穩定性建設目標 穩定性建設目標對穩定性建設非常重要， 穩定性建設工作的開展都是為了實現最終的穩定性目標， 穩定性目標可以通過評價指標實現量化。 來源：中國信息通信研究院 圖 3 穩定性建設目標視圖 （一）穩定性建設目標（一）穩定性建設目標 降發生，即降低故障發生的概率。支持應用建設“三高能力” ，即高可用、高性能、高質量，從方案設計階段即采用面向失敗的理念來設計系統架構，并通過一系列技術手段驗證系統“三高能力”是否符合預期。高可用，通過冗余設計的思想來實現應用架構的高可用能力保障，同時通過可靠的基礎設施組件，來將應用的高可用能力轉移到基礎設施

19、來提供。高性能，通過精簡主干業務邏輯，將不相干的業務異步化，實現快速的功能響應；通過緩存技術，加快數據訪問的性能。 高質量， 高質量設計更多的是一種軟件開發最佳實踐經驗的沉淀。分布式系統穩定性建設指南（2022 年） 9 通過設立開發、運維的規范可有效減少人為故障的發生；通過合理的拆分理念，如縱向技術分層、橫向業務分區的理念，提升系統的可維護性、可演進能力。 降影響，即降低故障發生后的影響范圍。早感知，故障感知最基礎和重要的原則就是完善監控告警。通過可視化的監控告警能力，感知系統的異常變化，可以盡早發現甚至預測系統故障?？於ㄎ?，系統對故障定位明確，故障管理機制定義完整，職責明確，流程清晰，能有

20、效提升故障發生后的處理效率。急止損， “止血”大于“修復” ，故障發生后的第一反應永遠是“優先止損” ，在完成止損工作之后，再開展故障修復。而為了有效止損，需要提前設立各種故障預案。優改進，及時復盤，實現故障閉環。故障復盤是故障發生后的改進措施，目的是完成系統韌性提升，實現故障閉環。 （二）穩定性評價指標（二）穩定性評價指標 穩定性保障是一項非常寬泛且復雜的工作， 規劃整體穩定性保障體系落地首先需要一組簡單清晰易衡量的評價指標來整體牽引穩定性能力的建設。根據企業規模和發展階段可以酌情從三個維度考慮，評估系統穩定性：業務可用程度、用戶影響程度以及資金損失程度。 業務可用程度： 業務可用程度是最通

21、常使用的系統穩定性評價指標，即 SLA。通常情況下，SLA 有兩種計算方式：一種是通過時間維度計算，一種是通過用戶請求狀態計算。除 SLA 之外，還可以配合使用 RTO、RPO 等指標，監測數據的完整性。 用戶影響程度：穩定性能力建設的目標之一就是降低故障影響，分布式系統穩定性建設指南（2022 年） 10 所以故障發生之后，用戶影響程度也是評價系統穩定性的重要指標，這里的影響程度主要是指受影響的用戶數量。 資產損失程度：資產損失程度主要從應用方的角度出發，評價故障發生后對組織產生的影響，此處的資產包括有形資產和無形資產。有形資產包括： 資金、 設備、 人力成本等； 無形資產包括： 社會形象、

22、潛在商機等。 分布式系統穩定性建設指南（2022 年） 11 四、分布式系統穩定性建設模式 穩定性建設模式是指在開展穩定性建設工作過程中應重點關注的技術方法或方案。在穩定性建設目標的指導下，需要有一系列技術模式來支撐穩定性能力實現， 以下就常見的穩定性建設模式進行介紹。 （一）架構設計（一）架構設計 根據不同系統業務特點、 不同發展階段 （如系統規模、 團隊規模） 、不同系統指標側重性要求等，有很多不同的架構思路及折衷考量，例如存儲選型、服務化治理、中間件選型、中臺系統抽象等。本小節會專注于簡要介紹會影響穩定性的核心架構設計要點以供讀者參考。 1.去除單點 （1） 硬件單點 設計確保不存在特定

23、硬件服務器單點。 如虛擬機分配上是否存在物理單點、 服務是否能夠容忍一臺或集群中的若干臺應用服務器發生故障等?？筛鶕鞣N崩潰型故障(crash、fail-stop)、阻塞型故障、緩慢型故障、以及任意型故障（邏輯故障等）分別進行分析設計。虛擬機環境下，需要針對物理機與虛擬機分別評估單點問題，原則上所有應用服務器不前置依賴物理機。 （2） 存儲單點 部署架構上確保不存在特定存儲主機單點， 如服務依賴的數據庫主機是否有單點、存儲主機部署架構是否存在單點、存儲管控節點是否存在單點。 分布式系統穩定性建設指南（2022 年） 12 （3） 網絡單點 明確網絡拓撲中是否存在單點， 一般情況下網絡基礎設施應

24、當是全冗余設計。但如果服務提出了例如專線、防火墻等要求，就必須考慮網絡的單點。 （4） 機房單點 對于具備機房級容災能力要求的服務或業務在部署架構及服務設計上必須考慮不可用 IDC 部署，設計上確認服務對 IDC 部署是否存在約束（如由于專線限制只能存在于一個 IDC 中），提前設計若干 IDC 故障，對服務影響的逃逸或隔離設計。 （5） 基礎技術單點 數據服務軟件單點：如緩存、文件系統、搜索等數據服務，需要分析服務是否對上述數據服務軟件存在依賴。 需考慮當上述數據服務軟件發生故障時，服務容忍性設計，對于緩存產品防熱點設計。 （6） 服務注冊中心單點 服務配置中心通常提供的關鍵能力包括服務發布

25、和訂閱推送， 消息的發布和訂閱關系推送。應用必須明確對配置中心的使用場景，確認依賴關系及注冊中心宕機對于自身應用的影響設計。 原則上建議應用系統啟動和運行時可不強依賴于注冊中心， 應用必須能夠忍受注冊中心短暫宕機所照成的影響， 亦即注冊中心需要具備一定恢復重建或心跳維持能力。 （7） 數據單點/熱點 分布式系統穩定性建設指南（2022 年） 13 數據庫單點規避： 首先需要分析確認應用系統所依賴的數據庫故障影響，單個數據庫宕機之后是否能夠夠快速恢復的問題，如果能夠故做到快速恢復， 恢復的時間大概是多長。 重要服務所依賴的數據庫，確保數據庫主機及存儲的單點冗余。 應用層面必須做到數據庫主機宕機后

26、的快速的 failover 恢復，如行業內通常采用的分庫分表設計。 熱點數據表單點規避：對于不同數據庫軟硬件配置，單數據表的數據量與事務承載能力存在上限， 如部分機型單數據表日事務數不應超過 3000 萬，否則可能產生表熱點。原則上在數據表設計時需確認所有業務數據等級， 對于業務流程數據需要強一致性保證的采用強同步機制保證可靠性， 若為業務日志數據可考慮采用異步方式緩解對主業務流程數據處理瓶頸壓力。 熱點數據記錄單點規避：可能形成熱點的數據記錄有賬戶、控制數據、鎖等。若單數據記錄上有事務串行執行要求，則會直接限制系統的最大吞吐能力。 另外設計上需保證做到串行操作的鎖等待不影響應用及數據庫的性能

27、和容量。對于關鍵服務，在設計之初就必須消除單一數據記錄上的并發操作，避免形成熱點；對于非關鍵服務，允許設計之初有數據記錄熱點，但必須建立處理量跟蹤機制，保證在熱點實際發生前，提前消除熱點；所有服務的數據庫鎖操作必須明確的定義鎖等待的時間。 （8） 內部服務單點 內部業務服務是指由自研軟件提供的業務服務。 原則上不允許有高等級服務依賴低等級服務。對于最高優先級服務提供方，必須盡最分布式系統穩定性建設指南（2022 年） 14 大可能，將內部業務服務單點個數降到最低，包括提供降級服務能力等。對于最高優先級服務依賴的組件，必須保證所依賴的組件發生各種類型故障時（包括崩潰型、緩慢型或任意型）不能整體崩

28、潰。 （9） 外部服務訪問單點 外部服務是指非自研軟件提供的服務。 除非與外部服務提供商有嚴格的 SLA 保障，否則所有的外部服務可視為低保障等級服務。 設計上充分優化將對外部服務的依賴降到最低。一般情況下，應用不應直接使用外部服務， 而應通過統一的內部網關服務來使用外部服務。通過前端方式引入的外部服務（如 JS 引入），也必須考慮在其中。對于關鍵服務，原則上不建議強依賴于外部服務。如果高優先級服務與外部服務具備業務上的直接相關性， 比如支付服務依賴于三方支付，盡可能保證單一外部服務的故障不會傳播。理想情況下對于一級服務依賴的外部服務應該有備份可供切換， 以消除關鍵外部服務的單點。 （10）

29、前端資源單點 圖片、JS、CSS 等靜態資源的可用性設計，建議盡量減少重要服務強依賴的靜態資源。 設計上做到當靜態資源無法訪問或訪問緩慢時，只影響用戶體驗，但不影響基本功能操作。 2.依賴設計 高等級服務不允許強依賴于低等級的服務或資源（內部服務、外部服務、數據庫、基礎技術組件等等）。這里的關鍵是依賴強弱程度的判斷： 分布式系統穩定性建設指南（2022 年） 15 最強依賴：當所依賴的服務不可用時，服務不可用，且造成系統崩潰。對于所有的依賴，不建議最強依賴。 強依賴：當所依賴的服務不可用時，服務不可用，但系統不會崩潰，且當所依賴的服務恢復后自動恢復。服務只可強依賴于同等級或高等級的服務與資源。

30、 弱依賴：當所依賴的服務不可用時，服務繼續可用，但損失一些次級功能。服務允許弱依賴于低等級的服務與資源。 最弱依賴：當所依賴的服務不可用時，服務繼續可用，且無任何功能損失。在成本可控情況下，推薦采用最弱依賴的方式。 分布式系統下的各資源依賴， 按類型和層次提煉出來會有如下幾種分類：系統啟動依賴、基礎軟件依賴、業務域依賴、數據庫依賴、硬件依賴、網絡依賴。 （1） 系統啟動依賴 系統啟動只允許依賴數據庫、 應用服務器本地資源 （如本地文件） 、公共存儲，不允許有其它基礎技術服務、內部服務或外部服務依賴。消除啟動依賴可以支持當發生大規模故障（如機房停電等）后的快速恢復。 （2） 基礎軟件依賴 基礎軟

31、件依賴主要包括消息中心以及數據緩存依賴， 同時還應考慮系統軟件及其第三方包依賴， 應用系統若無特殊情況不應依賴底層操作系統或 JVM 特定版本。 （3） 業務域依賴原則 分布式系統穩定性建設指南（2022 年） 16 建議上層業務域可以依賴下層業務域， 整體的依賴原則受到系統依賴原則的控制，必須首先遵守應用系統之間的依賴原則，而下層業務域不允許依賴上層業務域。 （4） 數據庫依賴原則 把數據庫按照數據等級進行分級， 不同等級的數據庫的數據保護和業務連續性保證都不一樣。 高優先級應用系統不能夠強依賴于次優先級的數據庫， 以此類推各級應用系統不允許強依賴低于自己等級的數據庫服務。 （5） 硬件依賴

32、原則 原則上應用服務不應該依賴特定的硬件設施， 比如服務器硬件平臺的型號 （CPU， 內存， 主板等） ， 網絡硬件的型號， 防火墻型號等。 （6） 網絡依賴原則 應用系統自身的網絡的依賴需求：包括跨機房的網絡依賴、外網訪問、防火墻等。原則上日常態不建議有跨機房的服務調用網絡需求(特殊情況如數據復制、容災等除外)，實現單機房內自閉環。 3.數據保護 數據保護的主要目的是提升數據安全性， 業界一般通過 RPO （恢復點目標）與 RTO（恢復時間目標）兩個指標進行度量,核心目標是盡可能縮短數據恢復時間（降低 RTO），避免數據丟失（RPO 接近于 0）。 （1） 服務器單點保護 分布式系統穩定性建

33、設指南（2022 年） 17 基于本地盤的數據庫系統，數據保護采取跨機房異步復制方式，服務器出現不可恢復性故障時存在數據丟失。 （2） 存儲單點保護 基于單存儲(如 EBS)保護的數據庫系統，數據保護采取跨機房異步復制方式，存儲出現不可恢復性故障時存在數據丟失。 （3） 同機房內多點保護 基于同機房多點保護的數據庫系統，采取同機房多份 redo 及跨機房異步復制方式，IDC 機房出現故障時存在數據丟失。 （4） 同城異機房保護 基于同城異機房保護的數據庫系統， 采取同城異機房內多份 redo保護及跨機房 DG，城市出現災難時存在數據丟失。 （5） 異地異機房保護 基于異地多點保護的數據庫系統，

34、 數據保護采取跨城跨機房數據保護，人類災難時存在數據丟失。 4.災備設計 災備恢復是指在災難發生后，將系統恢復正常運作的能力，包含部分數據保護技術。當故障或者災難發生時，可通過災備技術保證業務不中斷、數據不丟失。從災備技術的發展來看，主要經歷了冷備、主備、雙活/多活的發展歷程。 （1） 冷備技術 冷備技術最初是通過將數據放在異地進行備份， 解決了應用及數分布式系統穩定性建設指南（2022 年） 18 據單點問題，確保當主環境出現問題時，可利用異地備份還原數據即可，但冷備技術中備機不能提供訪問能力，存在資源浪費。 （2） 主備技術 主備技術，通過將部分應用部署到備，充分利用備的資源，但受到數據同

35、步限制，無法做到完美一致性，即使啟用備的寫應用，仍然是訪問主的數據，這種架構應對較大范圍故障問題存在不足，當發生如機房級故障時無法做到切換；為了解決以上問題，應用多活應運而生。 （3） 應用雙活/多活 應用雙活/多活是以應用為中心的云原生容災架構，是容災技術的一種高級形態， 可確保當災難發生時可在較短時間內實現業務流量切換， 盡可能減少災難帶來的損失， 有效保障業務系統持續穩定運行。應用多活通過將應用系統部署在多個地理節點， 綜合考慮各地理節點的電力、供水、網絡等基礎設施的容災因素，大幅降低區域性網絡整體故障和發生不可抗拒的自然災害時的服務故障以及丟失數據風險；通過支持各部署單元靈活調整業務接

36、入、同時支持處理業務邏輯、同時提供數據存儲等方式，確保當某個部署單元發生災難故障時，只有部分業務受到影響并按需分配到其他部署單元進行處理。 5.彈性設計 （1） 故障隔離標準 系統必須具備防止故障從一個系統/組件傳播到另一個系統/組件分布式系統穩定性建設指南（2022 年） 19 的能力。故障從一個系統/組件傳播到另一個系統/組件通常有以下兩種原因。 系統/組件間強依賴：如果系統/組件間存在強依賴，當一個系統/組件發生故障時，強依賴它的組件將無法正常工作。防止強依賴引發的故障傳播，通常的手段是將強依賴轉化為弱依賴或最弱依賴，比如設置合適的超時、 捕獲異常、 同步依賴轉異步依賴、 提供備份組件等

37、。 系統/組件間共享資源：如果系統/組件間存在共享的資源（如線程池、數據庫連接池、網絡連接池、內存區等），當一個系統/組件因為故障耗盡了共享的資源后，所有依賴該資源的系統/組件也都會發生故障。防止共享資源引發的故障傳播，通常的手段是對組件的資源使用建立配額體系，或者為重要組件提供專用資源。 （2） 訪問量控制標準 訪問量控制是指服務提供者或者服務使用者對服務資源有效的SLA 控制，在做訪問量控制設計時，需要關注以下幾方面： a. 服務提供者必須給出本服務 （包括系統調用服務、 頁面服務等）的訪問策略，包括最大的訪問能力、其它訪問約束（如參數約束、單賬戶訪問約束等），說明違反服務訪問策略的后果。

38、 b. 服務提供者需要對違反服務訪問策略的情況，實施管控措施。我們要求所有對外提供服務的系統（如對外服務的網關系統、對外服務的 web 系統等）必須具有防止外部訪問過載的能力（即具備限流能力）。 c. 渠道入口系統需要具備能夠降級入口服務的能力， 確保入口功分布式系統穩定性建設指南（2022 年） 20 能服務在出現異常時，在交易鏈路的最前段截斷異常，防止影響擴大。 d. 服務調用方需要對關鍵交易場景下的非關鍵服務訪問進行容錯設計，常用的手段包括（熔斷、降級），確保在非關鍵服務訪問出現異常的情況下，迅速切斷該服務訪問，保證關鍵交易成功率。 e. 服務調用方在調用第三方服務時，需要明確外部服務能

39、力，并具備相應手段可以進行訪問控制。 f. 原則上所有控制訪問量的手段（如限流、熔斷、降級）均應具備實時調整的能力， 以保證在異常訪問下系統的動態性能余量充足。 g. 原則上建議設定統一的 SLA 標準定義，按照標準的 SLA 模型進行訪問控制的實現，這樣可以確保全站的 SLA 模型和控制模型的一致性。 （3） 服務降級、限流與熔斷 服務限流是當負載超出系統/組件的處理能力上限時，可能會造成系統響應時間增加或部分業務失敗， 需要通過業務限流來防止系統響應進一步嚴重惡化。 比如： 某分布式系統能夠處理的最大tps為2000，通過規則限制上游服務每秒調用的 tps， 當請求量超過 2000tps

40、后隨機或選擇性拋棄一些請求。 服務降級是當出現系統/組件故障后，以犧牲某些業務功能或者犧牲某些客戶群體為代價，保障更關鍵的業務、客戶群體服務質量的分布式系統穩定性建設指南（2022 年） 21 應急措施。服務降級可以是人工觸發的，也可以是系統自動執行的。所有核心交易場景下的非關鍵服務訪問均應進行服務降級設計， 以保證核心交易成功率。如當某非關鍵的三方支付平臺發生故障，可以采取關閉該三方支付通道，確保整體支付成功率。 服務熔斷是在分布式系統中避免從系統局部的、小規模的故障，最終導致全局性的后果的手段。它是通過快速失?。‵ail Fast）的機制，避免請求大量阻塞，從而保護調用方。比如：一個服務

41、A 調用當下游 B 超時或失敗時，會導致請求超時引起堆積隊列，從而導致下游 B 系統壓力越來越大而無法恢復。當觸發熔斷后，到下游 B 服務的壓力減小，從而保護了存活的系統。 （4） 容錯設計 容錯設計對系統穩定性至關重要，在容錯設計中，首先應確定系統容錯等級策略，策略分級可參考表 2。 表 2 容錯等級設計 容錯設計等級容錯設計等級 等級描述等級描述 無容錯性設計 所依賴的外部資源訪問出錯，本應用未能檢測識別到，導致應用處理數據出錯，造成臟數據的 弱容錯性設計 所依賴的外部資源訪問出錯，本應用服務不可用且難以恢復的 基本容錯性設計 所依賴的外部資源訪問出錯，本應用服務不可用，但是由人工操作后可

42、恢復的 較強容錯性設計 所依賴的外部資源訪問出錯，本應用服務不可用，但可自動恢復的 強容錯性設計 所依賴的外部資源訪問出錯，本應用不受影響并正分布式系統穩定性建設指南（2022 年） 22 常對外提供服務的 來源：中國信息通信研究院 確定好容錯策略分級之后，開始系統容錯設計。系統需要提供充足的容錯機制， 以應對所依賴的外部服務或其他依賴資源發生故障情況；系統的設計原則應該本著不信任外部資源（外部服務、DB、網絡設備、存儲、消息等）100%可用的原則，在關鍵處理路徑上針對上述可能發生故障的點進行容錯加固設計，保護系統自身的可用性。 服務不可用容錯設計：跨系統服務調用，調用端必須保障請求準確送達、

43、服務端必須保障響應準確返回；基于此原則，某些場景下可能發生請求送達或響應返回丟失的，必須使用重試機制來彌補，如通過異步確保消息通知機制來解決跨系統、 一次性調用場景下請求無法確保送達問題。服務提供方系統發布中、或其他不可預知的服務訪問超時，都有可能導致客戶端請求失敗，此時客戶端應用若無任何容錯機制，則業務處理異常中斷。 關鍵應用的容錯設計： 某些關鍵應用服務需要多個系統參與處理，往往需要在多個系統中針對同一類型、性質的風險點進行多重加固，如一次嵌套分布式事務的所有參與者本身都會對主事務號的唯一性進行檢查，通過主事務記錄、其他參與者自有的事務記錄、默認參與者自有的事務記錄等多個唯一性約束裝置來多

44、重加固。 數據庫容錯設計：業務在正常執行的時候，如果遇到某個數據庫故障，需要具備快速的容錯機制，保證后續業務的正常進行。這種容錯機制包括數據庫的隨機拆分方案，數據庫的災難轉移或切換方案。 分布式系統穩定性建設指南（2022 年） 23 （二）容量設計（二）容量設計 容量設計的目的是根據業務優先級、 資源消耗情況等合理評估及分配資源， 良好的容量設計可以提升核心業務穩定同時帶來成本節約。 1.數據增長預測 數據庫訪問量：計算服務實現中對每一個數據庫的訪問量，可以表達為每秒/分事務數（TPS/TPM）或每秒/分查詢數（QPS/QPM），確保對數據庫的訪問量在數據庫可承受范圍內。 數據庫數據增長量：

45、計算數據的增長量，增長量可以表達為每日增加的記錄條數、增加的數量存儲量。確保數據增長量在數據庫與存儲可承受范圍內。 數據庫連接數： 計算承載服務的應用集群對數據庫連接數的需求，確保所依賴的每一個數據庫的總連接數不超過數據庫的承載能力。 其他數據服務訪問量與數據增長量： 除數據庫之外的其他數據服務訪問（如緩存、搜索等），可參考數據庫訪問量與數據增長量的評估方式進行評估， 確保數據服務的訪問量與數據增長量在可承受范圍內。 2.網絡流量 內部網絡流量、 連接數與請求數： 計算服務處理對內部網絡流量、連接數與請求數的需求，確保不超過內部網絡設備的承載能力。內部網絡流量、連接數與請求數需要包含交換機、負

46、載均衡設備、SSL 設備、防火墻、專線等。內部網絡流量計算復雜，推薦兩種方式：基于分布式系統穩定性建設指南（2022 年） 24 性能測試評測和基于生產服務實際網絡流量占比推算。 理想情況下可以針對每一個服務的訪問量與網絡流量之間建立計算公式。 外部網絡流量、 連接數與請求數： 計算服務處理對外部網絡流量、連接數的需求， 確保不超過外部網絡設備 （含外部負載均衡設備、 SSL設備、路由器、交換機、防火墻等）的承載能力。外部網絡流量的直接計算復雜，建議通過全鏈路壓測評測。 3.消息量 計算服務處理消息量與消息體大小，確保不超過消息中心(或消息隊列)的承載能力。若承載能力無法支持，則考慮對消息中心

47、進行擴容支持。如果涉及到跨 IDC 消息投遞，需要進行跨機房消息性能和容量的評估，原則上非必要不建議跨機房消息投遞。 4.內部資源使用 數據源連接池：在給定的服務訪問量下，針對數據源連接數（MAX/MIN）配置預估與設計，合理連接數的粗略估算方法可以通過事務并發數與事務長度來進行。如事務并發數是 100TPS，事務長度是 500ms，則 MAX 連接數至少要大于 50（100TPS*0.5s）。但合理的連接數最好通過性能壓測獲得， 或者根據處理模式與訪問量相似的系統的生產數據推測。 設置最大連接還必須同時評估對數據庫總連接數的影響以及與對 JVM 內存的影響。在無可參照系統的情況下，最穩妥的方

48、式是通過壓力測試來驗證。同時，嚴格設定連接池的BLOCK_TIMEOUT 值，確保系統在故障時期的容量和性能。若服務分布式系統穩定性建設指南（2022 年） 25 瞬時并發量大， 建議考慮數據庫連接池和預編譯SQL語句預熱設計，規避應用發布或重啟后的瞬間流量沖擊。 事務長度：數據庫連接在整個事務執行過程被占用，因此長事務對系統容量有嚴重的負面影響。由于遠程調用、底層資源訪問、長循環是典型的長時間操作，因此，必須將遠程調用、底層資源訪問與長循環盡可能從事務中移出， 將事務長度降到最低。 特別需要注意的是，在事務中進行可能產生阻塞的操作，后果可能非常嚴重，如無超時的遠程服務調用、底層資源訪問、可能

49、的無限循環等。對鏈路比較長的業務，可以通過異步化的方式來減少數據庫事務的長度。 線程池配置：在給定的服務訪問量下，確定每一個線程池的配置的合理性。線程池過小，將無法足夠的并發能力來支撐所需要的服務訪問量，線程池過大，則可能超過一個 JVM 可以支持的線程總數，且對性能可能產生負面影響。建議使用有界線程池，避免造成線程數量不可控。 建議通過壓測對線程池配置進行調優， 在滿足并發要求下，采用最小的線程池配置。 網絡連接池配置：在給定的服務訪問量下，需要確定每一個網絡連接池配置的合理性。網絡連接池過小，將無法提供足夠的并發能力來支撐所需要的服務訪問量，連接池過大，則對網絡設備與目標服務器產生過大的壓

50、力，且對性能可能產生負面影響。建議通過壓測對網絡連接池配置進行調優，在滿足并發要求下，采用最小的網絡連接池配置。 分布式系統穩定性建設指南（2022 年） 26 JVM 配置： 評估 JVM 內存配置、 GC 算法與參數配置是否合理。通常情況下，JVM 配置可以根據線上參考系統（應用的架構、典型處理模式、訪問量與訪問模式等）進行配置。但如果應用有特殊需求（比如開設了大的內存緩存、隊列，或者對響應時間與吞吐量有特殊要求等） ， 需要進行專門調優， 并對調優結果進行性能與穩定性測試。需要注意的是，所有的內存緩存、隊列以及內部其它數據結構查詢等都必須設置大小上限， 并計算或測試當上限達到時不會出現堆

51、內存溢出的情況。 一個容易出現的問題是使用內存數據結構作為批量查詢或文件處理的緩沖區，當輸入數據量過大或者并發度太高時，堆內存就耗盡了。 5.伸縮性 復制性伸縮：應用復制型伸縮是所有應用都必須具備的能力，因為應用必須是無狀態的，可以通過在集群中添加應用服務器實例，可以接近線性地擴展集群容量。對訪問量大、讀寫比高、數據一致性要求低的場景，可考慮緩存與讀寫分離策略，實現數據復制。應用必須具備容忍一定的數據復制延時造成的數據不一致的能力。 垂直性伸縮：應用垂直型伸縮是指按照功能將應用拆分。需要評估應用拆分與業務架構、應用架構、非功能性需求的匹配度以及粒度是否合理。數據的垂直型伸縮也是指按照功能對數據

52、拆分，同樣需要評估數據拆分與業務架構、應用架構、非功能性需求以及運維成本的合理性，取得各方面綜合最優的方案。 分布式系統穩定性建設指南（2022 年） 27 水平性伸縮：水平型拆分主要針對數據，是指按照用戶或請求的維度對數據進行水平拆分。 若預判未來業務量增長必須通過數據水平拆分才能支撐，需要在早期實現中就實現數據水平拆分，避免未來重構的成本與風險，行業內水平拆分的技術可以參考 TDDL 等技術。 6.IDC 容量 需確保每個 IDC 容量充足，可以應對任何單個 IDC 宕機的容量影響，原則上對于一級服務必須具備多個 IDC 的容量，確保任何一個 IDC 宕機，剩余的 IDC 都能提供 100

53、%的處理能力。 7.鏈路分析 同步調用鏈分析：過長的同步調用鏈對性能、容量、可靠性都是極大的風險，整個處理的響應時間是鏈條中每一環的處理時間之和，鏈條中的任意一環出現故障或緩慢，都會造成整個處理緩慢或失敗，所有的服務訪問量會壓到同步處理鏈條中的每一環， 且每一環存在大量的線程等待（阻塞線程資源甚至更昂貴的數據庫連接資源）。降低同步處理鏈路長度的通常做法有：控制系統的拆分粒度，優化系統的職責；對于大訪問量的處理（每日千萬級或以上），可考慮將遠程調用固化成本地處理，犧牲一些靈活性換取穩定性與性能；異步化。 響應時間分析：需要對所有服務的響應時間進行分析。服務處理的響應時間取決于它所直接依賴的內、

54、外部業務或系統服務的處理響應時間，它自身的處理時間、以及請求排隊等待的時間。對響應時間的評估不是一個絕對值，而應該是一個響應時間區間。需要找到瓶頸點進行分析與優化，確保響應時間區間滿足客戶端的需要。 分布式系統穩定性建設指南（2022 年） 28 8.吞吐量提升 在實踐中，由于資源的有限和調配存在延遲，通過提升系統性能不僅在資源上能降低成本，在穩定性上也有著積極意義，可以降低用戶體驗延遲，減少機器高負載時不穩定的概率。 基礎設施優化：依賴數據庫、中間件等通過優化配置、技術創新等針對性能進行優化，例如 gc 調優、慢 sql 治理等。 業務流程優化：降低調用次數、多次網絡調用優化批量調用、非核心

55、邏輯異步處理、根據負載自動化削峰填谷設計等。 （三）運維方案設計（三）運維方案設計 系統要考慮持續迭代發布變更以及線上運維的訴求， 做到變更可控、系統可觀、演練到位。 1.變更管控 變更引發穩定性一般都占據大部分比重， 因此需要管理好變更執行過程。 （1） 兼容設計 在變更管控各項變更中，如果考慮好兼容設計，其整體的變更就會比較平滑，整個變更的兼容設計會從硬件、軟件、數據三個層面展開，其中軟件部分還區分基礎軟件和應用軟件，現在從以上部分展開對應的兼容設計需要考慮的原則如下描述。 硬件變更兼容設計。硬件平臺變更，原則上不應該影響在其之上運行的應用服務 （主機硬件平臺升級， 網絡設備升級， 存儲設

56、備升級，分布式系統穩定性建設指南（2022 年） 29 防火墻升級），所有硬件升級必須考慮線下兼容性，需要在線下環境進行詳細的測試驗證，保證生產系統變更穩定性。 基礎軟件變更兼容設計。任何基礎技術和系統軟件的升級，原則上不應該影響使用其的應用服務（框架，消息組件，緩存，存儲中間件，操作系統，JVM，Apache，JBoss，Tomcat 等），所有基礎軟件必須考慮線下兼容性，需要在線下進行嚴格并且詳細的測試，保證生產系統變更穩定性。 應用軟件變更兼容設計。 應用升級方案中應該考慮應用向下兼容能力，無法完全向下兼容的應用升級過程，在聯調、預發布及正式上線過程中會引起已有業務服務的不可用， 在關鍵

57、業務路徑上的一級服務如果發生不兼容現象后果更加嚴重， 會直接導致變更過程中的大量業務處理中斷，引起核心業務下跌。應用可向下兼容的評估點包括但不僅限于：服務接口、方法、入參、返回值及服務方法具體實現的向下兼容性能力； 其中服務方法具體實現向下兼容是應用向下兼容能力的最核心表現。對于一、二級關鍵服務，應用升級過程中必須完全向下兼容， 確保發布過程中不產生兼容性問題進而導致業務下跌或其他關鍵服務不可用。 同時服務消費端設計上需要做到客戶端可不要求同步升級。 數據變更兼容設計。 應用軟件系統升級方案往往附有數據存儲格式變更， 良好的數據兼容性設計對升級后應用平穩上線起到重要的保障作用。數據兼容性設計要

58、求設計方案遵循安全的增量變更原則，即在保障已有的數據存儲結構不發生語義變化的前提下， 合理增加升級分布式系統穩定性建設指南（2022 年） 30 應用所必須的數據列； 并且所增加數據列不對已有業務服務造成影響，如外部系統所調用的查詢服務不會中斷、 業務返回結果不變。 原則上，當已有數據存儲結構語義發生變化， 原存儲列所存儲值業務含義發生變化時，應該通過新增存儲列來完成，避免直接復用已有存儲列或修改已有存儲列名的做法。 對于重要性高的服務，數據升級后必須完全向下兼容；確實無法做到數據向下兼容的，如原有存儲列完全廢棄的，應該首先確保外圍使用系統業務改造完成后方可上線。 （2） 新版本發布設計 停機

59、性發布。原則上建議非高優先級系統不進行停機發布。對于高優先級系統， 應在系統設計階段盡量避免停機發布， 如因系統拆分，數據庫拆分，整體架構升級等原因一定需要停機，需嚴格限定停機范圍、 停機的時間點與停機時長。 如需停機的系統及業務可以獨立發布，則除這些系統外，其他系統盡量保障采取非停機平滑發布方式。如因系統耦合度或者業務耦合度復雜無法獨立發布， 則進行整體停機發布； 發布順序是否合理。根據系統間依賴指定合適的發布先后順序。系統發布順序遵照以下原則：禁止系統啟動依賴，無因系統啟動依賴導致的發布順序依賴；對于業務依賴，需保證無相互依賴。高優先級系統原則上不應該依賴于低優先級系統；其他系統默認無發布

60、順序，可以根據發布進度進行無序發布。 發布時間點。發布時間點需盡量避開業務高峰，尤其是發布過程會對業務產生影響的核心系統。系統發布因盡量避免影響業務，如確分布式系統穩定性建設指南（2022 年） 31 實對業務影響較大又無法在系統設計上避免， 需將發布時間點放在絕對業務低峰點。 涉及新舊功能切換。驗證切換方案地合理性，可逆性。發布過程中涉及到的新舊功能切換方案，應確?？赡?，即切換失敗后能及時切回到舊功能。方案需在研發環境進行詳細測試，如無法在研發環境進行測試， 需在預發布環境進行模擬測試， 確保方案正確有效， 可回滾。 （3） 灰度變更 變更過程需要針對變更影響業務、 用戶或流程進行必要的灰度

61、設計，以確保變更一旦出現問題，影響在可控范圍內。 平臺建設部分，對于變更及發布過程，可以通過建立多級驗證環境并約束變更逐級變更來提前或在在有限影響范圍內發現問題。 常用技術環境包含線上和線上多個驗證環境， 各業務也可根據自身情況選擇性進行建設。 線下環境，包括開發環境、聯調環境，用于線下研發開發驗證及上下游聯調功能運行情況。 線上環境，包括預發布、灰度、仿真、線上等多個環境，預發布環境用于開發人員進行線上新功能驗證， 灰度環境用于引流內部可控用戶流量進行持續驗證，仿真環境可針對線上流量復制回放驗證，最后再生效線上真實環境。 變更灰度過程，在分布式系統中常見通用的灰度過程有 beta 發布、藍綠

62、發布，進行流量級別的灰度過程，能夠滿足絕大部分變更灰度驗證需求。如果變更復雜度較高或者業務比較重要，在方案設計中分布式系統穩定性建設指南（2022 年） 32 也需要進行更精細變更影響面控制， 例如按照影響用戶維度逐步生效的設計，但要注意一次業務完整流程中開關一致性問題。 （4） 數據遷移分析 發布過程所需的數據遷移方案， 需事先在線下環境進行模擬演練，反復梳理遷移過程執行步驟，將可能發生的遷移風險降到最小。數據遷移方案的可行性包括： 方案的完整性： 是否本次升級內容所必須包含的待遷移數據項全部覆蓋到位。 方案的安全性：對于敏感信息如用戶隱私信息的遷移方案，是否存在由于遷移腳本的不合理導致隱私

63、信息泄露風險。 方案的可實施性：包括數據遷移操作方案的合理度（發布過程中完成或者發布前、發布中、發布后多階段完成），相關角色配合實施步驟， 同時必須考慮本項目的數據遷移方案所占用時間是否對同一發布窗口的其他項目造成影響。 方案的可檢測性：遷移過程各個階段的數據完整性、準確性檢查腳本是否準備到位。 方案的可回滾性：遷移過程中各個階段如果發生了計劃外風險，必須要終止遷移操作的，是否具備了已遷移數據回滾能力。 涉及重要性高的服務的數據遷移方案必須完整、安全、可實施、可檢測、可回滾。 （5） 可回滾設計 回滾的必要性：應用新版本計劃應該制定詳盡的回滾計劃，能夠分布式系統穩定性建設指南（2022 年）

64、33 在最短時間內將應用恢復至上一穩定運行版本； 一般情況下應用本身可回滾，而數據層面的可回滾性是重要的考量因素之一。遵循安全的增量變更原則所設計的數據變更方案具備可回滾能力， 發布過程中所產生的增量數據列存儲值要求可廢棄。 原則上任何應用服務在發布之前都必須具備可回滾的能力， 沒有回滾能力的系統不允許發布上線。 回滾的復雜性：除應用本身及數據層面的可回滾性考慮外，若服務使用客戶端已完成同步升級，則必須考量客戶端的可回滾性；極端情況下， 若客戶端的本次同步升級也造成了其作為服務提供方的使用客戶端同步升級，則存在多個應用系統復雜的連帶可回滾需求；相關系統也需要評估其應用本身及其數據層面的可回滾能

65、力， 作為本次應用升級回滾方案的一并考慮項。 在升級方案設計中，應該提前預知復雜回滾方案的實施成本，防止發生上述的同步升級的多重強依賴關系。 回滾方案包括但不僅限于：應用回滾、數據回滾及清理、運維策略回滾、監控方案回滾等。 回滾操作對業務的影響：由于應用升級的回滾實施，必然會影響本次升級業務所服務的業務需求， 同時會直接影響對本次升級有依賴的其他業務系統； 回滾方案中必須明確本次發布窗口所有相關性需求項目，明確一旦發生回滾處理受影響范圍，提前告知相關項目組及業務方， 同時盡可能降低多個業務關聯性較強項目同一發布窗口的回滾風險。 分布式系統穩定性建設指南（2022 年） 34 涉及重要性較高的服

66、務應用升級方案要求必須提供回滾方案， 且此回滾方案事先在線下環境得到完整模擬演練并確認可行； 回滾完成后要求不得中斷服務，業務運行正常。 （6） 配置變更控制 涉及生產配置參數的變更， 原則上必須進行嚴格變更審批流程保障。所有對于生產動態配置變更由專業運維保障團隊統一操作。 動態配置能力可以從以下方面進行設計： 動態配置變更的時機：預發布變更、發布后變更等； 動態配置的可驗證： 變更接收方能夠以日志等形式驗證推送的內容，否則是否推送，何時推送，推送的內容正確與否無法確證； 動態配置的生效同步性： 在某動態配置涉及多個系統都需要同步時，應用需要考慮在多個系統間不同步時會出現的問題； 動態配置的容

67、錯性處理：防止進行線上配置填寫錯誤時，系統即按照錯誤的情況運行，動態配置必須有默認值; 動態配置是否系統啟動時加載：需要系統初起時加載的內容，需要防止出現系統啟動依賴； 周期性動態配置：對于定時刷新緩存方式實現的動態配置，需要保證刷新成功后才更新或者替換緩存內容； 不能在主線程中判斷和刷新緩存，而應該另起線程刷新，防止刷新緩存出現抖動或者阻塞而影響主線程的功能。 （7） 復核驗證 每個變更都需要有復核人，對于標準變更，復核人可只對結果進分布式系統穩定性建設指南（2022 年） 35 行復核。對于普通變更和重大變更，復核人需要對變更流程、變更表單、 實際操作進行核對確認， 對變更后的結果進行日志

68、、 監控等檢查。復核人應對變更不當而引發的問題負責。 每個變更后， 需要有一系列的基于變更清單管理的效果檢查的內容。如：服務是否正常啟動，功能是否可用，性能是否正常，以及變更的內容是否符合預期。通過對變更效果進行驗證，才能最終確認本次變更是否正確。同時，針對服務相關的全局核心指標的監控，在變更期間既不應該出現異常，也不應該隨意屏蔽。 2.可觀測設計 分布式系統一般涉及較大規模服務集群， 復雜度和鏈路深度較高，因此處于分布式系統各服務節點需要具備完善的日志、監控指標、鏈路追蹤等可觀測手段， 以便準確觀測業務系統運行情況并及時定位處理問題。 對于應用系統觀測需要覆蓋的資源類型如表 3 所示。 表

69、3 系統觀測覆蓋資源 覆蓋類型覆蓋類型 指標描述指標描述 基礎設施 操作系統、中間件等運行監控，包括計算、存儲、網絡資源，如 CPU、load、線程池等 系統服務 鏈路系統各節點運行情況，便于定位問題節點 應用依賴 系統組件依賴服務，如存儲、中間件、第三方依賴 核心組件 應用核心處理邏輯的關鍵運行數據及報錯監控 業務運行 能夠直接體現業務運行情況，包括用戶體驗監控 來源：公開資料整理 分布式系統穩定性建設指南（2022 年） 36 此外，系統可觀測性數據采集需要設置合理的資源規劃，具備應急降級能力，避免數據采集進程占用業務系統過多資源；控制采集數據大小， 可采用滾動切割并定期清理過期觀測數據方

70、式控制磁盤占用量；避免數據采集影響業務主線程，可采用異步方式輸出可觀測性數據。 3.演練設計 （1） 預案演練 預案演練主要解決的問題是：根據單個系統的應急預案，模擬應用系統的一種或多種故障場景，驗證系統的可靠性。 預案演練形式 預案演練根據應急預案組織相關的應急組織機構和人員， 利用本地的應急資源和系統環境，針對事先假設的異常應急場景，通過模擬實際決策、指揮和技術操作，完成應急響應及處置的過程，從而檢驗和提高相關人員的決策指揮、組織協調和應急處置能力。 預案演練原則 預案演練要遵循兩個主要原則，確保業務能提供連續性服務；案演練范圍和風險影響可控 預案演練目的 檢驗預案。通過演練進一步理順應急

71、處置流程，同時檢驗應急處置方案的完整性、有效性。 鍛煉隊伍。通過演練增強演練組織部門、參與人員等對預案的熟悉程度，提高應急處置人員的應急響應效率和應急處置能力。 分布式系統穩定性建設指南（2022 年） 37 磨合機制。通過演練進一步檢驗部門間的應急聯動效率，完善相關部門間的工作聯動機制。 預案演練實踐 明確演練場景。明確要演練的故障場景及影響范圍。 明確風險和應對措施。 提前評估預判各場景演練過程中可能存在的風險，并針對各種風險給出應對措施。將風險和措施告知所有干系人。 明確演練人員。演練人員包括組織人員和參演人員，組織人員負責演練前的策劃、文檔準備、演練人員與演練環境的落實、演練實施過程中

72、的綜合協調及演練結束后的評估總結等工作， 以保障應急演練能夠順利實施。 參演人員負責具體演練操作實施。 明確演練技術方案和業務驗證方案。演練前檢查與業務驗證：包含系統檢查：檢查數據庫、負載均衡、應用集群等狀態是否正常；應用檢查：檢查服務是否可用、交易量、交易成功率等指標是否正常；網絡檢查：檢查負載均衡、集群、數據庫間網絡環境是否正常；業務驗證：根據案例進行演練前的業務驗證。 切換階段。明確演練切換的各操作步驟，建議通過工具實現作業編排，自動化執行切換操作。 切換后檢查與業務驗證。切換后進行技術和業務驗證，檢查數據庫集群、負載均衡、應用集群、網絡環境等狀態是否正常，并根據案例進行業務驗證。 回切

73、前檢查。同演練前檢查操作，檢查系統、應用、網絡等狀態分布式系統穩定性建設指南（2022 年） 38 是否正常。 回切階段。通過工具編排操作指令，進行自動化切換。 回切后檢查與驗證?；厍泻筮M行技術和業務驗證，檢查數據庫集群、負載均衡、應用集群、網絡環境等狀態是否正常，并根據案例進行業務驗證。 演練實施流程 演練實施流程即演練切換前后每一步操作指令， 一般建議三要素形式明確，主要包含：時間，操作，內容。如演練前的操作 0：00 關閉負載均衡，阻止交易進入。 （2） 災難演練 災難演練與預案演練的區別首先體現在參與演練的應用范圍上，災難演練是針對整個地區的整個機房發生故障， 該機房所有部署的系統全部

74、切換到異地機房的演練， 預案演練是針對單個系統的某個或某幾個故障場景做的應急預案進行演練。 其次是在組織形式上和影響范圍上的差別，災難演練波及的系統范圍多，參與人員廣，預案演練波及的系統范圍少，參與人員少。 災難演練主要解決的問題是： 驗證當數據中心整個園區發生災難，如戰爭、 地震等引起大面積停電， 導致整個機房系統不可用的情況下，應用系統如何平穩切換到異地機房啟用災備系統， 繼續對外提供服務的能力。 災難演練形式 災難演練根據災備方案組織相關的組織機構和人員， 利用異地資分布式系統穩定性建設指南（2022 年） 39 源和系統環境，針對事先假設的異常災難場景，通過模擬實際決策、指揮和技術操作

75、，完成災難切換響應及處置的過程，從而檢驗和提高相關人員的決策指揮、組織協調和處置能力。 災難演練原則 災難演練過程中需要遵循以下重要原則： 確保業務能提供連續性服務；災難演練范圍和風險影響可控。災備環境有對等數量的機器部署了同樣的應用程序、數據庫、中間件等。演練目的就是驗證通過切換到災備環境后應用能正常運行， 因此分布式系統的災備系統建設是災難演練的前提。 建議對分布式系統按照業務重要性建設申請災備資源，例如重要核心系統申請 1：1 對等資源，非重要核心系統申請 1：0.75 的資源，保證災備環境的可用性。 災難演練目的 檢驗災備方案。通過災難演練進一步理順災備切換流程，同時檢驗災備方案的完整

76、性、有效性。 鍛煉隊伍。通過災難演練增強演練組織部門、參與人員等對災備方案的熟悉程度，提高處置人員的響應效率和處置能力。 磨合機制。通過演練進一步檢驗部門間的聯動效率，完善相關部門間的工作聯動機制。 災難演練實踐 災難演練方案一般包含如下內容： 明確演練場景。首先主要明確演練場景、演練時間（演練切換時間，異地執行時間，回切時間）； 分布式系統穩定性建設指南（2022 年） 40 明確風險和應對措施。 要提前判斷演練中可能存在的風險和應對措施，將風險和措施告知所有干系人。 明確切換范圍及業務影響。 其次主要明確參與切換的分布式系統以及其關聯系統范圍， 需要分析切換和回切階段對業務服務造成的影響，

77、是否需要停機，停機時長，停機影響哪些業務，業務中斷時長，是否需要向對監管機構報備等。 明確演練人員。演練人員包括組織人員和參演人員，組織人員負責演練前的策劃、文檔準備、演練人員與演練環境的落實、演練實施過程中的綜合協調及演練結束后的評估總結等工作， 以保障災難演練能夠順利實施。 參演人員負責具體演練操作實施。 明確技術切換方案。 明確如何切換技術方案是決定災難演練成功與否的最關鍵的一環，在保證災難演練能夠平穩切換，業務影響最小的前提下，明確各分布式系統切換的方式，如使用智能 DNS 切換或通過負載均衡重定向流量等。 關聯系統如何配合。在明確分布式系統切換方式后，需要明確不參與切換的關聯系統如何

78、接入和啟停方案。 如配合切換系統關停交易，待切換完成后重啟交易。 確保資源充足。 切換到異地機房運行期間要根據這期間的業務量預估災備環境計算資源、存儲資源是否夠用，否則需要申請資源。 自動化執行。切換盡量采用工具化，對切換作業進行編排流程，實現一鍵切換。 運行監控方案。 分布式應用系統切換后在異地機房的運行需要進分布式系統穩定性建設指南（2022 年） 41 行監控運行情況，需要明確異地機房的監控是否完善，確保切換前后對系統的運行情況始終有監控。 確定業務驗證方案 組織業務人員在切換前、切換后、回切后等三個階段，驗證分布式系統的業務連通性和業務服務的可用性。 演練實施流程 演練實施流程即演練切

79、換前后每一步操作指令， 一般建議三要素形式明確，主要包含：時間，操作，內容。如演練前的操作 0：00 關閉負載均衡，阻止交易進入。 （3） 混沌實驗 混沌實驗有相對固定的模式，通常包括實驗設計與準備、實施執行和實驗結果分析等過程。 混沌實驗一般通過混沌工程平臺實現各類混沌實驗的統一管理和執行。 實驗設計和準備階段。主要包括故障場景、穩態指標、靶點管理和實驗編排等內容。 實驗執行階段。主要包括故障注入、故障觀測、實驗防護和故障恢復等步驟。 實驗結果分析階段。主要包括實驗報告、問題分析與跟進以及統計度量等。 （4） 風險巡檢 風險巡檢驗證方案即可配合上述演練驗證方案同步進行，也可獨立實施。它是一種

80、白盒化的可擴展風險管理和巡檢能力。 分布式系統穩定性建設指南（2022 年） 42 一個基礎的風險巡檢方案包含以下必要的要素： 按照分布式系統穩定性各子域進行分類，實現每一個子域下穩定性相關的風險關鍵數據錄入形成一個驗證的基準，如表 4 所示。 表 4 穩定性風險基準表格示例 子域 穩定性風險 影響描述 關鍵指標 修復建議 風險 級別 風險 評分 數據庫 Druid連接池配置不合理 當連接池配置不合理時會造成數據庫操作請求阻塞和延遲。 若initialSize=0，建議調整； 若 minIdle=0，建議調整； 若maxActive=8，建議調整 initialSize：初始連接數，連接池啟動

81、時創建的初始化連接數量 minIdle： 最小空閑連接數，連接池中容許保持空閑狀態的最小連接數量，低于這個數量將創建新的連接 maxIdle： 最大空閑連接數，接池中容許保持空閑狀態的最大連接數量,超過的空閑連接將被釋放 maxActive：最大連接數，連接池在同一時間能夠分配的最大活動連接的數量 中 5 JVM 線程嚴重阻塞 嚴重的鎖競爭導致線程阻塞嚴重，可能對響應時間和 TPS造成較大影響 等鎖線程數（或比例）大于 X 找出等鎖線程中不合理的設計進行調整 高 8 來源：公開資料整理 實現各子域穩定性指標數據的采集。 分布式系統穩定性建設指南（2022 年） 43 不同類型的采集器遵循相同的

82、標準輸入及返回值 Schema 定義?？赏ㄟ^ Agent、系統工具、系統命令、虛擬機命令等作為數據采集的媒介。 數據采集對象建議以操作系統、 虛擬機、 應用等為一級域， 如：一級域：操作系統，二級域：CPU、內存、網絡等等；穩定性風險基準表格中的子域推薦與此保持一致。 實現采集數據與基準數據的比對，并出具風險報告。 數據比對。將采集到的數據與各子域對應的基準數據進行比對，將命中的數據進行匯總，以報告形式輸出。 數據報告。按完成采集驗證的子域進行匯總分類，給出整體發現的穩定性風險數量、及風險類型、風險等級分布信息，同時，按子域給出每個子域發現的具體的風險詳細信息 自動化能力，實現分布式系統穩定性

83、日常巡檢。 定時巡檢。實現按指定時間周期，指定子域范圍的自動進行風險巡檢。觸發式巡檢。實現按照特定數據指標閾值自動觸發風險巡檢。 （四）安全設計（四）安全設計 系統安全是系統穩定的基礎，沒有安全的運行環境，穩定性也無從談起。系統安全性設計可以劃分為如下幾個方面。 1.系統設計安全 從系統設計的安全性來說,目前大多系統的分布式結構稍不留神就會產生安全隱患?，F在已經有一些代碼安全掃描工具（如：Fortify,CxSuite 等）幫助開發者進行一些安全和漏洞識別。常見的由系統設計不當產生的安全漏洞類型及防范措施見表 5。 分布式系統穩定性建設指南（2022 年） 44 表 5 安全漏洞類型及防范措施

84、 漏洞類型漏洞類型 漏洞描述漏洞描述 防范措施防范措施 輸入驗證漏洞 嵌入到查詢的字符串、表單字段、cookie 、惡意 http 協議頭、大文件攻擊等。這些攻擊包括命令執行、跨站點腳本(XSS)、SQL 注入和緩沖區溢出。 在后臺代碼中必須驗證輸入信息后才向服務層提交。 身份驗證漏洞 標識欺騙、密碼破解、特權提升和未經授權的訪問。 程序設計中用戶身份信息必須由服務器內部的會話系統提供， 避免通過表單提交和頁面參數的形式獲取用戶身份。 授權漏洞 非法用戶訪問保密數據或受限數據、篡改數據及執行未經授權操作 訪問保密數據時一定要根據用戶身份和權限來判斷操作是否允許。 敏感數據保護漏洞 泄露保密信息

85、以及篡改數據 在儲存敏感數據時要采用合適的加密算法來對數據進行加密。 日志記錄漏洞 不能發現入侵跡象、不能驗證用戶操作以及在無法幫助診斷問題 程序設計中狀態變更的操作， 要記錄下盡可能詳細的操作信息， 以便操作記錄可溯源。 來源：公開資料整理 2.部署和操作系統安全 從系統部署及操作系統安全性來說，可以參考以下防范措施：部署的操作系統或系統本身所應用到的組件， 需要確保安裝或升級相關安全補丁，關閉了所有不需要的系統服務，只對外開放必須的端口，且對訪問進行鑒權；定期查看 OS 或引用到第三方組件的安全風險，及時安裝補丁或替換升級；定期檢查系統日志，對可疑操作進行分析分布式系統穩定性建設指南（20

86、22 年） 45 匯報； 應用服務器程序在服務器中文件系統中的目錄結構位置應該盡量清晰， 目錄命名需要盡可能的有意義； 應用服務需要創建獨自用戶，不能以具有系統管理員權限的系統用戶運行。 3.數據安全 從數據安全性來說，可用以下的防范措施：對數據庫監聽地址要有限制，只對需要訪問的網絡地址進行監聽；執行數據備份制度，對存儲數據和數據進行定期備份；數據操作授權限制，對表一級及其以上級別的數據庫或核心數據的操作授權不應對應用服務器開放。 4.網絡安全 從網絡安全性來說,可用以下的防范措施：選用企業級網絡防火墻；根據具體網絡環境，制定盡可能周密的防火墻規則；在外網中傳輸的數據，應選用合適的加密算法(如

87、:使用 https 協議)進行加密。 分布式系統穩定性建設指南（2022 年） 46 五、分布式系統穩定性建設路徑 “從業務來，到業務去”應當是穩定性保障設計的關鍵原則，否則再先進的技術也可能只是空中樓閣，脫離實際業務需求，往往于業務產生不了最大實用性價值。 在服務業務保障業務持續可用過程中沉淀下來的技術才是最有價值的技術。故而本指南將從軟件生命周期、運行周期逐步分解穩定性保障的要點及相關建設思路， 從業者可根據自身實際情況選擇、規劃。 （一）穩定性建設需求分析（一）穩定性建設需求分析 在開展穩定性建設工作之前，首先需要確認分析對象主體，一般情況下可對以下對象進行穩定性分析：一個應用系統，通常

88、以獨立的應用系統為分析對象，如聊天軟件、交易系統等；一組應用系統，通常以業務場景為主體關聯，如電商訂單支付關聯系統、微信聊天關聯系統；一個架構域，通常一個架構域內應用系統都會有一定的內在聯系， 以架構域為對象能夠盡可能避免可能發生的對長尾業務場景的忽視；當然，從業者可根據實際風險形勢，根據實際優先級重點確定核心對象。 其次需要確定被分析對象（如一個或一組應用系統）的穩定性需求，確定穩定性需求可采用如下方式：確定被分析對象提供的所有服務， 包括系統服務、 頁面表現層服務、 restful 服務或者終端設備服務；確定服務的使用場景用于哪些業務與系統流程， 存在于這些業務或系統流程對應的上游服務，上

89、游服務可以通過服務依賴鏈路追溯；確定每一個服務的重要性等級（一級、二級、三級） ，一個服務的重要性分布式系統穩定性建設指南（2022 年） 47 等級由強依賴它的最高等級的業務服務決定， 根據各服務的重要性等級，確定對象穩定性需求。 （二）穩定性建設實現分析（二）穩定性建設實現分析 確定穩定性保障需求之后，進一步采集分析與服務相關的業務、架構、設計、實現、配置、部署、硬件與軟件使用信息，只有擁有準確、全面的信息，才能保證穩定性分析結果及穩定性保障設計的可靠性。通常從以下幾個方面進行分析（包括但不限于以下各節）： 1.服務實現流程分析 分析明確服務的實現流程，如服務實現的 UML 活動圖、UML

90、序列圖或者業務流程圖等。 2.強弱依賴分析 分析服務實現流程中所依賴的所有應用系統 （以及這些系統提供的服務） 。對一個應用系統而言，將它提供的每一個服務所依賴的應用系統匯總起來，可以構成應用依賴總體結構圖。 對每一個依賴，需要識別該依賴的以下屬性： 依賴強弱：強依賴是指必須的依賴，弱依賴是指可選的依賴； 同步或異步：同步表示需要等待返回，異步指調用發生后無需等待立即返回； 依賴權重：一次服務過程中依賴的次數，即訪問的次數。 針對具體的服務類型，需要針對性地開展依賴分析，如： 分布式系統穩定性建設指南（2022 年） 48 數據庫依賴：需服務實現流程中所依賴的所有數據庫，將它提供的每一個服務所

91、依賴的數據庫匯總起來， 可以構成該應用對數據庫的依賴總體結構圖。 硬件服務依賴：服務實現流程中所依賴的所有硬件服務，如外部硬件存儲，網絡（短信，專線等），負載均衡（接入和內部負載均衡機制），防火墻等。 基礎技術服務依賴： 服務實現流程中所依賴的所有基礎技術服務，如消息、緩存、K-V、分布式資源管理等，將它提供的每一個服務所依賴的基礎技術服務匯總起來， 可以構成該應用對基礎技術服務的依賴總體結構圖。 3.部署架構分析 架構指系統的頂層結構， 穩定性建設工作開展前需分析各個實現組件的生產部署架構，明確系統有哪些部分組成，以及明確系統間的協作關系，如集群劃分、集群的大小、集群 IDC 分布、網絡拓撲

92、等。 4.訪問模式與訪問量分析 若訪問量、訪問模式與業務量之間存在確定的關系，可以給出該服務訪問量與業務量之間的函數關系。 這樣做的好處是可以方便準確地推算出該服務的訪問量與訪問模式，簡化容量分析與規劃； 如果訪問量、訪問模式與業務量之間沒有確定的關系，進一步估算合理的服務訪問量與訪問模式，根據生產實際運行情況持續更新。 （三）穩定性建設活動（三）穩定性建設活動 穩定性建設模式需要一系列具體的建設活動推進和落地，這些建分布式系統穩定性建設指南（2022 年） 49 設活動涉及人員、機制和文化，全方位的建設活動才能更好地落實建設模式。 1.建設穩定性保障機制 穩定性涉及團隊所有不同水平技術人員、

93、所有系統、研發所有環節、線上時時刻刻，單個技術人員是無法保障好的，必須建立團隊流程機制來可持續保障。 規范編制。穩定性工作，規范先行。制定代碼編寫規范，規范覆蓋日志、配置、多線程、數據庫使用等多層面，提升代碼質量；制定變更規范，提供變更級別、角色職責、活動階段以及輸入輸出的詳細規定；制定運維操作規范，針對公司日志標準，提供統一的日志排查命令及規范，針對運維相關的監控告警制定告警處理流程、告警升級機制。 方案評審機制。 在系統的負責團完成系統的建設或改造方案初稿后，需通過由業務、技術、測試、運維領域專家組成的專家團隊方案評審，才能進一步對方案進行實施。 測試準入準出機制。進入穩定性測試階段，要嚴

94、格審查系統是否達到測試準入條件，即滿足測試實施的所有必要條件，如果未滿足，則不開展穩定性測試。在穩定性測試實施結束后，嚴格檢查所有測試準出條件是否滿足，如：沒有進行中的缺陷等，否則不予測試通過。 值班及責任判定機制。 設置值班制度， 每天有技術人員負責值班，值班周期內的所有問題由值班人員治理，不能及時完成的，添加到BUG 定期跟蹤并統計。在出現生產事件后，由專家團隊對該問題進分布式系統穩定性建設指南（2022 年） 50 行詳細分析， 確定問題的發生原因、 解決辦法后， 對該問題進行問責，明確責任團隊、責任人、責任承擔比例等內容。避免在穩定性治理中產生“囚徒困境”。 能力考核機制。通過考核機制

95、，提升技術人員對系統穩定性建設的積極性，如在測試階段，發現系統存在較為低級的穩定性缺陷，則對響應負責人扣除部分考核績效等。系統穩定性經過驗收上線，很好的滿足了業務的需求，則增加相應績效。 故障管理機制。故障管理機制包括規范管理故障響應流程、故障升級機制、故障復盤機制，規范技術人員在應對突發故障時的操作流程，明確職責邊界，提升溝通效率，推動故障閉環，提升故障處理效率。 2.建設組織保障能力 企業在應對重點項目的穩定性建設時， 會從各方面給予保障支持，包括但不限于以下三個方面。 人力支持，從各領域抽調專家進行專項支持，并在人力緊張時，立項招聘相應人員進行支持。 資源支持，提供充足的技術資源支持，如

96、：長期 1 比 1 測試環境部署等。 組織優化，穩定性保障涉及多個團隊，容易產生責任劃分不清的問題，合理的做法是引入橫跨業務線的穩定性團隊來干預，調動全公司資源（包括但不限于技術、法務、合規）推動穩定性技術升級。 3.建設穩定性保障體系 分布式系統穩定性建設指南（2022 年） 51 參考中國信通院提出的“穩保計劃”，在穩定性工程建設前期、中期、后期等不同階段設置穩定性體檢工程、穩定性測試、系統穩定性度量評估環節，全方位推進企業系統穩定性能力建設。 來源：中國信息通信研究院 圖 4 中國信通院“穩保計劃” 穩定性項目實施前，開展 “穩定性體檢工程”，對參與體檢的系統進行“望聞問切”，對即將開展

97、穩定性建設的系統進行“望聞問切” ， 勘測當前系統穩定性水位， 結合度量結果給出穩定性建設路徑，企業可依據體檢結果以及需求/預算/時間等制定建設方案，有針對性的提升系統穩定性。 分布式系統穩定性建設指南（2022 年） 52 來源：中國信息通信研究院 圖 5 項目開展前穩定性體檢視圖 穩定性項目實施中期， 依據 混沌工程平臺能力分級要求 、 可觀測性平臺能力分級要求 、 全鏈路壓測平臺能力分級要求 、 應用多活平臺能力分級要求等標準開展能力建設與演練測試工作，根據測試情況校準建設路徑。并通過參與行業穩定性領域專家組成的“穩定性測試組”討論制定的云服務與系統穩定性測試方案，對被測系統開展多場景穩

98、定性測試， 測試結果校準建設方向、 評估行業水平，獲取相關證書以自證穩定性能力。 穩定性能力建設提供方可參考附錄1 中的“穩定性能力守護者列表”。 分布式系統穩定性建設指南（2022 年） 53 來源：中國信息通信研究院 圖 6 項目開展中穩定性測試視圖 穩定性項目實施后，可以依據“系統穩定性成熟度定位方法”、“系統穩定性度量方法” 等開展系統穩定性度量與能力建設的驗收工作。通過量化建設成效，驗收穩定性建設成果、校驗系統穩定性建設成效；同時在成熟度定位方面，為企業進行系統穩定性成熟度定位，如：從工程熟練度、應用成效度和組織建設度三個維度評價混沌工程能力建設后的成熟度水平。 來源：中國信息通信研

99、究院 圖 7 分布式系統穩定性度量模型 分布式系統穩定性建設指南（2022 年） 54 來源：中國信息通信研究院 圖 8 混沌工程成熟度模型 （四）穩定性建設工具（四）穩定性建設工具 穩定性保障能力建設是項體系化工程， 本文嘗試結合系統穩定性面臨的風險形勢進行分解， 試圖從全局視角回答各項關鍵能力對保證穩定性的技術邏輯。如下圖所示： 分布式系統穩定性建設指南（2022 年） 55 來源：中國信息通信研究院 圖 9 分布式系統穩定性建設工具關系圖 可見這是一項非常龐大而復雜的工程， 體系的落地非一朝一夕可完成。故障總會發生，當然也“沒有任何一項技術或者平臺能夠絕對規避風險”，需要通過不斷補全完善

100、體系中需要的能力來最大限度降低故障發生概率，或者提升故障應對速度。 對于穩定性保障從業者而言， 建議結合業務發展不同階段所面臨的關鍵風險形勢進行規劃，擬定合適的建設優先級及實施路徑。 1.穩定性綜合管理 微服務化日甚的當下，故障影響往往是復雜多樣的(單一節點故障可能導致全線業務出錯)，往往需要多個技術團隊的協同保障系統穩定。需要統一的系統化統一的系統化穩定性穩定性管理能力管理能力作為“連接器”實現多團隊協同“透明化”作戰，并進一步通過故障應急過程及結果數據復盤，分布式系統穩定性建設指南（2022 年） 56 “數據化”風險趨勢以確定建設重點，“標準化”故障管理流程以提升故障管理效率，定義業務或

101、服務的 SLO（Service Level Objective，服務等級目標）以“結構化”組織穩定性保障能力。圖 10 示意了穩定性管理能力建設思路。 來源：中國信息通信研究院 圖 10 穩定性管理建設架構 a. 標準化： 原則、 流程及基本定義標準化， 形成一致認知的標準，統一管理。 b. 透明化：處理過程信息透明即使傳遞，避免故障態勢由于信息不透明導致錯誤應急實施反而引發次生故障； 并且結合詳盡的過程及結果數據，也能夠為事后準確復盤、追溯、跟蹤等提供更為豐富的信息。 c. 結構化：結構化尤為重要，結構化沉淀的業務樹、指標、SLO等能夠通過真實故障不斷錘煉優化、并且也能夠持續沉淀，會分布式系

102、統穩定性建設指南（2022 年） 57 為后續能力演進打好非常好的基礎，如結構化 SLO 對 AIOps（Artificial Intelligence for IT Operations，智能運維） 演進意義明顯。 d. 數據化：可以將“預警響應耗時”、“故障恢復耗時”做為引領性指標， 結合真實故障、 預警時間建立指標數據化運營能力，驅動各業務技術團隊建設其架構自治的故障容忍、 應急響應能力。 2.故障預防工具 （1） 可觀測能力 建設可觀測能力的目的是觀測業務系統運行情況， 并盡早發現故障，定位、分析故障。其中涉及三方面能力：系統運行情況采集、故障發現、以及故障輔助定位分析。 分布式系統穩

103、定性建設指南（2022 年） 58 來源：中國信息通信研究院 圖 11 可觀測能力框架圖 系統運行情況采集。主要通過完善監控覆蓋率來達成，包含以下幾個方面： a. 數據完備程度 可觀測性數據形式上可分為三大類，日志、監控指標、分布式追蹤。 內容上分為系統數據和業務數據， 系統數據包括 CPU/內存負載、磁盤 I/O、 網絡等， 業務指標包括業務成功率、 響應時間、 吞吐量等。除直接采集之外，也應該允許用戶自定義數據采集，或由協議拓展收集數據。 b. 采集范圍廣泛 分布式系統穩定性建設指南（2022 年） 59 采集范圍與具體業務形態息息相關， 邏輯上可以從技術層面和業務層面來拆解。技術層面覆蓋

104、全局、園區、應用、集群、服務、節點各場景；業務層面覆蓋各個產品場景，如網頁端、客戶端、移動端應用、小程序等。 故障發現主要通過提升監控告警時效來達成。 在系統運行情況采集完整的基礎上，對可觀測性數據進行監控。根據用戶輸入的規則，及時發現異常數據，并產生告警。同時也可通過對業務重要性分級，提升重要業務告警優先級，如：重要業務 N 分鐘告警；非重要業務M 分鐘告警。 故障輔助定位分析。 主要通過完善單節點和全鏈路的故障定位能力來實現。單節點的定位能力，包括 SLO、錯誤碼、熱點、內部資源等；全鏈路的點位能力，包括定位到問題節點、定位到節點根因。 （2） 變更管理 對于大多數的變更類故障來說， 恢復

105、業務第一要素就是定位到準確的變更并執行回滾。但在分布式架構下，變更源極度分散、變更信息可能也沒有形成統一的標準化結構， 一方面導致無法以一種架構化平臺化能力統一管控全局變更的穩定性能力， 另外一方面由于缺少平臺化的約束在應急態時變更信息檢索效率低下， 還有可能定位到風險變更而缺少回滾能力的設置導致故障無法被快速消除。因此，建議可以形成：變更信息標準化、變更中樞統一、變更風控三層能力。圖12 示意了變更管理能力建設思路。 分布式系統穩定性建設指南（2022 年） 60 來源：中國信息通信研究院 圖 12 變更管理能力建設框架圖 （3） 容量管理 容量管理的目的是在恰當的時間以一種經濟節約的方式為

106、數據處理、存儲和計算提供所需的容量。構建基于分布式云原生系統的智能容量平臺，主要涉及 3 大類能力：容容量需求管理，容量供給管控，容量調度管理。 容量需求管控：主要分為資源運營和容量運維能力。資源運營能力包含預算，額度，庫存，計劃，規劃等功能，容量運維能力包含日常運維，臨時使用，活動容量，緊急容量等運維能力。 容量調度管理：主要包含容量決策，容量畫像，資源核算，性能回歸，容量彈性，容量風險管理能力，其中容量決策能力包含對應用容量進行分級（成本、穩定性、標準）和容量運維監控，基于分級進分布式系統穩定性建設指南（2022 年） 61 行的統一決策能力。容量畫像包含周期性，流量預測，流量突增，容量多

107、指標彈性和大數據中臺和算法實驗室。資源核算：包含對應用進行計量和計價賬單，驅動應用在穩定性和成本實現最佳平衡。性能回歸能力包含制定定期壓測和性能環境環境。 容量彈性包含水平彈性伸縮， 垂直彈性伸縮， 對應用涉及到的運維參數進行調節 （包含線程池，JVM 參數）。容量風險能力包含限流，自適應限流，流量調度，預案，隔離。 容量供給管控， 主要能力是基于資源調度分級， 實現在線和混部，對應急資源，云資源進行多重 SLO 和優先級保障。 來源：公開資料整理 圖 13 容量管理能力建設框架圖 分布式系統穩定性建設指南（2022 年） 62 （4） 全鏈路壓測 隨著壓測技術和手段的不斷發展，從最初的線下單

108、系統、單模塊以及短鏈路壓測， 逐步向生產有限條件下壓測、 生產全鏈路壓測演進。2014 年初，生產全鏈路壓測的方法開始誕生，其目標是希望在大型促銷活動來臨前， 可以在生產環境上模擬路演進行驗證整體容量和穩定性。由此，出現了全鏈路壓測方法所涉及的公網多地域流量模擬、全鏈路流量染色、全鏈路數據隔離、全鏈路日志隔離、全鏈路風險熔斷等關鍵技術。通過全國各地 CDN 節點模擬向生產系統施加壓力，通過染色與隔離手段防止壓測流量對真實業務產生影響， 并在壓測過程中對生產系統健康度進行實時監控， 快速識別壓測對生產業務帶來的風險，立即作出流量調節或熔斷決策。壓測結束后，根據壓測報告執行精準的容量規劃，保障分布

109、式系統穩定性。 全鏈路壓測常見誤區： a. “有了生產全鏈路壓測就不需要做線下壓測?！毙阅軠y試的階段越早， 成本與風險越低。 線下壓測是無風險發現程序級問題，線上壓測是低風險實現線下補足和評估生產的容量。 b. “有了生產全鏈路壓測技術，就可以在生產隨意實施壓測?！鄙a壓測需要充分考慮連帶影響， 除了防范對業務數據本身的污染風險外，還需考慮對監控、數據分析等下游環節的影響。同時生產壓測本身是高風險的行為， 所以壓測前中后的生產穩定性風險防控能力也至關重要。 全鏈路性能測試解決了單點性能測試無法從業務的全生命周期分布式系統穩定性建設指南（2022 年） 63 來觀測被測系統是否能夠滿足業務在實際

110、生產中的性能需求的能力。只有被測系統滿足了全鏈路性能測試指標， 才能說明系統在線上未發生故障的情況下，有能力進入穩定狀態，是系統穩定性的基本要求。 來源：中國信息通信研究院 圖 14 全鏈路壓測能力框架圖 全鏈路性能測試能力的構建，主要由以下幾部分構成： a. 資源管理能力，對測試環境資源、測試資源（壓力機）等資源進行管理，實現資源的動態管理和充分利用。 b. 數據收集能力，全鏈路測試過程中，需要對相應的測試數據進行收集，如測試環境數據、業務數據等。 c. 流量發起能力，即從全鏈路測試環境的起始端，模擬真實用戶發起業務流量，常見的流量發起能力如下： 分布式系統穩定性建設指南（2022 年） 6

111、4 壓測工具，通過腳本模擬業務流量，如：JMeter、LoadRunner等。 流量回放，復制線上的流量數據打入到測試環境中，從而答達到回放效果。 d. 數據分析能力，通過對收集后的數據進行分析，可以得出與測試指標相對應的數據，從而判斷測試結果是否滿足指標。 e. 結果管理能力，對壓測結果覆蓋的測試報告、測試方案、測試腳本、測試系統信息等內容進行管理，便測試例復用和測試數據分析等工作。 f. 若需在生產環境中進行壓測，則需要被測系統做出相應改造，以規避壓測帶來的風險。改造內容包含上文提到的流量染色、數據隔離、限流保護等。 （5） 混沌工程 混沌工程概念最早由 Netflix 提出，是一種提高技

112、術架構彈性能力的復雜技術手段，在穩定性驗證方面起到至關重要的作用。通過開展混沌工程實驗， 模擬隨機的基礎設施層、 業務層等各個層面的故障，聯合觀測系統表現來驗證分布式系統的穩定性和可靠性， 盡早發現系統潛在的問題，為提高分布式系統穩定性提供參考和建議。 開展混沌工程實驗可分為以下步驟： 選定假設設計故障實驗： 在用戶系統中模擬故障效果的發生從而進行穩定性實驗的設計過程， 對一次完整的實驗過程進行的詳細流程描述，比如：何時開始實驗、發生哪些故障、故障間的先后次序、故分布式系統穩定性建設指南（2022 年） 65 障效果的具體表現、故障持續時長、發生頻率等。 自動化編排與執行實驗：在系統中構建自動

113、化的編排和分析，包括故障注入與故障釋放。 故障注入是在用戶系統中開始進行故障效果模擬的動作實施。故障釋放與“故障注入”相對應，在系統中停止模擬故障發生的動作實施，可根據需要隨時終止實驗。 故障爆炸半徑控制：精準控制故障模擬時的影響范圍（故障爆炸半徑），以降低混沌實驗的風險，避免對生產環境造成較大程度的影響和損害。 實驗觀測：實驗過程中實時觀測業務穩態指標表現，包括基礎監控指標和業務層特性指標等，據此度量混沌實驗的效果。 分析實驗結果：對整個混沌工程的全流程進行復盤分析，總結實驗結果，進而優化系統穩定性建設。 來源：中國信息通信研究院 圖 15 混沌工程平臺能力建設框架圖 在上述混沌工程基礎能力

114、之上， 為了讓混沌工程在分布式穩定性分布式系統穩定性建設指南（2022 年） 66 保障能力方面充分賦能，還需要在面向軟件完整生命周期、面向智能化、面向度量和運營能力體系建設三個方面進一步加強?；诨煦绻こ虨闃I務基礎架構管控、 基礎設施技術風險和業務技術風險治理提供了強有力技術支撐，促進穩定性保障能力體系建設。 面向軟件完整生命周期：混沌工程可面向軟件完整生命周期，即開發、測試、發布、運行各階段，發揮質量守護作用。 來源：公開資料整理 圖 16 混沌工程與軟件完整生命周期對應圖 面向智能化：智能化是混沌工程發展方向和核心主題，通過智能化和自動化技術不斷提高混沌工程效率，降低學習成本。例如，通過

115、AI 技術實現穩態自動化對照分析（系統基礎指標、業務指標、監控指標、采樣指標等），可以有效提升混沌工程架構感知、智能演練場景推薦、根因分析、安全防護等方面的智能水平。 面向度量與運營能力體系建設：結合 DevOps 體系進行常態化持續集成演練，實現自動風險挖掘和度量，揭示研發質量、資金安全風險、高可用能力、監控預警、應急預案等風險水位，有效促進系統穩定性保障能力系統建設。 3.故障止損工具 （1） 應急平臺 應急平臺的建設主要考慮以下方面： 分布式系統穩定性建設指南（2022 年） 67 應用設計：應用系統本身必須是可應急的，對于所依賴的下游服務、 存儲， 應具備災備切換或功能降級的能力。 對

116、于每一個功能模塊，應設計動態開關。在緊急情況下，可以動態關閉部分功能模塊，容忍部分業務平滑降級的情況下保證整體服務基本可用。 應急預案：建立應急平臺，應急預案、應急開關系統化、集中化管理，專人負責。 定期演練： 所有應急預案應定期演練保鮮， 無損預案可以高頻次、常態化演練；有損預案在可控條件下謹慎演練，如夜間業務低峰期。 應急度量：預案效果需要有可量化的度量指標，如應急效果、時長等，方便在復盤階段提供有效抓手，持續優化預案。 從手動應急到自動應急：前期以人工盯屏監控、人工決策、人工執行；后期部分成熟固化的場景，可以結合監控數據做自動決策、自動執行，實現故障快速自愈。 來源：公開資料整理 圖 1

117、7 應急平臺能力框架圖 （2） 容災管理 分布式系統穩定性建設指南（2022 年） 68 分布式系統的擴展伸縮架構能力天然為災難逃逸提供了前置條件，多數企業也會建立多機房冗余的災難逃逸能力，并且也會通過周期性的容災演練驗證保鮮。由于缺少平臺化的約束及保障機制，通常一些無意識的配置、依賴、部署架構等變化會影響已有的容災設計導致整體容災能力的衰退，在此情況下，形成統一的容災管理平臺化能力就顯得意義非凡。我們建議在企業發展的合適階段，可以逐步建立起平臺化的容災管理能力，驅動逐步實現：IDC、網絡、服務多級災難逃逸能力，以達到更從容的災難應對能力。 容災管理主要分位容災揭示、容災管控兩部分，其中巡檢中

118、心和流控中心作為容災揭示和容災管控的基礎工具依賴。 容災揭示：主要從機房、業務、服務、存儲 4 個層面進行度量，通過一系列的健康巡檢給出預示和告警。 容災管控： 容災的主要手段是進行流量調度， 確保業務的連續性，為了支撐管控會進行相關的參數管理、方案及策略管理。其決策手段可以根據方案的成熟度進行輔助決策或自動決策。同時，為了確保管控方案的可行性，需要定期進行容災演練的管理。圖 18 示意了容災管理能力建設思路。 分布式系統穩定性建設指南（2022 年） 69 來源：公開資料整理 圖 18 容災管理能力建設框架圖 應用多活作為容災技術的一種高級形態， 通過在同城或異地機房建立一套與本地生產系統部

119、分或全部對應的生產系統， 所有機房內的應用同時對外提供服務。當災難發生時，多活系統可在分鐘級內實現業務流量切換。應用多活架構主要由以下幾方面能力構成： 管控層：是多活的管理控制層，通過多活控制臺、應用接入配置管理、日常演練、多活切換、管控高可用等關鍵動作，實現對應用多活的管理控制，保障多活管理的高效性和高可靠。 接入層： 是業務多活的核心入口， 是整個多活業務開放的匯聚點，具備對流量接入的統一管理能力，包括流量保護、流量糾錯、策略路由等。 應用層：是業務應用流量主經的鏈路，涵蓋應用多活的端到端生命周期管理，包含應用架構設計、消息中間件、微服務中間件等。 分布式系統穩定性建設指南（2022 年）

120、 70 數據層：是對整個系統中數據存儲相關組件的規范和設計約束，確保整個系統數據層的可靠性、 可用性和數據持久化程度滿足多活要求。包括業務應用數據讀寫、數據存儲、數據同步等關鍵動作。 基礎設施層：是基于計算，存儲，網絡等層面的基礎設施多活能力建設，確保應用多活底座高可用。 來源：中國信息通信研究院 圖 19 應用多活能力框架圖 分布式系統穩定性建設指南（2022 年） 71 六、分布式系統穩定性建設行業特點 本章關注不同行業在推進分布式穩定性建設過程中的特點， 主要從行業特點、穩定性挑戰以及解決方法三方面展開介紹，以期為不同行業的分布式系統穩定性能力建設提供有價值的參考。 （一）互聯網業（一）

121、互聯網業 1.互聯網行業特點及技術挑戰 互聯網行業在龐大的線上業務規模下海量的并發請求、 敏捷的運營訴求驅動著應用從單體服務向微服務、分布式系統演進。受益于云原生的 DevOps、Kubernetes、微服務、服務網格等技術紅利，應用的上線下線、發布變更、容量管理、服務治理等運營效率獲得了極大提升。運營效率和用戶價值的交付效率得到提升的同時，復雜架構下為系統穩定性保障也帶來了新的挑戰，主要表現為以下方面： 微服務間調用關系錯綜復雜，給服務性能瓶頸分析、快速定位影響評估范圍和根因分析等方面帶來了諸多的挑戰。云原生一線開發/運維人員時常會面臨“服務調用關系錯綜復雜，如何快速定位問題根因”、“某服務

122、發生異常，如何快速評估影響范圍”以及“如何快速分析復雜系統的服務瓶頸點”等問題。 在復雜的分布式系統中，無法阻止故障的發生，且分布式系統日益龐大，很難評估單個故障對整個系統的影響，如何能在這些異常故障被觸發之前，如何盡可能多地識別風險，在復雜的分布式架構中亦為穩定性保障一大挑戰。 分布式系統穩定性建設指南（2022 年） 72 互聯網業務服務具備活動發布節奏快、數量多、訪問量大且無法精準預估以及邏輯復雜、上下游依賴復雜等特點，需要耗費大量人力梳理調用關系和放大倍數， 且容量評估不準確對穩定性保障影響較大。 2.互聯網行業系統穩定性解決方案 面臨以上挑戰，為了保障分布式系統下的服務穩定性，可以從

123、以下方面入手： 架構設計方面， 我們認為所有的架構都是不完美的， 都存在缺陷，因此我們在做業務架構設計時都必須要考慮服務穩定性保障， 如負載均衡、多點容災、集群化服務、數據多活等能力。 從組織架構和人員構成上設立 SRE（Site Reliability Engineering,穩定性工程）團隊和 SRE（Site Reliability Engineer,穩定性工程師）角色。且按照 SRE 前置原則，SRE 角色需要提前介入，將運營階段可能出現的問題或風險提前在架構設計、編碼階段暴露，提前準備好解決方案，甚至規避問題與風險。 建設可觀測性能力，即通過采集業務指標、日志、追蹤等數據，構建監控告

124、警能力，并且在“事中”環節用于快速分析與定位問題，同時發現復雜系統的瓶頸點。 建設混沌實驗平臺， 通過模擬現網真實故障來驗證服務的“韌性”，讓故障在測試或預發布環境提前到來，找出系統的弱點，同時驗證系統監控告警的有效性。 分布式系統穩定性建設指南（2022 年） 73 建設全鏈路壓測能力，通過與可觀測性、混沌實驗能力的深度整合，實現模擬真實業務環境全鏈路壓測，達到業務上線前的精準資源評估，主動發現潛在性能、版本缺陷等問題。 建立故障應急機制,故障不可避免，技術人員需要不斷去提升MTBF（Mean Time Between Failure，平均故障間隔） ，降低 MTTR（Mean Time T

125、o Repair，故障平均修復時間） ，包括“事前”實施大量混沌實驗、故障預案、建立“On-Call”機制，“事中”采用打造的工具鏈，快速發現、分析、定位與解決問題以及“事后”組織總結復盤，沉淀案例經驗等措施。 建設 AIOps 能力，隨著整個互聯網業務急劇膨脹，以及服務類型的復雜多樣，“基于人為指定規則”的專家系統逐漸變得力不從心。建設 AIOps 能力，可以基于采集到日志、監控信息、鏈路、指標等數據，通過機器學習的方式來進一步提升異常檢測、根因分析、故障診斷、故障預測、故障自愈等運維能力。 （二）銀行業（二）銀行業 1.銀行業特點及技術挑戰 銀行業的 IT 系統，一旦出現穩定性問題，不單要

126、面對自身的業務損失，還要面對國家相關部門的監管。銀行業與傳統行業相比，在關鍵業務場景的核心訴求具有兩個鮮明的業務特性： 保證賬務一致性要求， 在各種復雜的金融業務場景下保證客戶資金和銀行資金準確無誤； 海量高并發的交易處理要求，達到每秒鐘萬筆以上，因此對分布分布式系統穩定性建設指南（2022 年） 74 式數據庫的要求更為嚴格，特別是在高并發、實時性和最終一致性方面。 長期以來，以 IBM 主機為代表的傳統集中式架構具有高可靠主機操作系統、 成熟的主機中間件業務軟件和強大的配套數據庫軟件等特征。隨著分布式轉型的變革，如何在基于 X86 平臺的分布式體系下，既能滿足各行業業務線上化、多樣化、高增

127、長，又能保持主機同等的穩定性,成為一個亟待解決的難題。 2.銀行業系統穩定性解決方案 針對以上銀行業業務特點、 當前分布式系統技術現狀及穩定性挑戰，可以通過以下幾個技術點推動銀行 IT 系統穩定性提升。 兩地三中心實現雙活數據中心。 針對可用性和穩定性要求高的系統，可建設兩個或者多個數據中心，主數據中心承擔用戶核心業務，其他數據中心承擔非核心業務并備份主數據中心的數據和配置。 主數據中心整體發生災難時，備份數據中心可以快速恢復數據和應用，減輕災難給用戶和企業帶來的損失。 多層級的故障保護機制提供可靠的基礎設施架構。 開放平臺硬件存在一定的故障率是客觀事實， 基于云計算技術架構來降低故障影響是切

128、實可行的途徑。通過云管平臺、資源調度平臺的兩級調度策略，確保同一業務的不同實例均衡分發到多地多中心的不同故障域， 確保單個節點、單個集群甚至單個數據中心發生故障時，不會影響到整體業務的可用性。 云平臺故障自愈提升業務連續性。 容器化部署的應用具備快速啟分布式系統穩定性建設指南（2022 年） 75 動和銷毀的特點， 結合 Kubernetes 的健康檢查機制，可以實現多層次的故障自愈能力。 業務可感知的優雅啟停機制實現無損升級。 借助分布式平臺提供的精細化、業務可感知的優雅啟停策略，支持研發人員對系統預熱進度的自動化探測和狀態自適應改變， 解決規?；渴鸷髽I務系統升級出現的交易波動和交易瞬時問

129、題，提高系統的業務連續性。 （三）證券業（三）證券業 1.證券業特點及技術挑戰 證券行業的高并發業務特點集中在開市的四個小時內， 業務停滯的每一秒都可能帶來巨大損失，因此其對于業務連續性的訴求極高。 隨著近十年的市場發展， 整個市場交易量也由千億級發展到萬億級，原來傳統的集中式交易系統的弊端愈發突出，IT 架構向分布式轉型成為必然趨勢，分布式架構擁有的高可用、低延時、高并發、靈活擴展的相比集中式交易系統的優勢明顯。 分布式架構提升了系統的業務承載能力，但同時也讓整個系統變得更加復雜，運維的難度在隨之提升。運維的過程難點主要體現在以下方面： 市場業務波動的不確定性， 交易業務量的激增的隨機性相比

130、一些其他行業高，政治、經濟、行業、公司等因素都能影響市場，而不像微信春節紅包、雙 11 等具有明顯周期特征； 業務系統繁雜，在微服務的改造過程中會長期保持著老系統，導致新老系統相互交織耦合； 故障預防難， 靠傳統的測試方法很難有效保障整個系統的穩定性； 分布式系統穩定性建設指南（2022 年） 76 故障定位難，系統的分散、數據分散、業務鏈路長等問題導致故障分析定位難。 2.證券業系統穩定性解決方案 證券行業大部分核心業務主要集中在 9:30-11:30，13:00-15:00 這4 小時，有一定時間窗口對系統進行升級維護，使得行業在生產環境對系統進行穩定性評估提供一個低成本、高回報的良好基礎

131、。某證券公司圍繞“以業務連續性為宗旨”，從“事前”、 “事中”、 “事后”的三個維度進行了豐富的探索實踐。 首先， “事前”傳統的單系統性能容量評估發展為全鏈路業務性能容量評估，從模擬環境到生產等比例環境的容量評估；其次，“事中”將業務鏈路上的監控“孤島”進行統一整合，從基礎架構監控、網絡性能監控、應用性能監控三個維度構建統一監控平臺；“事后”的應急處置的自動化率、智能化率的提升。 發展至今天， 行業部分頭部券商已引入混沌工程實驗對系統穩定性保障手段進行更深層次的強化提升，有效的助力了“事前”、“事中”、“事后”的建設成果。 （四）通信業（四）通信業 1.通信業特點及技術挑戰 通信行業主要包括

132、設備商和運營商， 運營商在整個產業鏈條中占據核心地位。 傳統運營商更多的是承擔 “管道” 的角色， 即提供網絡、基站等基礎設施，管道中的內容和服務鮮有涉獵。隨著移動互聯網和云計算的發展，管道價值不斷下降，各大運營商紛紛探索轉型之路。 分布式系統穩定性建設指南（2022 年） 77 經過多年發展， 運營商有了足夠多的用戶信息、 終端信息等數據，也有一定數量級的傳統 IT 系統， 這些在轉型期既是優勢， 也是壓力。運營商的業務覆蓋面廣，幾乎貫穿于每個人的日常生活中，一旦出現問題，對用戶體驗和品牌形象都將造成重大損失，系統的穩定性保障面臨巨大挑戰。 新舊系統的共存和過渡。云計算帶來更大的數據處理能力

133、，但是從傳統系統遷移至云不是一簇而就的， 相當長時間內會存在多種系統的共存，如何做好數據一致性、系統平滑割接是重要命題。 和互聯網公司越來越接近的軟件產品。 以基站為代表的網絡設施肯定還是運營商的基礎，但是隨著運營商數智化轉型的進程，各種軟件產品也被不斷推出，云計算、分布式等各種新技術也被廣泛應用；如何把穩定性保障嵌入到軟件生命周期的各個環節， 新技術的人才和資源投入也是需要考慮的問題。 子公司/子系統分散。運營商一般包括數十個省公司和若干子公司，也就對應著很多子系統、很多穩定性保障方案和工具，存在一定程度的資源浪費，如果把各方面的能力整合起來，做到策略、方案、工具一致，不僅節約資源，也能更好

134、的保障系統穩定性，但是實施起來有相當難度。 2.通信業系統穩定性解決方案 針對以上特點或痛點， 運營商轉型期保障系統穩定性的方法如下： 有序推進各子系統遷移至云，充分測試后適時割接，保證用戶無感知； 分布式系統穩定性建設指南（2022 年） 78 實施混沌工程，混沌工程適用于大規模的隨機故障，非常匹配運營商系統規模宏大、架構復雜的特點； 把穩定性保障嵌入到軟件產品的整個生命周期，從設計到開發、測試、上線和監控，都匹配合適的穩定性保障手段。 （五）云服務業（五）云服務業 1.云服務業特點及技術挑戰 云計算系統作為現代復雜的分布式系統的典型代表之一， 其穩定性表現至關重要。相比較其他行業系統，云計

135、算系統穩定性的特征體現在以下方面。 客戶業務、技術形態多元。云計算系統對人工智能、大數據、區塊鏈等創新技術的不斷整合，服務各行業細分領域形成的多元形態，滿足企業混合云/分布式云訴求的架構更新，為實現穩定性設計增加復雜度。 云服務提供商將穩定性建設貫穿于云平臺初始規劃、 設計實現和運維管理的方方面面。對于云計算系統來說，存在多種影響穩定性的因素，主要歸納為硬件故障、軟件異常和人為操作等類型。作為云計算系統的設計建設者，云服務提供商運用測試、代碼審查和語法掃描等軟件工程技術，結合聲明式設計、分布式追蹤和混沌工程等云原生實踐，同時規范生產環境的變更操作制度和過程，保障云計算系統的運行穩定。 2.云服

136、務業穩定性解決方案 實現云計算系統穩定性的途徑主要包括： 分布式系統穩定性建設指南（2022 年） 79 容量計劃。 云計算系統的容量計劃建立在資產管理和配置管理的基礎上，為云計算系統運行環境提供云資源在數量、規格和位置等方面的規劃和跟蹤。實現容量計劃的過程包括建立資源模型、監控分析資源使用、調優資源交付和持續跟蹤資源水位等步驟。 穩定性設計。 運用云原生技術和實踐強化云計算系統的穩定性設計。針對云計算系統，使用分布式追蹤技術洞察系統 API 調用情況，進行事務監控和服務依賴分析，輔助故障根因定位；實施混沌工程，檢驗系統面對各種錯誤的反應， 建立系統承受生產環境業務壓力的信心。 過程保障。制定

137、云計算系統的版本發布和線上變更規范，建立生產環境運維流程制度，控制人為誤操作對系統造成的影響范圍。 （六）零售（六）零售業業 1.零售業特點及技術挑戰 零售行業業務特點在于線上服務和線下服務同時進行， 互相依賴，系統高可用尤為重要，當系統產生異常，線上用戶無法進行下單，線下服務的門店無法給用戶進行結賬， 會對用戶體驗帶來巨大且無法挽回的影響。 零售行業系統迭代速度快，系統每周上線進行更新，系統穩定性保障非常重要，各個系統的保障措施、應急方案、回滾方案必須做到非常完善，同時有相應的團隊進行技術保障支持，確保系統線上運行穩定。 近年來傳統電商行業進行的大促培養了固定的大促模式和用戶分布式系統穩定性

138、建設指南（2022 年） 80 群體，大促日期也相對固定，比如 618、11.11、12.12 等，用戶群體更偏向于年輕群體， 零售行業區別于傳統電商行業， 大促時間在618、11.11、12.12 的基礎上，同時包括了中國傳統的節假日，業務峰值周末峰值高于平時峰值，這點區別于傳統電商行業，用戶群體分布在各個年齡段，線下門店的系統更要做到好用、便捷，給百姓帶來良好的購物體驗。 2.零售業系統穩定性解決方案 零售行業系統穩定保障一般從如下入手： 系統鏈路的梳理，分析薄弱點和瓶頸點，制定相應的應急預案，做到對系統了如指掌，應急方案做到有效、高效，而不是紙上談兵； 系統監控全面且可視化，包括應用監控

139、、基礎中間件監控、業務監控等，同時能夠明確高效通知系統負責人，監控報警做到聚合，防止報警轟炸； 系統高可用，具備容災、異地多活能力，機房間切換無感知，對用戶正常訪問的影響降到最低； 系統穩定性建設，依賴服務的降級方案制定，核心業務和非核心業務解耦，數據讀寫分離，系統間調用閾值制定，系統自愈、熔斷降級方案制定，數據慢查詢治理； 故障演練， 制定故障演練方案和編排演練場景， 模擬應用、 網絡、依賴服務、硬件、中間件、數據庫等故障，考核系統健壯性以及故障恢復時間，同時評估應急方案有效性； 全鏈路壓測，通過對核心系統（首頁、商詳頁、推薦搜索、購物分布式系統穩定性建設指南（2022 年） 81 車、結算

140、頁、訂單、物流履約等）進行性能評估，考核系統可靠性以及最大處理能力，確保大促過程中系統穩定，能夠應對突發流量對系統帶來的沖擊。 （七）能源業（七）能源業 1.能源業特點及技術挑戰 能源企業數字化系統對安全穩定運行具有很高的要求， 根據數字化應用不同的等級，呈現出不同的要求。其中，生產控制類系統系統安全穩定運行要求最高，且受國家能源局監督，系統不穩定事件會影響能源供應的安全，更會影響到國民生計及社會秩序，穩定性要求最高。 其次， 是面向企業客戶類系統， 如電費繳納， 用戶報裝及遷改等，系統不穩定不僅影響公司營業收入，也可能引發社會輿論影響，對穩定性要求較高。 2.能源業系統穩定性解決方案 近年來

141、能源企業深度應用云計算新技術，遵循全生命周期管控，全技術棧支持，全方位運行保障的原則，保障業務應用的連續可靠運行。 全生命周期管控方面， 制定了云上應用系統高可靠性相關配置要求，指引應用系統規范上云，在應用系統可研階段、需求設計開發測試、 部署實施等各階段進行技術管控， 保證可靠性各項要求切實落地。 在全技術棧支持方面，基礎設施層實現資源冗余，平臺軟件與應用技術互相配合，達到故障隔離與故障自愈的目標，在應用頂層架構方面采用同城雙活、應用級災備和數據級災備支持跨域切換，保證系分布式系統穩定性建設指南（2022 年） 82 統可以持續提供服務。 在全方位運行保障方面， 實現運行保障與應急演練互相促

142、進的方式，通過實戰演練，把系統“薄弱”環節納入檢查因子，通過實際注入故障等方式，做到提前發現問題，提前解決問題，提前檢驗應急保障的實戰能力。行業部分典型企業通過引入混沌工程，優化全生命周期管控，全技術棧支持和全方位運行保障的效率，提升能源企業數字化應用的建設成效。 分布式系統穩定性建設指南（2022 年） 83 七、分布式系統穩定性建設展望 （一）人才、生態、標準亟待關注，多重措施提升穩定（一）人才、生態、標準亟待關注，多重措施提升穩定性發展水平性發展水平 1.專業化人才稀缺，急需拓寬技術交流平臺 保障企業 IT 系統穩定高效地持續運行涉及的技術面廣、 難度大，是一項技術門檻較高的工作， 很多

143、企業缺乏相關專業技術人才及技術積累，市場急需專業技術人才，當前需要更多地借助供應商的知識、技術、人力來完成相應能力建設，國內 IT 系統穩定性保障服務領域蘊藏巨大商機。目前系統穩定性保障賽道足夠寬，整體而言參與者并不多，行業發展尚處于起步階段，頭部廠商技術一枝獨秀，中部廠商能力各有千秋。同時資本市場已經開始關注、布局這個新興賽道的準獨角獸企業。 重視專業技術人才培養，搭建專業技術交流平臺，推動專業人才成長和專業能力沉淀。針對市場專業人才稀缺，行業發展仍處于初級階段的情況，需要培養人才的專業化、專門化、精細化能力，營造良好的技術交流氛圍，提升各供應商能動性與創造性，促進系統穩定性保障行業高速發展

144、。在聚焦能力短板，強化專業人才培養方面，混沌工程實驗室將持續挖掘系統穩定性保障領域技術痛點， 面向預研人員、開發者和實驗室成員不定期推出一系列前沿技術課程。 在拓寬技術交流渠道、為行業中堅技術力量發聲方面，混沌工程實驗室為專業技術人才提供跨企業的溝通渠道，開展面向不同行業、背景人才的專題交流活動。 分布式系統穩定性建設指南（2022 年） 84 2.穩定性生態協同低效，急需賦能產業協同創新 系統穩定性保障熱度攀升，同時系統穩定性領域涉及面廣且深，單個企業難以提供覆蓋市場所有需求的產品， 需要協同行業內多家企業合作，各取所長，促成豐富、完善的穩定性保障生態。目前，由于穩定性保障賽道尚處于起步階段

145、，供應商之間存在爭奪市場資源、規避技術風險等方面的考量，企業各自為營，導致產品趨于同質化，不利于穩定性產業繁榮。推廣生態開放的價值、構建穩定性保障服務矩陣，將有利于產業發展，也是混沌工程實驗室未來的工作方向。 產學研多方共同打造產業開放生態，驅使產業高質量發展，協同推進產業創新升級。面對產業發展待協調，產品同質化嚴重，創新不足的現狀，應聯合產學研多方協同打造開放共享的產業生態，博采眾長，推動系統穩定性保障技術與產品創新，產業共同進步。打造全方位創新資源共享平臺，提供技術咨詢、技術對接、產學研合作渠道等一體化服務，為系統穩定性保障產業的發展提供動能?；煦绻こ虒嶒炇覍⒆鳛槠髽I之間溝通、 交流、 合

146、作的橋梁， 攜手共建 “協同” 平臺、共享“創新”資源、共創“生態”體系、共同“賦能”未來。 3.標準體系研制滯后，規圓矩方行穩致遠 穩定性領域的技術點豐富，相關標準體系在持續完善中，但標準研制進度不及用戶需求的爆發式增長及相關技術/產品的能力迭代。標準的缺乏，致使穩定性相關產品提供方缺乏能力建設指導，產品能力參差不齊；對需求方來講，缺少產品選型原則和依據，提升需求方POC 難度。 分布式系統穩定性建設指南（2022 年） 85 重視行業標準研究、建設工作，圍繞系統穩定性保障相關技術完善標準體系。不斷完善的行業標準體系建設，是促進系統穩定性保障產業高質量發展的強有力支持。 基于現階段系統穩定性

147、保障領域標準體系建設的主要任務和方向， 中國信通院積極發揮標準技術研究優勢，緊隨前沿技術發展趨勢，以滿足產業需求為導向，多次召開標準研討會，針對系統穩定性保障領域的各個專題展開深入討論，并與行業專家深度合作，共同完成系統穩定性保障系列標準的編寫工作。 （二）順應時代發展需求，推動穩定性建設進入新階段（二）順應時代發展需求，推動穩定性建設進入新階段 1.穩定性建設能力發展不均，傳統行業需求蓄勢待發 系統穩定性是企業對外提供服務的基礎， 但穩定性保障技術在不同行業的應用程度不均衡且不充分。以混沌工程為例，互聯網公司中混沌工程的應用已經比較深入，從基礎資源、中間件、微服務擴展到上層故障演練、容災多活

148、、攻防活動等。相對而言，國內相當多的傳統企業還停留在分布式系統改造升級后的基礎資源驗證、 業務場景探索、混沌價值不明階段。而在數字化轉型浪潮下，傳統企業開始邁向數字化與智能化，其穩定性保障和建設需求也隨之高漲，正逐步豐富系統穩定性建設賽道的商機。 2.企業架構阻礙穩定性建設，組織觀念正逐步進化 面對系統分布式化帶來的一系列穩定性問題， 需要組織架構上的配合調整以及思想觀念的變革， 牽動團隊全員共同建設穩定性保障組織。 穩定性保障組織建設主要體現在兩個方面： 一是組建 SRE 團隊，橫跨各業務線調動全公司資源（包括但不限于技術、法務、合規），分布式系統穩定性建設指南（2022 年） 86 確保應

149、對重點項目的穩定性建設時，能從各方面給予保障支持。二是構建 DevOps 流程機制，統一軟件開發（Dev）和軟件運維（Ops），讓運維人員介入到開發過程中， 了解開發人員使用的系統架構和技術路線，從而制定適當的運維方案，同時讓開發人員在運維初期參與到系統部署中，并提供系統部署的優化建議。 3.過度依賴開源致“懶”，倡導創新采納開源技術 國內外有眾多優秀的穩定性領域開源工具供企業、 個人用戶體驗使用，如表 6 所示，企業和個人用戶應擁抱創新開放的開源，推進開源協作模式在行業中的應用，這樣可以避免分散重復開發，賦能中小企業低成本發展，但使用開源框架時，要積極創新、勇于創新，避免“套路化”依賴已有開

150、源工具，強調創新而有效地開源，提高對開源技術的應用水平和自主可控能力。 表 6 中美穩定性工具開源情況 穩定性工具穩定性工具 中國中國 美國美國 混沌工程工具 ChaosBlade ChaosMesh OpenChaos Chaos Toolkit Chaos Monkey AWSSSMChaosRunner Chaos Gamedays 壓測工具 XPocket Vegeta loadUI Apache JMeter Locust 可觀測性工具 Kindling DataKit OpenTracing OpenCensus OpenTelemetry 分布式系統穩定性建設指南（2022 年）

151、 87 Zipkin 來源：公開資料整理 分布式系統穩定性建設指南（2022 年） 88 附錄 1 表 7 穩定性守護者列表1 穩定性能力域 守護者名稱 混沌工程能力 阿里云計算有限公司 華為云計算技術有限公司 中國移動通信集團有限公司信息技術中心 平凱星辰（北京）科技有限公司 南京爭鋒信息科技有限公司 建信金融科技有限責任公司 北京同創永益科技發展有限公司 螞蟻科技集團股份有限公司 杭州笨馬網絡技術有限公司 深圳市騰訊計算機系統有限公司 應用多活能力 阿里云計算有限公司 建信金融科技有限責任公司 全鏈路壓測能力 阿里云計算有限公司 螞蟻科技集團股份有限公司 杭州笨馬網絡技術有限公司 可觀測性

152、能力 阿里云計算有限公司 螞蟻科技集團股份有限公司 上海駐云信息科技有限公司 北京優特捷信息技術有限公司 中電云數智科技有限公司 優維科技（深圳）有限公司 北京基調網絡股份有限公司 來源：中國信息通信研究院 1 截止 2022 年 6 月 分布式系統穩定性建設指南（2022 年） 89 附錄 2 表 8 混沌工程實驗室成員列表2 序號序號 企業名稱企業名稱 類型類型 1 中國信息通信研究院 理事長單位 2 華泰證券股份有限公司 副理事長單位 3 阿里云計算有限公司 副理事長單位 4 中國工商銀行軟件開發中心 副理事長單位 5 天翼云科技有限公司 副理事長單位 6 中國移動通信集團有限公司信息技

153、術中心 副理事長單位 7 北京百度網訊科技有限公司 副理事長單位 8 深圳市騰訊計算機系統有限公司 副理事長單位 9 南京爭鋒信息科技有限公司 副理事長單位 10 華為云計算技術有限公司 副理事長單位 11 平凱星辰（北京）科技有限公司 副理事長單位 12 中國農業銀行信息中心 副理事長單位 13 北京銀行股份有限公司 副理事長單位 14 杭州笨馬網絡技術有限公司 副理事長單位 15 北京同創永益科技發展有限公司 副理事長單位 16 螞蟻科技集團股份有限公司 副理事長單位 17 上海浦東發展銀行股份有限公司 副理事長單位 18 建信金融科技有限責任公司 副理事長單位 19 京東科技信息技術有限

154、公司 副理事長單位 20 中信銀行股份有限公司軟件開發中心 副理事長單位 21 浩鯨云計算科技股份有限公司 理事單位 22 北京火山引擎科技有限公司 理事單位 23 中移（蘇州）軟件技術有限公司 理事單位 24 南方電網數字電網研究院有限公司 理事單位 2 截止 2022 年 6 月 分布式系統穩定性建設指南（2022 年） 90 25 陽光保險集團股份有限公司 理事單位 26 四川省農村信用社聯合社 理事單位 27 中電金信軟件有限公司 理事單位 28 中移（杭州）信息技術有限公司 理事單位 29 北京永輝科技有限公司 理事單位 30 思特沃克軟件技術（北京）有限公司 理事單位 31 中興通

155、訊股份有限公司 理事單位 32 北銀金融科技有限責任公司 理事單位 33 中國光大銀行股份有限公司 理事單位 34 北京必示科技有限公司 理事單位 35 中信建投證券股份有限公司 理事單位 36 中電云數智科技有限公司 理事單位 37 中國科學院計算技術研究所 理事單位 38 招商銀行總行信息技術部 理事單位 39 中關村智聯聯盟 理事單位 40 中原銀行股份有限公司 理事單位 41 上汽通用汽車有限公司 理事單位 42 安信證券股份有限公司 理事單位 43 中泰證券股份有限公司 理事單位 44 上海鈞正網絡科技有限公司（哈啰出行） 理事單位 45 中國銀行股份有限公司 理事單位 46 恒豐銀

156、行股份有限公司 理事單位 47 中科南京信息高鐵研究院 理事單位 48 申萬宏源證券有限公司 成員單位 49 北京水木羽林科技有限公司 成員單位 50 中國聯合網絡通信有限公司軟件研究院 成員單位 51 浙江菜鳥供應鏈管理有限公司 成員單位 52 東方證券股份有限公司 成員單位 分布式系統穩定性建設指南（2022 年） 91 53 太平洋財產保險股份有限公司 成員單位 54 亞信科技(中國）有限公司 成員單位 55 極狐創新（北京）信息技術有限公司 成員單位 56 天翼電子商務有限公司 成員單位 57 浪潮軟件集團有限公司 成員單位 58 中國移動通信集團湖南有限公司 成員單位 59 上海富麥信息科技有限公司 成員單位 60 東軟集團股份有限公司 成員單位 61 恒生電子股份有限公司 成員單位 62 興業數字金融服務有限公司 成員單位 63 上交所技術有限公司 成員單位 64 上海銀行股份有限公司 成員單位 65 釘釘（中國）信息技術有限公司 成員單位 66 中債金科信息技術有限公司 成員單位 67 杭州微智測信息技術服務有限公司 成員單位 68 濟南浪潮數據技術有限公司 成員單位 69 科來網絡技術股份有限公司 成員單位 70 上海有孚網絡股份有限公司 成員單位 71 江蘇蘇寧銀行股份有限公司 成員單位 72 優維科技(深圳)有限公司 成員單位 來源：中國信息通信研究院