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% на еталонному наборі питань, і прямо сказано, що решта — за оператором. Хаос-тест — та сама логіка, застосована до інфраструктури, а не до якості відповідей.
Що з цього перевірити у свого постачальника чат-бота
Якщо ви обираєте чат-бота для магазину, надійність черги повідомлень рідко потрапляє в список питань — але саме вона визначає, чи загубиться підтвердження оплати під час звичайного рестарту сервера постачальника. Три конкретні питання, які варто поставити: чи зберігаються повідомлення персистентно, поки не підтверджено обробку, чи є механізм повторної спроби після збою компонента, і чи проводили тест на реальному навантаженні з датою й цифрою — не «ми тестували», а скільки саме запитів і який результат.
Ми публікуємо власні заміри саме тому, що відповідь «довіртеся нам» тут не аргумент: перевірна цифра з датою — аргумент, обіцянка — ні.
