Денис

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

маст хев:

Понимание принципа работы ssh ключей, чтобы уметь настроить себе доступ на линукс машину или в гит (bitbucket/github/etc)

Базовое понимание git и то, что висит поверх него (github, bitbucket, etc) чтобы не путаться в пулл реквестах, понимать зачем они и как организована у вас работа - неймконвенш для веток, как ревью делается

Если пишете под докер, то Dockerfile - это в основном ответственность разработчика. Где его запускать - уже второй вопрос.

Вы должны уметь ваше приложение развернуть на локальной машине, и понимать как его развернуть на другой машине.
Jenkins\Teamcity - это тулзы, где девопс старается автоматизировать то, что вы разворачиваете на локальной машине. Вы его консультируете где и откуда вы читаете конфиги, возможно у девопсов есть какие-то централизированные способы для этого. Но Jenkins\Teamcity вам нужны на уровне продвинутого юзера. Можно на месте попросить девопса вам показать базу.

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

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

Есть ощущение, что настроить себе CI/CD нормальный девелопер и без OPS сможет.

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

кажется, что всё больше платформ переходит на виртуализацию/аутсорс (PaaS, SaaS, managed Kuber и т.д.)

так и есть. только это никак не отменяет необходимость иметь в штате человека(ов), способного этим рулить.

опс никуда не денется. разве только в мелких шаражках его в целях экономии переложат на девов.

Процитирую сам себя:

У enterprise-приложений есть три основных качества:

1. Большая и сложная кодовая база;
   
2. Высокие требования по надёжности и производительности;
   
3. Длительный срок эксплуатации.
   

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

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

Около года FreeBSD c ZFS в продуктиве на файловом сервере. Средняя отдача — 1ТБ трафика в сутки. Сервер: CPU — 2xOpteron 2214, Mem — 32G, контроллер — AMCC 9650SE-12M, диски — Seagate серии NS, 10-12 штук + SSD Intel X25-M под кэш устройство. Ни одного зависания связанного с ZFS за всё время работы сервера. Единственная проблема — замена отказавших дисков в raidz. Делаешь replace диску, пул резилверится на новый диск, а старый не уходит из конфигурации. Находил PR по этому багу, починили ли его или нет — не знаю.