实战 | DevOps重塑研发运维体系

目前DevOps相关的概念很多，比如DevSecOps、AIOps、SRE、CI、CD等。这么多概念往往让人很困惑，搞不清楚彼此之间的关系。不少人喜欢用图1来解释DevOps、敏捷、CI、CD等之间的关系，不过这可能会造成对DevOps的误解。

我们都知道DevOps要形成闭环，但仅仅关注闭环还是不够的，更别说仅关注研发或者CICD了。作为云原生思想之一，DevOps的核心是围绕应用生命周期过程的管理。在应用生命周期过程中，研发阶段可以采用敏捷研发方式，也可以采用瀑布等其他研发方式；SRE是Google对DevOps的一种很好的实践；CICD是实现DevOps集成部署自动化能力的手段；AIOps侧重于智能化运维而没有考虑研发；DevSecOps侧重于DevOps过程中的安全能力。如果仅仅关注其中一点，我们是难以建设好DevOps能力的。

我们也在尝试构建DevOps体系。“什么是真正的DevOps？DevOps的价值在哪里，DevOps如何能够重塑企业的研发运维体系？如何落地？”。笔者认为，在做任何具体项目落地之前，都需要理解其概念、理念、原则、方法、过程等，需要有一定的认知、有方向，才不会无的放矢。

图1 一种DevOps、敏捷开发、CICD关系示意图

DevOps到底是什么

DevOps到底是什么？我们认为DevOps从来不是一个产品，DevOps落地不是一个系统，而是一个体系。有人说，DevOps是一种思想、方法、理论。这没错，不过我们要把这种思想、方法、理论落地，就需要很多系统、组件的支撑。比如说需求管理系统、应用管理系统、研发平台、测试平台、运维平台、源码管理工具、缺陷管理工具、文档管理工具等。这些系统、平台和工具等及相关的人员共同构成一个DevOps体系。在这个体系中彼此相互联系、相互影响。为更好地达到DevOps体系建设的目标，需对体系中的系统、构成要素、组织结构、信息流动、控制机制等进行系统分析和设计，实现人和信息的持续反馈与协调。

很多人关注更多的是讨论DevOps具体功能实现而不是DevOps思想本质，很多人上来就谈CICD，谈流水线、工具链。但我们是否想过DevOps的本质是什么？DevOps要解决的核心问题是什么？我们知道敏捷研发尝试解决的是研发效率问题，智能运维尝试解决的是运维效率问题。那么DevOps解决的核心问题什么？DevOps的本质是协调开发和运维的关系，说到底，其实解决的核心问题是协作效率问题。不管研发运维一体化，还是持续集成持续交付，核心在于人。无论开发或运维，都有彼此的关切和利益需求，会相互影响。做开发肯定希望需求不要变来变去，尽快交付；做运维肯定希望系统稳定运行不出事。而业务总是在不断变化的，今天提个需求，明天又提个需求，唯一不变的就是变。所以只有解决了人与人之间的关切和利益分配，才能理顺DevOps中的关系，才不会有阻碍和相互负影响，才能提升效率。

DevOps为什么能够重塑研发运维体系？

DevOps是一种思想、方法论。它涉及的东西很多，不是一个产品所能够容纳的。需求收集、需求分析可能会用到需求管理、用户故事地图、服务蓝图等工具；设计可能用到UML、SysML、DFD等模型工具；编码有众多的开发语言和开发框架；测试、监控等工具更是数不胜数。不同的业务场景需求是不一样的，每种技术、工具都有最适合的场景。DevOps的核心并不在工具上，而是寻求开发和运维之间的高效协同。DevOps生命周期过程是个闭环，为什么要闭环？是为了使研发和运维能够高效协同起来，表现为一体化，从而实现研发运维体系质的变化。

DevOps闭环只是一维的流程，难以描述开发人员和运维之间的关系。协调平衡开发和运维之间的关系，才是DevOps关注的重点。传统方式下，开发人员开发测试完毕交付运维部署上线运维，每次的改动必然带来变化和不确定性，这就可能导致异常和故障，从而对运维人员利益带来损害。GoogleSRE使用系统工程的思想和方法替代软件工程系统管理员的手工工作，其终极责任是确保应用服务可以正常运转。为达成这一目标，SRE需要完成开发监控系统、规划资源容量、处理紧急事件、跟踪修复事故根源等。SRE天然排斥重复性、手工性的操作，SRE要求有足够的技术能力快速开发出软件系统以替代手工操作。SRE有50%的时间来做开发，但他们开发的是确保业务应用正常运转的工具、平台等，从而实现应用运维和系统、资源运维的自动化和智能化。SRE不做业务应用的开发，其专注于运维平台和运维工具的研发和运维，在SRE内部实现“研发运维一体化”。使业务研发人员专注于业务应用的研发，不需要考虑运行环境和运行资源，按需使用（云计算思想），这就极大地提升了研发效率。

开发和运维都有自己的诉求。DevOps的核心是要解决企业内部门与部门、团队与团队之间的协作难题，满足彼此的关切和利益需求。DevOps的目的是协调开发和运维的关切，在交付效率和系统稳定性之间寻求平衡，既保障开发又保障运维的利益诉求，追求最优或接近最优的协同状态。

容器云平台是DevOps中提供测试运维运营环境的平台。既要考虑敏捷，又要考虑稳定。测试环境要敏捷，生产环境要稳定，敏态和稳态并行。所以我们以镜像仓库为媒介，支撑着研发和运维不同的利益诉求。研发可以频繁的发布测试，但只有经过完整测试的镜像才能部署生产，确保生产的稳定。同时容器化环境也为稳定的运行和异常回滚提供了技术保障，为研发减少了大量的环境准备时间和环境运维工作量。这就解决了彼此的关切，使研发和运维专注于自己的事情。这就提升了协作效率。

图2 重塑的DevOps研发运维体系

DevOps怎么重塑研发运维体系？

要重塑研发运维体系，需要用系统工程的思想。首先，将基础设施资源运维、PaaS平台（或应用部署运行平台）运维和业务应用运维分离。可以通过多云管理平台来管理各种不同的基础设施资源（私有云、公有云、行业云等），向PaaS平台提供经过抽象和封装的规范化、标准化资源服务。而PaaS平台（或应用部署运行平台）以应用管理为核心支撑业务应用的部署、运行、运维和运营等。PaaS平台（或应用部署运行平台）为Dev开发提供应用的敏捷测试、部署、运行环境，Dev开发无需关注环境运维和资源运维，按需申请和使用资源及相应的工具、组件。SRE模型成功的关键在于对工程的关注，如果没有持续的、工程化的解决方案，运维的压力就会不断增加，也就需要更多的人来完成工作。用系统工程分层思想，通过标准化服务来支撑上一层平台或系统，松耦合了彼此之间的关系，职责分工相对明确，而工程化的方法也使运维人员通过自动化、智能化的工具和手段提升了运维效率和运维能力。所以Ops的终极目标也需要像SRE一样推动整个系统趋向于无人化运行，也就是智能化，不仅仅是自动化。

第二，DevOps生命周期是以业务应用为中心的。Dev交付的是业务应用，Ops确保稳定运行的是业务应用。这里的应用可以是微服务应用，当然也可以是其他类型的应用，只要能契合DevOps的理念就可以。DevOps寻求是Dev交付效率和Ops稳定运行之间平衡，并不是说一天发布10次8次就是DevOps了。每天发布多少次其实没有多大意义，关键在于业务场景的需求。在需要发布的时候能够支撑按需发布，具备这样的能力就可以了。如果把每天的发布次数作为一项考核指标，那就有点舍本逐末了。

SRE关注站点或产品、应用服务等运行的稳定性，以“错误预算”协调开发和运维之间的利益关系，错误预算是根据经验拍脑袋定的，有其局限性。SRE其实更多地关注Ops端，但关注“运维Ops”无疑是正确的，和我们习惯于更关注“开发Dev”是不一样的。SRE强调用工程化的手段应对运维问题。软件运维问题达到一定规模时，也确实只能通过软件工程化的手段来解决。

企业中研发Dev和运维Ops之间最主要的矛盾就是应用服务迭代创新的速度与应用服务稳定运行程度之间的矛盾。要解决Dev和Ops双方的利益冲突，则需要同时能关注矛盾双方的诉求、保障矛盾双方的利益。既要保证“速度”，更要关注“稳定性”。但任何软件系统都不应该一味追求100%可靠。对最终用户来说，99.99%、99.999%和100%的可用性并没有实质的区别。因此DevOps建设就是追求这种矛盾的统一。DevOps的关键在于利益平衡问题，这不是技术问题，而是社会学问题。

第三，DevOps由于涉及内容众多，在人员和团队之间的协同、角色和权限管理、访问控制等方面需要在不同的平台、工具、系统之间打通。这是基础的能力，但也是重塑研发运维体系的关键能力。不同的角色根据访问控制权限可以访问不同的资源API、服务API等，从而实现了DevOps体系统一的安全管控能力。

要实现这一点其实就面临着很多的问题。认证权限和访问控制是企业各种信息系统最基础的组成部分，每个系统都需要都会有。由于不同的系统由不同的厂商研发，也就造成了认证权限访问控制等管理体系各不相同。在实现系统集成的时候就面临着额外很多的工作量和麻烦。基于这点，在DevOps体系建设中结合技术中台架构的思路，我们提出构建企业统一身份认证服务中台和权限服务中台。可以采用微服务架构，重构身份认证和权限管理体系，以企业级标准化服务的形式，实现认证和授权、访问控制的企业级复用。

图3 企业级统一身份认证、权限中台

DevOps落地意味着很多基础的工具和平台的服务化、标准化、自动化甚至智能化。基于容器的PaaS平台提供敏捷的部署、运维、托管、弹性伸缩等能力，这也是我们为什么优先建设容器云平台的原因，优先解决Ops的需求，提供敏态和稳态的支撑能力，才能更好地支撑应用的生命周期管理。以微服务架构实现企业级的共享和复用以减少重复建设、节约成本、提升效率等，以复用服务逐步构建企业中台体系，进一步支撑业务的敏捷变化需求。认证、权限、日志等可复用服务的建设也促进了系统的融合，有利于DevOps的落地。容器化PaaS、微服务、中台、DevOps等相辅相成，重塑了企业的研发和运维架构体系。

DevOps提出的目的在于解决开发和运维之间的利益冲突问题，要落地DevOps，就需要重塑开发和运维的架构体系，不是简单的用CICD或者一个DevOps产品能够解决的。简单的说，原来那些习惯于系统运维而不具备研发工具的人员，完全可以让他们继续去运维基础设施资源，和上层业务应用运维分离，这样即便在传统企业也不会影响到DevOps的建设。我们建议用系统工程思想立体思维或多元思维构建DevOps体系，协调好开发、运维及相关利益者关系，以系统融合的思路架构，分步构建和完善DevOps体系，这样才能重塑研发和运维体系，使开发和运维高效协同，带来质的变化。