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