软件研发效能 2025 中国年度调查报告
益语智库 · 2026-03-10
报告显示，中国软件研发效能已经进入“泛 DevOps”阶段：高效能团队并非只在单点工具上领先，而是在度量体系、工程实践、CI/CD、DevSecOps、BizDevOps 与 LLM 应用深度上形成系统性优势。
---
title: 软件研发效能 2025 中国年度调查报告
publisher: 南京大学软件研发效能实验室 / 全国信息技术标准化技术委员会软件与系统工程分技术委员会（TC28/SC7）
date: 2026-03-10
summary: 报告显示，中国软件研发效能已经进入“泛 DevOps”阶段：高效能团队并非只在单点工具上领先，而是在度量体系、工程实践、CI/CD、DevSecOps、BizDevOps 与 LLM 应用深度上形成系统性优势。
topics: [组织, 业务设计, AI 技术]
---
# 软件研发效能 2025 中国年度调查报告
## 报告速览
这份报告延续南京大学软件研发效能实验室自 2016 年发起的“DevOps 中国年度调查”，并在 2023 年升级为“软件研发效能中国年度调查”的研究脉络。报告以非盈利、厂商中立为立场，结合 GB/T 42560-2023《系统与软件工程 开发运维一体化 能力成熟度模型》（DOMM 国标），观察中国软件与 IT 组织在研发效能、DevOps、DevSecOps、CI/CD、BizDevOps 与 LLM 赋能方面的实践状态。
报告最核心的判断是：**软件研发效能已经从“有没有 DevOps 工具”进入“是否能把度量、流程、质量、安全、业务价值和智能化能力连成闭环”的阶段**。高效能团队的优势不只体现在单一指标，而是贯穿质量、交付、可靠性、安全、需求管理、过程改进和智能化应用。==**高效能团队平均覆盖 7.6 项研发效能指标，一般效能组仅覆盖 3.2 项；差异背后是管理体系、工程实践和反馈机制的整体差距。**==
报告还呈现出三个重要趋势：第一，组织规模越大，研发效能度量越全面，万人级组织中 **72.73%** 已覆盖 30 个以上端到端度量指标；第二，CI/CD、DevSecOps 和 BizDevOps 的推进已经进入深水区，挑战从“工具建设”转向“组织协同、流程闭环和安全自动化”；第三，LLM 已明显进入 DevOps 左侧阶段，尤其是需求、设计、编码、测试等环节，但在部署、维护、运维等后端阶段仍处于早期探索。
| 维度 | 报告给出的主要判断 | 关键数据 |
|---|---|---:|
| 研发效能度量 | 高效能团队覆盖指标更多，管理体系更完整 | 高效能组平均覆盖 **7.6** 项；一般效能组 **3.2** 项 |
| 组织规模 | 组织越大，度量越全面 | 万人级组织中 **72.73%** 采用超 30 个指标 |
| CI/CD | 基础流水线建设已有较广基础，但高阶反馈能力不足 | **40%** 已达到基本建设阶段 |
| DevSecOps | 安全整合是方向，但流程、技术和团队协作仍是障碍 | **40%** 处于“尝试整合但有问题”阶段 |
| BizDevOps | 仍在初期探索，业务侧参与能力不足 | 已全面实现并形成体系的组织约 **15.8%** |
| LLM 赋能 | 主要集中在开发前期，后端阶段应用不足 | 编码阶段应用 **90%**，部署/维护阶段仅 **18%** |
| LLM 效能 | 多数团队认为 LLM 已带来可感知提升 | **60%** 认为效能提升超过 20% |
## 核心问题
报告并不是单纯盘点 DevOps 工具采用率，而是围绕“如何把软件研发活动从交付代码推进到持续交付价值”展开。它试图回答的问题，可以分成七组。
| 核心问题 | 对应讨论 | 报告中的观察方向 |
|---|---|---|
| 中国软件研发效能的成熟度如何衡量？ | DevOps 研发效能度量 | 端到端度量、持续集成成功率、缺陷逃逸率、需求交付周期、服务可用率等 10 项指标 |
| 高效能团队和一般团队的差距在哪里？ | 度量指标、实践能力域、工程实践对比 | 高效能团队在质量、交付、可靠性、安全和需求管理上形成全方位优势 |
| DevOps 实践是否已经体系化？ | DevOps 研发效能实践 | 过程改进、基础设施、产品研发、项目管理、服务管理、支持保障六大能力域 |
| CI/CD 流水线建设推进到哪一步？ | CI/CD 建设现状和挑战 | 基本流水线覆盖较广，但持续反馈、个人能力、技术更新和组织习惯仍是瓶颈 |
| DevSecOps 能否支撑可信软件与供应链安全？ | 软件代码可信、供应链可信、安全测试 | AI 代码监管加强，开源组件库建设推进，但安全自动化不足 |
| BizDevOps 是否真正连接业务和技术？ | BizDevOps 探索与挑战 | 高效能组更主动，一般效能组仍处于认知或初步尝试阶段 |
| LLM 是否已经改变 DevOps？ | LLM 投入、阶段、效果和挑战 | LLM 已深度进入需求与编码阶段，但落地挑战首先是过程转型，而非单纯技术研发 |
## 核心结论
### 结论一：高效能团队的优势是体系化优势，不是单点工具优势
报告根据受访者是否度量并观测 10 项研发效能指标，计算其选中指标数量并排序。选中指标数位于前 50% 的受访者归为“高效能组”，其余归为“一般效能组”。这一分组方法让报告能够比较“效能意识、度量能力和工程实践”之间的关系。
| 分组 | 平均指标覆盖数 | 指标覆盖率最高项 | 指标覆盖率最低项 |
|---|---:|---|---|
| 高效能组 | **7.6** | 服务可用率 | 配置漂移率 |
| 一般效能组 | **3.2** | 缺陷修复时效 | 端到端度量 |
```chart
type: bar
title: 高效能组与一般效能组平均指标覆盖数
unit: 项
x: 高效能组, 一般效能组
y: 7.6, 3.2
```
高效能团队的领先不只是覆盖更多指标，还体现在每一类关键指标上的成熟度。报告指出，高效能团队的端到端质量度量达到 **92%**，缺陷逃逸率控制达到 **80%**，持续集成成功率达到 **88%**，服务可用率达到 **96%**，需求交付周期达成率达到 **90%**。
```chart
type: hbar
title: 高效能团队关键研发效能指标覆盖情况
unit: %
x: 服务可用率, 端到端质量, 需求交付周期达成率, 持续集成成功率, 平均修复时间, 缺陷修复验证时效, 缺陷逃逸率控制, 计划偏差检出率, 安全事件频率控制, 生产环境配置正确率
y: 96, 92, 90, 88, 88, 84, 80, 76, 72, 60
```
> 这些数据说明，高效能团队不是“某一个工具用得好”，而是在质量、交付、可靠性、安全性、需求管理和运维响应上形成连续反馈能力。研发效能的本质，是组织是否能持续看见问题、定位问题、修复问题，并把改进沉淀进流程。
### 结论二：组织规模越大，研发效能度量越全面；小组织存在明显认知缺口
报告指出，多数组织采用高密度度量指标体系，**40%** 的组织拥有超过 30 个端到端度量指标。组织规模与度量指标数量呈正相关，万人级组织中 **72.73%** 覆盖“需求 → 上线 → 运营”全链路的端到端度量指标。20 人以下组织存在 **33.33%** 的度量认知缺失，即回答“不清楚”相关度量。
```chart
type: bar
title: 研发效能度量现状关键数据
unit: %
x: 关注端到端全链路度量, 团队持续集成成功率≥98, 大型组织采用超30个指标, 小型组织指标认知缺失
y: 70, 35, 72.7, 33.3
```
从组织规模分布看，受访者主要来自 **20-99 人组织（28%）** 和 **10000 人以上组织（26%）**，形成中小型灵活团队与超大型成熟组织并存的样本结构。
```chart
type: bar
title: 受访组织规模分布
unit: %
x: 20人以下, 20-99人, 100-499人, 500-999人, 1000-9999人, 10000人以上
y: 10, 28, 20, 2, 14, 26
```
> 度量体系越完整，组织越容易形成跨阶段、跨团队、跨角色的共同事实。小组织的问题不只是没有工具，而是对“应该度量什么、如何用数据推动改进”缺少清晰认识。
### 结论三：DevOps 实践成熟度与度量表现高度相关
报告将研发效能实践能力映射到《开发运维一体化成熟度模型》，覆盖 11 项关键实践与 6 大能力域。数据表明，受访者在实践能力与度量指标上的表现高度吻合，团队的度量指标得分与研发效能实践成熟度呈显著正相关。
| 分组 | 占比 |
|---|---:|
| 度量与实践双优 | **84%** |
| 实践优异 | **8%** |
| 度量优异 | **8%** |
```chart
type: pie
title: 度量表现与实践成熟度关系
unit: %
x: 度量与实践双优, 实践优异, 度量优异
y: 84, 8, 8
```
从六大能力域看，高效能组全面领先一般效能组，其中产品研发、支持和保障、项目管理是整体成熟度相对更高的领域；过程改进、基础设施、服务管理仍是一般组织容易出现短板的部分。
```chart
type: hbar
title: 研发效能实践能力域组间对比
unit: 分
x: 过程改进-高效能组, 过程改进-一般效能组, 基础设施-高效能组, 基础设施-一般效能组, 产品研发-高效能组, 产品研发-一般效能组, 支持和保障-高效能组, 支持和保障-一般效能组, 项目管理-高效能组, 项目管理-一般效能组, 服务管理-高效能组, 服务管理-一般效能组
y: 3.13, 0.97, 3.12, 1.24, 3.84, 1.31, 3.75, 1.39, 3.72, 1.96, 3.1, 1.27
```
> 高效能团队的实践成熟度不是抽象能力，而是可被观察的流程、制度、工具链、质量门禁、安全机制和持续改进机制。
### 结论四：CI/CD 已进入基础普及阶段，但最大瓶颈是人和组织能力
持续交付流水线建设方面，**40%** 的受访组织已达到基本建设阶段，能够实现自动化构建、测试和部署；**30%** 完善企业内部流水线并延伸至持续监控、持续反馈与改进；**20%** 尝试搭建流水线但只完成部分阶段自动化；**10%** 尚未开展建设。
```chart
type: pie
title: 持续交付流水线建设状态
unit: %
x: 尚未开展建设, 部分阶段自动化, 基本流水线建设, 完善内部流水线
y: 10, 20, 40, 30
```
开发策略上，分支开发占据主流。报告显示，**60%** 采用分支开发，**30%** 采用主干开发，最主流模式是 **分支开发 + 主干���布模式（35%）**。
```chart
type: bar
title: 开发策略对比
unit: %
x: 分支开发, 主干开发, 分支开发+主干发布模式
y: 60, 30, 35
```
但在持续集成实践挑战上，技术不是唯一问题。半数受访者认为**专业知识不足和技术更新能力欠缺**是最大瓶颈；低效能团队关注基础建设、流程缺失和标准不明，高效能团队则开始关注长期健康、规模化和技术债务。
```chart
type: hbar
title: 持续集成效能的主要挑战
unit: %
x: 个人能力, 度量与分析, 人员管理, 最佳实践实施, 自动化与工具支持, 组织文化, 项目管理, 其他
y: 50, 42.86, 42.86, 35.71, 28.57, 28.57, 28.57, 7.14
```
自动化或智能化技术在持续集成中的应用也受制于组织习惯。**28.57%** 的受访者认为人员习惯难以改变是主要阻碍，高于缺乏自主研发能力、流程复杂性等因素。
```chart
type: hbar
title: 持续集成中应用自动化或智能化技术的主要阻碍
unit: %
x: 人员习惯难以改变, 缺乏自主研发能力, 流程复杂性, 缺乏第三方可用技术
y: 28.57, 21.43, 21.43, 14.29
```
### 结论五：DevSecOps 已成为方向，但安全自动化和治理闭环仍不足
DevSecOps 部分显示，AI 生成代码正在成为新的可信治理对象。**41.94%** 的组织会对 AI 生成代码施加更多安全检查、抄袭检测、工作量评估等保障措施；**35.48%** 当前尚未采取额外措施，但未来会采取相应举措；**12.90%** 将 AI 代码视作与人类编写代码一样；**9.68%** 会将 AI 生成代码与人类代码区分出来。
```chart
type: pie
title: 组织对 AI 生成代码采取的措施
unit: %
x: 更多安全检查和保障措施, 未来会采取措施, 视作和人类代码一样, 与人类代码区分
y: 41.94, 35.48, 12.9, 9.68
```
架构治理方面，制定规范和标准的比例较高，但自动化、工具化和可视化不足。创建详细设计和开发规范的比例为 **68.18%**，制定统一架构标准和原则为 **63.64%**，进行架构依赖分析为 **59.09%**；但采用架构治理工具只有 **31.82%**，可视化架构治理过程和结果只有 **27.27%**，仍有 **31.82%** 缺少架构治理体系。
```chart
type: hbar
title: 架构治理方法采用情况
unit: %
x: 创建详细设计和开发规范, 制定统一架构标准和原则, 进行架构依赖分析, 采用架构治理工具, 缺少架构治理体系, 可视化架构治理过程和结果
y: 68.18, 63.64, 59.09, 31.82, 31.82, 27.27
```
软件供应链可信方面，**62.5%** 的受访者确认所在组织已建立内部可信开源组件库。第三方库依赖冲突处理上，组织更倾向于通过公开外部渠道自主解决问题，**61.11%** 选择搜索引擎��索，**55.56%** 选择工作群里询问，**50%** 会手动不断尝试，**50%** 依赖公司提供冲突解决方案。
```chart
type: hbar
title: 第三方库依赖冲突应对方式
unit: %
x: 搜索引擎检索, 工作群里询问, 手动不断尝试, 公司提供冲突解决方案, 很少或不会遇到依赖冲突, 其他
y: 61.11, 55.56, 50, 50, 38.89, 5.56
```
安全整合的成熟度仍不高。**40%** 的受访者选择“尝试整合，但有问题”，说明 DevOps 安全整合已成为多数组织方向，但流程衔接、技术实施或团队协作仍存在明显障碍。安全测试方面，**73.33%** 表示只是部分集成安全测试工作，且仍需要人工执行；完全自动化的安全测试只有 **13.33%**。
```chart
type: pie
title: 软件研发流程与安全测试工作的结合程度
unit: %
x: 不进行或独立执行, 部分集成但需人工执行, 完全集成且自动化
y: 13.33, 73.33, 13.33
```
应用安全性的主要挑战中，**迭代速度优先于安全**占比最高，为 **60%**；“执行不到位”和“发现问题不全面”均为 **40%**；安全要求不明确、资源投入不足、发现问题不及时均为 **20%**。
```chart
type: hbar
title: 应用安全性上的主要挑战
unit: %
x: 迭代速度优先于安全, 执行不到位, 发现问题不全面, 安全要求不明确, 资源投入不足, 发现问题不及时, 不清楚如何保障安全
y: 60, 40, 40, 20, 20, 20, 0
```
### 结论六：BizDevOps 仍处于初期探索，但高效能组更主动连接业务价值
BizDevOps 被报告称为 DevOps 2.0，它以 DevOps 成功实践为基础，把业务团队和业务目标纳入软件开发生命周期的每个阶段。整体上，**42.1%** 的组织已引入 DevOps 但尚不了解 BizDevOps，**21.1%** 已引入 DevOps 并计划推进 BizDevOps，**21.1%** 正在小规模试验，只有 **15.8%** 已全面实现 BizDevOps 实践并形成体系。
```chart
type: pie
title: BizDevOps 实践成熟度
unit: %
x: 已引入DevOps但不了解BizDevOps, 已引入DevOps计划推进, 小规模试验中, 全面实现并形成体系
y: 42.1, 21.1, 21.1, 15.8
```
高效能组与一般效能组差异明显：高效能组不了解 BizDevOps 的占比为 **28%**，计划推进/试验占比 **50%**，全面融入实践占比 **22%**；一般效能组不了解占比高达 **55%**，全面融入实践只有 **10%**。
| 分组 | 不了解 BizDevOps 占比 | 计划推进 / 试验占比 | 全面融入实践占比 |
|---|---:|---:|---:|
| 高效能组 | 28% | 50% | 22% |
| 一般效能组 | 55% | 35% | 10% |
推进 BizDevOps 的最大挑战是业务团队缺乏技术参与能力，比例为 **31.6%**；其次是业务商业价值目标和技术团队 KPI 不一致，比例为 **23.7%**；组织缺乏流程、体系或机制来协调业务、开发、运维三者形成反馈闭环，占 **15.8%**。
```chart
type: hbar
title: 推进 BizDevOps 的主要挑战
unit: %
x: 业务团队缺乏技术参与能力, 业务目标与技术KPI不一致, 缺乏流程体系机制形成反馈闭环, 数据不能对应难以互通联系, 缺乏标准最佳实践和生态环境, 沟通协作困难缺乏文化共识
y: 31.6, 23.7, 15.8, 10.5, 10.5, 7.9
```
非技术人员参与 DevOps 的方式仍偏人工协调：**36.8%** 通过同步工具、定期会议或指定对接人参与，**34.2%** 使用自动化工具（如低代码平台），**28.9%** 通过文档、演示或试用测试版本了解进展。
```chart
type: pie
title: 非技术人员参与 DevOps 的方式
unit: %
x: 同步工具/会议/指定对接人, 自动化工具如低代码平台, 文档演示或试用测试版本
y: 36.8, 34.2, 28.9
```
> BizDevOps 的难点不是“让业务知道开发进度”，而是让业务目标、技术活动、数据反馈和价值验证进入同一条闭环。
### 结论七：LLM 已进入 DevOps，但主要集中在左侧阶段；落地挑战首先是过程转型
LLM 赋能 DevOps 已经成为报告的核心新议题。高效能组平均 DevOps 阶段覆盖数为 **3.76**，一般效能组为 **3.20**。高效能组和一般效能组的覆盖率最高项都是编码阶段，但高效能组编码阶段覆盖率达到 **96%**，一般效能组为 **84%**；最低项分别为维护阶段 **16%** 和运维阶段 **16%**。
```chart
type: bar
title: LLM 应用的平均 DevOps 阶段覆盖数
unit: 个
x: 高效能组, 一般效能组
y: 3.76, 3.20
```
从具体阶段看，LLM 已深度融入软件开发左侧阶段。编码阶段使用比例 **90%**，需求阶段 **64%**，测试阶段 **50%**，设计阶段 **44%**，构建阶段 **40%**；部署和维护阶段均为 **18%**，运维阶段为 **24%**。
```chart
type: hbar
title: DevOps 各阶段使用 LLM 的比例
unit: %
x: 编码阶段, 需求阶段, 测试阶段, 设计阶段, 构建阶段, 运维阶段, 部署阶段, 维护阶段
y: 90, 64, 50, 44, 40, 24, 18, 18
```
效能提升方面，**44%** 的效能组认为 LLM 带来 **20%-30%** 的提升，**34%** 认为提升 **10%-20%**，**16%** 认为提升 **30%-50%**，**4%** 认为小于 10%，**2%** 没有感受到可度量的提升。报告进一步总结：**60%** 的效能组认为 LLM 为研发侧带来了超过 20% 的效能提升。
```chart
type: pie
title: 采用 LLM 对研发效能的提升感知
unit: %
x: 20%-30%, 10%-20%, 30%-50%, 小于10%, 没有可度量提升
y: 44, 34, 16, 4, 2
```
LLM 的使用方式仍以人为中心。**80%** 的团队采用“人工为主、LLM 为辅”，**14%** 采用“LLM 为主、人工为辅”，**4%** 仅在人工困难时使用 LLM，**2%** 基本不使用。
```chart
type: pie
title: 使用 LLM 的倾向
unit: %
x: 人工为主LLM为辅, LLM为主人工为辅, 人工困难再使用LLM, 基本不使用LLM
y: 80, 14, 4, 2
```
LLM 应用挑战中，过程转型占 **38%**，技术研发占 **30%**，人员适应占 **18%**，导入成本占 **12%**，其他（如信息安全）占 **2%**。这意味着 LLM 落地不是单纯购买工具或调用模型，而是需要重构研发流程、角色分工、质量机制、安全机制和协作方式。
```chart
type: hbar
title: 大语言模型应用挑战
unit: %
x: 过程转型, 技术研发, 人员适应, 导入成本, 其他如信息安全
y: 38, 30, 18, 12, 2
```
==**报告最值得注意的一点是：引入 LLM 的最大挑战不是技术本身，而是“过程转型”。**== 这与用户在平台化、智能化研发管理中的真实经验高度一致：AI 工具只有嵌入业务流程、工程标准、团队协作和数据闭环，才能成为生产力。
## 方法 / 指标体系
### 研究背景与调查定位
报告说明，南京大学软件研发效能实验室自 2016 年在国内率先发起“DevOps 中国年度调查”，并持续发布年度报告；2023 年升级为“软件研发效能中国年度调查”。2025 年调查继续由南京大学软件研发效能实验室组织，并与全国信标委软件与系统工程分委会（TC28/SC7）合作开展。
本次问卷一方面聚焦软件研发效能前沿主题，另一方面将 GB/T 42560-2023《系统与软件工程 开发运维一体化 能力成熟度模型》的核心内容和要求纳入其中，并更新安全、大语言模型与智能化技术等热点议题。
| 项目 | 内容 |
|---|---|
| 调查延续 | 2016 年发起 DevOps 中国年度调查，2023 年升级为软件研发效能中国年度调查 |
| 组织方 | 南京大学软件研发效能实验室 |
| 合作方 | 全国信标委软件与系统工程分委会（TC28/SC7） |
| 标准背景 | GB/T 42560-2023《系统与软件工程 开发运维一体化 能力成熟度模型》 |
| 主题范围 | 研发效能、DevOps、CI/CD、DevSecOps、BizDevOps、LLM 赋能 DevOps、优秀案例 |
| 基本立场 | 非盈利、厂商中立、客观公正 |
### 受访者行业与组织画像
受访者主要集中在软件研发活跃、数字化程度高、技术密集型行业。基础软件/平台与互联网合计接近半数，金融服务与通信行业也保持较高投入。
```chart
type: pie
title: 受访者行业分布
unit: %
x: 基础软件/平台, 互联网, 金融服务, 通信, 教育, 政府或事业单位, 工业制造, 零售
y: 26.1, 26.1, 15.2, 15.2, 8.7, 4.3, 2.2, 2.2
```
> 报告页面中的结论性文字将基础软件/平台与互联网概括为各约 24%；页面饼图标注显示两类均为 26.1%。本稿图表采用饼图标注值，并在文字中使用“约四分之一、合计接近半数”的表述。
组织安全人员规模呈现两极化：**1-5 人安全团队占 38%**，是最常见配置；**20 人以上安全团队占 32%**，显示大型企业或高安全要求行业已有战略性安全投入；仍有 **10%** 组织没有专门安全人员。
```chart
type: bar
title: 安全人员规模分布
unit: %
x: 0人, 1-5人, 5-10人, 10-20人, 20人以上
y: 10, 38, 16, 4, 32
```
### 研发效能度量指标体系
报告列出 10 项研发效能指标，分别覆盖研发过程效能、产品质量效能和运行稳定效能等方面。
| 编号 | 指标 | 主要效能类型 | 定义 | 计算方式 |
|---|---|---|---|---|
| A | 端到端度量 | 研发过程效能 | 覆盖“需求 → 上线 → 运营”全链路的综合度量 | 描述性汇总，如覆盖度、完整性等 |
| B | 持续集成成功率 | 研发过程效能 | 持续集成任务的整体通过情况 | 持续集成通过次数 / 持续集成总次数 × 100% |
| C | 生产配置漂移率 | 运行稳定效能 | 生产实际配置与基线配置偏离程度 | （生产实际配置项数 - 基线配置项数）/ 基线配置项数 × 100% |
| D | 修复验证时效 | 产品质量效能 | 从修复提交到验证通过的平均时长 | 平均（验证通过时间 - 修复提交时间） |
| E | 缺陷逃逸率 | 产品质量效能 | 测试阶段未拦截而流入生产的缺陷比例 | 生产环境缺陷数量 / 测试阶段缺陷数 × 100% |
| F | 安全事件频率 | 运行稳定效能 | 单位运行时长内发生的安全事件次数 | 发生安全事件次数 / 系统运行总时长（月） |
| G | 计划偏差检出率 | 产品质量效能 | 对计划偏差的发现覆盖程度 | 已检出计划偏差数量 / 实际发生计划偏差总数 × 100% |
| H | 需求交付周期 | 研发过程效能 | 从需求提出到交付的平均时长 | Σ（需求交付时间 - 需求提出时间）/ 需求总数 |
| I | 服务可用率 | 运行稳定效能 | 服务在承诺时段内保持可用的比例 | 实际服务可用时长 / 承诺可用时长 × 100% |
| J | 平均修复时间 | 运行稳定效能 | 从问题发生到恢复的平均时间 | 总解决时间 / 解决问题总数 |
### 研发效能实践能力体系
报告将 DevOps 研发效能实践映射到 DOMM 能力模型，涵盖 11 项关键实践。
| 编号 | 能力 | 所属能力域 | 定义 | 对应度量指标 |
|---|---|---|---|---|
| A | 效能管理 | 过程改进 | 通过数据度量和分析，持续提升组织效能、实现业务目标 | 端到端度量指标 |
| B | 系统与工具支撑 | 基础设施 | 为软件活动提供工具和平台，以自动化执行、促进协作与持续改进 | 工具链集成稳定性 |
| C | 环境支撑 | 基础设施 | 保障开发运维一体化顺利实施，提供并持续优化软件运行环境供给 | 故障恢复时效 |
| D | 过程质量保障 | 支持和保障 | 客观验证并改进已执行过程和工作产品质量 | 缺陷逃逸率 |
| E | 配置管理 | 支持和保障 | 通过配置与变更管理保障产物完整并确保交付版本正确可信 | 生产环境配置漂移率 |
| F | 测试 | 产品研发 | 验证软件服务满足需求，持续测试确保产品符合预期用途并减少偏差 | 缺陷修复验证时效 |
| G | 持续集成和交付 | 产品研发 | 通过自动化持续构建、集成、测试和部署确保产品随时可交付上线 | 项目需求平均交付周期 |
| H | 安全管理 | 支持和保障 | 加强安全管理能力，确保组织响应安全合规并交付可信产品 | 安全事件发生率 |
| I | 监控与调整 | 项目管理 | 理解项目进度，及时纠偏提高目标达成可能性 | 计划偏差检出率 |
| J | 服务监控 | 服务管理 | 监控服务状态，及时纠偏确保服务正常运行 | 问题解决时效性 |
| K | 服务连续性 | 服务管理 | 制定维护计划，确保服务正常运营、避免中断、保持连续性 | SLA 达成率 |
## 01 受访者概况
### 行业与岗位：样本集中于软件研发活跃领域
从行业看，基础软件/平台和互联网构成本次调研的主要覆盖行业；金融服务与通信行业也显示出较高软件研发投入。报告认为，这一行业分布代表了中国当前软件研发较活跃的领域。
从岗位看，样本覆盖开发、测试、需求、架构、运维、算法、安全、管理等关键角色。报告特别强调，调研样本包含研发一线人员和管理者，有助于同时从工程执行与组织治理视角理解研发效能现状。
| 画像维度 | 主要发现 | 管理含义 |
|---|---|---|
| 行业集中度 | 基础软件/平台与互联网合计接近半数 | 研发效能首先在技术密集型行业形成显性需求 |
| 金融与通信 | 金融服务、通信均为 15.2% | 高合规、高稳定性行业对研发效能投入持续 |
| 组织规模 | 20-99 人与 10000 人以上组织占比较高 | 样本兼具中小团队灵活性与大型组织成熟度 |
| 安全投入 | 1-5 人安全团队与 20 人以上安全团队并存 | 安全建设呈两极化，中度安全能力层薄弱 |
### 安全人员配置：基础小团队和大型安全部门并存
安全人员规模分布表明，中国软件研发组织在安全投入上存在明显分化：很多组织已经配备最基础安全人员，但也有较多大型组织形成成熟安全部门；与此同时，腰部安全能力不足，10% 的组织没有专门安全人员。
```chart
type: pie
title: 安全人员规模结构
unit: %
x: 0人, 1-5人, 5-10人, 10-20人, 20人以上
y: 10, 38, 16, 4, 32
```
> 对 DevSecOps 来说，这种分布意味着行业同时存在两类挑战：一类组织需要从 0 到 1 建立安全责任与基本流程；另一类大型组织则需要把安全能力嵌入研发流水线、供应链治理和 AI 代码治理。
## 02 DevOps 研发效能度量
### 十项指标构成端到端研发效能观测框架
报告把研发效能从单一产出速度扩展到质量、稳定性、安全性和价值交付周期。端到端度量不只是看某个环节，而是看“需求 → 上线 → 运营”全链路是否可见、可控、可优化。
| 指标类别 | 代表指标 | 关注的问题 |
|---|---|---|
| 研发过程效能 | 端到端度量、持续集成成功率、需求交付周期 | 需求从提出到交付是否顺畅，集成是否稳定 |
| 产品质量效能 | 修复验证时效、缺陷逃逸率、计划偏差检出率 | 缺陷是否被及时发现、修复和验证 |
| 运行稳定效能 | 生产配置漂移率、安全事件频率、服务可用率、平均修复时间 | 上线后的系统是否稳定、安全、可恢复 |
### 规模越大，度量越全面
组织规模与指标覆盖数量呈正相关。万人级组织中 **72.73%** 采用超过 30 个指标；20 人以下组织中 **33.33%** 回答“不度量 / 不清楚”，说明小型组织在度量认知上仍存在缺口。
| 组织规模 | 指标数量覆盖特征 |
|---|---|
| 20 人以下 | 约 67% 覆盖大于 30 个指标，但 33% 不度量 / 不清楚 |
| 20-99 人 | 指标覆盖分布较分散，15-30 个占比较高 |
| 100-499 人 | 5-15 个与 15-30 个指标较多，超过 30 个占 25% |
| 500-999 人 | 图示全部为大于 30 个指标 |
| 1000-9999 人 | 15-30 个指标占 75%，超过 30 个占 25% |
| 10000 人以上 | 超过 30 个指标占 73%，不度量 / 不清楚占 18% |
> 报告对不同规模组织的图表存在分段显示，部分百分比为图上标注值。整体趋势明确：组织规模越大，越倾向建立完整端到端度量体系。
### 高效能团队的领先是全方位的
高效能团队在端到端质量、缺陷逃逸、持续集成、配置正确性、修复验证、安全事件、计划偏差、需求周期、服务可用率和平均修复时间方面均明显优于一般团队。
| 维度 | 高效能团队表现 | 报告解释 |
|---|---:|---|
| 端到端质量 | 92% | 测试覆盖、质量门禁与持续集成质量保障更完善 |
| 缺陷逃逸率控制 | 80% | 能降低生产环境缺陷比例 |
| 持续集成成功率 | 88% | 构建、集成、测试流程更稳定 |
| 生产环境配置正确率 | 60% | 配置管理体系更规范 |
| 缺陷修复验证时效 | 84% | 问题响应更快 |
| 安全事件频率控制 | 72% | 安全治理审查与监测更严格 |
| 计划偏差检出率 | 76% | 项目监控与纠偏机制更成熟 |
| 需求交付周期达成率 | 90% | 需求澄清、优先级管理与节奏控制更成熟 |
| 服务可用率 | 96% | 运维可靠性保障更强 |
| 平均修复时间 | 88% | 故障响应和恢复能力更强 |
## 03 DevOps 研发效能实践
### 实践覆盖已经趋于体系化
报告在每个能力域中识别“最高占比实践”。多数最高占比实践的覆盖率在六成以上，说明行业已经具备流程规范、工具支撑、质量管理、项目治理等基础能力。
| 能力域 | 能力 | 最高占比实践 | 占比 |
|---|---|---|---:|
| 过程改进 | 效能管理 | 从组织业务目标出发，对效能目标进行识别和定义 | 62% |
| 基础设施 | 系统与工具支撑 | 为 DevOps 各能力实践提供适用工具支撑 | 62% |
| 基础设施 | 环境支撑 | 识别并满足环境的自动化供给需求 | 58% |
| 产品研发 | 测试 | 编制测试计划以指导测试工作 | 66% |
| 产品研发 | 持续集成和交付 | 建立实践标准和规范，并保持更新 | 64% |
| 支持和保障 | 过程质量保障 | 根据标准客观评价选定过程和工作产品 | 68% |
| 支持和保障 | 配置管理 | 对项目活动关键产出执行版本控制 | 68% |
| 支持和保障 | 安全管理 | 开展安全合规相关教育培训 | 64% |
| 项目管理 | 监控与调整 | 管理关键依赖关系和活动，识别并解决问题 | 74% |
| 服务管理 | 服务监控 | 采取纠正措施并跟踪管理 | 62% |
| 服务管理 | 服务连续性 | 建立和维护服务保障优先级 | 66% |
```chart
type: hbar
title: 研发效能实践最高占比实践
unit: %
x: 监控与调整, 过程质量保障, 配置管理, 测试, 服务连续性, 持续集成和交付, 安全管理, 效能管理, 系统与工具支撑, 服务监控, 环境支撑
y: 74, 68, 68, 66, 66, 64, 64, 62, 62, 62, 58
```
### 高成熟度安全实践覆盖不足
安全管理能力呈现出明显特点：低成熟度实践覆盖较高，高成熟度实践覆盖不足。比如，开展安全合规教育培训占 **68%**，而在组织层建立安全风险监测识别机制只有 **34%**，开展专业安全审计活动和在组织层建立安全事件应急响应机制均为 **36%**。
```chart
type: hbar
title: 安全管理各实践比例
unit: %
x: 开展安全合规相关教育培训, 资产活动及软件产品安全合规管理交付运行, 建立研发及生产环境安全标准, 基于安全合规需求开展培训, 全过程贯彻安全合规活动, 识别法规行业要求并更新制度, 建立产品组件安全处理机制, 将安全过程融入DevOps流水线, 建立安全事件应急响应机制, 开展专业安全审计活动, 建立安全风险监测识别机制
y: 68, 62, 56, 52, 44, 40, 40, 38, 36, 36, 34
```
> 安全实践覆盖率与成熟度等级呈负相关：越高阶、越系统化、越需要组织级机制的安全实践，实际覆盖率越低。
## 04 CI/CD 流水线
### 基本自动化已有基础，但持续反馈仍需提升
CI/CD 部分说明，持续交付流水线基础建设已较广泛。能够自动化构建、测试和部署的基本建设阶段占 **40%**；但完善到持续监控、持续反馈与改进的组织只有 **30%**。
| 状态 | 占比 | 管理含义 |
|---|---:|---|
| 尚未开展持续交付流水线建设，基本全部由手工完成 | 10% | 仍处于低自动化阶段 |
| 尝试搭建持续交付流水线，但只完成部分阶段自动化 | 20% | 局部自动化，端到端价值尚未形成 |
| 完成基本流水线建设，覆盖自动化构建、测试、部署等环节 | 40% | 已形成基础自动化能力 |
| 完善企业内部流水线，延伸至持续监控、持续反馈与改进 | 30% | 进入高阶持续交付和持续改进阶段 |
### 持续集成的主要瓶颈是能力、知识和实践经验
报告将持续集成效能挑战分为度量与分析、自动化与工具支持、组织文化、人员管理、项目管理、最佳实践实施等类别。最大挑战是个人能力不足，比例为 **50%**。这意味着 CI/CD 的下一阶段不是简单新增工具，而是组织知识体系、技术更新能力和工程文化的建设。
| 挑战类别 | 报告解释 |
|---|---|
| 度量与分析 | 缺乏明确的度量体系和分析框架 |
| 自动化与工具支持 | 缺少质量保证、自动化支持工具和研发效能平台 |
| 组织文化 | 团队氛围、领导决策、同事协作沟通存在问题 |
| 人员管理 | 工作量大、负载重、工作流程复杂 |
| 项目管理 | 追求短期交付造成技术债务累积、救火工作繁重 |
| 最佳实践实施 | 对持续集成等 DevOps 实践认识和应用不足 |
## 05 DevSecOps
### AI 代码治理成为新课题
AI 代码治理的核心不是禁止 AI 生成代码，而是建立可追踪、可检测、可验证、可审计的规则。报告显示，组织已经普遍意识到 AI 代码的特殊性，但治理方式仍处于形成期。
| 措施 | 占比 | 解释 |
|---|---:|---|
| 会施加更多安全检查、抄袭检测、工作量评估等保障措施 | 41.94% | 已建立初步风险防控机制 |
| 当前未采取额外措施，以后会采取相应举措 | 35.48% | 风险意识存在，但机制尚未落地 |
| 视作和人类编写代码一样 | 12.90% | 可能低估 AI 代码特殊风险 |
| 会和人类编写代码区分出来 | 9.68% | 已开始建立来源差异化管理 |
### 软件供应链可信需要从外部搜索转向内部知识沉淀
第三方库依赖冲突处理方式显示，受访组织更依赖搜索引擎、工作群、手动尝试等方式。报告建议组织建立内部知识库，沉淀解决方案，减少重复检索成本。
| 应对方式 | 占比 |
|---|---:|
| 搜索引擎检索 | 61.11% |
| 工作群里询问 | 55.56% |
| 手动不断尝试 | 50% |
| 公司提供冲突解决方案 | 50% |
| 很少或不会遇到依赖冲突 | 38.89% |
| 其他 | 5.56% |
### 安全整合最缺的是自动化和流程闭环
当前安全测试与研发流程的结合仍主要靠人工执行。**73.33%** 的受访者表示安全测试只是部分集成且需要人工执行，只有 **13.33%** 完全集成且自动化安全测试。
> 安全测试如果不能进入 CI/CD 流水线，就容易停留在“上线前检查”或“问题后补救”，很难成为持续交付体系中的内生能力。
## 06 BizDevOps
### BizDevOps 的价值在于从“交付代码”转向“交付价值”
BizDevOps 将业务团队和业务目标纳入软件开发生命周期，要求业务、开发、运维形成共同目标和反馈闭环。报告认为，高效能团队之所以更主动推进 BizDevOps，是因为它们不仅精通技术，更重视技术如何服务业务目标。
| 状态 | 占比 |
|---|---:|
| 已引入 DevOps，但尚不了解 BizDevOps | 42.1% |
| 已引入 DevOps，计划推进 BizDevOps | 21.1% |
| 在小规模试验 BizDevOps 中 | 21.1% |
| 已全面实现 BizDevOps 实践并形成体系 | 15.8% |
### BizDevOps 的最大障碍是业务侧缺乏技术参与方式
推进 BizDevOps 的最大挑战不是技术团队单方面的问题，而是业务团队难以参与技术全过程。报告列出的六类挑战构成了业务技术融合的全景障碍。
| 挑战编号 | 挑战内容 | 占比 |
|---|---|---:|
| A | 业务团队不熟悉具体技术，缺乏低代码工具平台或非技术方法支持参与技术全过程 | 31.6% |
| B | 业务商业价值目标和技术团队 KPI 不一致 | 23.7% |
| C | 组织缺乏流程、体系或机制来协调业务、开发、运维三者形成反馈闭环 | 15.8% |
| D | 业务团队和技术团队平台割裂，数据不能对应，难以互通联系 | 10.5% |
| E | 行业缺乏 BizDevOps 标准、最佳实践，生态环境尚未形成 | 10.5% |
| F | 业务团队和技术团队沟通协作困难，未形成文化和价值共识 | 7.9% |
> BizDevOps 需要的不是更多会议，而是把业务目标、需求流、技术交付、数据反馈和运营结果放进同一套协作机制。
## 07 LLM 赋能 DevOps
### LLM 的应用集中在需求、编码、测试等左侧阶段
报告将 DevOps 阶段拆分为需求、设计、编码、构建、测试、部署、维护、运维。LLM 当前应用明显集中在编码和需求阶段，说明其首先被用于代码生成、文档撰写、测试用例设计等较容易结构化和文本化的任务。
| 阶段 | 使用 LLM 比例 | 典型任务 |
|---|---:|---|
| 编码阶段 | 90% | 代码生成、补全、解释、注释 |
| 需求阶段 | 64% | 文档撰写、需求澄清、需求拆解 |
| 测试阶段 | 50% | 测试用例设计、测试说明生成 |
| 设计阶段 | 44% | 设计文档、方案辅助 |
| 构建阶段 | 40% | 构建脚本、错误定位辅助 |
| 运维阶段 | 24% | 故障响应、知识问答初步探索 |
| 部署阶段 | 18% | 部署说明、脚本辅助 |
| 维护阶段 | 18% | 维护文档、问题分析 |
### 高效能组对 LLM 的投入更深、更主动
在 LLM 投入层级上，高效能组在“正在 / 已经自主开发新的 LLM 及相关工具和服务”中占比 **83.3%**，低效能组仅 **16.7%**。这说明高效能团队更倾向于深度集成和自研，而低效能团队更多停留在第三方服务引入阶段。
| 投入层级 | 高效能组 | 低效能组 |
|---|---:|---:|
| A. 计划直接引入 LLM 的第三方服务 | 40.0% | 60.0% |
| B. 计划基于现有第三方 LLM 开发工具及服务 | 36.4% | 63.6% |
| C. 计划自主开发新的 LLM 及相关工具和服务 | 57.1% | 42.9% |
| D. 正在 / 已经引入第三方服务 | 50.0% | 50.0% |
| E. 正在 / 已经基于现有第三方 LLM 开发工具及服务 | 50.0% | 50.0% |
| F. 正在 / 已经自主开发新的 LLM 及相关工具和服务 | 83.3% | 16.7% |
```chart
type: hbar
title: 高效能组在不同 LLM 投入层级中的占比
unit: %
x: 计划引入第三方服务, 计划基于第三方LLM开发工具, 计划自主开发LLM工具, 已引入第三方服务, 已基于第三方LLM开发工具, 已自主开发LLM工具
y: 40, 36.4, 57.1, 50, 50, 83.3
```
### LLM 的最大挑战是流程、角色和组织协作重构
报告特别强调，过程转型比技术研发挑战更大。这意味着引入 LLM 的组织不能只关注模型能力，而要重新设计开发流程、评审方式、代码质量门禁、测试机制、知识库和人机协作边界。
| 挑战 | 占比 | 实际含义 |
|---|---:|---|
| 过程转型 | 38% | 工作流、标准、审批、评审、质量门禁需要重构 |
| 技术研发 | 30% | 工具集成、模型适配、工程化能力仍是挑战 |
| 人员适应 | 18% | 团队使用习惯、信任边界、技能结构需要改变 |
| 导入成本 | 12% | 工具、算力、集成、培训与管理成本需要评估 |
| 其他，如信息安全 | 2% | 数据安全、代码安全与合规风险仍需管理 |
## 08 优秀企业案例
报告收录多个符合国标要求的 DevOps 优秀案例，这些案例共同呈现了一个方向：研发效能提升已经从“局部工具部署”走向“企业级平台、标准体系、数据度量、AI 赋能和安全合规”的组合工程。
| 案例 | 核心做法 | 关键数据 / 成效 |
|---|---|---|
| 浪潮科技：跨行业研运平台 | 建设企业级一体化研发运维平台，覆盖项目管理、代码管理、CI/CD、自动化流水线、质量门禁、效能洞察、合规审计等八大领域 | 覆盖 10 余条行业线，10 多个重点客户；构建耗时由 34m 降至 5m，降低 **85%**；集成失败率由 18% 降至 1.5%，降低 **91%**；部署自动化率 **99%**；发布失败率由 12% 降至 0.8%，降低 **93%** |
| 云南电网：DOMM 应用落地 | 统一需求管理平台、研发运维管理平台、APM 平台，实现一键镜像构建、一键部署、一站管控 | 服务用电客户 **1800 万户**；传统 2-3 天发布周期缩短至 **2 小时内**；部署成功率 **99.2%**；300+ 指标智能监控；缺陷流转时效提升 **60%**；联调效率提高 **3 倍**；2025 年 7 月通过 DOMM 三级评估 |
| 中国电信：研发云赋能 DevOps | 构建集团统一研发云平台，覆盖敏捷管理、工作协同、持续集成、持续部署、效能度量、科研管理等 | 开发效率和协作效率提升 **20% 以上**；编译构建速度提升 **3 倍**，成功率提升 **25%**；释放 DevOps 支撑人员 **2/3** 人力资源（超 **600 人**）；减少不少于 **20** 个重复平台；年节约成本超 **2 亿元** |
| 长江证券：DevOps 度量改进 | 构建 AI 赋能的度量改进体系，实现数据整合、智能诊断、决策建议三级能力 | 支撑项目超过 **200 个**；需求交付周期 P85 缩短 **36%**；外包质量波动率下降 **63%**；CI/CD 成功率提升至 **98%**；度量改进实施率从 **30%** 提升至 **85%**；驻场开发成本降低 **18%**；需求月吞吐量提升 **120%** |
| 中国联通：AI + DevOps | 自研企业级一站式数智化研发平台，融合 DevOps、智能研发与大模型能力 | 需求开发周期由 **37.73 天** 缩短到 **18.77 天**，缩短 **50.25%**；需求交付及时率由 **58.78%** 提高到 **97.48%**；立项审批时长由 **23.3 天** 降至 **15.5 天**；智能需求助手将需求预评估从 **26.9 小时** 压缩至 **15.73 小时**；AI 代码生成 **362 万行**，节约 **894 人月**，折合约 **1788 万元** |
| 中国人寿：数字化研发变革 | 以效能工具、效能实践、效能度量为三大支柱，构建覆盖协同、编码、构建、测试、部署的自动化体系 | AI 代码助手用于建议、补全和生成基础函数；AI 视觉识别 UI 界面并生成测试用例；推动组织小型化、扁平化和服务模式融合化、精细化 |
| 中国移动：“四共”科技创新研发平台 | 以“共研发管理、共研发平台、共能力中台、共技术栈”为核心，实现全流程工具链集成和 AI 规模化应用 | 覆盖集团约 **60%** 研发单位，支撑 **3.6 万人** 协同；平台自研率超 **90%**；200+ 预置指标；需求交付周期由 **37 天** 降至 **18 天**，提升 **51%**；AI 代码生成占比 **25%**；单元测试覆盖率由 **10%** 提升至 **65%**；发布成功率超 **99%**；代码仓超 **1 万个**，代码行数超 **10 亿**，日均构建超 **5000 次**；年节约 IT 成本超 **1.5 亿元** |
| 嘉为蓝鲸：一站式研发效能 | 提供全生命周期 DevOps 一站式研发效能解决方案，整合 CTeam、CCode、CCI、CPack、CTest、CFlow、CMeas、CAgent | 数据同步效率从“小时级”提升至“分钟级”；故障定位时间从 **4 小时** 压缩至 **30 分钟**；支持金融、制造汽车、政企运营商等场景；兼容信创全栈生态 |
```chart
type: hbar
title: 部分企业案例中的效率提升幅度
unit: %
x: 浪潮构建耗时降低, 浪潮集成失败率降低, 浪潮发布失败率降低, 长江证券外包质量波动率下降, 中国联通需求开发周期缩短, 中国移动需求交付周期缩短, 云南电网缺陷流转时效提升
y: 85, 91, 93, 63, 50.25, 51, 60
```
### 案例共同经验
这些案例虽来自不同领域，但呈现出相似的研发效能升级路径。
| 共性经验 | 具体表现 |
|---|---|
| 以标准为底座 | 多数案例以 DOMM 国标或企业内部成熟度模型为基础，建立统一流程规范和评估标准 |
| 以平台为载体 | 研发效能不再依赖单个工具，而是依托统一研发平台、工作台、工具链和数据链 |
| 以数据为闭环 | 从项目、需求、代码、测试、构建、部署、运维采集多源数据，形成度量、诊断、改进闭环 |
| 以 AI 为加速器 | AI 用于需求拆解、代码生成、单元测试生成、故障定位、风险预测、智能助手等场景 |
| 以安全和合规为边界 | 金融、通信、能源、政企场景普遍强调质量门禁、安全扫描、审计日志、权限管控和供应链安全 |
| 以业务价值为目标 | 成功案例不只提升研发速度，还指向成本节约、交付及时率、故障恢复、业务响应和客户服务质量 |
> 从案例看，真正产生规模化成效的不是“单点 AI 工具”，而是“标准 + 平台 + 数据 + AI + 安全”的组合能力。AI 只有进入研发平台和流程闭环，才能成为可管理、可度量、可复制的效能提升力量。
## 结语 / 启示
### 1. 研发效能正在从工具问题变成组织能力问题
报告的整体数据说明，中国软件研发组织已经普遍意识到 DevOps、CI/CD、自动化、质量门禁、安全治理和 LLM 的价值。接下来的关键不是“要不要上工具”，而是组织能否建立一套可以持续运行的研发效能系统：有指标、有流程、有责任、有数据、有复盘、有改进。
### 2. 高效能团队的本质是端到端可见、可控、可改进
高效能团队平均覆盖 7.6 项关键指标，并在服务可用率、需求交付、持续集成、缺陷修复、安全事件等多个维度领先。它们的能力不是单点优化，而是把需求、开发、测试、部署、运维、安全、业务价值放入同一个反馈系统。
### 3. LLM 将放大研发效能差距
报告显示，高效能团队不仅更广泛使用 LLM，还更愿意进行深层投入，特别是在自主开发 LLM 工具与服务方面明显领先。未来 LLM 可能进一步拉开高效能组织和一般组织之间的差距：前者会把 LLM 变成研发体系的一部分，后者则可能停留在零散使用和个人效率提升层面。
### 4. DevSecOps 和 BizDevOps 是下一阶段的关键短板
DevSecOps 的瓶颈在于安全自动化、供应链治理、AI 代码风险管理和安全测试前移；BizDevOps 的瓶颈在于业务侧如何真正参与技术过程、业务目标如何与技术 KPI 对齐、业务数据如何与研发数据互通。这两个方向共同指向一个问题：研发效能不能只在技术部门内部循环，必须进入组织治理和业务价值系统。
### 5. 对组织管理者而言，下一步应关注四类建设
| 建设方向 | 关键动作 |
|---|---|
| 研发效能度量体系 | 建立覆盖需求、开发、测试、部署、运维、安全的端到端指标体系，避免只看局部效率 |
| 工程实践平台化 | 把 CI/CD、质量门禁、配置管理、制品管理、安全扫描和效能洞察整合为统一平台 |
| AI 工作流嵌入 | 不只引入 LLM 工具，而是重设需求拆解、代码生成、测试生成、评审、发布与运维流程 |
| 业务技术闭环 | 推进 BizDevOps，让业务目标、研发过程、上线效果和运营反馈形成同一条价值链 |
==**这份报告最重要的启示是：软件研发效能不是“更快写代码”，而是组织能否把技术交付变成稳定、可信、可持续改进的价值交付系统。**==