CMDB 集成

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

CMDB 概述

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

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

CMDB 的作用

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

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

表 3-1

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

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

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

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

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

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

架構(gòu)成熟度中一般包括容量瓶頸信息，可用性信息，安全風(fēng)險(xiǎn)信息，監(jiān)控盲點(diǎ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ù)驗(yàn)證信息，網(wǎng)絡(luò)接入情況，以及多云部署信息等配置信息。

CMDB 的價(jià)值

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

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

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

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

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

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

圖 3-8

3 ）數(shù)據(jù)的場(chǎng)景驅(qū)動(dòng)

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

CMDB 和 DevOps 的集成方法

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

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

從應(yīng)用的角度，規(guī)劃和管理各種運(yùn)維服務(wù)場(chǎng)景；通過全局視角，分析運(yùn)維對(duì)象之間的關(guān)系。根據(jù)運(yùn)維服務(wù)場(chǎng)景，建立架構(gòu)層級(jí)，分為應(yīng)用服務(wù)層、應(yīng)用邏輯層和基礎(chǔ)架構(gòu)層。對(duì)于分層信息，進(jìn)行拓?fù)潢P(guān)系的梳理和映射。最終，以 DevOps 為載體，快速實(shí)現(xiàn)應(yīng)用資源內(nèi)外部的拓?fù)淅L制，提升業(yè)務(wù)保障域的工作效能。運(yùn)維服務(wù)場(chǎng)景架構(gòu)層級(jí)如圖 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)建模型，通過功能的升級(jí)和服務(wù)的提升，進(jìn)行 CMDB 和 DevOps 的集成場(chǎng)景的擴(kuò)展。

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

圖 3-9

圖 3-10

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

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

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

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

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

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

CMDB 和 DevOps 的集成場(chǎng)景

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

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

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

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

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

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

圖 3-11

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

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

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

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

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

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

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

圖 3-12

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

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

表 3-2

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

在運(yùn)維環(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)的種類繁多。

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

創(chuàng)建運(yùn)維服務(wù)流程時(shí)的目標(biāo)

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

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

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

表 3-3

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

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

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

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

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

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

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

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

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

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

圖 3-13

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