要点简述
- 主责管控。变更管控重在管控、不在变更。变更管控将变更行为、管控流程解耦，变更管控平台主责管控流程，变更行为则由专业领域的变更平台实现
- 泛化变更。变更行为不限于应用领域、也不限于人工触发，凡是有管控需求的变更行为都是管控对象，如机器新购时控成本、OS升级时控合规，谨防蜕化到质量领域
- 重在枢纽。管控流程开放出关键节点，允许检查器通过PluginSPI方式接入；这样，管控平台以PluginSPI的方式、将变更行为和相关领域的烟囱串联起来，成为重要的自动化枢纽
名字解释
- CM：变更管控 Change Management
- MF：管控流 Management Flow，即变更管控的管控流程
- SPI：服务标准接口 Service Provider Interface
管控模型
变更场景，典型步骤如下。变更的开始，是用户提出需求；经自助设计或专家指导，得出实现需求的方案；方案被进一步编排为平台工单；工单被平台执行，产出结果；需求方验收结果，整个流程结束。工单+执行，是变更管控的领域范围。
一个典型的管控流程，关键步骤如下：
- 开始：用户在特定的变更平台上填写完工单、点击提交，触发管控平台、生成管控流程
- 规范检查：对工单内容(编排)做自动检查，检查内容包括对象模型(如参数标准化)、安全(如数据权限合规)、成本(如预算盈亏)等各种规范
- 工单审批：对工单内容(编排)做人工审查，如影响面判断(如变更范围)、质量把关(如代码Diff)；人工审批通常是技术管理动作
- 执行审批：执行前、对执行条件做人工审查，如业务高峰期、封网等；执行审批通常是技术管理动作
- 结果检查：执行后、对执行结果做自动检查，检查内容包括质量(如功能回归、业务监控)、安全(如应用漏洞)等；结果检查可用于阻塞分级执行
- 结束：变更平台执行完工单后，回调管控平台、结束管控流程
规范检查、结果检查是两类最常见的自动检查，但并非全部。管控流程开放出关键节点，允许检查器通过PluginSPI方式接入；管控平台以PluginSPI的方式、将变更行为和相关领域的烟囱串联起来，成为重要的自动化枢纽。
在此感谢滴滴运维团队，他们总结出的五条军规、对我们做变更管控的帮助很大，即①提前通报要记得、②变更步骤要完备、③分级发布要遵守、④高峰窗口要避免、⑤服务检查要执行。该规范缺少标准化的考量。
系统设计
变更管控CM的系统实体关系ER如下图所示，其中工单、管控流、检查项是三类主要实体。
工单是变更内容的平台化编排，关键信息包括所属变更平台、工单动作、变更对象等；变更平台通过OpenAPI、将工单接入到CM。管控流是CM的核心场景，抽象为管控单、管控事件、检查项三层，管控单即为管控流定义，工单、管控单、管控事件、检查项是1对多的关系；管控事件有发单、执行等类型，管控事件的前后可以配置检查项、即前置检查后置检查。检查项分为人工审批、自动检查两类，人工审批即为常规工作流、支持封线窗口等动态条件，自动检查有规范检查、服务检查、自动过单等实现。
管控流的核心状态流转FSM，如下图所示。工单管理员在CM平台配置管控流程，变更平台在创建管控单、执行完成时调用管控平台，审批人在工单审批、执行审批时操作管控平台，三者共同驱动FSM流转。
领域交互
变更管控跨领域的交互，主要发生在变更平台、检查服务、度量审计。变更平台指的是支持特定变更的平台，如云管用于云资源变更、Helm用于K8S组件变更、CD用于应用代码变更。检查服务即自动检查服务提供方，主要负责对象规范(标准化)、安全合规、质量风险、服务异常等检查工作，检查服务只是一种能力抽象、实现上可能包含多个领域。度量审计是对变更内容、变更流程的数据挖掘，驱动各种治理。
变更管控和变更平台的交互最复杂，时序图如下。变更发起人主要在变更平台操作、审批人在管控平台操作，变更平台使用OpenAPI、和变更管控进行前后端交互，创建管控单、执行检查、执行完成是三个主要的交互接口。创建管控单接口的核心参数是变更平台、工单动作、变更对象等，变更对象有服务、部门等类型。
变更管控和检查服务的交互，遵循CM约定的流程和SPI。第一步，检查服务注册到CM，注册信息包括检查类型、通信协议(Http或Ssh)、服务地址(域名)等。第二步，配置检查流程，工单管理员根据流程需要、将检查服务配置到管控流的某个节点，如发单前、执行后。服务检查SPI约定了两个接口，即创建检查任务、查询检查结果，是经典的两阶段设计。这样，管控单执行到流程节点后，CM就会根据SPI约定、调起检查服务，如果服务检查不通过、则阻塞管控流；CM只负责在变更流程中调起和阻塞、不负责具体的检查逻辑，检查逻辑交给检查服务闭环决策。
变更管控和度量审计是异步交互。CM将变更工单、管控流程的信息，以MQ消息的形式、异步给到事件中心，度量审计平台从事件中心订阅消息、完成挖掘。
更详细的变更管控DDD模型，如下图。
一些要点
未来规划
- 容灾。CM被深度耦合、很难做降级，因此要做足保持可用性的容灾手段
- 管控流标准化。CM目前只有标准流程、自定义流程两种，并未划分管控的严格程度