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转型，上面的故事是否发生在你身上？虽然分离与整合是组织转型的常态，但如果处理不当，代价是相当沉重的。2.思考DevOps时代的工作整合。什么样的工作需要整合，什么样的工作不应该整合？既然我们通过多年在软件交付领域的经验证明，按角色细化分工不利于整体交付效率，那为什么还要提倡全栈工程师和开发运维一体化呢？DevOps制造新问题？如何解决这些新问题？或许，我们需要认真思考一下，在整个软件交付过程中，哪些工作需要集成，哪些工作不应该集成。在前DevOps时代，分工分工的思想其实起源于工业时代。做过手工的都知道，如果要手工做100个灯笼，刚开始做的时候会很慢，做几个之后就会越来越快。所谓熟能生巧。更进一步，把制作灯笼的工序拆解，比如搭骨架、贴纸、上色等工序，然后再找几个人，每人负责其中一道工序。要做的事情比较简单，好用又熟练，效率会大大提高。灯笼的成品和质量也会越来越稳定。扩大这个过程就是工厂模式。所有的工厂都是通过拆解和分工来达到极高的效率，而且分工越细效率越高。生产的特点就是不断地做重复的事情，输出的是同一种产品，产品之间的差异越小越好。对于重复性的东西，要通过拆解、细化分工、标准化、自动化来提高效率。但软件交付过程完全不同，与生产的区别是“不重复”。每个软件需求不同，用户想要的结果也不同，这就导致每个需求的需求分析、开发和测试的具体任务不同，或者运维中的每个故障。而且，软件交付是一项知识工作，是一个信息流动和转换的过程，交接会带来信息的衰减和变异。因此，在软件交付过程中，按角色分工并不会带来与生产一样的效率。不同角色之间的信息交接和传递会产生不必要的摩擦和误解，甚至会交付错误的软件产品。因此，我们希望软件交付团队的成员能够具备从需求到运维端到端的交付能力。每个团队可以独立完成特定业务领域的交付，减少交接和对外依赖。并且这个团队要足够小（建议不超过7人），以保证团队内部目标一致、高效沟通和高度灵活性。但是，对于企业或者用户来说，IT系统和服务是一个整体，除了软件，还有硬件。但是，每个人的带宽和能力都是有限的，技术有专攻。不可能每个人都无所不能，尤其是在一些专业度很高的细分领域。如果把所有的责任都交给业务线的交付团队，那么交付团队就必须有具备各种所需技能的专家，从而形成一个新的庞大实体。除了造成不必要的资源浪费外，一旦组织规模变大，势必又会变得官僚化和低效化，原本想避免的问题又会重现。3、解决工作整合问题的关键是找出哪些工作是重复的，哪些是非重复的。那么问题的症结在哪里呢？通过前面的分析，我们知道重复性工作可以通过拆分、细化分工、标准化和自动化来提高效率，非重复性工作可以通过减少交接和依赖来提高效率。要解决如何分与合的问题，关键是要弄清哪些任务是重复的，哪些是不重复的。对于重复，解决方案是整合资源、角色划分和自动化；对于不重复，解决方案是集成。那么在软件交付过程中，哪些工作是重复性的呢？我想到了以下几点：1.网络、硬件等基础设施。这些IT基础设施不会因为项目和需求的不同而有太大差异，而且专业性强，不适合一个人身兼多职。这些角色整合在一个独立的团队中，可以让他们保持专注，也有利于这些专业领域的技术交流和知识转移。2、部署要尽可能自动化，至少要求要标准化，有标准的具体操作流程，任何人都可以按照来做好。我们可以安排上一篇文章中的小张，将应用部署的流程整理成一个标准化的手册，有具体的操作步骤，让工作组的任何人都可以做到，把他从部署的具体工作中解放出来。在此基础上，让他将这个流程自动化，让他学习流水线和自动化部署的技术，接触技术工作。他还可以将故障处理流程整理成操作手册，赋能其他团队成员在合规环境下承担运维工作，释放自己；3、DBA、操作系统等专家团队应该使用脚本、自助服务等形式赋能交付团队，在可控环境下满足交付需求，减少对他们的依赖。我们可以让上一篇文章中的小翠和大鹏去收集各个交付团队对DBA的具体需求，将共通的需求提炼出来，做成DBA权限可以执行的脚本，既满足交付需求，又保证DBA权限不会被滥用；4.标准流程采购等所有项目必经的标准流程由专业团队执行提供服务，大大减少了每个项目团队需要熟悉繁琐流程带来的不便。必要的浪费；将需求分析、开发、测试、业务支持等非重复性工作放在一个自给自足的小团队中，为特定业务领域提供软件交付和维护服务。4.小结分离与结合是组织转型的常态。DevOps的目标是实现持续交付，提高整体交付效率。要实现这个目标，简单地将开发、应用维护，甚至IT运维集成在一起，未免有些过于粗糙。具体哪些工作是重复的、可以标准化的，哪些是非重复的、不能标准化的，还是要仔细分析，分别处理。对于重复，解决方案是整合资源、角色划分、标准化和自动化；对于不重复，解决方案是集成。作者介绍了供职于世界500强银行的刘华（Kenneth）。负责基金外包业务的软件开发和交付。敏捷、精益、DevOps领域专家。《猎豹行动——硝烟中的敏捷转型之旅》一书的作者。
