上线前别急着庆祝
每次新系统上线，总有人迫不及待想点杯奶茶庆祝。可往往刚切流量，用户就炸锅了：登录不上、页面卡死、数据对不上。其实问题多半出在部署验证没做到位。别把验证当成走流程，它其实是最后一道安全网。
从最小单元开始测
别一上来就跑全流程。先把新部署的服务单独拎出来，用工具模拟请求。比如一个用户登录接口，可以用 curl 或 Postman 先打几下：
curl -X POST http://new-api.example.com/login \n-H "Content-Type: application/json" \n-d '{"username": "test", "password": "123456"}'看返回是不是 200，响应时间有没有异常。这步就像炒菜前先尝盐，简单但关键。
双端数据比对不能少
我们公司上个月升级订单系统，新旧两套并行跑了一周。每天定时拉一次数据，比对同一时间段的订单总数、金额、状态分布。发现第三天有个小偏差——退款单少了两条。一查是消息队列丢了 ACK，及时修了，没影响正式切换。
你可以写个脚本自动比对：
SELECT status, COUNT(*) FROM orders \nWHERE create_time BETWEEN '2024-04-01 00:00:00' AND '2024-04-01 23:59:59' \nGROUP BY status;监控要提前埋好
新服务还没上线，监控就得先看着。CPU、内存、请求延迟这些基础指标要接进 Grafana，错误日志往 ELK 里导。有次我们漏配了慢查询日志，结果数据库拖垮了整个服务，等发现时已经超时五分钟了。
建议加一条“健康检查”接口，比如 /healthz，返回 JSON 格式的状态：
{"status": "ok", "dependencies": {"db": "up", "redis": "up"}}让用户“无意中”参与测试
全量上线前，可以先放 5% 的真实流量进来。用 Nginx 做分流：
upstream backend_old { server 10.0.1.10:8080; }\nupstream backend_new { server 10.0.1.20:8080; }\n\nlocation / {\n proxy_pass http://backend_old;\n if ($http_user ~* "beta-tester") {\n proxy_pass http://backend_new;\n }\n}让内部员工或种子用户带上特定 Header，其他人都走老路。这样既不影响大众，又能拿到真实场景反馈。
回滚预案写纸上
别只在脑子里想“不行就回滚”。把具体命令写成文档，比如：
- 恢复旧版镜像：
kubectl set image deployment/app-web app=registry/app:v1.8.0 - 切换数据库读写主从
- 通知客服准备话术
真出事时没人有空翻笔记，纸质清单反而最快。