运维管理制度规范V1.0

运维管理制度规范（试行） Version 1.0 日 期 2012/2/25 第一章 概述 运维管理制度规范（试行），是针对目前数据中心现有体制制定的一系列运维规划，其中包括运维项目实施、运维流程控制、

第二章 运维实施

第一节 硬件上架 1. 硬件上架应严格按照机房管理室所提供的流程进行操作，填写机房管理室要求的相关申请文档。 2. 硬件上架后，要检查设备标签、网络标签、电源标签是否完整。 3. 硬件上架后，要检查机柜内走线是否已整齐。 4. 检查电源、网络配置能否符合和客户签定的SLA，如不符合走服务请求流程提交相关文档。 5. 机房管理室创建该项目的配置项文档， 并通知服务经理进度。 6. 涉及流程：机器上架申请、配置管理、服务级别管理、服务请求。 7. 涉及文档：《设备上架申请》、《服务请求单》、《服务级别协议》/《服务合同》、《配置项文档》 第二节 网络配置 1. 网络配置时，要求按照客户的服务合同中承诺的要求一致，如合同中没有明确说明以领导确认为准。 2. 网络配置后，录入相关的配置项信息，以及变更相关联的交换机、防火墙信息， 并通知服务经理进度。 3. 网络配置后，要建立该业务系统的网络拓扑图，网络拓扑图属于该项目的一个配置项。 4. 涉及流程：配置项管理 5. 涉及文档：《配置项目文档》 第三节 软件实施 1. 软件实施前要创建《软件实施调查表》，详细调查客户的软件环境、配置、版本等信息。 2. 软件实施要按照《软件实施调查表》进行实施。 3. 软件实施后，如客户没有要求，修改所有默认密码，密码规则同《信息安全管理制度》的口令、权限一章。 4. 软件实施后，要录入相关配置项目，并适当备份介质。 5. 软件实施后，要建立该业务系统的逻辑拓扑图，逻辑拓扑图属于该项目的一个配置项。 6. 涉及流程：配置项目管理 7. 涉及文档：《软件实施调查表》、《配置项目文档》 第四节 运维手册 1. 运维项目在项目实施后，要依据服务合同书及相关SLA写运维手册。 2. 运维手册的内容包括：服务内容、服务范围内满足服务合同要求的相应的日检、周检、月检、日常操作等规范，并提供输出的服务报告模板。 3. 运维手册书写后，要将运维手册的名称及位置记入《配置项文档》 4. 涉及流程：配置项目管理 5. 涉及文档：《运维手册》、《配置项文档》

第三章 运维流程

第一节 服务级别管理 1. 定义：服务级别协议（简称SLA）， 与客户之间签订的描述将要提供的一项或多项服务的一种协议，在协议期间作为评价和调整IT服务的标准。 2. 说明：在运维期间，所有操作都围绕着达成对客户的服务级别协议与展开。 3. 规范： a) 定期检查运维手册是否符合SLA中签订的标准。 b) 在SLA发生变化时，更新现有的运维手册以达到新的SLA中签署的。 c) 定期对现有服务进行评价，以满足SLA。 4. 涉及文档：《服务级别协议》《运维手册》以及所有该《服务级别协议》中包含的运维流程服务报告等。

第二节 配置管理（目前希望配置管理能在最初阶段建立尽量全的配置项，减少将来反复录入一些新配置项的过程 ） 1. 定义：配置项主要包含定义和维护IT基础架构的物理组件、有关文档，以及定义和维护这些组件之间的相互有关系和相关属性。 2. 说明：配置项管理主要针对配置项在物理关系上的构成、连接、需要，以及逻辑关系上的涉及、被使用，如某一主机与网络接口之间的新建的关联信息、如中间件与数据库之间的使用关系发生变化，都会涉及到配置项的变化。 3. 规范： a) 配置项要有固定的模板，并定期审核心是否满足现有业务需要。 b) 根据服务合同的SLA，确定该维护项目最初的配置项必添项目。 c) 在配置项发生变化时，必须及时更新《配置项文档》。 d) 定期审核《配置项文档》中与实际不符的信息。 e) 涉及文档：《配置项文档》 第三节 服务请求 1. 定义：服务请求，用户想要获得的支持、信息、建议或文档等不属于IT基础架构方面的事件； 2. 说明：当服务请求的输出是一个预授权变更，记录《服务请求单》和《变更实施报告》并反馈客户变更结果； 如果服务请求的输出是一个故障，那么走故障管理流程进行处理。 3. 流程图 4. 规范 a) 当用户提出要求时必须添写《服务请求单》。 b) 当用户提出的要求不属于IT基础架构方面的事件，仅在《服务请求单》中记录处理结果，并及时反馈给用户。 c) 当服务请求为一个预授权变更时，记录《变更实施报告》，并及时反馈给用户。 d) 当服务请求输出是一个故障时，走故障管理流程进行处理，《服务请求单》做为故障管理流程的输入。 5. 涉及文档：《服务请求单》、《变更实施报告》 第四节 故障管理 1. 定义：故障，在某一服务中已经导致服务中断或服务质量下降的情况。 2. 说明：故障的来源可能是由某一用户发现、管理员、由另一IT部门的人发现、由监控软件发现；故障管理的输出可能是一个《故障报告》或分析后可能成为《问题报告》。 3. 流程：

判定该故障是否需要变更提交变更申请通知服务经理是是否需要其他部门协助否填 写《服务协助单》填 写《故障报告》给嗠经理填 写《故障报告》给嗠经理同其他部门共同处理否是故障处理服务请求单/故障报告单故障处理

判定该 故障是否为故障

是

记录问题报告

4. 规范 a) 故障流程的输入如果来自服务请求，那么故障流程的输入为《服务请求单》；如果故障流程来自管理员、由另一IT部门的人发现、由监控软件发现那么故障流程的输入为《故障报告》。 b) 首先对故障事件进行分析，该故障是否为问题，如为问题记入《问题报告》。 c) 首先判定处理该故障是否需要变更，如需要，进入提交《变更申请单》。 d) 如故障处理需要其它部门协助，填写《服务协助单》给相关部门共同处理，最后提交《故障报告》给服务经理或对客户做出反馈。 e) 如该故障不需要其它部门协助，在故障处理后提交《故障报告》给服务经理或对客户做出反馈。 5. 涉及文档：《故障报告》、《问题报告》、《服务协助单》 第五节 问题管理 1. 定义：问题是一个或多个事件的未知潜在原因。问题分为已知问题和未知问题，已经问题就是已经查明事件根本原因和事件解决方法的。 2. 说明：问题管理的主要目的是记录问题并进行查明原因，提高已知问题的数量，减少对服务质量的影响，提高服务请求处理效率。一般问题管理流程的输入都为故障管理流程流转出的《服务请求单》和《故障报告》。 3. 流程

服务请求单/故障报告

是否为已知问题提交《问题报告单》

记录详细的问题状态

找到解决方案或变通措施

录入已知问题库

提交《问题报告》

问题管理 4. 规范 a) 每一个问题事件都必须详细记录该事件的相关线索，如系统信息、状态，有解决办法或变通措施的要详细到命令一级，以备录入知识库速查使用。 b) 要对一类的问题事件进行分析。 c) 定期审核已知错误及未知错误的数量。 d) 检查未知错误是否都有变更变通措施。 e) 所有与业务系统本身相关的已知问题，计入《运维手册》的问题库一章。 f) 所有与技术相关的已知问题，计入知识库。 5. 涉及文档：《服务请求单》、《故障报告》、《问题报告》、《知识库》 第六节 变更管理 1. 定义：变更分为预授权变更、常规变更、紧急变更，预授权变更为服务合同中已明确的不需要客户再次审核的变更；常规变更为操作手册中明确写明操作步骤及操作规范的变更和可以正常走变更审批流程的变更；紧急变更一般由故障引起而采用的为确保恢复服务质量或结束服务中断现象，从而保证SLA的变更。 2. 说明：预授权变更的入口目前一般为《服务请求单》及各管理员针对服务合同做的定期变更操作，如修改某个非关联的管理帐号密码；标准变更要严格走变更流程；紧急变更一般入口为《故障报告》，必须拿到领导审批授权才可以变更，后期保证文档完整。 3. 流程：

领导审批

变更实施《变更实施报告》《变更结果跟踪》提交服务经理

事件结束事件结束是否否

变更管理

《变更实施计划》审批

变更请求服务请求《变更实施计划》 4. 规范 a) 紧急变更必须拿到领导审批授权。 b) 预授权变更产生的文档为《变更实施报告》。 c) 标准变更及紧急变更产生的文档为《变更请求单》《变更实施计划》《变更实施报告》《变更结果跟踪》。 d) 如变更过程中会产生配置项的变更， 必须在《变更实施计划》中，变更配置项做为一项计划工作写明，并在后期的变更实施过程中严格执行。 e) 要定期检查变更相关报告的完整性。 f) 变更结束后，如需对变更结果进行验证，要填写《变更结果跟踪》，说明变更对原有系统带来的影响。 5. 涉及文档：《服务请求单》、《变更请求单》、《变更实施计划》、《变更实施报告》《变更结果跟踪》

第四章 服务报告

第一节 定期报告的基本原则 1. 定期报告首先借助于各类监控工具生成。 2. 定期报告格式要有数据灾备中心统一风格，如标题样式、页眉页脚、字体颜色、表格样式等。 3. 定期报告原则上分类书写，并有汇总文档进行说明。 4. 针对不同客户的SLA所协商的，分别定制粒度不同的服务报告。

第五章 文档管理

第一节 命名规则 1. 所有非流程流转的文档，如《配置项目文档》、《运维手册》等以项目名称为基础，命名方式为《项目名称-文档名》。 2. 所有流程流转的文档，如《变更请求单》等，以项目名称及生成时间为基础，命名方式为《项目名称-年月日-文档名》，如《**容灾项目-20120328-变更请求单》。 3. 所有文档使用工具进行管理，各技术人员通过获得的授权进行修改。

第六章 第七章 附件

第一节 标准文档模板及说明 1. 《运维手册》 2. 《配置项文档》 第二节 标准表格模板及说明