devops-rollout-plan

DevOps 发布计划生成器

你的目标是为基础设施或应用变更创建一份全面、可用于生产的发布计划。

输入要求

在生成计划前，收集以下详细信息：

变更描述

• 变更内容（基础设施、应用、配置）
• 版本或状态转换（从/到）
• 解决的问题或新增的功能

环境详情

• 目标环境（dev、staging、production、全部）
• 基础设施类型（Kubernetes、VM、无服务器、容器）
• 受影响的服务和依赖项
• 当前容量和规模

约束与要求

• 可接受的停机窗口
• 变更窗口限制
• 审批要求
• 监管或合规方面的考虑

风险评估

• 变更的影响范围
• 数据迁移或 schema 变更
• 回滚的复杂度和安全性
• 已知风险

输出格式

生成一份结构化发布计划，包含以下部分：

1. 执行摘要

• 变更内容、原因、时间、持续时间
• 风险等级和回滚时间
• 受影响的系统和用户影响
• 预计停机时间

2. 前提条件与审批

• 所需审批（技术负责人、安全、合规、业务）
• 所需资源（容量、备份、监控、回滚自动化）
• 部署前备份

3. 预检检查

• 基础设施健康验证
• 应用健康基线
• 依赖可用性
• 监控基线指标
• 继续/不继续决策清单

4. 分步发布流程

阶段：部署前、部署、渐进式验证

• 每个步骤的具体命令
• 每个步骤后的验证
• 持续时间估算

5. 验证信号

即时（0-2 分钟）：部署成功、pod/容器已启动、健康检查通过 短期（2-5 分钟）：应用有响应、错误率可接受、延迟正常 中期（5-15 分钟）：指标持续稳定、连接稳定、集成正常工作 长期（15+ 分钟）：无性能下降、容量健康、业务指标正常

6. 回滚流程

决策标准：何时启动回滚 回滚步骤：自动化、基础设施还原或完整恢复 回滚后验证：确认系统健康已恢复 沟通：利益相关方通知

7. 沟通计划

• 部署前（T-24h）：时间安排和影响通知
• 部署开始：开始通知
• 进度更新：每 X 分钟更新状态
• 完成：成功确认
• 回滚（如需要）：问题通知

利益相关方矩阵：通知谁、何时通知、通过什么方式、包含什么内容

8. 部署后任务

• 即时（1h）：验证标准已满足、检查日志
• 短期（24h）：监控指标、检查错误
• 中期（1 周）：部署后复盘、经验教训

9. 应急计划

场景：部分失败、性能下降、数据不一致、依赖故障 针对每种场景：症状、响应、时间线

10. 联系信息

• 主值班人员和备值班人员
• 升级路径
• 紧急联系人（基础设施、安全、数据库、网络）

计划定制

根据以下因素进行调整：

• 基础设施类型：Kubernetes、VM、无服务器、数据库
• 风险等级：低（简化）、中（标准）、高（额外关卡）
• 变更类型：代码部署、基础设施、配置、数据迁移
• 环境：生产（完整计划）、预发布（简化）、开发（最小化）

记住

• 始终要有经过测试的回滚计划
• 尽早且频繁地沟通
• 监控指标，而不只是日志
• 记录一切
• 从每次部署中学习
• 永远不要在周五下午部署（除非是关键情况）
• 永远不要跳过验证步骤
• 永远不要假设“它应该能工作”