Инженер DBA: кто это, за что отвечает и когда необходим

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

Стандартные копии на диски уже не работают — нужна системная защита. Инженер DBA проектирует механизм резервного копирования с учётом объёма и критичности данных. Он настраивает шифрование персональных записей, контролирует доступ по учётным записям и правам, а также внедряет аудит для обнаружения несанкционированного доступа или утечки. Целостность и сохранность — это зона ответственности DBA, а не системного администратора, который «ставит антивирус».

Это принципиально разные вещи, и их путаница ведёт к простоям бизнеса. Резервная копия — это «снимок» данных на определённый момент для восстановления после утечки или сбоя. А отказоустойчивость (репликация, кластер) — это бесперебойная работа сервера, даже если один узел вышел из строя. DBA настраивает оба механизма: он знает, как провести обновление без простоя, как быстро переключить нагрузку на реплику и как выполнить проверку копии без остановки обслуживания. Data-инженер без DBA-скиллов этого не сделает.

Затем, что написание быстрого запроса и обеспечение стабильности инфраструктуры под сотнями пользователей — это разные специализации. Программист думает о логике продукта, а DBA — о распределении нагрузки по узлам, использовании индексов и памяти, а также о предотвращении взаимоблокировок. Без DBA один «тяжёлый» отчёт аналитики ляжет на диски и уронит обслуживание всех пользователей. Мы, как IT-рекрутеры, видим это на каждом втором стартапе: разработчики не умеют мониторить сетевые инциденты на уровне СУБД.

Профессионал не ждёт, когда «упало», — он мониторит метрики заранее: время отклика запросов, загрузку CPU и памяти на серверных узлах, количество мёртвых записей, размер журналов и частоту очистки. Он настраивает оповещения по порогам — например, «диски заполнились на 80%» или «утечка памяти в пуле соединений». Сильный DBA использует систему логирования и инструменты вроде Prometheus + Grafana, а также пишет скрипты для автоматической коррекции мелких неполадок. Контроль конфигурации ведётся через системы контроля версий (например, Git).

Системный администратор обеспечивает работу сервера как компьютера — сеть, диски, ОС, обновление пакетов. А DBA отвечает за логику и целостность данных внутри СУБД. Системный админ не оптимизирует SQL, не проектирует секционирование таблиц на 2 терабайта, не настраивает логическую репликацию и не анализирует планы выполнения запросов. Если ваш системный администратор начал устанавливать расширения PostgreSQL на глаз — бегите. Это прямое нарушение принципов разделения зон ответственности.

И правильно делает. Расширения (как pg_stat_statements или postgis) меняют поведение сервера и могут сожрать всю память или всю загрузку CPU. А хранимые процедуры с бизнес-логикой внутри базы — это классический источник узких мест и трудно отлаживаемых багов. Зрелый DBA устанавливает расширения только после тестов на копии данных, а процедуры допускает лишь в строго регламентированных случаях (например, для сложной агрегации данных). Базовая проверка безопасности — запретить написание логики в базе данных кому-либо, кроме DBA.

Спросите, как кандидат решал инциденты с потерей данных или с длительным восстановлением. Junior назовёт команду pg_restore. Middle опишет настройку WAL-журналов. Senior расскажет про кластер Patroni, распределение нагрузки через pgbouncer, мониторинг логической репликации с задержками и автоматическое переключение узлов без потери транзакций. Senior также понимает тонкие параметры ОС (vm.dirty_ratio, nr_hugepages) и знает, как обеспечить предотвращение коррупции данных на уровне дисков. Если ваша инфраструктура содержит большие объёмы персональных данных или требования к бесперебойной работе 24/7 — Senior DBA не роскошь, а сохранность бизнеса.

Частая и опасная иллюзия. Облачная СУБД снимает заботы о физической памяти и дисках, но не о логике данных. DBA в облаке всё равно нужен: он оптимизирует запросы, настраивает индексы, проектирует схемы, управляет параметрами конфигурации (которые в облаке частично доступны), мониторит метрики производительности, планирует обновление мажорных версий без даунтайма, анализирует трафик репликации и стоимость запросов. Без DBA в облаке ваш счёт за CPU и IO будет расти, а пользователи будут ждать ответа секундами.

Не лезьте в технические дебри. Попросите кандидата нарисовать на доске схему отказоустойчивого кластера для вашего продукта (назовите примерное количество пользователей и объём данных). Задайте ситуацию: «Сервер упал в 3 часа ночи, восстановление из копии займёт 6 часов. Ваши действия?» Сильный кандидат назовёт RTO/RPO, предложит реплику для быстрого переключения и объяснит, как предотвратить потерю транзакций. Слабый начнёт говорить про «установить заново ОС». И, конечно, возьмите технического эксперта или IT-рекрутера с DBA-опытом на интервью — у нас в «Альфа Хантер» такие есть.

Вы столкнулись с провалом в управлении знаниями. Это инцидент, который решается наймом нового DBA и параллельным аудитом. Новый инженер начнёт с изучения текущей конфигурации: посмотрит параметры СУБД (postgresql.conf), схему прав доступа, список расширений, журналы логирования и систему бэкапов. Затем он создаст инструкции, описания узлов и процедуры восстановления — и всё это сохранит в системе контроля версий. Важный урок: при найме следующего DBA включите в требования обязанность вести актуальную документацию и онбордить коллегу.

Аналитики работают с данными, чтобы найти закономерности, а DBA — чтобы данные были доступны, целостны и быстро обрабатывались. Если вы используете Greenplum, ClickHouse или Apache Cassandra (это big data-хранилища), то без DBA со знанием распределённых систем не обойтись. Он настраивает шардирование, ребалансировку узлов, сжатие данных на дисках, управление памятью на серверных кластерах. Для ML-пайплайнов (machine learning) DBA проектирует представления и витрины данных, чтобы обучение моделей не тормозило операционные запросы. Без этого инженера ваши big data проекты превратятся в хаос из несогласованных копий.

Главный риск — взять специалиста, который знает один диалект SQL и не понимает глубинных различий. Microsoft SQL Server использует блокировки на уровне строк и тяжёлые хранимые процедуры на T-SQL. PostgreSQL — MVCC (многоверсионность), другую модель очистки (autovacuum) и другой оптимизатор запросов. Сильный DBA для такой миграции должен уметь:

Переписать диалект SQL и хранимые процедуры

Настроить логическую репликацию для синхронизации данных

Спроектировать секционирование и индексы заново

Обеспечить сохранность персональных данных и целостность ссылок

Если кандидат говорит «да там всё просто, экспорт-импорт» — бегите. Ищите DBA, который уже делал миграцию такого же объёма и сложности. В «Альфа Хантер» мы специально проверяем таких кандидатов на кейсах именно cross-platform миграций.