[持续交付实践] 研发协做平台：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平台建设的主要目标。

结语

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

组织结构是个很大的命题，能力有限观点不免有些偏颇，但这些东西思考了挺久以为仍是有必要总结下，也算是对本身有个交代。

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