运维的价值为何经常被挑战？哪些工作更有价值？

今天聊一下这个很让人扫兴的问题。刷进来的人，大概率至少是总监以上角色，或者有追求、善于思考的运维人员。握个手，幸会。
谁来回答这个问题

普通运维工程师无需回答，因为这是 CTO 最应该回答的问题。CTO 作为运维总监的领导，之所以要搭建运维团队，必然有其理由。如果 CTO 回答不了这个问题，这个 CTO 不称职。
作为普通运维人员，也可以尝试去思考这个问题，站在更高位置思考，未来才有可能爬到那个位置。
运维总监也应该理清这个问题。因为这个团队就是运维总监领导的，很多决策都是他和 CTO 共创的。他后续要招多少人、工作方向等，都和自己要创造的价值息息相关。
谁会问这个问题

最典型的是业务研发。业务研发觉得运维那摊事，他也能搞，现在让一个单独的运维团队来搞，增加了他的沟通成本，而对于结果，他又未必认可，于是他这个角色容易抛出这个问题。
这里的核心点是：

• 研发人员看到的运维的工作，是否是全貌，是否有失偏颇。如果研发人员看到的压根不是运维工作的全貌，那他这个问题的前提就是错的。（当然，站在运维的角度也需改进，你的工作成果为啥没有很好的呈现出来？）
  
• 如果研发人员看到的就是运维工作的全貌，仍然觉得运维没有价值，他可以取而代之。那本质上，研发人员就是顶着“研发”的岗位，干着运维的活，如果工作内容和方式没有变化，那他就变成了运维，只是汇报关系上不同罢了。
  

那最初的这个问题是否就没有价值了？非也。仍然很有价值，这敦促我们从根本上来思考岗位的价值和方向，对于未来工作给予指引。

如果每天都是在干一些不被认可的事情，那确实很痛苦。所以我们更要想清楚，哪些价值更容易被认可。

什么情况下会被挑战

其实，「运维的价值是什么」这个问题有些过于大了。但是大问题 + 部分事实才有流量啊，哈哈。开个玩笑啦。咱们不从流量出发，就只是从局内人的角度思考。就当理一下自己的工作也好。
一个问题要加很多限定词，才能精确描述，这个运维价值的问题，依旧如此。比如如下两个岗位：

• 产品自研的互联网公司的业务运维人员
  
• 产品外采的券商的交易系统的运维人员
  

岗位1被挑战的概率较高，岗位2估计不会被挑战，岗位2甚至都没有对口的研发。所以岗位2确实更幸福一些，至少不会被这样的破问题挑战不是嘛（诸位，择业方向的选择可以参考下，哈哈）。
那我们就来描述这个最可能被挑战的情况，其具备如下特点：

• 关键 IT 系统是自研的，同时有研发和运维人员，互联网公司居多；
  
• 研发人员的一些想法需要运维人员的首肯（可能是被框住了被限制了不爽了，进而产生这样的挑战）；
  
• 研发人员觉得运维这摊事，他可以用更好的更自动化的手段来解决，不需要这么多运维人力（可能是觉得运维占用了太多HC，自己可以做的更好）。
  

核心就是被框住和限制了，以及自认为可以比运维干得更好。
研发感觉被框住和限制了

其实，从 CTO 视角来看，这确实是运维的一个重要价值。如果研发人员没有规矩方圆，想怎么选型就怎么选型，想怎么操作就怎么操作，那结果就参差不齐了。
水平高的研发团队，可以做的很好，水平低的研发团队，就搞的乱七八糟。从 CTO 角度，肯定是希望提高下限的，所以就会构建一个横向组织：运维，来贯彻落实一些要求、规范。进而导致研发人员觉得被框住和限制了。

运维的核心价值之一：贯彻落实公司级的一些要求、规范，尤其是稳定性、变更、技术选型等方面。在这个场景下，运维就是 CTO（或技术委员会）的手。

所以，如果研发是因为被框住难受了进而导致对运维团队的价值挑战，可以不予理会。

顺带说一句。很多公司的运维人员是没有统一的组织的，是散落在各个研发团队内部干着运维的活，笔者觉得这样不好。一个是因为无法构建全局合力，无法作为 CTO 的手，另一个也是不好考核，毕竟运维人员和研发人员的能力要求是不同的。

研发觉得自己可以干得更好

这一点，本质上，研发不是说运维的事情没有价值，而是觉得运维做的不够好。这要引起足够的重视。
研发人员相比运维人员，通常来讲（别钻牛角尖，说的是一个大概平均情况）：

• 代码能力更强，对业务的理解更强，对自己所负责的系统的架构更清楚
  
• 系统管理能力更弱，对生产环境的敬畏感较差，见识的场景更少
  

进而，研发人员可能会觉得在下面这些方面可以做得更好：

• 有些可以工具化、平台化的事情，比如变更，运维没有做好
  
• 生产环境告警 OnCall，觉得运维人员的问题排查太慢
  
• 对业务不够熟悉，容量规划做的不好，无法应对突发流量
  
• 等等
  

在本文中，我不想跟大家逐一探讨每个事情怎么做更好，因为每个公司业务情况各异，我也没那本事，不过我感觉有些原则是提炼出来，对研发、运维的边界划分上，会有帮助。
如何划分运维、研发边界

有些事情、有些场景确实更适合研发来做，运维强出头事倍功半。运维做哪些事情更有价值？我个人感觉可以概括为如下几点：
建设公司级的统一的运维类平台

业务研发的主力任务是去做业务功能研发，而不是做运维类平台，所以运维类的平台让运维团队来干就很合适。比如：

• 统一的资产管理平台
  
• 统一的变更发布平台
  
• 统一的容器管理平台
  
• 统一的开关管理平台
  
• 统一的切流平台
  
• 统一的机器权限管控平台
  
• 统一的监控/可观测性系统
  
• 统一的故障演练系统
  
• 统一的预案管理
  
• 统一的 SLO 管理
  
• 统一的复盘历史知识沉淀
  
• 等等等等
  

<blockquote>
工作内容比较多，业务可能等不及，君子善假于物，有些平台工具可以外采或利用开源工具实现。比如笔者主导的开源监控项目：夜莺监控 就可以帮你解决统一指标、日志监控，统一告警分发的需求（广告硬入了
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！