烟测要解决什么
迁移切换后立刻做业务烟测，目的是在放量之前用最小代价回答一个问题：这套环境真的能承接业务吗。烟测不是把功能全测一遍，而是挑出「一旦不通就必须回退」的关键路径——登录认证、核心业务闭环、数据对账、外设与后台任务，逐项跑真实动作并留下结论。
基本信息
| 覆盖范围 | 登录认证、核心流程、数据、外设、后台任务、报表 |
|---|---|
| 执行方式 | 按清单逐项真实触发，不做替代性验证 |
| 判定要求 | 每项写明通过标准与责任人 |
| 与回退绑定 | 超时未通过立即按预案回退 |
| 基础连通 | 健康检查、服务状态、端口监听 |
典型使用场景
- 系统切换完成后、放量之前的业务验收
- 重大变更（版本升级、数据库迁移）后的回归确认
- 与业务方共同确认「什么算通过」的标准
- 作为回退判定的输入依据
- 把当次发现的问题沉淀进下一次的清单
基础连通与抽查
基础连通与抽查
curl -s -o /dev/null -w '%{http_code} %{time_total}s' http://app.example.com/health; echo
systemctl status app-web --no-pager | head -5 # 应用服务状态
ss -lntp | grep -E ':(80|443)' # 端口监听确认
ksql -U appuser -p 54321 -d appdb -c "SELECT count(*) FROM orders;" # 关键表行数比对基线
journalctl -u app-web --since '10 min ago' | grep -iE 'error|exception' | tail
# 外设与后台任务：按清单现场真实触发，逐项记录结论与执行人烟测项示例
| 类别 | 检查点 | 验证方式 |
|---|---|---|
| 登录认证 | 本地账号、域账号、单点登录 | 各角色实际登录一次 |
| 核心流程 | 主业务闭环（下单、审核、归档） | 走一笔真实测试单 |
| 数据 | 关键表行数与抽样记录 | SQL count 与抽样比对 |
| 外设 | 打印、扫码、加密狗 | 现场真实触发 |
| 后台任务 | 定时任务、队列消费 | 看执行日志与积压量 |
| 报表 | 常用报表生成导出 | 导出并核对合计 |
烟测清单要提前与业务方确认通过标准并指定责任人：现场临时定义「什么算通过」，等于把判定权交给运气。
烟测窗口与回退窗口必须绑定：超过约定时限仍未通过就按预案回退，不要在现场长时间排障。