信息中心IT运维服务管理制度Word下载.docx

上传人:b****6 文档编号:21861285 上传时间:2023-02-01 格式:DOCX 页数:8 大小:21.32KB
下载 相关 举报
信息中心IT运维服务管理制度Word下载.docx_第1页
第1页 / 共8页
信息中心IT运维服务管理制度Word下载.docx_第2页
第2页 / 共8页
信息中心IT运维服务管理制度Word下载.docx_第3页
第3页 / 共8页
信息中心IT运维服务管理制度Word下载.docx_第4页
第4页 / 共8页
信息中心IT运维服务管理制度Word下载.docx_第5页
第5页 / 共8页
点击查看更多>>
下载资源
资源描述

信息中心IT运维服务管理制度Word下载.docx

《信息中心IT运维服务管理制度Word下载.docx》由会员分享,可在线阅读,更多相关《信息中心IT运维服务管理制度Word下载.docx(8页珍藏版)》请在冰豆网上搜索。

信息中心IT运维服务管理制度Word下载.docx

(一)IT运维服务的常规原则包括

1.所有事件和服务请求都要通过业务服务管理系统进行登记、处理、确认、关闭。

2.受理事件和服务请求应符合平均响应时间要求,详细参见运维服务管理制度。

3.应确认用户上报事件/服务请求所选择的系统和服务项是否正确,以便于对事件/服务请求的分析处理,提高解决效率。

4.所有的事件/服务请求都应被完整记录,并保证相关信息尽可能详细。

5.事件/服务请求上报人申请系统数据维护、特殊业务处理时,需要提供总公司相关业务部门负责人签批和IT负责人签批,同意后才可进行维护。

如相关业务部门负责人或IT负责人通过书面或邮件等形式进行了授权,则被授权人可代为签批。

6.根据无纸化办公要求,签批过程应采用OA签报方式。

具体请见运维服务管理制度。

7.应定期对管理员操作日志进行审计。

(二)责任制原则

当问题上报人创建服务工单后,工单系统会自动分配至IT运维人员进行受理,问题的当前处理人为第一责任人,可以通过流程记录跟踪服务请求的当前处理人和服务轨迹。

(三)问题改派原则

当IT运维人员接收用户上报的问题后,如果该工单不属于该运维人员的受理范围,由当前处理人重新改派到对应的IT运维人员。

(四)问题关闭原则

工单解决后需由问题上报人进行确认,确认正确后方可关闭工单。

二、服务流程

(五)本章阐述的服务流程包括

事件管理、用户权限配置、数据维护、机构验收、问题管理、批处理管理、系统巡检、缺陷管理。

(六)事件管理

事件发生时应根据事件管理制度中的相关定义,尽快确认事件级别(即优先级),并发出事件通知。

通知的目的是将影响到服务可用性的事件的有关信息及时通知关键的IT人员和用户,确保相关资源可以投入到事件解决过程中,最快速度恢复IT服务。

1.对于长时间未解决的事件,应定时汇报处理进展;

2.事件解决后应重新确认事件级别,尽快发出事件恢复通知。

3.如事件处理过程中事件级别恶化或事件处理时间超时,则应触发事件优先级升级,并发出事件升级通知。

4.事件恢复后,相关负责人应出具事件分析报告,包括事件处理过程记录、原因分析、后续改进措施等。

如遇需要搭建测试环境重现、分析事件的复杂情形,则应定期发送事件分析进展说明。

5.各主体公司应参照下发的可用性模板每月对可用性进行计算。

各主体如新上线/下线重要系统或系统可用性权重有变化,应及时调整可用性计算模板。

(七)变更管理

1.在对运行中的IT服务进行调整时,须提交变更管理进行授权。

运行中的IT服务主要指生产环境中的所有IT基础设施和在基础设施上运行的各类应用系统服务。

2.变更申请应描述明确和完整,包括变更影响的范围及可能引起的风险,经变更经理初审及相关系统负责人评估,确认具备变更条件后,交由变更管理员编写变更方案。

3.变更方案须包含详细的实施步骤、时间、人员职责、联系方式等,必要时还应有测试方案和回退方案。

4.变更方案须经变更管理委员会审批,变更管理委员会应包括相关系统负责人、相关主体公司负责人、相关IT部门领导。

审批通过后,方可实施变更。

5.对于紧急变更,可通过IT内部认可的方式进行审批,但须将审批内容留痕,并尽快补充到变更工单中。

6.变更执行失败时,应快速修复当前变更,恢复到变更前的状态。

如果回滚操作不能成功,则按照应急方案进行恢复,保证不影响业务正常运行。

(八)缺陷管理

1.缺陷管理流程的主要目的是保证运维和研发、需求部门在缺陷解决的过程(从缺陷的建立到缺陷的解决关闭)中对进度进行跟踪、管理,确保缺陷不丢失。

应用系统软件缺陷管理流程的系统范围包括所有已正式上线的传统保险体系(不含移动互联)相关应用系统,但不包括处于开发或测试环境的系统和应用。

2.缺陷的属性包括:

缺陷级别、缺陷发生概率、缺陷处理状态、缺陷原因等。

3.根据缺陷级别定义,应及时反馈缺陷的上线计划并确定上线时间。

4.应用软件缺陷由缺陷受理人统一对接,并且经过初步分析后分派具体缺陷处理人员。

5.缺陷解决后应由缺陷提交人进行确认,确认缺陷正确解决后方可关闭工单。

如修复后缺陷依然存在,则必须返回缺陷受理人重新分派解决;

如修复后产生其他问题,则应提交新缺陷。

(九)服务请求及其它管理流程

应用运维交接是指信息系统应用运维交接工作,通过明确交接申请方、应用运维方、运维相关方在交接过程中的工作职责、交接方式及步骤,为系统应用运维平稳、顺畅交接提供保障。

1.在项目立项阶段项目组应确定上线后的运维模式,包括确定承接运维工作的部门、运维人员的参与方式、运维人员承担的职责等、与厂商的交接方式、交接时间等相关内容。

对于采购第三方实施服务的项目,在项目采购阶段,项目组应与厂商沟通交接时间和交接标准,并最终达成一致。

2.交接方须为应用运维预留资源准备时间,交接前,交接方须完成系统建设、系统验收、系统环境配备、系统架构部署、交付物和交接清单准备。

3.做运维交接时,如未进行生产发布和测试管理交接的,应同步启动配置生产发布、测试管理交接工作。

4.交接审核包括:

检查交接信息和交付物是否齐全;

确定是否符合交接条件;

制订交接计划。

5.交接过程分为三个阶段:

交接学习阶段、参与运维阶段、主导运维阶段。

交接学习阶段应完成系统基本信息交接、交付物审核完善、系统培训和学习。

参与运维阶段由交接申请方主导运维工作,负责受理问题,交接申请方已提供解决方案的问题,可转交应用运维方处理;

主导运维阶段由运维事业部门主导运维工作,负责受理问题,交接申请方予以配合,包括权限交付、交接宣导。

6.交接完成后应通知相关团队人员,包括业务、需求、开发、测试、配置等。

另外,运维事业部门还应与开发、配置、DBA、主机管理员沟通确认交接完成后的权限管理方案,并据此完成权限设置的实施工作。

(十)用户权限配置

原则上由用户部门负责,或实现与人力的自动对接,IT运维事业部不负责用户权限的开通、权限调整和注销管理。

但目前运维负责的系统,部分用户权限仍由IT运维部门负责配置,用户权限管理流程仅针对这部分用户权限的管理进行说明。

用户权限管理应遵循以下原则:

1.用户权限配置包括用户权限的新增、修改和删除。

需要配置权限时,用户须提供所属公司业务部门负责人签批意见后,由IT应用运维岗进行用户权限新增、修改或删除。

2.应每年至少开展一次生产权限梳理核对,由系统运维部门提取系统生产环境中用户角色/权限的明细表,通过邮件发给归口业务部门对系统中的用户账号和访问权限进行审阅、核对,以识别并清除多余的用户账号,及不符合用户工作职责的访问权限。

应提供系统帐号及权限、检查结果及异常情况的相应处理工作邮件。

(十一)数据维护

指对信息系统生产环境数据库中的错误数据进行修正。

数据维护的原因有操作错误、特殊业务和程序错误等。

数据维护应遵循以下原则:

1.需要修改数据时,用户须提供所属公司业务部门负责人签批意见后,由IT应用运维岗进行用户权限新增、修改或删除。

2.运维人员在日常数据检查工作中,如果发现业务数据问题,应及时通知业务部门,由业务部门申请修改。

如果发现属于程序错误造成的,由应用运维岗上报问题,并及时通知相应开发人员准备数据修改脚本及修改系统程序。

3.业务部门签批人原则上应为该业务条线的主管领导或分管副总,具体可参照相应发文及主体公司内有效授权文件。

4.数据维护为高风险操作,数据维护前需进行数据备份。

(十二)新机构开业验收

保监局验收时需要对系统进行验收。

验收前,信息中心需要制定系统验收方案,对系统进行配置、测试,并对发现的问题进行处理,保证系统的可用性、准确性、连续性,支持完成新机构的开业验收。

(十三)问题管理

负责诊断事件产生的根本原因和确定问题的解决方案,并确保解决方案的正确实施。

问题管理还将维护有关问题、应急方案和解决方案的信息,以便于能够减少事故的数量和影响。

问题管理应遵循以下原则:

1.分析和诊断问题的根本目的在于查明问题根本原因,一旦查明根本原因,未知问题就升级为已知错误。

2.对于未找到根本原因的问题,需提供临时解决方案,以降低问题在根本解决前对业务产生的负面影响,然后要继续对问题进行跟踪诊断,直至未知问题找到根本原因,提供根本解决方案。

3.如果问题最终解决需要通过修复缺陷来完成,则应参照缺陷管理制度创建缺陷修复任务,由研发部门及需求部门对缺陷进行处理。

4.运维事业部统一进行缺陷跟踪,提取进度异常的缺陷,邮件发送至研发部门负责人,由研发项目经理对缺陷修复计划和进度重新进行沟通和评估。

(十四)批处理

为系统中定时执行的对数据进行批量处理的任务,批处理的执行涉及的数据量较大,因此批处理的正确有序执行至关重要,批处理管理工作主要包括批处理的上线、下线以及日常监控。

批处理管理应遵循以下原则:

1.申请中应说明申请内容(新建、变更、删除),注明申请系统、批处理名称、任务处理类、基本任务编码、是否启用、循环类型、循环间隔及起始时间等配置信息,并详细描述申请配置的批处理作业功能用途,支持业务范围等,如有执行参数,需单独注明参数名称及参数值。

2.一般为开发部门向运维提交申请。

运维人员也可直接提交批处理作业配置申请,主要针对批处理作业的启停、执行时间、循环间隔的变更配置,提交变更申请前需征得开发负责人同意,并签字确认。

3.运维应对开发提交的批处理作业配置申请进行初审,有必要时需召开批处理作业上线评审会。

针对新增批处理,审核是否符合上线发布要求,上线启用后是否对正常业务产生影响,各批处理参数配置是否正确合理;

针对已上线的批处理,审核变更或删除操作后是否会对系统服务运行、工作效率、正常业务流程产生影响。

(十五)定期对系统运行情况巡检

定期对系统运行情况巡检至关重要,能够先于用户发现问题,及时制定解决方案,保证系统稳定运行和高可用性。

应用系统巡检应遵循以下原则:

1.每日对系统运行状态进行巡检,包括检查业务系统访问地址登录是否正常、业务操作是否能够正常操作等,并对巡检结果进行记录。

2.具备条件的系统可加入自动巡检平台和基础设施综合监控平台进行自动检查,运维人员应及时在邮箱中对监控工具发来的检查结果进行确认。

3.批处理类型存在crontab、job等运行方式,因此各系统批处理检查方式不同,请按各系统的实际情况进行批处理检查,若存在异常,由各主体根据存储方式提取记录。

4.为加强主动运维,对业务系统数据定期进行检查是不可忽视的工作,梳理系统中具有规律和制度的业务数据或批处理,形成sql脚本,通过数据检查系统建立数据检查任务,检查跟踪系统业务数据运行情况,根据各系统运行情况设置监控反馈频率,若运行出现异常,数据检查系统会发送邮件告警提示,这样可以及时检查业务数据,制定解决方案,保证业务系统数据完整性和数据流程制度性。

(十六)保证系统的管理员账户安全

保证相应管理员权限不被无关人员获得,特制定管理员权限管理流程。

管理员权限管理应遵循以下原则:

1.员工调岗或离职时,应确保及时将信息提交给账户管理员。

账户管理员应定期(建议至少每季度一次)核实调岗或离职人员的账户信息。

2.人员调岗或离职时,账户管理员应更新系统密码,确保原有密码失效。

3.申请用户帐号权限时,申请人必须写明相关的申请信息。

申请信息需包括日期,申请者,审批者,因何工作需要,帐号名称,联系人。

4.系统管理员用户的申请需得到系统运维主管的批准。

所有的审批需能够跟踪和审计;

所有被授权的审批者需有授权书。

5.管理员帐号的申请、批准及实施需保留相关记录,由账号管理员进行统一登记。

记录应包括日期,申请者,批准者,员工姓名及员工工号,帐号名称,状态,以及该帐号的联系人信息。

(十七)IT服务持续性管理

指负责预防灾难发生、增强IT基础架构的恢复能力和容错能力,并在灾难发生后迅速恢复IT服务正常运作的管理流程。

1.IT服务持续性管理是总体业务持续性计划的一部分,并依赖于业务持续性管理流程所提供的信息。

因此,在启动IT服务持续性管理前,应先与业务归口部门咨询或协商业务持续性管理计划。

2.IT服务连续性包含两个维度,一是事前将风险降低至合理水平,二是在业务中断发生以后进行业务流程恢复。

3.事前风险控制主要包括业务影响分析和风险评估。

4.业务影响分析主要内容是对关键业务流程以及由于这些流程中断而可能对组织造成的损害或损失进行确认,具体包括:

定义关键业务流程;

关键业务流程发生中断可能对组织产生的潜在损害或损失;

损害或损失可能出现的具体形式,如收入减少、成本增加、声誉损失或竞争优势丧失等;

服务中断发生后危害或损失程度的变化趋势;

灾难发生后为保持关键业务流程在最低可接受水平运作所必需的人员、技能、设施和服务(包括IT服务)等;

恢复到最低级别的人员、设施和服务所需的时间;

所有必要的业务流程以及支持人员、设施和服务全面恢复所需的时间。

5.风险评估主要通过确认业务中存在的威胁和薄弱环节以及相关的预防措施为决策提供有价值的信息,具体包括:

确认相关的IT组件,包括建筑物、基础设施、系统和数据等;

分析这些资产所面临的威胁以及这些威胁之间的相关程度,并估计灾难发生的可能性(高、中、低);

要确认这些资产的薄弱环节,并进行分类(高、中、低);

根据各IT组件的具体情况评估威胁和薄弱环节,从而评估风险的级别。

6.业务中断发生以后风险控制主要是指应急恢复预案及其演练。

7.应制定总体应急预案,内容包括紧急响应策略、影响评估体系、恢复计划、公共关系策略等。

8.每年应至少进行一次针对关键业务流程的应急演练,回顾演练过程并保留演练记录。

9.应急预案应下发所有相关IT人员,并每年定期组织培训,确保人员熟悉所有问题并在实施恢复期间能够提供支持,同时提高风险意识。

考核条款

(十八)应用运维根据业务需要调整非缺陷类的生产数据,须严格按照上述制度见到业务部门签报。

如非系统问题的数据修改没有签报,不得自行调整生产数据,违者按照《行政管理制度》戊类考核。

(十九)生产应用权限目前仍在由运维部门开通,如未见到业务部门签报私自给相关业务开通权限,按照《行政管理制度》丁类考核。

(二十)生产项目交接,须按照运维交接规范做好交接工作,交接物不齐全签字交接,按《行政管理制度》已类考核。

(二十一)运维重要人员离职,必须对这些人员的生产相关权限进行解除。

如发生账号未解除由按照《行政管理制度》己类考核。

(二十二)生产数据修改,须按照上述制度严格写入备份表,做到有据可查,有踪可追。

如发生修改原数据未进备份表按照《行政管理制度》己类考核。

(二十三)出现本制度已明确考核条款外的其他违纪行为,责任人参照《行政管理制度》有关条款执行。

附则

(二十四)本制度由信息中心负责制定、解释和修订。

(二十五)本制度自发布之日起执行。

信息中心

9月1日

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 农林牧渔 > 水产渔业

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1