取消
显示结果 
搜索替代 
您的意思是: 
cancel
3405
查看次数
34
有帮助
2
评论
julianchen
Spotlight
Spotlight
变更管理:以万变应万变

说了那么多的配置,思路清奇的您是不是已经想到了它那相爱相杀的好基友--变更管理呢?首先,就算仅仅是对配置管理库里的配置项基线的细微变更,都要准备一份与之对应的变更请求(Requestfor ChangeRFC),其中包括:

  • 变更发起人与实施人:发起变更请求的不一定是真正实施的人。

  • 所涉及到的配置项及类型:服务器、路由交换、存储设备或软件相关等。

  • 简单描述:主要是变更意图、必要性和预期的效果。

  • 波及范围:包括在逻辑上波及的现有IT系统与服务,和在地域上牵扯到的部门、站点或外部客户。

  • 紧急程度:视需要和严重程度进行综合且如实的判断。

  • 请求开始和结束的日期/时间。

  • 最重要、最详细的三大元:实施步骤、后退回滚步骤和完成后的效果测试步骤。

  • 附件:可以附上必要的截图、邮件或文档,让变更管理者更为深入和全面的了解该变更的来龙去脉。

下面是我们正在使用的一个风险矩阵的示例:



















紧急程度
数值
服务级别约定
紧急
21
30 分钟
普通
14
1 个工作日
标准
7
2个工作日
影响
数值
整个组织/所有外部客户
6
多个站点/多个系统与服务
5
单个站点/单个系统
4
个别部门/单个服务
3
个别员工/单个主机
2
实验/测试环境
1
计算公式
紧急程度 + 影响 = 风险
风险范围
风险级别
批准
19 及以上
前期准备有限,变更管理者可能需要发起人额外提供信息或直接与之交流,以确保业务可恢复能力。
15 18
根据背景知识,由变更管理者酌情批准,并手动发送批复通知给发起人。
12 14
由变更管理者直接批准,并自动发送批复通知给发起人。
11 及以下
由系统自动批准,并自动发送批复通知给发起人。
而作为变更管理者最好能够做到:

  • 多找几个臭皮匠组成委员会(Change Control BoardCCB),既能互为备份,又能集思广益、风险共担。

  • 手头应该有一张“事件汇总日历”,能够全局性地根据请求时间来判定当日的忙闲程度,从而在在批复通知里的批准实施的时间项上做适当的微调。

  • 及时地将新批准的变更加入到总日历对应的时间段中。

  • 伺机用现成的模板向变更将要波及到的人群发送服务中断和变更实施通知。当然,重要的变更可以“说三遍”。

  • 针对实施过程中报告上来的变更失败,既要确保能够回滚到原配置项状态,又要引入事故或问题管理流程。


评论
SMG-SH
Level 7
Level 7
这是哪方面的,有点不太懂
青沙流萤
Level 7
Level 7
这是项目管理层面的东西的
入门指南

使用上面的搜索栏输入关键字、短语或问题,搜索问题的答案。

我们希望您在这里的旅程尽可能顺利,因此这里有一些链接可以帮助您快速熟悉思科社区:









快捷链接