2.2.4 体系化度量

1.度量的意义

管理大师彼得·德鲁克说过：“如果你无法度量它，你就无法管理它。”要想做到有效管理，就难以绕开度量问题。实际上，人们容易倾向于关注那些容易度量的元素，而忽略那些难以度量的元素。容易度量的并不一定是最重要的，相反，那些难以度量的可能才是最重要的。度量是一把双刃剑。度量具有极强的牵引作用，可能引导你成功，也可能引导你失败。它会激励你重视并改善那些能够度量的元素，但也可能因为你忽视了那些无法度量的元素而使之恶化。

DevOps的推广打破了传统开发与运维之间的壁垒。全员以产品交付为最终目标，全面提高效率，完成业务需求。久而久之，消费者就会产生这样的潜意识：买了DevOps产品工具，企业就具备了DevOps能力。虽然DevOps工具提供了一个全新的视角去审视整个公司的人员配置、业务流程、企业文化等，打通了开发与运维信息壁垒，把以前的信息孤岛变成高速公路，但并不意味着可以高枕无忧了，因为高速公路也会堵车！

在微服务架构应用广泛的时代，只有将DevOps全生命周期的重要度量指标连接起来，提供从业务需求、开发、测试、运维等各种视角的参数，才能使得管理者准确把握产品市场定位，在产品发展的每个时期进行合理的资源配置，预测风险产品的关键风险，懂得取舍、不断试错，保持利润的最大化。

“度量驱动运维”（Metrics-Driven Operation）即在运维过程中，平台监控、运维及优化都建立在度量的基础上。

2.度量提高可观测性

可观测性（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相关的指标，定期统计并做团队反馈。

3.度量体系成熟度

运维服务能力评估是面向业务用户的自服务的评估，按照运维架构能力建设和管理的进化历程，运维服务成熟度可以分为4个级别。

1）基本级：依据《信息技术服务运行维护标准》（GB/T 28827.1）（以下简称《标准》）实施满足业务需求的运维服务管理，日常的运维活动实现有序运行。对标准的实施不要求全面性和系统性，而是根据业务发展情况，采用《标准》提供的方法。

2）拓展级：依据《标准》实施运维服务管理，实施标准要求的全面性和系统性，并能与业务发展情况相结合，形成较为完善的人员、过程、技术和资源等方面的管理制度，并有效实施。

3）改进级：在全面和系统实施《标准》的基础上，从保障运维服务交付质量的角度出发，形成完善的运维服务体系，建立人员、过程、资源和技术等能力要素协同改进的制度体系。

4）提升级：在全面和系统实施《标准》的基础上，从量化提升运维服务能力的角度出发实施有关运维服务质量评价。组织能够基于信息技术服务业务综合发展的需要，实现全面量化的运维服务能力管理，形成推动业务服务变革的机制。

运维服务能力度量体系要求运维服务能力达到运维成熟度的提升级别，即从量化出发评价运维服务价值与质量。运维服务能力度量指标示例见表2-1。

4.度量驱动改进

运维的体系化度量整体架构围绕CMDB、监控、ITSM等运维系统数据、用户数据、业务数据与第三方数据进行数据治理与分析计算，构建应用健康档案与人员服务水平画像，结合指标管理规范的约束，以业务为导向进行度量指标的规划、设计和优化，实现精准化运营，如图2-9所示。

在该理念架构的指导下，企业可以建设数字化的运维度量指标体系，持续改进运维各个活动与过程。度量驱动改进主要关注运维全生命周期中各种度量数据的收集、统计、分析和反馈，通过可视化的度量数据客观反映运维目标的达成情况，以全局视角分析系统约束点，并在团队内部共享信息，帮助设立客观、有效的改进目标，并调动团队资源进行优化改造，如图2-10所示。同时对行之有效的改进内容进行总结和分享，帮助组织更大范围受益于改进项目的效果，打造学习型组织和信息共享机制，不断驱动持续改进和价值交付。