Что ломается первым при пике
Пиковая нагрузка редко роняет всю систему целиком — сначала отказывают самые узкие места. Четыре типовых: лимиты API-провайдера (запросы отбиваются с ошибкой 429), таймауты RAG-поиска по разросшейся базе (ответы приходят позже, чем клиент готов ждать), очередь колбэков и webhook'ов из CRM (интеграция копит неотработанные события) и база логов, не рассчитанная на десятикратный поток записей. Каждое узкое место находится нагрузочным тестом, а не аварией.
Архитектура, которая держит пик
- Балансировщик с очередью. Запросы не бьют напрямую в модель, а выстраиваются с приоритетами: платящий клиент важнее фонового отчёта.
- Два провайдера модели. Основной и резервный: при отказе или исчерпании лимитов трафик переключается автоматически.
- Кэш типовых ответов. До половины обращений — повторяющиеся вопросы; отдача из кэша бесплатна и мгновенна.
- Rate limiting по пользователям. Один клиент не может занять весь контур, даже если сломался его скрипт.
- Асинхронные сценарии. Тяжёлые задачи (сводные отчёты, массовая обработка документов) уходят в фоновые очереди с уведомлением о готовности.
Это и есть водораздел между MVP и промышленной системой: первая работает на среднем потоке, вторая спроектирована под пики. Подробнее — в ответе чем отличается MVP от промышленной системы.
Что считать пиком
Пик — это не абстракция, а арифметика вашего бизнеса. Типовые источники: сезонность (отчётные периоды, праздники, рассылки), начало рабочего дня с всплеском обращений в 9:00–11:00, дедлайны и рекламные кампании, после которых трафик вырастает в 2–10 раз к среднему. Паспорт нагрузки составляется до проектирования: средний поток, прогнозируемый пик, допустимое время ответа на пике, доля потерь, которую бизнес готов простить. Без паспорта нагрузочный тест меряет случайные величины.
Нагрузочное тестирование как этап приёмки
- Сценарий. Прогноз пика × 1,5 запаса; распределение по типам запросов как в жизни.
- Прогон. Ступенчатый рост нагрузки до целевой и за неё; фиксация времени первого токена, доли ошибок, длины очереди.
- Разрыв. Отдельно — поведение при отказе основного провайдера: как быстро включается резерв.
- Отчёт. Узкие места, лимиты, рекомендации; критерий приёмки — метрики на пике в границах SLA.
У промышленного контура такой тест — часть приёмки, у пилота — опция. Разница цен: пилот от 480 000 ₽ проверяет пользу, промышленный контур за 0,9–1,2 млн ₽ — ещё и надёжность. Что входит в сопровождение таких систем — ответ что входит в сопровождение ИИ-системы.
Деградация вместо отказа
Лучший контур не тот, что «не падает», а тот, что падает красиво. Лестница деградации: сначала включается кэш на типовые вопросы, затем тяжёлые сценарии переносятся в фон, затем контур переходит на более дешёвую и быструю модель для простых запросов, и только в крайнем случае клиент видит «оставьте контакт — ответим через N минут». Клиент переживает медленный ответ; не переживает потерянный. Как зафиксировать времена реакции в договоре — в ответе что такое SLA на ИИ-систему.
Мониторинг: как увидеть пик заранее
Два заблуждения мешают нормальной подготовке к пикам. Первое: «пик случится — тогда и починим». Починить под давлением упавшей очереди в три раза дороже и дольше, чем заложить очередь заранее: авралы рождают компромиссы, компромиссы — новые уязвимости. Второе: «нагрузочное тестирование — это для крупных». Ошибка масштаба: ассистент малого интернет-магазина переживает чёрную пятницу по тем же законам, что и банковский колл-центр, просто с меньшими числами. Масштаб меняет бюджет теста, а не его необходимость: паспорт нагрузки и лестница деградации стоят почти нуля при проектировании и спасают продажи в единственный важный день года.
И помните про человеческий пик: в аварию попадают не только серверы, но и дежурные. Лестница деградации должна работать даже при недоступности инженера — автоматические пороги и готовые сценарии действий вместо импровизации ночью. Автоматические пороги деградации — единственный режим, который работает в два часа ночи без человека: очередь растёт, контур сам включает кэш и упрощает ответы, а дежурный получает уведомление, а не avalanche обращений. Ночная статистика инцидентов одинакова во всех отраслях: человеческий фактор добавляет к аварии время, автоматика — экономит; поэтому зрелые контуры автоматически переключают режимы и будят людей уже готовыми данными о причине.Что писать в ТЗ на нагрузочное тестирование
Чтобы тест мерял ваше будущее, а не фантазии инженеров, в задании фиксируются шесть параметров: средний и пиковый профиль обращений (штук в минуту, по типам); целевое время ответа на пике для каждого типа; допустимая доля отказов (обычно до 1%); сценарий разрыва — поведение при отказе основного провайдера; длительность выдержки пика (минимум час — короткие всплески прощает даже слабый контур); состав отчёта — узкие места, лимиты, рекомендации. Такое ТЗ занимает страницу и превращает нагрузочное тестирование из галочки в критерий приёмки: результаты сравниваются с целями, а не с прошлым запуском. Пилот такие тесты проходит в облегчённом виде; для промышленного контура они обязательны и входят в состав работ.
Численный пример: рассылка и её последствия
Служба поддержки получает 3 000 обращений в месяц — это примерно 200 в рабочий день, в среднем один запрос каждые четыре минуты. Маркетинг запускает рассылку по базе, и в первый день приходит 1 500 дополнительных обращений, из которых 400 припадают на один час вечером. Поток за этот час — почти двухнедельная норма. Без очереди и кэша контур пытается генерировать 400 полных ответов одновременно: упирается в лимиты провайдера, часть запросов падает с ошибками, клиенты уходят. С кэшем типовых (рассылка порождает массово одинаковые вопросы) закрываются до 70% потока мгновенно; с очередью остальные 120 запросов обрабатываются за 15–20 минут с приоритетом платящих; с лестницей деградации никто не видит ошибок — только чуть более короткие ответы. Одна архитектурная разница — три разных вечера для клиента.
Чек-лист устойчивости перед запуском
- Паспорт нагрузки написан: среднее, прогноз пика, допустимое время ответа.
- Нагрузочный тест пройден на 1,5× прогноза, отчёт с узкими местами есть.
- Резервный провайдер модели подключён и проверен переключением.
- Кэш типовых ответов включён и наполнен по частым вопросам.
- Rate limiting настроен на пользователя и на сценарий.
- Тяжёлые фоновые задачи вынесены в асинхронные очереди.
- Лестница деградации описана и известна дежурной смене.
- Мониторинг показывает очередь, время ответа, ошибки и лимиты — с алертами.
Восемь пунктов — это разница между «система работает» и «система работает в чёрную пятницу». Первые пять закрываются в пилоте, последние три — атрибуты промышленного контура.
Сколько стоит устойчивость
Устойчивость — не отдельная строка сметы, а свойство архитектуры: очередь, кэш и резервный провайдер закладываются при проектировании и удорожают контур на заметную, но не драматичную долю. Платите вы в двух местах: в разработке (инженерное время на отказоустойчивые паттерны) и в эксплуатации (сопровождение с мониторингом — от 50 000 ₽/мес, контур безопасности и мониторинга — от 60 000 ₽/мес). Сравните это со стоимостью часа простоя клиентского канала — и решение о запасе прочности принимает финансист, а не инженер. Как зафиксировать эти обязательства в договоре — ответ что такое SLA на ИИ-систему.
Пик, увиденный на дашборде, — уже не авария, а план. Мониторятся: длина очереди, время ответа по ключевым сценариям, доля ошибок и кэш-попаданий, остатки лимитов провайдера. Алерты настроены на пороги до боли: очередь растёт — масштабируемся, кэш-попадание падает — обновляем базу знаний. Такое сопровождение — от 50 000 ₽/мес; контур безопасности и мониторинга — от 60 000 ₽/мес. Как строить журнал обращений для разбора инцидентов — ответ как вести логирование ИИ-системы. Развернуть устойчивый контур под ваш пик помогает разработка ИИ-ассистентов НЬЮ-ССТ и гайд как развернуть корпоративного ИИ-ассистента.