项目上线前必须检查的清单：避开线上重大事故
很多线上事故，事后复盘时都会冒出一句："上线前要是多看一眼就好了。"
真正稳定的系统，不是靠"上线后救火"，而是靠上线前的 checklist。本文整理一份偏实战、可直接落地的前端 + 后端 + 运维通用上线检查清单，适合作为团队标准流程固化下来。
一、为什么需要上线前检查清单？
-
降低人为失误：人脑不可靠，流程才可靠。
-
缩短上线时间：不用临时想"还要检查什么"。
-
统一团队认知：新人也能按图索骥，不踩老坑。
-
减少回滚概率：把问题拦在发版前。
经验法则：一次认真的上线前检查，至少能挡住 60% 的线上低级事故。
二、通用必检项（所有项目都要看）
1. 变更内容核对
-
变更范围是否清晰：本次上线改了哪些模块、哪些接口、哪些配置？
-
是否有破坏性变更：字段删除、接口签名变化、返回结构变化？
-
是否向下兼容：旧版本客户端 / 旧版本服务能否正常工作？
-
数据库变更是否可逆：SQL 是否可以回滚？DDL 是否支持回退？
-
配置文件是否遗漏：新增配置是否已写入配置中心 / K8s ConfigMap？
2. 发布计划与回滚方案
-
发布顺序是否明确：先发 DB？先发后端？先发前端？
-
回滚方案是否可执行：回滚 SQL、回滚镜像、回滚配置是否准备就绪？
-
回滚条件是否清晰：出现什么指标（错误率 > 1%、P99 > 2s）立即回滚？
-
灰度策略是否确定：按比例放量 / 按白名单放量 / 按机房放量。
3. 沟通与通知
-
相关方是否知情：产品、测试、运营、客服、上下游依赖方。
-
值班人员是否就位：上线期间谁盯盘？谁负责紧急处理？
-
发布窗口是否合理：避开业务高峰期、大促期、节假日。
三、后端重点检查清单
1. 数据库与存储
-
SQL 审核通过：无全表扫描、无索引缺失、无大分页。
-
索引是否生效 ：
explain确认命中索引，避免索引失效写法。 -
数据迁移脚本可回滚 ：
INSERT/UPDATE/DELETE都有逆向脚本。 -
连接池配置合理 ：
maxPoolSize与 DB 承载能力匹配。 -
大表变更低风险：是否使用 pt-online-schema-change / gh-ost。
-
慢 SQL 已验证：核心接口 SQL 在预发环境已跑过 explain。
2. 缓存与 MQ
-
缓存 Key 设计合理：无 Big Key、Hot Key，Key 有过期时间。
-
缓存穿透/击穿防护：空值缓存、布隆过滤器、互斥锁。
-
MQ 消息幂等：消费者支持重复消费，不丢不重。
-
消息 TTL 与死信队列：防止消息无限堆积。
-
消费逻辑轻量化：单条消息处理耗时可控（< 100ms 为佳）。
3. 接口与服务治理
-
超时设置合理：下游调用超时 < 接口总 SLA。
-
重试策略安全：写接口不重试，读接口重试 ≤ 1 次。
-
熔断与降级开关：关键依赖有熔断规则，非核心功能可降级。
-
限流配置到位：QPS 限流、并发限流、用户级限流。
-
线程池/连接池监控：有告警，阈值设置合理。
4. 日志与监控
-
日志级别正确：生产环境无 DEBUG 日志。
-
日志内容脱敏：手机号、身份证、密码、Token 已脱敏。
-
关键指标有监控：QPS、RT P99、错误率、线程池使用率。
-
告警规则有效：告警接收人正确，阈值不过于敏感或迟钝。
-
TraceId 全链路打通：便于定位问题。
四、前端重点检查清单
1. 兼容性
-
主流浏览器测试：Chrome / Safari / Firefox / Edge。
-
移动端适配：iOS / Android 主流机型、不同分辨率。
-
弱网环境验证：3G / 4G 下页面加载是否正常。
2. 性能与体验
-
首屏加载速度：是否做了懒加载、分包、CDN 加速。
-
静态资源缓存策略：hash 命名，避免缓存失效问题。
-
接口异常处理：loading、error toast、重试按钮。
-
兜底页 / 骨架屏：接口超时或失败时用户体验可接受。
3. 安全
-
XSS 防护：用户输入正确转义。
-
CSRF Token：关键操作携带 Token。
-
敏感信息不暴露：前端代码无密钥、无内部接口地址。
五、运维与基础设施检查清单
1. 部署与环境
-
预发环境验证通过：预发 = 生产（配置、数据量级、依赖）。
-
资源配额充足：CPU / 内存 / 磁盘 / 带宽预留足够余量（建议 ≥ 30%）。
-
健康检查接口正常 ：
/health、/ready返回 200。 -
优雅停机配置：SIGTERM 能正常回收连接、处理完存量请求。
2. 网络与安全
-
防火墙 / 安全组规则正确：端口、IP 白名单无误。
-
域名解析生效：DNS 已切流，TTL 调整合理。
-
HTTPS 证书有效：证书未过期，链完整，无浏览器警告。
-
跨域配置正确：CORS 白名单不过于宽松。
3. 灾备与高可用
-
多实例部署：至少 2 个副本，避免单点故障。
-
跨可用区部署：核心服务分布在不同 AZ。
-
备份可用：数据库、配置文件、关键数据有近期备份。
-
应急预案演练：主库挂了怎么切？Redis 挂了怎么降级？
六、数据与业务检查清单
1. 数据准确性
-
核心业务数据对账：订单数、支付金额、账户余额前后一致。
-
历史数据兼容：老数据在新逻辑下表现正常。
-
数据清洗脚本验证：修复脚本在预发环境跑过，结果符合预期。
2. 业务流程
-
核心路径回归：注册 → 下单 → 支付 → 发货 → 售后全流程验证。
-
边界条件测试：空数据、超量数据、异常状态流转。
-
权限控制验证：普通用户 / 管理员 / 内部员工权限隔离正确。
七、上线后的"黄金 10 分钟"
上线不是终点，上线后的前 10 分钟最关键：
-
监控大盘盯盘：错误率、RT、QPS、CPU、内存。
-
日志异常排查：是否有大量 ERROR / WARN。
-
核心接口抽样验证：手工调用关键接口，确认返回正常。
-
业务指标核对：订单量、支付成功率、UV/PV 是否符合预期。
-
用户反馈关注：客服群、舆情是否有异常投诉。
经验原则：上线后 10 分钟内发现问题，回滚成本最低。
八、把清单变成团队习惯
-
固化到发布流程中：发版前必须打钩，禁止"凭感觉上线"。
-
定期回顾与更新：每季度根据事故复盘补充新条目。
-
工具化：将部分检查项集成到 CI/CD（如 SQL 扫描、配置校验）。
-
新人必读：入职培训中包含上线 checklist。
九、一句话总结
上线前多花 15 分钟检查，可能省下 15 小时的事故复盘。
清单不是束缚，而是对线上敬畏心的体现。