高可用性的专业说法应该叫“系统可用性”，也就是“3个9”（99.9%或99.95%）、“4个9”（99.99%或99.995%）。系统可用性和建设SRE的目标强相关，SRE的稳定性目标就是尽量减少系统故障的发生，提升系统可用的时间占比。
目前业界有两种衡量系统可用性的方式，一个是时间维度，一个是请求维度：
时间维度：Availability = Uptime / (Uptime + Downtime) ，是从故障角度出发对系统稳定性进行评估。
请求维度：Availability = Successful request / Total request ，是从成功请求占比的角度出发，对系统的稳定性进行评估。
1、如何从时间维度衡量系统稳定性
从时间维度出发，是如何衡量系统稳定性的？
这类计算方式最常见，不过，在真实的使用场景中，怎样才算是可用时长，怎样又是不可用时长，这个是怎么定义的呢？举个发烧生病的例子。
一个人如果发烧了，体温一般会超过37.5度。那么，如果这个人的体温正好达到这个温度，是不是代表他一定是生病了呢？依据生活经验，不一定。因为判断一个人是否发烧生病，不是只看这一次的体温，还要看他体温是不是持续超过37.5度。
所以，这就涉及到一个测量方法和判定方法的问题，包含三个要素：
**（1）衡量指标，**比如体温就是衡量指标；
**（2）衡量目标，**低于37.5度算正常，超过37.5度就是异常，但是单次测量不能说明问题，可以多次测量，比如6次中有至少4次低于37.5度才算正常，转化成比例的话就是67%；
**（3）影响时长，比如持续超过12小时。
对应到系统上，也是用一系列的标准和判定逻辑来说明系统是否正常。比如，请求成功率低于95%，已经连续超过10分钟，就要算作故障，那么10分钟就要纳入Downtime（宕机时间），如果达不到，就不算作故障，只算作一般或偶然的异常问题。
涉及到系统可用性上，同样有三个要素：衡量指标，系统请求状态码；衡量目标，成功率达到95%；影响时长，持续10分钟。
因此，只有当问题达到一定影响程度才会算作故障，这时才会计算不可用时长，也就是上面公式中的Downtime。同时还要求一个周期内，允许的Downtime，或者说是系统的“生病时间”是有限的，用这个有限时间来约束系统稳定性。
下面是常见的按时长维度统计的可用性对照表，也就是前面提到的几个9：
目前，按照时长维度的稳定性计算方式还有显著问题，稳定性只与故障发生挂钩。
这样做会带来哪些问题？比如有一个系统，因为网络抖动，有短暂的几秒、十几秒，或者几分钟异常，但是后来系统自己恢复了，业务并没有中断，这时按照时长维度来判断，肯定不会算作系统故障。但是如果这种短暂的影响频度非常高，一天有5、6次，持续一两周，应该可以判定系统运行状况也是不正常的，可能不是故障，但肯定是不稳定了。
所以这种用时长维度来衡量系统稳定性的方式，其主要缺点就是粒度不够精细。
2、如何从请求维度衡量系统的稳定性
假定系统一天内有100,000次请求，期望的成功率至少是95%，如果有5001次请求失败了，也就是成功率低于95%了，就认为系统运行状态是不正常的。
请求维度的系统可用性同样包含三个关键要素，
（1）衡量指标，请求成功率；
**（2）衡量目标，**成功率达到95%才算系统运行正常；
**（3）统计周期，**比如一天、一周、一个月等等，是在一个统计周期内计算整体状况，而不是看单次的。
这种方式对系统运行状况是否稳定监管得更为严格，不会漏掉任何一次问题的影响，因为它对系统整体运行的稳定性判定，不仅仅会通过单次的异常影响进行评估，还会累计叠加进行周期性的评估。
3、系统稳定性的衡量标准
知道了两个维度的衡量方式了，那么，系统到底需要几个9才满足要求呢？
这个问题其实并没有标准答案，到底定“几个9”主要取决于以下三个因素。
（1）成本因素。
从理论上来说，肯定是9越多稳定性越好，但是相应付出的成本和代价也会更高。比如为了更高的可用性，要有更多的冗余资源投入，甚至要做主备、双活甚至是多活。
如果一家公司的业务量和影响力都发展到一定程度，那这个成本不管多高都是必须要付出的。但是，肯定不是所有的公司都需要付出这么高的成本，而是要先考虑ROI（回报率）。这时候就要看企业自身对成本压力的承担情况了。
（2）业务容忍度。
稳定性怎么设定，很大程度上还要取决于业务上的容忍度。对于核心业务或核心应用，比如电商的交易和支付系统，当然是希望成功率越高越好，一般对系统稳定性要求是“3个9”或“4个9”。因为这些系统一旦出问题，就会直接影响整个网站和公司的收益，这些都是钱，所以对稳定性要求必然就会提高。
但是，对于非核心业务或应用，比如商品评论，商品评分等，或许“2个9”也能容忍。因为短时间的评论看不到，并不会对业务收入和用户体验造成太大的影响。
（3）系统当前的稳定性状况。
结合系统的实际情况，定一个合理的标准比定一个更高的标准更重要。从系统现状入手，比如，如果系统可用性是低于99%的，那首先第一步是不是可以做到99%，然后再争取做到99.5%，再到99.9%，一步一步朝着更高的标准迈进。