Стоит ли оставаться DBA или переходить в «соседние» области?
Публичный постЯ вижу в клубе много вопросов по поводу вкатывания / перекатывания в разные области и специальности, и решил задать свой - про администраторов баз данных (aka DBA) :)
С развитием облачных сервисов и переходом ко всяким managed instances, инфраструктурные функции DBA стали переходить, например, в DevOps, а аппликативные - к full-stack разработчикам, которые, в принципе, справляются с написанием сложных процедур.
Если поискать открытые позиции DBA, которых не так чтобы много, становится понятно, что функции «расползаются» по другим позициям.
Интересно узнать, что вы наблюдаете в последние годы:
- Является ли вышеописанное единичным или повсеместным явлением, с поправкой на страну / индустрию.
- Нужны ли ещё DBA в чистом виде (и будут ли в обозримом будущем) или это становится слишком узконаправленной специальностью, для строительства успешной карьеры.
- Стоит ли оставаться «чистым» DBA, заниматься сложными T-SQL процедурами, архитектурой, performance tuning'ом и, в перспективе, рассчитывать на работу в консалтинге.
- Может будет умным решением уйти / переквалифицироваться в «соседнюю» область, например, Data Analysis со всякими SSAS, MDX и т.д.
Небольшой оффтоп: Многие компании не хотят «как надо» (scalable and robust), им достаточно «быстро и чтобы работало прямо сейчас», а если завтра работать не будет, то «мы подумаем об этом завтра». То есть, быстрее и легче, а иногда и просто дешевле, добавить ресурсов в пару кликов, чем звать специалиста, который замедлит или даже остановит разработку продукта / фичера, чтобы всё переписать, перестроить и сделать «как надо». Я думаю, что это вполне может касаться и других специальностей :)
Сейчас у нас в ЕРАМ около 30 вакансий DBA (преимущественно со специализацией в DB2, Oracle, Postgre и Azure). На фоне 4000 вакансий всего — это немного.
Ещё у нас есть внутренняя рассылка, куда пишут, когда нужна экспертиза, которой нет внутри команды/проекта/аккаунта. Так вот за последний год там было не более десятка запросов на помочь в миграции БД или оптимизации запросов. То есть, твои наблюдения о том, что разработчики и девопсы в целом справляются, видимо, вполне себе подтверждаются.
В тех проектах, которые веду я, мы обращались за помощью по БД прямо в поддержку Azure и оттуда нам быстро и внятно помогали той самой экспертизой по конкретному продукту.
Думаю (надо проверить!), что DBA под более модными тайтлами "технологические консультанты по вопросам хранения данных" или "data architects", востребованы сейчас как раз больше на стороне облачных провайдеров (Azure, AWS, GCP, IBM, SAP, Snowflake), чем у вендоров или конечных клиентов.
Все к конечном счете упирается в деньги. Если мы не говорим об академических работах, то бизнесу "как надо" == "как дешевле" (на том горизонте планирования, на котором бизнес работает).
Если думать про карьеру, то есть 2 перспективных варианта. Либо уходить в совсем большие конторы, где неоптимальный код уже слишком дорого компенсировать доплнительными ресурсами. Либо менять профессию.
DBA немного, но они нужны + в России уж точно учитывая печальное положение облаков в свете последних событий.
Сам работал DBA и программистом/DBA на разных проектах. Программисты не умеют оптимизировать запросы (даже типа план посмотреть), DevOps с базами данных сильно на вы, мониторить даже толком не умеют (если не придет дядя и не настроит им мониторы с алертами)
Добить DevOps'овых скиллов - это, конечно, идеально, дорого продашься, но сами по себе DBA, конечно, нужно.
В принципе, и разработка особенно какого-нибудь Enterprise тоже ничего, разработчик со знанием баз данных сразу на голову выше по техническим скиллам.
Короче, к чему душа больше лежит, но я бы ковырял в сторону DevOps'овости.
Смотря, где вы работаете. Например , в финансовом секторе, в связи с событиями всем известными, все облака прикрыли по требованию регулятора. И сейчас будет огромный спрос , а я считаю он и был , на DBA. Уж не говоря , что сейчас отъедит поддержка вендорная и все будут искать компетенции в компаниях российских , например кто внедряет.