Как мы готовим проект к HighLoad: взгляд на систему до пика

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

Главное. Подготовка к HighLoad — это порядок: цель в цифрах → модель пика → карта узких мест → правки по приоритету → стресс-тест на реальных сценариях. Слои (кэш, БД, CPU) подключаем точечно, когда ясно, что именно горит.

Чем этот подход отличается от «архитектуры HighLoad»

Ответ: справочник паттернов говорит «какие слои бывают». Метод подготовки говорит «в каком порядке смотреть ваш проект, чтобы не сжечь рекламный бюджет».

Энциклопедию слоёв мы уже разобрали в архитектуре High-Load. Здесь — рабочий взгляд инженера на кабинет, портал, API или витрину до пика. Конкретика (кэш, CPU, пулы) уходит в отдельные статьи кластера и подтягивается по ссылкам.

Шаг 1. Цель нагрузки в языке бизнеса

Ответ: без цифры «сколько» подготовка превращается в галочки. Нужны целевые сценарии и пороги, которые согласованы с маркетингом и продуктом.

• Событие: акция, запуск Директа, отчётный период ЛК, выгрузка партнёров по API.
• Объём: пиковые заказы/час, одновременные сессии, RPS по ключевым URL или методам API.
• Допустимое: p95 ответа, доля 5xx, когда режем некритичные фичи (отчёты, поиск «на лету»).

«В прошлом году выдержали» — не цель. Цель звучит так: «чёрная пятница, ×5 к обычному дню, корзина+оплата p95 < 2 с, 5xx < 0,5%». Иначе непонятно, что считать победой после правок.

Шаг 2. Критичные пути, а не «весь сайт»

Ответ: падает обычно не главная, а путь денег или данных: поиск → карточка → корзина → оплата; или «войти в ЛК → сформировать отчёт → скачать».

Мы выписываем 3–7 сценариев с шагами и внешними зависимостями (эквайринг, SMS, 1С, склад). Всё остальное — второй эшелон. Нагрузочный прогон по одной красивой лендинговой странице создаёт ложное спокойствие: см. как провести стресс-тест до рекламы.

Шаг 3. Снимок системы: что уже видно без теста

Ответ: до генератора нагрузки смотрим прод-метрики и конфигурацию — часто узкое место уже кричит в графиках.

• p95/p99 ответа, доля 5xx, насыщение CPU/RAM, диск, swap.
• Пул соединений БД, медленные запросы, блокировки.
• Кэш: hit rate, stampede при протухании TTL.
• Очереди: длина, DLQ, ретраи к внешним API.
• SSR/воркеры: сколько процессов реально утилизируют ядра.

Для не-IT достаточно четырёх сигналов из мониторинга в production. Если алертов нет — сначала наблюдаемость, иначе тест покажет «упало», но не «почему».

Шаг 4. Карта узких мест и порядок правок

Ответ: правим не «всё красивое», а то, что ломает цель пика быстрее всего. Типичный порядок (уточняется замером):

1. Данные и БД — тяжёлые SELECT на горячем пути, отсутствие индексов, один master на всё чтение.
2. Синхронные внешние вызовы — оплата/SMS/1С в запросе пользователя без таймаутов и деградации.
3. Кэш и CDN — то, что можно не считать на каждый hit (витрина, сессии, агрегаты). База — в Redis и очередях.
4. CPU приложения — тяжёлый SSR, синхронные отчёты, ресайз в запросе.
5. Масштаб узлов — горизонталь, когда код уже stateless и узкое место не в одной «прожорливой» операции.

Покупать машину мощнее до карты — способ перенести потолок на два дня. Реплика vs шард — только когда упёрлись в диск/CPU одной БД после кэша и оптимизации: репликация или шардирование.

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

Шаг 5. Проверка: сценарий × целевая нагрузка

Ответ: готовность = повторный прогон на согласованных сценариях с запасом (часто ×1,5–2 к прогнозу) и понятным отчётом: где сломалось, что поменяли, что осталось риском.

Календарь «за месяц до акции» — в чеклисте пикового сезона. Цена ошибки, когда реклама крутится на 503, — в разборе рекламы и ошибки 503. Живой пример запаса прочности — 15 000 соединений на Judo Battle.

Что мы делаем в первые 1–2 недели

Ответ: фиксированный срез «понятность системы + приоритеты», а не бессрочный рефакторинг.

1. Интервью с продуктом/маркетингом: событие, цифры, недопустимый простой.
2. Разбор архитектуры as-is: приложение, БД, кэш, очереди, внешние API.
3. Снимок метрик и логов; список рисков с оценкой «вероятность × ущерб».
4. План первого инженерного среза (обычно 1–3 правки с максимальным эффектом на критичный путь).
5. Критерий приёмки: какой прогон считаем «можно лить трафик».

Дальше — либо вы закрываете срез своей командой, либо мы берём согласованный объём под ключ / как усиление. Паттерны масштабирования подключаем по необходимости из гайда по архитектуре и следующих статей кластера (CPU, пулы соединений, кэш под пик, внешние API).

Кому этот метод подходит

• B2B-кабинеты и порталы перед отчётным пиком или подключением сети партнёров.
• Витрины и SaaS перед рекламой или сезонным ×3–10.
• Команды, у которых уже есть продукт, но нет спокойной картины «где потолок».

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

Итог

Готовить проект к HighLoad — значит смотреть на систему как на цепочку ограничений, а не коллекционировать технологии. Цель → сценарии → карта узких мест → правки → проверка. Так мы снижаем риск сжечь бюджет на 503 и получаем запас прочности без лишнего зоопарка.

Если нужен разбор вашего контура до рекламы или акции — начните с нагрузочного тестирования или напишите на оценку за 1–2 недели: зафиксируем цель пика и приоритеты правок.