灰度与线上监控
自动关联目录：灰度与线上监控
1. 定位
发布不是终点，是开始：真正能验证质量的是线上数据，而不是测试环境。
一句话定位：灰度的目的是"把问题限制在小部分用户"，监控的目的是"在用户投诉之前发现问题"。两者缺一不可。
2. 灰度
| 维度 | 做法 |
|---|---|
| 按比例 | 1% → 5% → 20% → 100% |
| 按机型 | 先在低端机验（最容易出问题） |
| 按地区 | 先小地区 |
| 按渠道 | 先单一渠道 |
| 停止条件 | 崩溃率/关键指标超阈值立即停止 |
关键：灰度必须配套可停止、可回滚的机制，否则只是"慢慢出事"。
3. 必看的线上指标
| 指标 | 为什么 |
|---|---|
| 崩溃率 | 最直接的"坏没坏"（见 崩溃与 Dump） |
| 更新成功率 | 热更分发是否有问题（见 热更新与补丁） |
| 版本分布 | 决定何时能下线旧补丁 |
| 启动成功率 / 首次进入耗时 | PSO 与加载问题（见 PSO 预缓存） |
| 帧率分布 | 别只看平均，看低端机 |
| 内存 OOM 率 | 移动端硬指标（见 移动端内存与显存预算） |
UE 特有的一条：更新后 24 小时崩溃率——它能直接反映这次包有没有把 PSO/资源搞坏。
4. 崩溃与符号
| 要点 | 说明 |
|---|---|
| 保留符号 | 发布时归档，否则栈读不懂（见 崩溃与 Dump） |
| 崩溃聚合 | 按栈聚类，排优先级 |
| 版本映射 | 崩溃要能对应到具体版本 |
| 加壳/混淆 | 要留符号映射 |
5. 回滚
| 层 | 手段 |
|---|---|
| 资源/热更 | 撤回补丁（见热更新篇的回滚设计） |
| 商店版本 | 商店回滚能力有限，要谨慎 |
| 服务端开关 | 最灵活——用配置关掉出问题的功能 |
| 强制更新 | 必要时要求用户升级 |
服务端开关是最可靠的回滚手段——尽量把"能不能开"做成服务端可控。
6. 代价与权衡
| 设计 | 收益 | 代价 | 什么时候不该用 |
|---|---|---|---|
| 按比例灰度 | 问题可控 | 发布周期变长 | 紧急修复可跳（但要盯得更紧） |
| 服务端开关 | 回滚最快 | 需要提前设计 | 事后加就来不及 |
| 全量监控 | 看得见 | 数据量与成本 | 至少要监控崩溃率 |
| 只发不管 | 快 | 出事才知道 | 从不做 |
| 灰度但无停止条件 | — | 等于没灰度 | 必须有阈值 |
7. 踩坑与排查
| 坑 | 现象 | 怎么验证 |
|---|---|---|
| 没有灰度 | 一发全量就炸 | 建立灰度流程 |
| 灰度但不能停 | 眼睁睁扩散 | 加停止条件 |
| 没保留符号 | 崩溃看不懂 | 发布流程里归档 |
| 只看平均帧率 | 低端机崩了还以为没问题 | 看分布与低端机 |
| 没监控更新成功率 | 分发坏了不知道 | 加指标 |
| 回滚只能靠商店 | 周期太长 | 做服务端开关与热更回滚 |
8. 排查顺序
上线前：符号归档 ✓ 监控指标就绪 ✓ 灰度与回滚方案 ✓
上线中：看崩溃率 / 更新成功率 / 启动耗时，超阈值立即停止
上线后：24h 崩溃率是这次包的关键判据
出事时：优先用服务端开关或热更回滚，最后才是商店参考
许可协议：CC BY
作者：Davids
本文链接：https://hustjjd.github.io/88462182.html
更新于：2026年10月10日