3.9 基于流程指标的数据运营

建立持续优化的运维流程管理机制，需要度量运维流程运作的执行力与效率，流程指标是整个运维流程体系的重要组成部分，是对流程管理进行引导、控制、使其不偏离原定目标方向。所以，指标需要根据运维组织的核心价值主张，支持量化、实时、被监控，并透明、公开的传达到组织具体的人，让流程可以持续的得到优化，这是构建持续优化型与学习型组织的关键。在组织、流程、平台、场景四位一体的数字化运维体系下，指标的应用，在组织管理上能够让组织流程可视、可控，且具备在线、可穿透的作用；在流程的协作上能够建立公平、透明的协同文化；同时，指标也是运维平台化管理的场景设计提供基础原料。

本节提到的指标不包括生产环境对象涉及的运行指标，重点围绕运维流程中的指标运营，包括：事件管理、问题管理、变更管理、发布管理、配置管理、服务台、业务连续性、服务水平等。

1.运维流程指标概述

指标来源于统计学范畴，广泛用于各个领域，比如全国人口总数14亿、生产总值年度增长率7%、数字化经济占国家经济总值38%，企业营业同比上升20%等。从技术角度看，指标通常由key和value组成，key反映指标的定义，即指标反映什么状况，比如全国人口数量、生产总值年度增长率；value反映具体的数值，比如14亿、7%。指标可能用数值或枚举值表现，反映的是客观现象的数量特征，不可量化的信息或没有数量特征的指标不建议纳入到流程指标中。

在运维流程中分析指标需要了解有哪些流程、明确流程指标目标是什么、流程指标用在哪里、谁会重点使用流程指标，以下进行分析。

有哪些流程？

IT运维领域有很多指标，从描述运维数据表现可以分为生产环境对象及IT服务管理，前者是与运维相关的基础设施、平台软件、应用系统、业务及体验涉及对象的数据，后者是运维管理过程中涉及的IT服务管理数据，本章重点关注IT服务/流程管理的指标数据。运维平台化的建设，为运维组织提供了大量的数据，这些数据是运维流程指标的基础。但是需要注意的是“数据会作恶”，因为不同系统的数据成为指标的过程与软件设计者、指标使用者的个人见识有关，同一份流程数据用在不同的背景下展示的效果可能截然不同。即如果，运维组织流程规范不标准，各个环节都采用自律、经验驱动，那么指标就不能真实的反映流程状况。所以，运维组织首先需要设计好工作流程，然后设计指标来测量这些流程，再决定如何让软件落地指标数据。幸运的是运维已经有很多最佳实践可以借鉴，本章参考ITIL与ISO20000的分类，将流程指标数据分为服务战略、服务设计、服务转换、服务运营四类，分别包括：

服务战略：IT服务战略管理、需求管理、财务管理、服务组合管理等。

服务设计：供应商管理、信息安全管理、容量管理、连续性管理、可用性管理、服务级别重审、服务目录管理等。

服务转换：变更管理、发布管理、配置管理、变更评估、验证测试、知识管理等。

服务运营：事件管理、问题管理、服务台、技术管理、应用管理等。

注：此图来自互联网材料

流程指标的目标是什么？

流程指标应用的关键目标是为了建立持续优化型运维组织，并确保组织价值创造与公司的价值创造保持一致。在这个目标中，指标具体作用包括：

一是为IT流程提供可度量的依据，向运维组织、IT组织、企业经营决策层提供评价IT运营管理的情况，帮助利益相关者理解IT运营管理的总体情况。

二是为持续优化运维组织、流程、平台提供推力，度量IT运营的流程效率、服务水平、业务连续性、发布交付效率等，基于指标数据推动组织架构和能力的提升，流程的优化，并提高平台能力的赋能作用。

三是引导运维组织达成规划愿景，为IT运营的发展提供战略导向，达到ISO20000、ITIL、ITSS、AIOps等行业最佳实践或成熟度标准，并有效支撑运维组织对用户SLA目标的达成。

谁会重点使用流程指标？

对流程指标实时观测与趋势分析，有助于观察流程执行情况。指标数据是一种协作工具，不仅能为流程指标负责人观察流程有效性与合理性，也能为运维体系的管理决策、职能经理、一线员工，提供支持。

流程经理通过流程指标管理流程。每个流程指标都需要有对应的负责人或岗位，最好每一个指标都要有一个第一责任人，因为涉及责任岗位超过1个时往往就变成没有责任人。流程指标的责任人主要通过观测指标实时的变化，或长期的趋势，采取必要的措施来管理流程。

流程指标赋能管理决策层或职能经理数字化管理。不同的流程指标除了反映流程执行效率，还反映整个IT运营水平，比如：SLA和SLO涉及的SLI指标可以感知IT服务质量；发布管理指标可以感知IT交付速度；可用性与业务连续性指标可以感知IT风险保障能力水平等。同时，数字化流程指标，关联自动化能力后是实现运维平台化管理的基础。

一线员工能够透明的看到贡献与可改进方向。流程通常反映了运维组织的关键价值链，一线员工通过透明的观察流程指标，可以看到自己的工作情况，所属位置，并制定待改进的举措，将产生积极的学习型，持续提升的组织文化。

2.关注哪些流程指标

前面提到流程指标数据主要分为服务战略、服务设计、服务转换、服务运营四类，本节对每类摘录几个流程进行梳理可供使用的指标供参考。需要强调的是，某个流程关注的指标并不是越多越好，或者说应该聚焦与运维组织核心价值创造相匹配的几个最关键的指标，关键指标在不同的时段又可能需要调整。

（1）服务运营类流程：事件管理、服务台

事件管理相关指标：

• 故障平均发现时长
• 故障平均响应时长
• 故障平均定位时长
• 故障平均恢复时长
• 故障监控发现量/率
• 一线支持解决事件率
• 二线支持平均响应时长
• 绕过一线支持的事件反馈量/率
• 主动解决故障量/率
• 客户满意度
• ……

服务台相关指标：

• 服务台每天响应事件数
• 服务台一次解决问题量/率
• 升级到二线/三线支持的事件量/率
• 客户满意度
• 平均等待时长
• 主要问题类型的占比（可选几类主要占比的类型）
• 知识库匹配度
• 请求转事件率
• ……

（2）服务转换类流程：变更管理、发布管理、配置管理

变更管理相关指标：

• 变更总数
• 变更失败量/率
• 未按计划执行变更量/率
• 紧急变更量/率
• 被拒绝或退回变更量/率
• 变更负责人平均处理变更数量/时长
• 引发事件的变更数/率
• 未准时执行CAB评审的变更数/率
• 客户满意度
• 变更文档不全数/率
• ……

发布管理相关指标：

• 非CD发布的变更次数
• 紧急发布数/率
• 发布导致事件数/率
• 按时发布数/率
• 平均发布时长
• 未经测试的发布数/率
• 平均带缺陷发布的数/率
• 不在制品库的软件包
• 客户满意度
• ……

配置管理相关指标：

• 各CI项异常数（可统计到CI项、系统、团队、人），比如系统主机缺失、关系有误、证书超过有效期等
• CMDB接口消费数
• 配置数据异常导致变更失败数量
• 客户满意度
• ……

（3）服务设计类流程：服务水平管理、可用性管理

服务水平相关指标：

• 未达SLA目标的系统（可用性）、服务（请求）数量
• 服务升级数量
• SLA变更数量
• 客户满意度
• ……

可用性管理相关指标：

• 业务/系统/服务/模块/组件不可用时长
• 宕机恢复时长
• 重复性故障数量
• 系统故障平均间隔时长
• 关键时段故障时长
• ……

（4）服务战略类流程：业务关系管理

业务关系管理相关指标：

• 服务投诉量
• 与SLA客户正式或非正式沟通数量
• SLA客户反馈问题整体解决率
• 客户满意度
• ……

（5）具体指标的要素分析

以“事件管理”流程的“故障平均发现时长”为例。

事件管理的目标是为了尽可能提升事件处理效率，尽可能降低生产事件对生产业务连续性的影响。

“故障平均发现时长”是事件管理中事前管理流程中的一个关键环节，指标涉及的属性应该包括：指标名称、指标描述、指标负责人、指标消费方、发现超时阀值、目标值、指标数据来源、计算口径等。在“故障平均发现时长”的具体设计中，包括：

• 名称为故障平均发现时长
• 描述为生产故障在真实发生后到被运维机器或人第一时间发现的时长，理论上机器能更快发现。
• 流程与指标的负责人是流程经理。
• 指标的消费方包括事件流程经理、职能团队经理、一线系统管理员。
• 超时的阀值是5分钟
• 目标值是小于2分钟
• 指标数据数据来源于实时故障应急协同系统、统一监控告警系统、服务台、ITSM
• 计算口径是故障发现时间减实际发生时间

3.建立持续优化的流程指标运营

（1）一些问题

结合最近一年多在IT数字化运营上的实践，虽然输出不少IT运营相关的指标数据，但在存在一些问题，比如：

责任问题。指标数据没有与实际流程相结合，指标没有指定唯一的负责人，没有人对指标的正确性负责。指标涉及的报表负责人没有持续跟踪，对报表或看板的数据变化缺乏分析。

使用问题。报表和看板使用频率低，指标负责人或使用方（以下简称消费方）对于报表或看板带来的价值不清晰，指标数据没有与实际的运维流程相结合，很多是为了完成一项任务，数据输出很多时候是一次性工作。

设计问题。指标数据没有契合流程的关键点，比如：消费方对指标数据消费的需求分解不清晰，指标数据选择过多，指标数据实时性不强、指标波动太大、指标在技术实现上与需求的偏差等。

方法问题。企业在讲数字化转型，企业一级一级传递到运维组织，数据如何驱动运维工作，缺乏方法指引，指标的使用也缺乏沟通与培训。

效能问题。报表和看板越来越多，但主题多了之后容易重复，重复意味着浪费，也容易因为不一致导致的出错。

工具问题。缺乏对众多报表的统一管理，杂乱，而仪表盘信息太细，消费方只想看结果，中间缺少一个归纳总结。

（2）指标数据设计与应用的一些反思

基于上面的问题，我觉得在流程指标的使用上需要关注以下几件事：

流程指标遵循SMART设计原则。SMART指：S（Specific，明确性，明确关联某个流程与负责人）、M（Measurable，可衡量性，指标转化为数值或枚举，可量化）、A（Achievable，可达到性，指标可作为可达到的目标）、R（Realistic，现实性，指标数据是客户反映真实流程执行情况）、T（Timely，及时性，指标数据在线或及时统计输出）。

洞察、决策、执行闭环。将“洞察、决策、执行”贯穿于数据指标使用的解决方案中，在开始做指标分析或可视化前就要想好需要数据发现什么问题，发现问题后要如何处理，如何跟进这个处理的执行。

保持指标的简单。一是保持数据消费简单，方便消费方找到数据反映的观点，而不仅仅是数据的展示。二是降低数据分析门槛，方便数据的收集、上报、规划研发、指标复用、可视化、信息触达、闭环跟进等。

统一规划指标分析主题。梳理当前的数据指标消费角色，角色工作中的痛点与价值期望，按某此维度归纳几个可扩展性的主题，建立指标管理（包括：指标服务、口径、源数据等）。

数据指标的应用适度与流程关联。数据的应用与流程、机制适度关联，或必要的KPI映射，让指标数据运营成为流程的一个步骤，比如配置指标运营、变更管理运营、发布运营等。

推动指标数据研发工作。一方面，数据研发肩负数据驱动的布道者角色，享受从0到1的成就感。同时，积极拥抱有数据驱动思维的人或团队，大部分人是经验驱动的，如果有人对数据驱动有明确的需求与构思，数据研发团队要积拥抱这些人，让他们先富起来，带动其他小伙伴。最后，正确的数据研发绩效，数据研发绩效不是做了多少个看板，而应该是带来什么价值。

（3）流程指标的应用

流程指标有比较多应用场景，从表现形式看主要包括：定期报告、临时报告、实时看板，以及作为数据源料融入到其他工具等。以下从流程指标应用场景进行简单梳理：

定期报告类

定期报告通常会分解为不同流程的报告，比如流程经理为了洞察感知流程执行情况设计的相关报告，或运维团队用于IT运营复盘相关的分析报告。比如：

• IT服务运营月报
• 生产故障运营月报
• 生变更管理运营月报
• 问题管理运营月报
• 发布管理月报
• 服务台管理月报
• 每日IT运营分析
• 每日发布公告
• ……

管控看板或工具类

与报告不同的是，看板反映的是实时的数据指标，可能是单独的看板，也可以将相关数据融入到其他工具中，比如在某个变更窗口中查看当前变更的进展，故障应急中查看近期关联变更等。比如：

• 变更窗口管理
• 操作时序管理
• 故障应急
• 监控告警响应管理
• IT服务请求升级
• ……

在线运营类

在线运营类的实时性要求没有管控看板高，但比定期报告增强了个性化、配置化的分析能力，比如CMDB的数据运营，基于流程指标辅助绩效管理等。比如：

• CMDB数据运营
• 容量管理
• 绩效管理
• 可用性管理
• ……

汇报报告类

汇报类报告主要包括企业内部运维线、IT线、公司条线，以及企业外部监管、同业调研或交流涉及的专项汇报性的工作，此类汇报报告中经常会用到一些服务指标数据。比如：

• 运维体系运行保障工作汇报
• IT服务水平工作汇报
• 流程专项工作汇报
• ……