monicazhang 发表于 2015-11-6 11:26:14

ITSS运维管理体系现状评估和关键发现

本帖最后由monicazhang于2015-11-611:26编辑

20151106淡然续上




3运维服务管理体系现状评估3.1运维模式3.1.1现状描述ITSS考试根据某公司《运营管理体系及相关流程访谈纪要》可以看出,随着业务流程与IT运维的相互融合,业务系统的集约化程度不断提高,其运维模式具有以下特点:1)“一线式”业务系统运维:传统的IT服务管理通常设置“服务台”作为一线的单一联系点,处理常发生、易解决的服务请求或事件,一线无法处理的故障通过技术升级到二/三线解决。而某公司此次调研的34个业务系统,其服务请求(如:系统升级等)通过ITSM系统转派到二线处理,或发生故障后直接电话给相关业务系统管理员,或通过监控平台报告给业务系统管理员直接处理,服务台除转派服务请求外,不参与相关事件处理过程。同时,作为业务系统管理员支撑资源的开发团队、厂商团队,在ITSM系统中没有角色账号,参与流程过程无强制记录。

图3.1某公司“一线式”业务系统运维可见,业务系统管理员作为“单一线条”贯穿了业务系统故障或升级请求的完整服务周期,不存在服务台预先处理、错误分发等情况,但也造成根据忙闲情况,主观选择“故障紧急度”,事后补单等现象广为发生。2)IT-业务运维融合根据某公司IT运维服务目录可知,除网络、安全和云服务外,中信证券的业务系统运维或多或少的参与到业务流程运维层面,以“集中交易系统”为例,抽取2014年3、4、5、6四个月份共50条服务请求记录,按照业务运维、技术运维标记,占比如下:图3.2集中交易系统业务、技术运维对比ITSS认证其中,业务运维数量28条,占二分之一强,按照运维的精细度划分,均属于深度运维,不仅在技术层面上了解DB、中间件的表结构及相关接口,对业务逻辑也需要非常熟悉,其具体内容如下:

表3‑1集中交易系统业务、技术运维精细度
工作维度
精细度
工作内容

技术运维
深度运维
负责APP参数配置,需要了解DB表结构和字段含义等。

业务运维
深度运维
负责解答业务相关的常见和特殊问题,及初步的故障分析等。

由此可见,随着某公司IT运维的深入开展,与业务流程的融合运维成为趋势,这同时也对系统管理员深入理解业务逻辑提出了更高的要求。
3.1.2关键发现通过对某公司运维模式的总结,不难看出某公司的IT运维工作经过多年的积累和沉淀,形成了适合自身发展的运维模式。通过快速报障到二线业务系统管理员,加快了故障的处理速度,减轻对于业务的影响。同时,集中的处理模式,也存在业务不分轻重缓急,相关责任不明的潜在隐患。关键发现1:服务台无法承担基础的业务流程咨询工作。其中彭玉辉/张永武在访谈风险弱项时提出,“作为B角,由于长时间的接触较少,现对下述自己思考的四个工作范围感觉有些生疏:1、对营业部问题的指导,特别是特殊业务时的指导;2、(略);3、新业务不了解,不熟悉;4、(略)。”如果这些工作当中能够通过FAQ标准化的业务指导交付给服务台实现的话,业务系统管理员就可以更加集中在特殊业务或业务的深层次学习上,优化人员资源配置。关键发现2:运维团队与供应商的责任划分不清。其中张永武提到开发商风险时,包括“开发质量、测试质量、服务保障等。”杨利强还提到“经常有一些认为常识性或开发商承诺的程序处理方式却被推翻。”这些都体现了供应商在协助IT运维时,由于约束不足,导致的协同问题。这些问题当然不可能仅通过将供应商纳入ITSM系统,通过流程运转、处理时限等方式简单解决,但目前ITSM系统中并不记录供应商的处理时间、责任团队及故障原因等信息,也不利于对供应商参与故障解决的事后回顾。ITSS培训



待续http://www.ITILxf.com/thread-52992-1-1.html本帖关键字:ITSS
页: [1]
查看完整版本: ITSS运维管理体系现状评估和关键发现