Nine Cloud заявляет о 40 узлах POP и магистрали 2,9 Тбит/с, а публичный интернет показывает только два /24

Кратко

• На сайте Nine Cloud заявлено более 40 собственных POP-узлов в дата-центрах, более 2,9 Тбит/с полностью связанных частных магистральных линий и продукты с полосой для клиентов от 1 Мбит/с до 100 Гбит/с. Эти цифры описывают предложение, но ни один публичный перечень площадок, реестр каналов, схема энергоснабжения или независимый тест не демонстрирует установленную или доступную ёмкость.
• AS131495 активна и 15 июля 2026 года анонсировала два блока IPv4 /24. Один — зарегистрированный в Китае блок с одной видимой соседней сетью; второй — половина блока /23 гонконгской компании, видимая через две соседние сети. Это свидетельство живой маршрутизации, а не доказательство 40 физически разнесённых узлов POP.
• История лицензий, действующий сайт компании, работающий инструмент замера задержек и участие в публичной закупке 2024 года подтверждают продолжающуюся коммерческую деятельность. Но они не устанавливают текущее владение активами, операционную ответственность за дата-центры, устойчивость энергоснабжения, клиентскую нагрузку, доступный резерв или показатели восстановления.

Два взгляда на одну сеть

Центральное число в публичной презентации Nine Cloud — не номер автономной системы. Это «2.9T+», указанное наглавной страницекомпании рядом с «40+» узлов POP в дата-центрах, уведомлениями об инцидентах каждые 15 минут и доступностью частных магистральных линий 99,95 %. Ниже на странице компания сообщает, что эти узлы POP — собственные, охватывают большинство городов Китая первой и второй категории и позволяют предоставлять полосу от 1 Мбит/с до 100 Гбит/с. Она предлагает корпоративные частные сети по схемам «точка–точка», «звезда» и «полносвязная», подключения между публичными облаками и площадками клиентов, физические или виртуальные серверы, а также услугу «IDC Plus» для индивидуальных требований к дата-центру.

Число, видимое из публичного интернета, меньше: два маршрута IPv4 /24, то есть 512 адресов в сумме, анонсирует AS131495 вснимке RIPEstat за 15 июля 2026 года. Видимых маршрутов IPv6 нет. Один /24, 123.58.18.0/24, находится в адресном пространстве, зарегистрированном на пекинскую компанию. Второй, 103.175.197.0/24, входит в блок /23, зарегистрированный на HK JIUYUN INFINITE TRADE LIMITED. Коллекторы маршрутов видели три непосредственно соседние сети в пределах двух префиксов, но не все три на каждом префиксе.

Эти числа не исключают друг друга. Оператор частных линий может арендовать длины волн, каналы Ethernet, стойки и доступ «последней мили», не анонсируя в BGP каждый клиентский канал. В узле POP может стоять маршрутизатор и кросс-коннекты, при этом используемые адреса анонсируются из другого места. Коммерческий запас в 2,9 Т может суммировать законтрактованные скорости передачи, а не транзит публичного интернета.

И наоборот, общенациональная карта узлов может преувеличивать независимость, если многие узлы используют общего оператора связи, общего владельца площадок, общую кабельную канализацию, общий источник электропитания, единую систему управления или один контракт с вышестоящим оператором. Дело не в том, что BGP должен показывать 2,9 Тбит/с. Дело в том, что публичные данные не преодолевают разрыв между маркетинговым итогом и физической системой, которая должна этот итог нести.

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

Компания, стоящая за названием

Юридическая и операционная история начинается с полезного предупреждения о преемственности. Взапросе Шанхайской фондовой биржи2015 года о покупке другой компанией Beijing Senhua Yiteng спрашивалось, почему Senhua передала свою полностью принадлежавшую ей дочернюю компанию Nine Cloud господину Hong Lei непосредственно перед сделкой. В опубликованномответе, воспроизведённом в Securities Times, сообщалось, что Senhua учредила Nine Cloud в июле 2013 года, что Hong Lei был её юридическим представителем и что к концу 2014 года компания фактически не вела деятельность. Senhua передала доли Hong в январе 2015 года без денежного возмещения, одновременно зачтя внутригрупповое сальдо, чтобы обеспечить ему площадку для развития после ухода из Senhua.

Собственнаяистория развитияNine Cloud отсчитывает начало коммерческой деятельности с апреля 2015 года, с версии 1.0 продукта EDPN. Далее в ней заявлены последовательно полученные квалификации в областях IDC, ISP, ICP, VPN и фиксированной передачи данных; собственный номер автономной системы; продукт multi-line BGP; лицензия CDN; гонконгская компания; общенациональный мониторинг; периферийные серверы; подключение к ханчжоуской бирже обмена трафиком; защита через двух операторов; шэньчжэньский филиал; и наконец второй магистральный маршрут. Прочитанные вместе, раскрытие для биржи и хронология компании описывают бизнес, который был неактивен под первоначальной материнской структурой, отделился в 2015 году, а затем построил собственную операционную идентичность.

Это разделение важно. Выручка, мощности, клиентские контракты и операционная история, приписываемые Senhua Yiteng в сделке 2015 года, не могут быть автоматически перенесены на Nine Cloud. В ответе прямо различались компании и сообщалось, что до передачи Nine Cloud не вела деятельности. Поэтому любая более поздняя ёмкость должна подтверждаться собственными контрактами Nine Cloud: её оборудованием, арендой, лицензиями и маршрутами. В открытых источниках есть некоторые из этих слоёв, но не полный след активов.

Агрегатор коммерческих реестров в настоящее время указывает, что китайская компания учреждена 2 июля 2013 года, с единым кодом социального кредита 91110108071674731C и уставным капиталом 30 млн юаней. Там же указаны регистрация в Пекине и широкий профиль деятельности, связанной с телекоммуникациями. Этазапись агрегатораполезна для первичного поиска, но не заменяет свежую заверенную выписку из реестра. Публичные страницы расходятся в отношении текущего юридического представителя и точного номера зарегистрированного помещения. Настранице контактовNine Cloud указан головной офис в Пекине — комнаты 325–331 в Enji Xiyuan, и офис в Шэньчжэне в Honglong Century Plaza. Адреса офисов показывают, где связаться с поставщиком; это не адреса дата-центров и не доказательство владения оборудованием.

Есть признаки более свежей активности. В список предложенных технологических малых и средних предприятий Пекина на 2023 год компания включена в районе Хайдянь. В сентябре 2024 годазакупочное извещение CNOOCпоставило Nine Cloud на второе место среди трёх кандидатов на обслуживание и техническую поддержку ИТ-коммуникационной сети международной компании, с ценой заявки 4 375 680 юаней и баллом 56,22. Статус допущенного кандидата подтверждает, что компания участвовала в тендере на корпоративные сетевые работы. Но это не показывает, что она выиграла контракт, оказала услугу, владела соответствующей инфраструктурой или достигла конкретного показателя доступности.

Широкий набор разрешений — не реестр активов

История лицензирования Nine Cloud довольно обширна. В официальном списке Министерства промышленности и информатизации КНР на конец 2017 года компания значилась по лицензии A2.B1-20170249 на услуги сети распространения контента в Пекине и провинции Шаньдун. Отраслевые сообщения говорили, что в 2018 году она получила разрешения и на CDN, и на облачные сервисы. В публичных копиях более поздних лицензионных извещений видны изменение состава услуг, продление в 2021 году и смена юридического представителя в 2023 году.

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

Различие между разрешением и реализацией прямо прописано в китайских правилах электросвязи. Вкаталоге классификации услуг 2015 годаMIIT услуга IDC определяется как использование соответствующих машинных залов для размещения, обслуживания и управления оборудованием клиентов, аренды серверов и систем хранения, а также организации линий связи и исходящей полосы пропускания. Облачная кооперация интернет-ресурсов определяется как использование оборудования и ресурсов, установленных в дата-центрах. Услуга CDN определяется вокруг распределённых групп серверов-узлов. Лицензия означает, что компания вправе вести указанную деятельность на указанных условиях; она не раскрывает, какие здания компания использует, владеет ли она ими или арендует, какая ИТ-нагрузка запитывается и какая ёмкость уже законтрактована.

Извещение MIIT 2017 годао наведении порядка на рынкеужесточает этот тезис. Оно нацелено на нелицензированную и выходящую за рамки лицензии деятельность IDC, ISP и CDN, неавторизованное использование ресурсов и многоуровневую перепродажу. Оно требует, чтобы инфраструктура, IP-адреса и полоса пропускания поступали от должным образом лицензированных поставщиков, и ограничивает неавторизованные трансграничные каналы. Регуляторная модель, таким образом, предполагает цепочку поставок: корпоративный поставщик услуг может сочетать собственные сетевые элементы с мощностями и каналами, полученными от базовых операторов и других лицензированных операторов.

Сайт Nine Cloud описывает именно такое смешанное предложение. В нём говорится, что компания может предоставлять полосу China Telecom, China Unicom, China Mobile и BGP, физический хостинг серверов, виртуальные машины, доступ в городах и магистральные частные линии. Такая формулировка не называет владельца каждой стойки, оптического пролёта или системы питания. И надпись «собственный узел POP» не должна автоматически читаться как доказательство владения дата-центром.

Собственный маршрутизатор в арендованной стойке, внутри стороннего объекта и подключённый арендованными каналами оператора может быть операционно значимым, но при этом оставлять критические физические зависимости вне контроля Nine Cloud.

Именно поэтому в поле «регион» статьи указан Азиатско-Тихоокеанский регион. Компания сообщает, что её гонконгский бизнес расширился на более чем десять зарубежных территорий и работал с международными операторами. Гонконгский адресный блок и международные соседства подтверждают некоторую трансграничную связанность. Но они не устанавливают наличие глобального парка контролируемых компанией объектов или местных операционных команд. Глобальная доступность может обеспечиваться через вышестоящих операторов или партнёров; это не свидетельство глобального физического присутствия.

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

Что доказывает AS131495

Самое сильное независимое свидетельство — сетевая идентичность. Взаписи RDAP для AS131495от APNIC указано имя «Nine-cloud», описание Beijing Nine Cloud Infinite Network Technology и место регистрации — Китай. Номер зарегистрирован 26 апреля 2017 года, остаётся помеченным как активный и последний раз изменялся 28 ноября 2023 года. Административный и технический контакт — Hong Lei, чей объект последний раз изменялся в 2017 году. Эти записи подтверждают делегированный контроль над номером автономной системы и напрямую связывают его с пекинской компанией. Но они не показывают, кто сейчас настраивает маршрутизаторы и подписывает контракты с операторами.

Текущая таблица маршрутизации показывает две разные истории ресурсов. Взаписи 123.58.16.0/21от APNIC указано имя Nine-cloud, описание пекинской компании, и блок помечен активным в Китае. AS131495 в настоящее время анонсирует из него один /24 — 123.58.18.0/24. Второй видимый маршрут, 103.175.197.0/24, — половина блока103.175.196.0/23, активного гонконгского выделения, зарегистрированного на HK JIUYUN INFINITE TRADE LIMITED. Общий контактный доменjywx.comи общее имя «Jiuyun» позволяют предположить коммерческую связь, но в просмотренных открытых записях нет документа о корпоративном владении, связывающего гонконгскую компанию с пекинской. Безопасная формулировка такова: пекинская ASN анонсирует адресное пространство, зарегистрированное на гонконгский субъект.

Разделены и авторизации происхождения маршрутов.Результат валидации RPKI для 103.175.197.0/24в RIPEstat — valid для AS131495. Аналогичныйрезультат для 123.58.18.0/24— «unknown», то есть валидатор не нашёл применимой авторизации происхождения маршрута. Unknown — это не invalid: сети, отклоняющие маршруты RPKI-invalid, не должны отклонять маршрут со статусом unknown только из-за этого статуса. Тем не менее клиент, оценивающий безопасность маршрутизации, захочет узнать, намерена ли Nine Cloud создать действительную авторизацию для китайского маршрута и как она ведёт объекты маршрутов в разных регистратурах.

Истории двух префиксов тоже разные. История маршрутизации RIPEstat показывает, что AS131495 анонсировала весь блок 123.58.16.0/21 в части 2020 года, затем периодически объявляла 123.58.18.0/24 с 2022 года и снова непрерывно в наблюдаемом периоде с апреля 2026 года. Гонконгский /24 анонсировала AS136897 в 2023 году и начале 2024 года, прежде чем в феврале 2024 года источником стала AS131495, остававшаяся видимой до 15 июля 2026 года. Эта история демонстрирует смену контроля над маршрутизацией.

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

Живой маршрут — свидетельство достижимости, но плохой измеритель ёмкости. За /24 может стоять порт 1 Гбит/с или множество более крупных каналов. Он может обслуживать небольшой сервис или пропускать трафик сетевых функций, которым не нужно много публичных адресов. И наоборот, бизнес частных линий может нести большие объёмы, которые никогда не появляются как клиентские маршруты, анонсируемые собственной ASN. Защищаемый вывод узок: AS131495 активна, имеет небольшой видимый след анонсов IPv4 и не имеет видимых анонсов IPv6. Ничто в этом выводе не подтверждает и не опровергает цифру 2,9 Т частной магистрали компании.

Три соседа — не три независимых маршрута

Снимок состояния BGPв RIPEstat показал чёткое разделение по префиксам. Для 123.58.18.0/24 в путях коллекторов непосредственно перед AS131495 стоит AS24138, China TieTong Telecommunications Corporation. Для 103.175.197.0/24 непосредственно перед AS131495 стоит либо AS984, Octopus Web Solution, либо AS136897, EnjoyVC Cloud Group. Всводке по AS131495Hurricane Electric независимо перечислены те же три наблюдаемых соседа и те же два анонсируемых /24.

Это полезное свидетельство логического разнообразия для гонконгского маршрута. На уровне политики BGP более чем одна внешняя AS может распространять 103.175.197.0/24. Но это не показывает двух входов в здание, двух meet-me-комнат, двух владельцев волокна, двух подводных кабельных систем, двух энергосистем или даже двух маршрутизаторов. AS984 и AS136897 могут входить в один объект, пользоваться одним провайдером кросс-коннектов или сходиться на общем вышестоящем операторе дальше по цепочке.

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

У китайского /24 другое ограничение. В снимке непосредственно соседней была только AS24138. Более широкий охватывающий маршрут 123.58.16.0/20 анонсировала AS23724, пекинская сеть IDC China Telecom. Сайт Nine Cloud разрешается в адрес 123.58.16.244 — внутри зарегистрированного на компанию /21, но вне более специфичного /24. Поэтому RIPEstat относит адрес сайта к охватывающему маршруту China Telecom, а не к AS131495. Это легитимная схема маршрутизации. Но она иллюстрирует, почему регистрацию адресов, происхождение маршрута, веб-хостинг и физическое размещение серверов нельзя сводить к одному понятию.

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

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

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

Единственный публичный порт обмена трафиком

У Nine Cloud есть профиль в PeeringDB для AS131495. Взаписи сетиуказана пекинская компания, действует селективная политика пиринга и перечислено одно операционное подключение к NNIX в Ханчжоу. Порт записан как IPv4-адрес 103.164.64.125 со скоростью 1000 Мбит/с. IPv6-адрес, участие в route server и сведения о площадках не указаны. Подключение к бирже последний раз обновлялось 4 января 2022 года, общая запись сети — 26 октября 2022 года.

Это конкретное свидетельство, но с жёсткими ограничениями. PeeringDB наполняется самими участниками, запись устарела, а флаг «operational» — не живой поток телеметрии. Связаннаязапись о бирже NNIXуказывает, что биржа находится в Ханчжоу, но не перечисляет площадки и не даёт публичного URL фидов участников. Порт биржи 1 Гбит/с также не может подтвердить магистральную ёмкость 2,9 Т. Это может быть небольшой пиринговый интерфейс, устаревшая запись, управленческий канал или лишь один край среди множества частных соединений.

На странице развития компании сказано, что она присоединилась к ханчжоускому национальному центру обмена трафиком и стала членом национального комитета по межсоединениям. Запись в PeeringDB подтверждает участие в бирже под названием NNIX, но не более широкую институциональную формулировку. Она не доказывает расположение маршрутизатора Nine Cloud в Ханчжоу, владельца стойки, путь кросс-коннекта, уровень трафика или текущее состояние порта. PeeringDB не сообщает ни о раскрытом уровне трафика, ни о looking glass, ни о route server, ни о наборе IRR, ни о площадках межсоединения.

Из-за скудного профиля отсутствие IPv6 становится более значимым. Nine Cloud продаёт корпоративную связь, облачные каналы, хостинг и услуги, связанные с CDN, — всё это всё чаще упирается в требования двойного стека. Публичная ASN сейчас не анонсирует ни одного префикса IPv6, и у указанного интерфейса NNIX нет IPv6-адреса. Клиенты всё же могут получать IPv6 через другого оператора или сервисную ASN, но в открытых материалах об этом не сказано.

В спецификации закупки следует требовать чёткого ответа: нативный двойной стек, туннелируемый сервис, IPv6 от вышестоящего оператора или только IPv4; размер выделенного адресного блока; безопасность маршрутизации; поведение при переключении.

Сорок точек — коммерческая карта, а не схема маршрутов

Nine Cloud эксплуатирует отдельныйинструмент замера задержек EDPN. 15 июля 2026 года он вернул длинный выбираемый список городов «core POP», включая Пекин, Шицзячжуан, Чжэнчжоу, Ухань, Чанша, Гуанчжоу, Шэньчжэнь, Сямэнь, Фучжоу, Нинбо, Ханчжоу, Шанхай, Нанкин, Чэнду, Чунцин, Шэньян, Харбин, Куньмин, Наньнин, Циндао, Хуэйчжоу, Чжаньцзян и Хайкоу. Также там были названы несколько пекинских и шанхайских дата-центров. На главной странице компании отображались справочные задержки для пар городов, например Пекин–Тяньцзинь, Шанхай–Ханчжоу и Гуанчжоу–Шэньчжэнь.

Это лучше декоративной карты. Инструмент работает, селекторы узлов машиночитаемы, а таблица пар городов содержит проверяемые утверждения о задержках. Это поддерживает вывод, что Nine Cloud построила или заказала систему, предназначенную для измерений в многоузловом сервисе. Но инструмент не раскрывает IP-адреса проб, частоту тестов, размер пакетов, направление, перцентиль, потери, окно выборки, оператора, координаты площадок и то, доступен ли каждый выбранный узел клиентам сегодня. Надпись «core POP» — не акт приёмки инженерного объекта.

География — на уровне городов. Ни одна просмотренная публичная карта не содержит полилиний волокна, владельцев кабельной канализации, идентификаторов магистральных каналов, станций приземления подводных кабелей, входов в здания или координат meet-me-комнат. Названные дата-центры могут указывать на возможные точки предоставления услуг, но инструмент не сообщает, владеет ли Nine Cloud там оборудованием, перепродаёт ли услуги другого провайдера, держит ли там запасные порты или просто имеет тарифный продукт доступа.

Карта офисов на странице контактов ещё менее релевантна физической географии сети: головной офис и филиалы не являются автоматически узлами POP.

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

Для каждого купленного маршрута полезные картографические данные включали бы точки A и Z, оператора площадки, meet-me-комнату, точку разграничения, местного оператора доступа, магистрального оператора, класс защищённого пути, группы маршрутов с общим риском, оптический или пакетный слой, целевое время восстановления и дату последнего приёмочного теста. Без этих полей карта из 40 узлов — гипотеза о доступности услуги. Коммерчески она информативна и географически наводит на размышления, но не может установить физическое разнообразие маршрутов.

Что может означать 2,9 Т

Надпись на главной странице гласит «2.9T+ backbone private-line full interconnection» — без определения единицы измерения. В этом контексте естественно читать терабиты в секунду, но страница не уточняет, является ли 2,9 Т ёмкостью включённых интерфейсов, законтрактованной ёмкостью операторов, суммой каналов между узлами, теоретической пропускной способностью коммутации, пиковым трафиком, оплачиваемой клиентской полосой или задвоенным итогом по обоим концам каналов. Рядом с числом нет даты актуальности и ни одного показателя загрузки.

У каждой трактовки разный операционный смысл. Маршрутизатор с несколькими портами 100 Гбит/с имеет установленную ёмкость портов, даже если каналы вышестоящих операторов за ними меньше. Длина волны 100 Гбит/с — это включённая в работу ёмкость после установки оптического оборудования и приёмки оператором, но лишь её часть может быть зарезервирована за Nine Cloud. Сумма по полносвязной схеме может учитывать один и тот же магистральный пролёт в нескольких продаваемых маршрутах. Проданные клиентские обязательства уменьшают доступную ёмкость, а при переподписке (oversubscription) заявленная полоса не обязательно может использоваться одновременно.

Ни одно из этих условий нельзя вывести из цифры на сайте.

Диапазон продуктов от 1 Мбит/с до 100 Гбит/с — тоже заказная градация, а не доказательство немедленного предоставления в каждом узле POP. Nine Cloud сообщает, что имеющиеся ресурсы позволяют быстрое предоставление и что полоса может корректироваться хоть ежедневно. Чтобы превратить это в полезную ёмкость, покупателю нужны адрес предоставления услуги, способ доступа, гарантированная скорость передачи (CIR), политика burst, методика расчёта 95-го перцентиля, срок подключения, перечень портов и процедура расширения.

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

Цифры доступности требуют той же дисциплины. На главной странице указано 99,95 % для магистральных частных линий, тогда как в разделе услуг сказано, что индивидуальные контрактные обещания могут достигать 99,99 %. В истории развития говорится, что второй магистральный маршрут поднял доступность сети до 99,99 %. Все эти утверждения могут быть согласованы, если касаются разных продуктов, периодов или границ измерений. Но они не взаимозаменяемы. В невисокосном году доступность 99,95 % допускает примерно 4 часа 23 минуты недоступности, а 99,99 % — около 53 минут.

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

Не найдено ни одной открытой цифры ёмкости по стойкам, шкафам, числу серверов, CPU, памяти, хранилищу, ИТ-мегаваттам, мегаваттам от энергосети, ИБП, времени работы генераторов, охлаждению, топливу, запчастям, занятым портам или остатку резерва. Ни одна открытая цифра не показывает проданную или зарезервированную ёмкость. Облачное и IDC-предложение компании может поставляться через партнёров, но партнёрские площадки и условия выделения ресурсов не раскрываются. Для отказоустойчивости арендованных вычислительных мощностей сеть в 2,9 Т не заменяет запитанную стойку, запасное оборудование, восстанавливаемые данные и проверенный путь миграции.

Физический уровень в основном неизвестен

Крупнейший дефицит доказательств — не маршрутизация, а физическая среда. Nine Cloud называет города и некоторые ярлыки площадок, но не публикует перечень объектов с привязкой к юридическому владельцу, оператору, арендатору или ответственному за оборудование. В просмотренных открытых источниках нет данных о владении землёй, зданиями или машинными залами. Нет схемы стоек с указанием, где установлены маршрутизаторы и серверы Nine Cloud. Нет списка meet-me-комнат операторов или кросс-коннектов. Защищаемое предположение — не владение и не отсутствие, а неизвестность.

Энергоснабжение столь же непрозрачно. Маршрутизатору POP нужны питание от сети, распределительные устройства, ИБП или система постоянного тока, аккумуляторы, резервный генератор, охлаждение и мониторинг среды. Размещённый парк серверов добавляет значительно большую нагрузку и тепловую зависимость. Nine Cloud не публикует число вводов питания, подстанцию, топологию генераторов, время их работы, контракт на заправку топливом, испытания нагрузочными банками, PUE, плотность стоек или недавние тесты на отключение.

Китайская программа «зелёных» дата-центров задаёт требования к эффективности крупных объектов, а отраслевой план MIIT ставил целью PUE ниже 1,3 для новых крупных и гипермасштабных дата-центров к 2025 году. Эти программные ориентиры — контекст, а не доказательство их выполнения каким-либо объектом Nine Cloud.

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

Заявление сайта — 40+ «собственных POP-машинных залов». Эксплуатация не означает владения: даже если в каждом узле стоит оборудование под контролем Nine Cloud, открытые материалы не называют владельцев залов, зданий, систем энергоснабжения и соединительных каналов. Названные объекты в Пекине и Шанхае в инструменте задержек выглядят как бренды сторонних дата-центров или ярлыки местоположений, что указывает на колокацию или доступ через взаимные соединения. Это распространённая и не сама по себе слабая модель. Риском она становится, когда не раскрыты схема защиты, срок аренды, права доступа и концентрация поставщиков.

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

Сценарий отказа 1: доступ и магистраль

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

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

Разделённая картина вышестоящих операторов создаёт экспозицию, специфичную для услуг. Трафик к китайскому /24 сейчас достигает AS131495 через одну видимую соседнюю AS. Сбой или отзыв политики на этой границе могут убрать более специфичный маршрут, даже если охватывающий маршрут China Telecom останется. Будут ли сервисы клиента по-прежнему достижимы, зависит от использования адресов и конфигурации маршрутизации. У гонконгского /24 две видимые соседние сети, но их физическая независимость неизвестна. Ни одна из схем не доказывает, что купленная частная линия имеет эквивалентную защиту.

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

Круг пострадавших зависит от продукта. Отказ сети филиала может остановить аутентификацию, доступ к ERP, платежи, голос и видео. Отказ облачного канала может отрезать приложения от офисов или отделить активные системы от баз данных. Отказ CDN или ускорителя может замедлить публичные сервисы в целом регионе. Отказ аплинка дата-центра может разом изолировать множество арендованных клиентов. Чем шире агрегация у Nine Cloud, тем важнее прозрачные домены отказов и коммуникация с клиентами.

Сценарий отказа 2: стойки, питание и оборудование

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

Инвентаризация оборудования определяет время восстановления. Если откажут блок питания, диск, линейная карта или сервер, провайдеру нужны совместимые запчасти, право доступа и техник, способный добраться до объекта. На сайте компании сказано, что она предлагает персональные технические группы, но на странице контактов указана удалённая поддержка 5×8 и общенациональная горячая линия в рабочие дни. Публичных целевых показателей реагирования на месте 24×7, мест хранения запчастей или договора remote hands нет. Клиенту, которому нужна непрерывная работа, следует письменно согласовать эти описания поддержки.

Энергетические отказы заслуживают явного рассмотрения, потому что сетевой маркетинг часто их скрывает. Два ввода от энергосети могут приходить с одной подстанции. Две системы ИБП могут сходиться на одном статическом переключателе. Генераторы могут иметь ограниченный запас топлива или общую ёмкость. Охлаждение может отказать независимо от электроснабжения. Байпас на обслуживание может снять резервирование без публичного отключения. Ни один просмотренный материал Nine Cloud не описывает эти схемы, поэтому ни одному её узлу POP или арендованному сервису нельзя присвоить рейтинг энергетической устойчивости.

Восстановление также зависит от данных. Второй дата-центр — не резервная копия, если данные не реплицируются с приемлемой точкой восстановления, приложение не запускается там, зависимости недостижимы, а персонал не может выполнить план. Nine Cloud продаёт схемы «две площадки, три центра» и локальные dual-active, включая заявленную топологию «три маршрута, четыре линии» и гарантии обслуживания до 99,99 %. Это паттерны решений. Компания не публикует ни выполненного теста переключения, ни результатов по времени восстановления, ни точки восстановления, ни процедуры переносимости данных клиента.

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

Сценарий отказа 3: управление, поддержка и коммерческие зависимости

Устойчивость сети — это также свойство плоскости управления и организации. Системы конфигурации, аутентификации, мониторинга, тикетирования, биллинга и клиентские порталы могут создавать общие домены отказов для многих площадок. Nine Cloud сообщает, что инциденты отражаются каждые 15 минут, и предлагает выделенную техническую группу для каждого клиента. Но она не публикует историю статусов, календарь обслуживания, архив инцидентов или записи о начислении сервисных кредитов. Клиенты не могут со стороны судить, насколько быстро компания обнаруживает, эскалирует и объясняет неисправности.

Сам публичный сайт иллюстрирует операционную границу.jywx.comразрешается в 123.58.16.244 и отдаёт актуальный сайт на Nuxt по HTTP, но HTTPS-соединение при проверках 15 июля 2026 года завершилось ошибкой. Сайт достижим через охватывающий маршрут China Telecom, а не через текущие более специфичные маршруты AS131495. Это не означает, что клиентским сетевым сервисам не хватает шифрования или доступности. Но это показывает, что публичный информационный сервис компании зависит от другой маршрутизации, чем её ASN, и лишён обычной HTTPS-двери, которую ожидаешь от современного коммерческого сайта.

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

Участие в закупке CNOOC в 2024 году — более конкретный сигнал, поскольку данные приходят из закупочной системы покупателя. Но и там Nine Cloud заняла второе, а не первое место, а извещение касалось обслуживания и технической поддержки ИТ-коммуникаций, а не владения общенациональной магистралью. Покупателю следует запрашивать свежие референсы под конкретный продукт: частная линия — это не арендованное облако, а контракт на обслуживание — не услуга аварийного восстановления.

Лицензирование — ещё одна зависимость. Публичные извещения указывают, что межрегиональная лицензия продлевалась и позднее изменялась, но клиентам следует запрашивать действующий оригинал, категории услуг и разрешённые регионы. Трансграничная связность и размещение данных требуют особого внимания. Правила MIIT ограничивают неавторизованные трансграничные каналы, а адресный блок, зарегистрированный в Гонконге, анонсируется пекинской ASN. Этот факт маршрутизации не устанавливает, где хранятся данные клиента, где проверяется трафик и какое контрактное лицо предоставляет услугу.

Локализацию данных нельзя вывести из IP-метки

Гонконгский префикс делает вопросы локализации конкретными. В APNIC блок 103.175.196.0/23 помечен как гонконгский ресурс, а регистрант — гонконгская компания. Сервисы геолокации IP тоже обычно помещают видимый /24 в Гонконг. Ни страна регистратуры, ни геолокация не доказывают, в каком здании находится сервер. Адреса могут анонсироваться удалённо, туннелироваться, использоваться для anycast или переназначаться внутри сети. И наоборот, адрес, зарегистрированный в Китае, может нести трафик к инфраструктуре в другом месте.

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

То же правило относится к заявлениям о глобальном охвате услуг. Международные вышестоящие операторы могут обеспечить глобальную достижимость из одной гонконгской стойки. Они не создают локальную ёмкость на каждом рынке. Партнёр может обеспечивать последнюю милю за рубежом, при том что Nine Cloud не владеет этим каналом. Ни одна из моделей не хуже другой по своей сути, но ответственность за сбои и порядок работы с данными различаются. Контракт должен называть поставщика в каждой юрисдикции и путь эскалации при отказе субподрядчика.

Безопасность маршрутизации влияет на локализацию косвенно. Действительная авторизация RPKI для гонконгского /24 помогает сетям отклонять неавторизованный источник, тогда как китайский /24 остаётся без валидирующей авторизации. RPKI не предотвращает утечки пути после авторизованного источника, не защищает DNS, не шифрует трафик и не доказывает физическое расположение. Это один элемент контроля в более длинной цепочке. Клиентам следует запрашивать как отдельные меры: фильтры маршрутов, лимиты максимального числа префиксов, ведение записей IRR, безопасность DNS, схемы защиты от DDoS и согласование изменений.

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

Что покупателю следует запросить, прежде чем полагаться на заявленные 40 POP

Первый запрос — датированная топология под конкретную услугу. Она должна отмечать именно те узлы POP, которые использует клиент, а не каждый город на карте продаж. Для каждого узла нужно назвать оператора площадки, зал или meet-me-зону, оборудование Nine Cloud, схему питания стойки, местного оператора доступа, магистрального оператора, точку передачи и ответственную за обслуживание сторону. Маршруты должны показывать группы общего риска, а не декоративные прямые линии. Чувствительные детали можно раскрыть под соглашением о конфиденциальности; тревогу вызывает отсутствие любой проверяемой схемы.

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

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

Четвёртый запрос должен привести поддержку в соответствие с рисками. На публичной странице контактов Nine Cloud указана удалённая поддержка 5×8, тогда как её продукты обслуживают приложения, которые могут работать круглосуточно. Клиенту при необходимости нужно получить контакты для инцидентов критичности первого уровня с доступностью 24 часа, время реакции на площадке, покрытие запчастями, эскалацию к операторам, интервалы уведомлений, сроки анализа первопричин и сервисное кредитование. Следует проверить, что лица, указанные в APNIC, PeeringDB, лицензии и контракте, актуальны или имеют определённых правопреемников.

Пятый запрос должен урегулировать юридические границы и границы данных. Компания должна предоставить актуальную заверенную регистрацию, телекоммуникационную лицензию и её объём; назвать характер отношений с HK JIUYUN INFINITE TRADE LIMITED; перечислить субподрядчиков; сообщить, где хранятся данные клиента, журналы и резервные копии. Компания должна объяснить, как клиент выходит из сервиса, получает свои данные и переносит каналы, если завершится аренда площадки или контракт с провайдером.

Ни один из этих запросов не исходит из того, что заявления Nine Cloud ложны. Они переводят широкую сетевую риторику в доказательства, которые можно оценить и обеспечить исполнением. Небольшой публичный след BGP может поддерживать ценную частную сеть. Арендованная общенациональная магистраль может быть устойчивой. Порт биржи 1 Гбит/с может сосуществовать с гораздо более крупными частными каналами. Но каждое утверждение требует правильного документа, теста и границы контроля.

Работающая сеть с поправкой на доказательства

Nine Cloud — не просто спящая корпоративная оболочка. У неё есть активная регистрация автономной системы, действующие маршруты, действительная авторизация RPKI для одного префикса, поддерживаемая участником запись о бирже, работающий сайт, функционирующий инструмент замеров задержек по городам, история лицензий и недавний сигнал участия в корпоративной закупке. Эти факты поддерживают вывод средней уверенности в том, что компания продолжает работать и продавать сетевые услуги.

Уверенность резко падает на физическом уровне и уровне ёмкости. Ни одно просмотренное открытое свидетельство не подтверждает 40 действующих объектов POP, их владельцев, состояние их энергоснабжения или разнесение по общим рискам. Ни одно открытое свидетельство не определяет итог 2,9 Т, не сообщает о загрузке, не выявляет проданную ёмкость и не демонстрирует восстановление при сбое. Два публичных /24 и три наблюдаемые соседние сети показывают достижимость и некоторое логическое разнообразие, а не общенациональную физическую топологию. Запись о порте NNIX 1 Гбит/с конкретна, но устарела и слишком узка, чтобы подтвердить совокупное заявление.

Отсюда — поправка на доказательства, а не вердикт о прекращении деятельности. Покупателям следует оценивать услугу по тем объектам, каналам, условиям поддержки и тестам, которые Nine Cloud может задокументировать для их маршрута. Не стоит оценивать её как платформу на 40 площадок, 2,9 Тбит/с и 99,99 % лишь потому, что эти числа соседствуют на одной странице. Так же не следует сбрасывать её со счетов из-за того, что за её ASN видно только 512 IPv4-адресов. Масштаб публичного интернета и масштаб частного транспорта измеряют разные вещи.

Решающие доказательства были бы простыми: датированный перечень узлов POP и площадок, границы операторов и энергоснабжения, установленная и доступная ёмкость, пути защиты под конкретного клиента, действующие лицензии, завершённость мер безопасности маршрутизации и засвидетельствованные результаты переключений. Пока этого нет, наиболее обоснованное описание остаётся точным. Nine Cloud эксплуатирует небольшой видимый край интернета вокруг AS131495 и продаёт гораздо более крупную китайскую частную сеть и хостинговую ткань. Край наблюдаем.

Ткань остаётся утверждением, которое предстоит проверять по одному каналу, стойке и тесту восстановления за раз.