运维的价值为何经常被挑战？哪些工作更有价值？
今天聊一下这个很让人扫兴的问题。刷进来的人，大概率至少是总监以上角色，或者有追求、善于思考的运维人员。握个手，幸会。
谁来回答这个问题
普通运维工程师无需回答，因为这是 CTO 最应该回答的问题。CTO 作为运维总监的领导，之所以要搭建运维团队，必然有其理由。如果 CTO 回答不了这个问题，这个 CTO 不称职。
作为普通运维人员，也可以尝试去思考这个问题，站在更高位置思考，未来才有可能爬到那个位置。
运维总监也应该理清这个问题。因为这个团队就是运维总监领导的，很多决策都是他和 CTO 共创的。他后续要招多少人、工作方向等，都和自己要创造的价值息息相关。
谁会问这个问题
最典型的是业务研发。业务研发觉得运维那摊事，他也能搞，现在让一个单独的运维团队来搞，增加了他的沟通成本，而对于结果，他又未必认可，于是他这个角色容易抛出这个问题。
这里的核心点是：
- 研发人员看到的运维的工作，是否是全貌，是否有失偏颇。如果研发人员看到的压根不是运维工作的全貌，那他这个问题的前提就是错的。（当然，站在运维的角度也需改进，你的工作成果为啥没有很好的呈现出来？）
- 如果研发人员看到的就是运维工作的全貌，仍然觉得运维没有价值，他可以取而代之。那本质上，研发人员就是顶着“研发”的岗位，干着运维的活，如果工作内容和方式没有变化，那他就变成了运维，只是汇报关系上不同罢了。
那最初的这个问题是否就没有价值了？非也。仍然很有价值，这敦促我们从根本上来思考岗位的价值和方向，对于未来工作给予指引。
如果每天都是在干一些不被认可的事情，那确实很痛苦。所以我们更要想清楚，哪些价值更容易被认可。
什么情况下会被挑战
其实，「运维的价值是什么」这个问题有些过于大了。但是大问题 + 部分事实才有流量啊，哈哈。开个玩笑啦。咱们不从流量出发，就只是从局内人的角度思考。就当理一下自己的工作也好。
一个问题要加很多限定词，才能精确描述，这个运维价值的问题，依旧如此。比如如下两个岗位：
- 产品自研的互联网公司的业务运维人员
- 产品外采的券商的交易系统的运维人员
岗位1被挑战的概率较高，岗位2估计不会被挑战，岗位2甚至都没有对口的研发。所以岗位2确实更幸福一些，至少不会被这样的破问题挑战不是嘛（诸位，择业方向的选择可以参考下，哈哈）。
那我们就来描述这个最可能被挑战的情况，其具备如下特点：
- 关键 IT 系统是自研的，同时有研发和运维人员，互联网公司居多；
- 研发人员的一些想法需要运维人员的首肯（可能是被框住了被限制了不爽了，进而产生这样的挑战）；
- 研发人员觉得运维这摊事，他可以用更好的更自动化的手段来解决，不需要这么多运维人力（可能是觉得运维占用了太多HC，自己可以做的更好）。
核心就是被框住和限制了，以及自认为可以比运维干得更好。
研发感觉被框住和限制了
其实，从 CTO 视角来看，这确实是运维的一个重要价值。如果研发人员没有规矩方圆，想怎么选型就怎么选型，想怎么操作就怎么操作，那结果就参差不齐了。
水平高的研发团队，可以做的很好，水平低的研发团队，就搞的乱七八糟。从 CTO 角度，肯定是希望提高下限的，所以就会构建一个横向组织：运维，来贯彻落实一些要求、规范。进而导致研发人员觉得被框住和限制了。
运维的核心价值之一：贯彻落实公司级的一些要求、规范，尤其是稳定性、变更、技术选型等方面。在这个场景下，运维就是 CTO（或技术委员会）的手。
所以，如果研发是因为被框住难受了进而导致对运维团队的价值挑战，可以不予理会。
顺带说一句。很多公司的运维人员是没有统一的组织的，是散落在各个研发团队内部干着运维的活，笔者觉得这样不好。一个是因为无法构建全局合力，无法作为 CTO 的手，另一个也是不好考核，毕竟运维人员和研发人员的能力要求是不同的。
研发觉得自己可以干得更好
这一点，本质上，研发不是说运维的事情没有价值，而是觉得运维做的不够好。这要引起足够的重视。
研发人员相比运维人员，通常来讲（别钻牛角尖，说的是一个大概平均情况）：
- 代码能力更强，对业务的理解更强，对自己所负责的系统的架构更清楚
- 系统管理能力更弱，对生产环境的敬畏感较差，见识的场景更少
进而，研发人员可能会觉得在下面这些方面可以做得更好：
- 有些可以工具化、平台化的事情，比如变更，运维没有做好
- 生产环境告警 OnCall，觉得运维人员的问题排查太慢
- 对业务不够熟悉，容量规划做的不好，无法应对突发流量
- 等等
在本文中，我不想跟大家逐一探讨每个事情怎么做更好，因为每个公司业务情况各异，我也没那本事，不过我感觉有些原则是提炼出来，对研发、运维的边界划分上，会有帮助。
如何划分运维、研发边界
有些事情、有些场景确实更适合研发来做，运维强出头事倍功半。运维做哪些事情更有价值？我个人感觉可以概括为如下几点：
建设公司级的统一的运维类平台
业务研发的主力任务是去做业务功能研发，而不是做运维类平台，所以运维类的平台让运维团队来干就很合适。比如：
- 统一的资产管理平台
- 统一的变更发布平台
- 统一的容器管理平台
- 统一的开关管理平台
- 统一的切流平台
- 统一的机器权限管控平台
- 统一的监控/可观测性系统
- 统一的故障演练系统
- 统一的预案管理
- 统一的 SLO 管理
- 统一的复盘历史知识沉淀
- 等等等等
工作内容比较多，业务可能等不及，君子善假于物，有些平台工具可以外采或利用开源工具实现。比如笔者主导的开源监控项目：夜莺监控 就可以帮你解决统一指标、日志监控，统一告警分发的需求（广告硬入了🤣）。
建设公司级的统一运维流程、生产规范
比如笔者上家公司的运维团队，就颁布了生产环境变更的五条军规：
- 提前通报要记得
- 变更步骤要完备
- 分级发布要遵守
- 高峰窗口要避免
- 服务检查要执行
咱姑且不论这五条军规的细则是否合理，每个公司情况不同，但是有意识的去产出、推动落实这些军规，对生产环境的稳定性肯定是有帮助的。
其他的，比如业务程序如何埋点、如何部署、如何备份、如何限流降级、如何回滚、如何告警、如何排障、如何复盘等等，在很多环节中都可以制定相关的最佳实践、甚至是军规红线。
这些流程规范要得到各个研发团队负责人的认可，就方便推进了，一些管理班委会在这里要起到重要作用。
业务技术扶贫
如果某些业务的研发很强，像 OnCall 排障这样的工作，人家自己干觉得也能行，那就让他们自己干呗，没必要非得去支持。除非他们愿意承担 SRE HC，主动寻求 SRE 帮助，此时他们也不会挑战 SRE 的价值了，毕竟是他们主动找来的。
有些业务的研发水平不行，或者说他们的精力去开发功能都不够用，OnCall 更是精力不够用，此时肯定愿意寻求 SRE 帮助，愿意承担 SRE HC，等过一段时间，业务团队成长起来，SRE 再退出亦可。
如上，就是 Google SRE 的典型 HC 分配方式。
技术选型和架构设计，也很典型，很多业务团队都希望 SRE 尽早参与其中，帮他们找到设计不合理的点，愿意承担 SRE 的这部分投入。
但是，也有些研发团队觉得自己牛逼，或者觉得自己特殊，在技术选型方面，想自己造轮子。不需要 SRE 参与，一般公司不建议这样，因为 SRE 秉承的是技术委员会的要求，是公司的统一规范，业务研发团队自己搞，容易出纰漏（典型的比如团队选型了某个基础组件，但公司没有提供专门的运维团队）。
不过，确实有大公司实践中是允许业务自己搞的，比如 NetFlix，他们的 Chaos Monkey 做得很好，允许业务自己选型，但是业务自己选型之后，最终是要通过 Monkey 大军的检测的，如果无法通过，那不好意思没法上线。而使用公司推荐的基础设施和框架，通过的概率更高。
如上，我是把运维的这个价值，称之为 “技术扶贫”。运维人员深入业务，帮业务干一些工作。
当然，有时不需要这么深入，只是做一些教练、培训、咨询之类的工作，那多个业务团队其实可以复用一个运维人员，这种协作模式姑且称之为 “运维BP”。
结语
我们从“运维的价值是什么”作为问题出发点，最终总结运维工作的侧重点应该是哪里。希望对你有些帮助。
