Команда нагрузочного тестирования? Дайте две! Почему иногда подрядчик бонусом к внутренней команде — это хорошая идея
Привет! Меня зовут Юля Шамина, я руководитель IT-проектов в СберМаркете. Хочу поделиться нестандартным по всем меркам кейсом, как мы подготовили наши сервисы к высоким предновогодним нагрузкам за 3 месяца благодаря челленджу внутренней команды нагрузочного тестирования.
Эта статья не про успешный успех, а про то, как и зачем привлекать подрядчика, если вопросом уже занимается внутренняя команда. А ещё про страх неизвестности, мучительную настройку процессов и то, как в конце концов показать высокие результаты в сжатые сроки с минимальным количеством факапов.
Если бы можно было описать этот проект одной цитатой — «Это было смело, чертовски смело!»
А теперь по порядку. Расскажу, как мы пришли к тому, что нам понадобился подрядчик, и что вообще это за проект.
Предпосылки
Сбермаркет — высоконагруженный e-commerce сервис, №1 на рынке e-grocery. Одна из наших главных целей — это стабильность в работе систем.
За последний год наши нагрузки выросли в 2 раза, а по потреблению инфраструктуры с 2019 года — в 77 раз. Мы собираем с наших сервисов более 2 миллионов метрик в секунду, и эта цифра постоянно растет. На данный момент наш пик — 115k RPS.
Особенность бизнеса — сезонность, ярко проявляющаяся в периоды значительных маркетинговых акций и праздников, например, на Черную пятницу или Новый год. В это время из-за акций и скидок трафик на наших сервисах резко растет, а объем заказов кратно увеличивается.
Подробнее об этом феномене высокого сезона в e-com мои коллеги рассказывали в подкасте «Для tech и этих».
Системы СберМаркета. Вот они все, слева направо…
Заказ в СберМаркете можно оформить на сайте или в приложении. Но это, конечно, только вершина айсберга. У нас есть:
Витрина B2C — веб-версия и приложение;
Витрина B2B — веб-версия и приложение;
RTE (Ready To Eat) — раздел с заказом готовой еды из ресторанов;
ShopperApp и VendorApp — приложения для сборщиков и курьеров Сбермаркет.
Ключевым фокусом IT-команды на 2023 год стала надежность систем. Мы наметили векторы для работы, одним из которых было полноценное покрытие всех наших систем нагрузочными тестами. Мы поняли, что хотим усилить внутреннюю экспертизу в области нагрузочного тестирования, изменить стратегию и перейти на новый технологический стек.
У нас внутри уже существовала отдельная команда, занимающаяся нагрузочными тестами. Но мы оценили риски и поняли, что работы много и мы можем не успеть реализовать весь план текущим составом. У нас не было возможности рисковать подготовкой к сезону, поэтому нужно было найти надежное альтернативное решение. Так и появился этот проект.
Решение — внешняя команда
Мы рассмотрели различные варианты и решили привлечь внешнего подрядчика. Задумали этот проект как челленж внутренней команды НТ. Посудите сами:
У нас есть классная команда, но ее ресурсов не хватало для проведение полного нагрузочного тестирования всех систем с учетом вводных от бизнеса и жестких дедлайнов.
Открыть найм и оперативно набрать новых ребят не казалось лучшим решением. В этом случае необходимо было заложить несколько месяцев на поиск специалистов и найм, а минимум месяц — на обучение и адаптацию. Такой роскоши у нас не было.
Нанять подрядчика и полностью отдать ему проведение нагрузочного тестирования могло бы стать опцией, но тогда мы забрали бы всю работу у внутренней команды, а значит, могли потерять крутых специалистов.
Поэтому выбрали четвёртый вариант — челлендж.
Мы находим подрядчика, который проведет нагрузочное тестирование систем в формате «черного ящика» , а наша команда будет работать параллельно. Перед обеими командами будет стоять цель подсветить все уязвимые места системы нашим командам разработки в кратчайшие сроки. Таким образом, мы сохраним наших специалистов, повысим их хард- и софт-скиллы с помощью коммуникации с подрядчиком и успешно подготовимся к сезону. Кажется, все в выигрыше.
Вызов принят
Сроки у нас были сжатые — всего 3 месяца. Мы хотели начать работу 29 мая и завершить проект 1 сентября. Командам необходимо было составить точные профили нагрузки, максимально приближенные к реальным, учесть нюансы каждой из систем, написать скрипты и провести тесты.
Поставив перед собой такую задачу, мы столкнулись с недоверием и удивлением участников тендера. Кто-то называл сроки проекта «нереальными», а мы считали их просто амбициозными и были уверены, что они достижимы.
Единственным подрядчиком, который оказался готов реализовать наши требования с учетом очень жестких дедлайнов, стали IBS. И мы доверились им!
В ходе проекта планировали достичь следующие технологические цели:
Определить максимальную производительность системы. Мы хотели выяснить, какова максимальная интенсивность операций, при которой система удовлетворяет нашим требованиям по времени отклика или обработки.
Проверить надежность: смогут ли наши системы работать под нагрузкой длительное время.
Выявить «узкие места» — факторы, которые ограничивают нашу производительность (например, недостаток аппаратных или системных ресурсов, нюансы архитектуры), а также критичные показатели, требующие мониторинга в процессе эксплуатации.
Как это было (процессы и коммуникации)
В самом начале проекта мне было нужно организовать нетоксичную и эффективную коммуникацию между внутренней и внешней командами нагрузочного тестирования и разработки. Я использую слово «нетоксичную» осознанно — согласитесь, мало кому понравится такая ситуация:
↓ Ты работаешь в компании некоторое количество времени, показываешь результаты — и все классно.
↓ Появляются топ-менеджеры и проджект, которые объявляют, что они привлекли подрядчика и устраивают челлендж твоей работы. Невольно возникают вопросы: «Как так получилось? Неужели я плохо работаю? Меня уволят, если результаты подрядчика будут отличаться от моих?»
спойлер: нет, никого не уволят и не уволили
↓ Закономерно, что ты относишься ко всей этой затее с большим недоверием, а тут тебя еще забрасывают вопросами: «Как и что работает? Какие тестовые данные тут нужны? Расскажи о нюансах». Тебе нужно на них отвечать и помогать «команде противника», параллельно выполняя свои задачи и отгоняя неприятные мысли.
Мне искренне не хотелось, чтобы меня и внешнюю команду воспринимали как агрессора и чтобы наши ребята переживали о своих перспективах работы в СберМаркете. Что я сделала?
Провела встречу с лидами тестирования, разработки и топ-менеджерами нашего IT-департамента. Важно было донести: мы пошли на этот шаг, чтобы безболезненно пройти высокий сезон, перенять экспертизу и тем самым усилится самим. У всех участников встречи была задача принести эту информацию в свои команды и успокоить ребят, если возникнут волнения.
Провела встречу с внутренней командой нагрузочного тестирования с тем же буллетами, что и с топами. Ответила на все возникшие вопросы и еще раз подсветила, что у нас одна цель. Это помогло успокоить команду, ребята начали настраиваться на позитивную коммуникацию с подрядчиком.
Чтобы не возникло недосказанности, решили опубликовать информацию о старте проекта и ссылки, где и что можно посмотреть, в еженедельном дайджесте компании.
В СберМаркете ежеквартально мы проводим ревью по проектам. На эти встречи может прийти любой сотрудник и задать интересующие вопросы. Проект стартовал 29 мая, и 5 июня я ворвалась на эту встречу.
Все узнали о проекте из «первых уст» и не осталось места для додумывания о целях проекта. Любой сотрудник, которому было интересно что-то узнать о проекте, мог зайти на 1-pager и увидеть полную информацию.
Таким образом, кажется, вся компания знала о проекте и его целях — привлечение подрядчика уже не воспринималось так негативно.
Как мы организовали работу?
Проект был разбит на четкие этапы: с мая по июль — Витрина, финиш к концу августа — RTE, к середине сентября — Shopper. На каждом этапе тесно взаимодействовали с техническими экспертами разработки, которые помогали решать вопросы и внедрять необходимые инструменты для тестирования.
Каждый из сегментов работы представлял собой отдельную систему с уникальными требованиями и сложностями.
На старте проекта мы провели установочные встречи с разными внутренними командами, чтобы ввести подрядчика в курс дел.
Взаимодействие команды IBS с внутренними командами организовали по направлениям каждой из тестируемых систем. Мы завели отдельные каналыканалы в корпоративном мессенджере для коммуникации с рабочей группой разработчиков и мануальных тестировщиков и отдельный канал — совместно с внутренней командой нагрузочного тестирования.
Далее:
С внешней командой у нас стояли ежедневные 15-минутные дейли, на которых мы обсуждали апдейты и возникающие вопросы. Со стороны СберМаркета на них присутствовали технический лидер по надежности системы и проджект. Стейкхолдеры могли присоединяться по желанию, а «приглашенные звезды» с нужной экспертизой из других внутренних команд иногда залетали к нам для решения специфических вопросов.
Команды готовили отчеты после каждого нагрузочного тестирования и публиковали их в каналах тестируемой системы в корпоративном мессенджере, далее их в работу брали команды разработки.
Как это было (техника)
Здесь перед нами встал ключевой вопрос: как дать внешней команде нужные ресурсы, которых до этого не существовало.
Мы рассматривали различные инструменты нагрузочного тестирования, включая jMeter, k6 и Gatling. Главными критериями выбора были:
язык программирования (Java для jMeter, JavaScript для k6, Scala для Gatling),
способность генерировать высокую нагрузку и удобство интеграции с существующими системами,
возможность масштабировать нагрузку, что критически важно для точности и реалистичности тестирования.
Внутренние процессы СберМаркета ориентированы на JavaScript, поэтому k6 был для нас предпочтительной опцией. Однако сотрудничество с IBS потребовало выбора Gatling.
Организация рабочей среды для команды IBS потребовала тщательной подготовки. Сначала были обеспечены все необходимые технические доступы, включая VPN и внутренний контур. Затем каждому члену команды IBS были заведены учетные записи для доступа к системам мониторинга и логирования, таким как Kibana и Grafana. Особое внимание уделили созданию генераторов нагрузки, которые требовались для тестирования под реальными условиями.
Мы создали 50,000 тестовых аккаунтов и 1,200 магазинов. Это позволило воспроизвести нагрузку, максимально приближенную к реальным условиям. Тестовые данные регулярно обновлялись и адаптировались к изменениям в системе, включая обновления мобильных приложений и изменения в API.
Мы контролировали, чтобы тестовые данные были исключены из аналитических отчетов и соответствовали требованиям ИБ. Для этого использовали специальные атрибуты, которые помогали отличать тестовые операции от реальных, а тестирование проводили в ночное время, чтобы минимизировать риски.
Нагрузочные тесты проводились на продакшн-среде с минимальным влиянием на реальных пользователей — это было основной сложностью. СберМаркет работает в более чем 360 городах России от Калининграда до Петропавловска-Камчатского — то есть затрагивает все часовые пояса страны. Целью нагрузочного тестирования было выявление узких мест, а не создание инцидентов.
Если возникали проблемы, команды оперативно восстанавливали систему до наступления пиковой нагрузки от реальных пользователей.
В итоге: как безопасно проводить нагрузочное тестирование?
Проанализировав нагрузку на системы, мы определили менее чувствительные временные слоты для проведения тестов — Понедельник-четверг с 00:00 до 03:00 по Москве.
Нам каждую неделю нужно было планировать тесты, которые проводили внутренняя и внешняя команды, изолированное тестирование команд микросервисов, релизы и многое другое.
Делюсь лайфхаками, которые мы узнали в процессе.
Правила проведения любых работ на продакшене — наше всё!
Планировать тесты такого рода рекомендую на неделю вперед.
Заведите отдельную доску в Jira, чтобы отслеживать, не пересекаются ли задачи друг с другом.
Чтобы избежать инцидентов во время нагрузочного тестирования, мы собирали инженеров по тестированию, инцидент-менеджеров и дежурных разработчиков от тестируемой системы — если мы «положим прод», ребята могли все оперативно исправить.
Как мы переняли экспертизу через конкуренцию
Первоначальные опасения внутренней команды преодолели благодаря открытой и честной коммуникации. Мы подчеркивали значимость вклада ребят в общий успех — это помогло повысить мотивацию и сплоченность команды. С этим как раз и помогли ежедневные встречи по синхронизации.
Дух здоровой конкуренции между внутренней и внешней командами повысил качество работы. Команды мотивировались не только на выполнение задач, но и на достижение лучших показателей — это в итоге положительно сказалось на эффективности проекта в целом.
Выиграли от отличий в двух подходах
IBS специализируется на тестировании систем по методу «черного ящика», поэтому у них было много наработок и свежий взгляд на написание скриптов для нагрузочных тестов, составление профиля нагрузки и другие технические особенности.
В то же время, внутренняя команда подходила к организации нагрузочного тестирования с другой стороны: они знали всю «внутрянку» систем и использовали к6 для нагрузочного тестирования.
По окончании каждого этапа работы внешней команды мы готовили воркшоп для внутренней. Внешняя команда делилась тонкостями своей работы, внутренняя — задавала вопросы, рассказывала, как она подходили к решению задач. Таким образом получался симбиоз экспертности обеих команд, и все участники встречи выходили с новыми знаниями или лайфхаками.
Сравнили профили нагрузки
Обе команды формировали профиль разными способами — на выходе «чистота» результатов тестов отличалась. Своими подходами команды делились на встречах для синхронизации.
Автоматизация нагрузочного тестирования: за или против?
У меня нет однозначного ответа на этот вопрос, везде есть плюсы и минусы.
Внутренняя команда пришла к автотестам: тесты запускались в забронированный слот, и их контролировал дежурный инцидент-менеджер.
Внешняя команда не использовала автоматизацию так интенсивно как мы. С их стороны обязательно был инженер, который запускал и останавливал тест, смотрел за метриками. Дежурный инцидент-менеджер со стороны СберМаркета, конечно, присутствовал и при таких тестах. После окончания теста инженер со стороны IBS формировал отчет — и утром команда разработки забирала его в работу.
Результаты
(настолько открыто, насколько позволяют наши NDA)
Для СберМаркета и IBS это был необычный опыт взаимодействия. Будет ли СберМаркет использовать подобные «челленджи» дальше? Да, так как результаты даже превзошли ожидания: мы успешно прошли высокий сезон без серьезных инцидентов.
Самое ценное — мы переняли экспертность и помогли нашим командам взглянуть на свою работу с другой стороны.
А теперь к фактам:
Мы значительно изменили подход к анализу и составлению профиля нагрузки. Внутренняя команда начала учитывать ежедневные колебания нагрузки и изменения в профилях отдельных эндпоинтов. Мы автоматизировали процесс снятия эталонного профиля нагрузочного тестирования, , а тесты стали точнее и эффективнее.
Начальный стресс и сомнения среди команд уступили место здоровой конкуренции и эффективному сотрудничеству.
Благодаря совместному обучению ошибки реже повторялись, а решения стали быстрее и прозрачнее. Внутренняя команда значительно расширила свои знания и навыки. Мы внедрили практики, которые внешняя команда использовала для анализа профиля и написания скриптов. Команды научились делиться ресурсами для решения проблем, что позволило разработчикам сосредоточиться на решении общих задач.
Одним из самых значимых результатов стало увеличение количества заказов в 4 раза. Порог деградации системы снизился, а количество инцидентов в пиковые часы свелось к минимуму.
Ребята из IBS показали себя как отличных профессионалов и выполнили все работы в срок.
Для меня этот проект сыграл огромную роль в развитии как IT-проджекта. Проекты, которые я запускала и вела раньше, были не такими масштабными, а про тестирование я знала только благодаря небольшому опыту работы тестировщиком приложений на iOs. Здесь же потребовалось много включения и определенный уровень экспертизы. Необходимо было разбираться в наших системах, чтобы обеспечить подрядчику быстрый доступ к нужным командам. В конце проекта я уже понимала инструменты, подходы и стратегии нагрузочного тестирования, умела пользоваться мониторингом и анализировать происходящее на графиках. А еще консультировать проджектов по особенностям работы с командами нагрузочного тестирования.
Выводы — упакованная экспертиза
Я собрала ключевые моменты, которые помогли мне в организации работы с подрядчиком, и лайфхаки, возникавшие стихийно по ходу проекта:
Стоит ли идти к подрядчику за «вторым мнением»? Решать вам, но, кажется, имеет смысл усилиться в шортране и запустить обмен опытом, чтобы усилить внутреннюю экспертизу.
Для управления проектами в СберМаркет мы используем методологию p3express — это простой, гибкий и минималистичный фреймворк. Ее принципы здесь подошли как нельзя лучше: нам нужно было создать многогранного плана, обширно декомпозировать задачи и четко соблюдать сроки. Этот план был похож на живой организм — он постоянно эволюционировал и адаптировался в ответ на новые данные и результаты обсуждений. Рекомендую присмотреться к этой методологии — так в условиях неопределенности у вас будут рекомендации, как поступить, и останется только выбрать подходящие.
Плагин Structure в Jira и диаграммы Ганта — наше все. Помогают всем участникам проекта понимать прогресс и ход работ без дополнительной выгрузки отчетов по задачам.
Прозрачность процессов — ключевой фактор успеха в проекте, где вы привлекаете подрядчика.
Организуйте знакомство команд, постоянные воркшопы и встречи по обмену опытом или решению спорных вопросов, даже если кажется, что времени не хватает: перенимать экспертизу — важно, это win-win кейсы.
Быстро реагируйте на проблемы, возникающие в работе подрядчика с вашими системами. У нас с командой IBS был чат в Telegram, а оперативная реакция на проблемы или вопросы ребят была моим приоритетом. Так мы избежали проблему сломанного телефона.
Еженедельно информируйте участников проекта о результатах прошедшей недели и планах на будущую. Я вела канал в корпоративном мессенджере со всеми участниками. Каждый понедельник они получали своеобразную сводку новостей. Важно: минимум воды и красивых речевых оборотов — факты, планы и описание проблем (что за проблема, как решили и на что это влияет в будущем).
Рада, что вы дочитали статью до конца и надеюсь, что каждый возьмет из нее что-то полезное!
