Кратко

  • На сайте Spidernet рекламируются несколько видов бизнес-хостинга, но не названы ни здание дата-центра, ни оператор площадки, ни облачная платформа, ни конфигурация оборудования, ни схема электропитания, ни состав операторов связи, ни гарантии уровня сервиса, ни публичная история инцидентов. Предложение видно; схема работы — нет.
  • APNIC зарегистрировала AS154632 компании Spidernet 17 апреля 2026 года и выделила блок162.4.2.0/23— 512 адресов IPv4 — 20 апреля. По состоянию на 12 июля AS154632 не анонсировала ни одного маршрута, тогда как162.4.2.0/24был виден глобально через AS151988 компании Go2Cloud Solutions. Вторая половина,162.4.3.0/24, в глобальной таблице отсутствовала.
  • Все проверенные публичные пути к активному префиксу Spidernet заканчивались цепочкойAS18229 AS151988: CtrlS непосредственно выше Go2Cloud, которая и анонсировала блок Spidernet. Это доказывает достижимость через данную цепочку, но не физическое разнообразие маршрутов, запасную пропускную способность, вторую площадку или прямые коммерческие отношения какой-либо конкретной формы.
  • Публичные страницы продаж в последний раз существенно обновлялись в 2021 году и многократно описывают другую компанию — Surchi Infotech. Они дают общие описания услуг, а не актуальные спецификации, цены, условия резервного копирования, целевые сроки восстановления или процедуры миграции.
  • Степень доказательности — слабая. Покупателю следует потребовать названное место размещения, контрагента, операторов площадки и сети, проверенные точки и сроки восстановления, владельца резервных копий, эскалацию поддержки, правила обслуживания, процедуры выгрузки данных и второй домен отказа, прежде чем передавать на сервис невосстановимую нагрузку.

Облачный каталог без карты инфраструктуры

Spidernet Cloud Solutions предлагает знакомый набор услуг хостинга для малого бизнеса. В навигации перечисленыоблачный хостинг баз данных,почтовый хостинг,облачное ERP,файловый хостинг,хостинг Tally,хостинг сайтовиобслуживание серверов. На главной странице также предлагается разработка программного обеспечения и приложений. Если принимать это буквально, перед нами не один продукт, а стек: вычисления, хранилище, базы данных, обмен сообщениями, бизнес-приложения, публичная доставка веб-контента и человеческая поддержка.

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

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

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

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

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

Публичная идентичность требует подписанного договора, а не совпадения названий

Самая убедительная текущая запись об идентичности — из регионального интернет-реестра.Запись APNIC для AS154632называет Spidernet Cloud Solutions, указывает адрес в Кэрол-Багх с сайта компании и тот же телефонный номер. Административным и техническим контактом указан Lalit Jain, используются адреса электронной почты наspidernet.net.in. Такое совпадение делает сайт и организацию в APNIC согласованной операционной идентичностью.

Похожее по названию юридическое лицо появляется и в индийских сервисах информации о компаниях.Профиль ZaubaCorpфиксирует Spidernet Cloud Solutions LLP, номер AAQ-6356, как зарегистрированную в Дели в сентябре 2019 года. Но в профиле указан зарегистрированный адрес в Питампуре и назначенные партнёры Kumar Roshan и Jatin Kumar. Эти данные не совпадают ни с адресом в Кэрол-Багх, ни с контактом Lalit Jain в записях APNIC.

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

Сам сайт делает эту потребность особенно острой.Страница «О нас»говорит, что описанные услуги предоставляет «Surchi Infotech». Страницы баз данных, почты, ERP, файлов, Tally, хостинга сайтов и обслуживания повторяют название Surchi.Страница конфиденциальностиссылается наsurchiinfotech.com, адисклеймерприписывает заявления и обязательства компании Surchi Infotech. При этом в шапке, контактах и домене представлен Spider Net.

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

Возраст материалов усиливает осторожность.Публичная запись WordPress для страницы баз данныхSpidernet и соответствующие записи для большинства облачных страниц и страниц поддержки серверов датированы последним изменением в июне 2021 года. В подвале указан копирайт 2021. Сетевые записи появились почти пять лет спустя, в апреле 2026 года. Компания может добавлять инфраструктуру, не перестраивая сайт, но покупателям не следует принимать старые общие тексты за актуальное техническое описание.

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

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

Сетевой след Spidernet настолько новый, что его почти можно читать как последовательность ввода в эксплуатацию. APNIC зарегистрировала организациюORG-SCS6-AP7 апреля 2026 года. AS154632 — 17 апреля. 20 апреля она выделила диапазон162.4.2.0162.4.3.255— портативный/23, содержащий 512 адресов IPv4. Записи реестра активны и используют домен, адрес и контакты Spidernet.

Через несколько часов после выделения адресов появился один более конкретный маршрут.История статуса маршрутизации162.4.2.0/24от RIPE NCCвпервые наблюдала префикс в 16:00 UTC 20 апреля, анонсированный AS151988. К 12 июля префикс был виден всем 326 пирам полной таблицы IPv4 в выборке RIPE RIS.Проверка валидации источника маршрутаобнаружила действующее разрешение для AS151988 на анонсирование этого/24.

Это значимые механизмы контроля. Портативное адресное пространство даёт Spidernet адресный актив, который не просто заимствован из аккаунта веб-хостинга. Действительное разрешение на маршрут снижает один класс случайных или несанкционированных анонсов источника. Глобальная видимость означает, что маршрут не был локальным экспериментом, видимым лишь нескольким сетям. Активный/24был достижим как маршрутный пункт назначения по всему измеренному интернету.

Ограничения столь же конкретны.Представление RIPEstat для AS154632не показало ни первого, ни последнего маршрута, ни адресного пространства IPv4 или IPv6, ни наблюдаемого соседа по состоянию на 12 июля.Список анонсируемых префиксовбыл пуст. Отдельныйотчёт CIDR Reportтакже описал ASN как не анонсируемый и не видимый в качестве транзитной AS.

Таким образом, Spidernet владела автономной системой, но не использовала её как видимый источник маршрутов. Её живой префикс анонсировала AS151988 компании Go2Cloud Solutions Private Limited. Вторая половина выделенного Spidernet блока —162.4.3.0/24— в глобальной таблице не была видна. В снимке с IPv6-префиксами ASN Spidernet не ассоциировался ни один.

Такая схема может быть совершенно легитимной. Клиент может попросить транзитного или хостинг-провайдера анонсировать портативное пространство, пока готовит собственные маршрутизаторы. Он может предпочесть BGP под управлением провайдера. Может осознанно анонсировать только нужные адреса. Может резервировать второй/24для роста, миграции или второй площадки. Но эта схема не может доказать, что у AS154632 есть независимый транзит, что неиспользуемый/24установлен на резервном оборудовании или что второй дата-центр сможет анонсировать его после сбоя.

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

Один живой префикс идёт по одной видимой цепочке провайдеров

Активный префикс также показывает, где контроль покидает Spidernet.Представление AS151988 у Hurricane Electricопределяет источник как Go2Cloud Solutions Private Limited и перечисляет162.4.2.0/24как адресное пространство Spidernet Cloud Solutions.Снимок AS151988 у RIPEstatпоказал, что эта сеть анонсирует три префикса IPv4/24, без IPv6-маршрутов и с одним наблюдаемым соседом.

Впубличных путях looking-glass для префикса Spidernetпоследними двумя сетями последовательно были AS18229 и за ней AS151988. AS18229 принадлежит CtrlS. Иными словами, коллекторы маршрутов видели, что Go2Cloud анонсирует префикс Spidernet и выходит в более широкий интернет непосредственно через CtrlS. Пути выше CtrlS различались, но край, ближайший к префиксу, не менялся.

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

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

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

Ни у AS154632, ни у AS151988 не было публичного сетевого профиля вAPI PeeringDB для Spidernetили вAPI PeeringDB для Go2Cloudна момент проверки. PeeringDB заполняется добровольно, поэтому отсутствие — не доказательство плохой инженерии. Это означает лишь, что там нет поддерживаемого оператором публичного перечня площадок, точек обмена, масштаба трафика, политики соединений или контактов сетевых операций, который подтверждал бы разнообразный след.

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

Выделенные адреса не превращаются в полезную облачную мощность

Выделение/23даёт соблазнительную цифру для заголовков: 512 адресов IPv4. Это не то же самое, что 512 продаваемых серверов, 512 активных клиентов или даже 512 полезных адресов хостов. Сетевые и широковещательные соглашения, назначение шлюзов, инфраструктурные устройства, антиспам-контроль и клиентская разбивка на подсети уменьшают полезное пространство. Более важно, что в снимке от 12 июля маршрутизировался только один/24.

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

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

Собственный продающий сайт компании не является доказательством использования нового блока. На момент проверкиspidernet.net.inрезолвился в82.180.143.143— адресное пространство, связанное сAS47583 компании Hostinger, а не с портативным блоком Spidernet. Его почтовый обменник указывал на Rediffmail Pro, а авторитетные DNS использовали сторонние серверы имён. Передача корпоративного сайта, почты и DNS на аутсорсинг — обычное дело. Это просто означает, что эти сервисы нельзя считать нагрузкой, доказывающей использование новой сети.

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

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

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

У каждого продукта свой путь отказа

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

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

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

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

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

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

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

Стойки, питание и запчасти остаются скрытым фундаментом

Ни один публичный источник не назвал дата-центр, принадлежащий Spidernet, или хотя бы площадку партнёра, обслуживающую162.4.2.0/24. Маршрут через Go2Cloud и CtrlS может подсказывать, где существует соединение, но BGP не может определить местоположение оборудования клиента. Базы геолокации могут быть полезными подсказками и часто ошибаются на уровне здания. Ответственный вывод: физическое расположение остаётся непроверенным.

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

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

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

Страница обслуживания серверовпризнаёт, что компоненты изнашиваются и что обслуживание нужно для сокращения простоев. Однако она подаёт обслуживание как общий план и снова называет Surchi Infotech. Там не сказано, мониторит ли Spidernet серверы клиентов, удалённая ли поддержка или на месте, какие часы покрыты, что считается аварией и как быстро техник доберётся до стойки.

Поэтому окна ремонта — первоочередная характеристика сервиса. «24/7» часто описывает приём заявок, а не гарантированное вмешательство. Клиенту стоит различать время ответа, время диагностики, время доступа на площадку, время доставки запчастей и время восстановления. Стоит спросить, меняются ли эти цели в выходные и праздники. Если оператор площадки предоставляет «удалённые руки», в договоре должно быть указано, как Spidernet проводит эскалацию и кто платит за аварийные работы.

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

Концентрация поддержки может превратить сбой в долгий простой

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

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

Цепочка удлиняется, когда адресный блок анонсирует другая сеть. Инцидент со связностью может потребовать, чтобы клиент связался со Spidernet, Spidernet — с Go2Cloud, а Go2Cloud — со своей площадкой или вышестоящим оператором. У каждой стороны могут быть свои определения серьёзности и требования к доказательствам. Трассировки, предоставленной клиентом, может не хватить; вышестоящему оператору могут понадобиться логи маршрутизатора; площадка может ждать авторизованного контакта. Минуты копятся на договорных границах.

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

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

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

Восстановление требует второго домена отказа, а не второй копии в той же стойке

Публичные данные не подтверждают ни одного заявления о мультиплощадочной мощности. Неиспользуемый162.4.3.0/24Spidernet в перспективе мог бы поддержать другое развёртывание, но неанонсируемая подсеть — не площадка восстановления. Точно так же резервная копия на другом диске того же массива не переживёт отказ массива; реплика в том же помещении может не пережить потерю питания или охлаждения; а два сетевых сеанса у одного провайдера не переживут его отказ.

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

Целевые показатели восстановления должны быть числовыми. Целевая точка восстановления (RPO) отвечает, сколько данных может быть потеряно; целевое время восстановления (RTO) — как долго сервис может оставаться недоступным. Это не то же самое, что частота резервного копирования. Резервная копия, снимаемая каждый час, может всё равно требовать двух дней на восстановление, если провайдер ни разу не репетировал процесс или у него нет запасного оборудования.

Руководство NIST по планированию непрерывностирекомендует анализ влияния на бизнес, превентивные меры, стратегии восстановления, альтернативную площадку там, где это уместно, тестирование и постоянное обслуживание. Хотя оно написано для федеральных информационных систем, эта последовательность полезна любому покупателю. Она превращает «мы делаем резервные копии» в набор вопросов о том, что защищено, как оно возвращается и кто доказывает, что это работает.

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

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

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

Локализация не определена, и некоторые клиенты не могут это игнорировать

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

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

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

Отраслевые правила могут быть уже и строже.Указание Резервного банка Индии 2018 года о данных платёжных системтребует от подпадающих под него провайдеров систем хранить все данные, относящиеся к платёжным системам, только в системах, находящихся в Индии, с учётом оговорённого порядка для иностранной части транзакции. Это требование относится к регулируемому платёжному контексту, а не автоматически к каждому клиенту Spidernet. Участник платёжной системы, рассматривающий размещённые базы данных или ERP, не может принять неуказанное местоположение.

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

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

Как сбой выглядел бы для клиентов

Основные пути отказа не теоретичны, хотя в публичных записях не найдено конкретного сбоя Spidernet.

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

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

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

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

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

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

Затронутые люди выходят за пределы ИТ-команды покупателя. Сотрудники могут потерять сеансы бухгалтерии или ERP. Клиенты могут не суметь оформить заказы или получить сообщения. Поставщики могут не получить заказы на закупку. Финансисты могут пропустить сроки отчётности или сверки. Небольшая размещённая нагрузка может стоять на удивление большим бизнес-процессом.

Какие доказательства стоит требовать покупателю

Запрос на проверку Spidernet может быть кратким, потому что публичные пробелы очевидны.

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

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

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

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

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

В-шестых, докажите сеть. Если Spidernet намерена использовать AS154632 для автономии, она должна показать, когда ASN начнёт анонсировать маршруты, какие вышестоящие операторы будут её обслуживать и как будет тестироваться переключение. Если маршрутизация с анонсированием у провайдера — постоянная модель, нужно задокументировать процедуру передачи и аварийного анонсирования её портативного/23. Доступность IPv6 следует зафиксировать, а не предполагать.

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

Живой префикс — это начало, а не сертификат отказоустойчивости

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

Но видимая схема узка. AS154632 не была активна. Один/24анонсировался через AS151988 компании Go2Cloud, единственным наблюдаемым непосредственным соседом которой была AS18229 компании CtrlS. Второй/24не маршрутизировался. Никакие публичные данные не подтверждали вторую площадку, второй источник, IPv6, активные размещённые домены на новом блоке, отказоустойчивость уровня площадки, запасное оборудование или протестированное восстановление.

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

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

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