02 Emre Erim trading as Medyabim 数据中心 必须证明其商用数据中心容量能否在电力与连接限制下存活

摘要

• RIPE NCC 的公共记录赋予 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 的路由来源安全。RIPEstat 对经由 AS44922 的 37.247.116.0/24 的 RPKI 验证返回有效，有一条 ROA 授权 AS44922 且最大长度为 /24。
• Medyabim 自身的页面营销的运营规模超过了当前 AS44922 路由面所能证明的。数据中心页面声称有专用的就绪硬件在 Medyabim 机架中，对 Linux DirectAdmin 服务器有长期经验，提供土耳其和海外的服务器选项，总出口容量达 50 Gbit/s，并提到诸如 Turk Telekom 和 Superonline 等供应商路径，以及客户流量监控。主机托管页面声称提供 99% 的带带宽服务连续性、7×24 支持、防火墙后部署、免费重启端口和五个 IP 地址。
• 公共保证仍然不完整。官方页面并未公布双路供电、发电机续航、冷却拓扑、灭火措施、运营商交联室、维护窗口、可衡量的故障切换结果、设施认证或当前的 PeeringDB 互联概况。Medyabim 自己的域名解析至 185.7.83.213，而 RIPEstat 显示 185.7.83.0/24 当前由 DATAFOREST 而非 AS44922 通告，因此客户侧的依赖关系图必须区分 Medyabim 品牌、其 AS44922 节点、已分配的地址空间以及由第三方通告的服务面。

有用的核心问题不在于 Medyabim 是否存在

有一类区域托管服务商，其首要任务是证明自己不仅仅是目录中的一行字。Medyabim 并没有那么脆弱。公共注册记录包含具名自然人、商业名称、RIPE 组织注册记录、一个自治系统、已分配的地址资源、官方服务页面、位于布尔萨的联系地址以及可运营的产品供应。问题则不同：公共注册记录证明了身份和一个有限的路由端点，而公司的营销语言则要求客户相信一个更宏大的数据中心容量叙事。

最可靠的身份来源是 RIPE NCC。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，以及电话号码和公共电子邮件地址[email protected]。该地址与 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。RIPEstat 对 AS16276 的 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 导入/导出对等方 AS9121 和 AS53667 未在 BGP 中看到，而 AS16276 在 BGP 中可见但不在 whois 导入/导出策略中。这在较旧的路由记录中属于正常漂移，但这正是客户应当索取当前拓扑图，而不是依赖注册策略历史文本的原因。

正面的控制是 RPKI。当前 AS44922 路由 37.247.116.0/24 通过了RIPEstat 的 RPKI 验证校验，结果为有效。这很重要，因为路由来源授权是托管买家无需查看设施内部文件即可验证的少数公共控制之一。一条有效的 ROA 并不能证明供电、冷却或故障切换。它表明当前可见的 AS44922 来源并未被视为公共验证层中未知的路由来源声明。

因此，关于路由的结论是狭窄但有用的。AS44922 是真实的。其当前可见的 IPv4 路由根据 RPKI 是有效的。其观察到的上游面很薄弱。其 IPv6 证据目前未被通告。其公开路由策略记录不足以证明运营商多样性或故障切换。客户不应将其视为幽灵网络，也不应视为经过验证的弹性数据中心网络。

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

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

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

休眠 IPv4 前缀的情形也同样复杂。37.247.117.0/24 的 RIPE 搜索结果显示 NET-MEDYABIM-DC5 和一条 RIPE 路由条目，来源 AS44922，创建于 2025 年 6 月。然而，RIPEstat 的一致性检查未在当前 BGP 中看到它。这可能代表预留容量、计划中的迁移、最近撤回的路由、备用地址范围或仅仅是未使用的地址空间。公共证据无法确定这些解释中的哪一个成立。

重要的区别在于已分配容量与运营容量之间。一个 RIPE 分配、路由条目或地址分配可能显示出行政控制或准备状态。但这并不能证明该地址范围今天正在服务客户、可以通过多个运营商到达，或者可以在故障期间激活。需要可恢复容量的买家应询问 Medyabim 哪些前缀在生产中，哪些是保留的，哪些迁移到了其他来源，哪些是面向客户的，哪些是管理保留的，以及哪些受经过测试的 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。它表示专用服务器客户可以进入网络管理面板，7×24 小时监控自己的流量，并称数据中心使用 Foundry Networks 和 HP Procurve 网络硬件。

这是一个有用的证据，但应将其解读为公司发布的营销和运营文本，而非实时的运营商审计。该页面并未披露所列供应商中哪些是当前的物理运营商，哪些是转接提供商，哪些是对等或路由关系，哪些是历史上的转接选项，哪些支持土耳其服务，哪些支持海外部署。它没有展示设施内的交联室、多样化的光纤入口、互连地图或实时端口清单。检查时的公共 BGP 仅显示一个观察到的 AS44922 邻居，而非页面上所有供应商名称的可见公共地图。

在设施工程方面，该页面更为薄弱。它没有公布双路供电、UPS 容量、电池续航、发电机燃油续航、冷却冗余度、灭火等级、地面承重、机架密度、物理安全层级、维护窗口规则或灾难恢复演练。这些遗漏并不证明这些控制不存在。许多小型提供商并不公布此类细节。但评估数据中心恢复力的客户不应仅凭“数据中心”一词就假设这些控制存在。

Medyabim 的主机托管页面增加了面向客户的运营声明。它称 Medyabim 为其主机托管服务提供 99% 的可用性或带带宽的服务连续性保证；称拥有 Medyabim 数据中心内服务器的企业可获得 7×24 的企业支持；称流量统计数据可以在线查看；称服务器部署在防火墙之后；称将分配免费的远程重启端口；称分配的连接是专用且不限量的；并称为数据中心内的服务器免费分配五个 IP 地址。

这些是真实的服务声明，它们明确了买家在依赖服务之前应提出的问题。99% 的服务连续性承诺与现代高可用性 SLA 不是一回事，99% 仍可能在一年内允许相当长的停机时间。远程重启端口只有在电力分配、远程访问、控制台凭证和支持流程在事故中存活下来时才有用。放置在防火墙之后可以保护客户，但也可能成为共享瓶颈。五个 IP 地址对于简单托管可能足够，但这并未说明可路由子网的便携性或故障切换。该页面为客户提供了提问的要点，而非完整的恢复力证明。

官方网站证明供应范围，而非可恢复容量

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

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

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

公开的供应方案并未告知买家哪些依赖位于同一故障域内。客户可能购买一个网页托管套餐，其网站、邮件、备份、DNS 和工单访问都依赖提供商的同一套系统。经销商可能依赖 Medyabim 的控制面板和邮件系统，即使最终客户只看到经销商品牌。专用服务器买家可能拥有远程重启，但如果机器无法完成开机自检、磁盘控制器故障或防火墙策略阻止恢复访问，仍需要技术人员。主机托管客户可能拥有服务器，但仍依赖 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 的路由状态端点列出了当前的源 AS58212，同时指出该前缀在 2012 年首次从 AS44922 被看到，而在检查时最后一次看到是从 AS58212。RIPEstat 对 AS58212 的 AS 概览将该源识别为 DATAFOREST dataforest GmbH。同样，37.247.112.0/24 的前缀概览显示当前源为 AS29141，其AS29141 的概览识别为 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，其中一些根据公共路由当前归属于其他源 ASN。正确的结论并非丑闻，而是绘制依赖关系图。

如果 Medyabim 的 Web、邮件或 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 的数据中心页面提到 Turk Telekom、Superonline、Level3、Tinet、Lambdanet、Cogent、AMS-IX 和 ECIX Duesseldorf。仅凭公开证据，本文无法将这些层次调和为当前的物理拓扑。

正确的采购问题不在于每个列出的供应商是否虚假。而在于当前的生产服务是否拥有多于一条独立配置的路径，以及这些路径是否以相关方式实现了多样化。客户服务是否有多个活跃的付费转接提供商，还是只有一个可见的上游？列出的某些名字是否是历史上的？某些路由是否通过上游提供商、经销商或远程互连交付？布尔萨设施是否有多样化的光纤入口？土耳其路径和欧洲路径是否物理分离？存活路径在故障期间能承载多少流量？防火墙路径是否冗余，远程重启端口路径是否独立于客户生产路由？

公开证据无法回答这些问题，但能识别出提出这些问题的必要性。50 Gbit/s 的声明只是一个容量假设，除非有证据表明当前端口、合同、利用余量和故障切换能力。具名供应商的徽标或文本并不等同于路由多样性。观察到的单一 AS 邻居并不一定是单一连接的证据，但足以要求直接确认。

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

Medyabim 的服务合同很重要，因为它显示了公开的技术承诺如何与合同风险相互作用。合同规定，Medyabim 将在付款和接受后提供所订购的服务，但同时将账户凭据、托管内容、法律合规、税费和服务使用的责任归于客户。对于恢复力更为重要的是，合同表示客户的备份和数据存储义务属于客户，除非合同正文另有约定，同时又称 Medyabim 定期备份和维护客户数据，但对服务中断或数据丢失导致的错误、损失或损害不承担责任。

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

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

Medyabim 的支持系统帮助页面和在线帮助页面显示一种以工单为导向的支持姿态。数据中心页面称，电话支持在办公时间（09:00 至 18:00）可用，非办公时间客户可通过 7×24 支持系统以工单和邮件联系提供商。主机托管页面称，拥有 Medyabim 数据中心内服务器的企业可获得 7×24 的企业支持。在客户信任该服务之前，这些声明应转化为事件程序：谁可以打电话，谁可以开启紧急工单，是否有非工作时间电话升级，以及提供商如何区分重启、网络、硬件、防火墙、DNS 和滥用事件。

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

本次任务是对该企业数据中心基础设施的审视，而主要的物理依赖是供电、冷却、光纤交联室接入、设施运营和当地许可。Medyabim 的公开页面给出了一些类似设施的声明，但工程细节不足，无法支撑高恢复力信任评分。关于页面称，公司凭借自身资源在布尔萨建设了一座容量超过 500 台服务器的数据中心。数据中心页面称，硬件在 Medyabim 机架中就绪，公司使用自己的服务器硬件。主机托管页面称，服务器位于防火墙后，有流量统计，并获得免费重启端口。

这些声明使得物理设施几乎仍不可见。没有公开的双路供电声明。没有发布 UPS 拓扑或电池续航时间。没有发电机数量、燃油容量或加油合同。没有冷却冗余设计。没有关于烟感、灭火或漏水检测的细节。没有设施楼层平面图或认证。没有关于多样化光纤入口或交联室设计的声明。没有区分计划性、紧急和客户要求工作的维护窗口政策。没有公开的事件历史记录显示可衡量的恢复情况。

对于布尔萨的一家小型提供商而言，这种沉默在一定程度上是可以理解的。公布过多设施细节可能带来安全风险。小型运营商也可能依赖上游设施、租用空间、办公室电力安排，或将服务器混合部署在本地和海外。但客户面临的风险依然不变。声称“超过 500 台服务器容量”并不等同于在某个供电路径故障后可用的供电容量。声称“高可用性”并不等同于经过测试的发电机续航。“重启端口”不能替代远程控制台访问、备件硬盘、热插拔流程或技术人员的可用性。

实际的检验在于区分四种容量。已安装容量是提供商已建成或声称能够托管的容量。已售出容量是客户已经使用的容量。可用容量是在正常负载、热限制、电力预留、维护和超额认购之后剩余的容量。可恢复容量是在某个组件故障后剩余的容量。公开页面通常描述的是已安装容量。客户需要的是可用容量和可恢复容量。

Medyabim 目前的公开证据无法解决这一问题。它们只能确定所需的证据：电气单线图、UPS 和发电机续航、冷却设计、机架密度政策、消防和漏水控制、运营商入口多样性、维护历史、远程操作程序、备件政策，以及至少一次记录在案的故障切换或恢复演练。

Medyabim 发生故障时谁受影响

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

故障路径也不是单一维度的。即使上游路由完好，供电事件也可能关闭服务器。冷却事件可能迫使停机或降低允许的机架密度。防火墙故障可能同时隔离众多客户。如果受影响前缀没有活跃的替代路径，单一上游提供商故障就可能影响 AS44922。支持或工单故障可能延缓恢复，即使设施完好。外部源地址空间上的 DNS 或邮件故障可能使 Medyabim 更难联系，而其他地方的生产流量仍在运行。合同或滥用暂停可能在没有物理故障的情况下移除服务。

这就是为什么 DNS 发现很重要。如果公共品牌域名和邮件服务使用当前由 DATAFOREST 通告前缀下的 185.7.83.213，且 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 或其他源路由的客户服务。它应表明 AS16276 是否是 AS44922 路由的唯一活跃上游提供商，其他提供商是否通过私有或未观察到的协议活跃，以及数据中心页面上列出的供应商名称是当前的、历史的、间接的还是特定于产品的。

第二，询问设施恢复力。答复应包括供电输入、UPS 设计、电池续航、发电机续航、冷却冗余、机架密度限制、物理安全、消防和漏水控制、维护窗口、远程操作可用性、备件政策，以及 99% 主机托管连续性声称实际涵盖的内容。如果服务在布尔萨，询问建筑和公用事业依赖关系。如果服务在海外，询问适用的国家、设施、提供商和法律条件。

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

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

第五，要求在常规网站或邮件不可用时仍能联系到支持的证明。联系页面提供了电话号码和电子邮件。数据中心页面描述了办公时间的电话支持和非办公时间的工单/邮件支持。关键客户应要求提供具名的紧急升级联系人、经过验证的联系人、带外电话流程，以及在不完全依赖普通门户的情况下授权远程操作的方式。

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

同一附件应区分标准托管、主机托管和专用服务器。在共享托管中，买家依赖 Medyabim 的平台选择和备份政策。在经销商托管中，下游客户即使从其他品牌购买，也可能依赖 Medyabim。对于专用服务器，买家可以控制操作系统，但无法控制机架、路由器、供电路径或备件。在主机托管中，买家可能拥有服务器，但仍依赖 Medyabim 的机房、供电、支持访问和网络端点。这些差异决定了在故障期间谁首先采取行动。

证据评分

Medyabim 的公共网络证据评分为中等，设施和恢复力证据方面被降级。对于一家小型提供商而言，身份层是坚实的：RIPE RDAP 和组织注册记录将 AS44922 和 ORG-MIH2-RIPE 与以 Medyabim 数据中心 名义经营的 Emre Erim 联系起来，布尔萨地址与 Medyabim 的联系页面相符。当前的 AS44922 路由层也是真实的：RIPEstat 标记该 AS 为已通告，列出 37.247.116.0/24 为当前前缀，在检查快照中显示完整的 RIS IPv4 可见性，并在 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、支持升级、备份、退出和经过测试的恢复。这正是关键工作负载置于该品牌之前，尽职调查应重点关注的领域。