Маркетинг согласовал акцию. Бюджет в Директе уже в календаре. IT говорит: «Потянем. В прошлом году выдержали. При необходимости докупим сервер».

В день X главная ещё открывается, а корзина и оплата отвечают ошибкой. Реклама продолжает списывать клики.

HighLoad начинается не с Kubernetes и не с «сервера за миллион». Он начинается с вопроса: какой пик вы обязаны пережить — и где система сломается первой.

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

«В прошлом году выдержали» — не план. Другой ассортимент, другой рекламный бюджет, другие виджеты, другие лимиты банка и SMS. Всё это проявляется в день X — не на планёрке за месяц.

Три ступени, в которых узнаёте себя: - Спокойствие — «потянем», цифр нет, сценариев нет, тест свежий только в памяти о прошлом сезоне - Неделя до X — срочный «посмотрите нагрузку»; успевают косметику, не карту узких мест - Утро пика — путь денег лежит, реклама крутится, поддержка в огне, потом неделю ищут виноватых

Ориентир по деньгам: → час простоя в акционный день часто 50–200+ тыс. ₽ упущенной выручки → клики на мёртвую витрину — ещё десятки–сотни тысяч ₽ плюс просадка качества объявлений на 1–3 недели → цель пика + карта узких мест + первый срез правок и прогон часто 150–500 тыс. ₽ и 2–4 недели — дешевле одного сорванного дня Порядок до рекламы (не «сервер мощнее»): → цель в цифрах: заказы/час или сессии, время ответа худших запросов, доля ошибок → 3–7 критичных путей до денег или данных (корзина/оплата, отчёт в ЛК) — не только главная → снимок метрик: часто узкое место уже видно без генератора нагрузки → карта узких мест → правки по приоритету (база и внешние вызовы раньше «красивой» архитектуры) → повторный прогон со запасом ×1,5–2 к прогнозу маркетинга

Правило: сначала измеримая боль на критичном сценарии — потом микросервисы и Kubernetes. Преждевременная enterprise-архитектура дороже часа простоя в пик и реже его предотвращает.

Семь ворот до включения рекламы: - Цель пика записана в цифрах, не как «потянем» - Есть сценарии пути денег, не только главная - Внешние зависимости (оплата, SMS, 1С) учтены - Есть снимок метрик или хотя бы наблюдаемость - Карта узких мест с приоритетом - Повторный прогон с запасом и критерий «можно лить трафик» - Маркетинг знает сигнал «стоп реклама»; есть дежурный и откат

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

Лучше сдвинуть дату или снизить бюджет, если: → цифр нет, есть только «в прошлом году выдержали» → тест падает на корзине, оплате или отчёте → фиксы не прогнали повторно → единственный админ в отпуске в день X

Сдвинуть акцию на неделю неприятно. Сжечь рекламный бюджет на недоступную витрину — обычно неприятнее.

Полный разбор — статья на сайте «Как мы готовим проект к HighLoad: взгляд на систему до пика»: https://ninelab.ru/blog/prepare-project-for-highload?utm_source=setka&utm_medium=social&utm_campaign=ninelab_setka_prepare_project_for_highload

А у вас ближайший пик уже в календаре — и сформулирована ли цель в цифрах, а не как «потянем»?

#нагрузка #highload #CTO