系统可用性衡量指标学习

本文最后更新于2018年4月30日,已超过 1 年没有更新,如果文章内容失效,还请反馈给我,谢谢!

=Start=

缘由:

想整理一下最近看到的或是想到的关于系统可用性衡量的一些指标,一方面是在整理中学习,另一方面是为了方便以后检索和参考。

正文:

参考解答:

1. MTBF——全称是Mean Time Between Failure,即平均无故障工作时间。就是从新的产品在规定的工作环境条件下开始工作到出现第一个故障的时间的平均值。MTBF越长表示可靠性越高、正确工作能力越强 。

2. MTTR——全称是Mean Time To Repair,即平均修复时间。是指可修复产品的平均修复时间,就是从出现故障到修复中间的这段时间。MTTR越短表示易恢复性越好。

3. MTTF——全称是Mean Time To Failure,即平均失效时间。系统平均能够正常运行多长时间,才发生一次故障。系统的可靠性越高,平均无故障时间越长。

MTBF = MTTF + MTTR


&

  • 发现时长/发现方(Meam Time To Detect/Identify)
  • 响应时长/事故处理流程(Mean Time To Response)
  • 定位时长/定位方(Mean Time To Diagnose)
  • 处理时长/处理方(Mean Time To Fix)
  • 影响时长/影响方(Mean Time To Resolve)
  • 损失/定级

可靠性是最初是确定一个系统在一个特定的运行时间内有效运行的概率的一个标准。可靠性的衡量需要系统在某段时间内保持正常的运行。

目前,使用最为广泛的一个衡量可靠性的参数是,MTTF(mean time to failure,平均失效时间),定义为随机变量、出错时间等的”期望值”。但是,MTTF经常被错误地理解为,”能保证的最短的生命周期”。MTTF的长短,通常与使用周期中的产品有关,其中不包括老化失效。

可用性Availability = MTBF / (MTBF + MTTR),一般我们都是用N个9来表达系统可用性,用宕机时长来说更好理解,如果以全年为周期(24*365=8760个小时),3个9(99.9%)就意味着全年宕机时长是525.6分钟,4个9(99.99%)是52.6分钟,5个9(99.999%)是5分钟。用直观的数据展示如下:

可用性 宕机时间
99.9999% (6个9) 31秒/年
99.999% (5个9) 5分钟/年
99.99% (4个9) 52分钟/年
99.9% (3个9) 8.76小时/年
参考链接:

=END=

声明: 除非注明,ixyzero.com文章均为原创,转载请以链接形式标明本文地址,谢谢!
https://ixyzero.com/blog/archives/3895.html

《系统可用性衡量指标学习》上有6条评论

  1. 亚马逊 CTO:云架构师都应该知道的六大定律
    https://mp.weixin.qq.com/s?__biz=MjM5MzM3NjM4MA==&mid=216101937&idx=2&sn=6f8b260b942ef76a7db142a65b64a70d&scene=21

    1.卢卡斯批判(Lucas Critique)
    “如果完全依赖历史数据中观察到的关系,就预测变化的影响,这是很幼稚的做法。”

    2.盖尔定律(Gall's Law)
    “一个切实可行的复杂系统势必是从一个切实可行的简单系统发展而来的。从头开始设计的复杂系统根本不切实可行,无法修修补补让它切实可行。你必须由一个切实可行的简单系统重新开始。”

    3.迪米特法则(Law of Demeter)
    “每个软件单位对其他单位应该都只有最少的知识,而且局限于那些与本单位密切相关的单位。每个软件单位应该只与它的朋友说话;不要与陌生人说话。”

    4.奥卡姆剃刀定律(Occam's Razor)
    “需要最少假设的那个解释应该被选中。”

    5.里德定律(Reed's Law)
    “大型网络、尤其是社交网络的功效会随着网络规模呈指数级增加。”

    6.格式塔原理(The Gestalt Principle)
    “整体大于部分之和。”

  2. 大众点评账号业务高可用进阶之路
    https://mp.weixin.qq.com/s/Hl05RVxmcea5RRkNjm6upg

    衡量一个系统的可用性有两个指标:
    1. MTBF (Mean Time Between Failure)即平均多长时间不出故障;
    2. MTTR (Mean Time To Recovery)即出故障后的平均恢复时间。

    通过这两个指标可以计算出可用性,也就是我们大家比较熟悉的“几个9”。
    因此提升系统的可用性,就得从这两个指标入手,要么降低故障恢复的时间,要么延长不出故障的时间。

  3. 那些年,云厂商宕机教会我们的事
    https://mp.weixin.qq.com/s/qBgcmwk-YODjrOKPV5iK2Q

    云厂商宕机故障,这些年一直不是什么新闻。
    纵观以上云厂商宕机案例,有的是天灾(机房被雷劈了),有的是人祸(误删除操作),但可以肯定的是:宕机这事儿,预计在很长的一段时间里都无法避免。那么对于吃瓜群众们来说,看完热闹了,要看会什么门道呢?

    要注意Error Handling
    尽可能地把动态内容缓存起来,甚至静态化
    云用户应检查核心依赖关系,提升关键性服务的冗余水平
    故障演习很重要
    处理危机的方式能看出一个公司的高度

  4. 少年,MTBF 和 MTTR 了解下!
    https://mp.weixin.qq.com/s/SHDtek4YVEgjCxOn3y-6Kg

    先上两个概念,
    MTBF :Mean Time Between Fail,粗暴的翻译下,平均出错间隔。拿软件来举例,MTBF 就是出 bug 的平均时间间隔;MTBF 越大,说明你的软件的质量越好,因为很久才出一个 bug。

    再来第二个概念,
    MTTR:Mean Time To Repair, 平均修复的时间。这个在软件行业最好理解,出了一个 bug 平均的修复时间,这个值越小越好,侧面也体现了软件的质量好。小结下: 一个产品它的 MTBF 越大越好,MTTR 越小越好。

发表评论

电子邮件地址不会被公开。 必填项已用*标注