Елизавета Акманова
Ведущий аналитик
Хабравчане, всех рада приветствовать! Меня зовут Акманова Елизавета, я ведущий аналитик ГК «Юзтех». В своих статьях я стараюсь затрагивать темы, которые считаю важными, и обязательно с опорой на личный практический опыт.
Признаюсь, к этой статье я шла долго и это волнительно для меня. Вот почему.
ДИСКЛЕЙМЕР
Данная статья отражает личный опыт автора и не претендует на статус эталонного или единственно верного решения. Некоторые моменты могут вызывать несогласие или внутреннее сопротивление, это совершенно нормально. Я описываю конкретную ситуацию, сложившуюся в моей команде в рамках одного проекта. Это довольно специфический кейс, который не обязательно окажется применим в других условиях. Однако для нас он оказался полезным, и я не утверждаю, что так должно быть у всех. Моя цель — просто показать один из возможных вариантов развития событий. Возможно, наше решение совсем не идеально и не безупречно, но оно помогло нам улучшить ситуацию. Поэтому, пожалуйста, не торопитесь с критикой, будет здорово, если просто поддержите.
Надеюсь, это небольшое предисловие поможет настроиться на нужный лад.
Из названия статьи, уже понятно: мы дошли до того, что аналитики начали заниматься нагрузочным тестированием. Более того, они проводят его на этапе обследования, когда ещё не написано ни одной строки кода. О том, как мы к этому пришли, почему эту роль взяли на себя именно аналитики и какие инструменты нам помогают, я и расскажу.
Предыстория
В одной из компаний была собрана команда разработки из 20 человек (4 аналитика, дизайнер, 8 разработчиков, 2 тестировщика, а также владелец продукта и другие) для реализации проекта по импортозамещению системы управления взаимоотношениями с клиентами (CRM). Система была масштабной, стек технологий сложным, а сроки жёсткие: всего восемь месяцев. Как команда прожила этот период — тема для отдельной статьи, сейчас не об этом.
Итак, установленный срок прошёл, система была готова. В один момент отключили фронты старой системы, всех пользователей пересадили на новое решение. Именно на этом этапе мы обнаружили, что база данных начала задыхаться. 99,1% процессорного времени уходило на выполнение полезных операций, API запрос на получение одной записи по идентификатору длился 1.5 минуты, пользователи ждали загрузки простой страницы очень долго, а иногда страницы не открывались вовсе. В какой-то момент наши фронты тоже “потухли”.
Уязвимость нашли и устранили, через пару часов пользователи продолжили работу в системе, но уже с ограниченной функциональностью. Причина была в избыточно широком наборе фильтров: при определённых параметрах пользователи могли выгрузить около пяти миллионов записей вместе с файлами. Достаточно было пары таких запросов, чтобы база легла. Но убирать фильтры навсегда было нельзя, без них пользователи не могли работать полноценно.
И вот здесь началось самое интересное.
Как это на нас повлияло
При реализации системы мы упустили огромный пласт нефункциональных требований, в частности, требования к нагрузке. Я не зря акцентировала внимание на составе команды: тестировщиков было мало, один из них занимался исключительно ручным тестированием и физически они не успевали качественно проверить все задачи, которые генерировали 8 разработчиков. Проверка заканчивалась на функциональности, а остальные аспекты оставались без внимания. Да и сами аналитики не закладывали в требования моменты, связанные с нагрузкой.
Ситуацию нужно было исправлять. Фильтры предстояло открыть пользователям, но в каком виде?
Как-то раз ко мне подошёл тестировщик и показал интересный инструмент с открытым исходным кодом Gatling, предназначенный для нагрузочного тестирования.
Принцип работы:
На вход подаётся HAR-файл. Это JSON-файл, содержащий подробный журнал сетевого взаимодействия между фронтом и бэком. Он фиксирует все HTTP-запросы и ответы.
На его основе генерируется нагрузочный скрипт.
Остаётся скорректировать несколько параметров: подставить авторизационные ключи, при необходимости поправить запросы, а также настроить параметры нагрузки (количество сессий и продолжительность теста).
Оставалось понять, где взять HAR-файл. Мы открывали консоль разработчика прямо в интерфейсе, выполняли нужную последовательность действий и выгружали её в формате HAR. Запросы были с хардкодными фильтрами, но мы вручную их могли корректировать уже в самом скрипте.
Мы подставляли ту самую комбинацию запросов, которую нужно было протестировать. В итоге получалась симуляция поведения пользователей в нескольких сессиях. А по завершении работы скрипта формировался детализированный отчёт по нагрузке. Выглядел он следующим образом:
Здесь представлены такие показатели, как:
общее количество запросов с группировкой по задержкам;
группировка одинаковых запросов с детализацией задержки на разных процентилях;
информация по каждому запросу (на скриншот не попала, но находится ниже по отчёту);
информация по количеству сессий.
На основе этих данных мы могли принимать решение: можно ли открыть {вот такие} фильтры для N пользователей? Могла сделать определенный набор обязательными, могли запрещать определенные комбинации и тд.
Важно: бэкенд представлял собой репозиторий с CRUDL-операциями, поэтому всегда был готов к доработкам. Наша задача сводилась к проверке возможности открыть фильтры на фронте для конечных пользователей и не положить этими запросами базу.
Зачем все это?
Итак, я рассказала, как мы проводим нагрузочное тестирование ещё до начала разработки, и делают это аналитики на этапе обследования системы. Но зачем? Ведь для этого есть тестировщики, можно привлекать их.
Я снова напомню: их всего двое. Если мы начнём загружать коллег дополнительной работой на ещё более ранних этапах, они могут просто не выдержать такого объёма. К тому же для аналитиков это ещё и возможность проверить, насколько их задача вообще реализуема (в терминах smArt).
Очень часто бизнес приходит с идеями, которые нужно проверить. Например: «хотим внедрить кластерных сотрудников, которые будут отвечать за группу из N операторов». Мы, аналитики, собираем информацию: сколько новых сотрудников, какие кластеры. А после нагрузочных тестов можем принять взвешенное решение:
Да, мы выдержим новых сотрудников с таким набором кластеров.
Да, выдержим, но наборы кластеров нужно уменьшить, потому что выборка слишком большая.
Нет, такие изменения нельзя внедрять быстро — придётся уйти в длинную историю с оптимизацией, и только после этого станет возможно.
Заключение
Вот такая история. Теперь вы знаете ещё один кейс из практики аналитика — возможно, не самый идеальный, но точно честный и прожитый. Мы нашли способ справиться с реальной проблемой в условиях жёстких сроков, ограниченных ресурсов и высокой ответственности перед бизнесом.
Нам помогло то, что мы перестали ждать, пока кто-то другой решит нашу проблему, и взяли инструмент в свои руки. Нам помогло то, что мы начали задавать вопросы о нагрузке на этапе, когда ещё ничего не написано. Нам помогло то, что мы научились превращать гипотезы в измеримые данные, а данные в аргументы для принятия решений.
Делитесь вашим опытом, был ли у вас такой опыт?
Удачных вам проектов и стабильных продов!