prod测评：上线前最容易踩的坑
prod测评不该只跑一次接口测速，更不能看到页面能打开就宣布过关。靠谱的检查要覆盖发布、权限、监控、备份和回滚。下面用问答方式拆解几个高频坑，每个问题都给出可执行的验证动作，适合上线前照着逐项核对，也适合故障后补课。
问题一：健康检查通过就算可用吗？
不算。很多/health接口只返回固定的200，数据库断开、缓存失效时照样显示绿色。prod测评至少要分两层：存活检查只确认进程没挂，就绪检查验证关键依赖可连接。支付、登录等核心路径还应设置定时合成请求。
另一个坑是只盯平均响应时间。100个请求里有95个很快、5个卡十秒，平均值可能仍然好看，用户却已经明显掉线。应同时看P95、P99、错误率和吞吐量，并按接口拆分，别让轻量健康检查稀释真实数据。
问题二：有自动备份就稳了吗？
未必。备份任务显示成功，只能证明文件生成过，不能证明文件完整、密钥可用或恢复步骤正确。测评时要把备份恢复到隔离环境，检查表数量、关键记录和时间点，再记录完整恢复耗时。业务能接受停机一小时，就不能拿三小时恢复方案糊弄。
还要避开同区域、同账号存放的坑。误删账号或区域故障可能让主库和备份一起消失。重要业务至少保留跨区域或独立账户副本，并设置不可变保留期，防止勒索或误操作连历史版本一起清掉。
问题三：管理员账号共享方便吗？
方便排障，也方便把责任线索彻底抹掉。多人共用root账号后，谁改了配置、谁导出了数据都难追踪。正确做法是每人独立身份、多因素认证、按角色授权；临时高权限设置到期时间，并把关键操作写入不可修改的审计日志。
测评权限时不要只看人员名单，还要测试普通账号能否越权调用接口、旧员工令牌是否失效、CI机器人是否拥有多余权限。尤其注意对象存储：公开读写配置错误时，应用本身完全正常，数据却可能直接暴露。
问题四：回滚按钮为什么不可靠？
按钮通常只能退应用版本，退不了已经执行的数据迁移、消息格式和第三方配置。常见坑是新版本删除数据库列，发布失败后旧版本恢复，却因字段不存在继续报错。上线前应实际演练一次回滚，并确认旧版能读取新版产生的数据。
一份合格的prod测评记录要写清版本号、执行时间、指标截图、失败条件和负责人。只写“测试通过”几乎没有复用价值。最终门槛也要量化，例如错误率超过1%自动停止放量、P95上涨30%触发回滚，现场才不会靠感觉争论。
常见问题
prod测评主要测哪些项目？
至少覆盖核心业务路径、性能分位值、依赖故障、权限边界、告警触达、备份恢复和版本回滚七类项目。
可以直接在prod做压力测试吗？
不要在未隔离流量、未设上限时直接压测。优先在近似环境测试；必须在线测时，应使用专用账号、限速、低峰窗口和明确的停止阈值。
prod测评多久做一次？
核心冒烟测试应随每次发布执行；恢复演练和权限复核可按季度进行；重大架构、数据库或供应商变更后应立即补测。