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

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

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

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

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

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

Що це таке?

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

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

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

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

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

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

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

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

Стереотипи

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Різні джерела теоретичної інформації не завжди узгоджують між собою, оскільки кожне з них витворили автономно. Звідси й маємо по три різні назви для одного типу тестів (наприклад, довговічність, 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-мітинги. Перформанс-командою на проекті може бути один інженер, якому треба:

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

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

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

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

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

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

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

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

Опубліковано: 13/12/19 @ 11:00
Розділ Безпека

Рекомендуємо:

Веб-доступність. Що варто знати кожному Front-end розробнику і дизайнерові
Шифрування в базах даних SQL з можливістю пошуку
ІТ-волонтери: як викладач створив додаток про втрачену архітектурній спадщині Харкова
QA дайджест #40: лайфхаки автоматизації, добірка книг для тестувальників
9 способів чистити пошукові запити в Key Collector