Кто такой Performance Engineer? Обзор изнутри от Вадима Волкова

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Домены 

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

Обучение  

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

Литература: 

• Основы методологии тестирования производительности можно освоить по книгам 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 инженерах растет. Могу провести аналогию с автоматизированным тестированием. Я застал то время, когда его почти не было и все считали, что это делать не нужно, ведь есть мануальные тесты. А потом стало понятно, что без автоматизации вообще никуда и теперь это тренд, сейчас стараются как можно больше тестирования автоматизировать, профессия очень востребована. Похожие изменения я наблюдаю в своей специальности.  

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