В далеком 2010 году я решил вступить в партию GameDev ибо на рынке было глухо средь космических стратегий. Знаменитый СтарКвейк на стратегию никак не тянул, в сети главенствовал Огейм и его бесчисленные клоны. Но три ископаемых и достаточно простенький вариант развития колоний давил на меня отсутствием реалистичности. Немного пройдясь по гитхабам было решено писать с нуля.

Вариантов на тот момент особо не было, фронт на Flash бэк на PHP + MySQL - классика того времени. Писалось в одно лицо с привлечением художника и дизайнера, за что им бесконечное спасибо! Проект сначала жил на моем ноутбуке, затем на скромном VPS и под конец перебрался на качественный дедик в хецнере (да, были времена : ) с кучей ядер, памяти и диска. В период расцвета онлайн был 100-150 игроков. Но, как обычно, донат начал снижаться, и когда проект перестал оплачивать сервер я подождал пару лет и понял что "лошадь умерла, можно с нее слезать"

Параллельно проект ушел в 2019 на гитхаб, где был доступен абсолютно всем вплоть до недавнего времени. Единственная проблема - бэкап БД не уцелел, точнее уцелела версия 2012 года, в которой много чего не хватало.

Примерно месяц назад мне закралась мысль, а почему бы не использовать курсор для реанимации БД, ну он же может пройти по коду и все вернуть как надо? Оказалось может...

И тут все понеслось... Сначала мы разобрали исходники Flash и перепилили фронт, потом добили в БД то, чего не хватало, затем обработал напильником все картинки и "мультики", стараясь не уничтожить геймплей. Переработали ископаемые и элементы, все же 60 ископаемых оказались оверкилом. Поправили баланс кораблей и колоний...

Давайте попробуем еще раз, в прошлый раз как-то не задалось, но много воды утекло с тех пор. Проект начался как простой способ "заглянуть в БД сервера" собственно таким он и остается до сих пор. Но по мере развития ИИ в нем появились новые фишки.

Как гласит слоган на главной странице: Panopticum — место, откуда видно всё. Собственно я старался сделать его именно таким, чтобы можно было посмотреть и проверить как можно больше из одного места, желательно с одинаковым интерфейсом.

Сначала я просто начал наращивать количество коннекторов. И если сначала это было четыре вида БД, потом шесть, то теперь это 26 разных БД, логи из Kuberneties и просмотр S3 бакетов.

Приложение тормозит. Где узкое место? Почему растёт память? Есть ли дедлок?

Я написал JavaPerf — MCP-сервер, который даёт ИИ-инструментам прямой доступ к нативным утилитам JDK для профилирования. Без графических интерфейсов, без ручного CLI — только диалог с ассистентом.

В проекте часто бывает некий data-flow, который идет через ETL или даже отдельные серверы обогащения данных. Собственно и наш проект не исключение. Что было нужно? Данные из интернета летят в PostgreSQL, но только если в Redis не валяется хэш таких же. Далее несколько ETL проводит стандартный OLTP - OLAP преобразование и складывает все это в MongoDB — откуда клиент дергает эти данные и сравнивает их со своей PostgreSQL попутно складируя кэш в Redis. Все это периодически летает через RabbitMQ.

Что бесило? DBeaver + MongoExpress + redis‑cli все это в разных местах с разными учетками, экспресс постоянно падал по невыясненной причине, неправильный запрос в редиску подвисал, а затем улетал в космос. Мелькнула мысль: «ну почему никто не написал чего‑то более стабильного и удобного?», — собственно это и стало драйвером выходного дня.

Спасибо древним грекам, над названием долго думать не пришлось: Паноптикум — в оригинале «место откуда видно все», но также «сборище жутких и необычных артефактов».

Собственно дальше все очень просто, можно читать, можно искать, можно обновить отдельную запись (если DevOps разрешит) собственно это не production‑ready софт, а простой и надежный инструмент для QA и разрабов. Примитивная basic‑auth которую обязательно надо прятать под TLS и желательно за корп‑VPN, чтобы только свои могли запороть. Для прода и около можно сделать READ_ONLY — но тут каждый сам решает надо оно вообще ему или нет.

Наконец‑то можно проследить все преобразования данных и найти кто потерялся, можно открывать несколько вкладок, можно давать ссылку на конкретный объект. Ставится самым стандартным образом: берем образ — разворачиваем, ничего необычного.

Началось все весьма прозаично, клиент позвонить к нам в техподдержку и спросил «а как бы мне поставить ваш софт но в другую схему БД». Собственно вопрос проще некуда — мы писали на спринге, а значит лезем в application.yml и ставим схему. Но, клиент не из тупых и уже это попробовал — не сработало.

Начинаем разбираться что сломалось и кто виноват. Первым делом ДевОпс повторяет кульбиты клиента и выдает простой вердикт: «В 151 миграции лажа». Я открываю и: «батюшки родный, да это же лосенок явное указание схемы!»