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

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

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

## 3.5 云管理平台集成

云计算和微服务在 DevOps 的发展过程中起到了重要作用。谈及云计算，不得不提云管理平台。云管理平台自身也在不断发展，工具的集成和拥有的 API 能力逐步形成 DevOps 效应。在很多企业中，基于云管理平台，实现 DevOps 能力，这和企业的云计算使用方式形成了耦合关系。

3.5.1 云管理平台的 定义

随着云计算业态的快速发展，云管理平台的定义在不断迭代。在 Gartner 相关的最新报告中，云管理平台有了新的定义。云管理平台（ Cloud Management Platform ， CMP ）是一种管理公有云、私有云和混合云环境的整合性产品。企业或组织能够通过它统一管理多云服务和资源。云管理平台的主要能力包括对公有云、私有云、混合云和多云环境进行统一管理和调度，提供系统映像、计量计费，以及通过既定策略优化工作负载。随着云管理平台的发展，更先进的云管理平台可以与第三方系统进行对接和集成，包括提供 DevOps 能力领域中的 服务目录、 API 和数据的接入 / 接出，支持对存储和网络资源的配置，允许通过服务治理加强资源管理，并提供针对云计算的高级监控，提高云计算资源的性能和可用性。

根据最新的 Gartner 关于云计算的报告，云管理平台的能力主要体现在 7 个方面，分别为资源的提供和调度，云资源的配置和分类，服务管理，监控和分析，成本的管理和优化，云迁移和容灾备份，以及身份认证和安全合规管理。这些能力和 DevOps 的能力存在交叉，主要体现在资源管理、服务管理、成本管理和安全合规管理方面。

在价值层面， DevOps 能够提升组织级的效能和质量，助推企业发展，云管理平台能够增强对 IT 资源的管理能力，提高 IT 资源的利用率，满足企业对大规模计算的算力要求，最终推动业务发展。由此可见， DevOps 的价值范围更大，云管理平台需要和 DevOps 进行结合，实现云计算和其他能力子域的价值交互，提高底座的敏捷性、扩展性和规范性，最终提升交付的能力和价值。

3.5.2 云管理平台的种类

从云计算类型的角度，云管理平台可以分为公有云管理平台、私有云管理平台和混合云管理平台。从商业模式的角度，云管理平台可以分为商用云管理平台和开源云管理平台，介绍如下。

1 ．商用云管理平台

典型的商用云管理平台有 VMware 。在 VMware 的技术体系中，虚拟化平台 vCenter 管理整个资源，相当于资源管理层， vRealize Automation 为云管理平台，管理虚拟化平台。在能力输出方面， vRealize Automation 提供针对 API 功能的自服务和统一服务目录，支持不同类型的私有云和公有云，以及对容器的管理。根据 VMware 官方的介绍， vRealize Automation 和 VMware 的虚拟化技术强耦合， vRealize Automation 通过抽象的底层实现技术，提供可视化和可拖拽的设计画布，为各种应用提供预构建的组件集合，并提供极佳的用户体验和服务能力。以 VMware 为代表的云管理平台架构如图 3-14 所示。

图 3-14

2 ．开源云管理平台

开源云管理平台的典型代表是 OpenStack 。利用 OpenStack 内部多个不同类型的组件，可以对接不同的资源。在 OpenStack 的基础上，进行封装，形成开源云管理平台。开源云管理平台在逻辑层面分成统一资源层和服务抽象层。统一资源层的作用是利用 OpenStack 各组件对资源进行池化和管理，服务抽象层的作用是通过各组件的 API 对资源进行调用和抽象，将不同的基础架构资源、 IT 服务、编排策略和动态优化策略通过 API 方式进行汇聚和组合，便于场景调用。在开源云管理平台的能力输出方面，更需要通过与自动化运维和监控等工具的集成对赋能进行放大，打造更强的输出能力。以 OpenStack 技术体系为代表的云管理平台 架构如图 3-15 所示。

图 3-15

3.5.3 云管理平台的定位和边界

由于云管理平台体系、运维自动化体系和 DevOps 体系存在多种交叉，因此云管理平台的定位并非绝对。在实践过程中，我们根据实际情况选择云管理平台的建设方法和落地方式。从技术层面来看，对于云管理平台的定位，存在 3 个方向，分别是云管理平台在自动化运维体系中是什么定位，云管理平台能够为自动化运维体系和 DevOps 体系解决什么问题；云管理平台的管理边界和功能边界是否存在交叉渗透，面向对象是否会带来信息安全方面的威胁；云管理平台和 DevOps 体系在落地过程中是否存在重复建设的情况，以及如何做到双向集成。

下面对云管理平台体系、自动化运维体系和 DevOps 体系进行对比。

在如图 3-16 所示的云管理平台体系中，我们可以看出云管理平台的主要功能包括统一管理和调度，提供系统镜像，进行计费，以及通过既定策略进行负载均衡。

在如图 3-17 所示的自动化运维体系中，明显可以看出资源管理和运维服务流程管理的划分。运维服务流程管理包括服务流程、容量管理和服务管理，资源管理的对象主要包括计算资源、存储资源和网络资源，数据中心管理分为本地数据中心管理和云数据中心管理。

在如图 3-18 所示的 DevOps 体系中，明显可以看出云管理平台和自动化运维的集成情况，运维管理功能明显向横向扩展。

云管理平台体系、自动化运维体系和 DevOps 体系的关系呈现递增扩展的特点，因此它们的边界并不是非常明显，其中有众多交叉的部分，如 CMDB 、服务流程、作业平台、仓库管理和自动化工具。随着云管理平台体系、自动化运维体系和 DevOps 体系范围的扩大，不断推动交叉部分能力的放大，如资源整合能力的放大，提高资源利用率；资源管理能力的放大，提高资源调配的灵活性；交付能力的放大，放大 IT 组织持续交付的能力；部署能力的放大，提供更多的部署策略和实现部署的多样性；服务目录能力的放大，增强服务的输出能力。

图 3-16

图 3-17

图 3-18

上述交叉关系带来了边界问题。随着云管理平台的理念和技术的发展，边界逐渐模糊，因此，从功能扩展的角度来说，云管理平台的定位、云管理平台的建设、云管理平台的使用和云管理平台的扩展给打造 DevOps 价值输出能力带来了管理方面的困难。在定位方面，随着云管理平台产品能力的不断增强，能力方面已经超出了云管理平台的范畴，在通用的运维体系中，逐渐存在云管理平台体系、自动化运维体系和 DevOps 体系相互融合的困难，在海量资源管理和流程闭环方面，表现尤为突出。在建设方面，由于技术原因，导致实践风险加大。功能越多，产品越“臃肿”，导致和第三方系统集成时的交互越来越困难。在扩展方面，复杂场景下的多能力子域会逐渐暴露技术耦合问题，如新框架和新协议会导致底层技术不兼容，这会给后续开发带来更大挑战，同时，自主掌控能力会逐渐变弱。

3.5.4 云管理平台和 DevOps 的集成

从 本质上来说，云管理平台和 DevOps 的集成是合理地利用云管理平台的价值。这种价值是狭义上的价值，并非广义上对云管理平台进行放大的价值，也可以称为虚荣性的价值。

在云计算发展的成熟期，引进云管理平台的初衷是明确的，对云计算资源进行统一管理是云管理平台的核心能力，主要有实现动态的、弹性的资源管理，实现按需的、自助的和可优化的运营管理，实现多租户的、可与流程对接的服务目录门户，实现对资源管理、资源编排和资源交付的监控。

在云管理平台与 DevOps 对接的过程中，我们需要关注下列几点。

（ 1 ）在规划和设计过程中，将交叉的功能进行复用，避免重复建设，采取大 DevOps 体系和小云管理的规划思路，对云管理采取工具化和底座化的方式进行构建。

（ 2 ）通过 DevOps 体系，向云管理平台提供管理和赋能，基于 DevOps 的工具链，对云管理平台进行工具能力输出。

（ 3 ）在集成和实施过程中，需要对云管理平台的自身价值进行分层，通过云管理平台进行向下的垂直纳管，驱动各类资源，横向提供目录服务和流程服务，纵向提供管理服务和数据输出服务。

云管理平台和 DevOps 的集成架构如图 3-19 所示。

图 3-19

在云管理平台和 DevOps 的集成架构图中，底层是云的多种形态，包括私有云、公有云、混合云和其他形态的云。这一层提供了直接的基础资源池的能力，包括虚拟计算、虚拟存储和虚拟网络。往上一层是云资源管理，该层根据云的形态选择对应的云资源管理工具，将对资源的管理上升至对资源服务的管理。再往上是云管理平台。云管理平台对云资源和云服务进行管理，统筹对各类云资源的管理，并在不同云计算技术栈的基础上，通过编排、调度、监控和数据分析对外提供基础的云服务。云管理平台在 DevOps 体系中起底座的作用。顶层是 DevOps 体系，通过 CMDB 、自动化运维、 IT 服务流程和工具链对底座进行集中管控，从而打通端到端的资源输出和服务输出的通道，为价值交付赋能。

3.6 面向终态的监控

监控是 DevOps 体系中不可或缺的一部分，也是业务保障域和数据输出域的重要支撑。 随着 DevOps 的能力输出 不断放大，工具赋能带来的不确定性也随之放大，给业务保障带来了新的挑战。同时，这也让我们意识到，面向过程与操作的传统监控模型将难以为继，对于监控，需要在方法和实践方面寻求突破。

3.6.1 什么是面向终态

首先需要明确的是，面向终态是一种设计方法。在业务保障领域，面向终态有 4 个核心能力：安全、稳定、高效和低成本，它们也是运维服务能力模型的四大能力要素。这 4 个能力要素匹配运维服务能力模型的 4 个发展阶段，分别是手工运维、工具化运维、自动化运维和 DevOps 。在这 4 个发展阶段中，运维的对象逐渐面向系统、用户、业务和业态，因此，面向终态的重点在于终态的对象和范围。

在系统方面，面向终态描述了系统的最终形态，用户只需要描述自己需要什么，不需要详细规划执行路径，系统会根据线上的实时状况和运维知识库进行动态调整，以达到系统安全和稳定的目的。例如，在灰度过程中，系统会根据灰度的需求自动执行灰度策略来动态分配流量。

在用户方面，面向终态描述了用户的最终需求，其重点在于系统内部的控制逻辑，核心在于声明式 API ，用户只需要描述最终需求，不需要提供详细的逻辑设计，系统会根据需求进行声明，然后提交给系统，最终获得用户期望的结果。和基于系统的面向终态不同的是，基于用户的面向终态主要是指系统暴露给用户的使用方式。

3.6.2 监控平台产生的意义

随着科技不断发展，线上业务占比不断攀升，信息技术成为核心生产力，因此，一些非功能性的需求逐步增加，可用性、可靠性和业务连续性的兜底需要监控来完成。另外，数据存储成本、数据价值输出和数据衍生能力需要将核心业务数据扩展到一个较宽泛的范围，这也是面向终态的监控平台。

在运维领域，业务保障域是监控平台的核心，具备全方位监控功能，以业务为顶层视角，系统为主体数据输出模式，可以对故障进行检测、诊断、恢复和预测。其中故障预测基于运维经验和积累的结果，即通过对数据的分析总结故障的模式，然后进行预测。在 IT 数字化方面，监控数据是重要的数据资产，因此监控平台需要起到核心数据“集散地”的作用，为业务数据进行补全，为技术数据提供支撑。在成本预测方面，容量管理和采购管理需要根据相应的资源利用率获得数据支撑，需要根据投入产出比来进行优化。

因此，基于系统的面向终态，监控平台应包含以下特性：基于业务的实时链路监控、基于平台的应用异常实时监控、基于用户的子域数据汇聚、基于数据交换的实时输出和基于预警的统一集中收敛。

基于用户的面向终态，用户的最终需求涉及故障处理的事前、事中和事后。在事前阶段，用户关心有没有进行监控；在事中阶段，用户关心监控是否及时，相关指标的准确率高不高；在事后阶段，用户关心故障复盘是否能够达到既定目标。因此，监控平台应包括以下 4 种功能：以服务目录的方式对监控对象进行解读；以自动化的方式对监控对象进行全覆盖；智能地对报警阈值和等级进行定义；对故障处理流程进行学习，并形成知识库。

从输出能力来看，面向终态的监控平台应该对监控数据进行全生命周期管理，以达到运行态监控、安全审计、业务分析和数据输出的目的，并以数据“集散地”的形态提供第三方数据的接入和接出功能。

从监控平台的目标来看，监控平台需要发挥的作用如下：能够实时采集数据；能够实时反馈业务的运行态；能够智能地预测故障和进行告警；能够支撑能力子域进行辅助故障定位；能够支撑研发人员对系统进行有针对性的优化；能够对容量规划进行辅助分析。

从监控平台的数据覆盖率来看，横向需要进行数据宽度的扩展，从网络、服务器、存储、系统、应用到最终的业务层，进行数据的采集和汇聚；纵向需要打通用户终端、流量出入口、系统集群和产品运营，进行端到端的数据多维度关联。

监控平台的体系结构如图 3-20 所示。

图 3-20

3.6.3 现有监控方案的一些问题

在现实中，企业已通过各种监控软件来达到业务域保障的目的。典型的监控软件有 Zabbix 、 ELK 等开源软件，在实际使用过程中，它们都取得了很好的效果。但从面向终态的方法来看，开源的监控软件还存在下列需要改进的地方。

• 对于绝大多数企业，进行全局监控的能力较弱，现有的监控系统只针对某个领域或某个能力聚焦，无法对全局进行全面掌控。
• 无法将业务层以下的子域的链路关系、数据关系形成逻辑汇聚，导致排错时间长，业务恢复速度慢。
• 监控告警多且杂。正因为有很多领域级的监控软件，才导致出现各种独立的告警，甚至导致告警“风暴”。
• 不支持对其他能力子域的系统接入，尤其涉及业务链路级、接口级和方法级的数据自动获取，导致监控漏配、错配，产生准确率和召回率不达标的情况。
• 作为数据接入与接出的“集散地”，对数据的聚合和二次计算的支撑不够，导致数据的能力和价值大打折扣。
• 对于大规模的时间序列分析和根因定位，存在功能缺失。

3.6.4 面向终态的监控设计

在面向终态的监控设计过程中，需要更加友好的面对监控对象和监控使用者，因此，与普通监控不同的是，第三方数据的接入需要在服务目录范畴。在面向终态的服务目录设计中，包括如下要求。

• 提供可视化的服务内容，使用更为便捷，降低了使用成本，提升了用户覆盖率，把监控优先级提升至业务优先。
• 将第三方数据统一以服务中介的方式进行接入，服务中介采用箱即用方式对第三方数据进行统一管理，如外接接口管理平台，对于接口的新增、删除，能够自动进行统计、计算和分析。
• 服务中介将指定的服务提供给监控平台用户，并通过数据标签的方式自动进行关联，根据实时、近线和离线方式进行处理，最终呈现给特定的标签用户。
• 监控平台用户可通过自定义方式接入可用的服务对象。

在数据处理方面，更偏重清洗和指标分层计算。在此之前，需要进行数据源的多样化匹配，支持 Kafka 、 ClickHouse 和 VictoriaMetrics 等多数据源的接入，最终需要实现实时消息、文件的接入，以及数据的实时聚合。在对数据聚合的需求的梳理过程中，需要通过多个维度和指标对数据进行聚合。数据衍生是面向终态的直接表现，需要支持根据不同的指标进行运算，得到用户想要的多维复合数据。

其中，在清洗阶段，需要实时接收数据，并进行数据的处理、转换和清洗。任务一般基于 Storm 或 Flink 实现，经过清洗任务处理后的结构化数据通过消息队列进行数据流转或回流输出。在指标分层计算阶段，对结构化数据进行相关指标的计算，需要达到高吞吐量、标准 SQL 等要求，还需要加强时间窗口、去重等功能的匹配。根据标签数据和标签用户的不同特性，对数据动态地进行实时处理和离线更新。数据的处理流程如图 3-21 所示。

图 3-21

在数据的回流输出方面，面向终态的监控平台需要根据监控目标不断地回检当前的系统状态，从而为面向终态执行决策提供部分依据，因此，模型管道的构建必不可少。这也是我们经常提到的异常检测功能。图 3-22 为数据反馈图。

图 3-22

对于异常检测，可以从告警分析和根因分析方面进行落地。在告警分析方面，基于系统的面向终态需要实现，主要有对告警的时间顺序进行趋势分析；对指标对比进行分析，降低指标预警的召回率；对已知的告警进行标记，辅助优化模型，间接提升指标预警的准确率。在根因分析方面，通过数据的下钻和关联数据的收敛，根据最终的影响因素，对算法分析出的根因进行判断和标记，通过根因判断的结果符合度指标来进行算法调优。

在基于面向终态的监控平台设计中，应有如下分层：用户体验层、服务能力层、数据分析层、数据加工层和后台管理层，如图 3-23 所示。

图 3-23

从本质上来说，面向终态继承了更先进的 DevOps 理念，通过运用大量的声明式 API 来提高“无条件”的极致用户体验水平，同时运用机器学习来加强数据的输出和变现能力。这种设计方式将技术进行反向解耦，在服务能力的范围之内，将数据纳入用户体验中，提升了数据的反馈能力，扩展了监控平台的用户范围，解决了运维数据运营中的一系列问题，可以更加安全、稳定、高效和低成本地践行高效运维理念，是价值交付流水线中的重要组成部分。

全部连载

《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）