中國信通院：證券行業分布式核心系統SRE運維白皮書（2022）（33頁）.pdf

《中國信通院：證券行業分布式核心系統SRE運維白皮書（2022）（33頁）.pdf》由會員分享，可在線閱讀，更多相關《中國信通院：證券行業分布式核心系統SRE運維白皮書（2022）（33頁）.pdf（33頁珍藏版）》請在三個皮匠報告上搜索。

1、證券行業分布式核心系統SRE運維白皮書恒生電子股份有限公司中國信息通信研究院云計算和大數據研究所2022年4月版權聲明本白皮書版權屬于恒生電子和中國信息通信研究院， 并受法律保護。 轉載、 摘編或利用其它方式使用本白皮書文字或者觀點的， 應注明“來源： 恒生電子和中國信息通信研究院” 。 違反上述聲明者， 編者將追究其相關法律責任。由于金融行業擴大開放帶來的競爭環境變化， 以及用戶服務需求不斷提升， 證券機構核心系統技術日新月異， 網絡架構越來越復雜。 證券行業為滿足業務敏捷創新需求， 內部核心系統已從傳統的IT集約型架構開始逐漸向分布式架構轉型，這對企業內部IT運維管理帶來非常大的挑戰。 S

2、RE作為創新型運維方法論， 可為證券行業分布式核心系統運維人員提供一種新的轉型思路。本白皮書重點關注證券行業分布式核心系統SRE運維服務體系及相關服務支撐平臺工具。 首先， 白皮書給出IT運維國內外發展現狀和IT分布式架構運維面臨的問題和痛點。 其次， 梳理了SRE運維模式原則和思路， 并詳細分析了DevOps和SRE運維方式的異同點。 接著， 將SRE運維服務體系從服務度量體系、 觀測指標體系、 流程管理體系、 穩定性運營體系以及組織管理體系五方面分別展開介紹， 并介紹關鍵環節的服務支撐工具和平臺。 最后， 白皮書針對目前SRE發展面臨的問題提出相關建議， 明確了SRE運維發展趨勢， 并對S

3、RE運維方法論應用在證券行業分布式核心系統中給出三種應用模式建議。本白皮書編寫單位為： 恒生電子股份有限公司、 中國信息通信研究院云計算與大數據研究所、 東北證券股份有限公司、 東方證券股份有限公司、 光大證券股份有限公司、 山西證券股份有限公司、 招商證券股份有限公司。前言Foreword一、 我國證券行業分布式系統運維現狀(一) 外力和內需雙向促進證券行業分布式系統運維模式轉型(二) 系統分布式架構給傳統運維帶來挑戰(三) 以主動運維為核心的SRE運維模式興起， 彌補傳統運維模式缺陷二、 分布式核心系統SRE運維模式概述(一)SRE運維模式為證券行業業務系統可用性保駕護航(二)DevOps

4、與SRE異同點對比(三)SRE運維模式需貫徹五個核心原則三、 證券行業分布式核心系統SRE運維服務體系(一) 以用戶體驗為核心的服務質量度量體系(二) 以監控系統為基礎的觀測指標體系(三) 以穩定可靠為保障的流程管理體系(四) 以服務治理為目的的穩定性運營體系(五) 以持續改進為標準的組織管理體系目錄Contents12314820456810121418四、 證券行業分布式核心系統SRE支撐工具和平臺(一)監控平臺實現故障快速定位(二)事件管理平臺保障事件快速響應(三)數據服務平臺支持決策以釋放數據價值(四)自動化平臺助力員工解放生產力(五)應用部署優化業務迭代流程(六)CMDB高效管理IT

5、基礎架構與服務202021222222五、 證券行業分布式核心系統SRE發展前景(一) 主管部門完善相關政策指引(二) 證券業機構關注自身SRE能力建設(三) 服務提供機構提升SRE服務能力(四) 第三方機構構建分布式核心系統SRE標準評價體系六、 證券行業分布式核心系統SRE應用建議(一) 模式一： 內建SRE中臺能力 (二) 模式二： 外引SRE咨詢服務(三) 模式三： 內外結合的SRE混合體系目錄Contents242424242627272426我國證券行業分布式系統運維現狀1.我國政策環境良好， 金融科技推動經濟新增長(一)外力和內需雙向促進證券行業分布式系統運維模式轉型以AI、 大

6、數據、 云計算、 區塊鏈為核心的新技術生態正在逐步完善， 成為近年來帶動經濟增長的核心動力。 隨著數字化轉型的不斷推進， 軟件和信息服務業迎來新的發展機遇和挑戰， 國家對各行業的軟件質量及系統穩定性提出了更高的標準、 更嚴的要求。 工信部發布的 “十四五” 軟件和信息技術服務業發展規劃 中強調 “提升軟件質量管理能力和軟件價值保障能力” ，極大鼓勵軟件高質量發展。自2018年以來， 金融監管部門也先后出臺 證券基金經營機構信息技術管理辦法 、金融科技發展規劃 （2022-2025年） 等文件， 提出應加強金融業科技應用能力， 進一步明確信息技術與業務、 風控及合規管理深度融合。 在此情況下，

7、券商對 IT 技術賦能業務的重視程度日益增加，為保障IT業務高速發展變化， 以及新一代分布式核心系統穩定運行， 更多券商機構向以保障系統穩定性為目標的自動化運維、 智能化運維的新型運維模式轉型。2.證券機構核心系統向分布式架構轉型促使運維模式轉型證券行業核心系統架構由集約型向分布式轉型。 由于金融行業擴大開放帶來的競爭環境變化、 用戶服務需求提升、 消費主動性增強以及科技的創新發展， 使得業務創新成為證券機構的必然選擇， 因此對證券核心系統帶來巨大的變化和需求。 同時， 在互聯網金融模式的沖擊下， 證券機構的核心系統需要面對海量客戶和交易、 快速響應客戶需求、 提供靈活的金融產品和服務、 經營

8、模式變化等的挑戰。 目前， 傳統的集中式核心系統已難以適應數字化時代的種種變化，逐漸出現運維人力成本上升、 產品迭代效率低、 故障響應處理周期長、 客戶流失增加等問題。 為了應對上述問題， 支持敏捷開發、 彈性擴容、 智能靈活的分布式架構核心業務系統成為證券行業核心系統主流架構。證券行業分布式運維自動化程度較低， 被動運維普遍。 近年來， 隨著分布式運維管理技術的提升， 證券行業已經開始使用簡單的自動化工具， 但存在普遍程度較低的問題。 證券機構內部，1第一章分布式運維人員往往會花很多時間和精力在一些簡單且重復的問題上， 加上目前普遍處于被動運維管理模式， 故障預警機制并不完善， 往往在發生故

9、障后報警才處理， 導致系統遇到障礙時不能快速排查應用系統處理交易異常。 因此證券行業亟需一套適合分布式系統的自動化、 智能化的新型運維模式， 用以保障系統的穩定可靠運行。(二)系統分布式架構給傳統運維帶來挑戰1.分布式架構運維復雜度提升分布式架構將一個單體系統拆分為多個服務， 數據庫進行多個維度的拆分， 使運維面臨服務層次、 調用關系、 系統狀態更加復雜的挑戰。 這種情況下運維既要做到劃分合理， 充分解耦，又要盡量避免復雜的數據一致性問題。 如果缺少有效的服務治理手段將導致依賴地獄， 搞不清系統間的關聯關系， 一旦某個點出問題， 極易導致整個系統的崩潰。2.業務增長快速， 單一運維工具已無法滿

10、足用戶需求在滿足系統穩定性和效率提升的目標下， 分布式架構下的運維工具需要應具備評估資源池容量、 及時故障預警與應急響應、 故障自動定位等能力， 顯然單一工具無法滿足， 如何形成一套完整的運維服務工具進行自動化、 智能化運維成為挑戰。 例如， 隨著券商線上業務的快速發展，各大券商APP的活躍用戶規模不斷擴大， 運維人員應及時觀測和評估計算資源、 存儲資源、 網絡資源等， 保障在大規模用戶同時下單和交易等過程中， 將延遲控制在允許范圍內， 為用戶提供優質的產品服務， 提高用戶使用粘性。3.運維管理人員知識技能要求提高隨著行業業務驅動的需求增多， 系統架構由集中式向分布式架構轉型， IT 基礎設備

11、種類越來越多， 對運維管理人員的知識和技能將提出更高要求。 分布式架構中各個集群節點處理的業務請求也會激增數倍到數十倍， 需要監控的環節大大增加， 運維人員如何設置監控指標形成一套全面、 準確、 實時的觀測度量體系成為挑戰。證券行業分布式核心系統SRE運維白皮書2一般來說， 傳統的IT企業采用 “開發部 （Dev） +運維部 （Ops） ” 分離的團隊模式， 該模式存在隨著系統復雜度、 組件、 流量的增加， 相關的事件和變更需求也將增加的問題， 由于兩個團隊相互不了解對方的工作技能， 進而造成兩個團隊間的直接成本和間接成本不可避免上升。 在此背景下， SRE新型運維模式應運而生。SRE運維模式

12、可從根本上彌補傳統運維缺陷。 SRE最早在十多年前Google提出并應用， 近幾年逐步在國內外TOP互聯網公司以及金融機構開始廣泛應用。 SRE運維模式采用的是運維即開發、 自動化代替人工的思想。 SRE團隊主要由軟件工程師組成， 通過開發軟件工具、 自動化流程等方法地替代傳統模型中的人工操作。 在這種運維模式下， SRE運維工程師至少有50%的時間可以用于開發和學習， 通過開發自動化、 智能化工具， 可以提升運維人員工作效率并減輕運維人員工作負擔， 同時幫助運維人員快速排查故障問題， 達到對系統故障早發現早治理的效果， 最終達到節省直接成本和間接成本的目的。接下來， 將針對能解決證券行業分布

13、式核心系統運維痛點和難點問題的SRE新型運維模式展開詳細介紹， 包括SRE運維方法論的概述、 SRE的運維服務體系以及相關的支撐工具和平臺等。(三)以主動運維為核心的SRE運維模式興起， 彌補傳統運維模式缺陷我國證券行業分布式系統運維現狀第一章3分布式核心系統SRE運維模式概述(一)SRE運維模式為證券行業業務系統可用性保駕護航SRE是一種區別于傳統運維模式的新型運維模式， 用于保障企業系統的穩定性和可靠性。SRE （Site Reliability Engineering） 即網站可靠性工程， 是 IT 運維的軟件工程方案， 是以互聯網技術產品的可靠性和性能質量為目標的 “全?！?型技術崗位

14、。 SRE 團隊使用軟件作為工具， 以服務的可靠性為目的， 將IT運維相關技術與產品設計研發過程相結合起來， 利用軟件工程方法來管理系統、 解決問題并實現運維任務自動化， 盡可能提高運維管理的效率， 幫助團隊在快速迭代新版本和確保業務可靠性之間找到平衡。對于證券行業來說， SRE團隊需要保障核心業務系統運行可靠， 如集中交易系統、 投資管理系統等。 通過了解業務本身， 深度參與其規劃、 設計、 研發、 上線、 運維、 優化、 架構等環節， 制定SLA， 并圍繞SLO推動分布式架構系統的運維能力實現， 確保業務服務可用性、 業務服務成功率、 業務流程體驗符合目標。SRE運維模式為業務可用性保駕護

15、航。 隨著近幾年業務的快速發展， 國內各大互聯網公司需要維護的服務器有了巨大上漲， 幾乎每個公司都開始維護從幾萬個到幾百萬個服務器節點的系統， 系統頻繁的上線和變更給業務穩定性帶來極大挑戰。 為保障業務穩定可靠運行， IT部門相應的系統運維成本投入也隨之增加。 不同于其他業務部門的 “掙錢” 方式， 運維通過優化資源、 效率提升等多種方式直接地壓縮業務的資源折損消耗體現價值。 如何平衡業務穩定性和成本之間的關系， 是SRE運維的一個重要目標。 相比傳統的運維模式， SRE運維模式在業務團隊內的價值主要體現以下幾個方面：傳統運維模式下運維團隊是被動的， 只能應對之前已經出現過的問題， 很難及時跟

16、進新的場景。 SRE團隊會不斷地和開發團隊溝通業務細節， 共同制定SLI、 SLO等指標， 變被動運維為主動運維。 同時， SRE團隊會根據業務中斷的指標， 開發控制風險的流程和運維工具， 在技術和流程上對業務中斷進行預防和保障。第二章1.1.減少業務中斷42.維持運維高效運行SRE相比傳統的系統管理員、 應用運維工程師等角色， 很大的不同在于SRE會主動改進開發部分的能效。 SRE的任務屬性使得SRE會通過工具提升運維/開發中某些環節的自動化率， 進而提升業務的迭代速度， 讓業務更快地響應市場的需求。3.降低成本投入1.協作和敏捷是DevOps和SRE關注重點2.從開發和運維視角區分DevO

17、ps和SRE成本降低主要包括資源成本和人力成本兩方面。 資源成本方面， 一般來說， SRE團隊會要求業務團隊對應用的SLI/SLO進行梳理， 使得SRE團隊對業務模塊的資源情況非常清楚， 可通過結合監控等數據制定業務模塊擴容或縮容的策略和邏輯， 提升資源利用率。 人力成本方面， SRE運維通過引入自動化工具提升運維效率， 減少傳統的需要大量人工操作的重復性工作， 降低用人成本。團隊協作: SRE 和 DevOps 都致力于搭建開發團隊和運維團隊之間的互通橋梁， 協作是兩者共同的關注點， 致力于打破不同團隊間的壁壘。敏捷迭代:DevOps和SRE都可以實現更快的應用開發生命周期、 改進的服務質量

18、和可靠性， 以及縮短的 IT 應用開發時間， 通過高頻、 小變動的發布， 不斷的將新產品特性部署到線上環境， 帶來更快的迭代速度。DevOps可以認為是一套實踐理論、 指導原則和工作文化， 旨在打破IT組織中開發、 運維、 網絡和安全各自為政的局面， 對企業文化、 業務自動化和平臺設計等方面進行全方位變革， 從而實現迅捷、 優質的服務交付， 提升企業價值和響應能力。 而SRE是探索的一系列工作實踐的方式， 更加注重如何為企業提供的業務可用性提供運維保障。從實際工作場景來看， 如果將開發和運維分成兩個區域， 那么開發和運維中間的空白可以證券行業分布式核心系統SRE運維白皮書(二)DevOps與S

19、RE異同點對比5認為是開發團隊主動思變去填開發和運維之間的鴻溝， 開發團隊可以兼做運維。 而SRE是運維團隊突破自身局限， 從用戶的角度去思考、 去貼近開發團隊， 通過開發一系列自動化運維工具提升工作效率， 讓開發團隊聚焦于業務本身流程開發。業務連續性是SRE的根本出發點和目標。 由于軟件做不到100%完全可靠， 一方面， 基礎設施各部分出故障是常態， 這會影響到應用可用性； 另一方面， 軟件由工程師編寫， Bug不可避免，Bug出現也會引起異常停機。 SRE做到的是盡可能快地發現和處理故障， 并找到可能發生的故障， 在預算范圍內以有用的方式優化應用、 基礎設施， 滿足用戶體驗的需求。SRE運

20、維不只是單純的技術棧 （主機、 存儲、 基礎軟件設施等） 的設備運維， SRE還逐步延伸業務運維領域， 管 務棧的遞進， 體現了SRE運維體系對傳統運維體系演進和拓展。(三)SRE運維模式需貫徹五個核心原則圖 1開發、 運維、 DevOps、 SRE關系圖1.以業務連續性為目標2.從技術到業務分布式核心系統SRE運維模式概述第二章6SRE本身是一個軟件工程師以軟件工程的方法解決運維問題的體系， SRE更傾向于使用代碼的方式去應對各種重復性的運維操作， 通過工具打通各個運維環節實現自動化。 因此SRE運的誕生是因為軟件工程師觸及了運維。 目標將50%的時間用于編寫代碼， 30%時間用于與人打交道

21、、 20%時間用于應對緊急情況。 ”4.預防與事故應對5.平衡風險SRE運維模式中仍然有監控、 事件響度和事件回顧等環節， 與當前傳統運維體系有近似的地方。 但是從整體上， SRE整個運維體系非常強調預防的重要性。 通過事件回顧、 測試與發布、 容量規劃、 開發等層次的工作來持續優化應用， 提升系統的可靠性?！邦A防勝于治療” 這句話， 在IT系統建設和運維領域同樣適用。SRE運維體系首先認定新業務需求和新軟件版本的發布無論如何總會引入bug； 與此同時，較長的開發周期與更嚴密的測試會發現并修正bug， 但是亦會延遲業務需求實現以及新版本發布的時間。 快速實現業務需求與由于bug引起宕機的風險之

22、間需要得到平衡。 SRE通過制定合理的SLO以及錯誤預算， 嘗試在系統風險與業務快速迭代之間實現可量化的平衡。證券行業分布式核心系統SRE運維白皮書73.高度自動化維體系是一個將自動化提高到戰略高度的運維體系模型，正如 Google SRE 書中所言： “SRE證券行業分布式核心系統SRE運維服務體系第三章上一章節對適用于分布式核心系統的SRE運維模式從價值、 運維側重點以及運維核心原則等方面進行了介紹， 本章節將聚焦于證券行業的分布式核心系統的運維建設， 從服務質量度量體系、 觀測指標體系、 流程管理體系、 穩定性運營體系以及組織管理體系五大方面展開介紹。業務的最終目的是為了滿足用戶需求，

23、尤其在互聯網化后， 用戶的體驗滿意度已成為業務競爭中的重要一點。 為確保用戶獲得良好體驗， SRE運維模式需要關心業務的支撐體系是否可用、 穩定， 這是用戶體驗中極為重要而又極容易被忽視的， 也是IT人員對于賦能業務最具價值之處。證券行業越來越多面向終端用戶的業務， 終端用戶的體驗至關重要， 所在區域的網絡環境、服務集群， 以及進行自助業務的終端應用穩定性都是直接影響到用戶體驗的關鍵要素。 SRE可使用體驗指數來描述業務流程體驗狀態， 指數的計算因子可以從終端應用的響應率、 響應時延、 崩潰率、 卡頓率、 錯誤率多項指標進行綜合加權， 通過跟蹤業務流程節點中應用的完整鏈路， 以及各節點的業務量

24、變化， 快速響應和處理影響用戶體驗的問題。系統的線上穩定性作為直接影響用戶體驗感受的性能指標， SRE在處理穩定性時引入SLI（Services Level Indicator） 、 SLO （Service Level Objective） 和SLA （Service Level Agree-ment） 用于量化線上穩定性。SLO是服務提供方與服務需求方對服務的期望， 比如系統可用性是4個9， 還是3個9， 用于定量描述可靠性程度。 SLO是SRE實踐的核心， 對于進行數據驅動的可靠性管理決策很關鍵。 SLO既可以用于承諾付費用戶的場景， 又可以用于承諾非付費用戶的場景； 既可以對公司內部用

25、戶應用， 又可以對公司外部客戶應用。(一)以用戶體驗為核心的服務質量度量體系1.SLO為服務過程期望制定服務等級目標82. SLA為服務雙方責任及目標約定服務等級協議3. SLI為進一步細化SLO設置服務等級指標SLA是IT服務提供方和被服務方之間就服務提供中關鍵的服務目標及雙方的責任等有關細節問題而約定的協議。 一般用于付費用戶的場景， 會具有一定的法律效力。 當一個服務和用戶簽訂SLA時， 往往涉及服務付費、 承諾質量和違約責任等內容。 對于業務團隊來說， 在理想情況下， SLA最好和業務團隊的SLO一致， 這樣會比較符合業務發展的實際情況。常見的SLI指標包含性能指標、 可用性指標、 質

26、量指標等方面。 SLI除了可以衡量服務的外在表現外， 還可以衡量線上業務活動的各個方面。 通過一些列SLI技術指標可以對SLO進行細化并量化， 比如上述的系統可用性可能會轉化為運行時長， 故障時間等， 性能的話會轉換為響應時長、 成功率等。加強運維組織的IT服務管理， 可以采用SLA為基礎， 以SLO為服務質量期望， 以SLI為量化指標， 來設計自身的服務流程、 提供服務形式、 績效評估方法， 如圖2樣例所示。證券行業分布式核心系統SRE運維白皮書圖 2 SLA/SLO/SLI 樣例9(二)以監控系統為基礎的觀測指標體系1.監控系統是SRE運維的基礎和核心2.SRE落地應用亟需標準化的觀測指標

27、體系監控建設作為運維團隊的工具支撐， 在運維工作的方方面面都承擔著不可或缺的作用。 合理使用監控建設能及時發現線上異常、 快速定位線上問題、 有效縮短故障時間。 除此之外， 監控建設采集的數據也成為其他自動運維工具建設的基礎。 監控系統的建設應具備以下三方面特性：一、 穩定性。 穩定是監控重要的屬性， 也是監控的最低標準。 運維團隊保障線上業務的可用性依賴監控服務。 監控服務系統是一種典型的數據處理系統， 穩定性問題可能出現在數據流轉的各個階段， 包含數據源穩定、 網絡穩定、 數據處理穩定、 存儲穩定等。二、 準確性。 好的監控服務發出的警報要盡量準確， 這對監控服務而言尤為重要。 僅憑監控服

28、務提供的手段 （如同環比報警、 智能抑制壓縮、 故障根源定位等） 并不能測地解決有效性問題， 需要監控服務和運維團隊合作配合。 運維團隊要向監控服務表達被監控業務的特征， 監控服務要將業務特征轉化成各種報警能力， 最終體現在提高報警準確率方面。三、 易用性。 監控服務系統是運維團隊在日常工作中頻繁使用的系統之一。 隨著業務規模擴大、 復雜度提升， 運維團隊的線上運維壓力也在持續增加。 因此， 監控服務系統有必要在產品易用性方面做更多的設計與思考， 減少運維工作的壓力， 達到運維工作事半功倍的效果。監控系統的通用能力主要分為黑盒監控、 白盒監控兩種。 黑盒監控主要觀測系統行為， 直觀地發現其可用

29、狀態， 通常關注在線狀態、 配置狀態、 撥測狀態等指標， 基于實時狀態進行告警；白盒測試則依靠系統內部暴露的指標來進行觀測， 具體發現系統應用邏輯層面的問題， 通常關注指標包括異常、 錯誤、 容量、 性能等， 此類指標除了關注實時狀態之外， 還需要了解其歷史狀態， 分析其變化趨勢， 以發現其隱藏的風險， 統計的口徑包括日志分析、 HTTP接口統計分析、JAVA虛擬機接口統計分析等等。SRE需要全面觀測系統的運行狀態， 以達到快速發現、 快速響應、 快速定位、 快速處理。 一個證券行業分布式核心系統SRE運維服務體系第三章10好的指標體系可以幫助衡量觀測是否足夠全面， 參考 JR/T 0158-

30、2018 分級分類方法， 從業務條線出發， 首先對業務細分， 其次對數據細分， 形成從總到分的樹形邏輯體系結構， 最后對分類后的數據確定級別， 形成完整的指標體系。證券行業分布式核心系統按照業務層、 應用層、 系統及網絡服務層、 云底座/基礎資源層， 進行觀測資源對象的梳理， 描述各層級的資源拓撲關系， 以及層級之間個資源的關聯關系， 幫助SRE快速全面地了解系統全貌， 并根據指標觀測到實時狀態， 實現故障的快速發現及影響范圍的快速評估， 更好地進行應急響應。 對于業務層， 監測各節點關鍵業務數據、 體驗指數變化趨勢， 對比歷史基線， 判斷變化態勢是否異常， 告警給運維管理員， 排查關聯應用是

31、否存在異常； 對于應用層， 通過監測應用功能接口調用情況、 進程端口運行情況、 數據庫運行情況， 判斷是否存在異常指標， 告警給運維管理員， 排查應用及關聯的系統或網絡服務是否存在異常； 對于系統及網絡服務層， 通過監測操作系統的整體情況、 網絡連通性情況等， 判斷是否滿足閾值規則， 告警給運維管理員， 排查關聯的云底座或基礎資源是否存在異常； 對于云底座/基礎資源層， 通過監測云平臺、 宿主機、 基礎硬件資源、 基礎網絡服務的整體運行情況， 判斷是否有告警與異常信息， 通知給運維管理員， 快速進行異常排查。以上各層級的觀測指標， 大致可分為異常、 錯誤、 容量、 性能等四種類型指標。(1)異

32、常類型指標指配置、 狀態是否符合預期， 通常評估組件服務的在線狀態、 配置狀態， 以及服務過程中產生的異常日志等；(2)錯誤類型指標指請求失敗的計數、 速率或者比率， 通常評估服務請求的錯誤數和成功率， 終端應用的崩潰率、 卡頓率等， 它直觀地體現了服務的質量水平；(3)容量類型指標指支持上層業務的資源飽和程度和受限量， 通常評估提供服務的資源的運行飽和度， 包括基礎資源和應用資源， 如CPU占用率、 內存占用率、 帶寬使用率、 隊列的積壓情況、 會話的連接數等等。 容量觀測為資源的合理調度、 分配、 擴縮容提供有效依據， 同時， 過量飽和的資源使用可能會導致整體服務質量的下降， 影響到用戶的

33、使用滿意度， 甚至可能會導致業務服務的可用性中斷；(4)性能類型指標指影響或描述請求響應效率、 事務處理速率的指標， 通常評估項為時延和證券行業分布式核心系統SRE運維白皮書11吞吐量。 性能指標也體現了服務的質量水平， 對于不同的業務類型、 業務規模、 服務的用戶等級， 應該有不同的時延和吞吐量水平保障。應用發布的復雜程度往往與系統的復雜程度呈正比， 對于應用系統上規模的企業， 往往使用基于自動化框架構建自動化的應用發布過程。 通過自動化發布工具， 可以構建流水線實現部署的過程中所有的操作 （如編譯打包、 測試發布、 生產準備、 告警屏蔽、 服務停止、 數據庫執行、應用部署、 服務重啟等）

34、全部自動化， 無需人工干預解決以往手工發布存在的效率低下， 上線、更新、 回滾速度慢、 人為誤操作大等問題。 SRE人員會針對每次發布內容做針對性的發布， 包括灰度發布、 藍綠發布、 滾動發布等， 并且對每次發布過程做到效率最高， 影響最小。對于業務來說， 穩定性和迭代速度是整個變更管理的核心， 所有的變更管理本質上都是在尋找這兩者間的平衡點。 為找到這個平衡點， 可以從業務發展階段、 業務體量、 業務影響力三方面考慮。 比如業務發展初期， 大部分情況下是迭代速度優先， 以迅速滿足市場對業務的需求， 此時變更控制往往是弱化的， 更多是為了方便追蹤變化； 業務發展中期， 業務已經有一定的穩定性要

35、求， 業務處理方式通常是注重穩定、 兼顧迭代速度， 此時是兩者關系最難處理的時期； 業務成熟期， 通常業務團隊和業務框架比較成熟， 多選擇穩定性優先的策略。一般來說， 在保證業務穩定性的前提下， SRE團隊很重要的工作是讓業務更快速發展。 因此在保證業務的SLO達標且錯誤預算沒有耗盡的情況下， 在做變更決策時， 可以適度地偏向迭代速度優先的變更策略。 SRE需要對每次變更發布負責， 對每次變更上線做變更評審， 包括變更的準入規則， 變更的類型， 變更執行的步驟， 變更的記錄等內容， 實現多角度變更管理。 同時， SRE需要總結變更經驗， 優化變更流程和提高變更效率。 通過跟蹤最新行業動態， S

36、RE可以引入突破瓶頸的運維工具， 實現人力成本降低和風險管控提高的雙贏。(三)以穩定可靠為保障的流程管理體系1.構建自動化的應用發布流水線2.兼顧穩定和敏捷的變更管理12證券行業分布式核心系統SRE運維服務體系第三章證券行業分布式核心系統SRE運維白皮書3.平衡系統可靠和更新速度的錯誤預算4.定位問題根源和解決方案的on-call流程當我們設定好SLO， 需要有個可量化的數據， 用于提醒并觀測SLO的情況。 而SRE中通過反向推導SLO的方式， 得出一個量化數據-錯誤預算， 就能達到這個效果。 它可以直白的理解其為 “提示還有多少次犯錯的機會” 。 通過應用錯誤預算進行數據的歸一化方式， 可以

37、更好的來推進穩定性目標的達成。 錯誤預算為企業提供了一種監測和壓測的觀測手段， 可以有效直觀的感知某些指標或業務系統的瓶頸， 是保障業務系統穩定運行的重要方式。 例如， 錯誤預算能夠對容量的擴縮容提供觀測值， 通過側面反映業務系統的容量水位， 實現及時調整容量并反映調整后效果。另外， SRE運維工程師與開發人員溝通系統變更頻率時， 錯誤預算還可以作為雙方共同認可的指標。 也就是說， 雙方可圍繞 “錯誤預算” 來考量是否變更， 當錯誤預算充足時， 可放寬對變更的限制， 開發人員可以快速上線新模塊以滿足業務需求， 實現系統優化和架構改進； 當錯誤預算不足時， 需控制變更節奏， 應以保障業務系統穩定

38、運行為目標減少變更頻率。 特別地， 如果需要變更的系統本身是分布式的高可用架構且支持灰度發布， 錯誤預算指標并不直接影響變更頻率， 可以實現敏捷開發。 錯誤預算可以在每個績效周期開始時進行約定， 是減少運維和開發雙方矛盾的一個重要指標， 有必要在企業內部推行。on-call的職責在于： 監控預警處理， 第一時間處理生產環境的監控預警。 緊急故障救火， 協同業務團隊處理生產環境穩定性問題。 穩定性問題排查， 挖掘生產系統穩定性隱患， 進入深水區進行挖掘。 全鏈路穩定性巡檢， 生產系統核心業務SLO指標、 錯誤日志、 RDS健康度、 慢SQL巡檢等。 參與故障復盤， 此處的故障包括GOC故障與線上

39、的穩定性問題。 經驗總結輸出， 將on-call過程進行的故障診斷、 問題處理、 故障復盤進行總結。on-call意味著在一定時間內隨叫隨到， 并做好生產環境出現緊急情況的應對準備。 SRE工程師經常需要輪值on-call。 在on-call期間， SRE會根據需要對緊急情況進行診斷、 環境、 修復或升級事件;此外,SRE還要定期負責非緊急性生產任務。 SRE團隊可以緩解事故、 修復生產問題并自動執行運維任務。 由于大多數SRE團隊尚未完全自動化實現運維任務， 因此升級仍需要人工13聯系On-call工程師進行處理。值得說明的是， SRE工程師并不是On-call的主導者， 而是參與者， On

40、-call的主要目的是讓SRE工程師更全面了解系統， 及時發現系統需要優化的地方。 在此過程中， SRE工程師應以工程化的視角， 將精力更多放在找出問題根因和解決方法上， 比如通過改進運維流程、 使用運維工具、 進行容量規劃、 災備建設以及架構治理等手段， 實現快速發現、 響應、 排除故障、 以致徹底根治問題等， 這些都是SRE工程師需要花更多精力去思考和推動的事情。穩定性治理是個比較復雜的命題， 業界沒有統一的定義。 系統穩定性是指系統要素在外界影響下表現出的某種穩定狀態， 但事實上， 復雜系統中潛伏著大量影響穩定狀態的故障組合。在整個運維工作中， 線上業務運營時難免會有監控指標波動的情況，

41、 當這些監控指標波動突破一定范圍時， 會被定義為異常。 運維團隊對異常響應， 主要分為跟進、 分析、 定位、 解決等多個步驟。 異常響應在運維團隊工作中也占據了非常重要的地位。異常響應流程： 在傳統運維團隊中， 每個小團隊對異常響應都有獨立的想法和處理方式。 整個流程完全取決于處理團隊自己的利益和訴求， 往往沒有固定的流程。 從SRE團隊的角度出發，流程應該是要固化到平臺的， 而為了更好地將相關流程沉淀到平臺， 必須梳理異常處理流程的設計原則， 以適應不同業務的問題處理需求。 處理環節主要分為： 異常發現、 問題跟進、 問題升級機制、 問題分析、 問題通知、 問題解決、 問題后續追蹤。 實際按

42、照異常處理規范跟進時， 每個環節考慮的越細致， 在實際工作中就會有越好的處理體驗。應急溝通機制： 在實際的工作跟蹤， 總有些異常是超出預期的。 在傳統運維模式下， 線上應急主要聚焦問題的排查和解決， 很少關注信息的整理和同步。 因此， 團隊建設時需要專門對應急溝通機制進行梳理， 重點是設計一個運轉良好的的信息溝通機制。 雖然應急溝通機制可能隨著業務特性或當時的情況發生變化， 但是在信息同步方面還是有一些統一原則的： 需要做到分別制定問題排查任何信息同步人、 信息定期同步、 信息量足夠， 不過多解釋等。5.制定流程完備與溝通高效的應急事件處理機制14(四)以服務治理為目的的穩定性運營體系證券行業

43、分布式核心系統SRE運維服務體系第三章證券行業分布式核心系統SRE運維白皮書1.故障管理： 為系統穩定性和連續性提供保障1.故障等級穩定性治理的核心是故障管理， 細分為故障預防、 故障演練、 故障自愈、 災備建設等領域。 穩定性治理的主要工作范圍涵蓋了可用性、 監控告警以及線上應急。所有業務系統都無法避免發生各種各樣的故障， 故障管理是針對故障發生前、 故障發生時、以及故障發生后的計劃和措施的管理。 針對SRE運維模式來說， 故障管理是為實現業務系統穩定性以及連續性不斷提高的重要管理措施， 也是相比傳統運維而言擁有更健全的管理計劃、 更規范的管理流程、 更優秀的故障處理方案。 SRE故障管理包

44、括以下幾個方面：故障等級是對故障發生時的一種等級劃分。 故障等級通常由業務故障發生的時長而定， 隨著故障時間增加， 故障等級會隨著時間增加而上升。 告警的等級觸發條件與SLA掛鉤， 一般按業務停止時間， 成功率劃分， 具體按實際情況定。2. 故障處理故障處理直接會影響故障發生時故障處理效率以及應急調度方案。 故障處理通常會分為幾個階段， 包括故障通告， 故障調度， 故障恢復， 故障記錄等。 第一時間按故障等級通告， 并隨著故障等級升級而不斷通告。 通告發生后， 通過監控系統進行故障定位并且調用應急處理能力， 調度相關責任人處理。 并且以第一時間恢復故障為原則， 在恢復后進行故障原因排查分析，

45、防止故障擴散。 按照時間線記錄故障過程， 規范故障記錄文檔。3. 故障復盤4. 故障經驗沉淀故障復盤是對故障發生后的一次總體總結。 故障發生后， 按照故障等級召開相關人員會議，召開故障復盤會。 主要包括記錄故障復盤會的內容， 確定優化、 處理、 改進事項， 明確責任人， 并不斷跟進故障處理情況， 跟進落地情況。15在運維行業中， 運維人員的實踐經驗是否豐富直接影響運維人員的價值。 故障經驗沉淀有助于經驗較淺的運維人員快速成長， 這是對SRE人員良性提升與發展的重要方式。 通過故障經驗共享的方式， 企業能夠不斷豐富內部運維知識庫， 一方面， 可以在下次故障發生時有歷史應急經驗可循， 另一方面，

46、可以不斷優化故障發生時的應急策略提高系統穩定性。線上業務故障， 故障預案是一個無法避免的問題。 在傳統運維模式下， 當線上發生故障時，最常見的故障預案問題有以下兩類： 不在評估預期內的故障類型和故障預案執行有問題。 從SRE團隊的角度看， 相較傳統運維團隊， 更加注重對運維操作的提煉， 也因此更加注重自動化工具的建設。 線上測試技術的進化和SRE新理念的事件反映到故障演練上， 形成了以下兩個明顯的優勢： 第一， 故障類型完備度。 第二， 故障模擬更加容易。 目前的演練方案也有很多包括容災演練、 高可用演練、 容量壓測演練、 紅藍對抗演練等。 針對業務系統做到更全方位的演練， 不僅可以預防故障發

47、生， 修復演練中發現的問題， 更能在故障發生時， 提前準備好應急方案。對于所有線上故障來說， 其實最好的處理方式是防患于未然， 在線上還沒有出現問題時就跟進相關運維工作。 因此， 如果新系統從設計、 實現到運營就充分考慮穩定性， 例如采用防御性設計， 規范化操作和標準化運營等， 一般能規避大部分故障風險。 另外， 可通過風險評估的方式， 對可能存在且無法完全避免的風險進行提前評估， 以及通過預設風險的方式， 提前對系統功能架構的設計、 資源結構的設計等給出風險報告， 這樣在故障發生時有所準備。 SRE在運維的同時， 也要對整體架構有所感知， 通過對功能到資源架構深入理解， 不斷提升系統穩定性。

48、除了提前的風險評估和預防設計， 巡檢作為重要日常工作， 對故障預防也有著發現和保障的作用。 巡檢會對日常資源， 業務功能， 上線新功能以及歷史故障等做巡檢， 預防故障發生。同時， 故障預防對監控平臺也有要求， SRE會針對監控平臺的不影響業務系統的告警， 做處理和降噪。 分析告警的原因以及可能存在的故障風險， 做到預防故障發生。2.故障預防： 提前發現可能風險， 進行主動運維3.故障演練： 找出系統風險點， 提高系統魯棒性4.故障自愈： 通過自動化緩沖對線上穩定性影響16證券行業分布式核心系統SRE運維服務體系第三章故障自愈不只是運維Keepalived VIP、 MySQL主從等部署， 它代

49、表的是一整套的設計理念和運維想法。 從落地方法和實現上說， 故障自愈有以下多個層級： 基于主備的設計、 基于負載均衡的設計、 基于平臺的設計、 基于業務架構的設計。 故障自愈是所有SRE團隊和開發團隊對線上穩定性的最終追求， 故障自愈設計可以緩沖故障對線上的影響。 更重要的是， 故障自愈通過以自動化代替人工， 能夠實現在保障系統更加穩定的同時減少人員精力以及人力成本。 故障自愈的方案是從對初期設計無法預想的情況下， 不斷進行改進， 最終實現優化自愈。 在這個不斷持續性演進的過程中， 對SRE人員素質要求很高， 需要兼備開發能力與運維能力、 豐富的應急預案能力、 根因定位能力以及解決排查的能力。

50、證券行業分布式核心系統SRE運維白皮書5.容量規劃： 在成本控制和業務支撐間尋找平衡隨著企業對外服務的內容和用戶不斷增長， 企業會不斷增加對硬件和云基礎設施的投入，用于滿足業務發展的需要。 實際上， 企業研發部門在實際生產過程中都會面臨各種各樣的復雜業務場景及相應的困難和挑戰， 這些匯聚到IT支撐環節， 就形成了對IT資源的需求與規劃。 容量規劃包括業務容量和資源容量， 業務容量需要對于業務的事務處理性能進行監測， 參考系統基礎能力對業務吞吐量的支持， 對業務容量的飽和狀態進行評估和預測， 以提前及時地進行容量擴縮容； 資源容量需要對基礎資源的容量進行監測， 如算力、 存儲能力， 通過及時地調

51、整資源池空間， 來確保業務性能、 可用性不受影響， 同時很好地控制成本。為有效進行容量分析和預警， 可以從以下三個階段主動進行容量分析和優化。事前容量規劃： 在進行年度IT資源預算規劃或新業務、 新產品上線前需要仔細評估所需的IT資源。 同時， 對容量進行壓測， 壓測后的報告需要進行分析總結， 給出規劃預期。（容量壓測取決是否具備生產壓測能力） 。事中容量監控： 業務和產品在服務用戶過程中， 需要投入人力建設相應的容量監控和預警系統， 實時收集與容量相關的數據， 在容量水位低于或高于預先設定的閾值時， 進行容量擴縮容等優化。 其中， 擴縮容的標準可參照SLO， 擴縮容的方案可參照系統架構和系統

52、SLA制定的技術方案。事后容量調整： 根據業務情況及時調整容量， 以應對突發的流量或對處于生命周期末期的17產品進行縮容。 針對擴縮容形成容量報告， 輸出系統容量水位， 擴縮容記錄， 調整建議和調整后的效果。隨著客戶需求的多樣化以及業務數量的快速增長， 企業初期設計的系統架構往往已不能滿足業務需要， 甚至會頻繁出現系統故障等問題， 導致運維人員工作量大幅增加。 因為SRE運維模式直接觀測感知整個業務系統， 能夠對企業內部系統架構有全方位的認知， 可以在系統架構治理的痛點問題上給出更切實可行的建議， 尤其是在業務應用進入實際生產環境后SRE有著更權威的發言權。 例如， SRE可從系統健壯性、 系

53、統可拓展性以及系統成本等方面進行多維度綜合評估， 提出架構治理相關建議。 同時SRE也應及時跟蹤最新技術動態， 對可能解決當前系統架構痛點問題的新技術進行評估， 以幫助系統架構實現不斷優化治理。 諸如以上架構治理建議， SRE可通過報告等方式反饋到新一代系統架構研發過程中， 實現以運維服務系統， 以系統優化運維的目標。組建SRE團隊需秉承多樣化原則。 SRE團隊中應有包括 “技術負責人 （TL） ” 、“SRE經理（SRM） ” 、“研發工程師 （RD） ” 和 “項目經理 （PM/TPM/PGM） ” 等多種角色。 很多時候組織內部是一個動態的環境， 各種角色之間可以動態地協商切換責任。 一

54、般來說， 越動態的團隊成員的個人能力越強， SRE人員需要不僅僅是 “編寫代碼的運維人員” ， 也應該是開發團隊的成員， 通過開發運維工具的實現流程自動化， 提高運維效率， 尤其是在部署、 配置管理、 監控、 指標等方面。SRE團隊需持續溝通協作改進系統穩定性。 SRE需要參與的工作大多是跨團隊的， 溝通能在所有的運維系統中， 災備建設是故障恢復最終的兜底保障。 合格的符合需求的災備設計從技術上來講有以下幾個等級： 同機房災備、 同城雙活、 異地數據災備、 兩地三中心、 分布式多活等。 SRE人員需對內部系統架構進行綜合評估， 如果企業不具備災備能力， 應提供必要的災備建設建議和服務。6.災備

55、建設： 為故障恢復提供兜底保障7.架構治理： 通過觀測感知全系統以優化架構設計18(五)以持續改進為標準的組織管理體系證券行業分布式核心系統SRE運維服務體系第三章是最重要的軟實力能力之一。 SRE要非常重視團隊協作， 尤其在故障應急上， 要協作多方團隊，緊密合作， 降低故障MTTR。 而在日常工作中， SRE要積極協同業務團隊以及外部依賴團隊， 主導并推動穩定性相關工作的落地。證券行業分布式核心系統SRE運維白皮書19證券行業分布式核心系統SRE支撐工具和平臺第四章監控是SRE最重要的工具， 為了能更好地覆蓋到分布式架構系統的觀測點， 并且具備快速定位和排障能力， 監控需要滿足平臺化、 可視

56、化、 自動化、 智能化的特性。(1)能力中臺化抽象通用的監控能力， 如采集、 分析、 告警、 通知等， 統一建設和優化， 通過訂閱監控服務， 快速構建指標觀測場景。(2)監控自動化抽象規則明確、 邏輯清晰的工作流， 如采集能力、 分析能力、 告警合并、 通知能力的自動化，持續進行自動化改造， 提升觀測效率的同時， 將人力從無價值的繁瑣作業中解放出來， 投入到更有意義的業務創新中去。(3)過程可視化將監控狀態、 分析結果通過可視化的手段清晰地呈現出來， 幫助運維人員更容易進行決策和排障管理。(4)分析智能化結合AI、 大數據、 機器學習等新興技術， 對統一的運維對象、 海量數據進行智能分析， 擴

57、展運維的深度和廣度， 解決原本人力難為的運維問題， 如未知異常檢測、 持續惡化的指標、 告警的根因分析、 指標跟隨分析等場景， 主動發現風險， 提升數據價值。監控平臺還需要完整的告警臺功能， 提供告警的分類分級管理， 并清晰地呈現出來。 一個好的告警臺是必要的， 幫助管理人員更關注重要、 緊急信息， 驅動工作展開。 告警臺可以跟蹤告警的處理狀態、 關聯影響、 響應負責人， 以確保重要告警都能得到處理， 避免風險遺漏。 同時， 對于海量告警， 還須具備合并收斂、 根因歸類能力， 以降低告警數量， 提升告警的有效性。事件管理平臺負責跟蹤事件的處理進度， 一般來說， 影響到系統正常運行的告警會上升為

58、(一)監控平臺實現故障快速定位(二)事件管理平臺保障事件快速響應20故障， 影響到業務開展的故障會上升為事件。 每個故障都應有完整的預案， 以確保在發生時能夠快速地進行響應和恢復， 盡可能地降低業務中斷的風險， 或減少業務中斷可能造成的損失。事件管理平臺需要有故障畫像和預案演練能力， 對于故障從多個維度進行描述， 來區分故障的性質和本質， 對應的故障需要有應急預案和演練計劃， 跟蹤演練的情況， 復盤演練的問題，持續優化事件應急機制和流程。事件管理平臺能夠對故障發生整個環節進行流程推動， 將流程狀態完整地可視化呈現出來， 確保參與的人員能夠更好地理解任務、 執行任務。(1)當故障發生時， 需要迅

59、速明確出故障的應急人員， 確保相關人員在規定時間內進行到崗簽到， 確保故障得到第一時間的處理。 故障的現象、 內容、 級別、 影響情況、 應急進度都需要進行相關人員播報， 確保信息流暢， 執行一致。 故障關聯的資源對象須通過自動化觀測的能力實時呈現狀態， 以客觀地呈現故障的修復效果。(2)故障結束后， 相關負責人須組織復盤工作， 確認故障發生的根因并進行根本性修復， 確保下次不再發生或能更快速地完成響應恢復。數據服務平臺是決策分析的基礎， SRE通過將多方數據源進行加工管理， 并在容量規劃、 性能分析、 異常檢測等場景中加以應用， 可充分體現數據中的價值。 數據服務平臺應具備數據采集、 查詢與

60、分析、 數據加工、 數據消費與投遞、 可視化、 告警能力等功能。(1)數據采集從多種渠道采集源數據， 作為后續的消費基礎， 包括服務器/應用日志及數據、物聯網設備數據、 移動端數據、 開源日志服務軟件數據、 標準協議數據等；(2)查詢與分析能力是數據最基礎的消費場景， 通過匹配查詢、 上下文查詢、 SQL語法查詢、NoSQL語法查詢， 可以快速地獲取不同緯度的簡單數據統計結果， 滿足大多數統計分析場景需求；(3)數據加工主要對采集上來的數據進行加工處理， 對非結構化數據進行規整， 使其更利于不同場景的消費需求， 將多組數據進行串聯結合， 富化其含義， 使其價值得到提升， 對數據進行證券行業分布

61、式核心系統SRE運維白皮書21(三)數據服務平臺支持決策以釋放數據價值規整， 使其更利于不同場景的消費需求， 將多組數據進行串聯結合， 富化其含義， 使其價值得到提升， 對數據進行脫敏， 降低非法數據帶來的安全風險， 對數據進行過濾篩查， 提升關鍵熱點數據的服務能力；(4)消費與投遞主要體現數據對外提供的開放性服務能力， 包括支持第三方軟件消費、 支持java/python/Go語言消費、 支持流式計算消費、 支持投遞到存儲/數據庫等；(5)可視化能力提供多種可定制編排的圖表， 用來對數據的加工、 分析結果做具體的呈現，使應用人員能夠直觀地感知數據狀態， 并達成理解上的一致， 輔助決策；(6)

62、告警能力可以是數據服務平臺的一個具體的消費應用， 通過監控數據關鍵字、 數據變化等， 觸發相應的告警通知， 讓管理人員可以及時對數據進行響應。自動化平臺幫助SRE加速了運維工作自動化的實現， 通過將邏輯明確、 規則清晰的工作流程快速構建出來， 快速積累場景， 使SRE人員能夠從重復工作中釋放出來， 將精力投入到架構優化、 工具研發等工作中。自動化平臺一般有三個模塊： 控制臺、 設計器、 執行終端。 控制臺負責完成具體自動化任務的下發、 調度、 編排， 以及跟蹤任務的執行進度和狀態； 設計器通過腳本語言、 所畫即所得等方式進行自動化任務的開發、 調試、 測試執行； 執行終端負責執行接收到的自動化

63、任務， 處理任務異常， 輸出任務日志等。證券行業分布式核心系統SRE支撐工具和平臺第四章22(四)自動化平臺助力員工解放生產力應用部署平臺能夠提供灰度、 升級、 回滾等相關工作的管理， 對各種不同業務類型的系統提供多樣化的部署服務支撐。 也能夠進行容器、 物理機部署， 支持在線、 離線服務、 定時任務以及靜態文件的部署， 提供部署資源管理、 運行環境搭建、 部署流程定義和部署執行跟蹤， 可以進行金絲雀發布及藍綠部署。 應用部署平臺可以加快業務迭代速度、 規避故障發生， 提升產品發布節奏。(五)應用部署優化業務迭代流程(六)CMDB高效管理IT基礎架構與服務CMDB系統可以管理一個企業的全部服務

64、器， 包括物理機和各類云廠商提供的云主機資產， 以及相關對應的資源狀態、 使用人員、 產品應用的環境和項目信息， 可以為其他系統， 如監控系統、 自動化發布等DevOps類系統提供有效的支撐。 另外， CMDB需要構建資源與資源之間的關聯關系， 以確保運維對象、 運維數據得到有效地串聯和豐富， 協助自動化和故障定位等相關工作的展開。 CMDB系統可以進一步提供類似業務線-產品線維度的資源和負載情況， 進一步供相關負責人進行分析和決策。CMDB是運維工具和運維流程的基石， 如果SRE工程師想要持續地優化運維體系， 有必要構建一個面向消費的CMDB。 為了讓CMDB有助于SRE工程師， 面向消費的

65、CMDB需要具備以下三點特性：（1） 需構建資源模型和關系模型， 明確運維的資源對象， 管理資源配置數據， 以及各資源的關聯關系， 同時協助監控、 自動化等工具進行快速配置、 分析和決策。（2） CMDB管理的資源需具備自動發現、 自動拓撲等功能， 以確保資源配置數據具備實時性、 一致性。（3） CMDB系統需提供標準的開放接口， 可基于資源配置數據實現運維領域的消費場景擴展。證券行業分布式核心系統SRE運維白皮書23證券行業分布式核心系統SRE發展前景第五章無論是從企業成本上考慮還從技術演化上考慮， DevOps和SRE這類主動式IT運維模式都是運維未來的發展趨勢， 很多公司的傳統運維團隊也

66、紛紛有針對性地根據組織實際情況在跟進轉型。 作為相關主管部門應積極完善主動式IT運維發展政策指引， 推動IT運維從只關注IT基礎設施和系統的運行質量轉向進行類似SRE模式的主動式運維監控服務。(一)主管部門完善相關政策指引隨著技術運營的發展與實踐落地， IT運維團隊正處于從證券機構內部成本中心向利潤中心轉型的關鍵時期。 證券機構信息技術部門應積極組建SRE運維模式團隊， 實現降本增效的價值。一方面， SRE團隊聚焦于運維自動化， 通過自動化工具和平臺提升效率； 另一方面， SRE團隊通過高頻、 小變動的發布， 不斷地將新產品特性部署到線上環境， 實現盡可能減少變更導致的故障， 進而降低因產品故

67、障帶來的經濟損失。(二)證券業機構關注自身SRE能力建設過去， 我國多數 IT 運維服務提供商依賴大型或國際企業的運維工具、 產品或內容進行 IT 運維服務， 然而這些產品大多為被動式運維方式。 隨著企業業務系統復雜性的提高， 以及為滿足產品從開發到發布的快速迭代， SRE主動式運維模式越來越受到運維服務商關注。 運維服務商SRE團隊應投入精力在一些和線上穩定性相關的平臺和工具開發中， 包括基礎架構穩定、 代碼質量、 機器性能及安全問題等。(三)服務提供機構提升SRE服務能力“無規矩不成方圓” ， 在企業的IT運維管理工作中， 運維標準評價體系的構建是非常重要的。沒有標準規范的IT運維， 可能

68、會導致企業實際生產活動數據質量問題， 從而影響公司的業務發展。 目前， 業界常見的IT運維相關標準有ITIL、 ISO20000、 ITSS等最佳實踐及相關標準， 但自動(四)第三方機構構建分布式核心系統SRE標準評價體系24化運維、 SRE運維相關的標準體系仍有待完善。 第三方科研機構應積極聯合政府、 證券機、 運維實踐領先企業等共同進行分享、 總結、 整理， 以明確SRE運維服務規范和制定相關標準體系， 共證券全行業參考執行。證券行業分布式核心系統SRE運維白皮書25證券行業分布式核心系統SRE應用建議第六章在現有的運維體系中嵌入SRE是一項大的挑戰， 本文提供了下面三種模式供參考， 企業

69、可以根據自身的組織狀態， 選擇合適的路徑來落地應用SRE運維方法論， 以達到降本增效， 提高業務可用性的目的。自建SRE中臺即通過內部成立一個SRE組織， 對開發、 運維雙方進行賦能和影響。 在這種 “大中臺、 小前臺” 的組織架構下， 處于中臺的SRE組織對前臺各開發團隊、 各運維團隊提供建議、 服務、 約束多方面支持， 包括業務可用性規范設計、 可用性方案設計、 上線方案設計、 灰度方案設計、 架構優化建議、 應急預案等等， 同時， 基于平臺特性， 提供相關的工具能力建設， 如基礎設施的底座、 觀測能力平臺、 灰度管理、 災備管理等貼合實際業務運維的工具。在運維流程和運維觀測中， 持續地進

70、行自動化和可視化， 使得流程和觀測在多方服務對象形成理解一致、 執行一致的組織能力。該模式具備以下優勢：提升服務質量： 由于運維服務集中化， 通用能力上可以得到有效地規劃建設和迭代發展， 并一定程度上解決了理解和執行的不一致問題， 可持續地提升服務質量；共享人力資源： 通過建設統一的SRE人力資源池， 實現資源共享， 同時確保SRE人員的專業性， 緩解了在SRE模式落地過程中對于人員的需求問題。該模式具備以下劣勢：缺少服務深度： 由于SRE對接所有業務系統的運維需求， 必然導致SRE人員對于業務場景了解不夠深入、 服務不夠深入的問題， 從而對于業務可用性建設的構建缺乏保障；溝通存在障礙： 本質

71、上SRE一定程度上解決了開發、 運維的協同問題， 增加了中臺化的SRE組織后， 增加了溝通的復雜度， 在績效設置和考核上更加困難。(一)模式一： 內建SRE中臺能力26(二)模式二： 外引SRE咨詢服務(三)模式三： 內外結合的SRE混合體系外部引入SRE咨詢服務即依賴第三方運維服務商按照約定的范圍提供SRE咨詢能力， 重點在業務系統的觀測指標體系、 運維優化建議等方面提供支持。 觀測指標體系指圍繞業務系統提供全棧的運維觀測清單， 并確保供應商開放觀測所需的數據； 運維優化建議指第三方服務商通過跟蹤和管理業務系統的運行、 運維情況， 適當提供如可用性評測、 部署策略、 發布策略、 灰度策略、

72、升級策略、 災備策略等方面的可用性優化建議， 以及對運維工作流程進行評測和自動化優化建議， 對系統業務容量、 資源容量的趨勢進行評測并提供容量規劃建議。該模式具備以下優勢：提升服務深度： 對業務場景深入了解的第三方運維服務商， 可以切實地提供專業、 系統、 客觀的服務和建議， 并對供應商和運維流程提供合理、 有效的約束；快速適配體系： 在不影響現有的組織架構和運維體系前提下， 通過咨詢服務對分布式架構業務系統的運維能力進行加強和補充， 更好地完成適配和服務支持。該模式具備以下劣勢：管理和安全問題： 第三方運維服務商深入到運維工作過程中， 在監管嚴格的金融行業中， 存在較大的安全合規問題， 增加

73、了管理的困難；責任邊界模糊： 以咨詢服務的方式， 對于IT的整體規劃和實施產生影響的同時， 擔負的責任與影響不對等， 使得團隊之間的責任邊界變得模糊。SRE混合體系， 即企業既建設自己的SRE組織， 又依賴第三方運維服務供應商提供的SRE咨詢服務， 由企業自己的SRE組織參考第三方供應商的建議， 牽頭完成SRE運維體系的建設和業務系統可用性保障。該模式具備以下優勢：快速構建面向分布式架構系統的運維體系： 企業自己的SRE組織只需要進行相關工作的協同串聯和方案實施， 并對第三方服務商進行管理， 主要方案由第三方服務商進行設計， 可以解決管理、 安全以及服務深度的問題， 快速對分布式架構系統的運維工作提供支持；證券行業分布式核心系統SRE運維白皮書27建設SRE組織能力： 通過快速運轉分布式架構系統運維體系， 積累知識、 經驗， 培養相關專家， 持續優化SRE組織能力。該模式具備以下劣勢：增加人力成本： 同時構建SRE組織和購買第三方運維服務， 需要較大的成本投入， 具體的實施路徑需要更精細地規劃， 以控制成本投入；溝通存在障礙： 新構建的SRE組織依然存在與開發、 運維、 第三方服務商的溝通問題， 需要確認良好的溝通機制以確保信息和計劃得以傳達執行。 證券行業分布式核心系統SRE應用建議第六章28