在 LaunchDarkly…

适用于通过 LaunchDarkly MCP 工具在目标环境逐步放量新 flag variation，并按指标阈值监控回归、通知或回滚。

适用场景

解决思路

1. 在环境中配置 remotely hosted LaunchDarkly MCP server，并使用必需 MCP 工具：start-guarded-rollout 启动带监控的渐进式 rollout，get-flag 检查 flag 及其 variations，list-metrics 查找 rollout 期间要监控的 metrics。
2. 按需使用可选 MCP 工具：stop-guarded-rollout 立即停止 active rollout，toggle-flag 在启动前确保 flag 已打开，create-metric 创建不存在的 metrics。
3. 准备阶段用 get-flag 检查 flag，记录 test variation 和 control variation 的 variation IDs。
4. 准备阶段用 list-metrics 查找适合监控的 metrics。
5. 准备阶段确保 flag 在目标环境中为 on，必要时用 toggle-flag 打开。
6. 准备阶段确认该 flag 当前没有 active guarded rollout。
7. 设计 stages：规划逐步增加流量百分比的各个阶段，并为每个阶段设置 monitoring window。
8. 典型 Stage 1：1% 流量，monitoring window 为 1 小时，用于冒烟测试，捕获明显崩溃。
9. 典型 Stage 2：10% 流量，monitoring window 为 24 小时，用于获取指标早期信号。
10. 典型 Stage 3：50% 流量，monitoring window 为 24 小时，用于建立信心。
11. 典型 Stage 4：100% 流量，monitoring window 为 24 小时，用于全量发布并继续监控。
12. Rollout weights 使用 thousandths（basis points）：1000=1%，10000=10%，50000=50%，100000=100%。
13. Monitoring window 使用毫秒：3600000=1 小时，86400000=24 小时，604800000=7 天。
14. 核心原则：从低百分比（1-5%）开始，以尽早捕获问题。
15. 核心原则：选择能反映用户体验的 metrics。
16. 核心原则：设置现实阈值；太紧会导致误报，太松会漏掉回归。
17. 核心原则：每个 stage 都需要足够监控时间，让信号出现。
18. 核心原则：始终配置至少 regression notification，并准备 rollback plan。
19. 配置 metrics：选择能指示问题的 metrics。
20. 配置 error rate 示例：metricKey 为 api-error-rate，regressionThreshold 为 0.05（5% increase），onRegression 设置 rollback。
21. 配置 latency 示例：metricKey 为 p99-response-time，regressionThreshold 为 0.2（20% increase），onRegression 设置 notify。
22. 配置 conversion 示例：metricKey 为 checkout-completed，regressionThreshold 为 0.1（10% decrease），onRegression 设置 notify 和 rollback。
23. 调用 start-guarded-rollout 启动 rollout，传入包含 projectKey、flagKey、environmentKey、testVariationId、controlVariationId、randomizationUnit、stages、metrics 的 JSON。
24. 在 stages 数组中，每项设置 rolloutWeight 和 monitoringWindowMilliseconds。
25. 在 metrics 数组中，每项设置 metricKey、onRegression（含 notify、rollback）和 regressionThreshold。
26. 验证：用 get-flag 确认 guarded rollout 已 active。
27. 验证：检查 flag 在目标环境中显示 rollout 配置。
28. 验证：监控是否出现立即的 regression notifications。
29. 报告结果：guarded rollout 已以 N 个 stages 启动；正在监控 M 个 metrics；第一个 stage 为 X% 流量并持续 Y 小时。
30. 停止 rollout：如出现问题或需要暂停，调用 stop-guarded-rollout，传入包含 projectKey、flagKey、environmentKey 的 JSON；这会立即停止 progressive rollout 并将 flag 锁定在当前状态。
31. 边界情况：flag 为 off 时，先用 toggle-flag 打开，因为 rollouts 要求 flag 为 on。
32. 边界情况：已有 active rollout 时，先用 stop-guarded-rollout 停止，再启动新的。
33. 边界情况：没有合适 metrics 时，先用 create-metric 创建。
34. 边界情况：环境需要 approval 时，工具会返回 approval URL，按该 URL 处理审批。
35. 避免错误：不要在已关闭的 flag 上启动 guarded rollout。
36. 避免错误：不要跳过 monitoring window 设计；匆忙推进 stages 会失去意义。
37. 避免错误：不要把 regression thresholds 设为 0；小幅波动是正常的。
38. 避免错误：不要忘记配置至少一个 metric；没有监控的 rollout 只是普通 rollout。

适用边界 · 注意事项

• 未配置 remotely hosted LaunchDarkly MCP server，或缺少 start-guarded-rollout、get-flag、list-metrics 等必需工具时，不适用。
• flag 在目标环境未开启，或同一 flag 已有 active guarded rollout 时，不应直接启动；需先 toggle-flag 或 stop-guarded-rollout。
• 没有合适可监控 metrics 且无法先 create-metric，或无法接受监控窗口等待、把 regressionThreshold 设为 0、跳过 monitoring window 时，不适合使用。