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

这份运维管理实施细则有选择的参考了ITIL，但总的来说是以当时系统运维工作的实际情况为主（比如并未设立服务台），立足企业自己的工作特点编写的，适用于当时的情况，如需要，仅供参考。

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

第一条 为规范……公司（以下简称“公司”）各信息系统（以下简称“系统”）的运行维护（以下简称“运维”）工作，保障各系统安全、稳定、高效运行，参考信息技术服务管理领域主流的ITIL框架，基于公司实际情况，制定本实施细则。

第二条 本实施细则适用于支撑公司业务运行和管理的各类信息系统，包括但不限于：ERP系统、企业服务总线系统、OA系统、电子邮件系统、主数据管理系统、计划预算管理系统、报销管理系统、产品生命周期管理系统、制造执行系统、商业智能系统、资金管理系统、人力资源管理系统、档案管理系统、发票管理系统、客户关系管理系统、电商系统、域控系统、……，等。

第三条 本实施细则适用于公司总部及所有成员机构。

第四条 本实施细则涉及的相关术语见附件1。

第五条 公司的系统运维工作在信息化领导小组、信息化工作小组的管理下开展工作，运维工作的直接负责和执行部门是信息技术部。

第六条 公司运维组织架构分为一线、二线、三线共三级，一线运维人员由各部门的系统关键用户和信息化工作专员构成，二线运维人员由信息技术部门的各系统管理员构成，三线运维人员由各系统开发商或者实施商的专业人员构成。公司重点建设二线运维团队,各系统的运维工作主要由二线人员承担，二线同时覆盖一线的所有职责，一线是二线的有力补充，三线则是按公司运维工作的需求提供对应的市场化专业服务。

第七条 一线运维人员的主要职责包括：

（一）面向终端用户的现场指导；

（二）协助用户解决使用中的基础事件；

（三）将无法解决的事件反馈给二线运维人员并跟踪解决的过程；

（四）所在部门的信息化需求收集与建议；

（五）信息系统的测试；

（六）其他信息系统运维工作。

第八条 二线运维人员（以下如非特殊说明，本实施细则中运维人员均指二线运维人员）的主要职责包括：

（一）全面管理各系统，保障系统的稳定运行；

（二）响应和解决各类事件，处理系统的技术和业务问题；

（三）数据的备份、处理和挖掘；

（四）流程和系统的优化；

（五）需求的采集和分析；

（六）设计解决方案；

（七）开发新功能；

（八）编写信息化相关文档；

（九）信息化建设规划与建议；

（十）信息化项目管理；

（十一）培训用户和一线运维人员；

（十二）为用户提供各类信息技术支持；

（十三）制定系统应用考核评价体系并组织考核；

（十四）采购和管理外部服务资源；

（十五）其他信息系统运维工作。

第九条 三线运维人员的主要职责是按公司与外部信息技术服务供应商（以下简称“供应商”，通常指系统开发商或实施商）签订合同中约定的服务内容，在二线运维人员的管理下开展工作。

第十条 为保证内部运维资源稳定，每个系统应配置业务和技术能力总体相同的两位运维人员，至少应做到“一主一辅”的配置。

第十一条 公司信息系统的运维管理工作应根据附件4图1中的运维管理流程进行，运维管理流程包括5个部分：事件管理、问题管理、变更管理、发布管理、配置管理。事件管理对事件进行识别和快速处理，然后问题管理基于对事件的回顾分析发现产生事件的根本原因并找到解决方案，接着在变更管理的控制下通过发布管理实现对系统的改变得以解决问题，而配置管理则为这闭环流程提供基础支持。

图1：运维管理流程

第十二条 运维人员应及时识别和响应事件，通过事件管理流程（详见附件4图2），采取所有必要的措施尽快解决事件，避免因事件对业务造成影响，以确保最佳的服务质量。

图2：事件管理流程

第十三条 运维人员接到事件报告或者自主识别事件后，首先应判断事件的影响程度和紧急程度，然后为事件定义处理的优先级（优先级归类详见附件2），之后按优先级的高低合理分配时间和资源进行处理。

第十四条 对境外系统用户报告的事件，因时差会造成信息接收和处理的自然滞后，为优先保障境外业务的顺利开展，运维人员应在条件允许的情况下优先处理境外用户的需求。

第十五条 运维人员应对所有的事件进行记录，中级（含）以上的事件必须详细记录。

第十六条 如事件的复杂程度超过运维人员的技术或者业务能力范围，或运维人员不能在合理的时间内解决事件，运维人员应及时将事件升级。事件升级路径是一线转二线，当二线未能解决时，二线运维人员应及时将事件升级到三线以获得原厂技术支持。

第十七条 为了主动识别事件，运维人员应监控系统运行状态，包括监控服务器计算和存储资源使用情况、网络连通和负载情况、企业服务总线运行情况、各系统服务端运行情况、系统日志等内容。监控工作应制度化和常态化，应做到每个工作日开始时对关键业务系统的监控，应特别关注各系统在跨月、跨年等关键时段的服务情况，在技术层面尽可能做到对事件的及时识别和快速处理。

第十八条 用户的所有服务请求均应通过OA系统中的《信息技术服务申请单》（以下简称“服务申请单”，表样详见附件5表1）正式提出，同时兼顾面谈、电话、即时通讯软件、电子邮件等其它辅助沟通方式。运维人员应在服务申请单中记录事件的处理结果和重要事项，用户可通过流程查看服务申请的处理过程。

第十九条 运维人员均应使用OA系统中的信息技术工单（以下简称“工单”，表样详见附件5表2）记录对事件的处理过程，通过工单为运维知识积累和运维工作的绩效管理建立基础。

第二十条 应通过问题管理流程（详见附件4图3）建立对事件的回顾机制，基于对信息技术基础设施和所有可用信息的调查，回顾和研究事件的特点、共性、频率、趋势等产生事件的根源性问题，结合配置管理数据库对问题进行已知错误识别，最终提出解决方案，努力消除事件或者减少事件的发生，缩短解决问题所需的时间，降低解决问题的成本。

图3：问题管理流程

第二十一条 对可能导致潜在性事件的问题，运维人员应主动提出预防措施，以便事件出现后将影响控制在最小范围内。

第二十二条 应通过变更管理流程（详见附件4图4）保障系统从一个确定状态到另一个确定状态，在最小风险范围内高效经济的实现变更请求，具体应达到的目标包括：

(一)确保所有的变更都遵循标准的方法、程序和规则；

(二)确保所有的变更都能快捷有效的进行；

(三)减少与变更相关的事故对服务的影响；

(四)确保所有的变更都有明确的记录可追踪；

(五)维持变更前后系统运行效果之间的平衡。

图4：变更管理流程

第二十三条 不同级别的变更应进行分类管理。运维人员应准确评估变更的类型，得出变更的优先级和实施先后顺序。变更可按影响程度和紧迫程度两个维度进行分类（具体分类详见附件3）。变更按影响程度变更可分为重大、标准和常规三类，按紧迫程度可分为紧急、高级、中级和低级四类，综合两个维度后得出变更的优先级。

第二十四条 应对不同级别的变更执行对应的审核和实施流程(具体的优先级和评审决策级别详见附件3)。

(一)常规变更可由负责运维工作的经理或主管安排实施。

(二)标准变更需要由变更管理委员会评估和审核后安排实施，必要时可由运维人员召集变更管理委员会成员通过会议的形式评估和确定变更的实施方案。非紧急的标准变更也可以由被授权的负责运维工作的经理或者主管安排实施。

(三)重大变更需要经过变更管理委员会审核后报信息化领导小组进行决策，当信息化领导小组将变更授权给变更管理委员会时，由变更管理委员会评估和安排实施。

第二十五条 运维经理或主管在变更管理中的职责主要包括：

(一)筛选、接受和分类所有的变更请求；

(二)为变更获得所需的授权；

(三)计划和协调变更的实施；

(四)评审所有已实施的变更，确保达到预期目标；

(五)提交变更报告；

(六)根据需要召开变更管理委员会会议。

第二十六条 变更后应进行总结和评价，评价的标准主要包括：

(一)变更是否达到预期效果或可预见的目标；

(二)用户是否满意；

(三)变更是否有不可预料的副作用；

(四)变更过程是否按计划使用相关资源；

(五)实施计划是否正确。

第二十七条 所有变更请求都需要通过OA系统的协同提出申请并执行审批流程。中、低级的常规变更由具体负责的运维人员在运维经理或者主管授权下予以处理，其它所有变更必须经过变更审批。

第二十八条 经审批通过后的变更，应严格按照发布管理流程（详见附件4图5）规定的必要顺序、步骤和操作进行发布，以化解和控制变更可能产生的风险。发布管理应贯穿变更管理的整个周期，为变更管理提供支持。

图5：发布管理流程

第二十九条 运维人员应明确知晓并记录发布的相关内容，包括业务逻辑、必要的技术细节、解决的问题、增强的功能效果、关键用户、相关风险等，并评估新的发布对系统和业务的影响，从而制定测试和发布计划。同时应做好版本历史管理，包括版本号、发布日期、测试及发布后效果等。

第三十条 运维人员进行系统升级、新程序发布（包括新功能或修复Bug的程序）、更改系统配置等改变系统功能的操作时应进行充分的测试，完整验证变更效果之后方可发布。

第三十一条 在条件允许的情况下，各系统均需要搭建开发、测试、生产三套系统环境，新程序或配置需按“开发到测试，测试到生产”的顺序发布，三套系统彼此不直接影响，通过在开发环境和测试环境的充分验证，最大限度保障发布到生产环境下的程序或配置的正确性。

第三十二条 向生产系统发布新程序或配置时，在条件允许的情况下，应尽可能建立回滚机制，需在充分评估回滚对系统功能和数据的影响的基础上，在程序、配置和数据三个方面准备回滚方案，当新的发布在生产系统中出现异常后，可以尽可能的恢复到未发布之前，从而减少对系统的负面影响。

第三十三条 除非业务需求急迫，否则不得在生产时间向生产系统发布新程序或配置。对确实因业务急迫而未经完整测试的紧急发布，应将发布的影响控制在最小范围内，并与关键用户密切配合和沟通，及时对发布进行验证，以便在出现异常情况后及时对系统予以纠正。

来源：猫说信息化，侵权烦请联系删文。