Как проверить CRM перед десятикратным ростом нагрузки

Перед крупной распродажей команда проверяет, выдержит ли сайт посетителей. CRM нередко остаётся за рамками испытания: «письма можно отправить позже». Но позже могут устареть корзины и предложения, а задержка покупок приведёт к сообщениям уже купившим клиентам.

Нагрузочное испытание CRM проверяет весь путь от события до допустимого действия. Пропускная способность — сколько операций система устойчиво обрабатывает за время. Задержка — сколько конкретная операция ждёт результата. Эти показатели связаны, но высокий объём обработки не гарантирует своевременности критичного сообщения.

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

Составьте реалистичную модель нагрузки

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

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

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

Задайте критерии клиентского результата

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

Не позволяйте генератору скрыть перегрузку

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

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

Убедитесь, что сам генератор имеет достаточно ресурсов. Если он не сумел создать заданный поток, успешный результат теста ничего не говорит о работе на требуемом объёме.

Условный расчёт накопления

Предположим, во время пика приходят 1 000 событий в секунду, а участок устойчиво обрабатывает 800. Разница 200 событий каждую секунду накапливается в очереди. За десять минут добавится 120 тысяч записей.

После пика входящий поток снижается до 200 в секунду, обработка остаётся 800. На сокращение накопления доступно 600 в секунду; при этих упрощённых условиях понадобится 200 секунд. Если одновременно запускаются повторы и тяжёлый пересчёт сегментов, фактическое восстановление займёт больше времени.

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

Проверьте внешние ограничения

У платформы, SMS-провайдера, сервиса рекомендаций и каталога могут быть разные квоты. API — интерфейс обмена между системами; его ограничение может выражаться в запросах, записях, параллельных соединениях или объёме данных.

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

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

Испытайте управляемое ухудшение

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

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

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

Проверьте ограничения по отдельным клиентам

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

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

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

Оформите пределы готовности

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

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

Источники

Grafana Labs. Open and closed models. Документация k6. Раздел Drawbacks of using the closed model. Проверено 22.09.2026.