db-status-presentation-001

1.

db-status
Автоматический отчёт по использованию
PostgreSQL баз и ответственным
Краткий обзор проекта и алгоритм работы простым языком
один отчёт вместо ручной сверки
Java 21 · Spring Boot · PostgreSQL · Confluence
db-status · краткий обзор · 1/6
Базы
данных
Сервис
собирает
отчёт
Страница
Confluence

2.

Что делает проект
Без технических деталей: сервис заменяет ручной сбор информации одной регулярной публикацией.
Главная задача
1. Берёт факты
из базы данных
Понять, какие базы данных
реально используются, и сразу
увидеть ответственного.
2. Добавляет
ответственных
Практический эффект: меньше ручных проверок,
быстрее поиск владельца, проще принимать
решения по старым или спорным базам.
основных Java-файлов
16
тестовых Java-файлов
24
3. Публикует
страницу отчёта
Итоговый отчёт живёт там, где его проще
показать: в Confluence.
db-status · краткий обзор · 2/6
20
тестовых сценария

3.

Схема решения
Два источника данных, один сервис-посредник, одна итоговая страница для всех участников.
PostgreSQL
готовая таблица
статусов
db-status
сверяет данные
делает HTML-таблицу
Confluence
страница отчёта
пишет метрики
Confluence
таблица
ответственных
Ручной запуск: отдельная команда
Контроль: статус сервиса и
метрики
Важная особенность: отчёт не привязан к жёсткому списку колонок — он берёт заголовки из результата базы данных.
db-status · краткий обзор · 3/6

4.

Алгоритм простым языком
Эту схему можно показывать нетехническим участникам: без классов, API и SQL.
1
Ждёт расписания
или ручной команды
2
Берёт список
ответственных
3
Берёт данные
по базам
7
Записывает
успех или ошибку
6
Обновляет страницу
Confluence
5
Собирает
понятную таблицу
4
Склеивает
по имени базы
Если любой внешний источник недоступен, сервис не скрывает проблему: фиксирует ошибку и не делает вид, что отчёт
обновлён.
db-status · краткий обзор · 4/6

5.

Что получает команда
На выходе — не код, а понятный операционный артефакт: актуальная страница отчёта.
До
После
вопросы “кто отвечает?”
единая страница Confluence
ручная сверка статусов
ответственный рядом с БД
разные источники правды
→
ручной запуск после изменений
статус работы и метрики для контроля
Главный выигрыш в долгую: перед отключением или оптимизацией базы видно не только “используется/нет”, но и с кем
разговаривать.
db-status · краткий обзор · 5/6

6.

Реалистичная оценка и следующий шаг
Проект уже решает задачу, но для промышленного режима стоит закрыть несколько рисков.
Сильные стороны
Риски
Что сделать первым
простая схема без лишнего хранилища
токен доступа не должен жить в файле
проекта
убрать секреты в защищённые переменные
динамические колонки отчёта
формат таблицы ответственных легко сломать
руками
зафиксировать регламент страницы
ответственных
есть ручной запуск и проверка состояния
сбой базы или Confluence остановит
публикацию
добавить повторные попытки и алерт
тесты покрывают ключевой маршрут
история запусков отдельно не сохраняется
решить, нужен ли журнал истории
Вывод: сервис полезен как “единый источник правды” по статусу баз. Перед продуктивом лучше
закрыть секреты, устойчивость к сбоям и регламент владения таблицей ответственных.
db-status · краткий обзор · 6/6