前段时间和不同的人交流了DevOps平台后,大概了解了行业里DevOps平台是怎么回事。
DevOps平台最大的问题
DevOps的定义是什么?面对这样的问题,我想说行业里,10个人可能有11个答案。既然DevOps的定义在行业都没有一个权威的定义,那么,对于DevOps平台是什么这样一一个问题,自然也就没有权威的定义了。这就是行业里DevOps平台最大的问题。
P.S. 对于DevOps Master证书又应该如何定义呢?
如果DevOps平台没有定义,那么,我们就无法以下类似的问题:
它解决了谁的什么问题?
行业里,它的趋势是什么?
DevOps平台发展到后期,是不是AIOps?
因为,你再怎么回答这些问题,只要你与提问人对于DevOps的认知不一样,你都会与提问人内心的答案不一样。
这让我想起马斯克的名言:我现在不和人争吵了,因为我开始意识到,每个人只能在他的认知水准基础上去思考,以后有人告诉我2+2等于10,我会说,你真厉害!
谈DevOps平台的设计
我看到的是它们有很多功能:项目管理、需求管理、测试管理、流水线、制品管理、自动化部署……所有人都类似地美其名为:一站式研发云平台。
可是,当你在使用时,你会发现,它们不过是在以前的项目管理平台、测试管理平台、流水线平台、制品管理平台、部署平台等多个平台的功能的重新堆砌。而这些功能之间有有联系吗?很少。
行业里不少客户会要求DevOps平台的Dashboard,不同的角色进入要显示不一样的东西。其实就是开发者进入Dashboard应该只显示开发者关心的功能,测试人员进入Dashboard应该只显示测试用例相关的功能……这是不是可以成为康威推论的一个佐证?
总的一句,DevOps平台不过是过去多个不相关的烟囱系统,通过一个Dashboard,让它们显得像是一个平台。
研发效率有最优解吗?
和这么多人交流后,发现大家还是有一些共识的。那就是:DevOps平台应该是可以提高研发(or 运维)效率的(如果我只说研发效率,估计有人会以为我认为DevOps平台只是为研发侧服务的)。
行业里,To C产品的设计,最优解通常是未知的,是需要不断寻找的。所以,发展出各种方法论寻找方法论。这对于To C产品的设计是有效的。因为它的前提是最优解真的在于用户。
抛开产品设计方法论,对于研发效率的提升这个领域, DevOps平台的设计者应该比用户知道最优解是什么?
那我们使用To B的产品设计方法论去设计如何?个人觉得,即对,也不对。对的地方是DevOps产品毕竟是卖给企业的,所以,在设计DevOps时不得不考虑谁给它买单这个问题。不对的还是我上文提的最优解问题。
DevOps平台与Srcum、敏捷、迭代开发之间的关系
如果你的DevOps平台不与这些听起来牛x、高大上的名词关系起来,在这个行业里,你的产品估计有点难打开市场。
这就要求,我们在设计DevOps平台时,不得不考虑行业里的人对于Scrum、敏捷、迭代开发的理解。
个人觉得难点在于:在DevOps平台的设计上,无论用户希望使用何种方法论,都能在平台内实现DevOps平台本身的目标,同时平台还能保持自身的简洁。
用户使用那些方法论背后的目的才是关键。
后记
感谢这些同学花时间与我交流。让我学习到很多。
推荐阅读: