摘要
- LIVEHOSTING 数据中心 SRL 公开表明自身是蒂米什瓦拉一家数据中心的操作者，并持有 AS41635。其当前销售页面提供网站托管、虚拟服务器、专用服务器、服务器管理及 1U-3U 机柜托管。
- 公共网络边缘处于活动状态，而非仅注册而已。RIPEstat 于 2026 年 7 月 12 日观测到 AS41635 发出的 89.38.208.0/22 路由，在其路由状态快照中对所有 326 个报告 IPv4 对等体可见，观测到的相邻网络为 AS12302 和 AS39737。
- 物理证据则不够新。一份 2012 年的罗马尼亚行业指南报告了一个 30 平方米的数据室、两个 50 kW 三相电源、一个 100 kW 柴油发电机和四个 40 kW UPS 单元。这些数字是有用的历史数据，但并不能确定 2026 年的设备、负载、运行时间或冗余情况。
- 托管页面列出了两个电源、UPS、发电机、DDoS 防护和 1 Gbps 互联网端口。它并未公布 A/B 电路分离、发电机燃料续航时间、冷却冗余、光纤入口、运营商承诺、维护测试结果或第二个恢复站点。
- 网络证据等级为中等。有令人信服的证据表明存在当前服务和路由运行表面，但尚没有足够的当前独立证据来将所销售容量视为可同时维护的或在设施或运营商故障后可证明恢复的。
该主张具体且可测试
LIVEHOSTING 数据中心 SRL 并不隐匿于模糊的云标签之后。其当前联系页面列出了这家罗马尼亚合法公司，给出注册号 J35/815/2010 和税号 RO26963713，识别 AS41635，并声称该公司在蒂米什瓦拉运营自己的数据中心。其托管服务报价将客户设备置于该设施内，并列明 UPS 和发电机防护。这比从不指明站点或网络的转售商更为具体。
具体性创造了有用的举证负担。如果供应商声称其运营客户工作负载背后的建筑级基础设施，那么相关单元并非价格页面上显示的虚拟服务器。而是从市电输入到 UPS、发电机、配电、冷却、机架、交换机、边缘路由器、运营商路径和技术人员的完整链条。每一个环节都可能减少故障时客户实际可用的容量。
该公司的公开业务范围涵盖多种依赖类型。其首页推广 Windows 和 Linux 主机托管、虚拟服务器、专用服务器、托管及服务器管理。共享主机客户依赖于供应商控制的平台。虚拟服务器客户依赖于他们无法直接检查的主机和存储设计。专用服务器客户依赖于硬件、交换机和远程访问。托管客户拥有更多服务器所有权，但仍依赖于设施和网络。因此，公共电力或运营商层面的故障可能影响到在发票层面看似独立的产品。
关键区别在于运营证明与韧性证明之间。AS41635 和当前产品目录有力地证明了 LiveHosting 在运营。但它们本身并未显示在失去一条供电线路、一组 UPS、一个冷却单元、一台边缘路由器或一个光纤入口后，有多少负载能幸存。这第二个问题决定了一个小型的蒂米什瓦拉数据中心是仅在平常日子可用，还是在困难日子可恢复。
当前服务背后是较小的公开足迹
公开证据支持一个实际运营中的企业。LiveHosting 发布了虚拟服务器、专用服务器和托管的价格，维护着客户账户和订购页面，并提供了网络滥用联系邮箱。其SSD 虚拟服务器页面列出了六种配置，而NVMe 页面列出了另外六种。其专用服务器页面宣传HP ProLiant DL360 G7和G8系统，配备双热插拔电源和多个网络接口。
这些页面确立了销售表面，而非库存数量。它们并未说明安装了多少台物理主机、有多少可立即交付、CPU 和内存的承诺比例，或者现场是否备有替换系统和驱动器。一种配置可能在下单时仍可订购，而最后一个合适机箱已在用、备件正在维修，或无法为机架分配新电力。因此，买家应将所列配置视为所销售的服务类别，而非经审计的已安装容量。
公开的企业足迹也显得较小。罗马尼亚公司信息聚合商Termene.ro 的公司档案显示 2024 年营业额为 736,213 罗马尼亚列伊，净利润 286,410 列伊，平均员工一人。而 LinkedIn 将该公司归类为 2-10 名员工区间，并表示自 2006 年以来已服务超过 4,000 名客户。两者均不能证明当前夜间事件可用的工程师人数。承包商、关联员工、运营商技术人员和建筑人员都可能处于法定平均值或社交媒体范围之外。
这种不确定性很重要，但并不意味小团队能力不足。小型运营商可以在技术上训练有素且响应迅速。他们也可能严重依赖一名管理员的技能，以及响应时间超出客户合同的供应商。相关证据是当前的值班表、升级安排、访问名单和供应商支持权限。公开的员工人数信号只是让这些问题变得更加重要。
蒂米什瓦拉是服务地点，但非完整站点地图
LiveHosting 反复声称其在蒂米什瓦拉运营自有数据中心。其法律联系信息将注册办事处理于市郊的敦布拉维察，而托管页面则说明服务地点为“LiveHosting 数据中心 Timisoara”。这些声明是兼容的，但并不能证明注册办公室、数据室和每一台广告中的服务器都在同一地址。
数据中心 Map 的设施条目描述了一个 LiveHosting 设施，位于蒂米什瓦拉市中心两公里范围内，并表示确切位置不公开。其生态系统页面未报告该站点的网络或服务提供商数据。数据中心 Map 是一个商业目录，而非工程审计，但公开精确地址的缺失强化了一个重要边界：城市是支持的，建筑身份和所有权结构则不是。
“自有数据中心”可以描述多种安排。公司可能拥有房产及所有机电设备。可能拥有租赁建筑内的 IT 机房。可能运营机架和交换设备，而房东控制市电输入、消防系统或冷却。可能将发电机维护或远程安防外包。这些模式本身并无缺陷。它们会产生不同的恢复权利和不同的供应商节奏。
评估托管的客户应索要责任矩阵。该矩阵应明确谁拥有建筑、谁运营每个电气阶段、谁维护冷却、谁控制物理访问、谁持有发电机燃料合同、谁拥有外部光纤、以及谁有权批准紧急工作。还应区分法律注册办公室与设施地址以及任何备用地点。没有这张地图，“自有数据中心”一词有用但不完整。
服务区域在网络层面最为清晰。AS41635 注册在罗马尼亚，产品以罗马尼亚语销售，IPinfo 的 traceroute 在 2026 年 6 月通过 Prime Telecom 到达源自块中的一个地址，目的地标注为蒂米什瓦拉。这支持了罗马尼亚交付。但并不能证明每一项备份、控制服务、监控探针或客户副本都留在罗马尼亚。
详细的 2012 年快照无法证明 2026 年的设施
最具体的公开物理设施描述出现在 Market Watch 的数据中心 2012 指南中。该指南报告了一个 30 平方米的数据室、两个额定 50 kW 的三相变压器电源（一个来自 Electrica，另一个来自 CET）、一个 100 kW 柴油发电机和四个额定 40 kW 的 UPS 单元。还列出了 1 Gbps 通信、戴尔服务器、存储和网络设备、通过 PRTG 和 DRAC 进行的监控，以及 ISO 9001 和 ISO 27001 认证。
这是有价值的历史证据，因为它提供了当前网站所不具备的规模和拓扑声明。但也是十四年前的信息。设备老化、电池更换、冷却扩容、线路重布、运营商合同变更，设施也可能搬迁。该指南可能准确捕捉了供应商当时的状态，但对如今服务客户的设施则说明甚少。
这些数字也需要解读。两个标称 50 kW 的电源并不等于 100 kW 的弹性 IT 负载。如果任一电源必须能够承载整个机房，那么弹性市电容量可能更接近较小路径在扣除损耗和非 IT 负载后的可用额定值。100 kW 发电机并不能确定在计入冷却、UPS 损耗、照明、泵和启动电流后所能支持的 IT 负载。四个 40 kW UPS 单元并未揭示它们是配置为 N、N+1、2N，还是支持不同负载的独立系统。
因此，当前网站应与 2012 年指南一起阅读，而非合并。当前页面证明托管和服务器产品仍在销售。旧指南展示了公司曾经披露的内容。本文审查的公开文件中，没有一份将历史额定值与当前的单线电气图、调试记录、负载测试、电池状况报告或燃油运行时间测试联系起来。在出现这些之前，历史数字是提问的基线，而非当前容量的证书。
两个服务器电源不能证明两条独立供电路径
当前的托管表格在其 1U、2U 和 3U 计划下将电源供应列为“2”。专用服务器页面同样宣传双热插拔 750 W 电源。这是良好的组件级设计：如果一个电源模块故障，只要另一个模块及其输入保持健康，服务器可以继续运行。但韧性取决于两条电源线的去向。
如果两个服务器电源都连接到同一个机架 PDU，那么该 PDU 仍然是单点故障。如果两个 PDU 连接到同一个 UPS 输出或配电盘，那么上游电气路径仍是共享的。如果独立的 UPS 系统依赖一个转换开关或一台发电机，那么那里的故障可能同时切断两个看似独立的馈电。即使物理上独立的市电连接也可能共享建筑外的变电站、电缆路由或保护方案。
这就是为什么Uptime Institute 对 Tier 拓扑的解释区分了冗余组件与并发可维护性及容错能力。第二个组件不等于第二条输送路径。本文未给 LiveHosting 分配任何 Tier 等级；本文审查的公司页面未声称任何等级，2012 年指南也明确未提供 Uptime 分类。该框架仅用于澄清什么证据能支持更强的说法。
对于每个作为双路供电销售的机架，LiveHosting 应能够展示从市电或发电机经开关柜、UPS、配电到 PDU 的 A、B 路径。应说明哪些设备是单电源线连接，以及是否使用了转换开关。应公布最大机架功率、断路器额定值、允许的稳态负载和计量方法。托管页面称电费包含在内，但未量化电力配额。这一遗漏使得将 1U、2U 或 3U 空间转化为安全且商业上可执行的电力承诺变得困难。
最重要的测试不仅是图纸。而是在实际负载下进行受控切换，同时客户设备保持在线，随后提供证据证明电池、发电机、冷却和网络设备按预期运行。
存在发电机不等于发电机续航能力
当前销售页面列出了发电机，2012 年指南报告了一台 100 kW 柴油机组。发电机可以弥补长时间市电中断，但前提是整个支持系统正常工作：自动检测、启动电池、转换设备、燃料、冷却、排气、维护、负载接受和加油通道。“发电机”这个词并未披露这些条件中的任何一个。
运行时间是第一个缺失的数字。一个油箱可能在部分负载下支持数小时，但在设计负载下支持时间短得多。燃料消耗随电力需求变化，而设施的需求不仅限于服务器。冷却必须在电网失电期间继续运行；否则发电机可以让 IT 设备保持通电，而机房温度上升直至强制关机。因此，公开的运行时间应说明所支持的临界负载、现场最低燃料量、加油合同以及关于冷却的假设。
Uptime Institute 的燃料系统指南描述了 Tier 拓扑在设施标称 N 负载下 12 小时最低储存预期。这是一个参考点，并非证据表明 LiveHosting 满足或需要采用该确切设计。小型供应商可以选择不同的风险目标。重要的是客户知道目标，并能将其与自身的恢复需求进行比较。
测试与油箱大小同样重要。每月空载启动并不能证明发电机和转换系统能在炎热天气承载整个机房。有意义的记录应包括带载切换测试、持续时间、负载百分比、燃料质量、告警、启动失败和纠正措施。还应显示在移除市电后，两个当前运营商路径和外部监控是否仍可用。
对客户的影响是直接的。短时间中断可由 UPS 电池吸收。较长时间中断则成为发电机和燃料事件。如果发电机故障或无法支持冷却，机房内所有产品可能面临相同的关机时限，无论其上方有多少虚拟机、RAID 集或服务器电源。
冷却决定了多少电力容量可用
本文审查的公开材料未提供当前冷却设计、安装冷却容量、冗余级别、机柜布局或环境运行范围。这一缺失使得读者无法将历史电气额定值转化为可用的 IT 容量。几乎每一瓦 IT 设备消耗的电能都会转化为必须移除的热量，而机房可能在达到标称电气极限之前就受到冷却的约束。
2012 年报告的 30 平方米数据室对当前机架密度也说明不了什么。一个负载较轻的小机房可以是稳定的。同样的机房如果装满双处理器服务器、高密度存储或高速交换设备，即使建筑总功率仍在标称极限内，也可能出现热点。专用服务器目录包括多硬盘和双处理器的系统，而客户托管设备则更不可预测。容量分配必须同时考虑平均热量和局部集中度。
冷却冗余有多个层面：冷却单元、压缩机或冷冻水源、泵和风机、控制系统、电源和排热路径。“N+1 冷却”仍可能隐藏共同的管路、控制或电气依赖关系。维护可能比故障更具揭示性。如果一个冷却单元在炎热天气下无法隔离维修而不降低机房承诺负载，那么已安装容量超过了可同时使用的容量。
买家应询问服务器入口处的温度和湿度范围、传感器位置、告警阈值、趋势记录、高温天气余量以及冷却单元失效测试的结果。回复应解释自动关断策略以及在温度上升时对客户的通知。还应说明发电机容量是否包括支持承诺 IT 负载所需的所有冷却。
火灾和水灾的影响随之而来。冷凝水、屋顶或管道泄漏可能会迅速影响紧凑型机房。火灾探测和抑制必须与有人空间和带电设备兼容。公开材料提及了历史上的物理安全和监控，但未提供当前的防火分区、泄漏检测、灭火或洪水区域证据。客户不应仅凭数据中心标签推断这些控制措施。
已安装、可销售和可恢复容量是不同的数字
供应商可以如实拥有已安装设备，同时可用于新客户的容量较少，故障期间可用容量更少。已安装容量是标牌和已配置资源的总和。可销售容量是商业和工程规则在预留和超售后的许可量。可恢复容量是在定义组件故障后剩余或能在规定时间内恢复的量。
LiveHosting 的公开页面宣传服务器 CPU、内存、SSD 或 NVMe 存储以及“无限”流量。这些规格描述了一项权利或产品配置。它们并未显示主机占用率、存储复制、上行链路争用或备份吞吐量。“无限”流量尤其容易被误解：它可能意味着不基于流量计费，而每个数据包仍然共享有限的端口、边缘和传输承诺。
没有电力和网络余量，托管空间同样是不完整的。三个 1U 客户可能比一个 3U 客户耗电更少，也可能多得多，具体取决于硬件。1 Gbps 端口是接口速率，而非受到攻击或一个运营商故障后保证的互联网吞吐量。发电机标牌不是客户容量承诺。UPS 额定值不是运行时间保证。
关键运营指标是故障状态预算。如果一条供电路径被隔离，剩余多少千瓦？如果丢失一个冷却单元，可维持的机房温度是多少？如果 Prime Telecom 或 Vodafone 不可用，剩余互联网容量是多少？备份中可同时重启多少台虚拟服务器？多少名工程师可以同时处理硬件、网络和客户事件？
这些数字应关联到客户类别。共享主机可能允许与公共部门网站、事务性应用、邮件服务器或托管企业系统不同的恢复时间。小型设施不需要超大规模容量才有用。它需要适合其实际冗余的承诺，以及明确拒绝销售超出故障状态包络线的容量。
AS41635 处于活动状态且全球可见
网络证据是公开记录中最有力的部分。RIPE RDAP将 AS41635 列为活跃，并命名为 LIVEHOSTING-AS。RIPEstat AS 概览将持有者标识为 LIVEHOSTING 数据中心 SRL，并标记 ASN 已宣告。这与公司自身的联系页面相符。
2026 年 7 月 12 日，RIPEstat 路由状态显示一个已起始的 IPv4 前缀，包含 1,024 个地址，无已起始的 IPv6 前缀。该 IPv4 路由在快照中对所有 326 个报告 IPv4 对等体可见。RIPEstat 的已宣告前缀视图将 89.38.208.0/22 识别为当前宣告。路由历史视图显示 LiveHosting 起始的地址空间可追溯至 2006 年，尽管聚合块随时间从 /21 变为当前的 /22。
这是有意义的运营证据。一条持续多年广泛可见的路由与仅仅装饰性的 ASN 注册不一致。该前缀承载公司自己的网站和公共服务器名称，独立聚合商也识别了它。Hurricane Electric 的 BGP 工具包报告了一个 IPv4 前缀、1,024 个已起始 IPv4 地址、两个观测到的 IPv4 对等体，无 IPv6 起点。IPinfo将该 ASN 归类为托管，并显示 2026 年 6 月有一条路径通过 AS39737 到达该块。
该路由也是 RPKI 有效的。RIPEstat 验证发现 AS41635 被授权起始 89.38.208.0/22，最大长度 /22。正如RIPE NCC 解释的那样，源站验证回答了合法资源持有者是否授权了特定的前缀-源站组合。它不验证 AS 路径的其余部分，也不证明物理韧性。
结论应是窄幅的：LiveHosting 拥有当前、有效且高度可见的 IPv4 源站。这比营销地图更有力。但它仍无法显示路由器是否冗余、运营商是否从不同管道进入，或者幸存路径能否在故障后承载客户需求。
两条可见的运营商路径仍需物理证据
RIPEstat 的ASN 邻居视图在 2026 年 7 月 12 日观测到两个相邻网络：AS12302（Vodafone Romania）和 AS39737（Prime Telecom）。BGP 状态快照显示绝大多数采样路径经过 Prime Telecom，少数经过 Vodafone。Hurricane Electric 独立列出了相同的两个对等体。
观测到两个邻接比一个更好，因为它们提供了潜在的路由备选。但不应在没有合同和站点证据的情况下称之为两个经过验证的独立运营商。路由收集器观测的是 AS 路径，而非光纤所有权、建筑入口、交叉连接或付费容量。一个运营商可能转售另一个。两条电路可能共享同一个城域管道、人孔、街道交叉口、配线架或相同的外部供电设备。
RIPE 注册对象增加了另一个谨慎原因。其导入策略最后修改于 2021 年，列出了 AS6830 和 AS34279，而当前收集器看到的是 AS12302 和 AS39737。这种差异可能仅仅反映了运营商正常变动后的过时注册策略。这说明了为什么注册声明不能取代当前观测或当前运营商排期。
故障后的容量是另一个问题。如果主路径承载大部分流量，备用路径必须有足够的承诺和突发容量来吸收它。BGP 可能成功重收敛，而由于剩余电路拥塞，应用变得不可用。DDoS 防护增加了另一层依赖：供应商应说明过滤发生在何处、两个上游是否都支持、路由如何分流，以及防护事件是否减少洁净容量。
所需证据是实际的。LiveHosting 应识别两个签约运营商、端口和承诺容量、物理分界点、入口路径、边缘路由器和电源域。应展示最近一次在繁忙负载下单独撤回每个上游的测试，记录收敛和数据包丢失，并确认监控和客户通信保持可达。
无 PeeringDB 档案限制了公开可查的内容
本次审查中，对PeeringDB API的查询未返回 AS41635 的网络实体。这不是网络故障的证据。PeeringDB 参与是自愿的，小型托管网络可以购买传输服务而不维护公共互联档案。但这一缺失确实降低了设施、交换、流量水平、对等策略和网络联系人的公开可见性。
当前形态看似以传输为主导而非交换主导。公共收集器暴露了两个相邻网络，但没有公共 PeeringDB 记录识别互联网交换或设施连接。因此，客户应避免假设该网络拥有直接对等、多样化的交换路由或运营商中立的数据中心内部互联。这些功能可能存在；本文审查的公开记录未予确认。
这对故障隔离很重要。如果所有外部路径依赖于一栋建筑内的一小组传输交接点，那么即使全局路由表显示两个上游 ASN，本地运营商汇接点仍可能是共同的故障点。如果一条电路在站点外终止，并通过共享的本地接入线到达数据室，逻辑多样性可能在最后一公里消失。
供应商可以在不暴露敏感细节的情况下解决这一不确定性。它可以发布一个设施中立的网络图，显示独立的入口、独立的边缘设备、运营商身份、端口容量和故障转移策略。如果合适，可以维护当前的 PeeringDB 档案。可以提供 looking glass 或外部托管的状态服务。这些都不能证明每一个管道，但共同使网络的运营模式更易于验证。
缺失的 IPv6 源站需要直接回答
LiveHosting 的托管页面称每个套餐包含一个 /56 IPv6 子网。然而，RIPEstat 和 Hurricane Electric 在 2026 年 7 月的快照中显示 AS41635 未起始任何 IPv6 前缀。法国电信监管机构 ARCEP 在其 2025 年托管供应商测量中也将 AS41635 列为 IPv6 暴露量为零。这些观察并不证明客户未收到 IPv6 服务。
广告中的 /56 可能来自上游供应商的地址空间，并通过路由到达 LiveHosting 而无需 AS41635 起始 IPv6 前缀。可能仅应要求提供。可能在设施内部配置，但在采样的公共数据中不可见。每一种解释都有不同的韧性影响。
供应商分配的 IPv6 可以很好地工作，但故障转移可能依赖于分配的上游。如果 /56 属于一个运营商且该运营商故障，LiveHosting 可能无法通过另一条路径宣告同一个客户子网。在事件期间重新编号服务器集群并不等同于 BGP 故障转移。DNS、防火墙规则、访问列表和客户软件都可能保留旧地址。
买家应询问 /56 位于哪个聚合块、由哪个 ASN 起始、是否可通过两个可见上游到达，以及路由源授权是否覆盖了预期源站。还应询问 1 Gbps 端口和 DDoS 防护是否同等适用于 IPv4 和 IPv6。一个双栈服务的韧性仅与其测试较少的那一栈相当，当应用和 DNS 同时发布两者时。
这一差距很重要，因为 IPv6 不是一个装饰性功能。托管页面将其作为包含的容量呈现。公共路由证据使 IPv4 运营表面清晰；等价的 IPv6 证据将把 /56 从销售行转变为可验证的网络服务。
质量承诺的范围小于设施保证
LiveHosting 的质量承诺适用于 Standard、Business 和 Reseller Windows 或 Linux 网站托管套餐。它将正常运行时间定义为客户网站从中立位置通过 HTTP 可访问的月度比例。该页面称 LiveHosting 在其数据中心内以及罗马尼亚和国外的其他数据中心使用 PRTG 系统来测量可用性。
积分方案在正常运行时间介于 98% 和 99.5% 之间时返还 50%，介于 95% 和 97.9% 之间时返还 75%，94.9% 及以下时返还 100%。服务积分在商业上有用，但它不是对销售损失、数据或声誉的补偿。更重要的是，所述范围不自动覆盖虚拟服务器、专用服务器或托管。这些类别的买家需要自己的服务条款。
免责条款很宽泛。该页面排除了通信中断、火灾、洪水、自然灾害、病毒、攻击者、第三方软件、已宣布或关键维护、服务器升级、LiveHosting 控制之外的 DNS 以及若干访问协议。一些排除项恰恰描述了数据中心客户最需要了解的故障路径。将其排除在积分之外并不会使其变得不太可能；它将其经济成本转移给了客户。
测量定义也侧重于 HTTP 可达性。一个网站可能在电子邮件、数据库连接、存储、控制面板、VPN 访问或一个运营商路径降级时仍能响应。相反，应用故障可能导致 HTTP 失败，而设施电源和网络保持健康。客户需要组件级测量和一份区分设施、网络、计算、存储和应用原因的事件记录。
更强有力的保证包将按产品公布历史服务绩效、维护分钟数、事件原因和恢复时间。它将说明哪些监控位置独立于 AS41635，以及状态渠道在完全设施或路由中断期间是否保持可达。
响应时间不是恢复时间
质量页面承诺在周一至周五 10:00-18:00 内最大技术支持响应时间为 24 小时。当前联系页面列出技术支援时间为周一至周五 10:00-17:00。这些页面可能描述了不同的渠道，或者仅仅是不同步。无论哪种方式，这两份声明都不是在 24 小时内恢复服务的承诺。
服务器管理页面增加了一个更细化的商业区别。基础管理包括每月两小时和仅工作日可用。高级管理包括每月四小时，并声明周一至周日 24 小时可用。公开的服务合同称管理工作限于所购订阅中的小时数，额外工作需收费，且管理服务不保证应用可用性或性能。
这给非托管专用和托管客户留下了一些问题。即使服务器管理不可用，设施紧急响应是否连续？凌晨 3:00 谁处理电源、冷却或网络告警？远程手是否随时可用，到场目标是什么？托管页面将远程手定价为每小时 25 欧元，但未公布全天候响应承诺。
这种区分在小型运营中至关重要。检测可以是自动的，但诊断和授权可能依赖于人。运营商可能要求客户指定联系人。建筑可能限制非工作时间进入。故障服务器可能有双电源，但仍需要本地磁盘或线缆更换。每次交接都会增加恢复开始前的时间。
客户应询问四个独立时钟：告警到确认、确认到合格诊断、诊断到现场干预、干预到恢复。应询问每个时钟的负责人，以及两个事件同时发生时会发生什么。电话号码和工单承诺是有用的入口点；它们不是恢复计划。
维护可能比突发故障暴露更多风险
冗余通常在一切健康时看起来最强，而在一个组件被有意拆除维护时最弱。UPS 电池需要更换，发电机需要带载测试，冷却设备需要清洁，交换机需要升级，运营商需要维护窗口。在这些期间，剩余路径可能承载全部负载，没有备用。
质量承诺将已宣布的维护、关键工作和服务器升级排除在积分之外。这在托管合同中很常见，但实际风险取决于维护的设计方式。客户需要知道设施能否在不停机 IT 负载的情况下维护每个关键组件，多个供应商是否可能同时工作，以及回滚如何处理。
对于电源，维护证据应包括不将整个机房置于原始市电上的旁路路径和程序。对于冷却，应说明一个单元隔离时的最大安全负载。对于网络工作，应显示客户路由通过另一台路由器和运营商保持稳定。对于存储或虚拟化，应量化维护前可移动的工作负载量以及移动所需时间。
变更集中度是另一个问题。小型供应商可能明智地将多项任务安排在一个窗口以减少中断，但耦合电源、网络和主机变更消除了独立的恢复选项。客户应询问变更审批是否考虑了共同依赖关系，以及外部可达的通信渠道是否保持在受影响系统之外。
解决这一问题的证据是普通的运营材料：修订后的年度维护日历、近期窗口的通知、维护后报告、失败操作行动以及客户可见的影响。这比一般的正常运行时间目标更有说服力，因为它显示了运营商在冗余有意降低期间的管理方式。
火灾、洪水和电力中断最终影响客户数据
质量承诺明确将火灾和洪水列为不可抗力免责事项。这是合同分配，而非证明设施暴露或无保护。本文审查的公开页面未说明当前的火灾探测和灭火系统、防火分区等级、泄漏检测、洪水评估或与水和燃料源的距离。
当许多服务层位于一个站点时，这些问题更加重要。共享主机、VPS、专用服务器、托管、DNS、电子邮件和客户门户都可能依赖同一个机房。如果主数据、备份和控制系统共享设施，一个建筑事件可能同时消除生产服务和恢复手段。
公开的服务合同将重要责任放在客户身上，并限制保证。它还允许因未付款而暂停或删除服务，并保留修改或中断服务的广泛权利。这些条款使得即使在无物理事件的情况下，独立备份和经过测试的导出程序在商业上也很重要。
客户应确定每个副本的位置、谁控制其凭证、测试频率以及如果 LiveHosting 自己的账户门户或网络不可用如何进行恢复。在同一机房另一台服务器上的备份可以防止某些硬件故障，但不能防止机房级的电源、冷却、火灾或洪水事件。在另一栋建筑的副本但通过同样不可访问的身份系统进行管理，也可能难以使用。
对于托管客户，问题延伸到设备恢复。事件后谁可以进入？客户硬件是否由供应商、建筑运营商或客户投保？在长时间公用事业或访问关闭期间，客户能否取回设备？答案可能在个别合同中，但公开的计划页面并未确认。
故障以不同方式影响不同客户
共享主机客户很可能首先感受到公共平台故障，表现为网站、电子邮件或控制面板无法访问。他们可能对哪个物理服务器、交换机或存储系统发生故障知之甚少。转售商可能会放大影响，因为一个账户可能代表许多下游站点和支持义务。
虚拟服务器客户对操作系统有更多控制权，但仍依赖虚拟机管理程序容量、存储和供应商的本地网络。主机故障如果工作负载可以在其他地方重启，可能是可恢复的，但公开产品页面并未承诺实时迁移、复制存储或恢复集群。SSD 或 NVMe 的存在说明不了副本的数量和位置。
专用服务器客户避免了某些共享计算风险。他们仍然依赖机架、两条电源路径、交换设备、运营商传输和远程手。双电源和 RAID 可以吸收选定的组件故障，但无法在机房级中断或共享网络边缘故障中幸存。公开的专用服务器列表也显示了较老的 G7 和 G8 代；这可能是经济实惠的提供，但买家应询问备用系统和组件可用性。
托管客户拥有自己的设备，并可能宣告自己的地址空间，如同产品页面允许 BGP 宣告。他们对 LiveHosting 的依赖是物理层面的。他们需要访问、电源、冷却、交叉连接、路由和维修协助。设施中断可能停止完全由客户管理的设备。
公共部门、医疗、金融或工业用户还可能面临超出正常运行时间的义务。位置、事件通知、证据保留和供应商连续性可能很重要。文章未识别任何此类 LiveHosting 客户。它强调了为什么相同的设施声明可能根据放置的工作负载产生截然不同的后果。
因此，供应商应抵制一个统一的韧性声明。应披露哪些保护措施适用于每项服务、客户必须提供什么，以及哪些共同依赖关系跨所有产品线。
有意义的故障转移演示必须移除实际依赖
确定当前韧性的最佳方法是通过测试定义的故障而非积累标签。对于 LiveHosting，五项演练将回答大部分未解决问题。
第一，在代表性生产负载下移除正常市电。记录 UPS 切换、发电机启动、冷却连续性、燃料消耗、告警和客户影响。继续足够长的时间以证明公布的运行时间目标，然后在不降低负载的情况下恢复市电。
第二，依次隔离每条电源分配路径和 UPS 部分。确认双电源线客户设备保持在线，并识别需要转换设备的单电源线设备。成功的发电机测试不能替代这一内部配电测试。
第三，在环境条件苛刻的时期移除一个冷却单元或冷却路径。跟踪服务器入口温度，并确认有多少负载仍处于设施规定的环境限制内。这将冷却冗余声明转化为可用容量证据。
第四，在网络繁忙时分别撤回 Vodafone 和 Prime Telecom。测量 BGP 重收敛、数据包丢失、延迟以及 IPv4 和广告的 IPv6 服务的幸存吞吐量。确认 DDoS 防护、监控、DNS 和客户通信在剩余路径上工作。
第五，从主故障域外部的副本恢复一个代表性共享主机账户、虚拟服务器和控制服务。测量恢复时间和数据丢失，并包括客户门户不可用的情况。
结果不必完美才有价值。披露弱点并采取纠正措施比未经测试的完全可用性声明更强有力。客户随后可以判断演示的恢复是否符合自身的容忍度，以及是否需要独立的第二个站点。
电力增长和许可应被视为约束，而非假设
欧洲数据中心市场日益将电力可用性视为发展约束。欧洲委员会的能源绩效页面描述了不断增长的电力需求、冷却和水资源影响，以及超过相关阈值设施的申报义务。本文审查的公开证据中，没有任何信息证明 LiveHosting 超过了 500 kW 的申报阈值；历史数据表明设施更小。
小规模并不消除管理电力的需求。它改变了问题。一个紧凑的站点可能总需求较低，但增加开关柜、冷却、电池、排气或燃料存储的空间较小。城市或近城市建筑可能面临噪音、排放、消防和施工限制。市电连接可能足以应对当前负载，但使扩容变得缓慢或昂贵。
当前网站未公布计划扩容、新建筑或电力申请。买家不应推断。如果 LiveHosting 推广新的高密度容量，证据应说明它来自效率提升、旧设备退役、更大的市电额度、新冷却还是其他站点。“可用”一词应意味着电力、冷却和网络均已投产，而不仅仅是机架空间空置。
许可也会影响恢复。更换发电机、增加燃料存储、改变电力服务或改造消防系统可能需要审批和供应商前置时间。客户不需要每个许可编号公开。但需要确信已安装设备是授权、维护和支持的，并且计划增长不会使现有机房长期处于降级冗余状态。
正确的商业指标是为定义的故障就绪的容量，而非另一台服务器的理论空间。
什么会提升信心
LiveHosting 可以通过一份紧凑的披露包将证据等级向上移动。首先应发布由运营商注明日期和版本的当前设施概况。该概况应说明服务地址（适当级别）、运营商和房东边界、数据室面积、已投产的 IT 负载、当前测量峰值、机架功率限值、冷却拓扑和消防控制措施。
电源部分应显示市电输入、UPS 拓扑、发电机额定值、在承诺临界负载下的最短运行时间、燃料安排以及最近一次带载切换测试的日期和结果。应区分总安装额定值与 N 状态、维护状态和故障状态下的可用容量。
网络部分应将当前 Vodafone 和 Prime Telecom 的观测结果与较老的 RIPE 策略对象协调一致。应披露签约端口和承诺容量、边缘路由器多样性、物理入口分离、DDoS 安排以及广告的 IPv6 /56 的源站。当前的 PeeringDB 条目或 looking glass 将提高外部可见性，但不会取代物理文档。
运营部分应说明连续告警拥有者、设施响应目标、远程手覆盖、备件库存和供应商升级流程。应协调 10:00-17:00 和 10:00-18:00 的支持声明，并澄清 Premium 24/7 可用性对响应和恢复的意义。
最后，运营商应公布匿名化的测试和事件证据：市电切换、冷却单元丧失、运营商故障转移、恢复演练、重要维护以及吸取的教训。独立认证可以在范围和当前有效性明确的情况下强化披露包。2012 年的认证名称在没有证书、站点、标准和到期日期的情况下不应被视为当前有效。
这一披露水平不会暴露客户数据或敏感楼层平面图。它将允许买家区分一个功能正常且有测试限制的小型数据中心与一个主要从产品标签推断韧性的数据中心。
证据等级为中等
LIVEHOSTING 数据中心 SRL 在网络和基础设施证据方面获得了中等评级。公司特定的运营证据是实质性的：当前罗马尼亚销售网站、具名法律实体、明确的蒂米什瓦拉托管报价、AS41635、一个全球可见的 IPv4 路由、两个观测到的相邻网络、有效的路由源授权以及多年的路由历史。这不是供应商的存在或基本网络操作依赖单一目录列表的情况。
评级止步于中等，因为韧性声明缺少当前的物理证明。列出了 UPS 和发电机，但拓扑和运行时间缺失。列出了两个服务器电源，但 A/B 分离缺失。2012 年指南提供了详细额定值，但没有当前的调试或负载证据将那些数字连接到 2026 年的设施。在审查的来源中，冷却、火灾、洪水、光纤入口、运营商承诺、维护绩效、外部恢复和客户故障转移结果仍未披露。
两个当前的 BGP 邻接支持逻辑路径多样性，而物理路由证据的缺失阻止了更强有力的结论。有效的 IPv4 路由降低了源站风险，而 AS41635 的 IPv6 源站缺失使广告的 /56 安排悬而未决。质量承诺为客户提供了测量和积分机制，但其产品范围和免责条款限制了它对设施级恢复的说明。
该等级不是对服务质量 verdict。它是对可观测信息与仍需证明信息之间距离的陈述。LiveHosting 可能拥有比它发布的更强有力的当前工程记录。买家应在将停电成本超过服务积分的工作负载放置之前要求查看这些记录。
狭窄的结论是，所销售的容量作为一项实时服务是可信的，但尚未被证明作为故障状态容量。下一个有用的证据不是另一个服务器配置。而是当前的电源、冷却和运营商测试，显示当一个共同依赖被有意移除时，哪些设备保持在线。