Администратор баз данных

Принято думать, что администратор баз данных целыми днями пишет запросы. Пишет, но главный результат его работы другой: база, которую можно поднять после сбоя, ошибки оператора или отказа сервера, и которая не тормозит в конце месяца, когда бухгалтерия закрывает период. Хорошо сделанная работа DBA почти незаметна, а плохо сделанная видна сразу всем: отчёты не строятся, заказы не проходят, и никто не может сказать, какие данные на месте.

Что входит в работу

Обязанности складываются из пяти направлений. Резервное копирование: выбрать способ, расписание и место хранения копий и регулярно проверять восстановление из них. Репликация: держать рядом с основным сервером копии, которые получают изменения почти сразу и могут его заменить. Производительность: находить запросы, съедающие ресурсы, подбирать индексы, настраивать память и фоновые процессы. Безопасность: роли, права, шифрование соединений, журнал действий. И жизненный цикл самой СУБД: установка, обновления, переезды на новое железо и на другую систему управления базами данных.

В небольших компаниях всё это делает системный администратор или backend-разработчик между другими задачами. Отдельный DBA появляется там, где данных много, простой дорого стоит, а баз несколько десятков: в банках, у операторов связи, в крупной рознице, в государственных информационных системах.

Учебный пример: строки, удалённые без WHERE

Ситуация учебная. В 14:37 аналитик выполняет на рабочей базе запрос, который должен был удалить тестовые заказы, но забывает условие WHERE. Из таблицы заказов пропадает всё. Реплика не спасает: удаление дошло до неё за доли секунды, так же как и любое другое изменение.

DBA не восстанавливает всю базу поверх рабочей: за прошедшие минуты в неё уже попали новые заказы, и откат уничтожил бы их. Он разворачивает на отдельном сервере последнюю полную (базовую) копию и прокатывает архив журнала предзаписи (WAL — файлы, в которых PostgreSQL фиксирует каждое изменение) до момента 14:36:59. Этот приём называют восстановлением на момент времени. Когда копия поднялась, он выгружает из неё таблицу заказов, сравнивает с рабочей и возвращает только пропавшие строки. Потом разбирается, почему у аналитика было право удалять данные на рабочем сервере, и отзывает его. Всё это сработало только потому, что архивирование журналов было настроено заранее: без него восстановиться удалось бы лишь на момент ночной копии.

Реплики, отказ сервера и переключение

Потоковая репликация в PostgreSQL передаёт изменения с основного сервера на резервные, чтобы разгрузить его от отчётных запросов или быстро переключиться при аварии. Переключение обычно поручают кластерным менеджерам вроде Patroni, которые следят за узлами и назначают новый основной сервер. Синхронная репликация не теряет подтверждённых транзакций, но замедляет запись и может остановить её совсем, если реплика недоступна. Асинхронная быстрее, но при отказе основного сервера последние изменения могут не успеть уйти на реплику. Выбор между ними — это разговор с владельцами системы о том, что для бизнеса хуже: несколько потерянных секунд данных или остановка приёма заказов. DBA приходит на него с цифрами задержки репликации.

Когда база тормозит

Жалоба «всё медленно» почти никогда не означает «нужен сервер помощнее». DBA начинает со статистики запросов: расширение pg_stat_statements показывает, какие запросы суммарно занимают больше всего времени. Затем смотрит план выполнения через EXPLAIN ANALYZE: где СУБД читает всю таблицу вместо индекса, где ошибается в оценке числа строк, где сортирует на диске, потому что не хватило памяти.

Отдельная тема PostgreSQL — очистка старых версий строк. При обновлении и удалении старые версии остаются в таблице, пока их не уберёт фоновый процесс autovacuum. Если он не успевает, таблицы и индексы разрастаются, запросы замедляются, а в запущенных случаях возникает угроза переполнения счётчика транзакций. Поэтому DBA следит не только за запросами, но и за тем, как работают фоновые процессы.

Обновления: почему смена версии — это проект

Сообщество PostgreSQL поддерживает каждую основную версию пять лет после выхода, а потом выпускает последний корректирующий релиз и прекращает исправления, в том числе исправления уязвимостей. Это прямо записано в политике версий PostgreSQL. По той же таблице PostgreSQL 13 получил последний релиз 13 ноября 2025 года, а для PostgreSQL 14 последний релиз назначен на 12 ноября 2026 года. Для DBA, у которого в эксплуатации базы на 14-й версии, это ближайший срок, после которого придётся объяснять службе безопасности, почему сервер работает без исправлений.

Важнее дат другое различие из той же политики. Корректирующие релизы (14.23 → 14.24) не содержат новых функций, не меняют формат хранения, и для них достаточно остановить сервер, заменить программу и запустить его снова. Сообщество прямо рекомендует всегда держать последний корректирующий релиз своей версии. Переход на новую основную версию устроен иначе: меняется внутренний формат каталога данных, поэтому базу нужно либо выгрузить и загрузить заново, либо обработать утилитой pg_upgrade. Промежуточные версии при этом можно пропускать.

Как это выглядит на практике, хорошо видно по примечаниям к выпуску PostgreSQL 18. В 18-й версии утилита initdb, которая создаёт новый кластер, по умолчанию включает контрольные суммы страниц данных. При этом pg_upgrade требует, чтобы настройка контрольных сумм у старого и нового кластеров совпадала. Кластеры, созданные на старых версиях с настройками по умолчанию, контрольных сумм не имеют, и если DBA создаст новый кластер привычной командой, обновление не пройдёт проверку. Выход — создать новый кластер с параметром —no-data-checksums, а контрольные суммы включить отдельно, когда будет окно для этой работы. В той же версии pg_upgrade впервые научился переносить статистику планировщика, но только базовую: расширенную статистику после обновления нужно собрать заново, иначе часть запросов первое время будет выполняться по неудачным планам. Из-за таких подробностей обновление становится проектом с пробным прогоном на копии и планом отката.

Переезд с Oracle и MS SQL

Вторая крупная задача последних лет — перенос баз с Oracle и Microsoft SQL Server на PostgreSQL или на его российскую сборку Postgres Pro, которая включена в реестр отечественного ПО с марта 2016 года. Перенести таблицы и данные относительно просто. Основная работа — в коде и поведении, которое приложения считают само собой разумеющимся.

В Oracle пустая строка равна NULL, в PostgreSQL это разные значения, и отчёт, который фильтрует пустые поля, после переезда начинает показывать другие цифры. Пакеты PL/SQL приходится переписывать на PL/pgSQL. В SQL Server сравнение строк по умолчанию обычно не учитывает регистр, а в PostgreSQL учитывает, поэтому поиск клиента по фамилии может перестать находить записи. Для оценки масштаба работ есть инструменты: например, Ora2Pg подключается к Oracle, выгружает структуру и данные, переводит часть кода и готовит отчёт о сложности миграции. Но что переписать, а что упростить, решают DBA вместе с разработчиками и тестировщиками.

Чем DBA отличается от соседних профессий

Системный администратор отвечает за серверы, сеть и операционные системы в целом, а DBA — за одну из систем на этих серверах, зато глубоко: от формата хранения до планов запросов. Инженер данных строит конвейеры, которые забирают данные из разных источников и складывают их в хранилище для аналитики; DBA обычно отвечает за рабочие базы, откуда эти данные берутся. Backend-разработчик проектирует схему и пишет запросы со стороны приложения, а DBA следит, чтобы эти запросы не положили сервер, и помогает с индексами и миграциями. Есть ещё разработчик баз данных, который пишет хранимые процедуры и отчёты; в небольших командах эту роль и роль DBA совмещает один человек.

Что может оказаться трудным

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

Вторая трудность — график: обновления и переезды делают ночью или в выходные, а аварии случаются когда угодно, поэтому DBA часто участвуют в дежурствах. Третья — постоянные переговоры: разработчики хотят новых прав и быстрых изменений схемы, служба безопасности — ограничений, бизнес — работы без простоев. Если вам трудно говорить «нет» и объяснять почему, работа будет даваться тяжело.

Сколько платят

Открытых данных именно по DBA немного. В калькуляторе зарплат «Хабр Карьеры» для специализации «Администратор баз данных» на сентябрь 2026 года указана зарплата 215 033 ₽ в месяц по России для всех уровней вместе. Расчёт сделан по 92 анкетам, это небольшая выборка, а разбивка по уровням в открытом доступе не показана.

Предложения работодателей видно в разделе вакансий DBA на «Хабр Карьере». В сентябре 2026 года там было восемь вакансий. Две вакансии DBA PostgreSQL уровня middle в Москве предлагали 197 000–301 000 ₽ и 245 000–423 000 ₽, вакансии администраторов MongoDB и Greenplum того же уровня — 178 000–279 000 ₽ и 178 000–307 000 ₽. Это вилки из объявлений, а не фактические зарплаты, и вакансий для начинающих среди них не было.

Вывод практический: без опыта сразу на должность DBA попадают редко. В поиске вакансий фильтруйте по городу и опыту, смотрите медиану, а не среднее, и уточняйте, указана сумма до вычета налога или на руки.

С чего начать обучение

Основа — SQL и понимание реляционной модели: соединения, группировки, оконные функции, ограничения целостности, транзакции. Без этого не получится ни читать планы запросов, ни говорить с разработчиками на одном языке. Такую базу даёт, например, онлайн-курс «SQL-разработчик» в Eduson Academy: два месяца занятий, работа через DBeaver на PostgreSQL и восемь учебных проектов на бизнес-кейсах. Это именно SQL: в опубликованном плане модулей о резервном копировании, репликации и администрировании в программе нет.

Параллельно нужен Linux, на котором работает большинство рабочих серверов PostgreSQL: командная строка, права на файлы, службы systemd, журналы, контроль диска и памяти. Следующий шаг — сама СУБД изнутри: как устроены страницы и журнал, что делает autovacuum, как работают индексы, как делаются копии и восстановление. Многое здесь можно изучить бесплатно: официальная документация PostgreSQL подробно описывает резервное копирование, восстановление на момент времени и репликацию.

Документация объясняет, но не проверяет, поэтому полезна практика, где базу нужно не только наполнить, но и обслуживать. На курсе «PostgreSQL для начинающих» от Skillbox около 80 часов теории и 120 часов практики, есть индексы, роли и права, резервное копирование и восстановление, разбор планов через EXPLAIN ANALYZE и два проекта для портфолио. Администрирование там дано на базовом уровне: репликацию и отказоустойчивость придётся изучать дальше самостоятельно или на следующей программе.

Для самостоятельной тренировки поставьте два сервера в виртуальных машинах, настройте между ними реплику и архивирование журналов, а потом восстановитесь на заданный момент времени. Эта связка упражнений ближе всего к реальной работе DBA.

Переподготовка и диплом

Некоторым работодателям, особенно в государственном секторе, важен документ о профессиональной переподготовке. Такие программы есть у онлайн-школ, которые работают по лицензии на дополнительное образование. Например, программа переподготовки «Администратор баз данных» АПОК рассчитана на 400 часов, идёт в самостоятельном формате с текстовыми уроками и стоит 39 910 ₽. Подробной программы на странице нет, поэтому перед записью уточните у школы, какие СУБД изучаются, есть ли практические задания с проверкой и что именно будет в итоговой работе.

Диплом не заменяет опыта: на собеседовании DBA обычно просят рассказать, как он восстанавливал базу или разбирал медленный запрос. Поэтому оценивайте программу по объёму работы на живом сервере, а не по числу часов.

Как выбрать обучение и сделать первые шаги

При выборе программы проверьте четыре вещи: на какой СУБД идёт обучение и совпадает ли она с вакансиями в вашем городе; есть ли задания на восстановление из копии, а не только на её создание; разбирают ли репликацию и мониторинг; кто проверяет практику. Чтобы сравнить школы, можно начать с рейтинга онлайн-школ по системному и сетевому администрированию. Это широкий рейтинг по администрированию в целом, а не отдельно по базам данных, но Linux и эксплуатация серверов нужны DBA не меньше, чем SQL.

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