我们知道，如今的网购、娱乐、物联网等，给我们生活带了诸多便利，这其中很大一部分原因是互联网提供的服务是高可用的，能够随时随地满足你诉求，那么究竟什么是高可用？
什么是高可用？
试想下，你中午需要做饭，想在某平台购买食材，发现该平台不能下单，无法满足你的诉求。我们能说该平台是高可用的吗，显然不能。高可用是面对故障时，服务能够自愈或能够尽最大努力提供有损服务。
那是什么原因导致系统出现故障的呢？其实，可能只是一个小的、随意的原因引起系统的故障，比如：
- 库存不足；
- 新增第三方支付，引起的故障；
- 服务变更，版本兼容引起的故障；
- 触发某安全策略意外拦截，导致无法下单；
- https证书过期导致；
- 优惠券服务导致下单服务出现故障；
- 库存校验失败，引起故障；
- 某依赖云厂商出现硬件故障导致；
- 光纤被挖了；
- ……
对于能够引起系统故障的因素我们称之为影响高可用因素，这块我在下文会讲。
高可用从架构设计角度，可以理解是面向风险设计，也就是指面对风险时，能够提供高可用性的能力，从可靠性角度，可以理解是通过设计减少系统不能提供服务的时间。们在进行系统架构设计时，要考虑拓展性、安全性等等，其中，高可用也是必须要考虑的因素。
如何度量系统可用性？
上面的例子，我们能够大体地认识并了解高可用，所有的系统，必然是一步步地提升系统可用性的，不能一蹴而成，因此我们也要能够知道如何去度量高可用，管理学大师彼得.德鲁克曾说过：“如果你不能度量它，你就无法改进它 ”。
对于高可用的度量，一般从“可用性”和“可靠性”两个维度来描述：
- 可用性：在单位时间内，系统可提供服务的持续时间；
- 可靠性：根据系统平均失效时间来衡量。平均失效时间越短可靠性越高。
首先我们来看可用性。一般我们会用几个9来描述可用性（几个9也通常用来标识服务的SLA，即服务等级协议）。
可用性的计算公式： 可用性=系统无故障运行时间/(系统无故障运行时间+系统故障维护时间)
举个例子：某图书管理平台计划投入运行10天，计划运行时间为每天早8点至晚6点（每天运行10小时），第2天上午9点发生一次故障，故障恢复用了1小时；第5天下午又发生一次故障，故障恢复用了4个小时；第9天上午发生一次故障，故障恢复用了1小时，那么图书管理平台的可用性是多少呢？
- 系统故障恢复时间：一共用了1+4+1=6个小时
- 系统无故障运行时间：7*10+9+6+9=94个小时
- 图书管理平台的可用性：94/(94+6)=94%
通过上述案例能够看到，图书管理平台系统的可用性是94%，才一个9，对于很多平台，系统的可用性要求在三个9以上，要求更为严格的是4个9以上或者5个9。
以年为单位，倒推下，不同要求下对于故障的可容忍时间：
-
1个9：(1-90%)*365=36.5天
-
2个9：(1-99%)*365=3.65天
-
3个9：(1-99.9%)*365*24=8.76小时
-
4个9：(1-99.99%)*365*24=0.876小时=52.6分钟
-
5个9：(1-99.999%)*365*24*60=5.26分钟
所以，当你的系统可用性不满足三个9的时候，你就要注意了，考虑系统的可用性是不是要提高，换句话说一年内有三天多的时间系统是不可用的，无法正常提供服务，带来的损失也是不可估量的，因此，很多平台对系统的可用性要求在三个以上。
说完了可用性，我们再来说一下可靠性。在业界，一般谈到可靠性，必然离不开MTTR平均修复时间、MTBF平均无故障时间、MTTF平均失效时间这三个指标，在前面也讲到过平均失效时间越短可靠性越高。
- MTTR平均修复时间，它的计算方式是：MTTR=维护时间总和/维护次数之和，比如计算图书管理平台的MTTR：6/3=2个小时。MTTR反应出对线上响应和问题修复的效率，MTTR的数值越小，对故障的修复效率越高。
- MTBF平均无故障时间，它的计算方式是：MTBF=总运行时间/总失败次数，比如计算图书管理平台的MTBF：94/3≈31个小时。MTBF反应出系统的可用性，系统的可用性越高，平均无故障时间越长。
- MTTF平均失效时间，它的计算方式是：MTTF= 服务副本数的总运行时间/副本数，我们还是来计算图书管理平台的MTTF：图书管理平台是单机部署，所以只有一个副本，故MTTF：94/1=94个小时。MTTF反应出系统的故障间隔周期，该数值越低，说明系统故障的频率越频繁。
知道了什么是可用性和可靠性，那对于一个稳定性系统来说，哪一点更重要呢？
其实，系统的首要目标是先降低故障的次数，频率要低，从而提高可靠性；同时在故障出现后，要提高故障的恢复时间，速度要快，从而提高业务的可用性。
我们举个例子来说明二者的区别。如果系统在每小时崩溃1ms，那么它的可用性就超过99.9999%，但是它还是高度不可靠，因为它只能无故障运行1小时。与之类似，如果一个系统从来不崩溃，但是每年要停机两星期，那么它是可靠的，但是可用性只有96%。
还有个问题：为什么大家经常讲提升系统可用性（稳定性），而不经常提到可靠性呢？我认为可用性包含可靠性，理由是假设系统不可靠，那么面临的问题可能是业务Bug或者导致系统出错等情况，这些是不允许的，如果存在这些漏洞是无法上线的，所以大家经常讲可用性。
业界也有很多典型的案例，可以从中了解到对于有足够影响力的平台，一旦出现故障导致不可用，那也将影响着我们的生活，供我们参考和学习：
-
2020年国庆前一天，受“2020年最难打车日”的需求影响，滴滴平台和嘀嗒平台相继出现宕机故障；
-
2018年亚马逊prime day：亚马逊会员日故障（顾客无法将商品添加到购物车结账），导致公司损失高达9900万美元。
-
2015年由于中国工商银行部分地区因计算机系统升级，造成柜面和电子渠道业务办理缓慢，甚至不能受理业务
-
2012年12306铁路订票网站因机房空调系统故障，导致暂停互联网售票、退票、改签业务。
构建高可用系统，面临哪些难题？
不过，打造高可用系统，这个话题还是相对来说比较虚。高可用构建不是一个点，而是所有点组合的一个结果。不像技术案例具体可实现，高可用更抽象，需要有足够的技术视野，需要能够观测并提前做好布局。即便如此，在构建稳定性时，还是会遇到很多难题。
- 难题一：业务变化之快
对于一个业务来说，不同阶段业务目标是不同的，对系统的要求也是如此：业务初期的要求迭代效率，业务中期的要求是业务起量，业务长期的要求是高可用（稳定性）。需要注意的是，面对业务的快速发展及不确定性，想要提升系统稳定性，需要贴合业务的节奏，对于影响稳定性高严重性、高可能性的风险进行风险管控处理。
例如：我们针对某个核心关键流程进行优化、容错、解耦设计，这个改动可能涉及系统层面从上到下的多处修改，包括数据结构调整、业务逻辑改造、数据交互方式等等，可能上线一段时间，因业务变化，该业务废弃，那么前期所做的一切都是无用功。
面对业务的快速，我们对服务的优化和改造，一定要有远瞻性，可以提前做好稳定性建设布局：
- 基础设施建设，比如：日志、监控、告警、分布式配置中心；
- 通用性业务组件建设，比如：分布式锁、限流、熔断器；
- 洞察业务趋势，做好技术储备。
- 难题二：构建范围之广
稳定性建设需要从全局视角总览，建设范围广，工作量大，其中包括研发、测试、运维、DBA等多个角色，流程规范，变更管理，涉及架构设计、数据库、缓存、消息队列等。
例如：我们可能针对某个核心关键流程进行优化、容错、解耦设计，这个改动可能涉及系统层面从上到下的多处修改，包括数据结构调整、业务逻辑改造、数据交互方式等，涉及诸多方面，很可能有遗漏或bug，导致严重的事故，需要有逐一确认某个细节及强有力的测试才可以。
在构建范围上，可以考虑从以下几个维度入手：
- 业务上，要面向异常情况考虑，比如：页面加载失败、要友好提示；
- 技术方案上，要面向失败设计，比如：数据一致性、强依赖失败；
- 核心关键流程上，要标准化，比如：上线审批流程、技术方案评审必须由架构师确认；
- 工具上，要尽可能自动化、避免人为操作，比如：部署系统。
- 难题三：实施成本之高
稳定性建设是需要投入一定的成本，带来的收益也是隐形的，不像业务目标那么明显。一般情况下，业务上不会给技术做稳定性建设的，除非是业务已取得一定的收益，业务模型已形成闭环，此刻业务为了走的更远，打稳地基，允许投入一定的成本做稳定性建设。
不过技术债，还是要尽早还，因为坐在前期的成本要小很多。比如，服务依赖不合理，前期调整比后期调整的成本就要小的多。
影响稳定性因素有哪些？
在前面我们举了个买菜的例子，能够看到影响稳定性的因素有很多，比如网络通信、证书协议出了问题，或者配置信息有误等，为了便于我们理解和记忆，我这里对影响稳定性的因素进行抽象的总结，分为：人为因素、自然因素两大类。
以下为我简单总结的思维脑图，供参考：
系统的一砖一瓦都是我们自己搭建起来的，对于系统的稳定性，人为因素占比还是比较大的，相信大家都是深入感触，下面拿几个因素简要说明下：
- 研发流程方面
很多公司的稳定性都是通过流程规范来保障的，人总是不可靠的，当然不是说人不靠谱，原因是人为的操作过程中，可能出现丢三落四的情况，故尽可能把所有流程都流程化、标准化、自动化，减少人为的过多的干预。
例如：变更管理流程，涉及很多环节开发、测试、预发、灰度、小流程、全量，DB结构变更等等，很多公司都有相应的系统，而这个系统实际上是将变更管理所有要做的点做了自动化，避免了人直接操作，通过系统来避免出错，从而保障稳定性。
题外话：在很多公司，对于线上数据出现不一致的情况，那么该如何修复数据，怎么操作呢？
第一种做法：通过数据库客户端直接修改。
第二种做法：先将修复的数据备份，通过SQL语句直接修改。
第三种做法：通过shell或者python脚本，编写sql，通过执行脚本修复。
对于这种三种方法，你觉得那种比较合适呢？
- 代码方面
代码问题和研发人员水平有很大关系，例如对某段逻辑处理错误、参数校验合法性、异常逻辑处理、是否死循环、第三方依赖库是否正确使用等等。
关于代码问题，可以通过第三方工具进行代码检测，提前发现一些问题。工具可以帮助检测的内容如下：不遵循代码标准、潜在的缺陷、糟糕的复杂度分布、重复、注释不足或者过多、缺乏单元测试、糟糕的设计等，避免这些问题带到生成环境。
例如：非法数据输入，像入参的校验，我们是否做到参数非空、长度、数值类型、范围等多个维度的校验。
- 配置方面
很多研发工程师对配置参数了解的很少，大多数沿用默认的，像数据库连接池、消息队列重试次数、超时时间，中间件（Kafka、Redis）配置参数，对参数配置是否合理完全不感知。
当然我不是反对用默认的参数配置，而是说你要提前了解每个参数配置决定什么，对应起到什么作用，面对不同的业务场景配置合理的参数。
例如：超时参数配置，对于用TO-C服务、TO-B服务（业务后台）可能某些接口超时参数是不一样的，可能对TO-C比较短，业务最快响应，对TO-B可能面对某些大数据库查询，超时时间也是不一样的，需要根据业务场景及接口区分开合理配置。
再例如：重试次数配置，重试次数1和3的区别很大，因为是每个请求连接可能可能会流量放大1倍或3倍，试想下，重试参数配置很简单，带来的效果是完全不一样的，针对不同的场景对重试次数合理配置，或不配置用户侧重试，其实是对服务的一种保护机制。
小结
今天我们的学习，能够让你知道什么是高可用，理解度量可用性的方法；学完这篇文章，你还可以尝试着评估你负责的业务系统可用性。同时我们也分析了构建高可用系统面临的现实问题，以及分析现实场景中存在着影响高可用的因素。
标签：故障,可用,可用性,系统,业务,稳定性,如何,理解 来源： https://blog.csdn.net/u013045746/article/details/122128759
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。