一、可靠性基础：系统可靠性的定义、MTBF与MTWR、可用性计算、故障模式分类
聊到系统架构，大家首先想到的往往是高并发、高性能。但说实话，我这些年踩过最大的坑，几乎都跟「可靠性」有关。系统再快，动不动就挂，用户照样骂娘。
所以，咱们先从最基础的东西聊起。什么是可靠性？说白了，就是系统在给定条件下，在规定时间内，不出岔子的能力。你想想看，一个电商系统，双十一零点刚过，页面打不开了——这就不靠谱。
1.1 可靠性的核心指标：MTBF 与 MTTR
衡量可靠性，有两个绕不开的指标：MTBF 和 MTTR。我习惯把它们看作一对「冤家」。
- MTBF（Mean Time Between Failures）：平均无故障时间。系统两次故障之间能撑多久。这个值越大，说明系统越皮实。
- MTTR（Mean Time To Repair）：平均修复时间。从故障发生到恢复，花了多久。这个值越小，说明你恢复能力越强。
我在项目中遇到过这么个事：有个核心服务，MTBF 高达 2000 小时，看起来挺稳。但每次出故障，MTTR 要 4 小时。为啥？因为日志不全，定位问题全靠猜。后来我们重构了监控体系，MTTR 降到了 20 分钟。嗯，这才是真功夫。
核心公式：
可用性 = MTBF / (MTBF + MTTR) × 100%举个例子：MTBF = 720 小时（30天），MTTR = 4 小时，那么可用性 = 720 / (720+4) ≈ 99.45%。
我的习惯：做架构设计时，我会先定一个可用性目标。比如「四个九」（99.99%），然后反推 MTBF 和 MTTR 需要达到什么水平。这样设计起来才有方向。
1.2 可用性计算：别被数字骗了
可用性计算看起来简单，但坑不少。我曾经被一个「99.9% 可用性」的承诺坑过——后来才发现，人家算的是「单机可用性」，不是「服务可用性」。
常见的可用性等级：
| 可用性等级 | 年停机时间 | 典型场景 |
|---|---|---|
| 99% （两个九） | 87.6 小时 | 内部工具、开发环境 |
| 99.9% （三个九） | 8.76 小时 | 一般企业应用 |
| 99.99% （四个九） | 52.56 分钟 | 金融、电商核心 |
| 99.999% （五个九） | 5.26 分钟 | 电信、航空、医疗 |
你想想看，从三个九到四个九，年停机时间从 8.76 小时降到 52 分钟。这背后付出的代价，往往是数倍的硬件投入和架构复杂度。所以，别盲目追求高可用，够用就好。
避坑指南：我曾经帮一个客户做评估，他们号称「99.99% 可用」，但实际算下来，他们只算了「数据库主库」的可用性，完全忽略了网络、负载均衡、应用服务器。结果一上线，负载均衡挂了，整个系统瘫痪。记住：可用性计算要覆盖全链路。
1.3 故障模式分类：知己知彼
要提升可靠性，得先知道系统会怎么「死」。我习惯把故障分成几类：
- 硬件故障：磁盘坏了、网卡掉了、电源烧了。这类故障最直接，也最好预防——冗余就行。
- 软件故障：代码 bug、内存泄漏、死锁。这类最头疼，因为往往不是「坏掉」，而是「慢慢变慢」。我记得有一次，一个服务跑了三个月，内存从 2G 涨到 32G，最后 OOM 挂了。查了半天，是一个缓存没清理。
- 网络故障：延迟抖动、丢包、分区。分布式系统里，网络是最不可靠的。我常说：网络不可靠，这是分布式系统的第一性原理。
- 人为故障：配置错误、误操作、发布事故。说实话，这类故障占比最高。我见过最离谱的，是有人把生产环境的数据库删了——嗯，就是那条经典的 rm -rf /。
- 外部依赖故障：第三方 API 挂了、DNS 解析失败、云服务商出问题。这类故障你控制不了，只能靠降级和熔断。
我的经验：故障分类不是为了分类而分类。每次出故障，我都会问三个问题：
- 这是哪类故障？
- 我们有没有对应的预案？
- 下次怎么避免？
把答案记下来，慢慢就形成了自己的「故障知识库」。说白了，经验就是这么攒出来的。
1.4 小结
这一章我们聊了可靠性的基础。MTBF 和 MTTR 是硬指标，可用性计算要覆盖全链路，故障模式分类能帮你提前想好对策。嗯，这些概念看起来简单，但真正用好，需要你在项目中反复打磨。
下一章，咱们聊聊「冗余设计」——怎么用多副本、多活、多机房来扛住故障。到时候我会分享一个我亲手设计的「两地三中心」案例，踩过的坑不少，但收获也很大。