Меня часто спрашивают:
— Почему к вам, а не к гигантам?

Ответ простой:
— Мы не охреневшие.

Сначала я хотел рассказать про нашу сеть хранения, которая быстрее, чем скорость записи на RAID 0, про удивительное конкурентное преимущество «Трезвая поддержка», про 400G‑линки на каждом хосте, про изоляцию сетей и топологию Dragonfly+ с full mesh на уровне зон доступности. Но всё‑таки я решил: самое главное, что мы не охреневшие.

Это главная штука, которую мы решили для себя со старта.

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

Вот примерно так одна из площадок выглядит


Площадки и зоны доступности
Основные площадки — это три наших локации в Москве в пределах МКАДа (часть вообще внутри Садового) с новым типом инфраструктуры — когда снаружи непонятно, что это ЦОД, и инфра не собирается в маленький плотный кубик в очевидном месте.

Плюс два московских дата‑центра: IXcellerate North (Север) и IXcellerate South (Юг). По мере готовности двух наших площадок мы мигрируем из IXcellerate в них. Сами точки присутствия мы тоже хитро организовали. Заводить 50 разных операторов в своё свежеоборудованное здание — неприкольно. Поэтому у нас понятный транзитный процесс, который мы скоро завершим: остаётся бордер для стыковки с внешними сетями и пара серваков для резерва внутренней инфры в одной точке, такой же бордер и пара серваков в другой.

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

Итого у нас получается 5 зон доступности (по 2 внутри IXcellerate/новых и одна на самой первой локации), будет 6. Зоны доступности — это полностью изолированные инфраструктуры: свои непересекающиеся сетевые железки, свои отдельные энерговводы, своё охлаждение, свои источники бесперебойного питания. Полностью. Выход из строя оборудования в одной зоне доступности никак не должен затронуть другую.

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

Также у нас была точка присутствия в дата‑центре 3data, из‑за которой нас называли перекупами, и, что очень важно, на М9 — главном телекоммуникационном узле в России. Здесь мы можем быстро сделать физический линк с кем угодно, организовать прямой коннект для клиентов, затащить любого оператора, которого нет в основных ЦОДах (хотя там есть практически все). Фактически это наш третий Meet‑Me Room.

Сейчас мы подключаемся к точке обмена трафиком MSK‑IX. Зачем? Это даёт невероятную гибкость: мы можем пириться с кем угодно, как угодно, очень быстро и легко. Можно дать трафик на пользователей любого провайдера напрямую, не поднимаясь на вышестоящих операторов. Это как ещё один Meet‑Me Room, но уже виртуальный.


Связь
Между ключевыми площадками (обоими IXcellerate, М9, 3Data и офисом) мы взяли тёмное волокно, которое нам любезно предоставил «Мастертел», и засветили его на 400 Гбит/с. Про новое — деталей не будет, простите, мы решили поменьше открывать варежку про такие вещи, но уровень тот же.

В будущем планируем расширять ёмкость с помощью DWDM.

Связь с Александровом пока реализована через 10-гигабитный интернет от Ростелекома и 10-гигабитный L2 VPN‑канал до М9. Суммарной пропускной способности в 20 Гбит/с для этой площадки более чем достаточно. Работаем над строительством оптических трасс, но это небыстрая история.

Для сравнения: пиковый трафик всего Cloud.ru, по словам их бывшего сетевого инженера, не превышал 40 Гбит/с. У нас восемь внешних аплинков по 100 Гбит/с.

В каждом из ключевых ЦОДов ядро сети вынесено в отдельный независимый по питанию и инфраструктуре модуль — Meet‑Me Room. У нас прямо трассы с кросс‑панелями: всё красиво разведено. В каждом MMR у нас по четыре линка от разных провайдеров (два основных, два резервных). Мы специально проверяли, чтобы их трассы физически не пересекались и не приходили в один и тот же маршрутизатор.

Суммарная ёмкость каналов — 800 Гбит/с. Это мегаоверкилл, но такой запас — это фундамент для нашего собственного сервиса анти‑DDoS. Мы сейчас внедряем его на базе коммерческой версии одного open‑source‑решения, и, скорее всего, на старте он будет встроенным и бесплатным для всех клиентов.

Вся эта сложная система из AZ, MMR и ЦОДов построена по топологии Dragonfly+. Если упрощать, то каждая AZ и каждый MMR — это независимая группа узлов. В группе серверов — классический Клоз (Node‑Leaf‑Spine). Между всеми группами — full mesh. Это даёт потрясающую отказоустойчивость.

Представим себе худший сценарий: в одном из ЦОДов IXcellerate полностью выходит из строя MMR. Это значит, что все четыре внешних аплинка в этом ЦОДе отваливаются. Что произойдёт? Ничего критичного. Во‑первых, каждая зона доступности в этом упавшем ЦОДе напрямую связана с зонами доступности в другом ЦОДе через те самые 400-гигабитные каналы. Трафик просто пойдёт через бордер второго ЦОДа. Система спроектирована так, чтобы пережить отказ любого компонента.

Железо
Одно‑ и двухюнитовые серверы HPE 11-го поколения. На борту у них:

• Процессоры Intel Xeon 5-го поколения.
• По 2 терабайта оперативной памяти DDR5.
• NVMe для операционной системы и как сверхбыстрые локальные диски для кластерных баз данных (когда у вас кластерная СУБД, ей не нужен сетевой диск, а локальный NVMe даёт сумасшедшую скорость) и SSD для объединения в storage‑сеть.
• Опционально — GPU. Сейчас это в основном NVIDIA, уже наладили закупку B300 для задач инференса и нашей будущей дата‑платформы. GPU мы продаём не поминутно, а с долгосрочным коммитом — минимум на год.

Следующая закупка — это либо HPE 12-го, либо Dell 17-го поколения. Там уже Xeon 6-го поколения.

В сервере стоят две сетевые карты по два порта 100G. Каждая карта подключена к двум разным ToR’ам (лифам). Лифы, в свою очередь, соединены с двумя спайнами. Отказ любого кабеля или коммутатора не приводит к потере связности. Ну и, конечно, в каждой стойке — два независимых ввода питания. Сети задублированы на всех уровнях. При этом нам доступна вся полоса в 400G.

Каждый хост соединяется с тремя независимыми сетями:

• Управление железом (iLO/MGT): отдельная полностью изолированная сеть для управления физическими устройствами.
• OOB: ещё одна физически изолированная сеть с линками 2×25G для управляющих команд, обновлений, метрик и внутреннего доступа хостов. Даже если основная фабрика ляжет, то доступ к хостам останется.
• Основная фабрика: 400G‑сеть для Control Plane и Data Plane. Через Control Plane общаются наши кластеры. Сервисы управления говорят кластеру нагрузок, какие именно ресурсы должны быть и в каком состоянии (да, кубер оперирует понятием «желаемое состояние»). Это отдельный сегмент. Data Plane (SDN + SDS) — это второй отдельный сегмент 400G‑фабрики для трафика клиентских виртуальных машин и сетевых дисков.

Приоритеты трафика разграничиваются через QoS. Сами сети изолируются либо физически, либо через VRF без route‑leaking. Помимо Data Plane и Control Plane, есть ещё четыре служебных сегмента, но о них — как‑нибудь отдельно.

Доступность
Мы делаем гиперскейлер. Гиперскейлер — это про доступность и отказоустойчивость. В нашем случае — на уровне виртуальной машины. Под ней может ломаться что угодно, но если она может быстро и бесшовно мигрировать с сервера на сервер — это норм. Сейчас наша цель — обеспечивать SLA на уровне 99,5%.

К концу года мы целимся в SLA 99,99% для двух виртуальных машин, запущенных в разных зонах доступности, и 99,97% — для одной виртуальной машины или любого другого сервиса. Для дата‑центра уровня TIER-3 — это 99,982% доступности. Наши 99,99% для разнесённых виртуалок — это уже выше. А стоят они в двух сертифицированных TIER-3-ЦОДах и одном несертифицированном.

Выше TIER-3 не прыгнуть. Плюс доступность там считается без учёта времени простоя сети, то есть просто по включению. Ну, точнее, можно поискать Tier-4, но оно того обычно не стоит.

У нас доступность считается с сетью. И это доступность сервисов ВМ, а не пинг до гипервизора. Чтобы ваш сервис упал всего на несколько минут в год, даунтаймы ЦОДа, даунтаймы интернет‑провайдера и даунтаймы самого сервера должны совпасть в одном временном окне. Но так не бывает. Даже надёжный сервер Hewlett‑Packard 12-го поколения в первый год эксплуатации требует около четырёх часов регламентного простоя, плюс его нужно перезагружать для апдейтов.

В облаке таких проблем нет.

Вероятно, мы нарушим это обещание. Такое случается при авариях или идиотских проблемах. Сейчас, на период обкатки в продакшене, уровни гарантий для публичного облака выглядят у нас так:

• Если доступность между 99,5 и 99% — 10% скидки.
• Если доступность 95–99%, то 15% скидки.
• Ниже 95% — 30% скидки.

Убедившись, что с этим справляемся, мы перейдём к более жёстким SLA:

• Если доступность между 99,97 и 99% — 10% скидки.
• Если доступность 95–99%, то 30% скидки.
• Ниже 95% — расчётный период бесплатно.

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

По БПЛА‑форсмажорам пока не отвечу, мы в переговорах со страховщиками.

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

Софт
А теперь самое интересное — софт. Мы не используем OpenStack, CloudStack, китайский Z‑Stack или модный Cozy (как мы его прозвали, «козий стек»). Наша платформа — полностью собственная разработка. Почему? Потому что мы всё это попробовали и поняли, что лучше не надо. Если вы нас читаете, то видели часть этих экспериментов.

Любой фреймворк — это компромисс. Ты получаешь что‑то «из коробки», но быстро упираешься в его ограничения. Например, в нижележащей системе есть нужная тебе функция, а API фреймворка её ещё не поддерживает. И ты ничего не можешь с этим сделать. Мы прошли этот путь на раннем этапе беты, когда использовали гибрид из Cozy Stack и наших сервисов, и в итоге приняли решение выпилить его полностью и написать всё с нуля.

Ещё одна важная причина — сертификация. Ни один OpenStack никогда не пройдёт серьёзную сертификацию ФСТЭК или 152-ФЗ УЗ-1.

А собственная разработка может. Мы сейчас как раз этим и занимаемся. Конечно, есть нюанс: при каждом обновлении системы сертификат ФСТЭК нужно получать заново, а это дорого — услуги испытательной лаборатории стоят порядка 400+ тысяч рублей за раз. Как показывает опыт, многие коллеги получают его один раз на какую‑то версию, вывешивают на сайт, а в продакшене крутится уже совсем другое. Мы же для приватных инсталляций будем поддерживать сертифицированные версии, потому что нашли более правильный путь беспрерывной сертификации изменений.

В основе — Kubernetes. Причём мы используем его не только для управляющего контура (control plane), но и для оркестрации всей клиентской нагрузки, включая виртуальные машины. Когда мы накидывали архитектуру с собственным оркестратором, то в какой‑то момент посмотрели на результат и поняли: «Так вот же он, Кубер!» Зачем изобретать велосипед, если есть прекрасный стек технологий, который отлично с ним интегрируется: kubevirt — для виртуализации KVM, Linstor — для SDS, и не без боли — Kube‑OVN — для SDN.

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

Для виртуализации мы выбрали самый нативный и стандартный для Linux‑мира стек: KVM — в качестве гипервизора и QEMU — для эмуляции аппаратного обеспечения. Это компоненты, встроенные прямо в ядро Linux. Некоторые конкуренты используют Xen или VMware, но сегодня KVM — это де‑факто стандарт индустрии, и изобретать тут что‑то своё просто не имеет смысла.

Хранение
Вычисления и хранилище находятся на одних и тех же физических серверах. За хранение отвечает система Linstor с DRBD под капотом. Это гиперконвергентная архитектура.

Работает это так: все SSD‑диски на сервере отдаются JBOD. Да, вы не ослышались: JBOD, который не даёт никакой отказоустойчивости, но обеспечивает максимальную производительность. Мы превращаем диски в одну большую быструю «мясорубку». Linstor поверх этого массива нарезает тома для виртуальных машин (с помощью LVM‑thin).

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

Если один сервер (или все его диски разом) выходит из строя, то система мгновенно переключается на работу со второй репликой. Пользователь даже не заметит этого. Репликация синхронная, но за это приходится платить оверхедом. Вообще DRBD поддерживает три схемы репликации: Protocol A — полностью асинхронная, Protocol B — синхронная in‑memory (операция считается выполненной при записи на primary‑диске и при записи в память на ноде с secondary‑диском) и Protocol C — полностью синхронная.

Оверлейные сети
На заре нашего проекта, в бете, всё было просто: каждая виртуалка получала белый IP‑адрес. Это было щедро, но небезопасно: никакой изоляции между клиентами на сетевом уровне. Естественно, нас это не устраивало.

Мы выбрали Kube‑OVN для создания программно‑определяемой сети (SDN). Решение отличное, но очень непростое в настройке. Наш сетевик пытался расспросить всех, до кого только мог дотянуться (а в списке были ведущие архитекторы крупных российских клаудов), а они лишь пожимали плечами. Помню, я потратил два дня на траблшутинг проблемы, почему пакеты не ходят из VPC во внешний мир при правильно настроенном (прямо по инструкции) шлюзе. Пришлось обвесить всё tcpdump'ом и на уровне каждого пакета отслеживать его путь.

Проблема оказалась в связке конфигурации VPC и NAT Gateway — виртуального маршрутизатора, который стоит на границе VPC и Интернета. Пакеты извне на него приходили, он их отправлял внутрь VPC, адресат их получал, а вот ответные пакеты обратно не уходили. И хоть ты тресни! Оказалось, что вещь, которую в документации преподносили как опцию — статические маршруты, — на самом деле является обязательным компонентом. Без прописанных вручную маршрутов к этому NAT Gateway ничего не работало. Мы победили эту проблему.

Следом мы научили систему анонсировать белые IP‑адреса клиентов по BGP. Дефолтный способ работы (ARP) нам не нравится, потому что это L2, а в нашем масштабе он был бы ещё и растянутым, что есть конкретный антипаттерн. Буквально до текущей версии Kube‑OVN не умел корректно анонсировать /32 специфики по BGP и хотел слать целые подсети. Сейчас всё работает как надо. Когда NAT Gateway получает IP‑адрес, с ноды, где он запущен, улетает анонс маршрута /32 нашему пограничному маршрутизатору с помощью BGP‑спикеров. В результате IP становится доступен из всего мира.

Сейчас в арсенале сетей у вас есть:

• Неограниченное количество VPC и подсетей.
• SNAT: все машины внутри VPC могут выходить в интернет через один общий белый IP.
• DNAT: можно пробрасывать трафик с внешнего IP на разные машины и порты внутри VPC по гибким правилам.
• FIP: можно привязать IP к хосту в формате 1:1.
• Static Routes: можно задать любые статичные маршруты внутри VPC между подсетями.
• Policy‑based Routes: то же самое, что и static, но с более гибкой настройкой по условиям.
• Security Groups (читай: файрвол), правила которых применяются на уровне шлюза или отдельного хоста. Тоже без ограничений.

Для оптимизации производительности мы применяем продвинутые приёмчики, среди которых — Mellanox ASAP для аппаратного ускорения и eBPF‑bypass для трафика между ресурсами на одной ноде.

По умолчанию мы создаём рабочую конфигурацию: VPC, сабнет, NAT Gateway с белым IP, SNAT‑rule и Static Route. Всё работает «из коробки». Но мы даём пользователям и тонкие настройки. Правда, тут есть нюанс: если вы не понимаете, что делаете, то появляется миллион способов выстрелить себе в ногу. Поэтому наш совет: если не уверены, то используйте дефолтные настройки.

S3, IAM, биллинг и бэкапы
Мы даём S3-совместимый API для объектного хранилища, чтобы клиенты могли легко перенести свои приложения с Amazon AWS, просто сменив эндпоинт.

Сейчас для скорости мы развернули его на базе Ceph и RADOS Gateway. Но, честно говоря, RADOS Gateway — это так себе решение. Оно начинает деградировать при большом количестве объектов и упирается в производительность одного Ceph‑кластера. Поэтому мы уже пишем собственный API‑шлюз. Он будет работать с группой независимых Ceph‑кластеров, распределяя нагрузку и данные между ними. Этот шлюз будет взаимодействовать с RADOS, который, в отличие от RADOS Gateway, как раз хорош. Это позволит нам масштабироваться практически бесконечно и проще управлять репликацией между автономными зонами.

Сервис управления пользователями и правами доступа (IAM) мы писали с нуля, вдохновляясь архитектурой AWS. Нас интересовало, как они обрабатывают более миллиарда запросов в секунду. Чтобы не перегружать основной сервис, существует легковесный Authentication Runtime Service. Он кэширует необходимые данные и выполняет быструю проверку прав доступа для каждого API‑вызова, будь то чтение объекта из S3 или создание виртуальной машины.

Ключевой принцип безопасности, который мы заложили: API‑ключ можно увидеть только один раз при создании. Дальше он не подлежит чтению, его можно только проверить. Никто, даже мы, не сможет его восстановить. Потерял — перевыпускай новый. Это не шутка. Умный учится на чужих ошибках. Перевыпустить ключ — дело двух кликов.


Биллинг — целая пачка микросервисов, которая должна работать строго консистентно и идемпотентно. Идемпотентность означает, что случайный повторный запрос на списание не спишет деньги дважды. Система должна корректно обрабатывать пополнения через платёжные шлюзы, не допуская фрода, и, конечно же, автоматически останавливать ресурсы пользователя при нулевом балансе. Да, на старте у нас была забавная ситуация, когда ресурсы при нулевом балансе не прибивались. Тем, кто нашёл эту дыру, мы разрешили пользоваться ею до исправления). Багбаунти, кстати, пока нет (хотя коллеги и бета‑тестеры уже накидали пару раз в панамку), про неё думаем.

Бэкапы реализованы через снапшоты. Linstor, используя LVM‑thin, умеет делать мгновенные снимки дисковых томов. Эти снапшоты мы выгружаем в наше S3-совместимое объектное хранилище. Снапшоты, кстати, тоже есть — можно зафиксировать состояние диска в моменте и разворачивать из него виртуалки сколько угодно.

Важно, что хранилище для бэкапов работает на совершенно других, выделенных серверах. Кроме того, у нас есть партнёрство с «Киберпротектом» (это, если что, бывший Acronis, который разделился на Acroni~1 и Acroni~2 с момента начала санкций) для защищённых резервных копий в отдельном хранилище. Прямо под капотом их нет, но по запросу мы их включим.

А для самых параноидальных клиентов мы рассматриваем внедрение ленточных хранилищ. Звучит как анахронизм, но на самом деле — очень крутая штука. У ленты есть одно убойное преимущество — её нельзя заразить шифровальщиком. В смысле можно, но нельзя. Лента надёжна.

Поддержка
Помните историю про «Ваша виртуалка на согласовании» из одного энтерпрайзного облака, когда это должно решаться одной кнопкой в личном кабинете? А вот у кого‑то она до сих пор на согласовании. У кого‑то поломался биллинг, и, когда его починили, заблокировали треть пользователей разом без предупреждения. А у людей — праздники. Как им срочно пополнять баланс? И ответ один: «Не нравится — идите на...» Где‑то надо смотреть 40-минутный вебинар, чтобы разобраться, как поднять простенький сайт…

Мы другие.

Мы небольшая команда инженеров, которая строит продукт для таких же инженеров. Мы — это вы.

И хотим и дальше так делать.

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

Сейчас мы небольшого размера — сотни серверов. Это топовое современное железо, которое производительнее «среднего по рынку» в несколько раз. Так что по мощности мы соответствуем среднестатистическому облачному провайдеру. Какого размера мы хотим быть? Просто передам привет Селектелу, МТСу и Сберу.



Друзья, мы пришли на этот рынок всерьёз и надолго.

h3llo.cloud

Основное, что сейчас с рынком:

• У многих коллег по рынку моментально и некисло выросли ценники
• Мы не планируем повышать цены из-за текущей ситуации всвязи с повышенным спросом
• Мы вывезли почти всё оборудование из IXcellerate (крупные ЦОДы) и разместили на своих площадках
• Площадки снаружи не выглядят как ЦОД, инфраструктура внутри распределена шире, чем в обычном машзале
• Многие намеренно раскидывают оборудование на десяток разных площадок по чуть-чуть, возрождают старые серверные и админов в свитерах.
• Все переписывают Disaster Recovery-планы, потому что такого ещё не было, и главная проблема уже не в экскаваторах.

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

Теперь подробнее.

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

Мы, если что, не поднимаем и не планируем поднимать цены. Мы продолжаем жить ровно на тех же ценах и условиях, что и до мая.

Возможно, поэтому было тяжело поднять голову в эти дни, потому что свалилось много работы.

Все с мелкими виртуалками как‑то размазались по рынку (возможно, ушли в ЦОДы СНГ), а вот корпораты и гиганты не могут так сделать. У них обработка персональных данных, и она должна делаться на территории России. Поэтому к нам вполне утром может прилететь запрос на огромную инфраструктуру, мы отвечаем коммерческим предложением, днём мы её выделяем, вечером начинаем миграцию — и параллельно юристы обсуждают бумажки. Многим важнее подняться и найти новый ЦОД.

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

Ещё мы были очень заняты тем, что вывозили оборудование из крупных дата‑центров IXellerate — мы ещё пару месяцев назад начали подозревать что‑то и думали, что, если что, они в списке целей. Поэтому мы оттуда смигрировали почти полностью — там остались только единичные серверы и точки присутствия (где стык с провайдерами и тому подобное), это для технического резерва инфраструктуры.

Один новый дата‑центр развернули, ещё два на подходе. Где они — не скажем, но это не бункеры.

Что происходит с рынком?
Ну, все резко проснулись. Теперь сидят в когнитивном диссонансе и с разной скоростью пытаются осознать реальность.

Уже точно понятно, что, во‑первых, все теперь будут по чуть‑чуть бояться крупных, известных всем объектов, особенно если они находятся за пределами МКАДа.

Во‑вторых, концепция Disaster Recovery изменилась навсегда. Это смешно, но когда ваш DR‑план начинается со слов «найти уцелевший сервак». Концепция отказа целого региона или отвала крупного провайдера перестала быть чем‑то из области мифических единорогов, которых никто никогда не встретит. Теперь об этом стоит серьёзно думать.

Удивительно, что ситуация с AWS у арабов, когда им расхерачили огромный амазоновский ЦОД, ничему крупный бизнес не научила. Раньше дата‑центры проектировались из расчёта, что вылетит максимум что‑то одно — условно, перебьют линию с интернетом или отвалится питание. Сейчас ЦОДы выпадают не случайно. Бьют целенаправленно: выискивают самые загруженные узлы, точки отказа и фигачат прямо по ним. Теперь все большие компании будут тестировать отказоустойчивость из расчёта «а если ударили в самое больное?», и DR будут строить именно через это.

Кто приходит сейчас?
Профиль клиента сильно изменился. Повалили не небольшие пользователи, которым нужна виртуалка подешевле, а крупняк со специфическими запросами на нюансы работы. Им нужен Managed‑кластер Kubernetes с хитрой балансировкой внутри зон доступности и между другими кластерами. Возможно, это потому что у них уже поменялись подходы к Disaster Recovery.

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

Многим арендаторам просто не нашлось места в Яндексе — они, очевидно, приоритезировали собственные сервисы, в том числе критичные. Кто жил в нём как в единственной точке присутствия и нигде не резервировался — не повезло. Надо было делать Disaster Recovery. Теперь те, кто не делал, бродят по рынку и охреневают.

Когда мы выехали из IXellerate?
Ровно в тот момент, когда начали что‑то понимать про ситуацию и её прогнозы. Это понимание у всего рынка резко случилось несколько месяцев назад, и, глядя, кто рядом с нами стоит из крупняка, мы решили, что лучше стоять от них подальше. Даже до того, как сам Икселерейт начал рассылать инструкции о том, как вести себя в случае угрозы БПЛА.

В это же время на рынке начали появляться люди, которые искали подземные помещения типа бункеров для новых ЦОДов.

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

Куда сейчас встают клиенты коммерческого облака?
На нашу собственную площадку. Адрес не скажу: мы внимательно изучили столб дыма и решили, что не будем светить расположением своих ЦОДов вообще. Поэтому три новые площадки у нас без адресов — но это Москва внутри Садового кольца (две) и в пределах МКАД (ещё одна). Адрес нужен в одном случае — например, если корпораты едут регистрироваться в государственном органе. Там мы подписываем NDA и показываем.

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

Как поменялась архитектура ЦОДа на рынке?
Про бункеры я уже говорил. Это не наш подход, мы боимся затопления. Да, по стандартам Tier их сертифицировать нельзя. Но если рассматривать их не как основную рабочую единицу под всю нагрузку, а как место, куда в реальном времени снимаются актуальные бэкапы, — это суперперспективная история.

Наши же новые площадки мы проектировали вот так:

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

Главное для ЦОДа — электричество и сеть. Внутри Москвы ни с тем, ни с тем по доступности проблем нет, но по электричеству есть вопрос цены, это одно из важных усложнений.

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

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

Были попытки помочь Яндексу?
Я знаю, что многие туда стучали со словами «дайте нам ваших бывших клиентов». Мы общались по другим вопросам. Меня в первую очередь интересовала инфраструктура Рунета. Мы им предложили наши мощности и серваки для той инфры, на которую опирается всё IT‑комьюнити. Я говорю про DNS, NTP‑шки, зеркала репозиториев и так далее. Это та хрень, которая бизнесу денег не приносит, но которая реально нужна всем. Если её не станет, очень печально будет абсолютно всем.

Что будет с рынком?
Ну, стоимость владения инфраструктурой сейчас пересматривают примерно все. Причём это касается не столько облачных провайдеров, сколько обычного рядового среднего и малого бизнеса. Облака в том абстрактном виде, к которому мы привыкли, нужно пересматривать. Поэтому вопросы гибридной инфраструктуры (когда часть лежит on‑premise, а часть распределена по разным облакам) стали невероятно острыми.

Собственно, вот. Через пару дней узнаю, что происходит со страховщиками, потом нас опять накроет кучей работы (в основном миграций), а потом уже можно будет выдохнуть и чуть разобраться ещё.

С 15 июня Hetzner поднял цены на новые выделенные серверы в 2–4 раза. У нас освободились серверы, заказанные до повышения, поэтому сдаём их до 3 раз дешевле, чем сейчас стоят сопоставимые новые у самого Hetzner. Все — в дата-центрах Hetzner в Германии (DE) и Финляндии (FI), установка бесплатная.

Для больших проектов: виртуализация, базы данных, CI, нагруженные сервисы

• AMD EPYC 7502P · 256 GB DDR4 ECC · 4×3.84 TB NVMe — DE
  32 ядра / 64 потока · 1 Gbps безлимит · установка 0 €
  277 €/мес (≈ 25 980 ₽) · у Hetzner AX162-2 с 256 GB — 842 €/мес + 419 € установка
• AMD EPYC 7502P · 192 GB DDR4 ECC · 4×1.92 TB NVMe — FI
  32 ядра / 64 потока · 1 Gbps безлимит · установка 0 €
  265 €/мес (≈ 24 860 ₽) · у Hetzner AX102-2 с 192 GB — 547 €/мес + 274 € установка
• AMD Ryzen 9 5950X · 128 GB DDR4 ECC · 2×3.84 TB NVMe — FI
  16 ядер / 32 потока, до 4.9 GHz · 1 Gbps безлимит · установка 0 €
  146 €/мес (≈ 13 690 ₽) · у Hetzner AX102-1 со 128 GB — 257 €/мес + 129 € установка

Для сайтов, парсеров, игровых и рабочих серверов

• AMD Ryzen 9 3900 · 128 GB DDR4 ECC · 2×1.92 TB NVMe — DE, FI
  12 ядер / 24 потока, до 4.3 GHz · 1 Gbps безлимит · установка 0 €
  99 €/мес (≈ 9 280 ₽) · самый дешёвый новый со 128 GB у Hetzner — 257 €/мес + 129 € установка
• AMD Ryzen 9 3900 · 64 GB DDR4 ECC · 2×1 TB NVMe — DE, FI
  12 ядер / 24 потока, до 4.3 GHz · 1 Gbps безлимит · установка 0 €
  89 €/мес (≈ 8 350 ₽) · у Hetzner AX42-1 (8 ядер, 64 GB, 2×512 GB) — 97 €/мес + 49 € установка

Для бэкапов, архивов и медиа

• AMD Ryzen 5 3600 · 64 GB DDR4 ECC · 2×16 TB SATA (Software-RAID) — DE
  6 ядер / 12 потоков, до 4.2 GHz · 1 Gbps безлимит · установка 0 €
  74 €/мес (≈ 6 940 ₽) · у Hetzner SX65-2 с 4×16 TB — 82 €/мес + 39 € установка

Цены Hetzner — по официальному прайсу на новые заказы с 15.06.2026, без НДС и без IPv4. Новые серверы Hetzner построены на более свежем поколении процессоров и DDR5, но по памяти и дискам наши конфигурации такие же или больше, а стоят в разы дешевле и без платы за установку.

---

Условия

• сервер выдаём в течение часа после оплаты;
• цена фиксирована;

Серверы в единичном количестве: EPYC 256, EPYC 192 и 5950X — по одному, Ryzen 9 3900 128 GB — 4 шт., Ryzen 9 3900 64 GB — 5 шт., Ryzen 5 3600 4×16 TB — 2 шт. Новых по такой цене не будет в ближайшее время, Hetzner больше не продаёт эти конфигурации по старому прайсу.

Заказать: abcd.host/dedicated
Вопросы и подбор под задачу: Telegram · sales@abcd.host

Спасибо, что остаётесь с нами!
ABCD.HOST

Мы переносим наши серверы в Германии в дата-центр Digital Realty. Digital Realty — один из крупнейших операторов дата-центров в мире; их объекты ориентированы на бизнес-клиентов, для которых стабильность является главным приоритетом.

Для вас перенос осуществляется бесплатно.

ДАТЫ ПЕРЕНОСА

С 29 октября по 5 ноября включительно
Это касается только VPS на нашем оборудовании в Германии (тарифы LiteCPU и Hi-CPU). Выделенных серверов Hetzner/WorldStream это не затрагивает.

Что улучшится после переезда

• Каналы 10 Гбит/с. Каждый физический сервер, на котором размещаются VPS, теперь подключен по каналу 10 Гбит/с. Это обеспечивает узлу значительный запас пропускной способности.
• Новое сетевое ядро. Мы обновляем сетевое ядро ​​и подключаем вышестоящих провайдеров (апстримы) по каналам 100 Гбит/с.
• Точка обмена трафиком GNM-IX. Мы подключаемся к GNM-IX — точке обмена трафиком, где представлены Telegram, Meta (Facebook, Instagram, WhatsApp), Cloudflare и другие крупные сети. Часть трафика к ним будет направляться напрямую, минуя промежуточных провайдеров.
• + И множество других преимуществ, о которых вы узнаете позже.

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

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

Перенос никак не повлияет на данные, хранящиеся на вашем сервере.

Это не последнее письмо касательно переноса. Ближе к началу работ мы пришлем вам дополнительную информацию. Мы также будем публиковать актуальные сведения на странице spacecore.online/status/uptime

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

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

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

Для дополнительного хранения резервных копий предлагаем наше объектное S3-хранилище.
Его преимущества:

• Масштабируемость. Автоматическое увеличение объёма с возможностью установить лимиты.
• Репликация данных. Данные хранятся в двух копиях на независимых серверах в дата-центре IXcellerate.
• Простая интеграция. Поддержка S3 API для работы с вашей инфраструктурой.
• Прозрачная тарификация. 750 ₽/мес. за 300 ГБ, далее — 2,5 ₽/ГБ в месяц. Трафик и операции с данными не тарифицируются.

1dedic.ru/services/s3

Мы рады объявить о важном этапе нашей европейской экспансии: миланский регион Scaleway ( it-mil ) теперь официально является полноценным регионом.

С запуском стандартов MIL-2 и MIL-3 наряду с существующей зоной зон MIL-1, наша итальянская инфраструктура теперь предлагает полную отказоустойчивость корпоративного уровня, позволяя вам создавать, развертывать и масштабировать критически важные рабочие нагрузки в Южной Европе.

Что это значит для вашей инфраструктуры:

• Готовая к использованию экосистема: воспользуйтесь полным набором облачных ресурсов, включая экземпляры, блочное хранилище, публичный шлюз, объектное хранилище с поддержкой нескольких зон доступности и многое другое.
• Максимальная доступность: распределите вычислительные ресурсы, хранилище и сеть между тремя физически изолированными зонами доступности в одном регионе. Это помогает защитить ваши приложения от инцидентов уровня центра обработки данных благодаря бесшовной архитектуре высокой доступности (HA).
• Всё большая европейская автономия: сохраняйте полный контроль над своей инфраструктурой и данными на всей территории наших 3 зон доступности.

Готовы начать строительство?
Независимо от того, планируете ли вы создать собственную инфраструктуру, расширить свой бизнес в Южной Европе или перенести существующие производственные нагрузки к европейскому облачному провайдеру, мы готовы оказать поддержку на каждом этапе.

www.scaleway.com/en/

Начинающим стартапам, пет-проектам и open-source продуктам часто не хватает бюджета на надежную инфраструктуру. Мы готовы взять эти расходы на себя.

Что предлагаем:

• Бесплатный VPS (2 vCPU, 2 ГБ RAM, 40 ГБ SSD) на срок до 3 месяцев.
• Помощь с переездом и приоритетную техподдержку.
• Возможность получить более мощную конфигурацию под вашу задачу.

Взамен мы попросим от вас один честный материал о вашем опыте работы с UFO.Hosting — это может быть статья, обзор, пост или видео.

А ещё публикация может приносить вам доход: добавьте реферальную ссылку и получайте до 20% комиссии с привлечённых клиентов.

Программа подойдёт проектам с активной аудиторией, а для open-source — в том числе с активным GitHub-сообществом.

Количество мест ограничено.

ufo.hosting/programma-podderzhki-proektov

Обновили Пользовательское соглашение Selectel.

В разделе 6 «Ограничение ответственности» уточнены условия ограничения ответственности Исполнителя, а также положения об обстоятельствах, при которых Исполнитель не несет ответственности за убытки Заказчика.

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

С новой редакцией Пользовательского соглашения можно ознакомиться по ссылке: selectel.ru/about/documents/user-agreement/

После сообщений об атаках на дата-центры Яндекса в интернете распространились утверждения о том, что российские бот-фермы и операции по оказанию влияния были выведены из строя. Графики HTTP-трафика показали резкое падение, что подпитывало предположения о том, что повреждение инфраструктуры остановило действия этих злоумышленников. Однако агрегированные показатели трафика могут легко ввести в заблуждение. С Яндексом связаны два номера автономных систем (ASN): AS13238 используется поисковой системой Яндекса, а AS200350 — облачными сервисами.

Используя данные Cloudflare Radar и Bot Management, мы проанализировали, как это повлияло на эти две автономные системы (ASN), и хотя в обеих наблюдалось снижение трафика, последствия были разными.

• Поиск Яндекса (AS13238): Падение трафика было вызвано почти исключительно индексацией веб-страниц, изображений и ресурсов сайта проверенными поисковыми роботами.
• Yandex.Cloud (AS200350): Наблюдалось снижение вредоносной активности, такой как сканирование и проверка уязвимостей, но высокопроизводительная автоматизация не исчезла — она просто переместилась к другим хостинг-провайдерам.

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

Что произошло: последствия забастовок и исходный уровень до события.
В период с 7 по 11 октября, по сообщениям, украинские беспилотники нанесли удары по трем объектам Яндекса в России, постепенно выводя из строя центры обработки данных и сетевые мощности. Как видно на Cloudflare Radar, это привело к почти полному коллапсу сети Яндекса 11 октября, когда трафик упал на 99% ниже базового уровня для Яндекс Поиска (AS13238) и на 90% для Яндекс.Облака (AS200350). Несмотря на кратковременное частичное восстановление, обе сети оставались неработоспособными до 13 октября, стабилизировавшись на уровне 86-90% ниже нормального базового уровня. (По состоянию на 14 октября, 18:00 UTC, трафик составляет 85% от нормального уровня.)


Снижение общего HTTP-трафика лишь подтверждает сбой в сети. Оно не показывает, были ли нарушены действия вредоносных или скрытых ботов. Рассматривая базовый уровень автоматизации до инцидента, мы видим, что до атак автоматизированные запросы составляли 36,1% всего HTTP-трафика, наблюдаемого в сети Cloudflare по всему миру, и 35,8% трафика с российских IP-адресов.

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

ASN «Яндекс Поиск» (AS13238) используется для индексации поисковых систем. Cloudflare классифицировал 99,5% его запросов как автоматические, а 93,6% запросов от ботов — как подтвержденные. Наш анализ показал, что трафик из этого ASN индексировал страницы, отображал страницы и отображал изображения, что является типичным поведением для поискового робота. На ASN «Яндекс Поиск» приходилось около 7% запросов от ботов из России и всего 0,05% от общего глобального объема.

Азиатско-Тихоокеанская сеть Yandex.Cloud (AS200350) — это сеть облачного хостинга с совершенно иным набором автоматизации. Примерно 95% запросов, оцененных ею, были запросами от ботов, но ни один из наблюдаемых запросов от ботов не был подтвержден Cloudflare. Боты Yandex.Cloud больше походили на программные приложения: почти две трети их запросов отправляли данные на веб-сайты, некоторые идентифицировали себя как программы на JavaScript, Python или Go, и большая их часть направлялась компаниям-разработчикам программного обеспечения, чем поисковые боты Yandex. На долю Азиатско-Тихоокеанской сети Yandex.Cloud приходилось около 2% запросов от ботов из России и всего 0,01% от общего мирового объема.

Влияние события на общий трафик ботов.
«Бот-трафик» — это автоматизированные запросы к веб-сайтам в сети Cloudflare, такие как запросы от поисковых роботов и скриптов, а не обязательно активность на платформах социальных сетей. По мере снижения пропускной способности сетей Яндекса количество запросов от ботов также сократилось. Это было ожидаемо: почти весь трафик от Яндекс Поиска и Яндекс.Облака был автоматизированным. Хотя мы наблюдали очевидное падение общего трафика, мы не обнаружили никаких доказательств, связывающих глобальное снижение вредоносного трафика с падением трафика от Яндекса.

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


Влияние на ASN Яндекс Поиска (AS13238): меньше индексации поисковых систем.
Снижение популярности Яндекс Поиска было практически полностью обусловлено индексацией поисковых систем. Анализ запросов показал, что 78,1% из них принадлежали проверенному ЯндексБоту, 11,5% — ЯндексРендРепозиторсБоту и 1,9% — ЯндексИзображениям.

Среди веб-сайтов и сервисов наиболее резкое падение наблюдалось в сегменте издательского дела и газет, где трафик из сетей Яндекса упал на 44%. Примерно 90% трафика на новостные сайты из этой ASN до события составлял индексация статей Яндексботом, при этом 40,5% клиентов Cloudflare получали HTTP-ответы 403 Forbidden, поскольку владелец сайта блокировал поискового робота. Когда ASN Яндекс Поиска отключился, клиенты просто увидели меньшее количество индексации от Яндекса.

Влияние на ASN Яндекс.Облако (AS200350): легитимное использование и миграция вредоносного трафика.
В Яндекс.Клауде наблюдалась совершенно иная картина. После сообщений об атаках бот-трафик с Яндекс.Клауда упал примерно на 40%. Особенно резкое снижение наблюдалось в нескольких категориях, связанных с атаками. Например, количество запросов к плагинам WordPress упало на 90%, а количество запросов, идентифицированных сканером, — на 93%. Интересно (и показательно), что количество блокировок трафика Яндекс.Клауда со стороны клиентов Cloudflare также снизилось на 70% за период событий, что говорит о том, что даже вредоносный трафик с этой ASN попадал на WAF Cloudflare пропорционально меньше.

Влияние на бизнес-вертикали
Боковый трафик Yandex.Cloud также представляет интерес, если его сегментировать по наиболее часто запрашиваемым отраслям:


Большая часть трафика из ASN Yandex.Cloud приходилась на две отраслевые категории: программное обеспечение и азартные игры. Отношение к программному обеспечению было предсказуемым для ASN, предназначенной для размещения сторонних приложений и интеграций с программным обеспечением. Более того, мы даже обнаружили, что api.cloudflare.com является одним из основных хостов для запросов к Yandex.Cloud. В целом, большая часть этого трафика была успешной (запросы возвращали коды 200) как до, так и во время мероприятия, что указывает на легитимное использование.

Наиболее убедительные доказательства того, что вредоносная автоматизация не исчезла, а переместилась в другое место, — это игорный сектор. Практически все запросы ботов от Yandex.Cloud были направлены на один аккаунт клиента игорного сервиса, при этом трафик переключался между его хостами. Сразу после сбоя 8 октября количество запросов ботов от Yandex.Cloud к этому аккаунту упало до нуля. Одновременно с этим начали появляться идентичные запросы от других российских хостинговых ASN, включая Radist и Selectel. Входящий трафик сохранял идентичный «отпечаток» у всех провайдеров:

• Тот же отпечаток клиента JA4 TLS
• Те же самые нестандартные пути запроса и HTTP-заголовки.
• Те же самые пользовательские строки User-Agent.

В целом, трафик российских ботов, нацеленных на игровые аккаунты, за неделю остался практически неизменным, увеличившись со 167,7 млн ​​до 170,1 млн запросов (+1,4%). Автоматизация не прекращалась; операторы просто перенесли свои рабочие нагрузки на альтернативных облачных провайдеров, как только Yandex.Cloud стал недоступен.

В большинстве отраслей доля запросов ботов к Yandex.Cloud, возвращающих HTTP-ответы 4xx, снизилась. Это во многом связано с уменьшением трафика, подобного атакам, о котором говорилось выше. В сочетании с анализом поведения клиентов, занимающихся азартными играми, это показывает, что вредоносный трафик, отправлявший запросы через Yandex.Cloud, просто переключился на других провайдеров после сбоя в работе сервиса.

Наконец, при анализе трафика в социальных сетях мы не обнаружили неожиданных изменений ни с российских IP-адресов (снижение общего трафика на 0,6% за период событий), ни в глобальном масштабе (увеличение общего трафика на 1,2% за период событий). Мы повторили анализ трафика ботов, обращающегося к конечным точкам «публикация», «ответ» и «лайк» на конкретной платформе социальных сетей, и аналогично не обнаружили неожиданных изменений до или во время периода событий ни с российских IP-адресов (снижение общего трафика на 5,7% за период событий), ни в глобальном масштабе (увеличение общего трафика на 1,1% за период событий). На основании нашей оценки, данные, по-видимому, не подтверждают утверждения о том, что атаки парализовали манипуляции в социальных сетях, хотя без дальнейшего анализа данных вне Cloudflare мы не можем с уверенностью сказать, что связи нет.

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

Индексация поисковых систем снизилась. Подавляющее большинство трафика, упавшего с Яндекс Поиска, составляли проверенные краулеры ЯндексБот, загружавшие новостные статьи и веб-ресурсы. Основное влияние заключалось в снижении видимости контента в Яндекс Поиске.
Вредоносная автоматизация переместилась, а не прекратилась. Хотя сканирование уязвимостей и проверка плагинов временно прекратились на Yandex.Cloud, высоконагруженные операции быстро переместились на альтернативные хостинговые сети.
Сбой в сети означает, что конкретные серверы перестали отправлять запросы, но это не значит, что автоматизированная угроза исчезла. Облачные рабочие нагрузки являются переносимыми, поэтому, когда центр обработки данных выходит из строя или блокируется IP-префикс, операторы могут перенести свои скрипты к другому провайдеру за несколько часов.

Наш анализ напоминает, что объем трафика клиентских ASN является ненадежным показателем для интерпретации поведения автоматизированных ботов. Защита от автоматизированных угроз требует анализа поведения запросов, например, выявления общих отпечатков JA4, мониторинга аномальных частот запросов и применения правил WAF к конфиденциальным конечным точкам, независимо от того, из какой сети исходит запрос. Физическая инфраструктура статична, но вредоносная автоматизация создана для перемещения.

Finland Hetzner Ryzen-9 3900 [4vCore] / 4 ddr4 / 100 ГБ NVME — 1000р/мес
Finland Hetzner Ryzen-9 3900 [24vCore] / 8 ddr4 / 200 ГБ NVME — 1500р/мес
Finland Hetzner Ryzen-9 3900 [24vCore] / 16 ddr4 / 400 ГБ NVME — 2900р/мес
Свободно — 130 ГБ озу, сети 95.217.99.* / 135.181.14.* / 95.217.123.* / 5.9.195.* / 162.55.136.*

уникальный остаток — 1 единица
Finland Hetzner i9-9900k [16vCore] / 64 ddr4 / 800 ГБ NVME / 1 gbps — 5000р/мес
IP только такой 65.108.207.11
заказать по тикету можно
особенность сервера будет работать лет 5 точно еще, ибо там соседи не отказываются, но и новые клиенты уже не покупают, плюс я уже убрал такой процессор с прайса

OVH FR GRA1 GRA2
Ryzen 7 3800X [8 vCore] / 4 ddr4 / 50 NVME — 1000р
Ryzen 7 3800X [16 vCore] / 8 ddr4 / 100 NVME — 2000р
Свободно — 80 ГБ озу, сети 178.32.80.* / 54.36.71.* / 51.254.148.* / 149.202.17.* / можно из наших РУ сетей по запросу в том числе под игры

[распродажа, последние остатки] [2026]
i7-7700k/Random-Xeon/R7-3800x [8vCore] / 8 ddr4 / 100 ГБ NVME / 500 Mbps — 1200р/мес
Свободно — 140 ГБ озу
Особенности тарифа — только новые NVME диски, которые я хранил 3 года, а потом подумал нахуй не нужны и создал из этих разных солянок от 32 до 128 озу серверов тариф. Они еще лет 10 прослужат легко, идеально в долгосрок.

Заказать
asuka.onl/billmgr