第1章：Crash稳定性现状评估

1.1 适用场景

本章适用于以下三种典型启动阶段：

• 新团队/新项目首次接入Crash治理：尚未建立稳定性基线，需从头采集指标并归类问题。
• 存量产品稳定性恶化：线上Crash率连续两个版本上升，需通过现状评估定位治理切入点。
• 技术架构迁移/重构前后：评估新架构对Crash稳定性的实际影响，量化回归风险。

1.2 前置条件

1.3 操作步骤

本章分为三个子流程：现状指标采集 → 已知问题归类 → 团队能力摸底。每一步都有明确的输入物与输出物。

步骤1：现状指标采集

1. 拉取近30天Crash关键指标：从Crash平台导出日活、启动次数、Crash次数、影响用户数、4N、0N、用户影响率。
2. 计算稳定性核心基线：
   

   # 示例：使用Python计算日级Crash率基线
   import json, statistics
   daily_crash_rates = [0.32, 0.28, 0.35, 0.31, 0.29]  # 单位：%
   mean_rate = statistics.mean(daily_crash_rates)
   p90_rate = sorted(daily_crash_rates)[int(len(daily_crash_rates)*0.9)]
   print(f"基线均值: {mean_rate}%, P90: {p90_rate}%")

3. 记录版本级Crash率：按每个线上版本（包含灰度版本）分别汇总，标记版本号与发版日期。
4. 输出指标汇总表（见1.4 输入输出物）。

步骤2：已知问题归类

1. 按Crash类型归类：使用平台标签或脚本按异常类名进行归类。
2. 按模块/功能域归类：根据堆栈顶部的前3帧，映射到业务模块（如支付、登录、视频播放）。
3. 标记紧急度：
   • P0：影响用户量≥5% 或 影响核心交易/登录链路。
   • P1：影响用户量1%~5%，非核心功能。
   • P2：影响用户量<1%，偶现。

步骤3：团队能力摸底

1. 填写能力矩阵问卷：对团队成员在Crash分析、原生堆栈阅读、hook调试、符号解析方面的掌握程度打分（1~5分）。
2. 工具链审计：检查是否具备 dsym 自动上传、混淆映射表、符号化工具、自动化报警等基础设施。
3. 输出能力短板清单（见1.4 输入输出物）。

1.4 输入输出物

1.5 责任边界

• 客户端开发：负责提供代码分支信息、dsym文件、协助堆栈符号化、参与P0 Crash初步定位。
• QA工程师：主导指标采集体、输出归类看板、组织能力问卷填写与汇总。
• 技术负责人：审批紧急度标记、确认能力短板清单并制定能力提升计划。

1.6 记录材料

本次评估需存档以下材料（推荐存放在团队Wiki或Git仓库文档目录）：

• crash_baseline_YYYYMMDD.xlsx — 稳定性基线表
• crash_classification_YYYYMMDD.md — Crash归类看板
• team_skill_gap_YYYYMMDD.md — 能力短板清单

1.7 异常处理

1.8 验收标准

完成本章后，必须满足以下条件才算现状评估合格：

• 基线覆盖度100%：近30天（连续）Crash数据全部汇总，无遗漏日期。
• 归类完整性≥95%：Crash事件归类到具体类型/模块的占比≥95%，剩余≤5%归入“待归类”。
• 能力摸底完成率≥80%：团队核心成员（包括客户端开发、QA、架构师）参与评估。
• 所有输出物已存档：基线表、归类看板、能力清单均上传至指定位置并通知相关人。

1.9 本章小结清单