Граф от кода приложения до базы и цифровые сотрудники на нём
Перед изменением схемы, обновлением версии или переездом с Oracle система показывает, какие сервисы, запросы, процедуры, отчёты и расширения будут затронуты, кто за них отвечает и какие проверки нужны. Виртуальный DBA и инженер миграций готовят план и доказательства, решение о выпуске принимает человек. Слой ложится поверх вашей СУБД или машины баз данных, ничего не заменяя.
«Если мы изменим или перенесём эту базу, что сломается и можно ли выпускать?»
Переезд с Oracle неизвестного объёма
Оценка считает объекты Oracle, но не код приложений: Java, .NET, 1С, динамический SQL, ORM, отчёты, интеграции. Ошибка оценки превращает проект с фиксированной ценой в многомесячную переделку. Переезжают целиком, потому что непонятно, как по частям.
Схема или SQL под живыми сервисами
Одна колонка или процедура затрагивает десятки сервисов и отчётов. DBA, разработка, ИБ и бизнес собирают доказательства вручную, согласование релиза базы занимает дни, а владелец риска часто не назван.
Новая версия ядра и расширений
Клиенты не идут на новую версию, потому что не знают, какие расширения, внешние модули и приложения это затронет. После инцидента время уходит на восстановление картины зависимостей, а не на починку.
Общая причина: никто не связывает конкретную правку в коде приложения с конкретным потребителем в базе и с решением о выпуске.
Инструменты управляют миграциями, каталогом и мониторингом, но не связью кода с базой
| Класс инструментов | Что делает | Чего не делает |
|---|---|---|
| Миграции схемы: Liquibase, Flyway, Bytebase | версионируют и применяют изменения, политики, аудит | не знают, какой код и какие отчёты сломает изменение |
| Каталоги и lineage: DataHub, Arenadata Catalog | происхождение данных от источника до витрины | не видят код приложений и решение о выпуске |
| Оценка миграции с Oracle: Ora2Pg и аналоги | конвертируют объекты Oracle в Postgres | не считают внешний код, динамический SQL, ORM и интеграции |
| Мониторинг и тюнинг СУБД | производительность и доступность экземпляра | не отвечают на вопрос «что затронет это изменение» |
| pgra.ph/data | граф от правки в коде до потребителя в базе и до решения о выпуске | не заменяет ни один из классов выше: интегрируется с ними |
Мы не строим СУБД, не исполняем миграции вместо Liquibase и не строим каталог данных. Мы отвечаем на вопрос о радиусе изменения и даём доказательства для выпуска.
Граф от репозитория до работающего экземпляра
Узлы
Репозитории и сервисы, SQL-запросы, ORM-модели, таблицы и колонки, представления, функции и процедуры, триггеры, индексы, роли, расширения, миграции, ETL-задачи, отчёты, API, среды.
Связи
Читает, записывает, вызывает, преобразует, развёртывает, зависит от версии, владеет, тестирует, содержит персональные данные.
Источники
Git, каталоги PostgreSQL и Oracle, DDL и журналы запросов, Liquibase и Flyway, CI/CD, Airflow и dbt, BI, CMDB, мониторинг. Потребители вне репозиториев собираются из журналов и метаданных BI.
Выход
Радиус воздействия, несовместимости, владельцы, план тестов, последовательность миграции по волнам, план отката, пакет доказательств для архитектурного комитета.
Граф с первого дня хранит историю изменений, владельцев и связь с задачами. Поэтому оценка миграции не остаётся разовой услугой, а становится постоянным контролем изменений.
Основа — граф свойств кода GoCPG (живое демо на codegraph.tech), расширенный объектами базы данных.
Четыре слоя: база остаётся базой, мы добавляем слой над ней
Решения людей
DBA заказчика, архитектор, владелец релиза утверждают план волн, принимают изменение, подтверждают обновление.
Цифровые сотрудники на графе
Виртуальный DBA и инженер миграций готовят анализ, план и доказательства. Действуют только в рамках паспорта и по подтверждению.
Граф от кода до базы
Код приложений, SQL, ORM, миграции, ETL, отчёты, расширения и экземпляры как один граф с историей и владельцами.
СУБД или машина баз данных
Железо, Postgres, эксплуатация, производительность, доступность, резервирование. Ничего здесь не заменяем и не дублируем.
Слой 2 читает каталог и журналы экземпляра, слой 3 работает через конвейер в контуре заказчика. Для производителей машин баз данных и вендоров СУБД слой данных поставляется как опция к их продукту.
Виртуальный DBA и инженер миграций работают на графе, решение остаётся за человеком
Виртуальный DBA
Администрирование Postgres на графе потребителей.
- Перед обновлением ядра или расширения показывает, какие модули, функции и приложения затронуты, и собирает план проверки.
- По изменению схемы или SQL считает радиус: сервисы, отчёты, владельцы, нужные тесты и согласования.
- По инциденту связывает деградацию с недавними изменениями и предлагает безопасный откат.
- Отдаёт пакет доказательств для выпуска, план волн и отката, список владельцев. Не выполняет действия в проде сам: предлагает и обосновывает.
Инженер миграций
Перенос с Oracle и между версиями по графу.
- Инвентаризация схем, PL/SQL, SQL в коде, ORM, ETL и интеграций; классификация объектов: автоконвертация, ручная адаптация, архитектурное изменение.
- Волны по независимым схемам: параллельный контур размером с волну, а не со всю систему.
- Доказательство, что модуль переехал целиком и старую часть можно гасить.
- Отдаёт оценку трудоёмкости с раскрытием факторов, матрицу тестов и рисков, план cutover. Работает в паре с человеком-руководителем миграции.
Основа — 13 должностей цифровых сотрудников pgra.ph с именами и паспортами: область, ответственный человек, права на инструменты, политика одобрений. Должности DBA и инженера миграции данных появляются первыми в пилотах с вендорами СУБД и машин баз данных.
Конвейер в закрытом контуре: агенты делают работу, люди принимают решения
Всё работает внутри контура заказчика на российских и локальных моделях; код и схема наружу не уходят. Раннер ставится рядом с базой. Процесс описан в методологии разработки с ИИ-агентами.
От оценки миграции к постоянному контролю изменений
Assessment миграции или обновления
Инвентаризация, граф зависимостей, классификация объектов, волны, оценка трудоёмкости, матрица тестов и рисков, пакет доказательств.
Change Impact Gate
Тот же граф как годовая подписка в процесс: каждое изменение получает радиус, владельцев, тесты и согласования; человек решает о выпуске; связь «изменение, проверки, инцидент» хранится для аудита.
Incident Graph
Связь деградации с недавними изменениями, владелец, безопасные варианты отката. Контекст для поддержки L2/L3: конфигурация, версии, зависимости, затронутые потребители.
Три типа партнёров и заказчиков
Производители машин баз данных и вендоры СУБД
Переезд клиентов на машину по частям, доказательство готовности установленной базы к новой версии, пакет контекста для поддержки L2/L3. Слой данных и цифровые сотрудники как опция к продукту, настроенные под его профиль.
Банки и крупные заказчики
Миграция с Oracle и согласование изменений схемы в критичных системах. Пилот в инфраструктуре заказчика без передачи кода наружу, измеримый эффект относительно действующего процесса.
Интеграторы и команды миграции
Оценка объёма до фиксации цены проекта, волны и план cutover, Evidence Pack для архитектурного комитета заказчика.
Один контур, 8–10 недель, измеримый результат
Как устроен пилот
- Где: в инфраструктуре заказчика, без изменения промышленной базы и без передачи кода наружу.
- Вход: дамп схемы без данных, доступ на чтение к одному репозиторию приложения, история миграций за выбранный период.
- Выход: карта зависимостей контура, отчёты по историческим и текущим изменениям, пакет доказательств для согласования, измерение эффекта.
- Критерии успеха: доля известных экспертам зависимостей, которую нашла система; не меньше одной подтверждённой зависимости, ранее неизвестной команде; сокращение времени подготовки согласования на исторических изменениях.
Цены платформы pgra.ph
- 100 тыс. ₽ в месяц — команда до 10 рабочих мест.
- 10 тыс. ₽ в месяц — цифровой сотрудник сверх командной лицензии.
- 100 тыс. ₽ — инсталляция в контур заказчика.
- 200 тыс. ₽ — пилот конвейера: месяц, одна команда, метрики до и после.
- Assessment миграции — проектная оценка по размеру контура: число систем, баз, сред, команд и изменений в год.
- Инференс на стороне клиента: его подписки на модели или локальные модели. Партнёрская лицензия для вендоров — отдельно.
Три основателя, двое из ядра Postgres Pro
Александр Котин
Ex-Postgres Pro: разработка ядра Postgres Pro Enterprise и внедрения в крупнейших банках.
Михаил Савин
Руководство ИИ-направлением в Postgres Pro, управление продуктом Yandex Managed DB.
Константин Соловьёв
Генеральный директор: продажи крупным заказчикам, переговоры, партнёрства.
Опыт команды в ядре СУБД и в миграциях с Oracle — основа слоя данных: мы знаем, где именно ломаются переезды и обновления.
Обсудить пилот по базам данных
Один контур, 8–10 недель, критерии успеха согласуем на старте. Ответим в течение рабочего дня.