由 superadmin 于 2024/10/12, 15:32 最后修改
Show last authors
1 (% class="wikigeneratedid" %)
2 [[返回本章节索引>>http://www.itil4hub.cn/bin/view/G%20%E5%8F%82%E8%80%83%E8%B5%84%E6%96%99/ITIL%E5%AE%9E%E6%96%BD%E9%A1%B9%E7%9B%AE%E8%B5%84%E6%96%99/ITIL%E5%AE%9E%E6%96%B]]  [[ 阅读下一篇>>http://itil4hub.cn/bin/view/G%20%E5%8F%82%E8%80%83%E8%B5%84%E6%96%99/ITIL%E5%AE%9E%E6%96%BD%E9%A1%B9%E7%9B%AE%E8%B5%84%E6%96%99/ITIL%E5%AE%9E%E6%96%BD%E9%A1%B9%E7%9B%AE%E6%B5%81%E7%A8%8B%E8%AE%BE%E8%AE%A1%E6%96%B9%E6%A1%88%E9%9B%86/%E9%97%AE%E9%A2%98%E7%AE%A1%E7%90%86/10%20XX%E8%81%94%E5%90%88%E8%AF%81%E5%88%B8%E6%9C%89%E9%99%90%E8%B4%A3%E4%BB%BB%E5%85%AC%E5%8F%B8%E4%BF%A1%E6%81%AF%E6%8A%80%E6%9C%AF%E9%97%AE%E9%A2%98%E7%AE%A1%E7%90%86%E6%B5%81%E7%A8%8B/]]
3
4
5 = **访谈目的** =
6
7
8 在本次变更管理流程评估分析的过程中，HP咨询顾问针对流程规范、人员角色、绩效管理、持续改进、流程集成和支持资源方面信息，与IT维护室运维专家进行详细的访谈和了解，找出相关变更和期望，为流程设计提供依据。
9
10
11 |**访谈对象姓名：**|**夏X、马XX、付XX**
12 |**电话：**|
13 |**部门：**|**IT维护室**
14 |**主要职责：**|
15 |**访谈者姓名：**|**曹XX**
16 |**访谈日期：**|**2013-04-21**
17 |**访谈地点：**|**浙江XX网管中心X层**
18
19 |(% style="width:183px" %)**编号**|(% style="width:939px" %)**访谈变更**
20 |(% style="width:183px" %)(((
21 **1.变更管理**
22
23 **历程**
24 )))|(% style="width:939px" %)(((
25 **中心目前变更管理如何做起来的？ 科室层面对于变更管理流程的认识？变更流程的执行情况？**
26
27 **变更建设历程：**
28
29 •从割接升版流程发展到现在的IMEP变更流程和Excel内部审批流程；
30
31 •中心对于变更管理的要求，最初可能来自于符合sox审计(风险管控)的要求，由于sox审计考核是一票否决，领导很重视；
32
33 **变更管理意识：**
34
35 现在的个人变更管控意识方面还不是很高，哪些要走流程还不太清晰，各个科室走得流程也不太一样。
36
37 **变更流程的执行：**
38
39 •如割接数据、升级换版、硬件升级，哪些走流程，哪些线下审批，甚至于有些专业由于变更操作频繁，觉得走线上流程效率低下，而不走imep流程,线下的审批可能在线上不体现；
40
41 •部门也没有强制要求走流程，会导致变更执行时外室不知道变更的发生；
42
43 •现在要求变更发公告，至少提醒监控室和IT维护室知晓。目前的线上的流程只是实际流程的一部分环节。
44 )))
45 |(% style="width:183px" %)**2.管理层要求**|(% style="width:939px" %)(((
46 **对于领导要求的“变更流程可以复杂”如何理解？**
47
48 **变更信息的共享：**
49
50 •要做到有变更操作知会必要的部门。以前的维护模式不通知别的室，只是做到了监控室知道，明了变更后的第二天出现问题可以找到责任人。（变更信息的输出与信息共享）
51
52 •希望对变更流程（类型）做一些定义，由于人员有限，变更频次高，imep上的变更流程要跑得顺，在有限的资源下要有效率。
53
54 •要清晰变更的分工职责，以后的集中运维模式下，考虑要不要细化子任务单（原来是方案书，指令式的要求厂商去做），子任务谁来做？目前变更结束后的回顾做得不够，以后变更后业务要确认才行。以前是变更后邮件确认，但第二天又出问题了。
55
56 •加强变更方案审批的控制。以往回退方案做得也不够好，业务升版几乎没有因为回退计划方面的问题而打回变更计划
57
58 •还有，第二天的变更值守保障工作安排也比较差。
59 )))
60 |(% style="width:183px" %)**3.制度与审计要求**|(% style="width:939px" %)(((
61 **中心现有变更相关制度要求? 外部审计机构的相关审计情况？**
62
63 根据sox审计要求，但sox更倾向于安全管控（账号，安全等），表格记录也都是造出来的，sox审计涵盖的系统也越来越少（越来越形式化）。注：需要提供sox的审计记录和网管中心关于变更管控的制度。 
64 )))
65 |(% style="width:183px" %)**4.流程管理目标**|(% style="width:939px" %)(((
66 **有没有正式定义变更管理的流程和目标?  **
67
68 领导们看结果，前提在于变更要严格管控，原来的主机配置很高（通过高配置来弥补高可靠性、可用性方面的事情），现在小型机往刀片（X86）上迁回，系统可靠性、可用性都会降低（比如能否做割接，是否在变更里管理），同时那么多设备都转来IT维护室，如果再不管控变更，风险比较大。
69 )))
70 |(% style="width:183px" %)**5.变更角色职责**|(% style="width:939px" %)(((
71 **变更的计划安排？是否有变更时间窗口？**
72
73 现在很多变更都是被动式的，希望有一个常规的变更计划，让我们知道一段时间后的变更计划，好安排相应的人力资源，CAB会议也好提前安排召开。希望制定变更窗口，再急的变更，也要给IT运维室留几天的余量，否则不接受，这个要做出定义。
74
75
76 **有没有专人负责变更管理流程，对整体流程负责，并授权定义、管理、改进流程？**
77
78 在变更方面，如何管控变更，领导希望有一个专门的变更管理部门来管控。
79
80
81 **在变更中有没有人负责变更的协调，沟通，审批，审计，这些人是哪些人组成的?注意:是否变更委员会，组成的合理性？**
82
83 需要专门的变更经理，应该设定AB角。最好找一个铁面无私的人来做，还需要管控变更中做私活，如停机检修中自己多加一个脚本上去，要考虑如何控制。
84 )))
85 |(% style="width:183px" %)**6.变更发起与受理**|(% style="width:939px" %)(((
86 **对于IT维护室来说，变更的来源有哪些？这些变更的原因是什么？如何受理这些变更？**
87
88 变更的来源：
89
90 1、工程新建、扩容入网（新业务系统上线：“资源池”，“云平台”；已有系统扩容：“短信智能网”，一套一套扩的；）
91
92 2、业务系统升级版本（系统升版：业务侧升版本，业务新功能 ）
93
94 3、安全扫描后发现的漏洞打补丁（安全升版：巡检、安全扫描发现漏洞）
95
96 4、硬件更换、性能调优之类的变更（IT升版：硬件升级、性能优化 ）
97
98
99 变更的原因：
100
101 现在的评估仅限于评估方案本身，不评估变更的必要性，以后最好由业务部门在变更流程工具中负责评估变更的必要性
102
103
104 变更的受理：
105
106 1.业务发起：业务方面引发的变更需求，会跟业务接口人联络。业务部门会走割接升版，（有两个选项：权限申请、是否涉及资产变更）自己发起imep工单。
107
108 2. 业务接口人：IT运维室内部登记的变更单，会走内部变更流程。
109
110 3. 简单操作变更、紧急操作变更、一般操作变更没有明确定义。
111 )))
112 |(% style="width:183px" %)**7.变更风险评估**|(% style="width:939px" %)(((
113 **每一个变更发生之前是不是进行资源，影响及其风险的评估?依据有哪些？评估的深度如何？评估后是否都经过领导审批(授权)？**
114
115 **风险评估的方式和依据：**
116
117 一般是业务维护人员、领导、各专业技术人员参与评估。现在的评估仅限于评估方案本身,，IT维护室参与评估。
118
119 目前驻场工程师参与变更评估，能力有限，但由于设备品牌太多，技术比较复杂，现场是否有条件配置相关专家参与变更评估，可能不太现实，有些非核心业务的变更也不一定需要配备这样高等级的专家资源。
120
121
122 CAB定期开会，是否可能实现？
123
124 对于非常规的变更，方案有一定复杂度，确实需要制定CAB会议制度，CAB会议的组织权在IT维护室，CAB评审意见要室经理以上级别的领导签字授权。
125
126
127 变更审批的回退手续？
128
129 原则上原路退回给上一步，领导也可以直接cancel，但要考虑谁告知给发起人。建议是变更主管。
130 )))
131 |(% style="width:183px" %)**8.复杂变更实例**|(% style="width:939px" %)(((
132 **举例一个（最复杂的）变更流程是怎么来做的(实例：主机，交换机或者存储的变更从提交开始的到结束的做法)**
133
134 **变更实例：**IP计费认证系统，由于业务需求产生的计划内变更（非故障），需要做一个存储的扩容，通过协调HP的实施人员，进行磁盘的划分，需要协调Linux的专家进行文件系统创建和配置，同时还需要协调HP金牌服务人员进行主机HBA卡的配置等，同时也存在刀片重启后不能启动的业务风险。这个变更的量比较大、时间跨度比较长，算是比较复杂点的变更.
135
136
137 **变更原因：**业务需求（故障处理，问题解决）
138
139
140 **变更发起：**业务部门的业务负责人（网管中心的10个科室都有可能，前提是系统移交到IT）发起变更需求。
141
142
143 **变更受理：**IT维护室专业接口人（IT维护室设置了专业组和业务接口人，目前业务接口人没有AB角设置）受理变更。
144
145
146 **变更评估：**
147
148 没有做过的变更，先进行讨论。通过项目启动会初步的过一下，进行变更评估，等到讨论完之后，再出方案
149
150
151 **方案撰写：**方案由专业接口人根据技术需求转化，通过厂商来进行方案撰写（按照既定的方案模板）。方案内容包括，操作人、操作方案、时间、地点、回退方案、应急联系方式等。撰写完成后，再交给业务负责人确认，比较重要的要当面审核。具体的执行任务，一般要求细化到命令级。重复性的方案在具体的实施人手里，相应的方案是都有的，目前没有上收管理。
152
153
154 **跨专业协作：**在方案书写过程中，有实施方牵头方案撰写和跨专业协调。
155
156
157 **变更角色：**变更负责人（不跨专业的是变更所在小组的组长，跨专业的是业务接口人），变更实施人（具体任务的执行人）。
158
159
160 **变更授权：**之前有操作确认表，现在又松了。现在是基于信任，一般由组长进行。领导对于技术问题无法负责，而专业组长又会出现自己审自己。
161
162
163 **变更实施：**有变更实施人员和协维人员进行（协维人员负责技术上把关），厂商基于维保合同进行。正式实施前，还需要申请进出权限，提交门禁权限审批（张卷的审批，目前有权限开放使用问题）；实施的时候，至少是双人参加，一个人监督、厂商来实施。
164
165 注意：方案在实施的时候是可以变通的，但是需要告知（目前人太少15人，一周5-6次变更。1.需要提高自身人员能力，2.在方案中尽可能细）
166
167
168 **变更通告：**同时也会通过电子化短信平台，通知业务人员和监控人员；通告内容包括：实施开始时间、地点、系统、影响、恢复时间），同时通过此平台，进行加班统计。
169
170
171 **变更意外处理：**对于以外的情况，需要进行技术准备（备机等）；晚上万一出问题需要应急方案、应急联系人等。目前的执行力有差距，应急方案也不够健全。主要还是看风险，在高可用性环境下的成熟变更（比如换个硬盘）可以简单，但是还需要考虑风险，在内容上要有要求（做一个模板就可以）。
172
173
174 **应急处理上报：**需要有上报机制，目前是打给组长、领导、业务负责人或者应急联系人等，但是具体找谁不明确。实施过程中的问题，明确的要求和制度。监督的是，权限管理，通知应急联系人。简单操作。
175
176
177 **变更失败：**一般进入故障处理。时间过长，影响业务的属于故障，变更无法执行需要回退的。
178
179 **变更的角色：**变更业务负责人、业务接口人、专业组、实施人、领导、归档管理员（SPOC）、应急联系人、监控人。
180
181
182 **变更记录：**记录完整性有差距，用得比较少，每个组有专人记录，一般是做告警日清的人。
183
184 **变更如何关闭:**实施完之后，会发一个结果出来，小平台中申请报结。就正式关闭。
185
186
187 **变更实施后处理:**目前暂无。
188 )))
189 |(% style="width:183px" %)**9.紧急变更管理**|(% style="width:939px" %)(((
190 **针对紧急变更怎么做的?关注紧急变更后行为（注意是否有补录，补测）**
191
192 从业务需求层面提出的变更有些是领导或市场的紧急需求，如亲情网，变更要求紧急实施（快速上线、快速实施），还有如应付安全检查，扫出来漏洞需要紧急修复（有刚性的时限要求，应对检查）。业务要求的及时性和变更风险控制要折衷考虑。
193
194
195 **变更是否会按照预定时间完成?**
196
197 变更时效的考虑：
198
199 从业务需求层面提出的变更有些是领导或市场的紧急需求，可以理解为必须执行的。业务要求的及时性和变更风险控制要折衷考虑。
200
201
202 **每个变更是否都制定了回退计划?实施过程中，出现意外如何处理？**
203
204 变更异常处理：
205
206 方案到了现场发现与实际情况不匹配，如无磁带机备份系统，现在没有明确的处置要求，都是临时随机处理。最理想的情况就是变更执行直接按照方案粘贴复制，但现在难以做到，同时这也表示变更回顾做得不好，因为没出事领导就看不到。现在测试环境也难以跟生产环境一一对应，就连重要系统也不能一一对应，还有像存储这样的设备，上面跑的业务关联性很大，难以复制，找不到这样的设备做测试环境。要制定规则，约束变更发现异常是否升级通知领导或技术主管。
207
208
209 **失败的变更如何处理？**
210
211 分为应用和IT基础架构两方面原因导致要回退。这时双方要互相配合，要有明确召集人，这个应该在回退方案中事先指定。标准变更方案也要评审，可以最初要先稳定下来，以后再省去审批手续。但标准变更起码要在imep系统里登记。要控制非故障类的紧急变更，现在有些变更时间太紧，做成了事实上的紧急变更。一般应该提前一周，有时间走流程，便于做标准化管控的事情。
212
213
214 **变更如何关闭?对于这些变更，有没有做定期的回顾和分析?**
215
216 要实施变更后值守制度，可以让CAB来做重要变更的回顾，这样CAB议程较长，需要专门的变更经理，应该设定AB角。最好找一个铁面无私的人来做，还需要管控变更中做私活，如停机检修中自己多加一个脚本上去，要考虑如何控制。
217 )))
218
219
深圳市艾拓先锋企业管理咨询有限公司