第1章：Crash治理总体流程与角色职责
适用场景
本章内容适用于移动端/PC端/SDK类产品在线上出现Crash时，组织跨团队（开发、测试、运维、PM）进行标准化治理的场景。涵盖从Crash上报到最终复盘归档的全链路流程，确保多角色协作时输入输出清晰、责任边界明确、过程可追溯。
前置条件
- 已接入Crash上报平台（如Bugly、Sentry、Firebase Crashlytics等），并稳定收集Crash日志至少一个版本周期。
- 团队内部已定义Crash严重等级（P0/P1/P2/P3）以及各角色的基本职责。
- 具备灰度发布能力（如分阶段推送、A/B Test、Feature Flag等）。
- 拥有统一的Bug/任务跟踪系统（如Jira、TAPD、Bugzilla等）用于流转与记录。
流程总览（SVG）
操作步骤
- Crash监控与告警：运维通过告警平台（如Prometheus + Alertmanager）或第三方SDK接收Crash上报，按预设阈值触发告警通知到PM和开发群。PM初步判断是否触发应急流程。
- 归因分类：开发拉取完整堆栈与设备信息，结合测试辅助复现，将Crash归入已知根因/未知根因、必现/偶现、P0～P3等级。PM确认优先级和影响面。
- 灰度验证：开发提交修复补丁，通过Feature Flag或分桶策略推送至灰度用户。运维监控灰度Crash率变化，测试执行回归用例。若灰度Crash率低于阈值且无新增P0 Crash，则进入下一阶段。
- 全量发布：PM审批后，开发将修复合入稳定分支，运维推进全量推送或热修复。持续观察48小时Crash收敛情况。
- 复盘归档：PM组织复盘会议，填写Crash复盘表（根因、修复方案、改进措施），归档至知识库。同步更新Crash治理Checklist。
输入输出物（按角色）
| 角色 | 输入物 | 输出物 |
|---|---|---|
| 运维 | Crash上报原始日志、告警规则 | 告警通知、灰度Crash趋势图、全量发布监控报告 |
| 开发 | Crash堆栈、用户设备信息、历史修复记录 | 根因分析报告、修复补丁、灰度验证结果 |
| 测试 | Crash复现步骤、灰度策略说明 | 复现报告、回归测试结果、灰度稳定性评估 |
| PM | 告警通知、各阶段报告、用户反馈 | 优先级判定、灰度/全量审批单、复盘归档文档 |
责任边界矩阵
责任边界矩阵（RACI 简化版）
| 活动 / 角色 | 运维 | 开发 | 测试 | PM |
|---|---|---|---|---|
| 监控告警配置 | R/A | C | I | C |
| 归因分类 | I | R/A | C | C |
| 灰度方案设计 | C | R | C | A |
| 灰度执行与监控 | R | C | C | A |
| 全量发布审批 | I | C | I | R/A |
| 复盘归档 | I | C | C | R/A |
记录材料
- Crash治理工单（Jira/TAPD）：包含Crash ID、版本号、严重等级、当前状态（监控/归因/灰度/全量/归档）。
- 根因分析文档：按模板记录堆栈摘要、复现条件、代码关联、是否已知库问题。
- 灰度验证报告：灰度用户数、Crash率变化、是否新增Crash、验证结论。
- 复盘表：包括问题描述、根因、修复方案、耗时、改进措施（如补充单元测试、增加防御逻辑）。
异常处理
常见异常及应对：
- 告警风暴：同一个Crash瞬间上报大量，导致运维干扰。 → 在监控平台设置聚合规则（相同堆栈合并），延迟告警5分钟。
- 归因无法复现：缺少堆栈关键信息或设备环境特殊。 → 升级为“待补充”，尝试远程日志收集，或设置为低优先级待后续版本跟踪。
- 灰度Crash率不降反升：修复引入新问题。 → 立即回滚灰度，强制走P0应急流程。
- 全量发布后Crash率反弹：部分机型灰度未覆盖。 → 紧急回退，补充灰度范围，延长观察期。
验收标准
- 所有P0/P1 Crash在24小时内完成归因分类，72小时内完成灰度验证或回滚。
- 灰度阶段Crash率低于基线（0.05%）且无新增P0 Crash，审批后全量发布。
- 全量发布后48小时Crash收敛至原有水平（或低于基线）。
- 每个Crash工单均附带根因分析和复盘记录，归档至知识库。
- 责任边界矩阵中的职责清晰，无跨角色推诿记录。