---
phase: 4
name: planning-playbook
purpose: Phase 4 方案规划方法论（硬约束过滤 + 技术栈复用 + 可逆性维度 + Decision Brief + 方案数量弹性 + Fast-Path Runbook）
parent: ../SKILL.md
updated: 2026-04-23
---

# 📐 Phase 4 · 方案规划 Playbook

> Phase 4 不是"凭灵感列 3 个方案"，而是**按方法论过滤 + 打分 + 输出决策简报**。

---

## 1. 方案数量的复杂度适配

| 路径 | 候选方案数量 | 产物格式 |
|------|-------------|---------|
| 🟢 **Fast** | **1 主方案 + 0-1 可选升级** | `fast-path-runbook.md`（单页清单）|
| 🟡 **Standard** | 2-3 方案，标推荐 | 方案对比表 + 选一个深入 |
| 🔴 **Full** | 3-4 方案 + **Decision Brief** | 完整 L2 策略评审产物 |

**不要硬凑**：小场景只有一条合理路径时，不要编出 3 个"几乎一样的方案"糊弄客户。

---

## 2. 硬约束过滤器（对接 03-risk-assessment-playbook.md §2）

方案生成前**第一步**：从 Phase 3 的 Hard Constraints 表提取约束，**预先过滤候选方案池**。

```
候选方案池（初始）: [A. 维持 CA / B. 换 CA1 / C. 换 CA2 / D. 混合 / E. 拆分]
            ↓
硬约束过滤：
  - "必须维持 DigiCert" → 删除 B / C
  - "必须 RSA 4096" → 删除 D（如果 D 方案要改算法）
            ↓
候选方案池（过滤后）: [A. 维持 / E. 拆分]
            ↓
进入方案打分
```

> ⚠️ **不过滤的后果**：客户看到被否决方案会反问"你不是知道我合作方锁 CA 了吗还推这个"，损害信任。

---

## 3. 方案比较的六维打分

| 维度 | 评分方向 | 举例 |
|------|---------|------|
| **时长** | 越短越好 | 方案 A = 30 天 / 方案 B = 45 天 |
| **工作量** | 越少越好 | 方案 A = 5 人日 / B = 12 人日 |
| **风险** | 越低越好 | 方案 A = 🟡 中 / B = 🔴 高 |
| **可逆性** ⭐ | 越高越好 | 方案 A = ✅ 可逆 / B = 🟡 半不可逆 / C = 🔴 不可逆 |
| **未来代价** | 越低越好 | 方案 C 本次省事但下次续签更复杂 |
| **技术栈复用度** ⭐ | 越高越好（见 §4）| 方案 A 复用客户已有 acme.sh / 方案 B 引入新依赖 |

### ⭐ 可逆性维度说明

- **✅ 可逆**：本次做的事随时能撤回或重做（如 CA 品牌续签）
- **🟡 半不可逆**：撤回需付出额外代价但不是灾难（如 SAN 瘦身后再加回需重签）
- **🔴 不可逆**：撤回不可能或代价极大（如吊销老证书、拆 1 张证书为 N 张）

**客户通常倾向"最快"，但可能忽略"半不可逆"**。Agent 必须显式提示可逆性打分。

---

## 4. "复用客户已有技术栈"优先级原则

方案生成时启发式：**若客户某个绑定点已有 X 自动化（如 acme.sh / cert-manager），优先把其他绑定点也迁移到 X**。

### 为什么：
- 客户已熟悉 X，培训成本 = 0
- 运维工具集中度↑，未来维护成本↓
- 减少引入新依赖的风险

### 识别方法（Phase 1 输出）：
- 客户已有的 ACME 客户端（acme.sh / certbot / lego / cert-manager）
- 已有的证书管理系统（Vault / AWS ACM / 腾讯云 SSL）
- 已有的密钥管理方式（Vault / K8s Secret / 腾讯云 KMS）

### 示例：
- F2 案例 `admin.qq.com` 已跑 acme.sh，方案 β（LE + acme.sh）优于方案 γ（引入阿里云证书服务）

---

## 5. Decision Brief（决策简报）格式

Full Path 必用；Standard 在决策上移时也用。

### 何时触发 Decision Brief
- 资产范围调整（加/减 SAN）
- CA 品牌切换
- 预算超支
- 方案选择触及硬约束争议

### 格式

```markdown
## Decision Brief: [主题]

### 背景
- 关键事实 1
- 关键事实 2
- 当前限制条件

### 选项
- α. [方案 A] → [结果描述]
- β. [方案 B] → [结果描述]
- γ. [方案 C] → [结果描述]

### 推荐
- **β**（原因：硬约束 × 可逆性 × 时间）

### 影响矩阵
| 维度 | α | β | γ |
|------|---|---|---|
| 时长 | ... | ... | ... |
| 工作量 | ... | ... | ... |
| 风险 | ... | ... | ... |
| 可逆性 | ... | ... | ... |
| 未来代价 | ... | ... | ... |

### 请决策者回复
- [ ] 批准 α
- [ ] 批准 β + [启动条件]
- [ ] 批准 γ
- [ ] 其他：______

### 时限
[X] 时内需返回，否则 [关键路径挤爆 / 采购流程延期 / ...]
```

---

## 6. 决策上移路径

Phase 4 识别"**决策上移触发点**"，自动把决策推到合适层级：

| 触发点 | 默认上移到 |
|--------|-----------|
| SAN 范围调整（加/减）| 资产分类 A → 业务负责人；C 类 → 法务 + 战略团队 |
| CA 品牌切换 | 安全总监（L2）+ 合作方关系人（若有锁定）|
| 预算超支 | 部门预算负责人 → 财务 |
| 方案选择触及硬约束争议 | 决策链最高层（L3）|
| 关键路径可能挤爆 | L3 + 客户 CTO |

**Agent 不替 SRE 承担战略决策**。发现需要上移时：
1. 立即暂停当前 Phase
2. 生成 Decision Brief（§5 格式）
3. 明确告知 SRE："这个决策超出你的职权，我建议上移到 [X]"
4. 等待 Decision Brief 回填

---

## 7. Fast Path Runbook 模板

Fast Path 产物不是完整的 L1/L2/L3 三层 Review，而是**一张单页清单**。模板结构：

```markdown
# Fast Path Runbook · {{证书标识}}

## 场景
- 种子证书：[CN]
- 部署：[N 个绑定点]
- 执行者：[单人 / ≤ 2 人]
- 窗口：[剩余 X 天，操作于 Y 日内完成]

## 前置（打钩）
- [ ] 确认 CA 账号可登录
- [ ] 确认客户端兼容性（无老 IoT / 无 pin 证书的移动 app）
- [ ] 备份当前证书与私钥

## 步骤（6-10 步，每步 1 行命令或指令）
1. 生成新私钥：`openssl genpkey -algorithm {{algo}} -out new.key`
2. 生成 CSR：`openssl req -new -key new.key -subj "/CN={{cn}}" -out new.csr`
3. 提交 CA / 等待签发
4. 备份旧证书：`cp -a /etc/ssl/backup-$(date +%F)/`
5. 部署新证书：`cp new.* /etc/ssl/`
6. 预检：`nginx -t`
7. 重载：`systemctl reload nginx`
8. 验证：`curl -vI https://{{domain}}`
9. 观察期：等待 [X] 小时再验证一次（理由：见 `06-verify-rollback-playbook.md §等待时长表`）
10. 日历标记下次续签提醒（按证书有效期分档）：
    - ≤ 47 天证书 → 提前 7 天告警（**必须全自动化，手动不可行**）
    - ≤ 100 天证书 → 提前 14 天告警
    - ≤ 200 天证书 → 提前 30 天告警
    - ≤ 398 天证书（存量）→ 提前 30 天告警
    > ⚠️ 2026-03-15 起新签证书最长 200 天；若本次续签后有效期 ≤ 200 天，**强烈建议本次完成后立即规划 ACME 自动化**（每年 ≥ 2 次手动续签风险极高）

## 回滚（如任一步失败）
- `cp -a /etc/ssl/backup-[日期]/* /etc/ssl/`
- `nginx -t && systemctl reload nginx`
- 前提：旧证书剩余有效期 > 本次操作窗口 × 2（见准入条件）

## 升级建议（可选，一次性多花 10-15 分钟）
- [ ] 把续签步骤写成脚本 `/root/bin/renew-{{domain}}.sh`
- [ ] 接入 CT 日志告警（免费 SaaS: crt.sh email alert）
- [ ] 接入过期告警（公司告警系统 / 个人邮件）
```

---

## 8. 跨字段综合判断

骨架 § 2.1 的四段式推荐支持"字段独立"；本 playbook 增加**"跨字段综合判断"**模式：

当推荐依据来自多个字段组合（如 HP-7 人类预算 + D2 证书来源 + 时间窗口 = 是否引入 ACME 工程），Agent 应：

1. 明示"**本推荐基于多字段综合判断**"
2. 列出参与判断的字段及其当前取值
3. 说明综合判断的逻辑链
4. 仍遵守四段式（推荐 / 理由 / 替代 / 请确认）

### 示例
```markdown
【推荐】本次同款续签（暂不上 ACME），续签后立即规划 ACME 自动化

【依据字段组合】
  - HP-7 人类预算：3 SRE × 148 天 = 紧
  - D2 证书来源：Let's Encrypt 不签 OV，切 ACME = 同时切 CA
  - 业务重要性：R7 合作方锁 DigiCert 品牌
  - CA/B Forum 时代背景：2026-03-15 起新签证书 ≤ 200 天，每年至少续签 2 次

【逻辑链】
  引入 ACME 是一个新建设工程 → 不适合在过期倒计时里启动 →
  + 切 ACME 还需同时切 CA（LE 不签 OV） → 三件事叠加 →
  = 本次同款续签（≤ 200 天，受 CA/B Forum 硬约束）
  但：200 天证书每年至少续签 2 次，手动续签风险升高 →
  = 续签完成后立即把 ACME 自动化列入 backlog，下次续签前完成建设

【替代】
  - 本次直接切 ACME + 换 CA（LE OV 替代）：若团队有额外带宽且不受 CA 锁定约束可考虑
  - 继续纯手动续签：可行但随着证书有效期压缩（200→100→47 天）风险持续升高，不推荐作为长期策略

【请确认】
  你们认同  你们认同"本次维持 + 下次前建 ACME"的路线吗？
```

---

## 9. 相关文件

- [`03-risk-assessment-playbook.md`](./03-risk-assessment-playbook.md) — 硬约束 / DCV 矩阵 / 兜底树输入
- [`05-dry-run-matrix.md`](./05-dry-run-matrix.md) — 方案选定后的演练设计
- [`../SKILL.md § 2.1`](../SKILL.md) — 四段式推荐协议
- [`../review-guides/L2-strategy-review.md`](../review-guides/L2-strategy-review.md) — Full Path 的 L2 产物落地