南途锦域 
变更管理流程繁琐巧用可逆性与证据实现低成本自动化许多变更管理流程往往十分繁琐但对于可逆转的变更我们有机会减轻负担。这是一个闲散的周二下午你花了三个小时在变更管理电话会议上只为获批对生产环境进行 CostCenter 标签更新而受影响的仅仅是财务运营finops报告实际的变更操作用 Terraform 执行只需两分钟。上周你执行了一个 DROP TABLE 操作删除了 10TB 过时的跟踪数据。无论是这次标签更新还是上周的删除操作都需要花费一小时撰写文档以及三小时进行变更管理审核会议。大多数变更管理系统着重于促进团队间的协作、提供变更前后的证据以及建立回滚路径这些都是为了满足常见的需求如避免冲突、合规监管、安排调度以及可审计性和可追溯性。这些需求不容忽视但或许我们可以用更低的成本来满足这些需求让我们看看能否做得更好。理想情况下我们可以逐步实现这一目标即一次自动化验证一项证据然后将其融入现有的变更流程要避免对组织的变更管理流程进行大规模的突然重写。变更的可逆性许多变更管理团队都想了解你的回滚流程下面我们来明确一些关于可逆性的术语。-双向变更执行变更的同一个 API 调用或工具指令也能将其逆转。例如使用 CreateTags/DeleteTags 对 AWS 资源的标签进行更改向前和向后操作使用的是同一个 API 调用只是参数不同。-单向变更定义为“通过不同路径回到变更前的状态”。例如RDS PostgreSQL 主版本升级后若要回退需从备份中恢复到上一个主版本无法直接回退。-破坏性变更导致数据或配置永久丢失。例如销毁一个加密密钥虽然可以生成新密钥但它永远无法与旧密钥相同。有些变更本质上就是单向或破坏性的但如果能将变更设计成具有双向特性即便底层存在单向或破坏性变更也会更容易获得批准。例如采用蓝绿部署 AMI 版本这样回滚操作只需在自动扩展组的启动模板中更改一个参数。尽管底层机制并非双向的但系统的生产状态确实是双向可操作的。变更边界在考虑变更时变更范围很少只涉及你自己的系统。行为契约规定了合作伙伴系统所期望的行为使它们能够判断你的新行为是否仍符合这些期望。-完整契约验证你所做的变更不会违反与上下游合作伙伴系统的任何契约且所有行为都在契约中有明确规定。-部分契约你的系统对其他系统的部分义务在契约中有规定对于未涵盖的变更需要人工审核。-口头/惯性契约行为协议是口头达成的或者系统的行为非常陈旧即便变更完全自动化产生副作用的可能性也相当高。-无边界变更你到底在计划什么具体操作——提供证据需要问自己两个问题“我能否逆转变更”以及“我的合作伙伴能否逆转或承受我的变更所带来的影响”这两个问题并不相同。例如分离实例配置文件很容易逆转重新附加即可但如果在写入过程中进行此操作当重新附加配置文件时丢失的事务也无法恢复也就是说操作可以逆转但影响无法消除。如果你能对这两个问题都给出肯定答案并提供证据证明那么你的团队就可以采用更轻量级、可由机器验证的变更管理流程。破坏性变更即使完全自动化也始终需要进行全面审核。在证明的最强有力的一端需要从较低环境中收集以下工件应用内部工件在查看这些工件清单时要考虑变更审核委员会最希望看到的格式和呈现方式。仅仅将大量系统日志转储到附加在变更记录上的文本文件中并不意味着变更审核委员会会去阅读它。对自己方便并不等同于对他们可接受。- 提交到源代码控制的部署和回滚自动化脚本。- 从源代码控制中拉取脚本并执行的管道。- 部署操作的 API 和系统审计记录。虽然原始日志的完整转储从技术上讲是完整的变更记录但除了你的团队成员其他人很难消化这些内容。- 回滚/恢复操作的 API 和系统审计记录。要建立一个清晰、标准化的摘要让变更管理团队能够理解。- 正常运行时间和稳定性指标。展示变更前后适当的应用程序健康状况和吞吐量指标。要谨慎选择适合你应用程序的指标并确保能够长期支持这些指标。合作伙伴系统工件根据需要从合作伙伴系统收集这些工件。- 显示对部署和回滚操作支持的合同文件。与审计日志一样原始的技术合同规范不太可能满足变更审核委员会的可读性和可追溯性需求。- 与合作伙伴或依赖系统的调度冲突视图。如果你的计算资源有自动化备份要展示你的变更如何不受备份工作负载的影响。合同中也可以描述时间相关的组件审核委员会可能希望借此确保变更不会产生冲突。- 变更前后上下游应用程序的正常运行时间和稳定性指标。漂亮的图表总是受欢迎的。- 显示部署和回滚操作后成功处理的日志。- 向上游和下游依赖项的所有者团队发送的通知记录。根据行为契约发送这些通知以提高可见性。逐步推进在规划变更管理自动化工作时至少要考虑两个方面变更管理最看重哪些证据以及哪些证据手动生成最耗时找到这个平衡点就能在变更管理团队那里取得早期成果并最大程度地节省时间。局限性和权衡-技术实施成本转向可由机器验证的变更管理流程需要时间、精力还需要在人力和技术控制层面进行协商。要循序渐进合理设定预期。-人力实施成本期望变更管理团队成员深入了解你应用程序的部署细节是不现实的。他们通常比较保守之前从你这里收集的证据帮助他们在与审计人员的艰难对话中过关。你提供的证据要在数月或数年后仍有说服力。-无法参与有些团队无法符合轻量级审核的要求因为他们无法生成审计记录或者只能进行手动操作。要尽可能确保所有团队都能公平参与。-组织灵活性每个组织都需要应对紧急情况即“立即止血”的情况。当你的标准变更流程包含所有相关证据能像手动紧急变更一样快速时你就赢得了变更管理这场“游戏”。与变更管理团队沟通了解他们是否愿意采用可由机器验证的变更管理流程。毫无疑问他们会欣赏更简化的流程。记住在这里变更管理团队可以被视为你的客户。与他们合作确定哪种工件格式和交付渠道对双方团队都最有效。寻找一条让大家都能有所收获的途径。云管理、云计算、DevOps、软件开发 变更管理繁琐？巧用可逆性与证据，实现低成本自动化变更管理！
变更管理流程繁琐巧用可逆性与证据实现低成本自动化许多变更管理流程往往十分繁琐但对于可逆转的变更我们有机会减轻负担。这是一个闲散的周二下午你花了三个小时在变更管理电话会议上只为获批对生产环境进行 CostCenter 标签更新而受影响的仅仅是财务运营finops报告实际的变更操作用 Terraform 执行只需两分钟。上周你执行了一个 DROP TABLE 操作删除了 10TB 过时的跟踪数据。无论是这次标签更新还是上周的删除操作都需要花费一小时撰写文档以及三小时进行变更管理审核会议。大多数变更管理系统着重于促进团队间的协作、提供变更前后的证据以及建立回滚路径这些都是为了满足常见的需求如避免冲突、合规监管、安排调度以及可审计性和可追溯性。这些需求不容忽视但或许我们可以用更低的成本来满足这些需求让我们看看能否做得更好。理想情况下我们可以逐步实现这一目标即一次自动化验证一项证据然后将其融入现有的变更流程要避免对组织的变更管理流程进行大规模的突然重写。变更的可逆性许多变更管理团队都想了解你的回滚流程下面我们来明确一些关于可逆性的术语。-双向变更执行变更的同一个 API 调用或工具指令也能将其逆转。例如使用 CreateTags/DeleteTags 对 AWS 资源的标签进行更改向前和向后操作使用的是同一个 API 调用只是参数不同。-单向变更定义为“通过不同路径回到变更前的状态”。例如RDS PostgreSQL 主版本升级后若要回退需从备份中恢复到上一个主版本无法直接回退。-破坏性变更导致数据或配置永久丢失。例如销毁一个加密密钥虽然可以生成新密钥但它永远无法与旧密钥相同。有些变更本质上就是单向或破坏性的但如果能将变更设计成具有双向特性即便底层存在单向或破坏性变更也会更容易获得批准。例如采用蓝绿部署 AMI 版本这样回滚操作只需在自动扩展组的启动模板中更改一个参数。尽管底层机制并非双向的但系统的生产状态确实是双向可操作的。变更边界在考虑变更时变更范围很少只涉及你自己的系统。行为契约规定了合作伙伴系统所期望的行为使它们能够判断你的新行为是否仍符合这些期望。-完整契约验证你所做的变更不会违反与上下游合作伙伴系统的任何契约且所有行为都在契约中有明确规定。-部分契约你的系统对其他系统的部分义务在契约中有规定对于未涵盖的变更需要人工审核。-口头/惯性契约行为协议是口头达成的或者系统的行为非常陈旧即便变更完全自动化产生副作用的可能性也相当高。-无边界变更你到底在计划什么具体操作——提供证据需要问自己两个问题“我能否逆转变更”以及“我的合作伙伴能否逆转或承受我的变更所带来的影响”这两个问题并不相同。例如分离实例配置文件很容易逆转重新附加即可但如果在写入过程中进行此操作当重新附加配置文件时丢失的事务也无法恢复也就是说操作可以逆转但影响无法消除。如果你能对这两个问题都给出肯定答案并提供证据证明那么你的团队就可以采用更轻量级、可由机器验证的变更管理流程。破坏性变更即使完全自动化也始终需要进行全面审核。在证明的最强有力的一端需要从较低环境中收集以下工件应用内部工件在查看这些工件清单时要考虑变更审核委员会最希望看到的格式和呈现方式。仅仅将大量系统日志转储到附加在变更记录上的文本文件中并不意味着变更审核委员会会去阅读它。对自己方便并不等同于对他们可接受。- 提交到源代码控制的部署和回滚自动化脚本。- 从源代码控制中拉取脚本并执行的管道。- 部署操作的 API 和系统审计记录。虽然原始日志的完整转储从技术上讲是完整的变更记录但除了你的团队成员其他人很难消化这些内容。- 回滚/恢复操作的 API 和系统审计记录。要建立一个清晰、标准化的摘要让变更管理团队能够理解。- 正常运行时间和稳定性指标。展示变更前后适当的应用程序健康状况和吞吐量指标。要谨慎选择适合你应用程序的指标并确保能够长期支持这些指标。合作伙伴系统工件根据需要从合作伙伴系统收集这些工件。- 显示对部署和回滚操作支持的合同文件。与审计日志一样原始的技术合同规范不太可能满足变更审核委员会的可读性和可追溯性需求。- 与合作伙伴或依赖系统的调度冲突视图。如果你的计算资源有自动化备份要展示你的变更如何不受备份工作负载的影响。合同中也可以描述时间相关的组件审核委员会可能希望借此确保变更不会产生冲突。- 变更前后上下游应用程序的正常运行时间和稳定性指标。漂亮的图表总是受欢迎的。- 显示部署和回滚操作后成功处理的日志。- 向上游和下游依赖项的所有者团队发送的通知记录。根据行为契约发送这些通知以提高可见性。逐步推进在规划变更管理自动化工作时至少要考虑两个方面变更管理最看重哪些证据以及哪些证据手动生成最耗时找到这个平衡点就能在变更管理团队那里取得早期成果并最大程度地节省时间。局限性和权衡-技术实施成本转向可由机器验证的变更管理流程需要时间、精力还需要在人力和技术控制层面进行协商。要循序渐进合理设定预期。-人力实施成本期望变更管理团队成员深入了解你应用程序的部署细节是不现实的。他们通常比较保守之前从你这里收集的证据帮助他们在与审计人员的艰难对话中过关。你提供的证据要在数月或数年后仍有说服力。-无法参与有些团队无法符合轻量级审核的要求因为他们无法生成审计记录或者只能进行手动操作。要尽可能确保所有团队都能公平参与。-组织灵活性每个组织都需要应对紧急情况即“立即止血”的情况。当你的标准变更流程包含所有相关证据能像手动紧急变更一样快速时你就赢得了变更管理这场“游戏”。与变更管理团队沟通了解他们是否愿意采用可由机器验证的变更管理流程。毫无疑问他们会欣赏更简化的流程。记住在这里变更管理团队可以被视为你的客户。与他们合作确定哪种工件格式和交付渠道对双方团队都最有效。寻找一条让大家都能有所收获的途径。云管理、云计算、DevOps、软件开发