第4章 Crash优先级定级标准
适用场景
当多个Crash需并行或顺序修复时，使用本定级标准统一评估各Crash的修复优先级。适用于以下阶段：
- 每日Crash看板评审：筛选出当日最严重的Top N问题。
- 发版前封锁决策：评估哪些Crash必须随当前版本修复，哪些可延迟。
- 线上应急响应：根据影响范围与严重程度，决定是否需要立即热修复或回滚。
前置条件
- 已完成Crash归因分类（章节3），每条Crash关联了明确的根因模块。
- 已获取以下数据：DAU、Crash对应的用户量、单次Crash频率（用户级/会话级）、版本安装量。
- 已明确Crash表现类型：崩溃、黑屏、闪退、无响应（ANR）。
- 已知当前版本的发版窗口与紧急需求（阻塞发版 / 线上紧急 / 下个版本）。
操作步骤
- 评估影响范围：计算Crash涉及的DAU占比（受影响用户数 ÷ 日活跃用户数）。分三档：
高(>5%)、中(1%–5%)、低(<1%)。 - 评估严重程度：根据用户可见表现：
严重（黑屏/无响应）、中等（崩溃）、轻（闪退）。 - 评估修复紧急度：依据业务节奏：
阻塞发版、线上紧急、下个版本。 - 查矩阵定级：将影响范围×严重程度映射到下方矩阵，得到P0/P1/P2/P3。
- 记录与上报：将优先级写入Crash治理看板，通知相关责任人。
输入输出物
| 类型 | 说明 | 格式/示例 |
|---|---|---|
| 输入A | Crash归因列表（含根因模块、用户量、频率） | CSV或内部看板API |
| 输入B | DAU数据 & 版本安装量 | 当日DAU: 10M；版本 v4.2.1 安装量 6M |
| 输出 | Crash优先级定级表（P0/P1/P2/P3） | JIRA Epic / 内部看板卡片 |
责任边界
- Crash治理工程师：执行定级计算，填写矩阵，发起评审。
- QA：确认严重程度分类准确（例如“闪退”与“无响应”的边界）。
- PM：最终审批P0/P1列表，决策是否阻塞发版。
- 开发Owner：对优先级为P0/P1的Crash在24小时内给出修复方案。
记录材料
- Crash优先级定级表：
Crash ID | 影响范围 | 严重程度 | 紧急度 | 优先级 | 责任人 | 状态 C-123 | 高(6.2%) | 崩溃 | 阻塞 | P0 | 张三 | 已确认 C-456 | 中(2.1%) | 黑屏 | 线上 | P1 | 李四 | 开发中 - 评审记录：会议纪要或Slack Thread，包含争议定级原因的说明。
异常处理
场景1：影响范围数据缺失 —— 若因埋点采样不足无法精确DAU占比，则按保守策略取历史同模块Crash的平均用户量，并在记录中标记“估算”。
场景2：严重程度二义性 —— 例如同时报“闪退”和“无响应”时，以最高严重度（无响应）为准；若无法确定，触发三方（QA+工程师+PM）紧急评审。
场景3：紧急度与矩阵矛盾 —— 某些业务特性要求某低影响Crash必须阻塞发版（如支付流程），此时直接提升一级，并在备注中注明业务强依赖。
验收标准
- 每个已归因Crash都有明确的优先级（P0/P1/P2/P3），且与定级矩阵一致。
- P0/P1级Crash修复完成后，需回归验证并更新看板状态。
- 定级结果经过评审，责任边界签名确认。
- 记录材料完整可审计。
核心原则：优先级定级必须在24小时内完成，避免阻塞后续灰度验证流程（章节5）。