中国最大公有云服务商，如何从零开始构建一支云效团队

云原生研发效能平台，听起来是云原生时代的必备基础设施，但据信通院发布的《2022 中国软件研发效能调查报告》显示，业内具备该基础设施的团队仅有 26%，而有接近同比例的团队，甚至还处于纯手工阶段，可见留给各家企业的施展空间相当之大。

但要组建一支云效团队却并非易事。因为研发效能提升这一赛道的业务特点，相关工程师往往都带着一些客服色彩——传统客服无法解答研发类工具的使用问题，因此负责研发效能产品的工程师要和另一批作为用户的开发者保持密切的交流，实时解答问题，以获取第一手反馈。让后端的人，干前端的事，这对团队心性、企业文化是个考验。

同时，研发从某种意义上来讲，和艺术类创作一样，也是一件比较个人的事，使用工具的人往往有着不同的产品偏好。历代流行的研发工具，几乎全部具备高可定制性，这对企业的产品能力也是个考验。

再者，该领域在国内还没有绝对领先的产品出现，因此相关团队的创业氛围都比较浓厚，要求团队的战斗力比较强，也增大了团队组建和管理的难度。

带着这些疑问遍寻国内产研团队，阿里云云效团队，自然而然出现在了视野里。原因之一，阿里云是国内最大的云服务商，其团队构建、产品研发有着相当大的借鉴意义；原因之二，开放原子开源基金会刚发布的 AtomGit 代码协作平台产品，是基于阿里云云效研发的分布式多副本架构打磨而成，这从侧面证明了团队的实力。

在和阿里云云效团队总负责人陈鑫、CI/CD 团队负责人 崔力强，以及代码平台团队负责人蒋鑫聊过以后，我们发现阿里云云效团队更像一只创业团队，有着独特的创业气质，和而不同的团队文化，是他们向前的关键。

本文选自《中国卓越技术团队访谈录》（2023年第二季），下载查看更多精彩内容。

阿里云效团队发展历程

云效团队整体发展可以分为三个阶段：

第一阶段主要作为阿里内部服务出现，团队规模在几十人量级，以前后端研发、配置管理工程师、技术支持工程师为主，主要负责两个维度的工作：

1. 将阿里集团过去数年在工程效能上的方法实践通过工具进行标准化、数字化；

2. 配合技术中台战略，打造研发、运维、监控三大块领域的技术平台，也就是现在业界讲的“平台工程”；

这样阿里就可以通过统一的技术中台去推动内部技术发展与落地，比如容器化、云原生化、全面上云就是在技术中台的推动下实现的。

第二阶段，集团决定将技术中台核心产品和团队划归到阿里云，从而帮助阿里云补齐在 PaaS 层的核心能力，因此云效团队的主要工作目标是效能类服务的产品化。

云效团队要将过去近十年积累的效能改进方法实践、效能工具变成广大企业能轻松落地的产品。云效团队对产品架构进行了全面梳理，最终形成了七大核心模块，覆盖从项目需求管理到软件研发交付的全链路一站式工具平台。

为了确保产品质量和用户体验，云效团队按照新的产品架构，对原来的内部产品进行全面重构，重点投入用户故事梳理、UI 交互设计、云化改造、用户文档、性能优化以及稳定性体系建设。前后投入了两年左右时间，在 2020 年初完成了云效产品全新换代。

第三阶段是商业化。

商业化阶段最重要的是市场洞察、销售体系、运营体系、交付体系的搭建。云效作为阿里云上产品，需要同时服务公共云直接使用 SaaS 的客户，以及私有化部署的专有云客户。

SaaS 客户主要以中小企业为主，行业集中在互联网、新零售、娱乐等，这部分客户通常为自服务，更重视产品核心能力、交互体验、品牌影响力、价格与稳定性等，营销方面团队需要投入更多的内容运营与品牌运营。

而私有化客户主要为金融、交通、政府、能源等中大型企业，这部分客户不但希望买产品，还希望能够得到落地实施服务，更重视产品功能丰富度、落地案例、以及方法和实践的先进性。

针对不同的客户云效团队需要搭建不同的商业化团队，并且和阿里云市场、销售各部门进行紧密协同，有计划的对阿里云目标客户群体进行覆盖。

从发展流程来看，阿里云云效团队的发展存在两大特点：

1. 产品体系庞大且全面。由于发展历程长，且有阿里集团需求、阿里云云能力作为基础，阿里云云效团队与业内众多创业公司不同，并非只聚焦于研发工具等一两个垂直维度，而是从发展之初就聚焦于平台建设；

2. 阿里云云效团队虽然孵化自跨国大型企业内部，但有鲜明的创业团队色彩，其三个发展阶段，对团队能力的锻炼和要求都非常全面。

不过尽管如此，阿里云云效团队依然和业内所有团队一样，逃不开正常的业务开拓逻辑，遇见了许多挑战。

“大企业问题”与“小企业问题”

阿里云云效团队发展过程中遇到的问题，大致可以用“大企业问题”与“小企业问题”两个形容来做粗略的概括。“大企业问题”主要指目标与协同问题、战略目标的落地问题；“小企业问题”主要指有限资源与高目标的矛盾，以及团队的专业能力提升问题。

采访中，阿里云云效团队总负责人陈鑫聊到，团队目标与协同机制的问题，在最近几年商业化过程中，反映的最为明显。在商业化进程的早期，阿里云云效团队选择全面面向收入业绩去设定目标，业务人员、产品人员、技术 leader 都需要共背业绩指标。

实际上这也是业内大部分团队的选择，业务 leader 经常担心后台人员商业感觉迟钝，前台后台协作矛盾大，这种目标设定，确实可以让全体核心成员都可以面向商业化去思考问题，并且目标相同，在沟通协同时比较容易达成一致。比如某个行业客户要不要做，某个客户的需求要不要做等。

但是随着市场竞争进入深水区，这种目标设定的模式就出现了明显问题，比如团队更加追求短期经济利益，而忽视产品长期演进以及客户满意度，另外就是对一线技术人员来说缺少在技术卓越层面的激励等。时间长了，很容易发现团队的产品、技术层面硬实力出现停滞，而收入也随之陷入瓶颈。

所以阿里云云效团队最近几年开始实践 BizDevOps 方法，更加强调业务、产品、技术多角色的共识和协同，而不是单纯的业务导向。

反映在目标设定方面，首先是目标更加细化，业务团队承担收入与规模的指标，产品团队承担客户满意度、产品交付能力、产品竞争力指标，技术团队承担需求交付效率以及质量、成本、安全、稳定等技术先进性指标。

多角色之间目标不是简单的拆解关系而是承接关系。比如客户满意度和产品竞争力决定着市场营收的长期潜力，而技术竞争力和需求交付效率又决定着客户满意度以及产品长期竞争力。

其次是从组织协同上强调共识机制，对于前线带回来的业务需求，要求业务同学与产品技术同学达成业务价值、影响面、预计成本的共识，目的是为了有效的判断优先级。对于需求的传递强调从业务需求到产品需求再到技术任务的拆解，从而实现组织透明和溯源，让所有人对所做工作的价值和目标清晰和一致。

关于战略目标的落地，则与阿里云云效团队的发展阶段有关。

针对不同的发展阶段，云效团队的组织架构也经历过几次重大调整。在最早期的内部服务阶段，为了实现云效各子产品的快速发展，云效将产品与技术团队、测试团队放在一起组成独立的全功能团队，这样可以保障各产品资源独立并且闭环，决策快速，落地敏捷。

到了第二个阶段，即产品化阶段，这种产品全功能团队架构就出现了明显弊端，主要体现在各产品协同不够，导致产品一致性差，技术方面整体架构没有整体拉齐，也会导致在一些基础能力上投入不足，比如账号、权限、安全性、私有化输出、运维能力等。因此需要成立横向团队对基础模块和技术进行投入，比如产品团队统一拉齐产品设计规范、架构团队确定统一技术规范、基础平台团队完成跨产品共享能力的产品实现工作等。

此时云效团队形成了矩阵式组织架构。

在商业化阶段，云效团队面临的新问题是前线的市场洞见以及客户需求，能否快速有效的传递给后方，并且确保产品主线演进不被各种客户问题进行打断。

这就需要一套业务、产品、技术三个核心团队的有效协同方法。云效团队通过两个主要措施解决问题：

1. 业产技三级团队 OKR 设定以及拆解：如前文所述，业务团队负责业务指标、产品团队负责产品能力交付以及客户满意度、技术团队负责需求交付以及质量、成本、安全、稳定等目标。三级团队之间并不是简单业务数字拆解，而是要确保目标之间有承接与协同；

2. 业产技各角色执行中的事项、优先级、排期的共识：比如说需求并不是谁单方面决定要不要做，什么时候完成，而是要充分沟通形成共识。坚持市场为导向的同时，确保产品为中心的目标；

如果说以上都是“大企业”的烦恼，那么可以说云效团队也作为“小企业”、“创业者”的角色，为业务发展挠过头皮。

云效因为产品体系全面，注重平台能力，所以对研发、产品的能力要求极高。

在国内的 To B 赛道，绝大部分产品市场销量不好的原因很简单，就是不好用，用了以后解决不了业务问题。阿里云云效产品，在 2018 年产品发展的早期阶段，也曾被各类研发论坛的用户吐槽过，团队内部总结的问题有：用户注册、激活流程、交互设计、性能体验上都有不少短板，尤其是在产品架构方面问题很大。云效多个子产品之间互相耦合并且有强依赖，导致用户没有办法按照自身需求选择一、两个子产品进行落地，后期再逐步探索使用更多产品，而是要想用全都必须用，这无疑导致用户落地成本陡增。

坦诚问题存在是个勇气问题，但解决问题则需要付出卓绝的努力。差不多在同期，阿里收购了 Teambition，其对产品细节的极致追求给团队带来了很大的启发。

同时，云效团队下定决心，要对产品进行彻底重构，这带来了对人员能力的严苛要求。   一方面，这场重构对视觉、交互、产品设计相关岗位角色的能力要求需要大幅提升；另一方面则需要有魄力抛弃掉过去项目制思维（项目驱动，堆砌功能，缺乏复用和灵活性）转向产品化思维。在这个过程中一方面各产品技术负责人需要不断提升个人的能力与视野，在每一个功能上线前反复雕琢，上线后不断追踪数据和用户反馈进行改进，确保产品基本素质。此外，团队也需要引入优秀的产品经理，三年下来，云效产品团队的人员规模接近翻倍，最终完成了迭代升级。

除了主观层面，在客观层面上云效团队也经历过较大挑战，其核心在于资源和目标的矛盾。2019 年年底临近春节时，云效团队需要马上在阿里云上线新版云效。当时云效的产品已经和 Teambition 深度融合，只能带着 Teambition 在阿里云上重新部署一份，作为云效的产品组合来服务阿里云开发者。

工期限制在三个月内，人员投入十几位，时间非常紧张，整体技术难度也很大。而让全国人民印象深刻的三年疫情，也正是在那个春节快速传播。云效团队所有人被封闭在家中，只能以远程的形式工作。

但团队顺利的在预定时间内完成了对 Teambition 的改造，将其接入阿里云体系，并且高质量的完成了文档、技术支持、商业化等体系的搭建，完成了稳定性保障工作。这一次攻坚，确保了云效业务最近三年的顺利发展，完成了产品的全面升级工作，产品能力和体验相较于 2019 年年有了质的变化。

这是怎么做到的？陈鑫说，在云效发展的历史上，我们渡过了很多困难的节点，在关键时刻往往不是我去推动团队，去摇旗呐喊往前走。而是团队有一种自驱力，自然而然的兴奋起来，去战胜这些不可能难关，这个特质让我非常骄傲。

是什么造就了这种特质？这与企业文化、团队文化脱不开关系。

你相信阿里“六脉神剑”吗？

阿里“六脉神剑”作为头部公司的企业文化，在网络上广为流传，部分人会觉得文化不好落地。但在本次访谈中，我们发现，这套“六脉神剑”可能是云效团队能够前行的最大依仗。

云效 CI/CD 业务线早期规模很小，要对标国际成熟 GitHub 团队，做出更适合中国开发者的 CI/CD 产品，陈鑫谈及此事却并不觉得难以想象。他说，阿里巴巴能做出淘宝，蚂蚁能做出支付宝，我们相信我们也可以，因为“此时此刻，非我莫属”。

无独有偶，代码平台团队负责人蒋鑫也在采访中提到了“六脉神剑”，他最喜欢的是“认真生活，快乐工作”和“因为信任，所以简单”。蒋鑫说：“我特别喜欢这个文化，我爱人说我去了阿里以后整个人都不一样了。“认真生活，快乐工作”的意思就是，工作很辛苦，所以要做喜欢的事，要快乐；生活也是一样，你怎么对待生活，生活就怎么对待你。夫妻相处、子女教育都要花心思。”

“‘因为信任，所以简单’，有些公司的信息安全严格到无法在公司内参与开源贡献，而阿里云有更灵活的信息安全管控，参与开源贡献不再有重重阻碍，真正诠释了‘因为信任，所以简单’。”

同时，在企业文化的层面下，云效团队也在践行这些文化。如客户第一，陈鑫作为云效团队的总负责人，每天也会亲自在用户交流群去回答一些开发者的问题。

另一项整个云效团队比较看重的文化素质叫做“匠心”。

“匠心”贯穿招聘与文化

陈鑫在采访中说道：“匠心一方面代表着追求卓越的品质，另一方面也是一种愿意长期坚持做好一件事的心态。”

CI/CD 团队负责人崔力强用一个例子说明匠心是什么：“比方说你做事情的时候，你的方案是不是考虑的足够细致，还是说差不多能用就行。”

CI/CD 是阿里云云效产品对外提供的核心能力之一，历来是产品迭代的重中之重，因此，“匠心”也是 CI/CD 团队工作得重要特质。

2017 年，云效流水线产品正式进入到公有云市场提供服务，当时使用的是阿里云内部架构，19 年开始，云上用户量迅速增加，原有架构在规模化和可运维性上有一定的局限，于是 CI/CD 团队决定重新开发一个构建引擎，来应对云上用户更加丰富的构建场景需求，例如更多的语言，更多的技术栈，更多样的执行环境，以及快速增长的用户量对于稳定性和安全性的需求，希望可以做到 Any Language，Any Platform，无限扩容，支持不同的计算服务，比如 VM、容器以及阿里云的 ECI 等，支持不同的操作系统，支持不同的芯片架构。这是一个庞大的能力集合，需要稳扎稳打地逐步演进。

在开发的第一个阶段，也就是 2019 年底 - 2020 年底，团队的主要工作是开发并完善上层编排能力，希望 80% 的用户可以开箱即用，20% 的用户通过一定的自定义配置也可以实现自己的功能，需要解决的主要问题是场景化封装及构建环境调度等基础能力。

团队主要做了两件事情：一个是建立“执行环境” + “执行命令”组合的业务概念，内部称之为“步骤”，并使用阿里云容器服务的 ACK 集群作为容器的调度平台；第二个是实现了一个特殊的“自定义环境构建”的步骤。

在这套方案完成之后，CI/CD 团队不但在两个月内不但完成了 Top 5 编程语言在 Linux 平台下的编译、测试、扫描等能力的集成，而且实现了大多数阿里云 PaaS 层服务的集成，方便用户轻松地完成从源码到上线的全过程。

在开发的第二阶段，也就是 2021 年上半年，团队工作聚焦在优化构建引擎的稳定性、安全性。保证可用性达到 4 个 9 ，也就是一年最多 52 分钟不可用，为了达到这个目标，除了服务本身的质量和可靠性，还需要关注依赖的可靠性。在提升稳定性方面，主要遵循一些通用的设计原则：

1. 明确系统的依赖，确保依赖的 SLA 可以满足云效团队的 SLA 要求；

2. 通过冗余来提高 SLA；

3. 限流和削峰填谷；

4. 可水平扩容；

但如果在构建引擎这个领域将这些原则落地，还是有很多具体问题需要解决的。

比如，构建引擎依赖阿里云的 ACK 集群，而且会频繁的调用 ApiServer 创建任务。ApiServer 的可用性是 99.95%，作为单个依赖，就已经低于团队期望的可用性了。识别出来这个 SLA 上的不对等，就必须要使用多 AZ，多 Kubernetes 集群的冗余来弥补。团队在单个 Region 采用了三个 ACK 集群进行热备，当一个集群出现问题，可以快速扩容其他集群，以应对整体的流量，当两个 ACK 集群相继挂掉之后，构建引擎仍然可以提供服务。通过简单的计算可以知道使用了热备之后，ACK 依赖的可用性就从 99.95% 提升到了 99.9975% 。

当然为了做热备，还需要解决好多个热备之间的调度、心跳、熔断等细节场景，确保多个集群之间的调度均衡，且在单个集群失效之后，可以及时的侦测到并摘除集群，同时要避免误判，在及时性和准确性上需要达到一个平衡。

此外，崔力强也很喜欢“极限编程”这一软件工程方法，并将其带给了团队。极限编程最早于 1996 年由 Kent Beck 提出，主要目标在于降低因需求变更而带来的额外研发成本，有这一整套详细的规则和实践方法。其中最让崔力强和其团队收益的两点是“单元测试”和“重构”，节省了许多不必要的精力浪费。

也是因为好的编程方法的实践效果，崔力强并不崇尚团队加班，而是鼓励团队高效工作。

开源也是帮助团队成功的秘诀

除了“匠心”文化之外，开源也是云效团队的重要课题之一。作为代码平台团队的负责人，蒋鑫是个资深开源贡献者，他直言：“我来阿里的重要原因之一，就是阿里有非常好的开源文化。”

对于所有从事代码平台开发工作的工程师来说，GitHub 是个珠玉在前，不得不提的产品。但 GitHub 的设计理念却不一定适合企业级代码托管需求。

GitHub 在 2008 年创造性地发明了仓库派生（fork）和代码评审（pull request）的协同方式，推动了开源社区的发展。蒋鑫在深入了解开源社区的运作模式后，找到这一模式成功的原因，即：GitHub 模式解决了开源社区期望的人人皆可参与开源贡献的难题。现在已经是 2023 年了，开源贡献者面对只读的代码仓库，难道还是只有仓库派生一条路么？面向企业的研发协同代码平台，难道也要东施效颦，通过仓库派生进行代码协同么？GitLab 认为分支模式是企业协同的主要途径，但是这种模式也给很多团队带来分支管理混乱、无法适从的困惑。

阿里云云效代码平台团队的一项重要工作，就是突破传统惯性，创建既适合开源场景（包括企业内开源），又适合企业内部的代码协作模式。这种模式允许开源贡献者在没有写入权限时，仍然可以使用 “git push” 命令向只读的开源仓库推送，推送操作直接创建代码评审。新的模式让企业用户简化代码仓库的授权，无需管理人员参与，任何人均可以自助式的创建分支、删除分支、强制更新代码和创建代码评审。

这并非闭门造车。在创造突破性的代码协同模式过程中，云效团队和 Git 开源社区保持密切协作，在 2020 年将 Git 核心的改动贡献 Git 社区。

参考文章：《Git2.29 让 Git 成功“牵手”Gerrit》（https://developer.aliyun.com/article/776452）

代码平台的另一项技术挑战在于性能问题。现在业内的代码平台，支撑数万人同时在线协作，普遍会遇到性能和稳定性问题。数年前，云效代码平台的老架构，只有一个副本提供写服务，运维团队不得不 7x24 小时保持手机开机，疲于应付。后来也是在开源社区汲取营养，经过技术攻坚后，团队完成了分布式架构改造，解放了生产力。

蒋鑫聊到，这一般有两种解法，其一是期望采用现成的分布式文件系统实现计算存储分离，进而解决代码平台水平扩展问题；其二是针对 Git 仓库的特点通过仓库分片、自研分布式多副本架构解决代码平台架构问题。最终团队采用了第二种解决方案，研发和 GitHub 类似的分布式多副本架构，解决了性能和可扩展性问题。目前团队也在研发新一代架构以期实现云原生的计算存储分离的代码平台架构。

所有这些技术挑战，都从开源社区里吸收了许多养分，大到为技术攻坚寻求方案灵感，小到一个测试用例的写法。蒋鑫说：“我们发现 Git 开源项目的测试框架非常简单易用，开发测试用例非常高效，进而在团队内推广，已经将其延伸到 C 语言之外的开发语言。我们还写了技术文章分享——《测试用例难写？来试试 Sharness》（https://developer.aliyun.com/article/770948）。”

当然，有汲取就有回馈，云效代码平台团队里的多位同学都是 Git 社区的 Commiter，云效代码平台团队在打造创新产品同时，也在打造具备行业影响力的团队。云效代码团队 2021 年开始打磨 Git 系列视频教程和训练营，与业界开发者分享 Git 上手指南，至今已有近 30 万人次学习观看。

关于团队的未来思考

对于国内研发效能领域的绝大部分团队而言，挑战刚刚开始。相关报告中的数据显示，国内发布成功率在 85% 以上的团队仅有 69%，平均故障修复时长一天以内的团队，仅占总数的 48.9%，不足一半。要解决这些问题，需要一支能满足数字化时代客户需求的卓越团队。

陈鑫在采访中提到：“云效一直致力于为广大开发者提供专业、数字化、普惠的开发者工具产品。专业意味着代表最新的技术趋势以及生产力，这一点对于云效属于基本盘，我们有一个非常好的阿里云的技术基础，以及庞大的内部开发者群体来孵化。数字化意味着我们需要建立端到端的开发者工具链，去构建产研管理完整生命周期的数字模型，从而不但解决单点生产力问题，还有机会去解决生产关系问题。普惠意味着我们要服务足够多的客户去降低边际成本，又需要建立足够标准化的产品以及丰富的合作伙伴生态。从我们的使命愿景出发，云效的发展路径和目标已经可以被清晰构建出来。

我期望云效团队未来可以具备与使命愿景匹配的技术能力与组织能力。首先是有一批始终追求卓越的复合型技术人员，在大模型时代要求我们不但需要具备基础的工程素养以及能力，还需要懂数据与算法，一专多能成为标配。其次有一个懂用户，又有匠心的产品和服务团队，这个团队能够深入一线的开发者和企业的管理者，求真务实的解决问题，用细致产品和服务让客户满意。最后是整个云效团队的协同能力，在未来我们仍会继续践行 BizDevOps 产研数字化管理实践，也期望将自己的经验分享给更多的团队，与广大企业共同成长。”

采访嘉宾简介：

• 阿里云云效团队负责人 陈鑫

• 阿里云云效 CI/CD 团队负责人 崔力强

• 阿里云云效代码平台团队负责人 蒋鑫

内容推荐：

中国卓越技术团队访谈录（2023 年第二季）深入采访了腾讯、网易伏羲、阿里云、QQ 等技术团队，呈现了这些团队在向量数据库、大模型、前端和研效等方面的技术落地、产品演进和团队建设等方面的多年实践经验和相关心得体会。点击下载电子书，查看更多精彩内容。