Чёрная пятница каждый день: как облако выживает под пиковой нагрузкой

Для интернет-ритейла и финансовых сервисов «Чёрная пятница» – не просто акция, это стресс-тест для всей инфраструктуры. Один сбой в пиковый час способен обнулить выручку за несколько дней. Тимур Чубарин, генеральный директор mt cloud, объясняет, почему к распродажам нельзя готовиться в последний момент – и что на самом деле ломается под нагрузкой.

Железо дорожает, облако выигрывает

Российский рынок IaaS продолжает расти. В 2026 году акценты среди драйверов сместились. Один из значительных – резкий рост стоимости оборудования. Серверы, компоненты для инфраструктуры, оперативная память – всё подорожало кратно. При таком раскладе модель «купить своё железо» становится не просто дорогой, но и рисковой по затратам: многие компании стремятся избегать крупных капитальных вложений в инфраструктуру, особенно когда цены продолжают расти, а прежний трёхлетний горизонт планирования оказывается слишком длинным – компании рассматривают более краткосрочные сценарии.

Три года назад обычной практикой было сравнить аренду сервисов с покупкой оборудования и заложить мощности с запасом на 2-3 года. Сейчас подход изменился: проверить гипотезу за год, платя провайдерам условно миллион в месяц, и уже после успешного запуска сравнивать аренду с закупкой, а не тратить 30–40 миллионов на железо на этапе проверки гипотезы.

Отдельную роль играют регуляторные требования в области информационной безопасности. Соответствие 152-ФЗ и другим нормам требует не только лицензий и оборудования, но и длительного процесса внедрения и найма специалистов. Облачный провайдер снимает эту головную боль: не нужно самому собирать команду, внедрять средства защиты и месяцами ждать, пока всё заработает. Берёшь уже готовую аттестованную инфраструктуру с мониторингом событий безопасности и защитой веб-приложений в комплекте – и сразу начинаешь работать, а не настраивать.

Дешёвое облако – опасная иллюзия

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

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

Система рушится не от нехватки серверов

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

Нередко сетевую инфраструктуру строят в связке с СХД, и именно это становится узким местом при пиковом трафике. Когда IOPS и объём передаваемых данных резко растут, общая шина между вычислительным слоем, сетью и хранилищем начинает «душить» систему. Серверов формально достаточно – но данные не успевают двигаться с нужной скоростью, и пользователь может увидеть таймауты.

В mt cloud мы изначально закладываем достаточную пропускную способность между вычислительным слоем, сетью и хранилищем, без переподписки на ресурсы. Сетевые пути резервируются, контуры сегментируются – чтобы всплеск в одном месте не тянул за собой всё остальное. При этом широкий канал сам по себе не спасает: важен не только объём, но и характер трафика. DDoS-атака специальными запросами может перегрузить приложение или базу данных, даже не исчерпывая пропускную способность канала. Поэтому защита периметра – такая же часть архитектуры, как и всё остальное. Отдельно следим за тем, чтобы оборудование было современным и находилось на поддержке: это снижает риск отказов и даёт более высокий и предсказуемый уровень производительности по CPU, памяти, дискам и сети. При пиковой нагрузки этот подход даёт продажу нашему клиенту, а не таймаут.

ИБ – не надстройка, а фундамент

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

Подготовка к «Чёрной пятнице» в части информационной безопасности не начинается за неделю до события. Мониторинг событий безопасности работает в режиме 24/7 в течение всего года, тестирование средств защиты и команд реагирования проводится регулярно. Попытки атак могут случиться в любой период, и нередко начинаются за несколько дней до значимого события – именно поэтому защиту нельзя мобилизовать только под конкретную дату, защита должна быть постоянно, а не временной.

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

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

DR-сценарий – не роскошь, а страховка

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

Если система не выдержала нагрузку или стала жертвой атаки, должна быть возможность быстро переключиться на резервную площадку. Но работающей считается только та DR-инфраструктура, которую периодически проверяют в деле: каналы передачи данных, сетевая архитектура, средства защиты. Просто иметь резервную площадку недостаточно – она должна быть готова подхватить нагрузку в течение минут, а не часов.

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

Что проверить до начала сезона

Логика подготовки к пиковым нагрузкам одна: заранее, а не накануне. Анализ нагрузочного профиля клиента, проверка готовности инфраструктуры и аудит безопасности – всё это работает только как плановая, а не экстренная работа.

ЛПР, которые готовятся к высокому сезону, нередко концентрируются исключительно на вычислительных мощностях и упускают несколько критичных вещей. Первое – архитектурная готовность к масштабированию: система должна уметь обрабатывать кратный рост трафика без структурных сбоев. Второе – информационная безопасность как неотъемлемая часть подготовки, а не отдельная задача на потом. Третье – рабочий и протестированный DR-сценарий с понятным временем восстановления.

Облако, которое выдерживает «Чёрную пятницу» без инцидентов, строится не в октябре. Оно строится каждый день.