Управление базой данных ломается не в SQL, а в доступах, бэкапах и правах

Управление базой данных ломается не в SQL, а в доступах, бэкапах и правах

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

Минимальный набор дисциплины:
— отдельные роли для чтения, записи и администрирования;
— бэкапы с проверкой восстановления, а не просто с фактом создания;
— журналирование изменений схемы и миграций;
— контроль долгих запросов, блокировок и роста таблиц;
— регламент на ротацию секретов и доступов.
Безопасность начинается с доступа.

Для продакшена важно разделять эксплуатацию и разработку. Разработчик должен видеть только то, что нужно для отладки, а не всю боевую поверхность. Админ — иметь возможность быстро восстановить сервис, но не хранить критичные секреты в заметках и чатах. Автоматизация — это не опция, а необходимость: ручные операции в БД слишком хорошо умеют превращаться в инциденты.

Ещё одна типовая ошибка — отсутствие инвентаря. Если вы не знаете, какие базы живут, кто их использует и какие у них зависимости, управление превращается в археологию. Мониторинг должен быть проактивным, а не реактивным: свободное место, репликация, задержки, ошибки бэкапа и рост латентности надо ловить до того, как об этом напишет пользователь.

Сначала наводят порядок в правах и восстановлении, потом — в производительности. Остальное обычно уже следствие.