前言

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

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

跨组织 DevOps 平台建设实践

以应用为中心
任何一个成熟的公司，根据职能不同，内部都有很多的研发平台，研发端有代码管理平台，代码检查平台，codeReview 平台，配置管理中心等，测试端有接口测试平台，UI 自动化测试平台、测试数据中心、Mock 中心等，运维运营端有资产管理平台、发布作业平台以及各种监控平台，安全上也会有安全资产管理、安全情报感知，业务安全风控、网络安全监控等等平台。在过往的职能结构里，往往各个职能部门会各自建设这些系统，研发说系统，PM 说项目，运维说机器，安全说威胁信息等等，各个职能部门缺少一个共性的东西把这些系统打通是部门之间信息沟通不畅的重要原因。
所以建立公司级别的标准应用库，这点非常重要，是整个研发协同活动的基石。建立了统一的应用管理平台后（应用基础信息一般包括应用的语言，jdk 版本，编译工具和版本号，代码地址，应用负责人，部署中间件等），后面的代码、资产、环境、流水线、监控、配置、质效等等的管理就都可以围绕着应用维度来展开。
应用有了标准库，也就有了生命，有了生命周期的管理，应用不再只是一个干瘪的代号或标识，而是一个活动集合一个工作系列。比如停用应用的操作就可自动化驱动代码库冻结，流水线 job 回收，研发环境回收，线上资源回收，应用监控关闭等一系列操作，大大减少了人工操作的复杂度和错误率。

再举例来说，以前运维团队建设 CMDB 资源管理平台，传统思维上总是习惯于以物理资产为中心去建设，聚焦在物理资产的管理，比如各台机器什么配置，什么品牌，资产编号，资产价格，资产型号，资产位置甚至资产照片等等。自建机房的时候物理资产的管理还是存在一定的价值，但在云时代这些信息基本已经失去了意义，容器云时代已经完全不用关心容器的物理载体。对研发过程来说，仅仅聚焦在静态的物理资源管理是没有意义的，需要建立一个逆向思维，不要从资源的角度维护资源，而是从应用的角度来维护资源。主机是什么？是应用的一个资源；Docker 是什么？可以看成应用的附属资源；分布式 Redis 服务是什么？是应用的附加资源等等。
基于此考虑我们以应用为中心重建了 CMDB 系统。在申请资源的时候，研发团队以应用为主体申请需要的资源，在研发环境可以一键申请生成，在正式环境则在运维团队审批后自动分配，并在 CMDB 中记录了每个应用对应的资源信息，应用停用后，这些占用资源很简单的就可以实现自动的回收和释放。通过建立业务维度的资产管理体系，CMDB 才开始真正发挥出它应有的价值。

统一的认证授权
要聚合技术体系内原有分散的各个内部平台，使用统一的 SSO 认证授权机制是基础。这里有两个概念，一个是认证，一个是授权。
我们最早的内部用户体系是基于 LDAP，LDAP 可以实现用户名密码的统一管理，但由于缺少授权机制，跨多个系统时仍然存在需要重复登录授权的问题，后来基于 OIDC 重新构建了新的认证授权体系，并对公司内部所有的研发管理系统做了认证和授权的统一。
OIDC 因为是标准协议，开源应用一般也都支持，这样除了我们内部研发的系统，其他开源的如 Jenkins、Gitlab、Redmine 等系统都可以打通，免除了各个系统整合时重复登录的苦恼，各个系统的安全性也可得到有效的保障。

统一的权限管理
这里主要还是应用权限管理的统一，按照角色，维护每个应用的人员权限（应用负责人，开发人员，测试人员，运维人员等等）。
因为所有研发协作系统是以应用为核心，应用权限统一后，每个系统可以不需要再独立去建权限系统，谁能修改代码，谁需要接收报警，谁可以构建流水线，谁能申请资源，都可以获得高度的统一。

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

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

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

结语

公司的组织结构和技术结构直接相关，有时候甚至会直接决定技术的架构。
正如康威定律所言：设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。