研发运营一体化（DevOps）能力成熟度模型第4部分：技术运营dr.docx

《研发运营一体化（DevOps）能力成熟度模型第4部分：技术运营dr.docx》由会员分享，可在线阅读，更多相关《研发运营一体化（DevOps）能力成熟度模型第4部分：技术运营dr.docx（26页珍藏版）》请在课桌文档上搜索。

1、ICS35.0201.70YD中华人民共和国通信行业标准YD/T3763.42020研发运营一体化(DevOps)能力成熟度模型第4部分：技术运营Thecapabilitymaturitymodelofdevops-Part4：technicaloperationmanagement（报批稿）（本稿完成期：2019.11.12）-X发布XXXX-XX-XX实施中华人民共和国工业和信息化部发布目次前言Il1范围12术语、定义和缩略语12.1 术语和定义12.2 缩略语13技术运营管理过程概述14监控管理24.1 监控采集24.2 数据管理34.3 数据应用55事件与变更管理65.1 事件管理65

2、.2 变更管理86配置管理96.1 运营配置管理97容量和成本管理117.1 容量管理117.2 成本管理128高可用管理138.1 应用高可用管理138.2 数据高可用管理169业务连续性管理179.1 风险管理179.2 危机管理189.3 应急管理1910用户体验管理20I(U业务认知管理2110.2 体验管理21本标准是“研发运营一体化(DevOps)能力成熟度模型”系列标准的第4部分：技术运营，该系列标准的结构和名称如下：第1部分：总体架构第2部分：敏捷开发管理第3部分：持续交付第4部分：技术运营第5部分：应用设计第6部分：安全及风险管理第7部分：评估方法第8部分：系统和工具技术要求

3、本部分按照GB/T1.12009给出的规则起草。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本部分由中国通信标准化协会提出并归口。本部分起草单位：中国信息通信研究院、深圳市腾讯计算机系统有限公司、北京华佑科技有限公司、平安科技(深圳)有限公司、中国太平洋保险集团、中国电信集团有限公司、中兴通讯股份有限公司、中国移动通信集团有限公司。本部分主要起草人：梁定安、徐奇琛、王超、栗蔚、刘栖铜、萧田国、牛晓玲、车昕、党受辉、杨军、杨文兵、朱平、范晶晶、吴树生、陈亚殊、胡罡、杜颖君、陈靖翔、张南、曾庆辉、闫林、吴新颖、刘扬清、任明、毛茂德、燕杰、雍浩淼、潘晓明。研发运营一

4、体化(DevOps)能力成熟度模型第4部分：技术运营1范围本部分规定了研发运营一体化(DevOps)能力成熟度模型下技术运营管理的能力成熟度要求和评价方法。本部分适用于具备IT软件研发交付运营能力的组织实施IT软件开发和服务过程的能力进行评价和指导；可供其他相关行业或组织进行参考；也可作为第三方权威评估机构衡量软件开发交付成熟的标准依据。2术语、定义和缩略语2.1 术语和定义下列术语和定义适用于本标准。研发运营一体化DevOps它是一组过程、方法与系统的统称，用于促进开发(应用程序/软件工程)、技术运营和质量保隙(QA)部门之间的沟通、协作与整合。注：它的出现是由于软件行业认识到为了按时交付软

5、件产品和服务，开发和运营工作必须紧密合作。2.2 缩略语下列缩略语适用于本文件。API应用程序编程接口CD持续交付CDN内容分发网络CI持续集成CPU中央处理器ETL数据仓库技术IT互联网技术RPO恢复点目标SDK软件开发工具包SQL结构化查询语言TCC两阶段补偿型分布式事务ApplicationProgrammingInterfaceContinuousDeliveryContentDeliveryNetworkContinuousIntegrationCentralProcessingUnitExtractTransformLoadInternetTechnologyRecoveryPoi

6、ntObjectiveSoftwareDevelopmentKitStructuredQueryLanguageTryConfirmCancel3技术运营管理过程概述技术运营管理过程是技术运营能力建设的一个过程，它以业务为中心，交付稳定、安全、高效的技术运营服务，构建业界领先的技术运营能力，支撑企业的持续发展和战略成功。技术运营不仅关注“稳定”、“安全”、“可靠”，更要关注“体验”、“效率”、“效益”。技术运营管理过程分为：监控管理、事件与变更管理、配置管理、容量与成本管理、高可用管理、业务连续性管理、用户体验管理等，如表1所示。表1技术运营管理过程监控管理事件与变更管理配置管理容量与成本管理

7、高可用管理业务连续性管理用户体验管理监控采集事件管理运营配置管理容量管理应用高可用管理风险管理业务认知管理数据管理变更管理成本管理数据高可用管理危机管理体验管理数据应用应急管理4监控管理监控管理是对研发运营过程中的对象进行状态数据采集、数据处理分析和存储、异常识别和通知及对象状态可视化呈现的过程，其成熟度决定了技术运营工作的立体性、及时性和有效性。监控管理从数据流的维度展开分析，包括3个部分：监控采集、数据管理和数据应用。4.1 监控采集通过主动采集或被动收集方式获取监控数据，并保证采集数据的质量、采集过程的可靠性和安全性。监控采集的能力指标包括数据采集和数据传输，如表2所示。1 .1.1数据

8、采集将数据采集能力服务化，从采集的手段、支持的协议、兼容性、颗粒度、采集端的基础逻辑和扩展逻辑等角度对采集能力进行量化评估。4 .1.2数据传输采集能力的数据传输指从传输数据的质量保障、传输的可用性、传输过程中支持的功能特性的纬度来评估其能力成熟度。如表2所示表2监控采集级别数据采集数据传输1具备操作系统级监控指标的采集能力，如CPU、内存等。通过标准协议传输数据。2在1级基础上，需达到以下要求：1) 具备独立的数据采集服务，可采集多种数据类型的日志，如：系统日志、应用日志、接口日志等；相关采集方式包括但不限于嵌入SDK、API、私有协议等；2) 量化管理采集服务的覆盖范围，如能反映企业应用的

9、覆盖率；3) 数据采集可上报到多个服务端；4) 数据采集服务支持可扩展、可配置和高可用的采集架构。在1级基础上，且需达到以下要求：1) 具备独立的数据传输服务，可传输不同数据格式，如int、charsbinary等格式;2) 支持单份数据多份订阅及分发传输。3在2级基础上，需达到以下要求：1) 统一的数据采集服务，可跨平台兼容；2) 提供开放式、自定义的数据内容采集上报方案；3) 具备集中式的采集配置，包括但不限于采集内容、开关等：4) 对采集端进行实时管控，如采集管控、发送延迟、数据校验、统计等方式，并可通过插件化扩展采集逻辑；5)自定义监控内容，具备对采集服务的管理方法，如：采集限制、采集

10、限频等。在2级基础上，且需达到以下要求：1) 具备高可靠数据传输通道和高可用容灾方案：2) 支、多种传输方案，如同时具备数据推与拉的能力；3) 支持数据采集架构的平行扩展、数据汇聚和高效传输等能力。4在3级基础上，且需达到以下要求：1)采集频率可自定义配置调节：2)部分数据采集通过智能化技术动态调整，如智能减少采集内容、智能降低采集频率等。在3级基础上，且需达到以下要求：1)具备数据传输质量和安全的保障机制，如支持数据分片、压缩、断点续传等传输特性；2)保障数据传输的安全性，如数据加密、解密及校验等。5在4级基础上，且需达到以下要求：1)采集服务与技术运营活动关联，实现从固化到动态化的采集规则

11、，如压力测试活动时，将采集频率动态调整为秒级；2)实现监控能力的精细化，智能配置关联运维事件，实现同一运维对象的不同采集内容变化。同4级能力要求。4.2 数据管理数据管理是指对数据进行过滤、转换、提取、聚合和存储等操作，是数据监控的核心能力。按数据管理过程的三个环节，来量化具体的能力模型，包括数据接收、数据处理和数据存储，如表3所示。注1：本章介绍的数据多指与运营相关的数据(非敏感业务数据)，由多个纬度组织而成，可看作大数据处理平台的能力。4.3 2.1数据接收作为数据处理服务端的数据接收服务，承接数据采集服务传输来的数据，需要拥有良好的吞吐性能和可扩展的架构，并且具备区分数据类型和相应处理的

12、功能逻辑。4.4 .2数据处理数据处理指大数据处理的逻辑，支持逻辑运算、统计方法、机器学习等计算能力，可结合技术运营的场景，灵活实现数据的扩展与关联分析。同时，需考察数据处理的规模、性能及架构的能力。4.5 .3数据存储数据存储只针对监控数据的存储场景，对存储的方案、架构、存储成本、数据高可用等纬度综合评估。如表3所示表3数据管理级别数据接收数据处理数据存储1正常接收数据，可对接收到的数据进行量化管理和反查。1、对原始数据源进行预处理：2、对异常数据进行监控识别与校对。提供独立的数据存储。2在1级基础上，且需达到如下要求：1) 数据接收架构可根据容量扩容，可平行扩展：2) 可对基础数据进行初级

13、筛选，如数据转发、数据复制等；3) 可对原始数据进行规则化处理，如数据清洗、校对等：4) 可集中接收异构数据源的上报。在1级基础上，且需达到如下要求：1) 具备常用的数据处理逻辑，如自定义数据四则运算、统计(分类、聚类)等；2) 对外提供数据接口服务：3) 支持可扩展的ETL,实现如数据清洗、转换、导入和加载等功能：4) 对异构数据源进行常用数据处理逻辑分析和关联分析。在1级基础上，且需达到如下要求：1)提供统一的数据存储：2)数据存储架构可扩展，支持根据数据类型、容量等扩展方式；3)数据存储架构支持数据高可用管理，可保证数据的一致性、完整性和可用性等特性：4)可言储多种数据结构和数据类型，如

14、时序数据、文本、数值型和位图等。3在2级基础上，且需达到如下要求：1) 提供统一的数据上报服务，支持多协议多格式的数据源，如文本、字符串和加密协议等；2) 对数据进行进一步的校验，如空值检测、乱码校验和属性校验等；3) 对接收到的数据进行过我保护。在2级基础上，且需达到如下要求：1)数据处理架构可平行扩展、扩容；2) 对数据进行实时计算与离线计算，实时计算的数据处理延时小，如小于1分钟；3) 可处理结构化与半结构化数据，如时序数据、自定义日志数据等；4) 保证数据处理过程中的完整性，如数据校正、数据持久化等；5) 对数据处理过程中的异常状态进行监控和缶警，并具备相应的应对能力，如识别作业异常、

15、数据比对异常等。在2级基础上，且需达到如下要求：D提供高频高密度查询的吞吐能力，如通过SSD或缓存技术实现高并发查询：2)按数据使用场景的冷热数据分离存储；3)存储和快速检索结构化与半结构化的数据；4)可统计时序数据：5)具备数据安全管理能力，如数据容灾，备份、仓库容量高可用设计等。4在3级基础上，且需达到如下要求：1) 全网数据秒级上报：2) 可根据数据上报量，动态管理数据接收容量与吞吐性能。在3级基础上，且需达到如下要求：1) 数据处理逻辑支持可配置、可视化和可编排：2) 数据处理逻辑可通过插件化扩展；3)提供灵活的数据建模能力，可关联不同数据源，按业务场景组织多源数据：4)数据处理服务平

16、台与机器学习相结合，智能化进行数据在3级基础上，且需达到如下要求：1) 持续优化存储数据的管理方案和成本管理，使数据笆理性价比最优；2) 根据业务场景动态设置存储周期。处理与分析。5在4级基础上，且需达到如下要求：1）支撑百万次QPS请求量的数据接收与筛选；2）具备海量数据（如PB级）的存储能力。在4级基础上，且需达到如下要求：1） 持续优化数据处理服务，智能进行数据处理，智能发现新的数据特征；2） 数据处理服务达到PB级的处理能力。在4级基础上，且需达到如下要求：存储模型具备使用智能化技术所需的数据集规模。4.3数据应用数据应用是根据对监控数据的加工、分析，达到异常识别、告警分级、数据可视化

17、展示等应用。按照应用场景分为告警与管控、数据服务和可视化管理，如表4所示。4.3.1 告警与管控告警与管控指监控对异常识别的能力，包括对异常判断逻辑、管控能力、与业务场景的关联等。4.3.2 数据服务数据服务指具备可开放的数据服务能力，为其他系统整合与关联技术运营的数据提供支持。4.3.3 可视化管理可视化是监控数据指导技术运营工作开展的重要能力项之一，包括了对展现灵活性、可定制性、智能化和运维场景结合度的评估。表4数据应用级别告警与管控数据服务可视化管理11）按照阈值规则实现异常告警：2）多加道发送告警信息。提供基础的数据存储服务。在线展示数据图表。2在1级基础上，且需达到如下要求：1） 对

18、告警进行分级管控和简单收敛，告警信息关联标准运维操作；2） 针对标准告警信息，可关联提供标准操作的提示；3） 对告警信息进行一定的统计分析，如统计告警触达率、告警准确率等指标；4）告警明细可记录存储，告警统计数据可导出：5）告警可自动升级，能够将告警通知、升级与组织架构关联。1）对数据进行常规处理，如最大值、最小值、平均值、排序等；2）导出数据常见格式，如excel、txt、SQL、json等；3）数据迁移，如复制、同步、传输到其他存储介质；4）提供面向应用场景的数据服务化能力；5）自定义数据查询接口和数据内容。在1级基础上，且需达到如下要求：1）自定义展示常规图表；2）指标强化展示，如按业务

19、监控指标的重点展示；3）场景化的在线数据查询。3在2级基础上，且需达到如下要求：1)标准化的告警关联自动化工具，实现常见技术运营场景下的故障自愈：2)具备规则化的告警关联分析、关联收敛能力：3)自定义告警的关联引导或触发工具，如CDN回源失败告警信息中，会关联出CDN自助分析工具；4)对告警风暴进行管控，如抑制、收敛等管控措施；5)可自定义分级告警，如预警机制等。在2级基础上，且需达到如下要求：1)在线自定义数据统计分析，如在线SQLs自定义语法等：2)自定义大规模离线或异步数据计算，如批量MapReduce(编程模型，用于大规模数据集的并行运算)计算；3)对数据接口进行管控，如身份校验、调用

20、限频、限制访问源等；4)对常用数据进行安全管控，如权限管理、数据加密或脱密等。在2级基础上，且需达到如下要求：1) 基于业务拓扑架构或调用关系的可视化，并可标示出监控异常点：2) 可视化诵据指标多维度展开与下钻；3) 按条件进行数据统计与展现，如按时间、精度等维度的数据加工；多用户权限管理，如权限分级、按需申请等。4)自定k业务视图，如根据业务场景定制所需的图表；5)提供覆盖全业务的统一可视化。4在3级基础上，且需达到如下要求：1) 动态调整阈值，通过智能技术降低告警量并提高准确性：2) 多对象多事件关联分析，实现如关联抑制、收敛的能力：3) 将告警与其他运维事件关联，并进行根因分析，快速根因

21、定位与修复。在3级基础上，且需达到如下要求：1)监控链条分钟级的端到端分析与输出结果；2)智能数据推荐。在3级基础上，且需达到如下要求：1) 智能基线可视化展示；2) 按照特定节点智能关联展示相关节点的可视化，如数据库异常的监控点，可关联展示其他架构层的异常指标。5在4级基础上，且需达到如下要求：1) 按业务场景实现业务影响评估、故障智能调度、业务智能止损等告警发现与平台管控：2) 根因分析与处理的结论为架构优化提供参考。在4级基础上，且需达到如下要求：智能分析技术运营对象全生命周期相关数据，如智能分析故障账响范围、智能提供决策参考等。在4级基础上，且需达到如下要求：1) 智能推荐监控视图；2

22、) 按业务场景智能生成监控视图。5事件与变更管理事件和变更管理是技术运营和IT服务过程的两个重要管理手段，包括事件管理和变更管理两部分,事件管理是对影响生产的事故和问题建立预防、高效处理及度量改进的制度和手段，变更管理是对基础设施、系统应用、业务产品配置等场景实施变更所进行的审批和控制流程。5.1 事件管理事件是指计划外的服务中断、服务质量下降或还未影响服务的事态，事件管理的目的是快速响应用户事件，短时间内恢复受影响的IT服务，使事件对用户的影响最小化。通过对事件管理过程不同阶段的细分，从快速发现到高效的处理流转，再到复盘改善的跟进，建立对事件全生命周期的管理。事件管理包括事前管理、事件处理和

23、事后管理，如表5所示。5.1.1 事前管理事前管理是指在事前对于事件能够做到定义清晰、完备问题发现能力以及预防止损措施，如监控覆盖、信息周知和上升等。5.1.2 事件处理事件处理是指在事件发生时，具备完整的事件处理流程，包括应急响应的流程及要求、事件处理团队内外部的协同配合机制等。5.1.3 事后管理事后管理是指对事件处理后的学习与改进的能力衡量，通过复盘、对不同维度的事件分析等方式保持对事后改善工作的落地，如客户评估、演习验收等手段。如表5所示表5事件管理级别事前管理事件处理事后管理11) 对事件有基本的分类，被动的受理和处理系统故障，如依靠内外部用户反馈：2) 具备值班接口人角色，可实时响

24、应。业务发生故障后可快速处理和恢复。1) 对于事件有基本的记录；2) 具备事后的分析和通报。21) 对事件进一步分级，建立主动的事前流程和要求，如响应、周知、升级、反馈等环节的要求；并做到基本场景的预案建设、监控的基本覆盖、变更管控等要求；2) 建立对重大故障的应对预案；3) 设立完整的事件处理组织，定义一二线团队的基本职责并和业务团队打通：4) 通过工具支撑事前管理工作，如事件管理平台、知识库、监控平台等：5)架构具备基本的容错设计，并可运营。D建立事件处理规范，根据不同事件级别具备相应的应急响应和故障处理时效，所有处理的事件均已记录和反馈；2) 设定专职团队进行事件处理，并设定事件跟进角色

25、，如服务台角色，对事件处理过程进行追踪和协调：3) 事件处理人员整体具备止损意识：4) 通过一站式脚本或工具高效执行预案。1)建立基本的事后学习改善机制，如事后复盘、案例学习等手段避免事件重复发生：2)事件定位可客观找到原因和责任归属：3)建立事后度量和质量文化，开展基本的度量考核工作、事件记录，关注事故数、止损时效和解决率等，并建立起奖惩制度。3在2级基础上，且需达到如下要求：1) 对事件场景详细扩展，如安全类、用户体验类、系统类等，各应急角色保持培训学习和持续更新：2) 具备完整的重大故障预案，覆盖信息安全、舆情等场景；3) 事件处理组织进一步扩展至外部供应商、第三方服务等团队；4)具备事

26、前平台化能力，如压测平台、运维自动化和预案平台等；平台间可信息共享在2级基础上，且需达到如下要求：1) 对重大事故、突发事件快速决策、合理止损和快速处理，保证特殊重大事件的处理效率与质量：2) 设立标准化管理流程跟进事件处理，如IT服务台统一接受和分发事件、最优服务资源分配、跨团队沟通协作等；3)事彳牛处理平台化支撑，如预案平台的一键执行、执行结果的可视化反馈、可视化展示执行后各项数据的变化在2级基础上，且需达到如下要求：1) 事后复盘具备正确的改善点，复杂事件能区分出主次责任和根本原因；2) 执行优化改进，将改善措施进行落地和验证，验收演习必须在规定时效内完成，并进一步完善预案内容：3)通过

27、事件平台执行度量分析、改善追踪、知识库沉淀等：4)度量关联绩效考核，驱动团队重视问题和改进优化。和协同，如监控发现问题自动建单、变更操作自动周知影响范围等；5)架构的高可用和持续性建设。等；且绝大部分的预案可授权一线直接处理；4)大部分通用类事件可通过架构的容错能力做到无人化自愈，准确率高于90吼4在3级基础上，且需达到如下要求：1)事件管理平台进行智能故障预测、预案推送、智能监控等，实现大幅度收敛和精准定位告警；2)定期开展混沌工程、机房切换等事前演练。在3级基础上，且需达到如下要求：1)系统、网络类事件实现智能化自愈，无需人为介入操作，如90%以上的事件实现智能化自愈；2)借助平台和北能手

28、段实现秒级操作时效。在3级基础上，且需达到如下要求：1) 遵循事件终止原则，直至客户满意为止；2) 事件平台具备智能化分析能力，通过持续的信息输入，提前给出潜在风险的预判。5在4级基础上，且需达到如下要求：事件管理平台可进行预案自动学习生成，事前判断的准确率在99%以上。在4级基础上，且需达到如下要求：事件实现无人化自愈，如90%以上的事件。同4级能力要求。5.2 变更管理变更管理指对IT基础设施、系统应用、业务产品配置等场景实施变更所进行的审批和控制。在DeVOPS环境下，生产环境的变化非常频繁，变更管理面临许多挑战，组织需要了解变更的内容、识别变更的影响范围、识别变更的风险，以便采取有效的

29、管控措施，既要高效率实施变更，又要最小化业务风险。变更管理包括变更流程管理和部署管理，如表6所示。5.2.1 变更流程管理变更流程管理是指通过对变更进行评估，确保能够在对用户、服务产生最小负面影响的情况下实施变更，同时通过在组织内进行有效的协商和沟通，确保所有的变更都具有合理评估和可追溯性。5.2.2 部署管理部署管理是指对将软件代码、应用、配置和数据库变更应用到生产环境的过程进行管理。如表6所示表6变更管理级别变更流程管理部署管理11) 有变更操作的周知要求，能控制部分风险。2) 具备突发场景的变更能力。部署频率以月为单位，单次部署包含大量需求，部分部署工作通过手动执行。21)具备规范化的变

30、更操作要求，如变更文档、变更计划安排、变更周知、影响评估和非生1) 部署过程通过流程文档实现标准化：2) 采用定期部署策略，部署频率以周为单位，应用产环境验收等规范；2) 设立变更评审组织，跟进变更需求，执行变更后有值守观测的要求；3) 规范变更审批流程，变更操作具备一定的能力要求，如自动化变更、灰度发布、回滚和变更记录可追溯等能力。作为部署的最小单位，应用和数据库部署实现分离，实现测试环境及生产环境的自动化部署；3) 使用工具或自动化脚本完成部署；4) 部署失败可回滚解决，系统可用性影响在可控范围内。3在2级基础上，且需达到如下要求：D具备完善的变更管理和发布规范，覆盖到软件开发、配置管理、

31、部署管理和发布管理等过程；2) 提供变更报告和测试报告，对日常的变更质量有基本的度量；3) 建立变更顾问委员会，评估变更带来的影响，定期组织会议对历史变更进行回顾和总结，反馈变更后的信息：如：建立CAB组织，设立变更经理、服务经理、服务台代表、供应商、客户等角色。4) 变更管理的平台化能力，如监控推送健康监测、变更后的自动化测试等，且变更管理流程可自动化操作，平台一键化完成变更或回滚操作；5) 对变更质量和效率进行度量，变更执行顺畅，结合所处行业有较高的成功率。在2级基础上，且需达到如下要求：1)部署频率以天为单位，应用和环境整体作为部署的最小单位，应用和配置进行分离，可使用相同的方法覆盖所有

32、环境部署；2) 通过低风险的部署发布策略保证流程风险可控，如蓝绿部署，金丝雀发布等：3) 部署和发布全部实现自动化，具备统一的部署发布平台、架构和系统应用的标准化要求。4) 部署成功率不低于90%(按版本统计),集成回归测试用例并作为准入条件，每次部署活动提供变更范围报告和测试报告。5) 建立对部署的监控和度量体系。4在3级基础上，且需达到如下要求：1)重大变更操作的实施具备深度规范化，严格遵循定义、规划、构建、测试、验收、评估等的特定变更顺序，如切换核心数据库、Set迁移等变更操作；2)引入智能化技术，变更后通过机器学习跟踪用户反馈、挖掘舆情和变更风险自动分析等；3)对变更质量的度量能力；如

33、：部署失败率整体较低，按照模块、团队、应用都能达到99.95%以上，全年无发布升级导致的重大故障；4)关注通用场景以外的变更风险，如关注工具类变更、签名系统的升级、流程类变更等。在3级基础上，且需达到如下要求：1)按需部署；2)具备深度平台化能力，部署发布服务化实现团队自助一键式多环境自动化部署，同时支持数据库自动化部署：3) 部署过程灵活响应业务需求变化，通过合理组合实现灵活编排：4) 部署成功率可达到99.9%,部署失败自动化降级回滚。5在4级基础上，且需达到如下要求：进行智能化的完整变更流程管理，如变更操作无人化。同4级能力要求。6配置管理配置管理是由识别和确认系统的配置项、记录和报告配

34、置项状态和变更请求、检查配置项的正确性和完整性等活动构成的过程，其目的是提供IT基础架构的逻辑模型，支持其他服务管理流程特别是变更管理和发布管理的运作。配置管理作为技术运营工作的基础数据，为技术运营工作的开展提供必要的配置对象管理、录入、关联等功能，各个技术运营系统可以基于此配置数据实现自动化运维、监控管理等功能。6.1运营配置管理运营配置管理特指与技术运营相关的配置数据，包括配置管理系统的基础功能与扩展能力，配置对象的说明与对象间的关联与应用场景，包括配置对象与配置数据，如表7所示。6.1.1配置对象配置对象指与技术运营相关的配置项。6.1.2配置数据配置数据指与配置项相关的数据，记录配置项

35、的状态、变更及配置项间的关系，可覆盖配置项的全生命周期。如表7所示表7运营配置管理级别配置对象配置数据1记录基础设施的配置管理信息。依靠文档记录配置信息。2在1级基础上，且需达到如下要求：1) 对配置对象全生命周期进行管理，配置对象状态更新可通知：2) 对常用配置对象的业务、应用等进行管理。D统一配置数据管理，实时反馈在线运维对象的运行状态；2) 配置数据接口化，对外提供API调用接口；3) 通过流程管理配置项变更，人工维持数据的准确性；4) 配置数据变更日志可维护管理，可支持变更回溯和日志审计。3在2级基础上，且需达到如下要求：1)自动发现配置对象，如配置对象自动上报状态；2)自定义配置对象

36、，支持自定义扩展字段：3) 配置对象变更关联技术运营事件，如运维告警关联业务定义的返回码等；4) 常用配置对象相互关联，如主机与上联交换机相关联。在2级基础上，且需达到如下要求：1) 配置数据管理的权限与组织分工相关联，支持常态化的权限检查与更新机制；2) 基于单一可信数据源自动纠正关键配置数据；3)多向户视角的配置数据统计与展现：4)配置数据集中管理。如：专人负责维护与定义配置数据，有标准流程指导配置数据的查询与使用：统计管理数据负责人、数据定义、数据来源、数据依赖和对外提供服务等。4在3级基础上，且需达到如下要求：1)自动发现配置对象间的关联关系，智能识别配置对象间的内建关联关系，动态更新

37、配置库；2)根据配t对象间的关联关系动态生成配置视图或架构图，辅助绘制业务功能架构视图。在3级基础上，且需达到如下要求：D配置数据自动化变更，支持调用统一的变更API接口；2) 配置数据变更联动触发其他系统，如配置数据变更与外部系统的通知与回调；3) 统计与展现与业务场景相关联的配置数据；4) 配置数据为技术运营活动提供数据支持，如主动巡检、资产核算和容量管理等。5在4级基础上，且需达到如下要求：智能化扩展配置数据，持续扩充与完善配置对象与对象间的关联关系。在4级基础上，且需达到如下要求：D配置数据辅助智能决策，为运维智能决策提供数据支持；2)智能化定义配置数据的关联规则，如按业务场景智能组装

38、配置管理的流程、变量，实时产生适用的规则。7容量和成本管理容量和成本管理是对容量和成本进行评估、规划、分析、调整和优化的过程，它结合了业务、服务和资源容量需求，以保证对资源的最优利用，满足与用户之间所约定的性能等级要求，在公司IT规模较大或业务快速增长时，容量与成本管理更为重要。7.1 容量管理容量管理的评估包括三个维度：硬件负载、吞吐性能、业务量，以及这三个管理维度与运维活动的结合。容量管理由基础设施容量和业务容量组成，如表8所示。容量管理的常见评估维度有：硬件负载、吞吐性能、业务量，以及这三个管理维度与运维活动的结合。7.1.1 基础设施容量基础设施容量指容量管理中与基础设施相关的能力项，

39、如机房，服务器硬件，操作系统等指标维度、以及用多维度的统计方法进行容量评估，并能够运用基础设施容量评估指导相关的运营活动。7.1.2 业务容量业务容量以业务的视角来组织容量的数据，让容量的指标与业务的实际质量和运维效率结合，指导运维工作的开展，如表8所示表8容量管理级别基础设施容量业务容量11) 按不同维度聚合管理基础设施容量，如按硬件集群的指标聚合、按操作系统的性能指标聚合等；2) 对基础设施进行基本的容量监控与告警。D按业务相关维度聚合业务容量，如按业务功能模块或服务维度聚合等：2)按业务容量监控与告警。2在1级基础上，且需达到如下要求：D通过多维度的容量统计报表或视图展示进行容量统计，如

40、按照地域维度、机房维度等统计和展示；2)自定义容量计算方法，如最大值、最小值、极差等方法；3) 实时容量查询，对外提供容量API查询接口；4) 根据不同运维时象的容量特征，进行多维度的量化管理，如容量的访问密度等：5) 量化管理容量基线，常态化压测容量基线，支持容量管理与标准硬件管理结在1级基础上，且需达到如下要求：D反馈业务容量指标，支持多维度的业务容量统计报表或视图，如请求量、成功率和延时等，支持按接口、功能和应用等；2)自定义业务容量计算方法，如访问密度、木桶原则等方法：3) 业务容量实时查询，对外提供实时业务容量APl查询接口：4) 根据不同业务场景的容量特征，多维度的量化管理其容量指

41、标。介：6）主动巡检，如定期巡检发现硬件容量异常等。3在2级基础上，且需达到如下要求：D具备动态容量平衡的架构能力，根据业务分布差异动态调整业务量与容量配比，如负载均衡、平行扩展等；2）容量弹性伸缩，定期进行容量调度演习；3）进行容量预测和容量预警。如CPU80%、每小时增长斜率20%的时候进行容量预警。在2级基础上，且需达到如下要求：1）业务容量与基础设施容量指标关联分析；2）定期分析线上业务容量水平，支持常态化压测业务容量基线；3）根据容量数据决策调度业务，如过载保护、防雪崩等：4）进行业务容量柔性服务，如有损服务、容量弹性伸缩；5）具备基于实际运营情况的业务容量预测模型。4在3级基础上，

42、且需达到如下要求：1）自定义容量管理，可按运维场景定义容量管理方案，如母机容量、链路容量和机房容量等.2） 主动容量优化，并进行以容量优化为目标的相关技术运营活动：3） 全链路容量预测，如从单集群容量预测到链路容量预测等。在3级基础上，且需达到如下要求：1） 对业务容量进行精细化分析，如业务请求链路中的容量分析、架构性能瓶颈分析等：2） 业务容量支撑技术运营活动，如容量数据与故障关联等.3） 全链路业务容量预测，为保障业务连续性的容量分布活动提供支持。5在4级基础上，且需达到如下要求：智能容量预测管理，如支持硬件容量、性能、损耗的智能化预测分析等，并输出准确的结果。在4级基础上，且需达到如下要

43、求：业务容量智能管理，如支持业务容量的智能调度、智能决策和智能预测等。7.2 成本管理成本管理是对运维对象生命周期的运营成本进行量化管理，通过合理性分析、架构优化、容灾规划等手段达到成本节省的目的。成本管理分为成本合理性和预算与核算，如表9所示。7.3 2.1成本合理性成本合理性指对运营成本的主动分析，通过与容量数据、配置管理数据的结合，指导运维优化活动的开展，推动架构优化、自动化等能力的建设。7.4 .2预算与核算预算与核算指成本管理的一个重要环节，通过建立成本与业务的关联，根据业务的发展有计划的申请资源，并定期核对资源的使用合理性与必要性，寻求质量与效率的最优组合。如表9所示表9成本管理级

44、别成本合理性预算与核算1采购基础设施、软件时有成本意识。1）有流程支持基础预算申请；2）有流程支持基础核算，如具备资产配置.表，包括硬件、软件资产的记录管理方法。21）对基础设施全生命周期的成本进行管理，标示和记录其不同状态：在1级基础上，且需达到如下要求：D具备体系化的预算管理机制，如软硬件的过期2) 对软件全生命周期的成本进行管理，有流程规范指导软件的立项、上线、变更、下线等生命周期中的不同阶段；3) 记录成本管理涉及的相关数据，保证管理对象与生产环境状态的一致性。机制、更新机制等；2)主动成本分析，如定期清算等：3) 核算管理有对应的流程指导，如制定流程指导硬件的采购、使用、淘汰等生命周

45、期中不同阶段的对应管理行为；4) 对全局技术运营对象的进行核算，如对开发环境、测试环境和生产环境的核算管理。3在2级基础上，且需达到如下要求：D多维度的成本管理，包括软硬件、云资源和带宽等，可组合分析；2) 支持成本换算，可将云主机的CPU核数、存储量等按换算规则换算计价，如母机虚拟化出多个容器，每个容器的成本计算换算规则；3) 对资源利用率进行分析，如库存分析、库存预警、硬件损耗预测和预算预测等；4) 成本数据与容量数据关联分析，如对生产容量、容量扩缩容等技术运营活动进行合理性分析，并输出成本管理角度的分析和建议；5) 精细化成本管理，如从单机到单核的成本使用和管理等；6)主动成本管理，如主动的架构评审、架构成本合理性分析和带宽使用优化等。在2级基础上，且需达到如下要求：1)灵活管控成本，如使用云服务和技术，实现缩短采购周期、弹性伸缩等；2) 对成本进行分析与预测，如固化成本管理报表、例行化成本核算等；3) 成本数据可自动化校对，如采购数量与实际使用情况不匹配的自动发现能力。4在3级基础上，且需达到如下要求：1) 按业务场景进行成本优化管理，如混合部署、离线计算的应用等；2) 业务架构与容量成本数据的