|
Professor Seleznov
|
Привет, Хабр.
Я 16 лет работал с MS SQL Server - профайлер там был одним из главных инструментов в работе при расследовании проблем производительности. Сейчас я в Тантор Лабс, развиваем СУБД Tantor Postgres. И когда понадобился аналогичный инструмент для PostgreSQL оказалось, что его просто нет. В статье я хочу показать процесс создания работающего профайлера для PostgreSQL на основании моего опыта работы с MS SQL.
---------------------------
При работе с информационными базами на MS SQL Server мне часто приходилось использовать профайлер для того, чтобы найти дедлоки или "выловить" план проблемного запроса для расследования проблем производительности приложения. В качестве профайлера можно было использовать как Extended Events внутри Management Studio, так и отдельное приложение Profiler.
После перехода на PostgreSQL оказалось, что таких инструментов нет, а потребность в них у разработчиков и DBA осталась. В качестве первого шага наша команда разработки реализовала расширение pg_trace для СУБД Tantor Postgres. Реализация данного расширения дала нам программный интерфейс для сбора трассировки, оставалось реализовать визуальный для работы с ней.
Визуальный интерфейс мы планируем реализовать в платформе Tantor - это инструмент для графического управления и администрирования кластерами PostgreSQL, и логично инструмент для работы с трассировкой реализовать там. Но если ранее я ставил задачу на реализацию подобного инструмента в Jira, и ждал пока команда дизайнеров сделает макет в Figma, согласует его с разработкой и представит заинтересованным лицам на согласование, то теперь я могу сделать это сам с помощью AI. Это позволяет изменить подход к процессу разработки фич: я могу команде дизайнеров и разработчиков показать как должен выглядеть инструмент, как работает его механика, показать какие-то нюансы и тонкости, которые я знаю лучше них, так как я работал с подобными инструментами и могу свой опыт представить команде в виде работающего MVP.
Эта статья будет полезна прежде всего тем, кто хорошо знает предметную область, но не является разработчиком - product owner-ам, аналитикам, DBA, архитекторам. Я покажу на конкретном примере, как с помощью AI можно самому пройти путь от идеи до работающего MVP, не написав при этом ни строчки кода вручную.
Содержание статьи:
Проектирование дизайна
Разработка приложения
Отладка приложения
Демонстрация работы профайлера
План действий у меня был следующий:
- Спроектировать внешний вид профайлера в Claude Design
- Затем экспортировать его в Claude Code и реализовать приложение
- Отладка на тестовом сервере с установленным Tantor Postgres + pg_trace
Начнем.
Проектирование дизайна
Мой промт для проектирования интерфейса в Claude Design был следующий:
Скрытый текст
Задача: спроектировать интерфейс профайлера (Profiler) для визуального сбора трассировок запросов PostgreSQL по аналогии как реализовано в MS SQL Management Studio.
Входные данные для проектирования интерфейса:
1. Перед стартом трассировки необходимо определить ее параметры:
Base - выбор базы из списка
backend_pid - числовое поле
duration - числовое поле
query_like - текстовое поле
plan - булево
timeout - числовое поле
Все эти поля располагаются на уровне одной строки
2. Под параметрами сбора трассировки расположить список кнопок для управления трассировкой: старт, стоп, Clear Data, Filters, Clear all Filters, Grouping, Aggregation.
Кнопки отобразить предпочтительно иконками и текстом при необходимости.
3. Под командной панелью располагается 2 окна: сверху таблица со строками, снизу расшифровка каждой строки. Список полей верхней таблицы и ее расшифровки я определю на этапе кодинга, сейчас просто в дизайне отображаем наличие этих 2 окон.
4. Нижнее окно состоит из двух вкладок - Details, которая отображает все колонки анализируемой строки, и Query Plan, которая будет отображать план запроса через iframe
Прикладываю следующие референсы:
mssql_command_panel - команды управления трассировкой в MS SQL Management Studio, то что упомянуто в пункте 2 выше.
mssql_window - как выглядит целиком окно сбора трассировки в MS SQL Management Studio. Поля из п.1 здесь задаются по другому, но мы в целях упрощения интерфейса сделаем все в одном окне.
mssql_plan - как выглядит отображение плана запроса. Пункт 4.
reference_style_1, reference_style_2 - визуальный стиль, в котором сделать интерфейс.
logo - логотип нашей компании. Разместить в левом верхнем углу.
Перед началом проектирования проанализируй все файлы и требования, задай уточняющие вопросы, и только после получения всех ответов приступай к проектированию интерфейса.
В качестве референса профайлера я скинул несколько скринов из Extended events с изображением окна трассировки, плана запроса, командной панели:
Окно с трассировкой в Extended events
Для проектирования стиля, которому должен соответствовать интерфейс, я скинул референсы из платформы Tantor:
Главное окно платформы Tantor
После анализа данных Claude задал мне серию вопросов по дизайну, вот некоторые из них:
Уточняющие вопросы от Claude по дизайну
После ответа на все вопросы он начал проектирование и через 10 минут выдал мне 3 варианта стилей:
- A · Tantor Native — тёплый кремовый фон, бренд-оранжевый, скруглённые формы (рекомендуемый дефолт)
- B · Studio Classic — холодные серые тона, плотные строки, прямоугольные углы (приближено к SSMS)
- C · Pro Dark — тёмный IDE-стиль для долгих сессий, контрастные подсветки длительности и узлов плана
A · Tantor Native
B · Studio Classic
C · Pro Dark
Варианты отличались только цветовой гаммой. Я выбрал первый вариант Tantor Native. А что касается самого интерфейса, то Claude спроектировал его так как я и ожидал: командная панель управления трассировкой, фильтры, окно вывода данных трассировки и окно расшифровки строки трассировки.
Далее я подкорректировал несколько элементов в режиме чата:
- Объединил кнопки "Grouping" и "Aggregate" в одну, так как эти действия связаны.
- Убрал поле EVENT, так как у нас в отличии от MS SQL оно пока одно - это непосредственно выполнение запроса.
- Добавил кнопку подключения к серверу СУБД
- Скинул ему файл трассировки, собираемой pg_trace - он перерисовал вкладку Details согласно имеющейся спецификации полей. Также скинул документацию по данной утилите, чтобы он проверил, что командная панель управления трассировкой соответствует программному интерфейсу pg_trace.
- Скинул ему как работать с API explain.tensor.ru, чтобы он понимал, каким образом мы сможем отобразить план запроса. Мы решили, что визуализировать план будем по кнопку "Vizualize plan", а по дефолту показывать текстовый план запроса в формате json.
В итоге получился вот такой итоговый дизайн:
Далее спроектировали модальные окна управления различными командами.
Подключение к серверу:
Фильтры:
Группировка и агрерация:
Также я описал и технические нюансы, которые на дизайн не влияли:
- перед стартом трассировки необходимо проверить существует ли расширение pg_trace и если нет, то создать его.
- Как "слушать" трассировку и готовый python-скрипт, который может ее разобрать и отдать в нужном нам формате
Все это позволило Claude собрать полную техническую картину проекта ещё до написания первой строки кода и не переспрашивать по ходу работы.
Чтобы передать все результаты проектирования из Claude Design в Claude Code, нужно выполнить специальный промпт: 'Запусти Handoff to Claude Code'. После этого Claude Design упаковывает все артефакты спроектированного дизайна в единый архив, готовый к загрузке в Code
После этого он собрал мне архив, я скачал его и больше в Design не возвращался.
Переходим к разработке приложения.
Разработка приложения
В Claude Code я использую набор скиллов Superpowers, который по сути соответствует своему названию и дает следующие возможности:
- brainstorming — включается до того, как написана первая строчка кода. Помогает разобраться с сырыми идеями через вопросы, рассматривает альтернативы и показывает дизайн по частям — чтобы его можно было обсудить и поправить. В конце сохраняет документ с итоговым дизайном.
- using-git-worktrees — включается после того, как дизайн утверждён. Создаёт отдельное рабочее пространство в новой ветке, настраивает проект и проверяет, что тесты на старте проходят чисто.
- writing-plans — включается с готовым дизайном на руках. Разбивает работу на маленькие кусочки — каждый на 2–5 минут. Для каждой задачи: конкретные файлы, готовый код и понятные шаги для проверки.
- subagent-driven-development / executing-plans — включается, когда план готов. Либо запускает отдельного агента на каждую задачу с двухэтапной проверкой (сначала — соответствие заданию, потом — качество кода), либо выполняет задачи пакетами с остановками для живого ревью.
- test-driven-development — работает во время реализации. Жёстко держит цикл RED → GREEN → REFACTOR: написать падающий тест, убедиться что он падает, написать минимальный код, убедиться что тест проходит, закоммитить. Код без тестов — удаляется.
- requesting-code-review — включается между задачами. Сверяет, что сделано, с планом и сообщает о проблемах с указанием критичности. Критические блокируют движение вперёд.
- finishing-a-development-branch — включается, когда все задачи закрыты. Проверяет тесты, предлагает варианты дальнейших действий (смёрджить, открыть PR, оставить как есть или удалить ветку) и прибирает за собой рабочее пространство.
Загружаю архив, который в конце своей работы собрал мне Claude Design, и пишу следующий промпт:
Прочитай сначала design_handoff_pg_profiler/ CLAUDE.md , затем design_handoff_pg_profiler/ README.md. И потом запусти скилл brainstorming
Эти 2 файла содержали следующие инструкции:
- CLAUDE.md — короткий промпт-инструкция для AI-агента: что прочитать в каком порядке, какие требования жёсткие, что в макете мок, а что финальная версия, и каким порядком вести разработку. Это «вход» для агента, по которому он сразу понимает контекст без необходимости перечитывать всё подряд.
- README.md — полная спецификация проекта для разработчика: дизайн-токены, архитектура трёх тиров (фронт ↔ WebSocket ↔ unix-сокет pg_trace), маппинг параметров pg_trace_start(), описание всех экранов и модалок, процедура установки pg_trace на Astra Linux и сценарий smoke-теста. Это исчерпывающий справочник, к которому возвращаются по мере реализации.
После изучения данного контента Code оценил масштаб проекта:
Проект большой — CLAUDE.md перечисляет 10 шагов работы, это объём на несколько недель. Засовывать всё в один spec — слишком крупно для качественной проработки. Прежде чем уточнять детали, надо договориться о размере первой итерации.
Claude оценил объём в несколько недель работы. Забегая вперёд скажу, что реализация заняла 24 часа. Это хорошо иллюстрирует разрыв между тем, как AI оценивает задачи, и тем, насколько эффективно он же их выполняет при правильной декомпозиции.
После этого он начал задавать серию уточняющих вопросов по объему MVP и стеку используемых технологий. Пример:
Я везде выбирал рекоммендуемый вариант, так как с данными технологиями не работал. В итоге после 6 таких вопросов мы зафиксировали следующие решения:
- Scope: vertical MVP slice (шаги 1, 3, 4, 5 из CLAUDE.md)
- Backend: Python (FastAPI + websockets), asyncpg
- Frontend: React + Vite + TypeScript
- Dev env: WSL2 + локальный PostgreSQL+pg_trace
- Connection: минимальная Connect-модалка, без сохранения профилей
- UI: full chrome, disabled-состояния для будущих фич
Затем мы перешли к дизайну каждого из этих 6 разделов. Например, раздел по Scope:
Скрытый текст
Раздел 1/6 — Архитектура и границы MVP
Что IN scope для этого spec:
- Backend-скелет на FastAPI: один WebSocket /ws, один HTTP /api/health.
- Менеджер подключения к PG: принимает host/port/user/password/sslmode, всегда коннектится к системной БД postgres, резолвит Base name → oid.
- Lifecycle pg_trace: проверка установки расширения (3 состояния из README), SET pg_trace.plan_format='json', CREATE EXTENSION IF NOT EXISTS, pg_trace_start(...), pg_trace_stop().
- Socket reader: subprocess pg_trace_client.py--format=json --unix-socket=/tmp/pg_trace.sock, парсим JSON из stdout построчно. Порт парсера в нативный Python — следующий spec.
- Стриминг событий по WebSocket с типами сообщений из README (event, status, error — без buffer).
- UI: header, parameters strip, command panel (только Start/Stop/Clear Data активны), event table (5 колонок), Details inspector (8 секций, Query Plan tab показывает текст плана; кнопка Visualize disabled).
- Минимальная Connect-модалка (без блока saved profiles).
Что OUT of scope (явно):
- Сохранение профилей подключения (шаг 2)
- FIFO-буфер и индикатор Buffer X/Y MB (шаг 6) — вместо этого простой hard-cap 10000 событий с прекращением приёма (см. раздел 4)
- Visualize plan через explain.tensor.ru (шаг 7)
- Filters modal (шаг 8)
- Group & Aggregate modal (шаг 9)
- Auto-scroll smart defaults, статус-переходы, error toasts (шаг 10) — кроме базовых
- systemd unit, journald, packaging под Astra Linux (будет в production-spec'е, не сейчас)
Структура репо — монорепо:
Раздел 1 ок? Поехали к разделу 2 (Backend internals)?
И так по каждому разделу. Где-то я вносил свои корректировки, например, пояснил, что корректно останавливать трассировку через SELECT pg_trace_stop(), а не пытаться убить сеанс)
В итоге он составил план из 20 задач, TDD first.
| # |
Что |
Кол-во шагов |
| 1 |
Repo scaffold (Makefile, backend/frontend skeletons) |
11 |
| 2 |
/api/health + первый тест |
5 |
| 3 |
Error codes + protocol types |
6 |
| 4 |
PgClient.check_extension (3-state) |
5 |
| 5 |
PgClient.resolve_base/fetch_db_map/set_session_guc |
5 |
| 6 |
PgClient.start_trace/stop_trace |
5 |
| 7 |
Copy pg_trace_client.py в backend |
5 |
| 8 |
TraceReader (subprocess + JSON parser) |
5 |
| 9 |
SessionManager (state machine) |
5 |
| 10 |
/ws endpoint + session_busy |
6 |
| 11 |
Design tokens + globals.css |
6 |
| 12 |
TS types (TraceEvent, messages) |
3 |
| 13 |
WebSocketClient (3-try reconnect) |
5 |
| 14 |
Zustand store |
5 |
| 15 |
ConnectionDialog |
5 |
| 16 |
Header + ParamsStrip |
3 |
| 17 |
CommandPanel + EventTable |
3 |
| 18 |
Inspector (Details + Query Plan) |
5 |
| 19 |
App.tsx + Toaster + Footer |
5 |
| 20 |
End-to-end smoke test против реального pg_trace |
10 |
Последним вопросом перед началом разработки был выбор способа исполнения:
- Subagent-Driven (рекомендую) — на каждую задачу свежий subagent в чистом контексте, я ревьюю между задачами. Быстро итерируется, удобно ловить регрессии.
- Inline Execution — все задачи в текущей сессии через executing-plans, батчинг с чекпойнтами. Главное достоинство — контекст не теряется, но context window заполнится быстрее.
Выбрал вариант с субагентами. Реализация заняла почти сутки. Модель - Opus 4.7, параметр Effort выставил в Extra High: это режим максимальных усилий, при котором Claude тратит больше времени на обдумывание каждого шага, генерирует более качественный код, но и токенов расходует значительно больше. Примерно за 40–60 минут исчерпывался пятичасовой лимит использования Claude Pro - после чего приходилось ждать сброса счетчика. В итоге за 4 такие сессии мы реализовали 19 из 20 задач (последнюю задачу решили проверять руками).. На этот момент контекстное окно было заполнено на 43%:
Перед переходом к тестированию я выполнил команду /Compact. Это встроенная команда Claude Code, которая сжимает историю переписки: Claude анализирует все, что было сделано, и заменяет длинный контекст кратким резюме. Это освобождает место в контекстном окне для следующего этапа работы и позволяет агенту не терять фокус на главном. :
/compact Сохрани информацию о выполненных нами 19 задачах, и что мы проверяем вручную 20ю. Бекенд мы будем запускать удаленно на моем сервере и ты от меня ждешь ответы на вопросы по тому как мы это будем делать. Список вопросов сохрани. Также у нас проблема с запуском фронтенда и мы ищем способ решения
Отладка приложения
После компакта я перешел к отладке приложения.
Первая проблема с которой столкнулся была в том, что фронтенд просто не запускался. Как оказалось, не запускался он при включенном VPN. Для меня это не было критично и далее при запуске приложения я просто выключал VPN.
Разработанное приложение запускалось следующим образом:
Бекенд был установлен на удаленном сервере, где стоял Tantor Postgres 17 с расширением pg_trace, Бекенд поднимался как службаsudo systemctl start pg-profiler-backend.
Фронтенд запускался локально на моем ноутбуке. Для его запуска нужно было выполнить 3 действия:
- Пробросить SSH-туннель ssh -N -L 8000:127.0.0.1:8000 login@server
- Из каталога с фронтендом запустить команду npm run dev
- Открыть фронтенд по адресу http://localhost:5173/
И появляется долгожданное окно профайлера:
Первым делом после запуска идет подключение к хосту с PostgreSQL:
Так как я был подключен к удаленному серверу через SSH-туннель, то задавать хост было не нужно, вместо этого задать домашний каталог пользователя postgres - так было спроектировал приложение Code, хотя на стадии дизайна я ожидал, что там будет именно удаленный хост сервера СУБД. Но по факту он сделал правильно. В MS SQL Management Studio профайлер тоже работает внутри выбранного сервера, да и у нас в платформе Tantor все модули работают также внутри инстанса PostgreSQL.
Следующим шагом был запуск трассировки и тут было несколько ошибок при обращении к программному интерфейсу расширения pg_trace и получению данных трассировки. На исправление ошибок ушло полтора часа и затем я получил первые данные трассировки:
Вау! Чувствовал себя в знакомой среде как в MS SQL Management Studio!
После этого я перешел к доработке функций, которые мы не стали делать на этапе MVP.
Реализовали визуализацию плана запроса через API explain.tensor.ru:
Добавили фильтры, чтобы можно было найти в собранной трассировке запрос по конкретной таблице и длительности выполнения:
Добавили возможность применения группировки и агрегации к строкам трассировки:
И результат этого действия:
Добавил также команду экспорта в CSV, хотя в MS SQL я чаще пользовался возможностью выгрузки трассировки в таблицу базы данных. Эта фича была удобной, но реализовывать ее здесь не стал.
И последними реализованными фичами были автоскролл и управление размером трассировки:
Buffer это выбор лимита числа событий в клиенте (по FIFO идет вытеснение старых). А работа автоскролла показана в видеодемонстрации ниже.
Стоит отметить, что оставался один баг, который Claude не смог исправить - при нажатии на кнопку Clear Data должна была происходить очистка таблицы с данными трассировками, но иногда оставалось несколько строк, которые не удалялись и несколько итераций диагностики этого бага результата не дали. Для MVP это некритично, но в продакшн-версии нужно будет разобраться.
Демонстрация работы профайлера
VK:
Youtube:
Также вы можете попробовать работу данного профайлера сами - https://github.com/alex7six/pg-profiler, инструкция по установке там есть.
Что изменилось на самом деле
Если попробовать сформулировать главный вывод из этого опыта, то он такой: AI не заменяет разработчиков и дизайнеров - но он радикально меняет то, кто может поставить им задачу и в каком виде.
Раньше между идеей и ее воплощением стоял длинный коридор: Jira, бриф, Figma, согласование, разработка, правки. Теперь человек с экспертизой в предметной области может самостоятельно дойти до работающего прототипа и прийти к команде не с описанием задачи, а с готовым MVP в руках. Это меняет разговор: вместо 'сделайте мне вот это' получается 'вот как это работает, давайте доведём до продакшна'. Команда дизайнеров и разработчиков получила не техническое задание, а живой инструмент с механикой, нюансами и логикой, которую я как эксперт вложил в него сам.
Именно в этом, на мой взгляд, и есть главная ценность подобных инструментов - не в том, что они пишут код, а в том, что человек с идеей меньше зависит от тех, кто умеет ее реализовать.-Источник
|
