17 августа 2026 мы нагрузили LEO Chat тремястами запросами в секунду и принудительно убивали движок, очередь сообщений и кеш прямо во время теста. Разбираем, что именно проверяли, почему это не то же самое, что прод-нагрузка, и что показал результат.
17 августа 2026 года мы сделали с LEO Chat то, что обычно происходит с продакшн-системой только случайно: нагрузили его 300 запросами в секунду и посреди теста начали принудительно убивать процессы — движок, очередь NATS, кеш Redis. Не по очереди и аккуратно, а сигналом SIGKILL, который не даёт программе шанса корректно завершиться.
Эта статья о том, зачем мы так сделали с собственным продуктом и что именно показал результат — включая то, чего этот результат не доказывает.
Большинство тестов чат-ботов проверяют, отвечает ли бот правильно. Реже проверяют, что произойдёт, когда часть системы упадёт посреди работы — а именно это случается в проде: рестарт контейнера при деплое, сбой сети, исчерпание памяти. Вопрос не «упадёт ли компонент», а «что произойдёт с сообщением покупателя, которое именно в этот момент обрабатывалось».
Для LEO Chat этот вопрос особенно чувствителен, потому что часть сценариев — оформление заказа и подтверждение оплаты. Потерянное сообщение здесь — не неудобство, а заказ, который никто не увидел, или, хуже, оплата, подтверждение которой не дошло до покупателя.
Инструмент — k6, нагрузочный тест, который генерирует поток запросов по заданному профилю. Цель — 300 запросов в секунду, что для чат-бота означает имитацию нескольких сотен одновременных диалогов с сообщениями, идущими одно за другим.
Параллельно с нагрузкой тест принудительно убивал ключевые компоненты стека: сам движок обработки сообщений, очередь NATS (через которую сообщения передаются между сервисами) и Redis (кеш и часть состояния сессий). Убийство — не graceful shutdown, а SIGKILL: процесс исчезает мгновенно, без возможности дописать то, что недописано.
Метрика, которую считали: сколько сообщений потерялось (отправлено, но подтверждение не пришло) и сколько задвоилось (то же сообщение обработано дважды — например, заказ подтверждён два раза вместо одного).
0 потерянных и 0 задвоенных подтверждённых сообщений.
Это означает: несмотря на принудительное убийство движка, очереди и кеша под нагрузкой 300 запросов в секунду, ни одно подтверждённое сообщение не исчезло и ни одно не обработалось дважды. Технически это держится на том, что очередь NATS хранит сообщения персистентно (не только в оперативной памяти) и имеет механизм подтверждения обработки (acknowledgment) — сервис, упавший до подтверждения, не забирает сообщение из очереди навсегда, оно ждёт повторной попытки.
Это нагрузочный тест на локальном полном стеке — то есть на той же конфигурации сервисов, что и прод, но не на самом проде, не с реальным трафиком покупателей и не в условиях реальной сетевой латентности между дата-центрами. Прод-нагрузка может выявить то, чего нет в локальном тесте: специфические сетевые задержки, конкуренцию за ресурсы с другими сервисами на том же сервере, поведение под длительной, а не разовой, нагрузкой.
Это также не тест на 100% доступность: во время принудительного убийства компонента часть запросов получала задержку ответа, пока система восстанавливалась — очередь не теряла сообщения, но и не обрабатывала их мгновенно в момент сбоя. Для покупателя это означает более медленный ответ на несколько секунд, не потерянный диалог.
Большинство продуктовых страниц чат-ботов говорят о точности ответов и скорости. О поведении во время сбоя — редко, потому что это неудобная тема: показать, что система упала (даже в контролируемом тесте), значит признать, что она может упасть. Мы считаем более честным показать эту границу с датой и цифрой, чем молчать о ней или обещать «100% uptime», ничем не подкреплённые.
Этот же подход — измерять собственные границы, а не только сильные стороны — мы уже применяли к точности ответов LEO Chat: 89,7% на эталонном наборе вопросов, и прямо сказано, что остальное — за оператором. Хаос-тест — та же логика, применённая к инфраструктуре, а не к качеству ответов.
Если вы выбираете чат-бота для магазина, надёжность очереди сообщений редко попадает в список вопросов — но именно она определяет, потеряется ли подтверждение оплаты во время обычного рестарта сервера у поставщика. Три конкретных вопроса, которые стоит задать: хранятся ли сообщения персистентно, пока не подтверждена обработка, есть ли механизм повторной попытки после сбоя компонента, и проводили ли тест на реальной нагрузке с датой и цифрой — не «мы тестировали», а сколько именно запросов и какой результат.
Мы публикуем собственные замеры именно потому, что ответ «доверьтесь нам» здесь не аргумент: проверяемая цифра с датой — аргумент, обещание — нет.
Ваше мнение помогает нам создавать лучший контент
Помогите другим узнать это — поделитесь статьей в социальных сетях
Спасибо, что помогаете нам расти
Пишет о том, что делает руками: интернет-магазины на OpenCart, приложения на Next.js, интеграции и скорость сайтов. В статьях — замеры и проверки, которые читатель может повторить на своём проекте, а не общие советы. Коммерческая разработка с 2015 года.
Ответы на популярные вопросы по теме
Обычный нагрузочный тест проверяет, выдерживает ли система поток запросов. Хаос-тест добавляет к этому принудительное убийство компонентов посреди работы — не мягкое завершение, а SIGKILL, который не даёт процессу шанса корректно закрыться. Цель — проверить не скорость, а поведение во время реального сбоя.
Для чат-бота, где диалог состоит из нескольких сообщений подряд, 300 запросов в секунду означают одновременную активность нескольких сотен диалогов. Это не показатель максимальной пропускной способности системы — тест не искал предел, а проверял поведение под конкретной фиксированной нагрузкой.
Нет. Результат означает, что в этом конкретном тесте 17.08.2026, под этой конкретной нагрузкой и этими конкретными сбоями, потерь не было. Это не гарантия на все возможные условия — прод-нагрузка, сетевые задержки между дата-центрами или продолжительный, а не разовый, сбой могут показать другой результат.
Потому что принудительное убийство процессов на проде означало бы реальный сбой для реальных покупателей. Локальный стек — та же конфигурация сервисов, что и прод, но без риска для живого трафика. Это честное ограничение метода, и статья прямо об этом говорит, а не замалчивает.
Очередь NATS хранит сообщения персистентно, а не только в оперативной памяти процесса, и ждёт подтверждения (acknowledgment) обработки. Если сервис, который должен был обработать сообщение, упал до подтверждения, сообщение остаётся в очереди и обрабатывается повторно, когда сервис восстановится.
Подпишитесь на нашу рассылку и получайте полезные советы, инсайты и новости о веб-разработке, маркетинге и бизнесе.
Веб-разработка21 сентября 2026 года, в первые сутки учёта запросов по маршрутам, служебный /api/health получил 13 666 запросов — 60 % трафика приложения, и каждый шёл в общую базу. Рассказываем, какие две настройки это убрали, какую цену мы за них платим и как проверить свой healthcheck.
Веб-разработка21 сентября 2026 года проверка типов на нашем сайте показала 154 ошибки, хотя сборка каждый раз была зелёной: результат проверки просто выбрасывался. Внутри нашлись нули в статистике ссылок и в экспорте аналитики, сортировка, которая не сортировала, и тесты, которые не запускались. Рассказываем, как разбирали, что изменили и как проверить свой проект.
Веб-разработка22 сентября 2026 года мы проверили HTTPS-сертификаты на 116 сайтах, которые уже измеряли для рыночных исследований, и для 104 из них сравнили состояние с августовским. Все 116 прошли проверку, 108 стоят на 89- и 90-дневных бесплатных сертификатах, и только у одного сайта сертификат до сих пор не продлился, хотя при типичных настройках уже должен был. Разбираем замеры, границы метода и показываем, как проверить свой сайт одной командой.
