Метод визначення цільових показників продуктивності програмного забезпечення

Abstract

Development of the methods for the determination of the target indices for measuring the quality level , performance reliability is one of the important directions in the sphere of information technologies and, in particular, software engineering. Among the known methods we can distinguish the method of balanced management indicators, SMART-techniques, etc. GIST (Goals, Ideas, Step-Projects, Tasks) methodology it is the method of production planning, elaborated by I. Gilad former Google production manager. This methodology is aimed at reduction of the overhead cost for management, enhancement of the speed of development and creation of the products, which meet the requirements of the market and their subject area. Defining target performance indicators remains a pressing challenge for modern DevOps teams. They are frequently caught between two extremes: collecting thousands of time-series metrics, which inflates costs and alert noise, or, conversely, collecting too little data and missing performance regressions. Lightweight checklists such as the Four Golden Signals or RED/USE lower the entry barrier but remain static; they ignore business goals, service criticality, and lifecycle stage. The paper proposes to improve GIST (Goal Impact Stage Template) method for measuring software performance (GISTSP). Objective c of the study is to create and evaluate the method of target indices formation on the base of the methodology of metrics collection GIST. The suggested GIST method (Goal – Impact – Stage – Template) relies on a four-line “service passport” and a Coreplus-Plus metric library. By following a “collect only what you need” rule, GIST automatically generates Prometheus/Grafana configurations and alert rules. The approach was experimentally compared with Four GS, RED/USE, and AWS W-A on four testbeds (Web-API, Queue, Stream, Batch). Results show that required SLI coverage increased from 78 % to 92 %; daily metric volume decreased by 60 %; setup time was reduced by a factor of four, while the F₁-score for regression detection did not degrade. These findings indicate that GIST achieves a practic.

Розробка методів визначення цільових показників для вимірювання рівня якості, надійності продуктивності програмного забезпечення є одним з актуальних напрямів в галузі інформаційних технологій та, зокрема, в програмній інженерії. Серед відомих методів можна виділити метод збалансованих показників управління, SMART-методики тощо. Методологія GIST (Goals, Ideas, Step-Projects, Tasks) – це метод продуктового планування, розроблений І. Гіладом, колишнім продакт-менеджером Google. Вона спрямована на зменшення накладних витрат на управління, підвищення швидкості розробки та створення продуктів, які краще відповідають потребам ринку та їхній предметній області. Визначення цільових показників продуктивності є актуальним питанням для сучасних DevOps-команд. Вони часто опиняються між двома крайнощами — надмірним збиранням тисяч часових рядів, що збільшує витрати та шум в інформаційних повідомленнях щодо виявлення зменшення продуктивності, і навпаки — браком даних для своєчасного виявлення регресії продуктивності. Наявні «легкі» чек-листи (Four Golden Signals, RED/USE тощо) спрощують старт, але залишаються статичними й не враховують бізнес-цілі, критичність сервісу та стадію життєвого циклу. У статті запропоновано удосконалити метод GIST (Goal Impact Stage Template) для вимірювання продуктивності програмного забезпечення (GISTSP). Мета досліджень — створити й оцінити метод формування цільових показників на основі методології вибору метрик GIST. Такий метод здатний за кілька кроків генерувати мінімальний, але достатній і обґрунтований набір показників для конкретного сервісу. Запропонований метод ґрунтується на 4-рядному «паспорті сервісу» та бібліотеці шаблонів Core + Plus-метрик. Використовуючи правило «додай тільки те, що справді потрібно», GISTSP автоматично генерує конфігурацію Prometheus/Grafana й алерт-правила. Експериментальне порівняння з відомими методами Four GS, RED/USE та AWS W-A виконані на чотирьох стендах (Web-API, Queue, Stream, Batch). Результати показали, що покриття необхідних показників зросло з 78 % до 92 %; добовий обсяг даних скоротився на 60 %; час налаштування зменшився у 4 рази, при цьому міра виявлення регресії не погіршилася. Результати дослідження свідчать про те, що GISTSP забезпечує баланс між простотою старту та гнучкістю, необхідною для різних бізнес-цілей і середовищ.