前言

技术运维作为站在研发团队背后的群体，一直在担任着举重若轻的角色，而这两年盛行的Devops、研效变革也直接影响到技术运维同学岗位职责的变化，每一个运维人都需要保持自己在运维领域的自我修养水平与警觉，把自身未来的成长、运维人的定位，文化，价值观与行业发展紧密同步，谋求不断进步。

正文

很多人认为运维应该是在机房搬服务器，插拔网线，调试网络，或者修电脑的。但我们自己觉得运维应该是个比较“高雅”的职业，每天状态是在办公室，泡杯茶或咖啡，面对电脑处理着工作....但实际上呢，其实还是挺苦的，很多运维同事都是救火的状态，觉得特像消防员，每天都是在面对各种线上问题，半夜还要值告警，特别辛苦同时压力也会很大。

说着高大上，做着辛苦累。

运维的工作分类

运维这个职业有很多工种，比如说我自己是做业务运维，主要是面向业务的；还有系统运维，比如负责网络，操作系统的、底层IaaS的等等；还有一类是数据库DBA，是专门负责数据库；还有专门负责安全的安全运维；还有运维开发，Devops（AIOps）负责开发运维工具和平台；还有日常办公维护的小伙伴，做IT运维。

因为现在大部分的基础设施都云化了，如果按照云的维度来看，又可以分为SaaS、PaaS和IaaS运维。

技术成长

技术成长也是很多同事在聊的话题，比如最近状态不好，每天都在这干一些重复的事情，也不知道有没有前途，也不知道技术该怎么发展。但其实关于技术成长有个很好的实践，就是公司P族的技术运营通道，通道给出了很详细的能力模型系统，分了很多的子通道，每个都有一套完整的模型和能立项。

**到底什么是SRE？起源Google的VP Benjamin在2003年加入谷歌时，当时Boss给他的任务是让他组建一个由7名工程师组成的生产团队（Production Team）。要知道，在这之前他一直都是个写代码的程序猿！所以他只能按照我自己对运维的理解和想法和组建和带领这个团队，这个团队就成了今天Google的SRE团队，这个团队也一直坚守着由一位终生程序猿设定的初心。

SRE团队中的角色分为两类，其中50%-60%的成员就是Google的软件工程师；其余40%-50%的成员他们本身符合85%-99% Google软件工程师的招聘标准，但他们具备一些软件工程师没有的技能，例如Unix系统、网络（1层-3层）方面的专家，这些技能对SRE来说是非常有用的。所有的SREer都要求有能力和意识通过开发软件系统来解决负责问题。在SRE内部，通过跟踪调研以上两类成员的职业发展轨迹，我们发现并没有什么不同；事实上，不同背景的SREer让我们的团队产出了智能、高质量的运维系统。

核心竞争力是什么

运维人的维人的核心竞争力是什么，所谓核心竞争力是不可替代性，应该怎样去做与考虑个人能力能做到什么水平，不可能大家都是大佬，大佬也树业有专，因人而异。

第一个核心竞争力是对操作系统掌握。原来最早做运维的人就是所谓的古典派，他们对操作系统是非常深入的。我们现在很多应用和服务还是跑在Linux或者unix操作系统上，所以对应出现问题应该怎么去排查，性能怎么去优化，监控怎么去做，而这些都是需要对操作系统原理和架构清楚的，所以操作系统是很核心很基础的。

第二个核心竞争力是对业务和架构的深入掌握。运维会负责不同产品，它们之间的区别到底是什么，我觉得就是对所负责的业务和架构的深入理解。比如我是做存储的，对整个存储的架构，整个链路，底层的理解，以及关联的存储网络、存储硬件的了解和掌握，是你不可替代的部分。这是未来你再去找工作，大家最看重的东西，即在实践中进一步抽象技术经验与对理论更加深入的理解运用，乃至对新项目业务的无差别审美观概述能力。

到底怎么深入，大致可以用这样一个路径。比如一个开源软件，开始做肯定从网上找一些资料部署起来，稍微改一改，可以运行起来其实这才仅仅是第一层；然后你发现这个性能好像上不去，那就去研究哪些配置可以深入优化下、适配业务，所以第二个层次是能够做些配置的优化；第三个层次，是发现有一些功能没有，比如可能会基于它的源码做一些插件，去实现它的更多功能；再往下深入，就是让自己要去重新造跟这个一样的东西（原来我们也干过这个事情，比如说重新写一个做接入程序，有没有这样的能力能够把他包起来）所以它是一层一层往后去深入的，大家可以看下到底现在在哪一层，就可以很清晰地知道应该再往哪一层去深入。

第三个，方法论。用听到过一个人经历来举例，他原来一直做存储，然后负责数据库，当时没有数据库的经验，基本上就是知道最基础的操作而已，这种水平在操作中就会感到很虚。但后来去做了，由于之前的技术精而且基础牢固，新业务中很多事情其实是差不多的。

首先数据库业务也要关注故障生命周期，都要做监控、定位、预案恢复；当然也有不一样的地方，原来存储巡检的是硬问题、存储节点状态，数据库巡检是主从状态（是不是断开了，是不是延迟），这就是业务差异化的内容；所以可以把原来做存储的一些思路，拿来去做数据库，除可能有一些上层的业务不太了解，其他还是能够复用的。专业和业务层面也不用当心，会有专门的同学来帮助我们学习。

所以，当做一个产品很久之后，有没有去总结这个产品，比如应该怎样去运维，如果给你一个新的产品任务，能不能把你原来的经验抽象出并且把它复制到一个新的产品，把这个产品做好。比如存储做好了，可以经验复制到数据库，比如再去做CDN能不能做，只有个人不停总结去提升，然后把它变成方法论，这样本身的能力就是在提高的，而且个人的scope也变得越来越大。方法论其实是挺重要，尤其是方法论本身的迁移的能力。

运维的核心，就是这三个（方法论、业务和架构、操作系统）。

运维最终的发展方向

最后，运维最终出路是什么？

常规的理解是，首先是这个问题在于说大家把自己的角色想得太局限了，总是认为自己是一个运维工程师，就应该天天去看监控、变更，故障处理等等。但这里有一个思路，把运维最终归宿看成是业务。举个很简单的例子。

原来做运维的时候，每天都要做告警轮值，这件事情不仅在运营团队，在研发团队，在各种团队都有需求，收集各小组的日常工作开发成一个平台，先在公司内部推广使用，功能成熟后把这个平台变成一个产品卖给其他的公司。这其实就是把运维的这件事情产品化了，销售出去卖钱。

最后一句话，不会开发的运维不是好的产品经理。现在对运维的要求越来越高，个人除了会运维之外，还要会开发，像DevOps，结合业务，还是需要有很多的产品思维和产品能力，这样才能够不断拓宽个人的职业道路！