把运维和开发放一起就是DevOps？还差得远！

作者介绍

刘华(Kenneth)，就职于世界500强银行。负责基金外包业务软件开发与交付。敏捷、精益、DevOps领域专家。著有《猎豹行动——硝烟中的敏捷转型之旅》一书。

DevOps倡导“谁开发，谁运维”和开发运维一体化，那么是不是简单地把开发和运维人员放在一起就完事了呢?

一、DevOps转型中的“插队”故事

1、运维专员小明的故事

小明入职时是运维专员，原来隶属于运维部门，负责某业务线系统的应用维护工作。

一旦系统的生产环境出现任何故障，或者业务人员在生产环境上有任何请求，都是由小明所在的运维部门先处理，处理不了的，再联系该系统的开发团队一起处理。

由于生产环境关乎业务部门的业绩，每天收到的请求量也非常多，小明的压力很大，而且并不是每个故障或请求他都有能力或来得及处理;找开发团队，又会被开发团队说他只是把事情“左手交右手”，没有提供价值，小明很委屈也很为难。

他并没有参与系统的开发，而系统上线后的问题却需要他来应对，干着最苦最累的“背锅侠”的活，却没有什么掌声和成就感。

两年前，公司开始进行DevOps转型，把运维部门撤销了，小明“插队”到了业务线系统的原开发团队中。

公司希望借此让业务线的交付团队负责从开发到运维的整个链条，也让像小明这样的运维人员有机会参与到项目工作中，提升他们的技能和工作满意度。原来的开发人员也要参与运维，在开发中更多地考虑到生产环境运行的问题。

有重大问题时，整个团队都可以参与运维、解决问题。

但几个月后，小明发现他的具体工作并没有什么变化，生产环境的一切事务依然还是先派给他，由于这项工作已经占据了他所有的工作时间，他没有机会参与项目交付。

他感觉自己和团队里的开发人员是“同床异梦”，也没有机会拓展自己的能力。

2、DBA小崔的故事

小崔是持证DBA。原来隶属于独立的IT运维部门，该部门掌管着一切IT基础设施，如服务器、操作系统、数据库、中间件、网络以及相应的专家团队。

由于重要的权限都掌握在这些专家团队手上，业务线交付团队如果无法获得IT运维部门的支持，项目就进展不下去。当各业务线的项目需求越来越多时，IT运维部门就成了整个公司的瓶颈。

为了解决这个问题，公司开始将IT运维部门去中心化，部分领域专家“插队”到各业务线交付团队中，从而减少交付团队的对外依赖，实现“自给自足”。

小崔就是这波浪潮中的其中一员。被收编到交付部门后，他比过去更忙了。

由于DBA是比较专业的技能，多大的团队需要一个全职DBA成了一个问题。团队太小，拥有一个DBA响应力绝对没有问题，但是无法充分利用其时间;如果几个团队共享一个DBA，又会出现新的瓶颈问题。

小崔就是一个被几个交付团队“共享”的DBA，因为要疲于应付各交付团队的请求，他已经没有时间成长。

过去，由于DBA都集中在一起，他们之间可以频繁交流，相互学习，共同成长。而小崔现在收获到的只有孤独和压力。

3、DBA大鹏的故事

同样以DBA身份入职的大鹏则面对另一个情景。

由于他是新招的，直接进入了交付团队，但该团队的DBA工作不饱和，他被安排做了很多与DBA不相关的项目工作。

半年后，他辞职了，因为他感觉再这样下去，他的DBA武功就要废了。

如果你的公司也在做DevOps转型，以上故事是否也在你身边发生呢?虽然说分分合合是组织转型的常态，但是处理不好，代价是相当沉重的。

二、思考DevOps时代下工作整合问题

什么样的工作需要整合，什么样的工作不应该整合?

既然我们已经通过多年的经验证明了在软件交付领域，分角色的精细分工是不利于整体交付效率的，那为什么在DevOps倡导下的全栈工程师、开发运维一体化又会产生新的问题呢?如何解决这些新问题呢?

也许，我们需要认真思考，在整个软件交付过程中，什么样的工作需要整合，什么样的工作不应该整合。

在前DevOps时代，分角色分工的思路其实是来源于工业时代的。做过手工的都知道，如果要手工做100只灯笼，一开始会做得很慢，做了几只后，会越做越快，所谓熟能生巧。

再进一步，把做灯笼的过程拆解一下，比如拆解成搭骨架、糊纸、上色等工序，然后多找几个人来，每人负责其中一道工序，经过几番磨合，由于每个人要做的事情比较单一，很容易上手和熟练，效率将会大大提升。灯笼的成品和质量也会越来稳定。

把这个过程放大，就是一个工厂的模式。

所有工厂都是通过拆解和精细分工获得极高的效率的，而且，分工越精细，效率越高。而生产最大的特点是在不断地做重复的事情，产出是同样的产品，而且产品间的差异越小越好，最好趋近于零。对于重复的事情，就应该通过拆解、精细分工、标准化和自动化来提升效率。

但是软件交付过程则完全不一样，和生产最大的区别就是“不重样”。

每一个软件需求都是不一样的，用户想要的结果也是不一样的，这导致需求分析、开发、测试面对每个需求，或者运维面对每个故障的具体工作是不一样的。

而且软件交付是一个知识工作，是信息流动和转换的过程，而交接会带来信息的衰减和变异，因此在软件交付过程中，按角色分工非但不会带来像生产那样的效率提升，反而会因为信息在不同角色间的交接和传递而产生不必要的摩擦和误解，甚至交付出错误的软件产品。

因此，我们更希望软件交付团队成员可以具备从需求到运维的端到端的交付能力，每个团队针对一个特定的业务领域能够独立完成交付，减少交接，减少对外依赖。

而且这个团队应该足够小(最好不多于7人)，以确保团队内目标一致、高效沟通和高度灵活。

然而，对于业务或用户来说，IT系统和服务是一个整体，除了软件，还有硬件。而每个人的带宽和能力都是有限的，术业有专攻，不可能每个人都是全能的，特别是有些细分领域专业度非常高。

如果把所有的职责都归到业务线交付团队，那么交付团队必然需要拥有具备各类所需技能的专家，从而形成新的庞大实体，除了造成不必要的资源浪费外，组织一旦变大，势必又会变得官僚和低效，原本想避免的问题又会重新出现。

三、解决工作整合问题的关键

要找出哪些工作是重复的，哪些是非重复的。

那么问题的症结在哪里呢?通过前面的分析，我们知道，重复的工作，可以通过拆分、精细分工、标准化和自动化来提升效率，非重复的工作，可以通过减少交接和依赖来提升效率。

要解决如何分、如何合的问题，最关键的就是找出哪些工作是重复的，哪些是非重复的。重复的，解决方案是整合资源、角色分工和自动化;非重复的，解决方案是一体化。

那么在软件交付过程中，哪些工作是重复性的呢?我想到的有以下这些：

1、网络、硬件等基础设施

这些IT基础设施不会因为不同的项目和需求有太多的差异，而且专业性强，不太适合一人分饰多角，这些角色整合在一个独立团队中，使他们保持专注，也有利于这些专业领域的技术交流和知识传递。

2、部署

应该尽量自动化，最低要求也应该标准化，有标准的具体作业流程，谁都可以遵照流程做好。

我们可以安排前文中的小明把应用部署过程整理成含具体操作步骤的标准化手册，这样这项工作团队内谁都能做，把他从部署这项具体工作释放出来，在此基础上，让他把这个过程自动化，从而让他学习流水线和自动化部署的技术，接触技术性工作。

他也可以把故障处理流程整理成操作手册，赋能其他团队成员在合规的环境下承担运维工作，把他自己释放出来;

3、DBA、操作系统等专家团队

应该通过脚本、自助服务等形式赋能交付团队在受控的环境下满足交付需要，减少对他们的依赖。

我们可以让前文中的小崔和大鹏收集各交付团队对于DBA的具体需求，把具有共性的需求提炼出来，做成可以通过DBA权限执行的脚本，既满足交付的需求，又确保了DBA权限不会被滥用;

4、标准流程

所有项目都必须要走的标准流程，如采购等，由专业的团队提供服务的形式来执行，大大降低各项目团队由于需要熟悉繁琐流程的过程所导致的不必要浪费;

需求分析、开发、测试、业务支援等非重复性工作则应该保持在一个自满足小团队中，为特定的业务领域提供软件交付和维护服务。

四、总结

分分合合是组织转型的常态。

DevOps的目标是实现持续交付，提升整体的交付效率。要实现这个目标，简单地把开发、应用维护，甚至IT运维整合在一起，有点过于粗暴。

我们还是应该认真分析哪些具体工作是重复的、可标准化的和哪些是非重复的、不能标准化的来分开处置。重复的，解决方案是整合资源、角色分工、标准化和自动化;非重复的，解决方案是一体化。