1 为什么方案要写清「机房约束」
在 H15 中，我们用机架、机箱和服务器形态理解设备如何摆放。现在把视角移到机架之外：服务器接入电源、排出热量、连上网络，并且有人能够安全地维护它，才形成可交付的算力。数据中心提供的是这些条件的组合。采购清单上的计算能力，只有落在机房可承受的边界内，才可能持续供给业务。
例如，团队希望再装 16 台服务器。机架还有空余高度，网络交换机也有端口，于是认为扩容没有障碍。但如果机架已经接近配电上限，新机器就不能全部开机；如果冷却只能带走现有热量，开机也可能导致进风温度升高。空位、供电、散热和网络是相互独立又彼此关联的约束，任何关键条件不足，都可能使新增设备无法按计划使用。
容量规划因此不能只写“需要多少台”。它至少要回答：设备放在哪里，正常和故障状态下各消耗多少电，热量如何被带走，流量经过哪些链路，维护人员如何进入，以及出现异常时如何发现。每个答案都应有范围、单位和责任人。“机房够用”难以验收；“指定机架在约定故障场景下可持续支持新增 4 kW IT 负荷”才有检查对象。
这些约束还具有空间尺度。园区总电力充足，不代表某个配电支路还有余量；机房平均温度正常，不代表某台服务器进风正常；网络出口带宽充足，也不代表跨机房复制链路足够。方案需要从园区、机房、机架落实到设备，找出真正限制交付的位置。把总量平均分配到所有机架，往往会掩盖局部瓶颈。
约束也会随时间变化。日常负荷可能低于业务高峰，维护期间可用路径可能减少，扩容交付期间还可能有新旧设备同时运行。容量表应注明时间窗口与运行状态，不能用凌晨的低负荷测量代替业务高峰，也不能只按全部设备健康时的条件承诺服务。对关键业务，应把约定的故障和维护情景作为设计输入。
本课把机房看作有边界的资源系统。我们不会根据某种冗余名称直接判断可靠性，而是沿着电力、热量、流量和人员的路径检查依赖。读完后，你应能把“还可扩多少”拆成可计算的问题，并能向设施、网络、安全和业务团队提出具体的确认项。数据中心条件需要共同确认，服务器选型本身无法替代这些确认。
2 电力：IT 负荷与冗余级别直觉
IT 负荷指服务器、存储、网络等 IT 设备消耗的电功率，常用 kW 表示。功率表示消耗电能的速率，电量则是累计消耗，常用 kWh 表示。设备持续以 4 kW 运行 3 小时，消耗约 12 kWh。前者影响配电和冷却容量，后者影响用电量统计。把“每小时用了多少 kW”写进方案，会让容量与费用计算混在一起。
服务器电源铭牌上的额定功率通常表示供电能力上限，不等于设备一直按该数值取电。实际负荷取决于配置、任务、功率限制与运行状态。容量规划需要结合供应商数据、代表性压力测试和历史监控，并保留合理余量。不能把闲置时的功率当成高峰需求，也不能直接相加所有电源模块的额定输出，就把结果当成真实 IT 负荷。
从外部供电到服务器，常见路径包含配电设备、UPS、下游配电及机架配电单元 PDU。UPS 通过储能在供电切换等短时中断中维持输出，发电机则可能承担更长时间的后备供电；具体接入顺序和旁路形式依现场设计而定。UPS 并不代表无限续航，发电机也需要启动、燃料、维护和定期验证。应询问可支持的负荷、续航条件及切换过程。
N 表示满足约定负荷所需的容量。N+1 表示在该计算边界内增加 1 个容量单元，使失去指定单元后仍可能满足需求；2N 通常表示配置 2 套各能承担需求的系统。这些名称只能帮助建立直觉，不能替代拓扑检查。UPS 模块有冗余，而下游只有 1 条配电支路，仍可能因该支路故障中断。冗余必须注明针对什么部件、哪些路径和多大负荷。
双电源服务器接入 A、B 路，是常见的设备供电方式。正常时可能由两路分担，也可能因电源策略而不均衡。不能假设失去 A 路后 B 路仍只承担原来的一半：承接供电的路径需要具备相应容量，而且必须确认设备电源模块在该配置下能够独立承载整机。不同电源插座不一定代表独立上游，应沿线路核对共同设备和故障边界。
计算机架容量时，先使用设施团队确认的持续可用上限。假设某支路按运行规则允许持续支持 6 kW，当前预计高峰为 4.2 kW，新增设备高峰合计 1.4 kW，则预计负荷是 5.6 kW，账面余量为 0.4 kW。但这还不是最终结论：还需检查相位分配、另一条供电路径失效后的转移负荷，以及启动或其他短时变化。现场限制应由具备资质的人员确认。
“留 20% 余量”可以是某项目的运行约定，却不是适用于所有电气系统的通用规则。电压、相数、功率因数、保护装置与当地规范都会影响容量判断。入门阶段应学会索取明确的可用 kW 和测量边界，不自行根据插座外观估算承载能力。涉及带电测量、改接线路或保护装置调整的工作，交给授权的设施电气人员执行。
3 制冷与热通道
服务器消耗的电能，在机房容量规划中可以近似视为最终转化成热量。新增 5 kW IT 负荷，就意味着需要持续带走约 5 kW 热量。但总制冷量足够不代表每台设备都能得到足够冷空气。冷量还要通过气流送到进风位置；风量不足、冷热气流混合、局部阻挡，都可能让少数设备先出现温度问题。
常见风冷服务器从机箱前部吸入空气，从后部排出热空气。把机架前部相对排列，形成供冷空气进入的冷通道；把机架后部相对排列，形成热空气汇集的热通道。具体送回风方式可采用架空地板、顶部送风等不同设计，关键在于形成可控路径，让冷空气经过设备后回到冷却系统，而不是未经设备就直接返回。
气流组织中的常见问题有 2 类。短路指冷空气绕过设备直接进入回风路径，消耗冷却能力却没有有效带走设备热量；回流指热空气重新进入设备进风侧，抬高进风温度。机架空位缺少盲板、侧面缝隙未封堵、线缆挡住风口、设备风向相反，都可能破坏原定路径。通道封闭能减少混合，但仍需与送风、消防和现场维护设计配合。
热密度描述单位机架或区域集中释放的热量。同样是 40 kW IT 负荷，分布在 10 个机架与集中在 2 个机架，对局部供风的要求不同。设施总冷量有余量，也可能无法支持高密度机架。规划时应提供机架级功率分布、设备风向和预期负荷，必要时由设施团队判断是否需要改造送风、采用近端冷却或评估液冷等方案。
检查温度时，优先看设备进风条件与部件健康状态，不能只看房间墙上的温度计。机架前部的上、中、下位置可能有差异；顶部设备常更容易吸到回流热风。机箱内部传感器又受散热结构和任务负荷影响，不能与进风温度混为同类指标。判读时应记录传感器位置、设备型号和允许范围，并结合趋势，而不是只比较某个瞬时数字。
过热不一定立即关机。设备可能先提高风扇转速，再通过降低处理频率或功率来控制温度，使任务变慢。业务看到的是延迟升高或吞吐下降，设施看到的可能只是局部温度异常。把性能、温度、风扇与功率放到同一时间轴，有助于识别这种关联。仅因设备仍在线就判断运行正常，会把保护动作误当成应用性能问题。
温度和湿度目标应按设备要求、现场设计及适用规范确定，没有适合所有机房的固定温度。降低设定温度并不能自动修复气流问题，还可能增加能耗。改动送风、加装封板或搬迁设备前，应先确认故障范围与气流方向；改动后在代表性负荷下复测，观察进风温度、设备告警和性能是否共同改善。
4 网络出口与跨机房
服务器到外部用户之间通常经过机架接入、机房内部汇聚或交换网络、边界设备及运营商线路。机房内部网络常被称为网络 fabric，可以先理解为连接大量设备的一组交换路径。数据中心可能使用多种拓扑；入门时不必背设备层级名称，而要能指出流量从哪里来、到哪里去、经过哪些共享链路，以及故障后会走哪条路径。
网络容量需要同时看机架内部、机架之间和外部出口。面向用户的请求与响应常称为南北向流量，内部服务调用、存储访问等常称为东西向流量。业务只增加少量外部访问，也可能因数据库复制或分布式计算产生大量内部流量。如果方案只写“出口 10 Gbit/s”，就无法解释内部扩容是否会堵在某组机架的上联。
链路速率也不等于应用可得到的吞吐。协议开销、并发连接、拥塞、丢包、设备转发能力以及发送端和接收端的处理能力，都会影响结果。规划时可以按业务高峰估算数据量和持续时间，再通过代表性测试校正。还应说明多个业务是否共享链路，以及低优先级同步任务在高峰时如何让路，避免平均利用率掩盖短时间拥塞。
例如 12 台服务器各有 10 Gbit/s 接口，总接口速率为 120 Gbit/s，但它们共享的上联只有 40 Gbit/s。如果业务需要同时跨过这条上联，就存在超售；如果多数流量在本地交换，影响可能较小。超售不必然错误，但需要匹配流量模式。多条聚合链路能提高总容量，单条连接也未必能同时使用全部成员链路的带宽。
跨机房不仅要估算带宽，还要检查往返时延、抖动、丢包和中断恢复。复制 1 TB 数据，在理想的 1 Gbit/s 净数据速率下约需 8000 秒，实际还会受到业务争用、协议开销和磁盘速度限制。持续复制则要比较数据产生速度与可用复制速度。如果平时就追不上变化，中断后的积压只会更难消除，不能靠“晚上再同步”作为容量结论。
同步复制往往需要等待远端确认，因此跨机房时延可能进入业务请求路径；异步复制减少这种等待，但故障时可能存在尚未送达远端的数据。选择取决于业务对延迟与数据丢失窗口的要求，还涉及应用一致性设计。这里需要形成的直觉是：距离、网络、复制策略与业务目标相互约束，不能因为增加第 2 个机房，就直接宣称已经具备灾难恢复能力。
网络冗余也要沿物理路径检查。2 条线路可能共用入楼管道，2 家运营商也可能经过共同设施。双出口是否能切换、切换后剩余带宽够不够、访问控制与路由是否正确，都需要验证。方案应给出线路端点、共享风险、故障后的流量分配和测试方法。跨机房演练还要关注回切过程，防止恢复时的大量同步流量压垮正常业务。
5 物理安全与权限分区
物理接触可以绕过很多软件层面的保护。能进入机架的人可能接触控制台、存储介质、电源和网络线缆。因此，物理安全不是“有门禁”就结束，而是按区域与任务限制接触范围。常见边界包括园区入口、机房入口、特定区域、机架以及管理终端。不同边界应有不同授权，不能把能够进入建筑等同于能够操作所有设备。
授权应围绕具体工作建立。例如，设施人员负责配电和冷却，服务器维护人员负责指定设备，访客在限定时间和陪同条件下进入指定区域。紧急处理可以有应急授权流程，但应记录原因、范围、批准人和操作内容，并在事后复核。共享门禁卡、借用他人身份或长期保留临时权限，会使记录难以归属到实际操作者。
人员进入与设备变更应能关联。更换磁盘时，除了登记进入时间，还应记录设备标识、介质序列号、工单和处理结果。退出或报废的介质可能保留业务数据，需要按组织要求进行擦除、销毁或受控交接，并保留证据。只记录“服务器已下架”，无法说明数据去了哪里，也无法证明离场设备与批准清单一致。
现场巡检应遵守授权边界。观察指示灯、核对标签和读取已授权监控，与拔插线路、打开机柜或操作电气设备，风险和权限要求不同。未经确认拔掉“看起来多余”的线，可能移除备用链路；误断电也可能触发其他设备负荷转移。操作前明确对象、预期影响、回退办法和沟通渠道，比凭经验快速处理更容易控制影响。
远程管理也应纳入边界。服务器管理控制器能提供开关机、控制台等能力，通常需要与业务网络分区，并使用独立的身份授权与审计。物理门禁记录和远程管理日志不是相互替代的证据。排查某次重启时，应能把现场维护、远程命令、电力事件与设备日志对齐，避免只有结果而无法还原原因。
权限设计也影响容量交付。新设备到了机房，如果缺少进入许可、安装窗口、线缆标识或介质处理流程，仍然无法完成上线。方案应在交付条件中列出相关责任人与审批时限，并约定供应商、运维和设施团队如何协作。安全分区的目标是让经过授权的工作可控地完成，同时使异常接触可以被及时发现和追溯。
6 观测与巡检：温湿度、PUE 入门
机房监控需要把设施状态与 IT 状态放在同一张关系图里。设施侧观察供电路径、负荷、UPS 状态、制冷设备、温湿度和漏水等；IT 侧观察设备功率、部件温度、风扇、错误与业务表现。只有机房平均值，无法定位局部异常；只有设备告警，又可能看不到上游故障。资产标识、机架位置和时间同步是关联这些数据的基础。
温度测点应覆盖有意义的位置，例如高密度机架的进风区域、容易回流的顶部及送回风关键位置。湿度也要说明测量方式；相对湿度随温度变化，相同相对湿度不总表示相同水汽含量。对结露风险的判断还涉及露点和冷表面条件。运行目标应由设施团队结合设备要求制定，不能照搬某张网上的“最佳温湿度表”。
告警需要区分瞬时变化与持续异常，同时避免把保护阈值当作正常运行目标。可以设置趋势预警与严重告警，并指定接收人、响应时限和升级路径。例如进风温度持续升高时先检查负荷与气流，出现设备过温保护则按故障流程处理。只发通知却无人负责，或者大量重复告警长期未处理，都不能形成有效观测。
PUE 是数据中心能源使用效率的常见指标，定义为同一统计周期内，数据中心总能耗除以 IT 设备能耗。总能耗的统计边界通常包含 IT 以及供电、制冷等支撑系统，需要按采用的方法明确。若总能耗为 150000 kWh，IT 能耗为 100000 kWh，则 PUE 为 1.5。它是没有单位的比值，不表示服务器利用率，也不直接表示业务效率。
在该例中，额外支撑能耗为 50000 kWh，占总能耗约 33.3%，不是 50%。50% 是相对于 IT 能耗的比例。解释指标时要明确分母。短时功率之比可以帮助观察运行变化，但不能未经说明就当成年 PUE；年度统计应对相同周期的能耗求比值，也不应直接平均每小时的 PUE，因为各时段 IT 能耗权重可能不同。
PUE 较低通常说明支撑系统相对于 IT 的能耗较少，但不能单凭它判断数据中心总体更环保或业务更高效。气候、统计边界、IT 负载水平和运行要求都会影响比较。提高无用计算负荷，可能使比值看起来改善，却不会给业务带来价值。扩容评估应同时观察绝对能耗、可交付容量、业务工作量和服务表现，而不是只追求单项比值。
巡检用于补充监控盲点，例如标签脱落、线缆阻挡、异常声音、门未关闭或漏水迹象。巡检应有路线、检查对象和异常处理记录，不能只勾选“正常”。发生事件后，保留告警、负荷变化、维护操作与现场照片等证据，并按同一时间线整理。持续积累这些记录，才能修正容量假设，识别哪些机架或路径经常接近边界。
7 常见坑：只订服务器不订电与位
常见的扩容失误，是把“服务器到货”当成“容量上线”。实际上还需要机架位置、承重条件、电力路径、散热能力、网络接口、光模块与线缆，以及安装维护空间。即使设备可以塞进空位，机架深度、导轨、布线方向和地板承载也可能不匹配。H15 中的形态与尺寸检查，应与本课的基础设施检查一起进入交付清单。
另一个失误是只算新增设备。扩容期间可能需要保留旧集群、同时复制数据并执行验证任务，实际高峰会高于最终稳态。故障期间，负荷也可能集中到剩余电源路径或网络链路。容量计划应列出稳态、迁移和约定故障情景，分别说明持续时间与上限。只看迁移完成后的理想状态，会漏掉最容易出问题的交付窗口。
总量与分布混淆也很常见。某机房仍有 100 kW 可用电力，不能推出任意机架都能再装 10 kW。配电支路、局部送风、网络上联及物理位置都有自己的限制。审批时应把每台设备映射到目标机架，再核对该机架及其上游资源。使用平均功率填满所有机架，尤其容易在集中运行高负荷任务时暴露问题。
“以后再补冗余”会改变容量口径。如果目前正常状态下已经把单路容量用满，那么将来接入第 2 路电源，也不一定立即获得故障承载能力；还要检查路径独立性、模块容量和切换行为。同样，双出口正常时都接近满载，失去其中 1 条后就无法维持原业务量。冗余资源是否计入正常可售容量，必须在方案里明确。
还有团队把标称值直接当成交付值：把电源额定功率当成运行功率，把网口速率当成有效吞吐，把冷机总冷量当成任意位置可获得的冷量。这些数字各自有测试条件和适用边界。收集数据时应同时记录来源、测量时间、工作负荷与置信程度，对关键未知项安排验证，并说明未验证前采用的保守限制。
避免这些问题的方法，是把设施交付作为扩容依赖项，而不是上线前的临时检查。采购前先确认目标机架和资源预留，安装前复核实际余量，上线后用代表性负荷验证并留档。资源预留还应有有效期和释放机制，防止多个项目重复占用同一份余量。发生变更时同步更新容量表，避免方案里的“可用”早已被其他项目消耗。
8 案例：扩容卡在电力头
某团队计划在现有机架增加 8 台服务器，每台预计高峰功率为 0.6 kW。业务方案认为机架还有 8U 空间，交换机也有足够端口，因此安排下周上线。安装前，设施人员发现该机架在约定故障情景下允许的持续 IT 负荷上限为 10 kW，当前高峰预计已达 7.2 kW。问题出在电力余量，机架的空余高度无法解决它。
先统一口径：10 kW 是设施确认的运行上限，已考虑本案例要求的供电故障情景；7.2 kW 是当前设备在代表性高峰下的估计，仍需保留其依据。新增需求为 8 × 0.6 = 4.8 kW，合计为 12 kW，超过上限 2 kW。不能因为日常监控只有 5 kW 就宣称可以上线，也不能把 A、B 路标称容量相加后推翻故障状态的限制。
即使先装 4 台，预计合计负荷为 9.6 kW，也只剩 0.4 kW 账面余量。它是否足够，取决于项目约定的运行余量、估计误差和负荷变化，因此不能只凭算术结果批准上线。团队还需确认功率估计是否覆盖计算高峰、启动和维护窗口，并检查上游配电及局部冷却。容量表应区分已测量、已预留和待确认的数据。
团队提出 3 种选择。第 1 种是把新增服务器放到其他具备电力、散热和网络条件的机架；第 2 种是先退役部分旧设备，释放可确认的容量；第 3 种是评估配电改造。它们分别受到布线与位置、迁移风险、设施交付周期的约束。选择时要比较可用日期与最终可交付业务能力，而不能只比较硬件采购金额。
功率封顶可以作为经过验证的补充措施。若限制单机功率能够把高峰控制在上限内，还必须测量限制后的吞吐与尾延迟，并检查重启、升级或策略失效后限制是否仍生效。不能把“少用点电”的操作建议当成有保证的容量。即使每台都降低功率，业务工作量也可能需要更多设备或更长时间完成，效果需要共同评估。
最终，团队把新增设备分布到另 2 个已确认资源的机架，并重新核对网络上联与数据复制路径。安装前，设施团队确认电力与气流条件，网络团队确认接口和链路配置，业务团队准备代表性负荷。上线分批进行，先观察实际功率与进风温度，再逐步增加负荷。任何阶段接近约定边界，都停止继续加量并重新评估。
验收材料包括目标机架、实际功率记录、关键温度趋势、链路利用率及故障承载依据。团队还更新了容量表，写明剩余可用量和被谁预留，防止同一份余量再次被承诺。这个案例的关键不在于找到了空机架，而在于把“扩 8 台”转化为“在哪些条件下交付多少业务能力”，并让所有依赖都有明确负责人。
9 排查案例：局部过热导致降频
某机架新增设备后，少数服务器的批处理耗时明显变长。应用错误率没有明显变化，机房墙面温度也正常，团队最初怀疑存储变慢。此时不宜直接提高机房制冷强度或反复重启。先记录受影响设备、开始时间、近期变更和性能变化，再比较同机型、相似负载、不同机架位置的设备，建立可以检验的假设。
监控显示，变慢设备主要位于机架上部，任务期间 CPU 实际运行频率下降，风扇转速升高，并出现热相关保护记录。存储延迟与网络丢包没有同步异常。这些证据支持热限制方向，但仍不足以断定原因：部件散热故障也会产生类似现象。接下来要区分设备自身问题与外部进风问题，避免看到温度告警就直接归因于空调。
现场授权人员检查机架前部上、中、下进风条件，发现顶部进风明显高于中下部。进一步核对风向与布置，发现新增设备旁存在未封闭空位，机架侧面也有较大缝隙，热通道空气能够回到上部进风侧。相邻机架同型号设备在相近负载下未出现相同问题，进一步支持局部热回流的判断。房间平均温度无法反映这条异常路径。
排查还应检查风扇健康、设备风向、进风口是否被线缆或包装物遮挡，以及传感器读数是否可信。若进风条件正常而某台设备内部持续过热，则需要按设备维护流程检查内部散热。不要因为已发现 1 个气流缺陷，就停止收集其他证据；真实环境可能同时存在局部回流和设备部件故障，修复范围应由证据决定。
短期处置先控制风险。业务团队可以迁移部分任务或降低并发，使设备退出持续热保护状态，同时保留必要日志。设施与运维人员按现场流程补齐合适盲板、处理缝隙并整理阻挡气流的线缆。涉及通道封闭、送风调整或设备搬迁时，应确认对相邻区域的影响。随意打开地板或机柜门可能改变气流，不能当成通用处理方法。
修复后，在相近进风环境和代表性负载下比较性能、频率、风扇、部件温度与热保护记录，并观察机架上部进风是否恢复到约定范围。只看到温度下降还不够，任务性能应恢复到预期，且相邻设备没有出现新的异常。如果负载已经降低，就不能把更凉的结果全部归因于气流修复，需要恢复可比较条件后再判断。
最后，把本次变更与异常时间线归档，增加高风险位置的进风监测，并把盲板、风向和线缆检查加入安装验收。记录也应更新机架可承载热密度的判断，避免下一次扩容重复同样问题。排查结论应写明证据、处理和复测条件，例如“修复顶部热回流后，在约定负载下未再触发热保护且任务耗时恢复”，比“空调问题已解决”更可复核。
放进方案里
方案中的机房章节应把设备需求转换为可验收的基础设施条件。先列目标机房、机架位置、设备数量与形态，注明新增和现有 IT 负荷的估计来源，分别描述正常、高峰、迁移及约定故障状态。电力部分写清可持续上限、供电路径、共同故障点和余量口径；不要仅附电源额定功率表，或只写“双路供电”。
制冷部分提供机架功率分布、设备风向、进风要求与测点，说明高密度区域怎样送风和回风。网络部分列出业务出口、机架上联及跨机房复制需求，注明可用带宽、时延要求、共享路径和故障后的承载方式。物理安全部分明确进入区域、操作范围、临时授权、介质处理和审计责任，使安装与后续维护都有可执行流程。
例如可写：“新增 8 台服务器，预计高峰 IT 负荷合计 4.8 kW，分布于已确认资源的目标机架。设施团队在安装前确认各供电路径的故障承载能力及冷却条件；网络团队确认接口与复制链路；业务团队按分批加压方式验收。所有功率、温度与网络数据记录测量位置、时间窗口和工作负荷。”实际方案还应填入具体位置、数值与负责人。
验收不能只检查设备亮灯。应约定代表性负载下的持续运行观察，核对功率、进风温度、热保护记录、链路表现和业务性能；故障切换验证按批准的范围与窗口实施。PUE 另行注明统计边界和周期，用于能源观察，不能替代局部供电、散热和业务验收。最后列出未确认条件、确认期限、资源预留有效期和容量表更新责任，把上线依赖落实为可追踪交付项。
10 小结：走向弹性伸缩（C5）
数据中心让设备获得持续运行的条件。容量取决于电力、散热、网络、空间和操作权限是否同时满足，并且要在约定的高峰、维护与故障状态下成立。机架空位、园区总电力、机房平均温度和出口标称带宽，都不能单独证明可扩容。
提交方案前，逐项核对：
- 空间：目标机架、尺寸、承重、维护空间与安装窗口是否落实？
- 电力：IT 负荷来源、持续上限、A/B 路径与故障转移容量是否明确？
- 散热：局部热密度、设备风向、进风条件和回流风险是否确认？
- 网络：内部流量、外部出口、跨机房时延与剩余链路承载是否满足需求？
- 安全：进入区域、操作授权、远程管理和介质流转能否审计？
- 观测：测点、时间同步、告警责任、巡检及容量更新是否可执行？
- 交付：资源预留、迁移重叠负荷、验收条件和未决事项是否有人负责？
自测时尝试回答：为什么双电源不能直接证明供电可靠？为什么房间平均温度正常，设备仍可能热降频？为什么 PUE 改善不等于业务效率提高？如果能沿具体路径和统计边界解释这些问题，就能更可靠地把机房条件写进容量方案。
下一课转向 C5 弹性伸缩。
把本课的电力、散热、网络出口与机柜约束带走：下一课讨论弹性伸缩时，扩出来的实例仍要落在这些机房/可用区限额之内，并检查「计算弹性」会不会先撞上电与位。
作业：用本课 1 条电力/机柜限额，写成 C5 伸缩上限的硬约束输入。