02 Emre Erim trading as Medyabim Дата-центр должен доказать, что заявленная мощность дата-центра выдержит ограничения по электропитанию и связности

Кратко

• Публичные записи RIPE дают Medyabim согласованную юридическую и сетевую идентичность. ЗаписьRDAP RIPE для AS44922называет MEDYABIM-AS, указывает Emre Erim административным и техническим контактом и включает ORG-MIH2-RIPE с наименованием «Emre Erim trading as Medyabim Дата-центр»; записьорганизации в RIPEдаёт страну TR, статус LIR, адрес в Бурсе и контактные данные.
• Текущая маршрутная поверхность реальна, но узка.Обзор AS в RIPEstatпометил AS44922 как анонсируемый, астатус маршрутизациипоказал на момент проверки один IPv4-префикс, ни одного IPv6-префикса, 256 IPv4-адресов и одного наблюдаемого соседа.Список анонсируемых префиксовуказал только 37.247.116.0/24 как текущий.
• Самый сильный позитивный контроль — защита источника маршрута для этого текущего /24.Проверка RPKI для 37.247.116.0/24 через AS44922вернула статус valid, с ROA, разрешающим AS44922 и максимальную длину /24.
• Собственные страницы Medyabim рекламируют более широкую операционную зону, чем доказывает текущая маршрутная поверхность AS44922.Страница дата-центраобещает готовое выделенное оборудование в стойках Medyabim, многолетний опыт с DirectAdmin/Linux-серверами, варианты серверов в Турции и за рубежом, общую исходящую мощность 50 Гбит/с, называет такие пути провайдеров, как Turk Telekom и Superonline, а также мониторинг трафика клиентов.Страница colocationобещает 99% непрерывности услуги с полосой пропускания, поддержку 24/7, размещение за межсетевым экраном, бесплатный порт перезагрузки и пять IP-адресов.
• Публичные гарантии остаются неполными. Официальные страницы не публикуют два ввода от энергосетей, время работы генераторов, топологию охлаждения, пожаротушение, meet-me-комнаты операторов связи, окна обслуживания, измеренные результаты переключения при сбое, сертификацию объекта или актуальный профиль межсоединений в PeeringDB. Домен самого Medyabim резолвится в 185.7.83.213, тогда как RIPEstat показывает, что 185.7.83.0/24 сейчас анонсирует DATAFOREST, а не AS44922; поэтому карты зависимостей для клиентов должны разделять бренд Medyabim, его сетевой край AS44922, выделенное адресное пространство и сервисные поверхности, анонсируемые третьими сторонами.

Полезный вопрос не в том, существует ли Medyabim

Есть класс региональных хостинг-профилей, где первая задача — доказать, что компания — это не просто строка в каталоге. Medyabim не такой слабый случай. В открытых источниках есть названное физическое лицо, торговое наименование, запись организации в RIPE, автономная система, выделенные адресные ресурсы, официальные страницы услуг, контактный адрес в Бурсе и работающие продуктовые предложения. Проблема в другом: публичные данные доказывают идентичность и ограниченный сетевой край, а маркетинговый язык компании предлагает клиентам поверить в более масштабную историю о мощности дата-центра.

Самый сильный источник идентичности — RIPE.Запись RDAP для AS44922называет автономную систему MEDYABIM-AS и организацию «Emre Erim trading as Medyabim Дата-центр». Она также называет Emre Erim административным и техническим контактом, с адресом в Бурсе и номером телефона.REST-запись организации ORG-MIH2-RIPE в RIPEсодержит то же торговое наименование, страну TR, тип LIR, адрес в Бурсе, телефон, факс, ссылки на mnt-объекты Medyabim и дату создания в марте 2008 года. Это намного сильнее, чем запись из каталога хостинга.

Собственнаяконтактная страница Medyabimнезависимо закрепляет публичный операционный адрес. Она описывает «Medyabim Дата-центр ve Internet Hizmetleri» и указывает Kükürtlü Mahallesi, Oulu Caddesi, Oylum Sitesi F Blok Kat 3 No 13, Osmangazi, Bursa, с телефонами и публичным адресом электронной почты [email protected]. Этот адрес почти совпадает с адресом в RIPE. Это важно, потому что компания не представлена как безликий офшорный облачный бренд. Её публичные данные указывают на оператора из Бурсы, чьи записи о сетевых ресурсах и коммерческий сайт по крайней мере согласованы между собой.

Страница истории компании добавляет самоописание.Страница «О нас»говорит, что бизнес работает с 2000 года в сфере интернет-услуг, программных продуктов и Linux-систем «под ключ»; что позже он сосредоточился на регистрации доменов, веб-хостинге, выделенных серверах, управлении серверами и консалтинге; и что с 2006 года в Бурсе на собственные средства построен дата-центр ёмкостью более 500 серверов — для собственных серверов и серверов хостинговых компаний. Это не независимое доказательство установленных стоек или мощности электропитания, но это конкретное проверяемое операционное заявление.

Поэтому вопрос не в том, «есть ли Medyabim». Вопрос в том, «на какие части заявленной мощности Medyabim клиент может положиться, когда откажут электричество, охлаждение, маршрутизация, поддержка или вышестоящий провайдер?» Для покупателя дата-центра или colocation идентичность — лишь первый барьер. Более сложный тест — восстанавливаемая мощность: оборудование, питание в стойке, охлаждение, оптика, маршрутизация и человеческие процессы, которые остаются доступны при сбое.

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идентифицирует этого соседа как OVH SAS.

Это не значит, что у Medyabim всего 256 клиентов, одна стойка или одна услуга. Публичный BGP не видит приватные VLAN, стоки реселлеров, хостинг на адресах провайдера, инвентаризацию серверов, клиентские кросс-коннекты или внешние веб-поверхности. Но это значит, что видимый край AS44922 — не широкий мультипрефиксный, мультисоседский публичный магистральный узел на момент проверки. Если покупатель оценивает Medyabim как зависимость для дата-центра, публичная BGP-карта сама по себе не доказывает устойчивость к нескольким операторам.

Просмотр согласованности маршрутизации AS в RIPEstatделает разрыв нагляднее. Он показал 37.247.116.0/24 как присутствующий и в BGP, и в whois/IRR RIPE. Он также показал 37.247.117.0/24 и 2a03:400::/32 как присутствующие в whois/IRR, но не в BGP на момент проверки. Тот же просмотр показал старых пиров import/export AS9121 и AS53667, не наблюдаемых в BGP, при этом AS16276 наблюдался в BGP, но не в политике import/export в whois. Это обычный дрейф в старых маршрутных записях, но именно поэтому клиенту стоит просить актуальные схемы, а не полагаться на исторические тексты реестровой политики.

Позитивный контроль — RPKI. Текущий маршрут AS44922, 37.247.116.0/24, прошёлпроверку RPKI в RIPEstatсо статусом valid. Это важно, потому что авторизация источника маршрута — один из немногих публичных контролей, которые покупатель хостинга может проверить без доступа к приватным документам объекта. Действительный ROA не доказывает электричество, охлаждение или переключение при сбое. Он показывает, что видимый текущий источник AS44922 не оставлен как неизвестное заявление об источнике маршрута в публичном уровне валидации.

Вывод о маршрутах поэтому узок и полезен. AS44922 реален. Его текущий видимый IPv4-маршрут действителен по RPKI. Наблюдаемая поверхность вышестоящих провайдеров тонкая. Его IPv6-свидетельства сейчас не анонсируются. Публичных записей маршрутной политики недостаточно, чтобы доказать разнообразие операторов или переключение при сбое. Клиенту не стоит считать эту сеть призрачной, но и не стоит считать её доказанно устойчивой сетью дата-центра.

Данные по IPv6 и неактивным префиксам требуют понижения оценки

У Medyabim есть реестровые данные по IPv6.Поисковая запись RIPE для 2a03:400::/32показывает выделенный 2a03:400::/29 в TR-MEDYABIM-20110107 и запись route6 для 2a03:400::/32 с источником AS44922. Это звучит убедительно, пока не сравнить с текущей видимостью маршрутизации.

Обзор префикса 2a03:400::/32 в RIPEstatотметил префикс как не анонсируемый на момент проверки.Статус маршрутизациине показал текущих источников, ноль пиров RIS, видящих его, и последнее событие для AS44922 1 апреля 2026 года. Сам по себе это не вывод о провале. Некоторые клиенты могут не покупать IPv6; у некоторых операторов могут быть неактивные планы IPv6; некоторые блоки адресов держат на будущее. Но это меняет то, что можно доказать публично. Провайдера дата-центра, чьи актуальные официальные страницы продают хостинг и серверные услуги, но чей видимый сетевой край не имеет текущего объявления IPv6, стоит спросить, поддерживается ли IPv6, недоступен ли он, доступен ли выборочно или предоставляется через другого провайдера.

Картина неактивных IPv4-префиксов тоже смешанная.Результат поиска RIPE для 37.247.117.0/24показывает NET-MEDYABIM-DC5 и запись route RIPE с источником AS44922, созданную в июне 2025 года. Однако проверка согласованности в RIPEstat не увидела его в текущем BGP. Это может означать резервную мощность, планируемую миграцию, недавно отозванный маршрут, резервный диапазон или просто неиспользуемое адресное пространство. Публичные данные не могут выбрать одно из этих объяснений.

Важно различать выделенную мощность и рабочую мощность. Выделение RIPE, запись маршрута или назначение адреса могут показывать административный контроль или подготовку. Они не доказывают, что диапазон адресов обслуживает клиентов сегодня, что он достижим через несколько операторов или что его можно активировать при сбое. Покупателю, которому нужна восстанавливаемая мощность, стоит спросить Medyabim, какие префиксы являются рабочими, какие зарезервированы, какие переведены на другие источники, какие используются клиентами, какие только для управления и какие покрыты протестированными процессами DDoS, межсетевого экрана и RPKI.

Собственные страницы услуг Medyabim конкретны, но не публикуют устойчивость объекта

Страница дата-центра Medyabimподробнее, чем типичный хостинговый лендинг. В ней сказано, что модели выделенных серверов предоставляются после подтверждения оплаты и что оборудование готово в стойках Medyabim. Сказано, что у Medyabim более 15 лет опыта с Linux-выделенными серверами и что DirectAdmin активно используется с 2003 года. Сказано, что компания работает на собственном серверном оборудовании, размещённом в Турции, а услуги выделенных серверов можно выбрать в Турции или за рубежом в зависимости от спроса. Также описаны «высокая пропускная способность линий» и высокий аптайм как причина быстрого предоставления реального серверного оборудования.

Та же страница делает крупное заявление о связности. В ней сказано, что основные интернет-подключения дата-центра выбраны для быстрого доступа из Турции и мира, названы Türk Telekom, Superonline, Level3, Tinet, Lambdanet, Cogent Communications, AMS-IX и ECIX Duesseldorf, и указана общая исходящая мощность линий 50 000 Мбит, то есть 50 Гбит/с. Сказано, что клиенты выделенных серверов могут зайти в панель управления сетью и наблюдать свой трафик 24/7, и что в дата-центре используется сетевое оборудование Foundry Networks и HP Procurve.

Это полезные данные, но их нужно читать как опубликованный компанией маркетингово-операционный текст, а не как живой аудит операторов связи. Страница не раскрывает, какие из названных провайдеров являются текущими физическими операторами, какие апстримами, какие отношениями на биржах или по маршрутам, какие историческими транзитными вариантами, какие поддерживают турецкие услуги, а какие зарубежное размещение. Не показаны meet-me room объекта, разнообразные вводы оптики, карта кросс-коннектов или живой портовый инвентарь.

Публичный BGP на момент проверки показал одного наблюдаемого соседа AS44922, а не публичную карту всех названных на странице провайдеров.

Страница ещё скуднее по инженерным деталям объекта. В ней не публикуются два ввода от энергосетей, мощность ИБП, время работы батарей, автономность генераторов по топливу, резервирование охлаждения, класс пожаротушения, нагрузка на пол, плотность стоек, уровни физической безопасности, правила окон обслуживания или учения по восстановлению после аварий. Эти пропуски не доказывают, что таких мер нет. Многие небольшие провайдеры не публикуют такие детали. Но клиент, оценивающий устойчивость дата-центра, не должен предполагать наличие этих мер из одного слова «дата-центр».

Страница colocationдобавляет клиентоориентированные операционные заявления. В ней сказано, что Medyabim даёт гарантию 99% аптайма или непрерывности услуги с полосой пропускания для colocation; что компании с серверами в Medyabim Дата-центр могут получать корпоративную поддержку 24/7; что статистику трафика можно наблюдать онлайн; что серверы находятся за межсетевым экраном; что будет выделен бесплатный порт перезагрузки; что выделенное подключение является выделенным и не ограниченным; и что для серверов в дата-центре бесплатно выделяется пять IP-адресов.

Это реальные заявления об услугах, и они обостряют вопросы, которые покупатели должны задать до того, как положиться на услугу. Обещание 99% непрерывности — не то же самое, что современный SLA с высокой доступностью, и 99% всё ещё допускает ощутимый простой в течение года. Порт перезагрузки полезен только если распределение питания, удалённый доступ, учётные данные консоли и процедуры поддержки переживут инцидент. Межсетевой экран может защищать клиентов, но также может стать общей точкой отказа. Пяти IP-адресов может хватить для простого хостинга, но это ничего не говорит о переносимости маршрутизируемой подсети или переключении при сбое.

Страница даёт клиентам поводы для вопросов, а не полное доказательство устойчивости.

Официальный сайт доказывает широту предложения, а не восстанавливаемую мощность

Широта публичного предложения велика.Страница пакетов веб-хостинга Medyabimрекламирует пакеты хостинга с веб-пространством, трафиком, FTP, MySQL, веб-почтой, DirectAdmin, опциональным SSL, почтовыми продуктами резервирования, услугой дополнительных IP для серверов, услугой резервного копирования серверов на 300 ГБ, неограниченной FTP-передачей 24/7, автоматическим резервированием еженедельно и ежемесячно, расширенной статистикой, фильтрацией спама и отчётами о передаче данных.Страница реселлеровпредлагает реселлерские пакеты с веб-пространством, количеством POP3-ящиков, ежемесячным трафиком, количеством баз данных MySQL, турецкой панелью управления, веб-почтой, опциональным управлением DNS, вариантами SSL, антиспам-фильтрами и отчётами о трафике.

Страница VDSобъясняет виртуальные выделенные серверы как логически разделённые серверы на физическом оборудовании и перечисляет возможности пакетов VDS.Страница информации о панели управленияговорит, что DirectAdmin устанавливается на серверы, когда сервер находится в дата-центре Medyabim, описывает проактивное управление серверами, настройку безопасности и отслеживание спам-блэклистов, и говорит, что PHP, MySQL, Linux, ionCube и DirectAdmin устанавливаются и настраиваются на всех серверах.

Вместе эти страницы показывают, что Medyabim продаёт классический стек небольшого провайдера: домены, общий хостинг, реселлерский хостинг, VDS, выделенные серверы, colocation, почтовое хранение, SSL, резервное копирование и управляемую поддержку Linux/DirectAdmin. Такая смесь создаёт два вида зависимостей. Одна — физическая: стойки, питание, охлаждение, аплинки, межсетевые экраны, порты перезагрузки, запасные серверы и доступ техников. Другая — административная: клиентский портал, биллинг, состояние аккаунта, тикет-система поддержки, управление доменами, DNS, почта и процессы резервного копирования.

Публичное предложение не говорит покупателю, какие зависимости находятся в одной зоне отказа. Клиент может купить пакет веб-хостинга, где сайт, почта, резервные копии, DNS и доступ к тикетам зависят от одних и тех же систем провайдера. Реселлер может зависеть от панели управления и почтовых систем Medyabim, даже если конечные клиенты видят только бренд реселлера. Покупатель выделенного сервера может иметь удалённую перезагрузку, но всё равно нуждаться в технике, если машина не проходит POST, сломался дисковый контроллер или политика межсетевого экрана блокирует восстановительный доступ.

Клиент colocation может владеть сервером, но всё равно зависеть от здания, питания, апстрима, межсетевого экрана и реакции поддержки Medyabim.

Именно поэтому установленной мощности недостаточно. Заявление о ёмкости более 500 серверов на странице «О нас» и заявление об исходящей мощности 50 Гбит/с на странице дата-центра описывают возможный масштаб. Восстанавливаемая мощность спрашивает, что произойдёт после отказа одного ввода электросети, одного пути ИБП, одного коммутатора, одного межсетевого экрана, одного апстрима, одного пути аутентификации или одного канала поддержки. Публичные страницы на это не отвечают.

Собственная DNS-поверхность Medyabim указывает за пределы AS44922

Одна из самых показательных проверок — собственный домен Medyabim. Публичный DNS-запрос medyabim.com.tr показал, что apex и 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, отметив, что префикс впервые был замечен от AS44922 в 2012 году и в последний раз на момент проверки наблюдался от AS58212.Обзор AS58212 в RIPEstatидентифицирует этот источник как DATAFOREST dataforest GmbH. Аналогично,обзор префикса 37.247.112.0/24показал текущий источник AS29141, аобзор AS29141идентифицирует Bradler & Krantz GmbH & Co. KG.

Это не значит, что Medyabim искажает данные о своей услуге. Адресное пространство может быть выделено, арендовано, перенесено, маршрутизироваться апстримами, размещаться за рубежом или использоваться для старых сервисов. Результаты поиска RIPE по Medyabim показывают несколько помеченных Medyabim блоков адресов, включая 37.247.115.0/24, 37.247.118.0/24, 185.7.82.0/24 и 185.7.83.0/24, часть из которых публичная маршрутизация сейчас приписывает другим ASN. Правильный вывод — не скандал, а карта зависимостей.

Если собственные веб-, почтовые или DNS-поверхности Medyabim зависят от префиксов, которые сейчас анонсируют другие сети, клиентам нужно знать, какие части их услуги находятся на AS44922, какие на адресном пространстве внешних источников, а какие за рубежом. Это важно для анализа сбоев. Если у AS44922 проблемы, публичный сайт Medyabim или почта поддержки могут оставаться доступными через другого провайдера. Если проблема на внешнем пути, брендовая поверхность Medyabim может отказать, даже если маршрут AS44922 в Бурсе остаётся в строю.

Если клиент покупает размещение в «Турции», но поддержка, резервное копирование, DNS или почтовая зависимость находятся в другом месте, клиенту нужно, чтобы это было отражено в проекте услуги.

Более общая мысль: DNS и BGP рассказывают разные истории. Брендовый домен может быть онлайн, пока сетевой край узок. Держатель в RIPE может иметь выделенные диапазоны адресов, которые сейчас не анонсируются его собственной ASN. Провайдер может продавать хостинг, полагаясь на сторонние источники маршрутов для частей собственного стека. Ни один из этих фактов не дисквалифицирует компанию. Все они означают, что разбор сбоев должен быть точным.

Отсутствие данных в PeeringDB важно, потому что сайт называет много путей

PeeringDB — добровольный каталог, поэтому отсутствие сетевого объекта не доказывает, что у сети нет межсоединений. Тем не менее для Medyabim это важно, потому что официальная страница дата-центра называет много отношений связности и заявляет общую исходящую мощность 50 Гбит/с. ПубличныйAPI-запрос к PeeringDB для ASN 44922не вернул сетевой объект на момент исследования. Это убирает один публичный источник, который мог бы показать присутствие на биржах, присутствие в объектах, политику пиринга, соотношения трафика, информационные префиксы и самостоятельно заявленные точки межсоединений.

Без профиля PeeringDB покупатель остаётся с записями RIPE/RDAP, наблюдениями BGP в RIPEstat, собственными страницами Medyabim, DNS и текстом договора. Это работоспособно, но недостаточно, чтобы доказать разнообразный доступ к операторам в meet-me room. Публичный BGP показал AS16276 как наблюдаемого текущего соседа. Страница дата-центра Medyabim называет Turk Telekom, Superonline, Level3, Tinet, Lambdanet, Cogent, AMS-IX и ECIX Duesseldorf. Статья не может свести эти уровни в актуальную физическую топологию только по публичным данным.

Правильный закупочный вопрос — не является ли каждый названный провайдер ложным. Вопрос в том, есть ли у текущей боевой услуги больше одного независимо предоставленного пути и разнообразны ли эти пути в важных аспектах. Есть ли несколько платных транзитных провайдеров, активных для клиентской услуги, или только один видимый апстрим? Некоторые названия исторические? Некоторые маршруты доставляются через апстрим, реселлера или удалённое межсоединение? Есть ли в объекте в Бурсе разнообразные вводы оптики? Физически разделены ли турецкий и европейский пути? Какой трафик сможет пропустить выживший путь во время сбоя?

Избыточен ли путь межсетевого экрана и независим ли порт перезагрузки от клиентской боевой маршрутизации?

Публичные данные не могут ответить на эти вопросы. Они могут выявить потребность в них. Заявление о 50 Гбит/с — гипотеза о мощности, пока нет данных о текущих портах, контрактах, запасе по использованию и переключении при сбое. Логотипы или текст с именами провайдеров не эквивалентны разнообразию маршрутов. Один наблюдаемый AS-сосед — не доказательство одиночного подключения, но его достаточно, чтобы потребовать прямого подтверждения.

Договор обслуживания возвращает риск клиенту

Договор обслуживания Medyabimважен, потому что показывает, как публичные технические обещания встречаются с контрактным риском. Договор говорит, что Medyabim предоставит заказанные услуги после оплаты и принятия, но также возлагает на клиентов ответственность за учётные данные, размещаемый контент, соблюдение законодательства, налоги и использование услуг. Важнее для устойчивости: обязанности по резервному копированию и хранению данных клиента лежат на клиенте, если текст договора не говорит иное, при этом также сказано, что Medyabim регулярно создаёт резервные копии и поддерживает данные клиентов, но не несёт ответственности за ошибки, потери или ущерб, возникшие из-за перерывов в обслуживании или потери данных.

Такое сочетание обычно для хостинговых договоров, но оно имеет последствия. Публичные страницы хостинга могут рекламировать автоматические еженедельные и ежемесячные резервные копии, дополнительные услуги резервирования, отчёты о трафике и управляемую поддержку. Договор всё равно может ограничивать ответственность провайдера, если клиент не купил или не настроил правильный процесс резервирования и восстановления.

Поэтому клиенту стоит уточнить точный объём резервирования, срок хранения, тестирование восстановления, время восстановления, изоляцию резервных копий и то, находятся ли резервные копии в том же объекте, в той же сети провайдера, в той же плоскости управления аккаунтом или в той же зоне отказа.

Тот же договор даёт Medyabim право приостанавливать услуги при проблемах с оплатой, нелегальном контенте, спаме и других нарушениях договора. Это ожидаемо для хостинг-провайдера, защищающего свою сеть. Это также означает, что непрерывность услуги зависит от административного состояния, а не только от физических систем. Клиент может потерять услугу из-за неоплаты, разбора злоупотреблений, спам-инцидента, блокировки аккаунта, потери учётных данных или спора с поддержкой, даже когда стойки и маршруты здоровы.

Для критичных рабочих нагрузок биллинг, контакты по злоупотреблениям и процедуры эскалации — это операционные контроли, а не бэк-офисные детали.

Страница помощи по системе поддержкиистраница онлайн-помощипоказывают тикет-ориентированный подход к поддержке. Страница дата-центра говорит, что телефонная поддержка доступна в рабочие часы с 09:00 до 18:00, а вне этих часов клиенты могут обратиться к провайдеру через систему поддержки 24/7 по тикетам и почте. Страница colocation говорит, что компании с серверами в Medyabim Дата-центр могут получать корпоративную поддержку 24/7. Эти заявления стоит превратить в процедуры инцидентов до того, как клиент доверится услуге: кто может звонить, кто может открывать аварийные тикеты, существует ли телефонная эскалация вне часов и как провайдер различает инциденты перезагрузки, сети, оборудования, межсетевого экрана, DNS и злоупотреблений.

Электропитание и охлаждение — самые большие публичные слепые зоны

Задача по этой компании — инфраструктурная проверка дата-центра, и главная физическая зависимость — электричество, охлаждение, доступ к оптике в meet-me room, эксплуатация объекта и местные разрешения. Публичные страницы Medyabim дают некоторые похожие на объектные заявления, но недостаточно инженерных деталей для высокой уверенности в устойчивости. Страница «О нас» говорит, что компания построила в Бурсе дата-центр ёмкостью более 500 серверов на собственные средства. Страница дата-центра говорит, что оборудование готово в стойках Medyabim и что компания использует собственное серверное оборудование.

Страница colocation говорит, что серверы находятся за межсетевым экраном, имеют статистику трафика и получают бесплатный порт перезагрузки.

Эти заявления всё равно оставляют физическую инфраструктуру почти ненаблюдаемой. Нет публичного заявления о двух вводах от энергосетей. Нет опубликованной топологии ИБП или времени работы батарей. Нет количества генераторов, ёмкости топлива или контракта на заправку. Нет схемы резервирования охлаждения. Нет деталей о дымовых извещателях, пожаротушении или датчиках протечек воды. Нет плана объекта или сертификации. Нет заявления о разнообразных вводах оптики или конструкции meet-me room. Нет политики окон обслуживания, различающей плановые, аварийные и запрошенные клиентом работы. Нет публичной истории инцидентов с измеренным восстановлением.

Для небольшого провайдера в Бурсе часть этого молчания понятна. Публикация слишком многих деталей объекта может создать риск для безопасности. Небольшие операторы также могут полагаться на вышестоящие объекты, арендованные помещения, схемы питания в офисных зданиях или смешанное локальное и зарубежное размещение серверов. Но риск для клиента остаётся тем же. Заявление о «ёмкости более 500 серверов» не эквивалентно полезной мощности электропитания после отказа одного пути распределения. «Высокий аптайм» — не эквивалент протестированного времени работы генератора.

«Порт перезагрузки» — не замена удалённой консоли, запасных дисков, процедур горячей замены или доступности техника.

Практический тест — разделить четыре вида мощности. Установленная мощность — это то, что провайдер построил или говорит, что может разместить. Проданная мощность — это то, что уже используют клиенты. Полезная мощность — это то, что остаётся после обычной нагрузки, тепловых лимитов, резервов питания, обслуживания и оверсабскрипшена. Восстанавливаемая мощность — это то, что остаётся после отказа компонента. Публичные страницы обычно описывают установленную мощность. Клиентам нужны полезная и восстанавливаемая мощность.

Текущие публичные данные Medyabim не могут решить этот вопрос. Они могут только сформулировать запрос на данные: схемы энергоснабжения, время работы ИБП и генераторов, конструкция охлаждения, политика плотности стоек, противопожарные и водяные контроли, разнообразие входов операторов, история обслуживания, процедура remote hands, политика запасных частей и как минимум одно документированное учение по переключению или восстановлению.

Кто страдает, когда Medyabim выходит из строя

Затронутые пользователи — не только прямые владельцы аккаунтов Medyabim. Провайдер, продающий домены, хостинг, реселлерские пакеты, VDS, выделенные серверы, colocation, почтовое хранение и резервное копирование, может находиться под множеством нижестоящих сервисов. Реселлерский пакет может обслуживать десятки или сотни небольших сайтов, владельцы которых могут не знать о существовании Medyabim. Выделенный сервер может нести бизнес-приложение, базу данных, портфолио агентства, почтовый сервис или интернет-магазин.

Клиент colocation может владеть оборудованием, но зависеть от Medyabim в питании, доступе в стойку, пути межсетевого экрана, мониторинге трафика и управлении перезагрузкой.

Путь отказа также не одномерен. Сбой электропитания может остановить серверы, даже если вышестоящие маршруты здоровы. Сбой охлаждения может вынудить отключение или снизить допустимую плотность стоек. Отказ межсетевого экрана может изолировать многих клиентов сразу. Отказ одного апстрима может затронуть AS44922, если для нужного префикса не активен альтернативный путь. Сбой поддержки или тикетов может замедлить восстановление, даже если объект цел. Сбой DNS или почты на адресном пространстве внешнего источника может затруднить связь с Medyabim, пока боевой трафик в другом месте работает.

Приостановка по договору или злоупотреблениям может убрать услугу без физического сбоя.

Именно поэтому вывод о DNS важен. Если публичный брендовый домен и почтовый сервис используют 185.7.83.213 под префиксом, который сейчас анонсирует DATAFOREST, и если SPF ссылается на префикс 37.247.112.0/24, который сейчас анонсирует Bradler & Krantz, клиенты не должны предполагать, что «сеть Medyabim» означает одну AS, один город, один объект или одну юрисдикцию. Услуга может быть устойчивее, потому что часть компонентов находится за пределами AS44922. Она также может быть сложнее, потому что ответственность за инциденты пересекает границы провайдеров.

Люди, которым нужны ответы, — закупочные команды, веб-агентства, операторы реселлеров, владельцы малого бизнеса, системные администраторы, специалисты по комплаенсу и реагирующие на инциденты. Им нужно знать, есть ли у услуги, размещённой у Medyabim, второй путь, недавний тест восстановления, внешний канал поддержки, актуальные резервные копии, доступ к переносу домена, экспорт DNS, почтовая непрерывность и авторизация источника маршрута. Эти вопросы не враждебны. Это минимальная работа, чтобы превратить хостинг-отношения в инфраструктурную зависимость, способную пережить плохой день.

Что клиентам стоит попросить Medyabim доказать

Во-первых, попросите актуальную сетевую карту. Она должна идентифицировать AS44922, 37.247.116.0/24, любые зарезервированные или неактивные префиксы AS44922, такие как 37.247.117.0/24, любые планы IPv6 для 2a03:400::/32 или большего выделения, и любые клиентские услуги, маршрутизируемые под AS29141, AS58212 или другими источниками. Она должна показывать, является ли AS16276 единственным активным апстримом для маршрута AS44922, активны ли другие провайдеры через частные или ненаблюдаемые соглашения, и являются ли имена провайдеров на странице дата-центра текущими, историческими, косвенными или привязанными к конкретным продуктам.

Во-вторых, попросите данные об устойчивости объекта. Ответ должен включать вводы питания, конструкцию ИБП, время работы батарей, время работы генераторов, резервирование охлаждения, лимиты плотности стоек, физическую безопасность, противопожарные и водяные контроли, окна обслуживания, доступность remote hands, политику запасных частей и то, что на самом деле покрывает заявление о 99% непрерывности colocation. Если услуга в Бурсе, спросите, какие зависимости от здания и коммунальных служб действуют. Если услуга за рубежом, спросите, какие страна, объект, провайдер и юридические условия применяются.

В-третьих, попросите доказательства переключения при сбое на уровне клиента. Medyabim должна уметь показать, что происходит, когда отказывает апстрим, межсетевой экран, сервер теряет питание, отказывает диск, клиент не может попасть в портал, очередь поддержки занята, аккаунт помечен за злоупотребления или клиенту нужна аварийная миграция. Публичные страницы упоминают мониторинг трафика, резервные копии, порты перезагрузки и тикеты. Покупателю нужно знать, как эти инструменты ведут себя во время сбоя.

В-четвёртых, попросите данные и контроль выхода. Страница хостинга упоминает еженедельные и ежемесячные автоматические резервные копии, опциональное резервирование, почтовые продукты резервирования и услугу резервного копирования серверов. Договор ограничивает ответственность Medyabim за перерывы в обслуживании и потерю данных, если договор не говорит иное. Клиенты должны требовать тесты восстановления, объём резервирования, срок хранения, статус офсайта, шифрование, контроль доступа, процесс экспорта, процесс переноса домена, экспорт DNS и почтовую непрерывность.

В-пятых, попросите доказательства, что с поддержкой можно связаться, когда обычный сайт или почтовый маршрут недоступны. Контактная страница даёт телефоны и почту. Страница дата-центра описывает телефонную поддержку в рабочие часы и поддержку по тикетам и почте вне часов. Критичным клиентам стоит требовать именованную аварийную эскалацию, аутентифицированные контакты, внешнюю телефонную процедуру и способ авторизовать remote hands, не полагаясь только на обычный портал.

Разумный комплект доказательств не обязан раскрывать чувствительные планы объекта. Medyabim может предоставить приложение для конкретного клиента, в котором указано, какой объект обслуживает рабочую нагрузку, какие префиксы и исходные ASN используются, какие DNS и почтовые сервисы входят в объём, какие апстримы активны, какие компоненты являются едиными точками отказа и какие услуги находятся за пределами Турции. Оно может предоставить редактированную однолинейную схему, разделяющую клиентские серверы, общий межсетевой экран, контроллер перезагрузки, цель резервного копирования, портал поддержки, авторитетный DNS и публичный сайт.

Оно также может предоставить свежие даты тестов генераторов, обслуживания ИБП, обслуживания охлаждения, тестов переключения апстримов, тестов восстановления из резервных копий и изменений источника маршрута. Эти артефакты ответят на операционный вопрос без раскрытия имён клиентов или чувствительных схем безопасности.

То же приложение должно различать обычный хостинг, colocation и выделенные серверы. В общем хостинге покупатель зависит от выбора платформы и политики резервного копирования Medyabim. В реселлерском хостинге нижестоящие клиенты могут зависеть от Medyabim, даже если покупают у другого бренда. На выделенных серверах покупатель может контролировать операционную систему, но не стойку, маршрутизатор, путь питания или запасные части. В colocation покупатель может владеть сервером, но всё равно полагаться на Medyabim в здании, питании, доступе поддержки и сетевом крае. Эти различия определяют, кто действует первым при сбое.

Оценка доказательств

Medyabim получает среднюю оценку публичных сетевых доказательств со снижением за доказательства объекта и устойчивости. Слой идентичности силён для небольшого провайдера: записи RDAP RIPE и организации RIPE связывают AS44922 и ORG-MIH2-RIPE с Emre Erim trading as Medyabim Дата-центр, и адрес в Бурсе совпадает с контактной страницей Medyabim. Текущий маршрутный слой AS44922 тоже реален: RIPEstat отмечает AS как анонсируемый, указывает 37.247.116.0/24 как текущий, показывает полную видимость IPv4 в RIS на момент проверки и валидирует маршрут по RPKI.

Оценка не может быть высокой, потому что операционные доказательства быстро заканчиваются сразу после этого. RIPEstat показал только один текущий IPv4-префикс /24, ни одного текущего объявления IPv6 и одного наблюдаемого соседа AS44922. PeeringDB не вернул сетевого объекта для AS44922. Просмотр согласованности в RIPEstat показал запись route IPv4 и запись route6 IPv6, которых не было в текущем BGP. Собственная DNS-поверхность Medyabim указывает на адресное пространство, которое сейчас анонсируют другие сети.

Официальные страницы Medyabim публикуют полезные заявления об услугах, но не публикуют доказательства по электричеству, охлаждению, встречам операторов, обслуживанию и переключению при сбое, необходимые, чтобы доверять заявленной мощности дата-центра под нагрузкой.

Практический вывод — не отмахиваться от Medyabim. Данные подтверждают реального хостинг-провайдера и оператора дата-центра в Бурсе с давними записями в RIPE, видимым сетевым краем, официальными страницами услуг и конкретным предложением клиентам. Вывод также не в том, чтобы принять заявления о «более 500 серверов» и «50 Гбит/с» как доказательство устойчивости. Клиентам стоит считать эти заявления гипотезами, которые нужно проверить через актуальные схемы операторов, данные объекта, карту префиксов, проверки RPKI, тесты восстановления и процедуры поддержки, привязанные к договору.

Публичный след Medyabim сильнее всего там, где она называет идентичность, услуги и один текущий маршрут. Он слабее всего там, где клиенту больше всего нужны доказательства во время сбоя: сетевое электричество, охлаждение, физическое разнообразие оптики, активная избыточность операторов, текущий IPv6, эскалация поддержки, резервные копии, выход и протестированное восстановление. Именно на это и должна быть направлена должная осмотрительность, прежде чем критичные рабочие нагрузки окажутся за этим брендом.