如何更好的衡量IT服务质量?
发布于 9 个月前 作者 jackpgao 523 次浏览 来自 实战经验

还在用平均响应时间衡量你的业务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怎么写?好吧,看这里
# 以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

回到顶部