CHINA UNICOM CLOUD DATA COMPANY LIMITED Shanghai Branch продаёт размещённые мощности, которые по-прежнему зависят от стоек, транзита и ремонтных окон

Кратко

• APNIC идентифицирует AS63659 как CU-CDC-SH и описывает его как CHINA UNICOM CLOUD DATA COMPANY LIMITED Shanghai Branch в Китае. Те же публичные данные APNIC связывают блок 103.68.128.0/22 с сетевым именем CU-CDC-SH и адресом здания China Unicom: дом 1033 на улице Чаннин, район Чаннин, Шанхай.
• ASN филиала в настоящее время не является публичным подтверждением маршрутизации. В обзоре AS63659 в RIPEstat значилось announced: false; просмотр объявленных префиксов не вернул текущих префиксов; статус маршрутизации показал 0 префиксов IPv4, 0 префиксов IPv6 и 0 наблюдаемых соседей; история маршрутизации относит видимый источник 103.68.128.0/22 от AS63659 к 2017–2018 годам, последний наблюдаемый источник AS63659 — ноябрь 2018 года.
• Блок адресов по-прежнему важен, потому что просмотр префикса 103.68.128.0/22 в RIPEstat показал, что префикс объявляется через AS138421, владелец CU-CN-AS — China Unicom, и на момент запроса его видели 325 из 325 пиров RIS. Это подтверждает действующий маршрут China Unicom, а не заявление филиала о собственном клиентском обслуживании.
• Официальные отчёты China Unicom показывают крупный облачный и дата-центровый бизнес: выручка дата-центров за 2025 год — 28,1 млрд юаней, более 1,10 млн стандартных стоек, семь кампусов AIDC класса 100 МВт, рост выручки Unicom Cloud и выручка Unicom Cloud за первое полугодие 2025 года — 37,6 млрд юаней. Эти цифры задают контекст инфраструктуры материнской компании, но не точное размещение клиентов, число стоек или путь восстановления для шанхайского филиала.
• Оценка доказательств — слабая. Открытые данные подтверждают реальный след номерных ресурсов, связанный с филиалом, и действующий маршрут префикса China Unicom, но не доказывают текущую эксплуатацию AS63659, клиентские мощности на уровне филиала, разнообразие транзита, размещение данных или характеристики восстановления.

Полезные доказательства начинаются с расхождения

Главный факт о CHINA UNICOM CLOUD DATA COMPANY LIMITED Shanghai Branch — расхождение между данными регистрации и данными текущей маршрутизации. В записи RDAP APNIC дляAS63659handle — AS63659, имя — CU-CDC-SH, страна — CN, статус — active.Просмотр whois для AS63659в RIPEstat даёт ту же операционную метку и описывает ресурс как CHINA UNICOM CLOUD DATA COMPANY LIMITED Shanghai Branch. Это значимый идентификационный сигнал: это не общая отсылка к «облаку», вставленная в маркетинговую страницу.

Данные о маршрутизации более узкие.Обзор AS63659в RIPEstat показал, что AS63659 не объявлялся на момент запроса 2026-07-11 16:00 UTC.Просмотр объявленных префиксоввернул пустой список текущих префиксов за недавнее окно наблюдения, апросмотр статуса маршрутизациипоказал ноль объявленного пространства IPv4, ноль объявленного пространства IPv6 и ноль наблюдаемых соседей. Клиент не может превратить эти поля в обещание, что этот ASN филиала сегодня обслуживает живую размещённую услугу.

Это не делает филиал незначимым. В записи RDAP APNIC для103.68.128.0/22указано сетевое имя CU-CDC-SH, диапазон 103.68.128.0–103.68.131.255, статус active, страна CN.Данные whois для 103.68.128.0/22повторяют описание филиала и адрес здания China Unicom. Эти записи говорят покупателю, с чего начать, но не показывают полный облачный сервис.

Важное изменение в том, что тот же блок адресов сейчас виден через другой AS.Обзор префиксав RIPEstat показал, что 103.68.128.0/22 объявляется через AS138421, владелец CU-CN-AS — China Unicom.Просмотр статуса маршрутизации для префиксапоказал, что маршрут виден всем 325 пирам RIS IPv4 на момент запроса, источник — AS138421. Таким образом, доказательства подтверждают действующий маршрут блока адресов China Unicom, связанный с записью филиала. Они не подтверждают простую формулировку, что сам AS63659 сейчас является клиентским краем.

Неактивный AS филиала меняет критерии проверки

Неактивный AS — это не автоматически неисправный сервис. Крупные операторы часто консолидируют клиентские маршруты в более широкий магистральный AS, выводят из эксплуатации небольшие ASN-источники, меняют политику маршрутизации или держат номерные ресурсы на региональном или продуктовом счёте, пока трафик идёт через национальную сеть. Но неактивный AS филиала действительно меняет критерий проверки. Вопрос больше не звучит как «объявляет ли AS63659 клиентские префиксы?». Вопрос становится таким: «какая сеть, площадка и договор China Unicom сейчас несут размещённые мощности, которые, судя по всему, представляет имя филиала?»

История маршрутизации для AS63659в RIPEstat показала историческую видимость 103.68.128.0/22 и связанных более специфичных префиксов под источником AS63659, причём видимый источник AS63659 для агрегата закончился в конце 2018 года. Текущий просмотр префикса, напротив, помещает 103.68.128.0/22 под AS138421. Эта история полезна, потому что предотвращает две распространённые ошибки. Первая ошибка — называть филиал пустой оболочкой только потому, что его собственный AS не активен. Вторая — считать старый AS-источник текущим доказательством работы.

Клиент должен закрепить это различие в договоре. Если в продажных или сервисных документах всё ещё упоминается филиал, клиент должен спросить, будет ли его нагрузка использовать 103.68.128.0/22, другой пул адресов Unicom Cloud, частный стык, путь публичного облачного обмена или выделенный клиентский блок. Если ответ — «магистраль China Unicom», клиенту нужен сервисный край AS138421, а не AS63659, включённый в мониторинг и доказательства инцидентов. Если ответ — «шанхайский филиал», клиент должен узнать, какая площадка и операционная команда делают это утверждение реальным.

Отсутствиепрофиля AS63659 в PeeringDBв результатах публичной проверки API усиливает тот же вывод. Отсутствие в PeeringDB — не отрицательная оценка; многие внутренние или региональные ASN операторов не ведут публичные записи в PeeringDB. Это просто означает, что публичная плоскость межсоединений не показывает точки обмена, площадки, пиринговую политику или данные looking glass для этого ASN филиала. Покупатель должен получить эту информацию напрямую, а не выводить её из имени.

Активный путь, судя по всему, лежит в более широкой магистрали China Unicom

Текущие доказательства пути связаны с AS138421.Обзор AS138421в RIPEstat идентифицировал владельца как CU-CN-AS — China Unicom и показал, что AS объявляется.Просмотр объявленных префиксов AS138421вернул сотни текущих префиксов IPv4 за недавнее окно. Для самого 103.68.128.0/22данные looking glassв RIPEstat показали пути международных коллекторов, заканчивающиеся в AS138421 через апстримы, включающие AS4837 во многих наблюдениях. Это согласуется с тем, что блок адресов достижим как часть большой системы маршрутизации China Unicom.

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

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

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

Именно поэтому план мониторинга клиента должен включать обе идентичности. AS63659 — это номерная идентичность ресурса, связанная с филиалом. AS138421 — текущий публичный источник префикса, связанного с филиалом. Монитор маршрутов, который следит только за AS63659, пропустит живой маршрут, если текущий сервис остаётся под AS138421. Проверка закупки, которая следит только за AS138421, может пропустить специфическую для филиала неопределённость по распределению адресов, эскалации поддержки и размещению клиентов.

Масштаб China Unicom реален, но масштаб — это не размещение

Официальная отчётность China Unicom показывает масштаб материнской системы.Годовой отчёт за 2025 годсообщает, что выручка дата-центров достигла 28,1 млрд юаней, увеличившись на 8,5 % в годовом выражении; количество стандартных стоек превысило 1,10 млн; построено семь кампусов AIDC класса 100 МВт; утилизация стоек превысила 72 %; масштаб интеллектуальных вычислений достиг 45 EFLOPS; к магистральной волоконно-оптической сети «восемь вертикалей и восемь горизонталей» для соединения вычислительных хабов добавлено более 9 000 километров. В том же отчёте говорится, что Unicom Cloud развивается в сторону ИИ-облака и включает облачные IDC, облачные ресурсы, облачную платформу, облачный сервис, облачную интеграцию, облачные межсоединения и облачную безопасность в определение выручки Unicom Cloud.

Промежуточный отчёт за 2025 годдобавляет срез середины года: выручка Unicom Cloud за первое полугодие достигла 37,6 млрд юаней; выручка IDC — 14,4 млрд юаней; утилизация ресурсов IDC превысила 70 %; China Unicom предоставил услуги интеллектуальных сетей более 280 облачным провайдерам и соединился с более чем 400 дата-центрами; компания описала центры интеллектуальных вычислений на 10 000 чипов в Линьгане (Шанхай), Хух-Хото, Чжунвэе и Саньцзянъюане.Годовой отчёт за 2024 годаналогично сообщил о выручке Unicom Cloud в размере 68,6 млрд юаней, выручке IDC в 25,9 млрд юаней и крупномасштабных центрах интеллектуальных вычислений в Шанхае и других регионах.

Это сильные инфраструктурные факты уровня материнской компании. Они важны, потому что показывают: «облако» в данном случае — это не только перепродажный ярлык на маленьком сайте. Материнская группа тратит и отчитывается в масштабе оператора. Но масштаб материнской компании не определяет размещение филиала. В отчётах не говорится, что у CHINA UNICOM CLOUD DATA COMPANY LIMITED Shanghai Branch есть конкретное число стоек, доступных публичным клиентам. В них не утверждается, что 103.68.128.0/22 — это пул клиентских серверов.

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

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

Шанхайский адрес — это подсказка, а не план машинного зала

Связанные с филиалом публичные записи указывают на Шанхай. RDAP APNIC и whois RIPEstat указывают здание China Unicom по адресу дом 1033, улица Чаннин, район Чаннин, Шанхай в полях адреса административного и технического контактов для AS и аллокации 103.68.128.0/22. Это реальная географическая подсказка. Но это не значит, что клиентские серверы находятся по этому адресу, и не значит, что этот адрес — дата-центр. Это может быть офис, регистрационная точка, операционный контакт, площадка сетевого администрирования или бизнес-адрес рядом с площадкой.

Шанхай всё равно важен. Официальные отчёты называют Шанхай среди крупномасштабных развёртываний интеллектуальных вычислений China Unicom, а промежуточный отчёт за 2025 год конкретно называет Линьган в Шанхае в списке центров интеллектуальных вычислений на 10 000 чипов. Если клиент покупает размещённые в Китае мощности, потому что важны локализация в Шанхае, сетевая доступность или регуляторный контекст, он должен спросить, находится ли производственная нагрузка в Шанхае, в национальном вычислительном хабе, в другой провинции или в общем облачном пуле, чья плоскость управления и резервные копии охватывают несколько регионов.

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

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

Стойки превращают облачный сервис в ремонтную задачу

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

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

Для CHINA UNICOM CLOUD DATA COMPANY LIMITED Shanghai Branch публичные доказательства указывают на национальную операторскую среду, а не на изолированный бутик-хостинг. Это помогает с глубиной поставщика. Но это также усложняет границы ответственности. Если клиент входит через договор филиала, использует национальную платформу Unicom Cloud, получает публичные адреса из одного пула и полагается на региональный дата-центр, владелец ремонта может меняться по слоям. Филиал может вести аккаунт. Национальный центр операций может вести маршрут. Команда площадки может вести питание. Команда облачной платформы может вести хранилище.

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

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

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

Разнообразие транзита нельзя вывести из неактивного AS филиала. RIPEstat не показал текущих соседей AS63659, а значит, AS63659 не раскрывает текущую карту публичных соседей в этих данных. Активный путь префикса указывает на AS138421, поэтому тестирование транзита и достижимости должно фокусироваться на крае AS138421, который несёт 103.68.128.0/22. Клиент должен запросить текущую политику источника, договорённость с апстримами и пирами, контроль фильтрации маршрутов, состояние авторизации источника маршрута и проверенный путь переключения при отказе.

Состояние авторизации маршрута не идеально в качестве самостоятельной гарантии.Проверка валидации RPKIв RIPEstat вернула статус unknown для AS138421 и 103.68.128.0/22, без валидирующих ROA в этом запросе. Unknown — это не invalid, и это не значит, что маршрут угнан. Это значит, что публичный сигнал RPKI не дал положительного доказательства авторизации источника для этого источника и префикса на момент проверки. Для клиентов, которые зависят от строгой фильтрации маршрутов апстримами или пирами, статус unknown — реальный пункт для уточнения.

Гигиена маршрутизации — только одна часть устойчивости.RFC 6811объясняет валидацию источника маршрута;RFC 7454описывает операционные практики для BGP;MANRSформулирует ожидания по безопасности маршрутизации для сетевых операторов. Эти документы полезны, потому что определяют вопросы, а не потому что сертифицируют какого-то оператора. Провайдер может следовать хорошей практике фильтрации маршрутов и всё равно иметь локальный обрыв волокна, перегруженный резервный путь или медленную эскалацию поддержки.

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

Труд техподдержки — часть инфраструктуры

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

Структура филиала делает это особенно важным. CHINA UNICOM CLOUD DATA COMPANY LIMITED Shanghai Branch может быть видимым договорным или аккаунтным ярлыком, в то время как техническое восстановление может лежать на командах платформы Unicom Cloud, командах магистрали China Unicom, операционной группе дата-центра и региональной команде обслуживания клиентов. Клиент должен знать, какая команда отвечает за каждый симптом. Отзыв публичного маршрута, потеря пакетов, сбой консоли, сбой снапшота хранилища, блокировка идентичности, приостановка биллинга и задержка экспорта могут требовать разных владельцев.

Самое сильное доказательство поддержки — не общая строка SLA. Это пример пути инцидента. Кто получает первую заявку? Что даёт право на телефонную эскалацию? Как провайдер определяет, специфичен ли инцидент для филиала, относится ли он к маршрутизации AS138421, к плоскости управления облаком, к хранилищу, питанию, фильтрации безопасности или конфигурации клиента? Может ли страница статуса работать, если основная консоль управления недоступна? Есть ли прямой путь к команде, которая может менять маршруты или восстанавливать хранилище, или каждая заявка должна проходить через поддержку аккаунта?

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

Биллинг, приостановка и состояние аккаунта — это пути отказа

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

Публичные доказательства не раскрывают биллинговую систему филиала или контроль аккаунтов. Значит, покупатель должен спросить напрямую. Какое юридическое лицо выставляет счёт за сервис? Является ли шанхайский филиал договорным контактом, контактом поддержки или обоими? Что происходит при несоответствии имени аккаунта, документов, связанных с ICP, документов проверки безопасности и технического тенанта? Может ли приостановка за неуплату затронуть резервные копии или экспорт данных? Сколько времени есть у клиента, чтобы восстановить статус аккаунта, прежде чем ресурсы будут удалены?

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

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

Локализация данных не решается китайским адресом

Сигналы Китая и Шанхая у филиала релевантны локализации данных, но не решают её. Запись об адресах в APNIC и описание филиала показывают связанную с Китаем запись номерного ресурса. Отчёты China Unicom показывают национальный масштаб облака и дата-центров. Китайские регуляторные источники, включаяположения Управления по делам киберпространства Китая (CAC) 2024 года о трансграничных потоках данных,меры CAC по оценке безопасности экспорта данныхи официальную английскую публикациюЗакона о защите личной информации, показывают, почему размещение, доступ и пути экспорта важны. Но ни один из этих источников не говорит конкретному клиенту, где будут лежать его данные, резервные копии, логи или записи поддержки.

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

Текущий источник 103.68.128.0/22 — AS138421 — не отвечает на эти вопросы. Префикс может быть зарегистрирован на контакт шанхайского филиала и при этом маршрутизироваться по национальной магистрали. Плоскость управления может быть в Китае, пока часть операционных систем централизована. Резервная копия может быть в другой провинции для устойчивости. Платформа логов может быть отделена от производства. Локализация — это заявление о проектировании и договоре, а не умозаключение из кода страны.

Клиент должен потребовать график локализации, который охватывает производство, резервные копии, логи, телеметрию, тикеты клиентов, биллинговые записи, доступ поддержки и экспорт данных. График должен указывать, когда данные могут перемещаться, требуется ли согласие клиента, как работает репликация между регионами и как клиент может доказать удаление или экспорт после завершения. Без таких доказательств метка «Shanghai Branch» остаётся полезной, но неполной.

Миграция — последний честный тест на устойчивость

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

Для этого филиала публичные доказательства поднимают конкретный вопрос миграции: что происходит с нагрузками, привязанными к ресурсу филиала, который сейчас маршрутизируется через более широкий AS China Unicom? Если клиент получает публичные IP из 103.68.128.0/22, могут ли эти адреса переехать вместе с нагрузкой? Обычно адреса, назначенные провайдером, не переезжают за пределы провайдера, поэтому клиенту нужен план изменений DNS, сертификатов, allow-списков, партнёрских API и политик безопасности. Если сервис использует частные адреса или частные линии, клиенту нужны эквивалентные доказательства переключения.

Экспорт данных требует той же точности. Может ли клиент экспортировать все данные без услуг профессионалов? Включает ли экспорт метаданные, настройки идентичности, правила безопасности, логи, снапшоты и версии объектов? Можно ли запускать экспорты при деградировавшем сервисе? Как долго хранятся экспорты после завершения? Ограничена ли пропускная способность экспорта? Кто одобряет аварийный экспорт, если обычный администратор аккаунта недоступен?

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

Кто ощущает последствия сбоя

Прямым клиентом CHINA UNICOM CLOUD DATA COMPANY LIMITED Shanghai Branch может быть корпоративный тенант, нагрузка госсектора, оператор приложения, реселлер, системный интегратор, локальный бизнес или другая сетевая команда. Конечный пользователь может никогда не узнать имя филиала. Он может заметить только, что приложение медленное, консоль недоступна, база данных не восстанавливается, платёжный портал не работает или allow-список партнёра больше не совпадает с адресом сервиса.

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

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

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

Как проверить сервис, прежде чем полагаться на него

Первый тест — сопоставление идентичности и адресов. Попросите провайдера указать, используется ли AS63659 для какого-либо текущего клиентского сервиса. Спросите, назначен ли 103.68.128.0/22 продукту, и если да, объявляется ли он через AS138421 в нормальной эксплуатации. Сравните ответ с RDAP APNIC дляAS63659, RDAP APNIC для103.68.128.0/22,статусом маршрутизации AS63659в RIPEstat истатусом маршрутизации 103.68.128.0/22. Любое несоответствие может быть безвредным, но его следует объяснить до запуска в производство.

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

Третий тест — маршрут и восстановление. Наблюдайте за префиксом из нескольких точек, следите за AS-источником, проверяйте статус RPKI, тестируйте частное соединение, если оно используется, и запросите упражнение по переключению маршрута при отказе. Затем протестируйте восстановление нагрузки: восстановите из резервной копии, переключите трафик, подтвердите логи, пересоберите контроль доступа и замерьте время. Упражнение должно включать и сценарий планового обслуживания, и сценарий внепланового отказа.

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

Что могло бы усилить доказательную базу

Доказательства стали бы существенно сильнее, если бы провайдер опубликовал или предоставил актуальную карту сервиса для ресурсов, связанных с филиалом. Самый полезный документ связал бы в одном месте имя филиала, договаривающуюся структуру, AS63659, 103.68.128.0/22, AS138421, регион производства, регион восстановления, владельца поддержки и продукт клиента. Ему не нужно было бы раскрывать чувствительные координаты стоек или защитные меры. Ему нужно было бы сказать, какие публичные факты всё ещё операционно релевантны, а какие — только история.

Второе улучшение — живые операционные доказательства. Это могут быть недавние выборки мониторинга маршрутов для клиентского пула адресов, текущий план RPKI или объяснение статуса unknown, уведомления о обслуживании с указанием затронутого слоя и упражнение по переключению при отказе, показывающее, что происходит, когда убирают обычный путь, площадку или канал поддержки. Внутренняя уверенность провайдера полезна, но клиенту нужны доказательства, которые он может сохранить и интерпретировать во время инцидента.

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

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

Оценка доказательств — слабая. Эта оценка не означает, что компания слабая, и не означает, что у China Unicom нет облачного или дата-центрового масштаба. Это утверждение о том, что могут подтвердить публичные доказательства для этой конкретной инфраструктурной зависимости на уровне филиала.

Позитивные доказательства конкретны. APNIC и RIPEstat связывают AS63659 и 103.68.128.0/22 с CU-CDC-SH и CHINA UNICOM CLOUD DATA COMPANY LIMITED Shanghai Branch. Связанный с филиалом блок IPv4 активен в данных реестра. RIPEstat показывает, что 103.68.128.0/22 сейчас объявляется через AS138421 (China Unicom) с полной видимостью RIS на момент запроса. Официальные отчёты China Unicom подтверждают крупное национальное облачное, IDC и интеллектуально-вычислительное имущество, включая заявленную выручку дата-центров, масштаб стоек, кампусы AIDC, отсылки к интеллектуальным вычислениям в Шанхае и выручку Unicom Cloud.

Ограничивающие доказательства не менее важны. Сам AS63659 не был объявлен в RIPEstat на момент проверки, не имел текущих префиксов в просмотре объявленных префиксов и не имел наблюдаемых соседей. Активный маршрут связанного с филиалом блока /22 использовал AS138421, а не AS63659. Проверка RPKI для 103.68.128.0/22 и AS138421 вернула unknown. Публичные записи, рассмотренные здесь, не публиковали страницы продуктов филиала для клиентов, договоры площадок, число стоек, резервирование питания, эскалацию поддержки, проверенные цели восстановления, размещение клиентских данных или условия экспорта.

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

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

Вывод узкий: CHINA UNICOM CLOUD DATA COMPANY LIMITED Shanghai Branch — это реальная связанная с филиалом идентичность номерного ресурса внутри очень крупного облачного и дата-центрового контекста China Unicom, но публичные доказательства не подтверждают текущую поверхность размещённых мощностей, специфичную для филиала. Клиенту следует действовать, проверяя живой AS, пул адресов, размещение площадок, контроль маршрутов, владельца поддержки, учения по восстановлению и путь выхода, прежде чем считать сервис устойчивым.