Нагрузочная репетиция регистрации: как проверить check-in

Практический план приёмки регистрации под нагрузкой: пиковые сценарии, безопасные данные, резерв, критерии PASS/FAIL и отчёт подрядчика.

Что должна доказать нагрузочная репетиция?

Нагрузочная репетиция регистрации должна показать, что весь путь гостя работает при реальном потоке: запись находится, QR-код считывается, статус меняется один раз, бейдж печатается, а результат виден на соседних рабочих местах. Здесь check-in - это поиск записи и фиксация прихода гостя. Успешный ответ отдельной формы или звуковой сигнал сканера ещё не доказывают готовность всего процесса.

Мы в «Авентуре» сначала определяем границы проверки. Гость предъявляет приглашение или просит найти запись. Система проверяет статус, фиксирует приход и передаёт данные на печать.

Оператор получает понятное подтверждение. В карту зависимостей также входят внешние сервисы.

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

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

Пиковый поток в терминах заказчика

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

Для организации конференции полезно собрать расписание транспорта, начало пленарной части, доступ в секции и правила выдачи материалов. Автобус или окончание общего блока создают ступеньку спроса. Гости продолжают подходить, даже когда предыдущие операции уже замедлились.

Минимальная модель содержит:

• число ожидаемых гостей по временным окнам;
• долю QR, ручного поиска и гостей без предварительной записи;
• число входов, стоек, сканеров и принтеров;
• долю повторных сканирований и перепечаток;
• поздние изменения статуса или категории;
• зависимости от сети, почты, SMS и внешних баз.

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

Какие операции включить в сценарий?

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

Мы собираем маршрут так:

1. Гость предъявляет QR-код или называет данные для поиска.
2. Оператор находит одну правильную запись.
3. Система проверяет текущий статус и права доступа.
4. Check-in меняет статус ровно один раз.
5. Принтер выдаёт бейдж с актуальной категорией.
6. Соседняя стойка видит изменение без ручного обновления данных.
7. Итоговая выгрузка содержит одну подтверждённую отметку.

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

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

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

Практические разборы подготовки площадки и работы команды мы также публикуем в Telegram-канале «Авентуры».

Три режима прогона

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

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

Один режим показывает реакцию на внезапный наплыв, другой ищет предел. Рабочий прогон подтверждает конкретный сценарий мероприятия.

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

Как подготовить безопасные тестовые данные?

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

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

Набор готовят по шагам:

1. Определяют поля и статусы, которые реально участвуют в check-in.
2. Создают синтетические записи нужных категорий и распределения.
3. Отдельно помечают записи для повторного QR, позднего изменения и перепечатки.
4. Ограничивают доступы операторов и наблюдателей тестовыми ролями.
5. Блокируют отправку писем и сообщений реальным адресатам.
6. Назначают срок удаления записей, логов и выгрузок после приёмки.

Юридические требования к форме и согласиям нужно проверять отдельно. Для этого есть материал про форму регистрации по 152-ФЗ. В нагрузочной репетиции мы проверяем уже утверждённую схему данных. Состав тестовых записей, доступы, журналирование и сроки хранения согласуют с ответственным за персональные данные или юристом.

Критерии «пройдено / не пройдено» (PASS/FAIL) до запуска

PASS/FAIL означает «пройдено / не пройдено» по заранее записанному критерию. Запишите критерии приёмки до теста и свяжите их с обещанным маршрутом гостя. Универсальной нормы задержки или числа операций нет. Команда проекта задаёт допустимый поток, ошибки, время обслуживания и правила остановки, а затем сравнивает с ними фактический результат без корректировки порогов задним числом.

Пороговые условия k6 автоматически отмечают, пройден ли критерий для метрики. Конкретные значения из документации нельзя переносить в проект как норматив. Их определяют владелец системы, заказчик и операционная команда с учётом допустимой очереди и обещанного сервиса.

Особый критерий касается генератора нагрузки. Если запланированные операции не были запущены, отчёт описывает меньший поток, чем заявлено. Метрика dropped_iterations помогает отделить деградацию тестируемой системы от нехватки ресурсов или неверной настройки самого генератора.

Что ломать во время репетиции?

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

Полезный набор отказов:

• медленная или кратковременно недоступная сеть;
• отказ одного сканера или принтера;
• потерянный ответ после фактически выполненного check-in;
• ответ HTTP «Слишком много запросов» с указанием паузы до повтора;
• недоступная внешняя база или сервис печати;
• повторное нажатие оператором из-за неясного статуса;
• восстановление зависимости после ручных отметок.

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

Сетевую часть лучше согласовать с владельцем инфраструктуры площадки. Статья про гостевой Wi-Fi на конференции объясняет, почему служебную регистрацию нельзя оценивать одним общим тестом скорости вместе с гостевым трафиком.

Стойки, QR-коды и обратная связь

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

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

В нашем сценарии мы проверяем шесть различимых состояний: «код считан», «идёт проверка», «вход подтверждён», «уже отмечен», «запись не найдена» и «нет связи». Руководство W3C по статусным сообщениям требует, чтобы изменение состояния можно было определить программно без принудительного переноса фокуса. Для стойки это ещё и вопрос скорости обучения персонала.

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

Как проверить резерв и восстановление?

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

Сценарий восстановления проходит так:

1. Руководитель прогона объявляет отказ выбранной зависимости.
2. Команда фиксирует время обнаружения и видимый симптом.
3. Старший регистрации даёт одну согласованную команду переключения.
4. Операторы продолжают вход по резервному маршруту.
5. Наблюдатель фиксирует ручные и локальные отметки.
6. Основной сервис возвращают по согласованному порядку.
7. Данные сверяют, конфликты разбирают, итоговую версию подтверждают.

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

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

Отчёт подрядчика после прогона

Отчёт должен показывать фактически созданную нагрузку и результат каждой бизнес-операции. Отдельно указывают ограничения и ответственных за исправления. Одного графика средней задержки недостаточно.

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

В отчёт включают:

• версию системы и сценария;
• версию тестовых данных и оборудования;
• плановый профиль начала операций;
• фактически созданный профиль;
• результаты каждой отдельной операции;
• ошибки и тайм-ауты;
• ответы «Слишком много запросов» и поведение повторов;
• dropped_iterations и ресурсы генератора;
• полное время обслуживания на рабочем месте;
• очередь печати и случаи повторной выдачи;
• результат переключения на резерв и восстановления;
• список дефектов, ответственных и критериев повторной проверки.

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

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

Сообщение «исправлено» не закрывает замечание. Команда повторяет тот же сценарий с сопоставимыми исходными условиями. Если результат изменился, в отчёте появляется новый PASS. Если нет, дефект остаётся открытым или принимается как явно согласованное ограничение.

Чек-лист приёмки для заказчика

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

1. Описаны окна прибытия, входы и состав операций.
2. Базовый прогон каждого маршрута завершён до большой нагрузки.
3. Ожидаемый поток и резкий всплеск проведены отдельно.
4. Фактическая интенсивность совпадает с планом либо расхождение объяснено.
5. Успешный QR заканчивается одной правильной отметкой.
6. Повтор после тайм-аута не создаёт дубль.
7. Печать проверена на реальных принтерах и расходниках.
8. Ручные случаи идут в отдельную линию и не блокируют основной поток.
9. Операторы видят понятные статусы и следующее действие.
10. Использованы синтетические данные с ограниченными доступами.
11. Отказ зависимости и восстановление пройдены на практике.
12. Каждый критичный дефект повторно проверен после исправления.

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

Приёмка должна охватить весь путь гостя под реальным потоком, при сбое и после восстановления. Отдельный сканер или форма не дают полной картины.

Источники

• Grafana k6: типы нагрузочного тестирования
• Grafana k6: критерии thresholds
• Grafana k6: dropped iterations
• Microsoft Azure Architecture Center: Retry Storm antipattern
• Microsoft Azure Architecture Center: Retry pattern
• Zebra DataWedge: barcode input and feedback
• GS1: руководство по качеству и читаемости двумерных кодов
• IETF RFC 6585: HTTP 429 Too Many Requests
• W3C WCAG 2.2: Status Messages
• Федеральный закон № 152-ФЗ: принципы обработки персональных данных