企业信息系统运维管理实施细则（下）

续上篇（为阅读的完整性，部分属于实施细则附件的图直接放在了正文相应的段落中）：

第三十四条 发布新程序或者配置时，原则上均应在OA系统信息化专栏中发布对应的说明公告，必要时直接与关键用户取得联系告知发布计划。对在工作日需要停止系统服务的运维工作，考虑到加班以及在境外不同时区的用户可能在各个时间点在线使用系统的情况，所以无论是否在工作时间（以北京时间为标准）内都必须在OA中提前发布公告，以便于用户合理安排工作。

第三十五条 应通过配置管理流程（如附件4图6）识别和定义配置项，记录和报告配置项状态和变更请求，检验配置项的正确性，为信息技术基础架构提供逻辑模型。各系统的系统管理员是所负责系统的配置管理第一责任人，当系统发生变更时应及时更新配置项。

图6：配置管理流程

第三十六条 应建立和维护公司信息资源的配置管理数据库，并形成对配置项定期审核的机制，在变更时或者定期的对库中的配置项及其状态和关系审核，及时掌握配置项的增减和调整情况，保持配置库的可用状态。

第三十七条 应重点管理好配置项之间的关系，该关系包括但不限于：软件或硬件系统之间的接口关系、系统中各种功能的关系、各种数据之间的关系、业务流程之间的关系、系统与业务之间的关系、用户与系统之间的关系，等。基于对配置项及其状态和关系的管理，为事件管理、问题管理、变更管理、发布管理提供支持，使运维人员可以找到解决事件的方法，为分析问题提供基本信息进而得到解决方案，以及用以评估变更和发布的影响等。

第三十八条 在系统运行过程中，数据输入者（通常为终端用户）是数据质量的第一负责人，运维人员应协助用户保证数据质量，同时监控各系统的数据质量情况，在发现数据质量不符合要求时应向用户提出整改意见，并为用户恢复数据质量提供技术支持。

第三十九条 各系统在所有工作日的生产数据必须实现完整备份，至少应做到一天一次的完整备份，对数据产生密度较大的关键系统，应缩短备份间隔，最大限度减少系统出现严重故障时因数据对业务的影响。同时应定期对备份数据进行恢复验证，确保备份数据的可靠性。

第四十条 应妥善保管数据备份的存储介质，严禁与生产数据存储在同一机房中，以避免出现严重灾害时造成数据损失。在条件允许的情况下，应实现数据的异地备份。

第四十一条 应设置专岗专人承担数据备份和储存介质的保管工作，负责数据备份的运维人员应熟悉数据的备份和恢复操作，应制定备份工作计划，保障备份工作无疏漏。

第四十二条 运维人员对数据执行修改和删除操作前，在系统条件允许的情况下，应先对相关数据做好备份，应至少保证相关的数据有备份，对新增数据的操作也应建立数据回滚机制，以便当数据处理出现异常时能够最大限度的恢复，减少对系统的影响。

第四十三条 在进行复杂的大规模的数据修改前，如非业务紧迫，原则上应在非工作时间对数据备份后执行修改，以避免修改过程中出现异常对当天正常的业务数据造成影响。

第四十四条 运维人员应严格遵守工作纪律，在没有行政授权的情况下，严禁运维人员查看、修改和传播系统中与运维工作无关的数据。同时，在技术层面应加强对数据库的授权管理，严格将数据库的查看和操作权限控制在最小的必要范围之内。

第四十五条 对非标配的系统（公司员工标配系统如：OA系统、电子邮箱等），当需要新建系统用户账号或者调整功能权限时，需求人应提出服务申请，在申请中说明需要的功能范围以及账号有效期(未说明有效期的视为永久有效)，经用户部门、信息技术部门及相关部门领导审批后，由运维人员根据需求在系统中开通账号和调整权限。

第四十六条 在员工办理离职、退休等相关事项时，运维人员应及时禁用或者删除员工在各系统中的用户账号，因工作需要仍要保留系统用户账号的，需要员工所在部门领导或授权人通过服务申请单提出保留需求，并在需求中指定保留的有效期，经审批后由运维人员备案，在有效期结束前运维人员应通过服务申请向员工的部门领导请示处理意见，并根据意见对账号做处理。

第四十七条 当员工的工作岗位发生变化，如果在系统中的用户权限需要做相应调整时，员工本人应通过服务申请提出调整需求，经审批后由运维人员执行调整。

第四十八条 对丢失系统安全身份认证硬件设备（如USB Key、门禁卡等）的用户，丢失保存密码的计算机（如浏览器记忆过公司邮箱密码等情况）或存储设备的用户，以及发现账号有异常登录等类似情况的用户，必须及时向运维人员说明，以便运维人员在第一时间对系统权限进行防损控制（如禁用账号、修改密码等），避免非授权的操作对系统和业务造成损害。

第四十九条 当公司内部运维资源不足以满足系统运维需求时可以向外部供应商采购相关产品和服务，采购工作应严格遵守公司非业务采购管理办法的规定。

第五十条 与供应商签订合同时应严格评审项目工作说明书（以下简称“SOW”，Statement Of Work），尽可能的让用户和供应商细化需求，使需求范围准确和完整，在合同层面保障项目能够按时按质的执行。评审SOW时应建立评审小组，小组由用户部门和信息技术部门牵头组成，用户部门的被授权人担任组长，信息技术部门的被授权人担任副组长，成员还应包括相关部门的人员，SOW必须经评审小组审核通过后合同方可签约。

第五十一条 与供应商签订合同的同时应与其签订相互保密协议，从法律层面保障公司的信息安全。

第五十二条 被授权的运维经理或者主管负责编制支付外部供应商运维费用的预算，外部运维费用包括供应商的技术支持费用、系统版本升级费用、系统优化项目费用、按年度收取的软件授权费用，等。

第五十三条 因工作原因确实需要供应商的外部人员使用公司的网络和系统时，应做好对外部人员的授权管理，应根据需要由与供应商对接的运维人员为外部人员申请门卡、系统用户和VPN，申请时需要说明使用的范围和时间段。当外部人员撤场时应及时收回门卡、关闭系统用户和VPN。

第五十四条 运维人员应建立外部服务跟踪机制，详细记录向供应商发出的问题报告、需求以及得到的反馈，并计算供应商的服务工时，以保障对问题的解决速度和效果，同时对供应商的服务质量做出评价。

第五十五条 供应商发布新程序和新配置，以及修改数据时，应向对接的运维人员以及关键用户提出申请，在运维人员审核通过的情况下方可执行相关操作。

第五十六条 运维人员应做好运维手册的编写和更新工作，通过运维手册实现运维工作规范化和知识的积累与分享。运维手册的基本内容应包括：系统基本情况（开发及实施厂商、上线时间、服务器地址等）、运行的软硬件环境、运维工作要点、权限和用户管理、常见问题及处理方法等。

第五十七条 运维人员负责牵头编写各系统的用户使用说明书并培训用户，通过说明书和培训让用户可以熟练的使用系统，保障业务在操作层面上可以高效的开展，同时，做好培训工作也可以在用户层面减少因基础使用问题带来的运维工作量，使运维资源可以更多的投入到较为复杂的问题处理上。

第五十八条 应集中妥善的保管系统的各类纸质或电子文档，包括但不限于：各类合同、标书、需求文档、设计方案、项目工作说明书、计划、开发文档、操作说明书、程序代码、安装程序、演示及汇报材料、变更记录、培训材料、运维手册，等。在条件允许的情况下，应通过文档版本管理软件实现文档管理进一步的规范化和精细化。

第五十九条 应建立信息系统知识库（知识库可以是配置管理数据库的一部分），将事件、问题、解决方案等内容纳入知识库中管理，知识来自于用户和运维人员的积累，是公司重要的无形资产。通过知识库，用户可以自助解决部分常规的问题，在用户层面消化掉部分基础问题，以释放更多的二线运维资源处理复杂问题；同时，运维人员可以通过知识库对事件分类、快速识别已知错误并找到已有的解决方案，提高对事件的处理速度。

第六十条 本实施细则由公司信息化领导小组审议通过，自发布之日起生效。

第六十一条 本实施细则由信息部负责解释。

附件1 术语

（1）ITIL：Information Technology Infrastructure Library，即信息技术基础架构库。由英国政府部门CCTA(Central Computing and Telecommunications Agency)在20世纪80年代末制订，现由英国商务部OGC(Office of Government Commerce)负责管理，主要适用于信息技术服务（以下简称“服务”）管理，国际标准化组织在2005年基于ITIL颁布了服务管理国际标准ISO20000，OGC在2007年推出了最新版ITIL V3。ITIL为企业的服务管理实践提供了一个客观、严谨、可量化的标准和规范，被国内外业内广泛应用；

说明：本实施细则主要参考ITIL 2011版（V3的Update），最新版本 ITIL V4 已于2019年初发布。

（2）事件：是特指引起或者可能引起服务中断或者服务质量下降的事件，也包括用户的服务请求；

（3）问题：是指导致事件产生的根本原因，问题的来源通常有三种：

（4）变更：变更请求通常是因为解决问题的方案中需要对系统进行改变而产生，变更请求通常来源于问题管理流程或者由用户提交，变更范围包括但不限于软件、硬件、网络、流程、文档等；

（5）变更管理委员会：以下简称“CAB”（Change Advisory Board），通常由业务部门、管理部门和信息技术部门共同构成，包括：变更提出人、资深的业务或者管理人员、信息技术经理或者主管、各级相关领导等，核心职能是评估变更的合理性并安排变更的实施。为应对出现紧急或重大变更时不能立刻召集所有CAB成员的情况，应在CAB的基础上建立应急小组，应急小组可被授权执行紧急的决定；

（6）信息资产及配置项：企业的信息资产包括但不限于各类用于服务的单独的软件模块、单独的硬件组件、整合的软硬件系统、文档、人员等。配置项是信息资产更为明细的功能单元，例如一台路由器（信息资产）的一个端口（配置项），一个软件系统中的一个功能选项等。

附件2 事件优先级的归类（优先级由高到低）

（1）重大事件：系统功能的重大调整、流程或数据的重大调整、信息化战略或流程咨询、服务异常停止且长时间（工作日中超过30分钟，非工作日中超过8小时）不能恢复、导致业务大面积中断或者结果严重偏离的情况、导致大量数据计算或者更新错误的情况、造成大量生产数据损失的情况，等；

（2）高级事件：影响范围较大的程序和流程及数据调整、复杂方案设计、大规模程序开发、招标或者邀标采购、与新供应商签订合同、服务异常停止但较快（工作日中小于等于30分钟，非工作日小于等于8小时）可以恢复的情况、造成业务中断或者结果偏离的情况、导致数据计算或者更新错误的情况、数据传送失败且不能重新发起的情况、造成生产数据损失的情况，以及非重大的需要超过8小时处理完成的事件，等；

（3）中级事件：影响范围中等的程序和流程及数据调整、方案设计、程序开发、与供应商签订补充合同、境外用户报告的事件和提出的服务请求、业务流程中已产生后继相关数据（如财务数据）但未造成业务结果偏离的情况、数据传送失败但可以重新发起的情况，以及非重大非高级可以在4个小时以内处理完成的事件，等；

（4）普通事件：影响范围较小的程序和流程及数据调整、需求调研及分析、用户和供应商沟通、业务流程中未产生后继相关数据的输入错误或者数据缺失，以及非重大非高级可以在30分钟以内处理完成的事件，等；

（5）服务请求：用户的技术或者业务咨询、培训、软件安装、标准功能的配置和授权、标准功能下被授权的数据查询，等。

附件3 变更优先级分类

（1）按影响程度划分（优先级由高到低）：

（2）按紧迫程度划分（优先级由高到低）：

（3）变更优先级和评审决策级别（优先级由高到低）：

附件4 流程图

（详见正文）

附件5 表单

表1：信息技术服务申请单

（表样略）

说明：

信息技术服务申请单由用户填写并发起流程，首先由用户所在部门领导审批，然后流程到信息技术部门领导审批，如果需要，之后可以根据服务的内容继续选择加签给相关的人员审批（通常可包括财务或业务管理等相关部门，也可根据需要进一步升级到更高层领导），最后到系统管理员评估和执行，流程最后应加签给提出申请的用户及关键干系人，以反馈最终的处理结果。

对有专用服务申请单的事项，须使用专用申请单，无专用的则统一使用《信息技术服务申请单》。专用服务申请单通常为常规标准化的服务请求设立，例如：访客上网申请、办公电话申请、临时电话号码申请、电子邮箱开设申请、短期账号申请，等。

表2：信息技术标准工单

（表样略）

说明：

标准工单的填写内容包括：申请事由摘要、申请类别（目前包括：业务信息系统维护、数据修改、系统软件维护、硬件维修、模板调整、组织机构变更、咨询、其它）、申请事由等，通常由具体执行操作的运维人员填写，填写完成后提交存档。