摘要：本文从IT服务管理理论、方法和标准出发，结合用户实际和建设需要，遵循立足需求、统一规划、保障重点、分步实施、务求实效的原则，设计一套融合组织、制度、流程、人员、技术为一体的IT服务管理体系
　　关键词：运维体系、服务台、事件管理、问题管理、变更管理、发布管理、配置管理
　　运行维护方案
　　1.1 方案设计思路
　　本方案的设计思路是：按照IT服务管理理论、方法和标准，结合用户实际和建设需要，遵循立足需求、统一规划、保障重点、分步实施、务求实效的原则，建立一套融合组织、制度、流程、人员、技术为一体的IT服务管理体系，建立组织机构，制定规章制度，规范管理流程，明确职责分工，强化技术支撑，使技术团队能够以此为依托，实现对用户应用的综合管理监控和日常技术支持，快速响应和及时解决信息系统运行过程中出现的各种问题和故障，确保用户应用的正常、稳定、高效运行。
　　建立一个完善的IT服务管理体系，首先需要切合用户需求和用户特点。
　　本方案运行维护的用户群可归纳为两大类：
　　 内部用户：包括用户、相关单位等；
　　 外部用户：进行用户业务办理、查询的单位和个人。
　　在方案实施时，将进行详细调研，系统整理和规划服务对象类型和数量，制定针对性的服务设计，满足不同用户的服务期望。
　　维护对象包括机房、网络、主机和服务器、应用软件等。
　　在需求调研中，需要规划配置管理方案，确定配置属性，梳理配置关系。同时对于不同维护对象，各有技术特点，需要制定针对性的运维技术手册。
　　运维团队由用户信息中心、（总）集成商、集成商、应用开发商共同组成，可概括为三个服务团队体系：服务台、内部运维团队和外部运维团队。
　　1.1.1 本项目运维体系设计重点
　　在本项目运维服务体系设计中，重点投入在服务支持建设上，服务支持描述了所提供的IT 服务日常支持和维护活动相关的过程，是在实现运维支撑平台中最常用到的模块。
　　服务支持主要功能模块有：服务台与事件管理、问题管理、变更管理、发布管理、配置管理。
　　1.1.1.1 服务台与事件管理
　　服务台是组织机构内为所有IT 用户所提供的单一、集中的联系点，它处理所有事故、查询和请求。它为所有其它服务支持过程提供了一个接口。
　　事件管理负责管理所有事故从检测和记录到解决和完成的所有内容。事故管理的目标是快速有效地响应最终用户，使它们能够迅速恢复工作，以减小对最终用户的影响。
　　事件管理涉及主要活动如下：
　　(1) 事件查明和记录
　　(2) 分类和初步支持
　　(3) 调查和诊断
　　(4) 解决和恢复
　　(5) 关闭
　　1.1.1.2 问题管理
　　问题管理的目标是最小化事故和问题对业务的负面影響。为了达到这个目标，问题管理通过管理所有主要事故和问题来辅助事故管理，问题管理尽力记录所有的工作环境并对相应已知错误进行“快速修补”，并且在可能时产生变更以实施持久的结构性的解决方案。问题管理也对事故和问题进行分析和趋势分析，以预见性的预防进一步事故和问题的发生。
　　问题管理涉及主要活动如下：
　　(1) 问题识别、记录和归类
　　(2) 问题评审
　　(3) 调查和诊断
　　(4) 解决和关闭
　　(5) 已知错误识别和记录
　　(6) 已知错误分类和评估
　　(7) 已知错误解决和关闭
　　1.1.1.3 变更管理
　　一个单一的集中化的有效和高效地处理变更的变更管理过程，是任何IT 机构成功运营的关键。在变更从启动和记录到过滤、评估、分类、授权、调度、建设、测试、实施以及最终的审核和收尾的整个生命周期中，必须谨慎仔细地对其进行管理。此过程的一个关键成果是前向变更调度（FSC-Forward Schedule of Change），它是基于业务影响和紧急性的所有领域都同意变更的一个中央程序。
　　变更管理涉及主要活动如下：
　　(1) 启动、接受和分类
　　(2) 评估和审批
　　(3) 安排和分配
　　(4) 建设
　　(5) 实施
　　(6) 关闭
　　1.1.1.4 发布管理
　　发布管理过程采用了对IT 服务变更的整体全局视野，它考虑发布的所有技术和非技术方面。发布管理负责组织机构内所使用的所有硬件和软件的所有法律和合同义务。为了实现此目标并保护IT 资产，发布管理为定义硬件库（DHS-Definitive Hardware Store）中的硬件和定义软件库（DSL- Definitive Software Library）中的软件建立了一个安全的环境。
　　发布管理负责控制版本发布变更的频度。这涉及到对变更的整合或将变更分拆成更小的版本发布模块。这些举措基于一系列对业务需求、员工需求（开发、测试、实施、运作）和用户/业务影响的权衡考虑。
　　发布管理涉及主要活动如下：
　　(1) 启动、接受发布请求
　　(2) 发布策略制定
　　(3) 实施计划制定
　　(4) 方案审批
　　(5) 构建测试环境
　　(6) 发布实施
　　(7) 对实施结果测试
　　(8) 结束
　　1.1.1.5 配置管理
　　配置管理提供了成功的IT 服务管理的基础，它支持着所有其它过程。其基础成果是配置管理数据库（CMDB)，在数据库中包含了一个或多个综合数据库详细描述了组织机构中的所有IT 基础设施组件以及其它重要的相关的资产。就是这些资产提供了IT 服务，它们也被称之为配置项（CIs)。CMDB 同普通的资产注册所不同之处在于那些关系、或链接，它们定义了每个配置项（CI）如何互连以及如何同其邻居相互依赖。这些关系允许执行例如影响分析和“如果..将会…”等的活动。理想情况下，CMDB 也包含了同每个CI 相关的所有事故、问题、已知错误和变更的细节。
　　配置管理涉及主要活动如下：
　　(1) 登记组成服务的资产信息；
　　(2) 登记这些资产之间的关系；
　　(3) 确保配置管理信息库中的各类相关信息能够得以及时更新。
　　1.2 运维体系设计内容
　　运维体系设计内容包括：运维组织架构、角色与职责、运维相关流程、运维工作表单、服务度量指标。
　　1.2.1 运维组织架构
　　运维组织架构包括涉及运维管理的所有单位、部门、人员的组织信息，用树形层次结构记录，作为运维系统基础数据管理。
　　为确保整个运维工作的协调运转，建议采用分级管理模式规划运维组织架构，即组建运维服务台，三级运维支持部门协同工作，共同完成运维工作。
　　建立统一接入的服务台，实行中央控制，分级授权的集中式加分布式的服务台设计。当最终用户提出请求或者需对应用系统进行主动运维时，运维服务台作为呼叫受理反馈部门接受服务请求，并提供一线帮助。对于无法解决的问题，提交二线也即系统运维组处理，运维服务台同时进行跟踪和催办。
　　系统运维组包括内部运维团队和外部运维团队，作为核心团队负责运行维护和管理工作，针对应用系统进行主动运维，并解决运维服务台转交的请求，在必要时协调供应商、开发商等外部资源。
　　供应商、开发商作为三线支持，对运维中心提供二线不能解决的问题支持。
　　采用上述分级管理的工作模式，可以按照运维人员的不同技术能力分配到一、二、三线，实现了运维人员的专业化分工；对于技术要求相对较低的一线可根据工作量的增长及时增加，确保服务呼叫处理率，对于承担核心运维工作的二线人员，避免了初级服务请求的直接处理，保证其对关键应用和紧急故障的处理，可以大大提高运维服务效率和质量；同时，分级管理的工作模式充分发挥不同人员的技术能力，克服了高能低用情况的发生，降低了运维服务总体成本。
　　1.2.2 角色与职责
　　本方案运维管理的角色与职责设置，将以ITILV3标准为参考，结合总集成商历年来大量的运维服务实践，针对本项目用户进行设计。所涉及的角色及职责的定义，主要包括服务台、事件管理、问题管理、变更管理、发布管理、配置管理各个角色和职责。例如，服务台、一线工程师、二线工程师、事件经理、问题经理、问题分析工程师、变更经理、变更咨询委员会、配置管理员等角色。
　　各类角色在运行维护过程中承担不同的职责，并将在方案实施时根据用户特点进行完善。
　　1.2.3 运维相关流程
　　运维相关流程的定义和设计，根据用户的业务需求特点进行定义，主要包括服务台、事件管理、问题管理、变更管理、发布管理、配置管理、知识管理等流程。
　　在本方案实施时，将进行运行服务流程设计。主要流程设计工作内容包括：
　　1、服务台/事件管理流程设计
　　2、问题管理/知识管理流程设计
　　3、变更管理流程设计
　　4、配置管理流程设计
　　1.2.4 运维文档体系
　　建立文档体系是进行运行维护服务中持续进行的工作。完善的文档体系有助于维护团队工作持续性，维持稳定的客户服务能力。如运维流程类文档（事件报障信息表单、发起问题信息表单、变更申请表单、发布管理申请表单、配置信息记录表单等）、服务器、数据库日常维护操作类文档；日常检查模板；日常沟通工作模板、应用发布流程等等，这类标准化文档的建立，将规范运维管理，改善运维效率。
　　文档体系的建立并非易事，因此需要從思想上重视并不断更新文档，严格按文档实施操作，要监督文档质量等。
　　文档体系的建设包括两方面内容：
　　1、文档体系完善
　　2、规范梳理和固化
　　在实际运维中，由于运维活动具有多样性、复杂性，规范的制订往往跟不上运维实际的要求。但结合客户业务需要，有选择地制订关键的运维规范不失为一种有效方法。
　　定义：这里的规范指运维过程中应该遵循的、客户导向的行为约定。包括操作方法、结果提交方式、运维过程控制点的确认等。以升级为例：故障出现后，故障的等级判断标准，处理时长与升级的关系，升级的途径和相关人等，都受升级规范的约束。
　　流程的梳理是一个渐进的过程，规范内容也会随用户系统生命周期、运维局势不同而及时调整。对于规范梳理，需关注两方面的内容：
　　 其一是目前运维中影响较大、问题较多急需明确的流程；
　　 其二是明确确认规范的主体。
　　另外和规范相关的接口有客户和项目组，需分别进行梳理，并区分其各自不同的特点。明确责任，合理分工。这部分工作是服务持续改善计划的难点所在。
　　1.2.5 服务度量指标
　　制定服务度量指标，对运维系统制定内部和外部服务管理级别，对员工制定员工绩效考核标准。
　　规划的工作内容如下：
　　 配合用户技术支持部门梳理所有现有SLA相关资料编制服务目录；
　　 完善和巩固服务目录，同时加强客户沟通和宣传，让更多客户充分了解服务团队目前提供的服务内容；
　　 基于ITIL建立标准的服务水平管理流程，规范定义包括服务水平管理计划、客户需求管理、服务水平确定、OLA磋商、UC需求确定、SLA签署、监控和回顾等在内的各项服务水平管理活动；
　　 建议采用需求调研表和访谈的方式对客户的IT服务需求进行收集、整理和分析，从而确定服务水平需求；
　　 由客户服务部依据与客户签订的SLAs将相关的具体指标细化为各分相关职能部门的OLA，并与分解相应UC到对应供应商；
　　 利用工具监控和收集实际的服务水平管理数据，并通过与SLA的比较发现差距生成报告，交由OLA和UC支持团队进行改进；
　　 建立服务水平协议回顾和检查过程；
　　 制定服务水平管理流程相关的政策制度和工作规范；
　　 利用工具实现服务水平管理与其他流程之间的关联，提高组织整体的IT服务支持能力。