共计 2603 个字符，预计需要花费 7 分钟才能阅读完成。
简介：稳定性与高可用性是陈词滥调的两个词。凭借教训和感触咱们晓得，进步零碎的这两项指标，零碎会更加衰弱，产品也会有更好的用户体验。然而如果要给稳定性和高可用性下一个定义该如何表述？稳定性和高可用性这二者又有何区别和分割？我认为首先要了解好这两个问题，才可能设定清晰的指标，系统地制订残缺可行的计划。
作者 | 字恒
深刻了解稳定性与高可用性
稳定性与高可用性是陈词滥调的两个词。凭借教训和感触咱们晓得，进步零碎的这两项指标，零碎会更加衰弱，产品也会有更好的用户体验。然而如果要给稳定性和高可用性下一个定义该如何表述？稳定性和高可用性这二者又有何区别和分割？我认为首先要了解好这两个问题，才可能设定清晰的指标，系统地制订残缺可行的计划。
在维基百科上搜寻稳定性，定义如下：
稳定性是数学或工程上的用语，判断一零碎在有界的输出是否也产生有界的输入。若是，称零碎为稳固；若否，则称零碎为不稳固。
再看看高可用性的：
高可用性（英语：high availability，缩写为 HA），IT 术语，指零碎无中断地执行其性能的能力，代表零碎的可用性水平。是进行零碎设计时的准则之一。高可用性零碎与形成该零碎的各个组件相比能够更长时间运行。
首先从稳定性的定义中提炼出要害的词语 — 零碎、输出、输入。在蚂蚁当下的技术架构中，能够把一个利用当做零碎，利用之间的服务申请为输出，服务响应为输入，当服务响应合乎预期时认为利用零碎是稳固的。当他们互相组合造成一个更大的零碎，作为业务产品对用户表白时，用户的申请作为输出，产品的表白作为输入，当产品性能失常运行时能够认为产品零碎是稳固的。综上，对于稳定性的定义咱们能够总结演绎为 — 当零碎接管输出后，可能产生正确的、合乎预期的输入，称零碎为稳固；否则，称零碎为不稳固。
再回到命题上，为什么叫稳定性保障？能不能换一个说法叫进步稳定性？通过上文的定义咱们能够总结出，稳定性形容的是零碎的行为。一个零碎是否稳固，就像咱们评估一个人是否衰弱一样，很难用陈说的形式进行残缺的形容，去量化。然而却能够通过否定的形式进行疾速地判断。人们通过良好的饮食和生活习惯来缩小疾病的产生，放弃身材的衰弱。保障系统的稳定性或者说进步零碎的稳定性也是如此，咱们须要通过各种办法来防止那些不稳固的状况产生。所谓的更稳固，主观上并不存在，是主观上心愿防止或者缩小不稳固的状况产生。
与稳定性不同，可用性是一个能够量化的指标，计算的公式在维基百科中是这样形容的：
依据零碎侵害、无奈应用的工夫，以及由无奈运作复原到可运作情况的工夫，与零碎总运作工夫的比拟。
咱们常常听到的 3 个 9（99.9%），4 个 9（99.99%）度量的就是零碎的可用性，高可用就是要保证系统的这个指标维持在一个高水平。在公式的定义形容中，将零碎的运行工夫分成了三个局部：
- 零碎失常运作的工夫，即零碎处于稳固状态的工夫。
- 零碎侵害、无奈应用的工夫，即零碎处于非稳固状态的工夫。
- 零碎由无奈运作复原到可运作情况的工夫，即零碎由非稳固状态复原到稳固状态的工夫。
零碎的可用性和零碎的稳定性是成正相干的。不过在现实生活中，零碎是不可能永远处于稳固状态。逆向思考，将上述的公式进行转换，更有利于咱们进行剖析：
至此，本次命题的指标，KPI 就清晰了。保障系统的稳定性和高可用的指标是使零碎处于稳固的工作状态，对用户不产生负面的影响，防止线上问题和 P 级故障的产生。外围 kpi 是零碎的可用性。为了进步零碎的可用性，咱们应该首先保障系统的稳定性，缩小非稳固情况的产生，其次当零碎因为各个组成部分产生故障，呈现非稳固状态时，可能疾速发现并将其复原到稳固可用的状态。
稳定性与高可用保障的外围思路
通过上文的推演，针对进步零碎可用性这一指标，咱们可能失去两个根本的解题思路。按图索骥，为了解决问题，首要的工作是发现和定义问题。因而为了进步零碎的稳定性，咱们先列举利用零碎中常见的非稳固的状况，再一一隔靴搔痒：
性能：应用程序执行的性能呈现谬误，不合乎预期。
容量：当零碎接管的申请数量减少时，应用程序无奈失常解决，出现异常或超时，导致服务生效。
平安：当零碎接管到的没有受权的或者歹意攻打的申请时，应用程序出现异常甚至服务生效。
容错：对于用户谬误的应用形式, 应用程序无奈适合地解决。
当上述情况产生时，就意味着零碎处于不稳固的状态，须要咱们可能及时发现并进行解决。而造成这些问题的起因，在软件系统中通常能够归结为以下三类：
人为故障：在开发软件的各个环节中思考不充沛，或者执行时大意导致的各类问题。
硬件故障：网络不通，硬盘空间不够，内存解体等。
软件故障：线程池异样，JVM 异样，中间件或其余依赖的应用服务异样。
对于一个动静演进的零碎而言，咱们没有方法将故障产生的概率降为 0，只能通过在软件生产的过程中，建设流程标准和机制来尽量减少其产生。其次对于一个运行的零碎，咱们须要建设并欠缺监控和预警机制来及时发现零碎中的故障，并通过执行预案使零碎疾速复原。
基于上述论断，为了进步零碎的可用性，须要从以下三个方面动手发展工作：故障预防，故障发现和故障复原。image.gif 人犯错的几率是远远大于机器的，因而故障预防最重要的是建设一套机制，在团队内达成共识并继续依照此流程发展研发工作，从而缩小集体因素（思考、执行、状态等方面）对系统稳定性的影响。而故障发现以及故障复原，则是须要通过系统监控和应急计划来疾速发现零碎异样并复原，从而尽量加重故障的影响面。上面以蚂蚁日常的产品研发流程为例，从性能、容量、平安、容错这 4 个外围因素登程，给出一套计划仅供参考。
研发标准
设计阶段
- 团队细分文档模板
- 高可用设计规范
编码阶段
代码标准
- 通用代码标准
- 工程构造标准
单测覆盖率
- 单测通过率
- 代码覆盖率
- 日志标准
- 安全漏洞修复标准
公布阶段
- 变更标准：三板斧
容量保障
容量评估
- 机器容量
- DB 容量
- 缓存容量
- 压测摸底
- 限流计划
- 降级计划
监控告警
- 日志标准
- 监控梳理
- 利用根底监控
- 网关监控
- 服务监控
- 业务监控
- 限流监控
- 告警标准
- 数据核查
应急快反
日常预案
- 硬件异样预案
- 中间件异样预案
- 业务异样预案
- 大促预案
- 预案执行标准
总结
如何做好稳定性和高可用保障是一个很宏大的命题，其中的任一小部分内容在内网都能够搜到大量的文章。写这篇文章的目标是总结一下本人对稳定性和高可用保障工作的了解，给大家分享一套零碎的框架思路。心愿大家在读后可能更全面的理解平安生产，不陷于细节。
原文链接
本文为阿里云原创内容，未经容许不得转载。
