无限极｜零售行业数字化转型BizDevOps建设实践

前言

在11月召开的中国 DevOps 社区广州峰会上，无限极（中国）有限公司DIT开发与测试中心的测试与效能经理 陈顺生 分享了其团队在支持公司业务数字化转型中的 BizDevOps 建设实践，令在场听众受益匪浅。

一、背景与挑战

1. 灵魂三问

在工作中我们是不是经常听到这样几个问题？

“我的需求提交好久了，什么时候可以上线？”

“大家都说需求很急，排序怎么做合理？”

“大家很忙，但其他部门质疑我们工作量不饱和！”

第一个问题，业务部门关注客户需求并收集反馈给产研部门，却迟迟未能实现上线，询问进度时产研团队也无法明确承诺上线时间；

第二个问题，产品经理在面对一线业务提出的紧急需求时，无法权衡各个需求的价值，难以进行有效的排序和优先级设定，于是只能将这些需求传递给生产和研发部门；

第三个问题，研发团队的工作节奏常常被打乱，虽然看起来工作繁忙，但实际上效率低下。尽管其他部门也无法提供确凿的证据来支持他们的观点，但研发团队也难以拿出有力的证据来反驳这种状况。工作量的管理缺乏系统化的承载和度量方式，这使得生产和研发部门感到压抑和不满。

可见，业务、产品、研发三个角色各有痛点。无限极在业务指数式的爆炸增长下，引入 DevOps 前也面临着同样的挑战。于是交付效率的问题反复被提及，面临内部质疑，产研开始探索解决研发效能问题，证明自己。

2. 数字化转型过程中遇到的挑战

无限极在数字化转型中会经历三个阶段，分别是信息化、数字化与未来的全面智能化。在初期的信息化阶段，我们引入了数个单一工具以达成生产效率的初步提升，结果这些单一的工具形成了数据孤岛。到了基于云底座的数字化转型阶段，数据孤岛对数据闭环、分析造成了障碍。如果想实现数智化，数据孤岛也是需要治理的先决条件。

我们决心解决上述两类痛点与挑战，从组织文化、流程、工具、架构等层面进行改变。其中组织文化和人员技能就要求内部IT同学进行转变、并借助外部优秀的工具辅助提升效能，以满足快速迭代和交付产品价值。

二、 破局三板斧

破局？我们聚焦在三板斧！即敏捷文化宣导，组织流程优化、借助DevOps工具赋能以及技术容器化升级。这一切建立在数据层面分析驱动。

1. 打造数字化时代的高绩效研发组织

在组织文化和团队建设层面，以业务目标驱动，致力于打造数字化时代的高绩效研发组织，打破职能边界，转型为敏捷交付团队。

在实践过程中我们发现很多敏捷框架无法直接导入——在Scrum或LeSS里，PO的地位不上不下；Scrum Master 只是敏捷鼓吹手，不对交付结果负责，这与国内组织文化很不匹配。因此最终决定践行规模化敏捷框架ADAPT。

ADAPT框架包含5个部落级角色（部落长、业务负责人、测试分会长、架构师、版本经理），以及3个小队级角色（产品经理、小队长、研发小队成员）。部落可以是个虚拟组织，在不改变企业现有组织架构的情况下搭建而成。所以，这些角色定义的也可以是部落运行中的虚拟角色。

• 业务负责人：部落的业务带头人，覆盖产品整体范围和优先级决策。通常一块业务有一个负责人，对业务结果负责。当需求优先级发生冲突时，给出最终决策。
• 部落长：部落的交付负责人，负责部落交付和资源配置，也对部落最终绩效负责。部落长负责整合部落内的各种资源，保证快速高质量完成交付，也为跨部落资源协调提供帮助。
• 产品经理：部落产品创新的核心力量。产品经理要能融合业务知识、互联网运营思维和科技能力，综合要求较高，通常需要内部培养。产品经理负责产品规划，对短期业绩诉求和长期产品发展进行平衡管理，将业务创意转换成研发团队可以理解并实现的需求，并对研发交付的需求进行验收。产品经理和开发人员的配比应该在 1:6 到 1:10 之间，目前该角色在组织里多是配比不足的，这也成为了交付速度和质量的瓶颈。
• 测试分会长：测试资源的管理者，质量防线的设计师，负责守护部落交付质量。我们建议将测试人员分解，和开发人员一起混编成研发小队，而非将所有测试人员集中，形成测试人员资源池。测试分会长（部落内为分会，跨部落为行会）通过流程影响小队长和小队成员，在源头保证质量。TA还可以通过各种培训分享活动，提升整个部落的质量能力。可以考虑在部落级别保持一支专项测试小队，负责测试框架、自动化、测试环境维护、性能测试等专项工作。为了提升控制力，测试分会长应该是所有测试人员的汇报领导，对测试人员的考核具有最终决定权，这样既能提高该角色的影响力，也提供了一条快速通道，让研发小队里的测试人员能够自己升级质量风险。
• 架构师：系统架构的守护者，负责部落系统的长期质量守护，对系统发展和技术路线进行长期规划，明确各系统职责，并在各系统负责人的设计决定无法达成一致时进行仲裁。各系统的分管架构师负责该系统的整体质量，审核系统的核心设计，并对关键代码进行代码评审。
• 小队长、研发小队成员：研发小队由产品经理、开发人员、测试人员混编而成，一般不超过12人。产品经理负责澄清需求，并在业务负责人的授权范围之内，决策业务优先级。小队长负责组织小队成员交付需求，管理研发的容量、进度、质量。在SCRUM框架里，小队不设置负责人，由团队自组织运作，这超越了大多数组织的成熟度水平，在复杂架构的企业里尤其难以实现。
• 版本经理：部落交付的最后一棒，负责系统版本交付。版本经理负责规范化系统版本的制备过程，与运维团队对接，对系统版本部署到生产环境的全过程进行监控。

2. 有了组织，还要保证落地。这需要制定和贯彻流程管理规范。

• 具有仪式感的常规沟通：需求池月度会议沟通、线下会签定例展开；严控需求项目成本、执行收益报批；进行产品开发和进度跟踪，要求团队成员通过共享日历了解彼此的工作闲忙状态。诣在基于ADAPT形成自己的敏捷文化，打造适合自己的敏捷交付团队。
• 极其注重月度复盘：复盘的目标是从整体上了解团队的研发效能情况，及时发现研发过程的问题，通过问题分解和深入分析，找出问题的根因和改进点，从而驱动持续改进。久而久之也积累了一些复盘提倡的原则。
• 复盘还能助形成组织文化价值观。比如“过生日”文化、工作计划/进度/问题透明公开、提倡信守承诺、度量驱动持续改进、提升经营意识关注投入产出，以及鼓励内部积极分享、并形成“我做你看&你做我看”的会议主持风格。
• 在团队组织建设层面，提倡合适的人做合适的事。活用自有人力和驻场人力完成项目交付，比如自有人力熟悉业务、技能水平高，安排维护核心系统；其他短平快的产品迭代交与外包人员；对于供应商合作研发模式，以项目全包或者半包的方式灵活应对。

3. 敏捷迭代需要统一的流程

在流程层面，基于APAPT和SCRUM框架完善IT团队实现敏捷交付，并制定和遵循一套完整的从backlog-迭代-发版-运营的流程。

三、工具赋能实践

1. 插上工具的翅膀

我们基于腾讯云CODING DevOps平台改善数据分散原状，通过使用项目集、项目协同、代码仓库、代码扫描、持续集成、测试管理、制品仓库、持续部署、应用管理等功能，迅速实现了完整的敏捷交付工作流。并将CODING和内部运维平台、CMDB、以及接口压测平台系统集成，把所有的研发协作沉淀在平台上，进而将工程数据上报，拥有了自己的研发数据驾驶舱。

• 研发分支采用 Aone Flow 分支模型作为分支规范，并在CODING DevOps配置落地 在选择研发分支模型时，诸如Gitflow分支模型、GitLab分支模型等各有其优点和适用场景。我们的选择应基于自身业务的敏捷性以及电商零售行业面向小b和小C客户的具体需求。考虑到需要快速响应市场变化和客户需求，我们倾向于采用一种能够支持灵活、快速发布的模型 —— 类似“快慢车发布分支”的策略。这种方式允许我们为每个业务需求创建独立的特性分支，这些分支以其对应的需求ID作为命名，确保需求与代码分支之间的清晰关联。 在开发过程中，每次提交（commit）必须包含相应的需求编号，这有助于追踪和管理代码变更，确保每个改动都能准确地与特定需求相关联。当某个特性分支完成开发并通过测试，准备发布时，开发团队可以根据版本计划和发布对象，将该需求分支合并到相应的发布分支进行集成和上线。这种模型的优势在于其灵活性。如果在集成过程中由于业务原因需要取消发布，我们可以轻松地重新选择和整合其他需求分支。这样的流程设计旨在最大化我们的敏捷性和应对变化的能力。 基于以上考虑，我们选择了基于AoneFlow的改进规范。这一规范借鉴了Gitflow等现有模型的优点，同时针对我们的电商零售行业To小b/小C场景进行了定制化调整，以更好地满足我们的业务需求和发布节奏。通过实施这一规范，我们期望能够提升开发效率，保证代码质量，并实现更顺畅的发布流程。

这些分支规范配置在CODING代码规范中，统一管理规范并将执行进行固化。目前配置规范包括：

a. F&S flow 分支规范：适用于多分支迭代并行的中大型开发团队使用快慢车发布，支持 master、feature/*、 release/*、bugfix/* 分支；

b. 允许创建规定分支类型以外的分支（CODING分支规范配置）；合并方向：规范仓库分支间的合并方向，只允许创建列表中规定方向的合并请求，列表为空则不会对仓库中的合并请求方向做限制；

c. CD flow 分支规范：适用于开发与测试中心一般规模开发团队，支持 master、feature/、 release/、bugfix/* 分支；

d. 允许创建规定分支类型以外的分支（CODING分支规范配置）；合并方向：规范仓库分支间的合并方向，只允许创建列表中规定方向的合并请求，列表为空则不会对仓库中的合并请求方向做限制。

注意！不存在一个分支模型适合所有场景的情况，选择研发分支模型时大家一定要根据不同模型的特点和团队规模、操作成熟度和业务特性来选择合适的分支模型。

• 在CICD环节通过CODING CICD以及腾讯云基础设施，实现全流程串联 容器化之前我们使用了 CODING 持续部署的主机发布，后来由于公司基础运维大部分都已经上云，云原生应用平台必须以应用为中心展开部署，不仅可以直接通过基础设施管理集群负载和应用的状态和信息，还能接入云上的链路追踪、监控、告警、事件、日志组件。因此后来改为采用 CODING 持续部署和 CODING Orbit Gitops 应用管理发布云原生应用，同时在CODING上采用 CODING 持续集成实现代码编译构建，结合本地MAC自定义构建机实现IOS发布。 制品管理方面，研发测试的制品采用 CODING 制品库，生产制品会采用腾讯云 TCR，以方便跨集群跨区域制品加速下载。
• 开发与运维共享模板。为了加强 dev 和 ops 的协作，我们制作了一些通用共享模板以统一规范管理和实现自动化： a. 构建模版一般由后端服务构建，前端app、uniapp、小程序打包模版快速复制，同时根据代码的更新自动触发、定时触发，以及模版中指定代码扫描门禁、自动化测试插件的方式构建统一的模版； b. 部署模版通过 CODING 应用管理设置，每一次的发布都会代码的commit记录，采用gitops方式管理每一次部署。我们维护应用的服务模版，定义服务的启动方式、端口、通用的apm和监控的agent、配置相应的健康检查（启动、就绪、存活、优雅关闭等），确保开发和运维使用相同的模版，并且每个部署的流程和部署环境可以选择部分的自定义替换，统一了运维监控的手段； c. 考虑到制品传输的效率，我们使用了统一的基础镜像源，从而提升了CI/CD效率，也保障了制品安全。
• 打通价值流 ，践行BizDevOps与数据驱动 a. 拉通项目集-项目空间-需求-子工作项-工时统计，实施管理跨项目业务需求管理；b.项目集工作项与内部系统打通建立立项项目审批流，一方面拉通了IT与业务相关组织，另一方面实现了业务目标（gmv/nps/DAU/收入等）与研发投入的关联，实现了从立项、财务结算、业务成本及ROI全流程管理； c. 建立效能看板，整合和清洗Coding系统、CMDB系统、内部考勤系统数据进行展示； d. 除了敏捷指标外，也添加了业务满意度、收入效益、流动速率等评价指标，从“快不快”、“好不好”、“省不省”等几个方面收集评价。

• 质量内建

在质量内建的层面，我们已经在需求、用例规范、单元测试和接口压测等方面做出了努力，以确保P0和P1级别的接口通过率，并且要求每次测试的通过率至少达到90%。然而，我们意识到可能仍存在未被发现的测试场景。因此，我们推出了质量内建2.0版本，其中产品和开发团队也承担了一部分质量保障工作，不再完全依赖测试人员。

a. 在新的版本中，我们在需求评审、技术评审和用例评审过程中增加了会前评论数的参考，以避免评审流于形式且效果不佳。这一改变取得了良好的效果。通过这种方式，我们在需求的完整度、设计的全面性和测试的颗粒度上发现了许多问题，并能够尽早地暴露和解决。

b. 为了提升代码质量，我们实施了质量左移策略，包括代码扫描、代码评审、接口开发自测和自助压测。我们提高了代码评审率和代码质量评分指标，并制定了开发接口自测的标准。我们还通过APIFOX对接口模型的设计、评审、mock、自测和自动化测试进行了集成。此外，我们实现了基于CICD效率提高的开发自助压测，压测环境能够在压测前自动扩容，结束后自动缩容。对于数据库，我们启用了云上的自动扩容功能，当CPU使用率达到50%以上时自动增加一倍的CPU和IO资源，当低于30%时自动缩容，这极大地提升了我们在接口功能和性能方面的质量左移。

c. 我们还引入了基于jacoco的测试覆盖率工具，并将代码覆盖率不低于80%作为测试通过的指标。在提测阶段，我们会收集该功能分支的代码差异，并通过CICD模板在应用中进行插桩操作。如果代码覆盖率未达到标准，测试人员需要与开发人员确认未覆盖的代码分支和路径，进行测试场景的确认和补充，以提高测试的完整性。

d. 除了上述措施，我们还根据需要进行兼容性测试和安全性测试。例如，我们可能会每季度或定期通过众测等方式进行这些测试，少量的兼容性测试则直接在腾讯Wetest 平台上进行调试。

借助工具优化了流程、规范了过程、提升了效率和质量，也实现了基于数据的持续改进。结合架构优化、变更管控和运维保障手段，构建了可靠稳定的业务支撑基石。

四、收益与总结

经过内部的数字化转型和DevOps效能提升的实际应用，IT团队已经取得了符合预期的收益：

• 研发交付现以业务需求为中心，旨在为公司创造价值。IT团队的角色已经从成本中心转变为直接推动业务收益的部门。
• 我们成功打破了部门间的壁垒，实现了协同工作和透明的工作负载分配。IT团队的角色转变为主动寻求业务需求，实施了从需求端到端的流程优化，提高了人员效率，并在此过程中重塑了组织结构。
• 我们解决了迭代范围不清晰的问题，将过去的迭代周期从3周甚至更长的时间优化为固定双周迭代版本交付。这一改变实现了有计划的交付节奏，使我们更有信心承诺满足业务需求。
• 我们已经摆脱了过去忐忑上线、熬夜发布的状态，转变为无需熬夜发布并尝试采用灰度发布的方式。这种转变不仅提升了发布效率，也降低了潜在风险。

最后，我们也期待未来能够借助开发工具的AIGC能力进一步加持无限极的研发效能提升。