День старта потока: как проверяют под нагрузкой сайт, кабинет и портал записи

Есть системы, у которых год состоит из одного дня. Открытие продаж коллекции в интернет-магазине. Старт набора, когда онлайн-школа открывает запись и расписание. Первый день приёма заявок в клиентском кабинете или в портале записи. В такой день приходит аудитория, сопоставимая с месячной, и приходит она в течение часа после рассылки.

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

Отчёт «система доступна, отказов нет» обычно правдив и обычно бесполезен: доступность — слабое требование. Пользователь в это время видит другое.

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

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

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

Профиль собирается из трёх величин, и все три знает заказчик, а не подрядчик. Сколько людей приходит в самую плотную минуту — это следует из размера рассылки, доли открытий в первый час и включённой в этот день рекламы. Что они делают — не «заходят на сайт», а последовательность: открыл письмо, попал на страницу, авторизовался, нашёл нужное, оформил, заплатил. И в какой пропорции расходятся по сценариям.

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

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

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

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

Третье — точка, после которой система перестаёт отвечать и не возвращается сама; её ищут отдельным прогоном, поднимая нагрузку до отказа намеренно. Число нужно не ради рекорда: если точка отказа близка к ожидаемому пику, план старта меняют, а не надеются.

Четвёртое, и на практике самое важное, — что происходит после снятия нагрузки. Система, которая тормозила в пик и через пять минут вернулась к норме, день старта переживает. Система, которая осталась в плохом состоянии и требует ручного вмешательства, превращает пиковый час в испорченный вечер: нагрузка уже спала, а заказы всё ещё не проходят.

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

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

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

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

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

Grande Boutique — сеть мультибрендовых магазинов из Уфы, работающая больше двух десятилетий; ассортимент — свыше 35 000 наименований премиальных брендов. Мы перезапускали сайт: новый технический стек, обмен со складом, маркетинговые инструменты, CRM.

Для разговора о пике здесь важны две вещи, обе из кейса. Первая: практически по каждой из 35 000 позиций ежедневно идёт обмен — меняются цена, остаток, наличие в магазинах, и информация о наличии обновляется в режиме реального времени, чтобы покупатель не заказал то, чего на складе уже нет. То есть в пиковый час система занята не только посетителями: параллельно по ней идёт поток изменений, и оба потока борются за одни и те же данные.

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

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

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

Первое — технические меры, которые делаются за дни. Отдавать одинаковые для всех страницы из кэша, а не собирать каждую заново. Вынести отложимое в очередь. Выключить на время пика второстепенное: рекомендательные блоки, живые счётчики, подробную аналитику в админке.

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

Третье — пересмотр требований: в пик показываем не точный остаток по каждому магазину, а общее наличие с отметкой времени; в первый час личный раздел работает в сокращённом виде. Это осознанный размен, и принимают его заранее, а не когда всё уже легло.

Академия дополнительного профессионального образования EDPRO входит в топ-3 сегмента в России: более 10 000 выпускников, общая аудитория продуктов — более 150 000 человек. Платформа уже работала на вебе, и мы спроектировали и разработали мобильное приложение для iOS и Android.

В кейсе есть деталь, которая объясняет природу пика в обучении. Расписание в приложении синхронизируется с системой академии, и любые изменения — перенос лекции, новый материал — отражаются сразу; есть роли студента, преподавателя и администратора, у каждой свой доступ. Это значит, что нагрузка приходит не только снаружи: расписание меняет академия, а последствия этого изменения разъезжаются по всем, кто в этот момент в приложении.

Вторая деталь — требование работать при нестабильном интернете. Для разговора о пике она важнее, чем кажется: пользователь в дороге и пользователь в перегруженной системе видят одно и то же — долгий ответ.

Из опубликованных результатов: более тысячи установок в первые месяцы и оценка 4,4 в App Store. Нагрузочных замеров в кейсе нет, и выдавать за них эти числа мы не станем.

Будем честны по границам метода. Прогон воспроизводит сценарии, которые вы назвали, и не воспроизводит поведение живых людей: человек жмёт кнопку трижды, открывает восемь вкладок, возвращается назад в середине оплаты. Часть дефектов видна только на настоящем потоке.

Прогон делается на копии, а копия никогда не равна боевой системе: другие объёмы истории, другой набор данных, прогретые кэши. Результат «на стенде держит столько-то» не переносится на бой один в один — он показывает узкие места, а не даёт гарантию.

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

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

По ответам на эти вопросы видно, делал человек такую работу или рассказывает про неё.

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

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

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

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