摘要

  • 公共 RIPE 记录为 Medyabim 提供了统一的法律与网络身份。AS44922 的 RIPE RDAP 注册将 MEDYABIM-AS 列为其自治系统，指定 Emre Erim 为管理和技术联系人，并包含 ORG-MIH2-RIPE，其名称为“Emre Erim trading as Medyabim 数据中心”；RIPE 组织注册显示国家 TR、LIR 状态、布尔萨地址及联系方式。
  • 当前的路由表面真实但狭窄。RIPEstat AS 概览将 AS44922 标记为已宣告，而路由状态在验证快照时显示一个 IPv4 前缀、无 IPv6 前缀、256 个 IPv4 地址和一个观察到的邻居。宣告前缀视图仅列出 37.247.116.0/24 为当前。
  • 最强的正向控制是当前 /24 的路由起源安全。37.247.116.0/24 通过 AS44922 的 RIPEstat RPKI 验证返回有效，其中 ROA 授权 AS44922，最大长度为 /24。
  • Medyabim 自己的页面宣传的业务范围比当前 AS44922 路由表面所证明的更广。数据中心页面声称在 Medyabim 机架中准备好了专用硬件，拥有使用 Linux DirectAdmin 服务器的长期经验，提供土耳其及国外的服务器选项，总出站容量 50 Gbit/s，列出了 Türk Telekom 和 Superonline 等提供商路径，以及客户流量监控。主机托管页面声称 99% 的服务连续性，包含带宽、7x24 支持、防火墙后的放置、免费重启端口和五个 IP 地址。
  • 公开保证仍不完整。官方页面未公布双路电力输入、发电机运行时间、冷却拓扑、消防、运营商对接机房、维护窗口、实测故障转移结果、设施认证或当前的 PeeringDB 互联配置。Medyabim 自己的域名解析到 185.7.83.213，而 RIPEstat 显示 185.7.83.0/24 当前由 DATAFOREST 而非 AS44922 宣告，因此客户端依赖映射必须将 Medyabim 品牌、其 AS44922 边缘、已分配地址空间和第三方宣告的服务表面分开。

关键问题并非 Medyabim 是否存在

有一类区域性托管简介，首要任务是证明该公司不仅仅是一个目录中的条目。Medyabim 并非如此薄弱。公共注册包含一个具名的自然人、一个商号、一个 RIPE 组织记录、一个自治系统、已分配的地址资源、官方服务页面、布尔萨的联系地址以及有效的产品报价。问题在于：公共注册证明了身份和有限的路由边缘，而公司的营销语言要求客户相信一个更广泛的数据中心容量故事。

最强大的身份来源是 RIPE。AS44922 的 RDAP 记录将自治系统命名为 MEDYABIM-AS，并列出组织“Emre Erim trading as Medyabim 数据中心”。它还将 Emre Erim 列为管理和技术联系人，地址在布尔萨，并附有电话号码。ORG-MIH2-RIPE 的 RIPE 组织 REST 记录包含相同的商号、国家 TR、LIR 类型、布尔萨地址、电话、传真、Medyabim 维护者引用，以及 2008 年 3 月的创建日期。这比从网页抓取的托管目录条目要强得多。

Medyabim 自己的联系页面独立地锚定了公开的运营地址。它描述了“Medyabim 数据中心 ve Internet Hizmetleri”，并给出了 Kükürtlü Mahallesi, Oulu Caddesi, Oylum Sitesi F Blok Kat 3 No 13, Osmangazi, Bursa，附有电话号码和公共电子邮件地址bilgi@medyabim.com.tr。该地址与 RIPE 地址非常吻合。这一点很重要，因为该实体并非呈现为一个无面目的离岸云标签。其公共证据指向一个位于布尔萨的运营商，其网络资源记录和商业网站至少相互一致。

公司历史页面增加了自我描述。Medyabim 的关于页面称公司自 2000 年起围绕互联网服务、软件产品和基于 Linux 的交钥匙系统运营；后来专注于域名注册、网页托管、专用服务器、服务器管理和咨询；并称自 2006 年起在布尔萨建立了自己的数据中心，自有资源，容量超过 500 台服务器，用于自有服务器和网页托管公司的服务器。这不是已安装机架或电力容量的独立证明，但这是一个具体且可测试的运营声明。

因此，问题不在于“是否存在 Medyabim？”，而在于“当电力、冷却、路由、支持或上游依赖失败时，Medyabim 宣传的容量中哪些部分客户可以依赖？”对于数据中心或主机托管买家来说，身份只是第一道门。最艰难的考验是可恢复容量：在中断期间仍然可用的硬件、机架电力、冷却、光纤、路由和人员流程。

AS44922 可见，但当前公共路由表面狭小

RIPEstat 确认 AS44922 已被宣告。AS 概览端点将持有者标记为“MEDYABIM-AS Emre Erim trading as Medyabim 数据中心”，并在验证快照时将资源标记为已宣告。这是积极的网络结论。Medyabim 拥有路由系统可见的公共自治系统边缘。

该边缘的规模适中。RIPEstat 的路由状态端点显示一个 IPv4 前缀、256 个 IPv4 地址、零个 IPv6 前缀和一个观察到的邻居。宣告前缀端点列出 37.247.116.0/24 为 AS44922 的当前宣告。ASN 邻居端点显示一个左侧观察到的邻居，AS16276。AS16276 的 RIPEstat AS 概览将该邻居识别为 OVH SAS。

这并不意味着 Medyabim 只有 256 个客户、一个机架或一项服务。公共 BGP 看不到私有 VLAN、经销商库存、提供商寻址的托管、服务器库存、客户互联或外包的 Web 表面。但这确实意味着，在验证时，可见的 AS44922 边缘并非一个宽广、多前缀、多邻居的公共骨干。如果买家将 Medyabim 评估为数据中心依赖，仅凭公共 BGP 地图并不能证明多运营商弹性。

RIPEstat AS 路由一致性视图使差距更加明显。它列出 37.247.116.0/24 同时存在于 BGP 和 RIPE whois/IRR 中。它还列出 37.247.117.0/24 和 2a03:400::/32 存在于 whois/IRR 中，但在验证时刻不存在于 BGP 中。相同的一致性视图显示旧的 whois import/export peers AS9121 和 AS53667 未在 BGP 中看到，而 AS16276 在 BGP 中看到但不在 whois import/export policy 中。这在较旧的路由记录中是正常的漂移，但这正是客户应要求当前拓扑图而非依赖历史注册策略文本的原因。

正向检查是 RPKI。AS44922 的当前路由 37.247.116.0/24 通过了RIPEstat RPKI 验证检查为有效。这很重要，因为路由起源授权是托管买家无需查看私有设施文件即可验证的少数公共检查之一。有效的 ROA 不能证明电力、冷却或故障转移。它表明当前可见的 AS44922 起源在公共验证层中并非一个未知的路由起源声明。

因此，路由结论狭窄而有用。AS44922 是真实的。其当前可见的 IPv4 路由是 RPKI 有效的。其观察到的上游表面薄弱。其 IPv6 证据当前未宣告。其公共路由策略记录是证明运营商多样性或故障转移的有限公共证据。客户不应将其视为幽灵网络，也不应视其为经过验证的弹性数据中心网络。

IPv6 和休眠前缀证据需要降级

Medyabim 拥有 IPv6 注册证据。2a03:400::/32的 RIPE 搜索记录显示在 TR-MEDYABIM-20110107 下分配了 2a03:400::/29，以及 origin AS44922 的 2a03:400::/32 的 route6 条目。这看起来可靠，直到与当前路由可见性进行比较。

2a03:400::/32 的 RIPEstat 前缀概览端点在验证时刻将该前缀标记为未宣告。路由状态视图报告无当前 origin，零个 RIS 对等节点看到它，以及上次从 AS44922 看到的事件发生在 2026 年 4 月 1 日。这本身并非失败的结论。一些客户可能不购买 IPv6 服务；一些运营商可能有休眠的 IPv6 计划；一些地址块保留供将来使用。但这改变了可以公开证明的内容。一个数据中心提供商，其当前官方页面宣传托管和服务器服务，但其可见的 AS 边缘当前没有 IPv6 宣告，应被问及 IPv6 支持、其不可用性、选择性可用性或通过其他提供商提供的情况。

IPv4 休眠前缀情况也参差不齐。37.247.117.0/24的 RIPE 搜索结果显示 NET-MEDYABIM-DC5 和一个 2025 年 6 月创建的 origin AS44922 的 RIPE 路由条目。但 RIPEstat 一致性检查未在当前 BGP 中看到它。这可能代表预留容量、计划中的迁移、最近撤销的路由、备份范围或仅仅未使用的地址空间。公共证据无法在这些解释中选择。

重要区别在于已分配容量和运营容量。RIPE 分配、路由条目或地址分配可以显示管理控制或准备。它不证明地址范围今天为客户服务、通过多个运营商可达或在中断期间可以激活。需要可恢复容量的买方应询问 Medyabim 哪些前缀在生产中、哪些是预留的、哪些已迁移到其他 origin、哪些面向客户、哪些仅用于管理、以及哪些受经过测试的 DDoS、防火墙和 RPKI 流程覆盖。

Medyabim 自己的服务页面是具体的，但未公布设施弹性

Medyabim 的数据中心页面比通用的托管登陆页面更详细。它说专用服务器型号在付款验证后交付，硬件在 Medyabim 机架中准备就绪。它说 Medyabim 在 Linux 专用服务器方面拥有超过 15 年的经验，并自 2003 年起积极使用 DirectAdmin。它说公司使用位于土耳其的自己的服务器硬件，而专用服务器服务可以根据需求在土耳其或国外选择。它还描述了“高线路容量”和高可用性，作为快速提供真实服务器硬件的原因。

同一页面提出了一个大的连接性声明。它说数据中心的主互联网连接选择是为了提供从土耳其和世界的快速访问，列出了 Türk Telekom、Superonline、Level3、Tinet、Lambdanet、Cogent Communications、AMS-IX 和 ECIX Duesseldorf，并说明总线路出站容量为 50,000 Mbit，即 50 Gbit/s。它说专用服务器客户可以进入网络管理面板全天候监控自己的流量，并说数据中心使用 Foundry Networks 和 HP Procurve 网络硬件。

这是有用的证据，但必须作为公司发布的营销和运营文本阅读，而非实时的运营商审计。该页面未披露哪些命名提供商是当前的物理运营商、哪些是传输提供商、哪些是对等或路由关系、哪些是历史传输选项、哪些支持土耳其服务、哪些支持海外安置。它未显示设施对接机房、多样光纤入口、互联地图或实时端口库存。验证时刻的公共 BGP 显示一个观察到的 AS44922 邻居，而非页面上每个提供商名称的公开可见地图。

该页面在设施工程方面更为薄弱。它未公布双路电力输入、UPS 容量、电池运行时间、发电机燃料运行时间、冷却冗余、消防等级、楼板荷载、机架密度、物理安全层、维护窗口规则或灾难恢复演练。这些遗漏并不证明控制措施不存在。许多较小的提供商不公布此类细节。但评估数据中心弹性的客户不应从“数据中心”一词假设这些控制措施。

Medyabim 的主机托管页面增加了面向客户的运营声明。它说 Medyabim 为其托管服务提供 99% 的服务可用性或连续性保证，包含带宽；说在 Medyabim 数据中心拥有服务器的企业可以享受 7x24 企业支持；说流量统计可以在线观察；说服务器位于防火墙之后；说将分配免费重启端口；说分配的连接是专用的且不受限制；说为数据中心中的服务器免费分配五个 IP 地址。

这些是真实的服务声明，它们指定了买方在依赖服务之前应询问的问题。99% 的服务连续性承诺不等同于现代高可用性 SLA，99% 在一年内仍可能允许相当数量的停机时间。重启端口只有在配电、远程访问、控制台凭据和支持程序在事件中幸存时才有用。防火墙放置可以保护客户，但也可能成为共享瓶颈。五个 IP 地址可能足以满足简单托管，但它对路由子网的可移植性或故障转移毫无说明。该页面为客户提供了需要询问的事项，而非弹性的完整证明。

官方网站证明产品广度，而非可恢复容量

公开产品范围很广。Medyabim 的网页托管套餐页面宣传托管套餐，包含网页空间、流量、FTP、MySQL、Webmail、DirectAdmin、可选的 SSL、电子邮件备份产品、每台服务器附加 IP 服务、300 GB 服务器备份服务、无限制 24/7 FTP 传输、自动每周和每月备份、高级统计、反垃圾邮件过滤和传输报告。其经销商页面提供经销商套餐，包含网页空间、POP3 电子邮件配额、每月流量、MySQL 数据库、土耳其语控制面板、Webmail、可选的 DNS 控制、SSL 选项、反垃圾邮件过滤器和流量报告。

VDS 页面将虚拟专用服务器解释为物理硬件上逻辑分离的服务器，并列出 VDS 套餐功能。控制面板信息页面说 DirectAdmin 在服务器位于 Medyabim 数据中心时安装在服务器上，描述了主动服务器管理、安全配置和垃圾邮件黑名单监控，并说 PHP、MySQL、Linux、ionCube 和 DirectAdmin 已安装并配置在所有服务器上。

综上所述，这些页面显示 Medyabim 销售经典的小型提供商堆栈：域名、共享托管、经销商托管、VDS、专用服务器、主机托管、电子邮件存储、SSL、备份和托管 Linux/DirectAdmin 支持。这种混合创造了两种类型的依赖。一种是物理的：机架、电力、冷却、上行链路、防火墙、重启端口、备用服务器和技术人员访问。另一种是管理的：客户门户、计费、账户状态、支持工单、域名控制、DNS、电子邮件和备份流程。

公开产品并未告诉买方哪些依赖位于同一个故障域。客户可以购买一个网页托管套餐，其网站、电子邮件、备份、DNS 和工单访问都依赖相同的提供商系统。经销商可能依赖 Medyabim 的控制面板和电子邮件系统，即使最终客户只看到经销商品牌。专用服务器买家可能有远程重启，但如果机器无法 POST、磁盘控制器故障或防火墙策略阻止恢复访问，仍然需要技术人员。主机托管客户可以拥有服务器，但仍然依赖 Medyabim 的建筑、电力、上行链路、防火墙和支持响应。

这就是为什么已安装容量不够。关于页面声称超过 500 台服务器，数据中心页面声称 50 Gbit/s 出站容量，描述了一个可能的规模。可恢复容量询问当电力馈线、UPS 路径、交换机、防火墙、上行链路、认证路径或支持渠道消失时会发生什么。公共页面没有回答这个问题。

Medyabim 自己的 DNS 表面指向 AS44922 之外

最具揭示性的检查之一是 Medyabim 自己的域名。针对 medyabim.com.tr 的公共 DNS 查询显示，顶点和 www 名称解析到 185.7.83.213，mail.medyabim.com.tr 也解析到 185.7.83.213，名称服务器是 ns1.medyabim.com 和 ns2.medyabim.com，并且 SPF 记录引用 37.247.112.0/24 和 185.7.83.0/24。这些 DNS 事实必须被视为运营相关证据，因为它们显示了 Medyabim 如何向互联网展示自己的服务表面。

然后 RIPEstat 改变了解释。185.7.83.0/24 的前缀概览显示该前缀由 AS58212 宣告，而185.7.83.0/24 的路由状态端点列出了当前 origin AS58212，同时指出该前缀在 2012 年首次从 AS44922 看到，最近在验证快照时从 AS58212 看到。AS58212 的 RIPEstat AS 概览将该 origin 识别为 DATAFOREST dataforest GmbH。类似地，37.247.112.0/24 的前缀概览显示当前 origin AS29141，其AS29141 的 AS 概览将其识别为 Bradler & Krantz GmbH & Co. KG。

这并不意味着 Medyabim 歪曲了其服务。地址空间可能被分配、租用、迁移、由传输提供商路由、在国外托管或用于遗留服务。针对 Medyabim 的 RIPE 搜索结果显示了几个以 Medyabim 标记的地址块，包括 37.247.115.0/24、37.247.118.0/24、185.7.82.0/24 和 185.7.83.0/24，其中一些当前被公共路由归于其他 origin ASN。正确的结论不是丑闻；而是依赖映射。

如果 Medyabim 的网络、电子邮件或 DNS 表面依赖于当前由其他网络宣告的前缀，那么客户需要知道他们的服务的哪些部分在 AS44922 上，哪些部分在外部起源的地址空间上，以及哪些部分在国外。这对于故障分析很重要。如果 AS44922 出现问题，Medyabim 的公共网站或支持电子邮件可能仍通过另一个提供商可达。如果外部起源路径出现问题，即使布尔萨的 AS44922 路由保持在线，Medyabim 品牌表面也可能失败。如果客户购买“土耳其”安置，但支持、备份、DNS 或电子邮件依赖位于其他地方，客户需要在服务设计中标记该点。

更广泛的观点是 DNS 和 BGP 讲述不同的故事。品牌域名可以在线，而 AS 边缘狭窄。RIPE 持有者可以拥有当前未由其自己的 ASN 宣告的已分配地址范围。提供商可以在销售托管的同时，依赖第三方路由起源用于其自身堆栈的部分。这些都不是否定性的。所有都意味着故障分析必须精确。

PeeringDB 的沉默很重要，因为网站列出了许多路径

PeeringDB 是一个自愿目录，因此缺乏网络实体并不证明网络缺乏互联。但它对 Medyabim 很重要，因为官方数据中心页面列出了许多连接关系和一个 50 Gbit/s 的总出站容量声明。针对 ASN 44922 的 PeeringDB API 查询在搜索时未返回网络实体。这移除了一个公共来源，否则可能显示交换存在、设施存在、对等策略、流量比例、信息前缀和自行声明的互联位置。

如果没有 PeeringDB 配置文件，买家只能依靠 RIPE/RDAP 记录、RIPEstat BGP 观察、Medyabim 自己的页面、DNS 和合同语言。这是可行的，但不足以证明多样化的运营商对接机房接入。公共 BGP 显示 AS16276 为当前观察到的邻居。Medyabim 的数据中心页面列出了 Türk Telekom、Superonline、Level3、Tinet、Lambdanet、Cogent、AMS-IX 和 ECIX Duesseldorf。本文无法仅从公共证据将这些层协调成当前的物理拓扑。

正确的采购问题不是每个命名提供商是否都是假的。而是当前生产服务是否拥有多于一个独立配置的路径，以及这些路径是否真正多样化。是否存在多个付费传输提供商活跃于客户服务，还是只有一个可见的上游？一些命名是否已过时？一些路由是否通过上游提供商、经销商或远程互联交付？布尔萨设施是否有多样化的光纤入口？土耳其和欧洲路径是否物理分离？在中断期间，幸存路径可以承载多少流量？防火墙路径是否冗余，重启端口路径是否独立于客户生产路由？

公共证据无法回答这些问题。它可以识别需要提出这些问题的必要性。50 Gbit/s 的声明是一个容量假设，直到有当前端口、合同、利用率和故障转移空间的证据。命名的提供商徽标或文本不等同于路由多样性。一个观察到的 AS 邻居并非单宿主的证明，但足以要求直接确认。

服务合同将风险转移给客户

Medyabim 的服务合同很重要，因为它显示了公共技术承诺如何与合同风险相遇。合同说 Medyabim 将在付款和接受后提供订购的服务，但同时也将账户凭据、托管内容、法律合规、税收和服务使用的责任置于客户身上。对弹性更重要的是，它说除非合同文本中另有说明，客户的备份和数据存储义务属于客户，同时又说 Medyabim 定期备份和维护客户数据，但对服务中断或数据丢失引起的错误、损失或损害不负责。

这种组合在托管合同中很常见，但后果严重。公共托管页面可能宣传自动每周和每月备份、可选备份服务、流量报告和管理支持。如果客户未购买或配置正确的备份和恢复流程，服务合同仍可能限制提供商的责任。因此，客户应询问确切的备份范围、保留期、恢复测试、恢复时间、备份隔离以及备份是否位于同一设施、提供商网络、账户控制平面或故障域内。

同一合同赋予 Medyabim 因支付问题、非法内容、垃圾邮件和其他违约行为而暂停服务的权利。这对于保护其网络的托管提供商来说是预期的。这也意味着服务连续性依赖于行政状态以及物理系统。即使机架和路由健康，客户也可能因不付款、滥用处理、垃圾邮件事件、账户锁定、凭据丢失或支持争议而失去服务。对于关键工作负载，计费、滥用联系人和升级程序是运营控制，而非行政细节。

Medyabim 的支持系统帮助页面和在线帮助页面显示了基于工单的支持姿态。数据中心页面说电话支持在工作时间（09:00 至 18:00）可用，在这些时间之外，客户可以通过 7x24 工单和电子邮件支持系统联系提供商。主机托管页面说在 Medyabim 数据中心拥有服务器的企业可以享受 7x24 企业支持。在客户信任该服务之前，这些陈述应转化为事件处理程序：谁可以打电话，谁可以开紧急工单，是否有工作时间外的电话升级，以及提供商如何区分重启、网络、硬件、防火墙、DNS 和滥用事件。

电力和冷却是最主要的公共盲点

本次外联的任务是数据中心基础设施审查，主要的物理依赖是电力、冷却、光纤对接机房接入、设施运营和当地许可。Medyabim 的公共页面提供了一些设施类型的声明，但不足以支持高弹性置信度评级。关于页面说公司用自有资源在布尔萨建立了一个数据中心，容量超过 500 台服务器。数据中心页面说硬件在 Medyabim 机架中准备就绪，公司使用自己的服务器硬件。主机托管页面说服务器位于防火墙之后，有流量统计，并接收免费重启端口。

这些陈述仍然使物理设施几乎未被观察。没有双路电力输入的公开声明。没有公布的 UPS 拓扑或电池运行时间。没有发电机数量、燃料容量或加油合同。没有冷却冗余设计。没有烟雾、消防或漏水检测的细节。没有楼层平面图或设施认证。没有关于多样化光纤入口或对接机房设计的声明。没有区分计划内、紧急和客户请求工作的维护窗口政策。没有公开的事件历史显示测量的恢复。

对于布尔萨的一个小型提供商来说，其中一些沉默是可以理解的。发布太多设施细节可能会造成安全风险。较小的运营商也可能依赖上游设施、租赁空间、办公室级电力安排或混合的本地和海外服务器放置。但客户的风险仍然相同。超过 500 台服务器容量的声明不等同于在配电路径故障后仍可用的可用电力容量。高可用性声明不等同于经过测试的发电机运行时间。重启端口不能替代远程控制台访问、备用磁盘、热插拔程序或技术人员可用性。

实际测试是区分四种容量。已安装容量是提供商建设或声称可以托管的容量。已销售容量是客户已经使用的容量。可用容量是正常负载、热限制、电力预留、维护和超额订阅后剩余的容量。可恢复容量是组件故障后剩余的容量。公共页面通常描述已安装容量。客户需要可用和可恢复容量。

Medyabim 当前的公共证据无法解决这个问题。它只能设定证据需求：电力图、UPS 和发电机运行时间、冷却设计、机架密度政策、消防和水控、运营商入口多样性、维护历史、远程操作程序、备件政策以及至少一个记录的故障转移或恢复演练。

Medyabim 失败时谁受影响

受影响的用户不仅仅是 Medyabim 的直接账户持有者。一个销售域名、托管、经销商套餐、VDS、专用服务器、主机托管、电子邮件存储和备份的提供商可能会发现自己处于众多下游服务之下。一个经销商套餐可以支持数十或数百个小型网站，其所有者可能不知道 Medyabim 的存在。一台专用服务器可以承载企业应用、数据库、机构作品集、电子邮件服务或在线商店。一个主机托管客户可以拥有硬件，但依赖 Medyabim 提供电力、机架访问、防火墙路径、流量监控和重启控制。

故障路径也不是一维的。即使上游路由健康，电力事件也可能停止服务器。冷却事件可能强制关闭或减少允许的机架密度。单个防火墙故障可能同时隔离许多客户。单个上游提供商故障可能影响 AS44922，如果对相关前缀没有替代路径处于活动状态。即使设施完好，支持或工单故障也可能减慢恢复速度。在外部起源地址空间上的 DNS 或电子邮件故障可能使 Medyabim 更难联系，而其他地方的生产流量仍在工作。合同或滥用暂停可能在没有物理故障的情况下取消服务。

这就是 DNS 发现重要的原因。如果公共品牌域名和电子邮件服务使用 185.7.83.213，该前缀当前由 DATAFOREST 宣告，而 SPF 引用当前由 Bradler & Krantz 宣告的 37.247.112.0/24 前缀，那么客户不应假设“Medyabim 网络”意味着一个 AS、一个城市、一个设施或一个司法管辖区。该服务可能更具弹性，因为某些组件位于 AS44922 之外。也可能更复杂，因为事件所有权跨越提供商边界。

需要答案的人是采购团队、网页代理、经销商运营商、小企业主、系统管理员、合规官和事件响应者。他们需要知道 Medyabim 托管的服务是否有第二条路径、最近的恢复测试、带外支持渠道、当前备份、域名转移访问、DNS 导出、电子邮件连续性和路由起源授权。这些问题并不敌对。它们是将托管关系转变为能够承受糟糕日子的基础设施依赖所需的最低工作量。

客户应要求 Medyabim 证明什么

首先，要求提供当前网络图。它应标识 AS44922、37.247.116.0/24、任何预留或休眠的 AS44922 前缀如 37.247.117.0/24、2a03:400::/32 或更广泛分配的 IPv6 计划，以及在 AS29141、AS58212 或其他 origin 下路由的任何客户服务。它应标识 AS16276 是否是 AS44922 路由的唯一活跃上游提供商，是否有其他提供商通过私有或未观察到的协议活跃，以及数据中心页面上的提供商名称是否当前、历史、间接或特定于产品。

其次，要求提供设施弹性。答案应包括电力输入、UPS 设计、电池运行时间、发电机运行时间、冷却冗余、机架密度限制、物理安全、消防和水控、维护窗口、远程操作可用性、备件政策，以及 99% 托管连续性声明实际涵盖的内容。如果服务在布尔萨，询问存在哪些建筑和公用事业依赖。如果服务在国外，询问哪个国家、哪个设施、哪个提供商以及适用的法律条件。

第三，要求提供客户级别的故障转移证据。Medyabim 应能够展示当上游提供商故障、防火墙故障、服务器断电、磁盘故障、客户无法访问门户、支持队列繁忙、账户被标记为滥用或客户需要紧急迁移时会发生什么。公共页面提到流量监控、备份、重启端口和工单。买家需要知道这些工具在中断期间的行为。

第四，要求提供数据和退出控制。托管页面提到自动每周和每月备份、可选备份、电子邮件备份产品和服务器备份服务。服务合同限制 Medyabim 对服务中断和数据丢失的责任，除非合同另有说明。客户应要求恢复测试、备份范围、保留期、异地状态、加密、访问控制、导出流程、域名转移流程、DNS 导出和电子邮件连续性。

第五，要求证明当常用网站或电子邮件不可用时可以联系支持。联系页面提供电话号码和电子邮件。数据中心页面描述工作时间内的电话支持和工作时间外的工单/电子邮件支持。关键客户应要求指定的紧急升级、经过身份验证的联系人、带外电话程序，以及无需仅依赖常规门户即可授权远程操作的方式。

合理的证据包不必透露敏感楼层平面图。Medyabim 可以提供客户特定的附录，说明哪个设施服务工作负载、使用哪些前缀和 origin ASN、哪些 DNS 和电子邮件服务在起作用、哪些上游提供商活跃、哪些组件是单点故障、以及哪些服务在土耳其境外。它可以提供经过编辑的单线图，区分客户服务器、共享防火墙、重启控制器、备份目标、支持门户、权威 DNS 和公共网站。它还可以提供发电机测试、UPS 维护、冷却维护、上游故障转移测试、备份恢复测试和路由起源更改的最近日期。这些工件将回答运营问题，而不会暴露客户名称或敏感安全配置。

同一附录应区分标准托管与主机托管和专用服务器。在共享托管中，买家依赖 Medyabim 的平台选择和备份政策。在经销商托管中，下游客户可能依赖 Medyabim，即使他们从另一个品牌购买。对于专用服务器，买家可以控制操作系统，但无法控制机架、路由器、电力路径或备件。在主机托管中，买家可以拥有服务器，但仍然依赖 Medyabim 的建筑、电力、支持接入和网络边缘。这些差异决定了在中断期间谁首先行动。

证据评级

Medyabim 在公共网络证据方面获得中等评级，设施和弹性证据方面有所降级。身份层对于一个较小的提供商来说是可靠的：RIPE RDAP 和 RIPE 组织记录将 AS44922 和 ORG-MIH2-RIPE 与 Emre Erim（以 Medyabim 数据中心 名义经营）关联起来，布尔萨地址与 Medyabim 的联系页面匹配。当前的 AS44922 路由层也是真实的：RIPEstat 将该 AS 标记为已宣告，列出 37.247.116.0/24 为当前，显示验证快照时完全的 IPv4 RIS 可见性，并在 RPKI 下验证该路由。

评级不能为高，因为运营证据在此后立即变薄。RIPEstat 显示仅一个当前 IPv4 /24，无当前 IPv6 宣告，且只有一个观察到的 AS44922 邻居。PeeringDB 未返回 AS44922 的网络实体。RIPEstat 一致性视图显示了一个当前不在 BGP 中的 IPv4 路由条目和一个 IPv6 route6 条目。Medyabim 自己的 DNS 表面指向当前由其他网络宣告的地址空间。Medyabim 的官方页面发布有益的服务声明，但未发布在压力下信任所营销的数据中心容量所需的电力、冷却、运营商对接、维护和故障转移证据。

实际结论并非拒绝 Medyabim。证据支持一个真实的布尔萨托管和数据中心运营商，拥有长期的 RIPE 记录、可见的 AS 边缘、官方服务页面和具体的产品。结论也不是接受超过 500 台服务器和 50 Gbit/s 的声明作为弹性的证明。客户应将这些声明视为需要通过当前运营商图、设施证据、前缀映射、RPKI 检查、恢复测试和合同特定的支持程序来验证的假设。

Medyabim 的公共足迹在其命名身份、服务和当前路由方面最强。在客户最需要中断期间证据的地方最弱：电力输入、冷却、物理光纤多样性、活跃运营商冗余、当前 IPv6、支持升级、备份、退出和经过测试的恢复。这正是关键工作负载放置在该品牌背后之前应集中进行尽职调查的地方。