Addy Osmani 灰度与上线

Model: qwen-max | ¥0.15/call
工程方法论GPT-4.1工程实践灰度与上线

灰度与上线：addyosmani/agent-skills: shipping-and-launch，适用于工程实践、代码质量与开发流程优化。

Calls: 1

Skill Documentation

Addy Osmani 灰度与上线

摘要

灰度与上线：addyosmani/agent-skills: shipping-and-launch，适用于工程实践、代码质量与开发流程优化。

> 来源: addyosmani/agent-skills — Google Chrome 团队领袖 Addy Osmani

> 原文件: skills/shipping-and-launch/SKILL.md

> 模型推荐: 看 skill 类型挑

这个 skill 是干嘛的

Addy Osmani (Google Chrome 团队 Performance Lead,前端工程领域权威) 整理的 24 个工程方法论 skill 集合 — 覆盖 API 设计 / 浏览器测试 / CI/CD / 代码评审 / TDD / 安全 / 性能 / 部署 等。

michael 强调"skill 要有相应的指导功能,指导用户使用",所以加了下面两节让 Agent 和用户对接。

---

🤖 Agent 使用说明

1. 接到任务后,先按这个 skill 的触发关键词跑

2. 跑 Checklist 一遍,标记红线步骤

3. 红线步骤必须先完成(往往是 ask user 确认)

4. 完工前用 verification step 自检

5. 跑完了告诉用户结果,不要自行提交

👤 用户需要做什么?

1. 告诉 Agent 你要做什么(一句话即可)

2. 如果 skill 要求 ask user 凭证 / OAuth / 部署密钥,按提示提供

3. 完工后让 Agent 跑自检再交回

4. 全程 Agent 自动化,你只需回答"是/否"类决策点

---

原 skill 内容(addyosmani/agent-skills/shipping-and-launch/SKILL.md,截断到 12k chars)

---

name: shipping-and-launch

description: Prepares production launches. Use when preparing to deploy to production. Use when you need a pre-launch checklist, when setting up monitoring, when planning a staged rollout, or when you need a rollback strategy.

---

Shipping and Launch

Overview

Ship with confidence. The goal is not just to deploy — it's to deploy safely, with monitoring in place, a rollback plan ready, and a clear understanding of what success looks like. Every launch should be reversible, observable, and incremental.

When to Use

The Pre-Launch Checklist

Code Quality

Security

Performance

Accessibility

Infrastructure

Documentation

Feature Flag Strategy

Ship behind feature flags to decouple deployment from release:

// Feature flag check
const flags = await getFeatureFlags(userId);

if (flags.taskSharing) {
  // New feature: task sharing
  return <TaskSharingPanel task={task} />;
}

// Default: existing behavior
return null;

**Feature flag lifecycle:**

1. DEPLOY with flag OFF     → Code is in production but inactive
2. ENABLE for team/beta     → Internal testing in production environment
3. GRADUAL ROLLOUT          → 5% → 25% → 50% → 100% of users
4. MONITOR at each stage    → Watch error rates, performance, user feedback
5. CLEAN UP                 → Remove flag and dead code path after full rollout

**Rules:**

Staged Rollout

The Rollout Sequence

1. DEPLOY to staging
   └── Full test suite in staging environment
   └── Manual smoke test of critical flows

2. DEPLOY to production (feature flag OFF)
   └── Verify deployment succeeded (health check)
   └── Check error monitoring (no new errors)

3. ENABLE for team (flag ON for internal users)
   └── Team uses the feature in production
   └── 24-hour monitoring window

4. CANARY rollout (flag ON for 5% of users)
   └── Monitor error rates, latency, user behavior
   └── Compare metrics: canary vs. baseline
   └── 24-48 hour monitoring window
   └── Advance only if all thresholds pass (see table below)

5. GRADUAL increase (25% -> 50% -> 100%)
   └── Same monitoring at each step
   └── Ability to roll back to previous percentage at any point

6. FULL rollout (flag ON for all users)
   └── Monitor for 1 week
   └── Clean up feature flag

Rollout Decision Thresholds

Use these thresholds to decide whether to advance, hold, or roll back at each stage:

| Metric | Advance (green) | Hold and investigate (yellow) | Roll back (red) |

|--------|-----------------|-------------------------------|-----------------|

| Error rate | Within 10% of baseline | 10-100% above baseline | >2x baseline |

| P95 latency | Within 20% of baseline | 20-50% above baseline | >50% above baseline |

| Client JS errors | No new error types | New errors at <0.1% of sessions | New errors at >0.1% of sessions |

| Business metrics | Neutral or positive | Decline <5% (may be noise) | Decline >5% |

When to Roll Back

Roll back immediately if:

Monitoring and Observability

What to Monitor

Application metrics:
├── Error rate (total and by endpoint)
├── Response time (p50, p95, p99)
├── Request volume
├── Active users
└── Key business metrics (conversion, engagement)

Infrastructure metrics:
├── CPU and memory utilization
├── Database connection pool usage
├── Disk space
├── Network latency
└── Queue depth (if applicable)

Client metrics:
├── Core Web Vitals (LCP, INP, CLS)
├── JavaScript errors
├── API error rates from client perspective
└── Page load time

Error Reporting

// Set up error boundary with reporting
class ErrorBoundary extends React.Component {
  componentDidCatch(error: Error, info: React.ErrorInfo) {
    // Report to error tracking service
    reportError(error, {
      componentStack: info.componentStack,
      userId: getCurrentUser()?.id,
      page: window.location.pathname,
    });
  }

  render() {
    if (this.state.hasError) {
      return <ErrorFallback onRetry={() => this.setState({ hasError: false })} />;
    }
    return this.props.children;
  }
}

// Server-side error reporting
app.use((err: Error, req: Request, res: Response, next: NextFunction) => {
  reportError(err, {
    method: req.method,
    url: req.url,
    userId: req.user?.id,
  });

  // Don't expose internals to users
  res.status(500).json({
    error: { code: 'INTERNAL_ERROR', message: 'Something went wrong' },
  });
});

Post-Launch Verification

In the first hour after launch:

1. Check health endpoint returns 200
2. Check error monitoring dashboard (no new error types)
3. Check latency dashboard (no regression)
4. Test the critical user flow manually
5. Verify logs are flowing and readable
6. Confirm rollback mechanism works (dry run if possible)

Rollback Strategy

Every deployment needs a rollback plan before it happens:

## Rollback Plan for [Feature/Release]

### Trigger Conditions
- Error rate > 2x baseline
- P95 latency > [X]ms
- User reports of [specific issue]

### Rollback Steps
1. Disable feature flag (if applicable)
   OR
1. Deploy previous version: `git revert <commit> && git push`
2. Verify rollback: health check, error monitoring
3. Communicate: notify team of rollback

### Database Considerations
- Migration [X] has a rollback: `npx prisma migrate rollback`
- Data inserted by new feature: [preserved / cleaned up]

### Time to Rollback
- Feature flag: < 1 minute
- Redeploy previous version: < 5 minutes
- Database rollback: < 15 minutes

See Also

Common Rationalizations

| Rationalization | Reality |

|---|---|

| "It works in staging, it'll work in production" | Production has different data, traffic patterns, and edge cases. Monitor after deploy. |

| "We don't need feature flags for this" | Every feature benefits from a kill switch. Even "simple" changes can break things. |

| "Monitoring is overhead" | Not having monitoring means you discover problems from user complaints instead of dashboards. |

| "We'll add monitoring later" | Add it before launch. You can't debug what you can't see. |

| "Rolling back is admitting failure" | Rolling back is responsible engineering. Shipping a broken feature is the failure. |

Red Flags

Verification

Before deploying:

After deploying:

常见问题（FAQ）

使用「灰度与上线」这个 skill 能解决什么问题?

本 skill 专注于灰度与上线，addyosmani/agent-skills: shipping-and-launch。它将相关流程标准化，帮助用户更快拿到可靠结果，减少重复手工操作。

什么情况下适合使用「灰度与上线」?

当你需要在灰度与上线相关工作中获得稳定、可复用的产出时最适合——无论是单次任务还是纳入日常工作流，都能直接调用。

使用「灰度与上线」前需要准备什么?

需要一个具体的项目或任务上下文，最好带有代码仓库或需求文档。

FAQ

👤 用户需要做什么?

1. 告诉 Agent 你要做什么(一句话即可)

2. 如果 skill 要求 ask user 凭证 / OAuth / 部署密钥,按提示提供

3. 完工后让 Agent 跑自检再交回

4. 全程 Agent 自动化,你只需回答"是/否"类决策点

---

使用「灰度与上线」这个 skill 能解决什么问题?

本 skill 专注于灰度与上线，addyosmani/agent-skills: shipping-and-launch。它将相关流程标准化，帮助用户更快拿到可靠结果，减少重复手工操作。

什么情况下适合使用「灰度与上线」?

当你需要在灰度与上线相关工作中获得稳定、可复用的产出时最适合——无论是单次任务还是纳入日常工作流，都能直接调用。

使用「灰度与上线」前需要准备什么?

需要一个具体的项目或任务上下文，最好带有代码仓库或需求文档。

Open AIMS China Panel