在软件交付领域，分角色的精细分工是不利于整体交付效率的，那为什么在DevOps倡导下的全栈工程师、开发运维一体化又会产生新的问题呢？如何解决这些新问题呢？也许，我们需要认真思考，在整个软件交付过程中，什么样的工作需要整合，什么样的工作不应该整合。
在前DevOps时代，分角色分工的思路其实是来源于工业时代的。
做过手工的都知道，如果要手工做100只灯笼，一开始会做得很慢，做了几只后，会越做越快，所谓熟能生巧。
再进一步，把做灯笼的过程拆解一下，比如拆解成搭骨架、糊纸、上色等工序，然后多找几个人来，每人负责其中一道工序，经过几番磨合，由于每个人要做的事情比较单一，很容易上手和熟练，效率将会大大提升。
灯笼的成品和质量也会越来稳定。
把这个过程放大，就是一个工厂的模式。
所有工厂都是通过拆解和精细分工获得极高的效率的，而且，分工越精细，效率越高。
而生产最大的特点是在不断地做重复的事情，产出是同样的产品，而且产品间的差异越小越好，最好趋近于零。
对于重复的事情，就应该通过拆解、精细分工、标准化和自动化来提升效率。
但是软件交付过程则完全不一样，和生产最大的区别就是“不重样”。
每一个软件需求都是不一样的，用户想要的结果也是不一样的，这导致需求分析、开发、测试面对每个需求，或者运维面对每个故障的具体工作是不一样的。
而且软件交付是一个知识工作，是信息流动和转换的过程，而交接会带来信息的衰减和变异，因此在软件交付过程中，按角色分工非但不会带来像生产那样的效率提升，反而会因为信息在不同角色间的交接和传递而产生不必要的摩擦和误解，甚至交付出错误的软件产品。
因此，我们更希望软件交付团队成员可以具备从需求到运维的端到端的交付能力，每个团队针对一个特定的业务领域能够独立完成交付，减少交接，减少对外依赖。
而且这个团队应该足够小（最好不多于7人），以确保团队内目标一致、高效沟通和高度灵活。
然而，对于业务或用户来说，IT系统和服务是一个整体，除了软件，还有硬件。
而每个人的带宽和能力都是有限的，术业有专攻，不可能每个人都是全能的，特别是有些细分领域专业度非常高。
如果把所有的职责都归到业务线交付团队，那么交付团队必然需要拥有具备各类所需技能的专家，从而形成新的庞大实体，除了造成不必要的资源浪费外，组织一旦变大，势必又会变得官僚和低效，原本想避免的问题又会重新出现。
三、解决工作整合问题的关键要找出哪些工作是重复的，哪些是非重复的。
那么问题的症结在哪里呢？通过前面的分析，我们知道，重复的工作，可以通过拆分、精细分工、标准化和自动化来提升效率，非重复的工作，可以通过减少交接和依赖来提升效率。
要解决如何分、如何合的问题，最关键的就是找出哪些工作是重复的，哪些是非重复的。
重复的，解决方案是整合资源、角色分工和自动化；非重复的，解决方案是一体化。
那么在软件交付过程中，哪些工作是重复性的呢？我想到的有以下这些：1、网络、硬件等基础设施这些IT基础设施不会因为不同的项目和需求有太多的差异，而且专业性强，不太适合一人分饰多角，这些角色整合在一个独立团队中，使他们保持专注，也有利于这些专业领域的技术交流和知识传递。
2、部署应该尽量自动化，最低要求也应该标准化，有标准的具体作业流程，谁都可以遵照流程做好。
我们把应用部署过程整理成含具体操作步骤的标准化手册，这样这项工作团队内谁都能做，把他从部署这项具体工作释放出来，在此基础上，让他把这个过程自动化，从而让他学习流水线和自动化部署的技术，接触技术性工作。
他也可以把故障处理流程整理成操作手册，赋能其他团队成员在合规的环境下承担运维工作，把他自己释放出来；3、DBA、操作系统等专家团队应该通过脚本、自助服务等形式赋能交付团队在受控的环境下满足交付需要，减少对他们的依赖。
我们可以收集各交付团队对于DBA的具体需求，把具有共性的需求提炼出来，做成可以通过DBA权限执行的脚本，既满足交付的需求，又确保了DBA权限不会被滥用；4、标准流程所有项目都必须要走的标准流程，如采购等，由专业的团队提供服务的形式来执行，大大降低各项目团队由于需要熟悉繁琐流程的过程所导致的不必要浪费；需求分析、开发、测试、业务支援等非重复性工作则应该保持在一个自满足小团队中，为特定的业务领域提供软件交付和维护服务。
四、总结DevOps的目标是实现持续交付，提升整体的交付效率。
要实现这个目标，简单地把开发、应用维护，甚至IT运维整合在一起，有点过于粗暴。
我们还是应该认真分析哪些具体工作是重复的、可标准化的和哪些是非重复的、不能标准化的来分开处置。
重复的，解决方案是整合资源、角色分工、标准化和自动化；非重复的，解决方案是一体化。
说说DevOps“像” 什么：1. DevOps起源于敏捷方法论，或者我们说的精益原则，目的是为了产品发布更加快捷、频繁和可靠。
2. IT价值流在DevOps的带动下将快速贯穿开发至生产全过程，虽然字面上我们只看到一个“Dev”和一个“Ops”，感觉像是“一带一路”似的，其实包括了从开发到测试，再到发布生产各个环节，下图被经常用到解释DevOps和已有的研发部门角色之间的关系。
（其实还应该包括企业的架构师）“DevOps是在整个IT价值流中实施精益原则的结果。
IT价值流将开发延伸至生产，将由程序员这个遥远的祖宗所繁衍的所有子孙给联合在一起。
”以上是Gene Kim对DevOps的解释，供大家参考。
DevOps Check List这里简单粗暴地列出一些Check List，大家可以对号入座，但不要过分纠结：1. 开发团队，测试团队和运维团队之间应该没有障碍。
三者皆是DevOps统一流程的一部分。
2. 每个团队的输出都是经过自验证的，这样才能保证DevOps的闭环顺利运转。
分享一个DevOps 闭环图：3. 开发、测试和发布环境标准化，可以很容易将之扩展并进行部署。
4. 每个团队之间的通信线路都很明确，保证沟通效率。
5. 所有的团队成员都有时间去为改善系统进行试验和实践。
6. 每次学习到的经验都应该文档化下来并分享给相关人员。
事故处理成为日常工作的一部分，且处理方式是已知的。
运维的 “革命”运维可以说是DevOps这场“IT运动”中受到影响最大的角色，从传统运维到DevOps，就是一场“革命”。
Google的SRE（Site Reliability Engineer），从前一段时间开始，被人们热捧，有的公司马上把自己的运维岗位换名为SRE，确实显得B格高了一点点。
甚至有人把SRE和DevOps划了等号，这样做真让人觉得槽点满满。
我认为SRE其实是运维“革自己命”的产物，客观讲，这样的转型是很高明的，一定是经验积累，加思考，再加探索得出的。
SRE是Google的运维团队从实践中总结出来的一套方法论，将工程研发、日常运维和应急响应等任务较好地结合并落地，当Google的运维团队开始在做SRE的时候，DevOps的概念可能还不为人所知。
所以我们是否应该首先想到是，如何学习Google的运维团队走出适合自己的转型之路，我们的运维团队未来是什么？运维的未来是什么？—一切皆自动化“运维的未来是，让研发人员能够借助工具、自动化和流程，并且让他们能够在运维干预极少的情况下部署和运营服务，从而实现自助服务。
每个角色都应该努力使工作实现自动化。
”——《运维的未来》说到自动化，感觉又是槽点满满，也许有人和我一样都经历过为了自动化而自动化的尴尬，在大公司里，不乏专门做自动化工具的团队，每年出一套工具，“紧跟时代潮流”，然后被迫使用这些自动化工具的团队怨声载道；但是有经验的开发、测试或者运维工程师一定能体会到，“自动化”对于DevOps来说，是刚需。
—工具的合理选择同样对于DevOps来说，工具是必要条件，但工具不是充要条件，如果沉迷于各种工具的堆砌，那么可能跑偏，下面是我们经常会提到的一些工具：代码管理（SCM）：GitHub、GitLab、BitBucket、SubVersion构建工具：Ant、Gradle、maven自动部署：Capistrano、CodeDeploy持续集成（CI）：Travis、Jenkins配置管理：Ansible、Chef、Puppet、SaltStack容器：Docker、LXC、第三方厂商如AWS编排：Kubernetes、Core、Apache Mesos服务注册与发现：Zookeeper、etcd、Consul脚本语言：python、ruby、shell日志管理：ELK、Logentries系统监控：Datadog、Graphite、Ganglia、Nagios性能监控：AppDynamics、New Relic、Splunk压力测试：JMeter、Blaze Meter、loader.io应用服务器：Tomcat、JBoss、IISWeb服务器：Apache、Nginx数据库：MySQL、Oracle、PostgreSQL等关系型数据库；mongoDB、redis等NoSQL数据库项目管理（PM）：Jira、Asana、Taiga、Trello、Basecamp、Pivotal Tracker面对茫茫“工具海”，传统运维团队在日渐式微，而构建工具的团队日益壮大起来，这些工具包括持续集成环境和持续交付等等。
运维能力应该逐渐延伸到构建和维护基础设施服务、配置管理、日志管理、容器管理以及监控等多方面（深以为然）。
我的建议是，不选别人认为对的，只选最适合自己的。
—熟悉业务在实践中我们发现，熟悉业务是团队最难实现，颗粒度最难把握的一部分。
传统运维会有很详细的分工，包括团队之间和团队内部。
有的团队之间会做隔离，举个小例子，“今天上线的内容，我需要你每一步都写得清清楚楚，我只负责执行，不问为什么，出了问题我不负责”，听上去是否耳熟？其实问题不在于要求上线申请写得多清楚，问题是对业务相关“我不负责”。
在传统运维团队内部，一般有专门负责部署上线，跑脚本的同事；有DBA，数据库所有操作就是“我”来；有做监控的同事等等。
当然各个公司情况或许有所不同，但如果你曾经试着说服运维团队去靠近业务层，你碰到的问题应该类似，那就是或多或少的抵触。
DevOps中的运维团队需要对业务负责，这点毫无疑问，我想大家都没有必要再“害羞”了。
事要知其然，且知其所以然。
当然循序渐进的过程是有必要的，所以在GeneDock我们选择了一条自己的运维之路。
GeneDock的运维之路GeneDock的运维团队开始践行DevOps，努力的方向有两个：一是推进自动化落地；二是在原有的“知其然”基础上，要求团队成员“知其所以然”。
自动化的切入点是持续集成和部署，一步一脚印地向DevOps方向前进。
目前主要围绕GitHub和jenkins，构建了线上（公有云）和线下（私有云）混合模式的持续集成和部署框架。
如下图所示。
业务层面，运维团队在开发团队的大力帮助下，从上线后故障排查，以及配置管理问题的复盘开始，不断在实际问题中总结，并形成文档。
同时也通过优化部署流程帮助整个研发团队提高发布效率。
团队间相互促进，形成良性循环。
在很多企业中，应用程序发布是一项涉及多个团队、压力很大、风险很高的活动。
然而在具备DevOps能力的组织中，应用程序发布的风险很低，原因如下 ：（1）减少变更范围与传统的瀑布模式模型相比，采用敏捷或迭代式开发意味着更频繁的发布、每次发布包含的变化更少。
由于部署经常进行，因此每次部署不会对生产系统造成巨大影响，应用程序会以平滑的速率逐渐生长。
（个人体会：我觉得这是敏捷和DevOps最大的优势，对比之前老的开发模式，周期很慢，适用于硬件和传统嵌入式开发，而现在前端技术和中台技术的发展，造就了必须有快速部署、全栈开发的出现）；（2）加强发布协调靠强有力的发布协调人来弥合开发与运营之间的技能鸿沟和沟通鸿沟；采用电子数据表、电子数据表、电话会议和企业门户（wiki、sharepoint）等协作工具来确保所有相关人员理解变更的内容并全力合作。
（个人体会：软件交付，需要每天每时每刻进行沟通，所以不能采用一周一沟通的方式）（3）自动化强大的部署自动化手段确保部署任务的可重复性、减少部署出错的可能性。
与传统开发方法那种大规模的、不频繁的发布（通常以“季度”或“年”为单位）相比，敏捷方法大大提升了发布频率（通常以“天”或“周”为单位）。
（这点，只有大公司有这个能力，我之前的公司维持了一个庞大的团队，专门用于自动化测试，运维…减少后期很多bug和开发时间 ；然而成本也是巨大的，但是比起出bug花费的资源和隐形成本，总之是很值得的）