Сеть CHINANET SHAANXI province Cloud Base network продаёт размещённые ёмкости, которые по-прежнему зависят от стоек, транзита и ремонтных окон

Кратко

• В реестре APNIC RDAPAS134768указан какCHINANET-SHAANXI-CLOUD-BASE, с описательным названием CHINANET SHAANXI province Cloud Base network, страной CN, регистрацией в 2015 году и контактом Chinanet hostmaster.
• Текущая видимость в маршрутизации высокая.Обзор ASв RIPEstat сообщает, что AS134768 анонсируется, астатус маршрутизациив RIPEstat в проверенном публичном окне показывает 86 префиксов IPv4, 39 префиксов IPv6 и 11 наблюдаемых соседей.
• Топология по-прежнему зависит от родительской сети.Данные whoisиз APNIC перечисляют импорты из AS4134 и AS4809, но текущие публичные представления соседей — RIPEstat,bgp.tools,страница BGPHurricane Electric иIPinfo— все показывают видимым аплинком AS4134 (China Telecom Backbone).
• Публичные данные об адресах неоднородны, и это важно для размещённых ёмкостей. Многие анонсируемые префиксы — ресурсы Chinanet провинции Шэньси, но в публичных BGP-представлениях видны и маршрутизируемые диапазоны, описанные как IDC и облачные сервисы, выделенные линии, Baidu, Чжэцзян, Гуандун и Sichuan Xiaoteyun, — поэтому клиент не может по одному номеру AS определить владельца нагрузки или расположение стойки.
• Публичные сигналы об объектах указывают на реальную базу облачных вычислений в Сиане/Сисяне. В отчёте о визите Northwest University за 2025 год база облачных вычислений China Telecom в Шэньси описана как крупный западнокитайский центр облачных вычислений и больших данных: более 10 000 стоек, машинные залы уровня T4, PUE до 1,25, варианты стоек высокой плотности и роль в облаке провинциального правительства.
• Уровень доказательности — средний (Medium), а не высокий (Strong). Сеть явно жива и масштабна, но открытые источники не публикуют актуальную карту принадлежности стоек, схемы электропитания, переключение аплинков, тесты восстановления, ограничения переносимости данных и эскалацию поддержки для клиентов, покупающих размещённые ёмкости через эту облачную сеть.

Живая таблица маршрутов — лишь первое доказательство

Поставщик размещённых ёмкостей может выглядеть надёжным двумя очень разными способами. Одно доказательство — таблица маршрутов: маршруты видны, префиксы авторизованы, у пакетов есть путь, а AS числится у известного оператора. Другое доказательство — операционное: у стоек есть питание, у охлаждения есть запас, у гипервизоров есть свободная ёмкость, резервная копия восстанавливается, служба поддержки может дозвониться до нужного инженера, а клиент может вывезти данные, когда отношения заканчиваются. У сети CHINANET SHAANXI province Cloud Base network первое доказательство сильное, а публичное второе — более скудное.

Официальная идентичность проста. В APNIC RDAP дляAS134768указано имяCHINANET-SHAANXI-CLOUD-BASE, а описание — CHINANET SHAANXI province Cloud Base network. Запись относит сеть к Китаю, показывает регистрацию 27 октября 2015 года и перечисляет контакты Chinanet hostmaster.Представление whoisв RIPEstat повторяет то же имя и описание AS и добавляет строки маршрутной политики: импорты из AS4134 и AS4809 и экспорт AS134768 в эти сети. Этого достаточно, чтобы считать сеть реальным маршрутным субъектом China Telecom в провинции Шэньси, а не расплывчатым облачным лозунгом.

Текущее состояние маршрутов тоже существенно.Статус маршрутизациив RIPEstat в проверенном окне июля 2026 года показывал AS134768 видимым почти для всех пиров RIS и в IPv4, и в IPv6. Он насчитал 86 префиксов IPv4, 39 префиксов IPv6, 184 576 адресов IPv4 и 12 576 эквивалентов /48 для IPv6.Представление анонсированных префиксовв RIPEstat перечисляло 125 текущих записей префиксов по IPv4 и IPv6 вместе.Страница BGPHurricane Electric показывала похожий масштаб: 184 576 анонсированных адресов IPv4 и ни одного невалидного анонса RPKI в текущем представлении. Это не признаки неактивного ASN.

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

Это различие — центральная зависимость статьи. AS134768 продаёт впечатление сетевой облачной ёмкости, и публичные данные BGP подтверждают существование крупного активного периметра China Telecom в Шэньси. Но покупатель всё равно должен проверить физический и контрактный слой за этим периметром. В хостинге самый разрушительный сбой часто не «интернет исчез».

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

Что доказывает публичная маршрутизация

Публичная маршрутизация доказывает, что AS134768 видим и достаточно важен, чтобы его отслеживали.Обзор ASв RIPEstat идентифицирует держателя как CHINANET-SHAANXI-CLOUD-BASE, с тем же описательным названием, что и в APNIC. Текущий статус маршрутизации в RIPEstat показывает широкую видимость IPv4 и IPv6, а не периферийный маршрут, который видят лишь несколько коллекторов. На той же странице статуса указана первая активность в январе 2017 года и последняя запись 12 июля 2026 года. История маршрутов подтверждает непрерывность: публичный интернет видит этот ASN годами, и он не был просто зарегистрирован и заброшен.

Сторонние агрегаторы согласуются с этой картиной.bgp.toolsклассифицирует сеть как активную в APNIC, помечает тип сети как контентный, показывает аплинком China Telecom Backbone и сообщает о 75 анонсированных префиксах IPv4 и 39 префиксах IPv6 в своём видимом представлении.Страница AS134768Hurricane Electric сообщает всего о 127 анонсированных префиксах: 88 IPv4 и 39 IPv6, плюс 11 наблюдаемых BGP-пиров.IPinfoописывает ASN как ориентированный на хостинг, указывает страну China, показывает десятки тысяч размещённых доменов на адресах ASN и называет аплинком AS4134 в видимом кратком обзоре.

В счётчиках есть расхождения, потому что публичные BGP-коллекторы используют разные точки наблюдения, правила фильтрации и время обновления. RIPEstat насчитал 86 префиксов IPv4 в представлении статуса маршрутизации, bgp.tools показал 75 анонсированных префиксов IPv4, а Hurricane Electric — 88. Это расхождение не стоит переоценивать как противоречие. Общий сигнал важнее точного числа: у AS134768 большая маршрутизируемая поверхность, сильный родительский путь China Telecom и крупная смесь ресурсов IPv4 и IPv6.

Данные о происхождении маршрутов тоже выглядят лучше, чем у многих небольших хостинговых сетей. Проверка валидации происхождения маршрута в RIPEstat для репрезентативных шэньсийских блоков IPv4, таких как36.41.64.0/20,113.142.128.0/17и117.34.124.0/23, возвращала для AS134768 статус valid в проверенных результатах. То же верно для примеров облачных и сетевых блоков IPv6, таких как240e:982:4500::/40и240e:108:1140::/48. Валидные ROA не гарантируют качество услуги, но снижают один класс рисков, связанных с происхождением маршрута.

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

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

В записи whois AS134768, полученной из APNIC, названы два импорта: AS4134 и AS4809. AS4134 — China Telecom Backbone. AS4809 — сеть CN2 China Telecom, часто связанная с магистральными путями премиум-класса. Если бы оба пути активно и независимо несли клиентские нагрузки, это было бы полезным разнообразием. Публичные представления маршрутов не доказывают такое сильное прочтение.

Представление соседей ASNв RIPEstat в проверенном окне показало 11 наблюдаемых соседей. Слева был сосед AS4134 с высокой видимостью в IPv4 и IPv6. Справа находился набор городских сетей 5G China Telecom в провинции Шэньси, включая AS138387 для Сианя, AS138409 для Тунчуаня, AS138436 для Баоцзи, AS138513 для Вэйнаня, AS138514 для Сяньяна и другие, видимые в основном в IPv6. В кратком обзоре IPinfo также указан один аплинк —AS4134. bgp.tools аналогично представил аплинком AS4134. Hurricane Electric в видимой таблице показал AS4134 и IPv4-пиром, и указанным IPv6-пиром.

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

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

Это особенно важно, потому что все видимые пути находятся внутри более широкой семьи China Telecom. Устойчивость родительской сети может быть отличной, но это не то же самое, что коммерческая или физическая независимость. Настоящее заявление о резервировании должно разделять как минимум четыре уровня: разнообразие BGP-путей, разнообразие операторов или магистралей, разнообразие физических путей и запас ёмкости после переключения.

Если оба маршрута зависят от одной траншеи городского оптоволокна, одного ядра коммутации облачной базы, одного ввода в здание или одного контура управления China Telecom, вторая строка AS может не защитить клиента от того отказа, которого он опасается.

Правильная формулировка для закупки не должна быть враждебной. Покупатель может спросить: «Для покупаемой нами услуги какие исходный AS, аплинк-номера AS, префиксы, зоны доступности и физические машинные залы входят в объём? Какой путь основной? Какой проверен? Какой просто доступен оператору где-то ещё в сети?» Это различие не даёт продавать сильную сеть China Telecom как полную многовендорную отказоустойчивость.

Смесь префиксов показывает хостинг, доступ и партнёрские поверхности вместе

Публичный список префиксов достаточно широк, чтобы предполагать не одну бизнес-поверхность. Многие видимые префиксы — обычное сетевое пространство Chinanet провинции Шэньси. В реестре APNIC RDAP36.41.64.0/20разрешается в более крупную аллокацию CHINANET-SN, а метка административного контакта относит бюро передачи данных к Сианю. В реестре APNIC RDAP113.142.128.0/17аналогично разрешается в аллокацию CHINANET-SN. Эти блоки подтверждают, что AS134768 несёт адресные ресурсы China Telecom провинции Шэньси, хотя в некоторых устаревших описаниях используется написание «Shanxi (SN)», из-за которого Шэньси (Shaanxi) можно спутать с Шаньси (Shanxi). Практический якорь — сианьский контекст контакта.

Другие маршрутизируемые ресурсы усложняют операционную границу. bgp.tools перечисляет несколько блоков вида 103.236.0.0/22 с описаниями компании Sichuan Xiaoteyun Technology. В APNIC RDAP для103.236.88.0/22зарегистрированным именем ресурса указано XIAOTEYUN, а контактом — Чэнду, Сычуань; при этомобзор префиксав RIPEstat в проверенном маршрутном представлении показывает текущим источником AS134768. bgp.tools также показывает на странице AS134768 несколько префиксов с описанием Baidu и префиксов Chinanet вне Шэньси. Присутствие таких ресурсов — не признак нарушения. Это признак того, что AS-источник, клиент, держатель ресурса и фактическое размещение могут расходиться.

Такое расхождение нормально для крупных сетей. Оператор может анонсировать собственное пространство клиента (PI), пространство под защитой от DDoS, облачные адреса, сети выделенных линий, блоки доставки контента, сегменты правительственного облака или партнёрские аллокации. Риск клиента в том, что одно имя AS не позволяет покупателю определить, какая операционная схема применима. VPS на облачной инфраструктуре China Telecom — это не то же самое, что маршрутизатор клиента, чей префикс анонсирует AS134768, и ни то ни другое не равно сайту, размещённому на IP-адресе, который IPinfo учитывает в данных о размещённых доменах.

IPinfoиллюстрирует, почему это важно. Сервис сообщает о более чем 23 000 доменов, размещённых на адресах ASN, и выделяет 103.236.90.151 как адрес с тысячами доменов. Это полезный рыночный сигнал: ASN, судя по всему, несёт веб-трафик с высокой плотностью доменов. Но он не доказывает контрактного владельца этих сайтов, расположение стоек, политику резервного копирования и не показывает, принадлежит ли адрес реселлеру, платформе общего хостинга, CDN-слою или среде под управлением клиента.

Для клиентов карта адресов должна быть частью онбординга. Какой префикс будет выделен под услугу? Это пространство China Telecom в Шэньси, пространство клиента, партнёрское пространство или общее пространство Tianyi Cloud? Кто управляет обратным DNS, обработкой жалоб, созданием ROA, политикой межсетевых экранов и экстренной блокировкой (null-routing)? Если услугу переносят, IP переезжает вместе с нагрузкой или клиент получает новые адреса? Эти вопросы превращают большую таблицу маршрутов в настоящую карту зависимостей.

Вывеска Cloud Base указывает на физическую ёмкость

Публичные сигналы об объектах делают название Cloud Base не просто декоративным. В отчёте о визите Школы экономики и менеджмента Northwest University за 2025 годбаза облачных вычислений China Telecom в провинции Шэньсиописана так: строительство началось в 2013 году, официальная эксплуатация — в 2015-м. Там же она названа крупным западнокитайским центром облачных вычислений и больших данных, с машинными залами уровня T4, PUE до 1,25, более чем 10 000 стоек, вариантами шкафов с жидкостным охлаждением мощностью 5 кВт, 8 кВт, 12 кВт и выше, заявленной экспортной пропускной способностью 22 Тбит/с и ролью одного из ключевых магистральных узлов IDC China Telecom. Также сказано, что студентам показали охлаждение, распределение электропитания, средства безопасности и архитектуру облака провинциального правительства.

Это сильнее расплывчатой продуктовой страницы, потому что описывает физические атрибуты: стойки, плотность мощности, конструкцию охлаждения, противопожарную защиту, полосу и роль кампуса. Исторически это согласуется с материалом Дата-центр Dynamics 2015 года об открытии China Telecomбазы облачных вычислений в Сиане, где сообщалось об открытии облачной базы западного региона и отмечалась более широкая региональная стратегия облачных узлов China Telecom. Вторичные и партнёрские страницы, включаяописание узла на Fenghuoyunи статьюShaanxi Phoenix 2018 годаоб облачных сервисах Tianyi для предпринимателей, также относят облачную базу Шэньси к новому городу Фэнси в Новом районе Сисянь и обсуждают ёмкости IDC, облака и колокации.

Эти публичные описания объектов помогают, но их всё равно нужно читать как контекст об объекте, а не как доказательство для конкретного клиента. Страница Northwest University — отчёт о посещении, а не сервисный контракт. Страницы Fenghuoyun и Phoenix — партнёрские или медиаописания, а не независимые аудиты. Проектная ёмкость — это не доступная ёмкость. Количество стоек не говорит о наличии свободных стоек, запасе по мощности, резервных коммутаторах, складском запасе оборудования, окнах миграции клиентов или текущем распределении между облаком, правительственными нагрузками, доступом в интернет, выделенными линиями и партнёрскими сервисами.

Наиболее полезный вывод — физическая конкретика с оговоркой. Клиентам следует считать, что с историей облачной базы Шэньси связан значительный кампус облачных вычислений и IDC China Telecom. Не следует считать, что любая услуга, маршрутизируемая через AS134768, физически находится в одном названном зале, обеспечена всем кампусом или защищена всеми описанными в публичной экскурсии средствами резервирования. Облачная база может вмещать несколько логически раздельных сред. У одних есть двухплощадочное аварийное восстановление. Другие однозонные. Третьи — партнёрские стойки. Четвёртые — зоны публичного облака. Пятые — колокация клиентов.

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

Установленная ёмкость — это не доступная ёмкость

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

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

Если у облачной базы заявлена экспортная полоса 22 Тбит/с, но тариф клиента ограничен по скорости или однохомно сидит внутри сегмента услуги, эта цифра не определяет его сценарий отказа.

Публичная документация самого Tianyi Cloud подтверждает этот многослойный взгляд.Домашняя страница Tianyi Cloudподаёт бренд вокруг интеграции сети и облака, безопасности, индивидуальной настройки и множества форм облака: публичное, частное, выделенное, гибридное, периферийное (edge) и full-stack сервисы. В документации ECS орегионах и зонах доступностизона доступности объясняется как один или несколько физических дата-центров внутри региона с независимыми питанием и сетью, и говорится, что цель — изоляция отказов, кроме крупных катастроф или массовых сбоев электропитания. Это разумное архитектурное заявление. Но оно также означает, что клиент должен знать, действительно ли купленная нагрузка разнесена по зонам или просто находится в одном локальном пуле ресурсов.

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

Практическая проверка — запросить заявление о ёмкости при отказе. Сколько вычислительных мощностей, хранилища, полосы и поддержки остаётся, если откажут стойка, хост, коммутатор, полка хранилища, ввод питания или маршрут аплинка? Сможет ли оставшийся пул нести обычную клиентскую нагрузку или только держать онлайн приоритетных клиентов? Нужно ли клиенту покупать вторую зону доступности или отдельный продукт аварийного восстановления, чтобы получить такую защиту? Без ответа «облачная база» остаётся ярлыком объекта, а не гарантией отказоустойчивости.

Электропитание, охлаждение и ремонтные окна определяют сбой

Страницы дата-центров часто подают питание и охлаждение как предмет инженерной гордости. Клиентам стоит читать их как факторы, определяющие сбои. В отчёте о визите Northwest University сказано, что у базы в Шэньси есть залы уровня T4, низкий PUE, стойки высокой плотности и развитые средства охлаждения и безопасности. На странице Fenghuoyun описаны резервные системы питания, услуги колокационного типа, ядро коммутации и заявления о сертификации безопасности. В статье Shaanxi Phoenix 2018 года говорится, что база имела большую запланированную ёмкость стоек и продвигала уровни сервиса по непрерывности сети и питания.

Это позитивные публичные сигналы, но не замена индивидуальных условий услуги.

У резервирования питания несколько слоёв. Вводы от сетей могут быть разными, но распределительные устройства — общими. ИБП могут быть резервированы, но время работы от батарей может быть коротким. Генераторы могут быть, но реальную автономность определяют логистика топлива, надёжность запуска и состояние обслуживания. У стоечных PDU могут быть вводы A и B, но клиент может случайно подключить оба питания к одной стороне. Шкаф высокой плотности с жидкостным охлаждением может быть мощным, но он добавляет зависимости от теплоносителя и обеспечивающих систем, которых нет у обычных серверов малой плотности.

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

Ремонтные окна — это то, где клиент видит правду. Отказ стойки может потребовать удалённых рук. Отказ сервера — запасных частей. Сбой маршрутизации — инженера, уполномоченного менять BGP. Сбой хранилища — эскалации к вендору. Сбой гипервизора — места для эвакуации. Сбой резервного копирования — человека, который примет решение о восстановлении, пока основная услуга лежит. Размер China Telecom не убирает эти шаги; он даёт оператору больше ресурсов, чтобы управлять ими, если процесс подготовлен.

Клиенту стоит спросить о пути инцидента простыми словами. Кто открывает внутреннюю заявку? Кто может войти в зал? Какие запчасти хранятся на площадке? Какие изменения требуют окна обслуживания? Как уведомляют клиентов, если плановое обслуживание затрагивает облачный периметр, ввод питания, плоскость хранения или IP-маршрут? Исключает ли SLA плановое обслуживание? За какие услуги положена компенсация, а какие поддерживаются лишь по возможности (best effort)? Эти детали менее эффектны, чем количество стоек, но они определяют, станет ли отказ коротким инцидентом или долгой миграцией.

Сигналы размещённых доменов требуют осторожной трактовки

Счётчики размещённых доменов в IPinfo делают AS134768 похожей на хостинговую сеть, и это полезное рыночное свидетельство. Сервис сообщает о более чем 23 000 размещённых доменов в ASN с концентрацией на небольшом наборе IP. bgp.tools также помечает тип сети как контентный. В публичном продуктовом портфеле Tianyi Cloud есть эластичные облачные хосты, прикладные облачные хосты, сервисы физических машин, хранилище, резервное копирование, аварийное восстановление и другие инфраструктурные предложения. Вместе эти сигналы подтверждают центральный тезис: сеть облачной базы — часть клиентской поверхности размещённых ёмкостей.

Но они не доказывают, какая именно услуга стоит за конкретным размещённым доменом. Домен может указывать на общий хостинг, реселлерскую платформу, прикладной межсетевой экран, обратный прокси, оборудование клиента в колокации, легаси-сервер, внутреннее правительственное приложение или корпоративного клиента с услугой статического IP. Концентрация IP-адресов — это не концентрация облачных аккаунтов. Большое число доменов на 103.236.90.151, например, может указывать на общий хостинг или адрес платформы, но в APNIC RDAP для базовой аллокации103.236.88.0/22зарегистрированным именем ресурса указано XIAOTEYUN. Значит, операционная цепочка сложнее, чем «China Telecom в Шэньси владеет каждым сайтом на этом IP».

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

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

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

Локализация данных — одновременно преимущество и ограничение

Поле региона для этого профиля — CN, и публичные данные подтверждают операционную поверхность в Китае. APNIC указывает AS в Китае. Материалы об облачной базе Шэньси относят физический кампус к району Сианя/Сисяня. Продуктовые страницы и сервисные документы Tianyi Cloud ориентированы на Китай. Такое локальное присутствие может быть ценно для китайских государственных, регулируемых и чувствительных к задержкам нагрузок. Оно же может ограничивать проектирование резервных копий, доступа поддержки и путей выхода.

Правовая среда Китая делает размещение данных чем-то большим, чем закупочное предпочтение.Перевод Закона о кибербезопасности, размещённый DigiChina, описывает требование о локализации персональной информации и важных данных, собираемых или производимых операторами критической информационной инфраструктуры в материковом Китае.Закон о безопасности данныхустанавливает национальную систему безопасности данных. Закон о защите персональной информации, кратко описанный гонконгскимPCPDи переведённый, в частности,China Law Translate, добавляет обязанности по обработке персональной информации и трансграничной передаче. Точные обязанности зависят от клиента, типа данных и схемы оказания услуг, но направление ясно: правила размещения, доступа и передачи имеют значение.

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

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

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

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

Контракт на услуги определяет, что облако не покрывает

Облачные клиенты часто путают формулировки о доступности с полной операционной ответственностью.Каталог SLA Tianyi Cloudперечисляет соглашения об уровне сервиса для вычислительных продуктов, хранилищ, резервного копирования и аварийного восстановления.Страница SLA ECSотсылает пользователей к условиям уровня сервиса для эластичных облачных хостов. В продуктовых документах Tianyi Cloud также различаются зоны доступности, типы инстансов, GPU-сервисы, облачные диски, продукты резервного копирования и аварийного восстановления. Такая структура говорит клиентам важное: отказоустойчивость собирается из конкретных сервисов, а не наследуется автоматически от родительского бренда.

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

Для AS134768 границу контракта стоит проверить по основным сценариям отказов. Если отказывает маршрут аплинка, это покрывается доступностью сети или исключается как обслуживание магистрали? Если стойка теряет питание, клиент получает компенсацию за услугу, поддержку восстановления или и то и другое? Если управляемая клиентом виртуальная машина неправильно сконфигурирована после переключения, где заканчивается ответственность провайдера? Если меры защиты от DDoS блокируют IP клиента, каков путь эскалации? Если у правительственной облачной нагрузки другие меры безопасности, чем у коммерческого облака, какая команда поддержки действует?

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

Лучший облачный контракт делает невидимые зависимости видимыми. Он указывает границу услуги, метрику доступности, уведомления об обслуживании, хранение данных, ответственность за резервное копирование, способ экспорта, уровни серьёзности поддержки, целевое время реакции и обязанности клиента. Если AS134768 — маршрутная поверхность, а поставщик услуги — Tianyi Cloud или подразделение China Telecom в Шэньси, клиенту нужны в одном документе и факты о маршрутах, и факты контракта.

Основные сценарии отказов, которые стоит проверить

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

Второй сценарий — отказ аплинка или магистрали. Текущие публичные представления показывают видимым аплинком AS4134. В политике whois упоминается AS4809, но маршрутные коллекторы не делают её доказанным путём переключения для клиента. Клиенту нужны активная карта аплинков, тест переключения, фильтры маршрутов, состояние RPKI и ожидаемое поведение, если у AS4134 возникнет региональная или национальная проблема.

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

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

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

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

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

Что повысило бы уровень доказательности

AS134768 получает средний (Medium) уровень сетевой доказательности, потому что у неё сильная публичная маршрутизация, официальная идентичность в APNIC и правдоподобный физический облачный контекст. Чтобы достичь Strong, публичные или контрактные данные должны связать таблицу маршрутов с клиентской услугой более прямо.

Первое улучшение — актуальное заявление о топологии. Оно должно называть активный AS-источник, аплинк-номера AS, продуктовые префиксы, регион и карту зон доступности. Оно должно объяснять, работает ли AS4809 для услуги или только присутствует в маршрутной политике. Оно должно указывать, используют ли нагрузки клиентов пространство China Telecom в Шэньси, общее пространство Tianyi Cloud, собственное пространство PI клиента или партнёрские адресные блоки. Оно должно сообщать, кто поддерживает ROA и кто реагирует на жалобы о злоупотреблениях или утечки маршрутов.

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

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

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

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

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

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

Сеть CHINANET SHAANXI province Cloud Base network — активный инфраструктурный субъект. APNIC, RIPEstat, bgp.tools, Hurricane Electric и IPinfo подтверждают один и тот же ключевой факт: AS134768 — живая сеть облачной базы China Telecom в провинции Шэньси с существенным следом IPv4 и IPv6. Выборочные проверки происхождения маршрутов валидны. Текущая видимость высокая. Сеть — не пустая оболочка.

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

Для покупателя практическая позиция — дисциплинированная уверенность. Считайте сеть живой. Считайте контекст облачной базы China Telecom в Шэньси значимым. А затем запросите данные, которые реально определяют сбои: продуктовый префикс, зону доступности, путь аплинка, владельца ROA, питание стойки, запас охлаждения, запасное оборудование, объём резервных копий, доказательства восстановления, эскалацию поддержки, исключения по обслуживанию, правила непрерывности оплаты и условия экспорта данных.

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