Инженерия производительности (Performance Engineering) включает в себя набор ролей, знаний, практик, инструментов и результатов и применяется на каждом этапе цикла разработки ПО. В последнее время она приковывает к себе пристальный интерес. Управляющий консультант Excelon Development Мэтью Хеуссер рассказывает на портале TechBeacon об основных направлениях ее развития.

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

1. Открытые архитектуры

Поскольку популярность облачных вычислений растет, «язык» тестирования производительности отходит от браузера в сторону TCP/IP и других интернет-протоколов. «Веб-сервисы и нативные мобильные приложения только ускоряют эту тенденцию, доказывая, что генератором трафика может быть не только веб-браузер, — отметил Леандро Мелендес, консультант по тестированию производительности Qualitest. — Времена простой записи нагрузочных тестов через браузер и их воспроизведения подходят к концу, если уже не закончились». Слова эксперта означают, что все большее значение имеет слаженная работа составляющих и их изолированное тестирование производительности — от нагрузки до мониторинга и отладки. Одним из ключевых элементов такой открытой архитектуры будет облако.

2. Нативные облачные инструменты

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

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

3. Самообслуживание

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

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

4. SaaS-инструменты

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

5. Меняющиеся требования

В классическом тестировании приложений вам часто приходилось строить догадки, насколько отзывчивым будет ПО, как оно будет использоваться, придумывать для него требования и соглашения об уровне обслуживания (SLA) и затем в соответствии с этими требованиями выполнять тестирование. Напротив, ИТ-отделы, ориентированные на DevOps, подходят к рассмотрению требований к производительности более гибко — они могут меняться со временем.

И даже традиционные требования все больше зависят от сложности сценариев применения. «Опыт клиента с мобильным 3G-телефоном может сильно отличаться от опыта пользователя ноутбука в 100 милях от дата-центра, — сказала Вики Джавелли, директор по управлению продуктами для проектирования производительности Micro Focus. — Однако оба ожидают, что система будет работать».

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

6. Синтетические транзакции

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

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

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

7. Общие системные данные

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

Консультант по инженерии производительности New Relic Ребекка Клинард предлагает передавать результаты теста производительности в инструмент мониторинга, используемый как для тестирования, так и для производственной среды. Эти данные могут включать в себя журналы, анализ APM, данные фронтэнда, производительность микросервисов, производительность базы данных и т. д. Они позволят проводить «совместный анализ» с возможностью детализации. Это может предотвратить болезненные повторные тестовые запуски, сократить время отладки и исключить повторное тестирование с учетом изменений. Мелендес предлагает транслировать данные дашборда на веб-страницу, чтобы их могла видеть вся команда или любой заинтересованный сотрудник.

8. Тестирование в производственной среде

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

Для мобильных приложений можно применять так называемое «канареечное развертывание», в то время как для тестирования ПО для ноутбуков в производственной среде обычно задействуются флаги функций. Функции можно менять в базе данных или файле, что позволяет изменять конфигурацию без перекомпиляции. Некоторые инженерные команды даже выполняют непрерывную доставку, отправляя каждое изменение в коде в производство (если оно проходит автоматические тесты), но ПО с новым кодом будет работать только на компьютерах избранных внутренних сотрудников, которым оно будет подключено с помощью флагов функций.

Другие стратегии тестирования в производственной среде включают сплит-тестирование A/B, инкрементное развертывание и сине-зеленое развертывание.

9. Хаос-инжиниринг

Первоначально инструмент Chaos Monkey был разработан Netflix, но затем она перевела его в разряд Open Source. Он предназначен для выявления устойчивости работы служб в производственной среде путем их случайного отключения и проверки того, что у них после этого сломалось. Это позволяет командам встраивать в свои системы истинное резервирование и повышать устойчивость за счет устранения единичных точек отказа.

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

10. Машинное обучение, искусственный интеллект и анализ мнений

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

Инженерия производительности: тренд или охота за привидениями?

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