文档结构  
翻译进度:已翻译     翻译赏金:0 元 (?)    ¥ 我要打赏
参与翻译: vincentsun (14)

在上星期访问一个客户(一个大型的软件即服务(Software-as-a-service,SaaS)平台公司)时,我们与客户展开了一个关于服务级别协议(Service Level Aggreement,SLA)的有趣的讨论。在客户的鼓励下,我撰写了此篇博文。

我在1999年被DoubleClick公司委派成立服务质量(Quality of Service,QoS)小组。我的首要任务是建立起一个监控组,包括内部监控以及外部监控等;次要任务实际上是一个附加的工作:管理我们的SLA。

然而,我的次要任务在2001年变成了极为优先的任务。我们因违反了SLA而向一位客户支付了100万美金(真金白银呐)。本质原因是,我们的某一位员工签署了一份包含了疯狂的服务保障的协议:100%正常运行时间。

第 1 段(可获 1.4 积分)

当我们开始解决这个问题时,我们几乎是新手,但又必须尽快加强我们的SLA管理来阻止这类惩罚性的赔偿——我们处于危机状态。我们的CFO每天都在背后盯着我,一遍又一遍地问同样的问题:“我们今天又会违反什么协议吗?”

今天,我会分享作为一个应用服务提供商(Application Service Provider,ASP,SaaS的前身),走过的控制SLA的旅程,以及大家想要达到同样效果需要做的所有事情。

1. 什么是服务级别协议(SLA)

一个SLA是一份供应商和客户的协议。协议规定了供应商将要履行的约定的条款。SLA是一个法律保护伞,覆盖了一系列描述服务内容、测量方法论、以及各种目标(正常运行时间,速度,每秒事务发生数量等)的服务级别目标(Service Level Objective,SLO)。下面的定义描述了SLA是如何覆盖客户和供应商的。

第 2 段(可获 2 积分)

SLA Definitions at Doubleclick

  • 对客户来说:SLA提供了一个服务级别目标评级标准,以及针对恶劣服务的保护。
  • 对服务提供商来说:SLA提供了一个明确的方式,确保(客户)对服务质量的正确预期,确保服务质量会被公平地评估,以及激励服务提供商提高服务质量。
  • 为保证SLA被正确实现,我们同时会在下列关键原则上达成共识:
    • SLA可以实现
    • SLA可以重复
    • SLA可以测量
    • SLA有意义
    • SLA互相可以接受

2. 第一步,探索发现

在第一周,我建立了一个包含所有合同的列表,提取出SLA、SLO和惩罚赔偿,并把这些信息存入了数据库。

第 3 段(可获 1.21 积分)

然后我开始了对公司的业务涉众、法务部门和领导的培训过程。

如下面所述,我最开始关注基于终端用户体验的SLA。

SLA Application Performance

SLA:应用的性能

  • 终端用户的体验是最重要的
  • 应用的性能可以衡量终端用户体验
    • “管理太慢”
    • “横幅加载太慢”
  • 最好的与用户交流的方式
    • 不要使用黑话、行话
  • 最好的管理IT的方式
    • 不要用手指对别人指指点点
  • 最好的设置IT目标的方式
    • 基于终端用户体验的SLA

3. 建立SLA不仅仅代表在合同上多一两句话

我们支付了100万美元的原因是,我们没有准备就绪的SLA管理系统。

因此,我们开始建立基于四个支柱功能的服务级别管理方案:管理(Administration),监控(Monitoring),报告(Reporting)以及合规(Compliance)(AMRC)。

SLM Process

然后我们与商业伙伴、客户、法务部门和金融部门座谈,创建了SLA生命周期,避免未来可能发生的昂贵的错误。我们每个季度审阅一次服务级别管理(Service Level Management,SLM)情况:

第 4 段(可获 1.45 积分)

Process SLM

计划

  • 创建服务目录
  • 对服务目录估价
  • 定义服务目录的衡量标准
  • 数据收集和监控

测量

  • 测量
  • 存储测得的性能数据

分析

  • 验证
  • 将结果与他人沟通

修正

  • 目标
  • 方法论
  • 监控工具

 

之后,我们让公司内部的数据科学家基于我们从检测工具中获得的历史数据,对于违反SLA的风险进行仿真。我们不希望设置一个每天都(可能)会被违反的SLA。

SLA probability

我们同时运行了多个针对可用性和收入的假设场景分析(“what-if”),包括每天的不同时刻、每周的不同天的影响。

What If Scenario

我们甚至制作了一个在线工具(2001),使得销售部门能够为客户请求一个SLA“投资组合”。这个“投资组合”后续会被我们的QoS小组审理和批准。我们可以把这个工具想象成一个“SLA服务台”。

SLA Request

4. 外部SLA与内部SLA

第 5 段(可获 1.38 积分)

在这个项目的初始阶段,我们迅速发现了一个主要的差错:外部的SLA与内部的SLA不匹配。而且,在我个人看来,这是个巨大的错误——在内外不匹配的情况下,我们怎么可能在技术部门、业务部门和客户之前取得一致的目标,甚至是讨论同样的事情呢?客户可能会需要广告投放的正常运行时间,但我们的技术组可能提供的是服务器可用性。

因此,我们对齐了内外的SLO,并使得内部的服务等级目标非常非常高。这个做法取得了巨大的成功,因为这允许我们每天依靠同一套指标来理解我们的SLA风险情况,以及驱动公司的运营更为卓越。我们的技术组(运营,工程等)变得对业务SLA的概念敏感起来,并开始非常注意不违反他们。

第 6 段(可获 1.8 积分)

5. 监测

对于可用性和性能,我们依靠三个综合工具:在内部,Sitescope(一个无代理应用性能监控软件)运行在17个数据中心中,在外部有两个综合工具。我们希望从尽量多的工具中得到尽量多的数据点。不投入多种工具的代价太高了。这一整套服务等级管理项目每年都部署和运行的代价很高,但我同时知道不这么做的代价更高。

对于监测,我们清楚地意识到,我们需要从尽量多的有利位置,进行尽量频繁的测试:

第 7 段(可获 1.31 积分)
  • 如果你每小时测试一次SLO终点,每次检查后你不得不等待59分钟!因此你可能会错误计算停机时间。
  • 你需要尽量多的数据点来保证统计显著性。你可以使用小的数据集,但你可能会获得较低的统计功效和准确率。更大的数据集同时能够让你更好地处理假阳性和假阴性。

6. 性能 (速度) 监测

我们遇到的最大的困难之一,是找到一个测量第三方提供商的性能的有效方法——并将这项技术用于SLA。

第 8 段(可获 1.16 积分)

其中存在的挑战是,客户会关注他们网站的性能,看到其中的峰谷值,并归因于我们的系统。但与此同时,我们系统的性能图表不会显示任何问题。我们无法关联两个图表,因此我们无法得到这究竟是我们的问题还是别人的问题的共识。

我们创建了一个我们称为“有差别的性能测量”(Differential Performance Measurement ,DPM)的方法。

在DPM背后的设计哲学是,尽量准确地测量我们公司(Doubleclick)服务的性能和可用性,并评估其对我们客户的网页的影响,确保我们只为我们能控制的事情负责和买单,消除客户的责难。

第 9 段(可获 1.44 积分)

这个方法为测量增加了上下文。DPM引入了清晰性和对比性,从SLA中移除了绝对的性能数值。

有差别的性能测量(DPM)的“配方”——详细设计(基于一个广告来举例):

1- 选取两个页面,一个没有广告,一个有广告加载。

  • 页面 A = 无广告
  • 页面 B = 有广告

2- 确保页面不包括任何其他的第三方引用(如内容分发网络CDN等)。

3- 确保页面大小 (以KB为单位) 是一样的.

4- “烘焙” – 测量两个页面的响应时间,你将获得下面的指标:

  • 有差别的响应(Differential Response,DR)= (页面B的响应时间) 减去 (页面A的响应时间)
  • 有差别的响应百分比 (Differential Response Percentage,DRP) = DR / A. (例如:若页面A的响应时间是2秒,页面B的响应时间是2.1秒,则DR是0.1秒,DRP是0.1/2=0.05,或5%)
第 10 段(可获 1.75 积分)

利用这个方法,我们能够消除由下列因素引入的噪音:

  • 我们无法控制的,与网络状况相关的问题(如光纤断裂等)
  • 监测客户端的问题(这引发了一个完全独立的话题:监测你的监测服务)
  • 其他第三方提供商的问题

  • 场景1: 广告投放公司存在性能问题,并负面影响了客户网站的性能。厂商违反了SLA 4~8倍。
  • 场景2: 网站自身存在性能问题,该问题不是广告投放公司引起的。
第 11 段(可获 1.06 积分)

7. 报告

因为前面提到的大额赔付,整个SLM项目获得了大量的关注,甚至“上达天听”到了CEO那里。我们每月汇报一次对SLA的遵从情况,以及我们内部的SLA,SLA的违背可以被实时监测到(多亏了一个叫做DigitalFuel的优秀的工具,可惜现在已经不存在了。)。

外部的SLO仅仅是内部SLO的一个子集;到2001年下半年项目完成时,我们同时跟踪超过100个SLA。

OLA

我再怎么强调这一点也不为过:如果你们希望开始像我们一样控制SLA,你最好尽可能多地报告!同时,也要注意报告是可操作的(上图中绿色,黄色,红色)。

第 12 段(可获 1.33 积分)

一个月度报告的例子:

MonthlyReporting

在每日健康检查会议上的日报例子:

dailyreport

一个“质量之风”出现在DoubleClick里面,因为每个人都统一了这些业务服务指标。没有人想违反SLA,没有人想让客户失望。

8. 总结

在我们完成了这个我认为是21世纪初较为完善、综合的SLM过程实践后,我们能够:

  • 管理上百个多达5个SLO的合同
  • 提供多种可扩展(能够增加新产品)的SLA
  • 降低了公司的财务风险
  • 通过提供给客户有意义的SLA,以及准确、完整的汇报,赢得了公司的名声和信誉
  • 提供违背SLA的实时警报。提前知道一个SLA会被违背是不可能的。我们能够知道增加4分钟的停机时间将会违反12个合同并导致X美元的赔付,因此运营部门会采取措施来停止包括版本发布的任何能够影响正常运行时间的行为。
第 13 段(可获 2.14 积分)

有些人不信任SLA。劣质的SLA是指一些公司在合同里面不提及实际赔付,或未经实际测量的条款。我经常看到有些保证0%丢包率的SLA,但如果你问起这是怎么测量的,你很快会意识到这条SLA是无用的——正是这种情况给SLA带来了坏名声。

我相信SLA是能够统一客户和服务提供商意见,减少摩擦,消除互相指责的优秀方式。但是客户们总需要完成他们的工作,并要求有用的SLA。关键是,你要保证服务提供商是负责的,而不是让他们破产失业。你希望他们体会到,当他们没有提供你为之付费的服务时,没有做好工作的痛苦。

随着我们世界的“云化”的扩展,SLA仍将存在,甚至将变得更为流行和普遍。云服务器、云应用(Office365,Salesforce等)、云服务(DNS,CDN,安全等)等“云”的使用者将发现,他们的客户会要求更多有意义的SLA,更严格的执行,以及更大的赔付。这是走向前方的唯一方向。

第 14 段(可获 2.39 积分)

文章评论