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集中交易系统业务、技术运维精细度

[td]

工作维度	精细度	工作内容
技术运维	深度运维	负责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

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集中交易系统业务、技术运维精细度

[td]

工作维度	精细度	工作内容
技术运维	深度运维	负责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