飞行员起飞前要过检查单，逐项口念手到，几十年不变的仪式感背后是一条铁律：关键流程不能依赖记忆。AI 服务上线同理——翻车的事故复盘中，多数根因都是「忘了改」「漏了配」这类细节，而不是高深的技术难题。检查清单就是把记忆外包给流程。配置核对还有个实用技巧：把生产配置的期望值写成机器可读的基线文件，核对时用脚本比对，而非人眼逐项看，既快又不会看走眼。
先带走一个判断：清单的价值在执行方式，不在纸上。逐项打勾、双人复核、留档可查，三样齐了清单才生效；扫一眼签个字的清单只是自我安慰。
清单按什么顺序过
顺序有讲究：从内到外、从静到动。先过配置类（机器上长什么样），再过数据与权限类（谁能碰什么），然后过兜底与回退类（出事怎么办），最后才做流量类验证（真实请求通不通）。这个顺序的理由是：前面任何一项不过关，后面的验证结果都不可信——配置错了，压测数据是白测；权限没收敛，功能验证再顺也不能上。
四组的顺序与分工，一行一组看清楚。
| 顺序 | 检查组 | 回答的问题 | 覆盖的关键项 |
|---|---|---|---|
| 第一 | 配置类 | 机器上长什么样 | 环境配置、版本一致性、资源余量、密钥与凭证 |
| 第二 | 数据与权限类 | 谁能碰什么 | 权限最小化、数据链路、日志策略、审计就位 |
| 第三 | 兜底与回退类 | 出事怎么办 | 回退方案、停机预案、告警就绪、冷启动防护 |
| 第四 | 流量类验证 | 真实请求通不通 | 真实请求验证；前面任何一项不过关，验证结果都不可信 |
配置类检查项
配置核对覆盖这几组：环境配置——连接地址、超时参数、重试策略是否为生产值，测试环境的占位符清干净；版本一致性——部署的版本号与评审通过的版本一致，配置文件与代码仓库里的基线做差异比对；资源余量——内存、存储、并发上限是否在压测基线的安全水位内，基线数据来自容量压力测试，做法见容量压力测试是怎么做的？每一步都讲透；密钥与凭证——生产凭证是否就位、是否经加密存储、测试凭证是否已回收。
数据与权限类检查项
这一组回答「谁能碰什么」。权限最小化：新服务只开必要的库表与接口权限，临时提权是否已收回；数据链路：内网与云端的数据流向是否符合既定分界，脱敏是否在出边界前完成；日志策略：各类日志的保留期限与脱敏规则是否已配置生效，见日志的保留与合规是怎么平衡的？；审计就位：关键操作是否都会留痕，事后能不能按用户与时间段检索。
兜底与回退项
兜底项回答「出事怎么办」。回退方案：上一版本的回退路径是否验证过、回退要多久、回退期间数据是否兼容；停机预案：发布或应急时服务怎么停，优雅停机的流程是否演练过，见推理服务的优雅停机？内部门道在这；告警就绪：关键指标已接监控、阈值已设、通知能送达值班人；冷启动防护：新实例首次承接流量的预热措施是否安排，机制见冷启动是怎么消除的？预热，关键步骤一次讲清。清单最后留一栏签名区：执行人、复核人、执行时间各占一格，出了问题能直接回溯到当次的核对质量。
清单过完不等于万事大吉，上线后观察期内要保持随时可回退的状态，跨地域服务的上线节奏还要考虑分区放量，见多地域部署是怎么降延迟的？过程拆开看。
上线检查清单速查表
- 顺序：配置 → 数据权限 → 兜底回退 → 流量验证
- 配置四查：环境值、版本一致、资源余量、凭证就位
- 权限原则：最小化 + 数据分界 + 日志生效
- 兜底三件：回退路径、停机预案、告警就绪
- 执行方式：逐项打勾、双人复核、留档
上线检查快问快答三则
- 清单多长算合适？：以「每一项都能在几分钟内核完」为度，几十项分组的清单好过几百项的大杂烩，太长的清单没人认真过。
- 灰度上线还要走全量清单吗？：要，灰度只是放量策略，检查项一项不少，灰度期恰好用来复核清单里不好在预发验证的项。
- 用扣子或即梦AI搭的小应用也要这么隆重吗？：规模可以缩，骨架不能省，配置、权限、回退三组是底线，个人项目至少自己过一遍。
