Аудит нагрузочного тестирования: пять этапов реального проекта

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

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

Привет, Хабр! Меня зовут Михаил Володин, я ведущий инженер отделения нагрузочного тестирования. В этой статье расскажу о реальном кейсе, когда по отчетам с продуктом все хорошо, а пользователи все равно жалуются. Нам с командой нужно было дать объективную оценку: достаточно ли текущих методов, подходов и инструментов, где скрываются слепые зоны, необходимо ли что-то менять. 

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

Шаг 1. Знакомство с продуктом

До старта проекта мы уже знали, что система состоит из подсистем, которые работают единовременно, но в каждой есть свои высоконагруженные периоды в году. Общее количество всех пользователей системы — больше 10 миллионов человек.

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

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

Полученной информации было достаточно, чтобы понять, с чем мы работаем, и составить дальнейший план действий. 

Сам процесс проведения аудита мы формально поделили на три этапа:

1. Анализ документации.

2. Интервью с командами.

3. Анализ артефактов.

Далее рассмотрим подробнее, как шел процесс и что менялось в ходе изучения получаемой информации.

Шаг 2. Анализ документации

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

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

В основных документах были подробно рассмотрены все этапы нагрузочного тестирования:

• подготовка;

• разработка средств нагрузочного тестирования;

• отладка и запуск;

• анализ и оценка результатов.

По документации мы выяснили состав участников процесса и кто за какие активности отвечает. Выделили основные роли: тест-менеджер, владельцы продукта и инженеры отдела нагрузочного тестирования.

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

Нагрузочное тестирование проводится по сервисам, поставлено на релизный цикл. Его цель — получить информацию о наличии или отсутствии деградации в новой версии. Запуски и анализ результатов проводятся автоматически.

Тестирование стандартное — выход на заданный в профиле уровень нагрузки в течение 10 минут и поддержание достигнутой интенсивности в течение 20 минут. По проводимым тестам не густо, поскольку подобные испытания зачастую не показывают большинства проблем.

Каждый продукт тестируется изолированно, и наиболее частым и приоритетным подходом является hit based, а не сценарное тестирование — не идеальный выбор.

Больше всего вопросов вызвало распределение задач между командами. Сборкой профиля, согласно документации, почему-то занимается владелец продукта и его команда, а не инженеры НТ. Анализ результатов происходит автоматически — владелец продукта и тест-менеджер принимают решение на основе сформированного автоотчета. Почему в этом не участвуют специалисты отдела НТ?

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

Шаг 3. Интервью с участниками процесса

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

Для начала мы составили список, с кем нужно пообщаться в первую очередь. Это основные участники процесса: инженеры нагрузочного тестирования и владельцы наиболее критичных и высоконагруженных продуктов. 

Также нам было очень важно понять, что происходит в продуктиве, возникают ли там какие-либо проблемы и инциденты. Решили пообщаться и с участниками отделов, которые первыми сталкиваются с проблемами производительности. Первая линия обороны — это техническая поддержка и отделы, занимающиеся мониторингом системы.

Инженеры отдела НТ

Пообщавшись с несколькими инженерами НТ, поняли, что они стараются придерживаться регламентов. Их основная деятельность — это написание скриптов и встраивание этих скриптов в Jenkins. Из-за многообразия сервисов и добавления новых работы у ребят всегда достаточно. 

На этом этапе мы выделили два основных пробела в текущем подходе.

Во-первых, инженеры НТ не принимают участия в составлении профиля. Это очень странно — кто же, если не они, должен быть экспертом в этом? В ситуации, когда система работает в проде, наилучшим подходом будет составление профиля на основании реального боевого использования, а не предполагаемых нагрузок.

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

Владельцы продуктов

Владельцы продуктов — это те, кто несет ответственность за работу отдельной подсистемы. Сами подсистемы отличаются друг от друга, всего их более 200. НТ покрыто порядка 30% — около 70 подсистем. Договорились о встрече с тремя — теми, кто «владеют» самыми высоконагруженными и критичными продуктами.

По результатам общения выявили несколько проблемных мест.

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

По автоотчетам, которые формируются по результата теста, было сразу несколько замечаний. Они не информативны и часто бесполезны. Например, в отчете сравнивается время текущего запуска с предыдущим и при отличии в 10% и более просто рекомендуется заводить дефект. Информация по состоянию стенда на время запуска не заполняется, а сам тестируемый стенд часто не соответствует проду ни по характеристикам, ни по наполнению — часть проблем попросту невозможно отловить.

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

Техническая поддержка

Для нашей задачи было очень важно пообщаться с сотрудниками технической поддержки, ведь они принимают на себя весь удар, когда баги проникли в прод. Обычно они первыми узнают о проблемах, причем чаще всего в негативном формате — от недовольных пользователей. 

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

Получили информацию по массовым сбоям, таких за год оказалось 600 штук.

Отдел мониторинга

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

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

При текущем подходе это было практически невозможно по нескольким причинам.

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

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

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

Шаг 4. Изучение артефактов

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

Для дальнейшего анализа собрали: 

• отчеты по проведенным НТ;

• отчеты по массовым сбоям;

• отчеты по инцидентам по всей системе за 1 год;

• профили НТ; 

• сценарии JMeter.

Проанализировать все артефакты за отведенное время было нереально, поэтому мы следовали правилу Парето, которое гласит, что 20% усилий должны давать 80% результата, — изучили только часть артефактов за прошедший год для наиболее критичных и высоконагруженных продуктов.

Отчеты по проведенным НТ

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

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

В отчетах представлялась такая информация:

• ссылки на прошлый и текущий запуск в Jenkins — там мы можем найти html-отчет JMeter;

• информация по проценту ошибок.;

• информация по временам отклика по 95pct;

• сравнение времен отклика в 2 запусках по эндпоинтам — процент расхождения;

• сравнение % ошибок в 2 запусках по эндпойнтам;

• рекомендации по заведению дефектов на основании % расхождения — если время отклика было 100 мс, а стало 115 мс — будет рекомендовано завести дефект, поскольку ухудшение более 10%. 

Тут мы были согласны с владельцами продуктов: рекомендации не очень информативны и обоснованы. 

Пришли к выводу, что в отчете не хватает внушительного количества информации.

Нет данных о мониторинге стендов на момент испытаний. Без них нельзя понять, соответствовало ли требованиям состояние стенда на момент испытаний и корректно ли проводить сравнение результатов. Если в ходе тестов состояние аппаратных ресурсов для нас является «черным ящиком», могут быть упущены серьезные проблемы. 

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

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

К рекомендациям тоже были вопросы. Проводить сравнение и выдавать рекомендации относительно времени отклика нужно не только на основании ухудшения в процентном соотношении, но также сравнивая с эталонным значением. В большинстве случаев отклонение в 10% при времени отклика в миллисекундах не является критичным и может быть вызвано огромным количеством факторов, которые присутствуют повсеместно.

Инциденты

Инциденты — это внеплановое прекращение или снижение качества работы сервиса. Мы изучали возникшие уже в продуктивной среде. Как-то быстро выделить инциденты, которые связаны с высокой нагрузкой и должны были быть выловлены на этапе тестирования, не представлялось возможности. Решили искать такие задачи в Jira, используя поиск по ключевым словам, таким как 504, тайм-аут, медленно, тормозит, превышает, утилизация, утечка, и тому подобным. 

Обнаружили порядка 150 задач. Их также изучали вручную, отбирая те, которые должны обнаруживаться в ходе НТ. Таких оказалось 35 штук.

Массовые сбои

Массовые сбои — это инциденты, количество обращений по которым превысило определенный лимит. Для каждой подсистемы лимит свой, обычно составляет 100.

Мы обнаружили 600 штук таких сбоев за год. Это проблемы, не обязательно связаны с высокой нагрузкой на систему. Необходимо было изучить отчеты по массовым сбоям, чтобы иметь представление, вследствие каких проблем пользователи чаще страдают. Изучать решили не все, достаточно ознакомиться с 20% от общего количества. На эту активность выделили один день.

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

Часть проблем было невозможно отловить при текущем подходе к нагрузочному тестированию, воспроизвести их можно только на аналогичных объемах данных. Другую часть массовых проблем можно воспроизвести только при сценарном подходе.

Профили нагрузки

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

1. Список эндпойнтов.

2. Нагрузка в RPS суммарно на весь сервис.

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

Так мы снова подтвердили наши предположения: в процессе сбора профилей не хватает участия экспертов.

Сценарии JMeter

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

Шаг 5. Подведение итогов

Итоговая картина получилась такая.

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

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

Комплексное тестирование отсутствует и ранее не проводилось.

 Что же с этим делать?

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

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

В итоге, список рекомендаций получился таким.

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

1. В процессе составления профиля должны участвовать инженеры по нагрузке, для сборки должны использоваться данные по использованию модуля в проде. Если подсистема работает с большими объемами данных, то необходимо проводить предварительное наполнение на тестируемом стенде. 

2. В автоотчетах необходимо расширить предоставляемую информацию и отображать:

• утилизацию серверных ресурсов за время выполнения тестов;

• подаваемую нагрузку (графики RPS, количественные данные по выполненным/ошибочным запросам);

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

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

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

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

   1. поиск максимальной производительности; 

   2. тестирование стабильности. 

3. На этапе планирования должны быть собраны все необходимые метрики, такие как: 

   1. времена отклика;

   2. допустимый процент ошибок.

   3. утилизация CPU;

   4. утилизация RAM;

   5. состояние сетевой активности;

   6. состояние дисковых подсистем.

4. Проводить испытания в несколько итераций в целях обнаружения узких мест.

В конечном итоге полученную и структурированную информацию мы донесли до заказчика, подсвечивая те самые ранее слепые зоны. Наши рекомендации заказчик начал применять на практике. 

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