大规模团队 DevOps 转型实践
如果无法正常显示，请先停止浏览器的去广告插件。
1. 大规模团队 DevOps 转型实
践
分享人：司玉美
2. 目 录
01 改进背景
02 实施路径
03
主要实践
3. 互联网用户增长放缓，竞争加剧
VUCA 时代，用户拥有更多的选择权，聚焦用户（客户）价值 / 快速适应变化是成功的关键！
4. 共识：小批量是高效交付的基础
自动化技术：
松耦合架构：
•
快速、持续的小批量
代码和部署
完整工具链：
• 需求协作
• Devops 工具链
松
耦
合
架
构
完
整
工
具
链
自
动
化
技
术
MVP ：
•
产品版本规划
需求管理：
•
需求拆分和优先级
MVP
规划
需求
管理
持续
集成
基础设施、组织和文化
度
量
与
可
视
化
持续
部署
• 编译构建
• 静态扫描
• 自动化测试
• 自动化部署
• 自动化发布
度量与可视化：
• 效能度量
• 业务数据
• 运行监控
5. 共识：构建信任是激发团队的基石
团队激励：
团队自管理时效率最高
对自己做出的承诺比别人要求的承诺更认真
员工会尽力做到最好
在强大的压力下努力工作，员工会自然而然地降低对质量的要求
团队绩效：
当成员不被打扰时，工作效率最高
当团队解决自我问题时，提升最快
广泛的、面对面的交流是团队工作最高效方式
团队构建：
团队生产率大于相同数目的个体生产率之和
当不同技能领域的人员组成团队并聚焦于工作时，产品更健壮
Source: Jeff CSM Training
material
6. 构建研发效能管理体系
01 需求协作
03 制品库管 04 代码质量
06 持续集成 07 自动化测 08 环境的准 09 部署运营
02 配置管理
05 测试管理
管理
理
管理
管理
试
备与管理
发布
产品创新
需求和项目管理
基础设施标准化
效能提升落地的主要方向
代码和架构
10 架构
11 数据觉察 12 结果指标
工程实践
7. 效能度量指标
It you can’t measure it, you can’t manage it”
--Peter F. Drucker
8. 业务 DevOps 转型背景
01
部署频率低 + 发布周期长
产品发布周期长（ LT 30 天以
解放生产力 + 低成本试错
研发效能的发展落后于业务的发展速度，
需解放生产力
02
上），需要尽快构筑快速触达
用户能力
。
03
工程师素养 +“ 技术债”的鸿沟
模块 / 组件划分不清晰，耦合程度较高
基础自动能力弱 + 后置的质量
自动化程度低；无效等待时间过长； Bug
反馈弧过长 , Bug 后置
04
研发团队快速增长，工程素养参差不齐
9. DevOps 转型路径—质量的左移和 2 个自动化
总体原则：质量左移，工程自动化和流程自动化
持续部署
和发布
小批量交付
代码质量文
化
基础质量不降低的情况下，提升需求价值流转效率
分阶段：开发负责质量、小批量交付、数据 / 价值驱动
实施原则：基于理想模型，因地制宜制定合适解决方案
通过阶段目标制，促进个人和组织渐进转型
2 个自动化
质量内建
质量前置
人员转型：
开发负责质量：能像测试一样测试验证
开发参与设计：能像产品一样产品思维
开发参与运维：能像运维一样了解数据
10. 主活动流——实施要点
需求
编码
发布：
1. 一键灰度放量
2. Crash 智能分发
3. 特性开关
4. alpla 版本
构建：
1. 归一构建流程
2. 规范 MR 流程
3. 分层分级的 CD
4. QG- 质量红线
5. CI&CD
需求：
1. 需求评审和设计前置
2. 优先级和需求项量化
3. 需求实例化
4. 需求颗粒度拆分
构建
开发：
1. 统一的编码规范
2. 强制 CR 原则
3. 分支管理 & 流程自动化
4. 统一技术栈 / 插件化
5. 自测 & 用例设计
6. 自动化能力建设
7. 特性开关
测试
发布
测试：
1. 缩短测试周期
2. bug 前置到增量
3. 分层用例建设
4. 自动化 & 覆盖率
5. 日 alpha 体验
发布后
发布后：
1. 一键式用户反馈
2. 关键指标分析
3. 缺陷 FST
4. 需求 Leadtime
11. 实践一： FST 驱动缺陷前移，塑造团队持续改善的习惯
基于 FST 实施方案，确认瓶颈环节
FST:
PIQ 缺陷低成本理论
以 PIQ 降低为目标驱动各环节缺陷前移
批量分析，建立缺陷预防和举一反三机制
code review 是有价值的，测试左移是有价值
的
随着版本交付频率的不断加快，团队测试活动向左右两侧移动
12. 实践二：归一主活动的工作流，建立大团队协作节奏
常见场景：
大规模团队协作困难
需求大，习惯大招；
部件依赖多，进度难管理
临时变更多、抱怨多
举措：
优化迭代 Timebox ，共识迭代活动日历
统一需求拆解语言，从 Feature 到 US 需求拆小
基于优先级的协作、基于置换原则的变更管理
数据驱动需求收益量化
研发流程流转自动化
13. 实践三：质量内建在流水线中
覆盖率质量红线：
全量覆盖率 >= 0.5
用例通过率 >= 1
增量覆盖率 >= 0.6
代码检查：
新增 ( 致命 + 错误 ) 问题 <= 0
存量 ( 致命 + 错误 ) 问题 <= 0
圈复杂度阈值 <= 10
敏感信息严重告警数 <= 0
持续集成成功率，从低于 90%
提升至 95%
14. 实践四：减少等待、快速反馈的分支模式演进
2020.05 之前
初始分支模式
2020.05 - 2020.11
过渡模式
2020.11 之后
主干模式
feature/ 团队分支开发 较高频率个人分支开发，开发负责 主干开发，集成发布
，集中合入主干，集成 增量，完成后合入主干，集成测试 高频发版
测试后可发布 后可发布
目标模式：
• 从大功能型 -> 任务型研发模式
• 从阶段大集成到随时集成
• 从手工为主到高度完善的自动化测试
15. 实践五：高频发布的利器—特性开关
特性开关，是业务“频繁发布”能力推进的有力支持
新特性可见控制，将代码集成与功能上线有效隔离
BUG 可以通过开关实时关闭，及时控制风险
按需、高效、有序地对新特性的可见范围进行控制
1. 在满足业务需求的前提下，尽可能少用开关技术
2. 如果在“分支”和“开关”之间选择，尽可能选择开关技术
3. 对开关配置项进行统一管理
4. 尽可能使用统一的开关框架和开发策略
5. 定期清理不必要的开关
16. 实践六： alpha 发布—让体验无处不在
一周开发
一周开发
主干
bugfix
发布分
支
Alpha
版
集成测试
灰度放量
Beta 版
Alpha 版， 1 天发版 1-3 次
Git
Release 版
Build
Beta 版， 1 周发版 1-3 次
For 内部员工，测试为主
For 内部员工 + 热心用户群
持续发版
Release 版， 1-2 周发版一次 For 所有用户
17. 改进——我们在路上
每月 BUG 数降低 70% ， Bug 率降低 60%
需求吞吐量同比提升 40%
需求 Leadtime 降低到 10 天内
18. 改进——协作
能不能有点靠
谱的设计 ?
这个问题是测
试漏测
P0 用例自测不
通过，不提测 !
问题和我
没关系
这个设计这样
做似乎更好 ?
不定稿不开发
!
需求变更又不
知会测试 !
v
s
这个问题是我们没
有给回归建议
又加需求了 ! 这部分开发完了，
先测试下
我的任务完成了
啊 ? 测试给了很多
给力的帮助
这个设计思路，
开发同学看看 ?
这个用户体验不
够好
优先级可否
调整下
他那边事情多，
我来搞定
19. 一个 Feature 从开发到上线的关键路径上， 除了功能开发之外的时间，要尽
量短。不改变现有流程，以及人的行为习惯，实施 DevOps ， 本身就是不现实的
！
机制改变行为，行为改进文化！
——DevOps 三剑客