Привет! Меня зовут Юля Шамина, я руководитель IT-проектов в СберМаркете. Хочу поделиться нестандартным по всем меркам кейсом, как мы подготовили наши сервисы к высоким предновогодним нагрузкам за 3 месяца благодаря челленджу внутренней команды нагрузочного тестирования. 

Эта статья не про успешный успех, а про то, как и зачем привлекать подрядчика, если вопросом уже занимается внутренняя команда.  А ещё про страх неизвестности, мучительную настройку процессов и то, как в конце концов показать высокие результаты в сжатые сроки с минимальным количеством факапов.

Если бы можно было описать этот проект одной цитатой — «Это было смело, чертовски смело!»

А теперь по порядку. Расскажу,  как мы пришли к тому, что нам понадобился подрядчик, и что вообще это за проект.

• Предпосылки

• Решение — внешняя команда

• Как это было (процессы и коммуникации)

• Как это было (техника)

• Как мы переняли экспертизу через конкуренцию

• Результаты

• Выводы — упакованная экспертиза

Предпосылки

СберМаркет — высоконагруженный e-commerce сервис, №1 на рынке e-grocery за 2022 год. Одна из наших главных целей — это стабильность в работе систем. 

За последний год наши нагрузки выросли в 2 раза, а по потреблению инфраструктуры с 2019 года —  в 77 раз. Мы собираем с наших сервисов более 2 миллионов метрик в секунду, и эта цифра постоянно растет. На данный момент наш пик — 115k RPS.

Особенность бизнеса — сезонность, ярко проявляющаяся в периоды значительных маркетинговых акций и праздников, например, на Черную пятницу или Новый год. В это время из-за акций и скидок трафик на наших сервисах резко растет, а объем заказов кратно увеличивается. 

Подробнее об этом феномене высокого сезона в e-com мои коллеги рассказывали в подкасте «Для tech и этих».

Системы СберМаркета. Вот они все, слева направо…

Заказ в СберМаркете можно оформить на сайте или в приложении. Но это, конечно, только вершина айсберга. У нас есть: 

• Витрина B2C — веб-версия и приложение; 

• Витрина B2B — веб-версия и приложение; 

• RTE (Ready To Eat) — раздел с заказом готовой еды из ресторанов;

• ShopperApp и VendorApp — приложения для сборщиков и курьеров Сбермаркет.

Ключевым фокусом IT-команды на 2023 год стала надежность систем. Мы наметили векторы для работы, одним из которых было полноценное покрытие всех наших систем нагрузочными тестами. Мы поняли, что хотим усилить внутреннюю экспертизу в области нагрузочного тестирования, изменить стратегию и перейти на новый технологический стек. 

У нас внутри уже существовала отдельная команда, занимающаяся нагрузочными тестами. Но мы оценили риски и поняли, что работы много и мы можем не успеть реализовать весь план текущим составом. У нас не было возможности рисковать подготовкой к сезону, поэтому нужно было найти надежное альтернативное решение. Так и появился этот проект.

Решение — внешняя команда

Мы рассмотрели различные варианты и решили привлечь внешнего подрядчика. Задумали этот проект как челленж внутренней команды НТ. Посудите сами:

1. У нас есть классная команда, но ее ресурсов не хватало для проведение полного нагрузочного тестирования всех систем с учетом вводных от бизнеса и жестких дедлайнов. 

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

3. Нанять подрядчика и полностью отдать ему проведение нагрузочного тестирования могло бы стать опцией, но тогда мы забрали бы всю работу у внутренней команды, а значит, могли потерять крутых специалистов. 

Поэтому выбрали четвёртый вариант — челлендж. 

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

Вызов принят

Сроки у нас были сжатые — всего 3 месяца. Мы хотели начать работу 29 мая и завершить проект 1 сентября. Командам необходимо было составить точные профили нагрузки, максимально приближенные к реальным, учесть нюансы каждой из систем, написать скрипты и провести тесты. 

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

Единственным подрядчиком, который оказался готов реализовать наши требования с учетом очень жестких дедлайнов, стали IBS. И мы доверились им!

В ходе проекта планировали достичь следующие технологические цели:

1. Определить максимальную производительность системы. Мы хотели выяснить, какова максимальная интенсивность операций, при которой система удовлетворяет нашим требованиям по времени отклика или обработки.

2. ​Проверить надежность: смогут ли наши системы работать под нагрузкой длительное время.

3. Выявить «узкие места» — факторы, которые ограничивают нашу производительность (например, недостаток аппаратных или системных ресурсов, нюансы архитектуры), а также критичные показатели, требующие мониторинга в процессе эксплуатации.

Как это было (процессы и коммуникации)

В самом начале проекта мне было нужно организовать нетоксичную и эффективную коммуникацию между внутренней и внешней командами нагрузочного тестирования и разработки. Я использую слово «нетоксичную» осознанно — согласитесь, мало кому понравится такая ситуация: 

↓ Ты работаешь в компании некоторое количество времени, показываешь результаты — и все классно.

↓ Появляются топ-менеджеры и проджект, которые объявляют, что они привлекли подрядчика и устраивают челлендж твоей работы. Невольно возникают вопросы: «Как так получилось? Неужели я плохо работаю? Меня уволят, если результаты подрядчика будут отличаться от моих?»

спойлер: нет, никого не уволят и не уволили

↓ Закономерно, что ты относишься ко всей этой затее с большим недоверием, а тут тебя еще забрасывают вопросами: «Как и что работает? Какие тестовые данные тут нужны? Расскажи о нюансах». Тебе нужно на них отвечать и помогать «команде противника», параллельно выполняя свои задачи и отгоняя неприятные мысли. 

Мне искренне не хотелось, чтобы меня и внешнюю команду воспринимали как агрессора и чтобы наши ребята переживали о своих перспективах работы в СберМаркете. Что я сделала?

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

2. Провела встречу с внутренней командой нагрузочного тестирования с тем же буллетами, что и с топами. Ответила на все возникшие вопросы и еще раз подсветила, что у нас одна цель. Это помогло успокоить команду, ребята начали настраиваться на позитивную коммуникацию с подрядчиком.

3. Чтобы не возникло недосказанности, решили опубликовать информацию о старте проекта и ссылки, где и что можно посмотреть, в еженедельном дайджесте компании. 

4. В СберМаркете ежеквартально мы проводим ревью по проектам. На эти встречи может прийти любой сотрудник и задать интересующие вопросы. Проект стартовал 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. Здесь же потребовалось много включения и определенный уровень экспертизы. Необходимо было разбираться в наших системах, чтобы обеспечить подрядчику быстрый доступ к нужным командам.  В конце проекта я уже понимала инструменты, подходы и стратегии нагрузочного тестирования, умела пользоваться мониторингом и анализировать происходящее на графиках. А еще консультировать проджектов по особенностям работы с командами нагрузочного тестирования. 

Выводы — упакованная экспертиза

Я собрала ключевые моменты, которые помогли мне в организации работы с подрядчиком, и лайфхаки, возникавшие стихийно по ходу проекта: 

1. Стоит ли идти к подрядчику за «вторым мнением»? Решать вам, но, кажется, имеет смысл усилиться в шортране и запустить обмен опытом, чтобы усилить внутреннюю экспертизу.

2. Для управления проектами в СберМаркет мы используем методологию p3express — это простой, гибкий и минималистичный фреймворк. Ее принципы здесь подошли как нельзя лучше: нам нужно было создать многогранного плана, обширно декомпозировать задачи и четко соблюдать сроки. Этот план был похож на живой организм – он постоянно эволюционировал и адаптировался в ответ на новые данные и результаты обсуждений. Рекомендую присмотреться к этой методологии — так в условиях неопределенности у вас будут рекомендации, как поступить, и останется только выбрать подходящие.

3. Плагин Structure в Jira и диаграммы Ганта — наше все. Помогают всем участникам проекта понимать прогресс и ход работ без дополнительной выгрузки отчетов по задачам.

4. Прозрачность процессов — ключевой фактор успеха в проекте, где вы привлекаете подрядчика.

5. Организуйте знакомство команд, постоянные воркшопы и встречи по обмену опытом или решению спорных вопросов, даже если кажется, что времени не хватает: перенимать экспертизу — важно, это win-win кейсы.

6. Быстро реагируйте на проблемы, возникающие в работе подрядчика с вашими системами. У нас с командой IBS был чат в Telegram, а оперативная реакция на проблемы или вопросы ребят была моим приоритетом. Так мы избежали проблему сломанного телефона. 

7. Еженедельно информируйте участников проекта о результатах прошедшей недели и планах на будущую. Я вела канал в корпоративном мессенджере со всеми участниками. Каждый понедельник они получали своеобразную сводку новостей. Важно: минимум воды и красивых речевых оборотов — факты, планы и описание проблем (что за проблема, как решили и на что это влияет в будущем). 

Рада, что вы дочитали статью до конца и надеюсь, что каждый возьмет из нее что-то полезное!

Tech-команда Купера (ex СберМаркет) ведет соцсети с новостями и анонсами. Если хочешь узнать, что под капотом высоконагруженного e-commerce, следи за нами в Telegram и на YouTube. А также слушай подкаст «Для tech и этих» от наших it-менеджеров.