在分布式服务中，稳定性（Stability）通常被定义为系统在面对各种内部和外部扰动时，持续提供预期功能和性能的能力。扰动可以包括硬件故障、软件错误、流量激增、网络抖动、操作失误，甚至极端情况下的多重故障叠加。一个稳定的系统不仅要能够在这些事件发生时快速恢复，还需尽可能减少对用户体验的负面影响，甚至做到“用户无感”。
在当今数字化浪潮中，越来越多的企业正在依赖云服务或内部基础设施来支持其日常运营和发展。IT 基础设施的稳定性，对企业的影响也日益增大。特别是云服务，已经慢慢成为企业基础设施中的”水和电“，是不可或缺的一部分，一但这些 IT 基础设施长时间宕机，对企业会造成巨大的影响。
我们来看几个实际的案例：
- 2023年11月27日晚间，多名网友在社交平台反映滴滴出行App疑似故障，出现了无法定位，或者显示网络异常等情况。11月29日回应称，初步确定这起事故的起因是底层系统软件发生故障，并非网传的“遭受攻击”。
- 2023年11月12日17:44分，阿里云遭遇了一场罕见的大规模故障，全国多个地域的云产品控制台访问及API调用出现异常，影响了阿里云的核心业务，包括淘宝、闲鱼、钉钉等。这场故障持续了近两个小时，期间，阿里云的工程师们紧急介入排查和处理，最终在19:20分左右，恢复了正常服务。
- 2022年12月18日，阿里云香港 Region 可用区 C 发生大规模服务中断事件。由于香港Region可用区C机房冷却系统失效，包间温度逐渐升高，导致一机房包间温度达到临界值触发消防系统喷淋，电源柜和多列机柜进水，部分机器硬件损坏。整个处置过程超过10小时。彼时，澳门特区司法警察局曾发布公告，由于阿里云的香港机房节点发生故障，导致澳门金融管理局、澳门银河、莲花卫视、澳门水泥厂等关键基础设施营运者的网站、澳觅和MFood等外卖平台、以及澳门日报等本地传媒应用程式，自当日中午开始暂时无法访问使用。
- 2022年.6.13：华为云华南-广州区域公网访问异常，持续30分钟以上。
- 2018年11月23日亚马逊网络服务（AWS）的核心服务器在韩国全国发生中断，导致两个主要的加密货币在线交易平台停止运作。AWS是全球广泛使用的云服务之一，受到内部核心服务器故障的影响，导致主要的数字资产交易平台Upbit和Coinone戛然而止。据外媒报道，几个主要的电子商务中心在大约一个小时内也无法访问。
对于云服务供应商来说，如何让云更稳定，不仅关系到客户的收益，也关系到自身品牌的口碑。稳定性是所有问题的基础，稳定性的建设，无论在哪个企业，都是至关重要的。
系统地学习稳定性建设对于研发（开发）、运维和QA（质量保证）在以下方面都有重要作用：
如果是研发来说，系统地学习稳定性建设可以帮助研发团队识别和解决潜在的稳定性问题，从而提高软件的质量。这包括减少崩溃、错误和故障的发生，提高系统的可靠性和稳定性。
对于运维或 SRE 来说，运维团队可以优化系统的配置、监控和自动化管理，以提高系统的可用性。这有助于减少服务中断时间，提供持续稳定的服务，满足用户的需求。
对于QA（质量保证）来说，稳定性建设可以引导QA团队在测试过程中关注系统的稳定性和可靠性，帮助QA团队制定更有效的测试策略和计划。这包括制定稳定性测试用例、模拟不稳定环境下的场景、进行负载测试等，以验证系统在各种条件下的表现和稳定性。他们可以参与系统设计、架构评审和缺陷修复过程，为改进系统的稳定性提供有价值的意见。
对于工作不到3年的职场新人来说，系统地学习稳定性建设可以帮助职场新人建立坚实的职业基础，了解稳定性的概念、原则和最佳实践。
对于求职面试的人来说，系统地学习稳定性建设可以展示综合能力、对质量的重视、问题解决能力，并提供实践案例。笔者在做面试官的时候，也比较喜欢问候选人关于稳定性建设相关的工作，从结果上看，能把相关问题回答比较好的候选人寥寥无几。很多候选人对于系统如何部署上线，如何处理单点问题，如何规避并发问题都非常陌生，或者只能模糊地谈谈，基于认为这些是运维该做的事情。如果候选人借机展示自己的问题解决能力，提供针对性的解决方案和建议，那么将会大大加分。
综上所述，无论你是哪种角色，系统地学习稳定性建设都有相当不错的意义和现实收益。
我们明白了稳定性的概念后，下一个问题是，我们如何衡量稳定性呢？通常业界最常用的指标有：
- 可靠性（Reliability）：可靠性是指系统在给定时间内正常运行的概率。可以通过计算系统的故障率、平均无故障时间（MTTF）和平均修复时间（MTTR）等指标来评估系统的可靠性。
- 可用性（Availability）：可用性是指系统在给定时间内处于可操作状态的概率。通常以百分比形式表示，表明系统在特定时间段内处于运行状态而不是停机状态的时间比例。较高的可用性意味着系统对用户而言更加可靠和可访问。
- RTO（Recovery Time Objective）：恢复时间目标，以时间为单位。即在灾难发生后，信息系统或业务功能从停止到必须恢复的时间要求。RTO标志系统能够容忍的服务停止的最长时间。系统服务的紧迫性要求越高，RTO的值越小。
- RPO（Recovery Point Object）：数据恢复点目标，以时间为单位。即在灾难发生时，系统和数据必须恢复的时间点要求。RPO标志系统能够容忍的最大数据丢失量。系统容忍丢失的数据量越小，RPO的值越小。
另外还有几个大家常见的名词：SLI、SLO和 SLA。
SLI：Service Level Indicator 服务水平指示器，服务水平，简称SLI。对于业务来说是最重要的指标。比如，对于网站来说，一个常见的SLI是请求得到正常响应的百分比。
SLO：Service Level Object 服务水平目标，是围绕SLI构建的目标。通常是一个百分比，并与一个时间范围挂钩。比如，月度、季度、年度等。通常用一连串9来度量。如果脱离了时间的度量，SLO的意义就不大了。
SLA：Service Level Agreement 服务水平协议，是企业围绕SLO发布的协议。它要求在不满足SLO时向客户补偿的协议。
以上的概念，有助于我们初步了解如何衡量稳定性。当然，跟其他人交流的时候，我们也会更专业一些，起码不要再问“你们服务的 SLA 是多少”，而应该问“你们服务的可用性 SLO是多少”。
可用性（Availability）被定义为系统的一个属性，它说明系统已准备好，马上就可以使用。换句话说，高度可用的系统在任何给定的时刻都能及时地工作。可用性关注的是服务总体的持续时间，系统在给定时间内总体的运行时间越长，可用性越高。
| 可用性级别 | 年度宕机时间（以365天为例） | 月宕机时间（以30天为例） | 周宕机时间 | 日宕机时间 |
|---|---|---|---|---|
| 90% | 36.5天 | 72小时 | 16.8小时 | 2.4小时 |
| 99% | 87.6小时 | 7.2小时 | 1.68小时 | 14分钟 |
| 99.9% | 8.76小时 | 43分钟 | 10.1分钟 | 86秒 |
| 99.95% | 4.4小时 | 22分钟 | 5分钟 | 43秒 |
| 99.99% | 52.6分钟 | 4.3分钟 | 1.01分钟 | 8.6秒 |
| 99.999% | 5.26分钟 | 26秒 | 6.05秒 | 0.86秒 |
而公有云在结算可用性的时候，最常用的周期，是以自然月为单位。
以火山引擎为例，对于单ECS实例，如服务可用性低于99.975%，可按照下表中的标准获得赔偿：
| 服务可用性 | 赔偿代金券金额 |
|---|---|
| 低于99.975%但等于或高于99% | 月度服务费的10% |
| 低于99%但等于或高于95% | 月度服务费的25% |
| 低于95% | 月度服务费的100% |
可靠性（Reliability）是指系统可以无故障地持续运行。与可用性相反，可靠性是根据时间间隔而不是任何时刻来进行定义的。可靠性相关的几个指标如下：
**MTBF（Mean Time Between Failure）**即平均无故障时间，是指从新的产品在规定的工作环境条件下开始工作到出现第一个故障的时间的平均值。MTBF越长表示可靠性越高，正确工作能力越强 。
**MTTR（Mean Time To Repair）**即平均修复时间，是指可修复产品的平均修复时间，就是从出现故障到修复中间的这段时间。MTTR越短表示易恢复性越好。
**MTTF（Mean Time To Failure）**即平均失效时间。系统平均能够正常运行多长时间，才发生一次故障。系统的可靠性越高，平均无故障时间越长。
这些指标跟可用性关系Availability = UpTime/(UpTime+DownTime) = MTBF / (MTBF + MTTR)
我们举个一个例子来说明二者的区别：如果系统在每小时崩溃1ms，那么它的可用性就超过99.9999%，但是它还是高度不可靠，因为它只能无故障运行1小时。与之类似，如果一个系统从来不崩溃，但是每年要停机两星期，那么它是高度可靠的，但是可用性只有96%。
可用性和可靠性这两个概念很接近，感兴趣的可以看这一篇进行更细粒度的了解。
- 可靠性和可用性是稳定性的重要组成部分：
- 系统的可靠性和可用性是稳定性得以实现的基础。
- 如果系统在长时间内频繁发生故障（可靠性差），或在短时间内长时间宕机（可用性差），则无法被称为“稳定”。
- 反之，稳定性较差的系统可能会间接影响可靠性和可用性，因为扰动容易引发故障。
| 属性 | 核心问题 | 关键指标 | 时间跨度 | 目标 |
|---|---|---|---|---|
| 可靠性 | 输出是否正确且一致 | MTBF（平均无故障时间） | 长期 | 确保系统在指定时间内无故障运行 |
| 可用性 | 服务是否可用、响应是否及时 | SLA、正常运行时间比例 | 短期 | 确保系统随时可用，即便短暂故障也能快速恢复 |
| 稳定性 | 服务在异常情况下是否能持续可用 | 抗压能力、故障恢复速度 | 短期+长期 | 在扰动下维持系统的可用性和可靠性 |
通常对服务的外部客户而言，服务提供者承诺相关的 SLO 指标，主要是以可用性为主。但从服务内部的运维来看，通常会提出更高的要求，例如“5-10-30”：故障要在5分钟内发现，10分钟内定位，30分钟内恢复（止损）。
线上通过统计 5-10-30 的目标达成率，也可以作为稳定性的另外一项指标，通常是面向内部，作为各个产品的稳定性考核项指标。
稳定性的保证，需要有体系化的建设思路，覆盖了整个软件工程的方方面面，从研发，到测试，到上线，到变更，逐步落地，层层护航，是一个庞杂的系统化工程。
笔者将会按事前防御、事中应对、事后复盘、流程规范四个部分展开，力求对稳定性的建设有个全面的说明，希望读者在阅读后可以有些收获。
- 事前防御：事故发生之前的准备工作，目标是防范于未然，减少风险。包括但不限制于：架构设计的准备、可观测能力的建设、自动化测试、故障演练等等。
- 事中应对：事故发生后的处理工作。包括但不限于：应急预案执行、容灾切换、故障自愈等等。
- 事后复盘：事故恢复后的复盘工作，目标是问题的闭环。
注：有些工作可能是事前准备的，比如告警，但是事中也会用到，那属于事前还是事中呢？笔者的建议是：看看相关功能是“事前”用得多，还是“事中”用得多来区别。不过多纠结这个问题，我们只要做到不要遗漏即可。
稳定性的重点，在于如何做好事前防御和事中应对。