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