和行业里多家DevOps平台的同学交流后，我发现……

sunset-815270_640.jpg

前段时间和不同的人交流了DevOps平台后，大概了解了行业里DevOps平台是怎么回事。

DevOps平台最大的问题

DevOps的定义是什么？面对这样的问题，我想说行业里，10个人可能有11个答案。既然DevOps的定义在行业都没有一个权威的定义，那么，对于DevOps平台是什么这样一一个问题，自然也就没有权威的定义了。这就是行业里DevOps平台最大的问题。

P.S. 对于DevOps Master证书又应该如何定义呢？

如果DevOps平台没有定义，那么，我们就无法以下类似的问题：

1. 它解决了谁的什么问题？
2. 行业里，它的趋势是什么？
3. DevOps平台发展到后期，是不是AIOps？

因为，你再怎么回答这些问题，只要你与提问人对于DevOps的认知不一样，你都会与提问人内心的答案不一样。

这让我想起马斯克的名言：我现在不和人争吵了，因为我开始意识到，每个人只能在他的认知水准基础上去思考，以后有人告诉我2+2等于10，我会说，你真厉害！

image.png

谈DevOps平台的设计

我看到的是它们有很多功能：项目管理、需求管理、测试管理、流水线、制品管理、自动化部署……所有人都类似地美其名为：一站式研发云平台。

可是，当你在使用时，你会发现，它们不过是在以前的项目管理平台、测试管理平台、流水线平台、制品管理平台、部署平台等多个平台的功能的重新堆砌。而这些功能之间有有联系吗？很少。

行业里不少客户会要求DevOps平台的Dashboard，不同的角色进入要显示不一样的东西。其实就是开发者进入Dashboard应该只显示开发者关心的功能，测试人员进入Dashboard应该只显示测试用例相关的功能……这是不是可以成为康威推论的一个佐证？

总的一句，DevOps平台不过是过去多个不相关的烟囱系统，通过一个Dashboard，让它们显得像是一个平台。

image.png

研发效率有最优解吗？

和这么多人交流后，发现大家还是有一些共识的。那就是：DevOps平台应该是可以提高研发（or 运维）效率的（如果我只说研发效率，估计有人会以为我认为DevOps平台只是为研发侧服务的）。

行业里，To C产品的设计，最优解通常是未知的，是需要不断寻找的。所以，发展出各种方法论寻找方法论。这对于To C产品的设计是有效的。因为它的前提是最优解真的在于用户。

抛开产品设计方法论，对于研发效率的提升这个领域， DevOps平台的设计者应该比用户知道最优解是什么？

那我们使用To B的产品设计方法论去设计如何？个人觉得，即对，也不对。对的地方是DevOps产品毕竟是卖给企业的，所以，在设计DevOps时不得不考虑谁给它买单这个问题。不对的还是我上文提的最优解问题。

DevOps平台与Srcum、敏捷、迭代开发之间的关系

如果你的DevOps平台不与这些听起来牛x、高大上的名词关系起来，在这个行业里，你的产品估计有点难打开市场。

这就要求，我们在设计DevOps平台时，不得不考虑行业里的人对于Scrum、敏捷、迭代开发的理解。

个人觉得难点在于：在DevOps平台的设计上，无论用户希望使用何种方法论，都能在平台内实现DevOps平台本身的目标，同时平台还能保持自身的简洁。

用户使用那些方法论背后的目的才是关键。

后记

感谢这些同学花时间与我交流。本文作为一篇交流文章，目的不是为了贬低DevOps平台。