理想化的DevOps团队里只需要有Dev就够了？

640?wx_fmt=jpeg

（图片来源于网络）

几天前，本公众号发布的一篇译文列举了9种DevOps团队结构适用类型与7种反型（点击查看原文）。文章转发到朋友圈之后，很多DevOps同行留言（吐槽）了自己团队的现状，其中大部分人都反馈自己的团队命中了7种反型中的“DevOps作为工具团队”这种结构。

为什么会出现这种现象？DevOps团队适合的结构应该是什么样的呢？难不成，所谓的DevOps从业者都只是一个“工具管理员”？

针对这些疑问，我们在“DevOps案例深度研究讨论群”组织了一场关于“DevOps团队结构”的群讨论，集中探讨以下2个问题：

1、为什么很多团队DevOps会成为工具链、流水线？

2、DevOps团队应该长什么样？

本文整理了这次讨论的精华内容，和大家分享。

话题一：为什么很多团队DevOps会成为工具链、流水线？

针对这个问题，大家的普遍观点是：DevOps本身的定义不清晰，但又需要有可衡量的标准和可执行的动作，而工具链是可以看得见摸得着的东西，简单直接，执行看得见，效果可衡量。

当然，这也不能全怪DevOps本身，更多的问题还是出在了人身上。关于这一点，可以从执行者和组织结构2个方面来看。

执行者层面，通常我们将知识划分为道法术器四个层面，器就是工具，是最好入门的，就像我们去学java，会打出来一个hello world就算入门了。

归根结底还是因为真正能踏踏实实钻研技术的人少了，DevOps的概念出现以后，像是一根救命稻草一样给大家营造了一个“理想国”，一窝蜂地扑上去，但发现并不是那么回事儿，DevOps的落地同样需要钻研，需要踩坑，但打出来一个hello world容易，具备编程思维难，这时候怎么办呢？

思维不够工具凑呗，毕竟...我们最擅长的就是站在巨人的肩膀上睡大觉了，“拿来主义”思维驱使下，让DevOps成为了工具链，做DevOps的人也就像是流水线的操作工一样。

很多人认为，有了工具就是CI/CD了，认为有了武器就能打怪升级，但是却忽略了心法和招式，其实武器只是对打怪效果的加成。

组织结构方面，DevOps是一种敏捷化的团队，打破了原本软件研发团队的分工模式，DevOps这个名字就是由开发和运维2部分组合起来的，好处在于方便了开发和测试的沟通，但事实上这只是小范围的沟通便捷了，而并不代表2个团队的沟通变得便捷了。

在执行过程中，DevOps更像是一个创新小组，创新小组意味着在不停地尝试和探索，而探索型的工作方式就需要组织，或者说老板，足够的宽容和有耐心，但实际上，这是99%的组织都不具备的“实验”精神。

再加上DevOps和老板之间的沟通障碍，很多时候老板/领导没有理解DevOps要做什么，为啥这么做。

DevOps的实施除了需要老板的支持外，还需要有很好的基础条件。但实际上呢，我们通常遇到的问题是微服务化不够、基础设施治理不灵活、单元测试不成熟、测试好做但测试数据不好解决等等问题。

在提出假设-实验-反馈验证-优化假设这个不断循环的实验演进过程中，我们需要时间和资源，但跑下去就会发现，很多节点我们打不通。比如测试的问题，测试的时候需要准备各种环境条件，逼着我们很多测试只能去预发布测试环境，但预发布环境和生产的数据是一致的，很多场景和数据是不能拿来做测试的。再加上复杂业务的应用特别多，准生产环境的维护本身就很困难，很难对齐到生产环境。

那么好了，测试数据搞不定，不能做验收测试，再加上验收的程度和范围很难定义，这就导致测试很难推进下去，怎么办？没办法，这个节点打不通，真正的DevOps就很难往下落。

面对着人、组织、资源协调等众多问题，我们发现似乎只有持续集成持续发布还能做，为了更快的出成绩，先跑起来再说。所以，DevOps的一种常见反型就是成为了工具链和流水线。

话题二：DevOps团队应该长什么样？

640?wx_fmt=jpeg

上图是一个标准的DevOps团队结构，这张图中6种角色对应的颜色如果结合六顶思考帽的不同颜色代表的含义来思考，也许更有意思：

白色思考帽：白色是中立而客观的，戴上白色思考帽，人们思考的是关注客观的事实和数据；
绿色思考帽：绿色代表茵茵芳草，象征勃勃生机，绿色思考帽寓意创造力和想象力，具有创造性思考、头脑风暴、求异思维等功能；
黄色思考帽：黄色代表价值与肯定，戴上黄色思考帽，人们从正面考虑问题，表达乐观的、满怀希望的、建设性的观点；
黑色思考帽：戴上黑色思考帽，人们可以运用否定、怀疑、质疑的看法，合乎逻辑的进行批判，尽情发表负面的意见，找出逻辑上的错误；
红色思考帽：红色是情感的色彩，戴上红色思考帽，人们可以表现自己的情绪，人们还可以表达直觉、感受、预感等方面的看法。
蓝色思考帽：蓝色思考帽负责控制和调节思维过程，负责控制各种思考帽的使用顺序，规划和管理整个思考过程，并负责做出结论。

这张图中的6个人构成了DevOps团队的标准结构，我们不妨大胆地思考一下：如果老板要裁员，这6个人中，你觉得要先裁掉哪一个？

也就是说，流程主管、服务主管、运维团队、开发团队、DevOps工程师、把关人，要先干掉哪个？

在这个问题上，大家出现了几种观点：

观点一：砍掉运维团队和把关人，通过工具链固化流程，团队一起制定验收标准，将验收标准工具化。
观点二：DevOps其实应该是DevOpsiblity，是所有参与生产经营的人都要具备的能力和思维，从CEO到扫地阿姨都应该有，如果能做到这一点，都不需要组织结构了，大家的角色可以互换。当然，这只是一种乌托邦的美好世界。
观点三：观点二是不可能实现的，但我一直坚信Dev可以搞定一切，Ops不应该存在，或者说，除了Dev之外的角色都是浪费。接下来就是对人的培养的问题，只要组织允许，让一个人做过Dev，也做Ops，那么就会成为既懂运维又懂开发的DevOps人才。
观点四：DevOps是开发+运维，其实并不需要开发和运维团队，服务直接接口把运维给顶替了，或者运维兼职服务的事情，开发帮运维分担一些工作就好了。

关于这个问题，其实并没有直接的结论，DevOps的团队结构并没有统一的标准，一切以解决生产经营问题为核心。

无论是DevOps，精益还是敏捷，都是为了解决生产经营问题，但是有句话说得非常好，管理水平永远不能超越经营现状，从方法去推标准，实际上是为自己开脱，为自己的懒惰找借口。

生产经营的问题是在不断变化的，因为市场在变，技术在变，解决问题的手段在变，我们可以结合现状制定出解决当下问题的标准，自上而下地通过标准让组织更高效，但这个标准并不能是一成不变的，有可能明天就会被推翻。

以丰田为代表的日本车企，把大部分精力放在了精细化管理和持续改进上，到现在用的还是60-70年代的技术。而美国的车企则把太多的精力放在践行MBA的管理理论上，能外包的都外包了，同样失去了创新能力。

这就构成了日本经济社会的现状，也造成了美国的经济现状，我们所学习的这些管理理论是不是真的好，真的适合自己，还是要看是不是能解决具体问题，借鉴可以，照搬不行。

学习和借鉴是一个守、破、离的过程，先固化，再优化，再升华。从实践的角度，以及从企业的角度看，创造价值解决问题才是关键。

冒昧地抛出一个观点：每一套成功的敏捷、DevOps体系，都是具有自己特色的，甚至是唯一的。

总结

消灭分工是技术进步的结果，理想的DevOps团队里只有Dev 做软件。

值得注意的是：Developer（Dev）这个词被大家误解和狭义化了。Developer的原意指的是把东西“做”出来的人，而不是仅仅指编码开发。从这个角度理解，Dev需要从策划到设计，从编码到测试，从部署到运营等所有把东西做出来必须的能力。而且，在技术快速发展前提下，一个人具备所有能力的可能性越来越高，需要通过分工完成一件事情的必须性越来越低，这其实是整个人类技术发展的终极追求。因此除非分工角色中还有无法被技术进步取代的独特价值，不然早晚会替代，最终被个体能力吸纳。这个过程中会有很多类似那个没饭吃的高速公路收银员的人的抱怨，但是无论怎样都阻挡不了技术的发展对个体的赋能，以及对拒绝学习者的抛弃！DevOps仅仅是这个发展过程的一个表象而已，因此我们也可以想象，给DevOps订立一个标准是多么的可笑！

一个真正的DevOps团队，就一定是以Dev为中心的，我们一直在说DevOps要敏捷要敏捷，敏捷是一种让团队协作变得更高效的手段，而最高效的，是一个人的独立思考和执行，也就是所谓的“full stack”全栈。

所以说，全栈开发者是理想化的DevOps。全栈难吗？其实不难，而是大多数组织都被传统管理思路束缚了，总觉得分工才是组织提高效率的唯一办法，管理才是组织高效的核心能力。

其实都错了，提高效率最好的方法就是每个细胞都可以有自主活动的能力，高效的最简单办法就是给每个人的电脑加16G内存。

分工是社会化进步的结果，消灭分工是技术进步的结果。

当工作需要精细化的时候，就不得不进行分工；而当技术进步，对技术细节进行了很好的封装以后，曾经的一部分分工就被融合了。

现在Google/Facebook/微软等公司的测试工程师几乎被取消，并不是说不需要测试了，而是测试的能力已经融入到所有工程师身上。

当然，这并不是说Google/Facebook/微软等公司完全没有测试工程师了，只不过，测试不再追着开发跑，不再是开发的背锅侠，而是更加专注的去做一些探索性测试、测试链路设计、端到端测试等相关工作。

所以，如果DevOps团队需要裁员的话，保留Dev就够了，Dev是最基础，也是最核心的部分，这就像当测试进入了自动化测试时代，技术细节封装好了，剩下的就交给开发做就好了。

当然，DevOps团队里只需要保留Dev这一个角色，是一种理想化的状态，这需要开发人员的自我进化，以及像数据等各种基础条件的完备。想要通过工具和技术完全替代于人，还需要出现革命性的工具或者技术。

如果一个岗位彻底被替代肯定需要大量的实践验证，而且对替代者的要求也更高，但在DevOps这样一组开发+测试的组合中，现在实际情况就是开发来完成一部分测试的工作，比如自动化测试，这样测试人员会越来越少，但是对测试要求也会越来越高，我倒觉得测试和开发之间分工的差别会越来越大。

一个岗位对另一个岗位追杀的结果，就是被追杀岗位逐渐变得更加差异化，做更多让别人无法替代的事情，所谓适者生存嘛。

（以上内容来自“DevOps案例深度研究讨论群”的讨论，感谢各位群成员的分享。如果对文章内容有不同意见和观点欢迎在评论区留言）