1 可靠性理论要建立什么
值班时，最容易看到的是孤立的现象：进程还在，终端却连不上；文件存在，写入却返回错误；网卡显示启用，远端探测仍超时。可靠性理论要把这些现象放进明确的服务边界、时间范围和失效条件中，使“够不够可靠”成为能够讨论和检查的问题。它不承诺消灭故障，而是帮助我们说明：哪些功能必须持续工作，允许中断多久，故障发生后如何恢复，以及支撑这些判断的证据是什么。
本课采用真实运维中常见的场景：使用者通过网络读取主机上由进程提供的状态文件。路径经过接入网络、主机网络接口、监听进程和文件系统。成功条件可以定义为“从指定探测点发起读取，在 2 秒内得到内容正确的状态结果”。这里的进程存活只是条件之一。进程可能没有监听目标端口，监听正常也可能读不到文件，文件可读也可能因网络中断而无法交付。只有从边界到边界满足约定，才能算这次服务成功。
可靠性通常关心系统在指定条件下、指定时间段内持续完成规定功能的概率。可用性关心在观察或抽取的时刻，服务处于可用状态的程度。某台主机每天重启 1 次，每次恢复很快，长期可用性可能较高，但它连续运行 7 天不失效的能力并不强。如果任务是持续进行的远程终端会话，这种差别直接影响体验；如果任务是允许重试的周期性状态读取，评价方式又会不同。定义指标前，应先确定任务。
建立模型时，可以先画依赖，再给每个依赖写出成功条件，最后记录恢复手段。不要急着填概率。对于网络读取，成功条件包括路由可达、端口可连接、进程能处理请求、文件系统能在时限内返回正确内容。对于本机 shell 脚本，边界可能只包含命令执行、输入文件和输出目录。范围变了，同样的主机故障就可能属于模型内部，也可能只是外部前提。写清前提，才能避免不同团队拿不同边界上的数字比较。
可靠性数字还依赖负载、维护方式和运行环境。低负载时得到的结果不能直接保证高峰期表现；实验主机上测出的恢复时间，也不能自动代表远程机房里的人工更换时间。入门阶段最有用的做法，是给结论附上条件句：在什么配置、什么负载、哪些探测点和多长观察窗口下，得到什么结果。数字因此更容易被复核，也更容易在环境变化后及时作废。
2 失效、MTBF 与可用性计算
失效是系统未能完成规定功能的事件，故障原因则是导致失效的条件。磁盘错误可能导致文件读取失效；错误的目录权限也可能造成同样结果。反过来，某块磁盘出现错误时，如果服务仍能正确读取所需内容，组件已经发生问题，服务却未必失效。因此记录时要分清组件事件与服务事件，不能把每条系统告警都当成用户可见的停机，也不能只凭“没有告警”就认定服务正常。
MTBF 是平均故障间隔，在可修复系统的入门模型中，常按累计正常运行时间除以失效次数估算。假设观察到累计正常运行 1000 小时，期间发生 2 次失效，则样本估计 MTBF 为 500 小时。这不表示系统每运行 500 小时就必定失效，也不表示接下来 500 小时安全。样本少、环境变化或失效定义变化，都会使这个平均值难以代表未来。报告时应保留观察时间和事件数，避免只留下漂亮的平均数。
MTTR 在不同资料中可能指平均修复时间或平均恢复时间，本课明确用它表示从服务失效到恢复规定功能的平均时间。它包括发现、判断、执行恢复和确认成功的耗时。恢复可以通过切换到备用进程完成，损坏设备的彻底修复则可能稍后进行。因此服务恢复时间与硬件维修时间应分别记录。为了减少歧义，方案里最好直接写“平均服务恢复时间”，并说明起止事件，而不只写缩写。
在可修复、长期运行且统计条件近似稳定的简化模型下，可用性可估为 A = MTBF / (MTBF + MTTR)。若 MTBF 为 1000 小时、平均服务恢复时间为 1 小时，则 A = 1000 / 1001，约为 99.9001%。它说明提高可用性有 2 个方向：减少失效频率，或者缩短失效后的恢复时间。增加可靠组件主要影响前者；可靠告警、清晰操作步骤和经过验证的切换通常影响后者。模型不是要求所有问题都通过加机器解决。
实际服务常直接按窗口计算时间可用性：A = 满足成功条件的时长 / 应计总时长。若 30 天全部计入，总时长为 43200 分钟，99.9% 对应的不可用时间额度为 43.2 分钟。计划维护是否计入、部分用户失败如何计入，都必须预先约定。请求成功率则是成功请求数除以有效请求总数，与时间可用性不是相同指标。低流量时长时间不可用，可能只影响少量请求，不能据此推断停机时间很短。
如果进一步假设失效率恒定，才可以使用 R(t) = exp(-t / MTBF) 估计连续工作 t 时间的可靠性。这是带条件的入门关系，不适合直接描述老化、磨损或周期性配置发布。这里不展开分布推导，只需记住：平均间隔、连续成功概率和窗口可用性回答不同问题。任何公式都应先检查它的假设，不能因为单位相同，就把不同含义的时间直接代入。
3 冗余、相关故障与共因
先看串联依赖。若完成读取必须同时依赖网络路径、监听进程和文件系统，那么任意环节失效都可能导致整体失败。只有在这些组件状态可以近似看作独立、边界与统计窗口一致时，串联可用性才可写成 A链 = A网络 × A进程 × A文件。乘积一般低于其中任意单项，因此每个组件都“很稳定”，并不自动意味着长依赖链满足目标。模型提醒我们寻找必要依赖，也提醒我们删掉并不必要的依赖。
并联冗余的思路是，只要存在满足需求的可用分支，服务就能继续。在 2 个分支独立、任意分支都能独自承载需求、切换完全有效的理想模型中，可用性为 A并 = 1 - (1 - A1)(1 - A2)。若每个分支可用性都是 99%，结果为 99.99%。这个结果非常诱人，但公式中的“独立”“能承载”“能切换”都是实际工程条件。备用机资源不足、状态文件未同步或切换脚本权限错误，都会让算式高估收益。
相关故障表示分支的失效并非相互独立，共因则指出它们可能由相同原因触发。2 台主机接在同一供电单元上，供电单元断电即可让它们同时停止。2 个进程使用同一文件系统，目录被误删也会同时破坏服务。即使放在不同主机，如果同时接受相同的错误配置，也可能同步失效。复制组件数量没有消除这些共同依赖，物理位置不同也不等于所有故障都独立。
可以把共享供电视作串联在冗余组外部的组件。假设供电可用性为 Ap，供电正常时 2 个分支的条件可用性分别为 A1 和 A2，且此时近似独立，则 A总 = Ap × [1 - (1 - A1)(1 - A2)]。这个模型仍然简化，却清楚地显示：内部冗余无法突破外部公共依赖的限制。如果 A1、A2 已经包含供电故障，再额外乘 Ap 就会重复计算，因此组件指标的定义必须与图中的边界一致。
审查冗余时，应沿供电、网络入口、文件数据、配置和操作权限逐项追问共同依赖。接着验证故障发生时谁检测、谁决定切换、切换后如何确认内容正确。冗余设计也可能新增入口选择器或共享存储，形成新的必要组件。入门时不必追求穷尽所有罕见组合，先覆盖最常见、影响最大的共同原因，并把尚未验证的独立假设明确标出来，已经能显著改善判断质量。
4 动手：算一条链路的可用性
现在为状态文件读取建立可复查的计算。假设网络路径可用性为 99.9%，监听进程为 99.95%，文件系统为 99.99%。这些数值仅用于练习，假定来自相同窗口、相同成功定义，且各环节近似独立。先写出服务需要全部环节正常，再计算 0.999 × 0.9995 × 0.9999 = 0.99840064995，约为 99.8401%。按 30 天窗口折算，预期不可用时长约为 69.09 分钟，超过 99.9% 目标对应的 43.2 分钟。
可以在本机 shell 用 awk 重算，避免把百分数当成普通数直接相乘。命令中的小数表示可用比例，最后才转换成百分比和分钟。
awk 'BEGIN {
a = 0.999 * 0.9995 * 0.9999
printf "availability=%.6f%%\n", 100 * a
printf "unavailable_minutes=%.2f\n", (1-a) * 30 * 24 * 60
}'这只是模型输出，不能当作现场测量。若网络与文件读取都依赖同一主机，主机重启可能同时影响多个环节，独立假设就需要重新审查。可先把主机视作公共依赖，把条件于主机正常的进程和文件系统行为放在内部；也可以直接使用端到端观测结果评估目标。组件模型帮助解释结构，端到端观测帮助判断实际表现，2 者应互相校验，而不是强迫现场数据迎合算式。
在获准的测试环境中，先记录时间、探测位置、目标地址和成功条件，再用具体接口查证。ps -p PID -o pid,stat,etime,args 用于检查目标进程，ss -lnt 用于检查监听端口，ip route get 192.0.2.10 用于查看到示例目标的路由选择。示例地址需要替换成测试目标。检查监听时要看绑定地址：仅监听 127.0.0.1 的服务，不能据此认定外部连接可用。每条命令只证明有限的事实。
若状态由 HTTP 接口提供，可以用 curl --fail --silent --show-error --max-time 2 http://127.0.0.1:8080/status 检查本机接口，再从约定的远端探测点执行相同请求。本机成功、远端失败时，证据会把排查范围推向主机入口和中间网络。curl 返回成功后还要按约定检查内容，例如状态时间戳是否更新；返回旧文件不能算正确服务。退出码、耗时和内容判定应分别保留，便于解释失败类型。
文件侧可以检查 df -h /srv/status、df -i /srv/status 和 test -r /srv/status/state.txt。容量耗尽、inode 耗尽和权限不足会表现为不同故障，文件存在并不能排除它们。test -r 的结果属于执行该命令的用户，若服务使用另一个 uid，仍需在获准条件下确认服务身份是否可读。不要在生产目录随意写入测试文件。仅当路径属于明确的测试区域时，才进行写入、读回和清理验证。
持续观测要约定采样间隔。例如每 30 秒探测 1 次，结果只能近似描述状态变化，不能精确确定 2 次探测之间的起止时刻。单点超时也可能来自探测机自身，应结合其他位置的结果判断。若演练停止目标进程，要先明确恢复命令和负责人，再记录首次失败、恢复动作及首次确认成功的时间。这样得到的恢复耗时才有清楚边界，也能用于改进后续操作。
5 冗余成本与风险取舍
现在尝试改善练习中的链路。若把网络部分改为 2 条独立、可自动选择且各自能够承载需求的路径，理想网络可用性为 1 - 0.001² = 0.999999。保留原来的进程和文件系统假设，整体变为 0.999999 × 0.9995 × 0.9999，约为 99.9399%，30 天不可用时长约为 25.96 分钟。这个比较说明，改善较弱环节可能有效，但其他串联依赖依然限制整体结果。
如果所谓的 2 条路径实际共用接入设备，或者切换需要值班人员登录已经失联的主机，理想并联结果就不成立。采购清单上的数量不能代替故障域分析。预算讨论应同时列出设备、布线、备用容量、演练、监控和维护成本。新增分支也要更新配置、验证权限并处理版本差异；如果团队无法持续维护，冗余可能增加配置偏差和误操作机会。
滑块把分支不可用比例、公共依赖不可用比例和分支数量放在相同画面中。它使用明确简化的模型，帮助观察公共依赖如何限制收益。拖动后应先读假设，再读结果：公共依赖正常时，各分支近似独立；任意可用分支有足够能力；切换没有额外失败和延迟。真实系统若不满足这些条件，应补充相应事件或直接使用演练数据，不能把交互中的估计当作承诺。
减少恢复时间也是可以比较的选项。假设 MTBF 为 1000 小时，平均服务恢复时间从 1 小时缩短到 0.25 小时，简化可用性从约 99.9001% 提高到约 99.9750%。改进可能来自告警更早、备用启动命令经过验证、必要权限提前配置，或者恢复后有明确的内容检查。这里同样不能只计执行命令的时间；夜间无人响应、凭据过期和确认困难都属于服务恢复过程的一部分。
风险取舍还要考虑失效后果。只读状态页允许短暂重试，长期文件损坏则可能影响后续所有读取。较高可用性不代表数据已经安全，备份也不自动提供即时接管能力。方案应分别说明持续服务、正确内容和数据恢复的目标。预算有限时，优先保护后果严重且恢复困难的依赖，再结合实测结果决定是否增加分支，比追求更多小数位更有依据。
6 常见坑：独立假设掩盖共因
最常见的计算错误，是把来源不清的组件可用性直接放进并联公式。某份月报中的主机可用性可能包含机柜断电，另一份报表却排除了计划维护；把它们相乘无法得到有明确含义的系统指标。开始计算前，应为每个输入记录来源、窗口、边界、维护口径与样本量。若无法确认独立性，就把理想结果标为假设下的估计，不能把它写成已经验证的保障。
另一个陷阱是把相同副本当成不同故障域。2 个进程共享宿主机，主机重启会同时中断；2 台主机共享交换设备，设备失效会同时断网；不同机柜也可能共享上游配电。软件共因同样常见：同时下发错误路径、删除共同读取的目录、批量修改防火墙规则，都可能让多份副本同步不可用。冗余审查需要同时看物理依赖与管理动作，不能只数设备。
监控也可能成为共因的受害者。若探测器与被测服务同机，断电后探测器无法继续上报；仪表盘上最后的绿色状态只是旧结果。观测系统应显示最后采样时间，并把结果过期与明确成功区分开。必要时使用来自不同位置的探测，但不同位置也要检查是否共用网络出口。没有收到失败事件，可能表示正常，也可能表示收集链路中断，必须结合心跳或数据新鲜度判断。
排查中还容易把相关性误当作原因。2 台主机在相近时刻失联，提示可能存在共同事件，却不能直接证明供电故障；共同网络入口失效也会产生类似现象。应比较外部探测、机房供电记录、主机启动记录和变更时间。若时钟存在偏差，要记录偏差或扩大时间范围。多条证据应指向可解释的事件顺序，而不是只因为日志时间接近就得出结论。
平均值也会掩盖恢复过程的差异。多数故障在 1 分钟恢复，少数需要数小时，单独报告平均恢复时间会弱化长时间事件的影响。入门方案可以同时列出每次恢复耗时、最长事件和事件原因，不必立刻引入复杂统计。对于罕见共因，短观察期没有出现故障并不能证明概率为 0；应结合依赖检查、历史记录和受控演练保留不确定性。
7 案例：同机柜冗余同时掉电
某运维团队为内部状态文件服务部署了 2 台主机，分别运行监听进程并保存状态副本。入口可选择任意健康主机，平时停止其中 1 个进程，另一个能够接管。团队因此把“进程故障可切换”的结论扩展成“任意单点故障都不会影响服务”。实际上，2 台主机放在同一机柜，并接到同一供电单元；入口选择器可以工作，却无法把请求送到已经断电的主机。
某次供电单元断开后，外部探测同时连接超时。值班人员先尝试重启服务，但远程登录也失败。这时重复执行进程恢复命令没有帮助，因为相关命令根本没有运行条件。随后，其他机柜的探测仍正常，目标机柜内多个无关服务也同时失联。这个范围提示公共依赖异常。结合供电记录，团队确认事件发生在供电层，最终通过恢复供电和检查服务启动来恢复读取。
复盘需要区分触发事件、放大条件和恢复障碍。触发事件是供电中断；放大条件是所有可接管副本位于同一供电故障域；恢复障碍是原有手册只覆盖进程退出，没有提供整柜失联时的联系与确认步骤。入口切换没有失效，它在没有可用目标时无法创造服务能力。这样的解释能指导改动，也能避免把问题简单归结为某个值班人员没有更快重启。
假设供电可用性为 99.9%，且供电正常时每台主机分支可用性为 99.9%，分支在此条件下近似独立，则同供电冗余组的可用性为 0.999 × (1 - 0.001²)，约为 99.8999%。这个数字只用于说明结构：增加主机副本后，公共供电仍然限制整体表现。若直接将 2 台主机的条件可用性代入理想并联公式，会得到 99.9999%，却遗漏整个机柜同时断电的路径。
整改可以包含跨供电故障域部署副本、检查网络入口的公共依赖、验证备用容量，以及增加机柜级失联的判断步骤。每项措施都要对应证据：供电关系由设施记录确认，接管能力由受控演练确认，恢复时限由时间记录确认。不能仅凭插到不同插座就认定电源独立，也不能在未经授权的环境中拔电验证。演练范围和恢复条件应事先明确，结束后确认所有分支重新处于可接管状态。
8 把可靠性目标写进 SLA 方案
可靠性目标进入方案时，需要转化为双方能够按相同方法核对的约定。SLI 是服务水平指标，例如指定探测点的有效读取成功比例或时间可用性；SLO 是为该指标设定的目标；SLA 是围绕服务水平形成的约定，通常还涉及责任、例外和未达标后的处理。内部技术目标与对外承诺可以相关，但不应未经审查就直接等同。先把测量规则写清，再讨论目标数字。
本课场景可以约定：在每个 30 天统计窗口内，指定探测点按 30 秒间隔读取状态接口；在 2 秒内返回规定内容且时间戳满足新鲜度要求，才记为探测成功。若据离散探测估计时间可用性，要写明如何将失败样本换算为区间，以及连续失败与恢复的边界如何处理。若只采用成功探测次数比例，就应按该指标命名，不能把它未经说明地当作精确停机时长。
以 99.9% 时间可用性作为目标时，30 天的不可用额度为 43.2 分钟。这个额度用于比较风险和安排改进，不代表可以主动耗尽它。发生 20 分钟中断后，剩余额度减少，应重新判断近期变更和演练安排。也要说明窗口是固定周期还是滚动周期，因为相同事件在不同窗口下可能产生不同结果。目标越严格，测量缺口、时钟偏差和事件归属就越不能含糊处理。
方案还应包含责任接口。谁维护探测器，谁确认失效起点，谁有权启动切换，谁确认恢复后的内容正确，都需要明确角色。网络不可达时，负责进程的人可能无法登录主机；供电故障时，应用负责人也无法直接恢复设施。联系路径和必要权限属于恢复设计。若正常时没有验证这些条件，计算中的平均恢复时间就可能比实际乐观很多。
最后，应把承诺与假设并列记录：哪些故障域已经分离，哪些共因仍然存在，哪些恢复动作经过演练，哪些数字仅来自短期样本。计划维护、探测器故障、部分位置失败以及依赖方异常如何处理，都应提前约定。清楚的例外用于界定责任，不能通过不断扩大例外掩盖使用者真实经历的中断。技术报告仍应保留全部观测事实，便于持续改进系统。
9 从可靠性理论走向经典论文导读（S62）
学习可靠性理论后，阅读系统论文时可以先寻找它试图保障的功能，而不是先背结论。论文中的“可靠”可能指持续服务、数据保留、故障后恢复或某类结果正确，它们需要不同的证据。先圈出系统边界、运行条件和失效定义，再检查作者允许哪些故障发生。若论文只研究进程停止，就不能直接推断它解决了供电、文件损坏和错误配置等所有问题。
接着区分模型推导与实验观察。公式可能在独立失效、完美切换等前提下成立；实验可能只覆盖有限负载和有限故障类型。阅读时可以画出依赖图，在公共组件旁写出假设，再把测得的停机时间与模型预计的结果对照。发现差异时，先检查边界、统计口径和切换耗时，不必立刻判断论文错误。明确模型何时有用，比把某个结果搬到所有环境更有价值。
带着本课的状态文件场景进入 S62，可以准备 3 个问题：作者解决的服务失效是什么，系统通过什么机制保持或恢复功能，证据能支持多大范围的结论。再补充考虑失效后谁能观察、谁能执行恢复、恢复后如何判定正确。这样阅读经典论文时，抽象术语会对应到进程、文件系统、网络和操作步骤，理论结论也更容易转化为可检查的工程判断。
放进方案里
在状态文件服务的方案中，先写服务边界：指定探测点经网络访问目标接口，必须在 2 秒内获得内容正确且时间戳有效的状态。进程存活、端口监听和文件可读属于辅助证据，最终成功由边界上的探测决定。统计采用固定 30 天窗口，目标时间可用性为 99.9%，对应不可用额度为 43.2 分钟；同时明确采样间隔、区间估计方法、维护计入口径与观测缺失的处理规则。
附上依赖图，列出入口网络、供电、主机、监听进程和文件系统。冗余分支旁注明能否独自承载负载，以及共享供电、共享目录、同步配置等共因。串联乘积与并联公式只用于满足假设的部分，所有输入保留来源、观察窗口和事件数。未经演练的切换能力标为待验证，模型输出作为容量与风险讨论的依据，不直接替代端到端观测。
恢复部分写清告警接收角色、进程检查、网络检查和供电升级路径，并记录从首次失效到确认恢复的完整耗时。恢复后必须再次检查状态内容与新鲜度，不能只看到退出码为 0 就结束事件。为备用分支安排受控演练，确认权限、容量和操作步骤可用，并在结束后恢复冗余能力。
验收时分别模拟单进程退出和单条网络路径中断，要求剩余分支在约定负载下接管，且恢复耗时不超过方案预设上限。保留故障注入时间、连续探测结果和接管记录；若仅验证了进程退出，就不能据此宣称已经覆盖整机断电或共享存储失效。
最后把改进成本与剩余风险并列：跨故障域部署需要额外资源和维护，缩短恢复时间需要告警、权限和演练投入。每次事件保留探测结果、系统日志、变更记录和恢复时间，按约定窗口复核目标。若环境、依赖或负载发生变化，应重新审查独立假设和恢复时限，让方案随实际系统更新。
10 小结：下一步经典论文导读（S62）
可靠性判断从成功条件开始，通过依赖结构解释失效，再用观测和演练修正模型。MTBF 描述平均正常运行间隔，平均服务恢复时间描述失效后的恢复过程，可用性描述约定窗口或长期状态中的可用程度。串联依赖会积累失败机会，冗余收益则取决于独立性、承载能力和有效切换。
进入 S62 前，试着说明：为什么进程存在仍可能服务失效，为什么同机柜的 2 台主机可能无法抵御断电，以及为什么平均值必须附带边界和样本。能够把这些判断落到命令、探测点与恢复记录上，就已经具备阅读可靠系统论文所需的基本问题意识。