devops [持续交付实践] DevOps 背景下的组织结构

蒋刚毅 · August 10, 2018 · Last by 猪头君 replied at July 23, 2019 · 4884 hits
本帖已被设为精华帖!

前言

随着微服务架构与容器虚拟化技术的发展,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平台建设的重要目标。

结语

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

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 10 条回复 时间 点赞
蒋刚毅 关闭了讨论 10 Aug 16:26
蒋刚毅 重新开启了讨论 10 Aug 16:26

今年大会看到ebay的测试开发工程师也是这样玩的了

看来楼主在ci/cd上有点料呀,但我个人觉得不能仅仅以应用为中心,需要以人,应用与设备三者为中心。

卡斯 将本帖设为了精华贴 10 Aug 18:34

写的不错,大势所趋。

devops以后是大趋势,支持楼主

赞,统一的资源申请,统一调度,统一平台,减少沟通成本和内耗,提高效率

Author only
徐汪成 回复

可以 注明出处即可。

simple 专栏文章:[精华帖] 社区历年精华帖分类归总 中提及了此贴 13 Dec 14:44

部门架构上的划分问题并不是可以一笔带过的程度了:

  1. 中台和业务线业务重叠的部分责任如何划分?
  2. 业务线和中台都要快速迭代,但是中台的升级本身就会给业务线带来影响,如何能保证项目选择和快速交付的战略能够执行下来?
  3. 这个组织架构在结构上并不属于项目型架构,也不属于职能型架构,矩阵的划分上不仅有权责交叉还有业务领域的重合,怎么保证在执行组织级策略的时候,干系人之间能达成一个平衡,纵向的资源整合如何操作?
蒋刚毅 #15 · June 24, 2019 作者
猪头君 回复

你提的几个点都很到位,这种架构很考验团队的分工和组织能力。尽可能抽取共性的能力放中台,让个性化的业务能力放业务部分,这里没有一个通用的公式,取决于各个公司的业务结构。只是相对来说,运维平台、基础架构、研发效能平台、安全平台、数据平台等,这些职能的属性比较独立,更适合放在中台,但也会阶段性发生演变,比如数据部门在公司变得庞大以后,偏业务的数据分析部分会逐渐脱离中台,甚至运维部门里面的应用运维部分也会逐渐分拆到业务线去,没有绝对不变的组织结构。

蒋刚毅 回复

感谢,我发现我对共性这个点理解偏了,基础服务类包括运营支撑之类的平台抽到中台是一个合理的考虑,之前我见过一个把上下紧密依赖的业务公共服务抽到中台的案例,结果是底层服务频繁迭代,导致上层业务进度和沟通成本失控,缺陷在业务下游被放大;汇报线也混乱,上游业务的运营策略要依赖中台的资源,结果导致中台和业务没办法协同,互相推责任,整体效率低下

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up