Обновление (июнь 2026). Цифры в статье — это срез на март 2026 года: 247 разобранных интервью. С тех пор база заметно выросла — сейчас в ней более 1200 переработанных собеседований и свыше 10 000 вопросовЧитать полностью »
Обновление (июнь 2026). Цифры в статье — это срез на март 2026 года: 247 разобранных интервью. С тех пор база заметно выросла — сейчас в ней более 1200 переработанных собеседований и свыше 10 000 вопросовЧитать полностью »
Делаю pet-проект — приложение, чтобы свайпать тендеры в телефоне и видеть AI-скоринг заказчика. Идея простая: свайпнул, посмотрел «ваш шанс — высокий/средний/низкий», дальше принимаешь решение, лезть в этот тендер или нет.
Чтобы скоринг был не из воздуха, нужно собрать всю историю заказчика — какие контракты у него были, как он платил, какой типичный дисконт от стартовой цены. Источник один — ЕИС zakupki.gov.ru. И вот тут я наступил на грабли которыми и хочу поделиться.
Если кто тоже думает парсить госзакупки — пост сэкономит вам пару недель.
Пятница, вечер. Один из эндпоинтов начал отвечать секунд по восемь вместо привычных двухсот миллисекунд. Графики в Grafana — зелёные. CPU спокойный, память на месте, диск не забит. По всем дашбордам база здорова. А она не здорова.
Знакомая ситуация: мониторинг показывает, что сервер жив, но не показывает, что внутри базы что-то медленно гниёт. Раздулась таблица. Появился индекс, которым никто не пользуется, но который тормозит каждый INSERT. Висит забытая транзакция и держит блокировку. Ничего из этого не «падает» — оно просто потихоньку делает базу хуже, пока в пятницу вечером не станет совсем плохо.
Когда я начал поднимать PostgreSQL через Docker для своих проектов, всё выглядело просто: описал сервис в docker-compose.yml, запустил контейнер - база доступна.
Проблемы начались, когда я начал запускать миграции вместе с контейнерами. Иногда миграции стартовали раньше чем PostgreSQL успевал принять подключения, и приложение падало с ошибкой подключение к базе данных.
Когда я начал разбираться, чем в мире опенсорса можно закрыть задачу ASOC / Vulnerability Management, выбор оказался довольно грустным. По сути единственный известный вариант это DefectDojo. Сам я его в проде не тащил, но от коллег регулярно слышал одну и ту же боль: на больших объёмах он начинает захлёбываться, и тебе просто больше не хочется заходить, а аналогов с человеческим видом и БДУ ФСТЭК «из коробки» в опенсорсе я просто не нашёл. Так и появилась моя ASOC-платформа: Go + PostgreSQL + Redis Streams + React, развёртывание одной командой docker compose upЧитать полностью »
Самая дорогая ошибка моего B2B SaaS имела ровно одну строчку
```python
# app/config.py
TENANT_ID = "tenant-1"
```
Когда у меня был один тенант, всё работало корректно. На втором — половина админ-сущностей (врачи, услуги, прайс-листы) начала пропадать из интерфейса клиента. Не «не сохраняться» — а появляться в БД с чужим tenant_id. Я полтора дня смотрел на эту мистику, прежде чем понял: 30 endpoint’ов берут tenant_id из closure из config, а не из user.tenant_id. Очевидно в ретроспективе. Совершенно невидимо во время первого пилота.
Когда сервис поднимается по 8-15 минут, команда почти всегда начинает крутить одни и те же ручки: увеличивает initialDelaySeconds, добавляет startupProbe, поднимает progressDeadlineSeconds, иногда переносит миграцию в initContainer и считает, что стало «по-кубернетесному». Обычно это не лечение. Это способ аккуратнее завернуть проблему в YAML. Если тяжёлая миграция живёт внутри старта приложения, вы связали жизненный цикл Pod, rollout Deployment и поведение базы в один общий узел. А такие узлы в проде рвутся не там, где их ждут.
Есть очень узнаваемая картина. Новый релиз выкатывается нормально на staging, а в production внезапно «висит». kubectl get podsЧитать полностью »
Все началось с того, что мне поставили задачу: «У менеджеров есть большой телевизор. Сделай так чтобы у них там крутились красивые циферки и графики с результатами продаж».

Условия задачи:
Данные берем из 1С

Привет! Меня зовут Даша Александрова, я Java-разработчик. Хочу поделиться опытом миграции данных из Oracle в PostgreSQL без простоя сервисов.
Причина миграции - импортозамещение.