理解系统可靠性：现代基础设施的基础
发布: (2025年12月23日 GMT+8 09:15)
6 min read
原文: Dev.to
Source: Dev.to
想象一下，当你醒来发现公司主应用宕机时的情景。
客户电话此起彼伏。收入以 每小时 100,000 美元 的速度流失。你的团队正手忙脚乱，却不知道从何入手。
这并不是噩梦情节——它是 98 % 的组织 在某个时刻都会面对的现实。问题不在于系统是否会承受压力，而在于它们在压力来临时会 如何响应。这就是可靠性。
可靠性真正的含义
可靠性不仅仅是保持系统在线。它根本上关乎你的应用程序和服务优雅地应对压力和中断。
- 承诺： 当用户需要时，你的系统将正确且始终如一地执行其预期功能。
- 不是“永不失败”： 在复杂的分布式系统中，组件故障是不可避免的。关键在于系统如何响应。
根据 AWS 的 Well‑Architected Framework，可靠的系统具有一个关键特性：它们的设计旨在快速从故障中恢复，而不是防止所有可能的故障。
可靠性是整个系统的属性，而不仅仅是孤立的部分。你的应用程序可能拥有坚如磐石的代码，但如果数据库崩溃且没有故障转移，系统就不可靠。这种整体视角在站点可靠性工程（SRE）实践中被强调，SRE 在基础设施的所有层面上考虑可靠性。
可靠性的三大支柱
| 支柱 | 衡量指标 | 重要原因 |
|---|---|---|
| 可用性 | 服务可用且可访问的时间比例。 | • 99.9 % 正常运行时间 = $100 k 每小时；对大型企业而言，成本可达 每小时数百万美元。 • 客户信任： 88 % 的在线消费者在糟糕体验后不太可能再次光顾。 • 停机会损害品牌声誉，并为竞争对手争取用户提供机会。 |
| 延迟 | 响应请求所需的时间。 | 高延迟会降低用户体验，甚至导致流失。 |
| 持久性 | 随时间保持数据而不丢失的能力。 | 数据丢失会削弱信任，并可能带来法律/合规方面的后果。 |
构建可靠性：不是要防止每一次故障
实现高可靠性 并不意味着要防止所有故障——这既不可能也在经济上不可行。它意味着构建能够：
- 优雅地失败
- 快速恢复
- 在组件故障时仍保持可接受的服务水平
真实案例
- Netflix 和 Google 故意在生产环境中注入故障（混沌工程），以验证系统的弹性。
- Netflix 的 Chaos Monkey 随机终止生产环境中的实例，确保服务能够容忍实例故障。
“混沌工程是一门通过对系统进行实验，以建立对系统在生产环境中能够承受动荡条件的信心的学科。” – 《混沌工程原理》
现代可靠性实践的关键真理
- 故障是正常的 – 分布式系统总会有某些部分出现故障；目标是保持整体系统可用。
- 冗余很重要 – 多层次（实例、数据中心、地区）的冗余可以防止单点故障蔓延。
- 可观测性是必需的 – 不能衡量的东西就无法改进。监控、日志和追踪至关重要。
- 自动化加速恢复 – 自动化的补救和自愈可以把 MTTR 从数小时降低到数分钟甚至数秒。
可靠性不是在最后才添加的功能——它是从一开始就要在架构中体现的根本属性。把它当作事后想法会导致代价高昂的宕机和信任流失。
通往高可靠系统之旅
- 明确的服务等级目标（SLO），在可靠性与开发速度之间取得平衡。
- 失效模式分析，以了解潜在的故障点。
- 定期的混沌实验，验证对系统行为的假设。
- 无责文化，将事故视为学习机会。
接下来
在我们的下一个视频中，我们将探讨 弹性——系统抵御并从不可避免的故障中恢复的能力。因为在分布式系统中，关键不是 是否 会出现故障，而是 如何 故障以及 多快 恢复。
When, and how prepared you are to handle it.
Ready to start your chaos engineering journey?
Explore **LitmusChaos** to begin testing your system's reliability today.