oa系统维护(协同办公oa手机版)「终于解决」

大家好，我是讯享网，大家多多关注。

这个运维管理实施细则选择性的参考了ITIL，但总体来说是基于当时系统运维的实际情况(比如不设服务台)，基于企业自身的工作特点，适用于当时的情况。如有需要，仅供参考。

全文如下(为阅读完整起见，细则所附部分附图直接放在正文相应段落中):

第一条为了规范……所有信息系统(以下简称“系统”)的运行和维护(运行和维护)

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

第三条本规则适用于公司总部和各成员机构。

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

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

第六条公司运维组织架构分为一线、二线、三线三级。一线运维人员由关键系统用户和各部门信息专员组成，二线运维人员由信息技术部门系统管理员组成，三线运维人员由各系统开发人员或实施人员的专业人员组成。公司重点打造二线运维团队，各系统运维主要由二线人员承担。二线涵盖了一线的所有职责，一线是二线的有力补充，三线根据公司运维工作的要求提供相应的市场化专业服务。

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

(1)对最终用户的现场指导；

(二)协助用户解决使用中的基本事件；

(3)将无法解决的事件反馈给二线运维人员，并跟踪解决的过程；

(4)部门信息需求的收集和建议；

(五)信息系统测试；

(6)其他信息系统运行维护工作。

第八条二线运维人员(以下除特别说明外，本细则中的运维人员均指二线运维人员)的主要职责包括:

(1)综合管理各系统，确保系统稳定运行；

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

(3)数据备份、处理和挖掘；

(4)流程和系统的优化；

(5)需求的收集和分析；

(6)设计解决方案；

(7)开发新功能；

(八)编制信息相关文件；

(九)信息化建设规划和建议；

(十)信息化项目管理；

(十一)培训用户和一线运维人员；

(十二)为用户提供各种信息技术支持；

(十三)制定系统应用评估制度并组织评估；

(14)采购和管理外部服务资源；

(十五)其他信息系统运行维护工作。

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

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

第十一条公司信息系统的运维管理按照附件4图1的运维管理流程执行。运维管理流程包括五个部分:事件管理、问题管理、变更管理、发布管理和配置管理。事件管理识别并快速处理事件，然后问题管理基于事件的追溯分析找到事件的根本原因和解决方案，然后在变更管理的控制下，通过发布管理实现对系统的变更以解决问题，而配置管理为这个闭环过程提供基础支持。

图1:运行和维护管理流程

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

图2:事件管理流程

第十三条运维人员在接到事件报告或独立识别事件后，应首先判断事件的影响程度和紧急程度，然后明确事件的优先级(优先级划分详见附件2)，再根据优先级合理分配时间和资源。

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

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

第十六条事件复杂程度超过运维人员技术或业务能力，或者运维人员不能在合理时间内解决事件的，运维人员应当及时上报事件。升级路径是从第一行到第二行。如果二线解决不了问题，二线运维人员要及时将事件升级到三线，以获得原有的技术支持。

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

第十八条用户的所有服务请求应通过OA系统中的《信息技术服务申请表》(以下简称《服务申请表》，详见附件5表1)正式提交，并考虑其他辅助沟通方式，如面对面、电话、即时通讯软件、电子邮件等。运维人员要在服务申请单中记录事件的处理结果和重要事项，用户可以通过流程查看服务申请的处理过程。

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

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

图3:问题管理过程

第二十一条对于可能引发潜在事件的问题，运维人员应主动提出防范措施，以便在事件发生后将影响控制在最低限度。

第二十二条应采用变更管理流程(详见附件4和图4)确保系统能够从一种确定状态变更到另一种确定状态，并在最小风险范围内高效、经济地实现变更请求。要实现的具体目标包括:

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

(二)确保所有变更能够迅速有效地进行；

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

(4)确保所有变更都有清晰的记录和可追溯性；

(5)保持变更前后系统运行效果的平衡。

图4:变更管理过程

第二十三条不同等级的变更应当分类管理。运维人员要准确评估变更的类型，得到变更的优先级和实施顺序。变更可以按照影响程度和紧急程度两个维度进行分类(具体分类见附件3)。根据影响程度，变更分为重大、规范、常规三类，根据紧急程度，变更分为紧急、高级、中级、低级四类。综合两个维度后，可以得到变更的优先级。

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

(1)日常变更可由负责运行和维护的经理或主管安排和实施。

(II)标准变更在实施前需要由变更管理委员会进行评估和审查。如有必要，运维人员可召集变更管理委员会成员，通过会议评估并确定变更的实施方案。非紧急的标准变更也可以由负责运行和维护的授权经理或主管安排和实施。

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

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

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

(二)取得必要的变更授权；

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

(4)审查所有已实施的变更，以确保实现预期目标；

(5)提交变更报告；

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

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

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

(2)用户是否满意；

(3)变更是否有意想不到的副作用；

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

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

第二十七条所有变更请求都需要通过OA系统协同提交，并执行审批流程。中低级例行变更应在运维经理或主管的授权下，由具体负责的运维人员处理，其他所有变更均需经过变更审批。

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

图5:发布管理过程

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

第三十条运维人员在升级系统、发布新程序(包括新功能或漏洞修复程序)、改变系统配置等时，应充分测试系统功能。，并且只有在完全验证了更改的效果之后才能发布它们。

第三十一条在条件允许的情况下，每个系统应建立开发、测试和生产三个系统环境。新的程序或配置应按照“从开发到测试，从测试到生产”的顺序发布，三个系统不会直接相互影响。发布到生产环境的程序或配置的正确性应通过在开发环境和测试环境中的充分验证得到最大程度的保证。

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

第三十三条除业务需求紧急外，生产期间不得向生产系统发布新的程序或配置。对于因业务紧急而未完成测试的紧急发布，应把发布的影响控制在最低限度，并通过与关键用户的密切配合和沟通，及时对发布进行验证，以便系统出现任何异常情况后能及时纠正。

来源:猫说信息化，如有侵权请联系删文。