3.4 机房夜话
从一台更强服务器承担所有能力走到按故障域布置冗余并验证切换，沿机房可靠性边界诊断共同故障。
学习目标
- 能沿识别负载、划分故障域、布置副本、检测失效和切换恢复追踪一次机房可靠性设计
- 能解释供电、制冷、网络、计算与存储的故障域如何影响冗余与可用性判断
- 能在正常、边界和故障场景中回答：共享电源、交换机或机架时，哪一个共同故障应让系统拒绝独立副本假设
为什么需要这一机制
本页依据刘欣《码农翻身》（2018 年第 1 版）及出版社公开书目信息，独立重构 3.4 机房夜话。正文、代码、图示、实验和练习都是本课程重新设计的教学材料，不复制原书正文、插图、练习答案或代码。
3.4 机房夜话 不能停在故事类比。真实系统要解决的变化是从 一台更强服务器承担所有能力 到 按故障域布置冗余并验证切换；可执行机制是：机房可靠性来自供电、制冷、网络、计算与存储的故障域隔离，冗余只有在共同故障不会同时击中副本时才有效。
三个会让机房冗余失真的陷阱
四个目录节点到可靠性证据
3.4 机房夜话
在 ↡把机房的故事坐标转换为可验收的可靠性合同：识别负载、划分故障域、布置副本、检测失效并切换恢复。 中，验收对象不是“设备够不够强”，而是共同故障是否会同时击中所有副本。公式
只在每个因子和故障假设明确时才有意义；若两套服务共享一只配电柜，不能把它们当作独立因子相乘。
第一夜
在 ↡把请求、容量、依赖和失效模式列成最小输入，明确系统到底要保护什么。 中，先做 识别负载。记录请求量、延迟目标、数据副本、供电与网络依赖，并写出基线预期；没有负载和依赖清单，后面的副本数量没有判定依据。
第二夜
在 ↡把供电、制冷、网络、计算、存储和机架等共同失效边界标记出来的设计动作。 中，完成 划分故障域。把“不同进程”与“不同故障域”分开记录：不同主机仍可能共享机架、交换机、配电柜或制冷系统。
第三夜
在 ↡把副本放入彼此尽量独立的故障域，并记录复制、路由和一致性证据的动作。 中，完成 布置副本。副本的位置、角色、数据版本和共同依赖必须可查询；数量增加但共同依赖不变，不等于可靠性增加。
切换恢复
在 ↡探测失效后按策略改变角色和路由，验证请求、数据与健康状态回到合同的过程。 中，把 检测失效 与 切换恢复 连起来。切换完成不代表成功：还要确认新副本接收请求、数据版本符合策略、旧路径不再继续写入，并能从干净状态重放。
最小可重放实现
baseline = run(fixed_load, topology_version="topology-a")
fault = inject("shared-switch")
assert fault.first_deviation == "detect-failure"
assert recover(fault).topology_version == "topology-a-recovered"
assert reset_and_run(fixed_load) == baseline这段实现草图只表达验证合同，不复制原书叙事或代码。实际运行时应保存输入、拓扑版本、每个节点状态、故障域、首个偏离、最终结果和复位结果，使另一位读者能够从干净状态重放。
五步复核一次机房可靠性设计
1. 识别负载并固定基线
记录请求量、延迟目标、数据版本、容量和所有外部依赖。先预测正常样本的路由、响应和副本状态，再运行一次并保存请求 ID。
Lab
机房故障域与切换恢复实验
先预测一个共同故障会击中哪些副本，再切换正常、边界与故障样本并保存轨迹。
副本分处不同故障域，路由与数据位点一致
load=fixed → domains=power-a/power-b → replicas=ready → replay=match
判定
accept：独立性与恢复合同均有证据
当前样本：正常基线；保存请求 ID、故障域、角色、复制位点、首个偏离和复位轨迹。
正常、边界与故障证据矩阵
| 样本 | 只改变的变量 | 预期判定 | 必存证据 |
|---|---|---|---|
| 正常 | 负载、故障域标签和路由均符合基线 | 副本独立性成立，请求可完成 | 请求 ID、拓扑版本、角色、数据位点 |
| 边界 | 两副本共享机架、交换机或配电柜 | 标记共同故障风险，不得直接相乘 | 共同依赖、风险标签、策略解释 |
| 故障 | 注入一个电源、网络或主机故障 | 定位首个偏离并按策略切换 | 故障时间、检测延迟、路由、恢复轨迹 |
故障诊断：先找共同故障，再看切换结果
- 负载侧：查请求量、延迟、数据版本和外部依赖；先确认保护对象与基线是否相同。
- 故障域侧：查电源、制冷、交换机、机架、主机和存储的标签；不同主机不代表不同故障域。
- 副本侧：查副本位置、角色、复制位点和共同依赖；不要只用副本数量推断可靠性。
- 切换侧：查探活、选主、路由、旧路径写入、数据版本和恢复时间；切换完成必须有请求证据。
如果两副本同时掉线，先查共享电源或交换机，再查两个服务是否真的独立；如果探活已失败但请求仍走旧路径，查检测与路由的时序；如果恢复后数据版本倒退，查复制位点和旧角色是否仍可写。每次只改变一个边界，并重放可信基线。
术语表
名词解释
本章出现的专业名词，用大白话再讲一遍。
- 3.4 机房夜话
把机房故事转换为可验收的负载、故障域、副本、检测和恢复合同。
- 第一夜
从请求、容量、依赖和失效模式开始建立最小输入与基线。
- 第二夜
标记供电、制冷、网络、计算、存储和机架等共同失效边界。
- 第三夜
将副本放入尽量独立的故障域，并保存复制、路由和一致性证据。
- 切换恢复
失效检测后改变角色和路由，并验证请求、数据与健康状态回到合同。
练习
练习
问题 1（3.4 机房夜话）： 两台服务器分别运行同一个服务，为什么不能只因为主机不同就把可用性直接相乘？
问题 2（第一夜、第二夜）： 为一个有延迟目标和数据副本的请求写出最小输入，并说明如何从负载清单走到故障域清单。
问题 3（第三夜、切换恢复）： 注入共享交换机故障后，实验应记录什么，才能证明切换恢复而不是只把页面变绿？
本页小结
3.4 机房夜话 的关键不是记住故事，而是能解释：供电、制冷、网络、计算与存储共同定义故障域；冗余只有在共同故障不会同时击中副本时才有效。完成标准是从负载基线出发，沿识别负载、划分故障域、布置副本、检测失效和切换恢复观察实际，并证明复位后的同一输入重新得到基线轨迹。