> **来源：[研报客](https://pc.yanbaoke.cn)** # 软件研发效能 2025 # 中国年度调查报告 2025 Annual Report on Software Development Productivity in China # 前言 2016年，南京大学软件研发效能实验室在国内率先发起“DevOps中国年度调查”，至今持续发布《DevOps中国年度调查报告》（简称年度报告），并于2023年升级为“软件研发效能中国年度调查”。年度报告秉持非盈利的厂商中立观点，全面反映且综合分析了DevOps及研发效能在国内的发展现状，为软件及IT企业呈现了横向国际国内参照对比与纵向产业趋势演进的多维视角。年度报告的持续发布在工业界和学术界引发了广泛关注和积极反响，并为相关国家标准的制定提供了重要的数据参考。2023年12月1日起，由全国信息技术标准化技术委员会软件与系统工程分技术委员会（TC28/SC7）技术归口，南京大学软件研发效能实验室核心团队联合中国电子技术标准化研究院主持编写并发布了GB/T42560-2023《系统与软件工程开发运维一体化能力成熟度模型》（简称国标）。软件研发效能已成为“泛DevOps”时代软件企业实现“降本增效”和“持续创新”的核心竞争力，是软件行业新质生产力的集中体现。 2025年调查活动将继续由南京大学软件研发效能实验室组织，并与全国信息技术标准化技术委员会软件与系统工程分技术委员会（TC28/SC7）合作开展。为响应国家标准的实施，本次问卷在设计上与时俱进，不仅聚焦软件研发效能前沿主题，将“国标”的核心内容和要求融入其中，还更新了在安全、大语言模型及智能化技术等热点领域的探讨，并始终坚守厂商中立、确保客观公正的立场。 此外，报告收录符合国标要求的DevOps优秀案例，为企业系统化提升研发效能、深化数字化转型提供行动指南。无论您是刚刚开始研发效能提升之旅，还是已经成为领域实践专家，我们都非常期待倾听您的声音。 # 目录 PART 01 受访者概况 PART 03 DevOps研发效能实践 PART 05 DevSecOps PART 07 LLM赋能DevOps PART 02 DevOps研发效能度量 PART 04 CI/CD流水线 PART 06 BizDevOps PART 08 优秀企业案例 # PART 01 # 受访者概况 受访者行业分布及岗位角色 组织规模及安全概况 # 受访者行业分布及岗位角色 行业分布 24% 基础软件/平台 24% 互联网行业 调查主要集中于这两个行业，结果更能反映其研发效能特征，但其他行业的代表性相对较弱。 公司规模分布 受访企业规模呈现明显的两极化趋势，中小型与超大型组织占比最高。 54% 由20-99人与10000人以上组织构成 - 中小型组织因资源限制更注重效率和灵活性。 超大型组织倾向于通过标准化流程和工具提升整体效能。 行业分布：受访者所处行业中，基础软件/平台和互联网各占 $24\%$ ，合计接近半数，表明这两个领域是本次调研的主要覆盖行业，并且反映出软件研发效能的关注度在数字化程度较高、技术密集型行业中分布更为集中。金融服务与通信行业占比 $15.2\%$ ，表明这两个领域在软件研发方面也保持着较高投入。 行业分布 岗位角色分布 行业类型 基础软件/平台 互联网 金融服务 通信 教育 政府或事业单位 工业制造 零售 开发工程师 测试工程师 需求工程师 系统架构师 # 岗位类型 运维工程师 算法（AI、数据）工程师 安全工程师 管理者（项目经理、总监） 岗位角色分布：从岗位角色分布来看，受访者以开发工程师（15%）为主力，占比最高，说明此次调研样本以研发一线人员为核心。管理者（14%）的占比紧随其后，显示团队负责人和项目管理角色在调研中也保持较高参与度，有助于从组织视角理解研发效能现状。 总体情况：样本在行业上代表了中国当前软件研发较活跃的领域，在岗位上覆盖了从开发、测试、运维到架构、管理等关键角色，为后续研发效能相关分析提供了合理的人群基础。 # 组织规模及安全概况 组织规模分布 组织规模分布：从组织规模分布来看，受访者主要来自20-99人（28%）与10000人以上（26%）的组织，分布呈现中小企业以及超大型企业占主导的特征，表明本次调研在组织规模维度上兼具灵活型小团队与成熟型大型组织的双重视角，为后续对不同规模组织的研发效能差异分析提供了良好的数据基础。 安全人员规模 安全人员规模分布：从安全人员规模分布来看，受访组织在安全投入上呈现明显的两极化趋势。1-5人的人员配置（38%）是最常见的安全团队人员规模，说明大量组织配备了最基础的安全保障人力，体现出“轻量但必要”的安全配置特点。同时，20人以上的大型安全团队占比高达32%，显示不少企业在安全能力上进行了显著的战略性投入，通常对应金融、互联网平台、大型企业集团等对安全要求极高的行业与组织。“中度投入型”的安全组织并不多见，呈现较明显的断层。值得注意的是，仍有10%的组织没有专门的安全人员，反映部分中小企业尚未建立独立的安全团队，可能依赖外包或开发/运维兼任。 总体情况：该分布呈现出软件行业组织在安全方面存在基础小团队和大型安全部门并存，但腰部力量不足的特征，反映中国相关行业内在安全建设上的分化现状：一部分组织刚刚起步，而另一部分已经形成成熟的安全体系。 # PART 02 # DevOps研发效能度量 研发效能度量概况 研发效能度量指标分析 # 研发效能度量概况 # 效能分组方法说明 根据受访者是否度量和观测以上十项研发效能指标，计算其选中指标数量并排序。选中指标数位于前 $50\%$ 的受访者归为“高效能组”，其余归为“一般效能组”。 <table><tr><td>分组</td><td>平均指标覆盖数</td><td>指标覆盖率最高项</td><td>指标覆盖率最低项</td></tr><tr><td>高效能组</td><td>7.6</td><td>服务可用率</td><td>配置漂移率</td></tr><tr><td>一般效能组</td><td>3.2</td><td>缺陷修复时效</td><td>端到端度量</td></tr></table> # 研发效能指标概览 端到端度量 研发过程效能 定义：覆盖“需求 $\rightarrow$ 上线 $\rightarrow$ 运营”全链路的综合度量。 计算方式：描述性汇总（覆盖度、完整性等） 持续集成成功率研发过程效能 定义：持续集成任务的整体通过情况。 计算方式：(持续集成通过次数/持续集成总次数)×100% 生产配置漂移率运行稳定效能 定义： 生产实际配置与基线配置偏离程度。 计算方式： (生产实际配置项数-基线配置项数)/基线配置项数×100% 修复验证时效产品质量效能 定义：从修复提交到验证通过的平均时长。 计算方式： 平均(验证通过时间-修复提交时间) 缺陷逃逸率 产品质量效能 定义： 测试阶段未拦截而流入生产的缺陷比例。 计算方式： (生产环境缺陷数量/测试阶段缺陷数)×100% 安全事件频率 运行稳定效能 定义： 单位运行时长内发生的安全事件次数。 计算方式： 发生安全事件次数/系统运行总时长（月） 计划偏差检出率 产品质量效能 定义： 对计划偏差的发现覆盖程度。 计算方式： (已检出计划偏差数量/ 实际发生计划偏差总数)×100% 需求交付周期 研发过程效能 定义： 从需求提出到交付的平均时长。 计算方式： $\sum$ (需求交付时间-需求提出时间)/需求总数 服务可用率 运行稳定效能 定义： 服务在承诺时段内保持可用的比例。 计算方式： 实际服务可用时长/承诺可用时长×100% 平均修复时间 运行稳定效能 定义： 从问题发生到恢复的平均时间。 计算方式： 总解决时间/解决问题总数 # 研发效能度量概况 组织越大，度量越全面 研发效能度量现状 不同组织规模下指标数量覆盖情况 不同组织规模下指标覆盖数量情况：多数组织采用高密度度量指标体系，40%的组织拥有超过30个端到端度量指标。组织规模与度量指标数量呈正相关，万人级组织中有72.73%覆盖“需求→上线→运营”全链路的端到端度量指标。值得注意的是20人以下组织存在33.33%的度量认知缺失（即回答为“不清楚”相关度量）。 # 研发效能度量指标分析 # > 高效能团队在关键指标上的度量情况显著优于一般团队 研发效能指标采用情况：高效能团队在覆盖端到端研发过程、服务可用率及安全事件监测等关键指标上显著高于一般团队，说明其效能管理体系更加完善、持续改进意识更强。 相关研发效能实践的实施情况：高效能团队整体采用率显著更高，优势最突出的是自动化程度、组织级度量与分析和缺陷流转流程，一般效能团队在工具监控、质量评审与规范这类依赖制度化流程与规范体系的实践上差距更大。 # 研发效能度量指标分析 # 高效能团队的领先是全方位的 端到端度量 持续集成成功率 生产环境配置漂移率 缺陷修复验证时效 缺陷逃逸率 安全事件频率 计划偏差检出率 需求交付周期 服务可用率 平均修复时间 质量类指标：高效能团队的端到端质量（92%）与缺陷逃逸率控制（80%）度量情况优于一般团队，说明其在测试覆盖、质量门禁与持续集成质量保障方面具备更完善的机制。交付与稳定性指标：高效能团队的持续集成成功率（88%）、生产环境配置正确率（60%）以及缺陷修复验证时效（84%）均表现突出，反映其具备规范的配置管理体系和快速的问题响应能力。同时，高效能团队在安全事件频率控制方面（72%）也优于一般团队，表明其在安全治理流程中实行了更严格的审查与监测措施。 计划与需求类指标：同样呈现显著差异。高效能团队的计划偏差检出率（76%）和需求交付周期达成率（90%）均远高于一般团队，体现出其在需求澄清、优先级管理与节奏控制上的成熟度。服务可用率（96%）与平均修复时间（88%）亦显示高效能团队在系统可靠性与运维响应上具有更强的保障能力。 总体情况：高效能团队在质量、交付、可靠性、安全性与需求管理等维度均形成了优势，其工程体系具备更高的规范化程度和更强的反馈驱动能力。这些差异不仅揭示了卓越研发效能的关键特征，也为一般团队提供了明确的改进方向。 # PART 03 # DevOps研发效能实践 研发效能实践概况 研发效能实践能力域分析 研发效能实践洞察 # 研发效能实践概况 # > 效能度量表现与实践成熟度显著正相关 # 研发效能实践能力概览 # 效能管理 过程改进能力域 定义： 通过数据度量和分析，持续提升组织效能、实现业务目标。 度量指标映射： 端到端度量指标 # 系统与工具支撑 基础设施能力域 定义： 为软件活动提供工具和平台，以自动化执行、促进协作与持续改进。 度量指标映射： 工具链继承稳定性 # 环境支撑 基础设施能力域 定义： 保障开发运维一体化顺利实施，提供并持续优化软件运行环境供给。 度量指标映射： 故障恢复时效 # 过程质量保障 支持和保障能力域 定义： 客观验证并改进已执行的过程和所产生的工作产品的质量。 度量指标映射： 缺陷逃逸率 # 配置管理 支持和保障能力域 定义： 通过配置与变更管理保障产物完整并确保交付版本正确可信。 度量指标映射： 生产环境配置漂移率 # 测试 产品研发能力域 定义： 验证软件服务满足需求，持续测试确保产品符合预期用途并减少偏差。 度量指标映射： 缺陷修复验证时效 # 持续集成和交付 产品研发能力域 定义： 通过自动化持续构建集成测试部署确保软件产品随时可交付上线运行。 度量指标映射： 项目需求平均交付周期 # 安全管理 支持和保障能力域 定义： 加强安全管理能力，确保组织响应安全合规并交付可信产品。 度量指标映射： 安全事件发生率 # 监控与调整 项目管理能力域 定义： 充分理解项目进度，及时纠偏提高目标达成可能性。 度量指标映射： 计划偏差检出率 # 服务监控 服务管理能力域 定义： 监控服务状态，及时纠 偏确保服务正常运行。 度量指标映射： 问题解决时效性 # 服务连续性 服务管理能力域 定义： 制定维护计划确保服务正常运营避免中断保持连续性。 度量指标映射： SLA达成率 研发效能实践能力源自《开发运维一体化成熟度模型》，涵盖十一项关键实践，全面覆盖过程改进、基础设施、产品研发、项目管理、服务管理及支持保障六大能力域。数据表明，受访者在实践能力与度量指标的表现高度吻合，团队的度量指标得分与研发效能实践成熟度呈显著正相关。 <table><tr><td>分组</td><td>度量与实践双优</td><td>实践优异</td><td>度量优异</td></tr><tr><td>占比</td><td>84%</td><td>8%</td><td>8%</td></tr></table> # 研发效能实践能力域分析 # 高效能团队在各研发效能能力域的实验均显著优于一般团队 研发效能实践能力域组间对比图 能力域表现：产品研发、支持与保障以及项目管理是当前整体成熟度较高的领域，高效能组与一般效能组均相对表现较好。雷达图结果进一步显示，效能组织管理、系统与工具支撑、环境支撑以及服务监控与服务连续性等实践项整体得分偏低，仍是多数组织的短板。 研发效能实践能力雷达图 结合分析能力域与能力雷达图：高效能组与一般效能组在实践成熟度上整体呈现出明显差距，高效能团队优势显著，展现出更系统化的研发效能实践能力。 # 研发效能实践洞察 # 实践的覆盖情况已呈现体系化 <table><tr><td>能力域</td><td>能力</td><td>最高占比实践</td><td>占比</td></tr><tr><td>过程改进</td><td>效能管理</td><td>从组织业务目标出发,对效能目标进行识别和定义</td><td>62%</td></tr><tr><td rowspan="2">基础设施</td><td>系统与工具支撑</td><td>为DevOps各能力的实践开展提供适用的工具支撑</td><td>62%</td></tr><tr><td>环境支撑</td><td>识别并满足环境的自动化供给需求</td><td>58%</td></tr><tr><td rowspan="2">产品研发</td><td>测试</td><td>编制测试计划以指导测试工作</td><td>66%</td></tr><tr><td>持续集成和交付</td><td>建立实践标准和规范，并保持更新</td><td>64%</td></tr><tr><td rowspan="3">支持和保障</td><td>过程质量保障</td><td>在整个项目过程中,根据已记录的过程和适用的标准,客观评价选定的过程和工作产品</td><td>68%</td></tr><tr><td>配置管理</td><td>对项目活动的关键产出，执行版本控制</td><td>68%</td></tr><tr><td>安全管理</td><td>开展安全合规相关的教育培训</td><td>64%</td></tr><tr><td>项目管理</td><td>监控与调整</td><td>管理关键依赖关系和活动,监控工作环境以识别问题,与受影响的利益相关方一起管理和解决问题</td><td>74%</td></tr><tr><td rowspan="2">服务管理</td><td>服务监控</td><td>采取纠正措施并跟踪管理</td><td>62%</td></tr><tr><td>服务连续性</td><td>建立和维护服务保障优先级</td><td>66%</td></tr></table> 项目管理能力域：监控与调整占比最高，达到 $74\%$ ，体现出行业对项目透明度、节奏掌控和风险应对的高度重视，是保障项目管理稳定的核心手段。过程质量保障与配置管理的关键实践占比分别达到 $68\%$ ，表明客观评价工作产品和版本控制在研发效能中的重要意义。 产品研发能力域：测试计划编制和持续集成交付的比例分别为 $66\%$ 和 $64\%$ ，反映出自动化测试、规范化集成流程以及敏捷交付体系受到广泛关注。服务管理能力同样表现稳健，服务连续性与服务监控占比均超过六成，受访者强调交付后的运维稳定性与持续运营能力，体现了 DevOps 理念在行业中的普遍落地。 环境支持能力的关键实践占比相对较低。这表明识别并满足环境的自动化供给目前的实践成熟度较低，或将成为行业提升效能的方向。 总体来看：当前行业的软件研发效能实践整体已经趋于体系化，多数最高占比实践的覆盖率在六成以上，受访者普遍具备了流程规范、工具支撑、质量管理和项目治理等基础能力。 # 研发效能实践洞察 # 高成熟度实践的实施不足 安全管理各实践比例图 比例 安全管理能力：高成熟度等级的研发效能实践（“在组织层建立安全风险监测识别机制”“开展专业的安全审计活动”等）在企业中的实际覆盖率普遍不足 $40\%$ ，而低成熟度等级实践（如“开展安全合规相关的教育培训”“为组织的资产、活动及软件产品开展安全合规的管理、交付及运行”等）的覆盖比例则超过 $60\%$ 。 数据分布清晰表明，成熟度等级与实践覆盖率之间存在显著的负相关关系。在研发效能实践的实施水平上，整体呈现出向高成熟度等级实践稳步迈进的状态。 # PART 04 # CI/CD流水线 CI/CD流水线建设现状 CI/CD流水线实践挑战 # CI/CD流水线建设现状 # 大部分组织已完成基本流水线建设，覆盖自动化核心环节 持续交付流水线的建设现状 A. 尚未开展持续交付流水线建设，基本全部由手工完成 B. 尝试搭建持续交付流水线, 但仅完成部分阶段的自动化 C. 完成基本流水线建设，覆盖了自动化构建、测试、部署等环节 D. 完善企业内部流水线, 流水线延伸至持续监控、持续反馈与改进环节 40%的受访组织已达到持续交付流水线的基本建设阶段，能够实现自动化构建、测试和部署，这表明行业在基础自动化环节已形成较广泛的应用基础。建议此类组织可进一步向持续反馈等高阶能力延伸。 # 分支开发占据最主流地位 开发策略对比 最主流模式 60% 分支开发 35% 30% 主干开发 # 分支开发+主干发布模式 调查结果清晰显示，“分支开发”策略（共12票）占据绝对主导地位，其占比是“主干开发”（共6票）的两倍。 （1）最主流模式：分支开发 分支开发模式在并行开发和版本控制上存在平衡优势，建议组织在协作场景中优先参考此模式 (2) 采用分支进行隔离开发的策略是主流，其占比是主干开发的两倍。 # CI/CD流水线实践挑战 # > 个人能力不足（50%）是主要挑战 持续集成效能的主要挑战 度量与分析：缺乏明确的度量体系和分析框架 自动化与工具支持：缺少质量保证、自动化的支持工具和研发效能平台 ■ 组织文化：团队氛围、领导决策以及同事协作沟通存在问题 ■ 人员管理：工作量大、负载重，工作流程复杂 ■项目管理：短期追求交付进度造成的技术债务累积、救火工作繁重等 最佳实践实施：对持续集成等DevOps实践的认识和应用不足 半数受访者认为专业知识不足和技术更新能力欠缺是最大瓶颈，这直接影响持续集成的实施质量。建议加强技术培训体系和知识共享机制，帮助团队快速掌握DevOps。 # 低效能团队 关键词：基础建设、流程缺失、标准不明 核心问题：“我们该如何开始？” # 高效能团队 关键词：长期健康、规模化、技术债务 核心问题：“我们如何保持卓越？” 统计结果揭示了效能挑战的进化路径。低效能团队受困于基础流程，如 $16.0\%$ 的人缺乏最佳实践认识和度量体系。而高效能团队已跨越此阶段，转向更高级挑战，如 $12.0\%$ 的人关注技术债务和 $16.0\%$ 的人关注个人能力。这表明高效能团队的关注点正从建立流程向优化系统与人进化。 # CI/CD流水线实践挑战 # 持续集成过程中应用自动化或智能化技术的制约和阻碍因素 A. 缺乏第三方可用的技术 C. 缺乏自主研发基础知识 E. 人员习惯难以改变 G.执行流程的复杂性或不适应性 B.缺乏自主研发工程能力 D. 担心会对制品质量产生负面影响 F. 担心会对过程效能产生负面影响 持续集成过程中应用自动化或智能化技术的主要制约和阻碍因素 # 高效能VS低效能 01 # 差异一 低效能组受访者更倾向于将“人员习惯难以改变”视为阻碍因素 02 # 差异二 在自主研发工程能力与执行流程的复杂性上存在部分差异 28.57%的受访者认为人员习惯难以改变是主要制约因素，显著高于其他选项。这反映出组织内部可能存在技术接受度低、文化转型困难等问题，建议通过渐进式培训、激励机制推动变革。 # PART 05 # DevSecOps 软件代码及架构的可信 软件供应链的可信 软件及其供应链可信保障的挑战 # 软件代码及架构的可信 # AI代码风险监管逐渐加强 组织对于AI生成的代码采取了哪些措施 41.94%的组织对AI生成代码施加更多安全检查、抄袭检测等保障措施，表明行业普遍认识到AI代码的特殊性并建立风险防控机制。建议继续保持技术监管投入，形成标准化操作流程。 对比分析高效能团队与低效能团队，可以发现高效能团队在未来规范层面尤为重视。相较于低效能团队（23%），更多的高效能团队（47%）表示未来针对AI生成的代码会采取相应的措施。 # > 架构治理普遍缺乏标准自动化和可视化的能力 # 架构治理方法 >50% 均超过半数 制定统一的架构标准和原则创建详细的设计和开发规范进行架构依赖分析，识别关键组件和潜在风险 <table><tr><td>架构治理方法</td><td>比例</td></tr><tr><td>制定统一的架构标准和原则</td><td>63.64%</td></tr><tr><td>创建详细的设计和开发规范（例如编码标准、文档）</td><td>68.18%</td></tr><tr><td>采用架构治理工具</td><td>31.82%</td></tr><tr><td>进行架构依赖分析，识别关键组件和潜在风险</td><td>59.09%</td></tr><tr><td>可视化架构治理过程和结果</td><td>27.27%</td></tr><tr><td>缺少架构治理体系</td><td>31.82%</td></tr></table> 受访群体普遍认识到架构治理需要标准与规范，但普遍缺乏将标准与规范化和可视化的能力，仅有约 $30\%$ 的员工有效落实自动化与可视化架构治理。治理工作在很大程度上仍旧依赖于人工审查，这使得架构的监控和维护成本高昂，且难以持续。更存在高达 $31.82\%$ 的群体，尚不具备架构治理体系。 # 软件供应链的可信 # 通过公开外部渠道自主解决问题更受倾向 所在组织遇到第三方库间依赖冲突的情况会如何应对 # 低效能团队方法偏向 (1) 工作群里询问 (2) 搜索引擎检索 (3) 公司提供冲突解决方案 # 高效能团队方法偏向 (1) 搜索引擎检索 (2) 手动不断尝试 (3) 创建详细的设计和开发规范 61.11%的受访者选择通过搜索引擎检索应对依赖冲突，显著高于其他方式。这表明“通过公开外部渠道自主解决问题”更受倾向，建议组织建立内部知识库沉淀解决方案以减少重复检索成本。 高效能与低效能团队在解决问题上存在差异显著。低效能团队偏向被动解决（如群聊、等方案）；高效能团队则积极主动解决（搜索引擎、手动尝试）并系统性地预防问题（创建规范）。 # 内部可信开源组件库建设进展顺利 是否有建立内部的可信开源组件库 数据显示62.5%的受访者确认所在组织已建立可信开源组件库，表明多数组织在开源治理方面具备基础建设能力。未建立的组织可参考已建单位的实施路径，重点关注组件筛选标准、安全审计机制等关键环节。 通过比较分析两种团队的结果，可以得出高效能团队在内部可信开源组件库构建上更加完善。 # 软件及其供应链可信保障的挑战 $\succ$ 流程衔接、技术实施或团队协作等环节仍存在明显障碍 40%的受访者选择尝试整合但有问题，为占比最高的群体。表明虽然DevOps安全整合已成为多数组织的实践方向，但在流程衔接、技术实施或团队协作等环节仍存在明显障碍。此外，高效能团队在DevOps安全实践方面拥有明显更高的成熟度，且已有少部分群体将DevOps完全融入并获得显著成果。 > 安全测试自动化程度不足，人工干预仍是主要执行方式 73.33%的受访者表示部分集成，反映出当前安全测试自动化程度不足，人工干预仍是主要执行方式。建议通过引入自动化工具和流程优化减少人工依赖。 > 利用现有LLM基础设施进行二次开发更受偏好 组织更偏好利用现有LLM基础设施进行二次开发，而非完全自主开发或直接采购第三方服务。建议关注现有LLM平台的生态适配性和接口开放性。 # PART 06 # BizDevOps BizDevOps的探索情况 BizDevOps的建设挑战 # BizDevOps的探索情况 # > 高效能组更主动地探索和拓展新兴DevOps文化与实践 BizDevOps 通常被称为 DevOps 2.0，它以 DevOps 的成功实践为基础，通过整合开发团队和 IT 运营团队的工作，加快并改进软件交付流程。BizDevOps 扩展了这一概念，将业务团队和目标纳入软件开发生命周期的每个阶段。 BizDevOps实践成熟度 超过四成效能组已引入DevOps但尚不了解BizDevOps，而仅有约15.8%的组织已全面实现BizDevOps并形成体系，反映出BizDevOps实践仍处于初期探索阶段。 <table><tr><td>分组</td><td>不了解BizDevops占比</td><td>计划推进|试验占比</td><td>全面融入实践占比</td></tr><tr><td>高效能组</td><td>28%</td><td>50%</td><td>22%</td></tr><tr><td>一般效能组</td><td>55%</td><td>35%</td><td>10%</td></tr></table> 通过高效能组与一般效能组的对比可见，高效能组织更早、更深地推进BizDevOps实践，而一般效能组织大多仍处于认知空白或初步尝试阶段。这反映出高效能团队更重视跨职能协同的价值——他们不仅精通技术，更懂得如何让技术真正服务于业务目标，正通过BizDevOps推动从“交付代码”到“交付价值”的根本性转变。 # BizDevOps的建设挑战 # > BizDevOps建设的挑战是全方位的 推进BizDevOps的最大挑战是业务团队缺乏技术参与能力（31.6%），其次是业务与技术目标不一致（23.7%），反映出协同机制和价值对齐的缺失。组织流程割裂、数据不通、标准不明确等问题也制约了落地效果。根本症结在于缺乏支撑组织实施BizDevOps的最佳实践指导。 # 挑战 A. 业务团队不熟悉具体技术，缺乏低代码工具平台或非技术方法支持参与到技术全过程中 B. 业务的商业价值目标和技术团队KPI不一致 C. 组织缺乏流程、体系或机制来协调业务、开发、运维三者形成反馈闭环 D. 业务团队和技术团队有各自的平台，各自环节的数据不能对应，难以互通和联系 E. 行业缺乏BizDevOps的标准、最佳实践，尚未形成良好的生态环境 F. 业务团队和技术团队间沟通和协作困难，未形成相关文化和价值共识 # 非技术人员参与DevOps的方式 非技术人员参与DevOps的方式 36.8% 通过“同步工具、定期会议或指定对接人”参与，反映出当前仍依赖人工沟通和协调，流程尚未完全自动化； 34.2% 使用“自动化工具（如低代码平台）”，表明技术赋能正在提升业务人员的直接参与能力； 28.9% 通过“文档、演示或试用测试版本”了解进展； # PART 07 # LLM赋能DevOps LLM的投入意愿与现状 LLM应用的阶段与效果 LLM的应用倾向及其挑战 # LLM的投入意愿与现状 # > 高效能团队对LLM的应用更为深入，且投入意愿也更高 <table><tr><td>分组</td><td>平均DevOps阶段覆盖数</td><td>阶段覆盖率最高项</td><td>阶段覆盖率最低项</td></tr><tr><td>高效能组</td><td>3.76</td><td>编码阶段(96%)</td><td>维护阶段(16%)</td></tr><tr><td>一般效能组</td><td>3.20</td><td>编码阶段(84%)</td><td>运维阶段(16%)</td></tr></table> 高效能组在编码、需求和设计等左侧阶段对LLM的应用覆盖率高于低效能组，体现出更深入的技术整合。然而，在测试、构建、运维等后续阶段，两组的LLM使用率差异不大，均处于相对较低水平。这表明当前LLM的应用主要集中在开发前期，而在交付与运维环节反映出这些环节数目前仍处于探索阶段，尚未形成成熟的实践模式。 高效能组与低效能组的LLM投入计划分布比例 高效能组低效能组 # 低 # 投入程度 A. 计划直接引入LLM的第三方服务 B. 计划基于现有的第三方LLM，开发相关工具及服务 C. 计划自主开发新的LLM及相关工具和服务 D. 正在/已经引入第三方服务 E. 正在/已经基于现有的第三方LLM，开发相关工具及服务 F. 正在/已经自主开发新的LLM及相关工具和服务 整体来看，高效能组在更高投入层级（如自主开发LLM及工具）的比例显著高于低效能组，尤其在“正在/已经自主开发新的LLM及相关服务”中占比达 $83.3\%$ ，而低效能组仅占 $16.7\%$ 。这表明高效能团队对LLM的投入更深、战略更主动，正向技术自研和深度集成方向发展，而低效能组仍以引入第三方服务为主，处于相对初级的采纳阶段。 # LLM应用的阶段与效果 > LLM已在DevOps的部分阶段实现深度融入 LLM在DevOps实践中已深度融入软件开发的左侧阶段——编码阶段、需求阶段成为应用最广泛的两大阶段，主要用于代码生成、文档撰写、测试用例设计等任务。相比之下，在构建、部署、维护和运维等后端阶段，LLM的使用比例明显偏低反映出其在自动化流水线、系统监控与故障响应等领域的集成仍处于早期探索阶段，未来随着工具链成熟与工程实践演进，有望进一步释放其在全生命周期中的价值。 # 效能提升显著 >20% √ 60%的效能组认为LLM为研发侧带来了>20%的效能提升 √ 6%的效能组没有感受到较明显的效能提升 采用LLM对研发效能的提升 # LLM应用倾向及其挑战 # > 人工为主，LLM为辅的应用倾向 使用LLM的倾向 效能团队在应用LLM时，多数采用的是“人工为主，LLM为辅”的协作模式，表明当前LLM主要作为辅助工具支持开发工作；仅有14%的团队倾向于“LLM为主，人工为辅”，显示出对自动化能力的较高信任。此外，4%的团队仅在人工难以处理时才使用LLM，2%基本不使用，反映出整体仍以人为核心、LLM为补充的协作模式为主。 # 在全面变革的大势中，过程转型比技术研发的挑战更大 大语言模型应用挑战 挑战启示 01 启示一引入LLM的最大挑战不是技术，而是“过程转型” 02 启示二LLM落地是一场“人、流程、技术”的全面变革 # PART 08 # 优秀企业案例 # 案例一：浪潮科技-跨行业研运 浪潮科技的研发效能管理平台（DevOps）定位于一款具备企业级能力的一体化研发运维平台，覆盖了项目管理、代码管理、持续集成、持续交付、自动化流水线、质量门禁、效能洞察和合规审计等八大关键领域。平台面向公检法司、纪委监委、退役军人休、科技科研、应急、环保、税务、自然资源、工会、文旅、机关事务等10余条行业线，在山东省自然资源厅、河北公安等10多个重点客户落地应用。 # 深度融合DOMM模型 浪潮科技依据《系统与软件工程 开发运维一体化 能力成熟度模型》（GB/T42560—2023）DOMM国家标准指导，系统性地构建了“研发效能管理平台（DevOps）”，深入落地持续集成、持续交付与自动化测试等关键实践。 - 持续构建与集成方面，依据DOMM国家标准中“制定构建策略和集成规范”、“构建和使用组织级BI环境”等具体能力要求，制定了企业级的统一构建规范，根据各产品线特点，制定了构建频率、环境依赖与制品管理等一致性标准，并通过平台实现环境标准化与隔离管理。 # 案例一：浪潮科技-跨行业研运 - 持续交付与部署方面，依据DOMM国家标准中“建立CI/CD实践标准与规范”及“建设自动化系统以支持CI/CD实践”的能力要求，构建了端到端的自动化工具链与标准化流水线。同时，采用了DOMM框架中“设定CI/CD准入标准”与“定位并解决CI/CD故障”等建议，在流水线中集成了代码质量扫描、安全检测和自动化测试等多重质量门禁，并建立了快速故障定位与恢复机制。 # 深度融合技术实践与安全合规 将等保在内的多项合规性约束嵌入自动化流水线，设置为质量与安全门禁，使研发流程的安全保障要求得以自动、闭环落地。 # 构建数据驱动的持续改进机制 依托研发效能管理平台中各项效能指标的定期审视、评估与分析，精准识别过程瓶颈与改进机会，实现目标导向、反馈及时的闭环管理，确保改进过程可持续、可衡量。 $$ 3 4 \mathrm {m} \rightarrow 5 \mathrm {m} $$ 构建耗时降低85% $$ 99 \% $$ 部署自动化率达 $99\%$ $$ 18 \% \longrightarrow 1.5 \% $$ 集成失败率降低91% $$ 12 \% \longrightarrow 0.8 \% $$ 发布失败率降低93% # 案例二：云南电网-DOMM应用落地 云南电网是云南省域电网运营和交易的主体，负责云南省电网规划、建设、运营、管理，服务用电客户1800万户。其依托南网云平台，基于统一技术标准要求构建统一需求管理平台、统一研发运维管理平台、APM性能监控平台等工具，提供“一键镜像构建、一键部署、一站管控”能力，实现全流程CI/CD流水线，智能运维监控中心，研测运一体化协同。加速业务敏捷开发交付，增强业务代码管控，简化项目上云流程，在能源行业率先通过DOMM三级评估。 # 统一开发及运维监控 基于微服务框架的统一开发及运维管控，固化业务流程，统一开发及展示平台的建设，统一规范建设过程中设计、研发和交付物等管理，建设成果统一平台承载，同时支撑自主可控和充分复用共享。实现快速、高效、可复用的微服务敏捷交付工具链，以达到快速响应用户需求的目的。 - 全流程CI/CD流水线：平台提供完整的DevOps工具链，支持从代码提交到生产部署的自动化流水线。平台集成Git代码仓库、Jenkins构建工具和Kubernetes容器编排，实现代码编译 $\rightarrow$ 单元测试 $\rightarrow$ 镜像构建 $\rightarrow$ 灰度发布的端到端自动化。通过标准化流水线模板，将传统2-3天的发布周期缩短至2小时内，部署成功率提升至 $99.2\%$ 。 # 案例二：云南电网-DOMM应用落地 - 智能运维监控中心：平台内置基于Prometheus+Grafana的可观测性体系，实现对微服务API成功率、容器资源利用率等300+指标的智能监控。结合AI算法实现异常检测和根因定位，故障平均恢复时间(MTTR)大幅度下降。 - 研测运一体化协同：通过“云景”缺陷管理模块打通研发、测试、运维环节，支持测试问题实时推送至开发人员（缺陷流转时效提升60%）。平台提供API网关和Mock服务，使联调效率提高3倍，并建立与数字运营系统的数据闭环，实现部署与运维数据的双向反馈。 # DOMM评估与收益 云南电网DOMM评估基于《系统与软件工程开发运维一体化能力成熟度模型》国家标准开展，于2025年7月正式通过软件开发运维一体化能力成熟度模型（DOMM）三级评估，成为能源行业首家达到该等级的规模化企业。 - 强化风险防控能力：建立“风险与机会双库联动”机制，融合风险防控与创新发展需求，升级全链路主动防控体系，将自动化安全管控覆盖从代码实现到产品部署的全环节，提升关键业务连续性保障水平。 - 支撑国家能源战略：作为能源行业规模化企业中首家通过软件开发运维一体化三级评估的主体，为国家能源战略落地提供技术支撑范例，保障能源供应的稳定性与优化配置。 - 引领行业数字化转型：形成体系化的 DevOps 支撑架构实践，为能源行业数字化转型树立标杆，推动行业整体技术水平与竞争力提升。 - 提升公共服务品质：通过技术升级与工具链优化，丰富智能电网服务场景，提升公共电力服务的质量与稳定性，满足社会对可靠电力供应的需求，助力民生保障与社会发展。 # 案例三：中国电信-研发云赋能DevOps 中国电信作为信息通信行业的骨干央企，积极推进“云改数转智惠”战略升级，基于集团统一的研发生产关基系统——研发云平台，构建出“敏捷响应、安全可靠”的软件工程体系，研发全生命周期协同管理、自动化能力提升以及研发资源统一调度，显著提升研发效率、交付质量与组织写作能力。 # 统一研发平台与全流程协同体系 研发云的能力已覆盖敏捷管理、工作协同、持续集成、持续部署、效能度量、科研管理、基础服务等领域，实现从研发管理、开发测试、质量安全、生产部署到运维运营的全生命周期数字资产和研发效能管理。 - 具备大规模复杂场景下研发运营的端到端协同技术，推动了开发部署到运营运维全流程数智化高效协同与安全管理。 - 构建集团级统一研发工作台，建设统一的云网基础研发环境，提供研发所需各种能力和云数智资源，服务全国研发生产一线，实现了研发资源的统筹、协同、共享。 - 整合集团级平台及生产主流程，缩短成果转化周期，形成了可面向市场推广的研产供销集服全链路能力。 # 案例三：中国电信-研发云赋能DevOps # AI驱动的DevOps能力体系 研发云具备DevOps研发运营一体化工具链、AI驱动的研发数智化管理范式、全栈的统一基础研发环境、科创成果研产供销集服生态体系，加速成果转化与推广，全面赋能企业科技创新和数字化转型。 - 建成面向研发全生命周期的生成式DevOps研发运营一体化技术，自研CodeFree研发大模型，率先完成了生成式AI技术在DevOps全生命周期的深度应用。 研发云明显提升了中国电信各单位的软件开发质效，降本增效成效显著：提升了开发效率和协作效率20%以上，提升编译构建速度3倍和成功率25%；释放了各单位DevOps支撑人员2/3人力资源（超600人）；减少了各单位在DevOps平台重复建设投资与运营（不少于20个平台）和商业软件工具重复采购，每年节约企业成本超2亿元。 # 案例四：长江证券-DevOps度量改进实践 在资本市场数字化进程加速和金融科技深度融合的背景下，证券行业面对高频交易、实时风控与智能投顾等业务创新，对系统稳定性、交付效率和合规能力提出了更高要求。在此背景下，长江证券构建了覆盖业务需求、开发测试到运维交付的企业级一体化研发运维体系，实现证券关键业务系统的高效、稳定与可信交付。 在此基础上，公司打造了深度融合行业监管与业务特性的DevOps平台，引入智能编程助手、合规检查、风险预测等能力，为研发体系提供全流程AI赋能。面对多项目并行、业务变更频繁及驻场开发协作复杂等挑战，长江证券进一步形成了以数据整合、智能诊断和决策建议为核心的度量与改进体系，显著提升研发效能、工程质量与业务价值。 # AI赋能DevOps 长江证券基于国家标准构建了一体化研发运维体系，实现研发与运维全价值链贯通。DevOps平台融合证券行业监管与业务特性，整合项目协同、代码管理、CI/CD流水线、质量门禁与合规检测等模块，并与行业主流工具链无缝对接，实现开发、测试、发布的自动化与可视化管控。 平台同时接入自研的“长江灵曦AI中台”，提供智能编程助手、合规检查和风险预测等能力。 # 案例四：长江证券-DevOps度量改进实践 # 度量体系改进 在度量与改进方面，传统方法难以应对证券行业多项目并行、业务变更频繁、驻场开发协作复杂等挑战。长江证券通过构建AI赋能的度量改进体系，实现从数据整合、智能诊断到决策建议的三级能力跨越。 - 数据层自动采集和融合来自 DevOps流水线、测试平台、代码库及项目管理系统的多源数据，打破数据孤岛； - 诊断层依托多维度指标模板与历史数据关联分析，不仅能够精准定位问题根因（如需求流阻塞、代码复审延迟），还可量化各因素对质量的影响程度； 决策层输出的关键洞察及可执行的研发月度报告，如交付亮点及痛点、团队流程优化、个人技能培训等，形成“洞察-归因-行动”的完整闭环。 # 长江证券 # CHANGJIANG SECURITIES # 研发月报-2025年8月 # 一.关键洞察 # 1. 亮点 - 交付效率：本月需求交付周期环比提升 $10\%$ ，本月需求交付周期实现进一步缩短，整体交付节奏持续加快，反映出团队在流程衔接与资源调配方面的持续优化。（详见1.需求交付周期章节） - 开发效率：本月开发效率优于行业中位值，体现了团队在技术执行与协作方面的有效积累。（详见4.开发效率章节） - 交付效率：需求吞吐量环比上升，表明团队在单位时间内处理需求的能力有所增强。（详见2.需求吞吐量章节） - 交付质量：质控版本缺陷密度呈现收敛趋势，缺陷密度月环比下降。（详见5.交付质量章节） - 交付质量：代码内建质量中各指标均优于行业中位值。（详见5.2.代码内建质量章节） # 2. 痛点 - 交付效率：回归测试环节是缺陷解决时长中的最长耗时环节，待确认是最大堵点。（详见1.2缺陷解决流效率章节） - 交付效率：本月需求颗粒度均值超过行业中位值（217当量），需求颗粒度偏大。 大规模落地后，体系支撑项目超过200个，需求交付周期P85值缩短 $36\%$ ，外包质量波动率下降 $63\%$ ，CI/CD成功率提升至 $98\%$ ，度量改进实施率从 $30\%$ 大幅提高至 $85\%$ 。同时，驻场开发成本降低 $18\%$ ，需求月吞吐量提升 $120\%$ 。全面增强了科技团队的创新与交付能力。 # 案例五：中国联通-AI+DevOps 随着中国联通IT集约化进程加速推进以及公司业务和IT复杂度进一步提升，有限的IT资源与日益增长的业务诉求之间的矛盾进一步凸显。中国联通融合DevOps、智能研发与大模型技术，自主研发企业级一站式数智化研发平台，提供一体化AI赋能的IT系统研发解决方案及工具链支撑，覆盖规划立项、需求设计、开发、测试到部署交付的完整生命周期，重塑研发工作新范式，全面助力提质增效。 # 一站式企业级研发平台建设 中国联通全面落实DevOps实践，自主研发企业级一站式数智化研发平台，实现项目、需求、研发交付全面纳管，贯通软件研发全过程，构建统一IT研发交付模式，高质量打造数字化研发管理能力。 需求开发周期由37.73天缩短到18.77天，同比缩短 $50.25\%$ ；需求交付及时率由 $58.78\%$ 提高到 $97.48\%$ ，同比上升 $65.84\%$ ；智能项目助手上线后，立项审批评价时长15.5天，比上线前缩短 $33.5\%$ 。智能需求助手实现需求预评估时长从26.9小时压缩至15.73小时，降低 $41.5\%$ ；AI研发助手累积生成代码362万行，平均AI代码生成占比 $\geqslant 20\%$ ，较传统代码开发预估节约894人月，折合人工成本约1788万元。 # 案例五：中国联通-AI+DevOps <table><tr><td>维度</td><td>转型前</td><td>转型后</td><td>提升幅度</td><td>国标映射</td></tr><tr><td>需求交付及时率</td><td>58.78%</td><td>97.48%</td><td>↑65.84%</td><td>项目管理4级ESP4.1要求</td></tr><tr><td>需求开发周期</td><td>37.73天</td><td>18.77天</td><td>↓50.25%</td><td>项目管理3级ESP3.2要求</td></tr><tr><td>立项审批时长</td><td>23.3天</td><td>15.5天</td><td>↓33.5%</td><td>项目管理3级ESP3.2要求</td></tr><tr><td>单元测试覆盖率</td><td>10%</td><td>65%</td><td>↑5.5倍</td><td>项目管理4级ESP4.1要求</td></tr><tr><td>AI代码生成占比</td><td>0</td><td>20%</td><td>-</td><td>-</td></tr></table> # 研发交付体系化建设 基于行业DevOps能力成熟度模型和CMMI等行业标准，结合中国联通研发实践，制定统一的软件研发管理流程规范，形成体系化的评估标准和过程改进建议（《中国联通软件工程能力成熟度模型（CCMD）》），驱动软件工程成熟度持续提升。 # 效能度量体系落地 构建多维度研效数字化度量体系，贯通项目、需求、研发等场景，深化研发交付全过程数字化，全流程的科学评价体系助力数据驱动的效能改进，实现需求价值、交付数量、组织产能持续提升。 # 智能化研发范式升级 将大模型能力与软件研发场景紧密结合，构建AI辅助立项、AI辅助需求分析、AI辅助编程、AI软件测试等智能化能力，推动中国联通IT系统研发迈入智能化新时代。 # 案例六：中国人寿-数字化研发变革 在数字经济背景下，中国人寿股份有限公司研发中心推进了覆盖研发全链条的数字化变革，围绕组织架构革新、工程能力跃迁和业务技术融合进行系统性调整。变革以云原生技术为基础，通过自动化与智能化能力提升研发效率，推动研发体系从传统支撑模式向技术融合模式转变。 数字化研发体系以“效能工具、效能实践、效能度量”为三大支柱，构建了覆盖研发协同、编码、构建、测试和部署的全流程自动化研发体系，实现研发数据统一管理、流程标准化控制和效率显著提升。AI技术逐步融入开发和测试，通过代码生成、界面识别、智能用例生成等方式增强研发活动。整体框架在企业战略、技术演进和组织调整的共同作用下，使研发活动更具自动化、标准化和精准化特征，强化了研发能力和风险控制能力。 # 全链条数字化变革 中国人寿构建了贯穿单测、集成、构建到部署全能力链，整合开发工程师、测试工程师等多角色协作，支持标准流程与简化流程的双轨并行。工具层面搭建了覆盖研发管理、代码管理、制品管理的综合平台，依托服务网格和PaaS技术实现活动可追溯与最佳实践嵌入。 # 案例六：中国人寿-数字化研发变革 # 关键工程实践 - 流水线模板支持拖拽式动态编排，人工卡点机制保障制品晋级规范性。 - 质量前移机制在代码提交时自动触发质量与安全检测，减少后期返工成本。 统一制品管理规避多环境独立构建风险，经验证的镜像晋级提升交付可靠性，杜绝生产故障隐患。 # 组织模式变革 AI技术逐步融入体系，在开发阶段，AI驱动的代码助手实时建议和自动补全代码片段，甚至生成基础函数的实现，大幅减少重复性编码工作；在测试环节，使用AI视觉技术，动态识别UI界面，智能生成测试用例，覆盖更多边界和异常场景。 数字化研发实践框架不仅局限于技术层面，在企业数字化战略、数字化技术和研发组织的内外驱动下，实现了自动化先进技术与研发工程的深度融合。通过组织架构的小型化、扁平化演进，促进了生产流程的高效智能化和管理的数字化、标准化及自动化。 服务模式也随之转变为融合化、精细化和精准化。这一转型有效提升了金融科技研发的技术创新能力、价值创造能力和风险抵御能力。数字化研发的深远影响直接驱动了组织与服务的全面转型。业务数字化转型后，研发与用户之间建立了强有力的链接：研发团队通过分析用户操作行为和订单结果（如客户画像）来优化操作体验。组织小型化赋予各科技团队自主经营能力，使其能快速响应市场动态。 # 案例七：中国移动-“四共”科技创新研发平台 中国移动针对超大规模研发和复杂研发环境，建设了“四共”科技创新研发平台，以“共研发管理、共研发平台、共能力中台、共技术栈”为核心理念，整合需求、设计、开发、测试、构建、发布及运维环节，完成了需求管理、代码仓、制品库、安全扫描等核心功能建设，实现了全流程工具链集成，研发规范内置化，实施AI在需求、开发、测试等核心场景规模化应用。平台已覆盖全集团约 $60\%$ 研发单位，支撑3.6万人协同作业，预计到2027年实现全链路AI赋能与安全保障体系覆盖全集团。 # 四共科技创新平台 中台对接 和作社对接 云能大模型对接 蓝军监管平台对接 # 全链路数字化 - 统一研发桌面与流程管理，实现协同一体化。平台通过“研发桌面”为入口，提供标准化的流程配置、需求管理、代码仓管理、流水线编排等功能。支持Scrum、IPD等多种研发模式，实现项目、需求、版本、交付件的全链路线上化管理。通过自定义工作台、待办中心、团队空间等模块，提升了用户操作体验与协作效率。 - 融合服务与开放平台，打通工具链与数据链。通过“统一流程管理”模块，实现需求、设计、代码、测试、发布等环节的工具链贯通。建立统一开放平台，支持API、数据、模型三类能力开放，方便各省专公司进行二次开发和定制化扩展。工具网关与模型网关的设计，实现多工具接入与智能调度，提升了平台扩展性与灵活性。 # 案例七：中国移动-“四共”科技创新研发平台 # AI赋能研发效能 平台在六大核心场景中嵌入AI能力：支持需求智能拆分、排期优化和相似度查重；提供代码生成、自动补全、检视、调试及注释生成，支持十余种语言；实现测试用例生成、结果分析及故障根因定位；支持构建脚本生成与错误修复；优化发布策略并进行风险自动评估。通过国产大模型集成，平台在代码生成采纳率、单元测试生成效率等指标上提升超过 $30\%$ 。同时构建多维度研发效能度量体系，覆盖需求、开发、测试、部署等环节，提供200+预置指标及自定义报表，实现数据驱动的持续改进。平台兼容国产基础设施，自研率超 $90\%$ ，结合分层数据加密、权限管控、审计日志和供应链安全机制，确保研发资产全生命周期安全可控。 平台建设已取得阶段性成果，需求交付周期从平均37天缩短至18天，提升 $51\%$ ；代码构建速度提升3倍，部署效率提升2倍；AI代码生成占比 $25\%$ ，节约开发人月超100人/年；单元测试覆盖率从 $10\%$ 提升至 $65\%$ ，漏洞检出率提升 $40\%$ ，发布成功率超 $99\%$ 。平台已纳管代码仓超1万个，代码行数超10亿，日均构建次数超5000次，日均部署近千次；通过统一工具与资源集约，减少重复平台建设20余个，年节约IT成本超1.5亿元。 # 案例八：嘉为蓝鲸-一站式研发效能 在企业数字化转型持续深化的背景下，业务创新周期加速，传统IT研发与运维体系难以达到敏捷交付水平。企业普遍存在交付模式滞后、过程管理粗放、自动化程度低、流程工具割裂等问题。嘉为蓝鲸基于在金融、制造与汽车、政企与运营商三大典型行业场景，推出面向全生命周期的DevOps一站式研发效能解决方案，全面覆盖能源、交通航司等领域的个性化诉求。 # 工具与数据一体化 方案整合分散工具链，实现研发、运维、运营数据实时联动，消除跨系统切换成本，数据同步效率从“小时级”提升至“分钟级”。 - CTeam实现敏捷协同与项目管控，拉通跨部门协作； - CCode提供安全高效的代码管理与协作服务； - CCI通过可视化全自动流水线，结合代码检查与质量红线实现强管控持续集成； - CPack打造制品全生命周期管控体系，保障唯一可信源； - CTest规范测试流程与自动化工具集成，提升质量验证效率； - CFlow实现端到端价值流可视化，精准识别交付瓶颈； # 案例八：嘉为蓝鲸-一站式研发效能 - CMeas构建全域度量体系，以数据驱动持续优化； - CAgent AI助手提供智能需求拆解、用例生成等全流程辅助。 # 全流程闭环与智能化赋能 方案以“全流程闭环+智能化赋能”为核心，打通研发到运维全环节，以IT转型赋能业务数字化升级。兼容信创全栈生态，支持稳敏双态研发模式，内置细粒度权限管控与审计能力，满足金融、政企等强合规需求。并兼容国产芯片、操作系统、数据库等全栈信创生态，降低转型门槛与风险。通过标准化工具链整合与流程自动化，助力企业消除数据孤岛，降低工具采购成本，将故障定位时间从4小时压缩至30分钟，交付周期缩短，全面提升研发效能、交付质量与业务创新速度。 # 实践经验总结 - 以业务价值流为核心设计：打破“重工具轻流程”误区，通过CFlow价值流模块串联业务需求到部署全环节，避免管理流与工程流脱节，实现全局洞察。 - 坚持“一体化+可扩展”平衡：基于蓝鲸PaaS架构打造统一平台，既整合核心工具链消除孤岛，又保留自定义开发能力适配行业特性。 数据驱动持续优化：通过CMeas度量模块建立效能指标体系，结合客户实践沉淀行业基准，助力组织能力升级。 - 适配稳敏多态需求：针对政企稳态系统与互联网敏态业务，提供差异化流程模板，结合信创生态适配能力，降低转型门槛与风险。 # 软件研发效能实验室简介 软件研发运维一体化 (DevOps) 是当前软件行业建设和实现研发效能的主流形式，而随着 DevOps 的快速普及，软件研发效能也成为“泛DevOps”时代软件企业实现“降本增效”和“持续创新”的核心竞争力。南京大学软件研发效能实验室 (DevOps+ Research Laboratory) 在国内率先开展以软件研发效能及DevOps为中心的全方位教学、科研和产业合作，聚焦全面对接数字经济和全社会数字化转型发展的软件研发模式，为软件产业的规模化与工程化提供系统级解决方案。实验室团队在 DevOps 和研发效能等领域开展科研攻关，聚焦解决研发全局性、系统性瓶颈挑战，提出研发效能理论技术框架，构建面向全流程多维度研发效能持续提升的软件工程技术协同体系，以技术创新推动软件产业“泛DevOps”变革研发至价值交付全链路一体化，赋能国内“后互联网”时代数字经济发展。团队研究方向覆盖软件及系统工程过程、软件体系结构、软件质量与安全、构建与集成技术、观测运维技术，经验软件工程、区块链与智能合约技术、研发数字化与数据治理、软件工程智能化技术、智能系统工程等。实验室承担了多项国家与江苏省重大科研项目，包括主持国家重点研发计划、江苏省重点研发计划、国家自然科学基金、江苏省自然科学基金等各类科技计划项目；与华为、腾讯、中兴、百度、阿里巴巴、美团、星环科技等知名企业建立多方面长期科研合作。实验室曾主办多个软件工程学科重要国际学术会议以及中国软件大会的系列论坛，自2016年起发起“软件研发效能·DevOps 中国年度调查”，全球软件开发者大会 (NJSD) 和互联网架构峰会 (IAS) 等。2023年，实验室作为核心成员单位主持编制的《开发运维一体化 (DevOps) 能力成熟度模型》国家标准正式发布并在全国开始实施。实验室拥有雄厚的科研力量，现有全职教师10人，客座教授7人，企业导师7人，博士后2人，在读博士研究生近二十人，硕士研究生近百人。截止至2025年10月，实验室师生已在 ICSE、FSE/ESEC、ASE、ISSTA、CSUR、TSE、TDSC、TOSEM、EMSE、JSS、IST、JSEP、SPE 等国际顶级软件工程会议和期刊发表论文近三百篇，其中13篇获国际最佳论文奖/最具影响论文奖。实验室科研成果获80余项发明专利授权/受理。实验室对所有研究生实施国际标准的系统化培养，与挪威、澳大利亚、英国、加拿大、奥地利、瑞士、荷兰、新加坡等海外以及国内其他高校学者建立了学术交流与师生互访机制，为学生提供多种选择的中长期海外合作研习机会。实验室学生多次获得研究生国家奖学金，毕业生均进入华为、腾讯、阿里、字节跳动等一线知名企业，部分学生赴欧美海外顶尖学府继续深造。 # 全国信标委软件与系统工程分委会简介 全国信标委软件与系统工程分委会（TC28/SC7，秘书处：中国电子技术标准化研究院）是在工信部的指导下，经国家标准化管理委员会批准成立的软件与系统领域国家标准化技术组织，国际上对口ISO/IEC JTC1/SC7，工作范围是负责全国信息技术领域软件产品和系统工程方面的过程，支持工具及技术的标准化工作，现由73名专家委员及222家成员单位组成，下设8个工作组/研究组，专家委员覆盖了国内相关行业的学术带头人、教授、政府部门的领导、骨干技术人员、企业高层等。成员单位覆盖了行业龙头企业、研究院所、高校、第三方测评机构、社团组织等，充分汇聚了各方资源，促进组织健康发展。 # 下设8个工作研究组： 软件质量工程标准工作组(WG1) 负责软件质量度量、测试、评估、评价等方面的标准研制和应用的推广 软件能力开发标准工作组（WG2） 负责DevOps、生存周期过程、技术能力评估等方面的标准研制和应用推广 软件工程工具标准工作组（低代码开发平台特设组）(WG3) 负责低代码开发平台等开发工具及软件研发辅助工具的需求分析、能力要求、选型、分类分级、测试等方面的标准研制推广 软件价值评估标准工作组 (WG4) 负责软件资产、绩效、成本等方面的标准研制和应用推广 软件人才培养标准工作组（WG5） 负责软件学科体系、从业人员资质评估、认证等方面标准的研制和应用推广 软件工程新技术标准研究组(WG6) 负责产品线工程、数字工程、MBSE等软件工程新技术的研究和标准制定，培育新的研究方向和标准工作组 汽车行业软件标准工作组(WG7) 负责汽车软件工具、汽车应用软件等方面的标准研制和应用推广 智能软件工程工作组（WG8） 负责智能软件工具链、智能软件工程应用等方面的标准研制和应用推广 在国内标准化方面，软工分委会已发布软件与系统工程领域国家标准145项，行业标准20项；围绕软件需求、设计、开发、测试、运维构建了所需的方法、工具、管理、质量为一体的软件生存周期全栈式标准体系，为软件行业的规范化发展提供了重要支撑。 在国际标准化方面，中国核心牵头或参与的国际标准已发布48项，其中牵头4项，参与44项。我国在软件质量、软件测试、软件成本度量、基于模型的软件测试、敏捷和DevOps等重点领域标准水平已达到国际先进，并促进国际标准的制定，通过标准国际化为全球的文明发展做出中国的贡献。 # 版权声明 本调查报告版权属于南京大学软件研发效能实验室、全国信息技术标准化技术委员会，并受法律保护。转载、摘编或利用其它方式使用本调查报告文字或者观点的，应注明“来源：南京大学软件研发效能实验室”和“全国信标委软件与系统工程分委会”。违反上述声明者，将追究其相关法律责任。