下载掌阅APP，畅读海量书库
立即打开
传统运维管理体系模型（PPTR模型）是数字化运维管理体系的基础，企业根据PPTR模型打造其运维核心能力，为业务发展提供重要的保障。但随着企业数字化转型的推进、业务量的增长、IT技术的更新迭代、运维人员的技术要求变化等复杂因素的交叉影响，原有的PPTR模型已经不能匹配企业运维管理体系的要求，为此，我们融合了ITIL 4、DevOps、敏捷等先进的理念，创造性地提出了新一代数字化运维管理体系模型OPDM，如图2-5所示。下面将对OPDM模型的核心要素进行详细阐述。
图2-5 数字化运维管理体系模型OPDM
一体化运维操作平台是OPDM的基础能力，其能力图谱如图2-6所示。
图2-6 一体化运维操作平台能力图谱
一体化运维平台具备跨云跨网多级管控能力，代理可以自动无感升级，具备对资源进行监、管、控的能力。企业基础设施正在从传统数据中心集约式IT架构加速向云计算架构转型，未来很长一段时间内，企业的基础设施将形成传统IT架构、私有云架构、公有云异构架构并存的格局，有的企业还将边缘架构等多种技术架构纳入企业数字基础设施，异构环境下一体化运维管理能力受到极大的挑战。因此，建设一体化运维平台，需要提供底层统一的管控服务，包括三大基础服务能力—文件传输能力、实时任务执行能力、数据采集与传输能力，满足对IaaS层的所有管控需求，具备多数据中心异构资源的纳管能力。
一体化运维平台具备平台级的多中心能力，如统一的用户中心、权限管理中心、消息中心、审计中心等。通过平台多中心能力的建设，将基础能力抽象提炼成平台各个中心，提供上层应用统一的用户身份、权限验证、消息通知、日志查询等通用能力，有效支撑运维场景工具的快速搭建，避免各个应用重复造轮子的现象，摆脱传统运维工具的烟囱式建设模式。
一体化运维平台具备低代码能力，能实现部门、团队、岗位级SaaS定制以及场景工具拖拉拽。在数字化转型的大背景下，应用软件的需求持续增长，应用研发生产力直接关系到企业和整个社会的数字化进程。低代码开发平台作为不需要编码或通过少量代码就可以快速生成应用程序的工具，本质上是一种满足日益增长的应用创建需求的供给技术侧改革形式，其通过标准化“组件”和便捷“工具”，让不同编程技术基础的开发者以“搭积木”的方式进行应用开发。低代码开发平台通过降低技术能力门槛的方式，增加平台产品受众面，一方面可以降低企业应用开发人力成本，另一方面可以将原有数月甚至数年的开发时间大大缩短，从而帮助企业实现降本增效。
一体化运维平台具备前后端开发框架能力。开发框架由两部分组成：一部分是前端，提供了可拖拽的前端页面组装能力，可以生成前端的UI组件和代码；另一部分是后台，提供“后台开发框架”，集成了公共的后台模块，如登录、API调用等。基于PaaS平台“开发者中心”的服务，帮助运维人员低成本构建运营系统/工具。为了让上层研发的工具SaaS能满足企业的个性化需求，可以通过PaaS平台提供API、开放协议等方式来进行二次开发，将企业内已有系统接入PaaS体系中，便于上层的SaaS使用。
一体化运维平台能够对运维的组件能力进行提炼，并作为共性组件为能力中心、场景中心提供服务。企业运维管理共性组件的提炼，是通过构建完整的数字化PaaS平台，将资源和通用能力模块化、组件化，充分与上层业务应用解耦合，从而实现价值敏捷交付、产品快速创新、用户体验提升和上下游生态扩展。通过持续打造共性组件功能模块的完备性、易调用性、稳定性，为上层的IT工具和服务提供共性组件的数字化平台（即iPaaS平台），提供运维场景工具定制化的能力，实现业务系统和共性组件数字化平台的完全集成。
一体化运维平台具备高可用、同城双活灾备能力，能实现多中心同城双活或两地三中心架构，安全、稳定、高效地支撑企业IT管理系统的运行管理，保障业务的连续性。通过一体化运维平台基础架构高可用的容错设计，实现故障自动切换的能力，提高运维工具服务的稳定性、连续性。平台架构需要考虑全方位的高可用架构设计，如接入层的高可用设计、应用层的高可用设计、服务层的高可用设计、数据层的高可用设计。
一体化运维管理平台具备微服务和容器架构能力，实现平台的稳定性、灵活性和可扩展性。在异构环境下，运维管理场景的个性化需求会越来越多。为了匹配运维工具开发和运营的敏捷交付要求，一体化运维平台需要向更敏捷、更主动的交付转型，支撑运维工具的快速交付和运维。平台的敏捷化需要结合云原生技术来实现，通过微服务架构设计实现应用开发的拆分与能力的松耦合，通过容器化部署实现应用的快速搭建、按需发布以及可弹性扩展。
一体化运维平台可以通过API网关和ESB服务总线等机制，实现与外界系统进行数据交换和共享。通过API网关提供API托管服务能力，可以帮助开发者创建、发布、维护和保护API，以快速、低成本、低风险地开放系统的数据或服务。ESB服务总线支持组件编码接入和在线自助接入两种接入方式，并提供了统一的用户认证、应用鉴权、协议转换、请求转发、流量控制、日志记录等功能。基于统一数据交换共享的能力，打破数据孤岛，集成企业现有系统的能力，为上层业务提供数据服务。
高速化流程关注流程的敏捷性、价值的快速传递，即敏捷ITSM。敏捷ITSM是通过统一的IT服务管理平台，整合多来源的数据、自动化、用户协作和管控流程，实现以客户和用户价值为中心的IT服务管理实践的高速交付。
在IT服务管理领域，ITIL v3是以安全性和连续性为目标来建立和维护IT基础架构管理的。但迄今为止，随着敏捷和DevOps理念的不断深入，IT服务管理的环境正在变化，敏捷DevOps需要依据业务用户的需求缩短开发周期，提高发布频率。若保持原有的ITIL流程化的管理方式，就难以满足上述需求。为了实现敏捷和DevOps的目标，我们需要更轻量级的、更快速的IT服务管理。
为了做好敏捷开发与精益运维，我们重新组织了IT服务管理，这意味着仅须从IT服务管理中提取关键信息来管理业务连续性要素即可。如图2-7所示，我们定义了以下数据是在哪些流程或活动中发生的，这些数据包括业务活动模式（PBA）、服务级别需求（SLR）、服务级别协议（SLA）、服务设计包（SDP）、服务级别包（SLP）、服务验收标准（SAC）及运营级别协议（OLA）。主要思路是在活动过程中收集和记录数据，并利用这些数据生成汇总报告，或将这些数据提供给第三方系统使用。
图2-7 轻量级ITSM
敏捷ITSM与传统ITSM是有不少区别的，具体对比如图2-8所示。相同之处是两者都以ITIL最佳实践为基础，不同之处主要是传统ITSM关注合规、流程与稳定性，以项目思维进行管控，而敏捷ITSM关注快速响应，以产品思维进行场景化的融合，实现业务和用户价值。
1）建设原则如下。
❑统筹规划：服务或用于提供服务的元素都不是独立的，要对信息、技术、组织、人员、实践、合作伙伴和协议进行统筹规划，并将规划结果传达给内部和外部客户。
❑保持实用：如果流程、服务、行动或指标未能提供价值或产生有用的结果，则将其消除。要尽量简化流程或程序，并提供实用的解决方案。
❑专注于价值：组织所做的一切都需要直接或间接地为利益相关者创造价值。关注价值原则包含许多观点，包括客户和用户的经验。
❑协作可视化：跨界合作产生的结果会得到更多人支持，与目标的相关性更强，并且增加了长期成功的可能性。实现目标需要信息、理解和信任。应该明确工作和后果，避免隐藏的议程，并尽可能地分享信息。
❑充分利旧：不用从头开始构建新的能力，应对用户当前环境进行充分调研，结合当前最新的技术及方案融合已构建的能力，形成符合企业要求的能力。
图2-8 敏捷ITSM与传统ITSM对比
2）建设宗旨如下。
❑主要目标：提升IT运维管理的敏捷性，左侧对接DevOps管理体系，右侧服务业务运维保障价值；合规前提下，快速响应和实现服务管理实践交付。
❑主要方式：以ITIL 4为理论指导，基于统一平台，构建管理实践场景，实现与ITOM充分融合，构建端到端管理自动化，充分协同与互动。
❑建设效果：运维管理的绩效数据全局可视、可下钻。基于运维管理的绩效数据，可辅助运维决策。
高速化流程的价值可以从成本维度、稳定性维度、效率维度、安全维度、体验维度、风险维度来考虑。
1）成本维度。
❑工具成本：整合多个传统昂贵流程工具，节约维护和更新的成本。
❑员工成本：降低创建变更、事件、发布等流程的耗费时间，降低等值的TFE时间成本。
❑业务成本：降低业务和应用系统的MTTR，降低直接业务成本，增加业务收益。
2）稳定性维度。
❑减少引入风险：全局范围的变更与发布预分析能够减少可能引入的风险数量。
❑快速恢复业务：降低业务系统的MTTR，提升MTBF，提升业务的稳定性。
❑杜绝故障复发：全局性问题和知识管理，预防问题重复出现。
3）效率维度。
❑单一平台：通过单一平台提供更智能、更快的服务，消除技术孤岛，并无缝集成整个组织范围的流程。
❑充分整合：整合数据、自动化和流程，打破竖井，实现充分的结构化、数字化的服务管理。
❑完全可见：通过一体化平台，增加全局IT服务管理的能见度，削减决策成本，提高管理可跟踪程度。
4）安全维度。安全维度主要指统一权限，实现平台化权限管理，实现IT服务管理权限的充分可见和合规管控。
5）体验维度。
❑统一服务平台：单一的IT服务参与系统并支持多渠道的服务接入，提高用户体验的一致性。
❑敏捷服务实践：简洁、优美的交互界面和覆盖全面、逻辑清晰的服务管理实践，能够提高用户的直接使用体验；ITSM与ESM的整合，能达到一致的服务体验。
❑提升组织协作：服务管理过程中简单、充分、结构化的用户沟通，可大幅提升用户协作体验。
6）风险维度。
❑风险暴露清单：针对关键业务系统的可能风险的定义，确认风险清单。
❑风险应对预案：针对其中的重大风险，整合数据、自动化等制定处理预案。
❑定期检测验证：组织人员、流程、工具，定期检验预案有效性，并降低风险发生的可能性。
20世纪初期，移动互联网开始萌芽发展，如今各式各样的App已经渗透到我们工作和生活的各个领域。对于企业来说，供应、研发、制造、销售、运营等环节涉及的IT系统则更加广泛。随着用户的多元化需求，企业IT系统及应用的复杂程度和数量呈现急增的趋势，也促使IT运维管理系统的增加，运维系统采集的数据种类和数据量同步激增。
对传统企业来说，监控系统呈现分散的状态，而在一些复杂的运维场景如故障定位、服务优化、服务管理等中，常常在需要一些关键数据作为辅助决策时，才发现缺少相应的数据支撑。随着时间的推进，传统的IT运维监控系统已难以支撑企业业务发展的需要。在技术的变革演进过程中，新一代IT监控运维系统以应用为中心，逐渐开始将运维工作的重心进行转移，从工具建设聚集到数据建设，以数据驱动运维，运维走向数据化的时代。
简单来说，数据化运维是以数据架构为基础，以分析为手段，采集全领域相关的运维数据，从而达到掌握运维过程、衡量运维目标的目的。以提升服务质量为例，当遇到系统运行变慢的时候，用户体验就会变得越来越差，一线运维人员会第一时刻想到优化扩容，但是提升服务质量并不意味着一味地付出更多的资源成本。数据化运维更关注以下问题：现有的业务资源是否能够支撑未来业务的持续增长？业务扩容方案的设计与评估的标准是什么？有没有关键的数据作为支撑？数据是否具备说服力？这些都是运维数字化时代需要思考的问题。
数据运维驱动可以定义为一种运维的新方法，它通过数据化更清晰地识别运维目标的达成情况，借助数据评价体系来衡量运维过程的有效性。在数据化建设过程中通常会遇到以下问题：数据化运维的核心目标是什么？数据分析体系是什么样的？如何建设？最终又如何反作用于运维过程？我们运维的日常场景非常繁杂，但其实最终都会有其对应的目标作为导向，比如：IT系统产品的质量追求，运维的效率提升，运维成本的降低，业务连续性的要求等。业务应用集群提供的是面向用户的服务，而服务质量的好坏必须先传递到运维侧，通过付出更多的资源成本进行观测。在数据化运维能力的支撑下，我们可以更科学地评估用户服务规模和容量，以更好地适应业务的扩张。
面对运维的核心价值与目标，我们需要明确什么数据能识别当前的运维状态，此时就需要使用运维大数据的能力进行分析。开始时可以采集全量的运维数据，不需要考虑哪些数据才是需要的，数据归集后需要对数据进行清洗和识别，找到数据之间的依赖关系。其中一个有效的方法就是从用户访问流出发，看具体的用户请求经过了哪些资源和服务，然后统一采集这些系统产生的相关数据。数据的初步归类如下。
设备端是非常重要的数据采集点，从设备端采集回来的数据能直接反映用户对产品的感知情况。从用户侧来说，通常我们可以看到两类数据：一类是面向技术运营人员的，另一类是面向产品运营人员的。在数据驱动运维的实践中，一方面可以采集面向技术人员的数据指标，另一方面可以少量采集产品侧的数据。
向用户提供产品和服务的时候，后台有很多的资源在支撑，包括人力资源、带宽资源、存储资源、计算资源、IDC资源、机柜资源等，可以看出资源的对象非常多。为了更好地识别并管理这些资源对象，企业常规的做法就是建设一套CMDB系统。在建设CMDB系统的时候，需使用以业务为导向、以应用为中心的方法，对所有资源实例进行识别，以业务维度进行相关资源实例指标的采集，如带宽使用率、CPU使用率、内存使用率、磁盘IO使用率、数据库读写峰值等，这些指标决定着服务的支撑能力。我们可以建立标准的容量模型来计算资源的饱和度，同时可以设定业务资源的容量模型，确保支撑的业务规模大小。在面向用户的数据采集中，我们还可以采集部分的业务数据，根据业务的增长趋势进一步去看未来的资源容量需求。
公共服务是指常见的DNS服务、文件服务、缓存服务、负载均衡服务、队列服务等，比如分布式存储、Redis缓存等，是一种面向应用的基础资源能力封装。在CMDB中，服务也是一种特别的资源，因为它的关键特征、数据采集方式、表现形式都与传统资源截然不同。不同的服务关注的指标有所不同。比如DNS服务，它关注的核心指标是解析成功率和解析时间，并且关注各地LDNS的解析次数，甚至还关注变更后解析异常情况等。Redis、MySQL、分布式文件存储等服务，所需要关注的指标都不同。
当用户对页面发出请求或与客户端连接之后，都会转换到业务内部分布式系统之间进行大量的相互调用。分布式系统的典型特征不是函数式的内部访问，而是RPC的远程调用方式，因此对这类接口访问数据的采集显得尤为重要。接口数据有很多和其他对象指标不同之处：第一，数据量非常大，因此一般使用抽样采集，但在关注某些关键指标的情况下，需要全量模式；第二，实施难度巨大，不同的编程语言或者不同的RPC调用模型，采集的方式都大不相同，需要开发人员的深度配合；第三，采集数据的分析难度大，由于数据量大造成使用传统的技术方法和分析模型难以应对，需要使用运维大数据分析技术；第四，数据价值明显，在故障发现和系统优化等运维场景中，这个数据最具有说服力，直接体现出用户服务的好坏；第五，数据采集模型最容易统一，关注的核心指标是服务访问的延时、失败率等，再加上服务实例之间的描述信息。
当我们采集了上述4类数据之后，会发现这些数据都属于离散状态，而非关联的状态。用关联的视角，例如从业务拓扑、物理拓扑及用户访问流三个角度去看，整合之后的数据才能体现数据的核心价值。数据关联也给提炼核心数据价值带来一定的困扰，由于数据的多样化带来的干扰，因此需要回归数据使用消费场景才能识别出数据价值。还有一种数据整合方式，是在用户的实际访问流中通过字段丰富的机制来实现数据采集，这样的数据对故障定位的意义非常大。通过字段丰富的机制，看用户在内部服务之间的请求历史，寻找故障根源点，快速发现问题的所在。
“数据驱动运维”战略围绕以下几个方面展开。
1）感知能力。在数据中心的建设过程中，可以应用数字孪生技术，把运维对象数字化，构建可视化的界面。运维人员通过界面可以直观看到系统的运行状况。同时，监控平台覆盖了运维全领域，拥有维度丰富的数据，再通过智能运维算法智能发现故障，对数据中心整个运行组件做到全感知。
2）决策能力。人工决策单纯依赖的是运维专家的经验，对数据中心来说很重要。数字化时代下，需要采用“可视化+专家大脑”去代替部分的人工决策，同时通过“大数据+机器学习”来做智能决策。
3）执行能力。有感知有决策，但当服务质量有所下降或出现故障的时候，要怎么去恢复服务、减少故障恢复时间？这就需要在执行能力方面下功夫。建设了标准化流程、标准化动作、标准化场景，之后再通过自动化运维系统固化起来，这样在出现对应故障的时候，可以采用一键恢复的方式来提高问题处理的效率。
4）数据底座。要建设上面提到的3种能力，数据底座是基础。前面提到，运维工具很多，数据很丰富，但因为“数据孤岛”加上数据维度庞杂，构建统一的运维数据中台作为底座就非常重要。
5）组织转型。数据中心有各个领域的技术专家，网络专家精于网络知识，系统专家负责系统知识，所擅长的领域各不相同。而采用智能运维的方式时，运维感知和决策建立在数据的基础上，这时候就需要组织做相应的转型。采用Google SRE的理念来提高运维开发能力，提升运维效率。
管理大师彼得·德鲁克说过：“如果你无法度量它，你就无法管理它。”要想做到有效管理，就难以绕开度量问题。实际上，人们容易倾向于关注那些容易度量的元素，而忽略那些难以度量的元素。容易度量的并不一定是最重要的，相反，那些难以度量的可能才是最重要的。度量是一把双刃剑。度量具有极强的牵引作用，可能引导你成功，也可能引导你失败。它会激励你重视并改善那些能够度量的元素，但也可能因为你忽视了那些无法度量的元素而使之恶化。
DevOps的推广打破了传统开发与运维之间的壁垒。全员以产品交付为最终目标，全面提高效率，完成业务需求。久而久之，消费者就会产生这样的潜意识：买了DevOps产品工具，企业就具备了DevOps能力。虽然DevOps工具提供了一个全新的视角去审视整个公司的人员配置、业务流程、企业文化等，打通了开发与运维信息壁垒，把以前的信息孤岛变成高速公路，但并不意味着可以高枕无忧了，因为高速公路也会堵车！
在微服务架构应用广泛的时代，只有将DevOps全生命周期的重要度量指标连接起来，提供从业务需求、开发、测试、运维等各种视角的参数，才能使得管理者准确把握产品市场定位，在产品发展的每个时期进行合理的资源配置，预测风险产品的关键风险，懂得取舍、不断试错，保持利润的最大化。
“度量驱动运维”（Metrics-Driven Operation）即在运维过程中，平台监控、运维及优化都建立在度量的基础上。
可观测性（Observability）其实并不是一个新词，早在几十年前就被广泛地用于控制理念中，用来描述和理解自我调节系统。随着新一代技术如容器、微服务、Serverless等的迅速应用，系统之间的访问关系越来越复杂，一个核心业务系统可能会运行成百上千个微服务，导致传统的监控技术和工具很难跟踪微服务应用之间的通信路径和相互依赖关系。因此，系统内部的可见性变得越发重要。
可观测性其实与监控系统很像，可以说其本质是一样的，同样在解决一个问题：度量企业的基础设施、平台和应用程序等，以及了解它是如何运行的，运行状态是否正常。但两者应对的问题域却完全不同，监控告诉我们哪些系统或组件是正常工作的，可观测性告诉我们系统或组件为什么不工作了。度量是一个可深可浅的词，比如回到这样一个问题：你的应用是可观测的吗？可能某些人会给出肯定的答案，他们认为应用可观测就是监控应用的健康状态。对于Kubernetes里的容器来说，使用Prometheus就可以开箱即用地监控它。没错，状态是能够被监控的，通过监控系统可以知道某个时刻的活动状态，但微服务之间的关联关系以及某个微服务容器出现问题后产生的影响我们并不清楚。
量化目标是一切工作的起点，所有运维工作都应围绕服务水平目标（Service Level Objective，SLO）指标进行规划、执行、跟踪及反馈。其中在业务规划阶段，我们通常会选择合适的服务等级指标（Service Level Indicator，SLI），并设定对应的SLO。围绕业务侧关注的SLI、SLO，运维团队会拆解成各个管控指标和相关活动去完成。关于SLI的定义，Google提出了VALET（Volume、Availability、Latency、Error和Ticket）方法，这5个单词就是SLI指标的5个维度。
❑Volume（容量）：代表服务承诺的最大容量是多少，比如常见的QPS、TPS、会话数、吞吐量以及活动连接数等。
❑Availability（可用性）：代表服务是否正常或稳定，比如请求调用HTTP 200状态的成功率、任务执行成功率等。
❑Latency（时延）：代表服务响应是否足够快，比如时延是否符合正态分布，须指定不同的区间，比如常见的P90、P95、P99等。
❑Error（错误率）：代表服务有多少错误率，比如5××、4××，以及自定义的状态码。
❑Ticket（人工干预）：代表是否需要人工干预，比如一些复杂故障场景需要人工介入来恢复服务。
根据SLO定义业务相对应的SLI后，跟踪SLO的达成情况，时刻提醒还有多少错误预算、是否应该调整业务版本发布的策略或节奏，更加聚焦人力在质量管控方面的优化。我们可以对接监控与ITSM系统，获取故障单据、影响时长等数据，自动计算SLO相关的指标，定期统计并做团队反馈。
运维服务能力评估是面向业务用户的自服务的评估，按照运维架构能力建设和管理的进化历程，运维服务成熟度可以分为4个级别。
1）基本级：依据《信息技术服务运行维护标准》（GB/T 28827.1）（以下简称《标准》）实施满足业务需求的运维服务管理，日常的运维活动实现有序运行。对标准的实施不要求全面性和系统性，而是根据业务发展情况，采用《标准》提供的方法。
2）拓展级：依据《标准》实施运维服务管理，实施标准要求的全面性和系统性，并能与业务发展情况相结合，形成较为完善的人员、过程、技术和资源等方面的管理制度，并有效实施。
3）改进级：在全面和系统实施《标准》的基础上，从保障运维服务交付质量的角度出发，形成完善的运维服务体系，建立人员、过程、资源和技术等能力要素协同改进的制度体系。
4）提升级：在全面和系统实施《标准》的基础上，从量化提升运维服务能力的角度出发实施有关运维服务质量评价。组织能够基于信息技术服务业务综合发展的需要，实现全面量化的运维服务能力管理，形成推动业务服务变革的机制。
运维服务能力度量体系要求运维服务能力达到运维成熟度的提升级别，即从量化出发评价运维服务价值与质量。运维服务能力度量指标示例见表2-1。
表2-1 运维服务能力度量指标示例
（续）
运维的体系化度量整体架构围绕CMDB、监控、ITSM等运维系统数据、用户数据、业务数据与第三方数据进行数据治理与分析计算，构建应用健康档案与人员服务水平画像，结合指标管理规范的约束，以业务为导向进行度量指标的规划、设计和优化，实现精准化运营，如图2-9所示。
图2-9 运维度量指标体系架构
在该理念架构的指导下，企业可以建设数字化的运维度量指标体系，持续改进运维各个活动与过程。度量驱动改进主要关注运维全生命周期中各种度量数据的收集、统计、分析和反馈，通过可视化的度量数据客观反映运维目标的达成情况，以全局视角分析系统约束点，并在团队内部共享信息，帮助设立客观、有效的改进目标，并调动团队资源进行优化改造，如图2-10所示。同时对行之有效的改进内容进行总结和分享，帮助组织更大范围受益于改进项目的效果，打造学习型组织和信息共享机制，不断驱动持续改进和价值交付。
图2-10 度量驱动持续改进过程