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

发表于 | 分类于 |

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

看看新的指标吧~

关于性能

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

1. MTBF

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

2. 性能指标

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

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

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

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

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

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

      响应时间与吞吐量

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

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

响应时间的探讨

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

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

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

  • 真的完事了么？

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

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

    • “90% 99% 99.9%响应时间了解一下”
    • “中位数响应时间了解一下”

    • “方差、标准差，数据波动，了解一下”

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

Apdex

是什么？

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

有啥用？

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

怎么算？

  • 很简单

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

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

举例

  • 100个用户
  • 目标3秒，3-12秒是可忍受
  • 其中60个用户低于3秒，30个用户3-12之间，剩余10个在12秒以上，那么：
  • 0.75就是这个服务在这一时刻的性能指数

Apdex怎么来的？

怎么实践？

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

总结

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

Reference

热评文章