SERG1257Если вы задачи ДБА поручите кому-то другому, то либо этот другой все завалит и вы поймете свою ошибку и наймете ДБА либо справится и будет штатным ДБА.

Задачи ДБА пожалуйста озвучьте.
И чем 100% он будет занят всё рабочее время.

Тюнить запросики в БД?
Бекапить БД? Бекапить бекапы?
Проектировать (упаси боже, не дай бох) БД?

Вот просто интересно.

Я в последний раз видел ДБА на штатной позиции ДБА лет 10 назад.
И тогда от него проблем было на порядки больше, чем пользы.

MegabyteИнтересно было бы понаблюдать, как сисадмины будут оптимизировать запросы и искать проблемы производительности...

Старую, бородатую сказку про "оптимизации страшных запросов" может уже хватит рассказывать?

Так и представляю, как приходит дядька к 10 утра, и до 7 вечера оптимизирует запросы.
Ну не смешно уже даже.

OndaylИзвините, если ошибся разделом, но очень уж интересует вопрос.

Давно. Как телеграфисты там, или доярки. Где-то остались, как рудимент. Ну и не будем забывать про армию оставшихся "за бортом", которые должны и обязаны защищать свою позицию, доказывая, что она нужна, и без неё "тупые прогеры" не смогут одолеть БД и написать нормальные запросы. :)

MegabyteПриветствую тебя, адепт секты ОРМ. :)

Понимаю твою невменяемость, поэтому не буду углубляться в детали и повторять тыщу раз повторенное.

Знаете, а ведь как показательно, да? Есть люди, живущие в чёрно-белом мире.
Либо ты злостный SQL-щик.
Либо ты злостный ORM-щик.

Третьего не дано

Обычно такое исходит либо от маленького опыта и недостатка знаний,
либо это какой-то больной фанатизм, который видит только одного чёрта.

Dimitry SibiryakovНеспособность "прогеров" "одолеть БД и написать нормальные запросы" это, увы, реальность,
данная нам в ощущениях тематических форумов.

Такие прогеры вообще мало на что способны.
Кроме того, профили прогеров широки, есть например, фрондендщики, который с БД дел никаких не имеют.

Очень лысыйЛюди, которые говорят о ненужности DBA, скорее всего не сталкивались с реально большими и нагруженными базами.

"Большие и нагруженные базы", это уже притча во языцех.

Представьте, пожалуйста, на суд общественности, с каких размеров и с каких нагрузок в проекте должен появиться ДБА? Дайте нам эти константы.

SERG1257hVosttЗадачи ДБА пожалуйста озвучьте.
Полторы сотни серверов, две тысячи пользовательских баз от мегабайта до терабайта,
полный зоопарк приложений какие-то самописные, какие-то покупные
самые разные версии сиквела от 2005 до 2016 (последнего из могикан 2000 недавно грохнули)
пара баз Oracle, одна нормальная, другая Oracle E-Business Suite, все под AIX
За всем этим хозяйством зорко наблюдают аудиторы - ищут отклонения от "best practices" и "segregation of duties", ибо каждый момент который они нашли это им в плюс, нам в минус.

Задача только одна - чтобы все работало и никто не ушел обиженным.
Хватит квалификации хорошему разрабу за этим следить? Кем он станет когда разберется? А он разберется, я в него верю.
Да и бакапики с запросиками тоже есть.

Исходя из вышеописанного, я должен сделать вывод, что задачи ДБА, это: следить за диким зоопарком баз ?

Т.е. мы не развели такой зоопарк, а поддерживаем порядок, то и дба нам нафиг не упёрся?

Ну, ок.

SERG1257hVosttприходит дядька к 10 утра, и до 7 вечера оптимизирует запросы.Немного не так.
Не работает ваша программа, тормозит, начинаем разбиратся что именно не работает, где именно тормозит, когда не тормозило, когда стало тормозить.

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


SERG1257Смотрим на базу, спроектированную не дай бог спецами и удивляемся как оно вообще работает, ненужных индексов полно, нужных не хватает, но трогать ничего нельзя ибо поддержки лишим, можно только задокументировать ситуацию и отправить рекламацию разработчикам.

Ну, в нашем мире, это не должно делаться руками, так как это натуральная обезьянья работа. У нас, например, это метрики, различные показатели, которые показывают и сигнализируют, где боттлнеки, где деградация, где нездоровая тенденция и т.д. и т.п.


SERG1257А у разработчиков на все один ответ: выкиньте ваше устаревшее приложение, мы тут новое слабали.

Скорее всего ваш опыт сложился из-за работы с некомпетентными разработчиками.

SERG1257ДБА это тот, который (драматизма ради) будет разбужен ночью и дожен быстро разобраться с проблемой, а потом (днем) решить, что же именно пошло не так и как сделать чтобы проблема не появлялась.

Ну и как он разберётся, если проблема на стороне ПО, или в совокупности?

В общем, странно всё это. Чё он там должен понять, как собирается пофиксить, как разобраться...

KarbafosУ меня перед глазами уже год два проекта одной крупной конторы с 300к юзерами в сутки, где orm-сектанты, выпускники всяких новомодных курсов, даже индексы не осилили, им подавай ядер и памяти побольше ибо запросы что-то 10 секунд на простой выборке работают.

Это не ORM-сектанты, это некомпетентные программисты.

Алкаши часто в пылу попойки устраивают поножовщину...
Чёртовы сектанты ножей! Запретить ножи!

Поэтому, до маразма доводить уже не нужно.

По числу проведённых мною собеседований, у меня крайне печальная и удручающая статистика.

Alexander RyndinА я вот тут недавно столкнулся с программистами из секты Денормализации. Они, вместо того чтобы делать внешние ключи, справочники и тому подобную реляционную ересь, все пишут в один большой JSON и пихают его в базу. Т.е. при записи факта они информацию из всех справочников пишут в факт. Зато у них на 18 млн. фактов база занимает более 100 Гб.

Может здесь _они_ неправы, но видимо вам незнаком такой подход, где подобное может быть уместно.
Например, заключался договор с фирмой ООО "Рога и копыта". И даже если эта компания через год была 10 раз переименована, догов заключался именно с ООО "Рога и копыта".

Секты.. Есть лишь одна секта. Секта некомпетенции.

SERG1257ДБА появляется когда проект уже закончен и готов к сдаче.

Законченный проект = мёртвый проект. Реальность такова, что всё меняется. Бизнес меняется, обстоятельства, технологии.

SERG1257ДБА - это админ заказчика и он должен установить базу разработчиков и поддерживать ее. Более того, доступ разработчиков в боевую базу закрыт.

Ну ок. А что, если БД создаётся и ведётся самим приложением? Что тогда там делать ДБА? Что там поддерживать?

Вообще, развёртывание ПО сегодня, это не только БД, а много-много чего ещё. Да и СУБД больше, чем одно. По ДБА на СУБД? Получается, нужен не ДБА, а DevOps.


SERG1257hVosttТ.е. мы не развели такой зоопарк, а поддерживаем порядокВ гомогенной структуре жить явно легче, не вопрос.

Речь не про гомогенную структуру, а про зоопарк. Хаос, как вы привели в пример.

SERG1257Ох чую это что-то личное . Не нужен вам ДБА - не нанимайте.

Ну так про это и речь. Задачи ДБА озвучены какие-то странные и расплывчатые. Да ещё и конфликтующие с реальностью. Зачем он должен в логику запросов, например, лезть? Он либо должен сам разрабатывать в команде, либо на 100% знать как всё устроено, вся логика, и постоянно актуализировать знание, что тоже означает, что он должен быть непосредственно в команде разработки.


SERG1257ДБА ничего такого не знает.
Задача номер раз - восстановить нормальную работу
Задача номер два - понять что пошло не так, чтобы другого аврала не было.
Кто этим должен заниматся - разработчик, менеджер проекта, тестировщик?

Это всё решается адекватно построенным девопсом, canary-релизами и другими современными подходами, которые не допускают идеи, что периодически должен среди ночи приходить некий бородатый волшебник и всё "решать".

Так раньше и было, и в моей практике такое было, до сих пор помню.


SERG1257Как хочешь так и разбирайся. Снимай трассы, читай логи, кури мануалы, открывай тикеты в поддержку...

Странные задачи у ДБА.


SERG1257P.S. Если в вашем прекрасном мире все работает как часы, и вы не видите необходимости в админах, ремонтниках, наладчиках, инженеров поддержки и прочих дармоедов, то я за вас рад.

Я за админов ничего не говорил, и за других людей.
Просто ДБА, судя по описанию, это некий мультитул, почему-то по терминологии прибитый к БД.

Моё мнение, нужно автоматизировать, решать проблемы на берегу.
Если какой-то странный "дба" лезет и на продакшене "оптимизирует запросы", надо кому-то руки отрывать, не меньше и не больше.

DaniilSeryiА то, что у хорошего разработчика хватит квалификации рулить базой, или на минимальном уровне сервером - без всяких always on, репликаций и прочих кластеров и круглосуточной работоспособности - это верно, хватит.
Но вот добровольно брать на себя этот геморрой - необходимость приходить на работу на час раньше, и уходить на час позже, быть готовым встать по звонку ночью или бросить всё по звонку в выходные и решать несколько часов проблемы по удалёнке или в офисе - да кому из разработчиков это надо? DBA на это согласны, а разработчикам это зачем?

40 часов в неделю настраивать always on? Ещё бы, дба не были бы согласны )

SERG1257Кстати, коллеги-разработчики, концепция SaaS предполагает, что разработчики не нужны, нужны кастомизаторы, а для простых случаев клиент сам справится. Аналогию видите?

Да видим. Вот 1С, например. Всё прекрасно, 1С-программист это не программист, это интегратор (вашими словами "кастомизатор").

Лично я такой вектор поддерживаю.