DevOps 到底是 Dev还是Ops?答:属于研发工程师序列,偏向研发域,而不是运维域。
DevOps是研发工程师
DevOps 主要服务的对象就是所有产研团队的人员,与产研团队打交道比较多,相互配合更多,所以 DevOps 划分到 Dev 一侧比较好。
Ops 更专注底层基础设施,IaaS,PaaS,和应用稳定性这些方面。
通常 DevOps 团队是负责开发产研基础设施的团队,反而里面很少有 Ops 工程师,基本上都是产品、开发和运营人员,我们都是当作一个业务团队来运转。
我负责 DevOps 团队时,有些运维的小伙伴也想在工作之余加入进来做些开发的工作,这当然是欢迎的。但是运维的小伙伴有很多自己本职的工作,过了一段时间我们都发现了问题。
-
运维的小伙伴本身很忙,只有很少甚至没有时间来写代码
-
项目排期紧,运维小伙伴领了开发任务,但是太忙了,根本无法跟上项目开发进度。
项目上的很多事情,都是有明确时间点的,没按期交付整个团队都受影响。尝试了一两个迭代后,我们就结束了这种做法。运维团队负责底层基础设施,我们负责上面的平台建设。我们做平台,他们用平台。
DevOps招聘误区
DevOps 的主要工作在开发,而不是 Ops。很多公司招很多运维来做 DevOps 系统,对于小公司也许可以,但是稍微大点的公司基本都不这么做。
招运维工程师来做 DevOps 一般都是小公司。你看我招了一个运维工程师还能做 DevOps 平台,一举两得,忙的时候做运维,闲的时候做运维自动化系统,「可是占了大便宜」。这些做法在公司还小的时候无可厚非,但是不能奉若至宝,认为这个道理放之四海哪里都可以跑得通。
其实对于小公司很少有资源真正投入到做 DevOps平台,也不需要开发工程师,一般都是配置管理工程师、QA、运维工程师一起配合就能搞定。只有公司体量起来了,需要自研了,才真正的需要 DevOps 工程师,但这时候更需要专职的研发工程师了,配置管理工程师和运维工程师也成了平台的业务方。
我们招聘 DevOps 工程师的时候都是直接招聘开发工程师。这里要注意的一点就是并不是所有的开发工程师都愿意做内部平台,做 DevOps 系统,因为内部系统的上限和业务研发对比太低了,提供的机会也少。这一点和国外很多公司有很大区别,招聘的时候一定要讲明白。否则人来了两天就跑了,浪费感情和精力。
运维平台建设
运维小伙伴在大多数公司都是人力资源不足的情况,公司也愿意把人力资源投入到业务,而不是支撑平台。运维小伙伴整天忙得脚都朝天了,其实即便主观能动上想去开发一些系统,也是心有余而力不足。我认识的很多运维小伙伴每天都要忙到半夜,有时后半夜还要处理监控告警、导数据、迁机器。
运维团队需要研发的很多系统谁来做呢?那些不直接面对用户、优先级不高的系统可以让运维团队看自己时间安排自主选择。其他系统都是我们团队在支撑。我们建设平台、运维小伙伴用,合理分工,各自安好。
小公司招聘运维工程师做DevOps平台想法是好的,但往往也就是给运维换了个头衔而已;小公司的运维太忙,根本没时间开发; 小公司也没资源投入到自研 DevOps 平台建设。多数情况下开源工具够用了(有点逼格的公司除外)。
本文小结
本文主要讲了 DevOps 工程师主要的工作属于研发工程师序列,偏向研发域,而不是运维域。与此同时,招聘的时候也要招聘一些踏实、靠谱、能力强的小伙伴。内部产研运协作平台不是一朝一夕就能做好的,需要长期、不断的投入,大处着眼,小处着手,一步步脚踏实地地往前走,最终守得云开见月明。
阅读我的更多文章
互联网公司研发效能/工程效率团队建设和规划
破局DevOps|8大北极星指标指引研发效能方向
DevOps | 产研协同效能提升之评审、审批流、质量卡点
DevOps|研发效能+项目经理PMO
devops|中小公司效率为王,没必要度量