《DevOps权威指南：IT效能“新基建”》-支撑管理（3.2）

作者：顾黄亮 （现任苏宁消费金融安全运维部总经理）

【声明】为了能让大家更好的学习Devops以及深入了解应用Devops的实践案例，《DevOps权威指南：IT效能“新基建”》作者顾黄亮先生授权twt社区进行该书部分内容连载。内容包括DevOps的基本概念，DevOps的工具集，支撑管理，敏捷开发，持续集成和测试，持续部署和持续交付，代码质量和安全，DevOps的度量体系，持续改进和反馈，DevOps最佳实践，以及DevOps的后续发展。

## 3.3 CMDB 集成

在 DevOps 的实践过程中，流水线的构建具有 4 种方式：以项目批次为基准的价值交付流水线、以资源数据为基准的交付流水线、以支撑数据为基准的交付流水线和以交付数据为基准的交付流水线，其中以资源数据为基准的交付流水线方式主要依托 CMDB 。在 DevOps 的集成体系中， CMDB 是基础支撑数据的来源，也是基础元数据平台。

3.3.1 CMDB 概述

CMDB （ Configuration Management Database ，配置管理数据库）在传统企业中称为资产管理系统，在云计算或互联网企业中称为云配置中心。 CMDB 可以对企业内外部的 IT 资源进行识别、控制、维护和存储，从而实现对 IT 资源的高效控制。另外， CMDB 可以管理企业不断变化的 IT 资源和 IT 服务，还可以为问题管理、事件管理、交付管理和业务连续性管理提供完善且准确的配置信息。

从本质上来说， CMDB 通过收集 IT 资源的各种信息，并根据收集的信息对项目或产品的价值交付进行数据输出和赋能。 CMDB 在能力输出方面经过多次演进，即从基本的配置管理，到场景消费、应用驱动，再到为价值交付赋能。在实践过程中，落地后的实际用途和预期存在较大出入，纠其原因，不外乎 CMDB 因运维职能的泛化而导致数据输出能力的下降。 CMDB 的建设通常需要打通 IT 资源使用链路上的各个能力子域，因此需要组织协调 和流程推进，而运维职能范围的不断拓展，导致数据的标签和口径在一定程度上失真，如数据不准确、数据收集不及时、对接困难和数据输出薄弱等情况，导致最终效果达不到预期。

3.3.2 CMDB 的作用

CMDB 的使用场景较多，如配置管理在 IT 组织内部的应用，因此，我们需要梳理其主要使用场景，从而提升 IT 资源使用的透明度和准确度。同时，我们需要通过配置数据进行价值输出，通过提供价值交付流水线进行反向集成，如自动化发布、数据查询、资产审计、容量管理和全链路监控。常见的场景主要有两类：流程场景和数据场景。流程场景主要包括运维自动化的集成（需要 CMDB 提供系统的情况和系统资源的情况）、监控系统的集成（需要 CMDB 提供系统之间的关系和系统的 IP 地址等数据）和运维流程的集成（需要 CMDB 提供配置对象和数据的相关信息）。数据场景一般是指通过 CMDB 提供的数据进行高阶使用，也就是将 CMDB 的数据通过 API 方式对其他第三方系统进行输出，形成基础模块，提供统一服务入口，如常见的资源管理过程可视化，以及对 IT 资源进行查询和分类统计。

在传统行业中，运维管理流程是 IT 组织内部条目最多、范围最广的流程场景， CMDB 需要向运维管理提供数据的支撑服务，以及 IT 资源信息的输入、变更和存储。运维管理分为事件管理、问题管理、变更管理、配置管理和资产管理， CMDB 在它们中起到的作用如表 3-1 所示。

表 3-1

在能力子域方面， CMDB 的数据覆盖率取决于受众人群的类型， CMDB 的数据主要分为产品目录，产品团队，资源和容量，产品安全，服务质量，以及架构成熟度多个维度。

产品目录中一般包括系统标识、系统名称、运行状态、系统交互关系、版本信息、产品干系人、产品属主、产品功能、部署位置、系统用户范围和系统语言等配置信息。

产品团队中一般包括团队组织、人员工号和第三方支持团队信息等配置信息。

资源和容量中一般包括系统实例清单、中间件实例清单、数据库实例清单、基础软件类型、基础软件版本、数据中心信息、机房信息、物理机信息、虚拟机信息、容器信息、网络信息、线路信息和产品的容量规划等配置信息。

产品安全中一般包括产品保护级别信息、访问控制信息、出入口信息、对外服务信息和安全级别信息等配置信息。

服务质量中一般包括业务容量信息、产品分级信息、服务级别信息、业务关键场景信息、业务关键路径信息、系统可靠性方面的信息、业务可靠性方面的信息、业务黄金指标信息和服务监控信息等配置信息。

架构成熟度中一般包括容量瓶颈信息，可用性信息，安全风险信息，监控盲点信息，系统和数据库集群信息，应用状态信息，多活和灾备信息，容器架构信息，数据库架构信息，微服务架构信息，系统交互信息，关键服务耦合信息，业务限流信息，系统熔断信息，发布策略信息，应用配置信息，业务验证信息，网络接入情况，以及多云部署信息等配置信息。

3.3.3 CMDB 的价值

在 CMDB 的价值体系中，配置价值已不再适合被过度放大。尤其在 DevOps 价值交付过程中， CMDB 更多承担底座的作用，价值的体现需要 DevOps 和业务进行放大。因此， CMDB 的价值需要回归本源，逐渐锚定到 DevOps 数据的范围。 CMDB 的内在价值主要体现为数据的质量和范围，外在价值主要体现为场景驱动能力。

1 ）数据的质量

在 CMDB 的落地和推广过程中，数据质量需要经过前期调研、系统集成和数据治理等不同的阶段来保证， IT 组织往往不擅长这些工作，因此，需要从技术层面和管理层面进行数据质量的约束。在技术层面，需要对数据进行分解，通过数据的使用流程和使用场景进行反推和校验；在管理层面，需要对数据的干系节点进行职责明确，通过技术手段进行数据的校正。

CMDB 获取数据一般通过自动发现和人工录入两种方式。为了保证获取数据的准确性，需要尽可能提高自动发现的能力，降低配置管理的难度。常见的数据源有云管理平台、网络管理平台和负载均衡系统。对于人工录入的数据，需要对数据进行大范围流动，提高存量数据和增量数据的精度和透明度。通过数据的流动，实现场景消费的正向反馈，确保数据质量稳步提升。与此同时，在管理层面，以流程机制的方式定义场景约束，提升集中集成的能力。保证数据质量的流程如图 3-8 所示。

2 ）数据的范围

数据的范围主要依靠场景嵌入和流程约束来扩展。在 CMDB 的运行阶段，场景的结合和流程的约束是重要环节。在通常情况下，场景的结合增加数据范围的广度，流程的约束增加数据范围的精度。想要放大数据的范围，就需要将 CMDB 嵌入大范围的用户场景中，降低数据的使用门槛，因此， CMDB 需要具备实时、准确、方便、结构化处理数据的能力，让使用者察觉不到 CMDB 的存在，降低 CMDB 的影响，通过流量回流的方式进行数据范围的扩展。流程的约束通过资源申请和资产审计方式来实现，如常见的对计算资源、存储资源和网络资源的申请，需要通过流程方式对 CMDB 进行强依赖管理，并加大流程管控和数据审计的范围，促使数据的范围放大。

图 3-8

3 ）数据的场景驱动

CMDB 的外在价值体现为有价值的场景驱动，如安全驱动，业务域保障驱动，自动化驱动， DevOps 集成驱动，以及容量管理和审计驱动。从对场景的选择来看， CMDB 的场景具备数据输出的典型特征。打通业务端和 IT 端的数据融合的通道，这也是以资源数据为基准构建 DevOps 流水线方式的能力。在有价值的场景驱动中，可以实现 IT 组织内部的流程贯通和场景适配，也可以实现业务组织和 IT 组织在数据使用方面的整合。

3.3.4 CMDB 和 DevOps 的集成方法

CMDB 和 DevOps 的集成方法在业内已形成共识，这些集成方法包括从架构方面以应用为中心、从模型方面以服务为中心和从能力输出方面以业务为中心。

1 ）从架构方面以应用为中心

从应用的角度，规划和管理各种运维服务场景；通过全局视角，分析运维对象之间的关系。根据运维服务场景，建立架构层级，分为应用服务层、应用逻辑层和基础架构层。对于分层信息，进行拓扑关系的梳理和映射。最终，以 DevOps 为载体，快速实现应用资源内外部的拓扑绘制，提升业务保障域的工作效能。运维服务场景架构层级如图 3-9 所示。

2 ）从模型方面以服务为中心

服务可以分为业务导向和技术导向，其中业务导向的服务以用户角色为视角，技术导向的服务以生产角色为视角，通过业务系统的功能，打通端到端的服务。在模型方面，同样以功能和服务为中心构建模型，通过功能的升级和服务的提升，进行 CMDB 和 DevOps 的集成场景的扩展。

同时，通过用户角色视角和生产角色视角，对组织中的业务服务进行横向打通。在用户角色视角方面，以业务为视角，通过产品、模块和功能的下钻，提供给用户使用；在生产角色视角方面，以业务为视角，通过系统、应用和服务的下钻，提供产品交付，最终实现以服务为中心的模型构建。以服务为中心的模型如图 3-10 所示。

图 3-9

图 3-10

3 ）从能力输出方面以业务为中心

以业务为中心的集成通常采取面向终态的方式，这种集成方式强调 CMDB 的灵活性和可扩展能力，需要在 CMDB 数据模型的管理方面具备动态化和可配置化特征，能够随着业务的变化快速且灵活地进行 CMDB 数据模型的调整、扩展和修正，满足交付流水线上各能力子域对配置数据使用深度和广度的需求。另外， CMDB 需要提高数据的易用性，在使用场景中，实现低成本和高效率。 CMDB 一般具备以下能力。

（ 1 ）模型动态扩展能力。配置项动态化，对象属性上下游继承。

（ 2 ）数据多维度关联能力。通过数据属性的上下游关联，实现从单维数据到多维数据的转化，形成多场景的数据链路。

（ 3 ） API 能力。通过 API ，实现全量数据接口输出，快速匹配业务场景和提升第三方集成能力。

（ 4 ）自定义数据基线能力。以场景为边界，形成自定义数据基线，通过数据的初态、中间态和终态的特征，展现数据的血缘关系和数据的流向关系。

3.3.5 CMDB 和 DevOps 的集成场景

CMDB 和 DevOps 的集成场景主要包括业务场景、架构场景、部署场景、数据输出场景和传统的基础架构场景。在业务场景方面，基于业务访问流的方式，对服务进行可视化呈现；在架构场景方面，基于架构视图，对应用的颗粒度进行整合，形成完整的业务和业务的全景视图；在部署场景方面，包含应用对应的节点和组件，形成应用的部署视图；在数据输出场景方面，包括 CMDB 提供的数据所有的对外输出场景，该场景主要与其他集成场景进行单向和双向的数据交互；传统的基础架构场景是指对底层的基础设施进行视图输出，并提供采集、查询、存储和展示功能。

在应用方面， CMDB 辅助业务场景，通过 DevOps 驱动业务流程。在价值交付流水线中， CMDB 为各业务流程提供准确的配置数据。业务系统在架构设计、容量管理、持续交付和业务域保障过程中，通过数据赋能，进行业务流程的落地。同时， CMDB 提供的数据的高阶使用方式主要是多场景的数据关联和通过端到端的视图辅助 DevOps 在监控领域进行根因分析、故障定位和快速“自愈”。在 DevOps 的度量和反馈环节，对 CMDB 提供的数据进行服务化运营，实现业务的运营分析和成本复盘，以及资源的容量规划和管理。

随着对 DevOps 的实践不断深入，以及数据不断丰富， CMDB 的集成的选择逐渐多样化。从发展趋势来看，面向应用和面向业务是实现 CMDB 和 DevOps 集成的核心驱动力。

3.4 运维服务流程的集成

经过运维职责的多次演进，运维服务能力模型逐渐实现价值的锚定。该模型通过 SRE 和 DevOps 的重新定义，形成安全、稳定、高效和低成本四大能力要素。

运维的主要职能是通过运维服务流程进行输出，经过业务反馈后形成有效的运维体系，在从传统运维发展到互联网运维的过程中，进行技术迭代和体系建设，最终实现高 SLA （ Service Level Agreement ，服务等级协议）和低成本的业务目标。在 DevOps 价值交付流水线中，运维服务流程主要体现为基础支撑，并通过运维服务体系进行系统的可靠输出和业务的连续输出，这是 DevOps 整体服务框架输出的“底座”。运维服务能力模型如图 3-11 所示。

图 3-11

在运维服务流程方面，需要解决下列 3 个问题。

（ 1 ）为什么需要运维服务流程？

（ 2 ）运维服务流程应该如何设计、运行和处理问题？

（ 3 ）运维服务流程最终能够带来什么？

在传统运维阶段，运维能力子域和其他能力子域并无技术的融合，主要是通过资源输出进行沟通和基本的运维体系的构建，因此，运维服务能力模型呈现无状态和不规范特点，不能为业务保障带来质的提升。在这个阶段，往往通过制度进行约束和全局规范，价值输出过度依靠人力和制度，只为结果负责，并不考虑效率。在协作方面，由于技术栈的差异和业务诉求的传递衰减，制度不能完全约束运维活动的整个过程，因此，需要运维服务流程进行端到端的贯通。

随着 DevOps 理念的推广，运维服务流程开始提升运维组织内部的效率，同时更加关注能力子域之间的协作问题，这是自动化的开端。在这个阶段，运维服务流程丰富了运维体系的内容，通过流程驱动，提高了工作效率，同时带来了制度的重构，以技术和规范逐步对制度进行补充。在这个演进过程中，运维侧越来越注重技术栈的延展和融合，通过技术来解决业务问题，人员逐步精简，岗位职能逐步放大，技术落地成平台，制度落地成服务流程，相对应的，运维服务流程逐渐深入业务范畴。

在安全保障和稳定方面，运维服务流程涵盖了规范、资源和服务 3 个大类。其中规范是对流程、资源、服务、业务连续性和系统可靠性的统一标准化；服务体现在业务运维和技术运营两个场景，具体以监控告警、日志分析、服务预案、配置管理、持续集成和持续交付为主；资源包括计算、存储、网络、线路、容器和代码托管方面，如图 3-12 所示。

图 3-12

3.4.1 创建运维服务流程的原因

在创建运维服务流程之前，我们需要了解创建运维服务流程的原因，即需要通过它解决什么问题，如表 3-2 所示。

表 3-2

在业务诉求方面，大多数企业的运维组织需要对业务连续性指标负责，协调各职能组织共同保证业务的连续性，并通过组织能力和技术手段保证系统的可靠性和系统的安全性。

在运维环境方面，由于公司的治理和业务的发展存在不确定性，因此基础架构、技术栈，以及组织之间的沟通和协调存在一定的问题，最终影响企业可持续、稳定和健康发展，具体表现为产品线随企业的发展呈线性发展，技术架构的种类繁多。

运维组织最需要解决的问题出现在人员方面。人是运维服务流程中最需要约束的点。日常的运维活动最重要的载体不是技术栈，而是人。由于运维人员的能力参差不齐，运维习惯存在差异，因此需要运维服务流程进行规范的约束和运维体系的固化，从而提升运维效率和降低运维风险，最终通过业务进行运维能力的输出和放大。

3.4.2 创建运维服务流程时的目标

运维服务能力模型的 4 个能力要素并不等同于运维服务流程的目标，两者存在包含与被包含的关系，同时在考核方面存在可量化和可持续的区别，如在安全性和稳定性较高时，需要可持续地进行保持，而非量化地进行比较。总体来说，创建运维服务流程的目的是在合规和敏捷，以及安全和稳定中寻求平衡，最终通过 DevOps 实现对价值交付中业务保障域质量的控制。

在创建运维服务流程时，有 4 个目标，分别是完整、易用、高效和安全。完整是指流程的完整性，即需要覆盖运维能力输出过程中的绝大数流程。易用是指流程简单、好用，如果操作流程比较复杂，那么，在运维能力输出过程中，流程的使用者需要付出更高的学习成本，效果也可能达不到预期，影响最终的能力输出。高效是指流程流转过程中需要技术加持，及时给予流程使用者反馈。安全是运维服务能力模型的 4 个能力要素之一，因此，在流程方面，需要考虑安全因素。

表 3-3 中列出 DevOps 内嵌的常用的运维服务。

表 3-3

3.4.3 建立运维服务流程体系

运维服务流程体系本质上是运维文化和运维职责的延展。从某种程度上来看，和 ITIL （ Information Technology Infrastructure Library ）的理念是相通的。运维服务流程和运维流程的区别是运维价值输出方式和运维观念的不同，前者贯穿价值交付链路，后者贯穿运维交付链路。

在建立运维服务流程体系时，我们需要考虑下面 4 个方面：调查服务需求，设计相匹配的服务级别；通过技术赋能，建设高效的运维服务团队；创建运维服务目录，全面受理运维服务请求；规范对事件和问题的管理，形成总体闭环。

在服务级别方面，需要协同价值交付链路中的各能力子域从用户角度、业务角度、系统交付角度、服务角度和基础架构角度分别对服务进行分级，并针对分级结果形成服务级别协议和提出服务承诺。

在建设运维服务团队方面，管理者需要具备“小而美、少而精”的团队建设思想，按照服务的级别和层次，选择合适的技术工具，规划递进的技术迭代路线，配备专业的运维人员，建设层次分明和具备可持续特性的运维服务团队。

在运维服务目录方面，打破 IT 组织各能力子域之间的壁垒，构建 IT 组织和业务组织的沟通渠道，提供中心联络点，通过服务方式对外赋能，进行有价值的、高效的输出，同时对运维所要达成的安全和稳定指标进行内部控制。

在事件和问题闭环方面，需要具备完善的监控手段，并根据服务级别制订对应的应急处置预案，向价值交付链路的各能力子域提供对事件和问题的透明管理，推动形成闭环，最大限度地降低对业务和用户的影响，同时避免发生同类问题。

3.4.4 运维服务流程和 DevOps 的集成

通过将运维服务流程和 DevOps 集成，在 DevOps 层面形成 DevOps 流程，并且面向价值交付流水线所有的职能领域，在运维应用层面，形成一站式运维平台，通过 DevOps 服务目录的方式进行 运维服务能力的输出。

资源输出、自动化运维工具、运维规范和运维流程的积木式整合可以对内实现安全和稳定，对外实现高效和低成本，涉及基础架构、支撑平台、应用运维和业务运维的各个节点。运维服务流程和 DevOps 的集成架构如图 3-13 所示。

图 3-13

运维服务流程和 DevOps 的集成架构分为两层：工具层和服务层，其中服务层主要通过流程内嵌方式实现 SRE 和 DevOps 服务，并管理运维的资源、流程和服务，工具层通过工具实现运维的自动化，并为服务层提供运维服务流程体系的运维能力输出，实现安全、稳定的运维服务，提升价值交付流水线的用户体验水平。

全部连载

《DevOps权威指南：IT效能“新基建”》-前言
《DevOps权威指南：IT效能“新基建”》-认识DevOps（1.1）
《DevOps权威指南：IT效能“新基建”》-认识DevOps（1.2）
《DevOps权威指南：IT效能“新基建”》-认识DevOps（1.3）
《DevOps权威指南：IT效能“新基建”》-支撑管理（3.1）
《DevOps权威指南：IT效能“新基建”》-支撑管理（3.2）
《DevOps权威指南：IT效能“新基建”》-支撑管理（3.3）
《DevOps权威指南：IT效能“新基建”》-DevOps的度量体系（8.1）
《DevOps权威指南：IT效能“新基建”》-DevOps的度量体系（8.2）
《DevOps权威指南：IT效能“新基建”》-DevOps的度量体系（8.3）