>
>
Интервью
Как тестируют в Ozon: рассказывает ведущий инженер Иван Приходько
Время чтения: 10 минут
Покрывать нагрузкой большую систему, безопасно тестировать продукт прямо на проде, собирать 10 миллионов метрик в секунду и обеспечивать минимум 47 тысяч заказов в минуту — это темп работы серьезной e-commerce площадки. К нему должен быть готов и владелец бизнеса, и разработка, и конечно, отдел QA. Как справляться с этими вызовами и получать удовольствие от работы, рассказывает Иван Приходько — ведущий инженер по нагрузочному тестированию в Ozon.
О себе и первых шагах в профессии
“11 лет в тестировании. Успел поработать в самых разных областях, от телекома до от e-commerce. Последние несколько лет занимаюсь нагрузочным тестированием, в Ozon с декабря 2021 года. Также преподаю на кафедре QA Ozon Route256 — это бесплатные курсы для middle-специалистов. Из личного: воспитываю двух дочек”.
Расскажи, когда и как ты пришел в IT?
Я начал работать в банках с третьего курса института. После выпуска с большим трудом попал в IT Helpdesk PWC от компании Siemens IT Solutions & Services. Казалось бы — большая удача, работаю на топовую компанию. Но через несколько месяцев пришло ощущение: «Окей, а что дальше?». Особого развития в сфере Helpdesk нет.
В то время мой товарищ по институту работал в ITeco и пригласил меня в тестировщики. Тогда я ничего не знал ни про разработку, ни про тестирование. Он дал почитать методичку, и меня взяли стажером. У меня был небольшой опыт написания скриптов, ранее я написал на JavaScript алгоритм, который позволял заполнять форму в нашей HelpDesk системе: кто позвонил, по какому вопросу. Скрипт вытаскивал эти данные с Avaya Softphone и забивал их на форму. С этими знаниями я пришел в автоматизацию тестирования. Такой у меня старт — через друзей, как это обычно бывает.
Тебе интересно заниматься одним делом уже больше одиннадцати лет?
В какой-то момент понимаешь, что можно расти либо вверх, либо вширь. Я больше развивался по технической части: изучал языки программирования, новые виды тестирования. В какой-то момент дорос до бэкенд-тестировщика, а затем решил заняться нагрузкой. В общей сложности я уже три года в нагрузочном тестировании.
Есть ли яркий случай из практики, который врезался в память сильнее всего?
Я работал на Кипре, в одной компании в городе Лимассол. Задачей было протестировать поиск в одном из сервисов — про нагрузочное тестирование я тогда практически ничего не знал, только основы. У меня была самописная утилита, которая нагружала поиск по нашему протоколу: она выдала результат, что поиск держал нагрузку в 5 rps и еле-еле справлялся.
Надо сказать, что на Кипре расстояния небольшие, и на обед я ходил домой пешком. Перед обедом я нашел дефект, собрал консилиум из наших разработчиков, и они поправили все за 15 минут. Радостный, я раскатал новую версию, запустил со своего компьютера нагрузочный тест (спойлер: так делать нельзя) и пошел обедать.
Когда я вернулся, возле моего компьютера стоял злой, как собака, главный сисадмин. Тестовые среды находились в облаке в одной из европейских стран, канал был не сильно большой, и разработчики настолько хорошо потюнили поиск, что я одним тестом умудрился положить весь офисный канал связи. Не работал интернет, клиенты не могли дозвониться, никто не мог подключиться ни на один сервер — поэтому админ «бегал» по компьютерам и искал, откуда подают адский трафик. С тех пор я всегда контролирую нагрузку, ставлю автостопы и никогда не запускаю продакшн-тестирование со своего компьютера.
О том, как устроено тестирование в Ozon
4000
Человек работают в Ozon Tech
4000
Микросервисов в компании
3
Дата-центра
с микросервисами
47тыс
Заказов в минуту обрабатывает платформа
105тыс
Составил RPS
по результатам прошлой распродажи
30PB
Объем аналитических хранилищ
320млн
Метрик собирается за скрейп
с микросервисов
В Ozon Tech работает четыре тысячи человек, а в команде нагрузочного тестирования — всего четыре, без «тысяч». Как устроена ваша работа?
Наша команда поделена на две: нагрузочное тестирование и разработка. Действительно, в нагрузке нас всего четверо, а в разработке — шестеро . Взаимодействуем так: разработчики по заявкам пилят инструментарий, который нужен для тестирования. А мы собираем требования и оказываем консультационные услуги. По сути, у нас есть собственный сервис нагрузочного тестирования, в который могут зайти разработчики, тестировщики, иногда даже менеджеры — и собрать минимальный простой тест по своему сервису. Если возникают проблемы, то они могут написать в специальный канал, и мы помогаем организовать старт.
Работается в такой пропорции комфортно. Конечно, иногда случаются косяки, но мы с этим живем.
Получается, вы не делаете тесты сами, а обеспечиваете коллег инструментами?
Мы делаем тесты сложных систем: центральный стресс-тест сайта, комплексные тесты по системам, у которых нет владельца. Скажем, я занимаюсь нагрузочным тестированием Jira и ChatZone, могу оказать помощь и по другим проектам.
Инструментарий Ozon
• Собственная платформа управления нагрузочным тестированием
• Яндекс.Танк и плагин Tank-API для стандартизации генератора нагрузки.
• Кастомизированная Пандора в качестве генераторов нагрузки.
• S3 Облако для хранения патронов, артефактов и логов для дальнейшего анализа и разбора, а также для загрузки генераторов.
• Умеем собирать трафик с любых сервисов для дальнейшего нагрузочного тестирования.
• Kafka в качестве транспорта для статистики.
• Ozon тестируют на проде.
Самое интересное, пожалуй, — тестирование на проде. Почему так, почему нельзя, например, сделать тестовый стенд с меньшим объемом данных?
Это вопрос оценки рисков и стоимости. Оzon тестирует на продакшне, потому что у нас такое количество нагрузки, инфраструктуры и серверов, что создание полноценного релевантного стенда обойдется очень дорого.
На самом деле, есть отдельные кластеры стейджинга, но он сильно усечен. С учетом того, что у нас хайлоад, на слабом железе мы не получим достоверных результатов. А мы регулярно отлавливаем ошибки с нехваткой железа или пропускной способности сети на серверах — такие вещи можно увидеть только на очень дорогом релевантном стенде или на продакшене.
Звучит как опасная история: кажется, если что-то пойдет не так, компания понесет чудовищные убытки. Есть ли рычаги, которые позволяют минимизировать риски — или вы просто с ними миритесь?
Опасность зависит от надежности механизмов. Наша система спроектирована так, что все тесты могут быть отключены в любой момент по нажатию одной кнопки. У нас двухступенчатая система алертинга: на первой ступени мы видим предупреждение, и тест автоматически ставится на стоп. Дополнительно есть дежурные и ручка, которая останавливает все тесты разом. Сейчас это уже автоматизированный процесс.
Тестирование на проде подходит только для больших платформ и только для e-commerce? Есть ли, по твоей гипотезе, какие-то продукты или ресурсы, которые тоже требуют такой модели?
Я считаю, что тестирование на проде подходит для тех платформ, у которых большая часть трафика читающая. Так обстоит дело в Ozon, у нас достаточно малый процент пишущего трафика.
Скажем так, 90% трафика можно покрыть читающей нагрузкой, подавая ее и тестируя. С пишущей все сложнее, каждая команда подходит по-разному: где-то создают заглушки, где-то отменяются заказы, у складских систем тоже своя специфика.
Существует мнение, что тестирование на проде не годится для решения конкретных проблем. Как вы действуете, когда нужно локализовать дефект?
Важный момент: мы не все тестируем на продакшне. У нас большие пайплайны, они тестируются на стейджинге, покрываются автоматизацией, а также есть «канарейка».
Если говорить о проблеме с производительностью, то надо еще раз сказать спасибо нашей команде observability платформы: они покрыли мониторингом и алертингом все на свете. Даже если система начинает заходить в базу данных без индекса, члену команды, которому принадлежит эта база данных, сразу прилетает уведомление. По Trace ID мы можем посмотреть весь путь запроса: в какой сервис он ходил, какой сервис и за какое время ему ответил, где произошла ошибка.
На том объеме тестов, что мы проводим, редко бывают кейсы, когда действительно приходится что-то расследовать. Мы всегда знаем, какой сервис куда обращается, и видим, кто за какое время отвечал, на каком из этапов пошла деградация.
Твоя команда использует «Яндекс.Танк» и разные допилы к нему как основной инструмент. Хватает ли этого? Есть мнение, что «Танк» не подходит для интернет-магазинов, поскольку не умеет эмулировать пользовательские сессии.
Это миф, просто потому что «Танк» и пушка к нему — две разные вещи. «Танк» — всего лишь обертка для генератора нагрузки. Саму нагрузку подает пушка, и она может быть любой. У «Яндекса», например, сначала был Phantom, потом они разработали «Пандору». «Яндекс.Танк» позволяет свести всю боль конфигураций того или иного инструмента в Yaml-файл, который где-то хранится. Когда у тебя слишком много тестов, очень удобно управлять файлами, каждый тест — файл с конфигурацией.
«Танк» допилен для работы с нашими сервисами. В качестве пушки у нас — «Пандора», которая поддерживает наши платформенные фичи. Именно они позволяют жить Ozon так, как сейчас. При подаче нагрузки на тот или иной сервис нам нужно притворяться другим сервисом — чтобы это работало нормально, мы дописываем «Пандору» таким образом, чтобы она могла это делать.
Каждая команда может написать свой генератор нагрузки на основе Пандоры, предложить ссылку в конфиге — и она запустится.
Подробнее об инструментах нагрузочного тестирования и инфраструктуре Иван рассказывал в своем выступлении на ПерфомансКонф #8. Посмотреть его целиком можно на канале конференции в Telegram.
Тестирование в e-commerce — всегда стресс? Есть информация, что во время распродаж ваши разработчики и тестировщики буквально ночуют в офисе.
Напряжение всегда присутствует, потому что у всех есть понимание ответственности за работу. Но конкретно в нашей команде горячий период –– это не сама распродажа, а период примерно за две недели до нее. В это время все команды и проекты активно стараются успеть дотюнить свои сервисы, дотестировать, снять лишние риски.
За месяц перед распродажами у нас был последний рекорд — 19 тысяч нагрузочных тестов. Это на самом деле очень много, в среднем около 450 тестов в день.
Когда стартует сама распродажа, практически все тесты прекращаются, в чатах — тишина. Как раз в это время мы можем успеть сделать какие-то фичи, до которых никак не доходили руки, проекты, которые были отложены в дальний ящик.
К чему готовиться тестировщикам – начинающим и постарше
01.
Все больше компаний будет переезжать с Java на язык Go.
02.
LoadRunner сменится JMeter DSL
03.
Новый востребованный специалист — перфопс, смесь DevOps-инженера и специалиста по нагрузочному тестированию
Что изменилось после в вашей работе после ухода с рынка зарубежных компаний? Пришлось ли искать аналоги инструментам? Писать собственные утилиты?
Утилиты у нас почти все свои. Единственное, вместо Docker Desktop у нас Podman, а вместо Slack — Mattermost, экспрессом пришлось делать на него нагрузочные тесты и допиливать под собственные нужды. Вместо Opsgenie у нас теперь Opszone — буквально за неделю ребята написали свою систему алертинга и управления дежурствами. К моменту ухода зарубежных компаний я только начал привыкать к Miro, как у нас перестали закупать на него лицензии. Пришлось отказаться от него. Подход Ozon с написанием собственного инструментария показал себя очень хорошо: многие вещи как работали, так и работают, потому что изначально были свои.
Какие планы у вашей команды на 2023 год?
Ничего грандиозного не планируем. Из команды ушло несколько человек, поэтому восполняем потерю бойцов: пока новые люди обучаются, не можем брать какие-то масштабные проекты. Еще в прошлом году был запланирован переезд с Influx на ClickHouse — надеюсь, в этом году у нас дойдут до него руки.
Сейчас наша команда немного переписывает внутреннюю архитектуру сервиса, потому что наш сервис нагрузочного тестирования тоже теперь испытывает нагрузку. Ozon растет, и мы вместе с ним, соответственно, растет количество тестов — наша архитектура не всегда справляется с тем, что мы делаем.
Лично мне хотелось бы попробовать JMeter DSL, я вижу, что он активно развивается. Мне кажется, что те, кто раньше работал с LoadRunner, потихоньку переписывают тесты на JMeter. Еще последнее время много слышу про K6.
Кажется, компании будут переписывать сервисы на Go. Сохраняется кризис железа, его всё сложнее купить — а сервис на Go потребляет в разы меньше ресурсов, чем написанный на том же Java.
Дай несколько советов начинающему тестировщику, который хочет стать востребованным? Какие навыки стоит развивать? Кого читать? На что обращать внимание?
Кирилл Юрков из «Самоката» предложил термин «перфопс» — смесь DevOps-инженера и специалиста по нагрузочному тестированию. Этот подход мне очень импонирует. Я считаю, что хороший инженер по нагрузке должен уметь работать с системой мониторинга. Для нас большим плюсом является то, что человек работал c Prometheus, знает метрики, разбирается в Influx. Человек должен быть немного админом, неплохо знать Linux, уметь работать в командной строке, понимать, как работает сетевой стек, разбираться в кэшах, Redis и т.д.
Дополнительно он должен разбираться, как работают приложения, написанные на Go, C# и Java. Прежде чем приступать к задаче, нужно оценить, имеет ли смысл это тестировать и нагружать — или уже на этапе первичного анализа видно, что оно так работать не будет.
Хороший инженер знает, как подать релевантную нагрузку на систему, отличный знает, в каких случаях можно этого не делать и добиться тех же результатов. А офигенный инженер придет и покажет разработчикам, в каком месте у них проблемы.
Я стараюсь быть как раз офигенным инженером, больше развиваться в эту сторону. Для меня большим плюсом является то, что человек заглядывает в код, потому что только код ответит, как именно все происходит в системе.
Вообще инженер должен прийти и хорошенько всех встряхнуть. Конечно, не все любят такой подход. Я, на самом деле, не хочу тестировать ради тестирования и стараюсь не работать в компаниях, где есть процессы, но нет результата. Мне очень нравится работать в Ozon, потому что у нас в процессе нагрузочного тестирования участвуют CTO. Раз в неделю у нас проходит встреча с CTO, крупными топ-менеджерами Ozon Tech, где разбираются результаты стрельб за прошлую неделю: в каком месте и по какой причине произошел автостоп, принимаются решения на высшем уровне. Вот тот кейс, где топ-менеджеры не просто витают в облаках, а спускаются до конкретной проблемы и держат на контроле производительность. Думаю, это и позволяет Ozon держать ту скорость, с которой мы сейчас развиваемся.
Поделиться ссылкой:
Пожалуйста, войдите, чтобы прокомментировать
0 комментариев