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% на эталонном наборе вопросов, и прямо сказано, что остальное — за оператором. Хаос-тест — та же логика, применённая к инфраструктуре, а не к качеству ответов.
Что проверить у своего поставщика чат-бота
Если вы выбираете чат-бота для магазина, надёжность очереди сообщений редко попадает в список вопросов — но именно она определяет, потеряется ли подтверждение оплаты во время обычного рестарта сервера у поставщика. Три конкретных вопроса, которые стоит задать: хранятся ли сообщения персистентно, пока не подтверждена обработка, есть ли механизм повторной попытки после сбоя компонента, и проводили ли тест на реальной нагрузке с датой и цифрой — не «мы тестировали», а сколько именно запросов и какой результат.
Мы публикуем собственные замеры именно потому, что ответ «доверьтесь нам» здесь не аргумент: проверяемая цифра с датой — аргумент, обещание — нет.
