摘要
- RIPE RDAP 显示AS35667为 XSALTO35667，归属 Alpilink Cloud S.A.S.；RIPEstat 报告该 AS 于 2026 年 7 月 15 日宣告，可见 IPv4 分配为94.143.216.0/21，且该来源具有有效的 RPKI。
- 公共路由稳定但狭窄：RIPEstat 路由状态显示一个 IPv4 前缀、2048 个 IPv4 地址、无可见 IPv6 前缀和一个观察到的邻居，而RIPEstat 邻居数据将该邻居识别为 AS28768。
- Alpilink 自身的服务云页面声称提供托管、IaaS、虚拟机、托管服务、备份和外包灾难恢复、7x24 小时法国专家支持、三个互联数据中心、40 Gbit/s 保证带宽、超过 1500 台托管服务器和 3 PB 存储数据；这些是第一方运营声明，而非独立容量审计。
- 当前证据等级：身份和路由控制为中等偏强，但客户弹性仅为中等。公共记录支持一个真实的法国云和托管运营，但客户仍需当前机架位置、可用容量、电力和冷却设计、父 AS 以外的路由多样性、备份隔离、支持升级和迁移权利的实际证据。
公共记录指向一个真实的法国云运营商，而非一次性托管名称
最重要的第一步是身份识别。买家在了解哪家组织控制地址、合同、服务台和物理资产之前，无法评估托管容量。在这一点上，XSALTO35667 Alpilink Cloud S.A.S. 提供了有用的公开证据。RIPE RDAP 在https://rdap.db.ripe.net/autnum/35667上命名 AS35667 为 XSALTO35667，并将其关联到 Alpilink Cloud S.A.S.，组织记录显示地址为 2 Rue de la Viscose, Le Rayon Vert, 38130 Échirolles, France。同一 RDAP 响应还包含 XSALTO 的管理和网络运营联系人，地址在 Seyssinet-Pariset。这些细节并非性能保证，但它们将公司锚定在真实的法国运营环境中。
地址空间同样清晰。RIPE RDAP 在https://rdap.db.ripe.net/ip/94.143.216.0/21上识别出 94.143.216.0 至 94.143.223.255 为 FR-XSALTO-20090310，分配 PA，国家 FR，状态活跃，与 Alpilink Cloud S.A.S. 关联。RIPEstat 的 AS 概览在https://stat.ripe.net/data/as-overview/data.json?resource=AS35667报告该 AS 在 2026 年 7 月 15 日查询时间已宣告。其宣告前缀端点https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS35667在截至 2026 年 7 月 15 日的两周窗口内显示了 94.143.216.0/21。其前缀概览https://stat.ripe.net/data/prefix-overview/data.json?resource=94.143.216.0/21确认 AS35667 是起源持有者。
该网络还受到路由起源对象的保护。RIPEstat 的 RPKI 验证端点https://stat.ripe.net/data/rpki-validation/data.json?resource=35667&prefix=94.143.216.0/21返回有效状态，其中包含一个针对起源 AS35667、前缀 94.143.216.0/21、最大长度 /21 的验证 ROA。这是一个有意义的安全信号。它不能保证正常运行时间、安全运营或路由多样性，但它减少了一类可避免的路由风险：有效的路由起源授权使上游和路由验证者能够拒绝已通告 /21 的未经授权起源。
这些技术事实之所以重要，是因为该公司以云封装形式销售物理依赖。Alpilink 自身的服务云页面在https://www.alpilink.fr/services-cloud/列出托管、IaaS、虚拟机、托管服务、备份和外包灾难恢复。它称 Alpilink Services Cloud 提供法国主权托管商的专业知识和服务，7x24 小时的法国专家团队，安全承诺和可持续企业政策。它还提供了摘要规模声明：三个互联数据中心、40 Gbit/s 保证带宽、超过 1500 台托管服务器和 3 PB 存储数据。这些不是一般的软件声明。它们暗示机架、电力、冷却、存储阵列、网络链路、备份、支持人员和设施。
买家面临的挑战是，公共证据在身份和第一方定位层面很强，但在实时容量层面不完整。我们可以看到当前的 AS、当前的路由可见性、RPKI 有效性、PeeringDB 设施行和一个详细的第一方云页面。我们看不到按客户划分的容量台账：可用机柜、预留电力、空闲端口、服务器库存、备用硬盘、虚拟机监控程序集群余量、备份饱和度、远程操作合同或支持工单深度。这种区别并非对 Alpilink 不利。这是提供商存在证据与客户特定工作负载能否在下次故障中幸存之间的正常差异。
AS35667 注册清晰，但公共路由表面狭窄
路由证据在一方面令人鼓舞，在另一方面则具有约束性。RIPEstat 路由状态https://stat.ripe.net/data/routing-status/data.json?resource=AS35667报告在 2026 年 7 月 15 日查询时间，可见 AS35667 视图内有一个 IPv4 前缀、2048 个 IPv4 地址、零个 IPv6 前缀、326 个 IPv4 RIS 对等体中有 326 个看到该路由，以及一个观察到的邻居。这意味着该单一 IPv4 路由的可见性很强。这表明该 AS 并非仅仅被分配，而是在公共路由数据中被广泛看到。
限制因素是从弹性角度解读的相同数据点。一个可见前缀和一个观察到的邻居并不能证明多路径客户架构。RIPEstat 的邻居端点https://stat.ripe.net/data/asn-neighbours/data.json?resource=AS35667在 2026 年 7 月 14 日的观测中显示 AS28768 是唯一的观察邻居。RIPEstat 的 whois 视图https://stat.ripe.net/data/whois/data.json?resource=AS35667也记录从 AS28768 导入和向 AS28768 导出。一致性端点https://stat.ripe.net/data/as-routing-consistency/data.json?resource=AS35667在 BGP 和 whois 中都发现了 94.143.216.0/21，在导入和导出视图中也发现了 AS28768。这很整洁，但也非常集中。
AS28768 并非无关紧要的背景。PeeringDB 的网络对象https://www.peeringdb.com/api/net?asn=28768识别 XSALTO 拥有 10 个 IPv4 前缀、10 个 IPv6 前缀、一个 IX 计数和三个设施记录，而https://www.peeringdb.com/api/netixlan?asn=28768列出了 France-IX AURA LyonIX 对等条目。PeeringDB 的 netfac 数据https://www.peeringdb.com/api/netfac?net_id=9058显示 AS28768 出现在 Cogent Grenoble、Orange Business - La Fabrique in Grenoble 和 XSALTO Grenoble in Seyssinet-Pariset。这表明更广泛的 XSALTO/Alpilink 网络资产比 AS35667 单独更大。
但这里的分配特指 XSALTO35667 Alpilink Cloud S.A.S.，而公共 AS35667 视图本身并未显示相同的多样性。PeeringDB 的 AS35667 对象https://www.peeringdb.com/api/net?asn=35667在其配置文件中列出一个 IPv4 前缀、一个 IPv6 前缀、1-5 Gbit/s 流量、欧洲范围、平衡比率、零 IX 计数和一个设施计数。netfac 端点https://www.peeringdb.com/api/netfac?net_id=13798显示该设施为 Seyssinet-Pariset 的 XSALTO Grenoble。AS35667 的 netixlan 端点在此次审查中未返回公共 IX LAN 行。同样，这并不意味着不存在运营多样性；而是意味着该 AS 的公共多样性证据有限。
这一点很重要，因为许多客户中断发生在“集团具有弹性”和“我的确切服务路径具有弹性”之间的边界。如果客户虚拟机编号来自 94.143.216.0/21 并且它们通往互联网的路径通过 AS28768 承载 AS35667，那么客户应询问 AS28768 如何设计、边界路由器位于何处、路由能否在组网内部故障转移、哪些传输和对等路径实际承载流量，以及客户的 DNS、支持、备份和控制访问是否依赖于同一设施。父 AS 或相邻 AS 可以提供真正的冗余，但前提是它实际在客户的服务路径中。
物理资产集中在格勒诺布尔，当前和未来层级不能混淆
证据的物理方面指向格勒诺布尔及其周边市镇。RIPE 记录包括 Échirolles 和 Seyssinet-Pariset。PeeringDB 将 XSALTO Grenoble 列为 Seyssinet-Pariset 的设施。第一方服务云页面将联系地址列为 Le Rayon Vert, 2 rue de la Viscose, 38130 Échirolles。HDS 保证页面https://www.alpilink.fr/services-cloud/garanties-hds/将 ALPILINK CLOUD 列在 6 Avenue Pierre de Coubertin, 38170 Seyssinet-Pariset，并将 Orange - La Fabrique (EOLAS) 列在 73 Rue Général Mangin, 38100 Grenoble，作为两个机架的分包商。对于一个区域云提供商来说，这是异常具体的公开信息。
同一 HDS 页面对于运营商边界也很重要。它表示 Alpilink Cloud 拥有自己的数据中心，除表中列出的数据中心内的托管托管外，不进行分包。它将 Alpilink Cloud 描述为主机，Orange - La Fabrique 作为两个机架活动的分包商，支持由部分位于塔希提岛的人员通过加密访问提供 7x24 小时服务。这为客户提供了实际边界地图：某些服务由 Alpilink Cloud 直接运营，存在一些托管依赖，即使数据托管声明在法国，支持访问也可能跨越地理界限。
这是有价值的披露，但仍留下了客户必须验证的运营细节。公共页面表示 ISO 27001 存在且 HDS 适用，但并未公布完整的审计范围、客户机架安置、备份拓扑、Alpilink 自有设施与 Orange 托管机架之间的确切分离、或哪些工作负载位于哪个位置。对于健康数据客户，数据位置、管理访问、备份存储库、监控工具和服务台之间的区别至关重要。对于非健康客户，同样的区别对于恢复和合同责任也很重要。
Alpilink 的新数据中心公告增加了一个未来层级。2026 年 1 月的第一方文章在https://www.alpilink.fr/数据中心-souverain-a-grenoble-alpilink-groupe-renforce-son-offre-dhebergement-avec-un-nouveau-site-opere-par-alpilink-cloud/中表示，Alpilink Groupe 正在格勒诺布尔建设一个新的主权数据中心，由 Alpilink Services Cloud 运营，以加强其基础设施，预计 2027 年夏季投入使用。文章称该站点将位于 Saint-Martin-d'Hères，在一个收购并装修为数据中心用途的建筑内。文章描述了模块化多房间架构、高天花板、高密度设计、电气和气候冗余、发电机组、增强物理安全、访问控制、监控、与高级灾难恢复和业务连续性要求的兼容性、目标 PUE 约 1.3，以及时间表：2026 年施工，2027 年初交付和测试，2027 年夏季逐步投入使用。
项目页面https://www.alpilink.fr/services-cloud/nouveau-数据中心-alpilink-cloud-a-grenoble/重复了相同的框架：未来站点旨在实现更高的密度、弹性、主权和能源性能；目标架构相当于 Tier III；截至发布时间，尚未投入运营。这是一个重要的已安装与可用容量边界。规划中的站点可以支持预售、预留和架构规划。它不能支持 2026 年 7 月的声明，即未来房间、电力路径、冷却路径和客户迁移程序已经可用于生产流量。
因此，正确的尽职调查问题有两个方面。对于当前服务，客户的工作负载今天究竟位于何处：Alpilink 自己的数据中心、Orange - La Fabrique 机架、另一个已连接站点，还是未在公开命名的托管位置？对于 2027 年项目，预留空间何时可供客户使用，必须通过哪些验收测试，客户如何迁移，以及如果新站点的计划变更会发生什么？已安装容量是当前可以供电、冷却、连接和支持的设备和设施。已宣布的容量是关于未来设备或房间的承诺。可用容量是客户可以通过合同条款、网络可达性、备份策略和人员覆盖实际使用的子集。
当前服务目录足够广泛，创造了许多依赖路径
服务云页面列出的托管、IaaS、虚拟机、托管服务、备份和外包灾难恢复之所以重要，是因为每种服务都有不同的故障形态。托管最接近物理设施。客户可能拥有硬件，但 Alpilink 提供机架空间、电力、冷却、交叉连接、物理访问和一些远程操作。IaaS 和虚拟机将更多责任转移给提供商：虚拟机监控程序、存储、编排、主机维护、快照，有时还有操作系统模板。托管服务增加了人员和程序。备份和灾难恢复增加了额外的恢复承诺，该承诺必须比其保护的生产环境更独立。
第一方数字提供了规模感：三个互联数据中心、40 Gbit/s 保证带宽、超过 1500 台托管服务器和 3 PB 存储数据。这些数字足够具体，很有用。但它们是第一方数字。AS35667 的公共路由记录显示一个可见 /21；更广泛的 AS28768 PeeringDB 对象暗示更多的网络足迹；服务云页面暗示多站点基础设施；HDS 页面命名了一个自有数据中心和分包商的 Orange 机架位置。这些证据与一个成熟的区域云提供商一致，但它不允许局外人将 1500 台服务器声明分配到设施、客户、服务类型或备用容量中。
风险并非数字有误。风险在于买家可能将总体规模解读为个人保护。一个提供商可以托管 1500 台服务器，但仍将客户的工作负载集中在一个机架中。它可以有三个互联数据中心，但仍销售不包含跨站点恢复的特定备份计划。它可以保证网络级别的 40 Gbit/s，但客户端口、防火墙或存储阵列仍可能成为瓶颈。它可以运行 7x24 小时支持，但硬件更换路径仍受限于备件可用性或访问窗口。总体容量是一个有用的起点；工作负载级别的服务设计才是购买决策。
对于备份和灾难恢复尤其如此。Alpilink 宣传外包灾难恢复，HDS 页面使用法语术语表示连续性和监管保证。客户应询问备份存储库是否位于单独设施和单独管理凭证下，备份网络是否路由到不同的故障域，还原测试是否记录在案，完整还原需要多长时间，快照是否不可变，以及勒索软件、操作错误或计费争议场景如何处理。依赖同一帐户、同一存储结构和同一支持队列的备份服务可能会减少意外丢失，同时在更广泛的 outage 中仍然失败。
托管服务创造了另一个隐藏的依赖：人员。Alpilink 的公共页面强调法国专家可用性、7x24 小时覆盖和本地支持。HDS 页面指出部分支持人员位于塔希提岛，部分在公司。这可能是优势，因为时区分布可以改善非工作时间的覆盖。但它也需要明确。哪个团队可以重启设备？哪个团队可以访问管理网络？哪些事件需要格勒诺布尔的工作人员？如何控制权限？如何执行健康数据访问限制？当支持事件需要设施操作员、网络团队和客户管理员同时响应时，会发生什么？
路由和 DNS 证据应视为控制证据，而非完整的服务地图
公共路由证据证明了对可用互联网资源的控制。它并未告诉我们每项服务位于何处。RIPEstat 地理位置https://stat.ripe.net/data/geoloc/data.json?resource=94.143.216.0/21和 MaxMind GeoLitehttps://stat.ripe.net/data/maxmind-geo-lite/data.json?resource=94.143.216.0/21在查询视图中将 /21 定位在法国。DNS 链查询https://stat.ripe.net/data/dns-chain/data.json?resource=xsalto.com显示 xsalto.com 解析为 81.200.40.205，名称服务器为 ns01.xsalto.net、ns02.xsalto.net 和 ns03.xsalto.net。该 xsalto.com 网站地址位于 AS35667 /21 之外，因此不应将其用作 94.143.216.0/21 位置或容量的证据。
这是一个正常模式。公司的营销网站可以位于独立的平台、遗留地址范围、集团网络、网络托管商或内容分发提供商。公共网站的位置仅在声明涉及网站可达性时有用。它不是客户计算的直接地图。相反，一个可路由的 /21 是有用的控制证据，但不是服务目录。它可以承载管理系统、客户虚拟机、DNS、监控、备份网关和内部接口。没有公共服务地图，局外人无法知道哪些地址对应哪些产品。
PeeringDB 增加了另一层，但也有局限性。AS35667 的 PeeringDB 条目https://www.peeringdb.com/api/net?asn=35667列出 XSALTO 2，网站http://www.xsalto.com，AS set AS-XSALTO，配置文件中一个 IPv4 前缀、一个 IPv6 前缀，欧洲范围，1-5 Gbit/s 流量，零公共 IX 计数和一个设施计数。设施 APIhttps://www.peeringdb.com/api/fac/7114将 XSALTO Grenoble 识别为 Seyssinet-Pariset 的设施，该设施记录中有两个网络和零 IX 计数。PeeringDB 由运营商维护，可能不完整，但它仍然是有用的公共证据，表明该 AS 不仅仅是一个抽象的注册。
更广泛的 AS28768 配置文件https://www.peeringdb.com/api/net?asn=28768是更大互联故事出现的地方。它列出一个 IX 和三个设施，netixlan 端点列出 France-IX AURA LyonIX。这可以支持一个假设，即 Alpilink 更广泛的网络拥有比 AS35667 单独更多的路径。但是，没有客户特定的网络图，它不能证明 AS35667 客户流量具有独立的上游、独立的边界路由器、独立的光纤路由或跨站点的自动故障转移。AS35667 的公共路由显示在 AS28768 之后；客户应询问该边界之后存在什么多样性。
RPKI 有效性是当前 AS35667 证据中最强的路由卫生点。它降低了意外或恶意起源冲突的风险。它不能解决所有路由问题。如果 AS28768 出现故障，如果设施断电，如果交叉连接被切断，如果防火墙关闭失败，如果 DDoS 事件使交接点过载，或者如果客户 DNS 依赖于单个提供商路径，RPKI 无法恢复应用程序。它是一个路由认证控制，而不是运营恢复计划。
电力、冷却和密度方面，已宣布的容量必须谨慎处理
Alpilink 的新数据中心页面值得注意，因为它们直接谈到功率密度和热设计。2026 年 1 月的文章称，未来站点设计用于应对不断上升的应用负载、关键信息系统以及数据/AI 工作负载。它提到模块化多房间架构、高天花板、电气冗余、气候冗余、发电机组、物理安全、访问控制、监控、与高级灾难恢复和业务连续性的兼容性，以及目标 PUE 约 1.3。项目页面同样表示，未来数据中心目标实现 Tier III 等效架构、完整的电气冗余、模块化多房间设计、能量密度和高效的热/冷流管理。
这些声明具有商业意义。它们表明 Alpilink 理解许多区域云提供商现在面临的问题：每个机架的密度上升速度快于传统房间设计吸收的速度。为适度虚拟化构建的服务器机房在客户要求高密度存储、分析、AI、安全设备或高内存主机时可能变得紧张。容量限制不再只是机架数量；而是每机柜功率、冷却路径、线缆管理、UPS 容量、发电机自主性、断路器选择性、监控以及在不干扰相邻负载的情况下更换故障组件的人员能力。
时间很重要。同一页面将施工和装修定在 2026 年，2027 年初交付和测试，2027 年夏季逐步投入使用。截至本文发布日期，这些未来房间应被视为已计划或正在开发，而非已证明的可用容量。预留空间的买家可以从项目中受益；需要立即生产恢复的买家不能依赖于该未来站点，直到它经过调试、测试、连接、签约和验收。
当前的绿色托管声明也应谨慎解读。2024 年 7 月的可持续发展文章https://www.alpilink.fr/alpilink-cloud-notre-engagement-envers-un-hebergement-durable/表示，Alpilink 将其部分基础设施用于一个生态负责任的数据中心，使用 100% 可再生电力、地下水冷却而不消耗水、符合数据中心能源效率欧洲行为准则，以及低于 1.30 PUE 的能源效率。2024 年 6 月的文章https://www.alpilink.fr/un-数据中心-peut-il-etre-vert/表示，格勒诺布尔附近的 Alpilink Cloud 数据中心设计得尽可能良好，并使用水力发电能源。
这些可持续发展声明可以成为运营优势。高效冷却和本地可再生能源可以降低运营成本和风险敞口。但 PUE 和绿色能源本身并不能证明备用容量。一个低 PUE 设施可能已满。一个可再生供电的站点仍可能存在发电机、UPS、冷却、维护或人员限制。可持续设备生命周期可以减少浪费，同时也增加了了解硬件年龄、备件政策和更新计划的需求。因此，客户应询问按机架、功耗、冷却分配和服务等级划分的当前容量，而非仅依赖可持续性语言。
数据本地化是优势，但必须逐项服务明确
Alpilink 的定位围绕法国主权构建。服务云页面表示公司在法国提供主权托管和法国支持。Tech&Fest 2026 文章https://www.alpilink.fr/techfest-2026-alpilink-services-cloud-au-coeur-des-enjeux-de-souverainete-numerique/将 Alpilink Services Cloud 置于格勒诺布尔的主权、云和业务连续性核心。HDS 保证页面明确涉及健康数据托管、数据位置、认证、分包商角色和第三国访问风险。这比模糊的“安全云”徽章更有用。
实际规则仍然是逐项服务。客户的生产虚拟机可能位于 Alpilink 自己的设施中。备份副本可能位于另一个互联数据中心。健康数据机架依赖可能涉及 Orange - La Fabrique。支持访问可能涉及塔希提岛的人员通过加密访问进行。DNS 可能在一个系统中，发票在另一个系统中，客户文档在另一个系统中。当每个表面都被映射时，主权声明最强：计算、存储、备份、日志、工单、监控、电子邮件、凭证、管理和灾难恢复手册。
HDS 页面为客户提供了一个良好开端，因为它命名了角色，并声明在此上下文中，Alpilink Cloud 未将个人健康数据传输到欧洲经济区以外的第三国。它还表示，在显示的表中，Alpilink Cloud 未获得 SecNumCloud 3.2 认证。这一区别很重要。HDS 和 ISO 27001 对于特定用途可能是强有力的控制，但它们不等同于 SecNumCloud 认证，不是完整的弹性证明，也不能保证每个产品、客户或分包组件都在同一范围内。
对于非健康工作负载，同样的尽职调查适用于不同的标签。数据在哪里？谁可以访问？哪个国家管辖合同？哪些分包商提供机架、网络、电源、监控或支持？客户可以多快导出数据？备份是否存储在与生产相同的法律和运营域中？日志是否保留在法国？加密密钥是客户持有、提供商持有还是共享？如果客户必须离开，它能否在不等待手动支持队列的情况下获得磁盘映像、数据库转储、对象存储导出和 DNS 控制？
Alpilink 提议的最强版本是本地、具体和运营性的：以格勒诺布尔为中心的人员、法国设施、命名认证、具体机架、已知网络资源和可实现的迁移路径。较弱的版本将是一个没有逐项服务映射的广泛主权口号。公共记录比许多提供商更接近较强版本，但买家仍需要其自身部署的确切时间表和产品范围。
故障路径：什么先出故障，谁受影响
最明显的故障路径是机架或设施问题。托管客户可能失去电力、冷却、交叉连接或远程操作访问。IaaS 客户可能遇到主机、存储或网络故障。托管服务客户也可能失去诊断事件所需的人员操作顺序。如果受影响的位置是 Alpilink 自己的数据中心，提供商控制更多的响应。如果受影响的资产是分包商的托管机架，提供商必须与托管运营商协调。这一区别在夜间或周末中断期间很重要。
路由故障路径较窄但可见。AS35667 在观察数据中公开通过 AS28768 承载。如果 AS35667 和 AS28768 之间的内部边界、父 AS 路由器或 AS28768 背后的上游/对等光纤出现故障，编号为 94.143.216.0/21 的客户可能会看到可达性影响。如果授权路径物理上或操作上不可用，RPKI 有效性将无济于事。客户应询问客户前缀是否可以转移，是否有多个边界设备，设备位于何处，以及路径多样性是否经过测试而非仅配置。
支持故障路径是人为的。Alpilink 的 7x24 小时支持声明很有价值，HDS 页面提到塔希提岛的支持可以改善覆盖。但客户应知道该支持实际上能做什么。夜班团队能否重启主机？能否更换磁盘？能否访问设施？能否批准路由更改？能否恢复备份？能否以客户要求的语言进行沟通？能否在健康数据限制适用时采取行动？“我们看到了警报”和“我们恢复了服务”之间的区别是监控和恢复之间的区别。
迁移故障路径是最安静的，通常也是最昂贵的。Alpilink 当前的云服务和未来的数据中心项目使迁移成为一个核心问题。客户可能需要从现有的 Alpilink 房间迁移到新的 Saint-Martin-d'Hères 站点，从传统机架迁移到高密度房间，从物理服务器迁移到 IaaS，或从 Alpilink 迁移到另一个提供商。每一步都依赖于网络重新编号、DNS TTL、备份导出、存储复制、维护窗口、应用依赖和人员可用性。未来的数据中心建设只有在迁移计划成为现实后才会提高弹性。
受影响的各方比直接买家更广泛。Alpilink 的云服务服务于关心主权、健康数据托管、托管运营、业务连续性和本地支持的组织。如果机架、路由、存储集群或支持流程失败，最终用户可能会失去公共网站、旅游或商务系统、支付相关应用、内部业务服务、健康数据工作流、备份恢复或灾难恢复演练。Tech&Fest 的公共文章描述了寻找区域和主权云模型的 DSI、RSSI 和业务团队。这些正是恢复时间、数据位置和支持升级不是抽象问题的用户。
什么会提高或降低证据等级
当前证据等级：身份和网络卫生为中等偏强，因为 RIPE RDAP、RIPEstat 和 PeeringDB 在公司、AS、地址块、路由可见性和法国设施背景上一致。客户弹性为中等，因为公共证据未显示总括声明背后的实时服务地图。Alpilink 比许多小型提供商发布更多的运营细节，但客户仍需要当前机架安置、可用容量、电源设计、备份隔离和支持权限的直接确认。
如果 Alpilink 发布一份带日期的基础设施声明，将当前服务映射到设施，解释哪些数据中心通过光纤环路连接，说明 AS35667 和 AS28768 边界设备的位置，在服务层面命名当前上游/传输安排，提供公共状态或事件历史页面，描述备份分离，并区分当前容量与 2027 年站点，则证据等级将提高。如果公司发布客户可读的迁移指南，包括 Saint-Martin-d'Hères 建设的验收测试、回退、路由计划和支持窗口，证据等级将提高。
如果 AS35667 失去广泛的路由可见性，如果有效 RPKI 状态无故消失，如果 PeeringDB 设施信息变得陈旧或矛盾，如果第一方页面停止区分当前服务与未来容量，如果 HDS/ISO 声明变得不清晰，或者如果客户无法根据合同获得当前设施和恢复事实，则证据等级将下降。如果未来数据中心项目在投入使用和测试之前被营销为可用的生产冗余，证据等级也会下降。
最重要的一点是，Alpilink 的公共记录并非空洞。它是实质性的。谨慎来自精确性，而非缺失。买家有足够的理由进行认真评估。但它还没有足够的公开证据来跳过技术尽职调查。
客户在计算容量之前应要求什么
从 Alpilink 购买的最实用方式是要求提供工作负载图，然后再将任何头条数字视为可用容量。该图应命名生产计算当前运行的设施、备份存放的设施、客户公共地址使用的路由路径、虚拟机背后的存储层、可以在非工作时间行动的支持团队，以及如果客户迁移到计划的 Saint-Martin-d'Hères 站点的迁移方法。这一要求并非特殊待遇。这是将公共基础设施声明转换为客户特定运营计划的最低限度。
对于路由弹性，该图应将 AS35667 与更广泛的 AS28768 背景分开。公共 RIPEstat 证据显示 AS35667 有一个可见的 IPv4 /21 和一个观察到的邻居，而 PeeringDB 显示 AS28768 有更广泛的设施和交换足迹。此差异在一个提供商组内完全可以合理，但客户不应假设每个 AS28768 路径都保护每个 AS35667 服务。合同应说明哪些 AS 起源客户的地址，边界路由器位于何处，哪些上游或对等路径承载流量，是否测试了故障转移，以及客户 DNS 和控制访问是否依赖于同一位置。
对于设施弹性，该图应区分 Alpilink 自己的数据中心运营与 HDS 保证页面中命名的 Orange - La Fabrique 机架依赖。工作负载位于 Alpilink 运营房间的客户面临一种响应模型；工作负载依赖于分包机架的客户面临另一种模型。买家应知道谁控制物理访问，谁可以更换设备，谁负责电源事件响应，适用哪些维护窗口，以及如果任一站点不可用，适用哪些服务积分或退出权利。没有这些细节，“三个互联数据中心”的说法仍然是有用的营销背景，而非客户级别的冗余证明。
对于已安装与可用容量，买家应要求当前数字而非项目数字。服务云页面的 1500 台托管服务器、3 PB 存储数据和 40 Gbit/s 带宽声明描述了总体规模。2027 年格勒诺布尔项目页面描述了未来的高密度房间、发电机备份弹性和 PUE 目标。两组声明都没有告诉特定客户目前有多少备用 CPU、RAM、存储、机柜电力、交叉连接容量或支持时间。计划关键部署的客户应询问哪些容量是空闲的、哪些是预留的、哪些是超额订阅的、哪些需要硬件采购、哪些依赖于 2027 年调试时间表。
对于恢复，该图应包括还原证明。备份和外包灾难恢复只有在备份路径与生产故障足够分离时才有价值。客户应要求最近的还原测试证据、备份位置、备份访问控制、加密密钥所有权、还原时间估计、还原顺序优先级以及不依赖于单个过载支持队列的数据导出路径。提供商可能具有真正的区域优势，但如果恢复过程是手动的、未记录的或与同一故障存储系统绑定，客户仍可能暴露于风险之中。
这些问题不会使 Alpilink 成为弱势候选者。它们是可信的区域提供商应该能够回答的问题。公共证据已经显示了一个具有可见基础设施投资的可路由法国云运营商。缺失的不是身份；而是客户特定的弹性证明。一旦工作负载图存在，Alpilink 的本地存在、合规声明、格勒诺布尔关注点和未来数据中心项目就可以针对实际故障模型进行评估，而非针对宣传册。
对依赖运营商的底线
XSALTO35667 Alpilink Cloud S.A.S. 应被视为一个真实的法国区域云和托管运营商，拥有高于平均水平的公共身份证据。AS35667 注册于 Alpilink Cloud S.A.S.，其主要可见 IPv4 /21 被广泛宣告，RPKI 有效，PeeringDB 列出 XSALTO Grenoble，Alpilink 的云页面描述托管、IaaS、虚拟机、托管服务、备份、灾难恢复、认证、健康数据保证和多数据中心故事。运营图景足够具体，值得重视。
依赖图景也足够具体，值得质疑。AS35667 的公共路由表面狭窄。更广泛的 AS28768 网络看起来更多样化，但必须验证确切的客户路径。服务云规模声明是第一方和总括性的。新的格勒诺布尔数据中心项目计划于 2027 年，不应算作 2026 年 7 月的可用生产容量。HDS、ISO 27001 和可持续发展声明很有价值，但必须映射到客户的实际设施、服务和支持路径。
对于当前客户，实际问题很直接。哪个设施今天托管我的工作负载？哪个 AS 和前缀承载它？哪些上游和路由器在我的路径中？备份是否在生产故障域之外？哪些员工可以在非工作时间采取行动？对于故障主机、存储系统、机架电源事件、路由问题或站点中断，我的还原时间是多少？如果我需要迁移到新数据中心，必须更改什么，谁拥有每一步？
对于新买家，公共记录支持有条件的对话，而非盲目购买。Alpilink 拥有可信区域云提供商的可见要素：真实的路由资源、命名设施背景、本地运营、合规声明和基础设施投资计划。购买决策应基于当前可用容量、故障隔离和退出权的实际证明。托管容量总是归结为物理依赖。在 Alpilink 的情况下，这些依赖足够可见，可以提出更好的问题：格勒诺布尔的机架、通过 AS35667 和 AS28768 的路由控制、电力和冷却限制、7x24 小时支持权限、备份分离，以及从今天房间到明天承诺站点的迁移路径。