Что должен уметь делать администратор postgres?

Но послушал ребят из гугла на этой позиции. Это просто онкол опс с плейбуком, не более того.

В больших компаниях своя атмосфера, там очень часто чтобы выкрутить лампочку требуется 3 специалиста и один менеджер. В московский реалиях sre это скорее человек, который отвечает за инфраструктуру со всеми вытекающими. И плейбуки пишет и архитектуру ведет и за мониторингом всего следит.

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

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

Я стараюсь всего этого избегать, пусть как-нибудь без меня.

хороший админ разберется и настроит все за день работы.

Где в оп про хорошего админа?

Это относиться к dba. Но это не вариант «статья в документации на полчаса вдумчивого чтения» Если ты не не понимаешь логики, а тупо с первой «копипасты» и «полчаса вдумчивого чтения» начинаеш фигачить, то с данными станет /dev/urandom. Самый «счастливый» случай когда это выясняется сразу. Но это бывает редко. «Создание» неконсистентности данных чаще выявляется по прошествии большого времени.

Вдруг завтра компания разбогатеет и тебе скажут поехали на Oracle и что ты будешь делать?

Смотря какая компания и смотря какой он. Если он прокачается до статуса архиценного специалиста по PostgreSQL, возможно, наиболее логичным ответом будет немедленное написание ПСЖ и переход в другую компанию, где его умение востребовано. А та компания, откуда он ушёл, будет искать специалиста уже по Oracle. :)

Но таких людей мало. И в общем-то, знание работы «чужих» СУБД безотносительно к описанной ситуации, это действительно полезный навык.

тут просто Serge10 пытался доказать, что если есть база, то нужен дба, который должен только чуть-чуть базоньку админить,

Не стоит передергивать. Я прекрасно отдаю себе отчет, что полно контор вроде той, которую описал WitcherGeralt. Речь шла о другом. Если в штате есть DBA, его главными задачами являются обеспечение сохранности данных и непрерывности доступа к ним. Все остальное во вторую очередь и факультативно (зависит от конкретной конторы).

В конце концов, полно предприятий, эксплуатирующих информационные системы с закрытым кодом, DBA там в принципе не имеет возможности заниматься SQL-запросами...

эксплуатирующих информационные системы с закрытым кодом, DBA там в принципе не имеет возможности заниматься SQL-запросами...

А чем он там занимается? Играет в шахматы с монашками и кушает амброзию?

А чем он там занимается? Играет в шахматы с монашками и кушает амброзию?

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

наиболее логичным ответом будет немедленное написание ПСЖ

это связано с рисками(поиск новой работы, и т.п), да и прокачка до статуса архиценного специалиста занимает не меньше 10000 или сколько-то там часов. В наш век чаще встречаются швец-жнец-надудеигрец.

Сейчас наоборот тенденция пошла (Oracle-free) на сползание с ораклов на альтернативы.

Новые проекты может быть и начинают с чем-то другим на уме, а старые переписывать (мегабайты pl/sql-я) не спешат, ибо непонятно что дороже выйдет по итогу. Нужно либо сопровождать старое, либо мигрировать на новое, либо писать с нуля. А по итогу работает - не трогай.

Да это понятно. У нас сейчас довольно активные бурления по этому поводу, я собственно только за (особенно если выбор падёт на постгрю).

полно предприятий, эксплуатирующих информационные системы с закрытым кодом, DBA там в принципе не имеет возможности заниматься SQL-запросами...

это какбэ не так, у оракла есть прекрасный инструмент sql translation framework с помощью которого можно создавать словари и на лету подменять корявые запросы. и как раз со всякими проприетарными ebs, а также горе-погромистами это очень помогает. я понимаю, у тебя бомбит(и это прекрасно) от осознания, что большинство девелоперов не умеют в базы данных, чтобы эти недоучки себе ни представляли, просто смирись с этим.

у оракла есть прекрасный инструмент sql translation framework с помощью которого можно создавать словари и на лету подменять корявые запросы. и как раз со всякими проприетарными ebs, а также горе-погромистами это очень помогает.

Спасибо за информацию, с Oracle никогда дел не имел.

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