Chapter 7
第7章
目标管理

如果不详细了解服务中各种行为的重要程度，并且不去度量这些行为的正确性，我们就无法正确运维这个系统，更不要说可靠地运维。那么，不管是对外服务，还是内部API，我们都需要制定一个针对用户的服务质量目标，并且努力去达成这个质量目标。

——《SRE Google运维解密》

在生产运行对象越来越多、数据量越来越大、难度越来越高等问题持续增加的同时，运维组织人员规模与资源投入并未见长。为了有效达成企业对运维组织核心价值创造的期望，运维组织要建立清晰、可行的目标管理。目标管理要做好几件事：一是聚焦重要信息系统与关键基础设施，将有限、优质的资源投入关键领域；二是建立可量化的目标描述、过程评价、结果总结的数字化闭环；三是建立工作机制与工具，辅助组织与员工做好时间管理。

7.1 SLA、SLO、SLI

SLA、SLO、SLI是数字化运维的一个重要手段。SLA是针对目标的一个双方认同的协议，SLO定义对目标具体的量化要求，SLI定义量化要求的指标形式，可以理解为一份SLA通常由多个SLO组成。每个SLO的达成可以细分为多个SLI（见图7-1）的实现。这三个词基于IT服务管理建立，是站在整个运维组织角度，对外做出服务交付，对内对组织与员工提出绩效要求，指导运维人员达成高绩效。建立SLA、SLO、SLI，有利于组织建立差异化的IT服务管理，聚焦优质资源在重要的信息系统、重要基础设施、重要的价值创造、重要的工作项上。

1.SLA

SLA并不陌生，在生活中也经常遇到。比如在美团买菜，客户可以清晰地看到计划多久送达，如果没有按时送达，平台会按超时时间给你积分；网约车平台建立车主与用户之间的服务交付关系，如果预测车主未按时到，会帮用户在最近的位置更换另一个车主；在真功夫点餐，服务员会告诉用户需要等待多久，超时会给补偿。Google SRE最佳实践认为SLA可以用来帮助运维组织合理配置资源。一个有明确SLA服务理念的运行状态是“增加额外资源来弥补系统所带来的收益小于把该资源投给其他服务所带来的收益”。

运维领域的SLA由ITIL引入，指提供服务的运维组织与用户之间就服务的品质、水准、性能等方面达成双方共同认可的协议或契约。应用服务级别协议，首先要聚焦在“协议”二字上，表示供需双方对某项服务达成一致，具有约束性，不管是面向组织外还是组织内，运维要与用户梳理服务的协议内容。其次是“级别”，运维组织要与用户在差异化服务级别要求上达到一致，比如交易系统的服务级别要求会高于内部办公系统。SLA明确了企业部门之间对其角色、服务要有明确、清晰的认识，减少沟通成本，提升IT服务质量。

SLA让服务供需双方按协议约定进行服务交付，协议的内容包含SLO、SLI、异常恢复方式和时间等。SLA通常涉及如下内容。

供需双方对所提供服务的要求内容，协议有效期限，服务级别，服务相关收费，对用户数量、地点以及提供的相应硬件服务等做出规定。

服务交付过程中涉及服务不可用时的应急处置要求，比如服务连续性要求、异常情况报告流程、故障升级到更高水平的支持条件、对故障报告期望的应答时间等。

对服务变更请求流程的说明，包括完成例行变更请求的期望时间、变更对服务连续性的影响、变更时间等。

如果服务失效或者达不到预期效果，供方如何提供额外支持，以及承担什么责任，比如对外部的云厂商可能是赔偿，对内部的IT部门扣分等。

SLA帮助运维组织规范了常规支持服务，并将有限的资源进行了更合理的分配。在实施上，我们可以考虑先定义企业内部SLA服务范围，包括定义SLA框架，制定系统重要级别，明确哪些服务纳入协议，以及涉及的工作流程、角色、分工。在SLA框架下，与不同的业务部门沟通具体的服务水平协议，建立线上化服务支持，包括线上化工单、服务台等机制。线上化服务支持需要为服务交付效率、质量持续提升提供数据支撑。同时，还要与业务部门建立定期沟通机制，提高服务供需双方的沟通质量，以便更好地获知业务部门对服务的反馈。SLA将运维服务引向一个可量化、可控制、可评论、可管理、可改进的层面，使服务不再模糊，不再只停留在纯技术层面。

2.SLO

SLO定义服务交付期望状态或服务质量目标。SLO在SLA与SLI中起承上启下的作用，为SLA提供明确的服务目标要求，为SLI提供量化数值。SLO定义由服务指标与具体数值组成，比如，定义服务可用性99.99%，某个交易接口响应时间10ms，硬件资源服务交付时间1个工作日等。

运维组织需要有区别地设置SLO，在有限的资源下聚焦更重要的目标。制定SLO能让服务供需双方对服务质量有清晰的预期，让服务提供者可以根据预期的服务质量平衡成本与收益，更好地控制风险。以可用性目标为例，业界通常会用 N 个9来体现可用性程度（见表7-1），计算方法是：可用性=平均故障间隔时间MTBF/（平均修复时间MTTR+平均故障间隔时间MTBF）。不同服务对象的可用性要求不同，比如IDC机房、核心网等重要基础设施的故障是全局性故障，通常其可用性目标是100%或99.9999%；重要交易系统直接面向客户，可能还涉及客户权益或企业资金风险，需要投入更多资源进行保障，通常可用性目标是99.999%。

3.SLI

SLO的定义由服务指标与具体数值组成，这个可量化服务的测量指标就是SLI。要理解SLI，首先看指标。指标是在事物或业务的规模、程度、比例、结构等的度量基础上加工和计算得到的。例如，“客户获取成本”作为一个指标，是在给定时间段内的所有成本、同一时间段内获得的客户数量这两个维度度量上相除而得出的。

在运维领域，指标有很多，比如评价性能的交易量、耗时、成功率，评价可用性的无故障时间、故障恢复时间，评价变更管理水平的变更数量、成功率、紧急变更数量。运维指标能对运维工作进行引导和控制，使其不偏离原定的价值创造方向。随着数字化运维体系的推进，数据将融入各种工作场景，比如运维领域的资源消耗、容量、性能等指标数据会被用于业务连续性保障监控，可用性指标数据会被用于引导运营效能的持续优化，耗时、功能报错指标数据会被用于推动客户体验优化。我们需要将指标融入实际业务场景，发挥指标的价值。

不是所有的指标都可视为SLI。应选择尽可能少的SLI，但这些SLI应能说明服务是否稳定与可靠。能作为SLI的指标应该能直接反映服务质量，并起到驱动服务质量持续提升的作用。比如某个对客业务系统对客户体验要求很高，指标可以为响应时间、最大请求量、无故障时间、故障恢复时长等。如果是一个线上资源交付，指标可以为服务响应时长、交付周期等。

7.2 OKR

随着运维人员规模越来越大，工作协同涉及的点越来越复杂，发生内耗和浪费的可能性不断增加，企业需要有一种机制让运维组织聚焦工作重心，更一致地对齐整体目标，减少内耗。OKR的出现重点是为了解决上述问题。

1.OKR的由来

20世纪50年代，加州大学创立了目标管理体系（Manage By Objective, MBO）。该管理体系在德鲁克的《管理的实践》一书中有提及，它认为：企业的目的和任务必须转化为目标。企业如果无总目标及与总目标相一致的分目标，来指导职工的生产和管理活动，则企业规模越大、人员越多，发生内耗和浪费的可能性越大。概括来说，MBO是让企业管理人员和员工参与工作目标的制定，在工作中实行自我控制，并努力完成工作目标的一种制度。MBO提出后，得到了HP与英特尔等公司的大力推行，并产生了很好的效益。后来，英特尔在MBO的基础之上发展出了OKR，并将OKR推广到Google等企业。（据说是英特尔的一位高管投资了Google，并向Google推荐了OKR方法。）

OKR从字面上看由O和KR两部分组成，O表示目标（Objective），KR表示关键结果（Key Result）。目标是指想做什么事情，是定性的，能简洁直白地陈述，比如让应用运维团队向SRE转型，打造以“监、管、控、析”为底座的运维平台体系等。关键结果是指衡量已经完成的工作，是定量的。

2.OKR不是KPI

OKR的核心思想与数字化运维体系“递归”传递的价值创造思想一致，旨在建立一种机制，将运维组织的目标自上而下、明确地传达到各运维团队与一线运维员工，然后各层级对顶层目标的关键结果进行分解，并采用持续跟进的方式有效落实关键结果。

虽然OKR已经成为一种十分流行的目标管理方法，但很多企业还在使用以KPI为主的目标管理方法。KPI强调保质保量地完成预定目标，在制定目标时需要决策者清楚组织或个人能达成什么样的目标，是一个考核工具。在实际应用过程中，被考核的组织或个人容易产生为保留实力而设置低KPI目标的心态。OKR则强调持续推动完成预定的目标，在制定目标及量化关键结果时兼顾自上而下与自下而上，通常制定一个有挑战的目标，比如制定一个50%概率能完成的目标，然后通过一系列机制来持续推动团队完成这个目标。目标无法完成并不会引发处罚，而是分析目标未达成的原因，进行持续改进。

3.关键目标

OKR对员工要求比较高，它假设企业员工的素质、认知水平达到了一定高度，员工能够自发地为做好一件事而努力尝试。同时，OKR需要有一系列机制保证制定的目标、量化的关键结果合理，并持续跟进员工，及时沟通，实现最终落实。OKR的实现还需要一个扁平化组织结构，以提高基层员工的决策和自主能力。虽然OKR在定义上强调企业的使命、目标，并传达到部门组织、个人，但实际应用过程中，我们也可以缩小范围，比如从某个组织或项目群出发，这点与前面提到的“递归”传递思路一致。

以运维研发团队的OKR为例，团队的关键目标传承自运维组织的战略目标，可针对运维平台体系制定一个整体的目标，再将整体目标分解为3个以内的关键目标。比如运维工具研发团队针对将分散工具向平台化过渡，可以建立3个关键目标。

在“监、管、控”平台能力上，补充“析”平台。

基于CMDB，实现“监、管、控、析”平台在工具层面的互联互通。

推动运维工具运营，落实工具对员工的赋能。

为了更好地实现上述关键目标，运维团队需要将每个关键目标分解为几个关键结果，比如：

完成运维数据平台上线，实现运维数据“采存算管用”的基础能力，监控围绕IT服务、基础设施、平台软件、系统软件、业务功能与用户体验等维度的指标，并试点AIOps智能运维场景。

所有“监、管、控、析”平台至少需要包括消费系统、应用、集群、主机等配置项，达到互联互通效果。

对所有运维工具的使用情况进行数据埋点，建立可量化的运营效能指标体系，重点落地监控告警治理、IT服务管理关键流程线上化等。

4.OKR管理方法

要想持续进行运维目标管理，我们可以考虑以四象限看板的方式建立OKR管理。以下是很多OKR管理相关书籍推荐的一种看板（见表7-2），这个看板的四象限分别是本周关注任务、OKR当前状态、未来四周计划、状态指标。本周关注任务通常有3～4个，只有完成了这些任务，团队整体目标才能向前推进；OKR当前状态象限列出目标与关键结果，每个关键结果设置信心值，如果信息值为5/10，代表信心指数是五成把握，通常设置7/10比较好；未来四周计划除了列出工作计划外，还有哪些事情需要其他团队成员做好准备或支持；状态指标主要是列出重要的、影响目标达成的因素，需要团队额外关注，比如团队氛围、加班情况、外部重要事件等。

7.3 做好运维时间管理

随着业务的发展，运维部门成为企业中工作最繁重的部门之一。运维人员日常面临各种微信群、邮件的轰炸，由于零散、非计划性工作多，很多计划性工作经常被打断，管理决策很难得到跟进，员工执行力差，急需良好的时间管理能力。

1.运维琐事表现

Google SRE鲜明地提出用自动化消灭琐事的思路，提倡用自动化方式改变工作模式。由于运维琐事对于运维工程师来说太正常，且每一项都不复杂，很容易被忽视，如果运维组织不对琐事加以改进，组织内的人力资源将很快被琐事占据。下面是运维琐事的特征。

手工操作：比如手工处理的报表填报、变更发布、容量分析、性能分析等。

重复性：比如每天执行的手动巡检、手动补丁升级、批次检查、常规复盘等。

被动性：比如问题咨询处理、服务工单检查、监控告警处理等。

没有持久价值：比如磁盘空间满了，临时手工清理空间后磁盘还会满等。

与服务规模同步增长：比如操作系统初始化涉及的代理安装、标准目录规划等。

运维琐事还伴随着突发性、无计划性，容易中断员工正在处理的工作，影响员工工作连续性，使工程师长期处于“救火”状态，影响团队士气，阻碍组织技能的持续提升。了解运维琐事是为了让运维组织建立清晰的“消灭”琐事的文化，推动组织持续完善工具建设，将流程标准化，优化工作流程，让手工操作自动化，提升运维时间管理水平。

2.应对琐事

为了有效应对琐事，运维人员可以考虑从流程、自动化、数据驱动、协作模式、时间管理几方面进行处理。

（1）建立端到端的运维流程

推动运维组织更顺畅的协同运作，需要建立一系列端到端流程，减少无效流程。大部分运维组织基于行业政策、企业内部规程以及IT服务管理相关最佳实践，建立了管理及操作流程，让运维工作规范化、标准化。流程推进中通常存在价值不清晰与流程断点问题，前者指运维流程设计没有与IT价值创造相呼应；后者指流程之间缺乏端到端流程共识，导致跨团队协同沟通成本高，使一项工作存在多个断点的情况。针对这两个问题，一要围绕运维价值链，打通流程孤岛与协同断点，实现协同网络和精益运营；二要充分利用数字化技术优化端到端流程，通过自动化技术让原有重复性、操作性工作自动执行，释放生产力；三要提升运维工程师体验，比如：

通过社交化的ChatOps技术，实现“人、设备、事、系统”之间的即时连接。

通过移动化技术提供业务24小时在线、随时随地开展运维协同运作。

通过数字化协作空间技术，梳理各个环节参与者之间的连接方式，促进信息准确与实时传递，以便于信息与经验共享。

通过定期对处理经验进行梳理、总结、交流，借助知识分享工具让内部成员查询、学习，或形成知识库整合在IT服务咨询的线上路径中，减少用户重复咨询情况。

（2）自动化一切

“自动化一切”属于理想状态，实际情况下手工操作将一直存在。“自动化一切”更多是建立一种主动消灭低效琐事，创造更高价值的工作文化。运维自动化水平是运维组织平台化成熟度的一个评价维度，工业和信息化部提出的运维发展路线如下：

第一阶段是以人手工运维为主，手工运维伴随着一些分散的脚本或工具。第二阶段是用线上脚本或者工具完成工作，但是仍需要手工执行。

第三阶段是平台化运维，与第二阶段最大的区别在于，平台化运维涉及的工具进行了互联互通，主要实现线上规律性工作自动化。

第四阶段是基于DevOps等理念，建立高效协同的运维模式，此时的自动化将围绕软件交付等核心价值链。

第五阶段是智能运维，借助智能技术建立数据洞察、决策、执行闭环，此时的自动化将围绕人机协同运维模式。

运维组织可以考虑根据上述几个阶段，判断自身所处的阶段，并有侧重地推动相关重点项目与关键能力的建设。另外，除了一线操作需要自动化，管理上也需要自动化，比如通过机器人判断管理行为来落实管理要求，并提醒执行方落实决策。

（3）数据驱动

进入数字化时代，数据驱动模式将是运维工作的主要工作方式。以数据驱动行为自动化将是“消灭”琐事的一大利器。一是组织要建立高效的运维数据平台，从平台侧实现高效的“采存算”，支持快速采集日志，监控时序指标、告警、性能、报文、运营流水等数据，支持灵活、低代码的数据加工，并结合运维数据模型与算法，监控运维数据指标。二是运维平台需要开放灵活的数据消费能力，包括为其他工具提供开放、灵活的数据接口，为工程师提供所见即所得的数据服务。三是运维平台要向中台模式发展，落地可复用、可共享、可组装的服务，并在此基础上建立敏捷的数据应用，为工程师提供“感知、决策、执行”的数据闭环应用能力。

（4）建立适当的协作模式

关于协作，我们以ECC值班为例进行介绍。在2015年，笔者当时所在团队有一个刚被提拔的骨干申请离职，沟通过程中他提到一个问题：被动性工作太多，尤其是晚上接到临时处理监控告警、清算批次异常的电话，这个问题一直影响着他和家人，消耗着他的工作热情。我们意识到琐事给员工工作、生活都带来了消极影响，且“能力越强，干的琐事越多”这种问题在骨干身上尤其明显。因为这件事，我们开始在团队中试点一、二线分离策略，主要思路是：将每个业务运维团队分为两批，一批是一线岗位，每天工作重点围绕“监控告警处理、服务工单处理、故障处理、变更操作、问题咨询”；另一批是二线岗位，主要是做运维主动性分析工作，运维前侧涉及的评审、架构优化、项目类工作等。同时在夜间值班中每个业务运维团队安排一个同事现场值班，并要求运维所有人具备已知预案的应急处置能力，以减少夜间对非值班同事的电话咨询。这个一、二线分离策略让一部分同事能够从琐事中抽离出来做一些计划性工作，在个人工作热情、团队整体绩效方面起到了正面作用。

Google的on-call制度，其实也是一种值班管理制度，产生了一些积极效果。首先，on-call更加聚焦突发故障的处理，避免突发的重复性工作打扰每个成员。其次，Google运维是一个全球性组织，开发、运维分散在世界各地，on-call机制促进跨区域远程协作。最后，Google每月会安排专人值班，处理紧急突发问题，这样每个人只是定期轮值处理紧急突发问题，其他时间可以专注于优化运维的项目性工作。

（5）将时间管理融入运维场景

时间管理是指有效利用时间，提升单位时间效率。彼得·德鲁克认为，有效的时间管理通常有：

记录自己的时间，以认清在什么地方消耗了时间。

管理自己的时间，设法减少非生产性工作的时间。

集中自己的时间，由零星变集中，增加连续性时间段。

因为运维工程师日常琐事多，很多工程师来到公司后，遇到一个故障可能很快半天就过去了，可能忙到连喝水的时间都没有，但回过头来看又好像没做什么事情。很多运维工程师工作几年后，当被问及“擅长方向”时可能无从回答，因为运维沉淀的经验主要与故障应急处理、变更操作等琐事相关，长期看主要是重复，经验积累的价值越来越小，只能是消耗工作热情，难以提升个人能力。要想持续提升运维知识体系能力，运维工程师需要从琐事中跳出来，关注时间管理。

工具能够赋能运维时间管理，比如涉及面向个人的线上化的任务管理、日程管理，以及面向组织的计划管理、重要生产变更日历管理、变更窗口管理。时间管理工具将以数字员工助手的角色演进，帮助员工做好工作安排，完成操作性、重复性工作。 L04VnGVQJX9a0EkE5nB1iaul+6cAEJGhV1qMnuu4sfrPrFIjOUG/x3H1rUvzqfaF