Проблемы у очередного российского хостера: клиенты ESTT потеряли доступ к серверам, причины сбоя остаются неизвестными

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

Первым неладное заметил сервис мониторинга Detector404. С раннего утра 8 ноября пользователи жаловались на неработающие инструменты, причём у части клиентов одновременно отказывали несколько ресурсов:

• не открывались сайты;
• обрывались подключения к виртуальным серверам;
• переставали работать SSH и FTP;
• панель управления хостингом оставалась недоступной.

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

ESTT работает на рынке более 20 лет, сдаёт в аренду физические и виртуальные серверы, предлагает облачные платформы, хостинг и хранение данных. Собственный дата-центр компания относит к уровню Tier III по классификации Uptime Institute. Для объектов этого уровня предусмотрено плановое обслуживание инженерных систем без остановки оборудования, но от аварий и программных неисправностей классификация не страхует. На арендованных серверах живут интернет-магазины, CRM, базы данных и внутренние приложения, поэтому без резервной площадки переключение на другие мощности потребует времени и денег.

Нынешний сбой напомнил про июль 2025 года, когда ESTT попала под продолжительную DDoS-атаку. По данным «Ведомостей», воздействие на серверы началось 18 июля и затянулось на несколько дней, а источник в компании-клиенте хостера рассказал о пострадавших организациях ресторанного сектора. Перебои зафиксировали у заметных сетей:

• у «Вкусно и точка» нарушилась работа сайта и приложения;
• кухни «Много лосося» с 18 по 20 июля не могли принимать заказы;
• у Cofix возникли перебои в работе приложения;
• сеть «Суши мастер» попала в число затронутых;
• у iiko нарушилась работа сервисов автоматизации ресторанов.

Программы iiko управляют заказами, кухней и кассами, поэтому проблемы поставщика бьют по ресторанам напрямую. Сергей Миронов, основатель сети «Мясо & рыба» и председатель координационного совета Федерации рестораторов и отельеров, оценил долю решений iiko примерно в половину российских ресторанов. Позже ESTT подтвердила масштабную DDoS-атаку, сообщила об усилении фильтрации трафика и сохранности клиентских данных.

Точное число клиентов ESTT не раскрывается. В июле 2025 года Никита Цаплин, генеральный директор облачного провайдера RUVDS, оценил число заказчиков, которых могла задеть атака, величиной до 3500. Это прикидка по одному эпизоду, а не размер клиентской базы, и переносить её на нынешний сбой нельзя. За корпоративным аккаунтом стоят тысячи сотрудников и покупателей, поэтому для российских пользователей последствия оборачиваются недоступным приложением доставки или магазином, который не принимает заказы.

По данным Роскомнадзора, которые опубликовал «Интерфакс», Национальная система противодействия DDoS-атакам за первые 10 месяцев 2026 года отразила 20 115 атак на защищаемые ресурсы. Динамика резко пошла вверх:

• в 2024 году система отразила 10 935 атак;
• в 2025 году отразила 21 622 атаки;
• с января по октябрь 2026 года отразила 20 115 атак.

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

В ночь на 2 ноября 2026 года массированная кибератака обрушилась на провайдера Beget. По данным РБК, под удар попали около 500 тыс. интернет-ресурсов, среди них сайты СМИ и госсервисов. Компания сообщила, что восстановить все пользовательские данные не сможет, а облачную платформу придётся создавать заново. Более 60% хостинга удалось вернуть в работу, но восстановление данных из резервных копий осталось отдельной сложной задачей. Эти инциденты нельзя смешивать, ведь Beget говорит о кибератаке, а ESTT пока называет причину техническим сбоем.

Главная угроза кроется в концентрации ресурсов. Когда сотни компаний сидят на одной площадке, неисправность бьёт по независимым бизнесам одновременно, и в ИТ это называют риском общей точки отказа. Больнее всего сбои ударяют по нескольким категориям сервисов:

• интернет-магазины теряют оформление заказов, личные кабинеты и платежи;
• ресторанные сети и доставка лишаются передачи заказов на кухню;
• финансовые и корпоративные сервисы упираются в недоступные базы данных;
• облачные SaaS-платформы тянут за собой клиентов, которые зависят от чужой инфраструктуры.

Защититься помогает географическое резервирование, когда основная инфраструктура стоит у одного провайдера, а резервные копии у другого.

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

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