线上质量除了故障数量，还要统计哪些指标

月度复盘只看故障数量，容易把“这个月比较平静”当成质量改善，也可能漏掉少数严重故障、恢复缓慢或重复发生的问题。衡量线上质量，建议在故障数量之外补齐四类指标：严重度与影响面、时间维度、过程与重复性、体验与业务结果。本文给出每个指标的公式、分子分母、时间窗与单位，并说明数据口径、计算步骤和解读限制，便于在月度复盘中直接复算。

要点总览（TL;DR）

• 故障数量只回答“发生了几次”，月度复盘还需补齐严重度与影响面、时间维度、过程与重复性、体验与业务结果四类指标。
• 每个指标都要写清分子、分母、时间窗和单位，例如MTTR为恢复时长之和÷故障数，变更失败率为失败变更数÷变更总数。
• 故障数量与严重度分布、恢复时长分位数、重复故障率交叉看，才能识别“次数持平但质量下滑”的情况。
• 分母为零的月份标注“不适用”而非记0；口径变更时注明生效月份并做同口径调整，保证跨月可比。
• 指标用于定位改进方向和判断趋势，不宜直接作为个人绩效结论，也不存在适用于所有团队的统一达标线。

月度复盘要回答哪些线上质量问题

故障数量回答的是“发生了多少次”，月度复盘还需要回答另外四类问题。把评估目标先拆清楚，选指标时才有依据，也避免统计了一堆数字却说不清用途。

要回答的问题	判断用途	对应指标角度
这个月的故障有多严重、影响了谁	判断质量事件对用户和业务的实际冲击，区分“次数少但影响大”与“次数多但影响小”	严重度与影响面
出问题后我们发现和恢复得快不快	判断监控告警与应急响应能力，识别发现慢、定位慢、恢复慢的环节	时间维度
同类问题是否反复出现，问题是否在测试阶段被拦住	判断质量防线是否有效，识别重复故障和缺陷逃逸	过程与重复性
用户实际感受到的服务水平有没有变化	判断质量表现与业务结果的关系，为改进优先级提供依据	体验与业务结果

这四类问题共同构成月度复盘的评估目标：既看事件本身，也看发现与恢复能力、质量防线的有效性，以及用户侧的实际体验。评估目标与业务视角保持一致，复盘中提出的改进项才能落到具体系统、具体环节，而不是停留在“下个月少出故障”这类无法执行的要求上。

除故障数量外应纳入的指标与统计范围

下面按四个角度给出指标清单。每个指标都写明公式、分子分母、时间窗和单位，统计时按同一口径执行，跨月才能比较。

严重度与影响面指标

• 故障等级分布：按故障分级标准统计各级故障数量，单位“起”，时间窗为自然月。输出形式为各等级起数及占比，占比分母为当月纳入统计的故障总数。
• 受影响用户占比：受影响用户数 ÷ 当月活跃用户数 × 100%，时间窗取故障影响期间，分母取同一统计周期内的活跃用户数。需要说明“受影响”的判定方式，例如无法访问、功能不可用或数据异常。
• 受影响订单占比：受影响订单数 ÷ 同期总订单数 × 100%，适用于交易类系统。分母口径需与业务报表一致，避免与财务口径混用。

时间类指标

• MTTD（平均发现时长）：各故障从发生（或首次可观测异常）到被确认发现的时长之和 ÷ 故障数，单位“分钟”或“小时”。分子中的起点口径必须统一，例如统一取首次告警时间或统一取业务侧首次异常时间。
• MTTR（平均恢复时长）：各故障从发生到服务恢复的时长之和 ÷ 故障数，单位“分钟”或“小时”。需要区分“恢复服务”和“彻底修复”，两者统计口径不同。
• 恢复时长分布：除平均值外，统计恢复时长的分位数（如P50、P90），避免个别长故障被平均值稀释。
• 故障间隔：相邻两次故障之间的平均时长，单位“天”或“小时”，用于观察故障发生的密集程度。

过程与重复性指标

• 逃逸缺陷率：上线后发现的缺陷数 ÷（上线前发现缺陷数＋上线后发现缺陷数）× 100%，时间窗按缺陷发现时间归属月份。该指标反映测试与评审环节拦截问题的效果。
• 重复故障率：重复发生的故障数 ÷ 故障总数 × 100%。“重复”需事先定义，例如同一根因、同一功能模块或同一类触发条件再次引发故障。
• 变更失败率：导致回滚或故障的变更数 ÷ 变更总数 × 100%，时间窗为自然月，分母为当月完成的变更数量。

体验与业务结果指标

• 可用性：1 － 不可用时长 ÷ 统计周期总时长，以百分比表示。需要明确不可用的判定阈值和统计的系统边界。
• 错误率：失败请求数 ÷ 总请求数 × 100%，按接口或核心链路分别统计，时间窗可与月度对齐或取月度内的高峰时段。
• SLO达成率：达标时间窗口数 ÷ 统计窗口总数 × 100%。窗口粒度（如按小时或按天）需在SLO定义中写清。
• 客诉量：按工单来源去重后的客诉工单数，单位“件”，时间窗为自然月。需说明去重规则，避免同一用户多渠道重复计数。

统计范围

统计前先固定四项范围：系统边界（哪些系统和服务纳入）、故障口径（哪些事件计入故障台账）、时间窗（自然月或按发布周期）、单位（起、分钟、百分比、件）。范围一旦确定，在月度复盘中保持稳定；确需调整时，在报告中注明调整内容和生效月份。

数据口径与证据要求

指标能否复算，取决于数据来源和口径规则是否写清楚。建议在月度复盘前完成以下口径与证据规则。

• 数据来源：故障台账提供故障等级、发生时间、恢复时间和根因分类；监控告警系统提供首次告警时间和错误率原始数据；工单系统提供客诉量；发布系统提供变更总数和回滚记录。每个指标标注数据来源，便于复核。
• 故障分级标准：事先定义各级故障的判定条件，例如影响范围、核心功能是否可用、是否造成数据错误。分级由值班或质量负责人确认，避免事后按结果倒推等级。
• 纳入与排除规则：明确哪些事件计入故障台账，例如计划内维护、第三方服务故障、仅影响内部测试环境的事件如何处理。排除项需逐条列出，不能凭印象剔除。
• 分母为零的处理：某月没有变更或没有故障时，相关比率标注“不适用”，不记为0。记0会拉低年度均值，也会让趋势图出现虚假改善。
• 缺失值处理：缺少首次告警时间等字段时，标注缺失并在计算中排除该条记录，同时说明排除条数；缺失比例较高时，该月指标只作参考，不参与趋势判断。
• 口径变更的可比性：跨月或跨团队调整统计口径时，在复盘中注明变更内容、生效时间和影响范围；必要时按新旧口径各算一次，或对历史数据做同口径重算，避免趋势被口径变化扭曲。

计算与评估步骤

月度计算建议按固定顺序推进，先保证单项指标可复算，再做交叉分析，最后形成结论。

1. 锁定数据快照：在固定日期导出故障台账、告警记录、变更记录和客诉工单，记录导出时间和数据范围，后续复算以同一快照为准。
2. 逐项计算基础指标：先算故障总数和等级分布，再算影响面、时间类、过程类和体验类指标。每项指标写出分子、分母和单位，便于他人核对。
3. 做交叉分析：把故障数量与严重度分布对照，识别“次数下降但高等级故障上升”的情况；把故障数量与MTTR、恢复时长分位数对照，识别恢复能力变化；把故障数量与重复故障率、逃逸缺陷率对照，判断问题是否在反复出现。
4. 处理趋势与环比：环比时确认两个月口径一致；口径不一致时先做同口径调整再比较。对波动较大的指标，结合当月发布次数、业务流量变化解释，避免把正常波动当成质量恶化或改善。
5. 形成月度结论：结论回答“哪类问题在变化、变化是否可解释、下月优先改进什么”。每个结论对应具体指标和证据，改进项落到系统、环节和责任人。

当故障记录、变更记录和复盘文档分散在不同工具中时，复算成本会明显上升。ONES Performance 提供效能度量实践体系，覆盖交付效率、交付质量、资源效率、完成情况四个维度，并可对系统内产生的研发数据进行多维度、精细化、自定义的分析；其数据来自 ONES 系统内日常流转的研发数据。若故障工单、变更记录和复盘文档在 ONES 中流转，可将这些记录作为月度统计的输入，再用仪表盘模板呈现趋势，减少手工汇总。系统外的监控告警和客诉数据仍需按上述口径单独整理后并入分析。

一个月的指标计算示例

以下数据为演示用虚构示例，仅说明公式和交叉解读方式，不代表任何真实组织水平。

指标	示例数据	计算过程	结果
故障数量	当月故障6起	直接计数	6起
高等级故障占比	高等级2起	2 ÷ 6 × 100%	33.3%
受影响用户占比	受影响用户1.2万，月活40万	12000 ÷ 400000 × 100%	3.0%
MTTR	6起故障恢复时长合计540分钟	540 ÷ 6	90分钟
重复故障率	重复故障2起	2 ÷ 6 × 100%	33.3%
变更失败率	失败变更3次，变更总数60次	3 ÷ 60 × 100%	5.0%
可用性	不可用时长86分钟，月总时长43200分钟	1 － 86 ÷ 43200	99.80%
SLO达成率	达标窗口700个，统计窗口720个	700 ÷ 720 × 100%	97.2%

假设上月故障数量也是6起，但上月高等级故障为0起、MTTR为45分钟、重复故障为0起。两个月故障数量相同，质量表现却明显不同：本月高等级故障占比上升，恢复时间翻倍，且三分之一的故障属于重复发生。只看故障数量，会得出“质量持平”的结论，掩盖了严重度和恢复能力的变化。

解读示例时，先看高等级故障和影响面是否集中在少数系统，再看MTTR上升是发现慢还是修复慢，最后结合重复故障率判断改进项是否真正落地。示例中的比率均需与分母一起呈现，单独引用百分比容易失去参照。

如何解读指标并避免误判

指标用于定位问题和判断趋势，不能单独作为整体质量结论，也不宜直接作为个人绩效评价依据。

• 单指标会掩盖结构差异：故障数量下降可能伴随高等级故障上升；MTTR下降可能因为故障被更快地临时绕过，而根因尚未修复。解读时需要把数量、严重度、时间和重复性放在一起看。
• 指标之间存在制约关系：缩短恢复时长可能促使团队采用快速回滚，回滚增多又会推高变更失败率；提高发布频率可能增加变更次数，需要结合变更失败率判断发布质量。指标之间相互牵制，组合使用才能反映真实状态。
• 不设通用达标线：不同系统的重要性、流量规模和业务容忍度不同，可用性、MTTR等指标不存在适用于所有团队的统一达标线。目标值应结合SLO、业务要求和历史水平确定，并在复盘中说明依据。
• 区分相关与因果：指标变化与某次改进在时间上接近，只能说明相关，不能直接证明改进有效。判断因果需要对照改进前后的同类故障、重复故障和逃逸缺陷变化。
• 明确评价边界：月度指标反映组织在统计周期内的质量表现，受发布节奏、业务流量和外部依赖影响。用于绩效评价时，应结合具体事件复盘和岗位职责，避免用单一比率下结论。

把上述指标固定为月度复盘模板，每月按同一口径计算并记录口径变更，故障数量就会从唯一结论变成分析起点，严重度、恢复能力、重复性和用户体验的变化才能被看见并转化为具体改进项。

常见问题

月度故障数量与上月持平，还需要从哪些角度判断质量是否真的没变？

先看结构而不是总数：对比两个月的故障等级分布，确认高等级故障是否增加；对比MTTR和恢复时长P90，判断恢复能力是否变化；再看重复故障率和逃逸缺陷率，确认问题是否在反复出现。三项都稳定，才能说质量大致持平。若高等级故障占比上升或恢复时长翻倍，即使总数相同，也应视为质量下滑，并在复盘中定位到具体系统和环节。

某个月没有发生故障，MTTR和重复故障率应该记0吗？

不应记0。分母为零时，比率没有计算意义，应标注“不适用”并说明当月无故障。记0会把该月拉进年度均值，让趋势图出现虚假改善，也会掩盖后续月份的真实波动。同理，某月没有变更时，变更失败率同样标注“不适用”。在趋势分析中，可以把这类月份单独标注，只参与故障数量等计数类指标的统计。

统计口径中途调整过，跨月趋势还能直接比较吗？

不能直接比较。口径调整后，应先注明变更内容、生效时间和影响范围，再按新旧口径各算一次，或对历史数据做同口径重算，然后比较趋势。如果无法重算，就在趋势图上标注口径变更点，变更前后的数据分段解读。故障分级标准、纳入排除规则、系统边界任何一项调整，都属于口径变更，需要同样处理。

这些指标可以直接用于团队或个人绩效评价吗？

不建议直接使用。月度指标受发布节奏、业务流量和外部依赖影响，单一比率无法反映具体事件的处理难度和岗位职责差异。更稳妥的做法是把指标用于定位改进方向，绩效评价时结合具体事件复盘、改进项落地情况和岗位职责综合判断。若确需与考核挂钩，应事先说明指标定义、统计范围和免责条件，避免团队为压低数字而回避发布或延迟记录故障。

故障工单、变更记录和复盘文档分散在多个工具里，怎么降低月度汇总成本？

先统一记录入口：故障台账、变更记录和复盘文档尽量在同一个协作平台中流转，字段按统计口径设计，例如故障等级、发生时间、恢复时间、是否重复。ONES Performance 提供效能度量实践体系，覆盖交付效率、交付质量、资源效率、完成情况四个维度，并可对系统内产生的研发数据进行多维度、自定义的分析，数据来自 ONES 系统内日常流转的研发数据。系统外的监控告警和客诉数据仍需按统一口径单独整理后并入。