建设高效的DevOps平台：跨组织协作而不是互怼_DevOps_蒋刚毅

ArchSummit全球架构师峰会门票9折倒计时中~ 了解详情 



 写点什么

DevOps 对传统职能部门的挑战

对于传统技术组织架构，团队通常是按照技能划分，除了业务开发部门，通常还会有测试部、运维部、安全部，项目管理部等技术支撑部门，大家按照职责各行其是搭建各自的工具平台，并通过项目的方式协作，完成系统的交付。这样相互隔离的各部门沟通效率比较低，出了问题大家总是互怼。

DevOps 文化提倡打破原有职能组织的限制，每个职能团队都开始拥抱和接受 DevOps 高度协同，研发和交付一体化的思维，同时也看到各个团队都正面临着转型、痛苦和挑战。

运维团队

大概 10 年前我的一个老大曾经问我一个问题：如果一个公司快倒闭了，最后一个失业的岗位会是谁？他给的答案是运维，因为一个公司只要存在一天就需要有运维去确保机器运行正常。

这个答案看似正确，然而在公有云的大潮下，一切都被冲击的支离破碎，传统运维工程师的需求大量减少开始面临着岗位危机，运维开发团队开发的传统的资产管理、运维监控等系统在公有云上都已经有成熟的产品。流程导向的 ITIL 运维管理体系已经过时，优秀的运维开发工程师开始转向技术导向的 DevOps 平台建设，研究和开发 docker 容器、自动化运维、智能运维等技术，顺利的完成了自身技能和职能的转变。可能的问题是由于长期工作在交付末端，很多人会面临着对软件研发工程理解不足的问题。

测试团队

测试工作贴近业务，业务千差万别，测试自动化相比运维自动化难度自然要大很多，再加上高技能测试开发人员的匮乏，大多数公司的自动化测试并没有发挥太大的效力，国内手工业务测试人员岗位似乎也并没有减少的趋势。

但在一些国内外的大公司，业务测试人员其实一直是在收缩，大量的测试工作转交给了开发工程师执行，有理想的测试开发工程们都开始融入到 DevOps、CI/CD 的大潮中，测试人员对研发过程的痛点理解是最透彻的，而测试自动化在 DevOps 里也是非常关键的环节，这里仍保留了大量需要研究探索并使其流水线化的领域，所以会是一个良好的转型方向，当然前提是需要具备较好的开发能力。测试团队过于庞大后，如果缺少核心的竞争力，往往就会被拆散到各个业务线与业务线深度结合，潜台词就是不太会有大质量团队了，测试总监的岗位或许也不复存在。

安全团队

这几年的新起之秀，得益于国家监管部门对网络安全的关注以及《网络安全法》的实施，互联网时代数据安全的重要性开始超越业务质量和稳定性，各个公司都能看到正在组建独立的信息安全团队，里面的职责也不再仅限于安全漏洞的测试挖掘，还包括安全合规，安全风控，安全攻防，安全审计，安全管理等等，贯穿研发业务管理各个环节，正在形成一个独立稳定的基础设施团队。

信息安全团队风光的背后，我们经常也会听到以前在传统测试团队经常听到的质疑，“安全渗透测试主要都依靠手动挖掘，如何提升安全团队的测试效能？”、“安全漏洞问题，都是安全团队的责任吗，直接负责编码的工程师没有责任？”，他们通常与 DevOps 团队脱节，安全从业者也一直在反思并尝试将自动化的安全检测，自动化的安全代码检查融入到 DevOps 的体系中，所谓 DevSecOps。

项目管理团队

敏捷文化对 PM 这样一个最注重流程的角色来说，是一个不小的冲击，随着组织的垂直化，以前严格的工作流被迅速弱化，传统的瀑布式工作流程显得臃肿繁赘，除了一些传统软件厂商，现在已经没有多少互联网企业会去做 CMMI 这样的认证了，取而代之的是轻量级的敏捷工作流程，在大团队协同时 PM 依然会发挥不小的作用，很多优秀的 PM 也开始转型向敏捷教练的角色，输出有效的项目管理文化和方式给各个业务团队。

业务开发团队

产品开发测试等角色混合组建成一个完整的业务团队闭环正成为趋势。职能的独立性和业务的连续性需要保持一个微妙的平衡，在职能部门还没有足够大时，从业务交付角度以业务为导向组建跨职能项目团队，从人员技能培养角度以职能为导向组建技术职能团队也许是个不错的选择。闭环业务团队能够高效运行的前提，是这个企业需要有完善的研发工具和研发协作平台，不然光是人坐在一起提升的可能也就是业务团队内部的沟通效率，然后又是各个业务团队各做一套，各业务团队间的协作会成为很大的问题。

多功能跨职能的 DevOps 平台团队

在技术层面由谁来主导和推动 DevOps 平台的组建，在组织或者团队层面，如何传递 DevOps 文化的价值并让团队理解 DevOps 文化的价值，不同的公司能看到有不同的做法，比如有运维开发团队驱动，有测试开发团队驱动，有基础架构团队驱动等等，这种单一功能团队推动的形式往往会面临孤岛化和片面化的问题，重视自身的领域但对其他团队的痛点关注较少。

单一自下而上的 DevOps 团队虽然可以在个别领域解决效能问题，但对整个技术组织的影响还是比较有限。相比之下如果有一种自上而下的方式让开发团队基于已有业务基础之上去优化交付流程，并对每一个提交的最终价值负责，将产品思维真正植入到开发团队，从而达到全局优化的效果，这种做法才更符合真正的 DevOps 精神。

近期我们在技术组织上做了大胆的改变，除了各个闭环的业务开发团队以外，同时组建了技术中台部门（包括通用架构平台、大数据平台和技术支撑平台等）。其中技术支撑平台包括原有质量架构、运维平台、信息安全、项目管理这些技术职能的整体技术规划和管理，并正式组建研发效能部 (包括原有测试开发、运维开发、敏捷教练等多个角色，同时补充了部分专职开发工程师)，为整个技术团队提供 DevOps 整体解决方案，提供一站式需求 --> 开发 --> 测试 --> 运维（运营）全通道的研发协作平台。组织上也从原有的职能组织结构，正式转换成业务线 + 技术中台的组织结构。

类似的组织结构并不新鲜，在 BATJ 等大厂也早已经有成功的先例，最典型的就是阿里“大中台 + 小前台”的技术组织结构，中台部门负责基础设施建设，业务部门利用这些成熟的基础组件快速搭建业务应用，其中比较特殊的是研发效能和信息安全两个组织，纵向贯穿所有技术团队，为整个技术团队提供效能和安全的赋能，而研发效能团队主要是由原有的运维开发，测试开发，敏捷教练以及部分专职开发人员组成，为阿里几万名技术工程师整体研发效能解决方案。

虽然这种组织形式仍存在不少争议，实践中也有些过于理想化的地方，但总体来说从技术角度窃以为是更优于烟囱式团队结构，完全分立赛马的组织方式。

跨组织 DevOps 平台建设实践

以应用为中心

任何一个成熟的公司，根据职能不同，内部都有很多的研发平台，研发端有代码管理平台，代码检查平台，codeReview 平台，配置管理中心等，测试端有接口测试平台，UI 自动化测试平台、测试数据中心、Mock 中心等，运维运营端有资产管理平台、发布作业平台以及各种监控平台，安全上也会有安全资产管理、安全情报感知，业务安全风控、网络安全监控等等平台。

在过往的职能结构里，往往各个职能部门会各自建设这些系统，研发说系统，PM 说项目，运维说机器，安全说威胁信息等等，各个职能部门缺少一个共性的东西把这些系统打通是部门之间信息沟通不畅的重要原因。

所以 建立公司级别的标准应用库，这点非常重要，是整个研发协同活动的基石。建立了统一的应用管理平台后（应用基础信息一般包括应用的语言，jdk 版本，编译工具和版本号，代码地址，应用负责人，部署中间件等），后面的代码、资产、环境、流水线、监控、配置、质效等等的管理就都可以围绕着应用维度来展开。

应用有了标准库，也就有了生命，有了生命周期的管理，应用不再只是一个干瘪的代号或标识，而是一个活动集合一个工作系列。比如停用应用的操作就可自动化驱动代码库冻结，流水线 job 回收，研发环境回收，线上资源回收，应用监控关闭等一系列操作，大大减少了人工操作的复杂度和错误率。

再举例来说，以前运维团队建设 CMDB 资源管理平台，传统思维上总是习惯于以物理资产为中心去建设，聚焦在物理资产的管理，比如各台机器什么配置，什么品牌，资产编号，资产价格，资产型号，资产位置甚至资产照片等等。

自建机房的时候物理资产的管理还是存在一定的价值，但在云时代这些信息基本已经失去了意义，容器云时代已经完全不用关心容器的物理载体。

对研发过程来说，仅仅聚焦在静态的物理资源管理是没有意义的，需要建立一个逆向思维，不要从资源的角度维护资源，而是从应用的角度来维护资源。主机是什么？是应用的一个资源；Docker 是什么？可以看成应用的附属资源；分布式 Redis 服务是什么？是应用的附加资源等等。

基于此考虑我们以应用为中心重建了 CMDB 系统。在申请资源的时候，研发团队以应用为主体申请需要的资源，在研发环境可以一键申请生成，在正式环境则在运维团队审批后自动分配，并在 CMDB 中记录了每个应用对应的资源信息，应用停用后，这些占用资源很简单的就可以实现自动的回收和释放。通过建立业务维度的资产管理体系，CMDB 才开始真正发挥出它应有的价值。

容器化的资源管理

开发，测试，预发，发布，稍微上规模的互联网技术团队，上线前都会经历这几个阶段，每个阶段分别对应一套环境。所以我们至少会面对开发环境、测试环境、预发布环境、正式环境，在没有使用容器之前各套环境配置、软件包、资源类型等等难以保持一致。

产品线若干条，数百个应用，每个应用并发 N 个分支，有 Java、NodeJS、PHP、C++、Android、IOS、中间件等等。微服务和分支开发的背景下，应用和分支数量泛滥，各服务相互依赖耦合，资源管理复杂度和需求量剧增，难度不亚甚至更超过线上环境的管理。没有趁手的利器，环境稳定性差，会导致开发和测试效率都十分低下，各个应用之间的开发工作互相 block，从而拖垮整个团队的项目研发。

幸好我们有了容器这个救命稻草，软件包管理、目录管理、基线变更、运维脚本等等通过一个 dockfile 就可以规范解决，再通过分布式配置中心（业内知名的如 springcloud 的 config、百度的 disconfig、携程的 apollo、淘宝的 diamond 等）实现对不同环境的配置管理，基本我们就实现了环境的标准化以及运维服务的下沉，DevOps 的理念才得以真正的落地。

一键生成容器服务 (其他还包括 mysql、redis、mongdb 等的标准组件) 界面:

研发环境特别痛苦的一个点是，每个应用都会存在大量并行分支的开发。如果全部环境混在一起，各个分支之间互相依赖互相干扰的情况会让人崩溃，而如果搞出几套独立的研发环境（比如常规分支、特性分支、紧急分支等），多套环境的维护量也同样会让人崩溃。

这里 比较好的一个实践，就是区分出稳定环境（stable）和分支环境，并且将分支环境隔离。这里的分支环境可能是一个开发机，也可能是一个测试服务器，针对某个需求相互依赖的应用分支可隔离在一个环境内，而非需求强依赖的应用则可以直接连接稳定环境。因为我们的分布式服务用的是 dubbo, 容器管理用的是 K8S, 要实现这点中间其实还涉及到不少对 dubbo 和 K8S 自身的改造。

持续交付的流水线

要实现持续交付，核心在于 Pipeline，要实现 Pipeline，重点在于自动化测试。通过诸如 Jenkins 等 CI 平台的 Pipeline 技术，可有效衔接研发各个环节串联，这里面囊括了编译、部署、代码检查、单元自动化测试、接口自动化测试、UI 自动化测试、专项自动化测试（APP 专项 / 性能等）、发布等。

Pipeline as Code 是 Jenkins 2.0 的精髓所在，是帮助 Jenkins 实现 CI(Continuous Integration) 到 CD(Continuous Delivery) 华丽转身的关键推手。所谓 Pipeline，简单来说，就是一套运行于 Jenkins 上的工作流框架，将原本独立运行于单个或者多个节点的任务连接起来，实现单个任务难以完成的复杂发布流程。Pipeline 的实现方式是一套 Groovy DSL(类似 Gradle)，任何发布流程都可以表述为一段 Groovy 脚本，并且 Jenkins 支持从代码库直接读取脚本，从而实现了 Pipeline as Code 的理念。