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｜中小公司效率为王，没必要度量