1. 好久没理论创新了
任何互联网产品如果不能对外持续提供稳定服务,必将损失用户信心、口碑和商业利益。为了保障产品可用性和系统稳定性,产品的技术团队会不遗余力地做两件事:
第一块improving工作大家讨论得很多,也做了很多事,今天我们重点讨论第二块quantifying。对于量化产品可用性,业界有很多成熟方法论:
只需对系统数据实施采集、计算分析、可视化展示和异常报警,对绝大多数互联网产品而言,这便足够了。
但是,上述这些指标真的就够了吗?当一个大型产品的用户场景足够复杂,维护团队会不会在止血完一次线上事故之后,望着眼前绿色的请求成功率曲线图,心中嘀咕一句“怎么请求成功率还是那么高,根本就体现不出有一批用户登录失败”,旋即埋头回到这次事故的善后和复盘工作去了。
对于量化产品可用性这块工作,罕见有团队去创新理论。本文将回顾一下以前常用的量化指标的原理及其优缺点,并分享Google G Suite团队(负责Gmail邮箱服务、Drive云存储服务、Chat及时聊天服务、Calendar日历服务、Doc在线文档服务、等产品,后改名叫Google Workspace团队)的一次全新探索,他们提出了一个新指标叫User-Uptime(及其派生出的Windowed User-Uptime)。
致力于系统稳定性建设的童鞋,强烈推荐阅读这篇Google paper原文《Meaningful Availability》(链接地址见文章结尾“参考资料”段落)。
2. 经典的量化指标
先简单回顾和总结一下这些常用指标的原理和优缺点。
2.1 请求成功率Success-Ratio
2.2 系统故障率Incident-Ratio
2.3 故障恢复时间MTTF/MTTR
2.4 错误预算Error-Budget
2.5 服务水平目标SLA/SLO/SLI
2.6 在离线状态Uptime/Downtime
2.7 归纳为两大类
可用性就是好服务在全部服务中的占比,高度抽象的公式如下:
每一种量化指标都站在不同视角去定义和描述“好”good,归纳起来其实就是两大类:基于时间和基于数量。
2.7.1 基于时间time-based metrics
“故障恢复时间”、“在离线状态”、“服务水平目标”等指标都是基于时间维度,它们的计算公式可进一步具象为:
基于时间最大的问题在于:
2.7.2 基于数量count-based metrics
最典型的代表就是“请求成功率”,它的计算公式可具象为:
基于数量的指标不需要任何阈值,令他看起来浑然天成,统计起来也很方便,但它也有自己的问题:
3. 介绍一个新指标
察觉到现有指标存在不足之处,Google G Suite团队决定探索一套新指标。他们认为一个好指标必须满足3个条件,要能体现用户切身感受(meaningful)、数字与用户感受是成比例相关的(proportional)、具备故障源头指导意义(actionable),并且不需要人为设定阈值(否则太需要专家经验,容易过于武断,还需要长期跟踪和调优)。
3.1 用户可用时间user-uptime
3.1.1 定义
姑且先翻译为“用户可用时间”,计算公式如下:
先计算出每个用户(per user)成功使用产品的时间,全部用户加起来求和,作为分子。再计算每个用户成功和失败的时间之和,全部用户加起来再求和,作为分母。二者相除的结果,就是user-uptime。
3.1.2 阐述
3.1.3 两个细节挑战
3.1.3.1 挑战1:判断持续时间
对同一个用户,最简单的情况就是两次相邻请求要么都成功要么都失败,这两次请求的间隔时间的长度就算为求和公式里的一个加数uptime(i)或者downtime(i)。但假如前一次成功后一次失败,或者前一次失败后一次成功,那这段时间算作uptime还是downtime呢?
无非三种选择:
这三种选择如下图所示,综合来看,我们选择第一种方案。
3.1.3.2 挑战2:活跃与不活跃阶段
如果一个用户很久不请求(离开电脑去吃饭了,关掉手机去睡觉了),隔了几小时或者几天才发来下一个请求,该用户的时间轴(提醒:在这套理论里,每个用户是有自己的时间轴的,用户之间的时间轴是独立不相干的)会出现一段很长很长的绿色(或红色)线段。
在这段期间系统对他来说是down还是up呢?或者问,这段时间要算为uptime还是downtime呢?似乎都不合适。谷歌团队引入了一个“cutoff时间”的新概念。如果一个用户两次请求相隔时间超过cutoff时间,这段时间忽略不用于计算uptime和downtime。一个系统可以选定自己的cutoff时长,谷歌团队选择的是用户在线交互平均时间间隔的99线(the 99th percentile of the interarrival time of user requests),对Gmail而言就是30分钟。
克服这两个挑战之后,我们就可以重新定义uptime、downtime及inactivetime:
我们可以说,这里的uptime是特指user-uptime,是站在用户侧看到的uptime,即对用户来说一款互联网产品对他而言,切切实实的正常工作时间。
3.1.4 实验例子
谷歌做了这么一个实验,模仿用户行为随机地向系统发起请求,并故意制造一场持续15分钟的故障(发生在30~45分钟期间),以下图为例,是其中2个用户(user0和user1)的请求分布情况,也是他们俩人使用产品的“亲身体验”。
实验总时间是60分钟,系统故障时间是15分钟(即,系统正常时间是45分钟)。直观来说,这个系统的可用性的期望值应该在45 60=75%左右。那么,实验结果是75%吗?
谷歌将这个实验重复做数千次,并统计出请求成功率(success-ratio)和用户可用时间(user-uptime)两个指标的可用性正态分布图。可以看出:
3.2 累积最小用户可用时间Windowed user-uptime&MCR
3.2.1 定义
大多数互联网产品会计算一个特定周期的可用性,如每天、每周、每月、每季度。如下图,这是严选一个低优先级的内部服务的可用率周报表。这样的报表可以告诉我们可用性的抖动情况,但不能告诉某次事故的影响范围。
对稳定性管理员来说,他内心会希望拥有一张具备这样能力的新图表:呈现系统在过去1分钟的可用性最高是多少,同时呈现过去5分钟、10分钟、1小时、24小时、7天、90天的可用性最高达到多少?谷歌团队创新地引入了两个新概念:
暂且翻译为“窗口化用户可用时间”,缩写为WUU,先给产品选定几个时间长度作为“window窗口”(如1分钟/4分钟/15分钟/1小时/4小时/1天/1周/1月/1季度),将上一章节统计得到的“user-uptime”进一步量化,用窗口长度去平均切割过去一段时间(数日甚至数月)得到多个等长片段,计算每个片段里全体用户的user-uptime比率,得到多个比率(百分比)并从中找出最小值min,就是这个窗口粒度的Windowed user-uptime(WUU)。
暂且翻译为“累积最小用户可用时间”,缩写为MCR。将多个时间窗口按从小到大排列,将每个窗口找到的windowed user-uptime的点相连绘制呈线,这条曲线就是MCR曲线。
3.2.2 阐述
windowed user-uptime的思路是找到同一时间粒度上最差的那一次可用性,并绘制成MCR曲线。谷歌其实就是借鉴了编程语言Real-time Garbage Collector理论中的Minimum-Mutator-Utilization(MMU)思路,MCR和MMU在思路和计算上完全一样。
假如我们给自己的系统绘制MCR,为描述方便只选择过去3天的全部请求,选取的window窗口分别是1分钟、5分钟、15分钟、1小时、6小时和1天一共六个。那么,计算步骤如下:
MCR概念比较新,未接触过这类最小值累积原理(类比GC MMU理论)的童鞋可能一下子不好理解,我们举一张MCR图来说下。从下图可以直观地看出3个信息点(常规的SLA可用率曲线图是无法直观呈现出这些信息的),这款产品:
既然系统稳定性管理员从上一张图已经得知系统发生过一次持续近2小时的故障,从MCR图表下钻到更细粒度的“每分钟可用性”详图便可以知道这次故障在某一天下午13:50开始发生功能异常(影响用户请求),在15:40开始逐步恢复,到16点附近系统可用性爬升回到99.9%理想水位,整个过程持续了约2个小时。
3.2.3 MCR单调递增
谷歌在数学上证明了MCR公式的单调性(monotonicity),篇幅太长这里不赘述,证明过程详见paper原文(5.2、5.3及尾部附录Appendix章节)。也就是说,只要窗口是越来越大,那么MCR曲线只会越走越高,斜率取决于系统真实可用性和故障程度。但MCR曲线是不会往下走的。
通俗地说,1hour的Worst Availability是不会比1分钟的更低。由于1分钟是包含在1小时之内的,如果1分钟的最差可用性为99%,那这1个小时也差不到哪去,肯定不会比99%更低,而只会比99%更高至少持平。
4. 指标的关系
4.1 分开来看
谷歌收集了全部Google G Suite产品(Calendar、Docs、Drive、Gmail、等)在2019年度的用户请求数据(已脱敏),并分别从用户可用时间(user-uptime)及请求成功率(success-ratio)两个角度去计算,向我们展示了这两项指标的作用,以及优劣势。
如开篇所言,Google G Suite团队原先就只有success-ratio图表但看着总觉得哪里不够用,指导性不够,才会去折腾琢磨user-uptime这个新指标。好消息是,试水结果很好,没有白折腾。
可以看出,user-uptime橙线要比成功率的蓝线更高一些。这背后发生了什么?继续往下看。
谷歌G Suite产品的用户构成是:
当发生系统故障(产品功能异常)时,这1%超高频用户会在短时间内刷出大量请求(失败请求),而当系统正常时,这1%超高频用户则会刷出大量成功请求。这些数量太大,在计算success-ratio成功率时极大稀释了另外那99%常规用户的表现。这样的稀释会误导系统的稳定性管理员,过高或过低地误判一次故障在用户的真实影响程度。
X轴是不同的窗口大小,可以看到橙线和蓝线形状和斜率相似,但橙线水位更高。
无论是数据1按时间分布,抑或数据3按窗口累计分布,可以看到user-uptime橙线都要比success-ratio蓝线更高一些。让我们下钻到每分钟的详图,在这个故障发生之前(下图最左侧)和故障恢复之后(下图最右侧),橙线蓝线基本吻合。但是,在故障持续期间两条线有明显偏差,为什么呢?进一步分析,发现是来自一批Google G Suite产品的滥用用户(abusive users),他们使用第三方邮箱产品并设置同步Gmail邮件,但这个第三方产品功能有bug,可以同步中低数量邮件的邮箱,但无法成功同步海量邮件的邮箱,同步过程会报错并立即重试(不断又循环失败下去),重试之前没有间隔一定的休眠时间。
这批滥用用户会拉低请求成功率(success-ratio)指标,并不断上下抖动,但由于请求失败的只是这一小戳用户,其余大量用户的请求全部都成功,用户可用时间(user-uptime)指标看上去就平稳。
4.2 兼容并包,各取所长
从上文数据1、数据2和数据3的分析可以看出,请求成功率这个指标的最大问题在于容易受特殊用户(超高频用户、滥用用户、等)的行为干扰,而用户可用时间这个指标则更加稳健,不易受干扰。
借助上文这两项指标的数据对比,谷歌系统管理员便可以直观意识到有哪些极端用户和意外场景的存在,并进一步追查和优化,如联系第三方邮箱产品并沟通适配同步Gmail邮件的方式等。以前只有请求成功率这一张图,管理员是不易察觉到这样的深层次问题的存在的,可能会盯着蓝线单调地起起伏伏而熟视无睹,现在有了橙线的辅助,偏差一目了然。有偏差,就意味着哪里有问题。下面左图是把2个指标摆一起看,右图是把2个产品摆一起看,一对比,一些隐藏问题就可以跃然纸上。
因此,这两个指标(其它指标亦然)之间不是非黑即白的矛盾关系,而都是系统管理员武器库中的成员,武器种类越多当然越好。而且,这些武器不是那种管理员手上拿着刀便举不了枪的互斥关系,而是手上拿着刀头上还戴多一副红外夜视眼镜的相辅相成关系,让黑夜里数据变得更直观,信息更透明。
4.3 已获得银弹和万能钥匙?
答案是否定的。尽管新指标有诸多优点,新指标与成功率等旧指标摆在一起呈现可以给管理员提供更多信息和线索,但不意味Success-Ratio、MTTF/MTTR、SLA/SLO等旧指标就一无是处,也不意味着User-Uptime新指标就无所不能。举个最常见的例子,某些故障令用户请求根本就达到不了系统(域名DNS失效、机房光纤挖断、等),这些也影响产品可用性和用户体验,但无论Success-Ratio还是User-Uptime都是“灯下黑,睁眼瞎”,需要其它手段。
5. 需求不断,创新不止
回顾Google G Suite团队整个指标创新的过程,我的感觉是这样的:
回到开篇管理员的那声嘀咕,假如你在工作中也浮现过这样的“别扭瞬间”,说明当前的工具或者方法还不够好,说明有创新空间在,说明自己和团队可以抓住这个宝贵的痛点痒点进一步深挖和创造。
可能今天介绍的User-Uptime新指标不一定适用于你的产品你的系统,但这个敢于创新的精神是普世的。再大的痛点也不慌,再小的痒点也不要错过,“从0到1是创新,从1到1.1也是”,与诸君共勉。
页面更新:2024-04-26
本站资料均由网友自行发布提供,仅用于学习交流。如有版权问题,请与我联系,QQ:4156828
© CopyRight 2008-2024 All Rights Reserved. Powered By bs178.com 闽ICP备11008920号-3
闽公网安备35020302034844号