Сегодня я хочу вспомнить, как появилось, развивалось и организуется сейчас нагрузочное тестирование в Яндексе.
Кстати, если вам понравилась эта история, приходите Тестовая среда в нашем питерском офисе 30 ноября ( регистр ), — там я расскажу вам подробнее об игровых механиках в тестировании и буду рад пообщаться с вами в прямом эфире.
Так.
В 2005-2006 годах часть непоисковой инфраструктуры Яндекса начала испытывать нагрузку Рунета, которая росла как на дрожжах.
Возникла необходимость протестировать работу поисковых сервисов, в первую очередь баннер-спиннера.
Тимур Хайруллин, который на тот момент отвечал за нагрузочное тестирование, озадачился поиском подходящего инструмента.
Но существовавшие на тот момент открытые решения были либо очень примитивными (ab/siege), либо недостаточно мощными (jmeter).
Выделяется среди коммерческих коммунальных услуг HP Load Runner , но дороговизна лицензий и зависимость от проприетарного ПО нас не порадовали.
Поэтому Тимур вместе с разработчиком высокопроизводительного фантомного веб-сервера Женей Мамчицем придумали хитрый трюк: научили сервер работать в клиентском режиме.
Вот такой получился модуль фантом-бенчмарк.
Сам фантомный код теперь открыт и его можно скачать.
отсюда , а историю про фантома можно посмотреть на видео с презентации Здесь .
Тогда Phantom был очень простым, он мог измерять только максимальную производительность сервера, а мы могли только ограничивать количество потоков.
Но уже на тот момент наша утилита была на голову выше своих аналогов.
Поэтому все больше сервисов стали обращаться к нам за нагрузочным тестированием.
С 2006 по 2009 год команда нагрузочного тестирования выросла до десяти человек.
Очень быстро за нами закрепилось название «танкисты», которые заряжают «ленты» «патронами» и «стреляют» из «танков» по «мишеням».
Танковая тема все еще с нами.
Для экономии ресурсов мы создали специальный «полигон» или «курятник», где содержали виртуальные машины для нагрузочного тестирования.
Платформой виртуализации на тот момент была openvz, но сейчас мы полностью перешли на lxc из-за лучшей поддержки новых ядер и дистрибутивов серверов Ubuntu. Уважение сообществу lxc! Параллельно с появлением сервисов и ростом популярности нагрузочного тестирования, а точнее, с ростом самосознания сервисных команд, пришло понимание ограниченности возможностей инструмента.
При содействии разработчиков и под руководством «танкиста» Андрея баабака Кузьмичева, мы начали перерабатывать фантом в настоящий фреймворк для поддержки нагрузочного тестирования — Лунапарк.
Раньше из-за плохой организации отчетов результаты хранились беспорядочно — в Wiki, JIRA, почте и т. д. Это было очень неудобно, мы вложили много труда в это больное место и постепенно получили настоящий веб-интерфейс с дашбордом.
и графики, где все тесты были связаны с тикетами в JIRA, все отчеты наконец-то получили единообразие и четкое оформление.
Веб-интерфейс научился отображать процентили, тайминги, среднее время, коды ответов, количество полученных и переданных данных, а также около 30 различных графиков и таблиц.
Кроме того, к Лунапарку подключили почту, jabber и другие сервисы.
Изменения не обошли стороной и сам генератор нагрузки Phantom — он научился делать многое из того, что не умел раньше.
Например, подавать запросы по расписанию — линейно, ступенчато, снижать нагрузку и даже (!) подавать нулевую и дробную нагрузку.
В вывод консоли добавлен вывод агрегации с процентилями, мониторингом объема данных, ошибками и ответами.
Вот как выглядел вывод консоли в 2009 году.
Постепенно пришло понимание, что необходимо не только постоянно тестировать некоторые сервисы, но и сопровождать их из года в год от релиза к релизу, а также иметь возможность сравнивать тесты между собой.
Так появились страницы Лунапарка, важные для работы нагрузочного тестера: сравнение тестов и регрессия.
Вот как выглядели их первые версии.
Тестировщик, разработчик или менеджер мог в любой момент узнать, как развивается продукт с точки зрения производительности.
Сейчас мы работаем над улучшением и выведением этих страниц на передний план платформы.
На текущем этапе разработки для нас важнее всего не отдельные тесты, а тенденции производительности.
В 2011 году произошло важное событие — мы стали первой командой в Яндексе, запустившей настоящую геймификацию рабочего процесса, о которой я и расскажу.
отдельный отчет по тестовой среде.
Это редкость даже сейчас в самых передовых IT-компаниях.
Мы разместили «Зал славы» на странице Лунапарка и очень гордимся этой частью структуры.
За конкретный тест можно сказать настоящее, дружеское «Спасибо!» к нагрузочному тестеру.
Каждый тестер получает различные значки за то или иное событие, становится «командиром танка» (а-ля мэр в Ворскверике) и даже «званием», которое присуждается за количество выполненных испытаний.
Среди рутинной работы любое достижение или благодарность на вес золота.
Это очень мотивирует. 
Мы считаем 2011 год поворотным в нашем нагрузочном тестировании.
Команду разработчиков возглавил Андрей под Похилко.
Сообщество тестировщиков знает его как разработчика отличных плагинов для Джметр .
Андрей привнес свежие идеи и подходы, которые сейчас очень помогают в нашей работе.
Во-первых, мы поняли, что невозможно разработать инструмент в старой парадигме «нет времени объяснять, кодируй», и перешли на модульную парадигму разработки, где большой монолит разбивается на компоненты и разрабатывается отдельными частями, не ставя при этом перед собой задачу.
угроза всему проекту.
Во-вторых, поскольку заказы на нагрузочное тестирование стали поступать от сервисов, которым не интересен http-трафик, нам понадобился инструмент, который мог бы тестировать SMTP/POP3/FTP/DNS и другие протоколы.
Писать фантомные протоколы для каждого такого сервиса нам показалось накладно, и мы решили интегрировать в Лунапарк обычный Jmeter. Таким образом, без особых усилий мы научились поддерживать несколько десятков новых протоколов при нагрузочном тестировании.
Встраивание помогло нам уйти от стандартного веб-интерфейса без перехода на графический интерфейс Jmeter. Помимо поддержки Jmeter, наш танк со временем научился поддерживать SSL, IPv6, UDP, эллиптику, «мультитесты» на несколько адресов от одного генератора, подачу нагрузки в несколько миллионов rps от распределенных генераторов и многое другое.
В определенный момент заказов на нагрузочное тестирование стало настолько много, что для нас стало очевидно: мы не сможем ежегодно удваивать штат сотрудников, не убрав из нагрузочного тестера рутинные и регрессионные тесты.
Чтобы решить эту проблему, мы проанализировали всю нашу текущую ежедневную работу, и оказалось, что к сервисам нужно подходить с разной степенью глубины тестирования.
Мы придумали следующую схему работы:
- Для тестирования прототипов или экспериментальных сборок мы сделали отчуждаемую версию генератора нагрузки и, чтобы не отвлекать загрузчиков от более подготовленных проектов, стали рекомендовать ее разработчикам или системным администраторам для отладки нагрузочных тестов своего прототипа.
Полученные результаты совместимы с фреймворком Лунапарка и не возникает ситуаций типа «Я тестировал свой прототип с помощью ab, он выдавал 1000 оборотов в секунду, а в Лунапарке только 500!»
- Для тестирования разовых или событийных сервисов, где нагрузка может внезапно увеличиться в несколько раз (Спорт, ЭГ?, Новости, Акционные проекты), мы сохраняем виртуальные машины быстрого запуска, на которых развертываются готовые пакетные сервисы.
Испытания проводятся в ручном режиме с использованием удаленной телеметрии, снятой с объекта нагрузки.
Иногда процесс координируется в специальных чатах, где могут сидеть до 5-10 человек: «танкисты», разработчики, менеджеры.
По нашей внутренней статистике, 50% ручных тестов(!) выявляют различные проблемы с производительностью — от неправильно построенных индексов, «всплесков» файловых операций, недостаточного количества воркеров и т. д. Итоговые результаты документируются в JIRA.
При желании для анализа можно включить дополнительные графики, например время отклика.
Ошибки HTTP и сети: 
Время на разных этапах взаимодействия и потоков: 
Для регрессионных тестов или тестов, результаты которых принимаются разработчиками или администраторами, мы сделали так называемые автоматические и полуавтоматические тесты.
Об этом нужно поговорить отдельно.
В конце 2011 года мы поняли, что по сути все тестовые операции можно выполнять скриптами, вызовами или, проще говоря, каким-то механизмом выполнения.
Идеологически наиболее близкими к такой деятельности являются CI-фреймворки, способные собирать проекты, запускать набор тестов, уведомлять о событиях и выдавать вердикт о прохождении.
Мы рассмотрели варианты этих инструментов и обнаружили, что фреймворков с открытым исходным кодом не так много.
Jenkins показался нам наиболее удобным для расширения функционала с помощью плагинов и, протестировав его возле Лунапарка, мы внедрили его в тестирование.
Используя внешние обращения к специальному API и встроенному планировщику, мы смогли перенести всю рутинную работу тестера на Jenkins. Разработчики получили заветную награду «Протестируйте мой сервис прямо сейчас!» кнопки, нагрузочные работники получали десятки, а то и сотни тестов в день без их участия, менеджеры и системные администраторы получали графики регрессии производительности от сборки к сборке.
На данный момент автоматизированные тесты составляют около 70% от общего потока, и эта цифра постоянно растет. Это экономит нам десятки сотрудников и позволяет сконцентрировать интеллект тестировщиков на ручных и исследовательских тестах.
Внимательный читатель заметит, что Лунапарк постепенно стал представлять собой отдельную структуру: отчужденный генератор нагрузки, бэкенд для статистики и телеметрии, а также отдельный фреймворк автоматизации.
Глядя на это и зная, что с YAC'10, где баабака сказал по поводу Лунапарка, тестеры со всего Рунета нас троллят при каждом удобном случае с открытием Лунапарка наружу, мы решили выпустить часть Лунапарка в открытый код. Летом 2012 года на одном из Яндекс.
Субботников в Москве мы представлен генератор нагрузки для сообщества тестировщиков.
Сейчас Яндекс.
Танк с облегченными графиками, со встроенной поддержкой jmeter и ab разрабатывается только на внешнем GitHub, отвечаем на вопросы пользователей в клубе и принимать внешние запросы на включение от разработчиков.
Мы знаем, что сообщество нагрузочных тестировщиков в Рунете невелико, имеющиеся знания очень скудны и поверхностны, но тем не менее интерес к теме производительности только растёт. Поэтому мы будем рады поделиться накопленным опытом и знаниями в этой области и обещаем периодически публиковать статьи на тему нагрузок, инструментов и методов тестирования.
Теги: #Тестирование ИТ-систем #Яндекс.
Танк #тестирование в Яндексе
-
Проблемы И Риски Криптовалют
19 Oct, 24 -
«Гаарец» Переходит В Интернет
19 Oct, 24 -
В Московском Метро Появился Wi-Fi
19 Oct, 24
