质量与交付篇（5/6）：发版 checklist：如何降低线上事故率发版 checklist：如何降低线上事故率（把“

发版 checklist：如何降低线上事故率（把“必须阻断”和“可带风险”分开）

系列：质量与交付篇（5/6）
标签：Flutter 发布流程 Checklist 质量保障 工程管理

这篇只讲一件事：发版前哪些问题必须拦截，哪些问题可以记录风险后上线。
很多团队出事故，不是因为没有 checklist，而是所有项都“看情况”，最后变成“先发了再说”。

1. 问题背景：业务场景 + 现象

我们线上踩过三类典型事故：

登录、支付、下单这类主链路在某机型直接失败；
崩溃率明显上升，但发布当天没人拍板阻断；
有已知 UI 问题，大家口头说“影响不大”，结果投诉集中爆发。

复盘后发现，不是测试没做，而是缺少统一的发布判定标准：
同样的问题，在不同负责人手里，结论可能完全相反。

2. 原因分析：核心原理 + 排查过程

核心问题不是“有没有测”，而是“有没有门槛”

发版决策本质是风险管理，要解决两个问题：

是否触发阻断门槛（不能上线）
若不阻断，风险是否被明确记录并有兜底方案

很多团队把两者混在一起，导致：

该阻断的不敢拦；
不该阻断的也被拖，影响交付节奏。

我们后来用的排查顺序（每次发版固定跑）

主链路（登录/支付/下单/核心互动）是否全绿
Crash、ANR、卡顿、启动耗时是否超阈值
配置、开关、回滚路径是否可用
已知问题是否有用户范围评估和止损方案

3. 解决方案：方案对比 + 最终选择

3.1 两种常见做法

做法 A：单一 checklist，全“建议项”

优点：看起来灵活。
缺点：临门一脚全靠拍脑袋，最容易出事。

做法 B：分级 checklist（阻断项 / 风险放行项）

优点：决策成本低，责任清晰。
缺点：前期要花时间定阈值，且要持续校准。

3.2 最终选择：分级 + 明确 owner + 明确时限

我们落地时就三条硬规则：

阻断项命中任意一条，直接停止发版；
风险放行项必须写清影响面、兜底方案、修复期限；
没有 owner 的风险项，等同阻断项。

4. 关键代码/配置：最小必要片段

发版前我们会跑一段检查脚本（示意）：

#!/usr/bin/env bash
set -e

echo "1) 运行测试"
flutter test

echo "2) 构建产物"
flutter build apk --release

echo "3) 基础检查"
# 示例：检查版本号、渠道配置、关键资源是否存在
test -f "build/app/outputs/flutter-apk/app-release.apk"
grep -q "versionName" android/app/build.gradle

echo "4) 结果"
echo "基础流水通过，进入人工验收与发布评审"

以及在 CI 中加“阻断阈值”判断（示意）：

release_gate:
  crash_rate_max: 0.30%
  anr_rate_max: 0.10%
  cold_start_p95_max: 2200ms
  must_pass_cases:
    - login
    - payment
    - order_submit

重点不是脚本多复杂，而是：阈值先定好，发布当天不再临时改规则。

5. 效果验证：数据/日志/复盘结果

分级 checklist 执行 2 个版本周期后，我们看到几个变化：

发布会从“讨论要不要发”变成“对照门槛看是否达标”；
线上 P0 事故次数明显下降（尤其是配置和主链路类）；
测试和开发冲突减少，因为阻断标准提前对齐；
有风险上线的项能追踪到 owner，后续补丁节奏更稳定。

真正有价值的不是“零问题上线”，而是：
知道带了什么风险上线，什么时候补，出事怎么止损。

6. 可复用结论：通用经验 + 避坑清单

必须阻断发版（命中即停）

核心业务链路有 P0/P1 缺陷（登录失败、支付失败、下单失败、核心功能不可用）
崩溃/ANR 指标超过团队阈值（按近 7 天或灰度样本）
回滚能力不可用（无法快速回退版本或关闭关键开关）
关键合规问题（权限声明、隐私弹窗、审核必备信息）未满足
发布包与目标环境不一致（签名、渠道、配置错误）

可带风险上线（需记录）

非核心路径 UI 小瑕疵（有明确影响范围和修复计划）
低频机型样式问题（用户占比低且有客服话术）
可通过远程配置规避的问题（并已验证开关生效）
已有替代路径的问题（主流程不受影响）

风险放行必须写清楚 4 件事

影响面：影响哪些用户、比例大概多少
兜底方案：开关、降级、回滚怎么做
责任人：谁跟进修复和验证
截止时间：最晚何时补丁或下版修复

发版当天可直接用的判定模板

版本：x.y.z
结论：通过 / 阻断

【阻断项检查】
- 主链路：通过/失败
- Crash/ANR：通过/失败
- 回滚能力：通过/失败
- 合规项：通过/失败
=> 任一失败：阻断

【风险放行项】
1) 问题：
   影响面：
   兜底方案：
   Owner：
   修复截止：

最终发布人：
测试确认人：
产品确认人：
时间：

这篇的核心就一句话：把“是否阻断”标准前置，并把“带风险上线”流程标准化。
这样发版不靠情绪，靠规则。

质量与交付篇（5/6） ：发版 checklist：如何降低线上事故率