Хто ж такі аналітики продуктивності, Performance Engineers і Performance Testers? Ці поняття доволі рідко зустрічаються в інформаційному просторі, хоча об’єднують в собі одну дуже корисну професію, про яку розповів наш колега Вадим Волков.
Після питання «Ким тим працюєш?» зазвичай відразу запитують: «Що це? Чим ти займаєшся?». Людям, які не надто заглиблюються в ІТ-контекст, я пояснюю свою роль на реальних прикладах. Мабуть, багато хто опинявся в ситуації, коли інтернет-магазин влаштував масштабний розпродаж, вийшло довгоочікуване оновлення улюбленої онлайн-гри або відкрилася реєстрація до посольства на подачу документів для візи. Ви хочете купити, пограти, зареєструватися, але не можете, тому що сайти «підвисають» або взагалі не працюють через велику кількість бажаючих. Користувачів це дратує, а бізнес зазнає збитків і втрачає лояльність.
Сутність моєї професії полягає в тому, щоб подібних збоїв не було. Performance Engineer допомагає побудувати ефективні комп’ютерні системи, які працюють швидко й стабільно.
Продуктивність — одна з ключових характеристик якісного софту: користувачі не зможуть належно оцінити зручність та красу сайту, асортимент магазину, графіку та сюжет гри, якщо продукт працює повільно чи не працює взагалі.
Хочу відразу визначитися з термінологією. Іноді розмежовують тестування продуктивності і аналіз (оптимізацію) продуктивності. У першому випадку професія передбачає лише вимірювання того, як працює система, потім ці дані передати комусь, хто буде вивчати, чому працює не так, як хотілося б. У другому — не тільки виміряти, але й з’ясувати, чому працює повільно або хоча б допомогти це зробити. Однак, ми з колегами вважаємо, що тільки тестування продуктивності буде достатньо для новачків у професії Performance Engineer.
Подальший розвиток аналітика продуктивності вимагає здатності самостійно знаходити проблемні місці в досліджуваній системі. Нижче я буду використовувати всі терміни (і аналітик, і тестувальник, і performance engineer), розуміючи під ними одну й ту саму роль.
Витоки професії
Проблеми продуктивності розглядали й тоді, коли комп’ютери тільки з’являлися. Так, вже у 1968 році було опубліковано класичну статтю Роберта Міллера про вплив швидкості роботи комп’ютерних систем на користувача — Response time in man-computer conversational transactions. З того часу комп’ютери значно змінилися, але людина залишилася влаштованою так само, і вимоги, зібрані в цій статті, досі застосовуються для оцінки продуктивності.
Обов’язки Рerformance Engineer
На мою думку, це одна з найбільш різнопланових професій в ІТ. Дуже часто, навіть на великому проєкті є тільки один аналітик продуктивності. З одного боку, він може вільно вибирати методи, технології, інструменти. З іншого боку, це велика відповідальність: якщо обрав якийсь підхід, а він не спрацював, то й відповідати за це тільки тобі. Крім того, на Performance Engineer лежить відповідальність відразу за декілька напрямків, які він веде від моменту старту проєкту і до кінця.
1. Робота інженера продуктивності починається на стадії збору бізнес-вимог. Так, зазвичай цим займаються бізнес-аналітики, але гарний інженер може покращити вимоги, розуміючи, як вони потім будуть перевірятися.
Уявімо клієнта, який хоче зробити сервіс продажу авіаквитків. З мого досвіду, запит на продуктивність кінцевого продукту надходить приблизно такий: «Ми хочемо, щоб сервіс працював швидко і не «падав» під навантаженням». Такі вимоги не дуже добре визначають, які саме характеристики мають бути в системи. Тому аналітик продуктивності ставить додаткові питання і уточнює нюанси. «Скільки користувачів ви хочете обслуговувати одночасно?», «Що вони можуть робити: просто шукати квитки, бронювати, здійснювати оплату (це все різне навантаження на систему)?», «Яка кількість ключових дій користувачів очікується в одиницю часу?», «За скільки секунд повинна завантажуватися одна сторінка?» та ін. Якщо у бізнесу немає уявлення, що таке «швидко», Performance engineer допомагає визначити конкретні вимоги, ґрунтуючись на дослідженнях взаємодії людини і комп’ютера, а також стандартах в індустрії.
2. Іноді аналітику продуктивності вдається взяти участь в обговоренні майбутньої архітектури рішення. Припустимо, проєктується частина системи, яка має обробляти повідомлення від користувачів і віддавати їх кудись далі. Архітектор будуватиме дизайн-системи, спираючись і на вимоги до продуктивності в тому числі. Але точно не завадить, якщо поруч буде Performance Engineer, який запитає «Яку інтенсивність повідомлень ви очікуєте? Чи враховує її ваша архітектура?». А дуже досвідчений РЕ зможе оцінити архітектуру системи і запропонувати необхідні зміни.
3. Основна мета perfomance-тестів — зрозуміти й виправити причини повільної роботи системи. Для цього проводиться моніторинг показників «заліза» й ПЗ. Налаштування моніторинга інфраструктури часто виконує performance engineer, хоча це можуть робити і DevOps-інженери.
4. Далі йде процес розробки і перевірка готових частин продукту. Завдяки ітеративним підходам вивчати продуктивність — швидкість, стабільність і масштабованість продукту — можна вже на стадії, коли готовий хоча б мінімальний код. І це дуже гарний варіант розвитку подій. «Заходити» з perfomance-тестами тільки перед релізом — погана практика. Звичайно, це краще, ніж нічого, але вирішення проблем з продуктивністю часто потрапляє в 2/3 слогану студії Артемія Лєбєдева — «довго й дорого» (і не факт, що в підсумку все буде добре).
5. Після отримання результатів тестів починається, на мій погляд, найцікавіше — аналіз даних. Це дуже значна частина обов’язків аналітика продуктивності, на яку в середньому витрачається половина робочого часу. Тут завданням максимум для інженера буде визначити, що обмежує продуктивність системи і виправити це вузьке місце. Якщо після цього продукт не відповідає вимогам, потрібно шукати і прибирати обмеження далі. «Намилити, змити, повторити». Іноді буває, що самотужки неможливо зрозуміти причину низької продуктивності. В такому випадку потрібно виконати завдання-мінімум: зібрати інших членів команди для пошуку проблеми і всіма силами допомагати колегам її розв’язувати.
Якщо коротко, то до кола обов’язків Performance Engineer входять не лише тести продукту, але й багато іншої підготовчої та аналітичної роботи. При цьому, головне — це турбота про те, наскільки комфортно буде кінцевому користувачу працювати з системою.
Необхідні скіли
Те, що я зараз буду перераховувати, не є базовим набором для новачка. Це компетенції вже «дорослого» performance інженера і орієнтир, до чого прагнути.
Головна риса інженера продуктивності — аналітичний склад розуму або здатність робити висновки виходячи з фактів. Якщо цього немає, то в професіїї буде не дуже комфортно, оскільки вся робота побудована на аналізі інформації та висновках.
Взагалі, спеціальність аналітика продуктивності знаходиться на перетині трьох ІТ-професій:
частина тестування, але, як я вже, зазначив, доволі специфічна. Тому аналітику продуктивності необхідно знати й правильно застосовувати методологію тестування навантажень.
в спеціальності присутня велика частина від адміністрування. Щоб аналізувати продуктивність, інженеру потрібно знати весь стек роботи систем: вд мереж і «заліза», хмар і віртуалізації, до рендерингу в браузері. Крім того, потрібно розуміти роботу опеційних систем, web- і app-серверів, баз даних, runtime високорівневих мов і як все це налаштувати для досягнення потрібних результатів продуктивності.
без навичок розробника також не обійтися: performance інженер має аналізувати код і роботу додатку з пам’яттю. Щодо безпосереднього написання коду, то навантажувальні скрипти — це все ж таки не про програмування, хоча багато з них пишуться на «серйозних» мовах (C у LoadRunner, С# у Visual Studio). Проте часом трапляється так, що існуючих інструментів не вистачає і треба писати доповнення (або взагалі власні інструменти) з нуля — ось це вже «справжня» розробка.
Self-менеджмент і трохи project-менеджменту. Аналітик продуктивності часто працює один на проєкті і в нього немає тімліда, який буде допомагати. Тому важливо вміти планувати свою зайнятість, розуміти строки і вкладатися в них. Знання процесу розробки теж знадобляться, а гарний аналітик продуктивності може ще й зробити його кращим.
Комунікативні навички. Щоб довести продуктивність до ідеалу, performance engineer спілкується з великою кількістю людей. Для нього важливо зрозуміло висловлювати свої думки і трактувати отримані результати для колег. Крім того, спілкуватися з командою і клієнтами доводиться англійською мовою.
Також стануть в нагоді навички бізнес-аналізу, щоб зрозуміти потреби клієнта, бізнесу і як перетворити їх на вимоги.
Необхідні основи статистики і обробки даних. Performance Engineer постійно працює з даними, іноді їх дуже багато. Методи збору й обробки, приниципи роботи з даними — все це маст хев.
Бажання вчитися і розвиватися. Технічний горизонт performance інженера нескінченний. Щоб вміти аналізувати роботу комп’ютерних систем, в ідеалі, потрібно знати все про все. Звичайно, докладно розбиратися в усіх доменах нереально, однак при цьому можна вибрати ту частину технологічного стеку, яка подобається більше і заглиблюватися в неї. Так комусь подобається оптимізувати роботу з базами даних, хтось може бути спеціалістом з client-side продуктивності, хтось іде вглиб «хмар». В цьому, на мій погляд, і полягає краса професії: коли з’являється відчуття, що хотілося б розвиватися далі, це завжди можна зробити. Така багатопрофільність визначає рівень аналітика продуктивності: чим більше знаєш і вмієш, тим краще можеш визначити проблемні місця і ефективніше їх виправити.
Кар’єрний шлях
Історії дуже різні, але є й закономірності. Кілька років тому, ми у відділі провели дослідження і з’ясували, що третина людей приходить до нас із розробки і адміністрування, ще третина — з тестування, а інші «стартують» з performance інженерії. Я особисто починав з функціонального тестування, а потім перейшов до тестування продуктивності.
На мою думку, починати як Performance Engineer дуже класно, тому що спеціальність багатопрофільна, можна зрозуміти роботу різних дисциплін і отримати гарну технічну базу. Ті, хто потім хоче спробувати свої сили в іншій професії, йдуть переважно у розробники або модний нині Site Reliability Engineering.
Домени
Найчастіше РE працюють з доменами, де є високе користувацьке навантаження (електронна комерція, стримінгові медіа на зразок Netflix та ін.). Або ж у тих проєктах, де швидкість є критичною для роботи системи. До речі, високе користувацьке навантаження — це не завжди люди. Це може бути, наприклад, ІоТ з великою кількістю пристроїв і потоком даних, які надходять з датчиків і потребують обробки.
Навчання
Я не зустрічав навчальні заклади, де викладають конкретно цю спеціальність. Все тому, що професія комплексна. Як один з варіантів — спеціальність « Обчислювальні машини, системи і мережі» на КСіМ в БДУIР, там дають найбільш близьку до професії освіту. Там вивчають роботу «заліза», мереж і операційних систем, вчать оптимізувати код. А взагалі тут будь-який ІТ-бекграунд стане в нагоді, все одно доведеться доучуватися і набиратися досвіду.
Література:
Основи методології тестування продуктивності можна опанувати за книгами 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 інженерах зростає. Можу провести аналогію з автоматизованим тестуванням. Я застав той час, коли його майже не існувало і всі вважали, що в ньому немає потреби, адже є мануальні тести. А потім стало зрозумілим, що без автоматизації ніяк і тепер це тренд, зараз намагаються якомога більше тестування автоматизувати, професія користується величезним попитом. Схожі зміни я спостерігаю і в своїй спеціальності.
Працювати з продуктивністю важливо, оскільки вона сильно впливає на успішність системи. «Падіння» додатку під навантаженням, навіть на незначний термін, може спричинити великі фінансові втрати, повільна робота — відтік користувачів і недоотримання прибутків. Особливо це помітно в сфері електронної комерції: навіть невеличке прискорення сайту призводить до зростання конверсії. При цьому виправлення проблем продуктивності в системі, яка вже працює, може зайняти довгий час і коштувати дуже дорого.
