DevOps、持续交付、运维到底难在哪儿?

阅读数:14 2020 年 3 月 16 日 20:30

DevOps、持续交付、运维到底难在哪儿?

DevOps 也好,持续交付也罢,还是谈了这么多年的运维和 CMDB,讲了这么多年,各种大会的分享和各大社区的经验文章如此之多,但是这些话题依然火爆,依然是各大企业的痛点。

是因为这些东西真的很复杂,很难吗?

其实从理念、方法或者实践角度,现在网上的资料一大堆,大同小异,一点都不复杂,道理看看也都懂,甚至各种大会讲来讲去也就那些东西,万变不离其宗。

但是轮到自己做,就是不知道咋整,这些理念和方法,到底难在哪儿呢?
其实,难就难在在落地上。

比如,要 DevOps 一体化,但是像金融行业,因为监管因素,就是要求要开发和运维分离,你说要开发作为 owner 从前到后全都负责,那是不可能的,监管就不允许开发动线上设备和数据。

要做持续交付,做自动化,大家都是知道要先做标准,但是像金融行业,运营商行业,这么多年的 IT 建设,这么多积累,这么多遗留系统,而且大多是外采购第三方,哪来的标准?怎么做?

第三方采购来的软件,我们说从研发到运维持续交付,怎么持续?按照标准交付流程,客户的系统是不可能跟第三方的研发环境拉通的,双方都不允许,也做不到,完全两个不同的环节。

再就是,很多传统企业的组织架构,就是职能部门划分严格,界限清晰,我们说要打破部门墙就要打破,说拉通就拉通,这么多年的建立起来的利益和权利均衡态势,说变革就变革,这基本是根本不可能的事情。

所以,理论方法不难理解,道理大家都懂,真正的关键点也就那些,但是真正落地会遇到各种问题,各种不满足。

所以,谁能在这种复杂背景下,能够更好落地这些理念方法,那才是牛逼的人,牛逼的产品。

所以,知易行难,难就难在这些地方。

其实现在云产品的使用也大量存在这样的问题,怎么从现有架构和体系迁移到云上,用云的产品支撑业务跑起来。

这也是我为什么前面一直在说,有时候产品很重要,但是负责产品落地的那些架构师更关键,能解决问题的人,非常非常关键。

本文转载自成哥的世界公众号。

原文链接: https://mp.weixin.qq.com/s/VXGLgfuPVxch2Xyut4g0Zw

评论

发布