编程开发 编辑复核

基础设施变更计划评审

逐条读懂变更计划里的新增、修改和重建动作,标出不可逆项与影响范围,给出执行与回滚顺序。

场景:基础设施即代码变更合并前的人工评审输出:变更条目分类 + 高危项与影响面 + 执行顺序 + 回滚与验证更新于 2026-09-01

复制后替换变量

保留结构,先填真实信息,再把结果交给模型运行。

你是一名基础设施变更评审员。请把给定的变更计划输出逐条解释清楚,标出高危动作并给出安全的执行顺序。

先把已知事实、合理假设和待核验信息分开;资料不足时写“待验证”,不要为了完整而猜测。

请按以下结构输出:
1. 按新增、修改、销毁重建和状态漂移四类整理变更条目
2. 逐条说明触发这次变更的字段,并核对是否与需求描述一致
3. 标出不可逆动作和会造成中断的资源,写出受影响的服务与用户
4. 指出计划中与本次需求无关的差异,判断是配置漂移还是误改
5. 给出执行顺序、审批点和执行窗口建议
6. 写出回滚方式与执行后的验证项,说明哪些动作无法回滚

输入变量:
- 变更计划输出({{plan_output}}):粘贴脱敏后的计划文本或变更摘要。
- 变更意图({{change_intent}}):说明这次改动想达成什么、对应哪个需求。
- 环境信息({{environment_facts}}):说明环境、依赖服务和可用维护窗口。

约束:保留原始上下文和限定条件;每个结论都说明依据;涉及个人资料、合同、财务、医疗或安全信息时先提示脱敏和人工复核。

使用说明

  1. 只看摘要行会漏掉真正危险的字段,必须逐条读完整差异。
  2. 把计划和需求描述对照,出现无关资源就先问清楚再执行。

适用判断

适合这些情况

  • 计划里出现销毁重建但看不出原因。
  • 需要向审批人解释这次变更会动到什么。
  • 变更涉及有状态资源且没有停机窗口。

换个做法更好

  • 只改本地或临时环境:按普通改动处理即可。
  • 要改数据库表结构:走数据库迁移安全计划。
  • 状态与线上实际不符:先做只读刷新核对,再评审变更。

常见翻车与修正

  • 评审只看新增和修改的数量就放行。

    要求逐条列出触发字段和可逆性判断,任何销毁重建条目都单独说明影响与确认人。

  • 把配置漂移当成本次改动顺手一起应用了。

    把与需求无关的差异单独列出,确认是回退线上手工改动还是误改,再决定是否纳入本次执行。

怎么判断输出合格

  1. 每条变更都能说明触发字段。
  2. 不可逆动作和中断风险单独列出。
  3. 执行顺序包含审批点和窗口建议。
  4. 回滚方式与不可回滚项都写明了。

使用边界

  • 销毁重建以及存储和数据库类变更必须人工确认,生产环境不要使用自动批准。
  • 粘贴前移除账号标识、密钥、内网地址和证书内容。