https://www.ssforce.cn/archives/314

结论:要么成为20%的Ops,要么职能尽量更前置、更顶端

最初研发兼任运维职能,而后发现运维需要专业化分工,遂拆分独立工种。

拆分发展期间各方技术&理念不断进化,但运维实质上一直处于被动,成为优质的“背锅侠”,其属性在独立工种阶段难以扭转,这是因为在这期间运维所起到的价值并非由运维自身所决定,而是由整个软件交付体系&生命周期、产品市场运营体系、甚至公司层面所决定。

在一家公司业务快速扩张过程中,上业务、抢市场这无可厚非,但很可悲的是一方面位于技术体系末端的运维往往眼睛很难看到技术、业务的前头,另一方面,作为优质的“兜底”牺牲自身发展成全业务也是天生其“使命”。

但自然生存法则不会考虑这些,只认结果,所以大部分Ops如果不能成为20%(跑的更快前置于技术&业务、提升价值&定位),其实结果一定是悲剧的。

现在无论是谁发起DevOps还是OpsDev,那都是因为运维的职能无法从更宏观角度去满足技术、业务发展的要求,原本对称的社会的供需关系失衡而已,但不管你承认与否,这就是强迫被迫转型而已,只不过有了更好的由头。

退一步,无论跑的再快快到前置在技术&业务前;积极运作转型,提升运营价值、拔高定位,又如何?况且在一个复杂的技术体系和业务迭代动态过程中,能否做到这点也是个疑问。

所以,如果作为运维你现在无法抉择,未来是选择技术继续攻坚还是选择管理。没关系,在职能选择上:尽量选择一个更前置、更顶端的职能。