用途
Deployment Procedures 是一套关于生产环境部署的原则与决策方法，目标是帮助使用者建立安全发布的心智模型，而不是提供可直接复制的 bash 脚本。它明确说明：每次部署都是独特的，应理解每一步背后的原因，并把流程适配到自己的平台。
主要能力
平台选择
提供决策树，按部署对象区分路径：静态站点/JAMstack 对应 Vercel、Netlify、Cloudflare Pages；简单 Web 应用分为托管方案（Railway、Render、Fly.io）与自控方案（VPS + PM2/Docker）；微服务对应容器编排；无服务器对应边缘函数、Lambda。并列出各平台的部署方式：Vercel/Netlify 为 Git push 自动部署，Railway/Render 为 Git push 或 CLI，VPS + PM2 为 SSH 加手动步骤，Docker 为镜像推送加编排，Kubernetes 为 kubectl apply。
部署前验证
将检查分为四类：代码质量（测试通过、lint 干净、已评审）、构建（生产构建可用、无警告）、环境（环境变量已设置、密钥有效）、安全（已备份、回滚方案就绪）。并给出部署前检查清单，包括测试通过、代码评审批准、生产构建成功、环境变量核实、数据库迁移就绪、回滚方案记录、团队已通知、监控就绪。
部署工作流
提出五阶段流程：准备（验证代码、构建、环境变量）、备份（变更前保存当前状态）、部署（在监控开启下执行）、验证（健康检查、日志、关键流程）、确认或回滚（一切正常则确认，有问题则回滚）。每个阶段配有原则，例如“绝不部署未测试代码”“没有备份就无法回滚”“部署时盯着它发生，不要走开”“信任但要验证”“随时准备好回滚触发条件”。
部署后验证
需要验证健康端点（服务在运行）、错误日志（无新错误）、关键用户流程（核心功能可用）、性能（响应时间可接受）。验证窗口为：前 5 分钟主动监控，15 分钟确认稳定，1 小时最终验证，次日复查指标。
回滚
按症状决定动作：服务宕机立即回滚，严重错误回滚，性能下降超过 50% 考虑回滚，小问题若修复快则向前修复。各平台回滚方式：Vercel/Netlify 重新部署上一个提交，Railway/Render 在面板回滚，VPS + PM2 恢复备份并重启，Docker 使用上一个镜像标签，K8s 使用 kubectl rollout undo。回滚原则包括：速度优先于完美，先回滚再调试；不要叠加错误，一次回滚而非多次变更；沟通，告知团队发生了什么；稳定后再做复盘。
零停机部署
列出三种策略：滚动（逐个替换实例）、蓝绿（在环境间切换流量）、金丝雀（逐步转移流量）。选择原则：标准发布用滚动，高风险变更用蓝绿（便于回滚），需要验证时用金丝雀（用真实流量测试）。
紧急处理
服务宕机时的优先级：评估症状、不明确时先快速重启、重启无效则回滚、稳定后再调查。调查顺序为日志（错误、异常）、资源（磁盘满、内存）、网络（DNS、防火墙）、依赖（数据库、API）。
反模式与最佳实践
反模式对照表包括：不要在周五部署（应在一周早些时候部署）、不要仓促部署（应遵循流程）、不要跳过预发（应始终先测试）、不要无备份部署（应先备份）、不要部署后走开（应监控 15 分钟以上）、不要一次多个变更（应一次一个变更）。最佳实践包括：小而频繁的部署优于大版本发布、对高风险变更使用功能开关、自动化重复步骤、记录每次部署、出问题后复盘原因、在需要之前先测试回滚。
使用方式
该技能以原则和决策清单形式呈现，使用者需结合自身平台适配流程。部署前决策检查表包括：是否采用适合平台的流程、备份策略是否就绪、回滚方案是否记录、监控是否配置、团队是否通知、之后是否有时间监控。
适用场景
适用于需要向生产环境发布版本的开发者、运维人员和团队，尤其是希望建立统一部署规范、降低发布风险、明确回滚与验证流程的场景。
限制
该技能不提供可直接复制的脚本，强调理解原理并自行适配；具体平台的命令、配置细节和自动化实现需使用者根据自身环境确定。资料中未提供具体收费、价格或平台效果数据。