1. 目标

    在短时间内恢复服务正常运营（满足 SLA [Service-Level Agreement]），将业务运营的负面影响降至最低。

  2. 范围

    包括：

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

  3. 对企业的价值

    • 能够检测和解决故障
    • 能够将IT活动与实时业务优先级相关联
    • 能够发现潜在的服务改进方面
    • 服务台可以从中发现额外需要的服务或培训需求
    • 故障管理在企业中有很高的曝光率，更容易展示出流程价值所在，为争取投资提供支持。

  4. 基本概念

    • 处理时限：

      • 根据 SLA 中规定的整体故障响应与解决目标，在不同的故障处理阶段必须确定具体处理时限。要在 OLA [Operational Level Agreement] 和 UC [Underpinning Contract] 中作为目标明确规定
      • 所有支持小组必须清除了解这些处理时限
      • 可以借助服务管理工具用于自动执行处理时限，并根据预定义规则升级

    • 故障模型：

      • 预定的“标准”故障模型将有助于在故障发生时对应到合适的故障
      • 按故障模型要求将信息输入到故障处理支持工具中，之后该类工具可以自动进行流程的处理、管理与升级工作

    • 模型包括：

      • 处理故障应遵循的步骤
      • 这些步骤应遵循的时间顺序，相互依赖关系
      • 职责
      • 措施完成的时间表与阈值
      • 升级程序，应该联系谁，何时进行升级
      • 任何必要的证据保留

    • 重大故障：

      • 组织必须明确标识出哪类事件构成重大故障
      • 必要时可以动态成立一支重大故障处理团队
      • 如果需要调查故障原因，问题经理也需要参与其中
      • 服务台需确保所有活动均记录在案，且用户了解具体进展

  1. 流程活动

    • 故障确认：
      对各种途径反馈来的事件进行分析、判断，确认是否属于故障

    • 故障记录：
      所有的故障均需要做完整的记录，并带有时间戳

      故障信息，模型：

      • 唯一参考标号
      • 故障类型（通常为两到四个子类）
      • 故障紧急度
      • 故障影响度
      • 故障优先级
      • 记录的日期/时间
      • 记录事件的人员
      • 通知方法
      • 受影响客户的联系方式
      • 症状描述
      • 故障状态
      • 相关 CI
      • 负责故障的支持人员/小组
      • 相关问题/已知错误
      • 解决故障采取的活动
      • 解决日期/时间
      • 关闭类型
      • 关闭日期/时间
    • 流程图
      故障处理流程.jpg

    • 故障分类

      通常会使用不超过四个级别，例如：

      • 硬件 -> 服务器 -> 内存条 -> 插卡松动
      • 软件 -> 应用 -> OA套件 -> 采购订单系统

    • 故障优先级

      因素：紧急度、影响度

      优先级编码设计：
      优先级编码设计.jpg

    • 初步诊断

      由服务台完成，应尽量成功解决并关闭故障

    • 故障升级

      • 职能性升级：

        • 当故障处理已经超过一线解决的目标时间，必须立即升级故障
        • 参照 OLA 和 UC 中的规定，对故障升级进行管理
        • 故障的所有权要始终归属服务台，服务台负责跟踪进展、通知客户，直到故障结束

      • 管理性升级：

        • 当故障性质严重，需要引入额外资源或维护商，存在故障分配争议等情况时，必须通知相应的项目经理
        • 注意：在分配故障时，须明确按照真正的业务优先级顺序处理故障。不允许人员根据个人意向“挑选”故障。

    • 调查与诊断

      • 系类活动应尽可能地并行执行，以缩短时限
      • 此类活动应全面记录到故障记录中

    • 解决和恢复

      • 应确保恢复措施经过了可靠的验证测试
      • 可能需要协调多个小组的恢复活动并与所有参与方保持联系
      • 需要将采取的各种措施更新至故障处理记录
      • 问题解决小组应将故障反馈给服务台，以执行关闭措施

    • 故障关闭

      • 服务台应检查故障是否全部解决，用户是否满意并同意关闭故障

      • 服务台还应检查：

        • 关闭分类、故障初始分类是否正确和需要得到更新
        • 用户满意度调查，对约定比例的故障进行
        • 故障登记
        • 问题持续存在或重复发生？
        • 正式关闭

  2. 流程间接口

    • 问题管理
    • 配置管理
    • 变更管理
    • 容量管理
    • 可用性管理
    • 服务级别管理
    在 SLM [Service Level Management] 管理范围内，故障管理应关注：
    • 故障响应时间
    • 影响度定义
    • 目标修复时间
    • 服务定义（相对于用户）
    • 请求服务的规则
    • 想用户提供反馈的预期

  3. 信息管理

    故障管理中使用的大部分信息，来源于以下两方面：

    • 故障管理工具，包括：

      • 故障和问题历史记录
      • 故障分类
      • 为解决故障采取的措施
      • 诊断脚本，用于帮助一线分析人员解决故障，或者至少手机信息，来帮助二线或三线的分析人员更快速地解决故障

    • 故障记录，包括：

      • 唯一编号
      • 故障分类
      • 记录及任何后续活动的日期/时间
      • 记录和更新故障记录的人员姓名和身份
      • 受影响用户的姓名/组织/联系人信息
      • 故障症状的描述
      • 为诊断、解决故障所采取的任何措施的详情
      • 故障类别、影响度、紧急度、优先级
      • 与其他故障、问题、变更和已知故障的关系
      • 关闭详情，包括时间、类别、采取措施以及关闭记录的人员身份

  4. 指标

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

    PKI [Key Performance Indicators] 包括：

    • 故障总数量
    • 按各阶段细分的故障，如记录的、进展中的、关闭的等
    • 当前估值处理积压的规模
    • 重大故障的数量和比例
    • 解决或恢复故障的平均耗时，按影响度代码细分
    • 在约定响应时间内处理的故障比例
    • 重开的故障数量和所占百分比
    • 未正确分配任务的故障数量和所百分比
    • 未正确分类的故障数量和百分比
    • 服务台无需其他级别支持而关闭的故障所占百分比
    • 每个人员处理的故障数量和百分比
    • 无需到达现场二远程解决的故障的数量和百分比
    • 按各故障模型处理的故障数量
    • 按时间细分的故障，帮助确定故障高峰并确保提供匹配的资源

  5. 挑战/CSF/Risks

    • 挑战：

      • 尽早检测到故障的能力
      • 说服所有人员，所有故障必须进行记录，并鼓励使用基于Web的自助式功能
      • 可以提供相关问题和已知错误的信息
      • 可以结合CMS确定CI之间的关系，并为实际工作提供帮助
      • 集成到SLM流程，这可以帮助故障管理正确评估故障的影响和优先级

    • CSF [Critical Success Factors]：

      • 出色的服务台是故障管理成功的关键
      • 遵循明确定义的目标（在SLA中有定义）
      • 在该流程的各阶段拥有足够的、具备适当技能水平的、客户导向的技术支持人员
      • 整合的支持工具，推动和控制此流程
      • 能够影响和塑造所有支持人员正确行为的OLA协议和UC合同

    • Risks:

      • 故障泛滥
      • 缺少支持工具来发出告警和提示进展情况
      • 由于缺少工具或缺少整合，没有充足/及时的信息来源
      • 由于OLA和/或UC不存在，使得目标或措施制定不合理

标签: 故障管理流程

添加新评论