Однажды утром к нам обратился клиент: у него сработал алерт. Вместе мы начали разбираться, что произошло. Микросервис геймификации, который обычно работает на двух POD, внезапно заскейлился до десяти и не собирался масштабироваться обратно. Трафик был стабильно высоким, но ни акций, ни органического роста — ничего, что могло бы объяснить скачок.

Логи и referer были в норме — сервис работает на том же домене, что и основной продукт, поэтому выглядит как «свой» трафик. Причину мы увидели только когда сами зашли в основной продукт в меню. Там появился новый виджет с количеством попыток пользователя. Интеграцию мы согласовывали, но деталь, которая «выстрелила», в документ не попала. Виджет вызывал эндпоинт при каждой загрузке страницы, даже когда у пользователя не было наград и виджет должен был быть пустым.

Мы поставили на этот эндпоинт кеш на Cloudflare с TTL в 3 секунды, и нагрузка сразу снизилась. Это оставили как временный фикс, пока фронтенд не добавил условие «не отправлять запрос, если наград нет». Никакого инцидента на стороне пользователей не произошло — HPA отработал, а алерт пришел тогда, когда еще никому не было больно.

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

Партнер проекта?

Содержание

1 С какими пиками мы работаем
2 Что мы тестируем перед пиком
3 Подготовка к пику по дням
4 Какие метрики мы смотрим в реальном времени
5 Как система и команда реагируют на инциденты

С какими пиками мы работаем

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

крупным спортивным событиям на платформах клиентов — футбол, киберспорт, live betting;
jackpot- и bonus-кампаниям;
партнерским и реферальным акциям.

Во время популярного live-матча платформа клиента может получать около 50 000 одновременных сессий, до 10 000 RPS на API и резкие всплески write-нагрузки. Такие пики кратковременны, но очень интенсивны, поэтому мы моделируем их заранее.

Пиковые сценарии у наших клиентов всегда разные. Где-то это миллион RPS, где-то — 500 пользователей, но со сложными транзакциями. Поэтому мы не привязываемся к абстрактным цифрам и говорим о готовности системы к нагрузке, которая является предельной именно для нее.

Что мы тестируем перед пиком

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

Критичность сценариев определяем по трем факторам: бизнес-метрики, исторические данные (какие эндпоинты генерируют 70–80% реального трафика) и критичность транзакций (где потеря или дублирование запроса может стоить платформе репутации).

Из инструментов используем два:

k6 — для быстрых и повторяемых тестов, которые хорошо интегрируются в CI/CD и Grafana;
Locust — когда нужно смоделировать сложные user flow или масштабировать генерацию трафика через распределенные агенты.

Наиболее тщательно проверяем API (latency и throughput), базы данных (connections, locks, replication lag), очереди (Kafka/RabbitMQ) и интеграции, особенно с платёжными провайдерами. Причина в том, что большинство инцидентов — это цепная реакция задержек, а не падение одного сервиса.

Готовность к пику оцениваем по чётким SLO: p95 latency < 200 мс, error rate < 0,5%, CPU/RAM < 80%, throughput ≥ 80% от ожидаемого пика. Работаем через error budget, и если он исчерпан, релизы блокируются.

Есть и вещи, которые мы сознательно не тестируем, например длительные нагрузки и редкие edge-кейсы. Стоимость таких тестов не оправдывает их пользу. Вместо этого полагаемся на synthetic monitoring и production observability.

Подготовка к пику по дням

За 2–3 дня до пика

За несколько дней до пика мы запускаем финальные load-тесты на конфигурации, максимально приближенной к продакшену. Проверяем capacity: есть ли запас по ресурсам в кластере, не упираемся ли в лимиты нод. Включаем freeze на изменения — ни код, ни конфиги не деплоим без критической необходимости. Отдельно прогоняем failover-сценарии и проверяем бэкапы. Всё формализовано в runbook, потому что на этом этапе не должно быть импровизации.

Примерно за 24 часа до события

Примерно за сутки до пика мы тестируем сами алерты: действительно ли Grafana отправляет уведомления в PagerDuty, не сломался ли канал нотификаций. Просматриваем дашборды, проводим dry-run on-call, проходим escalation chain — кто кому передаёт инцидент, если primary-инженер не отвечает. Банальные вещи, но именно на них система падает в самый неподходящий момент, если их не проверить.

Последние несколько часов перед пиком

Когда до пика остаются считанные часы, наша главная задача — минимизировать количество неизвестных. DevOps в это время занимается preheat-скейлингом: заранее устанавливает минимальное количество POD на ожидаемый уровень, чтобы не ждать реакции HPA уже под нагрузкой. Эти 30–60 секунд на масштабирование в момент пика превращаются в реальные ошибки для пользователей.

Параллельно проверяем возможности масштабирования баз данных. Для Aurora это запас по классу инстансов и нагрузка на read replicas. Для Atlas — auto-scaling и лимиты тира. Лучше заранее увеличить ресурсы и снизить их позже, чем ловить деградацию под нагрузкой.

Обязательно проходимся по текущим инцидентам: незакрытые баги, нестабильные сервисы, недавние деплои, которые ещё не проверены реальным трафиком. Если что-то вызывает сомнения — откатываем или готовим план Б. И отдельно проводится финальная проверка мониторинга и алертов.

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

Что происходит в момент пика

Во время нагрузки каждый в команде знает свою зону ответственности — и именно поэтому ничего не проваливается между ролями. DevOps следят за инфраструктурой (состояние кластера, скейлинг, ресурсы), backend-команда мониторит сервисы, логи и время ответа, DBA держит руку на пульсе баз: slow queries, connection pool, репликация.

On-call организован через Grafana OnCall с ротацией primary + backup и эскалацией до Architect или CTO. Во время крупных событий дежурство удваивается: один инженер не перекрывает все риски, второй страхует первого. Коммуникация происходит в отдельном канале инцидента, куда автоматически приходят алерты и где команда в реальном времени обменивается контекстом.

Какие метрики мы смотрим в реальном времени

Во время пика у нас есть чёткая иерархия того, куда смотреть и в какой последовательности.

Первый уровень — бизнес-симптомы.
Error rate и latency на уровне API. Эти метрики первыми сигнализируют, что что-то пошло не так с точки зрения пользователя, а не инфраструктуры.

Второй уровень — базы данных.
Активные соединения, slow queries, replication lag. База первой начинает страдать под нагрузкой, а внешние симптомы появляются позже. Если ловить их только на уровне API, реакция будет запоздалой.

Третий уровень — CPU и RAM.
Важны, но скорее как индикатор для скейлинга. Поды могут потреблять 90% CPU и нормально отвечать или использовать мало ресурсов и зависать в ожидании соединения с базой. Поэтому эти метрики анализируем вместе с первыми двумя уровнями.

Инструменты, которые используем во время пика: Grafana с Prometheus как основным datasource (отдельные дашборды для API, БД и очередей), Kibana для логов, Datadog с кастомными дашбордами для бизнес-метрик.

Как система и команда реагируют на инциденты

Резервирование заложено на каждом уровне:

Kubernetes — auto-scaling подов и узлов кластера;
базы данных — Aurora с read replica и автоматическим failover, а также Atlas с replica set;
Istio — circuit breakers и retry-политики на уровне service mesh;
Cloudflare — как CDN и быстрый инструмент кэширования в экстренных случаях.

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

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

Самый быстрый инцидент мы закрыли за 4 минуты — от обращения клиента до полного решения проблемы. Во время пика зафиксировали всплеск нагрузки на API, но система быстро отреагировала: сработали circuit breaker и автоскейлинг подов. Помогли автоматизация в Istio и заранее подготовленные runbooks.

Ключевые уроки работы с highload

Мониторим бизнес-метрики, а не инфраструктуру. Раньше смотрели на CPU, RAM, количество подов — «зелёное» означало, что всё в норме. Но CPU может быть 30%, а пользователь уже не может провести оплату из-за исчерпанного connection pool. Сейчас мы алертим error rate, latency критических эндпоинтов, queue lag. Инфраструктурные метрики стали вторичными.
Performance safari. Раз в спринт разработчик проходит по метрикам своего сервиса — дашборды, логи, профили запросов — и ищет потенциальные слабые места до того, как они появятся на проде.
Во время интеграций проговариваем поведение во всех состояниях. История с виджетом геймификации в начале статьи — именно об этом. Недостаточно договориться об API — нужно проверить соответствие кода sequence-диаграммам и прогнать разные сценарии. Что происходит, если данных нет? Если фича неактивна? Если у пользователя нет доступа? Именно эти «очевидные» кейсы чаще всего и ломают систему.
Код-ревью важнее любой подготовки. Большинство проблем под нагрузкой — это не инфраструктура, а код: N+1 запросы, отсутствие индексов, запросы без таймаутов и обработки ошибок. Привычка спрашивать себя при каждом merge request «что будет при x2, x5, x10 трафике?» работает лучше любого load-теста.
Всегда должен быть быстрый путь назад. Rollback деплоя, feature flag, fallback. Highload-система — это не та, которая никогда не падает. Это та, которая предсказуемо реагирует на сбои и быстро восстанавливается.