变更控制

基础要点

确保经历评估风险、授权变更和管理变更计划的流程。

组织变更管理涉及的是人员方面；变更控制通常侧重于产品和服务的变化。

应由能够了解风险和预期收益的人员进行评估，不应引入不必要的延误。

标准变更：属低风险的、预授权的变更，易于理解与记录。初创变更时，应全面评估风险、并完成授权，之后不必重复。

一般变更：应根据类型与既定模型来确定需要评估和授权的角色。可手动创建请求，也可由CI/CD 管道进行自动化加速。

紧急变更：如解决事件或部署安全补丁。应尽可能经历与一般变更相同的测试、评估、以及授权环节，实施前可酌情推迟相关文件。由于时间受限，测试较少，因此需要由了解业务风险的高级管理人员授权。

需要传达有关变更的信息，以确保在变更前，涉事人员做好了充分准备。

解读

由于系统与服务的变更往往会引起一段时间的中断，因此在变更请求（Request for Change，RFC）提交的过程中，我们需要围绕着：变更什么？何时变更？变更影响？这三类问题展开。其中包括：

1.需求程度：标准、一般或紧急。

2.变更类型：操作系统、应用软件、硬件设备、网络组件、通信线路、文档目录、配置项、安全相关。

3.风险预判：低、中、高。

4.影响预判：单个应用系统、部分用户群、职能部门范围、多个分支站点、整个企业。

5.变更时间：提议开始的时间、目标完成的时间与耗时。

6.变更内容：当前状态、更改内容、预期目标。

7.回滚计划、事前与事后的测试方案等。

为了对产品和服务的变更进行有效的管理，在规范的企业中，变更请求一定要通过变更管理委员（Change Control Board，CCB）的审查与批准。该委员会的成员一般包括：企业业务部门、IT管理层、技术专业职能部门、以及外包/供应商等的代表。当然，除了固定人员角色之外，某些具体人员可根据实际变更请求的特点来动态调整。

在接到变更请求后，变更管理委员会需要有针对性地对单个请求进行风险评估。主要内容包括：提出人员的角色、变更的合理性、时间安排、变更回报、所需资源以及对其他产品与服务的影响等方面。经过集思广益与讨论磋商之后，委员会做出批准还是拒绝的结论。

在得到变更批准以后，实施人员应当从安全的角度出发，在实施之前确立好目标系统的基准线，也就是俗称的：给系统的当前状态“拍快照”。该基线既可以作为变更后参考比对的依据，又能够成为回滚操作的目标。

而在变更完成后，实施人员既要及时更新配置管理数据库（Configuration Management Data Base）里可能涉及到的配置项（CI），又要做好相应的文档记录，以被后期审计。

值得一提的是，如今由于虚拟化和云服务的调整所引发的变更，与传统的变更管理有着不同之处，我们应当到如下方面：

图4 风险矩阵表

对于镜像与配置模板的修改、云存储空间池的配额、以及虚拟CPU/内存资源的增减等方面，都应做好相应的计划与记录工作。

对于各种事故或故障所导致的被动变更，应当根据既定的协议，与云服务商事先明确好各自的职责。

例如，在何种情况下云服务商有权先采取必要的变更、再通知租户；在何种情况下我们的自行变更需要备案、甚至要得到服务商的批准，以免伤及其他的租户。

实务

根据上述解读中所提到的注意事项，我们企业在管理各项产品与服务的变更时，着重对于请求的如下方面做出了要求：

1.分清变更发起人与实施人，有时候发起变更请求的不一定是真正实施的人员。

2.根据波及范围与紧急程度的不同，我们事先规定好了不同的颜色代码。这样不但方便管理委员会能够从庞杂的记录中一眼认出或者筛选出重大的变更需求，而且也方便引起可能涉及到的技术人员或用户的警觉。

3.请求附件：可以附上必要的截图、邮件或者文档，让变更管理者更为深入和全面地了解到该变更的来龙去脉。如果涉及到比较复杂或者大型的变更，我们还应该适当地配上能体现出变更步骤以及涉及范围的流程图。这样，不但有助于我们理清变更的思路和波及面，还能够在变更后或是出现其他问题时，提供必要的参考与审计。

图5 变更流程管理顺序

而在变更管理委员会方面，我们践行了如下要点：

1.为了避免频繁的变更请求打扰、甚至拖累委员会成员的日常工作，同时也为了避免重要的变更被长期积压，进而给服务执行团队造成压力，我们在评估与审批频率上规定为：一周举行两次审批例会，并分别设置在周二与周四的中午。

2.委员会成员之间共享一张“事件汇总日历”，以方便他们全局性地根据请求的时间，来判定当日的忙闲程度，从而既能够对请求实施的时间进行微调，又能够及时地将新批准的变更，加入到总日历的对应时间段之中。

3.运用现成的模板，向变更将要波及到的人群发送服务中断与变更实施的相关通知。在此，我们同样沿用在请求里规定好了不同的颜色代码。

4.针对在实施后报告上来的变更失败，按需引入事故或问题管理流程。

我们企业的变更管理委员会在具体审批过程中，时常会借助如图4 的风险矩阵表。

总的说来，我们在实际操作中，参考了如图5 的变更流程管理顺序。