devops-rollout-plan

DevOps 发布计划生成器

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

输入要求

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

变更描述

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

环境详情

• 目标环境（开发、预发布、生产、全部）
• 基础设施类型（Kubernetes、虚拟机、无服务器、容器）
• 受影响的服务和依赖项
• 当前容量和规模

约束与要求

• 可接受的停机窗口
• 变更窗口限制
• 审批要求
• 法规或合规性考虑

风险评估

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

输出格式

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

1. 执行摘要

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

2. 前提条件与审批

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

3. 预检检查

• 基础设施健康验证
• 应用健康基线
• 依赖项可用性
• 监控基线指标
• 执行/不执行决策检查清单

4. 分步发布流程

阶段：部署前、部署、逐步验证

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

5. 验证信号

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

6. 回滚流程

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

7. 沟通计划

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

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

8. 部署后任务

• 立即（1小时）：验证标准是否满足，审查日志
• 短期（24小时）：监控指标，审查错误
• 中期（1周）：部署后审查，经验教训

9. 应急计划

场景：部分失败、性能降级、数据不一致、依赖项失败
每个场景：症状、响应、时间线

10. 联系信息

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

计划定制

根据以下因素调整：

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

记住

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