管理服务供应商提供的服务等级的系统与方法与流程

本发明涉及服务管理与服务呈现系统，其中收集并且处理关于服务供应商所提供给顾客的服务的测量数据，以计算并且传送在服务等级协议中定义的服务指示符，具体地，本发明涉及一种管理服务供应商提供的服务等级的与方法。

背景技术：

服务供应商(SP)提供、托管或管理对于其客户的资源。资源可以是服务器、服务器上特定的应用程序、联网设备、回应用户的客服人员、解决问题的人员、管理并且改变系统配置与位置的人员、或者由多个元素构成以完成或支持顾客业务过程的复杂解决方案。服务供应商与顾客可以是不同的公司、或者大型全球企业中不同的部门，其中各个部门被组织为对其他部分的支持服务，例如营销、研发、销售、生产。

一般地，在供应商与顾客之间签署服务等级协议(Service LevelAgreement，SLA)，用来定义各方角色，并且消除来自业务关系的任何歧义。这样的SLA：

·标识该协议所涉及的各方；

描述要提供的服务，并且以可测量、可定量的方式标识其上设置义务的服务的质量的指示符，其中关于计算这些指示符方面具有可能的一系列例外以及约定。

·定义所标识的指示符要满足的义务(称为服务等级(SL))，从而以无歧义的方式设置所交付服务的预期质量。

·定义设置这些义务的协议期。

·预先定义如果未满足一项或多项承诺则由SP支付/执行地惩罚。还可以预先定义如果超出承诺，则客户要支付的奖励。

·还定义报告策略、补救措施、争议解决程序、终止标准、知识产权。

当考虑到确信“总是具备(a lways on)”的用品(例如水、电、气、电话、或者按需电子商务)时，会遇到SLA。实际上，当与客户约定包含承诺的特定服务要约时，就存在SLA。

就其自身来说，SLA不会带来所交付服务等级的任何改变。服务供应商和/或顾客需要实现服务等级管理(SLM)程序，该程序将实际产生更高等级的服务。实际上，SLA只是指示服务是否达到约定等级。当未达到时，问题就在于确定是什么造成了违约，可能是如何改进服务，或者改变SLA或供应商。服务等级管理开始于为新合同的新服务等级的开展，并且贯穿真个合同生命周期，以确保满足并且维持服务等级承诺。

服务等级管理一般被标识为以下活动：

·协商、标识、并且同意支持顾客业务过程的可测量服务，并且在服务要约中用服务等级目的(SLO，也称为服务等级目标(SLT))定义SLA表述，

·监控用来交付服务的资源，并且从监控器或者从日志捕获关于这些资源运行情况的数据，

·通过利用预定服务参数公式(称为量度)，并且考虑到可能发生的各种例外，计算中间与高级等级的服务等级结果或者分数，评定对承诺的达标以及可能的惩罚或者奖励，

·评定运行故障、或者就SLA(服务)而言的下降的影响以及财务影响，以实时提醒可能的或者所产生的故障，诊断问题以供解决，只要可能就实施补救措施以调节交付系统，并且因此试图以主动方式保证履行义务，

向供应商与顾客报告相对于合同数目的实际数目，并且封存用于折扣或者奖励的最后数目，

·当未履行承诺时对顾客打折，或者当超过承诺时奖励供应商，以及

·完善、改进、审查SLA定义、服务等级以及支持顾客业务过程的服务。

目前，存在自动管理SLA的SLA管理系统，例如IBM Tivoli Service LevelAdvisor，Computer Associates SLM，Digital Fuel或者InfoVista。这些系统是建设用来完成至少任务的最小集合，例如从监控系统捕获数据，并且这些系统参与下一步骤或者为其提供信息，例如提醒、实施、或者报告。

然而，这些系统未提供对于所述问题的完整答案。实际上，很常见的是，用来支持服务供应商管理的客户业务过程的部分解决方案来自顾客，或者由顾客负责(与服务供应商共享或者未与其共享)。这些系统使用的手段不允许自动将以下情况考虑进来：由于顾客的责任而违反了SLA。在这种情况下，必须在这些系统计算之后修改结果，以仅反应SP的真实责任。

另外，当违反SLA时，或者当SP试图改进其交付的服务时，可以对监控数据进行大量调查，并且必须将上述问题考虑进来。这些SLA管理系统未对这些任务提供任何帮助，而这些任务可能既耗时效率又低，或者需要使用其他复杂昂贵的东西，以实现用于进行数据与结果之间校正的外部工具。

技术实现要素：

相应地，本发明的目的在于提供一种系统以及达成一种方法，用来通过引入以下步骤来管理由服务供应商提供给顾客的服务等级：在考虑到与输入数据有关的外部信息元素(判决元素)(例如SLA合同条款、或者来自服务管理者或其他企业管理系统的输入)的情况下，修改输入数据(判决)，以生成新的修改后输入数据，用于服务等级计算，然后关于作为结果的详细计算数据(运算数据)对达到或未达到服务等级目标的参与，修饰该作为结果的详细计算数据(运算数据)。

因此，本发明涉及一种管理服务供应商提供给顾客的服务等级的系统，该系统包含处理引擎，用来利用服务时间简档以及服务等级业务逻辑，将测量数据转换为运算数据，并且评估所述运算数据以产生服务等级结果以及经修饰的运算数据。所述处理引擎包含：用来在将所述测量数据转换为运算数据之前判决该测量数据的部件，该判决是通过利用描述要进行的修改的判决元素集合进行的；以及用来在所述运算数据经过评估之后修饰该运算数据的部件，该修饰是通过将运算数据与针对每个业务周期服务等级目标确定的修饰值相比较而进行的。

附图说明

通过参照附图阅读以下对本发明的更具体的描述，可以更好地理解本发明的以上以及其他目的、特征以及优点，其中

图1为表示本发明所使用的处理引擎、以及其中所实现的步骤序列的示意方框图；

图2为显示为每个服务等级所实现的处理循环的示意方框图；

图3为在判决测量数据的过程中所实现的步骤的流程图；

图4为显示创建修饰(qualify)运算数据(operational data)步骤中的规则的过程的示意方框图。

具体实施方式

根据本发明的系统包含：相应于每个服务等级的SLA描述库，管理数据的第一数据存储，判决元素的第二数据存储，SL结果的第三数据存储，运算数据，经判决数据，以及为每个服务等级(SL)处理评估循环的处理引擎。

图1所示的处理引擎10包含用于处理作为输入接收的测量数据以及提供经修饰的运算数据作为输出的必要软件模块。如下所述，由处理引擎执行的过程基本包含四个主要步骤：判决所输入的测量数据的步骤12，将经判决数据变换为运算数据的步骤14，评估这些运算数据的步骤16，以及修饰运算数据的步骤18。换言之，如图2所示，为每个服务等级20实现该过程。首先，检索对于服务等级的测量数据(步骤22)，这些测量数据涉及所评估的SL周期。然后，从判决元素的第二数据存储，检索与所评估的SL周期有关的判决元素(步骤24)，并且可以利用SLA描述执行SL评估循环(步骤26)。最后，在第三数据存储中存储经判决数据、经修饰运算数据、以及SL结果(步骤28)。

再次参照图1，判决步骤12用来反映服务供应商的责任的真实域，或者用来反映事实，这是因为出于某种原因，监控器提供了不正确的数据。该步骤必然产生一组新数据。虽然修改了测量数据，但是需要原始观察数据的其他系统仍然可以得到参考数据，或者可以对改变进行审计，因为该数据可能用于法律目的。

判决元素30可以是在合同签订时创建的、并且对于整个服务等级生命周期有效的条款32(排除条款、特殊条件、资源限制等等)，或者可以在服务等级生命周期期间的任何时间由服务管理者在执行其服务等级管理任务时从判决控制台(console)34创建，或者通过利用责任字段或其他信息，自动从其他企业管理系统36(例如问题与改变管理(Problem and Change Management))创建。判决元素必须保存其进行修改的原因、以及关于首先经过验证然后经过授权过程的创建者的信息，该原因将会显示给终端客户，并且必须经终端客户同意。

每个“修改后”的数据都包含至所应用的判决元素及条款的按照特定应用循序的引用列表，用于审计、详细报告、解释/顾客关系，以及用于法律判决及以后的计费应用(折扣或者奖励)。每个判决元素30一经使用就被锁定，从而对其不会再发生修改，以保证审计控制可以得到正确的信息。

该步骤还支持并行信息管理过程，由此可以封存判决，从而对给定服务等级周期的服务等级结果以及其他所产生的数据不可以再进行修改，即对于该服务等级周期，不可以再创建判决元素。这对应于恰在向计费系统发送结果数据、或者为其他法律目的使用结果数据之前、且在顾客审查并同意该结果数据之后的敲定过程。

每次请求评估SL时，都执行图3所示的过程。首先，拷贝所有测量，作为经判决测量，其具有空修改历史链(步骤38)，由此使之能够存储对每个测量的修改历史。然后，该过程检查是否还有判决元素要应用到该组经判决元素(步骤40)。如果有，则如上所述锁定该判决元素(步骤42)，并且得到要从该判决元素改变的测量的标识(步骤44)。然后，检查其是否相应于现有的经判决元素标识(步骤46)。如果是，则将经判决元素内容用在判决元素中指定的内容，并且将判决元素标识添加到修改历史链(步骤48)。如果不是，则创建具有该标识的新的经判决测量，并且用在判决元素中指定的内容填充该经判决测量，并且将该判决元素添加到修改历史链(步骤50)。在两种情况下，该过程都循环返回到检查是否还有判决元素要应用的步骤(步骤40)。

返回图1，由处理引擎10执行的第二步骤为：通过利用描述服务等级时间逻辑的服务时间简档52(一般还称为服务日历、并且用可能不同的SLT定义不同的服务周期)、以及在服务等级中定义的用来将原始数据修改为更适当形式以供评估及产生汇总服务等级结果的特定业务逻辑，将经判决数据变换14为运算数据。另外，所产生的每个运算数据点都回引到其来自的、初始的经判决的一个或多个测量数据点，以供跟踪及审计目的。例如，服务等级时间逻辑可以包含一月中的关键周期以及非峰值小时，其中要达到不同的目标，或者包含没有服务的周期。监控设备与数据采集系统不知道合同特有的此类信息，并且测量数据点可以覆盖多个此类周期。为生成服务等级结果以及与不同服务等级目标比较，需要产生数据点的适当集合。并且继续该例子，如果测量来自于监控同一资源的不同探测器，则当评估并产生汇总服务等级结果时，在这些测量可以用于服务等级计算之前，需要利用在服务等级中指定的逻辑54合并这些测量。

更详细地，并且作为例子，可以将转换经判决数据为运算数据的步骤分解为两个子步骤。该例子显示经判决数据如何传播到评估过程的下一步骤。

1.独立于SL服务时间简档(或者业务计划)地，合并关于同一被监控资源的几个测量数据。该部分精确定义初始数据与经变换数据的格式，并且因为精确标识并定义了这些数据，所以用来合并数据的对SL业务逻辑的描述自身可以是程序，其由与顾客定义了服务等级的人员提供，或者由顾客自身提供。

合并步骤逐测量类型id地收集测量，并且同时其为每个经判决数据点创建前运算(pre-operational)数据点(即没有业务计划状态的运算数据点)，同时原样保持经判决的值以及至原来的经判决数据点的引用。然后，其从SL信息中为每组选择相应的业务逻辑，并且其为每组应用合并逻辑，以为每组产生新的前运算数据点集合。如何对数据点执行合并逻辑依赖于实现：这可以是解释器、至该逻辑编译形式的动态调用等等。

作为例子，3个探测器监控URL，并且在SL中定义当所有3个探测器都同意观察到故障(outage)时才宣布故障，并且该故障从检测到其的第一探测器测量持续到返回正常的第一探测器测量。在这种情况下，只看到一个测量类型＝所观察的URL状态，因此只有一个组。有3个测量输入，由其不同的资源id标识。为了进一步简化，每个数据点对给定资源id/探测器只提及故障时间与时长。不需要再显示可用资源，因为默认地没有故障就意味着可用。

这些被置于一组测量，然后利用所提供的逻辑合并。在这种情况下，所提供的形式逻辑可以是：

-从数据集合组建立按照所提交的测量时间戳排序的前运算点的一个数据集合，

-按照排序后的顺序，经过每个非被排除的点，并且察看其描述的时间间隔(时间戳，时间戳+时长)是否与两个具有不同资源id的、随后或同时的点的时间间隔重叠。

-如果重合，则利用运算数据点创建工具，从这3个点创建新的运算数据点，并且将时间戳设置为当前点的时间戳，将时长设置为3个点的(时间戳+时长)减去该点时间戳的最小值，抛弃用来创建该点的3个运算数据点，并且将该点插入排序列表，在其中保持初始的经判决的数据点列表。

-如果未重合，则抛弃数据点。

2.相对于服务时间简档周期(服务等级时间逻辑)划分测量数据以创建每个周期的分离的集合。该步骤允许并行地向每个数据集合应用同一过程，而不用再在到达SL结果比较阶段之前关心服务时间简档。

该划分步骤将前步骤的输出作为输入，即仍未设置业务计划状态的前运算数据点。该步骤的外部输入为显示所处理的服务等级中每个时间的活跃业务状态的日历。

该步骤的逻辑非常简单，总是相同：

a-对于每个前运算数据点，从日历获得对于数据点时间戳的业务状态，并且将其设置在目前的运算数据点中。

b-如果该点为汇总点(即，不是一唯一时间点，而是覆盖了一时间范围)，则察看日历，以检查在该汇总点所覆盖的间隔的结束时间之前业务状态是否改变，

c-如果改变，则从该点创建新的运算数据点。将该新点的时间戳设置为业务状态改变的时间，将其业务周期状态设置为该新状态，并且将其结束时间或者时长设置来与当前点的结束相匹配。将当前点的结束时间或者时长设置为业务状态改变的时间。然后利用该新的运算数据点，重新开始子步骤c-。

作为例子，如果故障从下午3点持续到下午11点，并且服务时间简档指出在一天之中，早上8点至下午8点为正常小时，在其之外为具有不同目标的非峰值小时，则需要将该故障划分为两段，一段从下午3点到下午8点，其中业务周期状态＝“正常小时”，一段从下午8点到下午11点，其中业务周期状态＝“非峰值小时”。

然后，通过服务等级评估，利用公式56，评估(16)运算数据点，该公式56指定要馈送哪些数据作为输入，数据形式是什么(响应时间、可用性、计数、状态)，以及应该如何处理输入数据以产生汇总的中间与顶级服务等级结果。为服务时间简档中的每个业务周期产生一个数据集合。该步骤所产生的数据直接用于服务等级达标(attainment)比较，以对服务等级进行报告，并且用来输入到其他企业管理系统。其匹配供应商以合同形式进行的承诺，并且表示所交付服务的协商值与质量。

最后，针对与每个业务周期的服务等级目标58相比的、其参与达到结果或者降低该结果的情况，修饰(步骤18)从经判决数据产生的运算数据。该步骤以如“符合简档(In profile，＝对良好SL结果有贡献)”或者“不符合简档(Out of profile，＝对降低SL结果有贡献)”的标签，以及至破坏限界的余量(delta)来修饰所产生的运算数据点，，该到破坏限界(breaking limit)的余量用来理解数据点对高等级SL结果作出贡献的边际(margin)，不管是坏还是好(例如：“不符合简档”或者违约之前剩余的时间，对于问题解决时间，等等)。

该对运算数据的增强由服务供应商所管理的操作(Service ProviderManaged Operations)人员及其自动系统使用，以持续地跟踪对端至端(end toend)最终服务等级作出的贡献，以理解其对该等级的影响，并且帮助他们区分工作与措施的优先次序，以保证端至端服务等级。作为后者的例子，用于问题解决的违约之前剩余的时间为用于以下目的的信息：理解在当前未决问题中，首先要解决哪些问题。作为前者的例子，显示哪些详细量度对SL结果降低有贡献对以下各项有帮助：在输入数据集合中，迅速找到哪些是要改进的点，并且控制补救措施的效果。这之所以可能，是因为每个运算数据点都回指到经判决数据，其进而在其历史中具有对初始数据点进行的修改的列表。另外，至破坏限界的余量信息会使人了解改进服务等级所要花费的努力的量，以及应该集中到哪里才能获得最大好处。

实现过程要求对于每种运算数据类型创建用来修饰它们的规则。这会得到每个服务等级所特有的一组修饰规则。在服务等级评估循环中的先前步骤所产生的每个运算数据都具有与其相关的数据代码，该代码用来检索应用于该服务等级的以及应用于其所在的业务周期的的修饰规则。

这些规则可以在可执行代码中，并且在修饰时间对于每个运算数据执行这些规则，或者这些规则可以是对要进行的测试、以及要满足的条件的描述，并且也可以在修饰时间对这些规则进行解释。每个规则都依赖于服务等级评估公式以及目标。在多个服务等级之间可以有某些共同之处，也可以没有共同之处，并且在有共同之处的情况下，可以共享规则。

在图4中显示了为每个运算数据创建规则的过程，利用运算数据类型id、服务等级id、以及业务周期id，在规则表中获得62规则标识。然后相对于运算数据地，执行或解释64规则。然后，检查66结果是否为正。如果为肯定，则将运算数据修饰为“符合简档”68；如果不为肯定，则将运算数据修饰为“不符合简档”70。将结果存储为至目标的余量，以如上所述地被使用。

例如，SLA定义95％的URL响应时间测量应该小于2s。通过该SL评估产生的运算数据为评估周期上展开的响应时间测量列表，以及测量列表的第95百分区间值。在这种情况下，可能只使用两种运算数据类型共用的一个规则。该规则为将运算数据值与2s相比较，并且如果小于或等于则回答为肯定(符合简档)，否则回答为否定(不符合简档)，并且在运算数据点中存储余量。