Кто такой Performance Engineer, что делает, и какие еще названия у этой профессии

У моей профессии несколько названий: аналитик производительности, Performance Engineer, Performance Tester. И все они достаточно редко встречаются в информационном пространстве. Поэтому следом за вопросом «кем ты работаешь?» обычно сразу спрашивают: «Что это? Чем ты занимаешься?»

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

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

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

Хочу определиться с дальнейшей терминологией.  Иногда тестирование производительности и анализ (оптимизацию) производительности разграничивают. В первом случае профессия предполагает только замерить, как работает система, и отдать эти данные кому-то, кто будет изучать, почему работает не так, как хотелось бы. Во втором — не только замерить, но и разобраться, почему работает медленно, или хотя бы помочь это сделать. Однако мы с коллегами считаем, что навыков только тестирования производительности будет достаточно для новичков в профессии Performance Engineer.

Дальнейшее развитие аналитика производительности предполагает способность самостоятельно находить проблемные места в исследуемой системе. Ниже я буду использовать все термины (и аналитик, и тестировщик, и performance engineer), понимая под ними одну и ту же роль.

Истоки профессии

О проблемах производительности думали в то время, когда компьютеры только начали появляться. Уже в 1968 году была опубликована классическая статья о влиянии скорости работы компьютерных систем на пользователя –Response time in man-computer conversational transactions Роберта Миллера. Компьютеры с тех пор стали другими, но человек устроен так же, поэтому требования, собранные в этой статье, до сих пор применяются при оценке производительности.

Какие обязанности у Рerformance Engineer  

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

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

Представим себе клиента, который хочет сделать сервис продажи авиабилетов. По моему опыту запрос на производительность итогового продукта поступает следующий: «Мы хотим, чтобы сервис быстро работал и не „падал“ под нагрузкой». Такие требования плохо определяют, какие именно характеристики должны быть у системы. Поэтому аналитик производительности задает дополнительные вопросы и уточняет нюансы. «Сколько пользователей одновременно вы хотите обслуживать?», «Что они могут делать: просто искать билеты, бронировать, проводить оплату (это все разная нагрузка на систему)?», «Какое количество ключевых действий пользователей ожидается в единицу времени?», «За сколько секунд одна страница должна загружаться?» и др.  Если у бизнеса нет понимания, что такое «быстро», то Performance инженер помогает определить конкретные требования, основываясь на исследованиях взаимодействия человека и компьютера и стандартах индустрии.  

2. Иногда аналитику производительности удается поучаствовать в обсуждении будущей архитектуры решения. Допустим, проектируется часть системы, которая должна обрабатывать сообщения от пользователей и отдавать их куда-то дальше.  Архитектор будет строить дизайн-системы, основываясь, в том числе, и на требованиях в сфере производительности. Но точно не помешает, если рядом будет Performance Engineer, который спросит: «Какую интенсивность сообщений вы ожидаете? Ваша архитектура учитывает ее?» А очень скилловый PE сможет оценить архитектуру системы и предложить необходимые изменения. 

3. Основная цель perfomance-тестов — понять и исправить причины медленной работы системы. Для этого проводится мониторинг показателей «железа» и софта. Настройку мониторинга инфраструктуры часто делает performance engineer, хотя могут и DevOps-инженеры.  

4. Дальше идет процесс разработки и проверка готовых частей продукта. Благодаря итеративным подходам, изучать производительность (скорость, стабильность и масштабируемость продукта) можно уже на стадии, когда готов какой-то минимальный код. И это очень хороший вариант развития событий. «Заходить» с perfomance-тестами только перед релизом — плохая практика. Конечно, это лучше, чем ничего, но исправление проблем с производительностью часто попадает в  2/3 слогана студии Артемия Лебедева — «долго и дорого» (и не факт, что по итогу все будет хорошо).

Кто такой тестировщик. Обзор изнутри от Евгения Шидловского

По теме

Кто такой тестировщик. Обзор изнутри от Евгения Шидловского

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

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

Необходимые скиллы

То, что я сейчас буду называть, не базовый набор для новичка. Это компетенции уже «взрослого» performance инженера и ориентир, к которому нужно стремиться.  

Главные качества инженера производительности — аналитический склад ума или способность из фактов делать выводы. Если этого нет, то в профессии будет не очень комфортно, так как в принципе вся работа строится на анализе информации и заключениях. Вообще специальность аналитика производительности находится на стыке трех IT-профессий:

1. часть тестирования, но, как я уже описал, достаточно специфическая. Поэтому аналитику производительности необходимо знать и правильно применять методологию нагрузочного тестирования.
2. в специальности присутствует очень большая часть от администрирования. Чтобы анализировать производительность, инженеру нужно знать весь стек работы систем: от сетей и «железа», облаков и виртуализации до рендеринга в браузере. Кроме того, надо понимать работу операционных систем, web- и app-серверов, баз данных, runtime высокоуровневых языков и как это все настраивать для достижения требуемых результатов производительности.     
3. без навыков разработчика тоже не обойтись: performance инженер должен анализировать код и работу с памятью приложения. Что касается непосредственно написания кода, то нагрузочные скрипты — это все же не о программировании, хоть многие из них и пишутся на «серьезных» языках (C в LoadRunner, С# в Visual Studio). Но иногда бывает так, что существующих инструментов не хватает и нужно писать расширения (или вообще свои инструменты) с нуля — вот это уже «настоящая» разработка.

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

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

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

Необходимы основы статистики и обработки данных. Performance engineer постоянно работает с данными, иногда их очень много. Методики сбора и обработки, принципы работы с данными — все это маст хэв.   

Желание учиться и развиваться.  Технический горизонт performance инженера бесконечен.

Чтобы уметь анализировать работу компьютерных систем, нужно (в идеале) знать все обо всем. Конечно, глубоко разбираться во всех доменах нереально, но при этом можно выбрать ту часть технологического стека, которая нравится больше, и погружаться в нее. Так кому-то нравится оптимизировать работу с базами данных, кто-то может быть специалистом по client-side производительности, некоторые уходят вглубь «облаков». Это, на мой взгляд, и есть прелесть профессии: когда появляется ощущение, что хотелось бы развиваться дальше, это всегда можно сделать. Такая многопрофильность определяет уровень аналитика производительности: чем больше знаешь и умеешь, тем лучше можешь определить проблемные места в системе и эффективнее их исправить.

10 онлайн-курсов от технологических гигантов. Часть 1

По теме

10 онлайн-курсов от технологических гигантов. Часть 1

9 онлайн-курсов от технологических гигантов. Часть 2

По теме

9 онлайн-курсов от технологических гигантов. Часть 2

Карьерный путь 

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

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

На мой взгляд, начинать как Performance engineer очень классно, потому что специальность многопрофильная, можно понять работу разных дисциплин и набрать хорошую техническую базу. Те, кто потом хочет попробовать себя в другой профессии, уходят, в основном, в разработчики или в модный Site Reliability Engineering.

Домены 

Чаще всего РE работают с доменами, где есть многопользовательская нагрузка (электронная коммерция, стриминговое медиа типа Netflix и др.). Либо в тех проектах, где скорость критична для работы системы. Кстати, «многопользовательская» нагрузка — это не всегда люди. К примеру, IoT с большим количеством устройств и потоком данных, которые «стекаются» с датчиков и нуждаются в обработке.

Обучение  

Я не встречал учебных заведений, где конкретно обучают этой  специальности. Все потому, что профессия комплексная. Как один из вариантов, наиболее близкое к профессии образование дают, например, в БГУИР на КСиСе, специальность «Вычислительные машины, системы и сети». Там рассказывают про работу «железа», сетей и операционных систем, учат оптимизировать код. А вообще здесь любой IT-бэкграунд будет полезен, но все равно придется доучиваться и набираться опыта. 

Литература: 

• Основы методологии тестирования производительности можно освоить по книгам The Art of Application Performance Testing и Performance Testing Guidance for Web Applications.
•  Скриптование на самом популярном инструменте нагрузочного тестирования — Getting Started with JMeter — A Basic Tutorial. 
• Основы производительности сетей — High Performance Browser Networking. 
• Для аналитиков с опытом могу посоветовать книги Systems Performance — Enterprise and the Cloud и Guerrilla Capacity Planning.

Еще один вариант обучения — курсы. К примеру, помимо проектной работы я вместе с коллегами веду курс по основам Performance Optimization. На нем мы даем только основы профессии, а после студенты доучиваются внутри компании еще 3-6 месяцев до того, как попасть на проект. Конечно, успех такого обучения во многом зависит от бэкграунда: чем больше человек изначально знает и умеет, тем быстрее он вникнет в нюансы и тонкости.

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

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