漸進式發布計畫
依據 Idira 漸進式發布框架產生結構化的發布計畫：從 PRD 推斷訊號、分類發布路徑、規劃環圈、建立 R3 分波計畫，並提供 LaunchDarkly 的設定步驟。
步驟 1 — 閱讀並從 PRD 推斷訊號
完整閱讀 PRD。從內容中推斷下列所有訊號。對於你能自行判斷的資訊，無需詢問 PM。
| 訊號 | 要尋找的內容 |
|---|---|
| NFI | 「NFI」標籤、「新功能」、「先前未提供」、沒有先前版本的全新功能 |
| 影響範圍 | 受影響的使用者/租戶範圍、「關鍵路徑」/「核心工作流程」用語、資料敏感性、資料丟失或服務中斷的風險 |
| 回滾複雜度 | Schema 遷移、資料寫入、第三方依賴、需要客戶溝通、不可逆狀態 → 協調式或不可逆。僅切換旗標 → 容易。若完全未提及 → 必須提問 |
| 地區限制 | GDPR、FedRAMP、資料落地、地理位置特定需求、「從[地區]開始」、「僅限[地區]」、「先從[地區]」、「限於[地區]」 |
| 服務限制 | 功能依賴或修改的命名服務、整合項目或元件 |
| 早期測試者準備就緒 | 「準備好 QA」、衝刺完成日期、Alpha/Beta 日期 — 功能穩定到足以首次外部曝光的時間點 |
| 目標 GA | 已確定的發布日期、OKR 截止日期、發布里程碑 |
閱讀後，呈現你的推斷 — 不要問開放式問題。對於 PRD 中未找到的任何訊號，請標記為 ❓ 並在最後提出精準問題：
根據 PRD，我對此次發布的解讀如下：
- NFI： [是 / 否 — 原因] 或 ❓ PRD 中未明確說明
- 影響範圍： [高 / 中 / 低 — 原因] 或 ❓ PRD 中未明確說明
- 回滾： [容易 / 協調式 / 不可逆 — 原因] 或 ❓ 未提及
- 地區限制： [無 / 列出 — 原因] 或 ❓ 未提及
- 服務限制： [無 / 列出 — 原因] 或 ❓ 未提及
- 準備好早期測試者： [日期 — 原因] 或 ❓ PRD 中未找到
- 目標 GA： [日期 — 原因] 或 ❓ PRD 中未找到
然後僅提出 ❓ 的問題，使用以下精確格式：
- 未提及回滾 → 「是否有回滾計畫？選項：(1) 容易 — 簡單切換旗標，可立即回復。(2) 協調式 — 需要資料遷移、腳本或客戶溝通。(3) 尚未定義 — 回滾策略仍在設計中。」
- 影響範圍不明確 → 「如果出問題，對客戶的影響程度為何？高（影響核心工作流程或眾多租戶）、中（限於特定服務或子集）、或低（外觀/易於回復）？」
- 未找到準備好早期測試者 → 「功能何時準備好讓早期測試者開始驗證？」
- 未找到目標 GA → 「目標 GA 日期或時間範圍為何？」
- 未提及地區 → 「是否有任何地區限制？例如，從特定地區（EMEA、US、APAC）開始，然後再擴展到全球？」
不要假設任何值。不要詢問你已從 PRD 解決的訊號。
步驟 2 — 分類發布路徑
NFI = 是 → 高接觸型
或 影響範圍 = 高
或 回滾 = 不可逆
影響範圍 = 中 → 標準型
或 回滾 = 協調式
其他所有情況 → 輕量型
步驟 3 — 規劃所需的環圈
| 路徑 | 強制環圈 | R&D 負責 | 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 客戶零號 / Dogfooding — 內部團隊
- 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 波，並延長觀察期
每個波次需包含：百分比、分波描述、Go/No-Go 關卡（指標 + 觀察時間）、負責人。Go/No-Go 關卡是強制性的，絕不能省略。如果 PRD 定義了成功指標，請使用它們。如果沒有，則套用預設值：功能成功簽署率 ≥99.5%、錯誤率增量 <0.1%、p99 延遲回歸 <5%、每 1,000 個租戶的支援工單增量 <3，早期波次最短觀察時間為 48 小時，高 ARR 波次為 1 週。
步驟 5 — 輸出完整發布計畫
使用以下範本產出計畫：
# 漸進式發布計畫 — [功能名稱]
**發布路徑：** [輕量型 / 標準型 / 高接觸型]
**最早開始日期：** [日期] | **目標 GA：** [日期]
---
## 我對此次發布的解讀
| 訊號 | 值 | 理由 |
|--------|-------|-----------|
| NFI | 是/否 | [一行] |
| 影響範圍 | 高/中/低 | [一行] |
| 回滾 | 容易/協調式/不可逆 | [一行] |
| 地區限制 | 無 / [列出] | [一行] |
| 服務限制 | 無 / [列出] | [一行] |
---
## 所需環圈
| 環圈 | 階段 | 負責人 | 進入關卡 | 退出關卡 |
|------|-------|-------|------------|-----------|
| R0 | 內部 QA | R&D | 合併至主線 | QA 簽核 |
| R1 | Dogfooding | R&D | R0 完成 | 內部簽核 *(僅高接觸型)* |
| R2 | 第一位客戶 | PM | NFI 流程完成 | 客戶意見回饋審閱完成 *(僅高接觸型)* |
| R3 | 生產金絲雀 | PM | R2 完成 | 100% 波次穩定 |
| R4 | 全面上市 | PM | R3 100% 波次完成 | PM Go/No-Go |
*(僅包含所選路徑所需的環圈)*
---
## R3 分波計畫
**首先：** 測試租戶 — 在啟用任何即時租戶前，先確認安全啟動。
| 波次 | % | 對象 | 目標設定 | Go/No-Go 關卡 |
|------|---|-----|-----------|---------------|
| 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：為 R&D 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）和支援工單。
- 僅在滿足 Go/No-Go 條件後，才能擴展到下一波次。
- 若要暫停或回滾：將生產環境旗標設為 false — 所有租戶立即回復。
**5. 單一切換**
- R&D 必須在所有受影響的元件中實作同一個旗標金鑰。
- 在 R3 開始前，與 R&D 確認所有元件都讀取同一個旗標。
---
## 所有者與責任
- **R&D** — 實作旗標，負責 R0–R1，驗證單一切換覆蓋範圍
- **PM** — 負責客戶曝光（R2–R4），簽核每個波次關卡，更新分波計畫
- **產品營運** — 在 R3 開始前，根據強制準則審閱計畫
## 開放問題 / 假設
- [列出仍需與 R&D / BI 確認的事實或假設]
範例
請參閱 reference.md 查看一個已完成的範例（NFI、高影響範圍、3 個月 GA 目標），其中包含已填寫的分波表格和 LaunchDarkly 規則。