融会贯通之树业有专 |
职业小结 |
技术运维作为站在研发团队背后的群体,一直在担任着举重若轻的角色,而这两年盛行的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,结合业务,还是需要有很多的产品思维和产品能力,这样才能够不断拓宽个人的职业道路!