DDoS-атаки на региональных провайдеров достигли 2,5 Тбит/с: почему резервирование канала становится бизнес-задачей

Интернет-магазин принимает заказы, реклама приводит покупателей, сервер работает без перегрузки. Но часть посетителей не может открыть каталог, а сотрудники — войти в CRM. Причина может находиться за пределами инфраструктуры магазина: под DDoS-атакой оказался оператор связи, через которого проходит трафик.

В сентябре 2026 года CNews опубликовал данные StormWall: пиковая мощность атак на региональных интернет-провайдеров в августе достигла 2,5 Тбит/с. Исследование основано на данных клиентов компании из телеком-сферы. Это максимум в наблюдениях StormWall, а не средняя мощность атак и не оценка всех российских операторов.

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

Почему работающий сервер ещё не означает доступный бизнес

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

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

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

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

Второй канал помогает, но не заменяет фильтрацию

У резервирования и DDoS-защиты разные функции. Резервирование даёт альтернативный путь при отказе основного. Фильтрация отделяет вредоносный трафик от полезного, чтобы атака не исчерпала доступные ресурсы.

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

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

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

Два договора ещё не означают два независимых пути

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

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

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

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

Резерв должен выдерживать рабочую нагрузку

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

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

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

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

Кто и когда включает резерв

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

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

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

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

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

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

До проверки фиксируют, какие функции должны сохраниться и за какое время. Во время неё измеряют весь интервал: от возникновения отказа до возможности выполнить нужное действие. Отдельно проверяют возвращение на основной маршрут — оно тоже может прервать соединения.

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

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

Маркетинг участвует в этой проверке наравне с IT. Команде нужны правила управления кампаниями: при каком масштабе недоступности ограничивать рекламу, кто принимает решение и как учитывать затронутые регионы и площадки. Автоматическая остановка всех кампаний из-за единичной ошибки проверки может оказаться избыточной.

Как обосновать расходы на устойчивость

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

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

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

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