1、公司数据中心网络运维实施、流程控制制度编 制： 审 核： 批 准： 版 本 号: ESZAQDGF001 编 制： 审 核： 批 准： 版 本 号: 第一章 概述运维管理制度规范（试行），是针对目前数据中心现有体制制定的一系列运维规划，其中包括运维项目实施、运维流程控制、第二章 运维实施第一节 硬件上架1. 硬件上架应严格按照机房管理室所提供的流程进行操作，填写机房管理室要求的相关申请文档。2. 硬件上架后，要检查设备标签、网络标签、电源标签是否完整。3. 硬件上架后，要检查机柜内走线是否已整齐。4. 检查电源、网络配置能否符合和客户签定的SLA，如不符合走服务请求流程提交相关文档。5. 机房2、管理室创建该项目的配置项文档， 并通知服务经理进度。6. 涉及流程：机器上架申请、配置管理、服务级别管理、服务请求。7. 涉及文档：设备上架申请、服务请求单、服务级别协议/服务合同、配置项文档第二节 网络配置1. 网络配置时，要求按照客户的服务合同中承诺的要求一致，如合同中没有明确说明以领导确认为准。2. 网络配置后，录入相关的配置项信息，以及变更相关联的交换机、防火墙信息， 并通知服务经理进度。3. 网络配置后，要建立该业务系统的网络拓扑图，网络拓扑图属于该项目的一个配置项。4. 涉及流程：配置项管理5. 涉及文档：配置项目文档第三节 软件实施1. 软件实施前要创建软件实施调查表，详细调查客3、户的软件环境、配置、版本等信息。2. 软件实施要按照软件实施调查表进行实施。3. 软件实施后，如客户没有要求，修改所有默认密码，密码规则同信息安全管理制度的口令、权限一章。4. 软件实施后，要录入相关配置项目，并适当备份介质。5. 软件实施后，要建立该业务系统的逻辑拓扑图，逻辑拓扑图属于该项目的一个配置项。6. 涉及流程：配置项目管理7. 涉及文档：软件实施调查表、配置项目文档第四节 运维手册1. 运维项目在项目实施后，要依据服务合同书及相关SLA写运维手册。2. 运维手册的内容包括：服务内容、服务范围内满足服务合同要求的相应的日检、周检、月检、日常操作等规范，并提供输出的服务报告模板。3. 4、运维手册书写后，要将运维手册的名称及位置记入配置项文档4. 涉及流程：配置项目管理5. 涉及文档：运维手册、配置项文档第三章 运维流程第一节 服务级别管理1. 定义：服务级别协议（简称SLA）， 与客户之间签订的描述将要提供的一项或多项服务的一种协议，在协议期间作为评价和调整IT服务的标准。2. 说明：在运维期间，所有操作都围绕着达成对客户的服务级别协议与展开。3. 规范：a) 定期检查运维手册是否符合SLA中签订的标准。b) 在SLA发生变化时，更新现有的运维手册以达到新的SLA中签署的。c) 定期对现有服务进行评价，以满足SLA。4. 涉及文档：服务级别协议运维手册以及所有该服务级别协议中5、包含的运维流程服务报告等。第二节 配置管理（目前希望配置管理能在最初阶段建立尽量全的配置项，减少将来反复录入一些新配置项的过程 ）1. 定义：配置项主要包含定义和维护IT基础架构的物理组件、有关文档，以及定义和维护这些组件之间的相互有关系和相关属性。2. 说明：配置项管理主要针对配置项在物理关系上的构成、连接、需要，以及逻辑关系上的涉及、被使用，如某一主机与网络接口之间的新建的关联信息、如中间件与数据库之间的使用关系发生变化，都会涉及到配置项的变化。3. 规范：a) 配置项要有固定的模板，并定期审核心是否满足现有业务需要。b) 根据服务合同的SLA，确定该维护项目最初的配置项必添项目。c) 在6、配置项发生变化时，必须及时更新配置项文档。d) 定期审核配置项文档中与实际不符的信息。e) 涉及文档：配置项文档第三节 服务请求1. 定义：服务请求，用户想要获得的支持、信息、建议或文档等不属于IT基础架构方面的事件；2. 说明：当服务请求的输出是一个预授权变更，记录服务请求单和变更实施报告并反馈客户变更结果； 如果服务请求的输出是一个故障，那么走故障管理流程进行处理。3. 流程图4. 规范a) 当用户提出要求时必须添写服务请求单。b) 当用户提出的要求不属于IT基础架构方面的事件，仅在服务请求单中记录处理结果，并及时反馈给用户。c) 当服务请求为一个预授权变更时，记录变更实施报告，并及时反馈7、给用户。d) 当服务请求输出是一个故障时，走故障管理流程进行处理，服务请求单做为故障管理流程的输入。5. 涉及文档：服务请求单、变更实施报告第四节 故障管理1. 定义：故障，在某一服务中已经导致服务中断或服务质量下降的情况。 2. 说明：故障的来源可能是由某一用户发现、管理员、由另一IT部门的人发现、由监控软件发现；故障管理的输出可能是一个故障报告或分析后可能成为问题报告。3. 流程：4. 规范a) 故障流程的输入如果来自服务请求，那么故障流程的输入为服务请求单；如果故障流程来自管理员、由另一IT部门的人发现、由监控软件发现那么故障流程的输入为故障报告。b) 首先对故障事件进行分析，该故障是否8、为问题，如为问题记入问题报告。c) 首先判定处理该故障是否需要变更，如需要，进入提交变更申请单。d) 如故障处理需要其它部门协助，填写服务协助单给相关部门共同处理，最后提交故障报告给服务经理或对客户做出反馈。e) 如该故障不需要其它部门协助，在故障处理后提交故障报告给服务经理或对客户做出反馈。5. 涉及文档：故障报告、问题报告、服务协助单第五节 问题管理1. 定义：问题是一个或多个事件的未知潜在原因。问题分为已知问题和未知问题，已经问题就是已经查明事件根本原因和事件解决方法的。2. 说明：问题管理的主要目的是记录问题并进行查明原因，提高已知问题的数量，减少对服务质量的影响，提高服务请求处理效率9、。一般问题管理流程的输入都为故障管理流程流转出的服务请求单和故障报告。3. 流程4. 规范a) 每一个问题事件都必须详细记录该事件的相关线索，如系统信息、状态，有解决办法或变通措施的要详细到命令一级，以备录入知识库速查使用。b) 要对一类的问题事件进行分析。c) 定期审核已知错误及未知错误的数量。d) 检查未知错误是否都有变更变通措施。e) 所有与业务系统本身相关的已知问题，计入运维手册的问题库一章。f) 所有与技术相关的已知问题，计入知识库。5. 涉及文档：服务请求单、故障报告、问题报告、知识库第六节 变更管理1. 定义：变更分为预授权变更、常规变更、紧急变更，预授权变更为服务合同中已明确的10、不需要客户再次审核的变更；常规变更为操作手册中明确写明操作步骤及操作规范的变更和可以正常走变更审批流程的变更；紧急变更一般由故障引起而采用的为确保恢复服务质量或结束服务中断现象，从而保证SLA的变更。2. 说明：预授权变更的入口目前一般为服务请求单及各管理员针对服务合同做的定期变更操作，如修改某个非关联的管理帐号密码；标准变更要严格走变更流程；紧急变更一般入口为故障报告，必须拿到领导审批授权才可以变更，后期保证文档完整。3. 流程：4. 规范a) 紧急变更必须拿到领导审批授权。b) 预授权变更产生的文档为变更实施报告。c) 标准变更及紧急变更产生的文档为变更请求单变更实施计划变更实施报告变更结11、果跟踪。d) 如变更过程中会产生配置项的变更， 必须在变更实施计划中，变更配置项做为一项计划工作写明，并在后期的变更实施过程中严格执行。e) 要定期检查变更相关报告的完整性。f) 变更结束后，如需对变更结果进行验证，要填写变更结果跟踪，说明变更对原有系统带来的影响。5. 涉及文档：服务请求单、变更请求单、变更实施计划、变更实施报告变更结果跟踪第四章 服务报告第一节 定期报告的基本原则1. 定期报告首先借助于各类监控工具生成。2. 定期报告格式要有数据灾备中心统一风格，如标题样式、页眉页脚、字体颜色、表格样式等。3. 定期报告原则上分类书写，并有汇总文档进行说明。4. 针对不同客户的SLA所协商的，分别定制粒度不同的服务报告。第五章 文档管理第一节 命名规则1. 所有非流程流转的文档，如配置项目文档、运维手册等以项目名称为基础，命名方式为项目名称-文档名。2. 所有流程流转的文档，如变更请求单等，以项目名称及生成时间为基础，命名方式为项目名称-年月日-文档名，如*容灾项目-20120328-变更请求单。3. 所有文档使用工具进行管理，各技术人员通过获得的授权进行修改。第六章 第七章 附件第一节 标准文档模板及说明1. 运维手册2. 配置项文档第二节 标准表格模板及说明1. 服务请求单变更申请单