CloudTeknoloji Cloud Teknoloji Bilisim Hizmetleri ve Ticaret A.S. продаёт арендованные мощности, которые по-прежнему зависят от стоек, транзита и окон ремонта

Кратко

• CloudTeknoloji — компания, стоящая за брендом daha.net. На публичнойстранице с коммерческой информациейюридическим лицом указана CLOUD TEKNOLOJI BILISIM HIZMETLERI TICARET A.S., брендом — daha.net; там же приведены стамбульский адрес, телефон, номер MERSIS и номер торгового реестра, а также описание услуг: хостинг, облачные серверы, домены, SSL, электронная почта и сопутствующие ИТ-услуги.
• Заявление об инфраструктуре конкретно, но не полностью независимо. Настранице «О нас»сказано, что системы daha.net управляются из стамбульского района 4. Levent и размещены в стамбульском дата-центре ICS Дата-центр; упоминаются Tier III, PCI/DSS, резервируемый доступ в интернет, операторно-независимое волокно, ИБП, электропитание A+B, физическая защита и охлаждение. Читателям стоит воспринимать это как заявления самой компании, если они не подтверждены договорами с клиентами или сертификатами объекта.
• Публичный след маршрутизации актуален и узок.Обзор AS в RIPEstatпоказывает, что AS202048 анонсируется для CloudTeknoloji, аданные об анонсируемых префиксах— один видимый префикс 46.28.232.0/24 в окне с конца июня по 12 июля 2026 года.Счётчики префиксов RISпоказывают один исходный IPv4-префикс, ни одного транзитного префикса и ни одного исходного IPv6-префикса.
• Главный вопрос клиента не в том, существует ли daha.net, а в том, насколько сайт, VPS, почта, DNS, резервное копирование и план миграции клиента привязаны к одному стамбульскому объекту, небольшому маршрутизируемому адресному блоку, наблюдаемому сейчас восходящему пути через ICS, окнам ответа поддержки и условиям договора, которые возлагают часть ответственности за резервные копии и потерю данных на клиента.

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

Публичная идентичность CloudTeknoloji для небольшого хостинг-оператора необычно хорошо проработана. Настранице daha.net с коммерческой информациейюридическим названием указано CLOUD TEKNOLOJI BILISIM HIZMETLERI TICARET A.S., сказано, что daha.net — это бренд, налоговой инспекцией указан Маслак, налоговый номер 5470543764, номер MERSIS 0547054376400001 и номер торгового реестра 759033, а также что компания основана в 2010 году. На той же странице указан адрес: Sultan Selim Mahallesi, NEF 09 Plaza 4. Levent B Blok No:7/121, Kagithane, Istanbul, а также телефон, факс, электронная почта и реквизиты KEP.

Это важно, потому что речь не о домене, продающем анонимный хостинг. Покупатель может связать бренд, компанию, адрес, идентичность в реестре и публичную сетевую идентичность.Запись организации ORG-SBHv1-RIPE в RIPEуказывает Cloud Teknoloji Bilisim Hizmetleri ve Ticaret A.S. в Турции, показывает тот же номер торгового реестра, определяет тип организации как LIR и приводит адрес и телефон в Кагытхане, Стамбул.Запись aut-num для AS202048 в RIPEназывает AS CloudTeknoloji, описывает её как Cloud Teknoloji Bilisim Hizmetleri ve Ticaret A.S. и связывает с той же организацией в RIPE.

История бренда дополняет клиентское предложение. Настранице «О нас»сказано, что daha.net работает с 2010 года и обслуживает частных и корпоративных клиентов хостингом и серверными услугами. Бренд представлен как часть Cloud Teknoloji Bilisim Hizmetleri Ticaret Anonim Sirketi; описан набор услуг: хостинг, облачный сервер, реселлерский хостинг, домены, SSL и корпоративная почта. Настранице контактовуказаны публичные телефоны, факс, адреса поддержки, адрес и реквизиты KEP, так что у покупателей есть видимый канал для продаж, поддержки и официальных уведомлений.

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

Маршрутизируемый след реален, актуален и мал

Публичная сетевая картина проста.Обзор AS202048 в RIPEstatпоказал владельца CloudTeknoloji Cloud Teknoloji Bilisim Hizmetleri ve Ticaret A.S. и отметил AS как анонсируемую на 12 июля 2026 года.Данные об анонсируемых префиксахпоказали один видимый префикс 46.28.232.0/24 с 28 июня по 12 июля 2026 года.Счётчики префиксов RISна момент запроса 12 июля показали один исходный IPv4-префикс, ноль транзитных IPv4-префиксов, ноль исходных IPv6-префиксов и ноль транзитных IPv6-префиксов.

Этого достаточно, чтобы показать живую публичную работу.Обзор префикса 46.28.232.0/24 в RIPEstatотмечает, что /24 анонсируется через AS202048.Данные о статусе маршрутизациипоказали, что 325 из 326 пиров с полной IPv4-лентой видели маршрут в момент выборки; виден один IPv4-префикс и 256 адресов анонсируемого IPv4-пространства, а видимое IPv6-пространство — ноль, и наблюдался один сосед.Проверка RPKIвернула действительный ROA для AS202048 и 46.28.232.0/24 с максимальной длиной 24.

Те же доказательства ограничивают заявление. Один /24 — это небольшой публичный адресный след. На нём могут находиться авторитативные DNS-серверы, узлы хостинга, почтовые реле, точки управления, клиентские VPS или системы мониторинга, но это не свидетельство широкого регионального облачного региона. Отсутствие видимого IPv6-исхода особенно заметно для современного продавца облаков и хостинга. Видимость только IPv4 не делает услуги бесполезными, но означает, что клиентам, которым нужны публичные сервисы с двойным стеком, стоит явно спросить о наличии IPv6, а не предполагать его.

Кроме того, в публичном PeeringDB нет сетевой записи для этого ASN:запрос PeeringDB для ASN 202048возвращает пустой набор данных. Отсутствие в PeeringDB не доказывает слабую инженерию. Многие небольшие провайдеры полагаются на восходящий транзит и не ведут публичные профили на биржах трафика. Тем не менее это убирает одно из распространённых независимых мест, где операторы публикуют присутствие на объектах, объёмы трафика, политику пиринга, контакты NOC и подключения к биржам. Для CloudTeknoloji видимые публичные данные говорят: «реальная маршрутизируемая AS, один текущий IPv4 /24, действительная авторизация маршрута, без видимого IPv6-исхода, без публичного пирингового профиля».

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

Граница стоек — Стамбул, а не облако без места

Язык, которым сама компания описывает свои объекты, достаточно точен, чтобы сформировать разговор о рисках. Настранице «О нас»сказано, что системы управляются из операционного центра в стамбульском районе 4. Levent и размещены в расположенном в Стамбуле дата-центре ICS Дата-центр, который описан как сертифицированный по PCI/DSS и соответствующий стандарту Tier III. Там же заявлены более 100 Гбит/с резервируемого доступа в интернет, операторно-независимое волокно, полностью резервируемые ИБП и системы энергоснабжения, двухвводное электропитание A+B, физическая защита и охлаждение. Вполитике обслуживаниязаявление о местоположении повторяется проще: серверы daha.net размещены в стамбульском дата-центре ICS Дата-центр уровня Tier III.

Это превращает маркетинговое слово «облако» в конкретное место. Услуга клиента зависит от стоек в Стамбуле, оператора объекта, распределения электропитания, охлаждения, кабельных соединений, кросс-коннектов, портов коммутаторов, транзитных сессий, хранилищ, инвентаря оборудования и людей, способных выполнять ремонт. Чем-то из этого CloudTeknoloji может управлять напрямую. Что-то находится у ICS Дата-центр или вышестоящих операторов связи.

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

Это различие важно для локализации данных. Предложение CloudTeknoloji привлекательно для турецких клиентов отчасти потому, что вычислительные мощности и серверы, судя по всему, остаются в Турции.Страница VDSрекламирует размещение в Стамбуле, виртуализацию VMware ESXi и пакеты VDS на SSD.Страница Pro Cloudснова рекламирует размещение в Стамбуле, процессоры Xeon Gold 6138, управляемую поддержку и хранилище NVMe SSD.Страница хостингарекламирует хостинг в Стамбуле, Linux LiteSpeed, Windows IIS, бесплатный SSL и еженедельные резервные копии.Данные геолокации RIPEstat для 46.28.232.0/24также помещают публичный префикс в Турцию на момент проверки.

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

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

Каталог услуг продаёт слои, а не только серверы

Ассортимент daha.net шире, чем у узкого магазина VPS. Настранице с коммерческой информациейсказано, что компания работает в сферах веб-хостинга, облачных серверов, регистрации доменов, SSL-сертификатов, электронной почты и сопутствующих ИТ-услуг. Навигация и страницы продуктов показывают ту же широту:стандартные облачные серверы VDS,управляемые серверы Pro Cloud,веб-хостинг, хостинг WordPress, реселлерский хостинг, корпоративный хостинг, доменные услуги, SSL-сертификаты, лицензии панелей управления, Microsoft 365, массовые почтовые рассылки и услуги по обслуживанию серверов.

Такая широта коммерчески полезна. Небольшой бизнес может купить домен, хостинг, почту, сертификат, VPS и поддержку у одного провайдера. Агентство может держать домены и сайты клиентов под одним аккаунтом. Турецкий интернет-магазин может выбрать инфраструктуру в Стамбуле и поддержку на турецком языке вместо освоения консоли гиперскейлера. Клиент, переросший общий хостинг, может перейти на VDS или управляемый Pro Cloud, не меняя бренд.

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

Публичные страницы CloudTeknoloji неплохо называют некоторые технические составляющие. Страница VDS рекламирует VMware ESXi, SSD-хранилище, полный root-доступ, процессоры Intel Xeon E5-2695 V4 и пакеты от небольших двухъядерных машин до уровней с шестью ядрами, 8 ГБ ОЗУ и 80 ГБ SSD. Страница Pro Cloud рекламирует Xeon Gold 6138, NVMe SSD, выделенные ресурсы, управляемый сервис, обновления безопасности, оптимизацию и техническое сопровождение. Страница хостинга рекламирует Linux LiteSpeed, Windows IIS, NVMe SSD, cPanel или Plesk и еженедельные резервные копии. Это не пустые слова.

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

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

Эти вопросы определяют, комфортен ли проданный тариф только в обычные дни или выдерживает дни ремонта.

Маршрут сейчас, судя по всему, зависит от стороны ICS на объекте

Публичный путь маршрутизации указывает на границу между объектом и оператором.Запись aut-num для AS202048 в базе RIPEсодержит строки политики импорта и экспорта для AS48678, AS42910 и AS214588. Однакоданные RIPEstat о согласованности маршрутизации ASпоказывают разницу между записанной политикой и наблюдаемой маршрутизацией: AS214588 есть в BGP и в данных политики, а AS48678 и AS42910 присутствуют в данных политики, но не наблюдались в BGP на момент выборки.Данные о соседях ASN в RIPEstatтакже сообщили об одном уникальном соседе слева, AS214588, за последнее доступное время.

AS214588 — не случайный посторонний хоп.Запись AS214588 в RIPEназывает еёicsteknoloji, аобзор AS214588 в RIPEstatуказывает владельца ICS Bilisim Teknolojileri Danismanlik Hizmetleri A.S. В данных политики AS214588 показаны восходящие отношения с Turkcell/Superonline, Turk Telekom и Vodafone.Пример BGP-состояния для 46.28.232.0/24также показывает в выбранных маршрутах глобальные пути, достигающие AS202048 через AS214588.

Это не доказывает, что у CloudTeknoloji нет частного резервного канала, тёмного волокна и внешнего канала восстановления. Публичные коллекторы BGP показывают только то, что глобально видно в конкретный момент. Но для клиента, покупающего арендованные мощности, текущий публичный путь всё равно значим. Если публичный интернет-сервис AS202048 сейчас достигается через AS214588, то координация объекта и вышестоящего оператора со стороной ICS входит в операционную поверхность CloudTeknoloji.

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

Практический вопрос — разнообразие транзита. На странице самой компании CloudTeknoloji заявлены операторно-независимое волокно и резервируемый доступ в интернет более 100 Гбит/с для своей инфраструктуры. Это сильное заявление, но публичный вид AS показывает одного наблюдаемого соседа на границе CloudTeknoloji. Эти два утверждения могут сосуществовать, если у базового объекта несколько операторов связи, а собственная AS CloudTeknoloji сейчас использует сеть ICS как публичную транзитную точку сдачи.

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

Для критически важных сервисов ответ должен быть договорным и техническим. Клиентам нужно знать, остаются ли их публичные IP-адреса достижимыми через второго вышестоящего оператора, если AS214588 выйдет из строя; есть ли автоматическое переключение маршрута; зависит ли фильтрация DDoS от того же пути; и остаются ли DNS, панели управления и порталы поддержки доступными при отзыве основного маршрута AS202048. Без таких ответов публичные данные поддерживают осторожный вывод: текущий маршрут реален, аккуратно авторизован и виден, но внешне сконцентрирован.

Арендованные мощности продаются как мгновенные, но ремонт мгновенным не бывает

Страница VDS подчёркивает быстрое развёртывание и лёгкое увеличение ресурсов. Там сказано, что облачные серверы используют виртуализацию VMware ESXi, SSD-хранилище, полный root-доступ и изолированные ресурсы, а увеличение ресурсов рекламируется через панель клиента. Страница Pro Cloud идёт дальше: управляемый сервис, выделенные ресурсы, процессоры Xeon Gold и NVMe SSD для более тяжёлых сайтов, SaaS, агентств, электронной коммерции и проектов с высоким трафиком. Это обещание клиенту: получить сервер, не владея сервером.

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

Политика обслуживанияполезна тем, что признаёт часть этой трения. В ней сказано, что аккаунты, оплаченные картой, могут активироваться в течение нескольких минут, но услуги помимо хостинга и регистрации доменов — включая облачные серверы, лицензии, SSL-сертификаты и массовые рассылки — вне рабочих часов могут устанавливаться или подключаться до восьми часов. Сказано, что заказы по банковскому переводу требуют уведомления об оплате и проверки. Сказано, что неоплаченные услуги хостинга и облачных серверов удаляются с серверов через 30 дней. Также сказано, что Cloud Servers используют общий пул 10 Мбит/с, если клиент не арендует линию с другим лимитом.

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

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

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

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

Обязательства по поддержке видны, но они не одинаковы

daha.net публикует несколько заявлений о поддержке, и читать их стоит вместе, а не выборочно.Политика обслуживанияперечисляет телефонную поддержку в будние дни с понедельника по пятницу с 09:00 до 17:30, бухгалтерскую поддержку в будние дни в том же окне и техническую поддержку по электронной почте — семь дней в неделю, 24 часа, с гарантией ответа за 60 минут. Далее в той же политике раздел поддержки клиентов говорит, что daha.net обязуется ответить в течение 60 минут в рабочее время и в течение восьми часов вне рабочего времени.Страница «О нас»истраница контактовтакже упоминают телефонную доступность в будни и круглосуточный доступ к электронной почте или тикетам поддержки.

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

История поддержки CloudTeknoloji сильнее, чем у бюджетного хостинга без контактов: публикуются телефоны, адреса поддержки, путь тикетов, юридический адрес, адрес KEP и письменные условия. Риск в том, что те же опубликованные условия показывают естественные ограничения: телефон доступен не круглосуточно, часть неосновных услуг может ждать вне рабочих часов, а срок ответа вне часов описан двумя способами.

Покупателю стоит спросить, какой пункт действует для его конкретного продукта, отличается ли эскалация у управляемого Pro Cloud от неуправляемого VDS, включает ли аварийное реагирование действия на уровне объекта и есть ли именованная система приоритетов с целевыми сроками устранения.

Кадры связаны и с миграцией. Страница VDS рекламирует бесплатную поддержку миграции, включая перенос сайтов и баз данных без потери данных и прерывания сервиса. Это ценно, если в конкретном случае правда, но объём стоит уточнить. Перенос сайта на cPanel — не то же самое, что перенос кастомного приложения, Windows-сервера, живой базы данных, почтового архива, DNS-зоны, настройки DNSSEC, белых списков файрвола, cron-задач и сторонних интеграций.

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

Окна обслуживания явные и достаточно большие, чтобы иметь значение

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

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

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

Важный вопрос — как обслуживание изолируется. Можно ли освободить один хост, пока нагрузка продолжает работать на других? Выполняется ли живая миграция VDS между хостами? Требует ли обслуживание хранилища простоя? Резервируются ли сетевые работы на уровне коммутаторов или транзита? Могут ли клиенты Pro Cloud купить более высокую доступность, чем обычный VDS? Проверяются ли восстановления из резервных копий после замены оборудования? Относится ли уведомление за неделю, три дня и день ко всем работам или только к ожидаемому простою? Политика даёт публичный образец оповещений, но клиенту нужны детали архитектуры.

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

Формулировки о резервных копиях полезны тем, что не слишком успокаивают

Язык резервного копирования на daha.net честнее, чем на многих хостинговых страницах, и его стоит читать внимательно. Страницы продуктов хостинга и VDS рекламируют еженедельное или периодическое резервное копирование.Политика обслуживаниядаёт более жёсткое правило: хостинговые серверы копируются еженедельно и ежемесячно, серверные услуги не копируются, если клиент не купил услугу резервного копирования, резервные копии могут быть повреждены или непригодны, клиентам не даётся никаких гарантий по этим копиям, а резервное копирование аккаунта — ответственность клиента. Там также сказано, что когда клиенту нужна резервная копия, снятая daha.net, компания может по своему усмотрению предоставить доступную копию в зависимости от системы резервного копирования.

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

Разница между «резервная копия существует» и «восстановление работает» — центральная для этой компании. CloudTeknoloji продаёт арендованные мощности, но ответственность за защиту данных может оставаться на клиенте. Сайт на WordPress можно копировать на уровне приложения во внешнее хранилище. VPS можно снимать в снапшоты в отдельный регион. База данных может передавать реплики или дампы второму провайдеру. DNS можно размещать у отдельного оператора. Клиент может снизить риск, сделав CloudTeknoloji основным хостингом, но не единственным местом, где существуют данные.

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

Биллинг, отмена и удаление данных — тоже часть аптайма

Материалы об инфраструктуре часто фокусируются на маршрутах и стойках, но условия CloudTeknoloji показывают, что коммерческое состояние бывает не менее важным.Политика обслуживанияговорит, что заказы, не оплаченные в течение семи дней, автоматически отменяются. Хостинг и облачные серверы, которые не продлены, полностью удаляются с серверов через месяц после окончания периода продления. Отмена услуги удаляет аккаунт вместе с резервными копиями. Также ограничивается право на возврат средств для некоторых дополнений, лицензий, доменов, SSL и других услуг, и говорится, что право на возврат средств за Cloud Server может исчезнуть, если техническая команда по просьбе клиента установит дополнения или ПО.

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

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

План ухода прост по сути. Где возможно, держите доступ к регистратору независимым. Храните экспорт DNS. Храните резервные копии вне платформы. Знайте, какие IP-адреса привязаны к белым спискам. Ведите актуальный список SSL-сертификатов и дат продления. Протестируйте восстановление сайта у другого провайдера. Если почта критична, обеспечьте её непрерывность вне одного веб-хостинг-аккаунта. Ничто из этого не означает отказа от CloudTeknoloji. Это значит использовать компанию как провайдера, а не как единственную копию бизнеса.

Суверенитет данных — реальный аргумент продаж, но с компромиссом по восстановлению

Для турецких клиентов локальный хостинг может быть ценным. Он может снизить задержки для внутренних пользователей, упростить поддержку на турецком языке и по налогам, оставить договоры в знакомой юрисдикции и поддержать предпочтения по локализации данных. Официальные страницы CloudTeknoloji используют этот локальный профиль: офисы в Стамбуле, объект в Стамбуле, поддержка на турецком языке, приём заказов только из Турции согласно политике, турецкое юридическое лицо, адрес KEP и набор услуг для локального хостинга, доменов и бизнес-почты.Геолокационный вид для 46.28.232.0/24тоже соотносит видимый публичный префикс с Турцией.

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

Они не публикуют полную мультисайтовую архитектуру восстановления.

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

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

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

Кого затрагивает отказ этой системы

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

Вторая группа — клиенты VDS и Pro Cloud. У них больше контроля, но и больше ответственности. У клиента неуправляемого VDS есть root-доступ, и он может выстроить собственный стек, но обновления операционной системы, безопасность приложений, резервное копирование базы данных и планирование восстановления могут лежать на клиенте. Клиент управляемого Pro Cloud может получить больше помощи, но стоит подтвердить, какие именно слои управляются, какая поддержка оказывается по принципу лучших усилий, а что остаётся за клиентом.

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

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

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

Что закрыло бы открытые вопросы

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

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

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

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

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

Итог

CloudTeknoloji Cloud Teknoloji Bilisim Hizmetleri ve Ticaret A.S. не заслуживает ни отмашки, ни слепого доверия. Компания, стоящая за daha.net, идентифицируема, работает под видимой турецкой коммерческой идентичностью, публикует контактную и юридическую информацию, продаёт широкий хостинговый каталог, заявляет о размещении в стамбульском объекте и несёт живую публичную AS. Публичный маршрут AS202048 анонсируется, виден коллекторам и покрыт действительной авторизацией RPKI для 46.28.232.0/24.

Осторожность в том, что публичный след узок. Один видимый IPv4 /24, отсутствие видимого IPv6-исхода, отсутствие публичного профиля в PeeringDB и один наблюдаемый сосед по AS не доказывают широкого резервирования. Официальные условия сервиса также напоминают, что у облачных серверов, резервных копий, обслуживания, часов поддержки, пропускной способности и состояния продления есть пределы.

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

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

Пока эти ответы не записаны и не проверены, публичные данные поддерживают инфраструктурный профиль средней уверенности: реальная работа, ограниченная глубина публичной сети и вопросы восстановления, которые важнее слова «облако».