分部发布计划

根据Idira分部发布框架生成结构化的发布计划：从PRD中推断信号、分类发布路径、映射发布环、构建R3队列计划，并提供LaunchDarkly设置步骤。

第1步 — 阅读并从PRD中推断信息

完整阅读PRD。从内容中推断以下所有信号。不要询问PM任何你可以自己确定的信息。

信号	需要查找的内容
全新功能 (NFI)	“NFI”标签、“新功能”、“此前未提供”、无先前版本的全新能力
影响范围	受影响的用户/租户范围、“关键路径”/“核心工作流”用语、数据敏感性、数据丢失或服务中断风险
回滚复杂度	模式迁移、数据写入、第三方依赖、需要客户沟通、不可逆状态 → 需协调或不可逆。仅切换开关即可回滚 → 简单。如果未提及 → 必须询问
区域限制	GDPR、FedRAMP、数据驻留、地理特定要求、“从[区域]开始”、“仅[区域]”、“先[区域]”、“限于[区域]”
服务约束	功能依赖或修改的命名服务、集成或组件
早期测试者准备就绪时间	“准备就绪进行QA”、冲刺完成日期、alpha/beta测试日期 — 功能稳定到足以首次对外暴露的时间
目标GA	承诺的发布日期、OKR截止日期、发布里程碑

阅读后，呈现你的推断 — 不要提开放性问题。对于PRD中未找到的任何信号，将其标记为❓并在最后提出针对性问题：

基于PRD，以下是我对此发布的理解：

- NFI：               [是/否 — 原因]  或  ❓ PRD中不明确
- 影响范围：            [高/中/低 — 原因]  或  ❓ PRD中不明确
- 回滚：               [简单/需协调/不可逆 — 原因]  或  ❓ 未提及
- 区域限制：           [无/列表 — 原因]  或  ❓ 未提及
- 服务约束：           [无/列表 — 原因]  或  ❓ 未提及
- 准备就绪供早期测试者：[日期 — 原因]  或  ❓ PRD中未找到
- 目标GA：             [日期 — 原因]  或  ❓ PRD中未找到

然后仅询问**❓** 的问题，使用以下精确形式：

回滚未提及 → “是否有回滚计划？选项：（1）简单 — 只需切换开关，即时恢复。（2）需协调 — 需要数据迁移、脚本或客户沟通。（3）尚未定义 — 回滚策略仍需设计。”
影响范围不明确 → “如果出现问题，您如何描述对客户的影响？高（影响核心工作流或大量租户）、中（限于特定服务或子集）、还是低（表面性/易于撤销）？”
未找到早期测试者准备就绪时间 → “功能何时准备好供早期测试者开始验证？”
未找到目标GA → “目标GA日期或时间范围是什么？”
未提及区域 → “是否有区域限制？例如，从特定区域（EMEA、美国、亚太）开始，然后扩展到全球？”

不要假设任何值。不要询问你已经从PRD中解决的信号。

第2步 — 分类发布路径

NFI = 是            →  高接触
或 影响范围 = 高
或 回滚 = 不可逆

影响范围 = 中        →  标准
或 回滚 = 需协调

其他所有情况         →  轻量级

第3步 — 映射所需发布环

路径	强制性环	研发负责	PM负责
轻量级	R0 → R4	R0	R4
标准	R0 → R3 → R4	R0	R3、R4
高接触	R0 → R1 → R2 → R3 → R4	R0、R1	R2、R3、R4

R0 内部QA — 工程/QA环境
R1 客户零号/内部试用 — 内部团队
R2 客户一号 — 选定的早期访问客户（通过NFI流程）
R3 生产金丝雀 — 测试租户 → 通过LaunchDarkly标志实时队列
R4 全面可用 — 所有符合条件的生产租户

第4步 — 构建R3队列计划（仅标准和高级）

R3始终从测试租户开始。然后按ARR对实时租户排序：

波次	累计百分比	目标定位
0	—	测试租户（客户购买的沙箱）
1	5%	最低ARR，租户数量少
2	15%	低到中ARR
3	35%	中ARR
4	65%	中到高ARR
5	100%	所有剩余符合条件的租户

调整：

服务约束 → 每波添加服务筛选目标
区域限制 → 早期波次添加区域筛选，在波次4–5移除
时间短 → 合并波次（例如5% → 35% → 100%）
高ARR敏感 → 将高ARR租户保留至波次4，并延长观察时间

对于每个波次，包括：%、队列描述、暂停/放行门控（指标 + 观察时间）、负责人。暂停/放行门控是强制性的 — 绝不能省略。如果PRD定义了成功指标，则使用它们。如果没有，则应用默认值：功能成功签署率 ≥99.5%，错误率增量 <0.1%，p99延迟回归 <5%，支持工单峰值 <每1000个租户3个，早期波次最小观察时间48小时，高ARR波次1周。

第5步 — 输出完整发布计划

使用以下模板生成计划：

# 逐步发布计划 — [功能名称]

**发布路径：** [轻量级 / 标准 / 高接触]
**最早开始时间：** [日期]  |  **目标GA：** [日期]

---

## 我对此发布的理解

| 信号 | 值 | 推理 |
|--------|-------|-----------|
| NFI | 是/否 | [一行] |
| 影响范围 | 高/中/低 | [一行] |
| 回滚 | 简单/需协调/不可逆 | [一行] |
| 区域限制 | 无 / [列表] | [一行] |
| 服务约束 | 无 / [列表] | [一行] |

---

## 所需发布环

| 环 | 阶段 | 负责人 | 进入门控 | 退出门控 |
|------|-------|-------|------------|-----------|
| R0 | 内部QA | 研发 | 合入主线 | QA签署 |
| R1 | 内部试用 | 研发 | R0完成 | 内部签署 *(仅高接触)* |
| R2 | 客户一号 | PM | NFI流程完成 | 客户反馈已审核 *(仅高接触)* |
| R3 | 生产金丝雀 | PM | R2完成 | 100%波次稳定 |
| R4 | 全面可用 | PM | R3 100%波次完成 | PM暂停/放行 |

*（仅包含所选路径所需的环）*

---

## R3队列计划

**首先：** 测试租户 — 在激活任何实时租户前确认安全可用。

| 波次 | % | 谁 | 目标定位 | 暂停/放行门控 |
|------|---|-----|-----------|---------------|
| 0 | — | 测试租户 | 外部测试租户 | 48小时无事件 |
| 1 | 5% | 低ARR | [标准] | [指标]稳定[观察时间] |
| 2 | 15% | 低–中ARR | [标准] | [指标]稳定[观察时间] |
| 3 | 35% | 中ARR | [标准] | [指标]稳定[观察时间] |
| 4 | 65% | 中–高ARR | [标准] | [指标]稳定[观察时间] — 延长 |
| 5 | 100% | 所有符合条件的 | 移除筛选条件 | [指标]稳定[观察时间] |

---

## LaunchDarkly设置

**1. 创建功能标志**
- 标志键：`[feature-name]-rollout`（小写，连字符）
- 类型：布尔值
- 默认（关闭）：所有环境为false

**2. 配置环境**
- `internal-qa` → R0：为研发QA团队启用
- `dogfooding` → R1：为内部员工租户启用 *(仅高接触)*
- `early-access` → R2：为命名的客户一号租户启用 *(仅高接触)*
- `production` → R3：以下目标规则

**3. 生产环境目标规则（R3波次）**

波次0 — 测试租户：
- 规则：`tenant_type = "test"` → 返回true

波次1 — 5%：
- 规则：`tenant_type = "live" AND arr_tier = "low"` → 对5%的体验量返回true

波次2 → 5：递增发布百分比，并根据波次扩展`arr_tier`筛选。
在波次5（100%）时完全移除`arr_tier`筛选。

如果存在服务约束：
- 在每个规则中添加`AND deployed_services CONTAINS "[service-name]"`。

如果存在区域限制：
- 在早期波次中添加`AND region IN ["[region]"]`；在波次4–5移除。

**4. 波次之间的门控**
- 在观察期间监控错误率、延迟（p99）和支持工单。
- 仅在满足暂停/放行标准后，才扩展到下一个波次。
- 要暂停或回滚：将生产标志设为false — 所有租户立即恢复。

**5. 单一开关**
- 研发必须在所有受影响的组件中实现一个标志键。
- 在R3开始前，与研发确认所有组件读取相同标志。

---

## 负责人与职责

- **研发** — 实现标志，负责R0–R1，验证单一开关覆盖范围
- **PM** — 负责客户暴露（R2–R4），签署每个波次的门控，更新队列计划
- **产品运营** — 在R3开始前，对照强制性指南审查计划

## 未解决问题 / 假设

- [列出仍需与研发/业务智能确认的事实或假设]

示例

请参阅 reference.md 中的工作示例（NFI、高影响、3个月GA目标），其中包含已完成的计划以及填写好的队列表格和LaunchDarkly规则。

分部发布计划生成技能