1.变更管理

历程

中心目前变更管理如何做起来的？ 科室层面对于变更管理流程的认识？变更流程的执行情况？

变更建设历程：

•从割接升版流程发展到现在的IMEP变更流程和Excel内部审批流程；

•中心对于变更管理的要求，最初可能来自于符合sox审计(风险管控)的要求，由于sox审计考核是一票否决，领导很重视；

变更管理意识：

现在的个人变更管控意识方面还不是很高，哪些要走流程还不太清晰，各个科室走得流程也不太一样。

变更流程的执行：

•如割接数据、升级换版、硬件升级，哪些走流程，哪些线下审批，甚至于有些专业由于变更操作频繁，觉得走线上流程效率低下，而不走imep流程,线下的审批可能在线上不体现；

•部门也没有强制要求走流程，会导致变更执行时外室不知道变更的发生；

•现在要求变更发公告，至少提醒监控室和IT维护室知晓。目前的线上的流程只是实际流程的一部分环节。

对于领导要求的“变更流程可以复杂”如何理解？

变更信息的共享：

•要做到有变更操作知会必要的部门。以前的维护模式不通知别的室，只是做到了监控室知道，明了变更后的第二天出现问题可以找到责任人。（变更信息的输出与信息共享）

•希望对变更流程（类型）做一些定义，由于人员有限，变更频次高，imep上的变更流程要跑得顺，在有限的资源下要有效率。

•要清晰变更的分工职责，以后的集中运维模式下，考虑要不要细化子任务单（原来是方案书，指令式的要求厂商去做），子任务谁来做？目前变更结束后的回顾做得不够，以后变更后业务要确认才行。以前是变更后邮件确认，但第二天又出问题了。

•加强变更方案审批的控制。以往回退方案做得也不够好，业务升版几乎没有因为回退计划方面的问题而打回变更计划

•还有，第二天的变更值守保障工作安排也比较差。

中心现有变更相关制度要求? 外部审计机构的相关审计情况？

根据sox审计要求，但sox更倾向于安全管控（账号，安全等），表格记录也都是造出来的，sox审计涵盖的系统也越来越少（越来越形式化）。注：需要提供sox的审计记录和网管中心关于变更管控的制度。  

有没有正式定义变更管理的流程和目标?  

领导们看结果，前提在于变更要严格管控，原来的主机配置很高（通过高配置来弥补高可靠性、可用性方面的事情），现在小型机往刀片（X86）上迁回，系统可靠性、可用性都会降低（比如能否做割接，是否在变更里管理），同时那么多设备都转来IT维护室，如果再不管控变更，风险比较大。

变更的计划安排？是否有变更时间窗口？

现在很多变更都是被动式的，希望有一个常规的变更计划，让我们知道一段时间后的变更计划，好安排相应的人力资源，CAB会议也好提前安排召开。希望制定变更窗口，再急的变更，也要给IT运维室留几天的余量，否则不接受，这个要做出定义。

有没有专人负责变更管理流程，对整体流程负责，并授权定义、管理、改进流程？

在变更方面，如何管控变更，领导希望有一个专门的变更管理部门来管控。

在变更中有没有人负责变更的协调，沟通，审批，审计，这些人是哪些人组成的?注意:是否变更委员会，组成的合理性？

需要专门的变更经理，应该设定AB角。最好找一个铁面无私的人来做，还需要管控变更中做私活，如停机检修中自己多加一个脚本上去，要考虑如何控制。

对于IT维护室来说，变更的来源有哪些？这些变更的原因是什么？如何受理这些变更？

变更的来源：

1、工程新建、扩容入网（新业务系统上线：“资源池”，“云平台”；已有系统扩容：“短信智能网”，一套一套扩的；）

2、业务系统升级版本（系统升版：业务侧升版本，业务新功能 ）

3、安全扫描后发现的漏洞打补丁（安全升版：巡检、安全扫描发现漏洞）

4、硬件更换、性能调优之类的变更（IT升版：硬件升级、性能优化 ）

变更的原因：

现在的评估仅限于评估方案本身，不评估变更的必要性，以后最好由业务部门在变更流程工具中负责评估变更的必要性

变更的受理：

1.业务发起：业务方面引发的变更需求，会跟业务接口人联络。业务部门会走割接升版，（有两个选项：权限申请、是否涉及资产变更）自己发起imep工单。

2. 业务接口人：IT运维室内部登记的变更单，会走内部变更流程。

3. 简单操作变更、紧急操作变更、一般操作变更没有明确定义。

每一个变更发生之前是不是进行资源，影响及其风险的评估?依据有哪些？评估的深度如何？评估后是否都经过领导审批(授权)？

风险评估的方式和依据：

一般是业务维护人员、领导、各专业技术人员参与评估。现在的评估仅限于评估方案本身,，IT维护室参与评估。

目前驻场工程师参与变更评估，能力有限，但由于设备品牌太多，技术比较复杂，现场是否有条件配置相关专家参与变更评估，可能不太现实，有些非核心业务的变更也不一定需要配备这样高等级的专家资源。

CAB定期开会，是否可能实现？

对于非常规的变更，方案有一定复杂度，确实需要制定CAB会议制度，CAB会议的组织权在IT维护室，CAB评审意见要室经理以上级别的领导签字授权。

变更审批的回退手续？

原则上原路退回给上一步，领导也可以直接cancel，但要考虑谁告知给发起人。建议是变更主管。

举例一个（最复杂的）变更流程是怎么来做的(实例：主机，交换机或者存储的变更从提交开始的到结束的做法)

变更实例：IP计费认证系统，由于业务需求产生的计划内变更（非故障），需要做一个存储的扩容，通过协调HP的实施人员，进行磁盘的划分，需要协调Linux的专家进行文件系统创建和配置，同时还需要协调HP金牌服务人员进行主机HBA卡的配置等，同时也存在刀片重启后不能启动的业务风险。这个变更的量比较大、时间跨度比较长，算是比较复杂点的变更.

变更原因：业务需求（故障处理，问题解决）

变更发起：业务部门的业务负责人（网管中心的10个科室都有可能，前提是系统移交到IT）发起变更需求。

变更受理：IT维护室专业接口人（IT维护室设置了专业组和业务接口人，目前业务接口人没有AB角设置）受理变更。

变更评估：

没有做过的变更，先进行讨论。通过项目启动会初步的过一下，进行变更评估，等到讨论完之后，再出方案

方案撰写：方案由专业接口人根据技术需求转化，通过厂商来进行方案撰写（按照既定的方案模板）。方案内容包括，操作人、操作方案、时间、地点、回退方案、应急联系方式等。撰写完成后，再交给业务负责人确认，比较重要的要当面审核。具体的执行任务，一般要求细化到命令级。重复性的方案在具体的实施人手里，相应的方案是都有的，目前没有上收管理。

跨专业协作：在方案书写过程中，有实施方牵头方案撰写和跨专业协调。

变更角色：变更负责人（不跨专业的是变更所在小组的组长，跨专业的是业务接口人），变更实施人（具体任务的执行人）。

变更授权：之前有操作确认表，现在又松了。现在是基于信任，一般由组长进行。领导对于技术问题无法负责，而专业组长又会出现自己审自己。

变更实施：有变更实施人员和协维人员进行（协维人员负责技术上把关），厂商基于维保合同进行。正式实施前，还需要申请进出权限，提交门禁权限审批（张卷的审批，目前有权限开放使用问题）；实施的时候，至少是双人参加，一个人监督、厂商来实施。

注意：方案在实施的时候是可以变通的，但是需要告知（目前人太少15人，一周5-6次变更。1.需要提高自身人员能力，2.在方案中尽可能细）

变更通告：同时也会通过电子化短信平台，通知业务人员和监控人员；通告内容包括：实施开始时间、地点、系统、影响、恢复时间），同时通过此平台，进行加班统计。

变更意外处理：对于以外的情况，需要进行技术准备（备机等）；晚上万一出问题需要应急方案、应急联系人等。目前的执行力有差距，应急方案也不够健全。主要还是看风险，在高可用性环境下的成熟变更（比如换个硬盘）可以简单，但是还需要考虑风险，在内容上要有要求（做一个模板就可以）。

应急处理上报：需要有上报机制，目前是打给组长、领导、业务负责人或者应急联系人等，但是具体找谁不明确。实施过程中的问题，明确的要求和制度。监督的是，权限管理，通知应急联系人。简单操作。

变更失败：一般进入故障处理。时间过长，影响业务的属于故障，变更无法执行需要回退的。

变更的角色：变更业务负责人、业务接口人、专业组、实施人、领导、归档管理员（SPOC）、应急联系人、监控人。

变更记录：记录完整性有差距，用得比较少，每个组有专人记录，一般是做告警日清的人。

变更如何关闭:实施完之后，会发一个结果出来，小平台中申请报结。就正式关闭。

变更实施后处理:目前暂无。

针对紧急变更怎么做的?关注紧急变更后行为（注意是否有补录，补测）

从业务需求层面提出的变更有些是领导或市场的紧急需求，如亲情网，变更要求紧急实施（快速上线、快速实施），还有如应付安全检查，扫出来漏洞需要紧急修复（有刚性的时限要求，应对检查）。业务要求的及时性和变更风险控制要折衷考虑。

变更是否会按照预定时间完成?

变更时效的考虑：

从业务需求层面提出的变更有些是领导或市场的紧急需求，可以理解为必须执行的。业务要求的及时性和变更风险控制要折衷考虑。

每个变更是否都制定了回退计划?实施过程中，出现意外如何处理？

变更异常处理：

方案到了现场发现与实际情况不匹配，如无磁带机备份系统，现在没有明确的处置要求，都是临时随机处理。最理想的情况就是变更执行直接按照方案粘贴复制，但现在难以做到，同时这也表示变更回顾做得不好，因为没出事领导就看不到。现在测试环境也难以跟生产环境一一对应，就连重要系统也不能一一对应，还有像存储这样的设备，上面跑的业务关联性很大，难以复制，找不到这样的设备做测试环境。要制定规则，约束变更发现异常是否升级通知领导或技术主管。

失败的变更如何处理？

分为应用和IT基础架构两方面原因导致要回退。这时双方要互相配合，要有明确召集人，这个应该在回退方案中事先指定。标准变更方案也要评审，可以最初要先稳定下来，以后再省去审批手续。但标准变更起码要在imep系统里登记。要控制非故障类的紧急变更，现在有些变更时间太紧，做成了事实上的紧急变更。一般应该提前一周，有时间走流程，便于做标准化管控的事情。

变更如何关闭?对于这些变更，有没有做定期的回顾和分析?

要实施变更后值守制度，可以让CAB来做重要变更的回顾，这样CAB议程较长，需要专门的变更经理，应该设定AB角。最好找一个铁面无私的人来做，还需要管控变更中做私活，如停机检修中自己多加一个脚本上去，要考虑如何控制。