Какой опыт работы с базами данных на уровне DevOps или DBA?

Что проверяют

Для Python-разработчика это вопрос о границе ответственности: можете ли вы безопасно выкатить миграцию на живую базу, восстановиться из бэкапа и понять, почему база тормозит. Следом часто спрашивают про самый неприятный инцидент с базой, который вы разбирали.

Как отвечать

Честно обозначьте уровень: вы разработчик, который хорошо знает эксплуатацию, или реально администрировали кластер. Потом конкретика на примере PostgreSQL:

• миграции: Alembic или миграции Django в CI, схема «расширить, потом сузить»: новая колонка, заполнение пачками, переключение кода, удаление старого. Индексы через CREATE INDEX CONCURRENTLY, у миграций lock_timeout, чтобы не повесить таблицу в очереди блокировок;
• бэкапы: pg_dump для логической копии, pg_basebackup плюс архив WAL для восстановления на момент времени, инструменты вроде pgBackRest или WAL-G. Главное: регулярная проверка восстановления, а не только наличие файлов;
• производительность: pg_stat_statements для поиска тяжёлых запросов, EXPLAIN (ANALYZE, BUFFERS), контроль autovacuum и раздувания таблиц;
• соединения: пул в SQLAlchemy или PgBouncer перед базой, потому что каждое соединение PostgreSQL это отдельный процесс;
• мониторинг и доступы: postgres_exporter с Prometheus и Grafana, отдельные роли с минимальными правами для приложения, миграций и аналитики.

Хорошо, если опишете одну историю целиком: медленный запрос, как нашли, какой был план до и после, какой индекс или переписанный запрос помог. Цифры берите из своего опыта.

Если администрирование было не вашей зоной, так и скажите и перечислите, что делали сами: писали миграции, читали планы, участвовали в разборе инцидента.

Где спотыкаются

Говорят «бэкапы у нас настроены», но ни разу не пробовали восстановиться. Бэкап без проверенного восстановления остаётся гипотезой.

Считают, что база в Docker «легко масштабируется». Контейнер упрощает запуск, но реплики, хранилище и отказоустойчивость от этого не появляются.

Выкатывают ALTER TABLE, которому нужна эксклюзивная блокировка большой таблицы, без lock_timeout. Миграция ждёт блокировку, а все запросы к таблице выстраиваются в очередь за ней.