研发效能|DevOps 是运维还是开发?

研发,效能,devops,还是,开发 · 浏览次数 : 338

小编点评

**DevOps 是研发工程师序列,偏向研发域,而不是运维域。** DevOps 团队负责开发产研基础设施的团队,而运维团队负责底层基础设施的建设。

正文

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

与研发效能|DevOps 是运维还是开发?相似的内容:

研发效能|DevOps 是运维还是开发?

DevOps 到底是 Dev还是Ops?答:属于研发工程师序列,偏向研发域,而不是运维域。 DevOps是研发工程师 DevOps 主要服务的对象就是所有产研团队的人员,与产研团队打交道比较多,相互配合更多,所以 DevOps 划分到 Dev 一侧比较好。 Ops 更专注底层基础设施,IaaS,Pa

DevOps|研发效能不是老板工程,是开发者服务

有人说研发效能是老板工程。不是的,研发效能不是老板工程,它不直接服务于老板(虽然老板可能看一些报表),反而是服务于广大产研运(产品+研发+质量+运维)的同学,所以有的公司也把研发效能叫做基础中台,平台工程,开发者服务团队,或者叫开发者服务平台。做好研发效能,做好开发者中台,就容易把公司的各种中后台能

DevOps|研发效能解决的是企业效率问题

研发效能并不能解决企业效益问题 它不是利润中心,不能给你带来直接收入(研发效能相关工具厂商做咨询、出方案、卖工具除外)。想要解决企业效益问题,依赖于企业战略、业务/产品、组织、运营、创新等其他方面。 研发效能解决的是企业效率问题 研发效能解决的是企业内部「产研运协作效率」的问题。 企业最需要两种涉及

DevOps|研发效能价值如何衡量

现在很多公司都在做或者计划做研发效能,也知道研发效能工作很重要,能提高产研运同学的协同效率,提高员工的工作效率和质量,提高业务交付效率和交付质量,但是价值有多大?效率又有多高呢?因为不容易说清楚,所以经常碰到一些质疑和灵魂拷问。 如何衡量研发效能的效果? 如何衡量研发效能的作用? 如何说清楚研发效能

DevOps|破除壁垒,重塑协作-业务闭环释放产研运协作巨大效能

- 会议太多了,员工开会效率降低了50%! 上篇文章《研发效能组织架构:职能独立vs业务闭环》介绍了职能独立型组织架构和业务闭环型组织架构的特点,优劣势。也许有的小伙伴可能对这两种组织架构没有深刻的体会,而本文就是想通过数据说话,想仅仅通过计算这两种组织架构下开会时间这一项,让大家知晓职能型组织架构

研发效能|DevOps 已死平台工程永存带来的焦虑

最近某位大神在推特上发了一个帖子,结果引来了国内众多卖课机构、培训机构的狂欢,开始贩卖焦虑,其实「平台工程」也不是什么特别高深莫测的东西。闲得无聊,把这位大神的几个帖子薅了下来,你看过之后就会觉得没啥,都是熟悉的东西。 Sid Palas & 平台工程 这位大神的名字叫 Sid Palas,一位专门

DevOps |研发效能之环境、程序、配置、SQL变更管理

本文主要是讲如何建立有效的环境、程序、配置、SQL变更和管理平台。 ​几天前和一个朋友聊到环境、程序的配置变更,SQL变更和整个上线流程。之前我们在这块也做了很多,有做的好的也有做的一般的,借机都总结下来,希望对你有用。 通常情况下,我们最关注的也是最重要的部分是应用的变更,就是程序的部署上线发布这

DevOps|研发效能团队组织架构和能力建设

研发效能团队相对于各个公司主营业务规模来说并不是很大,但是在经历的几家公司里主要是有两种组织架构,职能独立型组织架构和业务闭环型组织架构。本文主要讲解这两种组织架构的特点、优劣、劣势。 业务闭环组织架构 这里引入了一个概念-特性团队,以及特性团队的负责人(FTO),更多的内容在我之前的文章《研发效能

DevOps|研发效能治理:进化史、规模化与治理复杂性

麻广广@码猿外 研发效能这个词近几年火遍全网,各大企业都加入了研发效能治理的行列,开始梳理企业内部各个团队的研发流程,以期望找到企业降本增效的方向。 抛开政治因素,研发效能治理我们到底是在谈什么呢?从企业高管的视角出发,一定是看到了一些问题,才会有研发效能治理这个话题。从实施者的视角出发,研发效能治

devops|中小公司不要做研发效能度量

我特别反感那些不顾公司现状一上来就想要做研发效能度量的人,尤其是想把研发效能度量当成锤子四处去敲打螺丝钉的人。 没几个人的小公司上来就做研发效能度量,就如同普通人一上来直接问媒婆怎么能娶到迪丽热巴。解决办法无非把大象装冰箱里的那三步。套用一下,公司想要做好研发效能度量也有标准的三步:长时间对研发效能