如何更好的衡量IT服务质量？

image

还在用平均响应时间衡量你的业务KPI？

看看新的指标吧~

关于性能

• 作为互联网后端大军的一员，除了应对日常的各种需求工作，同时还要有效的保障自己手里的服务质量，如何衡量服务质量的优劣（SLA），目前有常见的几种方式：

1. MTBF

• 即平均无故障时间，也就是常见的N个9问题，如5个9的可用性，全年可宕机时间就是5分钟，详见下图，这里不做讨论：

  image

2. 性能指标

• 提到性能指标，不得不提的两个细节指标就是QPS（或者TPS）和响应时间：

• 初出茅庐的‘IT菜鸟们’，往往在接触后端服务的时候，会一味的盯着QPS，一直致力于把单机性能压榨到极限，妄图获得一个高QPS的快感

• 但凡有一定工作经验的人，都知道，不考虑响应时间的QPS，就是耍流氓：

  • 还记得双11，你排队却无法支付的尴尬时刻么？
  • 还记得在某06网站抢票，以及大学抢选修课时候，怎么点击都没有响应的窘境么？

• 这一切都是下面这个图所示：

  • 当吞吞量无限增加（用户无限涌入），会导致响应时间（页面不是不响应，而是慢成天位数字）几何倍增加
  响应时间与吞吐量

• 任何做过后端数据库运维、以及有丰富的后端接口开发经验的人，都明白，只有在保证响应时间可用的情况下，追求吞吐量才是有价值的

• 关于上面的细节不做讨论，有兴趣“排队论、利特尔法则了解一下”~

响应时间的探讨

• 随着高速网络、移动网络的兴起，用户被日渐宠坏，你的网站响应时间比别人多1秒，用户都可能接受不了

• 因此，大多数互联网技术人员，都会对各自服务的响应时间进行实时监控

• 于是乎，大部分人使用了各种时间序列数据库，X轴拉一个时间，Y轴拉一个平均响应时间，完事~

  image

• 真的完事了么？

• 一个平均响应时间就足以表达出你的服务质量了么？

• 比较professional的，会增加如下指标：

  • “90% 99% 99.9%响应时间了解一下”
  • “中位数响应时间了解一下”
  • “方差、标准差，数据波动，了解一下”
  image image

• But，今天，我们不介绍这些指标（必经知道的人太多了，不足以显出我们的智(zhuang)慧(bi)）

image

Apdex

是什么？

• 举个例子，沪深三百、道琼斯指数，这些指标是用来衡量股市好坏的指标，原则上讲，你不需要了解所有几百几千支股票的细节，就可以从这些指数上来看出股市行情的好坏
• Apdex就是性能的指数

有啥用？

• 假如你提供的是CDN图片加速服务，你的服务质量标准是200ms（99.9%的用户响应时间在此范围内）
• 假如你的同事，提供的是后端接口服务，SLA定在了50ms以内
• 年底了，老板来看你们的KPI完成了没有
• 请问两个绝对指标不一样的业务，怎么去PK？
• 有了Apdex就可以很好的解决这个问题

怎么算？

• 很简单

• 假设你的服务标准是200ms，你认为，

  • 用户访问在<200的情况下，用户很开心
  • 200-1000ms的情况下，勉强可以忍受
  • 超过1000ms的情况下，不能接受，用户就不看了
  • 那么这个时刻的计算方式如下：
  • (满意用户数+可忍受用户数/2)/总的样本数
  • 即
    image

举例

• 100个用户
• 目标3秒，3-12秒是可忍受

• 其中60个用户低于3秒，30个用户3-12之间，剩余10个在12秒以上，那么：

  
  image
• 0.75就是这个服务在这一时刻的性能指数

Apdex怎么来的？

• Apdex是国外几家公司一起提出的性能监控指标，并且已经形成了一个联盟组织：http://www.apdex.org/index.html

• 国外的一家专做APM的公司New Relic对Apdex有比较详细的描述：https://docs.newrelic.com/docs/apm/new-relic-apm/apdex/apdex-measuring-user-satisfaction

怎么实践？

• 说了这么多，怎么用呢？
• 这个指标的含义真的是太简单、太利于理解了，简单到一条SQL就可以搞定：
  • 假如你是Web服务，已经有明确的响应时间范围指标了
  • 又假如你用了某个时间序列存储数据库，把每条响应时间的原始数据都记录下来了，于是乎，你只需要：
    1. 按照时间戳进行聚合
    2. 每次聚合，计算一下满足RT的有多少，忍受RT的有多少， 总共有多少？
    3. 什么，不知道SQL怎么写？好吧，看这里

# 以500-2000作为参考指标

SELECT
    ts,
  ((sum(url_rt < 500) + (sum((url_rt >= 500) AND (url_rt <= 2000)) * 0.25)) / count(*)) * 100 AS Apdex
  FROM table
GROUP BY ts
ORDER BY ts

• 什么？SQL还能这么写?😀
• 我们使用的是ClickHouse作为APM数据的后端存储，这是一个非常易用、超高性能、支持SQL的分析性数据仓库
• 某业务的原始日志会直接打入ClickHouse，不做聚合
• 使用上述的一条SQL，就可以拿到某个业务的Apdex指标

image

总结

• APM是一个非常复杂的事情，涉及到了后端运维、架构、大数据，以及数据分析等多个领域的交叉结合
• 任何APM、监控等，目的都是为了最终用户的满意程度(End user experience)，因此，只看单一指标、只看平均响应时间，就是耍流氓

Reference

• https://en.wikipedia.org/wiki/Apdex

• https://docs.newrelic.com/docs/apm/new-relic-apm/apdex/apdex-measuring-user-satisfaction