实施指南 › 案例研究示例 › 数据建模示例 › 案例研究 8：帮助台性能

案例研究 8：帮助台性能

这是一个针对帮助台性能的典型案例研究。

数据源如下所示：

以上显示的数据源列出了帮助台故障单的详细信息，这些故障单是针对客户服务的多个位置的每个客户进行管理的。 多个客户可能位于同一位置。

当使用此数据源时，以下三个要求是报告所必需的：

• 4 小时之内为客户 CM3 解决的优先级 1 故障单的百分比。
• 4 小时之内在每个位置为客户 CM3 解决的优先级 1 故障单的百分比。
• 1 天之内在每个位置为客户 CM3 关闭的优先级 1 故障单的百分比。

上述要求表明事件应按以下条件进行筛选：

• 优先级
• 客户
• 位置

您需要指定这些筛选条件中的哪一个应转换为事件类型以及哪一个要转换为相关资源。

我应如何选择事件类型？

在所需的三个筛选条件中，故障单优先级最适合转换为事件类型，原因如下：

• 它描述了正在处理的事件的类型（优先级 1 故障单）。
• 存在的不同优先级的数目相对较小（优先级 1、2、3）。
• 事件类型本身是相对常量（帮助台很少更改处理故障单时所基于的优先级）。

如何选择资源？

所需的另外两个筛选条件是客户和位置，它们是需要报告的最小实体。 因此，客户和位置的组合是资源。

客户和位置是相对固定的实体，且具有明确的生命周期，因此可能会添加新客户或新站点。 此外，站点和客户之间的关系可能会发生变化。

为了进行转换，可能会使用数据源的多个字段。 鉴于前一个案例研究中是将服务器字段转换为 CA Business Service Insight 资源，在本案例中，将使用这两个字段的组合来生成资源。 每种排列都会生成新的资源。

资源列表如下所示：

输出资源是使用符号“+”将客户和站点字段组合在一起所形成的组合。 很重要的一点是要注意资源的名称，因为资源是从数据源中提取的，并且稍后会出现在报告中。 报告能力需能满足期望。

注意：为帮助台、任何故障单或突发事件系统建模时，最常见的一个错误就是将单个突发事件定义为资源。

以下错误假设常常会导致错误：

1. 该单个突发事件是报告的事件。不要将要报告的实体设置为要为其生成计算的实体，这样可避免将单个突发事件作为客户站点计算的基础。 通常，SLA 是基于总体性能，而不是处理性能的个人故障单。
2. 按故障单级别设定保证。 这是错误的，因为该保证是定期的，计算的是一段时间内的聚合数据。

设置资源分配

对于第一个计算要求：

1. 4 小时之内为客户 CM3 解决的优先级 1 故障单的百分比。
   • 需要接收由特定客户引起的故障单事件。 客户是此资源的一部分，也表明了客户站点。 因此，要捕获与资源相关或由该客户引起的所有事件，有两个选项：
   • 在数据源中的客户代表合同方的情况下，可以将资源附加到相关合同方。 这样就可以按合同方进行注册。 在可能的情况下，总是首选这种方式。
   • 为数据源中的每个客户创建资源组，并将其中的所有相关资源进行分组。 采用此方式时，将按资源组进行注册。

   对于以下两个计算要求：

2. 4 小时之内在每个位置为客户 CM3 解决的优先级 1 故障单的百分比。
3. 1 天之内在每个位置为客户 CM3 关闭的优先级 1 故障单的百分比。

针对这些要求，将把资源收集到资源组中，因为在需要单独为每个站点进行计算时将不得不对度量标准进行组群。

注意：虽然资源分配对当前模型和要求而言并不是必需的，但创建它们以备将来的要求使用很重要。 这样做可省去以后系统开发工作中的一些工作。

选择时间戳字段

如前所述，时间戳对关联引擎处理事件的方式非常重要。 度量标准总是计算每个时间段的服务水平，在此时间段内处理的事件的时间戳也在此时间段内。

在第一个案例研究中，数据源仅有一个时间字段。 但在本案例中，可能存在三个字段能够设置为时间戳。 检查前两个记录：

要计算解决时长，引发时间和解决时间都是必需的。 对于事件，可以仅附加一个时间戳。 然后，另一个时间戳可用作值字段中的值。

如果引发时间值被用作时间戳，则故障单包含在十二月结果中。 如果解决时间值被用作时间戳，则故障单包含在一月结果中。 两个选项都是可用的。 选择项仅需要满足期望，也就是说，期望的故障单应显示在报告中。

这是实施期间的考虑重点，因为它确定了事件在何时用于计算。 例如，某故障单出现在十一月，但直到十二月才关闭，那它应当何时归到 SLA 结果中？ 它应该归到十一月还是十二月的数据中？

在本案例中，由于故障单仅在其关闭之后才报告给数据源，因此，可以等到故障单关闭之后才捕获数据。 通常，关闭日期都晚于引发日期和解决日期。 在选择引发日期作为时间戳的案例中，应将其归到十二月结果中进行处理。 关闭日期是在一月，这意味着报告此故障单时已过了十二月。 因此，十二月的结果已发布。 然后，关联引擎就像在过去一样通知事件，因为时间戳属于十二月并触发了重新计算。 因此，十二月的结果可追溯更改。

需要完全理解这些后果，以便定义必须选择哪个时间字段作为时间戳。 通常会选择关闭日期，以便生成无法追溯更改的最终报告。

另一方面，使用关闭日期作为时间戳可以延迟故障单进入计算。 已解决的故障单只能在一段时间后关闭。

但是请注意，使用关闭日期也可能会触发组织中加速故障单关闭的过程。

最终建议如下所示：