- Java锁的逻辑(结合对象头和ObjectMonitor)
- 还在用饼状图?来瞧瞧这些炫酷的百分比可视化新图形(附代码实现)⛵
- 自动注册实体类到EntityFrameworkCore上下文,并适配ABP及ABPVNext
- 基于Sklearn机器学习代码实战
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是运维还是开发?的文章就讲到这里了,如果你想了解更多关于研发效能|DevOps是运维还是开发?的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
我是一名优秀的程序员,十分优秀!