摘要
- Tempest Hosting, LLC 拥有真实的公共运营面：AS36231 已宣告，PeeringDB 将 Tempest 列为全球内容网络，流量为 1-5 Tbps，有八个设施存在点和一个 AS 集，而 RIPEstat 在 2026-07-15 快照中观察到 19 个 IPv4 前缀和 20 个 IPv6 前缀。
- 更有用的风险问题不在于 Tempest 是否存在，而在于当某个站点（如阿姆斯特丹、达拉斯、伦敦、法兰克福、迈阿密、芝加哥或悉尼）成为薄弱点时，哪些客户工作负载依赖于哪些机架、路由器、本地备件池、上游运营商和支持交接。
- 公开的维护和事故记录在这里异常有用：Tempest 披露了一次伦敦核心路由器迁移、一次达拉斯机柜和路由设备升级、一次达拉斯上游运营商故障、一次法兰克福 IP 问题，以及一次因核心交换机故障和备件采购延迟导致阿姆斯特丹宕机。
- 证据支持强大的网络足迹评分，但并非无限制的容量声明。已安装的前缀、PeeringDB 流量范围、测试文件和设施列表并不能证明客户可用的余量、合同电力权利、库存的替换硬件或保证的迁移时间。
一家主机公司可以真实存在，但在运营层面仍然不透明
Tempest Hosting, LLC 是那种公开痕迹看起来比小型网页主机宣传册大得多，但仍将最昂贵的问题留在公众视野之外的服务商。公共身份始于BTW 目录中的公司页面，但基础设施测试从 AS36231 开始。RIPEstat 的AS 概览将持有者标识为 TEMPEST-HOSTING - Tempest Hosting, LLC，并标注该自治系统在 2026-07-15 查询窗口已宣告。通过 RIPEstat 的WHOIS 视图呈现的 ARIN 衍生 WHOIS 数据给出了 AS 名称 TEMPEST，注册日期为 2020 年 5 月，以及指向 tempest.net 的注释。这些事实本身并不描述产品，但它们建立了一个可独立于销售语言测量的编号路由边界。
该边界并非空置。RIPEstat 的宣告前缀视图在此处使用的快照中返回了 40 条前缀时间线条目。其路由状态视图将其分离为 19 个 IPv4 前缀、4,864 个 IPv4 地址、20 个 IPv6 前缀和 65,538 个可见的 /48 等效 IPv6 单元，从 326 个 IPv4 RIS 对等体中的 326 个和 322 个 IPv6 RIS 对等体中的 322 个获得完全可见性。RIPEstat 的邻居视图显示了五个观察到的邻居，包括四个左侧关系和右侧关系。对 104.152.143.0/24 的代表性 RPKI 检查返回了有效的路由源结果。综合来看，这些记录表明 Tempest 拥有活跃的公共路由边缘。它们没有说明每个边缘背后有多少客户，哪些服务使用提供商分配的地址，或者前缀计数是否与服务器库存直接对应。
互连记录提供了下一层。PeeringDB 将Tempest Hosting, LLC列为 AS36231，网站为https://tempest.net，IRR 集为 AS-TEMPEST，类型为内容，全球范围，比率平衡，开放对等策略，流量范围为 1-5 Tbps。PeeringDB 的网络 API在配置文件中给出了 26 个 IPv4 前缀和 30 个 IPv6 前缀，而设施 API列出了八个设施：Telehouse London Docklands North、NTT Frankfurt 1、Iron Mountain Amsterdam AMS-1、CoreSite Miami MI1、Equinix SY3 Sydney、ColoCrossing CHI1、IP House London 和 365 Data Centers Richardson TX1。对应的交换连接 API为该 PeeringDB 网络对象返回了零个公共 IX LAN 条目。这一组合具有启发性：Tempest 呈现出多设施足迹，但公开列出的互连面是设施密集而非交换端口密集。
对于买家来说，这一区别很重要。设施条目可能意味着路由器、服务器机柜、传输交接点、客户面向服务节点或待定存在点。PeeringDB 流量范围是自我报告且故意粗略的。前缀计数可能包括管理、任播、游戏服务器、客户或预留空间。正确的问题不是“Tempest 是否有全球基础设施？”公开证据支持这一点。正确的问题是“哪些物理和合同部分将付费服务器转化为客户所购市场的可用、可恢复容量？”
可见足迹是全球性的，但运营面是局部的
Tempest 自己的状态页面异常具体。当前状态页面在 2026-07-15 显示伦敦、法兰克福、阿姆斯特丹、芝加哥、迈阿密、达拉斯和悉尼处于运营状态，分组在欧洲、北美和大洋洲。它还显示了 30 天正常运行时间数据：伦敦、芝加哥、迈阿密和悉尼为 100.0%，达拉斯为 99.4%，法兰克福为 97.4%，阿姆斯特丹为 84.6%。这些不是正式审计的可用性数字，并且仅覆盖该页面上代表的平台组件。尽管如此，它们使服务地理比通用主机品牌更具体。
Tempest 的 Looking Glass增加了第二个具体点。它暴露了来自存在点的实时诊断信息，在捕获的页面中列出了达拉斯测试位置，测试 IPv4 为 104.152.143.215，数据中心为 Equinix DA1。它还暴露了 100 MB、1 GB、5 GB 和 10 GB 测试文件。Looking Glass 证据很有用，因为它邀请外部测量，但它很狭窄：一个测试文件证明存在一个诊断端点并且可以从用户测试的位置到达。它不能证明完整的客户资产位于同一设施，所有产品具有相同的运营商路径，或者在另一个城市订购的服务器继承了达拉斯诊断路由。
PeeringDB 设施列表使地理范围比 Looking Glass 更广。Telehouse London Docklands North 是伦敦运营商密集站点；NTT 的Frankfurt 1 数据中心由 NTT 呈现为大型园区，拥有 70.1 MW 的关键 IT 负载和 DE-CIX 接入；Iron Mountain 的Amsterdam AMS-1被描述为哈勒姆园区，拥有当前电力和计划扩展；CoreSite 的Miami MI1是专为迈阿密建造的设施，通过光缆连接到 MI2；而 Tempest 页面本身列出了悉尼、芝加哥和达拉斯作为运营地点。这些设施事实有助于解释电力、冷却、会面室、交叉连接和本地接入限制在服务中的位置。它们不能证明 Tempest 在任何单个站点中的确切机柜大小、预留电力、机柜密度或远程手协议。
这就是反复出现的容量问题。安装容量是网络或设施理论上可以支持的容量。可用容量是可以销售、供电、冷却、修补、监控、计费并在不违反上游、机架、电力、支持或硬件库存约束的情况下恢复的容量。全球 PeeringDB 范围和八个设施条目可能使提供商比单一站点主机更具弹性。它们也创造了更多客户必须提出特定站点问题的地方。哪个城市容纳主服务器？哪个城市容纳备份？迁移是冷迁移、温迁移还是自动迁移？公共 IP 是否可在 Tempest 位置之间移植？如果达拉斯的上游运营商发生故障，流量是会转移到另一条达拉斯路径、另一个北美城市，还是会临时重路由并影响会话？
伦敦迁移展示了弹性的真正成本
Tempest 物理依赖最清晰的公开例子是已完成的伦敦网络升级。Tempest 表示正在扩展到 Telehouse London 数据中心园区，并将核心路由基础设施迁移到那里。它还说，工作需要从现有边缘路由器撤回 BGP 宣告，启用新的 Telehouse 路由器，宣告 IP 地址空间，并验证跨上游提供商和对等体的路由。客户被警告在路由传播和测试期间可能出现连接中断、数据包丢失和短暂中断。
该维护通知比普通正常运行时间消息更重要，因为它显示了隐藏的依赖图。可见产品可能是专用服务器、虚拟专用服务器、游戏服务器或托管服务。然而，重要的变化是运营商中立园区中的路由器迁移。故障模式不仅是“服务器宕机”，而是“互联网到达服务器的路径被故意撤回、重新宣告并验证。” 只询问 CPU、RAM 和月带宽的买家会错过使工作负载可达的实际路径。
同一通知也解释了冗余声明和冗余证明之间的区别。Tempest 描述了诸如改进弹性、更强连接性、降低延迟和为客户未来增长提供更好基础等好处。这些是 Telehouse 存在的合理好处，尤其是因为 London Docklands 是欧洲主要的互连区域之一。但维护通知仍然是一个假设，直到客户看到它在故障下如何表现。伦敦站点是否有多个上游？路由策略是否在变更窗口之前经过测试？有多少流量通过手动验证而不是自动故障转移移动？客户支持是否知道哪些前缀或产品受到影响？如果新路由器在旧边缘撤回后发生故障，恢复目标是什么？
答案可能很好，但公开记录并未完全披露。然而，公开记录确实使客户处于比模糊营销更好的位置。客户可以通过BGP.tools追踪 AS36231，将公开路由变化与 RIPEstat路由状态进行比较，并观察前缀集或邻居集是否在主要维护窗口周围变化。这些测试不能替代合同，但当提供商表示迁移改善弹性时，它们创建了独立证据。
达拉斯暴露了机架、机柜和上游层
已完成的达拉斯计划网络升级是第二个有用记录，因为它不仅仅涉及 BGP。Tempest 表示将添加新路由设备并压缩机柜空间，以便新设备可以机架安装。预计一些客户的机器将断电并移至其他机架位置，企业专用客户至少有三小时宕机时间，预算或刀片服务器至少有五小时。在窗口期间，客户在团队在机柜内或周围工作时也可能经历周期性网络中断。
这是最具体的公开提醒，表明托管容量并非悬浮在建筑之上的软件。它用螺栓固定在机柜中，用电缆连接到顶架或汇聚设备，由设施馈线供电，由房间设计冷却，并由具有物理访问权限的人员处理。压缩空间是一种基础设施行为。这意味着提供商正在更改机柜布局，为增长、硬件更换或网络升级腾出空间。它可以改善未来容量，但会造成短期故障路径，其中服务依赖于机器移动、电缆纪律、电源排序、标记和移动后验证。
达拉斯的路由事件增加了运营商层。Tempest 表示识别到达拉斯网络的路由问题，已与上游运营商接洽，因为故障位于该运营商的网络中，临时重路由流量以使服务上线，后来将流量移回正常连接路径。更新还指出，一些玩家可能在过渡期间经历短暂的断开连接。这种语言指向一个可能关心延迟和会话连续性的客户群体：游戏服务器用户或其他实时工作负载。对他们来说，如果路由重置会话或将延迟转移到改变用户体验的路径，那么“服务器保持通电”是不够的。
因此，达拉斯显示了两种不同的风险。计划风险是机柜和设备变更，客户知道维护窗口并可以安排停机。非计划风险是上游故障，提供商必须诊断所有权、与运营商接洽、重路由流量，并在不使客户影响恶化的情况下稍后恢复正常路由。两者都是可恢复的；两者对客户都不可见。认真的买家应询问对应两者的升级路径：谁可以授权紧急重路由，谁可以进入设施，谁处理机器搬迁，以及提供商如何快速传递产品特定影响而非宽泛的城市级状态。
阿姆斯特丹是备件课程
Tempest 的阿姆斯特丹宕机是记录中最硬的公开证据，因为它指出了非常具体的约束。该事件影响了阿姆斯特丹，开始作为宕机调查，后来被识别为核心交换机故障。Tempest 表示阿姆斯特丹是一个尚未运送备件的站点，因此正在接触当地供应商以采购替换件。后来连接恢复并受到监控。
该披露在运营上有价值。它将模糊短语“硬件故障”转化为可操作的依赖：核心交换机、尚未在站点上存在的备件以及本地供应商采购。对于决定是否将生产部署在阿姆斯特丹的客户，教训不仅仅是提供商发生了一次宕机。宕机总会发生。教训是多站点足迹仍然包含站点间的成熟度差异。一个站点可以被列出、宣告并运营，而其备件池不如更成熟的站点完备。提供商可以恢复服务，但恢复路径可能依赖于本地采购而非架子上现成的替换件。
这就是安装容量与可用容量成为弹性问题的地方。机柜可以有空间。设施可以有电力。前缀可以被宣告。这些事实都不能保证交换机故障后所需的替换件已在正确城市。可用容量包括使服务能够在故障中存活的枯燥库存：备用交换机、光模块、电源、磁盘、电缆和兼容路由器卡。它包括远程手权限、供应商交货窗口以及快速跨境运输的能力。在阿姆斯特丹，Tempest 自己的公开事件语言表明备件放置当时尚未完成。
这并不使阿姆斯特丹站点不可用。它使尽职调查问题更加尖锐。买家可以询问缺少备件是一次性的早期问题，还是该站点现在已有库存替换件，以及其他新城市是否有类似差距。买家还可以询问服务如何按城市划分：如果阿姆斯特丹节点故障，客户是否可以迁移到伦敦、法兰克福或其他 Tempest 区域，而无需更改应用架构？备份是否已在站点外部？IP 地址是可移植的还是只有数据？客户是否可以从快照恢复，如果是，当整个城市发生故障时，队列需要多长时间？
状态页面将正常运行时间转化为工程证据
Tempest 的状态记录很有价值，因为它将可用性转化为带日期的运营历史，而不是品牌承诺。状态页面不仅声称公司拥有全球位置。它显示了伦敦、法兰克福、阿姆斯特丹、芝加哥、迈阿密、达拉斯和悉尼的单独服务区域，并在审查的时间点展示了跨它们非常不同的 30 天数据。伦敦、芝加哥、迈阿密和悉尼显示为 100.0%。达拉斯显示为 99.4%。法兰克福显示为 97.4%。阿姆斯特丹显示为 84.6%。这些数字不应被视为审计的服务级别性能，因为公共状态页面由提供商维护并定义其自己的监控组件。它们仍然有用，因为它们防止足迹被解读为单一平滑云。每个城市都有自己的维护历史、故障历史和恢复行为。
这对于比较位置的买家尤为重要。如果提供商有七个城市，客户可能假设这些城市是可互换的。Tempest 的公开记录反对这一假设。阿姆斯特丹的 30 天数据因公开的核心交换机故障和替换采购问题而下降。达拉斯经历了计划机柜/路由设备升级和上游运营商事件。法兰克福发生了 IP 问题。伦敦发生了计划核心路由器迁移到 Telehouse 园区。悉尼、迈阿密和芝加哥在同一状态窗口中看似平静，但公开平静并不是相同备件库存、相同上游拓扑或相同产品可用性的证据。这意味着审查的公开状态记录未显示这些位置的相同中断。
状态历史也将计划与非计划风险分开。计划维护不仅仅是提前通知的停机。它是服务背后发生多少物理变化的指标。伦敦通知显示路由撤回、路由器启动和上游验证。达拉斯计划升级显示机器移动、机柜合并和新路由设备。这些是投资的迹象，但也表明可用容量有时需要服务中断。提供商只能通过接触路由器、电缆、机柜和机器来扩展容量。因此，客户应询问扩展工作是否按城市安排，维护是否影响所有产品或特定产品系列，以及通知是否足够精确地识别 IP 范围或客户组以进行规划。
非计划事件测试系统的不同部分。达拉斯运营商故障要求 Tempest 与上游提供商接洽并重路由流量。阿姆斯特丹故障需要本地替换采购。在这两种情况下，客户的体验取决于 Tempest 识别负责层并移动到正确恢复路径的速度。机架电源故障、核心交换机故障和上游路由故障对客户来说可能都像是“服务器不可达”。它们需要不同的响应者。提供商必须知道是派遣远程手、开运营商工单、更改 BGP 策略、更换硬件，还是告诉客户在其他地方恢复。
这使得状态措辞成为有用的尽职调查对象。客户应关注未来事件是否识别位置、产品系列、层、临时解决方案和最终恢复。城市级“运营”标记是好消息，但好的事件报告通常比绿色徽章更具信息性。它揭示提供商是否理解自己的依赖栈，以及客户是否收到可用于下游沟通的语言。Tempest 的公开通知在多个案例中确实命名了具体层，这加强了分析。剩余的差距是客户特定的：公共状态页面很少告诉个人买家其确切服务器、地址块、备份和支持层级是否被显示的组件覆盖。
法兰克福和迈阿密展示为何设施质量不是提供商证明
法兰克福很有用，因为公开记录有两种不同类型的证据。PeeringDB 将 NTT Frankfurt 1 列为 Tempest 设施存在点，而 NTT 的设施页面描述了一个大型园区，具有运营商中立连接、DE-CIX 接入、冗余运营商会面室和主要电力容量。另外，Tempest 的法兰克福事件称一次 IP 问题影响了法兰克福位置，后来得到解决。设施可能很大且连接良好，但客户的服务仍然依赖于 Tempest 在该设施内部或周围的自己的设备、地址计划、上游选择和支持响应。
相同的逻辑适用于迈阿密。CoreSite 的 MI1 页面描述了一个专为迈阿密市中心建造的数据中心，通过光缆连接到 MI2，并设计用于应对严重风暴条件。这是有价值的物理背景。它告诉我们为什么迈阿密可能是内容、游戏或面向美洲流量的合理位置。它本身也不能说明 Tempest 的确切机柜分配、交叉连接、电力消耗或客户迁移路径。强大的设施可以托管弱部署；中等设施可以托管精心设计的部署。公开设施页面设定物理范围，而非提供商的执行。
这种区别尤其重要，因为客户通常购买品牌而非建筑。如果 Tempest 客户在达拉斯订购服务器，他们可能认为自己购买了 Tempest 产品。在运营上，他们购买了复合产品：Tempest 的硬件、Tempest 的路由器策略、设施运营商的电力和访问制度、一个或多个运营商、远程手或本地员工、支持队列、计费系统和迁移规则。当某些东西损坏时，客户体验最慢的负责部分。公开事件记录很有用，因为它告诉我们这些部分已在真实事件中出现。
实际尽职调查步骤是将服务分为若干层。公司层是 Tempest Hosting, LLC。路由层是 AS36231 及其观察到的邻居。设施层是 PeeringDB 和 Tempest 状态页面命名的站点。产品层是专用、预算、刀片、虚拟专用或托管容量。恢复层是当产品和设施层不匹配时发生的情况：核心交换机故障、运营商故障或必须物理移动设备。客户需要在每一层得到答案，因为故障很少尊重报价中的整齐边界。
路由多样性可见，但物理多样性不可见
公共路由证据是此案例中较好的部分之一。RIPEstat 在快照中看到了 AS36231 的完全可见性，而 CAIDA 的AS Rank 页面识别了 Tempest Hosting, LLC、美国、一个小的客户锥和有限的 AS 度数。IPinfo 的AS36231 页面、Hurricane Electric 的BGP 视图和 BGP.tools 都为网络身份和前缀提供了独立交叉检查。这些服务都看不到完整的合同真相，但它们降低了网络仅仅是名义上的可能性。
限制同样重要。RIPEstat 邻居数据显示了五个观察到的邻居。这很有用，但公共 BGP 邻接并不揭示两个会话是否共享相同的地铁光纤、相同建筑的会面室、相同的运营商管道或相同的上游维护团队。它不揭示从某个邻居学到的路由是否对所有流量首选，备份路径是否有足够容量承载峰值负载，或者游戏服务器工作负载是否在数据包返回时仍能容忍延迟变化。路由多样性是必要的线索；物理路径多样性是单独的证明。
PeeringDB 对 Tempest 网络对象为零的公共交换连接也需要谨慎处理。这并不意味着 Tempest 缺乏互连，也不与多设施网络矛盾。PeeringDB 参与是自愿的，网络记录可能省略私有互连、传输、路由服务器会话或客户特定安排。它所说的是，公开配置文件目前没有给出一些欧洲网络那样丰富的交换端口列表。因此，客户应直接询问传输提供商、私有对等体、备份端口以及每个城市是否有独立的默认能力路径。
伦敦和达拉斯的记录展示了为何这很重要。在伦敦迁移期间，Tempest 计划在验证上游和对等体的同时撤回和重新宣告 BGP 路由。在达拉斯事件期间，上游运营商网络中的故障迫使临时重路由。在这两种情况下，客户面对的影响不仅取决于 AS36231 在某个地方是否可见，还取决于当时哪个路径处理受影响的服务。严肃的弹性审查应包括来自客户市场的 traceroute、路由源授权审查、前缀监控以及提供商对运营商故障期间发生变化的解释。
产品类以不同方式失败
公开的 Tempest 通知也很有用，因为它们识别了不同的客户类别。达拉斯计划升级提到了企业专用客户、预算或刀片服务器，以及团队在机柜周围工作时周期性网络中断。达拉斯路由事件提到可能经历短暂断开的玩家。状态页面本身指向虚拟专用服务器、专用服务器、游戏服务器和托管作为产品类别。这些标签很重要，因为相同的设施事件可以为每个产品类型创建不同的恢复任务。
专用服务器客户将机器视为个体资产。如果机柜正在压缩，他们需要知道自己的服务器是否会断电、物理移动、重新布线或留在原地。如果磁盘、电源或主板故障，他们需要知道同一城市是否有兼容备件，数据是否可以保存，以及谁授权动手工作。达拉斯升级通知很具体，因为它告诉客户一些机器可能断电并搬迁。它还暗示提供商的增长计划有物理布局组件，而不仅仅是软件配置组件。
虚拟专用服务器客户有不同的依赖。他们可能不关心哪个具体机箱托管虚拟机，直到主机、存储池或网络聚合元素故障。他们的恢复取决于虚拟机管理程序健康、存储复制、可用备用主机容量、备份新鲜度和迁移工具。Tempest 的公开记录没有披露这些产品背后的虚拟化或存储架构。然而，它确实显示了客户应询问 VDS 是否可以在主机或城市之间移动，备份是站点内还是跨站点，以及 IP 地址在恢复期间是否跟随工作负载。
游戏服务器客户关心时间如同可达性。恢复连接的临时重路由仍可能改变延迟、抖动或会话连续性。因此，Tempest 的达拉斯事件语言关于可能的玩家断连很重要。它承认即使在服务技术上恢复后，网络权宜措施仍可能产生面向用户的影响。对于游戏和其他实时工作负载，客户应询问玩家群体在哪里，使用哪个 Tempest 城市，正常延迟路径是什么，DDoS 和上游故障转移路径是什么，以及路由变化是否从玩家市场而非仅从提供商自己的监控点进行测试。
托管客户又是另一种情况。托管的设备可能依赖 Tempest 的空间、电力、网络、远程手和交叉连接协调，而客户拥有服务器软件，有时还拥有硬件。如果上游路由变化，Tempest 行动。如果客户设备故障，远程手和访问政策很重要。如果发生设施事件，双方可能需要协调。PeeringDB 的设施列表很有帮助，因为它命名了可能的物理场所，但场所名称本身并不能定义谁可以触摸什么，多快，以及在哪个授权过程下。该边界应在宕机前书面化。
这种产品区别是托管容量经济的核心。相同的机架、路由器和支持团队可以为许多产品线服务，这创造了效率。它也在共享事件期间产生争用。核心交换机故障、运营商故障或机柜移动可能让许多客户进入相同的支持和维修队列。公开证据证明这些层存在；它不能证明队列容量。最安全的客户姿态是要求 Tempest 提供产品特定的恢复语言，而非依赖一般基础设施描述。
相同的区别应塑造监控。专用服务器客户可能监视电源事件、接口计数器、磁盘健康和带外访问。VDS 客户可能监视快照年龄、主机维护通知和存储延迟。游戏服务器客户可能监视玩家区域延迟和抖动，因为达拉斯路由事件表明恢复的路由仍可能中断会话。托管客户可能监视交叉连接状态、机柜电源、远程手响应和上游路由变化。AS36231 周围的公共工具有助于部分工作。它们显示面向互联网的边缘；它们不显示客户自己的恢复假设是否与实际购买的产品类匹配。
客户影响取决于工作负载，而不仅仅是可用性
Tempest 的状态语言暗示了几个客户类别：企业专用客户、预算或刀片服务器用户、虚拟专用服务器用户、托管客户以及连接到游戏工作负载的玩家。这些组以不同方式经历相同的基础设施事件。计划的三小时断电对于测试服务器可能可接受，但对于生产数据库则不可接受。短暂的路由过渡对于静态网站无害，但对于游戏会话具有破坏性。核心交换机故障对于一个租户可能是临时宕机，但对于具有下游客户的分销商则是声誉事件。
这就是为什么受影响方不仅仅是“Tempest 客户”。它可能包括游戏社区、使用专用机器作为主服务器的小企业、客户不知 Tempest 在底下的分销商、因延迟而选择城市的开发者，以及假设全球提供商能让他们在站点之间快速迁移的公司。它还可能包括当路由变化将流量转移到替代路径时的对等体和上游。看到宕机的客户通常离故障物理部分有几层距离。
数据本地化增加了另一个后果。全球服务区域并不告诉客户哪个管辖区持有数据、哪个法院程序适用，或者支持是否能在本地行动。如果工作负载在阿姆斯特丹，即使账户通过面向美国或迪拜的商业界面管理，数据和硬件可能位于荷兰。如果客户恢复到伦敦或达拉斯，法律和延迟概况会改变。公开记录可以识别可能站点，但只有提供商文档和客户账户配置才能证明特定工作负载位于何处。
因此，迁移必须在需要之前进行测试。客户应询问快照是否可在 Tempest 位置之间移植，公共地址是否可以保留，跨区域备份是包含还是可选，以及提供商是否有应急搬迁的文档化流程。公开状态记录显示 Tempest 可以执行计划网络移动和紧急重路由，但它不显示在区域事件期间数据、计算、IP 地址连续性或支持队列容量的客户级恢复时间。
什么证据会使容量声明更强
Tempest 已经清除了第一个证据障碍。AS36231 是活跃的，前缀集可见，PeeringDB 配置文件已维护，状态页面命名了位置和事件，Looking Glass 暴露了真实测试端点。更强的证据将更接近客户合同。它将显示哪些产品在哪些城市可用，哪些设施托管哪些产品，每个城市存在哪些上游，路由多样性是否具有地铁多样性，以及较新位置现在存有哪些备件硬件。
提供商不需要在开放互联网上发布每个运营细节。一些细节是安全敏感或商业敏感的。但客户仍然可以要求私有架构说明、支持升级矩阵、当前可用性报告、影响其服务类别的维护窗口列表以及恢复测试。他们还可以要求解释 PeeringDB 1-5 Tbps 流量范围如何映射到客户可用余量。粗略流量范围不是容量承诺。它可能描述了峰值或典型聚合网络规模，而不是一个客户在故障期间实际可以使用的带宽量。
相同的原则适用于设施电力。NTT Frankfurt、Iron Mountain Amsterdam、CoreSite Miami 和其他设施运营商发布令人印象深刻的电力和连接特性。Tempest 客户仍需知道 Tempest 在站点内部的承诺电力、冗余级别、机柜密度和远程手程序。设施可能有备用兆瓦，而特定机柜没有立即空间或兼容电力鞭。设施可能有许多运营商，而客户的产品使用一条默认路由。数据大厅可能安全，而客户恢复失败，因为备份从未在受影响的站点外部。
这就是买家的证据阶梯。首先，证明公司绑定到活跃网络。其次，证明产品实际使用该网络。第三，证明产品的城市、机架、电力、上游和支持依赖。第四，通过测试证明恢复路径。Tempest 的公开记录在第一步上很强，在第三步上由于事件披露而有意义。对于任何特定客户，在客户获得产品特定确认之前，在第二步和第四步上仍不完整。
狭窄的判决
Tempest Hosting, LLC 应被视为真实的基础设施运营商，拥有可测量的公共网络，而非纯粹的单薄足迹。对于私有主机提供商来说，证据异常有用：AS36231 可见；RIPEstat 显示当前 IPv4 和 IPv6 空间；PeeringDB 列出全球配置文件、1-5 Tbps 流量范围和八个设施；状态页面命名多个运营城市；事件记录暴露路由器、上游运营商、机柜和备件硬件中的具体故障路径。这足以将提供商作为基础设施进行分析。
这不足以将每个广告或暗示的容量单元都视为在故障下已可用。公开材料不披露确切机柜数量、电力预留、按城市划分的客户分布、阿姆斯特丹故障后的备件库存，或决定客户是否可以在位置之间移动数据和地址的合同条款。最重要的教训是，Tempest 的公开记录既显示了覆盖面，也显示了摩擦。覆盖面来自全球前缀和设施足迹。摩擦来自维护窗口和事件揭示服务背后的手、零件、运营商和局部决策。
对于客户来说，实际测试说起来简单做起来难：要求 Tempest 将正在购买的特定产品映射到城市、设施、上游路径、支持队列、备件池和迁移计划。然后将该答案与来自 RIPEstat、PeeringDB、BGP.tools 和 Tempest 状态页面的公共路由证据进行比较。如果答案一致并且恢复程序经过测试，Tempest 的足迹可以支持严肃的工作负载。如果答案仍然通用，买家应假设服务器账户仍然依赖于站点特定的机架、路由变化、供应商交付和维修窗口，这些可能只有在某些东西故障时才会变得可见。