awesome-copilot 的 DevOps 发布计划生成器从预检到回滚的生产级 rollout 实操指南【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot导读devops-rollout-plan 是 awesome-copilot 仓库中面向 GitHub Copilot 的 Agent Skill用于为基础设施与应用变更生成一份完整、可落地、面向生产环境的发布计划rollout plan。本文将完整继承该技能的核心骨架——输入采集、十大输出章节、计划定制维度与纪律清单并结合仓库内的 DevOps Expert 智能体、DevOps 核心原则指令、DevOps 工程指南 与 事故复盘技能 进行源码级补充。读完本文你将掌握如何向 Copilot 描述一次变更以触发该技能、Copilot 应产出哪十大部分的结构化计划、每个部分的具体内容与验证信号以及如何按基础设施类型、风险等级、变更类型和环境裁剪计划。一、技能定位与使用方式devops-rollout-plan是一个标准的 Agent Skill它位于skills/目录以SKILL.md为指令文件通过 front matter 声明name与description由 Agent 按需加载progressive disclosure正如仓库文档 docs/README.skills.md 所描述的 Agent Skills 规范。该技能 front matter 中的 description 即为其触发条件Generate comprehensive rollout plans with preflight checks, step-by-step deployment, verification signals, rollback procedures, and communication plans for infrastructure and application changes.即当用户要求为基础设施或应用变更生成包含预检、分步部署、验证信号、回滚流程与沟通计划的综合发布方案时Copilot 会自动调用本技能。安装与引用方式与仓库内其他技能一致# 通过 GitHub CLI 安装需 GitHub CLI v2.90.0 gh skills install github/awesome-copilot devops-rollout-plan # 或将 skills/devops-rollout-plan 目录复制到本地 skills 目录该技能与仓库中其他 DevOps 资源互补devops-rollout-plan聚焦“发布前如何计划”incident-postmortem 聚焦“发布后如何复盘”DevOps Expert 则提供从 Plan 到 Monitor 的完整闭环方法论三者共同覆盖一次变更的完整生命周期。二、输入采集生成计划前必须收集的四类信息技能明确要求在生成计划之前先收集以下细节缺失时应向用户提问补全而不是直接编造计划。1. 变更描述Change Description变更对象基础设施infrastructure、应用application还是配置configuration版本或状态迁移从哪个版本/状态变到哪个版本/状态from/to解决的问题或新增的功能。这与 DevOps Expert 中 Plan 阶段“Define work, prioritize, and prepare for implementation”的目标一致——先明确“我们在解决什么问题”“验收标准是什么”“需要什么基础设施变更”。2. 环境细节Environment Details目标环境dev、staging、production还是 all基础设施类型Kubernetes、VMs、serverless、容器受影响的服务与依赖当前容量与规模影响验证阈值与回滚决策。3. 约束与要求Constraints Requirements可接受停机窗口acceptable downtime window变更窗口限制change window restrictions审批要求approval requirements法规或合规考虑regulatory/compliance。4. 风险评估Risk Assessment变更的爆炸半径blast radius是否存在数据迁移或 schema 变更回滚的复杂度与安全性已知风险。从源码结构看这四类输入构成了后续所有输出章节的数据来源风险评估直接决定回滚章节的深度约束要求决定沟通计划的时间轴基础设施类型决定验证信号的具体观测对象。三、输出格式十大核心章节全解技能要求生成包含以下十个部分的结构化发布计划。以下逐章展开并结合仓库内其他 DevOps 资源的实现细节进行扩充。1. 执行摘要Executive SummaryWhat / Why / When / Duration做什么、为什么做、何时做、预计耗时风险等级与回滚时间risk level and rollback time受影响的系统与用户影响预期停机时间。执行摘要是给管理层与业务方看的要求一页内说清“这次变更是否值得冒险”因此回滚时间与风险等级必须在此处先行给出。2. 前置条件与审批Prerequisites Approvals所需审批技术负责人technical lead、安全security、合规compliance、业务business所需资源容量capacity、备份backups、监控monitoring、回滚自动化rollback automation部署前备份pre-deployment backups。这一章与 DevOps Expert Release 阶段的“release approvals and gates”“rollback preparation”形成呼应审批即发布门禁gate备份与回滚自动化是“Plan for failure”的具体体现。参考 gem-devops-guidelines 的预部署检查清单本节还建议补充测试通过、代码评审完成、环境变量验证、数据库迁移脚本就绪、回滚计划已确认。3. 预检Preflight Checks基础设施健康验证infrastructure health validation应用健康基线application health baseline依赖可用性dependency availability监控基线指标monitoring baseline metricsGo/no-go 决策检查清单。预检的本质是建立“变更前的基线”只有知道正常时的错误率、延迟、容量水位才能在发布后判断“指标是否回归正常”。这与 DevOps Expert Monitor 阶段的 SLI/SLO 思维一致——没有基线就没有异常。建议为关键服务预先记录错误率、P95 延迟、连接数、队列深度等指标形成 Go/no-go 清单的量化判据。4. 分步发布流程Step-by-Step Rollout Procedure按阶段组织Pre-deployment部署前→ Deployment部署→ Progressive verification渐进验证每个步骤要求每一步的具体命令specific commands for each step每步之后的验证validation after each step耗时预估duration estimates。这是全计划最“可执行”的部分。gem-devops-guidelines 提供了与步骤对应的命令级证据Kubernetes滚动更新默认零停机可用kubectl rollout undo回滚部署策略三选一Rolling默认渐进替换零停机、Blue-green双环境原子切换、秒级回滚、成本 2×、Canary先路由小比例流量需要流量拆分能力健康探针为工作负载配置 startup/readiness/liveness 探针并设定合适的初始延迟与阈值。在编写步骤时应把“验证”内嵌到每个命令之后而不是留到全部部署完再统一验证。耗时预估应来自预检基线而非拍脑袋。5. 验证信号Verification Signals技能给出了按时间窗划分的四级验证信号这是判断发布成功与否的量化框架阶段时间窗验证信号即时Immediate0–2 分钟部署成功、pods/容器已启动、健康检查通过短期Short-term2–5 分钟应用正常响应、错误率可接受、延迟正常中期Medium-term5–15 分钟指标持续稳定、连接稳定、集成工作正常长期Long-term15 分钟无劣化、容量健康、业务指标正常值得注意的细节“部署命令返回成功”不等于“发布成功”——容器启动后仍需观察错误率、延迟与容量。技能强调“Monitor metrics, not just logs”监控指标而不仅是日志这与 DevOps Expert 的监控三支柱Metrics / Logs / Traces / Alerts一致。建议将每个时间窗的验证信号对应到具体指标如 2 分钟内kubectl get pods全部 Ready、5 分钟内错误率低于预检基线、15 分钟后容量指标无异常增长。6. 回滚流程Rollback Procedure决策标准Decision Criteria何时启动回滚回滚步骤Rollback Steps自动化回滚、基础设施回退infrastructure revert或完整恢复full restore回滚后验证Post-Rollback Verification确认系统健康恢复沟通Communication通知利益相关者。这是技能的纪律底线“Always have a tested rollback plan”始终拥有经过测试的回滚计划。gem-devops-guidelines 给出了不同平台的具体回滚命令Kuberneteskubectl rollout undoVercelvercel rollbackDocker重新部署上一个已固定 tag 的镜像因此该指南同时强调“永远固定基础镜像 tag绝不使用:latest”移动端EAS 使用eas update:rollback原生发布回退构建版本商店发布降低分阶段放量比例。回滚决策标准应具体化例如错误率超过基线 X 倍持续 Y 分钟、P95 延迟超过阈值、数据一致性校验失败——而不是模糊的“感觉不对劲”。7. 沟通计划Communication Plan按时间轴推进的沟通节点部署前T-24h发布日程与影响通知部署开始开工通知commencement notice进度更新每 X 分钟一次状态通报完成成功确认回滚如需要问题通知。同时要求输出利益相关者矩阵Stakeholder Matrix通知谁、何时、通过什么渠道、包含什么内容。这是 DevOps Expert 中“Communicate early and often”与 Sharing 支柱的直接落地。一次大版本变更至少应覆盖业务方影响与预期停机、用户支持团队投诉话术、技术负责人技术细节、安全合规如涉及。8. 部署后任务Post-Deployment Tasks即时1 小时验证标准已满足、审查日志短期24 小时监控指标、审查错误中期1 周发布后评审post-deployment review、经验教训lessons learned。第 8 章与 incident-postmortem 形成衔接即使没有事故一次发布也应在 1 周内做轻量评审若发生了事故则应在其 48–72 小时内写出无责备blameless的事故复盘输出带 Owner 与截止日期的行动项。9. 应急预案Contingency Plans针对以下场景逐一给出Symptoms症状、Response应对、Timeline时间线部分失败partial failure性能劣化performance degradation数据不一致data inconsistency依赖失败dependency failure。应急预案与回滚流程的区别在于回滚是“回到上一个已知良好状态”而应急预案还包括不中断服务的前进式修复例如通过 feature flag 关闭新功能、扩容、降级到只读模式等。参考 gem-devops-guidelines 的 feature flag 生命周期create → enable → 5% → 25% → 50% → 100% → 清理每个 flag 都应有 Owner、过期时间与回滚触发条件——这正是应急预案中“快速止血”的现成工具。10. 联系信息Contact Information主/备值班人员primary and secondary on-call升级路径escalation path应急联系人基础设施、安全、数据库、网络。联系信息应具体到个人而非团队与 incident-postmortem 中“action items 必须有具名 Owner”的原则一脉相承。四、计划定制四个维度裁剪发布计划技能明确要求根据以下维度自适应裁剪而非生搬硬套维度选项与处理方式基础设施类型Kubernetes、VMs、serverless、数据库——每类有专属的预检与验证命令风险等级低简化、中标准、高增加额外门禁变更类型代码部署、基础设施、配置、数据迁移——各有侧重章节环境生产完整计划、staging简化、development最小化这一设计理念与 DevOps Expert 的“deploy frequently in small, reversible changes”呼应低风险小变更不必背负生产级完整计划的重担但生产环境的任何变更都不得跳过验证与回滚章节。从代码结构可以推断该技能刻意将“完整模板”与“裁剪维度”分离正是为了让 Copilot 在面对 dev 环境的小配置改动时产出一份一页纸计划面对生产环境的数据库迁移时产出一份几十页的完整方案。五、纪律清单发布文化的八条底线技能在末尾给出了“Remember”纪律清单这是所有章节之上的元规则始终拥有经过测试的回滚计划尽早且频繁沟通监控指标而非仅监控日志记录一切document everything从每次部署中学习绝不在周五下午发布除非是关键修复绝不跳过验证步骤绝不假设“它应该能工作”。其中“Never assume it should work”与第 3 章预检、第 5 章验证信号直接绑定——一切以量化验证为准。这与仓库中 DevOps 核心原则指令 强调的 DORA 四项指标形成完整闭环发布计划降低 Change Failure Rate、快速回滚降低 MTTR、小步高频提升 Deployment Frequency 与缩短 Lead Time。一次执行良好的 rollout本质上就是一次对 DORA 指标的正面贡献。六、与其他仓库资源的联动使用发布 复盘发布后 1 周内若发现问题调用 incident-postmortem 撰写无责备复盘产出带 Owner 与截止日期的行动项发布 专家计划中的部署策略、监控指标、DORA 指标相关问题可由 DevOps Expert 提供 Plan → Monitor 全闭环指导发布 工程细则Docker 镜像 tag 固定、Kubernetes 探针、回滚命令、feature flag 生命周期等实现级细节参考 gem-devops-guidelines发布 基础原则CALMS 文化与 DORA 指标的定义与深层解读见 devops-core-principles。结语devops-rollout-plan的价值不在于模板本身而在于它把一次高风险变更拆解成了可验证、可回滚、可沟通、可复盘的结构化流程先收齐四类输入再产出十大章节再按四维裁剪最后用八条纪律兜底。结合 awesome-copilot 仓库中的专家智能体、核心原则指令与工程细则你可以在 GitHub Copilot 中直接获得一份“从预检到回滚、从发布到复盘”的生产级发布方案——把发布从冒险变成流程。【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
