3. Crash监控体系总体流程：宏观步骤、输入输出、责任部门、关键里程碑

3.1 适用场景

• App内测/灰度/全量发布阶段Crash事件的全链路追踪
• 跨版本Crash趋势对比与回归分析
• 因Crash导致的用户流失、性能衰减等业务问题的根因定位
• 新建Crash错误码体系或对现有错误码进行重新映射

3.2 前置条件

• 已接入统一Crash采集SDK（iOS/Android/PC Web等）
• 已搭建或租用事件管道（Kafka / Flume / 自研中转服务）
• 已定义错误码分类树第1版（至少包含一级、二级分类）
• 各责任部门已指定对接接口人及值班人员

3.3 宏观操作步骤

Crash监控体系总体流程按时间顺序分为6个阶段，每个阶段包含明确的输入输出与判断点。

1. Crash事件采集：客户端SDK在异常发生时捕获原始堆栈、内存快照、设备信息、用户ID等，打包上报至采集网关。
2. 数据归一化与清洗：采集网关或ETL层去除重复事件、过滤研发内部测试流量、将多端SDK数据格式统一为标准结构。
3. 上下文增强与关联：将清洗后的Crash事件与用户行为流、版本发布记录、A/B实验分组、滚动会话日志进行关联，生成增强事件。
4. 错误码映射与分类：依据预定义的映射规则（关键字匹配、堆栈签名、人工标记），为每条Crash事件打上错误码（Error Code）及严重等级。
5. 告警分发与工单演练：根据严重等级和业务线负责人配置的告警策略，将告警推送到企业微信/钉钉/PagerDuty，并自动创建JIRA工单或OpsGenie事件。
6. 复盘与迭代：每周/每月生成Crash趋势报告、错误码覆盖率报告、根因分析报告，驱动映射规则更新与客户端修复。

3.4 输入输出物

3.5 责任边界（责任部门与角色）

• 客户端团队（含SDK维护组）：负责SDK集成、采集参数调优、堆栈符号化、本地缓存策略制定。
• 数据中台（ETL/流处理团队）：负责数据管道建设、格式转换、去重逻辑、时效性监控。
• 云运维/基础架构组：负责采集网关高可用、告警通道联通性、存储容量规划。
• 质量保障/测试：负责映射规则验证、回归测试、错误码正确性评审。
• 业务线（各产品研发）：负责响应告警、提供上下文辅助根因分析、实施客户端修复。

3.6 记录材料

• 流程设计文档：包含各阶段交互接口定义、数据字典、降级策略。
• 告警配置清单：按错误码级别、业务线、值班表生成的CMDB。
• 映射规则历史版本：每次规则变更保留JSON Diff记录。
• 周/月Crash报告：以PDF或看板形式归档，保留至少6个月。

3.7 异常处理

• 采集网关过载：启用客户端本地缓存 + 指数退避重试，降级丢弃非P0事件。
• 映射规则未命中：自动归入“未知错误码”Bucket，触发人工标注流程，24h内完成映射。
• 行为数据缺失导致增强失败：使用默认上下文占位符，不阻塞下游。
• 告警风暴：聚合相同错误码/堆栈的告警为一条，并限制每分钟最大告警条数。
• 上游版本表变更：增强模块应通过渐变数据订阅，避免强依赖Schema硬编码。

3.8 验收标准

• 流程闭环率：从Crash发生到告警触达责任人，端到端延迟P99 ≤ 5分钟（采集→归一化→增强→映射→告警）。
• 错误码映射准确率：每周随机抽样500条Crash事件进行人工标注对比，准确率 ≥ 95%。
• 告警灵敏度：P0级别Crash事件上升趋势（连续3个5min窗口增长超20%）必须在首个窗口内触发告警。
• 数据完整性：每日Crash事件数据缺失率 ≤ 0.1%，支持15分钟粒度回补。