YISU CLOUD LTD продаёт арендуемые мощности, которые по-прежнему зависят от стоек, транзита и ремонтных окон

Кратко

• У YISU CLOUD LTD открытых операционных доказательств больше, чем у голой корпоративной оболочки: сайт Yisu продаёт облачные и хостинговые услуги, APNIC RDAP перечисляет подконтрольные Yisu AS136970, AS138152 и AS142403 как активные автономные системы Гонконга, а RIPEstat показывает, что все три анонсированы 12 июля 2026 года.
• Эти доказательства по-прежнему не раскрывают права собственности на стойки, договоры аренды площадок, топологию электропитания, резервирование охлаждения, глубину штата поддержки или проверенные сценарии миграции клиентов. Публичная маршрутизация доказывает доступность адресного пространства, но не то, какой объём полезных вычислительных мощностей переживёт обслуживание или отказ.
• Главный риск для клиента — нехватка доступных арендуемых мощностей: отказ стойки, вышестоящего транзита, запаса оборудования, поддержки, биллинга, миграции или контракта с провайдером, из-за которого небольшой клиент останется с видимым IP-сервисом, но ограниченными рычагами влияния на физический слой.

Витрина шире, чем доказательство инфраструктуры

Публичное лицо YISU CLOUD LTD — облачная витрина, а не пассивная табличка с маршрутами. Международная главная страница по адресуyisu.com/intlрекламирует эластичные облачные вычисления, выделенные физические серверы, управляемый MySQL, защиту от DDoS (Anti-DDoS IP), лёгкие серверы, балансировку нагрузки и SSL-сертификаты. На той же странице сказано, что компания предлагает мгновенный доступ к облачным сервисам в таких местах, как Токио, Франкфурт, Вашингтон и Лос-Анджелес, а карта локаций также называет Гонконг, Сингапур, Японию, Южную Корею, Германию, Бангкок, Индию, Индонезию, Австралию и США. Это широкое коммерческое заявление: Yisu продаёт клиентам идею, что мощности можно заказать через панель и использовать как глобальную хостинговую поверхность.

На собственной страницеО Yisu Cloudкомпания формулирует это заявление ещё жёстче. Там сказано, что Yisu основана в 2017 году, названа глобальным поставщиком облачных услуг и что она построила облачные вычисления для предприятий, разработчиков и государственных организаций. Там же сказано, что Yisu создала зелёные энергоэффективные дата-центры и офисы в Пекине, Шанхае, Гуанчжоу, Ханчжоу, Гонконге и других регионах Китая, а также в Европе, Южной Корее, Японии, Сингапуре и США. На той же странице заявлены более 50 000 облачных серверов, более 30 000 накопленных пользователей, более 2 800 CDN-узлов, пропускная способность CDN 130 ТБ/с и защита от DDoS мощностью свыше 5 000 Гбит/с. Это большие цифры для провайдера с ограниченным независимым раскрытием информации о площадках.

Этот разрыв — отправная точка статьи. Публичные доказательства подтверждают, что Yisu — реальный оператор хостинг-услуг с активной сетевой инфраструктурой. Они не подтверждают, что каждую локацию или масштабное заявление можно считать проверенной мерой мощности. На странице продукта может быть написано «облачный сервер»; заказ клиента может создать виртуальную машину; таблица BGP может показать маршруты, анонсированные Yisu; но ни один из этих фактов не называет машинный зал, количество стоек, схему электропитания, запас запчастей, очередь ремонта или план вывода клиента. Арендуемая мощность всегда выглядит абстрактно в момент покупки.

При отказе она становится физической.

Продуктовые страницы Yisu делают эту физическую зависимость необычно наглядной. На страницеElastic Cloud Computingсказано, что клиенты могут выбирать CPU, память, пропускную способность и выделенный IP, и она продвигает защиту данных на базе RAID, снимки, собственные внутренние сети, группы безопасности и защиту от DDoS-атак. СтраницаBare Metal Serverопускается на уровень ниже: она продаёт выделенные физические серверы в среде одного арендатора с автоматической установкой операционной системы, настройкой сети, подключением дисков и управлением жизненным циклом. СтраницаLight Serverпроще, но тоже зависит от надёжной связки вычислений, сети и хранения. Это не только программные обещания. Они требуют серверов, дисков, портов коммутаторов, электропитания, охлаждения, запаса IP, транзита и сотрудников, которые могут пересобрать или перенести клиентов при поломке.

Справедливое прочтение — не отмахнуться и не поверить всему. Публичная сетевая история Yisu достаточно весома, чтобы её изучать. Сайт достаточно конкретен, чтобы показать каталог услуг. Но слой площадок остаётся настолько непрозрачным, что клиентам стоит спрашивать, как продаваемые мощности соотносятся со стойками, арендой и ремонтными окнами. Собственные доказательства компании придают услугам форму; маршрутные доказательства дают сети скелет; отсутствующие доказательства по площадкам определяют риск.

Три ASN Yisu видны, но выполняют разные задачи

Самые жёсткие якоря — записи APNIC и RIPEstat по трём подконтрольным Yisu ASN.APNIC RDAP для AS136970перечисляет «YISUCLOUDLTD-AS-AP - YISU CLOUD LTD» как активную автономную систему Гонконга, зарегистрированную в сентябре 2017 года и последний раз изменённую в январе 2021 года.APNIC RDAP для AS138152перечисляет «YISUCLOUDLTD-HK - YISU CLOUD LTD» как активную, зарегистрированную в августе 2018 года и последний раз изменённую в январе 2021 года.APNIC RDAP для AS142403перечисляет то же имя YISUCLOUDLTD-HK как активное, зарегистрированное в июне 2021 года. Все три записи указывают на одну семью регистрантов Yisu в Гонконге.

RIPEstat подтверждает, что это не спящие метки. Его страницы обзора AS показываютAS136970,AS138152иAS142403как анонсированные на 12 июля 2026 года. Запросы статуса маршрутизации более полезны, потому что дают масштаб:AS136970имел 17 видимых префиксов IPv4,AS138152— 44 видимых префикса IPv4, аAS142403— 70 видимых префиксов IPv4 на момент запроса RIPEstat. В этом представлении у каждого — ноль видимых /48 IPv6. В совокупности это 131 маршрутизируемый эквивалент /24, или 33 536 адресов IPv4 до учёта адресов, зарезервированных, отфильтрованных, арендованных, приостановленных или используемых внутри.

BGP.tools даёт дополнительный внешний взгляд. Егостраница AS136970описывает Yisu как контентную сеть с 17 префиксами IPv4, аплинками через ASLINE и AS142403 и одной записью о нижестоящей сети AS142403. Егостраница AS138152показывает 44 префикса IPv4 и аплинки через Zenlayer, Cogent и China Telecom Next Generation Carrier Network. Егостраница AS142403показывает 70 префиксов IPv4, аплинки через NTT America, AS136970 и HK Kwaifong Group Limited и одну запись о нижестоящей сети AS136970. Эти страницы не являются сертификатами площадок, но они показывают, что публичное интернет-присутствие Yisu не ограничивается одним маршрутом или одним оператором.

Три ASN также намекают на разные роли. AS136970 выглядит как более старая сеть Yisu с меньшим набором префиксов и внутренней связью с AS142403. AS138152 выглядит как сервисная сеть с разнообразным транзитом: Zenlayer, Cogent, China Telecom Backbone и China Telecom Next Generation Carrier Network видны в данных BGP.tools или RIPEstat. AS142403 выглядит как крупнейшая публичная кромка: она несёт много описанных Yisu /24 Гонконга и описанных AFRINIC /24 и соединяется с NTT, HK Kwaifong Group и AS136970. Клиенту не нужно запоминать карту AS.

Она важна, потому что сбои, фильтрация и сроки ремонта могут различаться в зависимости от того, какой AS и какой аплинк-путь обслуживает сервис клиента.

PeeringDB добавляет заметное отсутствие. Запросы дляAS136970,AS138152иAS142403не возвращают ни одной записи сети. Это не доказывает, что у Yisu нет пиринга, площадок или частных соединений. Многие небольшие хостинговые сети не ведут страницу на PeeringDB, а некоторые покупают транзит вместо того, чтобы анонсировать присутствие на биржах. Но это отсутствие оставляет клиентов без публичного списка площадок, бирж, политики трафика и примечаний NOC от PeeringDB. Для покупателя арендуемых мощностей это означает, что публичный интернет видит маршруты, а физический след и межсетевое взаимодействие остаются в основном за витриной.

Смесь адресного пространства указывает на аренду и агрегацию, а не на единый простой пул

Маршрутизируемое адресное пространство Yisu — не единое аккуратное корпоративное выделение. APNIC показывает некоторые диапазоны напрямую у Yisu. Например,39.109.104.0/24находится внутри inetnum APNIC для YISU CLOUD LTD в Гонконге, и маршрутная информация APNIC также показывает происхождение через AS133115.103.100.208.0/24находится в переносимом блоке 103.100.208.0/22 для YISU CLOUD LTD, опять же с записью маршрута APNIC через AS133115. Эти записи полезны, потому что связывают хотя бы часть видимой сервисной поверхности с собственной нумерацией Yisu в APNIC.

У других маршрутов, анонсированных Yisu, более многослойная история.43.225.157.0находится в выделении APNIC, описанном как Better Cloud Limited в Квайчхуне, а не как прямое выделение Yisu.103.142.86.0описан как SHENGYD(HK)LIMITED, с записью маршрута, анонсированной AS138152.103.144.244.0описан как PROSPUR INT'L CO., LIMITED, также с записью маршрута AS138152. Примеры, обслуживаемые AFRINIC, добавляют ещё один слой:154.92.14.0/24описан как Yisu Cloud Ltd в Гонконге и анонсирован AS142403, а156.227.232.0/24описан как Cloud Innovation Ltd со страной RU и описанием маршрута для Yisu Cloud Ltd через AS138152.

Эта смесь обычна на рынке недорогого хостинга и защиты от DDoS. Провайдеры часто сочетают собственное переносимое адресное пространство с арендованным, переданным или маршрутизированным пространством клиентов и партнёров. Операционный вывод прост: рекламируемый запас IP — не то же самое, что постоянно контролируемая вычислительная мощность. Если клиент получает адрес из блока, принадлежащего другому LIR, сервис может работать безупречно, но условия контракта, обработка жалоб о злоупотреблениях, геолокация, авторизация маршрута, репутация и возможности переноса могут зависеть от сторон, помимо Yisu.

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

В записях RDAP есть ещё одно небольшое, но важное предупреждение. Запись контакта для злоупотреблений Yisu содержит пометки о том, что [email protected] недействителен в записях APNIC RDAP дляAS138152иAS142403, с датой последнего изменения записи о злоупотреблениях в марте 2026 года. Это не значит, что до Yisu нельзя добраться через любые каналы поддержки; на сайте указан[email protected] на странице контактов, а клиенты, купившие услугу, используют портал клиента. Но это значит, что публичная гигиена реестра в части обработки злоупотреблений не так сильна, как следовало бы ожидать от хостинг-провайдера, чьи услуги включают отражение DDoS-атак и клиентские IP-ресурсы.

Гигиена адресного пространства — не просто бюрократия. В облачном сервисе репутация IP может решить, доставят ли письмо клиента, примет ли платёжный шлюз трафик, разрешит ли CDN доступ к источнику, не сместит ли поисковая система сайт в другой регион и дойдёт ли жалоба о злоупотреблении до человека до того, как маршрут отфильтруют. Видимый маршрутный масштаб Yisu значим. Смесь прямых, партнёрских и обслуживаемых AFRINIC описаний означает, что клиентам стоит спросить, что они смогут сохранить, перенести или заменить, если контракт с провайдером или передача IP изменится.

Обещания продуктов быстро превращаются в физические зависимости

СтраницаElastic Cloud Computingу Yisu продаёт гибкий выбор CPU, памяти, пропускной способности и хранилища и говорит, что облачные ресурсы можно масштабировать горизонтально и вертикально. Это коммерческое удобство облачного хостинга. Физический вопрос в том, что происходит, когда многие клиенты одновременно хотят один и тот же ресурс в одном месте. Горизонтальное масштабирование требует запасной ёмкости хостов, запасных портов коммутаторов, достаточного запаса публичных или частных IP и серверных хранилищ, способных принять новую нагрузку ввода-вывода. Вертикальное масштабирование требует ёмкости гипервизора или миграции на более крупный хост. Ни то, ни другое не гарантируется одним лишь выбором продукта.

На той же странице есть заявления о надёжности: доступность сервиса до 99,95 % и надёжность данных не ниже 99,9999 %, защита данных RAID, снимки, собственные сети и функции безопасности. Клиенту стоит читать их как заявления о конструкции сервиса, а не как доказательство проверенного региона. RAID защищает от некоторых сбоев дисков, но не защищает от потери питания целой стойки, отказа плоскости управления, сбоя контроллера хранилища, ошибки оператора, неудачного восстановления из снимка или сетевого сбоя, из-за которого клиент потеряет доступ к данным.

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

СтраницаBare Metal Serverещё сильнее привязана к физическим ограничениям. Она рекламирует выделенные серверы в среде одного арендатора, быстрое развёртывание, круглосуточную эксплуатацию и обслуживание, физическую изоляцию, избыточность данных RAID10, технологию многоканальной сети и сетевую изоляцию. Bare metal привлекателен тем, что клиент избегает накладных расходов виртуализации и риска «шумных соседей». Но он менее эластичен, чем виртуальный сервер, когда запас оборудования ограничен. Отказ bare metal может потребовать запасного шасси, совместимых дисков, ручной диагностики, доступа удалённых рук или переустановки ОС. Если у Yisu есть запасное оборудование в той же площадке, восстановление может быть быстрым. Если приходится ждать визита на площадку или запчасть, ремонтное окно становится продуктом.

СтраницаRDS for MySQLговорит, что сервис баз данных использует корпоративное SSD-хранилище, высокую доступность, разделение чтения и записи, гибкие резервные копии и развёртывание первичного и вторичного узлов на разных серверах. Такая архитектура снижает риск отказа одного сервера, но порождает новые вопросы зависимости. Находятся ли основной и резервный узлы в разных стойках, разных доменах электропитания или только на разных хостах? Хранятся ли резервные копии в другом кластере хранения? Может ли клиент выгрузить рабочий дамп во время инцидента или только через рабочую панель управления? Сохраняет ли фейловер учётные данные приложения и конечные точки подключения? Управляемый сервис баз данных удобен именно потому, что скрывает эту механику. Покупателю всё равно нужен план переносимости.

СтраницаElastic Load Balancerпродаёт балансировку на уровнях L4 и L7, проверки здоровья, постоянство сессий и резервированную конструкцию. Сильнейшее применение балансировщика — поглощать отказ отдельного сервера. Слабейшее — размещать все инстансы клиента за балансировщиком, который сам зависит от одной площадки, одного аплинк-пути, одного аккаунта или одной плоскости управления. На странице Yisu сказано, что активация и деактивация сервисных узлов не влияют на текущий сервис. Это правдоподобно для хорошо спроектированного кластера, но публичная страница не сообщает, по каким площадкам распределён кластер и можно ли балансировать рабочие нагрузки клиента между регионами.

СтраницаAnti-DDoS IP— самый сетевозависимый продукт из всех. Она рекламирует большую ёмкость очистки от DDoS, скрытие реального IP, поддержку TCP/UDP/HTTP/HTTPS, защиту от DNS-флуда и поддержку 24/7. На странице есть и формулировки вида «свыше 5000 GB» и «1000G+», которые стоит читать внимательно: маркетинговые страницы часто смешивают общую ёмкость платформы, уровни продуктов и пиковые значения очистки в лучшем случае. Защита от DDoS — это не только число в гигабитах. Она зависит от чистой вышестоящей ёмкости, точек очистки, контроля ложных срабатываний, скорости маршрутизации, покрытия типов атак и от того, сможет ли клиент уйти, если защищённый IP заблокируют или он насытится.

Гонконг — публичный якорь, а глобальные мощности проверить сложнее

Юридические и сетевые записи Yisu прочно привязаны к Гонконгу. APNIC RDAP перечисляет YISU CLOUD LIMITED как гонконгскую организацию с адресом в World Peace Centre, Wo Tong Tsui Street, Kwai Chung, а записи whois APNIC для блоков IP, принадлежащих Yisu, повторяют те же гонконгские контактные данные. Публичный сайт Yisu также говорит, что её глобальная стратегия включает Гонконг, и карта локаций выделяет Гонконг среди других регионов. Гонконгский якорь правдоподобен.

Менее ясно, какая часть каталога услуг приходится на собственные стойки Yisu, арендованные кабинеты, арендованные серверы, реселлерские контракты или партнёрские мощности в каждой рекламируемой локации.

Гонконг — правдоподобное место для такого бизнеса. Государственный портал дата-центров называет Гонконг одним из лучших мест для дата-центров благодаря надёжной связи, внешним подводным кабельным системам, либерализованному рынку телекоммуникаций, примерно 300 лицензированным широкополосным провайдерам, высокой надёжности электроснабжения, свободному потоку информации и закону о защите конфиденциальности данных. СтраницаData Centre Facilitationна сайте Digital Policy Office говорит, что правительство поддерживает дата-центры как ключевую инфраструктуру для финансов, торговли, логистики и облачных вычислений, и отмечает, что участок кластера дата-центров Sandy Ridge был выделен в марте 2026 года. На той же странице сказано, что Гонконг выигрывает от надёжного электроснабжения, хорошей телекоммуникационной инфраструктуры и низкого риска стихийных бедствий.

Предложение не лишено ограничений. В ответе Законодательного совета от июня 2024 года оплощадях, пригодных для дата-центров, сказано, что в Гонконге на тот момент было около 970 000 квадратных метров площади дата-центров, оценён спрос операторов на ближайшую и среднесрочную перспективу примерно в 300 000 квадратных метров и ожидалось, что к 2026 году общая площадь достигнет 1,5 миллиона квадратных метров. В том же ответе обсуждались переоборудование промышленных зданий, реконструкция, высота потолков, несущая способность, пожарная безопасность, безопасность, канализация, парковка, лифты, туалеты, электроснабжение и резервные генераторы как практические вопросы. Это и есть физический мир за продуктовой сеткой облачного провайдера.

Для Yisu публичные доказательства не привязывают каждый рекламируемый регион к названным площадкам. Быстрые предложения на главной странице упоминают Токио, Франкфурт, Вашингтон и Лос-Анджелес, а страница «О компании» называет США, Германию, Бангкок, Индию, Южную Корею, Японию, Гонконг, Сингапур, Индонезию и Австралию с пометками «активировано», «строится» и «планируется». Это полезные коммерческие сигналы, но их не стоит превращать в независимые зоны доступности без дальнейших доказательств.

Ярлык региона может означать собственные стойки, арендованные выделенные серверы, виртуальные мощности третьей стороны, точку очистки от DDoS или локацию заказа в интерфейсе.

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

Он рискован, когда покупатель не может сказать, кто контролирует домен отказа.

Разнообразие транзита существует, но это не то же самое, что разнообразие площадок

Маршрутизация Yisu не сводится к одному аплинку в простейшем смысле. Представление соседейAS138152в RIPEstat показывает четырёх наблюдаемых соседей на 12 июля 2026 года: AS174, AS21859, AS4134 и AS4809. BGP.tools на своей публичной странице для AS138152 обозначает их как Cogent, Zenlayer, China Telecom Backbone и China Telecom Next Generation Carrier Network. Это значимая смесь для хостинг-провайдера, ориентированного на Гонконг и Китай. Она говорит, что Yisu может достигать клиентов через глобальный транзит, транзит, ориентированный на хостинг, и пути, связанные с China Telecom.

У AS142403 другая форма. Представление соседейAS142403в RIPEstat показывает AS133115, AS136970 и AS2914 слева, а AS136970 также появляется справа. BGP.tools определяет эти видимые аплинки как HK Kwaifong Group Limited, собственный AS136970 Yisu и NTT America. AS136970, в свою очередь, появляется в представлении соседейRIPEstatс AS142403 и AS18013, которые BGP.tools определяет как Yisu и ASLINE. В результате получается сеть, где ASN Yisu взаимозависимы, а внешний транзит различается в зависимости от ASN.

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

Клиент, видящий AS138152 подключённым к Zenlayer, Cogent и China Telecom, всё равно должен знать, подключён ли его сервер к резервируемым коммутаторам верхнего уровня стойки, выходят ли эти коммутаторы через отдельные маршрутизаторы и может ли окно обслуживания на одной площадке убрать всю практическую доступность.

Маркетинг Yisu, ориентированный на Китай, делает это особенно важным. Главная страница и страница «О компании» неоднократно упоминают полосу в стиле CN2 и быстрые пути возврата к пользователям в Китае. Видимость China Telecom Next Generation Carrier Network на AS138152 поддерживает идею, что китайский транзит важен для сервиса. Она не доказывает сквозную производительность из каждого рекламируемого города или из каждой материковой сети доступа. Китайские маршруты могут быть ценными, перегруженными, фильтруемыми, дорогими или ограниченными контрактом в зависимости от канала и провайдера.

Сервис, который хорошо работает для гонконгского клиента, может вести себя иначе для материкового предприятия, пользователя из Юго-Восточной Азии или североамериканского источника.

Публичное отсутствие в PeeringDB тоже здесь важно. Страница PeeringDB могла бы перечислить биржи, площадки, политику трафика и контакты NOC. Отсутствие записей для трёх ASN Yisu оставляет публичные доказательства транзита разбросанными по BGP-инструментам и записям реестра. Само по себе это не делает сеть слабой. Это делает проверку клиента более ручной. Покупателю стоит спросить, какой AS будет анонсировать его сервисный IP, какие аплинки будут его нести, проверялся ли фейловер, меняет ли защита от DDoS путь и может ли Yisu перенести маршрут или сервис в другой регион без принудительной пересборки.

Поддержка и биллинг — часть инфраструктуры

Сайт Yisu продаёт технический контроль, но сервис зависит и от административных систем. Главная страница продвигает консоль, развёртывание в один клик, графики мониторинга, управление конфигурацией и техническую поддержку 24/7/365.Страница контактовдаёт адрес поддержки и веб-форму. Продуктовые страницы ведут клиентов к ссылкам регистрации, входа, биллинга, пополнения и консоли. В модели недорогого хостинга эти системы не вторичны. Если выйдет из строя биллинг, верификация аккаунта или панель управления, клиент может не суметь продлить сервер, заменить IP, открыть тикет, расширить хранилище или восстановиться после приостановки.

Глубина поддержки особенно важна, потому что Yisu продаёт и виртуальные, и физические продукты. Виртуальные серверы часто можно перезапускать, переустанавливать или изменять через автоматизацию. Bare metal может требовать ручной работы. Защита от DDoS может требовать анализа трафика в реальном времени и настройки маршрутов. Управляемый MySQL может требовать восстановления из резервной копии, решений о фейловере и разбора производительности. Балансировка нагрузки может требовать исправления проверок здоровья или замены сертификата.

Провайдер может рекламировать поддержку 24/7, но настоящий показатель — может ли поддержка изменить что-то на стойке, на маршрутизаторе или в аккаунте клиента во время живого инцидента.

Примечание о здоровье контактов в APNIC не стоит переоценивать, но и игнорировать его не стоит. Пометка RDAP о том, что контакт [email protected] недействителен, не обязательно описывает поддержку клиентов. Однако она показывает, что публичный контакт для злоупотреблений, прикреплённый к ресурсам APNIC Yisu, имеет проблему валидации. Хостинг-провайдеры живут с жалобами о злоупотреблениях каждый день: скомпрометированные серверы, фишинговые страницы, сканеры, узлы командования DDoS, спам, подбор учётных данных, открытые прокси и бот-трафик.

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

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

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

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

Локализация и суверенитет данных требуют плана со стороны покупателя

Вопрос локализации из постановки задачи централен для Yisu, потому что её маркетинг охватывает Гонконг, материковый Китай, Азиатско-Тихоокеанский регион, Европу и США, а её юридические и сетевые записи прочно привязаны к Гонконгу. Локализация данных — не только то, где зарегистрирована компания. Это то, где выполняются рабочие нагрузки, где лежат резервные копии, где сотрудники поддержки могут получить доступ к данным, где очищается DDoS-трафик, какие законы регулируют передачу и что происходит, когда клиенту нужно доказательство.

Гонконгский государственный портал дата-центров подчёркивает свободный поток информации и Ордонанс о персональных данных (Personal Data (Privacy) Ordinance) как преимущества для операторов дата-центров. Комиссар по защите персональных данных также опубликовалруководство по облачным вычислениям, предупреждающее пользователей данных о необходимости проверять облачных провайдеров и учитывать договорную защиту, субподряд, безопасность, доступ к данным, хранение и трансграничную передачу. Это руководство написано для клиентов, а не только для провайдеров. Ключевой момент для покупателей Yisu: заявление об облачной услуге само по себе не отвечает на вопросы локализации.

Продуктовые страницы Yisu не публикуют график обработки данных по регионам. Они не говорят, остаются ли резервные копии управляемого MySQL в той же локации, реплицируются ли снимки за пределы региона, меняет ли очистка от DDoS юрисдикционный путь трафика, могут ли сотрудники поддержки получать доступ к дискам клиента из-за пределов Гонконга и может ли клиент договорно закрепить данные за выбранным регионом. Некоторым небольшим клиентам это неважно. Для клиентов из финансов, здравоохранения, госуслуг, регулируемой электронной коммерции, игр, рекламных технологий или связанных с материком операций эти детали имеют значение.

Смесь адресного пространства усложняет геолокацию. Некоторые блоки, анонсированные Yisu, — это пространство APNIC, описанное как Гонконг. Некоторые — диапазоны, обслуживаемые AFRINIC, с гонконгскими, российскими или другими описаниями в whois. Некоторые описаны под другими гонконгскими компаниями, но анонсированы Yisu. Вендоры геолокации могут привязывать эти адреса по-разному. Клиент может купить «гонконгский» сервис и обнаружить, что инструменты борьбы с мошенничеством, рекламные платформы или платёжные процессоры читают IP как другую юрисдикцию, пока базы данных не обновятся.

Это не обязательно вина Yisu, но это предсказуемая операционная проблема для хостинг-провайдеров со смешанными IP-пулами.

Суверенитет данных также пересекается с выходом клиента. Клиенту, которому нужно доказать локализацию, не следует полагаться на выпадающий список локаций в продукте. Он должен хранить независимые резервные копии, документировать, где заказан сервис, записывать назначенные IP-диапазоны и ASN, просить письменные заявления о месте хранения резервных копий и доступе поддержки и тестировать восстановление в другом провайдере. Сетевые и продуктовые доказательства Yisu делают её правдоподобным кандидатом для некоторых сценариев аренды. Они не снимают с клиента обязанность проверить, где на самом деле лежат данные, журналы и копии резервных копий.

Сценарии отказов, которые вскрывают скрытый физический слой

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

Второй сценарий — отказ аплинка или маршрута. У AS138152 несколько видимых соседей, но не каждый префикс клиента обязательно выигрывает одинаково. Набор путей AS142403 другой, а AS136970 частично зависит от AS142403. Утечка маршрута, фильтрация, обрыв кросс-коннекта, контрактный спор или изменение защиты от DDoS могут затронуть один ASN или группу префиксов, оставив другую здоровой. Поэтому клиентам стоит мониторить именно свой назначенный префикс и AS, а не только основной домен провайдера. Сервер может работать, пока маршрут к нему болен.

Третий сценарий — исчерпание запаса оборудования. Yisu продаёт недорогую эластичность и bare metal. Если локация распродана, страница покупки может остаться, но выделение замедлится, заменяющее оборудование может отличаться, а ремонт может зависеть от доставки запчастей. СтраницаBMSрекламирует автоматическое выделение, установку ОС и подключение дисков после покупки. Это полезно, когда запас есть. Это хрупко, когда запас исчерпан или когда конкретный CPU, память, SSD или уровень пропускной способности больше недоступны в запрошенной площадке.

Четвёртый сценарий — перегрузка поддержки. DDoS-трафик, жалобы о злоупотреблениях, фильтрация аплинков и проблемы панели управления могут создать много тикетов одновременно. СтраницаAnti-DDoS IPYisu говорит, что сервис может скрывать исходный IP, поддерживать несколько протоколов и предоставлять индивидуальные стратегии. Во время реальной атаки клиенту нужна быстрая настройка: контроль ложных срабатываний, изменение защищаемого домена, блокировка источника, изменение маршрутов и очистка после атаки. Если поддержка тонкая, обещанная ёмкость очистки может не превратиться в рабочее восстановление для каждого клиента.

Пятый сценарий — блокировка из-за биллинга или аккаунта. Предоплаченный хостинг-клиент может потерять доступ из-за баланса, проверки рисков, обработки злоупотреблений, отказа платёжного канала или реселлерского статуса. Такой сбой не виден в BGP. Но он может быть фатальным, если клиент не может продлить, экспортировать, сделать снимок или открыть тикет. Публичные страницы Yisu не описывают льготные периоды при прекращении обслуживания или условия хранения данных. Клиентам стоит исходить из того, что нужны резервные копии вне платформы и контроль над DNS.

Шестой сценарий — неудачная миграция. Страницы Yisu упоминают снимки, резервные копии, плавную миграцию и гибкую конфигурацию. Это ценно только если клиент их проверил. Услуга, работающая годами, может накопить локальные зависимости: правила межсетевого экрана, частные сети, белые списки IP, конечные точки баз данных, SSL-сертификаты, анти-DDoS фронтенды и мониторинг, привязанный к специфичным для Yisu элементам управления. Сбой провайдера становится гораздо хуже, когда клиент обнаруживает, что его собственная архитектура не может переехать.

Что усилило бы операционные заявления Yisu

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

Помогло бы и раскрытие транзита. BGP-доказательства Yisu уже показывают несколько путей аплинков, но клиентам нужно знать, как эти пути соотносятся с продуктами. Облачный сервер на AS142403 может иметь другой набор аплинков, чем сервер на AS138152. Защищённый от DDoS IP может идти через сеть очистки, прежде чем достигнет источника. Продукт bare metal может быть привязан к другой площадке, чем лёгкий сервер. Страница для клиентов с указанием того, какой AS и какая смесь транзита действуют по локациям, снизила бы неопределённость без раскрытия чувствительных операционных деталей.

Раскрытие управления IP было бы ценно, потому что видимый набор маршрутов Yisu включает прямые блоки Yisu, блоки APNIC, описанные партнёрами, и диапазоны, обслуживаемые AFRINIC. Клиентам стоит знать, переносимы ли назначенные IP внутри Yisu, можно ли быстро выдать замену, поддерживается ли корректировка геолокации, обрабатываются ли уведомления о злоупотреблениях через проверенный почтовый ящик и вызывают ли проблемы репутации IP приостановку или исправление. Для многих небольших хостинг-клиентов непрерывность IP так же важна, как непрерывность CPU.

Больше всего значили бы доказательства восстановления. Публичные сводки инцидентов, история обслуживания, цели восстановления, условия хранения резервных копий, окна замены bare metal и процедуры экспорта полезнее, чем общий процент надёжности. Провайдер может честно предлагать доступность сервиса 99,95 % и всё равно оставить одного клиента без возможности быстро восстановить базу данных. Клиентам нужна не только математика доступности; им нужно доказательство, что фейловер и восстановление репетировались.

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

Главный вывод

YISU CLOUD LTD — реальный публичный субъект в инфраструктурной сфере. Её сайт продаёт широкий облачный и хостинговый каталог, записи APNIC связывают несколько активных ASN с компанией, RIPEstat видит 131 видимый IPv4 /24 по трём ASN Yisu на 12 июля 2026 года, а BGP.tools показывает нетривиальное разнообразие аплинков. Это не провайдер-призрак.

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

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

В YISU CLOUD LTD, как и у любого хостинг-провайдера, сервис в конечном счёте держится на стойках, транзите и людях, которые могут чинить, когда панели управления уже недостаточно.