全部产品

效能洞察(仅专有云)

更新时间:2020-06-18 15:21:30

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

操作步骤

  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:任务 运行成功时长(分) 运行成功任务的运行时长。
    统计口径:所有运行成功的任务。