Хто такий Performance Engineer? Огляд зсередини від Вадима Волкова

Продовжуємо цикл матеріалів про ІТ-спеціальності. Кожну описує «типовий представник» — досвідчений фахівець і просто авторитетний колега, та сама людина, яка знає всі таємні куточки своєї професії. Ми сподіваємося, ці матеріали допоможуть школярам, студентам, перекваліфікантам, студентам і всім тим, хто зацікавлений у виборі ІТ-спеціальності. Цикл не тільки допоможе оцінити перспективи, а й дасть можливість краще зрозуміти індустрію і особливості професії зсередини. Обговорюйте і доповнюйте матеріал в коментарях, щоб зробити його ще корисніше.

Про професію розповідає Вадим Волков з EPAM.

 

Залишити коментар
Хто такий Performance Engineer? Огляд зсередини від Вадима Волкова

Продовжуємо цикл матеріалів про ІТ-спеціальності. Кожну описує «типовий представник» — досвідчений фахівець і просто авторитетний колега, та сама людина, яка знає всі таємні куточки своєї професії. Ми сподіваємося, ці матеріали допоможуть школярам, студентам, перекваліфікантам, студентам і всім тим, хто зацікавлений у виборі ІТ-спеціальності. Цикл не тільки допоможе оцінити перспективи, а й дасть можливість краще зрозуміти індустрію і особливості професії зсередини. Обговорюйте і доповнюйте матеріал в коментарях, щоб зробити його ще корисніше.

Про професію розповідає Вадим Волков з EPAM.

У моєї професії кілька назв: аналітик продуктивності, Performance Engineer, Performance Tester. І всі вони досить рідко зустрічаються в інформаційному просторі. Тому слідом за питанням «ким ти працюєш?» зазвичай відразу запитують: " Що це? Чим ти займаєшся?».

Людям, які не сильно занурені в ІТ-контекст, я пояснюю свою роль на реальних прикладах. Напевно, багато хто зустрічався з ситуацією, коли інтернет-магазин влаштував масштабний розпродаж, вийшло довгоочікуване оновлення улюбленої онлайн-гри або відкрилася реєстрація в посольство на подачу документів для візи. Ви хочете купити, пограти або зареєструватися, але не можете, тому що Сайти «виснуть» або взагалі не працюють через велику кількість бажаючих. Користувача це дратує, а бізнес зазнає збитків і втрачає лояльність.

Суть моєї професії полягає в тому, щоб подібних збоїв не було.  Performance Engineer допомагає побудувати найбільш ефективні комп’ютерні системи, які працюють швидко і стабільно. 

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

Хочу визначитися з подальшою термінологією.  Іноді тестування продуктивності і аналіз (оптимізацію) продуктивності розмежовують. У першому випадку професія передбачає тільки заміряти, як працює система, і віддати ці дані комусь, хто буде вивчати, чому працює не так, як хотілося б. У другому — не тільки заміряти, але й розібратися, чому працює повільно, або хоча б допомогти це зробити. Однак ми з колегами вважаємо, що навичок тільки тестування продуктивності буде достатньо для новачків в професії 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 входять не тільки тести продукту, але і багато іншої підготовчої та аналітичної роботи. При цьому головна мета — турбота про те, наскільки комфортно кінцевому користувачеві буде працювати з системою.  

Необхідні скіли

Те, що я зараз буду називати, не базовий набір для новачка. Це компетенції вже «дорослого» інженера і орієнтир, до якого потрібно прагнути.  

Головні якості інженера продуктивності — аналітичний склад розуму, або здатність з фактів робити висновки. Якщо цього немає, то в професії буде не дуже комфортно, позаяк в принципі вся робота будується на аналізі інформації та висновках. Взагалі спеціальність аналітика продуктивності знаходиться на стику трьох ІТ-професій:

  1. Частина тестування, але, як я вже описав, досить специфічна. Тому аналітику продуктивності необхідно знати і правильно застосовувати методологію навантажувального тестування;
  2. У спеціальності присутня дуже велика частина від адміністрування. Щоб аналізувати продуктивність, інженеру потрібно знати весь стек роботи систем: від мереж і «заліза», хмар і віртуалізації до рендеринга в браузері. Крім того, треба розуміти роботу операційних систем, web- і app-серверів, баз даних, runtime високорівневих мов і як це все налаштовувати для досягнення необхідних результатів продуктивності.     
  3. Без навичок розробника теж не обійтися: performance інженер має аналізувати код і роботу з пам’яттю програми. Що стосується безпосередньо написання коду, то навантажувальні скрипти — це все ж не про програмування, хоч багато з них і пишуться на «серйозних» мовах (C в LoadRunner, с# в Visual Studio). Але іноді буває так, що існуючих інструментів не вистачає і потрібно писати розширення (або взагалі свої інструменти) з нуля — ось це вже «справжня» розробка.

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

Комунікативні навички. Щоб привести продуктивність продукту до ідеалу, performance engineer спілкується з великою кількістю людей. Йому важливо зрозуміло викладати свої думки і трактувати отримані результати колегам. Крім того, спілкуватися з командою і клієнтами доводиться і англійською мовою. 

Також корисні будуть навички бізнес-аналізу, щоб зрозуміти потреби клієнта, бізнесу і як їх перетворити на вимоги.  

Необхідний основи статистики та обробки даних. Performance Engineer постійно працює з даними, іноді їх дуже багато. Методики збору та обробки, принципи роботи з даними — все це маст хев.   

Бажання вчитися і розвиватися. Технічний горизонт performance інженера нескінченний. Щоб вміти аналізувати роботу комп’ютерних систем, в ідеалі, потрібно знати все про все. Звичайно, глибоко розбиратися у всіх доменах нереально, але при цьому можна вибрати ту частину технологічного стека, яка подобається більше, і занурюватися в неї. Так комусь подобається оптимізувати роботу з базами даних, хтось може бути фахівцем з client-ide продуктивності, деякі йдуть в глиб «хмар». Це, на мій погляд, і є принадність професії: коли з’являється відчуття, що хотілося б розвиватися далі, Це завжди можна зробити. Така багатопрофільність визначає рівень аналітика продуктивності: чим більше знаєш і вмієш, тим краще можеш визначити проблемні місця в системі і ефективніше їх виправити.

По темі:

20 онлайн-курсів, де навчать бізнесу: від стратегії до Big Data

14 онлайн-сертифікатів від Google і IBM, щоб підвищити собі зарплату

Кар'єрний шлях 

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

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

Домен 

Найчастіше PE працюють з доменами, де є багатокористувацьке навантаження (tлектронна комерція, стрімінговое медіа типу Netflix тощо). Або в тих проєктах, де швидкість критична для роботи системи. До речі, «багатокористувацьке " навантаження — це не завжди люди. Наприклад, IoT з великою кількістю пристроїв і потоком даних, які «стікаються» з датчиків і потребують обробки.

Навчання  

Я не зустрічав навчальні заклади, де вчать конкретно цій спеціальності. Все тому, що професія дуже комплексна. А взагалі тут будь-який ІТ-бекграунд буде корисний, але все одно доведеться доучуватися і набиратися досвіду. 

Література: 

Ще один варіант навчання — курси. Наприклад, крім проєктної роботи я разом з колегами веду курс з основ Performance Optimization. На ньому ми розповідаємо тільки основи професії, а після студенти доучуються всередині компанії ще 3-6 місяців до того, як потрапити на проєкт. Звичайно, успіх такого навчання багато в чому залежить від бекграунду: чим більше людина спочатку знає і вміє, тим швидше вникне в нюанси й тонкощі.

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

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

Хочете повідомити важливу новину? Пишіть у Telegram-bot.

А також підписуйтесь на наш Telegram-канал — dev.ua | IT України.

Обговорення

Коментарів поки немає.