Hosting SC ITNS.NET SRL продаёт хостинговые мощности, которые по-прежнему зависят от стоек, транзита и окон ремонта

Кратко

• Публичная аргументация в пользу того, чтобы считать Hosting SC ITNS.NET SRL зависимостью по хостинговым мощностям, реальна, но ограничена: сама ITNS относит облачные приложения и управляемый хостинг к сервисам прикладного уровня, PeeringDB указывает вторую сеть SC ITNS.NET SRL — IPV4-HOSTING, а RIPE связывает обе автономные системы, AS35346 и AS202511, с одной и той же молдавской организацией.
• Более весомы сетевые доказательства, а не продуктовые. AS35346 активна, видна в RIPEstat, присутствует на MD-IX и KIVIX в PeeringDB и связана в базе данных RIPE с поименованной политикой аплинков и пиринга. AS202511 закреплена за той же организацией, но на 12 июля 2026 года не анонсировалась в RIPEstat.
• Главный операционный риск — не загадочная облачная панель управления, а обычный физический стек регионального хостинг-провайдера: площадки в Кишинёве, электропитание, разнообразие аплинков, запасы IPv4, конфигурация маршрутизаторов, замена оборудования, часы работы поддержки, экспорт данных клиента и возможность перенести нагрузку до того, как окно ремонта превратится в простой у клиента.
• Уровень доказательности — средний. Открытых данных о маршрутизации, регуляторе и операторе достаточно, чтобы выявить зависимости и сценарии отказов, но публичных сведений о площадках, инвентаризации, статусных страницах, контрактах и тестах восстановления недостаточно, чтобы подтвердить устойчивость на нескольких площадках или переносимость нагрузки клиента.

Полезный вопрос — не в том, находится ли ITNS «в облаке»

Хостинг часто продают как абстракцию. Клиент покупает виртуальный сервер, частную VLAN, управляемый файрвол, веб-портал, резервное хранилище или прикладную среду — и его подталкивают думать названиями сервисов, а не физическими ограничениями. Hosting SC ITNS.NET SRL — полезное напоминание о том, что региональные хостинговые мощности остаются набором обычных активов. Где-то сервер должен загрузиться. Где-то коммутатор должен пропустить кадры. Где-то маршрут должен покинуть Молдову. Где-то техник должен заменить блок питания, поменять оптику, восстановить конфигурацию или сказать клиенту, займёт ли миграция минуты, часы или выходные.

Публичные источники не дают оснований для грандиозной трактовки ITNS как гипермасштабной облачной платформы. Они дают основания для более узкой и более важной трактовки: ITNS — молдавский оператор связи, чьи публичные заявления охватывают сервисы прикладного уровня и управляемый хостинг и чья видимая инфраструктура автономных систем важна для любого клиента, полагающегося на неё в вопросах хостинговых мощностей. На собственной страницеWho We Areкомпания описывает IT and Network Solution (ITNS.NET SRL) как молдавского партнёра по оптическим сетям и телекоммуникациям с опытом более двух десятилетий. На страницеWhat We Doописана работа от проектирования физических сетей до интернет-, телевизионных и облачных систем. СтраницаLayer 7идёт дальше, к прикладным сервисам: облачные приложения, управляемый хостинг, порталы, DevOps-системы, видеонаблюдение, телевидение, телефония и заказные цифровые сервисы.

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

Поставка IPv4 — это собственные аллокации, арендованное адресное пространство, адреса клиента или повторно анонсируемые нижестоящие сети? Держит ли провайдер запасное оборудование рядом или отказавшие серверы и оптика ждут закупок? Если один аплинк, route server, фидер питания, биллинговая система или служба поддержки даст сбой — как далеко распространится отказ?

Открытые источники дают частичные ответы. Публичныйреестр ANRCETI поставщиков сетей и услуг электронных коммуникацийуказывает ITNS. NET S.C. S.R.L. по адресу Miron Costin 3/1 в Кишинёве, с разрешением на стационарные наземные сети и услуги общего пользования, включая телефонию, транзит вызовов, арендуемые линии, передачу данных и доступ в интернет.Запись организации ORG-SIS76-RIPE в базе RIPEидентифицирует SC ITNS.NET SRL в Молдове, указывает регистрационный номер, помечает организацию как локальный интернет-реестр и фиксирует адрес Muncesti 121A в Кишинёве.Запись aut-num для AS35346 в базе RIPEназывает EUROTELECOM, связывает автономную систему с этой организацией и перечисляет политику импорта и экспорта для аплинков, точек обмена и пиров. Втораязапись aut-num для AS202511использует имя AS HOSTING и ту же организацию, а PeeringDB указывает соответствующую сетьIPV4-HOSTINGв записи SC ITNS.NET SRL.

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

Юридическая и местная идентичность: молдавский оператор за сервисами

Юридический след прочнее, чем след розничных продуктов. Публичный реестр ANRCETI называет ITNS. NET S.C. S.R.L., указывает кишинёвский адрес Miron Costin 3/1 и перечисляет классы услуг оператора, включая публичный доступ в интернет, передачу данных и арендуемые линии. Эта запись регулятора важна: она закрепляет ITNS на молдавском рынке электронных коммуникаций, а не оставляет её веб-брендом чистого хостинга. Она же показывает компанию оператором, у которого хостинговые услуги, если они продаются клиентам, соседствуют с традиционными телеком-обязанностями: сети доступа, передача, взаимоувязка, поддержка и непрерывность сервисов.

RIPE даёт дополняющую картину по номерным интернет-ресурсам.Объект организациииспользует имя SC ITNS.NET SRL, код страны MD, регистрационный номер 1005600004190 и статус локального интернет-реестра. Поля адреса указывают Muncesti 121A, MD-2002, Кишинёв. Та же запись называет мейнтейнеров ITNS-NET-MNT и RIPE NCC-HM-MNT, аобъект мейнтейнера ITNS-NET-MNTописывает центр управления сетью ITNS с адресом в Кишинёве. Эти записи не доказывают, какое юридическое лицо владеет каждой стойкой или сервером. Но они доказывают, что публичные маршрутные ресурсы, о которых идёт речь в статье, не оторваны от идентичности молдавской компании.

PeeringDB подтверждает связь с точки зрения сетевого оператора.Запись организации SC ITNS.NET SRLиспользует то же имя организации, помечает EUROTELECOM как альтернативное имя, указывает сайты itns.md и itns.net, приводит кишинёвские адреса и связывает организацию с двумя сетями: ITNS.NET для AS35346 и IPV4-HOSTING для AS202511. PeeringDB ведётся самими сетевыми операторами, и к ней не стоит относиться как к записи регулятора, но она полезна, потому что отражает, как оператор представляет себя пирам. На этой площадке ITNS показывает не только общую сеть, но и автономную систему с хостинговой меткой.

Итак, картина идентичности состоит из трёх слоёв. Регулятор видит молдавского поставщика электронных коммуникаций. RIPE видит молдавский локальный интернет-реестр с AS35346 и AS202511, привязанными к SC ITNS.NET SRL. PeeringDB видит сетевого оператора с сетью ITNS.NET и второй сетью с хостинговой меткой. Этого достаточно, чтобы считать Hosting SC ITNS.NET SRL реальной инфраструктурной зависимостью. Но недостаточно, чтобы делать выводы о связях собственности, отношениях с клиентами или контрактах на площадки сверх того, что указано в этих открытых записях.

Что компания заявляет о своих услугах

Сайт самой ITNS широк по тематике и несколько маркетинговый, но он даёт несколько важных заявлений. СтраницаWho We Areописывает ITNS.NET SRL как молдавского игрока на рынке оптических сетей с более чем двадцатилетним ростом, экспертизой в бизнесе интернет-провайдеров и работой по проектированию, внедрению и эксплуатации волоконно-оптических сетей. Язык саморекламный, но он поддерживает базовый вывод: ITNS хочет, чтобы её воспринимали как инженерно-эксплуатационную инфраструктурную компанию, а не просто как страницу реселлера.

СтраницаWhat We Doконкретнее. На ней сказано, что ITNS предоставляет комплексные решения телекоммуникационной инфраструктуры — от проектирования физического волокна до интернет-, телевизионных и облачных систем. Стек разделён с уровня 1 по уровень 7. Уровень 1 охватывает проверку требований, полевой анализ, проектирование оптической инфраструктуры, согласование с органами власти и строительство. Уровень 2 охватывает проектирование активного оборудования с использованием таких вендоров, как Juniper, Cisco, Huawei, Arista, Mikrotik, D-Link и TP-Link. Уровень 3 — монтаж, настройку, предоставление интернет-услуг, подключение аплинков, пиринг, IP-транзит, мониторинг и обслуживание. Уровень 7 называет телевидение, видеонаблюдение, фиксированную телефонию, порталы, DevOps-системы и облачные приложения.

СтраницаLayer 1полезна тем, что объясняет физическую направленность заявления компании. На ней описаны проектирование и строительство сетей электронных коммуникаций, полевые обследования, трассировка маршрутов, документация, прокладка кабельной канализации и кабеля, сварка, оконцевание и тестирование OTDR. Для хостинговых мощностей это важно косвенно. Хостинговая услуга, вертикально близкая к оператору волокна и сетей, может иметь преимущества в местном доступе, абонентских цепях и частных подключениях. Но она наследует и ограничения полевой эксплуатации: разрешения, повреждения трасс, доступность техников и время, необходимое на ремонт или перемаршрутизацию физической инфраструктуры.

СтраницаLayer 3ближе к хостинговой зависимости. На ней описаны маршрутизация, BGP, OSPF, MPLS, VLAN, сегментация сети, подключение аплинков, пиринг, IP-транзит, проектирование высокой доступности, мониторинг и обслуживание. Клиент, покупающий у ITNS хостинговые мощности, покупает не только вычисления или хранилища. Он полагается на практики уровня 3, чтобы нагрузка оставалась доступной. Если изменится политика маршрутизации, приостановят транзитный контракт, распространится ошибочная конфигурация или во время сбоя придётся перемещать клиентское IP-пространство, границей сервиса становится граница сети.

СтраницаLayer 7— главное публичное свидетельство о сервисах для этой позиции. На ней сказано, что ITNS предоставляет сервисы прикладного уровня и прямо включает в число заказных решений облачные приложения, управляемый хостинг, интеграцию IoT и оркестрацию корпоративных сервисов. Это не полный каталог управляемого хостинга. На ней не публикуются размеры серверов, цены, платформа виртуализации, сроки хранения резервных копий, уровни хранилищ, уровни сервиса, условия оплаты или обязательства по экспорту данных. Тем не менее это прямое официальное заявление о том, что хостинговые и прикладные сервисы входят в коммерческую поверхность компании.

СтраницаWhy You Need Usодновременно поднимает планку и усиливает неопределённость. На ней заявлены сквозные решения от волоконной оптики до облачных приложений, круглосуточная поддержка и мониторинг, резервные маршруты, превентивное обслуживание и аптайм 99,99 %. Эти утверждения ценны как обязательства перед клиентами, но сама страница их независимо не подтверждает. При отсутствии публичной истории инцидентов, статусных страниц, карт площадок и учений по восстановлению эти заявления следует читать как утверждения, которые покупатель должен проверять через контракты и технический due diligence.

AS35346 — видимая производственная сеть

Самый ясный материальный актив в открытых источниках — AS35346.Объект aut-num в базе данных RIPEфиксирует AS как EUROTELECOM, привязанную к ORG-SIS76-RIPE, со статусом ASSIGNED, датой создания 20 июля 2005 года и датой последнего изменения 24 июня 2026 года. Тот же объект называет аплинки и политику взаимоувязки. В нём перечислены Cogent (AS174), RENAM (AS9199), NGN (AS60514) и Rapid Link (AS50084). Также указаны MD-IX со ссылками на точки обмена Moldtelecom, KIVIX со ссылками на точки обмена TRABIA и строки пиринга для Google Global Cache, Arax-impex и Rapid Link. Детали технические, но стратегический смысл прост: у AS35346 поверхность взаимоувязки шире, чем один транзитный поток.

RIPEstat подтверждает, что AS35346 не только закреплена, но и видна.Обзор AS в RIPEstatпоказывал владельца EUROTELECOM SC ITNS.NET SRL и помечал AS как анонсируемую на 12 июля 2026 года.Представление статуса маршрутизации в RIPEstatсообщало о полной видимости IPv4 по выборке пиров RIS, высокой видимости IPv6, 19 анонсируемых префиксах IPv4, 6400 адресах IPv4, 148 префиксах IPv6 и 13 наблюдаемых соседях. Там же были видны первое наблюдение происхождения этой AS в декабре 2005 года и текущие наблюдения в июле 2026 года. Для клиента хостинговых услуг это более весомое доказательство, чем сервисный буклет. Доступность видят независимые коллекторы маршрутов.

Запрос анонсируемых префиксов в RIPEstatпоказывает, насколько широка поверхность IPv6. Он перечисляет множество анонсов /29 для IPv6 наряду с префиксами IPv4, такими как 91.242.112.0/20, несколько сетей 91.242.x.0/24, 195.138.108.0/24 и 194.114.144.0/24. К точному составу стоит относиться как к изменяющемуся во времени, но текущий снимок показывает, что AS35346 — не спящая оболочка. Она активно анонсирует адресное пространство в масштабе регионального оператора.

Представление согласованности маршрутизации AS в RIPEstatдобавляет нюансов. Оно показывает много префиксов, которые есть и в BGP, и в реестре маршрутизации RIPE, но также длинный список префиксов IPv6, которые видны в BGP и не совпадают с whois-стороной вывода о согласованности. Это не значит автоматически, что маршрутизация ошибочна. Это значит, что клиенту или пиру не стоит предполагать, будто каждый анонс имеет одинаково оформленную позицию в реестре маршрутизации. Для хостинговых мощностей, особенно когда речь идёт о клиентских префиксах или делегированных диапазонах IPv6, качество маршрутной документации может влиять на фильтрацию, приём аплинками и скорость диагностики инцидентов.

Данные RPKI частичны, но полезны.Запрос проверки RPKI в RIPEstatдля 91.242.112.0/20 вернул статус valid для источника AS35346. Второйзапрос проверки RPKIдля 195.138.108.0/24 также вернул для AS35346 статус valid, показав при этом, что более широкая сеть AS8474 была бы недействительной для того же вопроса об источнике. Для клиентов действительные ROA не гарантируют аптайм сервиса, но снижают один класс риска происхождения маршрута для этих конкретных префиксов.

Автономная система с хостинговой меткой — зацепка, а не текущее доказательство живых мощностей

AS202511 — самая явная хостинговая зацепка в открытых записях.Объект aut-num в RIPEиспользует имя AS HOSTING, связывает AS с ORG-SIS76-RIPE и перечисляет политику импорта/экспорта с AS41221 и AS42881. Он создан в 2018 году и последний раз изменён в марте 2025 года. ЗаписьIPV4-HOSTING в PeeringDBуказывает AS202511 в составе SC ITNS.NET SRL, с сайтом itns.md и альтернативным именем SC ITNS.NET SRL.

Но данные о живой маршрутизации слабее.Обзор AS в RIPEstatдля AS202511 показывал владельца HOSTING SC ITNS.NET SRL, но помечал AS как не анонсируемую на 12 июля 2026 года.Запрос статуса маршрутизациидля AS202511 в RIPEstat не показал текущей видимости IPv4 или IPv6 по выборке пиров RIS, хотя зафиксировал исторические первое и последнее наблюдения. PeeringDB также не показывает для записи IPV4-HOSTING ни точек обмена, ни площадок, ни публичного профиля трафика.

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

Более безопасный вывод: у ITNS есть след номерных ресурсов с хостинговой меткой, но живую сервисную зависимость, видимую сегодня, лучше анализировать через AS35346, если клиентский контракт, looking glass, коллектор маршрутов или заказ услуги не докажут обратного.

Это определяет и экономику хостинга. Адреса IPv4 дефицитны и дороги, особенно для небольших региональных провайдеров, которым нужно поддерживать виртуальные серверы, выделенные машины, клиентские устройства, почтовые и именные серверы и легаси-приложения. Наличие сети с названием IPV4-HOSTING позволяет предположить, что поставка и выделение IPv4 могут быть центральными для сервиса, но нынешнее отсутствие публичной видимости в BGP затрудняет оценку того, как используется эта поставка.

Покупателю стоит спросить, получают ли хостинговые сервисы адреса IPv4 провайдера, собственные IPv4 клиента, общий IPv4 с пробросом портов, адресацию с приоритетом IPv6 или путь миграции при смене блока.

Пиринг и присутствие на точках обмена снижают одни риски и оставляют другие

PeeringDB указывает AS35346 как ITNS.NET, с именем сети IT & Network Solutions, региональным охватом, преимущественно входящим соотношением трафика, трафиком 50–100 Гбит/с, открытой политикой пиринга, включённым IPv6, двумя подключениями к точкам обмена и без публичных записей о площадках.Представление netixlan в PeeringDB для сети 29822даёт два подключения: MD-IX и KIVIX, оба показаны на 10 Гбит/с, оба действующие, оба с адресами IPv4 и IPv6, оба настроены как пиры route server. Это существенно. Хостинговой нагрузке нужен не только транзит через аплинки. Она выигрывает, когда локальный и региональный трафик может оставаться рядом с клиентом, избегать перегруженных магистральных путей и сохранять доступность при нарушении одного из транзитных путей.

Запись MD-IX в PeeringDBопределяет MD-IX как Moldova Internet Exchange в Кишинёве, оператором которого выступает Moldtelecom SA, с двумя записями о площадках в PeeringDB: COLO-54 Moldtelecom и Data City — Moldtelecom.Запись KIVIX в PeeringDBопределяет KIVIX как Chisinau Internet Exchange, связанный с кишинёвской площадкой Trabia. Эти записи о точках обмена не доказывают, что серверы клиентов ITNS находятся внутри этих площадок. Они доказывают, что сама обменная инфраструктура физически связана с кишинёвскими дата-центрами или операторскими площадками и что у ITNS есть по крайней мере те подключения к точкам обмена, которые перечислены в PeeringDB.

Здесь есть тонкий риск. Присутствие на точках обмена может улучшить локальную маршрутизацию, но может и создать иллюзию устойчивости на нескольких площадках. Два порта на точках обмена не обязательно означают два независимых вычислительных узла. Провайдер может пиринговать на нескольких точках обмена, держа серверы клиентов в одной комнате. И наоборот, провайдер может эксплуатировать серверы на нескольких арендуемых площадках, не раскрывая ни одной из них в PeeringDB. Запись в текущем виде в большей степени подтверждает разнообразие взаимоувязки, чем разнообразие площадок.

Объект aut-num в RIPE расширяет картину, перечисляя поименованные транзитные и пиринговые отношения. Cogent и RENAM видны и в политике RIPE, и в разделе импорта/экспорта согласованности маршрутизации RIPEstat как присутствующие в BGP. Другие перечисленные отношения — NGN, Rapid Link, MD-IX, KIVIX и отдельные пиры — видны в объекте политики, даже если представление согласованности не показывает соответствующей текущей видимости в BGP. Такая смесь не редкость. Записи политики маршрутизации могут отставать от реальности, включать запланированные отношения, пропускать живые или сохранять старые договорённости.

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

Площадки — самая большая публичная слепая зона

Самые весомые факты о площадках — это адреса и контекст точек обмена, а не карты стоек. RIPE указывает для организации Muncesti 121A. Объект мейнтейнера ITNS указывает для центра управления сетью Miron Costin 3/1. Реестр ANRCETI также указывает Miron Costin 3/1. Запись организации в PeeringDB указывает оба адреса — Muncesti 121A и Miron Costin 3/1. Эти публичные адреса определяют кишинёвские точки присутствия, но не показывают, где размещены серверы клиентов, системы хранения или пограничные маршрутизаторы.

Различие между офисом, центром управления, сетевым узлом, машинным залом и арендуемой стойкой важно. Хостинговые мощности отказывают по-разному — в зависимости от того, что именно задействовано. Если серверы клиентов находятся в собственном или арендованном машинном зале с резервированным питанием, охлаждением, контролем доступа, запасными частями и возможностью встречи операторов (meet-me), провайдер может обоснованно заявлять более высокую надёжность.

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

Представление netfac в PeeringDB для ITNS.NETне возвращает ни одной записи о площадках. Это один из важнейших негативных фактов в этом анализе. Он не даёт оснований заключить, что у ITNS нет присутствия на площадках. Многие сети сознательно не указывают площадки. Но это значит, что публичная запись PeeringDB не позволяет покупателю проверить, присутствует ли AS35346 в Data City, Trabia, Moldtelecom, в собственном помещении или на любой другой названной площадке. Бремя доказательства переходит к контрактным документам, отзывам клиентов, осмотру площадок, схемам провайдера или подписанным описаниям сервиса.

Сайт компании даёт уверенность в физической инфраструктуре в другом направлении. Материалы об уровне 1 описывают практики строительства и инженерии вокруг волоконных трасс и документации. Это поддерживает представление о том, что ITNS понимает внешние сети и физическое развёртывание. Это напрямую не подтверждает зрелость дата-центров. Оператор волокна может быть силён в траншеях, канализации, сварке и трассах доступа, полагаясь при этом на сторонний колокейшн для серверов. Хостинговый покупатель должен разделять эти вопросы.

Способности в волокне улучшают локальный доступ и частные магистрали; способности дата-центра определяют выживание серверов при событиях с питанием, охлаждением и доступом.

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

Установленная мощность — это не то же самое, что доступная мощность

Открытые источники показывают значимый сетевой след. RIPEstat сообщает о полной текущей видимости IPv4 и существенной видимости IPv6 для AS35346. PeeringDB сообщает о трафике 50–100 Гбит/с и двух портах точек обмена по 10 Гбит/с. Официальный сайт описывает сквозную инфраструктуру и прикладные сервисы. Эти факты указывают на установленные возможности. Но они не говорят клиенту, сколько доступной мощности остаётся с учётом существующих клиентов, оверсабскрипшена, резервов на обслуживание, запаса под DDoS и ограничений портов.

Это различие особенно важно для экономики хостинга. Провайдер может анонсировать много префиксов IPv6 и при этом быть ограничен выделением IPv4, количеством физических серверов, производительностью хранилищ, штатом поддержки или обязательствами по аплинкам. У него могут быть порты точек обмена по 10 Гбит/с, тогда как конкретная хостинговая услуга ограничена аплинком 1 Гбит/с, файрволом, общим дисковым массивом или клиентской VLAN. Он может рекламировать аптайм 99,99 %, пока окна обслуживания, обязательства по восстановлению и условия компенсаций остаются закрытыми.

Клиентам не стоит путать размер адресного пространства с запасом вычислений или присутствие на точках обмена с запасом серверных мощностей.

Адресный профиль AS35346 всё же полезен. Видимость 6400 адресов IPv4, если она актуальна и корректно атрибутирована, — материальный ресурс для регионального оператора. Он может обеспечивать клиентов доступа, инфраструктуру, почту, хостинг, пулы NAT, мониторинг и выделения клиентам. Анонсы IPv6 также достаточно широки, чтобы дизайн хостинга с поддержкой IPv6 выглядел правдоподобно.

Но бизнес-ценность зависит от операционной политики: могут ли клиенты получать маршрутизируемые подсети, делегируется ли обратный DNS, стоят ли файрволы провайдера на пути трафика, влияет ли обработка жалоб на хостинговых клиентов и переносимы ли выделенные адреса при уходе клиента.

AS202511 добавляет неразрешённый сигнал о мощностях. Хостинговая AS может быть полезна, если ITNS хочет изолировать хостинговые маршруты от общей сети доступа, применять отдельную политику аплинков, принимать клиентские префиксы или переносить нагрузку во время обслуживания. Но поскольку на 12 июля 2026 года эта AS не анонсировалась в RIPEstat, без дополнительных доказательств её нельзя считать живой резервной мощностью. Спящая AS может быть опцией; она не является проверенным путём аварийного переключения, пока не наблюдается в работе.

Сценарии отказов обычные — и именно поэтому они важны

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

Отказ стойки или помещения понять проще всего. Если серверы, хранилища и стоечные коммутаторы (top-of-rack), на которых работает нагрузка клиента, теряют питание или охлаждение, клиенты получают простой, если только нагрузка не переключается на физически отдельную площадку. В открытых материалах упоминаются резервирование и высокая доступность, но мультисайтовая архитектура не публикуется. Поэтому правильная позиция покупателя — осторожность: резервирование — это утверждение, которое нужно проверить, а не факт, выводимый из наличия нескольких подключений к точкам обмена.

Отказ аплинка или маршрутизации легче увидеть публично. У AS35346 есть поименованные аплинки и пиры на точках обмена, а RIPEstat видит текущих соседей. Это снижает риск единственного аплинка, но не устраняет отказы маршрутизации. Ошибочно настроенный фильтр маршрутов, истёкший объект маршрута, недействительная ROA, спор с аплинком, инцидент на route server или политика DDoS-блэкхола всё ещё могут затронуть хостинговую нагрузку. Действительность RPKI для некоторых префиксов помогает, но вывод о согласованности маршрутизации показывает, что представления реестра и BGP не единообразны для всех анонсов.

Клиентам со строгими требованиями к доступности стоит спросить, какие префиксы используют их сервисы и есть ли у этих конкретных префиксов действительные RPKI, полные объекты маршрутов и проверенный приём аплинками.

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

Но открытые источники не позволяют клиентам предполагать, что отказавший контроллер хранилища или материнская плата сервера будут заменены в тот же день.

Отказ поддержки — ещё одна скрытая зависимость. Официальный сайт перечисляет концепции поддержки и мониторинга, а PeeringDB указывает публичный контакт NOC в основной записи сети. Это полезный сигнал. Остальные вопросы практические: кто отвечает в нерабочее время, как эскалируются инциденты, может ли служба поддержки вносить изменения в сеть, внутренние ли это remote hands или предоставленные площадкой, может ли биллинговая проблема автоматически приостановить сервис и доступны ли резервные копии клиента во время споров по договору.

Отказ при миграции — самый тихий риск. В момент, когда клиенту нужно уйти, хостинговая мощность перестаёт быть абстракцией. Можно ли экспортировать образы дисков? Можно ли скоординировать изменения DNS? Переезжают ли IP-адреса? В стандартном ли формате резервные копии? Есть ли внешний путь копирования, если сеть провайдера повреждена? Разрешает ли договор выгрузку данных после расторжения или неплатежа? Публичные страницы ITNS на эти вопросы не отвечают. Для многих провайдеров это нормально, но именно поэтому клиентам стоит заняться переносимостью до сбоя.

Локальность данных правдоподобна, но суверенитет данных не гарантирован

Регион в этой задаче — MD, и открытые источники подтверждают Молдову как операционный контекст. ANRCETI указывает ITNS как молдавского провайдера. RIPE и PeeringDB указывают молдавские адреса. Точки обмена — в Кишинёве. Официальный сайт компании подчёркивает цифровое будущее Молдовы, молдавскую волоконную инфраструктуру и местную инженерию. Эти факты делают локальный хостинг или зависимость от местной сети правдоподобными.

Правдоподобная локальность — не то же самое, что гарантированный суверенитет данных. Открытые источники не показывают, где лежат диски клиента, где хранятся резервные копии, используют ли управляемые приложения сторонние платформы за пределами Молдовы и зависят ли административный доступ, мониторинг, почта, DNS, тикетинг, репликация хранилищ или сервисы безопасности от внешних поставщиков. Клиенту, которому нужна локализация данных в Молдове, нужны договор и схема архитектуры, а не только молдавская AS.

Сетевая картина указывает и за пределы Молдовы. Cogent — глобальный транзитный провайдер. RENAM — местный академический и исследовательский сетевой контекст. MD-IX и KIVIX удерживают локальный трафик локально там, где участвуют пиры, но транзит через аплинки по определению покидает местную обменную инфраструктуру. Хостинговая нагрузка может физически находиться в Кишинёве и при этом зависеть от внешнего транзита, зарубежных DNS-сервисов, иностранных платёжных процессоров или зарубежных целей резервного копирования. Само по себе это не проблема.

Это просто означает, что фразу «хостинг у молдавского оператора» не стоит автоматически переводить в «все зависимости остаются в Молдове».

Поэтому due diligence по суверенитету данных должен быть точным. Спрашивайте, где хранятся основные данные, где хранятся резервные копии, кто имеет доступ к среде, юрисдикции каких субподрядчиков задействованы, какие логи покидают страну и какая аварийная копия будет использована после отказа площадки. Открытые данные об ITNS поддерживают тезис о локальном операторе. Но они не закрывают вопрос о расположении данных для отдельного клиента.

Кто пострадает при отказе хостинговых мощностей ITNS

Пострадавшие стороны зависят от того, какую часть стека ITNS покупает клиент. Для интернет-провайдера или небольшого оператора доступа, покупающего сетевую интеграцию, отказ может затронуть абонентов последней мили, выдачу CPE, головные станции телевидения, сервис VoIP или мониторинг. Для предприятия, покупающего управляемый хостинг или облачные приложения, зона поражения — клиентские порталы, внутренние системы, хранилища видеонаблюдения, удалённый доступ, почта, бизнес-приложения или публичные сайты.

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

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

Но это и концентрирует риск, если один и тот же оператор контролирует доступ, маршрутизацию, хостинг и поддержку.

Механизм воздействия таков: сначала задержки, затем доступность, затем доступ к данным и в последнюю очередь — доверие клиентов. Частичное нарушение маршрутизации может сделать хостинговые сервисы медленными или недоступными в регионе. Отказ стойки или хранилища может сделать их полностью недоступными. Отказ поддержки может превратить короткий инцидент в долгий. Отказ переносимости может запереть клиентов во время спора с провайдером или затяжного сбоя.

Поскольку у ITNS видимое разнообразие маршрутизации, но непрозрачные данные о площадках и восстановлении, приоритетный due diligence — не вопрос «выглядит ли AS живой?», а вопрос «переживёт ли сервис клиента те самые отказы — помещения, аплинка, сервера и поддержки, — которые действительно важны?»

Что клиенту следует проверить, прежде чем полагаться на ITNS в вопросах хостинговых мощностей

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

Вторая проверка — независимость сети. Спросите, какая AS и какие префиксы будут нести сервис, используется ли AS35346 или AS202511, покрыты ли конкретные префиксы действительными ROA, какие аплинки их принимают, существуют ли объекты маршрутов и сколько времени занимает изменение маршрутизации во время инцидента. Открытые источники показывают, что AS35346 активна, а AS202511 закреплена, но в настоящее время не анонсируется в RIPEstat. Клиенту не стоит принимать общее заявление о «нескольких провайдерах» без деталей на уровне префиксов.

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

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

Пятая проверка — выход. Хостинговая мощность наименее переносима, когда клиент думает о переносимости в последнюю очередь. До перехода в промышленную эксплуатацию клиент должен знать, как экспортировать данные, как переедут DNS и обратный DNS, переносимы ли IP-адреса, как долго резервные копии остаются доступными после отмены услуги и предоставит ли ITNS экстренную помощь, если клиент мигрирует во время сбоя. Эти условия не видны в открытых источниках, а значит, это работа для договора.

Уровень доказательности и итог

Уровень доказательности — средний. Доказательства идентичности сильные: ANRCETI, RIPE и PeeringDB связывают субъект с молдавским оператором связи. Сетевых доказательств по AS35346 достаточно для анализа зависимостей: текущие анонсы, широкая видимость, примеры действительных RPKI, поименованная политика аплинков и присутствие на точках обмена публичны. Доказательства сервисов умеренные: сама ITNS упоминает облачные приложения и управляемый хостинг, а в PeeringDB под той же организацией существует сеть IPV4-HOSTING.

Доказательства по площадкам и восстановлению слабые: в PeeringDB нет публичных записей о площадках для основной сети, не опубликована карта стоек, нет публичных тестов восстановления, истории статусов, политики резервного копирования и условий переносимости клиентов.

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

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