宿迁市烟草局

政府信息公开

名称 宿迁市烟草专卖局(公司)系统信息系统运行维护管理办法(试行)
索引号 142334102/2015-00020 分类 工作部署   烟草    通知
发布机构 市烟草局 公开日期 2015-04-13
文号 宿烟〔2015〕26号 关键词  
文件下载  

宿迁市烟草专卖局(公司)系统信息系统运行维护管理办法(试行)

宿迁市烟草专卖局(公司)

2015年3月

目录

 

第一章 总则 - 3 -- 4 -

第二章 管理机构与职责 - 3 -- 4 -

第三章 管理定义及目标 - 3 -- 5 -

第四章 管理模式 - 3 -- 6 -

第五章 岗位与职责 - 3 -- 7 -

第六章 管理流程 - 3 -- 8 -

第七章 项目管理 - 3 -- 10 -

第八章 系统管理 - 3 -- 11 -

第九章 日常管理 - 3 -- 12 -

第十章 运维外包管理 - 3 -- 13 -

第十一章 安全管理 - 3 -- 14 -

第十二章 考核监管与责任 - 3 -- 15 -

第十三章 附则 - 3 -- 16 -

附件一 - 3 -- 17 -

附件二 - 3 -- 21 -

附件三 - 3 -- 36 -

附件四 - 3 -- 49 -

附件五 - 3 -- 64 -

第一章 总则

第一条 为加强宿迁市烟草专卖局(公司)系统信息系统运行维护管理(以下简称运维管理)工作,保证信息系统正常使用和安全稳定运行,依据《江苏省烟草专卖局关于印发江苏省烟草专卖局(公司)系统信息化工作管理办法的通知》(苏专信〔2012〕95号)、《江苏省烟草专卖局办公室关于印发江苏省烟草专卖局(公司)系统信息系统运行维护管理办法(试行)的通知》(苏专办发〔2013〕004号),结合全系统工作实际,坚持实行统一规划、统一规范、分级管理和分级负责的原则,特制订本办法。

第二条 本办法所称信息系统包括基础设施、信息安全保障设施、应用支撑系统,以及应用系统。信息系统运行维护(以下简称运维)是指基础设施、信息安全保障设施、应用支撑系统的运行保障与故障维修,以及应用系统的日常运行保障、故障排除、性能优化和应用支持服务等一系列工作。

第三条 本办法适用于市局(公司)以及各县(区)局(分公司)信息系统运行维护管理工作。

第二章 管理机构与职责

第四条 市局(公司)信息中心是全系统运维工作主管部门,其运维管理职责是:

(一) 制订全系统运维管理制度、流程、技术标准和服务规范;

(二) 指导全系统运维工作,组织开展检查、考核和培训;

(三) 组织建立全系统运维管理体系和应急保障机制,协调处理运维事故;

(四) 按照省局要求,组织开展统一推广的信息系统的运维工作;

(五) 设立运维管理专职岗位具体负责运维管理工作;

(六) 具体承担市局(公司)运维管理和组织实施工作。

第五条 各县(区)局(分公司)办公室是本单位信息化运维工作主管部门,其运维管理职责是:

(一) 负责县(区)局(分公司)的运维管理与实施工作;

(二) 负责本单位有关人员的运维管理和技术培训,建立健全运维管理制度;

(三) 按照省局、市局(公司)要求,承担统一推广系统的本级运维工作;

(四) 设立运维管理专职岗位具体负责运维管理工作。

第六条 各单位应用系统主管部门负责确定信息系统运维需求,评价运维服务质量。本办法所称应用系统主管部门是指该系统所承载或处理业务工作的主管部门。

第三章 管理定义及目标

第七条 运维管理采用以流程为导向、以用户为中心的管理方法,通过梳理整合、规范运维工作,提高信息系统的运营水平。

第八条 运维管理的总体目标是“确保所有提供的信息化支撑工作均以用户为中心,实现信息化与业务发展的融合;确保提供高质量信息化服务,提高用户的满意度;体现信息化支撑的价值,使得信息化能力成为宿迁烟草核心竞争力的重要组成部分”。

第四章 管理模式

第九条 信息中心是信息系统运行维护工作的管理部门,同时也是信息系统运行维护工作的提供部门。管理模式包含运维管理模式和运维支撑模式。

第十条 运维管理模式实行“统一管理、分级负责”的管理模式,即市局(公司)负责本级的运维管理并指导全系统运维管理工作,各县(区)局(分公司)负责当地的运维管理工作。

第十一条 运维支撑模式采取“统一入口、统一平台、统一流程”的服务模式,即统一服务台接入、统一服务管理平台支撑、统一标准流程流转。

第十二条 “统一入口”指统一服务台,对用户而言,服务台是统一联络点,服务台参照规范要求确保用户的服务请求及故障申告得到快速有效的解决。

第十三条 “统一平台”指信息中心统一采用IT运维管理平台支撑服务管理的运行,统一服务管理平台将最终实现集中管控和统一展现,规范IT运维管理流程,有效管理基础设施、桌面系统、IT应用系统的运维工作,实现IT运维的主动管理。

第十四条 “统一流程”指通过统一服务台接入的所有服务请求及故障申告均按照预先定义的标准流程,进行流转,实现统一、规范、有效的IT运维管理。

第五章 岗位与职责

第十五条 系统管理员、数据库管理员、安全管理员等在运维实施中涉及信息安全的岗位(以下统称运维管理员岗位)要由本单位在册人员担任。

第十六条 运维管理员岗位除包含系统管理员、数据库管理员、安全管理员等岗位职责外,其运维岗位职责是:

(一) 负责监控事件处理流程的效率和效果,监控运维团队的工作,为事件管理流程提供改进建议,对运维系统的应用提供改进建议;

(二) 负责协调处理影响服务质量的所有问题,发现造成问题的根本原因,跟踪问题解决的过程,必要时进行升级以及问题升级后的协调工作;

(三) 负责记录、整理、审核相关人员提出的变更请求,初步评价变更的风险、影响,跟踪变更实施过程,确保变更请求具有充分、准确的信息以及评估变更结果符合要求;

(四) 负责配置管理数据库的初始化、数据核对、配置审计及维护工作。

第十七条 担任运维管理员岗位工作的人员要相对稳定并建立AB角工作机制,可以一人多岗,人员变动时要做好交接工作。要定期开展专业技能培训,上岗人员要具备相应的专业技能。

第十八条 担任运维管理员岗位工作的人员要严格遵守保密规定,未经批准不得将本岗位工作交给他人办理,不得向其他单位(个人)提供任何数据和擅自复制数据,不得变更、删除任何数据或改变系统配置。

第六章 管理流程

第十九条 各单位要严格遵守全市统一制订的运维工作流程,包括事件管理、问题管理、变更管理、配置管理等运维流程规范。运维服务机构实施运维操作,包括日常巡检、维护保养和故障处理等,要严格按照信息中心审核认可的工作流程进行。

第二十条 各单位要建立运维审核机制。系统配置变更和系统优化、性能调整,要在信息中心履行审批程序并经该系统主管部门同意后实施。

第二十一条  行业统一推广系统的整体优化和调整由国家局统一组织实施,各单位对行业统一推广系统本级的系统软、硬件调整必须经省局(公司)同意并报国家局批准后实施。

第二十二条  全省统一推广系统的整体优化和调整由省局(公司)统一组织实施,各单位对全省统一推广系统本级的系统软、硬件调整必须经省局(公司)批准后实施。

第二十三条  全市统一推广系统的整体优化和调整由市局(公司)统一组织实施,各单位对全市统一推广系统本级的系统软、硬件调整必须经市局(公司)批准后实施。

第二十四条  现阶段IT运维管理流程主要由服务台、事件管理流程、问题管理流程、变更管理流程组成。

第二十五条  服务台主要由服务台服务规范、首问负责制、服务投诉处理、服务台知识管理等部分组成。

第二十六条  事件管理流程主要由事件记录及分类、紧急事件确认、初始支持、二线支持、解决方案细节记录、事件处理监控、事件管理、紧急事件处理子流程、维护作业子流程、服务请求处理子流程等部分组成。

第二十七条  问题管理流程主要由问题识别与记录、问题审核、问题分派、问题分析及诊断、确认解决方案、问题回顾、问题监控、问题总结与关闭等部分组成。

第二十八条  变更管理流程主要由变更发起、变更分类及审核、变更审批、变更任务安排及分派、变更实施及监控、变更回顾、变更关闭等部分组成。

第二十九条  建立健全流程评估和持续优化机制,保证流程实用、有效、正确地执行,当流程不能够适应服务管理运营时,必须及时对此进行分析、找出缺陷、进行改进(例如增加或合并流程的角色、增加或合并流程等),从而实现可持续提升。

第七章 项目管理

第三十条 信息系统运维分为建设维护期和运行维护期。建设维护期运维属于项目建设合同(或采购合同)服务内容,按照合同约定执行。运行维护期自项目建设合同(或采购合同)约定的运维服务内容全部完成之日计起,各单位要在信息系统进入运行维护期前完成运维服务机构选择工作。

第三十一条  基础设施、信息安全保障设施和应用支撑系统运维项目由信息中心提出,应用系统运维项目由该系统主管部门提出,运维经费要纳入各单位预算管理并由信息中心统一申请预算,运维费用不得超过国家局及省局(公司)统一制订的标准,运维费用要符合烟草行业信息系统建设相关管理和费用计算办法。

第三十二条  要加强运维项目集中统一管理。能实行集中运维的信息系统应委托运维服务机构进行集中运维;暂时无法进行集中运维的信息系统,对同一机构开发(建设)的系统要进行运维项目整合。

第三十三条  符合招标条件的运维项目,要通过招标方式选择运维服务机构。信息中心会同应用系统主管部门按照保证信息系统安全、稳定运行的原则设定投标人资格条件,招标文件须经法规部门审核。各单位进行运维项目招标时,在保证程序合规、公平公正的前提下,优先选择行业组建的全资或控股信息技术公司。新建信息系统在开发(建设)项目招标时,要将运行维护期的运维费用纳入招标内容并作为评标依据。

第三十四条  行业统一推广系统实行“统一管理、分级负责”的运维管理模式,国家局负责制订行业统一推广系统的运维流程、服务标准和费用标准等,运维项目由省局(公司)按照国家局要求统一组织实施。

第三十五条  全省统一推广系统实行“统一管理、分级负责”的运维管理模式,省局(公司)负责制订全省统一推广系统的运维流程、服务标准和费用标准等,运维项目由市局(公司)按照省局(公司)要求统一组织实施。

第三十六条  全市统一推广系统实行“统一管理、分级负责”的运维管理模式,市局(公司)负责制订全市统一推广系统的运维流程、服务标准和费用标准等,运维项目由县(区)局(分公司)按照市局(公司)要求统一组织实施。

第八章 系统管理

第三十七条  信息系统在设计开发阶段要进行运维方案论证;在项目验收交接阶段要进行系统运维手册或资料的审核并确定运维需求。

第三十八条  基础设施、信息安全保障设施和应用支撑系统的管理员账号和相应权限由信息中心统一管理,账号的创建、变更要履行审批程序。

第三十九条  为应用系统用户分配账号和权限的管理员账号由应用系统主管部门管理,管理员账号的创建、变更和撤销等要在信息中心备案;当此类管理员账号由信息中心负责管理时,账号的创建、变更和撤销须经该系统主管部门审核同意。

第四十条 信息系统的软、硬件配置和软件版本由信息中心统一管理,要妥善保管信息系统的各类日志,未经审核批准,不得擅自删除。

第四十一条  当信息系统需要变更时,如服务器添加、系统软件升级、系统扩容等,系统管理员应对变更需求进行确认,并依据变更内容填写变更申请单,进行系统变更。

第四十二条  系统管理员应定期检查信息系统,检查内容包括:信息系统运行状态、信息系统文件有无破损、信息系统服务器是否存在异常、信息系统是否存在安全漏洞。

第九章 日常管理

第四十三条  市局(公司)信息中心建立统一的运维服务台,统一受理信息系统故障报告和用户意见。各级运维队伍对运维问题应做好相关记录,问题的描述要详细、准确,答复要及时、明确。对于本级无法解决的问题应及时上报,并配合解决。

第四十四条  信息系统运维实施过程中的各项工作(事件)的处理程序、操作步骤、启动时间,均要按照操作规范、流程和服务质量要求严格执行。在实施中进行系统变更必须制订回退方案和应急预案,必要时准备好后备配件和应急措施。关键设备应有备品备件,并进行定期的检测和维护,确保随时处于可用状态。

第四十五条  信息系统要实行电子化运维管理,对运维工作中所有事件的提出、受理、审核、批准、实施过程和结果进行全程记录。市局(公司)信息中心要按照行业统一的要求和标准,建立信息系统运维知识库。

第四十六条  各单位要保证在机房运行期间有人值守或处于监控状态。主要业务信息系统因故停止运行并在一小时内没有恢复正常运行的,要及时向省局(公司)信息中心报告并通知相关业务部门。

第四十七条  行业统一推广系统日常维护工作按照国家局的统一要求进行,在系统无法正常运行时要及时向国家局指定的工作机构及省局(公司)信息中心通报有关情况。

第四十八条  全省统一推广系统日常维护工作按照省局(公司)的统一要求进行,各单位在系统无法正常运行时要及时向省局(公司)信息中心通报有关情况。

第四十九条  全市统一推广系统日常维护工作按照市局(公司)的统一要求进行,各单位在系统无法正常运行时要及时向市局(公司)信息中心通报有关情况。

第十章 运维外包管理

第五十条 市局(公司)信息中心在运维管理中担任管理和执行角色,负责跟踪外包运维工作处理过程及执行运维服务工作;监控运维工作执行效率和效果;对于由多个外包服务机构参与处理的问题,负责协调各机构的运维资源;考核外包服务单位的运维绩效。

第五十一条  外包服务机构在运维管理中担任执行角色,负责执行外包的运维服务工作,保证运维服务质量满足宿迁烟草运维要求。

第五十二条  外包运维服务机构要具有相应的资质,更换外包运维服务机构时要有3个月以上的工作交接期并采取有效措施保证运维工作的稳定性。

第五十三条  外包运维服务机构申请信息安全管理体系认证或其他认证时,若认证范围涉及行业信息,须经省局(公司)同意并报国家局批准。

第五十四条  与外包运维服务机构签订服务合同必须包括信息安全和保密条款,或另行签订信息安全保密协议,明确双方的信息安全保密责任。

第五十五条  对外包运维服务机构的运维权限实行统一管理,定期更换密码,采取有效措施防止权限失控。

第五十六条  对外包服务人员实行统一管理,服务人员要遵守烟草行业的相关管理规定。

第十一章 安全管理

第五十七条  确保信息安全事件得到及时的跟踪、控制和处理,力求使信息安全事件的影响最小化。

第五十八条  担任运维管理员岗位工作的人员要签订保密责任书,要采取必要的技术措施实行运维管控,规范运维操作,防止行业敏感信息外泄,保障信息安全。

第五十九条  信息系统的所有管理员账号密码要按照安全规则设置、保管和定期更换,管理员变动后必须及时变更密码。各单位要建立信息系统管理员账号密码备案制度。

第六十条 各单位要制订信息系统数据备份管理制度,明确各类数据备份的周期、保存时限和日常备份责任人等,保证系统发生故障时能够迅速恢复;业务数据必须设置在线定时自动备份策略,必要时应采用双机热备份。

第六十一条  各单位重要业务数据必须每年定期、完整、真实、准确地转储到不可更改的介质上,实行集中存储和异地保管,保存期根据档案管理要求确定。备份数据不得更改,要指定专人负责保管和登记。

第六十二条  原则上不得通过互联网进入行业网络实施远程维护操作。特殊情况下确实需要的,要在市局(公司)信息中心履行审批程序并要采取必要的安全措施。

第十二章 考核监管与责任

第六十三条  运维管理实行逐级考核管理制度,各单位要建立完善监管体系,切实加强运维工作监督管理。

第六十四条  市局(公司)信息中心每年组织一次全系统信息系统运维工作考核评议。信息系统运维考核评议的主要内容是:运维项目招标和管理情况,运维服务指标完成情况,运维服务对象和应用系统主管部门满意度情况、运维管理情况、运维规范化情况,以及行业统一推广系统、全省统一推广系统、全市统一推广系统的运维要求、规范和标准执行情况等。

第六十五条  对违反本办法规定导致系统无法正常运行或造成经济损失的,市局(公司)将依法依规追究有关领导和人员责任。

第十三章 附则

第六十六条  本办法管理细则见附件:

(一) 附件一《宿迁市烟草专卖局(公司)系统信息系统运行维护管理办法(试行)》服务台细则

(二) 附件二《宿迁市烟草专卖局(公司)系统信息系统运行维护管理办法(试行)》事件管理细则

(三) 附件三《宿迁市烟草专卖局(公司)系统信息系统运行维护管理办法(试行)》问题管理细则

(四) 附件四《宿迁市烟草专卖局(公司)系统信息系统运行维护管理办法(试行)》变更管理细则

(五) 附件五《宿迁市烟草专卖局(公司)系统信息系统运行维护管理办法(试行)》配置管理细则

第六十七条  本办法由市局(公司)信息中心负责解释。

第六十八条  本办法自印发之日起施行。

附件1:

《宿迁市烟草专卖局(公司)系统

信息系统运行维护管理办法(试行)》

服务台管理细则

宿迁市烟草专卖局(公司)

2015年3月

第一章 总则

第一条 为规范宿迁市烟草专卖局(公司)系统IT运行维护工作,使服务台能够对IT服务整个过程进行跟踪和监控,对外树立统一、规范的服务形象,提升用户满意度,根据相关规章制度及标准制订本管理细则。

第二条 本细则适用于市局(公司)以及各县(区)局(分公司)。

第二章 术语

第三条 服务台是组织中特定的部门、小组或个人完成的一项职能,它为用户提供了问题受理的单点接入功能。服务台将受理的用户故障申告或服务申请提交至相关的运维人员,并跟踪问题处理的过程。

第三章 服务台组织方式

第四条 市局(公司)信息中心须设置服务台,统一提供IT服务。

第五条 可采用以下几种服务台组织方式:

(一) 由信息中心人员采用轮流值班的方式担任服务台;

(二) 由信息中心专人兼职担任服务台;

(三) 由第三方服务厂商人员兼职担任服务台;

(四) 由第三方服务厂商人员专职担任服务台。

第四章 服务台服务规范

第六条 服务台人员在为用户提供支持服务时,必须礼貌、真诚的提供服务,对待用户必须耐心,仔细倾听用户的描述,体现IT支持人员专业的精神面貌。

第七条 服务台人员在处理客户的服务请求、故障申告、投诉和回访用户时,必须以规范的语言与客户进行交流。

第八条 服务台人员处理用户提交的服务请求及故障申告时,必须严格遵循IT服务管理流程的规定,须将详细情况按服务管理平台的格式录入服务管理平台,对于关键字段的录入要求准确。

第九条 应及时将工作分派给相关的运维人员,并跟踪、监督工作的处理情况。

第十条 服务台人员在分派工作时,除了通过服务管理平台分配外,还应电话与相关运维人员沟通,确保相关运维人员在第一时间处理该工作。

第五章 首问负责制

第十一条 服务台内部首问负责制,指第一个接听客户电话的服务台人员即为事情的负责人(以下简称负责人),负责跟踪整个工作的处理过程。

第十二条 负责人随时通过流程管理平台跟踪工作的处理状态,定期联系当前的相关运维人员,了解最新处理情况,直至工作处理完毕。

第十三条 负责人必须密切关注工作的优先级和完成期限,保证工作在时限内得到解决。如超过完成时限没有完成,负责人应立即对工作进行升级通知相关人员

第六章 附则

第十四条 本细则由市局(公司)信息中心负责解释。

第十五条 本管理细则从印发之日起施行。

附件2:

 

《宿迁市烟草专卖局(公司)系统

信息系统运行维护管理办法(试行)》

事件管理细则

 宿迁市烟草专卖局(公司)

2015年3月

第一章 总则

第一条 为加强宿迁市烟草专卖局(公司)系统IT运行维护管理工作,确保发现的系统故障或潜在故障能够快速解决并恢复业务正常运行,用户提出的IT相关服务能够快速响应处理,根据相关规章制度及标准制订本管理细则。

第二条 本管理细则适用于市局(公司)以及各县(区)局(分公司), 主要针对生产运行中发生的事件进行有效管理。包括各单位所维护的所有应用系统和相关基础架构,如机房环境与设施、系统软硬件、网络通信、应用系统等生产运行事件。

第二章 术语

第三条 服务台是组织中特定的部门、小组或个人完成的一项职能,它为用户提供了事件受理或服务请求的单点接入功能。服务台将受理的事件或服务请求分派给相关的处理人员,并跟踪事件处理的过程。

第四条 合作单位是与信息中心签有服务合同的公司,合作单位需指定具体的人员对信息中心的软、硬件进行维护。

第五条 故障申告是指信息中心所支持的系统和IT环境中所有影响正常使用、导致或可能导致IT服务中断或服务质量下降的任何情况。

第六条 服务请求是组织内部预先设定的一系列标准服务,其提供是根据既定程序进行,而这些程序是经过协商的且具有适当的检查和控制功能,市局(公司)信息中心统一将服务请求划分为:使用咨询、使用培训、巡检服务、其他服务。

第七条 使用咨询是由用户提出的,对信息系统操作、业务流程等方面的求助和询问。

第八条 使用培训是由用户或信息中心提出的,针对系统操作、业务流程等方面的正式培训。

第九条 巡检服务是由信息中心或合作单位进行的,对应用系统、桌面系统、基础设施进行运行情况检查的工作。

第十条 其他服务是由用户通过信息中心认可的渠道(电话、邮件、传真等)发起的,寻求信息中心帮助和支持的,除以上服务和变更以外的其他事情。

第十一条 事件分类指按照业务和技术两个维度对事件进行分类,便于对事件发生情况进行分析和统计。市局(公司)采用由省局(公司)经济信息中心进行统一维护和下发的事件分类标准。

第十二条 影响度指就所影响的用户或业务数量而言,事件偏离正常服务级别的程度。

第十三条 紧急度指解决故障时,对用户或业务来说可接受的耽搁时间。

第十四条 优先级是基于紧急度和影响度确定的事件处理优先顺序。所有事件都将分配到四个优先级中的一个,对于具有同样优先级的事件,可按解决事件需花费的精力的多少来安排顺序。

第三章 职责

第十五条 各单位事件管理的相关角色包括:流程负责人、事件经理、运维工程师、服务台。

第十六条 流程负责人是事件管理流程执行情况和执行效率的责任人,主要负责事件管理流程的制订和推动,主要职责包括:

(一) 制订事件管理制度和流程;

(二) 根据管理目标改进和修订事件管理制度和流程;

(三) 监控和评估事件管理流程执行的效果和效率;

(四) 向管理层汇报事件管理流程的执行情况。

第十七条 事件经理是事件管理流程执行过程中的监控人和协调人,负责在事件解决过程中的资源的协调和监控,主要职责包括:

(一) 按事件管理规定控制事件管理流程;

(二) 传达事件管理流程新政策;

(三) 确保事件处理过程中资源得到有效协调;

(四) 解决流程执行的异常状况;

(五) 分析和回顾事件管理流程,提出流程改进意见和建  议。

第十八条 运维工程师是相关系统的支持人员或是相关问题领域的专家,负责找出解决方案并尽快恢复服务,主要职责包括:

(一) 负责对分发来的事件进行处理;

(二) 根据经验和专业技能,提供有效的解决方案;

(三) 决定需要采取何种措施恢复服务并实施有效的行动;

(四) 必要时,负责引入原厂商或相关单位支持;

(五) 更新事件单,确保事件单真实反映事件状态;

(六) 如果不能在解决时限内解决事件,根据事件升级通知规则处理。

第十九条 服务台负责记录用户提交以及由监控系统自动发现的事件,并对事件进行分类、分级以及分派给相应人员进行处理,跟踪事件的解决过程,主要职责包括:

(一) 在指定的时间内响应所有用户发起的热线电话、邮件等事件报告,并完整记录事件信息;

(二) 根据事件所造成的影响,初步判断事件的优先级;

(三) 根据事件内容对事件进行合理分类;

(四) 将事件分派相应的运维工程师来处理;

(五) 跟踪事件处理进度,根据事件升级规则与运维工程师或事件经理进行沟通,保障事件及时处理;

(六) 与用户确认事件处理结果,对事件处理过程进行评价,结束事件处理。

第四章 活动

第二十条 各单位事件管理的主要活动包括:事件接收与记录、事件分派、事件调查与诊断、事件解决与恢复、事件确认与评价。

第二十一条 事件接收与记录,服务台记录所有用户提出的事件或服务请求,服务台可对外提供(但并不限于)电话、电子邮件、网站等方式,便于用户沟通。主要活动包括:

(一) 服务台对来自用户和系统产生的事件进行详细记录;

(二) 对于非信息中心维护职责范围内的事件在告知用户后进行关闭处理;

(三) 根据事件内容,判断事件分类;

(四) 紧急重大事件立即联系运维工程师,上报事件情况。

第二十二条 事件分派,服务台根据预先设定的分工表将不同类别的事件分发至不同的运维工程师。主要内容包括:

(一) 根据事件描述和分类,判断该事件由哪位工程师、团队处理,并与运维工程师联系确认处理人;

(二) 运维工程师判断是否需要根据服务协议联系第三方厂商帮助解决并负责核查;

(三) 对于省局(公司)、市局(公司)统一建设、维护的系统,在必要时联系省局(公司)、市局(公司)帮助解决并负责跟踪核查;

(四) 将工单分派给工程师处理。

第二十三条 事件调查与诊断,运维工程师负责查找事件根本原因和解决方案。主要内容包括:

(一) 根据事件记录的描述以及服务台对紧急、重大事件的初步判断最终确定事件优先级,如优先级为高和极高的事件须立即通知信息中心相关人员;

(二) 指定时限内不能解决的事件,应及时通告事件经理,由事件经理负责协调资源做进一步处理;

(三) 对经过客户确认未得到妥善处理的事件做进一步处理。

第二十四条 事件解决与恢复,运维工程师负责实施查找到的解决方案以解决事件。主要内容包括:

(一) 对于需要通过变更解决的事件提出变更申请,通过变更流程实施解决方案;

(二) 事件解决后,详细记录事件解决过程及方案并更新事件信息及状态;

(三) 将典型的解决方案作为知识提交到知识库;

(四) 针对故障申告,必须记录服务恢复时间。

第二十五条 事件确认与关闭,服务台通过电话等方式和用户确认事件处理情况,对事件处理过程进行评价。主要内容包括:

(一) 通过回访与客户确认事件是否已被解决,如解决设置事件处理结果,关闭事件单结束事件处理;

(二) 如果没有解决,将事件返回给支持人员继续处理;

(三) 服务台在关闭事件的同时必须确认事件单记录的服务恢复时间是否准确;

(四) 部分事件在关闭后会作为问题管理的输入进行进一步处理以发掘故障产生根源。

第五章 规则

第二十六条 总体规则:

(一) 信息中心所支持的系统和网络环境中,所有影响正常使用的情况都须通过事件管理流程处理;将通过流程中定义的规范和规则进行管理;

(二) 所有参与事件的人员须遵守统一的事件管理流程,不应有任何例外;

(三) 所有运维工程师须优先处理优先级为“极高”和“高”的事件;

(四) 应定期对发生的事件进行分析和总结,对发现的潜在的问题发起问题管理流程;

(五) 应定期对流程进行回顾,以改进事件管理流程。

第二十七条 责任人规则:

(一) 当事件单创建后,由服务台负责对事件的整个处理过程进行跟踪和监督;

(二) 当事件单被分派后,由被分派方(指定的运维工程师)负责该事件处理;

(三) 事件处理过程中,如果需要向用户通知处理情况,由事件单的当前处理人负责。

第二十八条 创建规则:

(一) 服务台和运维工程师在运维工作中均可以创建事件单;

(二) 所有由监控系统发现的紧急告警均须创建类型为“故障申告”的事件单;

(三) 用户通过服务台提出的,对信息系统操作、业务流程等方面的求助和询问等,须创建类型为“使用咨询”的事件单;

(四) 用户通过服务台提出的,对信息系统操作、业务流程等方面进行培训,须创建类型为“培训服务”的事件单;

(五) 用户通过信息中心认可的渠道(电话、邮件、传真等)发起的,寻求信息中心帮助和支持的,除故障申告和变更以外的其他事情,须创建类型为“其他服务”的事件单;

(六) 运维人员在日常运维过程中发现故障,须创建类型为“故障申告”的事件单;

(七) 运维人员在日常运维过程中,需要进行设备巡检时,须创建类型为“巡检服务”的事件单;

(八) 事件创建过程中,应根据附则二《事件通知策略》通知相关人员。

第二十九条 分派规则:

(一) 事件单由服务台统一分派;

(二) 运维工程师不能退回和转派服务台分派给自己的工单;

(三) 运维工程师在工单处理过程中,由于某些原因不能继续对工单进行处理时。服务台和事件经理可以将工单转派给其他工程师处理。

第三十条 升级通知规则:

(一) 按事件优先级将事件分为四级,即1级(极高)、2级(高)、3级(中)、4级(低)。各级事件对应的优先级定义参见附则一《事件优先级定义》;

(二) 不同优先级事件对应不同的事件解决时限,事件未能在规定解决时间内解决,应按照附则三《事件升级通知策略》的规定及时通知相关人员。

第三十一条 重复事件处理规则:

(一) 短时间内不同用户报告的相同故障现象的事件,可以认为是重复事件。可以将重复事件关联在一个主事件上,主事件被解决时,所有的重复事件都被解决;

(二) 重复的事件应该被标识,不计入事件流程的关键衡量指标;

(三) 服务台如可以判断到重复事件,则由服务台对重复事件标识,否则由运维工程师人员负责重复事件的处理。

第三十二条 关闭规则:

(一) 事件解决后由服务台统一关闭。服务台如果认为事件需要重新处理,可将事件提交给运维工程师重新处理;

(二) 服务台分派事件后,由于某些客观原因不需要对已提交事件进行处理,并且事件还未被设置为已解决或已关闭状态,服务台可撤销事件单,关闭事件;

(三) 撤销事件单时,须记录事件撤销原因;

(四) 事件被撤销后,服务台可通过电话、短信或邮件的方式通知事件当前处理人。

第六章 附则

第三十三条 本管理细则由市局(公司)信息中心负责解释。

第三十四条 本管理细则从印发之日起施行。

第三十五条 相关事件业务策略见附则:

(一) 附则一《事件优先级定义》

(二) 附则二《事件通知策略》

(三) 附则三《事件处理升级策略》

附则一、事件优先级定义

事件的优先级表明了该事件的处理优先顺序,所有事件都将分配到四个优先级中的一个。优先级从 1 (极高) 到 4 (低) 。

表三是宿迁市烟草专卖局(公司)制订的优先级判断原则,事件优先级从事件的影响程度(表一)和事件紧急程度(表二)两个维度来确定。事件优先级可分为四级:极高、高、中、低。

表一、事件影响程度定义表

描述

分数

企业外网

25

18

10

8

5

500+

25

15

8

3

一级

25

15

5

全部应用

25

15

10

3

60-100

40-59

20-39

0-19

表二、事件紧急程度定义表

紧急度

极高

表三、事件优先级定义表

影响程度

极高

极高

极高

极高

附则二、事件通知策略

事件通知策略的目的是将影响到服务可用性事件的有关信息及时通知信息中心和业务部门的相关人员。

通知基于优先级发送给相关人员。表四(“-”表示不被通知的人员)列出了不同优先级的事件所需要通知到的人员清单。

表四、不同优先级事件通知人员列表

系统管理员

业务责任人

信息中心主任

业务部门负责人

通知

通知

通知

通知

通知

通知

通知

通知

通知

通知

附则三、事件升级通知策略

不同优先级事件对应不同的事件解决时限,事件未能在规定解决时间内解决,应按照表五(“-”表示不被通知的人员)及时升级通知相关人员

表五、不同优先级事件通知相关人员时间表

通知系统管理员

通知业务责任人

通知信息中心主任

通知业务部门负责人

5分钟

5分钟

15分钟

15分钟

15分钟

15分钟

30分钟

30分钟

1小时

1小时

1天

1天

1天

1天

附件3:

 

《宿迁市烟草专卖局(公司)系统

信息系统运行维护管理办法(试行)》

问题管理细则

宿迁市烟草专卖局(公司)

2015年3月

第一章 总则

第一条 为加强宿迁市烟草专卖局(公司)系统信息系统运行维护工作,确保发现的系统故障或潜在故障能够快速解决后,找出故障产生的根本原因,彻底解决问题,并对事件记录做趋势性分析,提供主动预防性措施,根据相关规章制度及标准制订本管理细则。

第二条 本管理细则适用于市局(公司)及各县(区)局(分公司),主要针对生产运行中发生的问题进行有效管理。包括信息中心所维护的所有应用系统和相关基础架构,如机房环境与设施、系统软硬件、网络通信、应用系统等生产运行问题。

第二章 术语

第三条 服务台是组织中特定的部门、小组或个人完成的一项职能,它为用户提供了问题受理的单点接入功能。服务台将受理的问题提交至问题经理或分派给相关的问题分析专家,并跟踪问题处理的过程。

第四条 合作单位是与信息中心签有服务合同的公司,合作单位需指定具体的人员对信息中心的软、硬件进行维护。

第五条 紧急事件触发问题指紧急事件恢复服务后关联提出的问题,以便进行紧急事件的根本原因分析,为了分析为什么会发生该紧急事件,以及查看其他是否也存在类似的问题,此时可以提出一个问题记录,以便对该紧急事件进行分析。

第六条 维护中提出问题是运维人员在维护系统、硬件等其他设备、服务时,发现一个或多个事故,从而提出问题,以找出根本原因。

第七条 趋势分析问题是通过业务发展情况、设备运行情况等对导致或可能导致出现故障的情况进行分析,通过该趋势分析,判断问题发生原因,从而找到问题原因并解决问题。

第八条 第三方厂商提出问题是由第三方厂商产品升级更新等对业务、服务产生影响。对此类问题提出有效的解决方案或优化方案。

第九条 问题分类是按照业务和技术两个维度对问题进行分类,便于对问题发生情况进行分析和统计。市局(公司)采用由省局(公司)经济信息中心进行统一维护和下发的问题分类标准。

第十条 影响度指就所影响的用户或业务数量而言,问题偏离正常服务级别的程度。

第十一条 紧急度指解决问题时,对业务来说可接受的耽搁时间。

第十二条 优先级是基于紧急度和影响度确定的问题处理优先顺序。所有问题都将分配到四个优先级中的一个,对于具有同样优先级的问题,可按解决它们需花费的精力的多少来安排顺序。

第三章 职责

第十三条 问题管理的相关角色包括:流程负责人、问题经理、问题分析专家、问题创建人。

第十四条 流程负责人是问题管理流程执行情况和执行效率的责任人,主要负责问题管理流程的制订与推动,主要职责包括:

(一) 制订问题管理制度和流程;

(二) 根据管理目标改进和修订问题管理制度和流程;

(三) 监控和评估问题管理流程执行的效果和效率;

(四) 向管理层汇报问题管理流程的执行情况。

第十五条 问题经理是问题管理流程执行过程中的监控人和协调人,负责在问题解决过程中的资源的协调和监控,主要职责包括:

(一)按问题管理规定控制问题管理流程;

(二)传达问题管理流程新政策;

(三)确保问题处理过程中资源得到有效协调;

(四)解决流程执行的异常状况;

(五)对问题处理结果进行审核和评价;

(六)分析和回顾问题管理流程,提出流程改进意见和建议。

第十六条 问题分析专家是相关系统的支持人员或是相关问题领域的专家,负责找出问题原因并提出解决方案,主要职责包括:

(一)负责对分发来的问题进行处理;

(二)分析和诊断问题,确定根本原因;

(三)确定和测试问题的解决方案;

(四)提交变更请求并监控变更实施;

(五)协助运维工程师进行重大或紧急事件的处理;

(六)必要时,协调厂商或省、市局(公司)资源诊断和解决问题。

第十七条 问题创建人负责主动发现并创建的问题,并对问题进行分类、分级以及提交至问题经理进行审核,主要职责包括:

(一) 定期对事件记录进行分析,发现潜在问题;

(二) 提交问题到问题经理审核。

第四章 活动

第十八条 各单位问题管理的主要活动包括:问题识别与记录、问题审核与分派、问题分析与调查、问题解决、问题回顾、问题评价与关闭。

第十九条 问题识别与记录指服务台记录所有用户提出的问题,服务台可对外提供(但并不限于)电话、电子邮件、网站等方式,便于用户沟通。主要活动包括:

(一)服务台对来自用户和系统产生的问题进行详细记录;

(二)可以主动的从紧急事件、趋势分析中提出记录问题并记录相关信息;

(三)根据问题内容,判断问题分类;

(四)紧急重大问题立即联系问题经理,上报问题情况。

第二十条 问题审核与分派指服务台将记录的问题工单提交至问题经理,由问题经理进行问题的审核与分派。主要内容包括:

(一)服务台将问题提交至问题经理处;

(二)问题经理对问题进行内容等信息的审核;

(三)根据问题内容将问题分派给相应的问题专家处理;

(四)跟踪问题处理情况。

第二十一条 问题分析与诊断是指问题分析专家在接受问题分派后负责查找问题根本原因和解决方案。主要内容包括:

(一) 根据问题记录的描述以及服务台对紧急、重大问题的初步判断最终确定问题优先级,如优先级为高和极高的问题须立即通知信息中心相关人员;

(二) 经过一段时间分析,问题分析专家预见或判断目前是否能确定问题的根本原因;

(三) 指定时限内不能解决的问题,应及时通告问题经理,由问题经理负责协调资源做进一步处理;

(四) 分析问题的原因列表,找出最有可能的原因并测试,从而确定问题的根本原因。

第二十二条 问题解决是指问题分析专家负责实施查找到的解决方案以解决问题。主要内容包括:

(一) 对于需要通过变更解决的问题提出变更申请,通过变更流程实施解决方案;

(二) 问题解决后,提供问题的正确状态、进展和历史信息;

(三) 将典型的解决方案作为知识提交到知识库;

(四) 针对故障申告,必须记录服务恢复时间。

第二十三条 问题回顾是指问题分析专家根据问题的描述、优先级以及具体的解决方案等内容,对问题的改正效果进行监控,以确保问题被正确的解决:

(一) 判断已实施解决方案的问题是否得到解决;

(二) 判断已实施解决方案的问题优先级是否为关键;

(三) 编写关键问题报告,包括:问题描述、原因分析、解决方案、经验总结等;

(四) 分发关键问题报告给相关人员。

第二十四条 问题总结与关闭是指问题经理通过对问题处理过程及情况进行评价。主要内容包括:

(一) 检查问题信息项的填写情况;

(二) 根据问题处理情况填写服务评价;

(三) 选择相应的结束代码,更新问题状态为“结束并关闭”,并选择合适的问题结束代码;

(四) 如需要,通报事件经理相关问题的处理结果。

第五章 规则

第二十五条 总体规则:

(一) 信息中心所支持的系统和网络环境中,所有紧急事件、维护中遇到的问题、趋势分析得出的可能存在的问题、第三方厂商提出的问题,都需通过流程中定义的规范和规则进行管理;

(二) 所有参与问题的人员须遵守统一的问题管理流程,不应有任何例外;

(三) 所有运维工程师须优先处理优先级为“极高”和“高”的问题;

(四) 应该定期产生和回顾问题管理报表;

(五) 应该举行定期的问题管理会议对这些问题进行评估;

(六) 应定期对流程进行回顾,以改进问题管理流程。

第二十六条 责任人规则:

(一) 当问题单创建后,由问题经理负责对问题的整个处理过程进行跟踪和监督;

(二) 当问题单被分派后,由被分派方(指定的问题分析专家)负责该问题处理;

(三) 问题处理过程中,如果需要向用户通知处理情况,由问题单的当前处理人负责。

第二十七条 创建规则:

(一) 服务台和运维工程师在运维工作中均可以创建问题单;

(二) 所有紧急事件都须创建类型为“紧急事件触发”的问题单;

(三) 服务台以及运维人员在工作中,根据趋势分析了解到的可能发生的问题,都须创建类型为“趋势分析”的问题单;

(四) 服务台以及运维人员了解到第三方厂商由于更新或存在问题,而可能引发对业务、系统等的问题时,都须创建类型为“第三方厂商”的问题单;

(五) 运维人员在日常运维过程中发现问题,须创建类型为“维护中提出”的问题单;

(六) 同一故障在一段时间内反复发生了多次,必须产生问题;

(七) 运维人员在事件管理处理过程中,找不到恢复服务方法时,须发起问题管理流程;

(八) 服务台在关闭事件时,对于处理结果是“处理失败”和“部分成功”的事件须发起问题管理流程;

(九) 问题登记时,如果问题是根据事件产生,为便于根源诊断和解决,应将以前相关的事件与问题关联。

第二十八条 分派规则:

(一) 问题单由问题经理统一分派;

(二) 问题分析专家不能退回和转派问题经理分派给自己的工单;

(三) 问题分析专家在工单处理过程中,由于某些原因不能继续对工单进行处理时。问题经理可以将工单转派给其他专家处理。

第二十九条 重复问题处理规则:

(一) 短时间内不同用户报告的相同故障现象的问题,可以认为是重复问题。可以将重复问题关联在一个主问题上,主问题被解决时,所有的重复问题都被解决;

(二) 重复的问题应该被标识,不计入问题流程的关键衡量指标;

(三) 服务台如可以判断到重复问题,则由服务台对重复问题标识,否则由问题经理负责重复问题的处理。

第三十条 问题关闭与回顾规则:

(一) 问题解决后由问题经理统一关闭。关闭前需要对问题处理过程和结果进行评价;

(二) 已关闭的问题单不允许重开。如果问题重复发生,则创建一个新的问题单;

(三) 具有借鉴意义的问题在关闭时必须整理经验,提交知识库。实现解决方案共享。

第六章 附则

第三十一条 本管理细则由市局(公司)信息中心负责解释。

第三十二条 本管理细则从印发之日起施行。

第三十三条 相关问题业务策略见附则:

(一) 附则一《问题优先级定义》

附则一、问题优先级定义

问题的优先级表明了该问题的处理优先顺序,所有问题都将分配到四个优先级中的一个。优先级从 1 (极高) 到 4 (低) 。

表三是宿迁市烟草专卖局(公司)制订的优先级判断原则,问题优先级从问题的影响程度(表一)和问题紧急程度(表二)两个维度来确定。问题优先级可分为四级:极高、高、中、低。

表一、问题影响程度定义表

描述

分数

企业外网

25

18

10

8

5

500+

25

15

8

3

一级

25

15

5

全部应用

25

15

10

3

60-100

40-59

20-39

0-19

表二、问题紧急程度定义表

紧急度

极高

表三、问题优先级定义表

影响程度

极高

极高

极高

极高

附件4:

 

《宿迁市烟草专卖局(公司)系统

信息系统运行维护管理办法(试行)》

变更管理细则

宿迁市烟草专卖局(公司)

2015年3月

第一章 总则

第一条 为加强宿迁市烟草专卖局(公司)系统IT运行维护工作,规范所有对IT系统生产环境的变更,从而保证由变更引起的对生产环境的影响降到最小,提高IT系统及服务的质量,为业务的快速发展提供更优质的信息技术服务,减少或消除由于变更实施准备不当等原因出现的对IT环境的破坏作用,根据相关规章制度及标准制订本管理细则。

第二条 本管理细则适用于市局(公司)及各县(区)局(分公司), 主要针对生产运行中发生的变更进行有效管理。包括信息中心所维护的所有应用系统和相关基础架构,如机房环境与设施、系统软硬件、网络通信、应用系统等生产运行变更。

第二章 术语

第三条 服务台是组织中特定的部门、小组或个人完成的一项职能,它为用户提供了变更受理的接入功能。服务台将受理的变更提交至变更经理或分派给相关的变更管理员,并跟踪变更处理的过程。

第四条 合作单位是与信息中心签有服务合同的公司,合作单位需指定具体的人员对信息中心的软、硬件进行维护。

第五条 一般变更是指金额在2000元以下,变更影响程度为低的变更。这类变更运维工程师可以直接实施,一般变更的特点是变更管理员即可以安排变更实施而不需要变更经理批准。

第六条 重大变更是指金额在规定金额以上,或变更影响程度为中及中以上的变更,重大变更需要运维工程师先评估计划,提交领导审批通过后才能实施。

第七条 紧急变更是指如果不执行,会立即或正在严重影响业务运行或带来重大影响的变更,应得到尽可能快速的处理,紧急变更通常先在线下获得授权后,开始实施,变更完成后需要变更补单,补批。

第八条 变更分类指按照业务和技术两个维度对变更进行分类,便于对变更发生情况进行分析和统计。市局(公司)采用由省局(公司)经济信息中心进行统一维护和下发的变更分类标准。

第九条 影响度指就所影响的用户或业务数量而言,变更偏离正常服务级别的程度。

第十条 紧急度,紧急度指进行变更时,对用户或业务来说可接受的耽搁时间。

第十一条 优先级,基于紧急度和影响度确定的变更处理优先顺序。所有变更都将分配到四个优先级中的一个,对于具有同样优先级的变更,可按解决它们需花费的精力的多少来安排顺序。

第三章 职责

第十二条 各单位变更管理的相关角色包括:流程负责人、变更经理、变更管理员、服务台。

第十三条 流程负责人是变更管理流程执行情况和执行效率的责任人,主要负责变更管理流程的制订与推动,主要职责包括:

(一) 制订变更管理制度和流程;

(二) 根据管理目标改进和修订变更管理制度和流程;

(三) 监控和评估变更管理流程执行的效果和效率;

(四) 向管理层汇报变更管理流程的执行情况。

第十四条 变更经理是变更管理流程执行过程中的监控人和协调人,变更经理全面负责变更管理流程所有具体活动执行,保障所有变更依照预定流程顺利执行,主要职责包括:

(一) 全面负责变更管理流程中的所有具体活动执行,保障所有变更依照预定流程顺利执行,通常由具有决策权的人员担任;

(二) 确保具体的变更活动得以有效、正确的执行;

(三) 确保变更请求得到有效评估,授权和实施;

(四) 帮助变更管理员协调必要的变更时间、人员等方面的协调工作;

(五) 审批变更请求,确保只有授权和必要的变更才被实行,并使该种变更影响最小化;

(六) 定期召开变更会议,回顾变更;

(七) 参与流程评估,对流程改进提出意见和建议,与流程负责人共同制订流程改进建议。

第十五条 变更管理员通常由与变更请求内容相关的具体技术领域负责人担任,主要职责包括:

(一) 检查由变更创建人提交的变更请求,检查变更的正确性和必要性,必要时拒绝无关、无法实施或没有必要的变更请求;

(二) 检查变更请求的分类、变更时间要求、分析风险等;

(三) 作为具体变更的责任人,负责领导变更的构建、测试、实施和参与回顾;

(四) 负责收集与该变更有关的部门或小组的意见,综合变更对应用的影响;

(五) 制订变更实施计划、测试计划、回退计划等;

(六) 确保变更在预定的时间、资源和成本内完成;

(七) 必要时确保回退计划得以正确实施;

(八) 变更完成后,进行监控,并记录监控结果。

第十六条 服务台负责记录用户提交的变更,并对变更进行分类、分级以及提交至变更经理进行审核,跟踪变更的解决过程,主要职责包括:

(一) 必要时提出变更申请,创建变更单;

(二) 填写变更内容,描述变更需求;

(三) 为变更分类、初步确定变更的风险等;

(四) 填写变更完成的时间要求;

(五) 在变更处理过程中提供必要的信息。

第四章 活动

第十七条 各单位变更管理的主要活动包括:创建变更、变更分类及计划、变更审批、变更实施及监控、变更回顾、变更评价与关闭。

第十八条 创建变更指服务台记录所有用户提出的变更,服务台可对外提供(但并不限于)电话、电子邮件、网站等方式,便于用户沟通。或由其他变更创建人维护或自发的提出变更,主要活动包括:

(一) 变更创建人根据来自维护自发或其他IT人员提出的、或事件、问题、配置管理流程提出的变更需求,收集信息,跟相关部门或用户确认;

(二) 创建变更请求记录;

(三) 初步为变更分配类型、风险等级等;

(四) 保证变更信息项的完整性和正确性。

第十九条 变更审核分类及计划指服务台将记录的变更工单提交至变更管理员,由变更管理员进行变更信息的补充完善。主要内容包括:

(一) 变更管理员负责对变更创建人提交的变更请求记录进行检查,如有必要则协助变更创建人对变更请求记录相关信息进行完善或更正,以确保变更请求记录的正确性和完整性;

(二) 查询配置管理数据库,确认变更关联到的各配置项信息;

(三) 初步评估变更的类型、风险等,提出可能会影响哪些业务系统和部门,以供变更经理决策参考;

(四) 变更管理员生成变更通告以备提前通知相关部门;

(五) 变更管理员具体负责制订变更计划,包括实施计划、测试计划、回退计划、配置项更新计划等;实施计划、测试计划、回退计划要求可操作性强,应有详细的操作步骤,包括命令、实施变更步骤的具体时间、操作执行人、核查人以及实施变更后观察期内的监控人员等信息;配置项更新计划包括配置项属性和关系的更新等内容;

(六) 判断是否为一般变更,如是一般变更则进行变更实施与监控;

(七) 判断是否为紧急变更,如是紧急变更,则转紧急变更子流程处理,由变更经理处理;

(八) 当接受变更申请后,判断变更非紧急变更、一般变更,则统一归类为重大变更,转至变更经理审批。

第二十条 变更审批是指变更经理在接受变更提交审批后负责变更的信息审核以及必要性的审核。主要内容包括:

(一) 变更经理审核变更方案和计划是否完善,如不完善退回给管理员重新进行计划;

(二) 变更经理视风险等级情况判断是否召开会议讨论变更方案和计划;

(三) 如变更经理判断不需召开会议讨论,则需要进一步判断是否批准变更;

(四) 变更经理如果审批通过,变更进行实施阶段,如果不同意,变更进入评价关闭阶段。

第二十一条 变更实施及监控是指变更管理员负责实施变更以及对变更后影响程度、是否变更成功等进行有效监控。主要内容包括:

(一) 完成应用系统上线前的最后准备;

(二) 变更管理员负责监控、实施整个变更实施过程;

(三) 变更管理员判断是否能够按时完成变更,如不能按时完成则中断变更实施,执行回退计划并通知变更经理;

(四) 如能够按时完成变更实施则进一步核实变更实施完成情况;

(五) 变更管理员负责监控变更实施后的效果。

第二十二条 变更回顾是指变更管理员根据变更的描述、优先级以及具体的变更方案等内容,对变更的效果进行监控,以确保变更的成功实施。主要内容包括:

(一) 变更管理员负责准备相关变更回顾资料;

(二) 变更管理员判断是否召开变更回顾会议,对于紧急变更、执行了回退计划的变更、变更执行后产生了不良效果的变更等;

(三) 变更管理员负责将回顾结果更新到变更记录中并抄送给所有参会人员;

(四) 如不需要召开变更回顾会议则进行变更的评价关闭。

第二十三条 变更评价关闭是指服务台通过对变更过程及完成情况进行评价。主要内容包括:

(一) 根据问题处理情况填写服务评价;

(二) 根据变更处理结果,选择合适的变更处理结果。

第五章 规则

第二十四条 总体规则:

(一) 所管理的生产和准生产测试环境以及闲置设备中,将采用统一的变更管理流程处理各类变更;

(二) 所有管理的IT资源,均应接受变更管理流程的管理;

(三) 应遵循变更管理流程的政策、操作步骤和操作规程;

(四) 所有涉及技术、流程、操作步骤以及相关信息和文档等可能影响服务能力的变更应遵循变更管理流程;

(五) 应定期产生变更管理报表并进行检查;

(六) 通过变更管理会议对变更活动进行跟踪、沟通和协调;

(七) 应定期进行流程检查,以改进变更管理流程。

第二十五条 责任人规则:

(一) 变更管理员对变更负责,确保该变更的实施达到变更的期望和效果;

(二) 服务台负责在变更处理过程中进行跟踪。

第二十六条 创建规则:

(一) 服务台和运维工程师在运维工作中均可创建变更;

(二) 由用户提出的,对管理范围内的IT资源做变更请求,均发起变更管理流程;

(三) 运维人员在日常运维工作中需要对管理范围内的IT资源做变更请求,均生成变更单;

(四) 运维人员在问题管理处理过程中,需要对IT基础设施进行变更时,必须发起变更管理流程;

(五) 变更创建时应根据变更类型定义,创建不同类型的变更;

(六) 金额在规定金额以下,变更影响程度为低的,创建一般变更;

(七) 金额在规定金额以上,或变更影响程度为中及中以上的,创建重大变更;

(八) 如果不执行,会立即或正在严重影响业务运行或带来重大影响的变更,应得到尽可能快速的处理,这种情况先线下获得授权,实施后再补单、补批。

第二十七条 分派规则:

(一) 变更工单由变更创建人分派;

(二) 运维工程师不能退回和转派分派给自己的工单;

(三) 运维工程师在工单处理过程中,由于某些原因不能继续对工单进行处理时。服务台和变更经理可以将工单转派给其他工程师处理。

第二十八条 变更回退规则:

(一) 当变更实施失败或者无法在规定的时间内完成,则需要进行回退。变更回退是为了满足所承诺的服务水平;

(二) 回退的变更将作为失败而关闭,而部分回退的变更将作为部分成功而关闭。在下一次实施前,变更创建人必须重新提交新的变更请求单,以便重新进行审批。

第二十九条 变更关闭规则:

(一) 变更完成后,由服务台统一关闭;

(二) 变更提交后,由于某些客观原因不需要对已提交变更进行处理,并且变更还未被设置为已完成或已关闭状态,服务台可撤销变更单,关闭;

(三) 撤销变更单时,必须记录变更撤销原因;

(四) 变更被撤销后,应通过短信、邮件的方式通知变更当前处理人。

第六章 附则

第三十条 本管理细则由市局(公司)信息中心负责解释。

第三十一条 本管理细则从印发之日起施行。

第三十二条 相关变更业务策略见附则:

(一) 附则一《变更优先级定义》

(二) 附则二《变更风险定义》

附则一、变更优先级定义

变更的优先级表明了该变更的处理优先顺序,所有变更都将分配到四个优先级中的一个。优先级从 1 (极高) 到 4 (低) 。

表三是宿迁市烟草专卖局(公司)制订的优先级判断原则,变更优先级从变更的影响程度(表一)和变更紧急程度(表二)两个维度来确定。变更优先级可分为四级:极高、高、中、低。

表一、变更影响程度定义表

描述

分数

企业外网

25

18

10

8

5

500+

25

15

8

3

一级

25

15

5

全部应用

25

15

10

3

60-100

40-59

20-39

0-19

表二、变更紧急程度定义表

紧急度

极高

表三、变更优先级定义表

影响程度

极高

极高

极高

极高

附则二、变更风险定义

变更的风险等级表明了实施该变更的风险等级,所有变更都将分配到四个风险等级中的一个。优先级从 1 (重大) 到 4 (低) 。

表四.变更风险等级定义表

风险等级

描述

重大

1、在关键方面存在很多不确定因素

2、变更一旦失败无法恢复到原有状态

3、变更涉及到的应用系统或服务被整个公司所使用

1、有较多不确定因素

2、没有经过测试的恢复方案,不能保证变更失败后可以完全回复到原有状态

3、变更涉及到的应用系统或服务被某一部门所使用

4、变更实施时间:业务中断超过2小时

5、变更回退时间:回退时间超过2小时

1、有少数不确定因素

2、有经过测试的恢复方案,可以保证变更失败后可以部分回复到原有状态

3、变更涉及到的应用系统或服务被某一部门所使用

4、变更实施时间:业务中断1-2小时

5、变更回退时间:回退时间1-2小时

1、几乎没有不确定因素

2、有经过测试的恢复方案,可以保证变更失败后可以完全回复到原有状态

3、变更涉及到的应用系统或服务仅被小组或个人所使用

4、变更实施时间:业务中断不到1小时

5、变更回退时间:回退时间1小时或更短

附件5:

 

《宿迁市烟草专卖局(公司)系统

信息系统运行维护管理办法(试行)》

配置管理细则

宿迁市烟草专卖局(公司)

2015年3月

第一章 总则

第一条 为加强宿迁市烟草专卖局(公司)系统IT运行维护工作,规范应用系统和相关基础架构的配置管理流程,建立并完善配置管理库,保证配置管理数据准确性,降低配置管理成本,根据相关规章制度及标准制订本管理细则。

第二条 本管理细则适用于市局(公司)及各县局(公司),主要针对生产运行中的配置项进行有效管理。配置项包括信息中心所维护的所有应用系统和相关基础架构,如机房环境与设施、系统软硬件、网络通信、应用系统等的配置项。

第二章 术语

第三条 配置项是构成IT架构的组件,如:硬件、软件、文档、流程。

第四条 配置项关系是指两个配置项以什么样的形式组合,提供IT服务。例如:软件运行与硬件、硬件与硬件连接、文档与硬件关联。

第五条 配置管理数据库是记录基础架构中配置项信息及配置相关的数据库。

第六条 配置管理员负责配置管理数据的一致性和准确性,确保为其他操作管理提供的数据是准确的。

第三章 职责

第七条 配置管理的相关角色包括:配置管理员、配置经理、配置管理流程负责人。

第八条 配置管理员的职责:

(一) 按照资产配置模型,创建配置管理数据库;

(二) 负责配置项数据、配置项之间关系数据的可用性和更新;

(三) 定期审核配置数据,并对审核发现的差异进行修正,确保配置数据与真实IT环境的一致性;

(四) 当问题解决过程中需要配置信息时,负责提供配置管理数据;

(五) 当某个项目需要配置管理信息时,作为项目的技术资源提供帮助;

(六) 当问题升级/解决、项目开发、服务支持回顾会议等活动需要配置数据时,负责参与和协助;

(七) 提供改进流程的建议。

第九条 配置经理的职责:

(一) 收集分析配置管理的信息、标准、步骤、使用的工具和技术的需求;

(二) 监控配置管理流程的有效性和效率,提出改进流程的建议;

(三) 当配置管理的内容作为某个项目的重要组成部分时,作为协调者参与整理项目需求;

(四) 负责确保配置管理流程的日常顺利运行。

第十条 配置管理流程负责人的职责:

(一) 发布衡量标准和目标,以提高流程的有效性和效率;

(二) 控制并领导流程改进活动;

(三) 批准或拒绝违背流程的事例;

(四) 审核、抽查配置管理流程的执行情况;

(五) 对整个流程的执行情况和结果负责。

第四章 活动

第十一条 各单位配置管理的主要活动包括:配置建模、配置维护、配置审核。

第十二条 配置建模指在运维管理系统中定义配置项分类、配置项属性以及配置项之间关系以及配置数据初始化。主要活动包括:

(一) 配置管理员依据资产配置数据库模型,在运维管理系统中定义配置项分类、配置项属性及配置项之间关系;

(二) 根据配置数据库模型收集配置项信息、配置项关系信息;

(三) 在配置管理数据库中对将配置项信息、配置项关系数据进行初始化。

第十三条 配置维护指在IT运维过程中对配置管理数据库和配置项信息进行维护,配置维护工作应由变更请求产生,所有配置变更过程须受变更管理流程控制。主要活动包括:

(一) 配置管理员对配置变化情况进行确认;

(二) 配置管理员对产生变更的配置项进行维护,并更新配置管理库中配置项的属性信息;

(三) 配置管理员对配置项的关联关系进行记录及更新。

第十四条 配置审核指配置管理员对配置数据进行审验,确保配置管理数据库中的配置数据能真实反映IT环境中配置项的存在和变更情况。主要活动包括:

(一) 配置经理安排配置审核计划,规定配置审核范围、审核时间,审核时间可分为周期审核与突发审核两类;

(二) 配置管理员根据审核计划及时对待审核的配置项进行审核,检查配置项信息是否正确、完整;

(三) 配置管理员对存在差异的配置信息进行修正;

(四) 对未能及时进行审核的配置项,配置管理员应及时通知配置经理。

第五章 规则

第十五条 总体规则:

(一) 配置管理数据库将为所有IT运行及服务管理流程提供所需信息,特别是针对事件和变更管理流程;

(二) 所有事件、问题、变更流程触发后,均需要判断是否涉及到配置项信息的变化,如果涉及,则需要根据配置管理流程维护其信息和配置管理数据库信息的一致性;

(三) 所有配置项信息必须存储在一个数据库管理系统中;

(四)  配置管理数据库准确反应当前已知的IT架构状态;

(五) 每半年对流程进行回顾,回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性,以改进配置管理流程。

第十六条 流程关联规则:

(一) 若与变更管理关联,变更管理员在制订变更计划阶段必须制订配置项更新计划,对计划修改的配置项进行说明;

(二) 变更实施完后,由变更管理员汇总相应的配置项修改的情况,并通知相应的配置管理员,配置管理员接收到配置项修改请求后,与配置项实体进行核对,核对无误后方可修改配置项属性及关系;若与事件管理、问题管理关联,配置项应与事件记录、问题记录建立关联,从而确保对配置项维护工作的统计和分析。

第十七条 配置维护规则:

(一) 所有有关生产环境配置项的更改都需要通过变更管理流程进行控制;

(二) 只有得到授权的人员(配置管理员)才能对配置管理数据库中的配置项信息进行修改,修改之前需要对物理配置项的属性进行核实;

(三) 任何设备进机房前或系统投入使用前必须启动配置管理流程,以确保配置项信息与物理环境的一致;

(四) 其它流程会引发对配置项的修改,例如日常使用中发现不正确的配置项信息需要相应的修改、配置管理数据库审核引发的对配置项的修改等,均需要通过变更管理流程的控制,发起配置项修改需求的人将作为变更请求者,通过变更管理流程进行相应的审批,实现对配置项信息的修改控制(在变更结束阶段,通知相关的配置管理员修改配置项);

(五) 在配置管理数据库建设的初期,由于数据仍然处于调整中,可以由配置经理定义一个时间段,该时间段内的数据调整可以不经过变更管理流程控制;

(六) 当确认配置项信息不需要在配置管理数据库中保留时,进行配置项的删除,配置项的删除不在配置管理数据库中进行物理删除,通过删除状态属性来标识其被删除与否。

第十八条 配置审核规则:

(一) 配置管理流程必须每半年对IT环境进行审核、跟踪监测,以保证配置管理数据库的信息收集准确、完整,并与实际IT环境的状态高度统一,该工作由配置管理员负责;

(二) 应定期根据变更的执行情况对变更引发的配置项的修改情况进行审核。

第六章 附则

第十九条 本管理细则由市局(公司)信息中心负责解释。

第二十条 本管理细则从印发之日起施行。

宿迁市烟草专卖局(公司)系统信息系统运行维护管理办法(试行)相关推荐

  1. 无需深厚技术背景,也可以做好系统和应用维护管理

    版权声明:原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 .作者信息和本声明.否则将追究法律责任.http://lauef.blog.51cto.com/413888/165636 做 ...

  2. 智慧灯杆运行维护要求

    要保障智慧路灯杆系统的长久稳定运行,同样需要对智慧杆进行周期性的巡检维护,包括对杆载设备硬件的完好性与稳定性检查,以及对智慧杆运营管理系统的功能升级和漏洞修复,以保障智慧杆整体系统能得到持续拓展提高. ...

  3. 计算机系统上线保障计划,系统运维信息系统运行保障方案计划新.docx

    系统运维信息系统运行保障方案计划新 信息系统运行保障方案 统一服务台建设 提供统一报障电话,统一报障.统一维修接口,XX企业可以通过统一的报障电话申请服务.查询服务处理进程,跟踪处理进度,确保服务时效 ...

  4. java计算机毕业设计南京市某物流公司管理信息系统源代码+数据库+系统+lw文档

    java计算机毕业设计南京市某物流公司管理信息系统源代码+数据库+系统+lw文档 java计算机毕业设计南京市某物流公司管理信息系统源代码+数据库+系统+lw文档 本源码技术栈: 项目架构:B/S架构 ...

  5. linux系统在pe下查看ip地址,pe下查看原系统ip的方法_网站服务器运行维护

    linux查看php环境是否安装_网站服务器运行维护 linux查看php环境是否安装的方法:1.执行[find / -name php.ini]命令,查看系统是否有php的配置文件:2.执行[net ...

  6. 网站服务器系统组成,linux系统由哪几部分组成_网站服务器运行维护,linux

    笔记本如何禁用自带键盘_网站服务器运行维护 笔记本禁用自带键盘的方法:1.首先右键点击[计算机],选择[属性]:2.然后打开[设备管理器],右键点击[PS/2标准键盘],选择[更新驱动程序软件]:3. ...

  7. 电脑服务器显示过期,win10系统提示你的设备存在过期风险怎么办_网站服务器运行维护,win10...

    win7系统安装后无网络适配器怎么办_网站服务器运行维护 win7系统安装后无网络适配器的解决方法是:1.打开控制面板,进入[设备管理器]:2.右键点击异常的驱动程序,选择[更新驱动程序]:3.选择[ ...

  8. 服务器可以装win7或win10系统吗,win10改win7用legacy还是uefi?_网站服务器运行维护,window...

    win7系统关机一直转圈(关不了机)是什么原因?_网站服务器运行维护 win7系统关机一直转圈的原因:1.病毒或一些应用程序或者系统任务有可能造成不能关机或关机慢:2.外设和驱动程序兼容性不好,不能响 ...

  9. 服务器2016系统装完卡logo进不去,win10系统开机卡在logo画面_网站服务器运行维护...

    win10系统开机时间很长_网站服务器运行维护 解决win10系统开机时间很长问题的方法:1.首先打开运行窗口,输入[msconfig],打开系统配置:2.然后在[常规]选项下,勾选[加载系统服务]与 ...

最新文章

  1. C++中rdbuf()简介及文件流的概念
  2. Linux_Bash常用脚本
  3. strtus2改成springboot_jdk1.6环境下struts2改spring boot方案
  4. 剑指OFFER之二维数组中的查找(九度OJ1384)
  5. 速看 | 电子元器件如何确定好坏?
  6. python中定义数据结构_Python中的数据结构—简介
  7. Extracting Text From Image
  8. 都是山寨惹的祸 最邪恶安卓恶意程序肆虐网络
  9. html滚动轮播图片代码,html 无缝轮播图完整代码
  10. 汇报措辞:你懂得如何向领导汇报吗(审阅、审批、审阅、批示、查阅)?
  11. 时下常用有效的rss源
  12. 基于Vue的数据埋点统计
  13. 【图像修复】基于matlab损坏图像修复【含Matlab源码 731期】
  14. 李彦宏创业语录中我喜欢的几句
  15. 如何注册成为腾讯QQ互联个人开发者
  16. 到底什么是国土空间规划?
  17. 淘宝API获取——商品详情信息、DESC信息、主图
  18. java计算机毕业设计实验室耗材管理系统源程序+mysql+系统+lw文档+远程调试
  19. 【新手入门.考试高频】Java中“一个类声明的两个对象如果有相同的引用,二者就有相同的变量”的理解
  20. localStorage使用实例-进入显示广告,点击关闭之后,刷新网页不再出现

热门文章

  1. dedecms 找后台总结_总结找到后台路径的N总思路方法
  2. # 定义四边形_对特殊平行四边形核心梳理,拓展提升思维
  3. 超详细简单解决git的上传和下载
  4. 编写python程序、输出*图形_Python用程序输出字母“C”的图案
  5. eclipse php 代码风格,关于更改Zend Studio/Eclipse代码风格主题的介绍
  6. oracle建表语句string,编程式Mybatis获取oracle表创建表语句
  7. 购物网站php模版,运动服装购物网站模板
  8. python3 ascii转utf8_ASCII、Unicode、UTF-8以及Python3编码问题
  9. qt qlabel 布局重叠_Pyqt5布局管理实例
  10. C语言之extern关键字探究