系统稳定性与高可用保障的思考
原文地址：稳定性与高可用保障的工作思路， 本文在原文的基础上做了一些补充和删减。
一、深入理解稳定性与高可用
维基百科上稳定性与高可用性的定义
稳定性
稳定性是数学或工程上的用语，判别一系统在有界的输入是否也产生有界的输出。若是，称系统为稳定；若否，则称系统为不稳定。
关于稳定性的定义我们可以总结归纳为 – 当系统接收输入后，能够产生正确的、符合预期的输出，称系统为稳定；否则，称系统为不稳定。
稳定性描述的是系统的行为，一个系统是否稳定，很难进行量化，但是可以通过否定的方式进行快速地判断。保障系统的稳定性或者说提高系统的稳定性需要通过各种方法来避免那些不稳定的情况发生。所谓的更稳定，客观上并不存在，是主观上希望避免或者减少不稳定的情况发生。
高可用性
高可用性（英语：high availability，缩写为 HA），IT术语，指系统无中断地执行其功能的能力，代表系统的可用性程度。是进行系统设计时的准则之一。高可用性系统与构成该系统的各个组件相比可以更长时间运行。
与稳定性不同，可用性一个可以量化的指标，计算公式在维基百科中描述如下：
根据系统损害、无法使用的时间，以及由无法运作恢复到可运作状态的时间，与系统总运作时间的比较。
计算公式：
- A（可用性）
- MTTR(Mean Time To Repair): 平均修复时间，指系统从发生故障到维修结束之间的时间段的平均值， MTTR越短，表示易恢复性越好。
- MTTF(即 Mean Time To Failure): 平均无故障时间。指系统无故障运行的平均时间，取所有从系统开始正常运行到发生故障之间的时间段的平均值，MTTF越长，表示系统可靠性越高。
- MTBF(Mean Time Between Failures):平均故障间隔，指系统两次故障发生时间之间的时间段的平均值，MTBF越长，表示出现故障出现的越不频繁。
从定义还可以看出，MTBF = MTTR + MTTF。
在线系统和执行关键任务的系统通常要求其可用性要达到5个9标准(99.999%)。
| 可用性 | 年故障时间 |
|---|---|
| 99.9999% | 32秒 |
| 99.999% | 5分15秒 |
| 99.99% | 52分34秒 |
| 99.9% | 8小时46分 |
| 99% | 3天15小时36分 |
以上内容出自:维基百科-高可用性
综上所述，保障系统的稳定系及高可用的目标是使系统处于稳定的工作状态，避免线上问题及故障发生。其次，出现非稳定状态时，能够快速发现并将其恢复到稳定可用的状态。
二、稳定性与高可用保障的核心思路
2.1 应用系统中常见非稳定的情况
功能：应用程序执行的功能出现错误，不符合预期。
容量：当系统接收的请求数量增加时，应用程序无法正常处理，出现异常或超时，导致服务失效。
安全：当系统接收到的没有授权的或者恶意攻击的请求时，应用程序出现异常甚至服务失效。
容错：对于用户错误的使用方式, 应用程序无法合适地处理。
2.2 软件系统问题原因归类
人为故障：在开发软件的各个环节中思考不充分，或者执行时粗心导致的各类问题。
硬件故障：网络不通，硬盘空间不够，内存崩溃等。
软件故障：线程池异常，JVM异常，中间件或其他依赖的应用服务异常。
对于一个动态演进的系统而言，我们没有办法将故障发生的概率降为0，只能通过在软件生产的过程中，建立流程规范和机制来尽量减少其发生。其次对于一个运行的系统，我们需要建立并完善监控和预警机制来及时发现系统中的故障，并通过执行预案使系统快速恢复。基于上述结论，为了提高系统的可用性，需要从以下三个方面入手开展工作：故障预防，故障发现和故障恢复。
人犯错的几率是远远大于机器的，因此故障预防最重要的是建立一套机制，在团队内达成共识并持续按照此流程开展研发工作，从而减少个人因素（思考、执行、状态等方面）对系统稳定性的影响。而故障发现以及故障恢复，则是需要通过系统监控和应急方案来快速发现系统异常并恢复，从而尽量减轻故障的影响面。
2.3 稳定性与高可用保障方案
下面以蚂蚁日常的产品研发流程为例，从功能、容量、安全、容错这4个核心要素出发，给出一套方案仅供参考。
总结
稳定性和高可用是一个很庞大的命题，底层开发者来在设计开发过程中，缺乏一套系统的框架思路，缺少对于稳定性和高可用的方案系统全面的考量。通过对上述稳定性和高可用的理解，可以从故障预防、故障发现、故障恢复三个层面进行稳定性和高可用保障。而对于具体的方案可以从研发规范、容量保障、监控告警、应急快反这四个核心要素制定相关规范，从实现系统的稳定性和高可用的保障。