20150722淡然

续上

2.4服务流程

2.4.1.服务台现状

v服务范围

目前“网管专家服务”服务台向40余家用户提供主动监控和故障处理服务。监控对象主要为CPE设备，包括客户端的路由器和交换机，另外还有少量主机，监控范围涉及大约700个点左右。服务台向用户提供7*24的服务。同时，作为向用户提供支持的单一联系点，服务台已经向用户公布电话，供用户申告、咨询或投诉所需。

v服务台岗位

目前“网管专家服务”服务台共有服务支持工程师8人。分为4个班组，每两天轮换一次，每天两班，每班2人。早班时间为8：30－17：30，晚班时间为17：30－8：30。ITSS考试

v服务台活动

目前服务台支持工程师为一级运维工程师，主要职责是利用nView系统对用户CPE设备及线路进行主动监控；在发生告警后，对故障进行识别和确认；在确认故障后，负责通知到用户；负责在CTS系统中记录故障信息；负责对设备、线路等方面故障进行处理。

服务台与用户的通知和沟通主要以电话为主，邮件，短信为辅，大多通过手工方式完成。服务台人员在向用户提供故障处理支持时分为远程处理和现场处理两种方式。如需现场服务时，由服务台负责协调和调度现场服务人员到用户现场处理故障，并对故障单回收归档以便后期故障分析时用。

v服务台制度

目前有对服务台电话用语、填写故障单以及包括交接班在内的日常工作规范。同时也有相应考核指标对服务台人员的工作进行评判。但目前制度和规范的执行和遵守方面尚不严格。

2.4.2.事件管理流程现状

v流程角色

目前按岗位定义了一级运维工程师、二级运维工程师和三级运维工程师的工作职位。但尚未按照事件管理流程定义一线支持和二线支持的角色。同时，尚未建立针对事件管理流程角色明确的流程职责定义。

v流程活动

目前“网管专家服务”一级运维工程师负责对监控发现故障、用户上报故障和用户其他服务请求进行受理和响应，同时在CTS系统中进行记录。

目前在CTS系统中记录故障时，主要包含以下信息：

n故障发生时间。

n用户名称

n节点名称

n设备信息

n故障发生地点

n故障描述

n故障处理结果

n解决方法

其中，故障发生时间、用户名称、发生故障的节点和故障描述信息是需要在开单时记录的。故障处理结果和解决方法在处理过程中进行填写。

在记录故障时，由一级运维工程师依照故障设备的重要性和故障类型两维共同确定。其中，故障类型反映了故障对业务的影响程度。目前“网管专家服务”的故障优先级划分为P1、P2、P3、P4等四个等级。P1为最高优先级，表示对最终用户的业务有重大影响；P4为最低优先级，表示对最终用户的业务运作基本没有影响。

对于主动发现和被动受理的故障，一级运维工程师将首先通过Ping、Tracert、SNMP读取、LOG和端口流量分析或者远程登录用户端设备等方式对其进行分析和处理。如能基本确认故障为设备导致，则联系用户的设备供应商进行现场处理；如能基本确认故障为线路导致，则申报用户所属级别电信部门对线路进行现场处理。对于无法判断的故障，一级运维工程师会将该故障以口头的形式分派给二级运维工程师作后续分析处理。

“网管专家服务”目前向用户承诺了对故障的响应时间，按故障优先级不同分为15分钟、30分钟、60分钟不等。尚未承诺服务解决时间，但由于用户线路隶属，因此遵照对外承诺的解决时间约定。

如超过对应解决时间，则由一级运维工程师负责升级至运维主管（不再向上升级），目前主要采用手动方式电话、邮件或短信通知。其他情况下尚无升级机制。

对于故障单的关闭，一级运维工程师是没有权限对其进行关闭的，主要考虑到一级工程师的经验不足可能造成客户满意度的降低，所以目前必须由二级运维工程师来关闭，保障服务的满意度。另外，故障单在关闭必须满足以下条件：

（1）已经找到故障的真正原因。

（2）故障得到恢复并且找到合理解决方案。

（3）故障解决后提交给用户且经过确认无误。

v流程制度

目前“网管专家服务”专项组内部已经定义了初步的运维规范，其中对Netcare故障处理工作流程进行概要描述，包括岗位职责定义、工作流程和现场服务调度等方面的内容。但对流程的分派、重开、关联、升级等方面尚缺乏完整明确的定义。

v流程保障

目前“网管专家服务”专项组由二级运维工程师负责对一级运维工程师的故障处理数量和质量进行统计和评价，这些评价名义上与人员绩效考核挂钩，但尚未产生实际效果。同时，服务团队内部尚未针对事件管理流程定义流程层面的KPI指标，并对这些指标进行监控和分析。

2.4.3.问题管理流程现状

v流程角色

目前“网管专家服务”专项组内部没有成文的问题管理流程，因此也没有专人负责这块工作。同时，服务团队对于事件和问题各自的定义和相互之间的区别比较模糊。但在实际服务过程中，事实发生了一些问题管理活动，如故障根本原因的分析以及解决方案的提供等。

目前“网管专家服务”专项组内部没有对问题管理流程中的人员角色和职责进行明确划分，因此没有全职进行问题管理的团队。

v流程活动

目前在对故障处理的过程中，要求一级或二级运维人员对每个故障的根本原因进行分析和诊断，并提供和实施最终解决方案后才能关闭故障单。对于难度较大问题，由资深人员介入处理。

目前对问题的记录和跟踪尚未成文的规范。一般而言重大问题信息会在故障单中有所体现。另一个体现问题信息的地方是针对每个用户提供的月报，月报中会对本月故障进行分类和统计，并对结果进行分析和建议，但这里只能实现问题的识别，问题的处理和解决由用户方完成。

对于NETCARE自身平台的问题管理，目前尚未有明确的规范和执行迹象。

v流程制度

目前有规范要求故障关闭前必须满足（1）已经找到故障的真正原因及（2）故障得到恢复并且找到合理解决方案这两个条件。此外，组织内部尚未建立与问题管理流程相关的制度和规范。

v流程保障

目前“网管专家服务”专项组由二级运维工程师负责对一级运维工程师的故障处理质量进行分析和评价，但尚未产生实际绩效考核效果。服务团队内部尚未针对问题管理流程定义流程层面的KPI指标，并对这些指标进行监控和分析。

2.4.4.变更及发布管理流程现状

v流程角色

没有明确的变更管理流程角色和职责定义，目前相关工作主要由二级运维工程师负责。

v流程活动

目前“网管专家服务”可能涉及几种类型的变更：用户新增监控点、用户切换监控点、用户联系人信息变动、CPE设备搬迁、CPE设备更换或升级、CPE设备参数调整等。其中用户联系人信息变动是最频繁的变更。

目前没有对变更按照标准变更、一般变更、重大变更和紧急变更进行划分，同时对于变更的紧急程度尚未有一个确定的判定标准，主要是根据用户类型和影响范围等方面进行经验性的主观判断。

目前专项组使用“客户信息变更单”对联系人信息变动进行记录和跟踪，其他类型的变更尚无规范的表单或系统进行记录和管理。

对于用户新增监控点等服务开通类型的变更，目前有相应的工作流程进行管理，但该流程主要是针对变更实施过程和发布过程。对于变更实施前对评估、制定方案、审核等工作，目前尚无更明确的文档规范定义。

对于相对简单的变更，如增加IP网段，修改部分设备IP地址等，包含在服务范围之内，运维工程师和专项服务工程师直接填写变更单，内部处理。对于相对复杂的变更，如全网网络结构调整，增加新功能，升级路由器IOS等，不包含在服务范围之内，需要与客户经理协商签订服务合同/变更合同，按照合同/协议流转流程操作。ITSS认证

v流程制度

专项组内部对于开通类型的变更有比较详细的定义，但仅针对变更实施和发布过程。对其他类型的变更仅有非常粗略的说明，尚未建立更加详细且具有指导意义的制度。

v流程保障

目前“网管专家服务”专项组内部尚未针对变更管理流程定义流程层面的KPI指标，并对这些指标进行监控和分析。

2.4.5.配置管理流程现状

v流程角色

没有明确的配置管理流程角色和职责定义，目前相关工作主要由后台运维工程师负责。

v流程活动

“网管专家服务”专项组尚未建立配置管理流程及相应的配置管理数据库（CMDB），总体来说在组织内部对于配置管理的理解还不是很深。目前专项组通过后台系统收集和记录了用户的设备信息，但一方面这些信息尚不全面，另一方面的设备信息相对离散，没有记录设备之间、线路之间的关联关系，对故障分析和诊断缺乏支撑作用。另外，对于IT相关文档，目前由后台运维工程师统一管理。

v流程制度

目前“网管专家服务”专项组内部尚未针对配置管理流程定义相关制度规范。

v流程保障

目前“网管专家服务”专项组内部尚未针对配置管理流程定义流程层面的KPI指标，并对这些指标进行监控和分析。

2.4.6.服务级别管理流程现状

v流程角色

目前“网管专家服务”尚未指定专门人员负责对服务目录的维护，客户需求收集、SLA沟通签署、OLA沟通签署主要由客户经理和前端售前人员负责，SLA的监控、报告和回顾主要由专项服务经理负责。但流程相关角色和职责尚未明确界定和划分。

v流程活动

网管专家服务专项组针对当前提供的服务整理了一个服务目录。该服务目录对现有服务进行了初步分类，包括实时主动式端到端监控、客户网络故障处理、客户网络管理和分析、实时查看、专项会议服务和可选服务6大类。

用户大多知道“网管专家服务”有这样一个服务目录，但不清楚该服务目录内容的含义和背后体现的意义。

服务目录可读性及可理解性不甚理想，目录本身没有清晰的体现客户需求和期望，导致用户很难在服务目录中准确选择自己需要的服务。

服务级别定义过于简单，指标定义和监控尚不规范。没有明确说明或者告知客户服务级别中包含的指标，以及不同服务级别对应指标的区别。另外，服务目录中尚未定义用户所关心的故障响应时间、故障解决时间和CPE设备/线路可用性等影响客户体验的关键指标。

虽然向用户提供了服务级别，但没有与可能影响服务的第三方供应商之间签署对应的OLA或者UC。

目前组织内没有对服务级别协议（SLA）进行回顾和检查的过程。

v流程制度

目前组织内没有定义服务级别管理流程相关的政策制度和工作规范

目前没有机制将服务级别协议与其他流程之间建立关联，规范和提高组织整体的服务支持能力

v流程保障

目前“网管专家服务”专项组内部尚未针对配置管理流程定义流程层面的KPI指标，并对这些指标进行监控和分析。

2.5服务工具

服务工具对于服务管理体系而言，扮演着至关重要的支撑作用。上海某公司“网管专家服务”以“一点接入、全网监控”的方式，7*24小时实时监控客户的端到端网络性能状况和故障情况，主动发现和处理客户网络故障，并及时主动通知客户，定期向客户提供网络运行及优化分析报告。这些服务内容主要基于nView和CTS系统，其中nView为网络设备监控系统，CTS为故障跟踪及管理系统。

日常运行过程中，服务人员主要利用nView系统对用户端的CPE设备进行主动实时的监控。若发现并确认告警，则通知用户并在CTS系统中新建一条记录，对该故障信息进行记录，方便随后对故障的处理和跟踪。在CTS系统中登记后，系统将自动邮件通知设备/线路对应的用户联系人。用户也可自行通过公布的WEB访问方式实时查看自己公司的网络情况和统计报表，或者当前故障处理状态以及历史故障统计报表等信息。ITSS培训

由于目前这套系统是基于网银系统建立的，因此其系统功能的调整和扩展受到网银方面的商务和技术层面协作的影响。对于客户新需求的响应时间较长，且由于License的限制，某些重要功能往往不能及时的更新和改进。从监控角度而言，对主机、中间件、数据库和应用系统的监控将越发重要；从服务管理角度而言，对问题、变更、服务级别、配置等管理流程的支持也是规范和提供服务能力的必要保证。另外，监控及服务管理两方面能友好的向用户提供内容丰富且配置灵活的报表也愈发成为关键的用户体验点。

待续http://www.ITILxf.com/thread-51819-1-1.html

本帖关键字：ITSS

20150722淡然

续上

2.4服务流程

2.4.1.服务台现状

v服务范围

目前“网管专家服务”服务台向40余家用户提供主动监控和故障处理服务。监控对象主要为CPE设备，包括客户端的路由器和交换机，另外还有少量主机，监控范围涉及大约700个点左右。服务台向用户提供7*24的服务。同时，作为向用户提供支持的单一联系点，服务台已经向用户公布电话，供用户申告、咨询或投诉所需。

v服务台岗位

目前“网管专家服务”服务台共有服务支持工程师8人。分为4个班组，每两天轮换一次，每天两班，每班2人。早班时间为8：30－17：30，晚班时间为17：30－8：30。ITSS考试

v服务台活动

目前服务台支持工程师为一级运维工程师，主要职责是利用nView系统对用户CPE设备及线路进行主动监控；在发生告警后，对故障进行识别和确认；在确认故障后，负责通知到用户；负责在CTS系统中记录故障信息；负责对设备、线路等方面故障进行处理。

服务台与用户的通知和沟通主要以电话为主，邮件，短信为辅，大多通过手工方式完成。服务台人员在向用户提供故障处理支持时分为远程处理和现场处理两种方式。如需现场服务时，由服务台负责协调和调度现场服务人员到用户现场处理故障，并对故障单回收归档以便后期故障分析时用。

v服务台制度

目前有对服务台电话用语、填写故障单以及包括交接班在内的日常工作规范。同时也有相应考核指标对服务台人员的工作进行评判。但目前制度和规范的执行和遵守方面尚不严格。

2.4.2.事件管理流程现状

v流程角色

目前按岗位定义了一级运维工程师、二级运维工程师和三级运维工程师的工作职位。但尚未按照事件管理流程定义一线支持和二线支持的角色。同时，尚未建立针对事件管理流程角色明确的流程职责定义。

v流程活动

目前“网管专家服务”一级运维工程师负责对监控发现故障、用户上报故障和用户其他服务请求进行受理和响应，同时在CTS系统中进行记录。

目前在CTS系统中记录故障时，主要包含以下信息：

n故障发生时间。

n用户名称

n节点名称

n设备信息

n故障发生地点

n故障描述

n故障处理结果

n解决方法

其中，故障发生时间、用户名称、发生故障的节点和故障描述信息是需要在开单时记录的。故障处理结果和解决方法在处理过程中进行填写。

在记录故障时，由一级运维工程师依照故障设备的重要性和故障类型两维共同确定。其中，故障类型反映了故障对业务的影响程度。目前“网管专家服务”的故障优先级划分为P1、P2、P3、P4等四个等级。P1为最高优先级，表示对最终用户的业务有重大影响；P4为最低优先级，表示对最终用户的业务运作基本没有影响。

对于主动发现和被动受理的故障，一级运维工程师将首先通过Ping、Tracert、SNMP读取、LOG和端口流量分析或者远程登录用户端设备等方式对其进行分析和处理。如能基本确认故障为设备导致，则联系用户的设备供应商进行现场处理；如能基本确认故障为线路导致，则申报用户所属级别电信部门对线路进行现场处理。对于无法判断的故障，一级运维工程师会将该故障以口头的形式分派给二级运维工程师作后续分析处理。

“网管专家服务”目前向用户承诺了对故障的响应时间，按故障优先级不同分为15分钟、30分钟、60分钟不等。尚未承诺服务解决时间，但由于用户线路隶属，因此遵照对外承诺的解决时间约定。

如超过对应解决时间，则由一级运维工程师负责升级至运维主管（不再向上升级），目前主要采用手动方式电话、邮件或短信通知。其他情况下尚无升级机制。

对于故障单的关闭，一级运维工程师是没有权限对其进行关闭的，主要考虑到一级工程师的经验不足可能造成客户满意度的降低，所以目前必须由二级运维工程师来关闭，保障服务的满意度。另外，故障单在关闭必须满足以下条件：

（1）已经找到故障的真正原因。

（2）故障得到恢复并且找到合理解决方案。

（3）故障解决后提交给用户且经过确认无误。

v流程制度

目前“网管专家服务”专项组内部已经定义了初步的运维规范，其中对Netcare故障处理工作流程进行概要描述，包括岗位职责定义、工作流程和现场服务调度等方面的内容。但对流程的分派、重开、关联、升级等方面尚缺乏完整明确的定义。

v流程保障

目前“网管专家服务”专项组由二级运维工程师负责对一级运维工程师的故障处理数量和质量进行统计和评价，这些评价名义上与人员绩效考核挂钩，但尚未产生实际效果。同时，服务团队内部尚未针对事件管理流程定义流程层面的KPI指标，并对这些指标进行监控和分析。

2.4.3.问题管理流程现状

v流程角色

目前“网管专家服务”专项组内部没有成文的问题管理流程，因此也没有专人负责这块工作。同时，服务团队对于事件和问题各自的定义和相互之间的区别比较模糊。但在实际服务过程中，事实发生了一些问题管理活动，如故障根本原因的分析以及解决方案的提供等。

目前“网管专家服务”专项组内部没有对问题管理流程中的人员角色和职责进行明确划分，因此没有全职进行问题管理的团队。

v流程活动

目前在对故障处理的过程中，要求一级或二级运维人员对每个故障的根本原因进行分析和诊断，并提供和实施最终解决方案后才能关闭故障单。对于难度较大问题，由资深人员介入处理。

目前对问题的记录和跟踪尚未成文的规范。一般而言重大问题信息会在故障单中有所体现。另一个体现问题信息的地方是针对每个用户提供的月报，月报中会对本月故障进行分类和统计，并对结果进行分析和建议，但这里只能实现问题的识别，问题的处理和解决由用户方完成。

对于NETCARE自身平台的问题管理，目前尚未有明确的规范和执行迹象。

v流程制度

目前有规范要求故障关闭前必须满足（1）已经找到故障的真正原因及（2）故障得到恢复并且找到合理解决方案这两个条件。此外，组织内部尚未建立与问题管理流程相关的制度和规范。

v流程保障

目前“网管专家服务”专项组由二级运维工程师负责对一级运维工程师的故障处理质量进行分析和评价，但尚未产生实际绩效考核效果。服务团队内部尚未针对问题管理流程定义流程层面的KPI指标，并对这些指标进行监控和分析。

2.4.4.变更及发布管理流程现状

v流程角色

没有明确的变更管理流程角色和职责定义，目前相关工作主要由二级运维工程师负责。

v流程活动

目前“网管专家服务”可能涉及几种类型的变更：用户新增监控点、用户切换监控点、用户联系人信息变动、CPE设备搬迁、CPE设备更换或升级、CPE设备参数调整等。其中用户联系人信息变动是最频繁的变更。

目前没有对变更按照标准变更、一般变更、重大变更和紧急变更进行划分，同时对于变更的紧急程度尚未有一个确定的判定标准，主要是根据用户类型和影响范围等方面进行经验性的主观判断。

目前专项组使用“客户信息变更单”对联系人信息变动进行记录和跟踪，其他类型的变更尚无规范的表单或系统进行记录和管理。

对于用户新增监控点等服务开通类型的变更，目前有相应的工作流程进行管理，但该流程主要是针对变更实施过程和发布过程。对于变更实施前对评估、制定方案、审核等工作，目前尚无更明确的文档规范定义。

对于相对简单的变更，如增加IP网段，修改部分设备IP地址等，包含在服务范围之内，运维工程师和专项服务工程师直接填写变更单，内部处理。对于相对复杂的变更，如全网网络结构调整，增加新功能，升级路由器IOS等，不包含在服务范围之内，需要与客户经理协商签订服务合同/变更合同，按照合同/协议流转流程操作。ITSS认证

v流程制度

专项组内部对于开通类型的变更有比较详细的定义，但仅针对变更实施和发布过程。对其他类型的变更仅有非常粗略的说明，尚未建立更加详细且具有指导意义的制度。

v流程保障

目前“网管专家服务”专项组内部尚未针对变更管理流程定义流程层面的KPI指标，并对这些指标进行监控和分析。

2.4.5.配置管理流程现状

v流程角色

没有明确的配置管理流程角色和职责定义，目前相关工作主要由后台运维工程师负责。

v流程活动

“网管专家服务”专项组尚未建立配置管理流程及相应的配置管理数据库（CMDB），总体来说在组织内部对于配置管理的理解还不是很深。目前专项组通过后台系统收集和记录了用户的设备信息，但一方面这些信息尚不全面，另一方面的设备信息相对离散，没有记录设备之间、线路之间的关联关系，对故障分析和诊断缺乏支撑作用。另外，对于IT相关文档，目前由后台运维工程师统一管理。

v流程制度

目前“网管专家服务”专项组内部尚未针对配置管理流程定义相关制度规范。

v流程保障

目前“网管专家服务”专项组内部尚未针对配置管理流程定义流程层面的KPI指标，并对这些指标进行监控和分析。

2.4.6.服务级别管理流程现状

v流程角色

目前“网管专家服务”尚未指定专门人员负责对服务目录的维护，客户需求收集、SLA沟通签署、OLA沟通签署主要由客户经理和前端售前人员负责，SLA的监控、报告和回顾主要由专项服务经理负责。但流程相关角色和职责尚未明确界定和划分。

v流程活动

网管专家服务专项组针对当前提供的服务整理了一个服务目录。该服务目录对现有服务进行了初步分类，包括实时主动式端到端监控、客户网络故障处理、客户网络管理和分析、实时查看、专项会议服务和可选服务6大类。

用户大多知道“网管专家服务”有这样一个服务目录，但不清楚该服务目录内容的含义和背后体现的意义。

服务目录可读性及可理解性不甚理想，目录本身没有清晰的体现客户需求和期望，导致用户很难在服务目录中准确选择自己需要的服务。

服务级别定义过于简单，指标定义和监控尚不规范。没有明确说明或者告知客户服务级别中包含的指标，以及不同服务级别对应指标的区别。另外，服务目录中尚未定义用户所关心的故障响应时间、故障解决时间和CPE设备/线路可用性等影响客户体验的关键指标。

虽然向用户提供了服务级别，但没有与可能影响服务的第三方供应商之间签署对应的OLA或者UC。

目前组织内没有对服务级别协议（SLA）进行回顾和检查的过程。

v流程制度

目前组织内没有定义服务级别管理流程相关的政策制度和工作规范

目前没有机制将服务级别协议与其他流程之间建立关联，规范和提高组织整体的服务支持能力

v流程保障

目前“网管专家服务”专项组内部尚未针对配置管理流程定义流程层面的KPI指标，并对这些指标进行监控和分析。

2.5服务工具

服务工具对于服务管理体系而言，扮演着至关重要的支撑作用。上海某公司“网管专家服务”以“一点接入、全网监控”的方式，7*24小时实时监控客户的端到端网络性能状况和故障情况，主动发现和处理客户网络故障，并及时主动通知客户，定期向客户提供网络运行及优化分析报告。这些服务内容主要基于nView和CTS系统，其中nView为网络设备监控系统，CTS为故障跟踪及管理系统。

日常运行过程中，服务人员主要利用nView系统对用户端的CPE设备进行主动实时的监控。若发现并确认告警，则通知用户并在CTS系统中新建一条记录，对该故障信息进行记录，方便随后对故障的处理和跟踪。在CTS系统中登记后，系统将自动邮件通知设备/线路对应的用户联系人。用户也可自行通过公布的WEB访问方式实时查看自己公司的网络情况和统计报表，或者当前故障处理状态以及历史故障统计报表等信息。ITSS培训

由于目前这套系统是基于网银系统建立的，因此其系统功能的调整和扩展受到网银方面的商务和技术层面协作的影响。对于客户新需求的响应时间较长，且由于License的限制，某些重要功能往往不能及时的更新和改进。从监控角度而言，对主机、中间件、数据库和应用系统的监控将越发重要；从服务管理角度而言，对问题、变更、服务级别、配置等管理流程的支持也是规范和提供服务能力的必要保证。另外，监控及服务管理两方面能友好的向用户提供内容丰富且配置灵活的报表也愈发成为关键的用户体验点。

待续http://www.ITILxf.com/thread-51819-1-1.html

本帖关键字：ITSS