012、系统可靠性分析与设计

系统可靠性设计：从一次深夜宕机说起

凌晨两点，产线控制服务器突然失去响应。重启后日志显示内存耗尽，但监控里JVM堆使用率明明只有70%。排查六小时后发现，是某个第三方库的本地缓存没有上限设置，随着时间推移吃光了所有物理内存。这个教训让我明白：可靠性不是功能清单上的复选框，而是渗透在每个设计决策里的基因。

可靠性数学基础：别被公式吓到

可靠性指标常被各种公式包裹，其实核心就三个。MTTF（平均无故障时间）好比设备的“预期寿命”，MTTR（平均修复时间）是“送修到取回的平均耗时”，MTBF则是两者之和。实际工程中我更关注年故障率：假设某模块MTBF是10万小时，年故障率 ≈ 8760/100000 ≈ 8.76%。这个数字比抽象的“五个月”直观得多。

可用性计算有个经典误区。很多人认为99.9%和99.99%只差0.09%，实际意味着从每年8.76小时宕机变成52.6分钟——对支付系统来说，这多出来的8小时能损失几个亿。计算串联系统可用性时直接乘，并联系统用1减各部件不可用性的乘积。但真实系统都是混联结构，这时候别硬算，用故障树或蒙特卡洛模拟更靠谱。

硬件可靠性：那些容易忽略的细节

双机热备听起来简单，实际踩坑无数。有一次主备机共用SAN存储，结果存储控制器故障导致双机同时不可用——单点转移了但没消失。真正的冗余要遵循“不同路径原则”：不同机柜、不同交换机、甚至不同型号设备。电源冗余常被忽视，我们吃过亏，两台服务器接同一路PDU，机房线路改造时一起断电。

嵌入式场景更微妙。汽车ECU的看门狗设计有个经典陷阱：喂狗线程优先级设得太低，被高优先级任务饿死，狗没叫系统却僵死了。后来我们改成硬件看门狗+软件心跳链，每个关键线程互相监督。芯片选型时别只看性能，工业级和商业级的温度范围差异，在夏天无空调的厂房里就是稳定和崩溃的区别。

软件可靠性设计模式

错误处理最忌“吞异常”。见过最坑的代码长这样：