故障管理流程与故障管理功能开发的设计

故障管理流程的设计目标

在最短时间内恢复服务正常运营，满足SLA要求，将事件对业务运营的负面影响降至最低。

故障管理功能的开发需求

1. 不能只是实现一个网页版的Excel，要能引入流程元素，结合故障管理流程管理好故障事件。
2. 避免生成和维护重复的信息，如机房、主机、应用服务等，在该管理功能的实现中优化考虑从运维管理平台的已有数据做功能集成。
3. 满足故障统计分析和展示需求。

故障事件的范围

1. 用户和技术人员报告的失效、问题或疑问；
2. 事件监控工具自动发现和报告的；

故障事件的处理需要有时限管理和故障升级处理

故障模型的定义与使用

对常见故障预定义故障处理模型，故障模型需要包括：

1. 处理故障应遵循的步骤；
2. 这些步骤应遵循的时间顺序和相互依赖关系；
3. 职责；
4. 措施完成的时间与阈值；
5. 升级程序，联系谁、何进进行升级；
6. 任何必要的证据保留活动。

故障管理流程图

故障管理流程中的主要活动

1、故障确认

从各种途径反馈来的事件中分析、判断，以确认是否属于故障（事件管理、web界面、用户反馈、电子邮件等途径）。

故障事件需要指定一个负责人，对故障事件的全生命周期的管理负责。

2、故障记录

所有故障均需要做完整记录并带有时间戳。

故障记录的定义需要包括：

• 唯一参考编号
• 故障类型
• 故障紧急度
• 故障影响度
• 故障优先级
• 记录的日期/时间
• 记录事件的人员
• 通知方法
• 受影响客户的联系方法
• 症状描述
• 故障状态
• 相关配置项（应用、主机、机房、服务SLA）
• 负责故障的支持人员/小组
• 相关问题/已知错误
• 解决故障采取的活动
• 解决日期/时间
• 关闭类型
• 关闭日期和时间

3、故障分类

要求小于4个级别，如下所示

• 硬件->服务器->内存条->插槽松动
• 软件->应用服务->OA套件->考勤系统

4、故障优先级

优先级取决于两个因素：紧急度+影响度

优先级编码设计：

5、初步诊断与处理

应尽量成功解决并关闭故障。

6、故障升级

当故障处理已经超过目标解决时间，或者超出自己处理范围，必须立即升级故障。

• 职能性升级，在业务应用、系统、网络等专业分组间升级故障；
• 管理性升级，当故障性质严重、需要引入额外资源或发生故障分配争议时，必须通知运维负责人。

7、调查与诊断

此类活动应全面记录到故障处理记录中。

8、解决和恢复

• 应确保恢复措施经过了可靠地验证测试；
• 可能需要协调多个小组的恢复活动并与所有参与方保持联系；
• 需要将采取的各种措施更新至故障处理记录中；
• 问题解决小组应将故障恢复结果反馈给该故障事件负责人，以执行故障关闭操作。

9、故障关闭

故障事件负责人应检查故障是否全部解决，用户是否满意并同意关闭故障。

还需要检查：

• 故障分类，故障初始分类是否正确或需要得到更新；
• 用户满意度调查，对约定比例的故障事件进行；
• 故障登记，是否完备；
• 是否属于重复发生的故障；
• 正式关闭故障。

故障管理流程相关的监控指标（基于故障记录的统计分析）

以下KPIs指标应得到监视和报告，据以判断故障管理流程及其运营的效率和效果。

• 故障总数量
• 按产品服务统计的故障数量和百分比
• 故障数量的同比、环比展示
• 按各阶段细分的故障，如进行中的、已关闭的等
• 重大故障的数量和百分比
• 在约定响应时间内处理的故障比例
• 重开的故障数量和百分比
• 每个人员处理的故障数量和百分比
• 按故障模型处理的故障数量和百分比

其它故障管理功能需求

• 故障自动关闭功能：启用该功能后，该故障事件在持续一个指定的时间段后，会自动关闭，并且把故障关闭类型标识为“自动关闭”。
• 重开故障功能：在一个限定的时间内，故障重复发生，需要重开不久前关闭的故障，继续按同一故障事件进行维护。