2.4 贡献价值

运维如何贡献价值？自从运维这个岗位出现在互联网行业后，很多人都在说运维的价值。有的人会说保持业务稳定运行就是运维最大的价值，而有的人则会将运维视作一个没有办法的消耗部门，认为运维不会对业务有直接的价值。

如果在10年前，服务器规模还很小的时候，可能运维工程师也是这样认为的。但是随着近几年业务的发展，国内各大互联网公司需要维护的服务器突然有了一个巨大的上涨，几乎每个公司都开始维护从几万个到几百万个服务器节点。业务部门在扩张的同时也在不断地被成本挑战。这个时候再考虑运维，很多人突然发现运维是一个“挣钱”的部门。不同于其他业务部门的“挣钱”方式，运维可以通过优化资源、提升效率等多种方式非常直接地压缩业务的资产折损消耗。相比传统的运维模式，SRE团队在业务团队内的价值体现在以下几个方面。

1.维持业务高效运作

SRE相比传统的系统管理员、应用运维工程师等角色，很大的不同在于SRE 会主动改进开发部分的能效。SRE 的任务属性使得 SRE 会通过工具提升运维/开发中某些环节的自动化率，进而提升业务的迭代速度，让业务更快地响应市场的需求。例如，在之前的开发流程中，业务团队调整测试环境往往需要找多个角色的运维工程师修改配置，转变为SRE后，SRE只需要专门投入人力去分析跟进这样的需求，就可以通过工具打通整个链路。SRE在部分产品的实践中实现了功能测试环境（从建立云主机、发布、修改LB配置等环境）一键部署，将整个环境构建流程从小时级别压缩到分钟级别。

2.提升资源利用率

从本质上说，所有的业务团队和运维团队都希望自己有最多的服务器资源，这样可以规避很多问题。业务开发周期、新功能开发和代码优化效率其实是冲突的，为了让业务快点上线，很多代码难免会没有经过优化就直接部署到线上，多点服务器资源会让人心里踏实。

曾经有开发工程师辛苦调试了好久将JVM的内存优化了500MB，但最终他的优化并没有上线，因为大家发现新款服务器的内存可以直接翻倍，而优化 JVM 内容需要改动的代码太多。这种场景在软件行业并不是罕见的场景，代码推上去，业务功能对就好，优化交给编译器，这样做最终会看到一个结果：线上服务器的资源利用率往往会有问题。业务团队很多时候是很难预估线上资源需求的，久而久之线上服务器的“平均水位”就一直很低。

传统运维团队可能会关注这个情况，但一般从公司层的任务性来安排。常见的情况就是成本考核时，业务团队自己会因为成本压力而去压缩成本，这种压缩也只是停留在清理不用的服务器等一般操作上，传统运维团队在这个过程中只是配合角色。

SRE团队其实在这方面有很大的先发优势，因为SRE团队一般会要求业务团队对应用的SLI/SLO进行梳理，所以SRE团队对业务模块的资源消耗情况非常清楚。对线上业务团队来说，他们很多时候会关心自己代码的运行稳定情况，如果没有专业的SRE 团队评估，有时候会陷入申请过多资源的情况。SRE团队会根据业务模块的SLI/SLO等信息，结合监控等数据制定业务模块扩容或缩容的策略和逻辑（一般这个逻辑会和CPU、内存、负载等数据紧密相关）。有SRE团队介入的业务团队，一般资源情况会用得更合理。SRE团队不只是评估容量，更有可能会帮助业务团队规避常见的资源浪费情况。

例如，当一个业务团队遇到一个性能问题时，因为是代码偶发的问题，所以该业务在线上运行的时候不得不多部署50%的节点，防止突发性能异常请求处理能力下降。业务团队也想过办法去解决这个问题，但一直没有得到很好的结果。SRE团队介入后，通过分析相关程序的运行逻辑，结合操作内核的特性，最终定位到是因为程序某个系统调用在某些场景下在内核态有O（n）的复杂度。这个例子充分说明了SRE团队在资源优化层面可以做的事情比之前整风式的服务器资源回收要好得多。

更进一步的是 SRE 团队投入了大量的时间在运维优化上，SRE 团队会主动地去推动业务接入自动扩缩容，推动业务进行“削峰填谷”。这些都使整个公司在服务器资源消耗上获得了更多的提升。

3.减少业务中断

运维这个职业开始的第一天就在和减少业务中断做斗争。系统管理员、数据库管理员、应用运维工程师等各种细分的运维角色的KPI都会有与业务中断相关的指标，可以说减少业务中断是运维领域最重要的价值。相信之前很少有开发团队将减少业务中断作为KPI的重点。

传统的运维团队在这方面也有做很多的事情，但做的事情总感觉是填坑式的。大家在网上看到传统运维团队最多的情况就是说，“一到重要活动运维工程师就开始提心吊胆，生怕背锅”。这种情况在传统运维场景下会经常存在，尤其是当开发团队和运维团队存在沟通鸿沟的时候。原因很简单，传统模式下的运维团队是被动的，只能应对之前已经出现过的问题，很难及时跟进新的场景。简单举例，之前有业务在线上搞出问题了，事后复盘要划分责任的时候，开发团队和运维团队的责任就各占50%。可能运维团队觉得很冤，因为他们是按照开发团队说的操作的，而开发团队觉得整个过程是运维团队的操作触发的，运维团队应该要找他们确认细节。

转变为SRE后，SRE团队在减少业务中断上明显投入更多，至少如果出现上面例子中的场景，SRE团队事先会和开发团队进行确认，而不是进行简单的操作，或者直接让开发团队自己按照规范使用运维工具操作。SRE团队会不断地和开发团队沟通业务细节，当然制定SLI、SLO等指标本身就是化被动运维为主动运维的操作。SRE团队会根据业务中断的指标，开发控制风险的流程和运维工具，在技术和流程上对业务中断进行预防和保障。

更进一步的是SRE团队会在公司层对业务的稳定性进行约束，因为业务连续性在很多时候可以很直接地和金钱联系在一起。我们常说“一个回车下去大量的钱被烧掉”，有时候还真不是开玩笑的。有兴趣的读者可以查一下高频交易公司乌龙操作导致纳斯达克公司暴跌的事情，这就是一个典型的运维发布异常导致的线上事故。很简单的一个发布操作，因为没有按照运维规范执行，最终在短短的几小时内毁掉整个公司，由此可以看到SRE团队对公司的价值。