收益：
- 能够利用人工智能起草变更请求、风险评估和回滚计划，并使变更安全且可预测
- 能够使用自己的依赖信息扩展域，对可检索性进行分类，并获得使用金丝雀计划逐步部署的能力。
- 能够理解是人批准、安排变革并承担变革的责任，并获得纪律，在没有成功标准和回头路的情况下不实施变革。
变更管理：利用 AI 进行风险评估、回滚和维护窗口
生产系统中的绝大多数灾难不是由攻击引起的，而是由更改引起的：补丁、配置更新、发布发布、“次要”修复。这就是为什么每个成熟的组织都有变革管理：规划生产变革、评估其风险、批准它、实施它并在必要时回滚它的规范过程。目标不是阻止变革，而是使其安全且可预测。在这里，人工智能是起草变更请求、列出风险和受影响的系统、建立回滚计划框架和准备部署清单的强大助手。但基本规则仍然存在：人工智能生成记录变化和风险的蓝图；批准、安排变更并负责变更的人。
在本单元中，变更请求、风险评估、回滚计划、维护窗口、金丝雀/分阶段分发和 CAB（变更咨询委员会）的概念；您将学习如何利用人工智能来规划安全变革。
剖析一个好的变更请求
不受控制的改变是“我更新了这个”这句话；受控的改变是一个计划。一个好的变更请求可以回答以下问题：发生了什么变化？ （范围），为什么？ （理由），哪些系统受到影响？ （域和依赖项），风险级别是多少？ （低/中/高），什么时候？ （维护窗口），如何申请？ （步骤）、如何验证？ （成功标准），坏了怎么找回来？ （回滚），谁批准？ （权威）。人工智能很快就填补了这个骨架——但真正了解领域和风险、了解组织的是你；您可以使用自己的依赖性知识来完成人工智能的列表。
提示：变更中最常被忽视的两个部分是“回滚计划”和“成功验证标准”。如果在实施更改之前您没有对“如果出现问题，我到底该用哪个命令转向哪里”和“如何证明它是成功的”等问题的书面答案，那么该更改还没有准备好。
回滚：每次变更的出口
变革管理的核心是周转计划。每个变更都必须有一个回滚路径：回滚补丁、恢复之前的配置、回滚版本到之前的版本、从快照回滚。关键的区别是：有些更改很容易恢复（配置行），有些更改是不可恢复的或非常困难（数据库模式迁移、数据删除）。不可逆转的更改是最高风险级别，需要最多的关注、最多的备份和最窄的维护窗口。询问 AI“此更改是否可以恢复，如果不能，我应该采取哪些额外的安全措施？”
维护窗口和分阶段部署
维护窗口是一个预先宣布的时间段，在此期间更改将影响最少的用户 - 通常是在夜间或流量较低的周末。但选择好时间还不够，还需要注意。逐步推出变革进一步降低了风险。金丝雀部署是首先将更改应用到一小部分（一台服务器，5％的用户），对其进行监控，如果没有问题则将其传播。这样，一个错误不会影响整个舰队，而是影响一小部分，并且会被及早发现。您可以要求 AI 提供分阶段部署计划和每个阶段要跟踪的指标。
一步一步：人工智能辅助变革
- 起草请求。在上面的标题中记录 AI 的更改。
- 扩大影响。使用您自己的依赖关系图完成 AI 受影响系统的列表； “还有什么与此服务相关？”
- 对风险进行分类。低/中/高和可逆？它需要最严格的流程，要求很高且不可逆转。
- 写一个回滚并测试它。写下回滚步骤，如果可能的话，在测试环境中尝试回滚——无法回滚的“回滚计划”不算是计划。
- 规划窗户和楼层。定义维护窗口和金丝雀阶段，以及每个阶段要监控的指标。
- 确认和沟通。获得当局批准（CAB，如有必要），通知受影响者，实施、监控、验证。
三个迷你箱子
案例 1 — 回滚计划挽救了这一夜。一个团队应用了 Web 服务器补丁；该补丁意外地破坏了依赖关系，站点开始出现 500 错误。但变更请求中有 AI 准备的明确回滚步骤：“删除补丁，恢复之前的包，重新加载服务。” 6分钟后球队返回。如果没有回滚计划，在半夜寻找根本原因时，停机可能会持续几个小时。
案例 2 — Canary 发现了 5% 的 bug。将发布新版本。该团队要求 AI 提供一个交错部署计划：首先是 1 个服务器，观察，然后是 25%，然后是全部。 Canary 服务器上的响应时间增加了一倍；分发已停止。该错误仅存在于一台服务器上，95% 的用户未受影响。如果一下子蔓延开来，整个服务就会崩溃。
案例 3 — 不可逆转变化的附加措施。计划进行数据库模式迁移——这一更改很难恢复。工程师向AI询问风险； YZ表示，这一变化是不可逆转的，并建议进行完整备份、单独测试运行和缩小窗口。该团队在迁移之前进行了完整备份，并首先在副本上进行了尝试。迁移过程中出现了问题，但得益于备份，20分钟内就恢复了一致性。
四个可复制模板
1) 变更请求草案：
您的角色：变革管理专家。起草以下变更的变更请求：[变更]。标题：内容/原因、受影响的系统和依赖项、风险级别（低/中/高 + 理由）、是否回滚、实施步骤、成功验证标准、回滚步骤、维护窗口建议、所需批准。将您不确定的依赖项标记为“验证”。
2）风险和影响评估：
从风险角度评估以下变化：[变化]。 (1) 列出可能受到直接和间接影响的系统，(2) 最坏的情况是什么，(3) 它是否可逆，如果不可逆，我应该采取哪些额外措施，(4) 证明风险水平的合理性。说明这是初步评估，决定是我的。
3）创建回滚计划：
为[变更]编写逐步回滚计划。确保每一步都可以复制和验证。如果更改中有不可逆转的部分，请清楚地说明并写下我应该为它们进行哪些备份。添加如何验证Rollback是否成功。
4）分阶段分配（金丝雀）计划：
为以下部署建议一个[部署]分阶段计划：哪些阶段（例如 1 个服务器 -> 25% -> 全部），每个阶段我应该等待多长时间，以及我应该跟踪哪些指标（响应时间、错误率等）？如果超过什么阈值，我应该停止并回滚部署？清楚地写下你的决策点。
弱提示/强提示
弱提示：
我应该应用这个补丁吗？
没有上下文，没有影响，没有冗余，没有窗口。人工智能既不了解你的系统，也不了解你的风险；它给出的“是/否”是一种不负责任的猜测。
强力提示：
您的角色：变革管理专家。我将向生产中的一组网络服务器（8 个服务器，位于负载均衡器后面）应用安全补丁。给我：（1）针对此更改的草稿更改请求，（2）可能受影响的依赖项（我将确认），（3）回滚步骤，（4）金丝雀计划为 1 个服务器 -> 25% -> 全部以及我将在每个阶段监控的指标。证明风险水平的合理性。我批准并决定。
更改功能
低风险
高风险
可逆性
轻松回滚
不可撤销/困难
域
单份，隔离
多服务、依赖链
分布
可以直接
强制金丝雀+窄窗
批准
团队内
CAB / 最高批准
备用
标准型
额外的完整备份+测试运行
常见错误
- 在没有回滚计划的情况下实施。如果没有写下回去的路，改变就是一场赌博。
- 缩小影响范围。绕过附加到服务的隐藏依赖项将导致意外的侧面中断。
- 将不可逆转的变化误认为是平常的变化。架构迁移、数据删除等变更需要最严格的流程和全量备份。
- 一下子就传遍了整个舰队。如果没有 Canary，一个错误就会同时影响所有用户。
- 没有定义成功标准。如果没有写出“成功”的含义，您可能会将损坏的更改误认为是“完成”。
注意：AI 生成的受影响系统的列表是初步列表，而不是完整列表。人工智能不知道你的组织的依赖关系； “如果这个服务崩溃了，还有什么会崩溃？”这个问题的确切答案在于你的企业知识。假设人工智能的列表不完整并扩展它。
总之
大多数生产灾难都是由变化引起的，而不是攻击；变更管理不会阻止变更，而是使其变得安全且可预测。人工智能;快速起草变更请求、风险评估、回滚计划和分阶段部署清单。但是用您真正的依赖知识扩展领域，对可逆性进行分类，编写回滚并在可能的情况下对其进行测试，使用维护窗口和金丝雀来分配风险，定义成功标准。是人批准、安排变革并承担变革的责任； AI是加速该计划的合作伙伴。
应用任务
选择您计划很快（或最近进行）的生产变更。让 AI 使用上面的“变更请求草案”模板准备完整的变更请求。将 AI 生成的“受影响系统”列表扩展为至少两个具有您自己的依赖信息的项目。使用“生成回滚计划”模板打印出回滚步骤，并确定是否存在无法回滚的更改部分。最后，提出一个金丝雀计划。将整个计划总结为 6 点，并注明需要哪些批准。
清单
- [ ] 我是否准备了变更请求，其中包括变更内容/原因、影响、风险、步骤、验证和回滚？
- [ ] 我是否使用自己的依赖信息扩展了 AI 受影响系统的列表？
- [ ] 我是否已将更改分类为可逆还是不可逆？
- [ ] 我写了回滚步骤并在测试环境中尝试过，如果可以的话？
- [ ] 我是否确定了维护窗口和金丝雀部署计划以及每个阶段的监控指标？
- [ ] 我是否定义了成功验证标准并获得了必要的批准？