n 第一阶段现场访谈。该访谈以运维服务管理体系及流程总体情况为主,访谈对象为运营中心质量经理栾宜男,从2014年6月11日开始到2014年7月1日结束,历时约2个周;
评估项
| 客户应答 | 备注
|
有专人负责故障管理流程,对整体流程负责,并授权定义、管理、改进流程。
| 目前事件经理负责出月报。全部管理流程的持续改进由质量经理负责。 ITSS考试
|
|
流程涉及的所有人员均被明确角色和职责。 | 经查,文档中有角色和职责定义。
| 需具体访谈事件经理。
|
有效使用故障管理系统和其他相关工具平台。
| 使用ITSM系统管理故障。
|
|
IT维护人员发现服务不正常时提出故障。 | 发生故障时,以恢复业务为第一优先级,但是要求后补故障单。
| 没有相关要求的书面记录。
|
合适的支持人员或外部服务提供商参与解决故障。
| 没有明确的三线定义,在集中交易系统会在事故可能发生时第一时间集中所有相关人员一起分析解决故障,其他系统admin会先自行分析解决再升级,但是没有明确的技术升级时间限定。
| 外部服务提供商参与故障解决,并没有在ITSM中有明确记录。
|
使用单一故障管理工具记录和管理所有故障。
| 是。
| 抽查。
|
如果使用多个故障记录系统,需要有机制来确保用户请求可以在多个系统间跟踪。
| 使用ITSM系统管理故障。
| 事件流程+抽查校验
|
使用脚本帮助识别和记录故障的现象和详细信息。
| 中间件崩溃了,有没有,需要跟管理员访谈。故障识别的SOP。和用户的考核。
| 数据分析。
|
使用合适的工具帮助识别和记录故障的现象和详细信息。
| arcsight分析日志。各系统具体情况需要调研各系统管理员。
|
|
有工具或流程将故障与已解决的问题或已知错误进行匹配。 | 重大事故要有专题分析,重复事件要求开问题单,但是可能直接提交厂商,很多解决方案资深管理员知道,但是可能没有在流程工具中记录。
|
|
故障管理工具能够生成管理报告和趋势分析报表。 | 工具可以生成报告,参照月报,但是故障原因等字段可能存在管理员填写不准确的时候。
|
|
定期检查故障数据质量,报告结果和趋势,需要提升数据质量时应采取必要措施。 | 报告生成,但是分析上还有提升的空间。
| 记录的缺失可能导致数据质量的降低。
|
故障管理工具与其他服务管理工具集成,包括配置、变更和问题管理。
| 系统功能上可以,但是执行层面需要调研。
|
|
单一故障管理流程,覆盖生产服务和基础架构支持的所有故障。 | 流程管理上都有要求。是否每一个故障都有相应的故障单?目前缺少检查和激励机制。 ITSS认证
|
|
需要进一步调查或采取措施的事件(event)应在故障管理系统中记录;例如,未对服务产生实际影响的暂时性性能问题。 | 管理员会分析巡检或报警过程中发现的事件,相应的开故障单。
|
|
允许最终用户提交故障。 | 可以。
|
|
有重大故障处理流程。该流程能够协调和调动必要的资源,如为重大故障的处理提供工作场所方便解决故障。 | 有事故管理流程。
|
|
有安全类的故障流程,定义了特殊的升级手段和并能够单独保存与安全相关的信息。 | 目前定义所有故障都是安全类事件。
|
|
故障模型用来提供处理通用故障的标准流程。例如:处理桌面硬件故障的流程。 | 需要访谈管理员,了解是否存在
故障发现、故障定位、故障解决的常用模型,如果有是否能帮助管理员。
|
|
能够利用配置管理提供的数据记录、诊断和解决故障。 | 访谈管理员。
|
|
定义故障的服务级别,并经过认可,可以被衡量。 | 存在故障级别。
| 服务请求的优先级别存在用户自我定义的情况。
|
提供例行报告可用于故障管理服务水平的评估。
| 目前对故障管理没有SLA,不对业务部分提供例行报告。
|
|
故障被恰当的分级、区分类型和分类。 | SLA只包括RTO\RPO和可用性。
|
|
基于故障的优先级,明确定义故障处理的时间阶段。 | 存在,事故的处理时间为1小时。
| 事后补单的存在可能导致无法明确判断故障的处理时段。
|
定义升级流程并得到遵从。
| 对于事故来说,会第一时间通知相关领导,技术升级没有明确定义。
|
|
故障记录应以一定的规则更新,直至被关闭,确保能够反映故障的当前状态。 | 最后谁处理谁关单,如果经过服务台的单由服务台关单。
|
|
故障解决后,最终影响用户会立即得到通知。 | ITSM平台是所有中信用户使用,外部用户由营业部IT处理。
|
|
只有得到故障发起人认可,故障才能关闭。 | 经过服务台的由服务台关单,其他管理员关单。
|
|
故障关闭后,检查故障的类型和分类,以及是否需要生成问题。 | 问题分析有提升空间。 ITSS培训
|
|
故障关闭后进行用户满意度调查,可以调查所有故障或一定百分比的故障。 | 没有针对单次故障的满意度调查。
| |