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

Кто-то «закальцинировался» и не хочет пробовать новое, кто-то опасается ошибок, которые может допустить модель, и которые незаметно уйдут в продакшн, а кто-то разочаровался после неудачных попыток решить более комплексные задачи с помощью модели.

И если с первой проблемой можно справиться волевым усилием и положительным примером, то вторая и третья решаются качественным ревью, высокой квалификацией специалиста и хорошо структурированным кодом. Об этом чуть подробнее.

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

• Насколько корректно и оптимально настроены все модули системы?
• Где порог отказоустойчивости наших сервисов и сторонних компонентов, используемых в решении?
• Что именно мы можем гарантировать потребителю при различных условиях эксплуатации?
• Сможем ли мы выдержать повышенные нагрузки - и если да, то какие именно?

Ответить на эти вопросы помогают нагрузочные тесты. В статье рассмотрены ключевые идеи подхода к их реализации: какие тесты запускать, когда и где это делать, кто несёт ответственность за их написание и на что стоит обратить внимание при анализе результатов.