效能洞察（仅专有云）

研发效能平台效能洞察功能依托数据和算法，以提效为中心，对研发过程进行多维度度量分析，识别效能问题、推荐方案，驱动组织和个人效能的持续提升。

操作步骤

1. 选择应用（不选择则默认是所有应用）通过页面左上角的应用选择器，选择需要观察的应用，可以选择查看所有应用或单独应用。

2. 选择统计时间通过页面右上角的时间选择器，选择需要观察的数据统计时间，可以分别按照周、月、季、年。

3. 查看统计指标点击页面上的不同卡片入口，分别查询的应用研发过程指标和流水线指标，分别对趋势分析和对比分析进行下钻分析。

指标说明

研发过程

1. 应用迭代交付量

   完成的应用迭代数量以及变更代码行，综合评估团队的交付量。

   • 指标：完成应用研发迭代数 统计时间范围内完成发布的迭代数量，按迭代 ID 计 算。按应用名称+迭代 ID 算，即两个应用对应 1 个迭代 ID 的情况，算 2 个。
     
   • 统计口径：仅统计完成发布的迭代。

2. 应用迭代交付效率

   用于查看和分析应用每个迭代的平均交付周期。

   • 指标1：研发迭代平均交付周期 从迭代创建到发布成功
     

   • 统计口径：只统计周期在 0-180 天(包括 180）之内的迭代；只统计类型为“标准迭代”的 LinkE 迭代。

   • 指标2：完成研发迭代数 统计时间内已完成发布的迭代数量
     

   • 统计口径：对于迭代周期不 符合统计口径的(比如周期>180 天）也会计算在内，同时在明细中也可以查看到对应的迭代明细，可用于帮助团队分 析周期异常的原因，但不会影响“研发迭代平均交付周期” 指标的计算。

3. 应用迭代交付质量

   用于查看和分析应用每个迭代交付的结果质量。

   • 指标1：活跃应用客观质量分 “质量分”是迭代交付质量的重要指标，质量分由一系列指标构成，可拆分子指标逐一分析，目标50分。
     

   • 统计口径：已经交付完成的迭代(迭代周期 > 0）。

   • 指标2：活跃应用数 统计时间范围内已发布完成迭代的应用。
     

   • 统计口径：无。

4. 应用发布效率

   从发布视角监控和分析应用的发布节奏

   • 指标1：应用发布周期 应用每次发布和上一次发布的时间间隔，可衡量应用的持续发布能力。
     

   • 统计口径：只统计周期在 0-180 天(包括 180）之内的迭代；只统计类型为“标准迭代”的 LinkE 中的迭代；若仅 0 或 1 次发布，则默认为 0 天。

   • 指标2：应用发布迭代数
     

   • 统计口径：统计时间内 1 次应用的 1 个迭代发布算 1 次，即如果 存在 2 个应用关联同一个迭代 ID 同时进行 1 次发布，则算 为 2 次。此外，对于计算应用发布周期时不符合统计口径的 (比如周期>180 天）的迭代也会被计算在内，在明细中也 可以查看到对应的迭代明细，可用于帮助团队分析周期异常 的原因，但不会影响“应用发布周期”指标的计算。

流水线

1. 流水线质量

   提交 MR 触发的流水线的通过情况。

   • 指标1：流水线通过率 流水线成功运行且所有质量规则检查通过。
     
   • 统计口径：流水线运行通过数 / 流水线运行数。
   • 指标2：流水线运行通过数 由于流水线中每一个任务的运行结果有四种: (1）执行完成且规则检查成功 (2）执行完成但规则检查失败 (3）未执行用户主动点击跳过 (4）执行失败(因环境或工程等原因） ，因此整条流水线的运行结果为所有任务运行结果的汇总，流水线运行结果有两种: 1、“流水线运行成功”，从工程的角度成功完成了运行，所有任务的状态为(1）或(2）或(3）；2、“流水线运行通过”，从用户使用的角度执运行成功且所有规则检查通过，所有任务的状态为(1）或(3）。
     
   • 统计口径：1、“流水线运行通过数”并非按照每一个运行通过的流水线 ID 统计，而是每次提交的 CommitID 去重计算。原因是避免 1 个应用多个迭代的情况，在集成阶段后 1 次提交会触 发多个流水线同时跑失败，导致通过率计算结果偏低的情况。2、提交质量的管控基本都依赖 MR 提交模式，因此只统计 “MR 类型”的流水线。
   • 指标3：流水线运行数 运行过的流水线数量，无论结果如何，E2E 运行完成 一次算一次。
     
   • 统计口径：同“流水线运行通过数”指标统计口径。
   • 指标4：流水线合并前未通过数 没有通过的流水线且失败的任务节点在“MR 合并” 节点前。指标的内含是判断有多少问题是在代码合并前就被流水线拦截的。在使用质量门禁的情况下（不通过任务节点 不能跳过），这个指标可用来判断流水线的有效性。
     
   • 统计口径：同“流水线运行通过数”指标统计口径。
   • 指标5：流水线运行未通过数 流水线运行数 - 流水线运行通过数。
     
   • 统计口径：无。

2. 流水线效率

   提交各种形式（Push、MR、配置变更等）触发的流水线的 运行效率。

   • 指标1：流水线运行成功率 流水线运行成功数 / 流水线运行数。
     
   • 统计口径：无。
   • 指标2：流水线运行成功数 由于流水线中每一个任务的运行结果有四种: （1）执行完成且规则检查成功 （2）执行完成但规则检查失败 （3）未执行用户主动点击跳过 （4）执行失败（因环境或工程等原因） ,因此整条流水线的运行结果为所有任务运行结果的汇总，流 水线运行结果有两种: 1、“流水线运行成功”:从工程的角度成功完成了运行， 所有任务的状态为（1）或（2）或（3）; 2、“流水线运行通过”:从用户使用的角度执运行成功且 所有规则检查通过，所有任务的状态为（1）或（3）。
     
   • 统计口径：支持流水线类型和含义包括Push 提交（push 代码后自动触发）、MR 提交（提交 MR 后自动触发）、 自动触发（定时任务触发）、配置变更（修改配置触发）、手工触发、提交预发部署等。
   • 指标3：流水线运行数 运行过的流水线数量，无论结果如何，E2E 运行完成一次算一次。
     
   • 统计口径：同“流水线运行成功数”统计口径。
   • 指标4：流水线运行失败数 流水线运行数 - 流水线运行成功数。
     
   • 统计口径：无。
   • 指标5：流水线 运行成功时长（分） 没有通过的流水线且失败的任务节点在“MR 合并” 节点前。指标的内含是判断有多少问题是在代码合并前就被流水线拦截。在使用质量门禁的情况下（不通过任务节点不能跳过），这个指标可用来判断流水线的有效性。
     
   • 统计口径：由于流水线存在因用户重跑导致从启动到结束显示时间超长的情况，因此“流水线运行成功时长”获取规则如下: 1、只统计运行成功的流水线。2、流水线上显示的运行时长 和 流水线中每个任务运行时 长之和，两者取最小值。3、若取值后总时长仍超过 120 分钟，视为异常值，暂不统计。

3. 工程活动效率

   从工程的角度评估流水线上任务（编译、部署、静态检查 等）的执行情况，找到效率瓶颈点，并有针对性的提升。

   • 指标1：任务运行成功率 流水线运行成功数 / 流水线运行数。
     
   • 统计口径：无。
   • 指标2：任务运行成功数 统计流水线上运行的任务节点，单个任务的运行结果有四种: （1）执行完成且检查成功（2）执行完成但检查失败 （3）未执行跳过 （4）执行失败，因此如下是任务运行结果的两类定义: 1、“任务运行成功”:运行结果为（1）或（2）或 （3），任务从工程的角度成功完成了运行。 2、“任务运行通过”:运行结果为（1）或（3），任务从 用户使用的角度执运行成功且所有规则检查通过。
     
   • 统计口径：所有运行成功的任务。
   • 指标3：任务运行数 运行的任务数量。
     
   • 统计口径：所有运行的任务。
   • 指标4：任务运行失败数 任务运行数 - 任务运行成功数。
     
   • 统计口径：无。
   • 指标5：任务 运行成功时长（分） 运行成功任务的运行时长。
     
   • 统计口径：所有运行成功的任务。