7 шагов для подготовки инфраструктуры к высоким нагрузкам, атакам и сбоям

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

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

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

Шаг 1. Проводим стресс-тест

Для начала проверим, к каким нагрузкам готова инфраструктура.

Стресс-тестирование поможет понять:

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

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

Провести такое тестирование можно с помощью разных инструментов, как платных, так и бесплатных. Вот несколько неплохих Open Source решений, с помощью которых можно провести стресс-тест самостоятельно:

• JMeter — один из самых популярных инструментов нагрузочного тестирования. С его помощью можно тестировать веб-сервисы, мобильные приложения и базы данных. Язык программирования по умолчанию — Groovy. Однако, если у вас распределённая инфраструктура, его может быть сложно масштабировать.
• Locust — популярный Open Source на Python. Подходит для тестирования не только онлайн-сервисов, но и API. Позволяет отслеживать работу систем при росте нагрузки в удобном интерфейсе и легко масштабируется.
• Artillery.io — приложение для создания нагрузочных тестов. Позволяет имитировать нагрузку от тысячи пользователей. Можно добавить собственную логику, чтобы проверить нетипичные сценарии роста нагрузки. Поддерживает большинство популярных протоколов.

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

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

Шаг 2. Добавляем ресурсы там, где их не хватает

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

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

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

При этом большинство облачных провайдеров (в том числе и EdgeCenter) используют модель PAYG (Pay-As-You-Go): вычислительные ресурсы оплачиваются поминутно, только за время работы виртуальной машины.

Таким образом, в облаке вы не переплачиваете за простои.

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

Шаг 3. Используем балансировщики нагрузки

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

В этой ситуации поможет балансировщик нагрузки.

Они бывают разных видов. Мы в EdgeCenter, например, предоставляем 2 типа балансировщиков:

1. На уровне приложений L7 (HTTP/HTTPS). Поддерживает маршрутизацию на основе URL-путей. Запросы могут перенаправляться на 1 или несколько портов каждого сервера в кластере. Балансировка определяется содержанием сообщений.

Такой балансировщик необходим, когда нужно понимать, какой именно контент должен отдаваться пользователям. Например, у вас есть две версии сайта: на русском и английском. С помощью L7-балансировщика можно направить пользователей из России на русскоязычную версию, а пользователей из США — на англоязычную. Или у вас разные тарифные сетки для разных регионов. Балансировщик направит одних пользователей на ресурс с одной тарифной сеткой, а пользователей из другого региона — на другой.

2. На сетевом и транспортном уровне L3, L4 (TCP/UDP). Может обрабатывать тысячи запросов в секунду. Не считывает содержимое и более эффективен для простой балансировки на уровне пакетов, быстрой и безопасной передачи сообщений. Этот балансировщик подойдёт, если вам нужно просто равномерно распределить нагрузку между серверами.

Шаг 4. Используем CDN

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

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

CDN нужна, если в вашем проекте много статического контента (картинок, видео, текстов и т.п.), часто происходят пиковые всплески трафика, или если у вас географически распределённая аудитория. Мощная сеть обеспечит быструю загрузку ваших веб-ресурсов из любой точки мира и легко справится с нагрузкой.

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

Шаг 5. Подключаем профессиональный DNS

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

Например, DNS-хостинг EdgeCenter использует балансировку Anycast. Запросы к DNS распределяются по серверам и отправляются кратчайшим маршрутом. А если один из серверов выйдет из строя, ваш ресурс останется доступным.
Кроме этого, многие DNS-провайдеры предоставляют дополнительные опции для повышения отказоустойчивости. У нас, например, есть функция DNS Failover. Она проверяет доступность вашего сайта или сервера. Если система обнаружит неработающий IP-адрес, она выведет его из ответов DNS. Таким образом, ваш ресурс останется доступен при сбоях.

Шаг 6. Защищаемся от кибератак

По данным Curator за первые три квартала 2026 года количество DDoS-атак в России выросло на 140,7% по сравнению с прошлым годом. Злоумышленники комбинируют разные методы: изучают инфраструктуру, перегружают сервисы и пытаются использовать уязвимости. По исследованию WMX и Servicepipe 44% (почти половина!) кибератак на российские компании в первом полугодии 2026 года были многоэтапными. А для поиска уязвимостей злоумышленники уже вовсю используют ИИ.

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

Поэтому защиту нужно подбирать под конкретные угрозы: Anti-DDoS помогает сохранить доступность сервисов, антибот — ограничить вредоносную автоматическую активность, а WAF — блокировать поиск уязвимостей и попытки взломов.

Защита приложений и инфраструктуры от DDoS-атак

Сейчас большинство DDoS-атак сложные: злоумышленники одновременно используют разные методы, чтобы «положить» сервер. Но глобально все атаки можно разделить на три типа:

• Volumetric-атаки (объёмные атаки или флуд) направляют на сервер большое количество сообщений.
• Protocol-атаки используют уязвимости сетевых протоколов и могут вывести ресурс из строя точечными действиями.
• Application-атаки на уровне приложения направлены непосредственно на веб-сервис.

Наилучшую защиту от DDoS-атак обеспечивает комплексный, многовекторный подход:

• Защита работает на всех уровнях модели OSI.
• Трафик проходит через центры фильтрации, которые анализируют каждый запрос и блокируют вредоносные.
• Все запросы анализируются с помощью комплекса методов: технического, поведенческого, сигнатурного и статистического анализа.

Такой подход позволяет останавливать большинство DDoS-атак. А доступ к вашим ресурсам получают только настоящие пользователи.

Защита от ботов

Боты могут серьёзно навредить вашему бизнесу:

• Парсить данные в пользу конкурентов
• Искажать аналитику на ваших ресурсах
• Взламывать аккаунты пользователей
• Скликивать платную рекламу
• Мешать пользователям делать покупки (например, добавив все товары в корзину)

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

Приведу для примера, как работает наша защита от ботов:

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

В основе нашего решения лежат алгоритмы машинного обучения. Это позволяет определять ботов с точностью 99,99%, работать на опережение и блокировать даже неизвестные ранее атаки.

WAF

WAF (Web Application Firewall) — защитный экран для веб-приложений от взлома. Он не позволяет злоумышленникам находить уязвимости в сервисах и использовать их.

Многие межсетевые экраны работают достаточно грубо — тотально блокируют порты, адреса и протоколы, чтобы остановить вредоносный трафик. Из-за этого под раздачу могут попасть важные легитимные сервисы.

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

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

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

Шаг 7. Обеспечиваем сохранность данных и непрерывность бизнеса

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

Разберём ключевые параметры, рассчитываемые при планировании и настройке системы бэкапов.

Резервное копирование

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

Начните с плана аварийного восстановления — DRP (Disaster Recovery Plan). В нём нужно определить, какие системы восстанавливать первыми, кто за это отвечает и в каком порядке действует команда.

Для каждого критичного сервиса задайте два показателя

• RPO определяет, какие максимальные потери данных (в единицах времени) допустимы. Грубо говоря, он отвечает на вопрос, когда должно быть последнее сохранение, через какие промежутки времени делаются бэкапы.
• RTO определяет время простоя и показывает, сколько времени займет восстановление работы с момента аварии.

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

А ещё понять, где эти бэкапы будут храниться. Разумнее всего их хранить отдельно от основных данных, в надёжном хранилище, расположенном в дата-центре не ниже уровня Tier III.

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

Снапшоты

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

От бэкапов прежде всего они отличаются целью. Бэкапы создаются, чтобы данные можно было восстановить в случае потери. А снапшоты позволяют быстро откатиться к предыдущему состоянию системы, если что-то пошло не так.

Снапшоты делают перед обновлениями или любыми изменениями в сервисах.

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

Итоги: чек-лист для отказоустойчивой инфраструктуры

Главные шаги, которые помогут любому онлайн-бизнесу подготовить системы к форс-мажорам:

1. Провести стресс-тестирование, чтобы понять, какие нагрузки способны выдерживать ваши сервисы.
2. Добавить вычислительных мощностей. Если нагрузка нестабильная, можно подключить масштабируемое облако и регулировать количество мощностей в пару кликов.
3. Использовать балансировщики нагрузки, чтобы не перегружать отдельные ресурсы.
4. Подключить CDN (если у вас большая географически распределённая аудитория и бывают всплески трафика).
5. Использовать профессиональный DNS-хостинг.
6. Организовать комплексную защиту от кибератак.
7. Позаботиться о бэкапах и снапшотах.

Проверьте, всё ли вы учли, чтобы сделать ваши системы устойчивыми к атакам и сбоям.