菜单
Phased rollout strategy, feature flag patterns, rollback trigger definition, and canary deployment criteria. Use when planning a product launch, designing a progressive rollout, or defining rollback thresholds.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | launch-rollout-patterns |
| description | Phased rollout strategy, feature flag patterns, rollback trigger definition, and canary deployment criteria. Use when planning a product launch, designing a progressive rollout, or defining rollback thresholds. |
The safest launch is the one where nothing goes wrong at full scale because you caught the problem at 1% traffic. This skill covers the patterns for progressive rollout — from internal testing to full production — with clear success criteria and rollback triggers at each phase.
A big-bang launch (feature off → feature on for everyone simultaneously) removes your ability to:
Every meaningful feature launch should be phased.
Rollback criteria decided during an incident are criteria decided under pressure. The question is not "should we roll back?" but "we already agreed we would roll back at this threshold — do we do it now?"
Define both what success looks like (proceed to next phase) AND what failure looks like (roll back). Without success thresholds, a rollout stays in limbo indefinitely.
Phase 0: Internal Testing
Target: Internal team + selected employees
Duration: Until no critical bugs found
Proceed to Phase 1 when: Zero P0/P1 bugs in 48 hours
Phase 1: Alpha (Limited Beta)
Target: 1-5% of production traffic / invited users
Duration: 1-2 weeks minimum
Proceed to Phase 2 when: [defined success criteria]
Roll back when: [defined thresholds]
Phase 2: Expanded Beta
Target: 10-25% of traffic
Duration: 1-2 weeks
Proceed to Phase 3 when: [defined success criteria]
Roll back when: [defined thresholds]
Phase 3: Broad Rollout
Target: 50-75% of traffic
Duration: 1 week
Proceed to Phase 4 when: [defined success criteria]
Roll back when: [defined thresholds]
Phase 4: Full Rollout
Target: 100% of eligible users
Post-launch monitoring: 2 weeks active monitoring
Adjust phases based on feature risk level:
## Rollback Triggers: [Feature Name]
### Automatic Rollback (no human decision required)
These conditions trigger immediate rollback without waiting for approval:
- Error rate on [endpoint] exceeds [X]% for 5+ consecutive minutes
- [Metric] drops below [threshold] in any 1-hour window
- [P1 or higher bug] confirmed in production
### Manual Rollback (human decision required within 30 minutes)
These conditions trigger a team review and rollback decision:
- Conversion rate on [flow] drops > [X]pp from baseline
- Support ticket volume increases > [X]% vs. same period previous week
- NPS score drops > [X] points within 48 hours of rollout expansion
### Rollback Procedure
1. Disable feature flag for current cohort
2. Confirm metric recovery within 15 minutes
3. File incident report
4. Notify stakeholders
5. Root cause analysis before re-launch
| Metric | Conservative Threshold | Aggressive Threshold |
|---|---|---|
| Error rate increase | > 1x baseline | > 3x baseline |
| Core conversion drop | > 2pp | > 5pp |
| Revenue impact | > 1% decrease | > 5% decrease |
| Support volume increase | > 20% | > 100% |
| Page load time increase | > 500ms P95 | > 1s P95 |
Use conservative thresholds for payment flows, auth, and data operations. Use aggressive thresholds for low-risk UI changes.
| Strategy | Use When | Implementation |
|---|---|---|
| Percentage rollout | Random exposure for A/B testing | Hash user ID to [0-100], enable for users < threshold |
| Cohort targeting | Target specific segments (new users, power users) | Match on user attribute |
| Geographic targeting | Phase by region (primary market → secondary) | Match on user location |
| Beta opt-in | Engaged users who want early access | Match on beta flag in user profile |
| Employee-first | Internal validation before external exposure | Match on internal user flag |
OFF: Feature completely disabled for all users
SHADOW: Feature executes but output is not shown (backend validation)
BETA: Feature visible to targeted cohort only
PARTIAL: Feature live for [X]% of traffic
FULL: Feature live for all eligible users
SUNSET: Feature disabled pending removal (post-deprecation)
feature.[product-area].[feature-name].[variant]
Examples:
feature.checkout.guest-checkout.enabled
feature.listings.bulk-upload.rollout-pct
feature.payments.split-payment.beta
For products with multi-market presence:
Tier 1: Primary market (highest traffic, most test data)
Launch here first. Most bugs found with the most signal.
Tier 2: Similar markets (comparable infrastructure, similar user behavior)
Launch after Tier 1 is stable for [X] days.
Tier 3: Adjacent markets (different language, different infrastructure needs)
Requires localization validation in addition to functional testing.
Tier 4: Emerging markets (lower bandwidth, different device distribution)
Requires performance validation under constrained conditions.
| Audience | Message | Timing |
|---|---|---|
| Engineering | Technical details, rollback procedure, on-call escalation path | 48 hours before Phase 1 |
| Support | Feature summary, expected user questions, escalation path | 24 hours before each phase expansion |
| Leadership | Feature summary, launch plan, success metrics | 1 week before Phase 1 |
| All company | Feature announcement and availability | Phase 4 launch day |
First 24 hours after each phase expansion:
Structured frameworks for competitive intelligence, gap analysis, and market positioning. Use when mapping the competitive landscape, building feature comparison matrices, or defining differentiation strategy.
TAM/SAM/SOM estimation, ICP definition, and customer segment sizing. Use when estimating market opportunity, defining ideal customer profiles, or sizing addressable segments.
Strategy definition, unit economics, monetization models, and roadmap sequencing frameworks. Use when defining product strategy, modeling business economics, or sequencing roadmap priorities.
Qualitative and quantitative user research synthesis techniques. Use when processing raw user interviews, survey data, usability tests, support tickets, or app reviews into structured insights.
KPI hierarchy definition, north star metrics, OKR trees, and leading vs. lagging indicator frameworks. Use when defining success metrics for a product, building a measurement plan, or evaluating whether current metrics actually reflect business health.
Post-mortem structure, 5 Whys root cause analysis, blameless retrospective patterns, and improvement recommendation formats. Use when facilitating a cycle retrospective, conducting a post-mortem, or generating structured improvement recommendations.