Як ми створили систему моніторингу, що допомогла зрозуміти стан проєктів навіть C-level менеджерам

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

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

Поїхали! Уявіть собі сучасну технологічну компанію, яка одночасно розробляє кілька цифрових продуктів: мобільні застосунки, вебсервіси, бекенд-системи. У кожного проєкту є своя команда, свої завдання, і, звісно, свої проблеми. Усі ці команди використовують різні інструменти для управління завданнями, моніторингу якості коду, контролю процесів CI/CD та відстеження помилок у реальному часі.

На перший погляд, це здається типовим підходом у сучасному світі IT, але коли справа доходить до аналізу стану проєктів загалом, з’являються серйозні проблеми. C-level менеджери хочуть бачити узагальнену картину: як просувається розробка, які проєкти відстають від графіка, скільки часу потрібно до завершення. Однак інформація розкидана між інструментами — GitLab, Jira, SonarQube, Sentry, і для її отримання потрібно витратити багато часу.

Крім того, навіть якщо менеджер отримує звіт з одного з цих інструментів, це ще не означає, що він його зрозуміє. Технічні терміни, такі як Technical Debt Ratio, Maintainability Rating, Bug Escape Rate, Burndown Charts, звучать для нетехнічного користувача так само як квантова фізика для гуманітарія. Особливо це стосується проджект-менеджерів, які часто не мають технічного бекграунду.

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

Проблеми, які ми вирішували

Ми зіткнулися з кількома основними викликами:

1. Розрізненість даних. Кожен інструмент давав свою частину інформації, але об’єднати їх було непросто:

• GitLab показував лише CI/CD процеси.
• Jira дозволяла відстежувати задачі, але не давала розуміння їхнього впливу на загальний стан проєкту.
• SonarQube фокусувався на якості коду, але його звіти були занадто технічними.
• Sentry відстежував помилки, але працював ізольовано від інших систем.

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

3. Відсутність прозорості для керівництва. C-level менеджери не могли швидко отримати узагальнене уявлення про стан усіх проєктів у компанії, що заважало стратегічному плануванню.

Рішення: створення універсального дашборду

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

1. Об’єднання даних з усіх основних джерел. Дані з GitLab, Jira, SonarQube та Sentry мали бути зібрані в одному місці, щоб більше не потрібно було перемикатися між кількома інструментами. Ми прагнули створити систему, яка автоматично збирає, агрегує та візуалізує ці дані в реальному часі.

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

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

Технологічний стек

Для реалізації цього рішення ми обрали Prometheus як систему збору метрик і Grafana як платформу для їхньої візуалізації. Також були розроблені кастомні експортери, які підключалися до API GitLab, Jira, SonarQube та Sentry, збираючи дані у форматі, який підтримує Prometheus.

Основні причини вибору цієї архітектури:

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

Як це працює? Уявіть, що всі ключові метрики проєкту — від стабільності збірок у GitLab до кількості відкритих багів у Jira — автоматично збираються, передаються в Prometheus і виводяться на дашборд у Grafana. Наприклад:

• GitLab передає дані про частоту успішних збірок (Build Success Rate) і середній час розгляду Merge Request.
• Jira показує кількість відкритих, закритих і критичних завдань.
• SonarQube надсилає метрики, такі як покриття тестами, технічний борг та кількість дублювань у коді.
• Sentry інформує про частоту помилок і їхній тип.

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

Як це було реалізовано

Розповідь далі буде йти на прикладі POC-моделі, яку розробили на ранніх етапах реалізації проєкту. Фінальний продукт більш секьюрний, складніший та надійніший.

Етап 1. Визначення ключових метрик

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

Ми організували серію зустрічей із командами розробників, проджект-менеджерів, CTO та Director of engineering, щоб узгодити пріоритети та розібратися в потребах кожної зі сторін.

У результаті ми зосередилися на більш ніж 50 метриках, ось деякі найбільш інформативні з них:

• Build Success Rate (GitLab) — відсоток успішних збірок, який дозволяє оцінити стабільність процесів CI/CD. Ця метрика стала однією з основних, адже стабільність збірок є ключовим показником якості коду та конфігурацій, які команди інтегрують у репозиторій.
• Bug Count (Jira) — кількість відкритих багів, що сигналізує про якість продукту. Ми включили цю метрику, оскільки вона дозволяє оцінювати стан проєкту з погляду кінцевого користувача. Зростання кількості багів може свідчити про погіршення якості коду або недостатнє тестування.
• Code Coverage (SonarQube) — частка коду, покрита тестами, яка свідчить про якість тестування. Це один з основних показників, що демонструє, наскільки добре код захищений автоматизованими тестами. Ми вирішили також відстежувати покриття окремо для різних напрямів (Frontend, Backend, Mobile).
• Technical Debt Ratio (SonarQube) — співвідношення технічного боргу до часу розробки. Цей показник дозволяє оцінити, скільки часу буде потрібно на виправлення існуючих проблем у коді, якщо вони накопичуватимуться без оптимізації. Технічний борг — це одна з найбільш вагомих метрик для довгострокового планування.
• Error Rate (Sentry) — частота виникнення помилок у реальному часі. Частота помилок є критичним показником для команд, які працюють у середовищах з високими вимогами до надійності (наприклад, у фінансових або медичних застосунках).

Окрім основних метрик, ми також визначили додаткові показники, які допомогли зробити аналіз ще детальнішим:

• Середній час розгляду Merge Request у GitLab. Це показник, що демонструє швидкість реакції команди на нові зміни в коді. Затримки в розгляді можуть свідчити про проблеми з координацією або високий рівень завантаженості розробників.
• Кількість завершених завдань у Jira. Ця метрика дозволяє оцінити прогрес команди в межах одного спринту або певного періоду часу.
• Кількість дублювань коду (SonarQube). Високий рівень дублювань коду свідчить про низьку якість архітектури проєкту та може бути причиною технічного боргу.

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

Етап 2. Розробка кастомних експортерів

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

1. Гнучка адаптація під специфіку кожного проєкту. Кожен із наших проєктів мав свої особливості: різні структури репозиторіїв у GitLab, відмінності в налаштуваннях Jira, специфічні вимоги до аналізу коду в SonarQube тощо. Кастомні експортери дозволили нам врахувати всі ці нюанси та створити рішення, яке ідеально підходило для наших потреб.

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

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

Як це виглядало на практиці? Наші експортери були написані на Python. Експортери запускалися у Docker-контейнерах, що спрощувало їхнє розгортання та інтеграцію з іншими компонентами системи. Наприклад, ось як виглядає частина коду експортеру для отримання метрик із SonarQube:

def get_project_status(sonarqube_url, api_token, project_key):
    """
    Retrieves the quality gate status of a given project in SonarQube.

    :param sonarqube_url: SonarQube URL
    :param api_token: API token for authentication
    :param project_key: Project key in SonarQube
    :return: Project status (e.g., OK, WARN, ERROR) or None if data could not be retrieved
    """
    endpoint = f"{sonarqube_url}/api/qualitygates/project_status"
    headers = {
        'Authorization': f'Basic {base64.b64encode(f"{api_token}:".encode()).decode()}'
    }
    params = {
        'projectKey': project_key
    }

    try:
        response = requests.get(endpoint, headers=headers, params=params)
        response.raise_for_status()
        data = response.json()

        if 'projectStatus' in data and 'status' in data['projectStatus']:
            return data['projectStatus']['status']

    except requests.exceptions.RequestException as e:
        print(f"Error when making a request to SonarQube API: {e}")

    return None

Повний скрипт:

• Підключається до API SonarQube, щоб отримати дані про статус останньої перевірки.
• Форматує ці дані у вигляді, який підтримує Prometheus.
• Запускає HTTP-сервер, який Prometheus може використовувати для збору метрик.

Щоб забезпечити легке розгортання експортерів, ми використали Docker. Ось приклад Dockerfile, який ми застосовували для контейнеризації:

FROM python:3.9-slim 

# Встановлення залежностей
WORKDIR /app 
COPY requirements.txt . 
RUN pip install -r requirements.txt 

# Додавання коду експортера 
COPY exporter.py . 

# Запуск скрипта 
CMD ["python", "exporter.py"] 

Цей Docker-контейнер дозволяє запускати експортери на будь-якому сервері з Docker, забезпечуючи простоту масштабування й оновлення.

Після створення експортерів ми налаштували їх як targets у Prometheus. Це дозволило Prometheus автоматично збирати дані з експортерів у реальному часі. Наприклад, для SonarQube ми додали наступний запис у prometheus.yml:

scrape_configs:
  - job_name: 'sonar_exporter'
    metrics_path: '/metrics'
    scrape_timeout: 25s
    static_configs:
      - targets: ["sonar_exporter:8085"]

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

Приклад частини docker-compose файлу:

services:
  sonar_exporter:
    build:
      context: ./sonar_exporter
      dockerfile: Dockerfile
    platform: linux/amd64
    container_name: sonar_exporter
    ports:
      - "8085:8085"
    volumes:
      - ./sonar_exporter/exporter.py:/app/exporter.py
      - ./sonar_exporter/.env:/app/.env
    networks:
      - monitoring

Етап 3. Візуалізація у Grafana

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

Для кожного напряму розробки — Frontend, Backend і Mobile — ми створили набір окремих панелей на загальному дашборді, які містили наступні елементи:

Графіки зміни ключових показників у часі. Це були динамічні графіки, які відображали такі метрики, як кількість відкритих багів, технічний борг, покриття тестами, частота помилок. Ми додали лінії тренду, щоб можна було аналізувати, чи покращується ситуація, чи погіршується. Наприклад, графік для метрики «Build Success Rate» демонстрував, як стабільність збірок змінювалася протягом останнього тижня.

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

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

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

Вбудовані алерти. Grafana дозволила нам налаштувати алерти, які автоматично відправляли повідомлення в Teams, якщо якась із метрик перевищувала допустимі межі. Це зробило процес моніторингу проєктів проактивним, а не реактивним.

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

Етап 4. Інтеграція штучного інтелекту

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

Щоб розв’язати цю проблему, ми впровадили штучний інтелект (AI), який узяв на себе роль аналітика. Його функції включали:

Автоматичний аналіз метрик. AI отримував дані з Prometheus і створював аналітичні звіти. Наприклад, щопонеділка AI аналізував динаміку технічного боргу, кількість закритих і відкритих багів, покриття тестами та інші ключові показники. Результати аналізу подавалися у вигляді простого тексту, зрозумілого навіть для людей, які вперше бачать ці метрики.

Генерація рекомендацій. На основі аналізу AI пропонував конкретні дії для покращення показників. Наприклад:

• «Кількість багів у проєкті X зросла на 20%. Рекомендуємо перевірити тестові кейси й підвищити якість автоматизованого тестування».
• «Середній час виконання збірки зріс на 15 хвилин. Варто переглянути конфігурацію CI/CD».

Пояснення складних показників. Однією з найцінніших функцій AI стало пояснення технічних термінів простими словами.

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

Короткі звіти для C-level менеджерів. Окрім технічних звітів, AI створював окремі зведення для керівників. У цих звітах наводилися лише ключові метрики з короткими висновками.

Щотижневі автоматизовані рекомендації та звіти. Кожна команда отримувала персоналізовані рекомендації щодо того, як покращити свої процеси.

Приклад частини коду запита до OPENAI:

# Request analysis from OpenAI
payload_analysis = {
    "model": "gpt-3.5-turbo-0125",
    "messages": [
        {"role": "system", "content": "You are a data analyst. Analyze the following metrics."},
        {"role": "user", "content": prompt_analysis},
    ],
    "max_tokens": 500,
    "temperature": 0.7,
}
print(f"Sending data for project {project} to OpenAI...")
try:
    openai_response_ana = requests.post(OPENAI_URL, headers=headers, json=payload_analysis)
    openai_response_ana.raise_for_status()
    ana_data = openai_response_ana.json()
    analysis = ana_data["choices"][0]["message"]["content"] if "choices" in ana_data else "No response for analysis."
except requests.exceptions.RequestException as e:
    print(f"Error fetching analysis: {e}")
    analysis = "Error fetching analysis."

all_analyses.append(f"### Analysis for Project {project} ###\n"
                    f"**Metric Characteristics:**\n{characteristics.strip()}\n\n"
                    f"**Behavior Analysis and Recommendations:**\n{analysis.strip()}\n")

Приклад відповіді:

Вплив впровадження AI:

• Краща доступність даних: менеджери почали розуміти аналітичну інформацію без необхідності мати технічний бекграунд.
• Оптимізація аналізу: аналітичні звіти AI скоротили час на аналіз даних і ухвалення рішень на 40%.
• Зменшення критичних помилок: кількість серйозних помилок у проєктах зменшилася на 25% завдяки рекомендаціям AI.
• Зростання ефективності: робота команд покращилася завдяки чітким інструкціям щодо оптимізації процесів.

Note: для розробки представленого прикладу (POC-моделі) використовували OpenAI, проте у кінцевому продукті було створено власну модель LLM (Large Language Models), що забезпечило більш безпечний, гнучкий і кастомізований підхід для обробки та аналізу даних.

Висновок

Наш досвід показав, що сучасні технології, такі як Prometheus, Grafana та AI, можуть суттєво змінити підхід до моніторингу проєктів. Ця система не лише об’єднала розрізнені дані, але й зробила їх зрозумілими та корисними для всіх учасників процесу. Впровадження штучного інтелекту стало важливим етапом, який перетворив Grafana із простої візуалізації в повноцінний інструмент прийняття рішень. Тепер наші дашборди не лише показують стан проєктів, але й допомагають робити їх кращими.