|
|
|
|
|
|
|
|
|
|
|
变更管理流程须确保供方通过管理、控制变更的过程，确保变更有序实施。在IT服务运营中应充分执行以下事项。
|
|
|
|
（1）受理变更请求：对变更进行受理，对于变更进行分类，确保变更单填写规范。
|
|
|
|
（2）对变更进行评估、审核：对变更进行评估并最终审核，要充分考虑变更所带来的风险，对于变更或不变更带来的后果需要进行分析，必要时应该召开变更顾问委员会（CAB）进行讨论。
|
|
|
|
（3）对变更进行实施、确认和回顾等：需要协调发布管理或项目管理对变更的实施过程进行管理，在必要时需提出或批准回退计划，对变更后的成果要进行实施后评审。
|
|
|
|
（4）生成变更报告：对变更完成情况进行统计分析，包括未经批准变更数量及占比、不同类型的变更数量及占比、不成功的变更数量及占比、取消的变更数量及占比、变更关联的配置数等。变更报告应定期发布。
|
|
|
|
（5）对如下关键指标进行管理：变更管理过程的完整性、变更记录的完整性。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
服务级别管理流程须确保供方通过定义、签订和管理服务级别协议，满足需方对服务质量的要求。在IT服务运营的流程中应当充分执行以下事项。
|
|
|
|
（1）更新服务目录并管理服务级别变更：在服务运营中，随时会产生新的服务需求及请求，或组织的服务能力提升、服务范围扩大等，或客户在原有服务范围的基础上变更服务级别需求，均应对服务目录进行及时的更新，并在与客户协商一致的基础上对服务级别协议进行变更。
|
|
|
|
（2）监控服务级别协议执行情况：需定期监控服务级别的达成情况，做出服务级别监控图表，对不同程度的服务级别协议违反情况提出警告，通知相关人员。
|
|
|
|
（3）对如下关键指标进行管理：服务目录定义的完整性，签订服务级别协议文件的规范性，服务级别考核评估机制的有效性和完整性。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
事件管理流程须确保供方具有检测事件、尽快解决事件的能力。在IT服务运营中，流程应充分执行以下事项。
|
|
|
|
（1）对事件进行受理与处理：包括接收事件，对事件进行分类和初步支持、调查和诊断并解决。
|
|
|
|
（2）对事件进展进行监控与跟踪：需要对事件的处理过程进行跟踪，确保每个环节都在约定时间内完成。一般建议由服务台进行监控与跟踪，并确保事件的最终关闭。
|
|
|
|
（3）对事件进行升级：当出现技术不足、超时、事件范围超出、沟通不利、需要外部资源沟通等情况时，需要对事件根据预定的规则进行升级。
|
|
|
|
（4）进行事件满意度调查：应对每个事件的处理情况进行满意度调查，可以通过工具或人工的方式收集满意度得分。对于重大不满意事件，应当及时报备、升级并处理。
|
|
|
|
（5）完成事件报告：事件报告包括事件解决率、事件平均解决时间等指标，也需要对重大事件进行回顾。事件报告一般定期制订。
|
|
|
|
（6）对如下关键指标进行管理：事件管理过程的完整性、有效性，事件解决评估机制的有效性。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
运维是运行维护的简称，是一种IT服务形态。在《信息技术服务分类与代码》（GB/T 29264-2012）中，对运行维护服务（operation maintenance service）给出的定义是“采用信息技术手段及方法，依据需方提出的服务级别要求，对其信息系统的基础环境、硬件、软件及安全等提供的各种技术支持和管理服务”。
|
|
|
|
运维是信息系统全生命周期中的重要阶段，也是内容最多、最繁杂的部分，是对信息系统提供维护和技术支持以及其他相关的支持和服务。运维服务的主要对象包括基础设施、硬件平台、基础软件、应用软件以及依赖于IT基础设施的数据中心、业务应用等信息系统，其范围可以是单个IT基础设施的运维，也可以是整体IT基础设施和业务应用的总体运维。运维服务交付内容主要包括咨询评估、例行操作、响应支持和优化改善。
|
|
|
|
在《信息技术服务分类与代码》（GB/T 29264-2012）中，将运行维护服务分成基础环境运维、硬件运维服务、软件运维服务、安全运维服务、运维管理服务和其他运行维护服务六类，每类运维服务及其说明见下表。
|
|
|
|
|
|
|
|
|
|
任何组织和个人提供运维服务需要依据需方提出的服务级别要求，并确保提供的运行维护服务符合与需方约定的质量要求。因此，具备相应运维服务能力是服务组织提供服务的必要条件，比如规范和明确运维人员的岗位职责和工作安排、提供绩效考核量化依据、提供解决事故和问题经验、提供知识的积累和共享手段、实现完善的IT运维管理、提高组织经营水平和服务水平等等。在《信息技术服务运行维护第1部分：通用要求》（GB/T 28827.1-2012）中给出了供方运维服务的能力模型，该模型定义了运行维护服务能力的四个关键要素：人员、资源、技术和过程，每个要素通过关键指标反映应具备的条件和能力。模型也给出了供方为持续提升运维能力的管理方法。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
灾备管理体系主要是指组织机构的各个层面，在日常状态和灾难状态下的各种管理工作，至少包括以下5个方面。
|
|
|
|
（1）灾难恢复组织机构。商业银行应结合本行机构设置的具体情况，设立灾难恢复组织机构，包括灾难恢复规划建设、运行维护、应急响应和灾难恢复等各阶段工作所需的人员，有关人员可为专职，也可为兼职，关键岗位的人员应有备份。商业银行可以参考《JR/T0044 2008银行业信息系统灾难恢复管理规范》，设置灾难恢复组织机构，包括决策层、管理层和执行层，各层之间分工明确、职责清晰。
|
|
|
|
（2）岗位与培训管理。灾备中心的应急生产岗位应与生产中心对等，只不过可以按照人员复用的原则，由灾备管理人员、开发测试人员或系统运维人员专职或兼职担任。对不同层次、不同部门的岗位，在灾难恢复策略规划、系统建设与运维、预案制定、演练和更新维护等不同阶段，应按照不同的培训目标，安排不同的培训计划。
|
|
|
|
（3）灾难恢复预案管理与演练。灾难恢复预案要长期保持有效性，必须在灾难恢复策略发生变化、演练发现问题、生产系统发生变更、人员出现调整等情况下，及时修订维护预案，做好变更管理、版本管理，以及发布管理等，确保合适的人员及时获得最准确、最合适的信息。演练验证灾难恢复预案有效性的最佳手段。演练管理就是要对演练的计划、场景、人员、过程、总结评估和后续完善调整等进行全面管理，通过演练来培养灾难恢复团队面对复杂环境的信心和冷静心态，验证灾难恢复能力，改进灾难恢复流程，发现并纠正灾备体系中的缺陷。
|
|
|
|
（4）灾备中心日常运维、灾难响应与重续运行管理。灾备中心应随时做好接替生产中心的准备，因此，必须像生产中心一样，对灾备中心的系统、网络和环境等基础资源进行运行维护，按照备份策略按时完成数据备份，完成灾备系统与生产系统的同步。当灾难发生后，灾难恢复组织机构的各层人员立即响应，在指挥报告、协调、联络、保障等工作机制的保障下，按照灾难恢复流程步骤，一步步地恢复信息系统及其支撑的关键业务功能。在生产系统成功切换到灾备中心运行后，要按照生产中心的规章制度、操作流程、技术规范来管理，保障生产系统安全稳定运行，直至生产中心重建并恢复了生产运行能力。
|
|
|
|
（5）外部资源管理。外部资源主要指商业银行的合作伙伴、服务商、设备商和外协人员等。当发生灾难时，可能需要这些外部资源的支持才能完成灾难恢复，比如，从设备供应商紧急采购灾备生产设备，从电信运营服务商紧急租用通信线路，从银联借调交易流水等。因此，需要与这些外部资源建立日常联系或签订协议，并不定期地测试其支持能力，以保证在灾难恢复期间，外部资源可以提供有效的支持。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
实施项目的组织结构对能否获得项目所需资源和以何种条件获取资源起着制约作用。组织结构一般有三种类型：职能型、矩阵型和项目型。矩阵型可进一步划分为弱矩阵、平衡矩阵和强矩阵。不同组织结构的区别如下表所示。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
很多组织在不同的组织层级上用到上述所有的结构，这种组织通常被称为复合型组织。例如，在典型的职能型组织中建立专门的项目团队来实施重要的项目；又如，组织采用强矩阵结构管理其大多数项目，而小项目则采用职能型结构管理。
|
|
|
|
|
|
|
|
|
|
|
|
|
