2.3 如何衡量工作

有些时候对运维工作的衡量其实不只是考虑运维团队的 KPI 有没有实现，更多的是考虑运维能效是否提升和运维做了哪些大型项目等。

但是当我们在支持跨境电商、云音乐这样的大型业务时，因为业务太庞大了，所以业务团队的领导有时候根本看不到运维团队做的具体效果。尤其是看到内部结算账单的时候，他们经常会考虑一个问题：运维团队到底做了什么事情？

运维工程师经常会拿一座桥的护栏比喻运维的工作：“运维是护栏，防止业务落水”，这个比喻在运维团队角度看很贴切，但是从领导角度看有些空洞。尤其是当考虑业务成本的时候领导就会想：“整个桥上的护栏都没有起作用，是不是就可以将这个桥的护栏去掉，只留两条绳索挡一下。”

为了解决这种情况，运维团队开始转变思路，开始根据业务团队的KPI同步制定SRE 的运维KPI。从源头上将运维团队和业务进行关联，初步解决了业务团队不了解运维团队到底做了什么事情的问题。随着时间的增长，业务团队的领导又开始提新的需求，这次他的需求是这样的：“虽然运维团队之前帮我们解决了很多的问题，但是做的事情很零碎，看不到更大的效果。”

这样的描述其实本身说明了业务团队已经认可了运维团队，也看到了运维团队对业务的推动，希望未来运维团队能给业务有更多更全面的推动。

在实际的工作中，我们按照业务团队的做事方式梳理了 SRE 团队新的KPI制定方式。

1.运维工作项目化

相比传统的运维工作，新形势下的SRE的运维工作更多地会通过梳理业务团队的业务需求和当前情况，项目化地制定运维工作计划。例如，线上当前有多次业务错误使用缓存的情况，SRE团队就可以通过收集此类问题的现状，整理之前发现的风险，项目化地制定一个缓存优化项目。

在实际落地过程中可以发现，因为缓存优化项目和开发团队一样需要分析问题、制定工作步骤、确定最终考核结果（一般会是减少延迟，提升缓存稳定等），所以最终执行的结果会更容易判读和理解。

2.运维项目评审

传统运维团队要推进什么项目，很多时候都是内部直接制定相关策略和逻辑后，“撸起袖子就干”。这种操作方式有一个很大的风险，就是很难获得业务团队的认同或支持，传统运维团队往往需要花很多的时间去说服业务团队。

例如，我们之前遇到的场景，当业务团队的工作核心还是业务新特性时，运维团队可能已经发现了线上的隐患（如机房容量不足，需要发起业务迁移改造），并启动了相应的项目。在最初发起项目的时候运维团队就直接遇到了来自业务团队的挑战，业务团队可能会给出“容量不会涨了”“项目开发更有限”等多种理由，直到项目完成落地，

SRE 团队的做法则是将项目整理信息后，邀请业务团队参与评审，通过评审实现运维项目的想法传达，同时争取业务团队的支持和认可。同样的机房搬迁项目，SRE 团队将自己的容量问题转述为和业务逻辑或特性相关的问题后，业务团队往往会更能理解和支持项目的执行。

当然运维项目让业务团队参与评审还有一个好处：业务团队对SRE团队执行的项目有清楚的认识，有利于业务团队更好地规划KPI，还可以方便他们衡量运维成效。

3.进度汇报和主动沟通

进度汇报一直是最直接的方式，在之前我经历的多个项目中，运维团队会经常发送周报给业务团队，也会定期安排季度沟通。我们发现有时候SRE团队的周报直接发送给对应业务团队后，也能获得对方的反馈。在部分业务团队中，SRE团队的周报和开发团队的周报都能相互看到，这种机制在很大程度上能减轻业务团队对运维团队工作的焦虑，增进双方的了解。

我们经常使用的一个汇报模板是运维周报格式样例，如表2-1所示。

表2-1 运维周报格式样例

如表2-1所示，一般周报汇报内容会包含时间、进度风险、运维工作汇总、下周计划等多个因素。这种简单的汇报表可以让业务团队的领导对业务运维情况有清楚的认知，也为业务团队和SRE团队的沟通提供了素材。

运维团队有时候也是需要刷一些存在感的，主动地沟通和情况说明是非常重要的方式，时不时地收集一些运维需求调查表、运维讲座需求等，可以很好地提升业务团队的运维服务体验。