上线风险处理流程

临近上线组员发现问题、有上线风险，组长标准处理流程

一、第一步：快速定风险（5 分钟内落地）

1. 立刻叫停盲目打包 / 发版，暂停上线流程，不硬冲。
2. 让组员同步完整信息：
   • 问题复现步骤、影响范围（全量 / 部分用户、核心流程 / 边缘功能）
   • 问题严重级别：崩溃 / 资损 / 流程阻断 / UI 小问题
   • 根因初步判断、能不能快速修复、修复要多久
3. 自己快速判定：阻断级 BUG、核心链路问题一律不准强行上线。

二、第二步：分级决策（核心 3 种场景）

场景 1：严重 BUG（资损、交易失败、登录异常、页面崩溃）

1. 立即暂缓上线，同步产品、测试、运维、业务负责人。
2. 安排专人加急改 BUG、自测、回归。
3. 修复完成后走完整回归测试，只过不冒险。
4. 若修复耗时久：申请顺延上线窗口，发群同步所有相关方，说明原因和新上线时间。

场景 2：中度问题（不阻塞主流程、少量边缘功能异常）

1. 评估能否临时屏蔽、配置开关关闭、降级处理。
2. 能降级：先上线，把问题挂后续迭代版本，登记缺陷台账，排期修复。
3. 不能降级：按严重问题处理，延后上线。

场景 3：轻微问题（文案、小 UI、不影响任何业务流程）

1. 内部记录 BUG，正常按期上线。
2. 明确下个版本固定修复，不遗留放任。

三、第三步：现场资源调度（组长核心职责）

1. 分工到人：谁改 BUG、谁复测、谁对接产品、谁同步运维。
2. 优先抽调资深开发 / 测试攻坚，不摊活、不推诿。
3. 禁止组员私自拍板 "将就上线"，所有上线放行必须组长 + 测试 + 产品三方确认。

四、第四步：沟通同步（避免业务、领导不知情）

1. 对内：组内同步风险、处理方案、时间节点，稳定团队心态，不慌不乱。
2. 对外：同步业务、上级、运维，如实说明风险、不隐瞒不瞒报，给出明确处理结论（延后 / 降级 / 正常上线）。
3. 不甩锅、不指责发现问题的组员：发现问题是好事，避免线上事故，要肯定。

五、第五步：事后复盘（避免下次再发生）

1. 复盘为什么提测前没发现：用例遗漏、自测不到位、联调不充分、工期压缩。
2. 优化流程：增加提测准入、主干合入卡点、上线前预发环境全量回归。
3. 沉淀到团队规范：临近上线严禁随意合入新代码，只允许修复阻断级 BUG。

六、组长核心原则总结

1. 风险优先，绝不带病强行上线；
2. 快速定级、快速分工、快速同步；
3. 不追责发现问题的人，只复盘流程漏洞；
4. 所有上线放行必须流程合规、三方确认。