可靠性与可用性
§1摘要与结论
可靠性用一句话概括就是即使出了问题也能继续正确工作，其外延由用户期望给出：功能符合预期、允许用户犯错或以非预期方式使用、在预期负载与数据量下性能足够、能挡住未授权访问与滥用。定义的关键动作是把故障与失效分开：故障指系统的某个部分停止正常工作，失效指整个系统不再提供所需服务、即未达到服务级别目标。二者常被混为一谈，其实只是观察层次不同——单块硬盘停转对只有一块盘的机器就是失效，对多盘系统只是一项故障，只要别处还有副本，系统就可能容忍它。可靠性因此以服务级别目标来衡量。容错总是针对特定类型与数量的故障而言，无法容忍某部分故障的部分称为单点故障；
别名：reliability、availability、可靠性、可用性、容错 | 英文：Reliability and Availability | 类型：方法原则 / concept
§2局部关系图
§3原理 · 为什么
把可靠性当作架构层面的属性而非编码纪律，依据是失效的成因分布在组件之间：单点依赖、资源争用、交互涌现、共享假设破裂，这些都不是个人谨慎能够消除的。书中给出的佐证是，运维改配置在大型互联网服务的中断诱因中排首位，服务器与网络硬件只在少数中断里起作用。因此可靠性的着力点是结构性的冗余、隔离与恢复能力，而不是要求每个操作者都不出错。适用边界同样明确：小型系统中故障件易于更换时，为低频事件过度投入并不划算，只有规模大到故障成为日常运行的一部分，结构性容错才真正回本。这条原则也提示，可靠性目标必须能被写成可检验的陈述，否则它只是一句无法核对的愿望。进一步说，把可靠性归到结构层面也改变了排查方式：当失效来自组件之间的交互与共享假设，追问「谁操作失误」通常找不到根因，有效的问题是「哪一处假设被打破、为什么它没有被冗余或隔离覆盖」。这条原则还提示冗余必须放在故障真正会扩散的位置，若副本与原件共享同一电源、同一网络出口或同一份配置下发通道，冗余只增加成本而不增加可靠性。最后，结构性容错并非一次建成，它需要在系统演进中随故障模式的改变而重新校验。此外，扇出任务要容错，接手的机器既不能漏投也不能重复投递；故意提高故障率反而有助于验证容错机制；安全类故障无法事后补救，属于预防胜过容忍的例外。由此还可推出两点限定：一是可靠性并非「不出错」，而是出错后仍能交付服务，因此它天然与检测和恢复能力绑定，没有检测手段的冗余只是账面上的冗余；二是用户期望随场景变化，同一个停顿在交互式场景里是失效，在离线批处理里只是延迟，故可靠性目标必须挂在具体的用户任务上，而不能挂在内部指标上。此外还要区分可恢复与不可恢复的失效，前者可用重试与切换吸收，后者只能靠事前约束避免。
§4机制 · 如何运作
故障与失效的区分机制在于观察层次：同一个事件在局部看是部件停止工作，在整体看可能只是被吸收掉的一次扰动。判断标准落在服务级别目标上——只有当整个系统不再向用户交付所需服务时，才算失效。由此推出单点故障的判据：某个部分一旦出问题就会升级为整体失效，它便是单点。机制上的含义是冗余必须落在能截断升级路径的位置，例如同一份数据在别处仍有副本，则单块盘的事件停留在故障层。反例是只有一块盘的机器，同一事件立刻穿透到失效层。这条区分让容错有了可检验的表述：不是声称不出问题，而是声称问题发生时服务仍在。软件侧的机制则不同，同构部署让所有节点共享同一处缺陷，一次计时异常或资源泄漏就能让全体同时倒下，级联失效还会沿调用链放大，因此应对方向偏向隔离、快速重启与抑制重试风暴这类反馈环。还需补一层：把可靠性目标分解成可观测的中间量，例如故障被发现的时延、恢复所需的时延、期间允许丢失的数据范围，这些量各自都能被单独检验，比一个笼统的可用性数字更容易定位短板。另外要区分可恢复故障与不可恢复故障的处置：前者用副本与切换来吸收，后者只能靠事前约束与权限收窄来避免，把两者混用会让投入花在错误的路径上。最后，容错能力本身也会退化，冗余件长期未被使用便可能已经失效而不自知，所以需要周期性地确认备用路径仍然可用。
§5工程 · 怎么落地
容错声明必须附带故障类型与数量边界，这是可验证性的要求而非措辞讲究。书中把“容忍任意数量的故障”判为无意义：若全部节点都倒下，任何机制都无从补救。工程上由此得到三条纪律：一是把可用性目标写成带故障场景、检测时限、恢复时限与允许丢失内容的可验证陈述；二是明确系统能同时承受几块盘、几个节点、几个可用区的损失；三是把这类边界做成演练用例而非纸面承诺。可复用的手段是故意注入故障，例如无预警地杀掉某个进程，用受控的破坏来检验容错路径确实按预期生效，而不是假定它生效。落地上还应先隔离故障域再谈副本数量，因为共享同一机架或同一可用区的多份拷贝可能一起倒下。还要补两点操作性要求：其一，演练应有固定频次并纳入日常运维，只在事故后临时补做，等于把检验推迟到最不方便的时刻；其二，每次容量变更、拓扑调整或依赖替换之后都要重新核对故障边界，因为边界是随部署形态变化的，昨天的双副本今天可能已经退化为实质单点。相应地，故障边界应写进运维手册，使值班者能在压力下判断该人工介入还是等待自动恢复，而不是临时猜测。
§6权衡卡
此外，可靠性投入的收益往往只在规模大到故障成为常态时才显现，小系统里它更像一笔难以回收的保费。
冗余本身也有隐含代价，其有效性依赖各组件失效彼此独立，然而实测显示失效之间存在明显相关性，同一机架乃至同一可用区仍会比预期更频繁地一起不可用，于是“多副本”可能共享同一个故障域而在关键时刻同时倒下。
因此可靠性设计应优先做故障域隔离，而不是盲目复制；对低概率但影响巨大的事件，还要权衡是否值得为其常年支付冗余成本。
取舍还应按故障可否补救再细分一层：可补救的故障适合用容错吸收，因为代价只体现为延迟与切换开销；不可补救的故障只能事前设防，因为一旦发生就没有对冲手段。
另一个常被忽略的反例是把容错当成万能替代品，例如用重试掩盖下游不稳定，短期看可用性数字变好，长期却把过载放大并让真实缺陷永远不被修复。
- 容忍故障与预防故障之间需要分场景取舍，而取舍依据是故障可否补救。
- 书中给出的边界很清楚：安全问题属于预防胜于治疗的一类，一旦攻击者取得敏感数据，事后无从撤销；而可补救的故障则更适合用容错吸收。
- 因此对每类故障都要先判断它的可逆性，再决定投入哪一侧，并把重复出现的同类故障视为结构问题而非偶发事件。
权衡原文仅按显式标记词归栏引用（收益 / 代价 / 反例），其余句子按原序列为「原文要点」；内容逐字引用未改写。
§7冲突 / 对比表
| 对照维度 | 可靠性与可用性 | 性能效率本质 |
|---|---|---|
| 定位 / 依据层 | 可靠性与可用性 · Reliability and Availability | 性能效率本质 · Essence of Performance Efficiency |
| 核心定义（原文） | 可靠性用一句话概括就是即使出了问题也能继续正确工作，其外延由用户期望给出：功能符合预期、允许用户犯错或以非预期方式使用、在预期负载与数据量下性能足够、能挡住未授权访问与滥用。 | 性能效率的可操作含义是：起点为某个具体事件抵达系统，终点为系统在给定的时间或资源预算内交出响应。 |
| 首条机制断言（原文） | 把可靠性当作架构层面的属性而非编码纪律，依据是失效的成因分布在组件之间：单点依赖、资源争用、交互涌现、共享假设破裂，这些都不是个人谨慎能够消除的。 | 任何计算都必须消耗时间与资源，所以性能不是可以事后追加的特性，而是系统结构与资源约束共同决定的结果。 |
| 对照关系 | 性能与可靠性作为权衡的两端（对照） | 同一条 对照 边的另一端 |
| 典型反例（原文） | 另一个常被忽略的反例是把容错当成万能替代品，例如用重试掩盖下游不稳定，短期看可用性数字变好，长期却把过载放大并让真实缺陷永远不被修复。 | 两种反例值得记住：在没有测量依据时凭直觉重构，投入大量精力却未触及真正瓶颈，反而破坏了结构；把性能等同于单点延迟，忽视吞吐、容量与资源利用。 |
| 处置要点（原文） | 容错声明必须附带故障类型与数量边界，这是可验证性的要求而非措辞讲究。 | 先打点测量，再决定改哪里：只有在关键路径上记录耗时，才能看出时间究竟消耗在哪些环节，从而把有限的改造精力投向占总耗时比例最高的少数部分。 |
§8案例带
preset 通道耦合分析
对 harness「委派工具层→续用管理器→preset 服务→MCP 服务器」这条通道做耦合分析：识别契约、服务定位、数据契约、组合语义、路径与装配一致性六类耦合点，定位「静默丢弃特化」与「装配漂移」两处实质缝隙。
§9信源与核验
核验结论：可用性是可被正常使用的时间比例；系统可在部分功能降级下仍算可用，且过高目标的边际成本极高，百分之百并非合理目标 [OFF-005]
核验结论：可靠性关注规定时间段内执行规定功能的程度（含无故障性、容错、可恢复）；可用性是其下属子特性，关注可服务时间比例，二者相关但不等价 [OFF-005]
§10原始关系清单
展开：本节点的全部原始关系边（2 条，含边 ID 与方向）
| 关系 | 方向 | 对端节点 | 说明 |
|---|---|---|---|
| 对照 | ← ESS-M-03 | 性能效率本质 E-343 | 性能与可靠性作为权衡的两端 |
| 依据推导 | ← MTH-M-03 | 可用性战术应用 E-348 | 可用性战术服务于可靠性与可用性 |
附对照资源 · 12factor 子库
| 12factor 节点 | 关系 | 对照说明 |
|---|---|---|
| 无状态性 t-stateless | 跨体系对照 | 无状态性是传统应用与 Agent 共有的可靠运行基石 |