# 备份与异地容灾 — PRD

> **module**: ops/backup-and-dr
> **doc_type**: PRD
> **status**: Active
> **owner**: lijian
> **upstream_docs**: 无（PRD 是依赖链起点）；事实参考: [10-backup-strategy.md](../10-backup-strategy.md), [.learnings/2026-05-14-pgbackrest-sandbox.md](../../../.learnings/2026-05-14-pgbackrest-sandbox.md)
> **last_verified**: 2026-05-14
> **issue**: [#342](http://43.130.59.228/FFAIWorkspace/workspace/issues/342)
>
> **事实源**：本文档定义"做什么 / 不做什么 / 验收什么"。"具体怎么接的 SOP" 在 [`../10-backup-strategy.md`](../10-backup-strategy.md)。

---

## 1. 目标与问题

### 1.1 要解决的问题

公司核心数据**目前没有系统性的丢失保护机制**。应用 DB 一项做得扎实（`db-backup` skill），其他维度都有不同程度缺口：4 个应用 DB 未接枢纽 / 无 PITR / 附件策略不明 / Configs & Secrets 完全无备份 / Temporal 状态间接覆盖未验证 / 腾讯云 CBS 快照未启用 / **恢复演练除 Gitea 外从未验证**。

一句话：**今天任何一台机器物理挂掉、或谁误删一个关键表，我们不能保证在 4 小时内带着 0 数据丢失恢复**。

### 1.2 成功指标（issue 验收条款）

| # | 指标 | 数据源前提（关键）| 验收方式 |
|---|---|---|---|
| **A** | 空白 VM 起，按 runbook 从备份恢复整个 production，**4h 内业务可用 + 数据完整** | **本地 repo 不可用**（机房/主机挂），仅能用枢纽**异地副本**（RPO 上界 = 上次枢纽 pull 时点，最坏 ~24h，正常 ≤ 04:30 cron 后几分钟）| 演练矩阵 §A 全 ✅ |
| **B** | 每月自动 drill **连续跑 ≥ 3 次无 false failure** | 数据源任选（drill 是验证机制本身） | 演练矩阵 §B 全 ✅，记录在 [02-drill-matrix.md](./02-drill-matrix.md) |
| **C** | 任意员工误删关键表 → **30 分钟内恢复到误删前 10 秒** | **本地 repo 仍可用**（只是逻辑误删，主机/磁盘没挂）→ 用本地 pgbackrest WAL（RPO ≤ 5min）| 演练矩阵 §C 全 ✅ |

A / B / C 各自对应 Phase 1 / Phase 3 / Phase 2 的退出条件，详见 [03-phase-roadmap.md](./03-phase-roadmap.md)。

> **RPO 二义性必须区分**：本系统有**两层 repo**——主机本地 repo（pgbackrest WAL 几乎实时）和枢纽异地副本（pull cron 后才到位）。**A vs C 的 RPO 数字差一个数量级**，混用 = 演练时争论"哪个数字才算数"。下文 §3 矩阵显式拆 "RPO 本地 / RPO 异地" 两列。

---

## 2. 功能边界

### 2.1 In-scope（覆盖维度）

| 维度 | Phase | 说明 |
|---|---|---|
| **应用 DB 备份**（4 套：FFAI prod/UAT, AIxC prod/UAT）接入枢纽 | P1 | 日级逻辑 dump，沿用枢纽 §3 SOP 接入 |
| **应用 DB PITR**（WAL 流式归档） | P2 | pgbackrest，目标 RPO ≤ 几分钟 |
| **Configs & Secrets 备份**（`.env.*` / `certs/` / Nginx / pm2 / systemd unit） | P1 | tarball 入枢纽；**offsite-1 自身的 secrets**（`/etc/backup-hub/keys/*`）走交叉备份到应用机之一（见 §3 矩阵注解），避免 hub 自己挂时密钥同归于尽 |
| **Temporal 状态显式验证** | P1 | 演练时显式恢复 Temporal DB + 启 worker 走通信号 |
| **上传附件备份**（platform_tickets + 其他模块） | P2 | 调研存储路径后接入枢纽 |
| **枢纽 `/backups/` 静态加密** | P1 | LUKS 全卷加密 |
| **腾讯云 CBS 系统盘快照标准化**（5 台机：4 应用 + offsite-1） | P3 | 控制台/CLI 策略 + **跨地域复制必开**（CBS 快照默认同区域，不开复制 = 区域故障时快照同归于尽，失去异地承诺）+ 定期检查 |
| **恢复演练扩展**（从只 Gitea 到月度按 source 轮转 + 季度全维度） | P1 + P3 | 见 [02-drill-matrix.md](./02-drill-matrix.md) |

环境范围：**production + UAT 全覆盖**。

### 2.2 Out-of-scope

| 不做的 | 原因 |
|---|---|
| dev / test 环境备份 | issue 明确排除 |
| 跨云厂商容灾（AWS / 阿里云副本） | 与提出人共识：腾讯云生态收敛 → 不引入跨厂商 → 不防云账号失陷场景 |
| Gitea 备份机制本身的设计 | #310 已完成，本 PRD 只引用 [`../10-backup-strategy.md § 2`](../10-backup-strategy.md) |
| 业务模块的 schema/代码/前端改动 | 本工单纯基础设施，无业务契约面变更 |
| pgbackrest 自身的 `repo-cipher` 加密 | 与 LUKS 二选一；选 LUKS 因对 pgbackrest 透明、不影响 SOP |
| Standby / Streaming Replication | 与本 PRD 正交；replication 是高可用，备份是数据安全；未来另立工单 |

### 2.3 不变量（继承自 [`../10-backup-strategy.md § 1.2`](../10-backup-strategy.md) + 新增）

继承：
1. 枢纽机不持有任何业务凭据（只持各 source 的 backup read key）
2. 每个 source 用独立 system user + 独立 keypair
3. 源机 `authorized_keys` 必须 `command=...` 强制走 dispatcher + case 白名单
4. dispatcher 的 `log()` 不能用 sudo（`set -e` 退出陷阱）
5. 每个 source 在源机本地保留 7 天，枢纽保留 30 天
6. 备份时间错开应用 DB 备份的 03:00 一小时以上

新增（本 PRD）：

7. **PITR 配置变更必须先 UAT ≥ 2 周稳定 + 一次演练通过，再上 production**（PITR 触碰生产 postgresql.conf 是高风险路径，无 standby 时即时回滚成本高）
8. **演练失败 = 备份不算完成**（沿用现有，本 PRD 显式扩到所有维度，不只 Gitea）
9. **PG 配置文件 不需要另存**（沙箱实测确认 postgresql.conf / pg_hba.conf / postgresql.auto.conf 全在备份里；详见 [`.learnings`](../../../.learnings/2026-05-14-pgbackrest-sandbox.md) Q8）
10. **archive_command 失败不可静默**（实测主库不阻塞但 pg_wal 无界堆积；必须监控 `pg_stat_archiver.failed_count` 增量 + `pg_wal/` 大小阈值；告警逻辑用 `last_failed_wal > last_archived_wal` 而不是 failed_count 绝对值——见 `.learnings` Q1）
11. **空白机器恢复必须从 OS image 起，不能复用已装好 PG 的机器演练作弊**
12. **携带 `DROP` 语句的 dump 必须走 restore wrapper + 目标机白名单**：`pg_dumpall --clean --if-exists` 生成的 dump 内含 `DROP DATABASE IF EXISTS` / `DROP ROLE IF EXISTS`，直接 `psql -f` 到生产 = 整库被 wipe。**禁止**任何脚本 / 人工直接 `psql -f` 这类 dump；恢复**只能**通过 `restore-to-spare.sh` wrapper 执行，wrapper 必须：(a) 内置 spare/演练机 hostname/IP 白名单，命中 prod hostname 立即 exit 1；(b) 校验当前 host 不在生产 host 清单（事实源 [`../01-server-infrastructure.md`](../01-server-infrastructure.md)）；(c) dump 文件名统一带 `-DESTRUCTIVE-DO-NOT-APPLY-TO-PROD.sql.gz` 后缀以阻止误操作 tab 补全。dispatcher 只负责 push dump 到归档目录，**不允许**dispatcher 链路存在任何 apply 路径。

---

## 3. 备份维度矩阵

| 维度 | 数据源 | 备份机制（决策） | 频率 | 异地保留 | RPO 本地 | RPO 异地 | RTO（目标） | 恢复优先级 | Phase |
|---|---|---|---|---|---|---|---|---|---|
| 应用 DB 逻辑 dump | 4 套 PG（FFAI prod/UAT, AIxC prod/UAT） | 枢纽 SSH-pull + **`pg_dumpall --clean --if-exists`** dispatcher（一次 dump 实例全部 DB，含应用 ffoa + Temporal + roles/globals）| 日 04:30 | 30d | ≤ 24h | ≤ 24h（pull 后） | ≤ 30min | T1 (FFAI prod) / T2 (FFAI UAT, AIxC prod) / T3 (AIxC UAT) | P1 |
| 应用 DB PITR | 同上 | **pgbackrest**（archive_command + 全量+增量+WAL） | 全量周, 增量日, WAL 连续 | 30d (full+incr) + 14d WAL | **≤ 5min** | **≤ 24h**（异地副本仍按 04:30 cron 节奏；如要异地 PITR ≤ 5min 需 P3 评估更密 pull）| ≤ 30min（到任意时间点） | 同上 | P2 |
| Configs & Secrets（应用机）| 4 应用机的 `.env.*` / `certs/` / `/etc/nginx/sites-enabled/` / pm2 ecosystem / 关键 systemd unit | 枢纽 SSH-pull + tar dispatcher | 日 05:00 | 30d | ≤ 24h | ≤ 24h | ≤ 5min | T1 (FFAI prod) / T2 / T3 | P1 |
| Configs & Secrets（offsite-1 自身）| `/etc/backup-hub/keys/*` + `/opt/backup-hub/bin/` + `crontab -u backup-hub` 导出 | **交叉备份到 FFAI prod 机**（独立 dispatcher，避免 hub 自挂时 keys 同归于尽）| 日 05:00 | 30d | ≤ 24h | ≤ 24h | ≤ 5min | **T0**（hub 重建是其他一切的前置）| P1 |
| Temporal workflow 状态 | Temporal 自己的 PG schema（与应用 ffoa 同一 PG 实例 / 不同 database） | 通过 `pg_dumpall` **同一命令一次性 dump 整个 PG 实例**已覆盖（不另开 dispatcher）；演练时显式恢复 Temporal DB + 起 worker 走通信号 | 同应用 DB | 同应用 DB | 同上 | 同上 | 同上 | 跟随对应 PG 实例 | P1 验证 |
| 上传附件 | **依赖 P1 inventory 产出**（穷举哪些表/字段引用文件 + FS 存储路径约定）；platform_tickets + 其他模块 | 枢纽 SSH-pull + rsync dispatcher | 日 05:30 | 30d | ≤ 24h | ≤ 24h | ≤ 1h（量级未知，待 P2 inventory 后定） | T1 (FFAI prod) / T2 / T3 | P1 inventory + P2 接入 |
| Gitea 实例 | Gitea 主机 | **已实现**：枢纽 SSH-pull + `gitea dump` dispatcher | 日 04:30 | 30d | ≤ 24h | ≤ 24h | ≤ 30min | T2（代码/issue 不影响业务运行）| 已 ✅ |
| 腾讯云 CBS 系统盘快照 | 5 台机系统盘 | 腾讯云控制台/CLI 自动快照策略 + **跨地域复制必开** | 日 1 次（系统盘） | 7d 滚动 + 跨地域副本 | ≤ 24h | ≤ 24h | ≤ 30min（重挂卷） | 同主机优先级 | P3 |
| 枢纽机静态加密 | `/backups/` 卷 | LUKS 全卷加密 | n/a | n/a | n/a | n/a | 重启 + 解锁（systemd-cryptenroll 或 TPM） | n/a | P1 |

> Phase 退出条件不是"所有维度都通过"，而是"对应该 Phase 的 issue 验收条款 A/B/C 通过"。详见 [03-phase-roadmap.md](./03-phase-roadmap.md)。

### 3.1 应用 DB ↔ 附件一致性模型

DB dump（04:30）和附件 rsync（05:30）有 1 小时偏移 → restore 后**可能出现** DB 行引用了不在附件备份里的文件（或反之）。**本 PRD 决策**：

- **接受最终一致性 + 启动时清扫**：restore 后 backend 启动一个一次性 job，扫描所有引用文件路径的表，把指向不存在文件的行标记为 `attachment_missing`（不删行，保留业务上下文供人工处理）
- **不追求** point-in-time 严格一致（不引入 FS 快照 / 应用层 quiesce，复杂度 ROI 太低）
- **顺序约束**：备份顺序 DB → 附件（先冻结引用，再拍快照），恢复顺序也是 DB → 附件
- 清扫 job 在 P2 设计，由后端模块负责（不在本运维 PRD 实施范围，只声明约束）

### 3.2 恢复优先级分级（T0/T1/T2/T3）

灾难发生（机房挂 / 多机同时挂）4h 预算内不能并行 restore 所有目标，按以下分级依次恢复：

| Tier | 范围 | 理由 | 4h 预算分配 |
|---|---|---|---|
| **T0** | offsite-1 枢纽机自身（含 `/etc/backup-hub/keys/*`）| 其他一切恢复的前置（没 keys 不能拉别的 source）| ≤ 30 min |
| **T1** | FFAI prod 应用 DB + Secrets + 附件 | 业务命脉（员工日常用） | ≤ 2 h |
| **T2** | FFAI UAT、AIxC prod、Gitea | 测试环境 / 第二业务线 / 代码库 | ≤ 1 h（并行） |
| **T3** | AIxC UAT | 第二业务线测试 | 剩余预算，可延后 |

演练 §A 必须按 T0→T1→T2→T3 顺序跑（即使是单机演练也要标注顺序，确认 runbook 正确）。多机同时受灾时若 4h 不够，**T3 允许延后到 next day**，但 T0/T1/T2 必须在 4h 内全部 ✅。

### 3.3 演练失败升级阶梯

不变量 #8 "演练失败 = 备份不算完成" 是原则；本节给出**未修复多久 → 升级到谁 / 触发什么动作**的可执行阶梯，避免"cron 被禁了几周没人察觉"的隐性失效。

T0 = [02-drill-matrix.md § "不通过的处理"](./02-drill-matrix.md#不通过的处理) 触发的"禁用 cron + #342 评论"时刻。

| 状态 | 时限 | 自动动作 | 决策权 |
|---|---|---|---|
| 演练 fail / cron 被禁 | T+0 | issue #342 评论 + 当班运维 ack | 当班运维 |
| 仍未修复 | T+24h | 自动 ping owner（lijian）+ tech-lead；同时**当日起每日手工 dump 顶替**，记录到 `docs/ops/incidents/` | owner |
| 仍未修复 | T+72h | 自动开新 issue `Severity/High` + ping 管理层；当前 RPO/RTO 承诺**临时降级**披露给业务方 | tech-lead |
| 仍未修复 | T+7d | 触发 SLA 重议（issue #342 评论 @ 提出方 chentao.jia）：4h RTO / 分钟级 RPO 是否仍然承诺 | 提出方 + tech-lead |
| 仍未修复 | T+30d | 状态正式声明为"**当前没有可信备份**"——本 PRD 第 8 条不变量被违反，须紧急 P0 复盘 | 管理层 |

**约束**：

- 自动动作的实现属于"演练失败自动告警"基础设施，目前在 [03-phase-roadmap.md § P3](./03-phase-roadmap.md) 才完整上线；**P1/P2 期间**降级为人工巡检 #342 评论 + owner 每周一固定 check-in（写入 owner 日历），**不接受**"等 P3 再说"
- cron 禁用期间的"代偿手工 dump"是硬约束：每日手工 dump + 写 incident 记录，否则 #8 不变量在 T+24h 之后就实际破裂
- 升级到 T+7d / T+30d 的判定不依赖告警系统是否触发——owner 必须主动追踪，告警是兜底不是唯一信号

---

## 4. 核心架构决策

**所有 5 条决策的实测依据见** [`.learnings/2026-05-14-pgbackrest-sandbox.md`](../../../.learnings/2026-05-14-pgbackrest-sandbox.md) 末尾"直接进 PRD 的 5 条决策"。

### D1：架构 — pgbackrest，本地 repo + 枢纽 pull

- pgbackrest 在 DB 主机本地建 repo（`/var/lib/pgbackrest/`），枢纽 SSH-pull rsync 拉取
- 复用现有枢纽 [`../10-backup-strategy.md § 3`](../10-backup-strategy.md) SOP：新 source 只补 `(source-name, dump-command, runtime-user)` 三元组 + 一段 dispatcher
- **P1 dump 命令形状**：`pg_dumpall --clean --if-exists`（一次拿到实例所有 DB + roles + tablespaces，包括 Temporal）；不用 per-DB `pg_dump` 循环 + `--globals-only`，避免漏 dump 新建的库。**P2 上 pgbackrest 后**，逻辑 dump 与 pgbackrest 并存一段时间（双轨过渡 ≥ 2 周稳定再下逻辑 dump）
- **不选** push 到 COS 的拓扑：与现有 pull 模型不对齐 + 失去"源机被攻破拿不到任何东西"的安全收益
- **pgbackrest 版本要求**：≥ 2.50（沙箱实测 2.58.0），P2 实施前 pin 在所有 source + 枢纽机一致

### D2：恢复模式选择

- **误删恢复**（验收条款 C）→ `pgbackrest restore --target-action=pause`：恢复完进入等待状态，**人工验证数据再 promote**，防止"target 选错"
- **空白机灾难恢复**（验收条款 A）→ `pgbackrest restore --target-action=promote`：直接退出 recovery 进入服务

### D3：监控指标（必须，否则静默失败拖死 PITR）

- `pg_stat_archiver.failed_count` 增量（不是绝对值；用 `last_failed_wal > last_archived_wal` 判定告警）
- `pg_wal/` 目录大小阈值
- 告警动作：> 15 分钟未追平 → 警告；pg_wal > N GB（按主机磁盘 60% 设阈）→ 紧急

### D4：备份范围 = PG 自身配置 ❌ 不另存 + OS 级配置 ✅ 另存

- PG 配置（postgresql.conf / pg_hba.conf / postgresql.auto.conf）已含在 pgbackrest 备份里（沙箱 Q8 实测）→ **不另存**
- OS 级（pgbouncer / Nginx / pm2 / systemd / certs / `.env.*`）→ **走 Configs & Secrets 维度**

### D5：演练验收 — 起空白 VM，不在原机器作弊

- 从 OS image 起 → 装 PG 16 + pgbackrest → restore → 验证 `SELECT version()` + 数据 + pg_hba 认证 + 应用连得上
- 沙箱实测 29.5MB 数据 10s 完成；生产规模留 1-2h buffer，4h RTO 充裕

### D6（独立）：拓扑收敛 — 腾讯云生态

- 枢纽机本身在腾讯云 offsite-1（与生产/UAT 主机不同区域）
- CBS 快照走腾讯云控制台
- **不引入** AWS S3 / 阿里云 OSS（[`../03-ops-policy.md`](../03-ops-policy.md) 现有描述需同步修订）

### D7（独立）：加密 — LUKS 全卷（不选 pgbackrest repo-cipher）

- LUKS 在枢纽 `/backups/` 卷透明加密
- 优势：对 pgbackrest 透明，不改 dispatcher / 不改恢复流程；恢复演练只多一步 `cryptsetup open`
- **解锁策略 — P1 实施前必须先验证 offsite-1 实例的 TPM 可用性**：
  - 首选：`systemd-cryptenroll --tpm2-device=auto`（腾讯云标准 CVM 默认**不暴露 vTPM** 给 guest，特殊机型才有；不验证就上 = P1 卡死）
  - Fallback：keyfile 存在**应用机之一**的 `/srv/secrets/luks/` 受限目录（chmod 600 + 仅 ubuntu 可读），offsite-1 启动时 initramfs hook 通过 SSH key 远程拉取 → 解锁后立刻丢弃。**这条 fallback 必须配独立监控**（拉取失败 = LUKS 不解锁 = 当天 cron 跑不起来 = 静默丢一天备份）
  - **绝不**：keyfile 落在 offsite-1 本机明文（违反零信任原则）

---

## 5. 可扩展性承诺（针对 #339 / #338 / #332 等未来模块）

本 PRD 设计的接入 SOP（基于 [`../10-backup-strategy.md § 3`](../10-backup-strategy.md)）是 **source-agnostic** 的：

> 新模块上线时，只补 `(source-name, dump-command, runtime-user)` 三元组 + 一段 ~30 行 dispatcher + 枢纽 `backup-all.sh` 加 8 行段；**不再改枢纽核心代码**。

这意味着 #339（全员 AI 工作台）/ #338（AI 用量跟踪）/ #332（内部 PaaS）上线时，备份接入是一个 ~半天的 SOP-driven 任务，不需要再写 PRD。

---

## 6. 提出人共识（PRD 不动项）

issue body 已对齐、PRD 不再回锅讨论的两条前提：

1. **不引入跨厂商 → 不防云账号失陷**：腾讯云生态足够
2. **"备份能恢复" 比 "备份写入" 重要 10 倍**：演练优先级 > 备份实现优先级；演练失败 = 备份不算完成

---

## 7. 风险与缓解

| 风险 | 影响 | 缓解 |
|---|---|---|
| pgbackrest archive_command 配置错拖累生产主库 IO | 主库写入变慢/堵塞 | **P2 必须 UAT ≥ 2 周稳定 + 一次演练通过**才上 prod；监控 P95 写入延迟基线 |
| LUKS 重启需手工解锁影响 cron 早上 04:30 跑不起来 | 当天备份缺失（30d 异地兜底 cushion 充足） | systemd-cryptenroll + TPM 自动解锁（**P1 实施前必须先验证腾讯云 offsite-1 实例支持 vTPM**）；TPM 不可用时落 D7 fallback（远程拉 keyfile + 告警必须从**应用机**发出，不能从 offsite-1 自己发——否则 offsite-1 挂时告警也挂，循环依赖）|
| offsite-1 自身挂 → 自己的 secrets（`/etc/backup-hub/keys/*`）和 backup-hub 配置同归于尽 | 整个备份机制需手工重做 §3.1 SOP 给所有 source 重新生成 keypair（实测约 0.5 天/source × N source） | offsite-1 secrets 走**交叉备份到 FFAI prod 机**（§3 矩阵已纳入 P1）；演练 §A 必须包含"假设 offsite-1 已彻底丢失，从应用机的交叉备份恢复 backup-hub keys"步骤 |
| §C 演练 30 min 总时限**零 slack**（步骤累加正好 30 min） | 任何一步小延迟整体 fail | 演练前 pre-stage spare 机的 pgbackrest / `.env` 模板 / pm2 ecosystem，让 30 min 全用在数据恢复 + 验证；如多次演练贴近上限，作为信号触发与提出人重议 SLA。真实事故触发本流程时的现场降级路径详见 [`02-drill-matrix.md § C.5`](./02-drill-matrix.md) |
| CBS 系统盘快照默认同区域，区域故障时与系统盘同归于尽 | 失去"异地"语义，验收条款 A 隐含的异地恢复能力可能不达标 | CBS 跨地域复制**必开**（PRD §3 矩阵 + Phase 3 实施时硬性 checklist）；CBS 仅作为**同区域快速回滚兜底**，灾难恢复主路径仍是 pgbackrest 异地副本 |
| 枢纽机磁盘满 | 全部 source 备份失败 | pgbackrest WAL + 全量+增量保留 14 天约需 dump 体积 5-10×；P2 实施前必须做容量预估 + 监控阈值 |
| Temporal worker 在 PITR 恢复后状态错乱 | workflow 重放异常 | P1 演练显式验证 + Temporal 自带 "stuck workflow" reset 工具兜底 |
| 备份文件损坏未被发现 | 灾难时才发现 | pgbackrest 自带 `verify` + manifest sha256；月度演练强制 `pgbackrest verify` 前置 |
| 沙箱推迟未跑的 5 个问题（Q2/Q4/Q5/Q6/Q7）实施时翻车 | P2 进度被拖 | 每个推迟问题在 `.learnings` 已列推迟理由 + 实施阶段补跑方式；P2 启动前必须各 1 天验证 |
| `pg_dumpall --clean --if-exists` dump 被误 apply 到生产 | 整个 PG 实例的库 + 角色被 wipe，等同于一次 P0 数据事故 | 不变量 #12：强制 `restore-to-spare.sh` wrapper + 目标机白名单 + dump 文件名 `-DESTRUCTIVE-DO-NOT-APPLY-TO-PROD` 后缀；dispatcher 只 push 不 apply；wrapper 实现作为 P1 必交付项（不能等 P2/P3）|
| 演练失败后 cron 长期处于禁用状态无人察觉 | "演练失败 = 备份不算完成" 实际兑现不了，备份能力静默归零 | §3.3 升级阶梯（T+24h owner / T+72h tech-lead / T+7d SLA 重议 / T+30d 管理层）；P1/P2 期间靠 owner 每周一日历 check-in + 人工巡检 #342 评论兜底；P3 上自动告警 |

---

## 8. 角色

| 角色 | 设计 | 实施 | 演练 | 紧急恢复 |
|------|:---:|:---:|:---:|:---:|
| 运维 / IT（lijian） | ✓ | ✓ | ✓ | ✓ |
| 后端负责人 | review | - | ✓（演练验证应用层） | ✓ |
| 提出人（chentao.jia） | review | - | - | - |
| 管理层 / 合规 | - | - | 季度报告 review | - |

---

## 9. 变更与版本

| 版本 | 日期 | 变更 | 触发 |
|---|---|---|---|
| 0.1 | 2026-05-14 | 初版 PRD，基于沙箱实测 + 4 轮澄清 | issue #342 |