---
phase: 3
name: risk-assessment-playbook
purpose: Phase 3 风险评估方法论（硬约束过滤器 + 人因风险 + CA 品牌锁定 + 硬阻塞兜底 + DCV 矩阵）
parent: ../SKILL.md
updated: 2026-04-23
---

# ⚠️ Phase 3 · 风险评估 Playbook

> Phase 3 不是"凭经验列风险清单"，而是**按方法论扫描六个维度**，输出**结构化风险登记册 + 硬约束清单 + 兜底方案树**。

---

## 1. 六维风险扫描框架

每次 Phase 3 必须扫描以下 6 个维度，每维至少问一遍"这里有风险吗？"：

| 维度 | 核心问题 | 代表风险类型 |
|------|---------|-------------|
| **R1 技术** | 证书替换本身技术上会失败吗？ | SAN 影响面 / TLS 兼容性 / 幂等性 / 批处理故障 |
| **R2 业务** | 业务层面谁会受伤？ | 合作方信任 / SLA 违约 / 用户流失 |
| **R3 合规** | 法规 / 合同约束 | 金融合规 / 国密要求 / 等保 / 数据出境 / 审计留痕 |
| **R4 操作者** | 执行者的能力和可得性 | 单人运维 / 经验薄弱 / 休假 / 权限丢失 |
| **R5 组织** | 协调 / 审批 / 政治 | 跨团队阻塞 / 审批超时 / 法务介入 / 政策委员会（**治理侧信息，等客户声明，不主动问**）|
| **R6 时间** | 时间窗口是否真的够 | 关键路径挤压 / CA 签发 SLA（**采购周期等治理侧信息等客户声明后才纳入关键路径**）|

### R1-R6 的 Fast/Standard/Full 适配

| 路径 | 扫描要求 |
|------|---------|
| 🟢 **Fast** | R1+R6 必扫；R2-R5 每维 1 个问题跳过即可 |
| 🟡 **Standard** | R1-R6 每维至少识别 1 条风险；0 条算"已核验无风险" |
| 🔴 **Full** | R1-R6 每维深扫 + 交叉风险（如 R3×R5 = 合规 + 审批复合）|

---

## 2. 硬约束过滤器

> Phase 4 方案生成**前**必须先从 Phase 3 风险表中提取"**不可违反的硬约束**"，避免浪费往返提出被否决的方案。

### 硬约束识别

硬约束 = 满足以下任一条件的风险：
- 客户**明示书面依据**拒绝（如 "安全组 2022 规定 RSA 4096 不可改"）
- **合规强约束**（金融 / 国密 / 等保 3+）
- **合作方信任链**（如 EV 证书换 DV 会触发合作方重新评估）
- **不可逆外部依赖**（如客户端已 pin 特定 CA）

### 硬约束清单格式

Phase 3 结束时生成独立一张表：

```markdown
## Hard Constraints（硬约束 · 方案生成必须遵守）
| 约束 | 依据 | 影响 | 违反代价 |
|------|------|------|---------|
| 必须维持 DigiCert CA | 合作方 R7 明示 | 不可换 LE / ZeroSSL | 触发合作方 3 周重评估 |
| 必须 RSA 4096 | 客户安全组 2022 内规 | 不可改 ECDSA | 需过策略委员会 2 周 |
| 必须经法务 Bob 签字（收购遗留资产） | 收购协议条款 | qcloud.* 相关变更全数受约 | 审批超时 → 关键路径挤压 |
```

此表直接喂给 Phase 4 的方案过滤器（见 `04-planning-playbook.md` §2）。

---

## 3. 跨 zone DCV 方式矩阵

对 T4（跨 zone 多域）场景，必须在 Phase 3 输出**每个 SAN 的 DCV 方法矩阵**：

```markdown
## DCV Matrix
| SAN | DNS 所在 | DCV 方式 | 自动化度 | 预估时长 |
|-----|---------|---------|---------|---------|
| api.example.com | DNSPod（有 API）| DNS-01 TXT | ✅ 全自动 | 10 min |
| api.example.cn | 阿里云万网（有 API） | DNS-01 TXT | 🟡 半自动 | 30 min |
| legacy.example.com.cn | 自建 BIND（需 SSH） | DNS-01 TXT | 🔴 手工 | 2 h |
| mail.example.com | DNSPod | HTTP-01（无 DNS 写权）| 🟡 半自动 | 45 min |
```

**用途**：
- 识别自动化瓶颈（手工的 SAN 数决定关键路径下限）
- 识别需要前置准备的 SAN（如"BIND 要先申请 SSH 审批"）

---

## 4. 硬阻塞风险的兜底方案树

**场景**：识别到某 SAN 的 DCV 彻底做不了（凭证丢失、授权不到位、域名已废弃）。

**兜底决策树**：

```
┌────────────────────────────────────────┐
│  某 SAN 的 DCV 彻底做不了                │
└───────────────┬────────────────────────┘
                ↓
  ┌───────────【Option A】DNS-01 替代为 HTTP-01 ─────────┐
  │  条件：能在该 FQDN 对应服务器放文件                    │
  │  不适用：服务器也访问不到 → 走 Option B                │
  └──────────────────────────┬───────────────────────────┘
                             ↓
  ┌───────────【Option B】Email DCV ─────────────────────┐
  │  条件：WHOIS 邮箱可达 或 admin@ / hostmaster@ 邮箱可达 │
  │  不适用：都不可达 → 走 Option C                        │
  └──────────────────────────┬───────────────────────────┘
                             ↓
  ┌───────────【Option C】资产瘦身（移除 SAN）──────────┐
  │  条件：客户决策同意从证书中移除该 SAN                  │
  │  触发：决策上移（详见 04-planning-playbook.md §5）      │
  │  不接受 → 走 Option D                                  │
  └──────────────────────────┬───────────────────────────┘
                             ↓
  ┌───────────【Option D】本次不换 / 整体延期 ─────────┐
  │  最终兜底：接受本次变更无法完成                        │
  │  后果：证书过期，触发业务事故                          │
  │  必须：决策者书面同意（风险自担）                      │
  └───────────────────────────────────────────────────────┘
```

---

## 5. 客户拒绝推荐的优雅降级

当客户给出**书面策略依据**拒绝 Agent 推荐（如 "安全组 2022 规定"），Agent 应按以下规则降级：

1. **承认客户依据**，不再反复游说
2. **把推荐记为【待策略周期内重审】**（下次续签时再提一次）
3. 在 L2 交付物里**留痕**：[推荐 X 被客户基于 Y 拒绝 → 下次续签时 Agent 应再次提议]
4. 不把"客户拒绝了 Agent 推荐"当作风险登记（这是客户权力，不是风险）

> 📌 骨架 § 2.1 的"推荐协议"本来说"用户拒绝时立即采纳用户方案"，本小节在此基础上增加了**"记待重审"的审计轨迹**，避免好建议永久丢失。

---

## 6. 资产分类 → 风险权重（配合 02-scope-lock-and-reflow.md §5）

| 资产分类 | 风险权重加成 | 特殊关注 |
|---------|-------------|---------|
| A 主品牌核心 | +0（基准）| 影响面最大，灰度策略要细 |
| B 主品牌边缘 | +0.5（轻）| 可能长期无人维护，老系统 |
| **C 收购遗留** | **+2（重）** | **架构迷雾 / 法务约束 / 文档缺失** |
| D 影子资产 | +1.5（中重）| 来源未审计，可能不受管 |
| E 历史废弃 | -0.5（降权）| 建议借此机会吊销 |

---

## 7. 风险登记册格式

Phase 3 交付的**统一风险登记册**：

```markdown
# 风险登记册 v1.0（场景 X）

## R1 技术
- [F-R1] 泛域名影响面广 · 🔴 极高 · 源自资产 A 类主证书
- ...

## R2 业务
- [F-R7] CA 品牌锁定 · 🔴 极高 · 源自合作方合规
- ...

## R3 合规
- (无) · 已核验

## R4 操作者
- [F-R3] 单人运维操作失误 · 🟡 中
- ...

## R5 组织
- [F3-R2] 法务 Bob 对 qcloud.* 有条款约束 · 🔴 高（**客户声明后录入**）
- ...

## R6 时间
- [F3-R1] 关键路径挤压 · 🔴 极高
- [F3-R6] 采购/审批周期（**仅在客户声明存在此约束后录入，Agent 不主动询问**）
- ...

---

## Hard Constraints（从上表提取）
[见 §2]

## DCV Matrix（T4 场景必填）
[见 §3]

## 硬阻塞兜底树启动项
[见 §4 Option 列表]
```

---

## 8. Fast Path 的风险评估简化

Fast Path 场景下，风险评估应遵守**"够用就停"**规则：
- 覆盖 R1 / R2 / R4 / R6 四个基本面，每面 1 条风险即可
- R3 合规 / R5 组织在 Fast Path 准入条件里已被过滤（无强合规、≤ 2 人），跳过
- 不硬凑"每 Phase 必有风险"

示例 Fast Path 风险清单：

```markdown
## Risk (Lite)
- R1 技术：新私钥部署时 nginx reload 失败 → 备份 + nginx -t 预检
- R2 业务：CDN 回源切换时间差 → CF 会自动重握手
- R4 操作者：单人执行无复核 → 必须先演练一次
- R6 时间：113 天充裕 → 无压力（若客户声明有采购/审批周期，届时补录）
```

---

## 9. 相关文件

- [`02-scope-lock-and-reflow.md`](./02-scope-lock-and-reflow.md) — 资产分类输入
- [`04-planning-playbook.md`](./04-planning-playbook.md) — 方案生成接受硬约束 / 兜底树输入
- [`../SKILL.md`](../SKILL.md) — 四段式推荐协议（本文件 §5 扩展了拒绝后的降级）