关于 deployment-procedures
为负责生产环境发布的开发和运维人员提供部署决策原则，覆盖发布前检查、部署验证、回滚及紧急处置。内容按平台和风险场景引导选择流程，而非提供可直接复制的脚本。
主要功能
- 01平台选择指导
- 02发布前检查清单
- 03分阶段部署流程
- 04部署后验证与监控
- 05回滚与紧急处置
- 06零停机策略选择
适用场景
- 01准备生产环境发布
- 02选择适合平台的部署流程
- 03部署后检查服务健康状况
- 04服务故障时评估回滚
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/deployment-procedures确认已加载。
详细介绍
部署流程
安全部署到生产环境的原则与决策。 学会思考，而不是死记脚本。
⚠️ 如何使用此技能
此技能讲解的是部署原则，而不是供你复制的 bash 脚本。
- 每次部署都各不相同
- 理解每个步骤背后的原因
- 根据你的平台调整流程
1. 平台选择
决策树
What are you deploying?
│
├── Static site / JAMstack
│ └── Vercel, Netlify, Cloudflare Pages
│
├── Simple web app
│ ├── Managed → Railway, Render, Fly.io
│ └── Control → VPS + PM2/Docker
│
├── Microservices
│ └── Container orchestration
│
└── Serverless
└── Edge functions, Lambda
各个平台的流程各不相同
| 平台 | 部署方式 |
|---|---|
| Vercel/Netlify | 推送到 Git，自动部署 |
| Railway/Render | 推送到 Git 或使用 CLI |
| VPS + PM2 | SSH + 手动步骤 |
| Docker | 推送镜像 + 编排 |
| Kubernetes | kubectl apply |
2. 部署前原则
4 类验证
| 类别 | 检查内容 |
|---|---|
| 代码质量 | 测试通过、lint 检查干净、已审核 |
| 构建 | 生产构建正常，无警告 |
| 环境 | 环境变量已设置，密钥为最新 |
| 安全 | 已完成备份，回滚计划已就绪 |
部署前检查清单
- 所有测试均已通过
- 代码已审核并获批准
- 生产构建成功
- 已验证环境变量
- 数据库迁移已就绪（如有）
- 已记录回滚计划
- 已通知团队
- 监控已就绪
3. 部署工作流原则
5 阶段流程
1. PREPARE
└── Verify code, build, env vars
2. BACKUP
└── Save current state before changing
3. DEPLOY
└── Execute with monitoring open
4. VERIFY
└── Health check, logs, key flows
5. CONFIRM or ROLLBACK
└── All good? Confirm. Issues? Rollback.
各阶段原则
| 阶段 | 原则 |
|---|---|
| 准备 | 绝不部署未经测试的代码 |
| 备份 | 没有备份就无法回滚 |
| 部署 | 全程观察，不要离开 |
| 验证 | 信任，但要验证 |
| 确认 | 准备好回滚触发条件 |
4. 部署后验证
验证内容
| 检查项 | 原因 |
|---|---|
| 健康检查端点 | 服务正在运行 |
| 错误日志 | 没有新增错误 |
| 关键用户流程 | 关键功能正常 |
| 性能 | 响应时间可接受 |
验证时段
- 前 5 分钟：主动监控
- 15 分钟：确认稳定
- 1 小时：最终验证
- 次日：检查指标
5. 回滚原则
何时回滚
| 症状 | 操作 |
|---|---|
| 服务宕机 | 立即回滚 |
| 严重错误 | 回滚 |
| 性能下降超过 50% | 考虑回滚 |
| 轻微问题 | 如果能快速修复，则向前修复 |
各平台的回滚策略
| 平台 | 回滚方式 |
|---|---|
| Vercel/Netlify | 重新部署之前的提交 |
| Railway/Render | 在控制面板中回滚 |
| VPS + PM2 | 恢复备份并重启 |
| Docker | 使用已验证的先前不可变镜像摘要 |
| K8s | kubectl rollout undo |
回滚原则
- 速度优先于完美：先回滚，之后再调试
- 不要让错误叠加：只回滚一次，不要多次更改
- 及时沟通：告知团队发生了什么
- 事后复盘：稳定后弄清原因
6. 零停机部署
策略
| 策略 | 工作原理 |
|---|---|
| 滚动部署 | 逐个替换实例 |
| 蓝绿部署 | 在不同环境之间切换流量 |
| 金丝雀发布 | 逐步转移流量 |
选择原则
| 场景 | 策略 |
|---|---|
| 常规发布 | 滚动部署 |
| 高风险更改 | 蓝绿部署（易于回滚） |
| 需要验证 | 金丝雀发布（使用真实流量测试） |
7. 紧急流程
服务宕机时的优先处理事项
- 评估：症状是什么？
- 稳定局面：保留日志并确定影响范围；仅在已批准的事故处理流程允许时重启
- 回滚：满足回滚触发条件时，使用经过验证且兼容的制品和数据迁移计划
- 调查：稳定后进行
调查顺序
| 检查项 | 常见问题 |
|---|---|
| 日志 | 错误、异常 |
| 资源 | 磁盘空间不足、内存 |
| 网络 | DNS、防火墙 |
| 依赖项 | 数据库、API |
8. 反模式
| ❌ 不要 | ✅ 应该 |
|---|---|
| 在周五部署 | 在一周开始时尽早部署 |
| 仓促部署 | 按流程执行 |
| 跳过预发布环境 | 始终先测试 |
| 部署前不备份 | 部署前备份 |
| 部署后就离开 | 至少监控 15 分钟 |
| 同时进行多项更改 | 一次只进行一项更改 |
9. 决策检查清单
部署前：
- 流程是否适合该平台？
- 备份策略是否就绪？
- 是否记录了回滚计划？
- 是否配置了监控？
- 是否通知了团队？
- 部署后是否有时间进行监控？
10. 最佳实践
- 小规模、频繁部署，优于大型发布
- 对风险较高的更改使用功能标志
- 自动化重复步骤
- 记录每次部署
- 出现问题后，复盘出错之处
- 在需要回滚之前测试回滚
请记住： 每次部署都伴有风险。通过准备而非追求速度来降低风险。
适用场景
当需要执行概述中描述的工作流或操作时，可使用此技能。
限制
- 仅当任务明确符合上述范围时，才使用此技能。
- 不要将输出视为针对特定环境的验证、测试或专家审查的替代品。
- 如果缺少必需的输入、权限、安全边界或成功标准，请停止并请求澄清。
评论
支持 Markdown