10 线上验证与运营：发布不是终点¶

生产环境验证的目标不是“再点一遍”，而是 确认真实环境、真实配置、真实网络、真实数据下，用户流程仍然成立。它和开发环境的 E2E 使用同一套证据链，但约束更严、风险更高。

1. 线上验证的前提¶

1.1 必须已满足¶

1.2 测试账号与数据¶

原则：最小权限、专用租户、可清理、可识别。

账号：e2e-prod@example.com（专用，非个人账号）
租户：e2e-prod-tenant
数据前缀：e2e-<run_id>-<story_id>-

要求：

测试账号只拥有测试租户的权限；
不使用真实客户数据；
写操作创建的数据带前缀；
测试结束清理，或保留 24 小时后自动清理；
不测试不可逆操作（删除真实数据、发送真实短信/邮件给真实用户、支付扣款）。

1.3 只读优先¶

操作	生产是否允许	说明
登录/登出	✅	用测试账号
查看列表/详情	✅	只读
创建测试数据	⚠️	专用租户 + 前缀 + 清理
修改/删除测试数据	⚠️	仅限自己创建的测试数据
修改/删除真实数据	❌	禁止
支付/退款	❌	禁止
群发通知	❌	禁止
修改权限/配置	❌	禁止

2. 线上 E2E 的流程¶

1. 记录环境信息（URL、版本、commit、部署时间）
2. 打开 Chrome（有头或连接宿主 Chrome）
3. 登录测试账号
4. 按用户故事逐步执行
5. 每一步：
   - 动作
   - JS 断言
   - 关键截图
   - 记录 manifest
6. 检查控制台/网络/性能
7. 清理测试数据
8. 生成 Word 报告
9. 人走查 + 签字
10. 更新 CSV：verified_prod

2.1 与开发环境 E2E 的差异¶

维度	dev	prod
数据	合成	真实（但只用测试租户）
写操作	自由	受限、可清理
登录	测试账号	测试账号 + 可能 2FA
失败处理	直接修	先回滚/关开关，再修
证据	必需	必需 + 更严格脱敏
权限	开发者	最小权限
监控	可选	必须

2.2 生产 E2E 提示词¶

你是生产验证工程师。请用 Chrome MCP 在生产环境验证 US-004“创建任务”。

环境：
- 前端：https://app.example.com
- API：https://api.example.com/api/v1
- 版本：<commit/tag>
- 测试账号：e2e-prod@example.com（凭证从环境变量读取，不写入报告）
- 测试租户：e2e-prod-tenant
- 数据前缀：e2e-<run_id>-US004-

安全约束（必须遵守）：
1. 只操作测试租户和带前缀的测试数据。
2. 不删除/修改任何非本次创建的数据。
3. 不触发支付、群发、真实通知。
4. 不修改权限、配置、用户资料。
5. 截图和报告中不得出现令牌、密码、真实个人信息。
6. 遇到意外的真实数据，立即停止并报告。

步骤：
1. 登录，断言进入工作台。
2. 进入测试项目。
3. 创建任务（正常路径），断言 201、卡片出现。
4. 空标题提交，断言校验错误。
5. 无权限账号访问，断言 403 提示。
6. 刷新页面，断言数据持久化。
7. 清理本次创建的测试数据（或记录待清理）。
8. 检查控制台错误、网络 5xx、关键请求耗时。
9. 生成 docs/04-qa/manifests/US-004-prod.json 和截图。
10. 生成 docs/04-qa/e2e-report-prod-<date>.docx。
11. 输出摘要，不贴大段 HTML。

任何一步失败：
- 保留截图/控制台/网络/request_id；
- 停止后续写操作；
- 报告是否需要回滚或关闭功能开关。

3. 线上验证检查项¶

3.1 功能¶

3.2 技术¶

3.3 数据¶

3.4 可观测性¶

日志能按 request_id 查到
错误日志有上下文
指标有数据
告警通道可用

4. 线上监控与告警¶

4.1 四个黄金指标¶

指标	含义	关注
延迟	请求耗时	P50/P95/P99
流量	QPS/请求量	突增/突降
错误	5xx/业务错误率	阈值告警
饱和度	CPU/内存/连接池/磁盘	容量瓶颈

4.2 业务指标¶

登录成功率；
任务创建成功率；
关键流程转化率；
每个租户的错误率；
第三方依赖可用性。

4.3 告警原则¶

告警必须可行动；
不要为每个指标都设告警；
分级：P0 电话/即时消息，P1 工作时间，P2 日报；
告警要有 runbook；
定期演练。

5. 事故响应¶

5.1 发现¶

监控告警；
用户反馈；
线上 E2E 失败；
日志异常。

5.2 处置顺序¶

1. 确认影响面和严重度
2. 立即止损（回滚/关开关/限流/降级）
3. 保留证据（日志、指标、请求 ID、截图）
4. 通知相关人
5. 修复
6. 验证
7. 复盘

先止损，再定位。 不要一边故障一边让 AI 大改代码。

5.3 回滚¶

# ECS 示例：切回上一个任务定义
aws ecs update-service \
  --cluster "$CLUSTER" \
  --service "$SERVICE" \
  --task-definition "$PREVIOUS_TASK_DEF" \
  --region "$AWS_REGION"

回滚后：

验证健康检查；
跑冒烟；
确认数据一致性；
记录回滚原因和时间。

5.4 事故记录模板¶

# 事故记录 INC-20261105-01

## 概要
- 时间：2026-11-05 10:12 - 10:35
- 影响：部分用户无法创建任务
- 严重度：P1
- 状态：已恢复

## 时间线
- 10:12 告警：5xx 上升
- 10:15 确认影响面
- 10:18 回滚到上一版本
- 10:25 错误率恢复
- 10:35 完成验证

## 根因
数据库迁移新增 NOT NULL 列，但旧代码未写入默认值。

## 修复
- 回滚
- 补默认值 + 回归测试
- 迁移改为 expand-contract

## 改进项
- [ ] 迁移检查清单增加“旧代码兼容性”
- [ ] 发布前在生产同构环境跑迁移演练
- [ ] 增加 5xx 告警阈值

6. 线上验收报告¶

6.1 与开发报告的区别¶

环境信息更详细（域名、版本、部署时间、CDN）；
数据脱敏更严格；
增加安全/性能检查；
增加监控截图/指标；
结论明确“是否可对外发布”。

6.2 报告结构¶

封面
  标题：US-004 创建任务 - 生产环境验收报告
  版本 / 环境 / 时间 / 结果

1. 发布信息
2. 测试范围
3. 环境与配置
4. 测试账号与数据（脱敏）
5. 步骤与截图
6. 控制台/网络/性能
7. 安全与合规检查
8. 缺陷与处理
9. 监控基线
10. 结论与签字
附录：request_id、清理记录

6.3 结果判定¶

结果	条件
通过	所有 P0/P1 通过，无 P0/P1 缺陷，监控正常
有条件通过	有 P2 问题，不影响核心流程，有明确修复计划
不通过	任何 P0/P1 失败，或存在数据/安全问题

不通过就必须回滚或关闭功能开关，不能“先这样上线”。

7. 发布后运营¶

7.1 发布后 24 小时¶

每小时看一次错误率/延迟；
关注用户反馈；
检查日志中的新异常；
确认数据写入正确；
确认备份/清理任务正常。

7.2 发布后一周¶

对比发布前后指标；
收集用户反馈；
修复小问题；
更新文档；
复盘流程。

7.3 持续验证¶

合成监控：定时跑关键流程（登录、创建任务）；
真实用户监控（RUM）；
错误追踪（Sentry 等）；
定期跑 Chrome MCP E2E（例如每天一次）；
证书/域名/依赖到期提醒。

8. 从线上反馈回到需求¶

线上不是终点，而是下一轮需求的输入：

线上反馈
  → 分类（bug/体验/新需求/性能/安全）
  → 评估优先级
  → 进入 user-story.csv（新故事或修改现有）
  → 回到需求阶段

要求：

每个反馈有记录；
不明确的需求先访谈；
紧急 bug 走 hotfix 流程；
重要变更重新走门禁；
复盘结论落到文档，不只在聊天里。

9. Hotfix 流程¶

生产紧急问题时，可以走简化流程，但不能跳过验证：

1. 确认问题和影响面
2. 从 main 拉 hotfix 分支
3. 写复现测试
4. 修复
5. 单元/集成测试
6. 人工审查（至少一人）
7. 部署
8. 线上验证（最小范围）
9. 合并回 main
10. 补文档和复盘

Hotfix 不是“直接改生产”。它只是缩短流程，不是取消流程。

10. 本章交付清单¶

下一章：11 完整实战：从 0 到 1 做一个任务系统 —— 把所有章节串成一个真实项目。