CMDB 集成

在 DevOps 的實踐過程中，流水線的構(gòu)建具有 4 種方式：以項目批次為基準的價值交付流水線、以資源數(shù)據(jù)為基準的交付流水線、以支撐數(shù)據(jù)為基準的交付流水線和以交付數(shù)據(jù)為基準的交付流水線，其中以資源數(shù)據(jù)為基準的交付流水線方式主要依托 CMDB 。在 DevOps 的集成體系中， CMDB 是基礎(chǔ)支撐數(shù)據(jù)的來源，也是基礎(chǔ)元數(shù)據(jù)平臺。

CMDB 概述

CMDB （ Configuration Management Database ，配置管理數(shù)據(jù)庫）在傳統(tǒng)企業(yè)中稱為資產(chǎn)管理系統(tǒng)，在云計算或互聯(lián)網(wǎng)企業(yè)中稱為云配置中心。CMDB 可以對企業(yè)內(nèi)外部的 IT 資源進行識別、控制、維護和存儲，從而實現(xiàn)對 IT 資源的高效控制。另外， CMDB 可以管理企業(yè)不斷變化的 IT 資源和 IT 服務(wù)，還可以為問題管理、事件管理、交付管理和業(yè)務(wù)連續(xù)性管理提供完善且準確的配置信息。

從本質(zhì)上來說， CMDB 通過收集 IT 資源的各種信息，并根據(jù)收集的信息對項目或產(chǎn)品的價值交付進行數(shù)據(jù)輸出和賦能。CMDB 在能力輸出方面經(jīng)過多次演進，即從基本的配置管理，到場景消費、應(yīng)用驅(qū)動，再到為價值交付賦能。在實踐過程中，落地后的實際用途和預(yù)期存在較大出入，糾其原因，不外乎 CMDB 因運維職能的泛化而導(dǎo)致數(shù)據(jù)輸出能力的下降。CMDB 的建設(shè)通常需要打通 IT 資源使用鏈路上的各個能力子域，因此需要組織協(xié)調(diào) 和流程推進，而運維職能范圍的不斷拓展，導(dǎo)致數(shù)據(jù)的標簽和口徑在一定程度上失真，如數(shù)據(jù)不準確、數(shù)據(jù)收集不及時、對接困難和數(shù)據(jù)輸出薄弱等情況，導(dǎo)致最終效果達不到預(yù)期。

CMDB 的作用

CMDB 的使用場景較多，如配置管理在 IT 組織內(nèi)部的應(yīng)用，因此，我們需要梳理其主要使用場景，從而提升 IT 資源使用的透明度和準確度。同時，我們需要通過配置數(shù)據(jù)進行價值輸出，通過提供價值交付流水線進行反向集成，如自動化發(fā)布、數(shù)據(jù)查詢、資產(chǎn)審計、容量管理和全鏈路監(jiān)控。常見的場景主要有兩類：流程場景和數(shù)據(jù)場景。流程場景主要包括運維自動化的集成（需要 CMDB 提供系統(tǒng)的情況和系統(tǒng)資源的情況）、監(jiān)控系統(tǒng)的集成（需要 CMDB 提供系統(tǒng)之間的關(guān)系和系統(tǒng)的 IP 地址等數(shù)據(jù)）和運維流程的集成（需要 CMDB 提供配置對象和數(shù)據(jù)的相關(guān)信息）。數(shù)據(jù)場景一般是指通過 CMDB 提供的數(shù)據(jù)進行高階使用，也就是將 CMDB 的數(shù)據(jù)通過 API 方式對其他第三方系統(tǒng)進行輸出，形成基礎(chǔ)模塊，提供統(tǒng)一服務(wù)入口，如常見的資源管理過程可視化，以及對 IT 資源進行查詢和分類統(tǒng)計。

在傳統(tǒng)行業(yè)中，運維管理流程是 IT 組織內(nèi)部條目最多、范圍最廣的流程場景， CMDB 需要向運維管理提供數(shù)據(jù)的支撐服務(wù)，以及 IT 資源信息的輸入、變更和存儲。運維管理分為事件管理、問題管理、變更管理、配置管理和資產(chǎn)管理， CMDB 在它們中起到的作用如表 3-1 所示。

表 3-1

在能力子域方面， CMDB 的數(shù)據(jù)覆蓋率取決于受眾人群的類型， CMDB 的數(shù)據(jù)主要分為產(chǎn)品目錄，產(chǎn)品團隊，資源和容量，產(chǎn)品安全，服務(wù)質(zhì)量，以及架構(gòu)成熟度多個維度。

產(chǎn)品目錄中一般包括系統(tǒng)標識、系統(tǒng)名稱、運行狀態(tài)、系統(tǒng)交互關(guān)系、版本信息、產(chǎn)品干系人、產(chǎn)品屬主、產(chǎn)品功能、部署位置、系統(tǒng)用戶范圍和系統(tǒng)語言等配置信息。

產(chǎn)品團隊中一般包括團隊組織、人員工號和第三方支持團隊信息等配置信息。

資源和容量中一般包括系統(tǒng)實例清單、中間件實例清單、數(shù)據(jù)庫實例清單、基礎(chǔ)軟件類型、基礎(chǔ)軟件版本、數(shù)據(jù)中心信息、機房信息、物理機信息、虛擬機信息、容器信息、網(wǎng)絡(luò)信息、線路信息和產(chǎn)品的容量規(guī)劃等配置信息。

產(chǎn)品安全中一般包括產(chǎn)品保護級別信息、訪問控制信息、出入口信息、對外服務(wù)信息和安全級別信息等配置信息。

服務(wù)質(zhì)量中一般包括業(yè)務(wù)容量信息、產(chǎn)品分級信息、服務(wù)級別信息、業(yè)務(wù)關(guān)鍵場景信息、業(yè)務(wù)關(guān)鍵路徑信息、系統(tǒng)可靠性方面的信息、業(yè)務(wù)可靠性方面的信息、業(yè)務(wù)黃金指標信息和服務(wù)監(jiān)控信息等配置信息。

架構(gòu)成熟度中一般包括容量瓶頸信息，可用性信息，安全風(fēng)險信息，監(jiān)控盲點信息，系統(tǒng)和數(shù)據(jù)庫集群信息，應(yīng)用狀態(tài)信息，多活和災(zāi)備信息，容器架構(gòu)信息，數(shù)據(jù)庫架構(gòu)信息，微服務(wù)架構(gòu)信息，系統(tǒng)交互信息，關(guān)鍵服務(wù)耦合信息，業(yè)務(wù)限流信息，系統(tǒng)熔斷信息，發(fā)布策略信息，應(yīng)用配置信息，業(yè)務(wù)驗證信息，網(wǎng)絡(luò)接入情況，以及多云部署信息等配置信息。

CMDB 的價值

在 CMDB 的價值體系中，配置價值已不再適合被過度放大。尤其在 DevOps 價值交付過程中， CMDB 更多承擔(dān)底座的作用，價值的體現(xiàn)需要 DevOps 和業(yè)務(wù)進行放大。因此， CMDB 的價值需要回歸本源，逐漸錨定到 DevOps 數(shù)據(jù)的范圍。CMDB 的內(nèi)在價值主要體現(xiàn)為數(shù)據(jù)的質(zhì)量和范圍，外在價值主要體現(xiàn)為場景驅(qū)動能力。

1 ）數(shù)據(jù)的質(zhì)量

在 CMDB 的落地和推廣過程中，數(shù)據(jù)質(zhì)量需要經(jīng)過前期調(diào)研、系統(tǒng)集成和數(shù)據(jù)治理等不同的階段來保證， IT 組織往往不擅長這些工作，因此，需要從技術(shù)層面和管理層面進行數(shù)據(jù)質(zhì)量的約束。在技術(shù)層面，需要對數(shù)據(jù)進行分解，通過數(shù)據(jù)的使用流程和使用場景進行反推和校驗；在管理層面，需要對數(shù)據(jù)的干系節(jié)點進行職責(zé)明確，通過技術(shù)手段進行數(shù)據(jù)的校正。

CMDB 獲取數(shù)據(jù)一般通過自動發(fā)現(xiàn)和人工錄入兩種方式。為了保證獲取數(shù)據(jù)的準確性，需要盡可能提高自動發(fā)現(xiàn)的能力，降低配置管理的難度。常見的數(shù)據(jù)源有云管理平臺、網(wǎng)絡(luò)管理平臺和負載均衡系統(tǒng)。對于人工錄入的數(shù)據(jù)，需要對數(shù)據(jù)進行大范圍流動，提高存量數(shù)據(jù)和增量數(shù)據(jù)的精度和透明度。通過數(shù)據(jù)的流動，實現(xiàn)場景消費的正向反饋，確保數(shù)據(jù)質(zhì)量穩(wěn)步提升。與此同時，在管理層面，以流程機制的方式定義場景約束，提升集中集成的能力。保證數(shù)據(jù)質(zhì)量的流程如圖 3-8 所示。

2 ）數(shù)據(jù)的范圍

數(shù)據(jù)的范圍主要依靠場景嵌入和流程約束來擴展。在 CMDB 的運行階段，場景的結(jié)合和流程的約束是重要環(huán)節(jié)。在通常情況下，場景的結(jié)合增加數(shù)據(jù)范圍的廣度，流程的約束增加數(shù)據(jù)范圍的精度。想要放大數(shù)據(jù)的范圍，就需要將 CMDB 嵌入大范圍的用戶場景中，降低數(shù)據(jù)的使用門檻，因此， CMDB 需要具備實時、準確、方便、結(jié)構(gòu)化處理數(shù)據(jù)的能力，讓使用者察覺不到 CMDB 的存在，降低 CMDB 的影響，通過流量回流的方式進行數(shù)據(jù)范圍的擴展。流程的約束通過資源申請和資產(chǎn)審計方式來實現(xiàn)，如常見的對計算資源、存儲資源和網(wǎng)絡(luò)資源的申請，需要通過流程方式對 CMDB 進行強依賴管理，并加大流程管控和數(shù)據(jù)審計的范圍，促使數(shù)據(jù)的范圍放大。

圖 3-8

3 ）數(shù)據(jù)的場景驅(qū)動

CMDB 的外在價值體現(xiàn)為有價值的場景驅(qū)動，如安全驅(qū)動，業(yè)務(wù)域保障驅(qū)動，自動化驅(qū)動， DevOps 集成驅(qū)動，以及容量管理和審計驅(qū)動。從對場景的選擇來看， CMDB 的場景具備數(shù)據(jù)輸出的典型特征。打通業(yè)務(wù)端和 IT 端的數(shù)據(jù)融合的通道，這也是以資源數(shù)據(jù)為基準構(gòu)建 DevOps 流水線方式的能力。在有價值的場景驅(qū)動中，可以實現(xiàn) IT 組織內(nèi)部的流程貫通和場景適配，也可以實現(xiàn)業(yè)務(wù)組織和 IT 組織在數(shù)據(jù)使用方面的整合。

CMDB 和 DevOps 的集成方法

CMDB 和 DevOps 的集成方法在業(yè)內(nèi)已形成共識，這些集成方法包括從架構(gòu)方面以應(yīng)用為中心、從模型方面以服務(wù)為中心和從能力輸出方面以業(yè)務(wù)為中心。

1 ）從架構(gòu)方面以應(yīng)用為中心

從應(yīng)用的角度，規(guī)劃和管理各種運維服務(wù)場景；通過全局視角，分析運維對象之間的關(guān)系。根據(jù)運維服務(wù)場景，建立架構(gòu)層級，分為應(yīng)用服務(wù)層、應(yīng)用邏輯層和基礎(chǔ)架構(gòu)層。對于分層信息，進行拓撲關(guān)系的梳理和映射。最終，以 DevOps 為載體，快速實現(xiàn)應(yīng)用資源內(nèi)外部的拓撲繪制，提升業(yè)務(wù)保障域的工作效能。運維服務(wù)場景架構(gòu)層級如圖 3-9 所示。

2 ）從模型方面以服務(wù)為中心

服務(wù)可以分為業(yè)務(wù)導(dǎo)向和技術(shù)導(dǎo)向，其中業(yè)務(wù)導(dǎo)向的服務(wù)以用戶角色為視角，技術(shù)導(dǎo)向的服務(wù)以生產(chǎn)角色為視角，通過業(yè)務(wù)系統(tǒng)的功能，打通端到端的服務(wù)。在模型方面，同樣以功能和服務(wù)為中心構(gòu)建模型，通過功能的升級和服務(wù)的提升，進行 CMDB 和 DevOps 的集成場景的擴展。

同時，通過用戶角色視角和生產(chǎn)角色視角，對組織中的業(yè)務(wù)服務(wù)進行橫向打通。在用戶角色視角方面，以業(yè)務(wù)為視角，通過產(chǎn)品、模塊和功能的下鉆，提供給用戶使用；在生產(chǎn)角色視角方面，以業(yè)務(wù)為視角，通過系統(tǒng)、應(yīng)用和服務(wù)的下鉆，提供產(chǎn)品交付，最終實現(xiàn)以服務(wù)為中心的模型構(gòu)建。以服務(wù)為中心的模型如圖 3-10 所示。

圖 3-9

圖 3-10

3 ）從能力輸出方面以業(yè)務(wù)為中心

以業(yè)務(wù)為中心的集成通常采取面向終態(tài)的方式，這種集成方式強調(diào) CMDB 的靈活性和可擴展能力，需要在 CMDB 數(shù)據(jù)模型的管理方面具備動態(tài)化和可配置化特征，能夠隨著業(yè)務(wù)的變化快速且靈活地進行 CMDB 數(shù)據(jù)模型的調(diào)整、擴展和修正，滿足交付流水線上各能力子域?qū)ε渲脭?shù)據(jù)使用深度和廣度的需求。另外， CMDB 需要提高數(shù)據(jù)的易用性，在使用場景中，實現(xiàn)低成本和高效率。CMDB 一般具備以下能力。

（ 1 ）模型動態(tài)擴展能力。配置項動態(tài)化，對象屬性上下游繼承。

（ 2 ）數(shù)據(jù)多維度關(guān)聯(lián)能力。通過數(shù)據(jù)屬性的上下游關(guān)聯(lián)，實現(xiàn)從單維數(shù)據(jù)到多維數(shù)據(jù)的轉(zhuǎn)化，形成多場景的數(shù)據(jù)鏈路。

（ 3 ） API 能力。通過 API ，實現(xiàn)全量數(shù)據(jù)接口輸出，快速匹配業(yè)務(wù)場景和提升第三方集成能力。

（ 4 ）自定義數(shù)據(jù)基線能力。以場景為邊界，形成自定義數(shù)據(jù)基線，通過數(shù)據(jù)的初態(tài)、中間態(tài)和終態(tài)的特征，展現(xiàn)數(shù)據(jù)的血緣關(guān)系和數(shù)據(jù)的流向關(guān)系。

CMDB 和 DevOps 的集成場景

CMDB 和 DevOps 的集成場景主要包括業(yè)務(wù)場景、架構(gòu)場景、部署場景、數(shù)據(jù)輸出場景和傳統(tǒng)的基礎(chǔ)架構(gòu)場景。在業(yè)務(wù)場景方面，基于業(yè)務(wù)訪問流的方式，對服務(wù)進行可視化呈現(xiàn)；在架構(gòu)場景方面，基于架構(gòu)視圖，對應(yīng)用的顆粒度進行整合，形成完整的業(yè)務(wù)和業(yè)務(wù)的全景視圖；在部署場景方面，包含應(yīng)用對應(yīng)的節(jié)點和組件，形成應(yīng)用的部署視圖；在數(shù)據(jù)輸出場景方面，包括 CMDB 提供的數(shù)據(jù)所有的對外輸出場景，該場景主要與其他集成場景進行單向和雙向的數(shù)據(jù)交互；傳統(tǒng)的基礎(chǔ)架構(gòu)場景是指對底層的基礎(chǔ)設(shè)施進行視圖輸出，并提供采集、查詢、存儲和展示功能。

在應(yīng)用方面， CMDB 輔助業(yè)務(wù)場景，通過 DevOps 驅(qū)動業(yè)務(wù)流程。在價值交付流水線中， CMDB 為各業(yè)務(wù)流程提供準確的配置數(shù)據(jù)。業(yè)務(wù)系統(tǒng)在架構(gòu)設(shè)計、容量管理、持續(xù)交付和業(yè)務(wù)域保障過程中，通過數(shù)據(jù)賦能，進行業(yè)務(wù)流程的落地。同時， CMDB 提供的數(shù)據(jù)的高階使用方式主要是多場景的數(shù)據(jù)關(guān)聯(lián)和通過端到端的視圖輔助 DevOps 在監(jiān)控領(lǐng)域進行根因分析、故障定位和快速“自愈”。在 DevOps 的度量和反饋環(huán)節(jié)，對 CMDB 提供的數(shù)據(jù)進行服務(wù)化運營，實現(xiàn)業(yè)務(wù)的運營分析和成本復(fù)盤，以及資源的容量規(guī)劃和管理。

隨著對 DevOps 的實踐不斷深入，以及數(shù)據(jù)不斷豐富， CMDB 的集成的選擇逐漸多樣化。從發(fā)展趨勢來看，面向應(yīng)用和面向業(yè)務(wù)是實現(xiàn) CMDB 和 DevOps 集成的核心驅(qū)動力。

運維服務(wù)流程的集成

經(jīng)過運維職責(zé)的多次演進，運維服務(wù)能力模型逐漸實現(xiàn)價值的錨定。該模型通過 SRE 和 DevOps 的重新定義，形成安全、穩(wěn)定、高效和低成本四大能力要素。

運維的主要職能是通過運維服務(wù)流程進行輸出，經(jīng)過業(yè)務(wù)反饋后形成有效的運維體系，在從傳統(tǒng)運維發(fā)展到互聯(lián)網(wǎng)運維的過程中，進行技術(shù)迭代和體系建設(shè)，最終實現(xiàn)高 SLA （ Service Level Agreement ，服務(wù)等級協(xié)議）和低成本的業(yè)務(wù)目標。在 DevOps 價值交付流水線中，運維服務(wù)流程主要體現(xiàn)為基礎(chǔ)支撐，并通過運維服務(wù)體系進行系統(tǒng)的可靠輸出和業(yè)務(wù)的連續(xù)輸出，這是 DevOps 整體服務(wù)框架輸出的“底座”。運維服務(wù)能力模型如圖 3-11 所示。

圖 3-11

在運維服務(wù)流程方面，需要解決下列 3 個問題。

（ 1 ）為什么需要運維服務(wù)流程？

（ 2 ）運維服務(wù)流程應(yīng)該如何設(shè)計、運行和處理問題？

（ 3 ）運維服務(wù)流程最終能夠帶來什么？

在傳統(tǒng)運維階段，運維能力子域和其他能力子域并無技術(shù)的融合，主要是通過資源輸出進行溝通和基本的運維體系的構(gòu)建，因此，運維服務(wù)能力模型呈現(xiàn)無狀態(tài)和不規(guī)范特點，不能為業(yè)務(wù)保障帶來質(zhì)的提升。在這個階段，往往通過制度進行約束和全局規(guī)范，價值輸出過度依靠人力和制度，只為結(jié)果負責(zé)，并不考慮效率。在協(xié)作方面，由于技術(shù)棧的差異和業(yè)務(wù)訴求的傳遞衰減，制度不能完全約束運維活動的整個過程，因此，需要運維服務(wù)流程進行端到端的貫通。

隨著 DevOps 理念的推廣，運維服務(wù)流程開始提升運維組織內(nèi)部的效率，同時更加關(guān)注能力子域之間的協(xié)作問題，這是自動化的開端。在這個階段，運維服務(wù)流程豐富了運維體系的內(nèi)容，通過流程驅(qū)動，提高了工作效率，同時帶來了制度的重構(gòu)，以技術(shù)和規(guī)范逐步對制度進行補充。在這個演進過程中，運維側(cè)越來越注重技術(shù)棧的延展和融合，通過技術(shù)來解決業(yè)務(wù)問題，人員逐步精簡，崗位職能逐步放大，技術(shù)落地成平臺，制度落地成服務(wù)流程，相對應(yīng)的，運維服務(wù)流程逐漸深入業(yè)務(wù)范疇。

在安全保障和穩(wěn)定方面，運維服務(wù)流程涵蓋了規(guī)范、資源和服務(wù) 3 個大類。其中規(guī)范是對流程、資源、服務(wù)、業(yè)務(wù)連續(xù)性和系統(tǒng)可靠性的統(tǒng)一標準化；服務(wù)體現(xiàn)在業(yè)務(wù)運維和技術(shù)運營兩個場景，具體以監(jiān)控告警、日志分析、服務(wù)預(yù)案、配置管理、持續(xù)集成和持續(xù)交付為主；資源包括計算、存儲、網(wǎng)絡(luò)、線路、容器和代碼托管方面，如圖 3-12 所示。

圖 3-12

創(chuàng)建運維服務(wù)流程的原因

在創(chuàng)建運維服務(wù)流程之前，我們需要了解創(chuàng)建運維服務(wù)流程的原因，即需要通過它解決什么問題，如表 3-2 所示。

表 3-2

在業(yè)務(wù)訴求方面，大多數(shù)企業(yè)的運維組織需要對業(yè)務(wù)連續(xù)性指標負責(zé)，協(xié)調(diào)各職能組織共同保證業(yè)務(wù)的連續(xù)性，并通過組織能力和技術(shù)手段保證系統(tǒng)的可靠性和系統(tǒng)的安全性。

在運維環(huán)境方面，由于公司的治理和業(yè)務(wù)的發(fā)展存在不確定性，因此基礎(chǔ)架構(gòu)、技術(shù)棧，以及組織之間的溝通和協(xié)調(diào)存在一定的問題，最終影響企業(yè)可持續(xù)、穩(wěn)定和健康發(fā)展，具體表現(xiàn)為產(chǎn)品線隨企業(yè)的發(fā)展呈線性發(fā)展，技術(shù)架構(gòu)的種類繁多。

運維組織最需要解決的問題出現(xiàn)在人員方面。人是運維服務(wù)流程中最需要約束的點。日常的運維活動最重要的載體不是技術(shù)棧，而是人。由于運維人員的能力參差不齊，運維習(xí)慣存在差異，因此需要運維服務(wù)流程進行規(guī)范的約束和運維體系的固化，從而提升運維效率和降低運維風(fēng)險，最終通過業(yè)務(wù)進行運維能力的輸出和放大。

創(chuàng)建運維服務(wù)流程時的目標

運維服務(wù)能力模型的 4 個能力要素并不等同于運維服務(wù)流程的目標，兩者存在包含與被包含的關(guān)系，同時在考核方面存在可量化和可持續(xù)的區(qū)別，如在安全性和穩(wěn)定性較高時，需要可持續(xù)地進行保持，而非量化地進行比較。總體來說，創(chuàng)建運維服務(wù)流程的目的是在合規(guī)和敏捷，以及安全和穩(wěn)定中尋求平衡，最終通過 DevOps 實現(xiàn)對價值交付中業(yè)務(wù)保障域質(zhì)量的控制。

在創(chuàng)建運維服務(wù)流程時，有 4 個目標，分別是完整、易用、高效和安全。完整是指流程的完整性，即需要覆蓋運維能力輸出過程中的絕大數(shù)流程。易用是指流程簡單、好用，如果操作流程比較復(fù)雜，那么，在運維能力輸出過程中，流程的使用者需要付出更高的學(xué)習(xí)成本，效果也可能達不到預(yù)期，影響最終的能力輸出。高效是指流程流轉(zhuǎn)過程中需要技術(shù)加持，及時給予流程使用者反饋。安全是運維服務(wù)能力模型的 4 個能力要素之一，因此，在流程方面，需要考慮安全因素。

表 3-3 中列出 DevOps 內(nèi)嵌的常用的運維服務(wù)。

表 3-3

建立運維服務(wù)流程體系

運維服務(wù)流程體系本質(zhì)上是運維文化和運維職責(zé)的延展。從某種程度上來看，和 ITIL （ Information Technology Infrastructure Library ）的理念是相通的。運維服務(wù)流程和運維流程的區(qū)別是運維價值輸出方式和運維觀念的不同，前者貫穿價值交付鏈路，后者貫穿運維交付鏈路。

在建立運維服務(wù)流程體系時，我們需要考慮下面 4 個方面：調(diào)查服務(wù)需求，設(shè)計相匹配的服務(wù)級別；通過技術(shù)賦能，建設(shè)高效的運維服務(wù)團隊；創(chuàng)建運維服務(wù)目錄，全面受理運維服務(wù)請求；規(guī)范對事件和問題的管理，形成總體閉環(huán)。

在服務(wù)級別方面，需要協(xié)同價值交付鏈路中的各能力子域從用戶角度、業(yè)務(wù)角度、系統(tǒng)交付角度、服務(wù)角度和基礎(chǔ)架構(gòu)角度分別對服務(wù)進行分級，并針對分級結(jié)果形成服務(wù)級別協(xié)議和提出服務(wù)承諾。

在建設(shè)運維服務(wù)團隊方面，管理者需要具備“小而美、少而精”的團隊建設(shè)思想，按照服務(wù)的級別和層次，選擇合適的技術(shù)工具，規(guī)劃遞進的技術(shù)迭代路線，配備專業(yè)的運維人員，建設(shè)層次分明和具備可持續(xù)特性的運維服務(wù)團隊。

在運維服務(wù)目錄方面，打破 IT 組織各能力子域之間的壁壘，構(gòu)建 IT 組織和業(yè)務(wù)組織的溝通渠道，提供中心聯(lián)絡(luò)點，通過服務(wù)方式對外賦能，進行有價值的、高效的輸出，同時對運維所要達成的安全和穩(wěn)定指標進行內(nèi)部控制。

在事件和問題閉環(huán)方面，需要具備完善的監(jiān)控手段，并根據(jù)服務(wù)級別制訂對應(yīng)的應(yīng)急處置預(yù)案，向價值交付鏈路的各能力子域提供對事件和問題的透明管理，推動形成閉環(huán)，最大限度地降低對業(yè)務(wù)和用戶的影響，同時避免發(fā)生同類問題。

運維服務(wù)流程和 DevOps 的集成

通過將運維服務(wù)流程和 DevOps 集成，在 DevOps 層面形成 DevOps 流程，并且面向價值交付流水線所有的職能領(lǐng)域，在運維應(yīng)用層面，形成一站式運維平臺，通過 DevOps 服務(wù)目錄的方式進行 運維服務(wù)能力的輸出。

資源輸出、自動化運維工具、運維規(guī)范和運維流程的積木式整合可以對內(nèi)實現(xiàn)安全和穩(wěn)定，對外實現(xiàn)高效和低成本，涉及基礎(chǔ)架構(gòu)、支撐平臺、應(yīng)用運維和業(yè)務(wù)運維的各個節(jié)點。運維服務(wù)流程和 DevOps 的集成架構(gòu)如圖 3-13 所示。

圖 3-13

運維服務(wù)流程和 DevOps 的集成架構(gòu)分為兩層：工具層和服務(wù)層，其中服務(wù)層主要通過流程內(nèi)嵌方式實現(xiàn) SRE 和 DevOps 服務(wù)，并管理運維的資源、流程和服務(wù)，工具層通過工具實現(xiàn)運維的自動化，并為服務(wù)層提供運維服務(wù)流程體系的運維能力輸出，實現(xiàn)安全、穩(wěn)定的運維服務(wù)，提升價值交付流水線的用戶體驗水平。