可靠性与可用性

可靠性和可用性在 SLA 谈判和架构评审中经常被混用，但它们是两个正交的属性。一句简洁的区分：可靠代表不能错，可用代表你可以错，但必须马上纠正。

这个区分背后是不同的工程投入方向。追求可靠性要消灭故障本身——测试、验证、消除单点；追求可用性要管理故障的后果——冗余、降级、快速恢复。一个系统可以非常可靠但可用性一般（故障极少但每次故障恢复很慢），也可以可靠性一般但可用性极高（经常出小故障但每次几秒钟就自愈）。

可靠性：消除故障的概率

可靠性回答"系统在多大概率上不出错"。严格的工程定义是：系统在规定条件下、规定时间内执行预期功能且无故障的概率。度量的核心指标是 MTBF（平均无故障时间）和错误率。

可靠性的工程手段在软件和硬件领域有不同的成熟路径。硬件可靠性靠冗余和降额——航天系统的三模冗余投票、服务器内存的 ECC、硬盘的 RAID——每个组件出错的概率被冗余结构吸收。软件可靠性靠测试和验证——单元测试覆盖分支逻辑、集成测试覆盖组件协作、形式化验证覆盖关键协议（如 TLA+ 验证分布式协议的一致性）。软件和硬件的关键区别在于：硬件故障有物理规律可循（浴盆曲线、MTBF 数据），软件故障几乎全部来自人的错误——需求理解错、边界条件漏、并发竞态。

因此软件的可靠性本质上是一个工程流程问题而非技术问题。代码审查的深度、测试的覆盖策略、发布前的验证流程，这些流程的严谨程度直接决定了软件的错误率。试图用技术手段弥补流程缺陷——比如靠"更聪明的框架"来保证可靠性——通常不会成功，因为框架本身也是人写的。

可用性：管理故障的后果

可用性回答"系统在多大比例的时间内是可用的"。核心指标是 99.9%、99.99% 这类"几个 9"，背后的数学是 MTBF/(MTBF+MTTR)——不仅取决于多久出一次故障，更取决于出了故障多快恢复。

这个公式揭示了一个反直觉的事实：可用性主要由 MTTR 决定，而非 MTBF。把 MTTR 从 1 小时降到 1 分钟，对可用性的提升等同于把 MTBF 从 100 小时提升到 6000 小时——前者只需要改进监控和回滚流程，后者需要把软件错误率降低两个数量级。工程上改进 MTTR 的难度远低于改进 MTBF。

由此得到可用性工程的三个核心手段：

快速检测。故障恢复的前提是知道故障发生了。这依赖可观测性——健康检查探测依赖服务的存活性、指标监控捕获延迟和错误率的异常、告警系统在用户投诉之前通知值班人员。检测速度的极限是"故障发生前预测"——容量趋势告警、错误预算燃尽率预警——但基本盘是"故障发生后一分钟内感知"。

快速恢复。恢复手段按速度排序：自动重试（毫秒级，处理瞬时故障）→ 熔断切换（秒级，切换到备用路径）→ 回滚部署（分钟级，撤销有问题的变更）→ 数据恢复（小时级，从备份重建状态）。设计系统时如果每个故障的恢复路径都需要"开会讨论怎么办"，这个系统的可用性上限就被管理流程锁死了。

故障隔离。可用性工程中最被低估的手段。一个服务的故障不应该拖垮其他服务——这要求架构上主动隔离：服务间的超时和熔断防止级联失败、资源隔离（线程池、连接池、舱壁模式）防止一个慢调用耗尽共享资源、数据库的读写分离防止分析型查询拖垮事务型写入。隔离的目标不是消灭故障，而是把故障的影响半径控制在一个可承受的范围内。

可靠与可用在实践中的取舍

两个属性在工程投入上存在真实的资源竞争，理解各自的适用边界才能做对取舍。

数据完整性场景优先可靠性：支付、账务、数据库事务。这类场景"错一次"的代价是灾难性的——钱算错了不能用"马上纠正"来搪塞。工程投入全部倾斜到测试、验证、审计——宁可停机也不可出错。银行的批处理系统允许凌晨维护窗口，但不允许一条账目错误。

在线服务场景优先可用性：推荐系统、社交信息流、API 网关。这类场景"错一点"的代价有限——一条推荐不准用户无感知，一个请求失败用户可以重试。工程投入倾斜到冗余、降级、快速恢复——宁可偶尔出错也不可长时间不可用。典型的取舍是降级策略：核心功能保持完整，非核心功能在故障时优雅关闭（推荐算法挂了就回退到热门榜，而不是整个页面报错）。

两者的交界是"可以错但必须马上纠正"的精髓所在。可用性不等于放任错误——错误必须被检测（可观测性）、被记录（审计日志）、被纠正（补偿机制）。支付回调失败要有重试队列，消息丢失要有死信队列，数据不一致要有对账任务。可靠性和可用性的工程手段在这些场景汇合：可靠性手段（幂等设计、事务保证）降低错误率，可用性手段（重试、补偿）处理残余错误。

与可维护性的关系

可用性依赖可维护性。"马上纠正"的能力——快速定位根因、安全地修改代码、验证修改有效——正是可维护性的定义。一个可维护性差的系统，MTTR 被代码的复杂度锁死：定位根因要三天（因为日志不全、结构混乱）、修复要一周（因为改一处动全局）、验证修复要一个月（因为没有测试）。这样的系统无论监控多完善，可用性上限都不高。

这也是为什么"快速恢复"的投资方向应该优先于"消灭故障"——改进可维护性的收益是全方位的（既降低 MTBF 又降低 MTTR），而单纯追求可靠性的收益是单向的。可用性的持续改进路径通常是从可维护性入手：先让系统"错了能改、改了能验证"，再追求"少出错"。