您好,欢迎访问专业IT管理知识分享平台

上传文档

当前位置:首页 > 文章列表 > SLA的组成要素

「ITIL文章」SLA的组成要素


服务目录


      服务目录决定了SLA约束的服务范围,即服务商到底提供哪一些服务,只有客户“选择”了的服务目录,服务商才会报价与后续的响应,在服务目录之外的内容,将不受SLA的限制,这也意味着报价时是未考虑这些服务内容的,最后结算也是单独的,服务目录要利于阅读与理解,便于客户、服务商自身消化,不然在实际应用中是无法真正起到作用的。


服务日历

       服务日历决定了SLA约束的时间范围,即服务商为客户提供X*X的服务响应期,是7*24还是5*8,是否扣除一个周期内的法定假期,很多服务商有自己的公司日历,事实上,每一个服务型的项目存在着一个服务日历,服务日历与公司日历很多时候不是相同的,不同则意味着成本的增加与管理难题的增加,这需要进行在报价结算时综合考虑,因为它直接关系到人力的配备与排班,服务日历跟各种监视计划也有直接的关系,它还跟SLA的测量有关联关系。


可用性

      事实上每一个项目是一组服务的集合,比如桌面运维或IDC运维,亦或者是一个应用系统的运维,这些在实际的作业中,多数是以项目的形式管理与存在的,这同时也表示是一个服务集群,这里就需要定义每一个项目的可用性,说到可用性,通常的公式是:可用率=(AST-DT)/AST*100。AST(agreed service time)是指约定的服务时间即上面提到的服务日历,DT(Actual downtime during agreed servicetime)在约定服务时间内的停机时间。这个计算公式表面看起来简单但在实际的取值中是比较复杂的,因为AST需要考虑日历问题,需要把服务日历的所有时间段换算成小时甚至分钟,如果一个故障发生在5*8之外的时间,是不会考与计算的,同时每一个故障的发生与结束时间需要测量出,还有加上其它的因素,比如是不是这次故障是由服务商承担的,如果是客户非法违视操作,或者是第三方导致的,此时把故障时间纳入可用性计算显然是不合理的。事实上考虑到一个合同周期的长度,通常说的可用性达99%这实际是一个非常低的可用指标,如果是5*8的服务的话,99%的可用性意味着有208个小时的时间内服务是不可用的,在实际的服务过程中,单位用小时是过粗的,因为故障的发生一般是以分钟为单位的,有的行业甚至需要用秒为单位。加上用户群的问题,可用性的计算还需要更复杂才能真正发映真实的服务情况,一直以来有一个问题困扰着许多人,到底怎样的故障算是影响了可用性呢?比如一个应用系统,如果是全国范围内的应用而且用户群众多的话,发生了局部地区的用户无法使用部份模块了,这需要纳入可用性的计算吗?如果纳入的话,会让可用性无端的降低很多,而实际中并非如此,你会发现全国的服务不可用与部分地区的不可用造成的计算结果一样了,但实际的服务情况并非如此,这表示计算的模型复杂。



解决时间

      解决时间是指当发生各种类型的事件时的完成处理时间要求,常态而言,事件分为咨询、请求、投诉、故障、新需求。这是事件的分类,另外事件需要进行分级,一般可分为五级或三级,这时需要定义每一个分类、级别的事件的解决时间要求(比如一级故障要求多少分钟解决),还需要定义哪个级别的事件影响可用性(比如一级故障二级故障都影响可用性),有一些事件分类象投诉与咨询可能是不会影响可用性的,常态而言新需求也是不影响可用性的(除非在商务报价之初就纳入新需求的约束考虑)。

       这里要特别需要强调一下可用性与解决时间的关系,这是一个相互钳制关联的,比如可用性定义了一年之中只能宕机20个小时,但是客户不会充许在同一个时间里把20小时用完,解决时间里定义了宕机是一级故障,一级故障的解决时间是1小时,这样会强制把20个小时分散到全年之中,以减少对业务的冲击。当可用性与解决时间这两个核心指标定义了后,象按时解决率等等这些事实是用于服务管理的,基于服务商自身的管理而言的,站在客户方的立场而言有了这两个指标就足够约束服务商了。



相关文章推荐:

暂时没有评论,评论一个吧?

您需要登录后才能评论 , 去登录

发表文章

Powered by DS文库

Copyright © 专业IT管理知识分享平台 All Rights Reserved. 鄂ICP备19005274号-1
×
保存成功