Основные выводы

  • Регистрационная записьAPNIC для AS151217идентифицируетSIHE-SHCTкак Sihe Cloud Shanghai Technology Co., Ltd. с адресом: Шанхай, улица Куньян, 1508. Компании также принадлежат портативный диапазон IPv4160.19.76.0/23и портативный диапазон IPv62401:9e20::/32; все ресурсы зарегистрированы в мае 2024 года с совпадающими контактамиsihe.ai.
  • Сам AS151217 публично не активен.Статус маршрутизации по данным RIPEне сообщает об анонсируемом IPv4- или IPv6-пространстве, не показывает наблюдаемых соседей и нулевую видимость среди пиров с полной таблицей маршрутов. IPv6-аллокация шанхайской компании также не маршрутизируется.
  • С IPv4-блоком ситуация иная:RIPE видит160.19.76.0/23у всех сообщающих IPv4-пиров с источником AS9808 (China Mobile). Маршрут виден с июня 2024 года. Это доказывает публичную достижимость адресного ресурса, но не независимую эксплуатацию сети через AS151217 и не конкретное размещение в стойке.
  • Работающий витринный сайт Sihe Cloudпродаёт виртуальные машины, контейнеры, управляемые базы данных, объектное и файловое хранилище; доступныконсольицентр документации. Однако эти публичные страницы истандартное соглашение об оказании услугназывают поставщиком Haining Sihe Cloud Computing Technology Co., Ltd. Роль шанхайской компании в розничном предоставлении услуг они не объясняют.
  • Поэтому разумный вывод остаётся узким. Sihe Cloud Shanghai Technology Co., Ltd. документально контролирует номерные ресурсы интернета и имеет IPv4-блок, маршрутизируемый через крупного оператора. Публичные данные не подтверждают, что компания владеет дата-центром, управляет клиентским облаком, контролирует мультиоператорскую пограничную сеть, держит резерв для миграции или несёт обязательства по поддержке и возврату данных, продаваемые под именем Sihe.

Живой маршрут — самый сильный факт, и он порождает самый трудный вопрос

Небольшие облачные компании проще всего находить по публичным интернет-ресурсам, привязанным к их юридическим наименованиям. Так и здесь, но записи не дают той простой картины, которую предполагает название компании. ЗаписьAS151217называет держателем Sihe Cloud Shanghai Technology Co., Ltd., указывает сетевое имяSIHE-SHCTи размещает административный контакт на втором этаже здания 2 по улице Куньян, 1508, район Миньхан, Шанхай. Регистрация произведена 11 мая 2024 года. Административный, технический контакты и контакт для жалоб о злоупотреблениях используют доменsihe.ai.

В тот же день компания получила два портативных адресных ресурса. Первый —160.19.76.0/23— охватывает 512 IPv4-адресов. Второй —2401:9e20::/32— IPv6-аллокация, достаточно большая для огромного числа клиентских подсетей. Это не случайные упоминания в каталоге. Это авторитетные регистрационные записи, ведущиеся через APNIC и CNNIC. Они подтверждают, что шанхайская компания является указанным держателем ресурсов и имеет признанную операционную контактную поверхность для жалоб и администрирования сети.

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

Тем не менее IPv4-блок шанхайской компании жив.Сетевая информация RIPEотносит весь /23 к AS9808.Представление статуса маршрутизациификсирует AS9808 как источник, сообщает о видимости у всех 325 доступных IPv4-пиров в точке наблюдения и датирует первое появление маршрута 7 июня 2024 года.История маршрутизациипоказывает повторяющиеся интервалы видимости с тем же источником, начиная с июня 2024 года. Маршрут — не забытая реестровая аллокация. Он достигает глобальной таблицы.

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

AS151217 назначен, но молчит

Текущая картина коллекторов данных по собственному ASN шанхайской компании не оставляет неоднозначности.Обзор AS в RIPEпомечает AS151217 как неанонсируемый.Ответ о статусе маршрутизациисообщает о нулевом количестве IPv4-префиксов, нулевом количестве IPv6-префиксов, отсутствии первого и последнего маршрута и отсутствии наблюдаемых соседей. Видимость нулевая среди 325 IPv4- и 322 IPv6-пиров с полной таблицей.Ответ по анонсируемым префиксампуст, апредставление соседейне сообщает ни о левом, ни о правом, ни об уникальном, ни о неопределённом соседе.

Независимые данные о топологии указывают в ту же сторону.Запись AS Rank от CAIDAидентифицируетSIHE-SHCTв Китае, но помечает его как ненаблюдаемый, без степеней провайдера, пира или клиента и без конуса адресов или префиксов.CIDR Reportсообщает, что этот ASN не используется для анонсирования префикса в глобальной таблице и не виден как транзитный AS.Запрос к PeeringDBне возвращает ни одного сетевого объекта. Участие в PeeringDB добровольное, поэтому отсутствие там не доказывает отсутствие соединений. Однако вместе с данными коллекторов оно не даёт оснований для публичного пиринга или присутствия в узлах под AS151217.

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

Портативная IPv6-аллокация тоже молчит.Статус RIPE для2401:9e20::/32не находит ни источника, ни более специфичного маршрута, ни менее специфичного маршрута; видимость среди доступных IPv6-пиров нулевая. Аллокация административно значительна, но операционно отсутствует в публичной таблице. Этот разрыв важен для клиентов, ожидающих сервис с двойным стеком, потому что IPv6-ресурс на бумаге не эквивалентен маршрутизируемому IPv6-сервису с проверенными клиентскими назначениями, фильтрацией, мониторингом и реагированием на инциденты.

Картина безопасности маршрутизации тоже скудная.Валидатор RPKI в RIPEвозвращаетunknownдля пары AS9808 и160.19.76.0/23, поскольку не находит подтверждающей авторизации источника маршрута (ROA). Unknown не означает invalid и не является доказательством угона маршрута. Это значит, что публичная криптографическая система не даёт положительной авторизации на анонсирование этого префикса сетью AS9808. Для портативного блока, маршрутизируемого через третью сторону, действующая авторизация сделала бы предполагаемый источник более явным и сняла бы одну из категорий неоднозначности маршрутизации.

Источник маршрута — China Mobile, а не ASN держателя ресурса

Запись APNIC для AS9808идентифицируетCHINAMOBILE-CNкак China Mobile Communications Group Co., Ltd. Это крупная операторская сеть с масштабом и маршрутным охватом, намного превышающими /23 шанхайской компании. Её присутствие как источника даёт блоку глобальную достижимость и путь операторского уровня в остальной интернет. Но оно не сообщает клиенту, покупает ли шанхайская компания транзит, арендует ли канал доступа, арендует ли хостинговые мощности, пользуется ли продуктом анонсирования адресов или имеет какое-то иное соглашение.

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

Коммерческий спор по каналу может сделать недостижимой действительную аллокацию адресов.

Публичный маршрут показывает также только один источник, а не множественность операторов. Сервис с несколькими операторами может анонсировать префикс через один ASN, используя других операторов способами, которые коллекторы не раскрывают, но для предположений здесь нет публичных оснований. У AS151217 нет видимых соседей. У /23 один видимый источник. Отсутствиезаписи в PeeringDBоставляет без добровольного перечня точки обмена, узлы и политику взаимодействия. Поэтому покупателю следует рассматривать множественность операторов как нерешённый инженерный вопрос, а не выводить её из наличия ASN или общих заявлений на связанном коммерческом сайте.

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

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

Заказываемый сервис Sihe указывает на другую компанию-контрагента

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

Но юридическое лицо, указанное на этом сервисе, — не Sihe Cloud Shanghai Technology Co., Ltd. Метаданные главной страницы, описание компании и подвал сайта идентифицируют Haining Sihe Cloud Computing Technology Co., Ltd.Страница «О компании»сообщает, что хайнинская компания основана в 2018 году, и описывает облачные вычисления, проектирование и производство оборудования, строительство и эксплуатацию ЦОД. Она приводит номер службы поддержки клиентов и адрес: Хайнин, провинция Чжэцзян, улица Цанхай, 180. В подвале документации также указана Haining Sihe, показаны запись в реестре ICP провинции Чжэцзян и номер лицензии на услуги добавленной стоимости в области телекоммуникаций.

Стандартное соглашение об услугах и SLAболее явны. В нём сказано, что Haining Sihe Cloud Computing Technology Co., Ltd. заключает с пользователем договор на предоставление облачной платформы Sihe. Местом исполнения назван адрес: Хайнин, улица Цанхай, 180. Соглашение обещает круглосуточную эксплуатационную поддержку, ежемесячную доступность не менее 99,9 процента и начало реакции в течение 30 минут после технической проблемы. В нём также определены исключения, обязанности по оплате, права на приостановку, условия расторжения и возврат ресурсов.

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

Эта граница должна оставаться чёткой. Шанхайскую компанию можно описывать как держателя AS151217 и двух портативных аллокаций — так говорит реестр. Хайнинскую компанию можно описывать как публичного поставщика — так говорят витрина и условия. IPv4-блок можно описывать как анонсируемый China Mobile — так говорит маршрут. Соединение этих трёх фактов в единую корпоративно-операционную цепочку требует соглашения, регистрационных документов о собственности или технического раскрытия самой стороны, которых нет в открытом доступе.

Витрина доступна через четвёртую сетевую поверхность

Видимый веб-сервис в настоящее время не использует портативный IPv4-блок шанхайской компании. Публичный DNS дляглавной страницы,консолиисайта документацииведёт через узлы Deyang с именем Sihe к адресу222.213.119.154.Сетевая информация RIPEпомещает этот адрес в диапазон222.208.0.0/13с источником AS4134.Адресная запись APNICидентифицирует покрывающую сеть какCHINANET-SC— сеть China Telecom в провинции Сычуань.

Это мгновенный снимок пограничной сети сервиса, а не карта приложений или хранилищ. DNS-имя, содержащее Deyang, может отражать соглашение об именах оператора; оно не доказывает, в каком здании находится каждый сервер. ASN-источник определяет сеть, анонсирующую конечную точку, а не владельца сервера за ней. Веб-фронтенд также может быть отделён от вычислительных и storage-регионов. Наблюдение всё равно полезно: оно показывает, что самые заметные клиентские поверхности Sihe не достигаются через AS151217 и не через160.19.76.0/23шанхайской компании.

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

Этот разрыв создаёт и легко упускаемый сценарий сбоя. Витрина и консоль могут отказать, пока клиентские машины остаются доступными. Клиентские машины могут отказать, пока консоль выглядит здоровой. Документация может оставаться онлайн при сбое control plane. Маршрутизируемый оператором /23 шанхайской компании может оставаться видимым, когда стойка за ним теряет питание, или быть отозванным, пока все серверы под напряжением. Достоверная модель статуса требует отдельных проверок доступа к аккаунту, управляющих операций, достижимости вычислений, операций хранилища, DNS, каждого публичного префикса и каждой анонсируемой зоны.

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

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

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

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

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

Страница тарифов ECSоценивает процессор, память, диск и исходящий трафик как раздельные единицы потребления и сообщает, что цена в консоли имеет приоритет. Для покупателя это экономически понятно, но каждая единица соответствует конечной инфраструктуре. Виртуальный процессор — это доля процессора хоста. Гигабайт памяти должен быть установлен в сервере. Дисковая аллокация потребляет носители, контроллеры, трафик репликации и запас для замены. Исходящий трафик потребляет обязательства оператора и, возможно, перегруженный порт. Розничный счётчик не раскрывает закупочные обязательства провайдера или резерв, доступный при сбое.

Установленная, продаваемая и восстанавливаемая мощность — разные величины

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

Главная страница Sihe заявляет о трёх машинных залах или зонах доступности с независимыми охлаждением и сетями, двух независимых вводах от двух подстанций, многоканальном доступе в сеть, охлаждении по схеме N+1, собственной фотоэлектрической станции, 20 Гбит/с публичной полосы и внутренней сети 50GbE или 400GbE. Это значимые заявления, поскольку они описывают физические и логические проектные решения. Они не сопровождаются названиями объектов, адресами площадок, однолинейными электрическими схемами, деталями операторских каналов, введённой нагрузкой, утилизацией, аудиторскими отчётами или тестами переключения.

Поэтому заявления следует читать как заверения поставщика, а не как измерения текущей доступной клиентам мощности.

Слово «три» особенно легко переоценить. Три зала в одном здании не дают той же защиты, что три площадки на раздельных системах энергоснабжения, защиты от наводнений и пожаров и у разных операторов. Три логические зоны могут по-прежнему разделять control plane или сеть хранения. Независимое охлаждение внутри залов может зависеть от одной системы водоснабжения или электроснабжения здания. Два ввода могут сходиться на одной подстанции, распределительном щите или трансформаторе, несмотря на проектное намерение их разделить. Солнечная установка может снизить затраты на энергию, не поддерживая нагрузку серверов при отказе сети.

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

Для шанхайской организации на первом месте — пробел в определении местоположения. Её реестровый адрес на улице Куньян — это адрес административного контакта, и его нельзя выдавать за место размещения стоек. Хайнинское соглашение об услугах указывает место исполнения договора, но не перечень дата-центров. Веб-пограничная сеть использует адресное пространство Сычуани и метки Deyang, но это не определяет местоположение всего облака. Маршрут /23 анонсирует China Mobile, но источник у оператора не раскрывает, в каком городе или здании находится оконечное оборудование.

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

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

Дерево отказов начинается ниже виртуальной машины

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

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

Шанхайский маршрут добавляет в это дерево зависимость от оператора. AS9808 — публичный источник для160.19.76.0/23. Если клиент в этом блоке теряет связность, хостинговая сторона должна решить, находится ли сбой внутри виртуальной сети, на коммутаторе перед сервером, на стыке с оператором, в магистрали оператора, в распространении маршрута или в удалённой сети доступа. Если компания не контролирует напрямую маршрутизаторы источника, качество эскалации становится частью качества услуги. Практические вопросы: у кого аккаунт оператора, какой приоритет у канала, могут ли инженеры напрямую звонить в центр управления сетью и требуют ли экстренные изменения маршрута коммерческого одобрения.

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

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

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

Это границы того, что клиент может уверенно предполагать.

Заявления об избыточности должны выдерживать проверки на общие причины

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

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

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

А также показывала бы, сохраняет ли переключение тот же клиентский адрес или требует изменения DNS и адресов.

Испытания важнее схем. Контролируемый отзыв маршрута может показать, действительно ли резервный путь пропускает трафик. Эвакуация хоста может показать, существует ли резерв для миграции. Упражнение по восстановлению может показать, читаемы ли резервные копии и переживают ли учётные данные инцидент control plane. Испытание переключения питания может показать, остаётся ли стойка под напряжением. Упражнение для поддержки может показать, отвечают ли нужные люди в обещанное окно. Без результатов избыточность остаётся проектным намерением.

Спецификация BGPобъясняет, как сети обмениваются достижимостью и путями AS, аэксплуатационные рекомендации в RFC 7454охватывают фильтрацию, защиту сеансов и контрольные механизмы, такие как ограничение максимального числа префиксов. Эти практики снижают риск маршрутизации, но их нельзя вывести из зарегистрированного ASN. Молчание AS151217 означает, что нет видимой публичной эксплуатации, по которой их можно было бы оценить. Для живого /23 релевантная политика — это прежде всего политика источника AS9808 и коммерческое соглашение, которое её санкционирует и регулирует.

Восстановление — это проблема мощности, а не только функция ПО

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

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

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

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

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

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

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

Клиенту следует проверить внешнее восстановление до того, как оно понадобится. Экспортировать репрезентативный образ виртуальной машины или пересобрать из конфигурации. Восстановить базу данных в независимо контролируемой среде. Скопировать значимый набор объектов с метаданными и проверить контрольные суммы. Воссоздать контроль доступа. Измерить пропускную способность в обычное и пиковое время. Зафиксировать, какие шаги требуют консоли Sihe или службы поддержки. Эти проверки превращают переносимость из договорной надежды в наблюдаемое свойство.

Поддержка, биллинг и состояние договора могут остановить здоровую инфраструктуру

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

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

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

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

Граница юридических лиц снова важна здесь. Опубликованное стандартное соглашение называет поставщиком Haining Sihe. Портативный IPv4-блок называет держателем шанхайскую компанию. Маршрут анонсирует AS9808 от China Mobile. Если клиентский адрес в этом блоке приостановлен или недоступен, клиенту нужно знать, какой договор регулирует адрес, какая компания управляет аккаунтом, какая компания говорит с оператором и у какой стороны находится оборудование с данными. Общий бренд не заменяет такое распределение ответственности.

Показатель ежемесячной доступности 99,9 процента тоже нужно переводить в операционные последствия. В 30-дневном месяце 0,1 процента — это примерно 43 минуты. Исключённые обслуживание и события третьих сторон могут увеличить фактический простой, не меняя договорного расчёта. Компенсация, если она предусмотрена, не восстанавливает потерянные транзакции и не чинит повреждённые данные. Полезный вопрос при закупке — не выглядит ли процент знакомым, а соответствуют ли архитектура сервиса, исключения, доказательства и план восстановления реальной модели потерь клиента.

Локализация данных — это цепочка копий и контролёров

Все выявленные записи о компаниях и сетях находятся в Китае, но «в Китае» — не полный ответ о месте размещения данных. Регистрация шанхайской компании указывает на Миньхан. Стандартное соглашение об услугах указывает на Хайнин. Пограничная сеть витрины указывает на адрес China Telecom в Сычуани и узлы с именем Deyang. IPv4-блок обслуживает China Mobile, без публичного указания площадки. Документация продуктов заявляет о копиях хранилища на разных устройствах и в разных дата-центрах. Эти факты описывают несколько мест и ролей, не отображая первичные и вторичные данные клиента.

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

У каждого типа могут быть разные контролёр, срок хранения и местоположение.

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

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

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

Кто страдает, когда цепочка отказывает

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

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

Радиус поражения зависит от того, независимы ли рекламируемые зоны и сознательно ли клиенты распределяют рабочие нагрузки. Автоматическая миграция может смягчить отказ одного хоста, но сконцентрировать нагрузку на оставшихся хостах. Многоузловая база данных может пережить отказ одного узла, но не общий сбой хранилища или control plane. Репликация объектов может пережить отказ диска, но не удаление в масштабе аккаунта, если все копии следуют одной и той же авторитетной инстанции. Множественность операторов может защитить один канал, но не общую ошибку политики маршрутизации. Архитектура должна соответствовать угрозе.

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

Какие доказательства прояснили бы роль шанхайской компании

Первым полезным раскрытием стало бы короткое заявление от Sihe Cloud Shanghai Technology Co., Ltd. о её текущей роли. Управляет ли она сетевыми ресурсами для хайнинского сервиса, держит ли адреса от имени связанной компании, предоставляет ли мощности в Шанхае, ведёт ли договор с оператором или готовит будущую инфраструктуру? Какие сервисы используют160.19.76.0/23? Почему AS151217 не является источником? Планируется ли развёртывание2401:9e20::/32? Ясные ответы связали бы реестровые факты с операционным назначением без раскрытия чувствительных данных клиентов.

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

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

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

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

Вывод: маршрутизируемый ресурс с нерешённой границей сервиса

Sihe Cloud Shanghai Technology Co., Ltd. — это не просто имя в старой записи. За ней закреплены AS151217, портативный IPv4-блок /23 и портативный IPv6-блок /32, зарегистрированные с согласованными шанхайскими контактами и контактамиsihe.ai. Её IPv4-блок публично маршрутизируется, виден в глобальной таблице и с июня 2024 года анонсируется сетью AS9808 (China Mobile). Это осязаемая сетевая активность, привязанная к ресурсу, который контролирует компания.

Те же данные не показывают независимо эксплуатируемую шанхайскую сеть. AS151217 ничего не анонсирует, не имеет наблюдаемых соседей и не имеет видимой истории префиксов. IPv6-аллокация находится в спящем состоянии. IPv4-маршрут использует ASN другой компании и не имеет подтверждающей авторизации источника маршрута в наблюдаемой картине RPKI. Никакой публичный объект, опись стоек, стык с оператором, команда поддержки или клиентская рабочая нагрузка не привязаны конкретно к шанхайской организации.

Живой сервис Sihe Cloud добавляет коммерческую субстанцию, но не чистую атрибуцию. Его витрина, консоль, документация и договор показывают, что клиенты могут покупать и эксплуатировать облачные продукты под именем Sihe. Они также называют публичным поставщиком Haining Sihe Cloud Computing Technology Co., Ltd. и используют клиентскую веб-границу в адресном пространстве China Telecom в Сычуани. Публичные материалы не объясняют, как участвует шанхайский держатель ресурсов.

Итоговая оценка доказательств для точной цепочки «организация — инфраструктура» слабая, несмотря на сильные доказательства отдельных реестровых и маршрутных фактов. Клиентам не следует делать вывод, что шанхайская компания владеет дата-центром, управляет тремя независимыми площадками, эксплуатирует мультиоператорскую границу или несёт розничное SLA только потому, что её /23 жив и её имя разделяет бренд Sihe. Им следует спрашивать, кто контролирует источник, где заканчиваются адреса, какая компания владеет или арендует стойки, каков резерв для миграции, кто несёт обязательства по поддержке и как данные покидают систему в условиях давления.

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