Аналитика Jira без API: считаем Lead Time, CFD и метрики релизов прямо в SQL по базе Postgres

Вот важная новость с фронта ИИ: i_alakey 9 минут назад Аналитика Jira без API: считаем Lead Time, CFD и метрики релизов прямо в SQL по базе Postgres Сложный 12 мин 225 PostgreSQL * SQL * Atlassian * Визуализация данных * Управление проектами * Туториал TL;DR. Jira Data Center хранит всё в обычной Postgres, включая полный лог переходов по статусам. Если подключить эту базу как источник данных в Grafana, можно построить инженерную аналитику (Lead/Cycle Time, предсказуемость, CFD, метрики релизов) без REST API, без выгрузок в BI и без плагинов из маркетплейса.

В статье — разбор трёх самых нетривиальных запросов: предсказуемости через перцентили, восстановления времени в статусах из changelog и рекурсивного обхода дерева релиза. Все имена проектов, команд, ID полей и названия статусов в примерах — условные, приведены для иллюстрации. В вашей Jira они будут другими.

Технические детали

Зачем вообще лезть в базу, если есть APIУ Jira есть REST API, есть JQL, есть маркетплейс с дашбордами. Но как только метрики становятся чуть сложнее, чем «сколько задач закрыто за спринт», всё это упирается в потолок:JQL не умеет считать время между переходами. Он фильтрует задачи, но не отвечает на вопрос «сколько задача пролежала в статусе review».

А именно это и есть основа потоковых метрик. API отдаёт changelog поштучно, по одной задаче. Чтобы посчитать перцентиль Lead Time по тысяче задач, нужно выкачать changelog каждой и агрегировать на своей стороне.

Это медленно и хрупко. Готовые плагины — чёрный ящик. Они считают «что-то похожее на Cycle Time», но их определение статусов не совпадает с вашим реальным процессом.

Отраслевые последствия

При этом Jira Data Center / Server работает поверх обычной реляционной СУБД — как правило PostgreSQL. Вся история задач лежит в таблицах, к которым можно обратиться напрямую. Grafana умеет подключать Postgres как источник данных и рендерить результат SELECT в графики, таблицы и bar gauge.

Дальше — вопрос знания схемы и умения писать SQL. Важная оговорка про доступ. Читать боевую базу Jira напрямую — плохая идея: тяжёлые запросы с оконными функциями и рекурсией нагружают СУБД, а это тот же инстанс, на котором работают люди.

Правильный вариант — read-only реплика или отдельный аналитический слепок. Дайте Grafana пользователя строго с SELECT и только на нужные таблицы. Схема Jira: три таблицы, на которых всё держитсяПрежде чем смотреть запросы, нужно понять четыре сущности.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.