Кратко

  • EHOST SOFTWARE COMPANY LIMITED подтверждается согласованными юридическими, контактными и сетевыми идентификаторами: операционный сайт называет Công ty TNHH Phần Mềm EHOST и налоговый код 0312916711, а публичные записи маршрутизации идентифицируют AS135920 как EHOST-VN и показывают пять анонсируемых IPv4-префиксов/24.
  • Маршрутизируемый след реален, но скромен. Изученные BGP-источники показывают 1 280 анонсируемых IPv4-адресов, отсутствие анонсируемого IPv6-пространства и единственное вышестоящее соединение, наблюдаемое через AS135905. Это не доказывает ни плохой сервис, ни физическое подключение к одному оператору, но делает существенными вопросы о разнообразии маршрутизации, аварийном переключении и доступности IPv6 для конкретных продуктов.
  • Публичные коммерческие поверхности Ehost не дают стабильной спецификации продукта. Один и тот же тариф Cloud 1G за 250 000 донгов описан по-разному на маркетинговой странице и в биллинговом портале; расходятся и публичные, и биллинговые предложения колокации. Поэтому авторитетные условия по CPU, памяти, хранилищу, IOPS, полосе пропускания, локации, резервному копированию и поддержке должен определять подписанный заказ на поставку.
  • Того же подхода требуют заявления о резервном копировании, безопасности и поддержке. Ehost обещает ежедневные или еженедельные резервные копии, физические межсетевые экраны, AntiDDoS, поддержку 24/7 и пятиминутный ответ на некоторых продуктах, но не раскрывает публично полный план восстановления, матрицу критичности, график сервисных кредитов, историю инцидентов, процесс управления жалобами на злоупотребления или независимое страховое покрытие.
  • Провайдер может подойти клиентам, которым важны вьетнамский биллинг, прямое человеческое общение в поддержке, помощь с миграцией и меню из виртуального хостинга, облака, выделенных серверов, колокации, резервного копирования и DDoS-защиты. Покупателям со строгими требованиями к непрерывности, комплаенсу или переносимости необходимо провести проверку реального предоставления услуг (proof of service) и согласовать осуществимый план выхода до запуска в продакшен.

Сервер за 250 000 донгов с двумя ответами

Начнём с самого дешёвого облачного пакета Ehost. На публичной страницеCloud Serverтариф «EHOST 1G» стоит 250 000 вьетнамских донгов в месяц и описан как два ядра CPU, 2 ГБ оперативной памяти, 30 ГБ SSD-хранилища и сетевое подключение 100 Мбит/с. На странице указано, что все облачные тарифы получают как минимум 2 000 IOPS для хранилища. На рабочей странице заказов EhostSSD Cloud Serverтариф «Cloud 1G» тоже начинается от 250 000 донгов в месяц, но показанная спецификация — одно ядро CPU, 2 ГБ оперативной памяти, 20 ГБ SSD-хранилища, сеть 200 Мбит/с и 10 000 IOPS.

Ни одна из страниц не является незаметной. Одна — это описание услуги для клиентов; другая — система, через которую покупателя приглашают оформить заказ. И при этом они описывают существенно разные вычислительные блоки. Расхождение не ограничивается самым дешёвым тарифом. Публичное предложение Cloud 2G указывает два ядра, 4 ГБ памяти и 40 ГБ хранилища; биллинговая версия — два ядра, 2 ГБ памяти и 40 ГБ. Более дорогие пакеты тоже различаются по памяти и диску. Отдельная биллинговая категорияSSD Cloud Server C6представляет ещё одно поколение похоже названных тарифов, включая Cloud 1G за 350 000 донгов с двумя ядрами, 2 ГБ памяти, 30 ГБ хранилища, 200 Мбит/с и 50 000 IOPS.

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

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

Поэтому первая проверка при покупке у Ehost должна быть документальной. В коммерческом предложении, заказе или договоре должны быть указаны: точное семейство и поколение продукта; число vCPU и модель планирования; гарантированная память; полезный объём хранилища; тип носителя; минимальные и пиковые IOPS; национальная и международная полоса пропускания; лимиты трафика; выделение публичных IP; локация; образ операционной системы; объём управления; включённое резервное копирование; плата за восстановление; налоги; срок продления. Покупатель должен хранить этот документ вместе со счётом и подтверждением первичного предоставления ресурсов.

Центральный тезис этого обзора исходит из двух описаний Cloud 1G. Инфраструктуру Ehost нельзя корректно описать фирменным названием, помесячной ценой или словом «облако». Реальный продукт начинается там, где стороны сверяют страницу продаж, биллинговый портал и фактически оказанную услугу.

Точное юридическое лицо за экранами

Границы юридического лица важны тем более, что «Ehost» существует и как бренд, и как домен, и как портал поддержки, и как сервис AntiDDoS, и как зарегистрированная сеть. Рассматриваемая здесь компания —EHOST SOFTWARE COMPANY LIMITED, по-вьетнамски —Công ty TNHH Phần Mềm Ehost, налоговый код0312916711. Настранице контактовEhost указаны юридическое наименование, регистрационный номер, адрес в Хошимине: 147/25 An Dương Vương, район Биньтан, телефон 0938-227-199 и контактный адрес электронной почты@ehost.vn. В нижнем колонтитуле указано, что регистрация предприятия выдана 9 сентября 2014 года.

Внешнийагрегатор вьетнамских налоговых записейнезависимо связывает тот же налоговый код с EHOST SOFTWARE COMPANY LIMITED, тем же адресом, датой начала деятельности 9 сентября 2014 года и представителем Nguyễn Thanh Tâm. Эта запись — полезное подтверждение, но не замена свежей выписке из официального реестра предприятий Вьетнама. Статус и отраслевые классификации в ней стоит рассматривать как зафиксированное на дату отображение публичных документов агрегатором.

Сетевая идентичность даёт отдельную проверку непрерывности.BGP.toolsвоспроизводит исходные регистрационные данные APNIC для AS135920:EHOST-VN, описание — Ehost software company limited, страна — Vietnam, сопровождение — через VNNIC. Запись была изменена в январе 2026 года.Страница IPinfo для AS135920тоже классифицирует сеть как хостинговую и связывает её с тем же названием компании.

Эти связи позволяют честный вывод: юридическое лицо, действующая торговая поверхностьehost.vn, биллинговая и сервисная поверхностьsecure.ehost.vnи AS135920 относятся к согласованному операционному контуру. Они не доказывают, что каждая услуга, рекламируемая на каждом связанном домене, принадлежит компании, управляется ею или гарантируется ей. IPinfo, например, указываетehost.com.vnкак домен для ASN, тогда как фактический операционный сайт, рассмотренный здесь, —ehost.vn; первый в ходе этого исследования не отдал рабочую страницу. Это вопрос доменной преемственности для компании, а не повод разделять или сливать юридические лица.

Та же осторожность относится к AntiDDoS. Ehost напрямую ссылается наAntiddos.vn, а на облачной странице указано, что клиенты могут интегрироваться с этим сервисом. Сайт AntiDDoS представляет себя как многоузловую вьетнамскую сеть фильтрации, основанную в 2015 году. Рассмотренные здесь публичные страницы не раскрывают отдельную корпоративную идентичность или достаточную договорную цепочку, чтобы определить, является ли Antiddos.vn подразделением, продуктом, дочерней компанией или коммерческим партнёром EHOST SOFTWARE COMPANY LIMITED. Покупателю следует явно зафиксировать контрагента, а не выводить его из перекрёстных ссылок.

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

Что доказывает AS135920 — и чего не доказывает

AS135920 — самое сильное независимое свидетельство того, что Ehost управляет чем-то большим, чем брошюра и витрина реселлера. В зафиксированном срезе публичного BGP автономная система анонсирует пять IPv4-префиксов/24:45.123.96.0/24,45.123.97.0/24,103.63.212.0/24,103.63.213.0/24и103.63.215.0/24. Это 1 280 IPv4-адресов.BGP.toolsиIPinfoпоказывают, что префиксы покрыты валидными авторизациями происхождения маршрута. Таблица валидации происхождения маршрутов APNIC Labs для Вьетнама сообщает о 100 % валидного покрытия измеряемого пула адресов EHOST-VN.

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

Валидность RPKI — тоже реальная проверка. Она позволяет валидаторам маршрутов криптографически подтверждать, что именно AS135920 уполномочена анонсировать покрытые префиксы. В отчёте VNNIC об интернет-ресурсах за 2024 год RPKI и IPv6 названы важными пунктами развития интернет-ресурсов Вьетнама. Валидные авторизации происхождения Ehost снижают один класс рисков — ошибку происхождения маршрута или перехват.

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

Видимая связность скромнее. BGP.tools указывает одного вышестоящего оператора — AS135905, описанный как Vietnam P&T. Независимый отчёт CIDR тоже видит единственное вышестоящее соединение и отсутствие нижестоящего адресного пространства. IPinfo также указывает одного вышестоящего оператора и одного пира — в обоих случаях AS135905. Обозначения связей различаются по источникам, но устойчивое наблюдение одно: в рассмотренных представлениях маршруты AS135920 несёт одна видимая соседняя сеть.

Это не следует читать как утверждение, что у каждой стойки Ehost один физический кабель или что каждый продукт подключён к одному оператору. Ehost рекламирует колокацию в дата-центрах нескольких брендов и может использовать адреса, выделенные провайдером, частные соединения, сервисы второго уровня (L2), удалённую DDoS-фильтрацию или маршруты, невидимые как отдельные соседства AS. Публичные коллекторы BGP также могут пропускать частные или избирательные отношения.

Тем не менее это создаёт закупочный тест. Если услуга продаётся как мультиоператорская или мультидатацентровая, Ehost должна показать, как клиентский трафик переживает потерю AS135905, задействованного граничного маршрутизатора, обслуживающей площадки и пути к платформе фильтрации. Доказательствами могут быть схема архитектуры, текущие BGP-сессии, политика маршрутизации, результаты looking glass, записи аварийных переключений и контролируемый тест. «Несколько дата-центров» — заявление о площадках; «разнообразие интернет-достижимости» — заявление о маршрутизации. Одно не даёт другого автоматически.

IPv6 — ещё один видимый пробел. Изученные источники маршрутизации показываютноль анонсируемых IPv6-префиксовдля AS135920. Это не доказывает, что Ehost нигде не предоставляет IPv6: клиент может получить IPv6 от площадки или вышестоящей ASN. Это означает, что покупатель не может вывести нативную поддержку двойного стека из собственной автономной системы Ehost. Вопросы по продуктам должны охватывать размер выделяемого IPv6-пространства, маршрутизацию, обратный DNS, межсетевой экран, управление DDoS, мониторинг и паритет с поддержкой IPv4. В 2026 году фраза «добавим позже» — это обязательство на весь жизненный цикл, а не технический ответ.

Каталог разных моделей ответственности

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

Вперсональном виртуальном хостингеEhost заявляет, что платформа предоставляет cPanel, SSL, SSD-хранилище, базовый слой AntiDDoS и еженедельные резервные копии. Клиент в основном управляет кодом сайта, контентом, учётными записями и обновлениями приложений, полагаясь на Ehost в части общего сервера, панели управления, сети и изоляции. Настранице бизнес-хостингадобавлены выделенный публичный IP, кеш Redis и заявлено разделение ресурсов. Это общий сервис с большим контролем, но не эквивалент виртуальному серверу.

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

Выделенные серверы передают покупателю исключительность оборудования, но не обязательно право собственности на него. Настранице выделенных серверов 2026 годауказаны помесячные конфигурации от 5,5 до 12 млн донгов: процессоры Intel Xeon, память 128 или 256 ГБ, SSD- или NVMe-хранилище, IP-адрес и полоса 100–200 Мбит/с. Покупатель избавляется от шумных соседей и конкуренции за вычисления, но остаётся зависимым от Ehost в части машины, стойки, электропитания, операторского канала, remote hands и процесса замены.

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

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

На страницеeStorage«vStorage» описан как технология объектного хранилища, разработанная Ehost для медиа, документов, логов и статического контента; утверждается, что данные хранятся постоянно и всегда резервируются. Страница не публикует спецификацию API, модель консистентности, цель долговечности, схему стирания или репликации, поведение при удалении, карту регионов, цены на вывод данных или уровень обслуживания. «Объектное хранилище» называет класс услуги, а не архитектуру, достаточную для решения о долговременном хранении данных.

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

OpenStack — это список компонентов, а не гарантия доступности

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

Для покупателя первый вопрос — какую версию OpenStack и какой набор сервисов эксплуатирует Ehost. От ответа зависят статус поддержки, обновления, драйверы, исправления безопасности и поведение API. Публичная страница продукта не называет ни версию, ни гипервизор, ни бэкенд хранилища, ни схему сети, ни зоны доступности, ни политику живой миграции, ни API, доступный клиенту.

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

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

  • Если отказывает вычислительный узел, перезапускается ли виртуальная машина автоматически и сколько занимают обнаружение и перезапуск?
  • Если отказывает общее хранилище, реплицируются ли тома по независимым доменам отказов или защищены только RAID внутри одной системы?
  • Если отказывает контроллер или очередь сообщений, продолжают ли существующие машины работать, пока операции управления приостановлены?
  • Если отказывает коммутатор top-of-rack или ядерный коммутатор, есть ли физически независимый путь?
  • Если отказывает площадка, можно ли восстановить клиента на другой площадке из независимой копии?
  • Если сбой происходит при самом обновлении OpenStack, каковы процесс отката и уведомления клиентов?

Эти вопросы важны, потому что публичное заявление о доступности 99,5 % относительно мягкое. При непрерывном применении доступность 99,5 % допускает примерно 3 часа 36 минут простоя за 30-дневный месяц, или около 43 часов 48 минут в год. Этот расчёт не является заявлением о фактической работе Ehost. Он показывает, почему период измерения, исключения, учёт обслуживания, источник мониторинга и компенсации важны не меньше процента.

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

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

Путь клиента проходит через три контура управления

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

Коммерческий путь начинается наосновном сайте Ehost, где страницы продуктов представляют пакеты и помесячные цены. Ehost заявляет, что после регистрации отправляет подтверждение и уведомление о стоимости, а услуга создаётся после оплаты. Затем клиент попадает вsecure.ehost.vn— биллинговую и сервисную систему с категориями продуктов, вариантами отображения в VND и USD, учётной записью, формами заказов, тикетами, объявлениями, загрузками и ссылкой на статус серверов.

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

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

Миграция — не одна задача. На основном сайте Ehost обещаны бесплатные консультации и помощь в переносе данных для клиентов, использующих его услуги. Но производственная миграция всё равно требует инвентаризации исходных данных, копирования данных, стратегии DNS, управления сертификатами, теста почтовых потоков, окна заморозки приложения, проверки целостности и отката. Если меняются IP-адреса, могут потребоваться обновления списков разрешений, платёжных провайдеров, API третьих сторон и правил безопасности. Если меняется почта, репутация отправителя и DNS-записи вроде SPF, DKIM и DMARC становятся частью приёмки.

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

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

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

Цена прозрачна только после стабилизации спецификации

Ehost публикует больше цен, чем многие инфраструктурные провайдеры. Это полезно. Небольшой бизнес может увидеть, что виртуальный хостинг начинается от 50 000 донгов в месяц, бизнес-хостинг — от 300 000, облако — от 250 000, резервное копирование — от 95 000, выделенные серверы — от 5,5 млн, а колокация на публичной странице — от 1,8 млн. Дополнительные опции имеют видимые цены: дополнительные CPU, память, диск и IPv4 для облака; дополнительное хранилище, домен или IP для хостинга; расширение места в стойке, мощности и сети.

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

Но опубликованная цена — не то же самое, что надёжная цена. Вкатегории заказов бизнес-хостингаесть поразительная аномалия: «Business-02» показан за 1,35 млрд донгов за три месяца, тогда как соседние пакеты стоят сотни тысяч. На той же странице указаны устаревшие версии PHP и MariaDB. Было бы неразумно считать миллиардную цифру намеренным тарифом Ehost без подтверждения; её лучше понимать как свидетельство того, что витрина может содержать ошибки ввода данных или несоответствия жизненного цикла.

Колокация показывает более широкую проблему сверки. Напубличной странице колокациипакеты 1U указаны в VNPT Data, Viettel IDC и CMC за 3,2 млн, 2,8 млн и 1,8 млн донгов в месяц, обычно с внутренней сетью 200 Мбит/с и разделяемым международным каналом 30 Мбит/с. Вкатегории колокации биллингового порталаперечислены ODS, Viettel IDC и VNPT Tân Thuận за 1,3 или 1,4 млн донгов, с портами 100 Мбит/с и международным каналом 4 или 10 Мбит/с. Локации, мощности и цены не эквивалентны.

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

Полная стоимость должна включать как минимум:

  • первичную миграцию, настройку ОС и проверку приложения;
  • НДС и все прочие применимые налоги;
  • минимальный срок обязательств и условия продления;
  • публичные IPv4, полосу пропускания, международный трафик и опции DDoS;
  • лицензии панели управления, Windows, баз данных или другого ПО;
  • объём резервного копирования, срок хранения и плату за восстановление;
  • управляемую поддержку или remote hands;
  • простои при замене оборудования или модернизации;
  • доменные, сертификатные и почтовые зависимости;
  • содействие при выгрузке, переносе и переходе при завершении сотрудничества.

«Безлимитная полоса пропускания» тоже требует определения. Несколько страниц Ehost используют этот термин, отдельно публикуя скорости портов или международную полосу. «Безлимит» может разумно означать отсутствие платы за объём трафика, а не бесконечную пропускную способность или выделенный канал без конкуренции за ресурс. В договоре нужно различать скорость порта, гарантированную информационную скорость (CIR), поведение при пиках, политику добросовестного использования и внутренние и международные маршруты.

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

Резервное копирование — обещание с двумя сроками хранения

Именно в резервном копировании публичные материалы Ehost наиболее полезны и наиболее противоречивы. Облачная страница сначала говорит, что всё облако копируется ежедневно, а копии хранятся не менее семи дней. В примечаниях к тарифам сказано, что «ежедневное полное копирование» хранит последние четырнадцать дней, а восстановление стоит 500 000 донгов. Оба утверждения находятся на одной странице.

Виртуальный хостинг следует другой политике. На персональной и бизнес-страницах сказано, что данные хранятся в трёх копиях в реальном времени и копируются еженедельно, с хранением копий два месяца. Отдельная услугаCloud Backupпродаёт от 10 до 100 ГБ хранилища и заявляет, что может скопировать весь диск, чтобы перенести ОС и приложения на заменяющее оборудование. Рекламируется техническая поддержка 24/7/365 и помесячный биллинг.

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

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

Покупателю стоит превратить «резервное копирование включено» в план:

  1. Объём:загрузочный том, подключённые тома, базы данных, объектное хранилище, конфигурация панели управления, почтовые ящики и ключи, управляемые клиентом.
  2. Точка восстановления:максимальный объём данных, который может быть потерян по каждой услуге.
  3. Время восстановления:когда Ehost начинает работу и когда рабочая нагрузка должна снова стать доступной.
  4. Срок хранения:точное число восстанавливаемых копий и как считается их возраст.
  5. Изоляция:переживут ли копии компрометацию рабочей учётной записи, кластера или площадки.
  6. Способ восстановления:полное восстановление машины, на уровне файлов, на уровне базы данных и восстановление на альтернативную площадку.
  7. Плата:включённые восстановления, плата за срочность и стоимость вывода данных.
  8. Подтверждение:регулярные тесты восстановления для клиента с фиксацией результатов.

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

Ответ за пять минут — это не восстановление за пять минут

Поверхность поддержки Ehost видна. На основном сайте указаны телефон и электронная почта; на портале поддержки есть тикеты, база знаний, объявления, загрузки и статус серверов. Настранице гарантийного обслуживаниясказано, что поддержка работает 24/7 и что клиентов уведомят по электронной почте, телефону или напрямую, когда обслуживание потребует времени. Страницы выделенных и игровых серверов обещают ответ за пять минут через тикет, электронную почту, горячую линию или онлайн-чат.

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

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

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

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

Уведомление об обслуживании тоже следует сделать измеримым. За сколько сообщают о плановых работах? Какие аварийные действия исключены из уведомлений? Исключается ли обслуживание из расчёта доступности? Может ли клиент перенести работы? Переносит ли Ehost виртуальные машины или выключает их? Что происходит с неуправляемой ОС, которая не перезагружается штатно?

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

Безопасность — это несколько продуктов, а не единый щит

В риторике безопасности Ehost упоминаются физические межсетевые экраны, изоляция виртуального хостинга, базовая AntiDDoS, платная DDoS-фильтрация, SSL-сертификаты, резервные копии и поддержка. Эти меры отвечают разным угрозам, и их не следует смешивать в общее заявление, что рабочая нагрузка «защищена».

На облачной странице сказано, что у каждого кластера есть физический межсетевой экран, а виртуальные машины можно интегрировать с Antiddos.vn. На странице бизнес-хостинга сказано, что базовая AntiDDoS может автоматически включать защиту межсетевого экрана от небольших ботнетов. СайтAntiDDoSописывает несколько прокси- и межсетевых узлов, распределённых по вьетнамским дата-центрам, фильтрующих вредоносные запросы и предоставляющих функции HTTP/2 и межсетевого экрана веб-приложений. Вкатегории заказов AntiDDoSEhost публикует названия тарифов и некоторые параметры объёма запросов.

Это коммерческие заявления о схеме услуги, а не независимое подтверждение возможностей фильтрации. При закупке нужно спросить: защита постоянна или включается после обнаружения; покрывает ли она флуд уровня 3/4, запросы уровня 7 или оба типа; куда перенаправляется трафик; какая полоса для очистки гарантирована; сохраняются ли исходные IP-адреса; как обрабатываются ключи TLS; что происходит с не-веб-протоколами; влекут ли атаки дополнительные платежи; остаётся ли исходный сервер напрямую доступным.

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

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

Неясен и путь сообщения об abuse. Данные, происходящие из APNIC, указывают контакт VNNIC для реагирования на инциденты, а не явно заявленный abuse-отдел Ehost; на основном сайте указаны бизнес- и сервисные контакты, а не выделенная политика abuse. Это не доказывает отсутствия внутренних процессов у Ehost. Это значит, что внешнему заявителю или клиенту трудно проверить, куда сообщать о вредоносном ПО, спаме, фишинге, нарушении авторских прав или сетевых злоупотреблениях. Хостинг-провайдер должен уметь показать подтверждение получения, проверку, сохранение доказательств, уведомление клиента, стандарты приостановки и апелляцию.

В официальной правовой базе ВьетнамаЗакон о защите персональных данных 91/2025/QH15указан как действующий с 1 января 2026 года. Применение этого закона зависит от фактов и должно оцениваться квалифицированным юристом. Для покупателей Ehost практическое требование простое: договор должен определять роли в обработке данных, поддержку доступа, местонахождение данных, субпроцессоров, взаимодействие при инцидентах, хранение, удаление и выгрузку для фактической услуги.

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

Предупреждение о жизненном цикле на витрине

В публичном каталоге есть признаки того, что информация о продуктах устарела неравномерно. Страницы виртуального хостинга описывают поддержку PHP версий 5.4–7.1 и MariaDB 10.1. Биллинговый портал отдельно перечисляет MultiPHP 5.5, 5.6 и 7.0 для некоторых пакетов и PHP 7.0 с MariaDB 10.1 для одного высокопроизводительного предложения.

Эти версии не актуальны. Таблица снятых с поддержки веток PHP фиксирует окончание поддержки PHP 5.4 в сентябре 2015 года, PHP 7.0 — в январе 2019 года, PHP 7.1 — в декабре 2019 года. Таблица сопровождения версий Фонда MariaDB относит окончание сопровождения MariaDB 10.1 к октябрю 2020 года.

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

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

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

Упоминание процессоров Intel Broadwell на облачной странице — ещё одна примета возраста, тогда как страница выделенных серверов рекламирует более новые конфигурации Xeon Gold и Platinum, а категория C6 в биллинге заявляет значительно более высокие IOPS. Похоже на несколько поколений инфраструктуры, а не однородный парк. Для давно работающего хостера это нормально, но важна политика размещения. Покупатель должен знать, привязан ли тариф к определённому поколению CPU и классу хранилища или к любому пулу со свободной ёмкостью.

Управление жизненным циклом должно охватывать не только версии. Оно должно определять уведомления о переносе серверов, смене панели управления, выводе образов ОС, окончании жизненного цикла оборудования, перенумерации IP, смене издателя сертификатов и снятии тарифов. На портале поддержки есть даже категория «EOL», хотя её содержимое в зафиксированных материалах недоступно. Опубликованная политика жизненного цикла позволяла бы клиентам планировать, а не узнавать о выводе продукта через продление или инцидент.

Конкуренция проверяет Ehost доказательствами, а не масштабом

Ehost конкурирует сразу на нескольких рынках. В виртуальном хостинге — с местными хостинг-компаниями и сайтовыми платформами. В виртуальных машинах — с облаками вьетнамских операторов связи, специализированными VPS-провайдерами и глобальными гиперскейлерами. В выделенных серверах и колокации — с операторами дата-центров, системными интеграторами и прямыми договорами с площадками. Для резервного копирования, CDN и DDoS клиент может купить специализированную услугу отдельно.

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

Проблема в том, что более крупные местные альтернативы публикуют иной уровень гарантий.VNPT Cloudрекламирует SLA 99,99 %, поддержку IPv6, более широкий каталог управляемых сервисов и поименованные сертификаты безопасности. Это заявления самой VNPT, а не независимое доказательство, что любая нагрузка будет работать лучше. Они иллюстрируют сравнение при закупке, которое Ehost должна выдерживать: какой уровень сервиса, возможности двойного стека, подтверждения соответствия, архитектуру и объём управления получает покупатель за свою цену?

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

Поэтому корректный конкурентный тест привязан к конкретной нагрузке:

  • Для сайта-визитки виртуальный хостинг может быть дешевле и проще облака.
  • Для вьетнамского приложения, которому нужна предсказуемая местная поддержка, облако или выделенное оборудование Ehost могут быть привлекательны, если спецификация услуги проверена.
  • Для регулируемой нагрузки объём гарантий, порядок работы с инцидентами и условия работы с данными могут перевесить заголовочную цену.
  • Для глобально распределённого приложения важнее IPv6, международные каналы, автоскейлинг и мультирегиональная архитектура, чем местная поддержка.
  • Для игры, чувствительной к задержкам, решают тактовая частота CPU, реакция на DDoS, внутренний пиринг и потери пакетов при атаке, а не общий бренд «облако».

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

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

Затраты на переход накапливаются по одной зависимости за раз

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

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

Второй уровень —хранилище и резервные копии. Образ диска может не включать снимки, метаданные объектов, историю резервных копий или детали шифрования на стороне провайдера. Страница eStorage не публикует API экспорта или порядок вывода данных. Восстановление, работающее только внутри Ehost, — это защита непрерывности, а не переносимость.

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

Четвёртый уровень —сетевая защита. Если домен проходит через DDoS-прокси или CDN, привязанные к Ehost, выход требует смены DNS, перенастройки сертификатов и исходного сервера, выгрузки логов и аккуратного вывода старого пути. Миграция во время атаки особенно сложна, потому что в переходный период исходный сервер может быть раскрыт.

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

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

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

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

Закупочный тест под реальный публичный след Ehost

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

1. Сверить коммерческие данные

Попросить Ehost назвать авторитетный каталог продуктов и объяснить различия между публичной страницей Cloud Server, магазином SSD Cloud Server и магазином C6. Потребовать подписанную спецификацию конфигурации. То же сделать для публичных и биллинговых пакетов колокации. Подтвердить налоги, сроки обязательств, продление, возврат, восстановление и плату за апгрейд.

2. Проверить предоставленную машину

Во время испытаний зафиксировать модель CPU и показатель stolen time, доступную память, полезный диск, устойчивые и пиковые IOPS, задержки под нагрузкой, пропускную способность интерфейса и скорости по внутренним и международным каналам. Проводить тесты в разное время, а не считать единичный бенчмарк гарантией. Сравнить результат с заказом.

3. Составить карту доменов отказа OpenStack

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

4. Тестировать маршрут, а не список дата-центров

Подтвердить, какие ASN и префиксы использует продукт, взяты ли адреса из пространства Ehost или площадки и доступен ли IPv6. Спросить, как AS135920 переживает потерю AS135905 и как меняются маршруты при включении AntiDDoS. Тестировать из крупных вьетнамских сетей доступа и из международных точек. Фиксировать потери пакетов и изменения маршрута во время обслуживания или имитации аварийного переключения.

5. Превратить резервное копирование в учения по восстановлению

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

6. Определить поддержку по уровням критичности

Открыть тикеты через каждый обещанный канал. Подтвердить, что 24/7 означает квалифицированного специалиста, а не только приём заявок. Зафиксировать в договоре отдельные цели по подтверждению и восстановлению, контакты эскалации, уведомления об обслуживании и предоставление отчётов о первопричине. Получить исторические показатели по покупаемому продукту и площадке.

7. Проверить меры безопасности и работу с abuse

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

8. Проверить жизненный цикл и переносимость

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

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

Неотвеченные вопросы — часть продукта

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

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

Он не устанавливает, что объекты уровня Tier 3, названные в маркетинге Ehost, сертифицированы именно для тех стоек и услуг, которые продаются, или что Ehost владеет этими объектами. Он не устанавливает физическое или операторское разнообразие по списку площадок. Он не устанавливает, что каждый адрес под RPKI получает DDoS-защиту.

Он не устанавливает полное соглашение об уровне обслуживания. У публичных 99,5 % нет видимой методики измерения и компенсационных условий, а формулировка об «абсолютной доступности» на странице выделенных серверов — не убедительная замена ограниченным условиям. Полного порядка возврата средств в доступе не было.

Он не устанавливает актуальных версий рабочего окружения. Старые упоминания PHP и MariaDB могут быть устаревшим текстом или живой совместимостью; различить их может только инвентаризация платформы. Он не устанавливает версию или топологию OpenStack.

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

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

За чем следить дальше

Пять сигналов существенно повысили бы уверенность в контуре управления Ehost.

Первый —согласованность каталога. Публичные страницы продуктов и биллинговый портал должны описывать одинаковые пакеты или явно помечать поколения и даты. Удаление неправдоподобных цен и неподдерживаемых версий ПО сделало бы витрину надёжной частью сервиса.

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

Третий —операционная прозрачность. Рабочая страница статуса с временными метками инцидентов, затронутыми продуктами, обновлениями и разрешением превратила бы существующую ссылку статуса в доказательство. Периодическая публикация метрик доступности и восстановления сделала бы заявления о доступности и резервном копировании проверяемыми.

Четвёртый —завершение политик. На сайте Ehost есть ссылки на страницы конфиденциальности, условий, оплаты и гарантии, а портал поддержки предлагает загрузку политики услуг EHOST. Публикация актуальных и доступных условий по возврату средств, допустимому использованию, abuse, работе с данными, поддержке, SLA, резервному копированию, расторжению и удалению снизила бы издержки переговоров для обеих сторон.

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

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

Именно поэтому важны два описания Cloud 1G за 250 000 донгов. Они вскрывают ту самую точку, где отношения с хостинг-провайдером становятся либо управляемыми, либо неопределёнными. Если Ehost и покупатель смогут согласовать спецификацию, подтвердить маршрут и путь восстановления, распределить ответственность за сбои и сохранить выход, местная широта предложения компании станет преимуществом. Если эти вопросы останутся в противоречивых веб-страницах, самый дешёвый сервер ещё не получил надёжную цену.