kscz0000 部署流程
安全生产发布的部署原则与决策制定。 学会思考，而非死记脚本。
⚠️ 如何使用此技能
此技能教授部署原则，而非可复制的 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 push, auto-deploy |
| Railway/Render | Git push or CLI |
| VPS + PM2 | SSH + manual steps |
| Docker | Image push + orchestration |
| Kubernetes | kubectl apply |
2. 部署前原则
四大验证类别
| 类别 | 检查内容 |
|---|---|
| 代码质量 | 测试通过、linting 干净、已审查 |
| 构建 | 生产构建成功、无警告 |
| 环境 | 环境变量已设置、secrets 最新 |
| 安全 | 备份已完成、回滚计划就绪 |
部署前检查清单
- 所有测试通过
- 代码已审查并批准
- 生产构建成功
- 环境变量已验证
- 数据库迁移就绪（如有）
- 回滚计划已记录
- 团队已通知
- 监控就绪
3. 部署工作流原则
五阶段流程
1. 准备（PREPARE）
└── 验证代码、构建、环境变量
2. 备份（BACKUP）
└── 在变更前保存当前状态
3. 部署（DEPLOY）
└── 执行并保持监控开启
4. 验证（VERIFY）
└── 健康检查、日志、关键流程
5. 确认或回滚（CONFIRM or ROLLBACK）
└── 一切正常？确认。有问题？回滚。
阶段原则
| 阶段 | 原则 |
|---|---|
| 准备 | 永不部署未测试的代码 |
| 备份 | 没有备份就无法回滚 |
| 部署 | 盯着它发生，别走开 |
| 验证 | 信任但要验证 |
| 确认 | 准备好回滚触发器 |
4. 部署后验证
验证内容
| 检查项 | 原因 |
|---|---|
| 健康检查端点 | 服务正在运行 |
| 错误日志 | 无新错误 |
| 关键用户流程 | 核心功能正常 |
| 性能 | 响应时间可接受 |
验证窗口
- 前 5 分钟：主动监控
- 15 分钟：确认稳定
- 1 小时：最终验证
- 次日：审查指标
5. 回滚原则
何时回滚
| 症状 | 行动 |
|---|---|
| 服务宕机 | 立即回滚 |
| 严重错误 | 回滚 |
| 性能下降 >50% | 考虑回滚 |
| 小问题 | 如果能快速修复则向前修复 |
各平台回滚策略
| 平台 | 回滚方式 |
|---|---|
| Vercel/Netlify | Redeploy previous commit |
| Railway/Render | Rollback in dashboard |
| VPS + PM2 | Restore backup, restart |
| Docker | Previous image tag |
| K8s | kubectl rollout undo |
回滚原则
- 速度优于完美：先回滚，后调试
- 不要叠加错误：一次回滚，不做多次修改
- 沟通：告诉团队发生了什么
- 复盘：稳定后理解原因
6. 零停机部署
策略
| 策略 | 工作原理 |
|---|---|
| 滚动更新 | 逐个替换实例 |
| 蓝绿部署 | 在环境间切换流量 |
| 金丝雀发布 | 渐进式流量转移 |
选择原则
| 场景 | 策略 |
|---|---|
| 标准发布 | 滚动更新 |
| 高风险变更 | 蓝绿部署（易于回滚） |
| 需要验证 | 金丝雀发布（用真实流量测试） |
7. 紧急流程
服务宕机优先级
- 评估：症状是什么？
- 快速修复：如果不确定就重启
- 回滚：如果重启无效
- 调查：稳定后进行
调查顺序
| 检查项 | 常见问题 |
|---|---|
| 日志 | 错误、异常 |
| 资源 | 磁盘满、内存 |
| 网络 | DNS、防火墙 |
| 依赖 | 数据库、API |
8. 反模式
| ❌ 不要 | ✅ 要 |
|---|---|
| 周五部署 | 周初部署 |
| 匆忙部署 | 遵循流程 |
| 跳过预发布 | 先测试 |
| 无备份部署 | 部署前备份 |
| 部署后走开 | 监控 15+ 分钟 |
| 一次多个变更 | 一次一个变更 |
9. 决策检查清单
部署前：
- 流程适合平台？
- 备份策略就绪？
- 回滚计划已记录？
- 监控已配置？
- 团队已通知？
- 有时间监控？
10. 最佳实践
- 小而频繁的部署优于大版本发布
- 对风险变更使用功能开关
- 自动化重复步骤
- 记录每次部署
- 出问题后复盘
- 在需要之前测试回滚
记住： 每次部署都是风险。通过准备而非速度来降低风险。
何时使用
此技能适用于执行概述中描述的工作流或操作。
局限性
- 仅当任务明确匹配上述范围时使用此技能。
- 不要将输出替代为环境特定的验证、测试或专家审查。
- 如果缺少必需的输入、权限、安全边界或成功标准，请停止并请求澄清。