总结
- Rackspace IT Hosting AS IT Hosting Provider Hong Kong 对应公共 APNIC 和 RIPEstat 注册中的 AS45187。APNIC 的 RDAP 记录将 Rackspace.com Hong Kong Limited 列为持有者组织，RIPEstat 将持有者标记为"RACKSPACE-AP - Rackspace IT Hosting AS IT Hosting Provider Hong Kong"。
- 路由表面实质可见。RIPEstat 对 AS45187 的路由状态快照显示 13 个 IPv4 前缀、2 个 IPv6 前缀、66816 个 IPv4 地址、两个地址族均观察到完全 RIS 可见性，以及 23 个观察到的邻居。已宣布前缀视图列出了活动前缀，包括 119.9.64.0/19、119.9.96.0/19、120.136.32.0/20、180.150.128.0/19、202.168.208.0/21、203.60.0.0/17、2401:1800::/32 和 2407:fa00::/32。
- PeeringDB 提供站点和互连上下文，而非容量保证。它将"Rackspace Hong Kong"列为 AS45187，开放策略，指示性前缀计数为 100 个 IPv4 和 10 个 IPv6，在 Equinix Hong Kong 和 HKIX 有两个 10G 交换条目，以及香港 MEGA-i 的一个设施条目。
- Rackspace 的 HKG1 和 HKG5 页面使物理依赖可见。HKG1 被描述为位于荃湾，配备 UPS 模块、双 11 kV 馈电和冗余网络组件；HKG5 被描述为位于将军澳，拥有 917 平方米的专用数据中心空间、13.5 MW 的总电力、7.2 MW 的 UPS 容量、七家光纤运营商、每家运营商 10 Gbit/s、BGP 多路径路由优化，并声明客户保留对租赁服务器的管理控制，而 Rackspace 控制网络硬件。
- 对于香港的公共网络身份和运营证据，证据水平为高，但这并非对所有托管工作负载的空白支票。客户仍需关于放置、冗余、恢复时间、工单升级、维护排除、备件访问、RPKI 状态、合同限制和退出路径的特定服务证据。
有用的问题不再是 Rackspace 是否存在于香港
一些基础设施配置文件从一个薄弱的名称和弱 ASN 开始。这里不是这样。围绕 Rackspace IT Hosting AS IT Hosting Provider Hong Kong 的公共记录足够丰富，足以将调查从存在转向依赖。APNIC 的自治系统 RDAP 记录将 AS45187 标识为 RACKSPACE-AP，国家设为 HK，持有者组织为 Rackspace.com Hong Kong Limited。RIPEstat 的AS 概览使用持有者标签"Rackspace IT Hosting AS IT Hosting Provider Hong Kong"，并标记该 ASN 为已宣布。这种配对比刮擦的托管目录条目或过时的公司页面更可靠。
路由证据也足够新，具有相关性。RIPEstat 的路由状态显示，在快照时，AS45187 在所有观察到的 RIS 对等点上具有 IPv4 和 IPv6 可见性，13 个 IPv4 前缀、2 个 IPv6 前缀和 23 个观察到的邻居。已宣布前缀数据集列出了 15 条当前前缀行。这些包括两个大的 IPv6 聚合，2401:1800::/32 和 2407:fa00::/32，以及 IPv4 路由如 119.9.64.0/19、119.9.96.0/19、120.136.32.0/20、122.200.132.0/22、180.150.128.0/19、202.168.208.0/21 和 203.60.0.0/17。这不是一个单前缀的虚荣网络。
Rackspace 的公共设施文档使得问题更加具体。Rackspace 的HKG1 数据中心页面将一个设施置于香港荃湾，并描述了电力、冷却、安全、连接和保障。其HKG5 页面将另一个设施置于将军澳，并进一步列出了 917 平方米的专用数据中心空间、13.5 MW 的总电力、7.2 MW 的 UPS 容量、七家光纤运营商到站点，以及 BGP 多路径路由优化。存在性问题因此对于采购工作已足够确定。开放问题是某个特定客户的托管服务是否具有与公布的足迹所暗示的相同弹性。
这种区别很重要，因为"Rackspace"是一个大品牌，"香港"是一个市场标签，AS45187 是一个网络边界，而客户工作负载是一个特定合同的部署。买家可以看到公共编号资源和 Rackspace 对其设施的声明，但不能推断哪个房间、哪个机架、哪个运营商、哪个 VLAN、哪个备份系统、哪个支持团队或哪个维护计划适用于他自己的环境。一个证据充分的设施页面应当使审查更严格，而非更不严格。
AS45187 是一个真实的运营边界，但注册表并不显示所有服务
APNIC 和 RIPEstat 记录显示了一致的身份。RDAP 记录的注册日期为 2014 年 12 月，最后更改日期为 2020 年 7 月。RIPEstat 的whois 派生视图记录了 aut-num 为 45187，as-name 为 RACKSPACE-AP，描述为 Rackspace IT Hosting AS IT Hosting Provider Hong Kong，国家为 HK。它还显示了引用 AS3491、AS1239 和 AS2914 的历史导入和导出策略行，以及 Rackspace 路由维护者联系人。这些细节很有帮助，因为它们将编号资源与香港 Rackspace 实体以及长期存在的路由管理记录联系起来。
这并不足以定义产品。AS45187 可能以不同方式承载公有云、托管托管、专用服务器、主机托管、存储、监控、控制平面、支持或骨干功能。一些客户系统可能直接从 AS45187 寻址。其他可能使用提供商分配的地址、私有互连、云提供商地址或混合路由，这些并不作为客户可见的来源出现。注册表可以告诉买家在哪里寻找。它不能告诉他哪种确切产品使用路由边界，哪个法律实体签署合同，或哪个提供商对事件负责。
因此，APNIC 持有者证据必须被解读为责任图的起点。如果客户被告知香港工作负载从 Rackspace 基础设施交付，AS45187 给了客户一个具体的网络边界，以便提出问题。涉及哪些前缀？哪些是面向客户的、仅管理的、仅备份的或遗留的？哪些路由策略是活动的，哪些是历史的？哪些前缀有路由来源授权，哪些对 RPKI 验证器仍然未知？这些不是学术问题。它们决定了路由泄漏、过滤器更改、DDoS 缓解事件或上游中断是否会影响服务。
第一个注意事项涉及 RPKI。本文用于 119.9.64.0/19 的验证检查通过 RIPEstat 的RPKI 验证端点返回了未知状态，而非有效。对于从已宣布前缀列表检查的前缀集，相同状态出现。未知与无效不同，也不意味着网络失败。这意味着路由来源授权应当是一个积极的采购问题，因为执行路由来源验证的网络对有效、未知和无效路由处理不同。对于依赖香港稳定边界的客户来说，"未知"应导致关于 ROA、路由过滤器、联系程序和变更控制所有权的讨论。
Rackspace 在香港发布了两种不同类型的设施证据
Rackspace 的香港设施页面相比许多区域托管配置文件异常具体。HKG1，在Rackspace Technology Data Centers: Hong Kong (HKG1)中描述，位于荃湾。页面说明香港设施配有系统工程师，24/7/365 管理和维护系统。HKG1 列出的物理声明包括 400 KVA UPS 模块（N+1 配置）、30 分钟电池运行时间、来自不同中电变电站的双 11 kV 馈电、双电源立管、多台发电机，以及由双电信连接供电的运营商中立设施。
HKG5，在Rackspace Technology Data Centers: Hong Kong (HKG5)中描述，位于将军澳，展示了不同的具体信息。它列出了 917 平方米的专用数据中心空间、13.5 MW 的总电力、7.2 MW 的 UPS 容量、容量各为 2.25 MW 的柴油发电机、12000 升油箱、超过 1 MW 的冷却能力、七家提供光纤连接到站点的运营商、每家运营商 10 吉比特以太网、冗余的 Cisco 和 Arista 路由器，以及 BGP 多路径路由优化。它还声明客户保留对租赁服务器的管理控制，而 Rackspace 保留对网络硬件的控制。
这些声明具有运营含义。它们表明 Rackspace 不仅仅是在香港标签下转售匿名云区域。它们表明物理设施、网络设计、支持人员和控制边界。但它们仍必须转化为特定服务证据。"HKG5 有七家运营商"本身并不证明每个客户服务都有七条活动、默认能力、已付费和已配置的路径。"BGP 多路径路由优化"并不证明路由多样性一直延伸到应用程序、存储层或客户管理控制台。"客户保留管理控制"并不证明客户可以在网络硬件、门户、支持队列或计费状态阻止访问时恢复服务。
设施页面在命名物理输入时最强。电源馈电、UPS 容量、发电机燃料、运营商数量和路由器系列都是真实的东西，买家可以要求在服务设计中看到。页面在必然通用时最弱。它们不发布机架分配、客户放置、跳线面板、私有 VLAN 映射、存储拓扑、备份地理位置、备件箱或事件期间将调用的技术员队列深度。采购任务是弥合这一差距，而不假装公共设施页面已经完成。
PeeringDB 确认互连信号，而非客户放置
ASN 45187 的 PeeringDB 网络 API列出了名为 Rackspace Hong Kong 的网络实体。字段显示一般开放策略、AS-IRR AS 集为 AS-RACKSPACE、指示性前缀计数为 100 个 IPv4 和 10 个 IPv6、IPv6 支持、IX 计数为 2、设施计数为 1。PeeringDB 是一个自愿目录，因此这些字段都不是认证。尽管如此，条目很有价值，因为它将 AS45187 与可以与 Rackspace 的路由收集器和设施声明进行比较的互连姿态联系起来。
PeeringDB netixlan 记录列出了两个运营的交换面向条目：Equinix Hong Kong 和 HKIX: HKIX Peering LAN。两者都显示速度为 10000 Mbit/s。Equinix Hong Kong 线路列出 IPv4 地址 36.255.56.87 和 IPv6 地址 2001:de8:7::4:5187:2。HKIX 线路列出 IPv4 地址 123.255.90.101 和 IPv6 地址 2001:7fa:0:1::ca28:a065。PeeringDB netfac 记录将香港 MEGA-i (iAdvantage Hong Kong) 列为网络实体的设施条目。
这些行与 Rackspace 的 HKG1 和 HKG5 页面产生了有用的张力。Rackspace 发布了荃湾和将军澳的设施页面，而 PeeringDB 在 MEGA-i 暴露了一个网络设施条目以及 Equinix Hong Kong 和 HKIX 的交换连接。除非有人试图使单条记录包含超过其能力的信息，否则没有矛盾。PeeringDB 可能描述互连存在而非客户计算放置。Rackspace 的数据中心页面可能描述托管设施而非每个交换或互连位置。客户需要连接这些层的映射：服务器所在位置、边缘路由器所在位置、交换对等发生位置、传输进入位置以及客户拥有合同权利的位置。
直接的运营教训是设施计数不等于冗余。PeeringDB 设施行可以与 Rackspace 运营或营销的多个站点共存。两个交换面向端口可以改善到选定网络的可达性，而不证明完全的传输多样性。10G 交换端口可能适合对等，但事件期间存活的客户路径可能取决于付费传输、私有互连、DNS、安全过滤、负载均衡器、存储复制和支持访问。公共互连记录给买家名称和地址进行测试，而非端到端故障转移结果。
路由表面广阔，但多样性必须证明两次
AS45187 有一个可见的邻居集。RIPEstat 的ASN 邻居端点返回了 23 个观察到的邻居。列表包括左侧的大型全球网络如 AS174、AS3257、AS3300、AS3491、AS4637、AS6453、AS6939 和 AS7473，右侧一行 AS58982，以及几条不确定的行。公共 BGP 无法分辨每个邻接是付费上游、对等、客户、交换路由-服务器关系、临时路由泄漏伪影还是收集器侧分类伪影。它只能告诉我们路由边界并非不可见。
历史的 APNIC whois 策略行增加了另一层。它们列出了从 AS3491、AS1239 和 AS2914 的导入以及向这些 AS 的导出。这是一个有用的历史性路由管理证据，但它并不自动描述当前的流量工程。RIPEstat 当前的邻居列表间接包括其中一些名称，并显示其他名称。买家应询问 Rackspace 当前的传输和对等设计，而非依赖静态 whois 策略文本。
多样性必须证明两次：一次在路由层面，一次在物理运营层面。一个网络在公共数据中可以有许多 BGP 邻居，同时多条路径共享同一建筑、同一互通机房、同一电源域、同一光纤管道、同一路由器对或同一支持队列。相反，一个服务可以具有在公共 BGP 中几乎不可见的强私有或提供商侧弹性。目标不是惩罚 Rackspace 隐藏运营细节；而是避免将公共 AS 图误认为是经过测试的客户恢复设计。
最佳问题是特定于层的。哪些 AS45187 前缀源自香港的哪些边缘路由器？哪些上游在正常运行期间承载服务的默认路由？哪些交换会话是无结算对等与关键可达性？哪些路径在光纤入口和建筑层面是多样的？在移除一个运营商、交换、路由器或设施域后，剩余路径在峰值时能承载多少流量？公共 BGP 可以提示在哪里提问。它本身无法回答所有这些问题。
Rackspace 销售抽象，但香港经济仍然是物理的
Rackspace 的托管托管页面以熟悉的企业语言呈现产品：托管专用托管、单租户专用基础设施、裸机、数据库、网络、存储、托管备份、灾难恢复、RackConnect 和私有云。商业承诺是 Rackspace 将物理复杂性转化为服务。客户购买性能、支持和控制，而无需拥有每个路由器、电源馈电、存储舱、互连和维护过程。
这种交换有真实价值，但它并不消除底层经济学。Rackspace 的主机托管客户指南描述了为预留冗余关键电力按千瓦分配的计费，互连和混合带宽若购买则单独按月经常性收费。它还提及一次性设置费、电力电路、私有笼子、机架内 PDU 和互连。这是物理容量的词汇。云账单仍然依赖于能源分配、机架空间、光学设备、远程手、带宽承诺和劳动力。
香港页面使这一点可见。HKG5 对 13.5 MW 电力、7.2 MW UPS 容量和七家光纤运营商的声明不是营销装饰。它们是容量输入，可以约束或保护客户。如果机架密度上升，如果客户需要更多互连，如果备用路由器不可用，如果运营商路径拥堵，或者如果维护窗口需要串行工作，客户通过延迟、工单延迟、迁移限制或事件后信用感受到物理状态。托管容量作为服务购买，但作为一连串物理和行政步骤失败。
这就是为什么必须区分"已安装"容量和"可用"容量。已安装容量是公布的足迹似乎包含的内容：设施、发电机、UPS 系统、运营商连接、路由器、前缀和支持人员。可用容量是在考虑正常预留、超额预订、维护、客户特定路由和保护域后为客户保留的部分。可恢复容量更窄：在组件故障后，能在客户要求的时间范围内恢复的部分。公共页面适用于已安装容量。客户保证必须证明可用和可恢复容量。
控制按设计划分
HKG5 上最重要的行可能不是关于兆瓦或运营商数量。页面声明客户保留对租赁服务器的管理控制，而 Rackspace 保留对网络硬件的控制。这种分离正是托管托管客户在正常运行期间想要的：客户可以管理工作负载，提供商保护共享网络层。在故障期间，相同的分离成为必须演练的边界。
如果租赁服务器健康但无法访问，客户的管理权限可能不足。如果客户可以通过 VPN 访问服务器但不能访问公共服务，网络边界就很重要。如果客户需要路由更改、防火墙规则、互连工单或硬件更换，Rackspace 的权限和队列成为限制因素。如果客户有备份但无法通过可用路径移动足够数据，服务器级控制就无用。共享责任在这里不是口号；它是运营架构。
Rackspace 的主机托管指南强化了相同的边界。它描述了实施经理、客户门户培训、远程手请求、自动工单创建、警报监控和运行手册。它声明客户可以通过 Rackspace 客户门户创建工单进行交互，并可致电 24/7/365 支持团队。它还列出了远程手任务，如设备电源循环、视觉验证、电缆测试、客户提供硬件更换、机架安装和移除、机架内网络布线以及硬盘销毁。这些是将故障检测转化为修复的具体行动。
对于买家来说，控制问题很简单：没有 Rackspace 我们能做什么，没有我们 Rackspace 能做什么，以及什么需要双方按正确顺序行动。这个问题应在生产前回答。它应以运营步骤书写，而非仅合同语言。哪些门户用户有权限？如果门户不可用，哪个电话号码有效？哪些路由更改需要工单？哪些硬件操作包含在内？哪些任务按 15 分钟增量计费？哪些任务依赖于客户提供的部件而非 Rackspace 提供的部件？
维修窗口是产品特性，而非脚注
Rackspace 的数据中心页面发布了强保证，但细节很重要。HKG1 和 HKG5 都包含网络、基础设施和硬件更换的保证语言。网络和基础设施部分以可用性和信用条款表述，而硬件更换保证声明 Rackspace 提供的硬件或组件的更换或维修将在问题识别后一小时内开始，否则提供信用。"开始"一词很重要。它与"完成"不同，且不描述所有客户提供的组件。
主机托管指南中的远程手表格在运营上更细致。它显示 HKG1 对于远程手既有 1 小时响应 SLA 也有 24 小时执行 SLA。同一指南给出了常见任务的估计时间，例如路由、服务器或交换机的电源循环 30 分钟，每三根电缆的布线支持测试 60 分钟，以及更换非热插拔客户提供设备 60 分钟。它列出了远程手费率每 15 分钟增量 46.25 美元外加物料清单。这些不是琐碎的细节。它们显示了维修时钟可以从抽象正常运行时间指标转向付费人力劳动的位置。
因此，客户应分开三个时钟。检测时间是监控注意并分类故障的时间。响应时间是 Rackspace 或客户接受所有权并开始行动的时间。执行时间是维修实际花费的时间，包括部件、访问、布线、重启、路由更改、存储重建和验证。故障后信用在商业上重要，但它们不恢复工作负载。弹性审查应关注测量的恢复，而不仅仅是服务信用。
同样的逻辑适用于维护。Rackspace 的保证语言排除计划或紧急维护。这种排除是正常的，但在托管容量审查中很重要。如果路径或站点因维护不可用，客户真正的弹性是剩余在非维护路径中的容量。如果客户在提供商维护冻结期间需要更改，升级规则很重要。如果紧急维护事件触及共享网络组件，客户的管理权限可能无济于事。维修窗口和维护窗口是产品的一部分，而非附属文书。
路由来源安全是强大公共足迹中的弱点
网络证据中最明显的降级是 RPKI 状态。RIPEstat 清晰报告了路由表面，PeeringDB 提供了互连细节，但针对当前前缀列表的 RPKI 验证检查在此处使用的采样中返回了未知状态，而非有效。未知状态可能因多种原因存在，包括 ROA 缺失、验证器覆盖、时间或资源管理选择。它并不意味着 AS45187 正在劫持路由。这意味着来源授权层不如 BGP 可见性层强大。
对于托管客户来说，这很重要，因为来源验证已不再陌生。RFC 6811 描述了路由来源验证作为一种使用资源公钥基础设施判断 AS 是否被授权发起前缀的方法。APNIC 自己的 RPKI 材料用运营术语解释了资源认证控制。依赖公共可达性的客户应当关心其提供商的正式前缀是有效、未知还是无效，以及客户自己的路由前缀在迁移前是否有正确的 ROA。
实际问题不是"Rackspace 知道 BGP 吗？"公共邻居集和设施声明表明成熟的路由运营。更具体的问题是：对于承载客户服务的确切前缀，路由来源授权是否已发布并与主要验证器测试？如果客户带来自己的地址空间，谁创建和维护 ROA？如果 Rackspace 分配地址空间，Rackspace 能否显示状态和变更控制过程？如果在事件中前缀必须移动，ROA 状态和过滤器会发生什么？
这是少数公共检查之一，答案可以在不透露私有设施细节的情况下改进。有效的 ROA 不能证明客户弹性，但它消除了一种可避免的故障模式。未知路由可能在大多数网络上仍然有效；它只是在来源验证级别给买家的保证较少。在 Rackspace 香港文件的其他方面强大时，这恰恰是那种不应在品牌重量下丢失的具体、可修复的问题。
数据本地性并非由字母 HK 决定
分配区域是 HK，APNIC 将 AS45187 列为国家 HK，Rackspace 在香港发布设施，PeeringDB 记录描述了香港的互连。这些是良好的本地性信号。它们仍不能证明客户的数据、备份、日志、支持记录、身份系统、快照或恢复副本位于何处。在云和托管托管合同中，本地性是放置矩阵，而非国家代码。
香港的隐私监管机构在其公共指南中强调了这一点。PCPD 的云计算指南（2025 年 1 月）告知数据使用者考虑数据存储位置、设备安全措施、访问人员的完整性和能力、安全传输、与分包商的合同、保留控制以及跨境转移的影响。PCPD 关于香港境外云系统的案例说明指出，条例并不禁止在香港境外云系统中存储个人数据，但数据使用者仍必须遵守 PDPO 和数据保护原则。PCPD 的推荐示范合同条款为跨境转移提供了合同框架。
对于 Rackspace 香港客户，后果是实际的。客户应询问主要数据存储在哪里、快照存储在哪里、备份存储在哪里、管理日志存储在哪里、哪些支持团队可以访问环境、涉及哪些分包商或合作伙伴云，以及正常支持操作是否将个人数据传输到香港以外。香港的路由边界可以与香港之外的支持工具、全球身份系统、离岸备份副本或多云互连共存。这些不一定不当；它们只是需要披露并根据客户自身的监管义务进行测试。
本地性也与恢复相互作用。香港外部的备份可能提高弹性但改变传输分析。仅本地备份可能满足居住偏好，但如果本地设施遭遇区域事件则失败。香港内部的多站点设计在延迟和管辖权方面可能更好，但成本更高且仍依赖共同提供商。买家需要设计，而非口号。
退出证据是弹性的一部分
托管服务直到客户能够在压力下离开时才完全具有弹性。Rackspace 的文档包含有用的迹象，表明一些服务暴露了导出和迁移路径。Rackspace Cloud 关于 OpenStack Flex 的手册指向用于创建虚拟机、块存储、对象存储、导出映像、导入映像和调度迁移的功能。导出映像指南描述了从 OpenStack Flex 项目导出实例快照。对象存储 API 指南说明访问需要 Rackspace Cloud 凭据、项目详细信息和 API 调用。
这些文档并不证明香港的每个托管客户都可以执行完整的紧急退出。它们证明应在工件级别讨论退出。客户能否导出 VM 映像？能否导出块卷？备份是否可移植？网络配置、防火墙规则、负载均衡器设置、DNS 区域、证书、日志和监控历史是否可导出？如果客户门户降级，导出是否有效？是否需要付费支持参与？能否在不触发生产更改的情况下进行测试？
物理层在退出期间重新出现。大型导出消耗带宽和时间。互连计费、传输上限、存储读取速率、对象存储凭据和支持工单都构成迁移路径的一部分。从未测量过完整导出的客户可能在事件中发现"我们可以移动"实际上意味着"在提供商批准请求后，我们可以开始一个漫长的传输"。退出规划不是对 Rackspace 的敌意；它是依赖审查的诚实终点。
Rackspace 发布的基础设施足够强大，许多客户理性地选择不自行管理同等基础设施。这是托管托管的经济意义。危险不在于使用提供商；而在于使用提供商时没有保留在出现问题时移动、恢复或独立验证服务所需的证据。
公司包装有帮助，但本地证据仍然获胜
更广泛的 Rackspace Technology 公司文件有助于解释为什么这个香港档案不应被视为小型区域主机。Rackspace Technology, Inc. 在 SEC 文件中作为纳斯达克上市公司出现，代码 RXT，其2025 年 10-K 文件向投资者提供了其云、托管和服务运营的更广泛业务和风险背景。Rackspace 的全球数据中心页面呈现了多市场数据中心足迹，并声明其设施在安全、电力、冷却和网络域使用冗余。这些事实减少了身份不确定性，并使香港设施页面比独立登陆页面更可信。
它们并不消除对本地证据的需求。全球企业仍可能有本地设施限制、区域供应商依赖、产品特定折旧路径、客户特定支持层级或与公共设施页面不同的私有云设计。10-K 也是为投资者撰写的，而非为试图了解哪个机架、哪条路由、哪个备份系统和哪位工程师将决定周六故障的香港客户。上市公司披露可以描述业务风险、收入部门、债务、竞争和运营假设。它不能证明 AS45187 上特定工作负载的恢复路径。
这种公司包装改变了保证方法。对于小型未知提供商，首要任务可能是证明公司和网络存在。对于 Rackspace 香港，首要任务是协调多个公共层，每个层都是真实的：来自 APNIC 的 AS45187 身份、来自 RIPEstat 的当前路由证据、来自 PeeringDB 的互连线路、来自 Rackspace 的 HKG1 和 HKG5 设施页面、来自 Rackspace 的托管托管和主机托管文档，以及客户自己的合同。风险不在于每个层是假的。风险在于客户假设所有层以相同方式适用于他的服务。
因此，买家应要求 Rackspace 提供本地服务时间表。它应命名设施、相关 ASN 和前缀、恢复站点、备份位置、支持模型、维护排除项、RPKI 计划、数据本地性控制和退出过程。全球品牌可以使该时间表更容易获得。它不能替代时间表。
客户在信任香港边缘前应测试什么
第一个测试是映射。要求 Rackspace 将服务映射到 AS45187、设施、生产前缀、管理路径、备份路径和支持系统。用 APNIC RDAP、RIPEstat 已宣布前缀、PeeringDB Rackspace 香港记录和 Rackspace HKG1/HKG5 页面交叉检查 ASN 答案。如果客户服务不使用 AS45187，那可能可以接受，但应明确说明。
第二个测试是故障。在桌面演练或实时演习中移除上游、交换路径、路由器、存储组件、支持门户、客户凭证和维护域。记录可达性、控制台访问、DNS、监控、备份、计费、工单和数据导出发生的情况。结果应确定服务的哪些部分是主动-主动、主动-被动、仅备份或手动的。
第三个测试是路由安全。询问确切生产前缀（包括任何客户拥有的前缀）的 RPKI 状态。询问迁移期间 ROA 如何更改以及谁批准更改。询问是否为 AS45187 和客户公告维护路由过滤器。公共未知 RPKI 状态不应被视为丑闻；它应被视为一个开放的控制项。
第四个测试是支持和维修。使用主机托管指南中的远程手词汇使演习具体化。谁打开工单？如果门户失败，谁可以打电话？哪些任务包含在内、可计费或排除？哪些备件由 Rackspace、客户或供应商提供？哪个 HKG1 远程手 SLA 适用，确切 HKG5 服务的等效 SLA 是什么？如果硬件更换保证在问题识别后一小时内开始，谁识别问题，什么标记开始？
第五个测试是本地性和退出。询问数据本地性矩阵，包括主要、副本、备份、日志、支持记录和身份。询问导出证据和定时恢复测试。PCPD 材料明确说明了为什么这些问题属于香港云讨论：客户即使在使用云提供商或分包商时，仍负责个人数据的处理。
证据水平
Rackspace IT Hosting AS IT Hosting Provider Hong Kong 获得高的公共网络证据水平。该水平反映身份和运营可见性，而非关于所有 Rackspace 服务的无限制声明。APNIC 将 AS45187 与 Rackspace.com Hong Kong Limited 关联。RIPEstat 显示 AS45187 已宣布，具有 13 个 IPv4 前缀、2 个 IPv6 前缀、在检查快照时观察到完全 RIS 可见性，以及 23 个观察到的邻居。PeeringDB 列出 Rackspace 香港，有两个 10G 交换面向条目和一个香港设施行。Rackspace 发布了 HKG1 和 HKG5 页面，包含关于设施、电力、运营商、网络和支持的具体声明。
水平不更高是因为公共证据总是在客户边界停止。它不披露客户的机架分配、服务器数量、保留电力、存储拓扑、备份地理位置、备件库存、支持队列、合同排除、维护计划或测试退出时间。它还将路由来源授权作为开放问题，因为采样的当前前缀返回了 RPKI 状态未知而非有效。
实际结论狭窄且有用：这不是香港的薄弱托管足迹。它是一个真实的、有充分记录的 Rackspace 网络和设施存在，但仍需要特定服务保证。客户不应将其视为不可验证。他们也不应让 Rackspace 名称、两个香港数据中心页面或可见的 AS45187 路由表面替代真正保护工作负载的故障证据。
谁感受到故障
首先感受到 AS45187 或香港设施故障的人可能是应用程序所有者、经销商运营商、金融科技团队、SaaS 管理员、在线零售商、数据库所有者、合规经理或试图保持客户服务可达的网络工程师。下游影响可以迅速从数据包丢失变为收入损失、从存储警报变为错过的监管义务、从门户中断变为延迟的迁移、或从计费争议变为管理锁定。
Rackspace 的规模可以降低一些风险。它有全球数据中心运营、公布的 SLA、命名的香港设施、成熟的支持语言和可见的互连。规模也可以隐藏客户特定依赖。大型提供商可能有许多路由，但客户仍依赖自己的服务设计。大型提供商可能发布硬件更换保证，但客户仍需要知道故障部件是 Rackspace 提供、客户提供还是由其他供应商控制。大型提供商可能有全球工程师，但客户仍需要本地和合同升级路径。
这就是为什么本文将 Rackspace 香港视为要理解的依赖，而非要解决的谜团。公共证据良好。物理基础设施被命名。网络可见。互连记录有有用的细节。剩余工作是测试当真实工作负载失去机架、上游、硬件组件、支持路径、计费授权、维护窗口或迁移路由时，这些事实如何表现。托管容量仅与这些答案背后的证据一样具有弹性。