[持续交付实践] 研发协作平台：DevOps背景下的组织结构

前言

今年以来做的事情越来越杂，负责的技术方向越来越广，精力越来越分散（创业公司的典型特点），编码的时间越来越少，有时候也会觉得很疲惫没办法专注一个事情。

除了技术方向上的实践，组织上如何组建一个最优的DevOps团队形式，实际工作中也面临着大量的挑战和困惑，抽点时间总结一些不太成熟的实践。

虽然下面很多的内容与测试开发已经无关了，但对这个论坛还是比较有感情的，过往的系列文章也都在这里，所以还是在这里发下分享给正走在这条路上的朋友。

DevOps对传统职能部门的挑战

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

互联网时代，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等大厂也早已经有成功的先例，最典型的就是阿里“大中台+小前台”的技术组织结构，中台部门负责基础设施建设，业务部门利用这些成熟的基础组件快速搭建业务应用，其中比较特殊的是研发效能和信息安全两个组织，纵向贯穿所有技术团队，为整个技术团队提供效能和安全的赋能，而研发效能团队主要是由原有的运维开发，测试开发，敏捷教练以及部分专职开发人员组成，为阿里几万名技术工程师提供一站式的研发协作平台。

内部组织结构涉及公司机密，这里可以贴下阿里一个公开的技术组织结构图。

虽然这种组织形式仍存在不少争议，实践中也有些过于理想化的地方，但总体来说从技术角度窃以为是更优于腾讯提倡赛马，各组织完全分立的组织方式（TEG技术工程部门的掌控力很有限），这点从阿里和腾讯在基础技术设施能力上的对比就可以深刻体会。纯属个人意见，估计会收到不少板砖哈哈。

跨组织DevOps平台建设的一些基础

以应用为中心

任何一个成熟的公司，根据职能不同，内部都有很多的研发平台，研发端有代码管理平台，代码检查平台，codeReview平台，配置管理中心等，测试端有接口测试平台，UI自动化测试平台、测试数据中心、Mock中心等，运维运营端有资产管理平台、发布作业平台以及各种监控平台，安全上也会有安全资产管理、安全情报感知，业务安全风控、网络安全监控等等平台。在过往的职能结构里，往往各个职能部门会各自建设这些系统，研发说系统，PM说项目，运维说机器，安全说url请求，各个职能部门缺少一个共性的东西能把这些系统打通是部门之间信息沟通不畅的重要原因。

举例来说，以前运维团队建设CMDB资源管理平台，传统思维上总是会以物理层资产角度去建设，聚焦在物理资产的管理，各台机器什么配置，什么品牌，资产编号，资产价格，资产型号，资产位置甚至资产照片等等，自建机房的时候物理资产的管理还是存在一定的价值，但在云时代这些信息基本已经失去了意义，容器云时代已经完全不用关心容器的物理载体。对研发过程来说，仅仅聚焦在物理资源管理是没有意义的，资源是静态的。必须要建立一个逆向思维，不要从资源的角度维护资源，而是从应用的角度来维护资源。主机是什么？是应用的一个资源；Docker是什么？可以看成应用的附属资源；PaaS平台中分布式RDS服务是什么？是应用的附加资源等等。

建立了统一的应用管理平台后（一般包括应用的语言，jdk版本，编译工具和版本号，构件路径，代码地址，应用负责人，中间件等基础信息），后面的流水线、发布平台、监控平台、资产管理平台等等都可以公用这些公共信息，从而保持了各个系统应用信息的一致性，并以应用名贯穿了跨组织的各个系统。

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

统一的认证授权管理

要聚合技术体系内原有分散的各个内部平台，使用统一的SSO认证授权机制是基础。这里有两个概念，一个是认证，一个是授权。

我们最早的内部用户体系是基于LDAP，LDAP可以实现用户名密码的统一管理，但由于缺少授权机制，跨多个系统时仍然存在需要重复登录授权的问题，所以现在基于OIDC(OAuth2+OpenID)重新构建了新的认证授权体系，并在全公司的内部研发系统做了统一。

OIDC因为是标准协议，开源应用一般也都支持，这样除了我们内部研发的系统，其他开源的如Jenkins、Gitlab、Redmine等系统都可以打通，免除了各个系统整合时重复登录的苦恼，各个系统的安全性也可得到有效的保障。

统一的权限管理

这里主要还是应用权限管理的统一，按照角色，维护每个应用的人员权限（应用负责人，开发人员，测试人员，运维人员等等）。

因为所有研发协作系统是以应用为核心，应用权限统一后，每个系统可以不需要再独立去建权限系统，谁能修改代码，谁需要接收报警，谁可以构建流水线，谁能申请资源，都可以获得高度的统一。

统一的配置管理

所有的内部研发系统，使用统一的配置管理后台，配置参数灵活管理，调整后实时分发。

统一的操作审计管理

确保所有内部研发系统的操作可以审计，操作日志统一管理。

一站式的研发协同

在上面几个关键技术环节统一后，再加上UI设计上的统一，各内部研发系统的统一要做到一站式的统一就已经是水到渠成的事情。各个系统还是可以独立研发，但有选择的整合到一个统一的DevOps研发协作平台非常有必要，让整个研发协同过程变得连续而有节奏，再也没必要去记一堆的系统不停的去切换登录操作了，一站式的解决研发协同过程中的所有问题是DevOps平台建设的主要目标。

结语

公司的组织结构和技术结构直接相关，有时候甚至会直接决定技术的架构。

组织结构是个很大的命题，能力有限观点难免有些偏颇，但这些东西思考了挺久觉得还是有必要总结下，也算是对自己有个交代。

话题比较沉重通篇也没什么技术干货，后面还是总结点纯技术的文章比较省心，哈。