Конференция по DevOps практикам — DevOps Fest, 20-21 марта. Cпикеры и доклады на сайте >>
×Закрыть

Портрет перформанс-інженера

Мене звати Андрій і вже чотири роки я займаюсь перформанс-тестуванням та оптимізацією. Кар’єру починав як Java-розробник, але дуже швидко перейшов на темну сторону нефункціонального тестування. Мав справу з різноманітними продуктами, переважно у сфері e-commerce, працював із різними стеками (від .NET та Java до Node.js та Python) і тулами (від JMeter та Gatling до HP Load Runner). Зараз займаюся перформанс-тестуванням бекенду та оптимізацією клієнтської частини продукту в компанії AB Soft (Одеса).

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

Дисклеймер. У статті зустрічаються англіцизми та ІТ-жаргонізми, котрі я намагався звести до мінімуму але, на жаль, поки що треба шукати баланс між суто українським текстом і текстом, що нормально сприймається людиною, яка працює в ІТ-сфері й використовує ці слова у повсякденні задля збереження цілісності сприйняття думки автора. Стаття не претендує на об’єктивність. Вона містить лише моє власне бачення галузі та особисті думки про специфіку професії перформанс-інженера.

Коротко про перформанс-тестування

Оскільки ця стаття про роботу перформанс-інженера, то нам не уникнути розмови про перформанс як вид тестування.

Що це таке?

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

  • швидкість обробки запитів;
  • рівень використання виділених ресурсів;
  • стабільність роботи;
  • здатність реагувати на зміну рівня навантаження тощо.
Існує чимало типів перформанс-тестів, що мають на меті визначення однієї або більше із зазначених характеристик. У кожного з них власна специфіка планування, створення та проведення. Можливо, якщо ця тема буде цікавою аудиторії, я розгляну її в окремій статті.

Навіщо потрібен перформанс?

В епоху Web 2.0 стрімкий розвиток технологій та ринку портативних пристроїв дає можливість будь-кому споживати контент та отримувати послуги будь-де та будь-коли. Кожного року гіганти індустрії задають нові стандарти якості для того, аби кінцевий користувач отримував те, що хоче, та якнайшвидше: моментальна реєстрація та оплата, покупки та бронювання в один клік, стримінг 4К відео.

Перформанс-характеристики системи впливають на формування досвіду використання системи кінцевим користувачем. Вони не без підстав виділені як складові частини моделі якості продукту (див. ISO/IEC 25010:2011). Саме швидкість надання послуги може бути вирішальним фактором під час вибору користувачем між двома її постачальниками.

Ефективність та швидкість роботи системи стали визначальними для бізнесу. Задоволений користувач приносить гроші, тому битва за нього — на секунди. Звідси і починається історія про впровадження перформанс-тестування.

Однак самого бажання поліпшити перформанс замало. Усе починається з формування правильних вимог і цілей. Якщо запитати в людини з бізнесу: «Навіщо Вам перформанс-тестування?», то зазвичай можна почути щось на кшталт:

  • «Треба, щоб було швидко»;
  • «Хочемо знати, скільки користувачів витримає наш production»;
  • «Ти ж тут перформанс-інженер, от і скажи, що нам робити».
Жоден з цих варіантів у такому форматі не вартий часу, бо не має ніякого зв’язку з дійсністю й не призведе до поліпшення продукту. Але в певному розумінні вони визначають напрямки, у яких можна й треба працювати для досягнення реальних результатів.

Стереотипи

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

Ілюстрації: Дмитро Яценко

Стереотип 1. Перформанс-тестування аналогічне DDoS-атаці

Усе, що треба, — запустити якомога більше потоків, які хаотично навантажуватимуть сервери твоєї системи. ОК, ми запустили такий тест, наша система померла через 10 секунд. Яка користь з таких результатів для тебе як інженера з нефункціонального тестування, для команди й для бізнесу загалом?

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

Тут працює принцип «Роби як треба або не роби зовсім», інакше тільки змарнуєш гроші й час замовника.

Стереотип 2. Головне — функціонал, що працює. Неважливо, як швидко користувач отримає результат

Для більшості бізнес-доменів швидкість надання послуги — це невід’ємна частина самої послуги. Найпоширеніший приклад — електронна комерція. Інтернет-магазини, онлайн-гемблінг, трейдинг та інші високонавантажені системи.

Тут знову згадуємо про концепцію з попереднього стереотипу. Моделювання поведінки юзерів дає нам змогу прогнозувати досвід користування нашим продуктом. Бо саме це хвилює бізнес. Не мілісекунди дають прибуток, а користувачі й задоволення їхніх потреб конвертуються в гроші.

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

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

Стереотип 3. Для виконання перформанс-тестування треба декілька годин перед деплоєм

Насправді перформанс-тестування — це тривалий і ресурсозатратний процес, який іноді складно вкласти в часові межі, установлені різними «гнучкими» методологіями розробки.

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

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

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

Стереотип 4. Більшість проблем зі швидкодією можна розв’язати завдяки масштабуванню

Навіщо витрачати час на оптимізацію коду, конфігурацію кешу, пулів з’єднань тощо? Набагато простіше подвоїти кількість серверів або збільшити кількість оперативної пам’яті. Не завжди очевидне і просте рішення є правильним. Адже що більшу інфраструктуру ми маємо, то більше за неї платить замовник. А це не те, на що він радо витрачатиме свої гроші.

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

Головна ідея — найліпший стан швидкодії системи з оптимальним використанням ресурсів. Саме тому більш далекоглядним і ефективним вирішенням буде виділення ресурсів на повноцінне перформанс-тестування для налагодження та оптимізації продукту.

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

Часто на конференціях з QA/DEV-тематики, коли спілкуюся з людьми й кажу, що роблю, чую у відповідь: «О, я теж проводив перформанс-тестування в себе на проекті. Мій менеджер/продактовнер захотів його провести, але нам бракувало ресурсів. Я поставив Apache JMeter і зі свого ноута навантажив наш QA».

Орієнтовно за таким сценарієм розвиваються події, коли не перформанс-команда намагається знайти розв’язок поставлених бізнесом завдань, приклад яких я озвучив на початку.

Насправді спектр завдань перформанс-інженера дуже широкий і поєднує в собі навички багатьох інших професій.

Хто такий перформанс-тест-інженер?

Я окреслив абстрактний портрет людини, яку можна назвати перформанс-тест-інженером й основні проблеми в цій галузі. У жодному разі не претендую на об’єктивність у цьому питанні — це лише узагальнення персональних спостережень і досвіду. Ви можете погоджуватися зі мною або мати іншу думку, про яку я залюбки прочитаю в коментарях.

Термінологія, тайтли та співбесіди

Різні джерела теоретичної інформації не завжди узгоджують між собою, оскільки кожне з них створили автономно. Звідси й маємо по три різні назви для одного типу тестів (наприклад, longevity, endurance, CHO-тест). У галузі перформанс-тестування це окрема тема для холіварів. До відмінностей у термінології додається «збірна солянка» з підходів до створення моделей навантаження, генерації навантаження й аналізу отриманих даних. Така суміш власного й запозиченого досвіду іноді може призвести до неправильно впроваджених процесів. Найгірше те, що про це може не здогадуватися не лише керівництво, а й перформанс-інженер, який будував ці процеси.

Аналогічна ситуація з означенням, хто такий перформанс-інженер. Причина цього — велика кількість активностей та обов’язків, які поєднує в собі ця позиція. Саме тому на рівні лінійного й високого менеджменту часто бракує перформанс-грамотності. У багатьох є загальне уявлення про діяльність розробника: він пише код; або QA-спеціаліста: він шукає дефекти в написаному коді. З перформансом усе складніше, тому до обов’язків перформанс-інженера також належить нести світло знань про специфіку своєї роботи й перформанс загалом.

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

З популяризацією перформанс-тестування й зростанням попиту на таку експертизу на ринку з’явилося багато вакансій з різними назвами та змістом: Performance Tester, Performance Analyst, Performance QA Engineer, Load Engineer тощо. Зазвичай за описом вимог у вакансії відразу можна визначити, має компанія уявлення про перформанс чи ні. Ось абстрактний чеклист підозрілої перформанс-вакансії:

  • практично скопійована загальна інформація з англомовних ресурсів про перформанс;
  • перелік усіх можливих інструментів для генерації навантаження й моніторингу;
  • відсутність подробиць про проект.

Якщо вакансія складається лише з цих пунктів, швидше за все, у компанії не мають уявлення про перформанс. Це означає, що ви перший потенціальний спеціаліст цієї галузі, якого вони наймають. Постає запитання: хто має бути присутній на співбесіді для виявлення вашої компетентності? У правильній компанії матимемо розмову зі спеціалістами з різних команд OPS/DEV/QA про процеси й специфіку розв’язання тієї чи іншої проблеми, пов’язаної з перформансом. У найгіршій ситуації ми отримуємо співбесіду з членом команди автоматизації тестування про bash, git, запити до БД, основи ${ваша_улюблена_мова_програмування} та інші базові речі. Складно об’єктивно оцінити результати такої співбесіди, навряд чи хоча б одна зі сторін матиме якусь користь з цього. Іноді може виявитися, що впровадження перформанс-процесів на конкретному проекті взагалі не потрібне.

Інтеграція в проект

Перформанс-тестування потрібне лише тоді, якщо система очікувано одержуватиме достатні об’єми навантаження під час свого циклу використання. Інакше впровадження перформанс-процесів буде лише витратою часу й грошей. Тому зазвичай перформанс-інженер працює з великими ентерпрайз-проектами з розподіленою архітектурою, двома або більше продуктами тощо. Здавалося б, що більший проект, то більший штат перформанс-інженерів. На жаль, це не так. Що вища кваліфікація інженера, то менше таких спеціалістів потрібно на проекті. Тому зазвичай штат інженерів на одиницю проектів — 1–2 (значення не абсолютне й може відрізнятись у конкретному випадку). Можна виділити різні способи інтеграції перформанс-інженера в проект.

Інженер за запитом

Інженер/інженери не прив’язані до конкретного проекту. Окремий юніт спеціалістів працює всередині компанії (a.k.a Center of Excellence), що як відділ швидкого реагування перекидають з проекту на проект для створення перформанс-процесів і надання відповідної експертизи. Популярна практика в аутсорс-компаніях з великою кількістю проектів, коли просто не вигідно тримати досвідченого спеціаліста на одному проекті. В Україні є компанії, які імплементували такий підхід.

Виділений інженер

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

Повна інтеграція в організацію

Цей варіант ідеальний і тим самим наближений до неможливого. Інженера інтегрують у команду розробки, але він також відповідає за інтеграцію перформанс-процесів на рівні організації. Для цього бізнес і менеджмент мають бути зацікавленими в поліпшенні перформансу з перших етапів розробки ще на етапі проектування. Сюди також належить формування не тільки функціональних вимог до реалізації, а й вимог до перформансу продукту, який розробляють. Для цього треба розвивати перформанс-культуру в цілій організації, зацікавити бізнес, розробників, QA-спеціалістів і всіх інших, змусити їх задумуватися про перформанс під час виконання їхніх повсякденних завдань.

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

Портрет

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

Бізнес-аналіз

Більшість літератури з перформансу радить відразу вирушати до бізнес-аналітиків по готові профілі користувачів і докладну статистику користування продуктом, але зазвичай потрібної інформації або немає, або вона зовсім не в тому стані, щоб бути якось корисною. Цю інформацію нерідко доводиться збирати по крихтах і доповнювати емпіричними даними, зібраними власноруч. Доступні дані про інші продукти в конкретному бізнес-домені також можуть бути корисними для формування вимог до вашого продукту.

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

UX-аналіз

Як уже зазначав, ми маємо справу з нефункціональним тестуванням. Воно нерозривно пов’язане з досвідом кінцевого користувача (UX). Звичайно, правильне функціювання продукту — це найвищий пріоритет, але його продають користувачеві завдяки іншим характеристикам: надійності, безпеці даних, зручності інтерфейсу, швидкодії тощо.

Варто зазначити, що перформанс з технічного огляду й з погляду користувача — це дві великих різниці. Коли ми говоримо про серверну частину, то оперуємо такими поняттями як затримка (latency), час відповіді (response time), пропускна здатність (throughput). Але для користувача, який взаємодіє з сервісом через клієнт, ці поняття нічого не значать. Тут важливо не наскільки «швидкий» наш продукт, а наскільки швидким його сприймає наш користувач.

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

Системний аналіз

Перформанс-тестування немає нічого спільного з black-box-тестуванням. Якщо інформація про середовище й структуру системи з якоїсь причини недоступна, результати тестування будуть малоінформативними. До стратегії перформанс-тестування мають входити не лише подробиці про структуру системи загалом, а й логічна, фізична, мережева й програмна архітектура production-середовища та виділеного середовища для тестування перформансу. Інакше неможливо хоча б приблизно екстраполювати отримані результати й робити якісь висновки про відповідність системи визначеним вимогам.

Нерідко перформанс-інженер — один з небагатьох членів проекту, хто має повне уявлення про продукт як цілісний організм. Без такого бачення прогнозувати й виявляти вузькі місця в системі неможливо. Це й відрізняє перформанс-інженера від інших гравців команди. Зазвичай вони починають перформанс-кар’єру, перейшовши з іншої спеціальності, і тому в них може бути зміщений фокус на певному баченні системи. Наприклад, інженери, які виконували автоматизацію тестування клієнтської частини, бачать систему починаючи з клієнта, розробники аналізують систему з ядра, з коду, що виконується на сервері. Це не проблема конкретного спеціаліста, а самого сприйняття системи, межі якого формуються під впливом тієї чи іншої спеціальності. Але тільки знайшовши певний баланс, можна ефективно локалізувати проблему, тому здатність бачити систему повністю та її архітектуру з різних боків, вважаю, — найважливіша навичка перформанс-інженера.

Аналіз даних

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

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

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

Комунікація

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

  • зібрати всі потрібні дані й запити бізнесу та найвищого менеджменту;
  • зібрати інформацію про структуру системи;
  • домовитися про виділене середовище (релевантне до production-середовища) для проведення тестів;
  • скоординувати взаємодію всіх команд, залучених до процесу тестування;
  • взаємодіяти з DEV/QA/OPS-командою під час аналізу отриманих помилок;
  • презентувати отримані дані й висунуті гіпотези замовникові;
  • проводити навчальні сесії для всіх охочих членів команди, щоб підвищити рівень перформанс-грамотності.

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

Програмування

Створення справжніх перформанс-тестів далеке від просто запису дій користувача через рекордер, який має майже кожна сучасна load-тула. Для написання тесту, що генеруватиме релевантне навантаження на систему, найпевніше, доведеться написати код з додатковою логікою, а також уміти читати й розуміти код, написаний розробниками.

Кожен проект має свою специфіку, у той час як load-тули покривають найбільш розповсюдженні сценарії, тому часто доводиться писати додаткові тули для автоматизації процесів (парсинг специфічних логів, генерація тестових даних у великому обсязі, попереднє налаштування середовища, збір кастомних метрик з віддалених інстансів) або розширення базового функціоналу тули (реалізація специфічного протоколу).

Перформанс-інженер не зобов’язаний володіти мовою програмування на рівні senior розробника, але, як мінімум, він має вміти читати та писати код для створення власного фреймворку з автоматизації процесів перформанс-тестування.

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

Замість висновків

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

LinkedIn

7 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Дуже професійно написана стаття! Крутяк! Дякую!

Хороша і правильна стаття!

По заголовку чуть было не подумал, что вы программист, занимающийся как раз оптимизацией производительности :)

Полностью поддерживаю развитие этой темы,
так же хотел бы порекомендовать книгу от уже упомянутого Brendan Greggа, «Systems Performance: Enterprise and the Cloud»
И телеграмм чат в котором обсуждаются вопросы тестирования производительности t.me/qa_load

Тоже работаю Performance engineer’ом и радует что такие статьи начинают появляться на ДОУ.
Немножко многословно на мой вкус и больше сконцентрировано на тестировании, чем на остальных процессах( capacity planning, оптимизация, root cause analysis)
Вот полезные ссылочки если кто интересуется темой:
MIT курс: ocw.mit.edu/...​ftware-systems-fall-2018
Блог Брендана Грегга Principal Performance Engineer’a в Netflix: www.brendangregg.com
Linux Perf tutorial: sandsoftwaresound.net/perf

Дякую. Стикаюсь з цими стереотипами щодня.

Крутяк! В закладки :)

Подписаться на комментарии