摘要

  • Firehose 1.0 的早期设计可能出现一种故障：两组机器各自还能连接其他机器，却无法彼此通信。该方案从未承载生产流量，不能将它写成今天的事故。
  • 后来的独立网络块缩小了维护时撤出服务的范围，但共享软件、控制链路和配置过程仍可能把物理冗余重新耦合起来。
  • Urs Hölzle 的基础设施管理职责与联合署名，为理解这项团队工程提供了依据，并不证明每一种技术都是他个人设计的。

“机器还在线”有时是一个不够用的判断。一组机器能与别处通信，另一组也能，唯独这两组不能彼此交换数据。应用看到的不是一块边界清楚的孤岛，而是网络中某一种关系消失了。

Google 团队在 2015 年 SIGCOMM 原论文中描述过这样的情况。Firehose 1.0 的机架顶部交换机上行连接受限；如果两台交换机中位于相反侧的上行链路在同一个修复时间窗口内失效，两台交换机下的机器就可能出现这种非传递的连通性。作者指出，应用很难处理它。

这里有一道重要边界：Firehose 1.0 从未承载生产流量。这是早期方案的设计与实施教训，不是某次现行 Google 服务中断的报告。它值得研究，恰恰因为团队留下了“为什么这一版没有走进生产”的细节。

人物与团队，怎样连接起来

Urs Hölzle 是论文的多位共同作者之一。Google Research 的人物介绍称，他现为 Google Cloud 的 Google Fellow，直到 2023 年曾任技术基础设施高级副总裁，负责支撑 Google 服务的服务器、网络和数据中心的设计、安装及运行。

这份职责说明人物为什么与这段工程史有关：网络设计、设施建设、任务放置和持续运行，并不是互不相干的工作。但职务和署名都不足以分配每一项具体方案的发明权。把整个演进写成一位高管的个人创造，会遮住原论文最有价值的部分——团队如何同时处理线路、交换芯片、控制软件和维护流程。

Google 的 2013 年计算服务公告与 Hölzle 的 2020 年网络文章，也分别记录了他在当时的基础设施职责。后者区分 Google 网络与互联网接入服务商承担的最后一公里。不能据此把用户经历的全部连接依赖，都纳入同一个人的控制范围。

为了分散故障，通信反而更远

原论文解释了一种应用与网络之间的联动。把计算任务和存储分散到不同供电与故障域，可以减轻一个局部问题对工作的集中冲击；代价是机器之间不再那么“就近”。原来可能留在局部的数据交换，需要跨越更多机器组。

多级 Clos 交换结构通过大量交换部件形成多条路径，使大型网络不必只围绕一个巨型机箱来组织。但图上有多条线，并不等于应用所需的每一对机器都能在特定故障组合下继续通信。Firehose 1.0 暴露的，就是路径数量与实际连通关系之间的差别。

后续 Firehose 1.1 同时调整了物理封装与连接结构。用于容纳交换芯片的普通服务器被专用机箱替代，系统采用独立的带外控制网络、成对的机架顶部交换机和修改后的汇聚结构。团队报告了更好的链路故障鲁棒性，也记录了布线劳动与设备摆放的困难。一个架构必须经得起安装、重新接线和部件更换，才算真正可以运行。

维护一块，究竟撤走了什么

后来的 Freedom 架构把维护单位讲得很具体：典型连接层由四个独立块组成，某一块可以先排空流量，再退出服务并升级，汇总容量因此下降 25%。可以干预的对象，缩小到了整个连接层的一部分。

这个比例只属于文中那种安排。它没有保证所有应用在维护期间都保持原来的性能，也没有说明剩余每条路径的负载。仍需判断工作是否装得进剩下的资源。

同一论文中的另一幅升级图，恰好说明不能仅按设备数量理解影响。它把一个 Clos 网络的机箱分为四组；禁用其中一组后，跨级损失相乘，剩余容量是 56.25%，而不是 75%。分成八组可以让过程更温和，却需要更长时间。这个例子与 Freedom 的四个独立块不是同一种拓扑，不能把两者的比例互换。

维护单位是否合适，取决于撤出之后还剩下哪些连接、流量怎样重新分布，而不是仅仅“这一批占了多少台机器”。

分开的硬件，仍共享哪些风险

论文对 Firehose、Watchtower 和 Saturn 的 Firepath 控制方式有详细说明：系统分发共同的拓扑与链路状态，各交换机再在本地计算转发表。这里集中的是协调状态，并不是由一个控制器逐包决定转发。冗余主节点与独立控制网络支撑这一安排。作者明确指出，Jupiter 的详细控制架构不在该论文的范围内，不能把前代说明直接套到 Jupiter。

在 Jupiter 之前，少量集群参数也被用来生成物料清单、机架与线缆计划、控制网络资料、监测信息和统一交换机配置。选择更少，让重复建设更容易；与此同时，共同规格的正确性也变得更重要。

运行案例把这种共享风险具体化。一次全网同时重启，暴露了存活检测与路由计算争抢有限交换机处理器资源的问题。老化的内部链路和控制网络链路，暴露了未被充分监测的故障状态。还有一次 Freedom 的 BGP 配置变更，未加锁的并发读取与写入相互影响，产生了不完整配置；团队随后回退并加固工具。

这些段落没有给出完整事故日期、持续时间、客户损失或总体故障率。它们提供的是机制证据：物理上独立的部分，可能仍被同一种软件转换、监测盲点或配置操作一起影响。

留下的是运行能力，不是个人神话

2015 年会议版本与 2016 年 CACM 版本是同一项工作的不同出版版本，不是两次独立验证。运营方自己的回顾可以解释历史机制，却不能证明今天所有数据中心的实现与可用性。

在这段历史里，Hölzle 的意义，是其明确的基础设施职责与团队共同工程之间的连接。真正值得保留下来的成果，是让一个大网络能够按边界清楚的部分接受改变。下一次撤出其中一块时，哪些东西确实分开了，哪些仍共享同一个变化或故障，这才是这项能力的实际内容。

来源