Как обеспечить готовность ИТ-инфраструктуры к сезонным пиковым нагрузкам

«Жаркий сезон» — это время больших доходов для бизнеса и большого стресса для ИТ-команд. Разбираем анатомию подготовки к пиковым нагрузкам вместе с Александром Лактионовым, руководителем проектов компании «ИнфраМенеджер».

Содержание

С чего начинается высокий сезон для ИТ-директора? За сколько месяцев до фактического пика нагрузки стартует подготовка?

Подготовка к новому «жаркому сезону» начинается сразу после окончания предыдущего. В январе, когда стихают новогодние распродажи, проводится детальный post-mortem (разбор полетов). Фиксируются все инциденты и узкие места, где инфраструктура трещала по швам. На основе этого формируется бэклог архитектурных и инфраструктурных задач на год.

Если говорить об активной фазе подготовки к конкретному пику (например, к черной пятнице), то за полгода до часа Х начинается планирование мощностей, утверждается ИТ-бюджет под масштабирование и проводится аудит архитектурных ограничений. За 2–3 месяца начинаются первые стресс-тесты, а за месяц до пика стартуют учения и финальная заморозка релизов, чтобы никакие новые фичи не обрушили прод в неподходящий момент.

Как прогнозировать нагрузку? На какие исторические данные, бизнес-метрики и маркетинговые планы надо опираться?

Прогнозирование — это всегда стык математики, аналитики и бизнеса. Нельзя просто посмотреть в монитор и почувствовать нагрузку. Мы строим модель, опираясь на три слоя данных: исторические профили, бизнес-метрики и цели, маркетинговые планы.

Берем графики прошлого года (RPS — запросов в секунду, потребление CPU/RAM, количество коннектов к БД) и накладываем на них базовый органический рост проекта. Например, ваша аудитория за год выросла на 30% — значит, базовая линия тоже сдвигается.

Бизнес всегда ставит цели в деньгах и пользователях. Если в прошлом году вы сделали X выручки при Y активных пользователей, а в этом году цель по выручке — X*1.5, то вы должны понимать, за счет чего это будет достигнуто: за счет роста конверсии, увеличения среднего чека или кратно большего притока трафика?

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

Где чаще всего возникают узкие места при кратном росте трафика?

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

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

Платежные шлюзы, API служб доставки, сервисы скоринга, SMS-шлюзы имеют жесткие лимиты на количество запросов. При пике вы можете просто положить партнера или получить от него бан.

Иногда лимиты упираются не в серверы, а в количество открытых TCP-сессий на фаерволах или пропускную способность каналов.

Что делать, если маркетинг запускает непредвиденную акцию, на которую инфраструктура не рассчитана?

Бороться с этим нужно не в момент запуска акции, а заранее, закладывая архитектурные страховочные механизмы. Например, настраивать автоскейлинг не ровно под рассчитанный пик, а с запасом (+40-50% сверху), чтобы система могла переварить внезапную волну.

Механизм плавной деградации — ваше главное оружие. Если вы видите, что база данных задыхается, вы должны уметь программно отключать необязательные тяжелые функции. Например, блок «Похожие товары», персональные рекомендации, сложные фильтры или отзывы. Вы жертвуете частью UX, но сохраняете возможность пользователю положить товар в корзину и оплатить его.

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

Пиковые нагрузки — это всегда стресс и ночные дежурства. Как бороться с выгоранием команды и мотивировать инженеров в этот период?

Ночные ручные дежурства, когда инженер сидит и смотрит в графики — это антикейс. Инциденты должны триггериться автоматически, а типовые действия (например, перезапуск зависшего пода или очистка очереди) описываться в виде Runbooks, которые может выполнить дежурный первой линии или бот.

Никто не должен дежурить несколько ночей подряд. Используйте скользящий график с обязательными отгулами после ночных смен. Если человек поднял упавший сервис в 4 утра, в 10 утра его уже не должно быть на созвоне.

Высокий сезон — это сверхнагрузка, и она должна оплачиваться. Инженеры должны видеть, что их вклад очень важен для бизнеса.

Какие метрики объективно показывают, что ИТ-инфраструктура успешно пережила высокий сезон?

Метрики успеха делятся на три категории: технические, финансовые и бизнесовые.

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

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

Но самое главное — это бизнесовые метрики. Во-первых, конверсия: если в моменты пиковой нагрузки воронка продаж не сузилась и пользователи спокойно доходили до оплаты, значит, ИТ справился со своей задачей. И вторая, итоговая метрика — упущенная выгода. Если ИТ-отдел не стал причиной того, что компания недополучила выручку, значит, высокий сезон пройден успешно.

64

Время прочтения:

7 минут