feat(ai-customer-service): add gate readiness verification and handoff docs

This commit is contained in:
Your Name
2026-05-06 09:39:33 +08:00
parent 087de4e102
commit 6c3474e23b
25 changed files with 2322 additions and 400 deletions

View File

@@ -0,0 +1,90 @@
# 灰度阶段最小 Dashboard
> 状态:已定义
> 用途:灰度 5% / 20% / 50% / 100% 放量时,值班工程师和 TechLead 必须看的单页观察面
---
## 1. 必须展示的 8 个指标
1. `Webhook 5xx 比例`
2. `Webhook reject 数`
3. `Ticket 创建量`
4. `Handoff 比率`
5. `Audit 写入失败数`
6. `Readiness down 次数`
7. `PostgreSQL 连接异常`
8. `单实例重启次数`
---
## 2. 推荐布局
### 第一行:放量门禁
- Webhook 5xx 比例
- Audit 写入失败数
- PostgreSQL 连接异常
- Readiness down 次数
这些指标用于判断:**是否必须停止放量或立即回滚**
### 第二行:业务链路健康
- Ticket 创建量
- Handoff 比率
- Webhook reject 数
这些指标用于判断:**是否出现隐性降级或业务异常漂移**
### 第三行:实例稳定性
- 单实例重启次数
- 当前灰度比例
- 当前版本
- 最近一次 Gate B / 回滚演练记录链接
---
## 3. 颜色规则
| 指标 | 绿色 | 黄色 | 红色 |
|------|------|------|------|
| Webhook 5xx | `<= 0.5%` | `0.5% ~ 1%` | `> 1%` |
| Webhook reject 数 | 在预期基线内 | 高于基线但 <20% | `>= 20%` |
| Ticket 创建量 | 与 handoff 基本匹配 | 明显下降 | handoff 存在但 ticket 持续为 0 |
| Handoff 比率 | `<= 15%` 或接近基线 | `15% ~ 25%` | `> 25%` 或高于基线 `2x` |
| Audit 写入失败数 | `0` | 短时抖动 | `> 0` 持续 5 分钟 |
| Readiness down 次数 | `0` | 偶发 | 连续 3 次 |
| PostgreSQL 连接异常 | `0` | 短时抖动 | 持续异常 |
| 单实例重启次数 | `0` | `1~2 / 10min` | `>2 / 10min` |
---
## 4. Dashboard 直接用途
值班期间,只允许做三类决策:
1. **继续放量**
前提:所有门禁指标为绿色,且观察窗口已满足
2. **冻结当前档位**
前提:出现黄色趋势,但未触发红色门禁
3. **立即回滚**
前提:任一核心门禁指标变红
---
## 5. 当前状态
这份 dashboard 文档已经定义完成,但真实共享预生产/灰度环境还需要补:
- 指标来源接线
- 展示面板
- 告警路由
在这些接线完成前,只能说:
> **Dashboard 设计已完成,运行时观察面尚未真正上线。**

View File

@@ -0,0 +1,122 @@
# AI-Customer-Service 灰度放行清单
> 版本v1.0
> 状态:灰度放行总门禁
> 用途:作为一页式放行清单,统一判断“是否允许进入灰度、是否允许继续放量、是否必须回滚”
---
## 1. 使用规则
- 任一 `阻断项` 未通过:**不得进入灰度**
- 任一 `回滚项` 触发:**立即回滚**
- 任一 `观察项` 异常:**冻结当前档位,不继续放量**
- 本清单的结论优先级高于口头判断
---
## 2. 代码级门禁
- [x] `go test ./... -count=1` 通过
- [x] `go test -race ./...` 通过
- [x] `go vet ./...` 通过
- [x] production 禁止 memory fallback
- [x] readiness 语义已与真实依赖对齐
- [x] 工单闭环语义已收口
- [x] 后台接口最小鉴权已启用
说明:
- 当前这些门禁已通过,属于**进入灰度准备的必要非充分条件**
---
## 3. Gate B 预生产门禁
- [x] `scripts/verify_preprod_gate_b.sh` 已建立
- [x] 本地/容器化 Gate B 预演通过
- [x] 真实 PostgreSQL migration 成功
- [x] signed webhook 联调通过
- [x] ticket / audit / dedup 入库可验证
- [x] `live` / `ready` 探针符合预期
- [x] 有验证记录:`docs/PREPROD_VERIFICATION_RECORD.md`
- [ ] 真实共享预生产环境已复跑同一脚本并留痕
阻断结论:
- **最后一项未完成前,不得宣称“真实预生产门禁已通过”**
---
## 4. Gate C 灰度门禁
- [x] 最小监控指标已定义
- [x] 告警阈值已定义
- [x] 灰度放量节奏已定义
- [x] 回滚触发条件已定义
- [x] 最小 dashboard 已定义
- [x] `scripts/verify_gate_c_rollback.sh` 已建立
- [x] 本地/容器化回滚演练已通过
- [x] 有验证记录:`docs/ROLLBACK_DRILL_RECORD.md`
- [ ] 真实共享预生产/灰度环境监控接线完成
- [ ] 真实共享预生产/灰度环境回滚演练完成并留痕
- [ ] 值班通知链路已确认
阻断结论:
- **最后三项未完成前,不得进入真实灰度放量**
---
## 5. 灰度放量节奏
| 阶段 | 流量比例 | 最短观察时间 | 进入条件 |
|------|----------|--------------|----------|
| Stage 1 | 5% | 30 分钟 | Gate B 已通过,核心门禁全绿 |
| Stage 2 | 20% | 2 小时 | Stage 1 稳定5xx / audit / DB 指标正常 |
| Stage 3 | 50% | 半天 | Stage 2 稳定handoff / ticket 指标正常 |
| Stage 4 | 100% | 次日 | Stage 3 稳定跨工作日,无新增 P0/P1 |
---
## 6. 继续放量判定
进入下一档前,必须同时满足:
- [ ] `webhook 5xx <= 0.5%`
- [ ] `webhook reject` 无异常升高
- [ ] `audit 写入失败数 = 0`
- [ ] `postgres 连接异常 = 0`
- [ ] `readiness down` 未持续发生
- [ ] `单实例重启次数 <= 2 / 10 分钟`
- [ ] `handoff 比率 <= 25%` 或未高于基线 `2x`
- [ ] `ticket 创建量` 与人工承载能力匹配
任一不满足:
- **冻结当前档位**
---
## 7. 立即回滚判定
满足任一项,立即回滚:
- [ ] `webhook 5xx > 5%` 持续 5 分钟
- [ ] PostgreSQL 异常导致 `ready` 持续失败
- [ ] `audit 写入失败数 > 0` 持续 5 分钟
- [ ] ticket 创建链路断裂
- [ ] 全量 readiness down
- [ ] 实例反复重启且影响服务
---
## 8. 当前总判定
当前状态:
- **代码级门禁:通过**
- **本地/容器化 Gate B通过**
- **真实共享预生产 Gate B未通过**
- **本地/容器化 Gate C 回滚演练:通过**
- **Gate C 灰度门禁:未通过**
因此当前唯一允许的结论是:
> **可以继续做共享预生产验证和灰度准备,但还不能进入真实灰度放量。**

View File

@@ -1,126 +1,133 @@
# DO-P1-1最小监控与告警闭环
> 状态:✅ 已交付
> 负责人:DevOps宰相代填
> 基准:P0 完成 Gate B 预生产验证
> 日期2026-05-04
> 状态:✅ 已定义,待在真实共享预生产/灰度环境接入
> 负责人:TechLead / DevOps
> 基准:Gate B 已完成本地/容器化预演Gate C 前必须落地最小观察面
---
## 一、监控覆盖矩阵
## 1. 目标
| 告警项 | 监控端点 | 阈值/判定条件 | 动作 |
|--------|----------|---------------|------|
| **5xx 错误激增** | `GET /actuator/health` 中 status≠UP或日志 level=ERROR | 5xx 占比 > 5% 持续 1min | 触发 PagerDuty / 日志告警 |
| **签名拒绝** | 业务日志中 `CS_AUTH_4031/4033/4034` code 出现 | 10 次 / 5min 窗口 | 记录安全事件,暂不阻塞 |
| **Handoff 异常** | `GET /api/v1/customer-service/webhook` 返回 `handoff=true` 率 | handoff=true 突增 3x 历史均值 | 记录人工介入事件 |
| **Ticket 未创建** | refund intent 触发后 10s 内 cs_tickets 无对应记录 | refund intent 但 ticket_id="" | 告警并记录异常 |
| **Audit 未写入** | ticket 创建后 5s 内 cs_audit_logs 无 `object_type=ticket` 记录 | audit_count 增量=0 | 告警 DB 写入问题 |
| **PostgreSQL 不可用** | `GET /ready` 中 postgres check ≠UP | postgres status= DOWN | 立即告警,影响 ready |
| **服务未就绪** | `GET /ready` 返回 non-200 或超时 3s | ready != 200 | 服务 restart 触发 |
| **服务挂了** | `GET /live` 返回 non-200 或超时 3s | live != 200 | K8s/Supervisor restart |
生产一期灰度阶段不追求“全量可观测平台一次到位”,只要求有一套**最小、可执行、能支持放量/回滚决策**的监控闭环。
本轮最小监控集只覆盖 8 个指标:
1. `webhook 5xx`
2. `webhook reject 数`
3. `ticket 创建量`
4. `handoff 比率`
5. `audit 写入失败数`
6. `readiness down 次数`
7. `postgres 连接异常`
8. `单实例重启次数`
---
## 二、监控接入方式
## 2. 最小指标定义
### 2.1 Kubernetes Probe存活 + 就绪)
```yaml
livenessProbe:
httpGet:
path: /live
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
failureThreshold: 3
```
### 2.2 Prometheus 指标暴露可选v1.1+
```
# 暴露端点
GET /metrics
# 关键指标
ai_cs_webhook_requests_total{status="success|reject|5xx"}
ai_cs_tickets_created_total
ai_cs_audit_logs_written_total
ai_cs_handoff_total
ai_cs_postgres_errors_total
ai_cs_session_active_gauge
```
### 2.3 日志聚合ELK/Loki
关键日志字段抓取:
```
level=ERROR AND msg="webhook request rejected"
level=ERROR AND msg="audit log write failed"
level=WARN AND msg="handoff ticket missing"
```
| 指标 | 定义 | 最低数据来源 | 说明 |
|------|------|--------------|------|
| Webhook 5xx | `POST /api/v1/customer-service/webhook*` 返回 5xx 的比例 | API 网关/Ingress 访问日志或应用日志 | 灰度放量的首要阻断指标 |
| Webhook reject 数 | 因签名、时间戳、非法 body 被拒绝的请求数 | `CS_AUTH_4031/4032/4033/4034``CS_REQ_*` 日志或审计 | 区分“攻击/误配置”和“服务不可用” |
| Ticket 创建量 | 每 5 分钟新建工单数 | `cs_tickets` 表或应用埋点 | 与 handoff 比率配合判断主链健康 |
| Handoff 比率 | `handoff=true` 会话数 / 总 webhook 请求数 | webhook 结果日志、审计或 DB | 反映机器人有效性与故障降级情况 |
| Audit 写入失败数 | audit 写入失败事件数 | 应用 ERROR 日志 | 任一增长都需要关注 |
| Readiness down 次数 | `ready` 探针失败次数 | K8s probe / LB 健康检查 / 外部探测 | 用于摘流与自动回滚判断 |
| PostgreSQL 连接异常 | DB ping/query error 次数 | `ready` 检查、应用 ERROR、连接池错误 | Phase 1 的核心依赖告警 |
| 单实例重启次数 | 单个实例在窗口期内重启次数 | K8s event / systemd / 容器平台 | 判断二进制稳定性和资源问题 |
---
## 三、告警阈值配置Prometheus AlertManager 风格)
## 3. 告警阈值与动作
```yaml
groups:
- name: ai-customer-service
rules:
- alert: HighErrorRate
expr: rate(ai_cs_webhook_requests_total{status="5xx"}[1m]) / rate(ai_cs_webhook_requests_total[1m]) > 0.05
for: 1m
labels:
severity: critical
annotations:
summary: "AI-CS 5xx 错误率超过 5%"
### 3.1 必须可执行的阈值
- alert: PostgresDown
expr: ai_cs_postgres_errors_total > 0
for: 30s
labels:
severity: critical
| 指标 | 阈值 | 持续时间 | 级别 | 动作 |
|------|------|----------|------|------|
| Webhook 5xx | `> 1%` | 5 分钟 | P1 | 立即停止继续放量,触发回滚评估 |
| Webhook 5xx | `> 5%` | 5 分钟 | P0 | 立即回滚当前灰度版本 |
| Webhook reject 数 | `> 5%` 且以 `4031/4034` 为主 | 10 分钟 | P2 | 检查上游签名配置,不自动回滚 |
| Webhook reject 数 | `> 20%` | 10 分钟 | P1 | 暂停放量,升级为渠道接入故障 |
| Ticket 创建量 | 灰度期内 handoff 明显存在,但连续 10 分钟 `ticket 创建量 = 0` | 10 分钟 | P1 | 判定工单主链异常,停止放量 |
| Handoff 比率 | `> 25%` 或高于过去 24h 基线 `2x` | 30 分钟 | P2 | 检查意图识别/依赖故障/降级路径 |
| Audit 写入失败数 | `> 0` | 5 分钟 | P1 | 停止放量,优先排查审计链路 |
| Readiness down 次数 | 单实例连续 3 次失败 | 3 个探针周期 | P1 | 从灰度池摘流量 |
| PostgreSQL 连接异常 | `> 0` 且影响 ready | 1 分钟 | P0 | 立即停止放量,必要时回滚 |
| 单实例重启次数 | 单实例 `> 2` 次 | 10 分钟 | P2 | 冻结当前比例,排查资源/崩溃问题 |
- alert: TicketCreationDrop
expr: rate(ai_cs_tickets_created_total[5m]) == 0 AND rate(ai_cs_webhook_requests_total[5m]) > 0.1
for: 2m
labels:
severity: warning
### 3.2 放量前置条件
- alert: AuditLogWriteFailure
expr: increase(ai_cs_audit_logs_written_total[5m]) == 0 AND increase(ai_cs_tickets_created_total[5m]) > 0
for: 1m
labels:
severity: critical
```
进入下一个灰度档位前,必须同时满足:
1. 最近一个观察窗口内 `webhook 5xx <= 0.5%`
2. `audit 写入失败数 = 0`
3. `postgres 连接异常 = 0`
4. 没有实例因 `readiness down` 被持续摘流
5. `ticket 创建量``handoff 比率` 没有出现异常偏移
---
## 四、最小化监控检查清单(部署时必检)
## 4. 指标落地方式
- [ ] **就绪探针**`curl http://localhost:8080/ready` → 200 + `postgres:UP`
- [ ] **存活探针**`curl http://localhost:8080/live` → 200
- [ ] **日志告警**ERROR level 日志出现时触发监控告警
- [ ] **PG 连接**:每分钟 check `/ready` 中 postgres status
- [ ] **Handoff 率**:每 5 分钟比对 `webhook_count` vs `handoff_count`
- [ ] **Ticket 漏单**refund intent 触发后 10s 内查 DB 确认 ticket 存在
- [ ] **Audit 漏写**ticket 创建后 5s 内查 `cs_audit_logs` 确认记录
当前仓库还没有 Prometheus 指标端点,因此本轮按“两层实现”定义:
### 4.1 Gate C 前最低可接受方案
- Ingress / API Gateway access log 统计:
- webhook 请求总量
- webhook 5xx
- 应用日志统计:
- `CS_AUTH_403*`
- `audit write failed`
- `webhook process failed`
- `postgres` 相关错误
- 数据库 SQL 统计:
- `cs_tickets` 新增量
- `cs_audit_logs` 指定 action 数量
- `cs_message_dedup` 去重记录数
- 探针统计:
- `live`
- `ready`
### 4.2 推荐目标方案
后续在不改变本轮门禁的前提下,可以升级为:
- Prometheus metrics
- Alertmanager 路由
- Grafana 灰度大盘
- Loki / ELK 日志聚合
---
## 五、故障自愈策略
## 5. 最小告警路由
| 事件 | 通知对象 | 方式 | 时限 |
|------|----------|------|------|
| P0DB 异常 / 5xx > 5% | 值班工程师 + TechLead | 电话 + 飞书 | 5 分钟内响应 |
| P15xx > 1% / audit 失败 / readiness 异常 | 值班工程师 | 飞书 + 工单 | 15 分钟内响应 |
| P2handoff 异常升高 / reject 异常 | 值班工程师 + 产品/运营 | 飞书 | 30 分钟内响应 |
---
## 6. 当前落地状态
| 项目 | 当前状态 | 结论 |
|------|----------|------|
| 指标定义 | 已完成 | ✅ |
| 告警阈值 | 已完成 | ✅ |
| Grafana/Prometheus 接入 | 未完成 | ⚠️ Gate C 前需至少完成最低可接受方案 |
| 真共享预生产环境监控联调 | 未完成 | ⚠️ |
| 回滚联动门禁 | 已定义,未演练 | ⚠️ |
---
## 7. 与灰度放量的关系
这份文档不是泛化监控说明,而是**灰度放量门禁文档**。
任何放量决策都必须引用:
- [GRAY_DASHBOARD_MINIMUM.md](/home/long/project/立交桥/projects/ai-customer-service/docs/GRAY_DASHBOARD_MINIMUM.md)
- [SERVICE_SLA.md](/home/long/project/立交桥/projects/ai-customer-service/prd/SERVICE_SLA.md)
- [GRAY_RELEASE_ROLLBACK_RUNBOOK.md](/home/long/project/立交桥/projects/ai-customer-service/prd/GRAY_RELEASE_ROLLBACK_RUNBOOK.md)
| 故障 | 自动处理 | 人工介入 |
|------|----------|----------|
| `/ready` 失败 3 次 | K8s 重启 Pod | 如果 5min 内仍失败,发告警 |
| PG 连接断开 | 服务 graceful shutdown等待 PG 恢复后自动重连 | 若 >10min 无自动恢复,发告警 |
| OOM / 内存泄漏 | OOMKiller 杀掉后K8s 重启 | 分析 heap profile |
| 磁盘满(审计日志) | — | 立即告警,人工清理 |

View File

@@ -2,7 +2,7 @@
> 来源:`docs/RECTIFICATION_REVIEW_REPORT_V2.md`
> 用途:按角色推动整改执行、跟踪状态、做阶段门禁验收
> 当前总状态:**第5件事已完成代码侧 P0 技术阻断已闭环,项目可进入预生产整改与联调阶段,但仍禁止按“生产可直接上线”口径放行**
> 当前总状态:**Task 1~7 已推进至“灰度门禁已定义”阶段;代码级、本地/容器化 Gate B、本地/容器化 Gate C 回滚演练已通过,但真实共享预生产 Gate B 与真实灰度环境演练仍未闭环,禁止按“可直接灰度上线”口径放行**
---
@@ -40,12 +40,12 @@
|---|---|---|---|---|---|---|---|
| XL-P1-1 | P1 | 统一 PM/TechLead/QA/DevOps 交付模板 | 小龙 | 角色交付模板 | 每份角色输出均含结论、证据、阻塞、下一阶段条件 | XL-P0-1 | 未开始 |
| XL-P1-2 | P1 | 增加关键修复后的实施漂移复核点 | 小龙 | 复核流程 | 每次关键修复后都有测试复跑、配置复核、状态更新 | XL-P0-2 | 已完成 |
| PM-P1-1 | P1 | 补上线运营观察指标与失败判定线 | PM | 文档更新 | 含 handoff、ticket、audit、ready、重启后数据等观察项 | PM-P0-1 | 未开始 |
| PM-P1-1 | P1 | 补上线运营观察指标与失败判定线 | PM | 文档更新 | 含 handoff、ticket、audit、ready、重启后数据等观察项 | PM-P0-1 | 已完成 |
| PM-P1-2 | P1 | 统一环境变量文档契约 | PM | 文档更新 | 仅使用代码真实变量名,不再写泛化别名 | TL-P0-3 | 已完成 |
| TL-P1-1 | P1 | 补 ticket/session 后台接口鉴权设计 | TechLead | 设计文档 | actor 来源不可伪造,接口 auth 模式明确 | TL-P0-3 | 未开始 |
| TL-P1-1 | P1 | 补 ticket/session 后台接口鉴权设计 | TechLead | 设计文档 | actor 来源不可伪造,接口 auth 模式明确 | TL-P0-3 | 已完成 |
| TL-P1-2 | P1 | 补多实例与恢复场景验证设计 | TechLead | 设计文档 / 测试计划 | 覆盖 dedup、多实例、重启一致性、migration 幂等 | TL-P0-2 | 未开始 |
| QA-P1-1 | P1 | 建立文档漂移检测检查项 | QA | QA 模板/报告更新 | 每次审查都校对代码 vs 文档 vs 测试状态 | QA-P0-1 | 已完成 |
| QA-P1-2 | P1 | 增加真实环境前置门禁 | QA | 预生产验证记录 | 启动、ready、migration、webhook、入库验证完成 | DO-P0-1, DO-P0-2 | 未开始 |
| QA-P1-2 | P1 | 增加真实环境前置门禁 | QA | 预生产验证记录 | 启动、ready、migration、webhook、入库验证完成 | DO-P0-1, DO-P0-2 | ✅ 本地容器化通过30+25 PASS |
| DO-P1-1 | P1 | 补最小监控与告警闭环 | DevOps | 告警配置/监控清单 | 覆盖 5xx、reject、handoff、ticket、audit、DB、ready | DO-P0-1 | ✅ 已完成 |
| DO-P1-2 | P1 | 补运行与回滚 runbook | DevOps | runbook 文档 | 覆盖启动失败、migration 失败、DB 不可用、auth 联调失败 | DO-P0-1 | ✅ 已完成 |
@@ -59,7 +59,7 @@
| TL-P2-2 | P2 | 提升 store/app 关键层测试覆盖 | TechLead | 测试与覆盖率报告 | store/app 关键层覆盖明显提升并覆盖异常场景 | TL-P1-2 | 进行中 |
| QA-P2-1 | P2 | 建立长期质量回归基线 | QA | 回归清单 | 关键链路、关键控制点形成常规回归项 | QA-P1-2 | 未开始 |
| PM-P2-1 | P2 | 完善数据保留、审计、运营复盘口径 | PM | 产品/运营文档 | 有保留策略、失败判定、复盘节奏 | PM-P1-1 | 未开始 |
| DO-P2-1 | P2 | 细化容量与可观测性建设 | DevOps | 容量规划与监控扩展文档 | 有容量阈值、趋势指标、扩容策略 | DO-P1-1 | 未开始 |
| DO-P2-1 | P2 | 细化容量与可观测性建设 | DevOps | 容量规划与监控扩展文档 | 有容量阈值、趋势指标、扩容策略 | DO-P1-1 | 进行中 |
| XL-P2-1 | P2 | 将整改执行纳入长期阶段复盘机制 | 小龙 | 复盘模板 | 每个阶段都有事实校准、漂移回收、责任追踪 | XL-P1-2 | 未开始 |
---
@@ -80,7 +80,7 @@
|---|---|---|---|
| PM-P0-1 | 修正文档上线口径 | P0 | 已完成 |
| PM-P0-2 | 明确 memory/dev/prod 约束 | P0 | 已完成 |
| PM-P1-1 | 补运营观察指标与失败线 | P1 | 未开始 |
| PM-P1-1 | 补运营观察指标与失败线 | P1 | 已完成 |
| PM-P1-2 | 统一环境变量文档契约 | P1 | 已完成 |
| PM-P2-1 | 完善审计/保留/复盘口径 | P2 | 未开始 |
@@ -90,7 +90,7 @@
| TL-P0-1 | 禁止 prod fallback 到 memory | P0 | 已完成 |
| TL-P0-2 | 收紧 readiness | P0 | 已完成 |
| TL-P0-3 | 配置契约基线 | P0 | 已完成 |
| TL-P1-1 | 后台接口鉴权设计 | P1 | 未开始 |
| TL-P1-1 | 后台接口鉴权设计 | P1 | 已完成 |
| TL-P1-2 | 多实例/恢复验证设计 | P1 | 未开始 |
| TL-P2-1 | 完整威胁建模 | P2 | 未开始 |
| TL-P2-2 | 提升关键层覆盖率 | P2 | 进行中 |
@@ -101,7 +101,7 @@
| QA-P0-1 | 重做 QA 门禁文档 | P0 | 已完成 |
| QA-P0-2 | 将核心风险列为 Critical | P0 | 已完成 |
| QA-P1-1 | 增加文档漂移检测 | P1 | 已完成 |
| QA-P1-2 | 增加真实环境前置门禁 | P1 | 未开始 |
| QA-P1-2 | 增加真实环境前置门禁 | P1 | ✅ 本地容器化通过30+25 PASS |
| QA-P2-1 | 建立长期回归基线 | P2 | 未开始 |
### 4.5 DevOps
@@ -111,7 +111,7 @@
| DO-P0-2 | 关键配置 fail-fast 部署标准 | P0 | ✅ 已完成 |
| DO-P1-1 | 最小监控与告警闭环 | P1 | ✅ 已完成 |
| DO-P1-2 | 运行与回滚 runbook | P1 | ✅ 已完成 |
| DO-P2-1 | 容量与可观测性细化 | P2 | 未开始 |
| DO-P2-1 | 容量与可观测性细化 | P2 | 进行中 |
---
@@ -131,12 +131,17 @@
- [x] audit / ticket 入库成功实测webhook → session → handoff → ticket → audit 全链路)
- [x] ready/live 符合预期(/actuator/health/ready → 200postgres checker → UP
- [x] 最小监控已接通(✅ `docs/MONITORING_ALERTING.md` 已交付,覆盖 8 项监控 + Prometheus 告警配置)
- [ ] 共享预生产环境已复跑 Gate B 并留痕
### Gate C生产灰度通过
- [x] 灰度指标、阈值、回滚条件清晰
- [x] 一页式灰度放行清单已建立
- [x] 本地/容器化回滚演练已通过
- [ ] 共享预生产/灰度环境监控接线完成
- [ ] 5% 灰度稳定
- [ ] handoff / ticket / audit 指标正常
- [ ] 无异常 5xx / reject 激增
- [ ] 回滚演练通过
- [ ] 真实共享预生产/灰度环境回滚演练通过
---
@@ -154,6 +159,12 @@
- `go vet ./...`
3. 验证结果:
- 上述命令本轮均已通过
4. 灰度门禁文件:
- `docs/GRAY_LAUNCH_CHECKLIST.md`
- `docs/MONITORING_ALERTING.md`
- `docs/GRAY_DASHBOARD_MINIMUM.md`
- `prd/GRAY_RELEASE_ROLLBACK_RUNBOOK.md`
- `docs/ROLLBACK_DRILL_RECORD.md`
---
@@ -163,3 +174,15 @@
2. 每完成一项,必须更新状态和证据
3. QA 不能在 P0 未清零前给出生产放行结论
4. 小龙负责最终事实校准,不接受“口头完成”
---
## 8. 当前最小结论
当前可以接受的唯一发布口径:
1. **代码级:通过**
2. **本地/容器化 Gate B通过**
3. **共享预生产 Gate B进行中**
4. **本地/容器化 Gate C 回滚演练:通过**
5. **Gate C 灰度放量:未通过**

View File

@@ -0,0 +1,107 @@
# PREPROD_VERIFICATION_RECORD.md
> 状态:已建立
> 最近一次更新2026-05-04
> 目标:沉淀 Gate B 预生产验证的可复跑证据,而不是口头结论
---
## 1. 验证范围
本记录对应 Task 5 的 Gate B 验证脚本:
- [scripts/verify_preprod_gate_b.sh](/home/long/project/立交桥/projects/ai-customer-service/scripts/verify_preprod_gate_b.sh)
脚本覆盖的检查项:
1. 环境变量完整性与 production 约束
2. PostgreSQL 连通性
3. migration 账本与基线版本检查
4. 当前源码构建与服务启动
5. `/actuator/health/live`
6. `/actuator/health/ready`
7. 带签名 webhook 请求
8. dedup 入库与重复消息抑制
9. ticket 创建 / 分配 / 解决 / 关闭
10. audit 入库验证
---
## 2. 最近一次实测记录
- 时间2026-05-04 18:50 CST
- 环境:本机容器化/本地 PostgreSQL 联调环境
- 基线提交:`65e48bc`
- 说明:本次验证基于当前工作区源码重新编译执行,不依赖仓库内旧二进制
- 运行 ID`gateb-20260504185024`
- 产物目录:`/tmp/ai-customer-service-preprod-gate-b/gateb-20260504185024`
执行命令:
```bash
AI_CS_RUNTIME_ENV=production \
AI_CS_ADDR=127.0.0.1:18080 \
AI_CS_POSTGRES_ENABLED=true \
AI_CS_POSTGRES_DSN='host=localhost port=5434 user=ai_cs password=ai_cs_secret dbname=ai_customer_service sslmode=disable' \
AI_CS_POSTGRES_MIGRATION_DIR='/home/long/project/立交桥/projects/ai-customer-service/db/migration' \
AI_CS_WEBHOOK_SECRET='gate-b-secret-20260504' \
AI_CS_WEBHOOK_TIMESTAMP_HEADER='X-CS-Timestamp' \
AI_CS_WEBHOOK_SIGNATURE_HEADER='X-CS-Signature' \
AI_CS_WEBHOOK_MAX_SKEW_SECONDS=300 \
scripts/verify_preprod_gate_b.sh
```
结果摘要:
- PASS 总数:`30`
- FAIL 总数:`0`
- 生成 ticket`0806e91f-f50a-4942-b263-f14a4ed5285e`
- 生成 session`9a468320-81c3-44fb-9707-9819dba16e94`
- 验证 message_id`gateb-20260504185024-message`
- 服务日志:`/tmp/ai-customer-service-preprod-gate-b/gateb-20260504185024/service.log`
关键通过项:
1. 当前源码可成功构建并启动为 production + postgres 模式
2. `live` / `ready` 探针均返回成功
3. 带 HMAC 签名的 webhook 请求返回 `200`
4. 首次 webhook 成功创建 `ticket``message_processed audit`
5. 相同 `message_id` 的重复 webhook 被 dedup且 dedup 表中仅保留一条记录
6. `assign -> resolve -> close` 工单闭环在 PostgreSQL 中成功落库
7. `assign / resolve / close` 两层 audit 都成功入库
---
## 3. 本次验证中暴露并修复的问题
在脚本首次联调过程中,暴露并修复了两个真实问题:
1. Gate B 脚本最初使用仓库内旧二进制,无法代表当前源码行为
已修复为:脚本默认先构建当前源码,再启动服务。
2. handler 层 audit 事件 ID 不是合法 UUID导致 PostgreSQL audit 写入静默失败
已修复文件:
- [audit_helper.go](/home/long/project/立交桥/projects/ai-customer-service/internal/http/handlers/audit_helper.go)
- [audit_helper_test.go](/home/long/project/立交桥/projects/ai-customer-service/internal/http/handlers/audit_helper_test.go)
这两项修复后Gate B 本地/容器化预演已全部通过。
---
## 4. 当前结论
### 已确认
- **本地/容器化 Gate B 预演:通过**
- **脚本化验证入口:已建立**
- **ticket / audit / dedup / health / migration已有可复跑证据**
### 仍未确认
- **真实共享预生产环境 Gate B尚未执行同脚本复跑**
- **Gate C 灰度监控 / 回滚演练:未完成**
因此当前正确结论是:
> **Gate B 脚本与本地/容器化联调证据已经建立并通过,但还不能把这直接等同于“真实预生产环境已经放行”。**

View File

@@ -23,6 +23,36 @@
2. **不具备直接生产上线条件。**
3. **更适合被定义为“Phase 1 后端骨架 + 最小工单闭环”,距离生产上线至少还差 3 个阶段。**
### 1.1 整改后状态更新2026-05-04 当日追加)
在本次 review 之后,已继续完成并验证:
1. 文档口径与配置契约收口
2. 后台最小鉴权落地
3. 工单 `assign -> resolve -> close` 语义收口
4. Gate B 预生产验证脚本建立并完成本地/容器化实测
5. 灰度最小监控、阈值、放量与回滚门禁文档建立
6. 一页式灰度放行清单建立
这意味着项目状态已经从“只有代码级可运行”提升到了:
> **代码级门禁通过 + 本地/容器化 Gate B 通过 + Gate C 门禁已定义,但真实共享预生产与真实灰度放量仍未通过。**
相应地,这份报告中的“生产放量准备度”需要更新为:
| 维度 | 初始判断 | 当前更新判断 |
|---|---:|---:|
| 代码级可信度 | 45% | 60% |
| 预生产可验证度 | 20% | 55% |
| 灰度放量准备度 | 20% | 40% |
但这仍然**不构成“允许灰度上线”**。当前主要剩余阻断是:
1. 共享预生产环境尚未复跑 Gate B 脚本
2. 共享预生产/灰度环境监控接线未完成
3. 回滚演练未完成
4. 首轮 5% 灰度稳定性尚无证据
## 2. 本次实际验证
本次实际执行并确认了以下检查:
@@ -365,3 +395,33 @@ PRD 的 in-scope 能力包含:
- **距离完整规划设计完成:约 25%**
- **距离生产可灰度上线:约 75% 的关键工作仍未闭环**
- **距离 PRD 全量目标上线:约 70%~80% 的业务能力仍未落地**
---
## 9. 2026-05-05 实测更新
### Gate B 本地/容器化验证(实测通过)
| 项目 | 值 |
|------|------|
| 运行 ID | `gateb-20260505101654` |
| PASS/FAIL | **30/0** |
| 验证范围 | postgres连通、migration账本、live/ready、webhook签名、dedup、ticket全链路(assign/resolve/close)、audit入库 |
### Gate C 回滚演练本地验证(实测通过)
| 项目 | 值 |
|------|------|
| 运行 ID | `gatec-rollback-20260505101646` |
| PASS/FAIL | **25/0** |
| 验证范围 | 源码构建、baseline启动、broken release退出、回滚重启、主链路恢复、dedup/audit/ticket验证 |
### 结论升级
| 维度 | 更新前 | 更新后 |
|------|--------|--------|
| 代码级可信度 | 60% | **75%** |
| 预生产可验证度 | 55% | **70%** |
| 灰度放量准备度 | 40% | **50%** |
**仍需线下验证**:真实共享预生产环境 Gate B + 灰度监控接线 + 5%灰度稳定性

View File

@@ -0,0 +1,127 @@
# ROLLBACK_DRILL_RECORD.md
> 状态:✅ 已完成实测
> 最近一次更新2026-05-05
> 目标:沉淀 Gate C 回滚演练的可复跑证据,而不是只保留 runbook 描述
---
## 1. 验证范围
本记录对应 Gate C 回滚演练脚本:
- [scripts/verify_gate_c_rollback.sh](/home/long/project/立交桥/projects/ai-customer-service/scripts/verify_gate_c_rollback.sh)
脚本覆盖的检查项:
1. 当前源码重新构建与 baseline 启动
2. baseline `live` / `ready` 探针成功
3. baseline signed webhook 联调成功
4. 模拟错误发布导致服务无法 ready
5. 立即回滚到 baseline 配置并重启
6. 回滚后 `live` / `ready` 恢复成功
7. 回滚后 signed webhook / dedup / ticket / audit 主链恢复成功
---
## 2. 实测记录2026-05-05
- 时间2026-05-05 10:16 CST
- 环境:本机容器化 + 本地 PostgreSQL端口 5434
- 基线提交:当前工作区最新源码
- 运行 ID`gatec-rollback-20260505101646`
- 产物目录:`/tmp/ai-customer-service-gate-c-rollback/gatec-rollback-20260505101646`
执行命令:
```bash
AI_CS_RUNTIME_ENV=production \
AI_CS_ADDR=127.0.0.1:18081 \
AI_CS_POSTGRES_ENABLED=true \
AI_CS_POSTGRES_DSN='host=localhost port=5434 user=ai_cs password=ai_cs_secret dbname=ai_customer_service sslmode=disable' \
AI_CS_POSTGRES_MIGRATION_DIR='/home/long/project/立交桥/projects/ai-customer-service/db/migration' \
AI_CS_WEBHOOK_SECRET='gate-c-secret-20260505' \
AI_CS_WEBHOOK_TIMESTAMP_HEADER='X-CS-Timestamp' \
AI_CS_WEBHOOK_SIGNATURE_HEADER='X-CS-Signature' \
AI_CS_WEBHOOK_MAX_SKEW_SECONDS=300 \
scripts/verify_gate_c_rollback.sh
```
结果摘要:
| 指标 | 值 |
|------|------|
| PASS 总数 | **25** |
| FAIL 总数 | **0** |
| baseline message_id | `gatec-rollback-20260505101646-baseline-message` |
| rollback message_id | `gatec-rollback-20260505101646-rollback-message` |
| rollback ticket_id | `a2307c4f-0a2c-406c-ad19-e9ebfe927d40` |
| rollback session_id | `79447f0d-6ca4-4d3f-99ee-e0a6df311731` |
| baseline 日志 | `/tmp/ai-customer-service-gate-c-rollback/gatec-rollback-20260505101646/baseline-service.log` |
| broken release 日志 | `/tmp/ai-customer-service-gate-c-rollback/gatec-rollback-20260505101646/broken-service.log` |
| rolled-back 日志 | `/tmp/ai-customer-service-gate-c-rollback/gatec-rollback-20260505101646/rolled-back-service.log` |
关键通过项25/25
1. ✅ 当前源码成功构建
2. ✅ baseline 服务启动pid=`2064155`
3. ✅ baseline `live` + `ready` 探针通过
4. ✅ baseline signed webhook HTTP 200
5. ✅ baseline webhook response `received=true`
6. ✅ baseline webhook response `handoff=true`
7. ✅ baseline 服务正常停止
8. ✅ broken release 进程启动(模拟错误发布)
9. ✅ broken release 进程按预期退出never became ready
10. ✅ 回滚重启后服务启动pid=`2064338`
11. ✅ 回滚后 `live` + `ready` 探针通过
12. ✅ 回滚后 signed webhook HTTP 200
13. ✅ 回滚后 webhook response `received=true`
14. ✅ 回滚后 webhook response `handoff=true`
15. ✅ 回滚后 webhook 返回 `ticket_id` + `session_id`
16. ✅ 回滚后 webhook 创建 `open` 状态工单
17. ✅ 回滚后 dedup 行持久化
18. ✅ 回滚后 `message_processed` audit 持久化
19. ✅ 回滚后工单关联 session 验证通过
20. ✅ gate-c rollback drill 整体通过
---
## 3. Gate B 实测记录2026-05-05 同轮)
- 时间2026-05-05 10:16 CST
- 运行 ID`gateb-20260505101654`
- 产物目录:`/tmp/ai-customer-service-preprod-gate-b/gateb-20260505101654`
| 指标 | 值 |
|------|------|
| PASS 总数 | **30** |
| FAIL 总数 | **0** |
| ticket_id | `b183631d-e551-47c5-a719-f0f0f3d1adba` |
| session_id | `41bcaf30-4ac8-48cb-844c-a87a582e9429` |
| message_id | `gateb-20260505101654-message` |
关键通过项30/30构建、postgres 连通、migration 账本、live/ready、webhook 签名、dedup、ticket assign/resolve/close 全链路、audit 入库。
---
## 4. 当前结论
### ✅ 已确认
- **本地/容器化 Gate B通过30/30 PASS**
- **本地/容器化 Gate C 回滚演练通过25/25 PASS**
- **真实 PostgreSQL 工单闭环assign → resolve → close已验证**
- **审计日志多层持久化workflow store + handler已验证**
- **回滚后主链路完全恢复**:已验证
### ⚠️ 仍未确认
- **真实共享预生产环境 Gate B尚未执行同脚本复跑**
- **真实共享预生产/灰度环境监控接线:未完成**
- **5% 灰度稳定性:未执行**
> 本次结论已从"脚本已建立"升级为"本地/容器化实测通过"。但真实共享预生产和灰度环境仍需单独验证,不能混淆为同一结论。
---
*最后更新2026-05-05 by 宰相*

View File

@@ -7,6 +7,49 @@
---
## 0. Gate B 推荐入口
预生产 Gate B 不再建议靠零散手工命令拼接验证。优先使用:
- [scripts/verify_preprod_gate_b.sh](/home/long/project/立交桥/projects/ai-customer-service/scripts/verify_preprod_gate_b.sh)
- 最近一次实测记录:[PREPROD_VERIFICATION_RECORD.md](/home/long/project/立交桥/projects/ai-customer-service/docs/PREPROD_VERIFICATION_RECORD.md)
- Gate C 回滚演练入口:[scripts/verify_gate_c_rollback.sh](/home/long/project/立交桥/projects/ai-customer-service/scripts/verify_gate_c_rollback.sh)
- 最近一次回滚演练记录:[ROLLBACK_DRILL_RECORD.md](/home/long/project/立交桥/projects/ai-customer-service/docs/ROLLBACK_DRILL_RECORD.md)
脚本会完成:
1. 环境变量完整性检查
2. PostgreSQL 连通性检查
3. migration 基线检查
4. 当前源码构建与服务启动
5. `live` / `ready` 探针检查
6. signed webhook 联调
7. dedup 入库验证
8. ticket / audit 入库闭环验证
推荐执行方式:
```bash
AI_CS_RUNTIME_ENV=production \
AI_CS_ADDR=127.0.0.1:18080 \
AI_CS_POSTGRES_ENABLED=true \
AI_CS_POSTGRES_DSN='host=localhost port=5434 user=ai_cs password=ai_cs_secret dbname=ai_customer_service sslmode=disable' \
AI_CS_POSTGRES_MIGRATION_DIR="$PWD/db/migration" \
AI_CS_WEBHOOK_SECRET='replace-with-real-secret' \
AI_CS_WEBHOOK_TIMESTAMP_HEADER='X-CS-Timestamp' \
AI_CS_WEBHOOK_SIGNATURE_HEADER='X-CS-Signature' \
AI_CS_WEBHOOK_MAX_SKEW_SECONDS=300 \
scripts/verify_preprod_gate_b.sh
```
通过标准:
- 脚本退出码为 `0`
- 输出末尾出现 `summary: pass=... fail=0`
- 产物目录中保留 `summary.txt``service.log``webhook_response.json`
---
## 一、部署前检查清单Pre-flight
```bash

View File

@@ -0,0 +1,339 @@
# 共享预生产入口交接清单
> 状态:待共享预生产环境提供方回填
> 最近更新2026-05-06
> 适用项目:`projects/ai-customer-service`
> 目标:确保“真实共享预生产 Gate B 复跑”和“真实共享预生产/灰度环境 Gate C 回滚演练”具备可执行入口,而不是停留在口头说明
---
## 1. 这份清单解决什么问题
当前项目已经具备:
1. 代码级门禁通过
2. 本地/容器化 Gate B 通过
3. 本地/容器化 Gate C 回滚演练通过
当前仍然缺失的是:
1. **真实共享预生产环境 Gate B 复跑入口**
2. **真实共享预生产/灰度环境 Gate C 回滚演练入口**
这里的“入口”不是一个 URL也不是一句“环境已经有了”而是
> **从当前执行机器出发,能真实操作共享预生产环境的运维通道。**
必须能够支持:
1. 启动/重启服务
2. 查看日志
3. 访问 health probe
4. 访问真实 PostgreSQL
5. 获取真实环境变量来源
6. 在该环境执行 Gate B 验证
7. 在该环境执行 Gate C 回滚演练
8. 留下可复核证据
---
## 2. 合格入口类型
满足以下任一类型即可:
### 2.1 SSH 主机入口
提供:
- 主机地址
- 用户名
- 登录方式
- 项目目录
- 启动/重启命令
- 日志路径
- 服务访问地址
适用场景:
- systemd 服务
- 直接运行二进制
- Docker / Podman 单机部署
### 2.2 Kubernetes 入口
提供:
- `kubectl` 可用
- `kubeconfig` 或 context
- namespace
- deployment / service 名称
- 查看日志权限
- rollout / undo 权限
适用场景:
- Kubernetes Deployment
- StatefulSet
- 多副本灰度切换
### 2.3 CI/CD 或发布平台入口
提供:
- 预生产部署流水线入口
- 环境变量/Secret 查看或确认方式
- 服务日志查看入口
- 重启/回滚入口
- 部署版本与提交号映射
适用场景:
- GitOps
- 平台托管部署
- 云上控制台发布
---
## 3. 不算合格入口的情况
以下情况都不够:
1. 只有共享预生产 URL
2. 只有数据库只读账号
3. 只有监控只读面板
4. 只有截图、文档或口头说明
5. 只能“看状态”,不能“重启/回滚/留痕”
原因很直接:
> Gate B / Gate C 都要求可操作性,不只是可观察性。
---
## 4. 入口必须满足的规范要求
### 4.1 部署对象明确
必须明确服务部署对象:
- systemd service 名称
- Docker / Podman 容器名称
- Kubernetes deployment / rollout 对象
不能只说“服务在那台机器上”,必须能回答:
1. 由谁启动
2. 怎么重启
3. 怎么回滚
4. 日志在哪
### 4.2 环境变量来源明确
必须明确共享预生产如何注入这些变量:
- `AI_CS_RUNTIME_ENV`
- `AI_CS_ADDR`
- `AI_CS_POSTGRES_ENABLED`
- `AI_CS_POSTGRES_DSN`
- `AI_CS_POSTGRES_MIGRATION_DIR`
- `AI_CS_WEBHOOK_SECRET`
- `AI_CS_WEBHOOK_TIMESTAMP_HEADER`
- `AI_CS_WEBHOOK_SIGNATURE_HEADER`
- `AI_CS_WEBHOOK_MAX_SKEW_SECONDS`
基线文档:
- [CONFIG_CONTRACT_BASELINE.md](/home/long/project/立交桥/projects/ai-customer-service/docs/CONFIG_CONTRACT_BASELINE.md)
必须至少能回答:
1. 变量值从哪里来
2. 谁负责维护
3. 如何在不泄露明文 secret 的前提下确认其已正确注入
### 4.3 数据库必须是共享预生产真实库
不能使用:
- 本地测试库
- 临时容器库
- 开发库
必须使用共享预生产 PostgreSQL才能证明
1. migration 基线真实可用
2. ticket 入库真实可用
3. audit 入库真实可用
4. dedup 入库真实可用
### 4.4 必须具备最小操作权限
入口必须允许执行以下动作:
1. 启动或重启当前版本
2. 查看最近日志
3. 访问 `/actuator/health/live`
4. 访问 `/actuator/health/ready`
5. 读取当前部署版本/镜像/tag/commit
6. 执行回滚动作
7. 验证回滚后主链恢复
### 4.5 必须可留痕
至少保留以下证据:
1. `summary.txt`
2. 服务日志路径
3. 部署版本 / 提交号
4. 健康检查结果
5. Gate B / Gate C 执行命令
6. 回滚前后版本信息
7. 必要时数据库验证摘要
---
## 5. Gate B 所需最小入口要求
如果当前只想完成“真实共享预生产 Gate B 复跑”,入口最少要具备:
1. 共享预生产服务启动权限
2. 共享预生产 PostgreSQL 可连
3. 真实 `AI_CS_*` 环境变量可确认
4. 服务地址可访问
5. 日志可读
执行入口:
- [scripts/verify_preprod_gate_b.sh](/home/long/project/立交桥/projects/ai-customer-service/scripts/verify_preprod_gate_b.sh)
对应证据模板:
- [PREPROD_VERIFICATION_RECORD.md](/home/long/project/立交桥/projects/ai-customer-service/docs/PREPROD_VERIFICATION_RECORD.md)
---
## 6. Gate C 所需额外入口要求
如果要完成“真实共享预生产/灰度环境 Gate C 回滚演练”,除 Gate B 外还必须额外明确:
1. **坏发布怎么制造**
- 错误配置
- 错误 DSN
- 错误 Secret
- 错误镜像/tag
2. **回滚对象是谁**
- systemd service
- container
- deployment
3. **标准回滚动作是什么**
- `systemctl restart ...`
- `docker/podman restart ...`
- `kubectl rollout undo ...`
4. **恢复完成如何判定**
- `live` / `ready` 恢复
- signed webhook 重新返回 `200`
- ticket / audit / dedup 重新恢复写入
执行入口:
- [scripts/verify_gate_c_rollback.sh](/home/long/project/立交桥/projects/ai-customer-service/scripts/verify_gate_c_rollback.sh)
对应证据模板:
- [ROLLBACK_DRILL_RECORD.md](/home/long/project/立交桥/projects/ai-customer-service/docs/ROLLBACK_DRILL_RECORD.md)
---
## 7. 共享预生产入口交接模板
请环境提供方至少按下面模板回填:
```text
共享预生产入口类型:
- SSH / Kubernetes / CI-CD
如果是 SSH
- 主机地址:
- 用户名:
- 登录方式:
- 项目目录:
- 服务启动命令:
- 服务重启命令:
- 服务停止命令:
- 日志路径:
- 服务访问地址:
- 环境变量来源文件或注入方式:
如果是 Kubernetes
- kubeconfig/context
- namespace
- deployment 名称:
- service 名称:
- ingress / 访问地址:
- 查看日志命令:
- 重启命令:
- 回滚命令:
- Secret / ConfigMap 名称:
如果是 CI/CD
- 平台名称:
- 流水线入口:
- 发布目标环境名称:
- 当前部署版本查看方式:
- 日志查看入口:
- 回滚入口:
数据库:
- 是否为共享预生产 PostgreSQL
- DSN 获取方式:
- migration 目录所在位置:
Gate B 执行责任人:
- 负责人:
- 计划时间:
Gate C 回滚演练责任人:
- 负责人:
- 计划时间:
证据归档位置:
- summary.txt
- service.log
- 版本信息:
- 回滚记录:
```
---
## 8. 当前项目的真实阻断
截至 2026-05-06当前执行机器上已确认
1. **没有 `kubectl`**
2. **没有 `~/.kube/config`**
3. **没有共享预生产专用 `AI_CS_*` 环境**
4. **仓库内没有共享预生产部署清单**
因此当前阻断不是:
- Gate B/Gate C 脚本缺失
- 本地演练能力缺失
- 门禁文档缺失
而是:
> **真实共享预生产环境运维入口未交接。**
---
## 9. 当前结论
当前可以准确表达为:
1. **代码级门禁:通过**
2. **本地/容器化 Gate B通过**
3. **本地/容器化 Gate C 回滚演练:通过**
4. **真实共享预生产 Gate B待共享预生产入口交接后执行**
5. **真实共享预生产/灰度环境 Gate C待共享预生产入口交接后执行**
> 没有入口,不应宣称“真实共享预生产已验证”;有入口后,才可以继续执行真实 Gate B / Gate C。