1. 系统可靠性基础：从理论指标到工程语言
第一次接触系统可靠性指标时，我被各种缩写搞得晕头转向——MTTF、MTBF、MTTR这些字母组合看起来像某种密码。直到负责的电商系统在促销活动中崩溃，才真正理解这些抽象指标背后的工程意义。那天凌晨三点，我们一边抢修一边计算：如果系统MTBF能达到200小时，就能撑过整个大促周期。
**MTTF（平均无故障时间）**就像灯泡的寿命预期。实测过一个服务器集群的MTTF：200台机器连续运行30天后，有3台发生硬件故障。计算公式很简单：
MTTF = 总运行时间 / 故障次数 = (200台×720小时)/3次 = 48,000小时但这个"5.5年"的理想值需要打个问号——实际环境中的电压波动、温度变化都会影响结果。
**MTBF（平均故障间隔时间）**更适合可修复系统。去年我们数据库集群的MTBF从120小时提升到300小时，关键是把例行维护纳入了计算模型：
# 计算MTBF的简化示例 uptime = [68, 105, 92] # 三次正常运行时长(小时) downtime = [2, 1.5, 3] # 对应修复时间 MTBF = sum(uptime) / len(uptime) MTTR = sum(downtime) / len(downtime) print(f"系统可用性：{MTBF/(MTBF+MTTR):.2%}") # 输出：98.28%可用性计算有个经典案例：某云服务商承诺99.9%可用性，实际全年宕机8.76小时就违约。我们团队用这个数据说服管理层投资冗余电源——虽然单电源MTBF已达标，但并联设计能让可用性从99.9%提升到99.99%，相当于全年宕机时间从8.76小时缩短到52分钟。
2. 从理论到实践：SRE的可靠性度量体系
在Google的SRE手册中发现个有趣对比：传统IT用"uptime"衡量可靠性，而SRE更关注"是否满足用户预期"。这解释了为什么我们以前自认可靠的系统，用户却总抱怨卡顿——标准不同。
**SLI（服务级别指标）**的设定是个技术活。为API服务设定延迟SLI时，我们最初用平均值，结果掩盖了长尾问题。后来改用分位数：
# 延迟SLI计算示例 import numpy as np latencies = [45, 62, 58, 130, 71, 82, 55, 490, 63, 68] # ms print(f"平均延迟:{np.mean(latencies):.1f}ms") # 112.4ms - 被490ms拉高 print(f"P90延迟:{np.percentile(latencies, 90):.1f}ms") # 130ms - 更反映用户体验错误预算的运用最考验平衡艺术。去年Q3我们的搜索服务错误预算还剩57%时，产品团队坚持要上线高风险的功能迭代。我给他们看了这个公式：
允许发布次数 = 剩余错误预算 / (预计故障率 × 影响时长)计算结果为2次，最终他们自愿拆分了发布批次。这就是错误预算的魅力——把技术风险转化为决策语言。
**SLO（服务级别目标）**的黄金法则是"用户可感知"。曾有个存储服务设定了99%的写入成功率SLO，实际用户却因读取超时投诉。后来我们细分为：
- 写入成功率SLO：99.9%
- 读取延迟SLO：P99<200ms
- 数据一致性SLO：99.99% 这才真正改善了用户体验。
3. 可靠性建模：从浴盆曲线到现代监控
浴盆曲线理论在服务器硬件上得到完美验证。新采购的SSD集群前两周故障率明显偏高（早期失效期），之后进入稳定的"正常寿命期"。运维看板上的故障率曲线就像教科书插图：
早期失效期：第1周故障率2.3%/天 → 第2周0.7%/天 正常寿命期：第3周起<0.1%/天串联系统的脆弱性在微服务架构中尤为明显。某次线上事故演示了这点：订单服务（R1=99.5%）→支付服务（R2=99%）→库存服务（R3=99.5%）组成的调用链，整体可靠性只有：
R_total = 0.995 × 0.99 × 0.995 ≈ 98%这意味着每天约有28分钟不可用——远超SLO允许的4.8分钟。
并联冗余是我们对抗硬件故障的利器。用三台服务器做热备份，单台MTTF为10,000小时，系统可靠性提升到：
R_single = e^(-t/MTTF) = e^(-720/10000) ≈ 93% (一个月) R_triple = 1 - (1 - R_single)^3 ≈ 99.97%代价是成本增加200%，这就是可靠性的trade-off。
现代监控工具让故障预测更精准。某次Prometheus的预警指标：
disk_failure_prediction{device="sda"} > 0.7结合SMART数据，我们提前72小时更换了磁盘，实现了零宕机。这比传统MTTF预测更精准——因为后者无法感知个体差异。
4. 可靠性设计模式：从冗余到弹性
三模冗余(TMR)在航天系统很常见，但我们在金融交易系统实现时遇到了新问题。三个并行交易处理器理论上应该投票决定正确结果，但网络分区会导致"脑裂"。最终方案是：
// 简化版TMR投票逻辑 func processTransaction(input Transaction) (output Result) { results := make(chan Result, 3) go processor1(input, results) go processor2(input, results) go processor3(input, results) resultMap := make(map[Result]int) for i := 0; i < 3; i++ { res := <-results resultMap[res]++ if resultMap[res] >= 2 { return res // 多数表决 } } return ErrorResult("no consensus") }断路器模式在微服务间至关重要。我们为商品详情页设置的熔断策略：
连续5次调用评分服务超时(>500ms) → 熔断30秒 → 半开状态尝试 → 恢复这比简单重试更有效，避免了级联雪崩。Hystrix仪表盘显示，熔断使系统负载峰值降低了63%。
混沌工程是提升可靠性的终极考验。在模拟数据中心网络分区时，发现Kafka集群的ISR（同步副本）机制存在单点依赖。改进后的部署方案：
跨AZ部署 → 最小ISR设置为2 → 启用unclean.leader.election=false现在即使一个AZ完全断电，消息仍然不丢不失。
可靠性设计要避免"过度工程"。曾有个系统设计了三地五中心容灾，结果日常运维复杂度反而导致更多故障。现在我们遵循：
1. 先满足SLO要求 2. 预留20%~30%余量 3. 评估复杂度成本这个原则帮我们砍掉了多个"看起来很美好"的超配设计。
