我们一直说DevOps是“谁开发谁运维、开发运维一体化”，但具体怎么做并没有几个人说的清楚的。特别是“谁开发谁运维”，这明显是不符合实际情况的。试想一下，一个开发人员开发的应用服务都由他自己来运维，他能运维几个应用服务？然后又有多少时间能继续做开发？到最后岂不是所有开发人员都成了运维人员。有点极端，但是也正说明了我们对DevOps的认识存在很大的误解。
DevOps提倡“开发运维一体化”，但不是“谁开发谁运维”。但怎么开发运维一体化往往也都没有说清楚，也没有很好的实践案例。Google SRE更多的其实是运维阶段的工作，虽然Google SRE很多工作是运维工具和运维服务的开发工作，但其本质上是做运维。但是它给我们的一个很好的启示是，把“运维开发”和“运维维护”一体化了，也就是运维人员不再是简单的系统管理和维护，而是通过运维工具的研发，使运维流程自动化和智能化，将一些日常重复性的运维工作通过自研工具自动化和智能化了，这就大大减轻了运维人员的维护工作量，提升了运维效率。这些工作不再靠“研发人员”，而是“运维自身”的能力来实现的。
DevOps开发运维一体化并不是让开发去做运维，而是使开发和运维通过一些机制有机结合、高效统一，成为一个整体，从而消除开发团队和运维团队之间的gap，有效提升应用服务的研发和运维运营效率。
那么通过什么样的机制，如何来消除开发和运维之间的利益冲突，如何提升效率是我们在实施DevOps之前或者实施过程中需要认真思考的问题。
Google SRE实践给我们了很好的运维阶段的DevOps实施启示。运维还是需要专职做运维，而且比传统运维做的更多。运维人员需要对自己运维的环境、工具、流程、资源等有深入的理解和认识，能独立开发运维工具，独立实现运维的自动化、智能化、高可用、稳定性、安全性等要求。支撑应用的运维和运营。这就使运维成为了一个有机的小闭环，包括了运维工具、流程等的需求、设计、开发、测试、部署、运营、反馈、改进等完整生命周期过程。这和业务应用的开发和运维运营是不同层次的。SRE的工作在提升运维效率的同时也很好的支撑了业务应用的运维运营效率。
SRE侧重于DevOps的Ops运维阶段。DevOps的Dev开发阶段包括需求、设计、编码、测试、部署等过程。开发阶段则强调持续开发、持续部署或持续开发、持续交付，强调敏捷开发。目的还在于提高效率。环境的敏捷准备、环境的一致性是Dev阶段高效的重要基础。
传统开发、测试、UAT等环境都是由开发人员自己来维护。这也导致了往往和生产环境不一致，所以在生产部署时可能会存在很多意向不到的问题。因此在DevOps实践中，环境的运维一定要交由运维人员统一来维护，开发人员只是使用环境而不运维环境。
谁有权限使用环境谁没有权限使用环境这又涉及到了DevOps中的统一权限管理和统一认证管理部分。统一权限和认证管理可以作为企业的技术中台服务由技术中台运维团队来统一运维运营。为企业内外用户提供认证和权限服务。各个环境使用技术中台的统一认证权限平台的服务来完成认证和权限管控，也避免了重复的投入和建设。开发人员只需要用自己的账号随时登录不同的环境来完成自己的工作。这其实就是PaaS的理念。当然，你也可以在企业内部实现单点登录，一次登录，可以在拥有权限的不同环境之间切换来完成工作。这些是DevOps的基础工作。看似没有关系，却带来完全不同的效果。
环境一致性可以简单的通过容器化来实现。但容器环境只能达到相对一致性，并不能实现完全一致性。容器运行在不同配置的宿主机或虚拟化节点上，都会带来一定的差异。所以你也可能经常会遇到在某个节点性能很高，而某个时刻迁移到另外一个节点性能却不如预期。
环境的敏捷准备则是一个相对不容易的工作。传统研发过程中通常很多时间都是花在环境准备上。不管是否采用容器化，这块的效率都是需要考虑提升的。在开发阶段涉及的流程和工作也比较多。比如开发环境准备、测试环境的准备、测试数据的准备、测试用例的自动构建、测试缺陷的自动记录等。而且这部分工作可以通过相应的工具实现敏捷能力，尽可能使工具和流程标准化，这样就可以实现自动化，就能更快的提升效率。
而软件编码的标准化程度也相对就比较低，往往依赖于开发人员的个人能力和态度。软件研发其实质是智力投资，不同的人带来的效果完全是不一样的。所以很多想以外包的方式实现自有软件的自主可控基本上是不现实的。
开发阶段最终需要交付标准化交付件，不管是容器镜像、或是jar、war、exe文件等，这些文件需要统一管理起来，镜像可以用镜像仓库，jar等可以通过配置管理工具等统一来管理，而部署则可以实现自动化，不管使用自动化脚本或者自动化工具，以减少部署问题和提升效率，支持持续部署的能力。
我们在《容器云平台运维架构设计》也清楚地解释了开发和运维之间的标准化交付环节。这是减少开发和运维之间沟通成本和提升效率的重要机制。如果使用容器，镜像和镜像仓库将充当这样的一个标准化交付件和标准化交付管理媒介。它可以很好的划分和有效连接开发、测试、UAT、生产运维等应用生命周期阶段。
另外我们知道DevOps很重要的是要形成闭环。运维运营对开发的反馈是非常重要的，不仅仅是bug和缺陷的反馈修复，包括用户体验等都是很重要的内容。这就需要合理合适的反馈机制和流程。既包括技术的，也包括非技术的因素。
所以横向上我们可以简单的看作是开发、标准化交付和运维的划分，标准化交付就像是人的关节，起到润滑和弹性伸张的作用，使开发和运维成为一体并充分发挥各自的专业优势。而纵向上，可以通过分层来实现高度专业化运维。最下层是基础设施资源的运维，之上是平台、工具、环境的运维，在这些平台、工具、环境之上是业务应用的运维。所有这些工作都是为了保证业务运营的可用与安全。通过业务运营才能有收益、有利润。
从应用整个生命周期管理过程看，80%的基本工作可能是在运维阶段，运维的事项也比较多，从效率上讲，使各运维事项专业化、自动化甚至智能化则容易提升效率。开发运维一体化重点在于提升运维的效率，包括应用、环境、平台、工具、基础设施资源等。有高效、高可用的运维环节能力，则能保证业务应用的高可用与稳定性，也就是Google SRE的Site Reliabilities。而对于应用开发人员，即便是出现意外情况，运维也有应对措施，开发人员则有充足的时间进行细致的设计和问题处理，追求更稳定、可靠、高效的能力，从而使运维更容易和便利。
开发运维一体化追求开发和运维的利益一致，而不是一个人既做开发也做运维。这需要通过一定的机制和借助相应的工具等来保证，使开发和运维之间能够有活动关节、有润滑剂。这应该是我们在构建DevOps的时候需要认真考虑实现的核心内容。
