变更管理:以万变应万变
说了那么多的配置,思路清奇的您是不是已经想到了它那相爱相杀的好基友--变更管理呢?首先,就算仅仅是对配置管理库里的配置项基线的细微变更,都要准备一份与之对应的变更请求(Requestfor Change,RFC),其中包括:
- 变更发起人与实施人:发起变更请求的不一定是真正实施的人。
-
- 所涉及到的配置项及类型:服务器、路由交换、存储设备或软件相关等。
-
- 简单描述:主要是变更意图、必要性和预期的效果。
-
- 波及范围:包括在逻辑上波及的现有IT系统与服务,和在地域上牵扯到的部门、站点或外部客户。
-
- 紧急程度:视需要和严重程度进行综合且如实的判断。
-
- 请求开始和结束的日期/时间。
-
- 最重要、最详细的三大元:实施步骤、后退回滚步骤和完成后的效果测试步骤。
-
- 附件:可以附上必要的截图、邮件或文档,让变更管理者更为深入和全面的了解该变更的来龙去脉。
-
下面是我们正在使用的一个风险矩阵的示例:
紧急程度 | | |
| | |
| | |
| | |
| |
| |
| |
| |
| |
| |
| |
| |
|
| | |
| | 前期准备有限,变更管理者可能需要发起人额外提供信息或直接与之交流,以确保业务可恢复能力。 |
| | 根据背景知识,由变更管理者酌情批准,并手动发送批复通知给发起人。 |
| | 由变更管理者直接批准,并自动发送批复通知给发起人。 |
| | |
而作为变更管理者最好能够做到:
- 多找几个“臭皮匠”组成委员会(Change Control Board,CCB),既能互为备份,又能集思广益、风险共担。
-
- 手头应该有一张“事件汇总日历”,能够全局性地根据请求时间来判定当日的忙闲程度,从而在在批复通知里的批准实施的时间项上做适当的微调。
-
- 及时地将新批准的变更加入到总日历对应的时间段中。
-
- 伺机用现成的模板向变更将要波及到的人群发送服务中断和变更实施通知。当然,重要的变更可以“说三遍”。
-
- 针对实施过程中报告上来的变更失败,既要确保能够“回滚”到原配置项状态,又要引入事故或问题管理流程。
-