Начну с попытки объяснить Вам кто такой DevOps и зачем он нужен.
В современном ИТ наиболее важно уметь управлять инфраструктурой.
При разработке какого либо программного продукта используется огромное количество серверов, виртуальных машин и пр.
Сегодня скомпилировать приложение из исходного кода это совсем не банальный запуск команды make build. У приложения есть зависимые библиотеки, определенные параметры окружения и пр. Для упрощения работы с различными окружениями был придуман Docker. В Docker-е можно собрать любое нужное приложение получить на выходе что то похожее на маленькую виртуальную машину с установленной в ней программой. Такой подход позволяет легко и достаточно быстро переносить приложение на любой сервер. Для автоматизации процесса сборки приложения, его тестирования и размещения на серверах есть специализированные утилиты, например Jenkins, в которых на каком либо специализированном языке программирования пишут сценарии по которым будет происходить сборка приложения в подготовленной среде.
DevOps это как раз тот человек, который постоянно изучая особенности сборки различных приложений на различных языках программирования выстраивает инфраструктуру используя инструменты Ci/CD и управления конфигурациями (например ansible) таким образом, что бы добиться максимальной скорости выполнения этапов сборки, тестирования и деплоя собранного приложения.
Задачу по проектированию инфраструктуры назвать легкой нельзя, приходится учитывать много различных нюансов, прорабатывать различные схемы и планировать то как все будет работать.
Во многих компаниях используют большое количество виртуальных машин с различным окружением для разных задач, это позволяет изолировать окружения и использовать индивидуальные параметры для каждого сервера в отдельности. Управление таким парком виртуальных машин то же входит в задачи DevOps и была разработана методология Infrastructure As Code.
Infrastructure as Code - это своего рода план описывающие как нужно управлять огромным парком машин как физических так и виртуальных.
Используя средства по управлению конфигурациями, такие как ansible, Pupet,и др. можно описав кодом правила настройки этих серверов добиться их автоматического развёртывания (поднятия) в любой нужной конфигурации за минимальной короткое время и сделать это быстрее чем это сделает специалист в ручную.
Вот теперь давайте поговорим о ручном труде.
Большинство компаний в принцепе не понимают всего выше описанного и используют виртуальные машины как способ экономии на серверах, поднять 1 небольшую виртуалку дешевле чем заказывать новый и дорогой выделенный сервер. На самом деле все работает совсем иначе, Вам не нужно делать резервные копии виртуальных машин, отслеживать в режиме 24/7 их работоспособность и заставлять системных администраторов в 3 часа ночи подрываться что бы срочно переустановить виртуозку если с ней что то вдруг произойдет.
Виртуальная машина - это скот который должен жить ровно столько. сколько это необходимо для работы сервиса, службы или какого либо приложения. По завершении операции виртуальная машина удаляется и о ее существовании уже больше никто не вспоминает.
В моем опыте было очень много компаний которые не принимали данных подход. Выполнение ручного труда у них возведена в абсолют и если ты сидишь и ничего не делаешь, значит и не работаешь.
Не смотря на то что на дворе уже заканчивается 2020й, а специалисты моего профиля достаточно дороги, обращаются с ними как с обычными системными администраторами в лучшем случае нагружая работой по настройке сетей, виртуальных серверов и различных серверных приложений, в худшем же случае специалист используется как эникейщик который только что принтеры не заправляет.
Теперь коротко о том почему так часто приходится менять работу.
Я очень сильно ценю свой опыт и у меня есть свои определенные интересы и направление развития, мне интересно работать с инфраструктурой, автоматизировать процессы связанные с моей работой, работать с облачной инфраструктурой, люблю программировать и в целом мне нравиться изучать языки программирования. Я не люблю когда меня пытаются использовать как дешевого сисадмина эникейщика и плюют на мой опыт как DevOps инженера. Я принципиально не работаю с Windows в силу ее определенных особенностей и этот момент оговаривается при устройстве на работу, но всегда игнорируется руководством после оформления.
У меня так же есть определенные требования к постановкам задачи. Это даже отдельная тема, можно целую статью написать о том как не надо ставить задачу. Для примера во многих компаниях если и слышали про Jira , то у сотрудником толи из за недостатка творческого мышления, толи по каким либо другим причинам в принципе не выходит нормально описать задачу, расписать внятным подробным языком что нужно сделать, для чего и какие этапы этому следуют. На последнем месте работы такие задачи и вовсе прилетали на английском, при том, что сотрудник знает Русский, и работает в русскоязычной компании. В другой компании считалось нормой делать задачи без описания, например только указывая заголовок и ожидая, что исполнитель будет бегать по офису в поисках автора у него подробностей, а чего же он хотел.
На данный момент я нахожусь в поиске работы и очень надеюсь найти компанию которая понимает, что DevOps это не системный администратор, что он не должен разбираться в работе DNS серверов если это не касается подготовки окружения, что если в требованиях вакансии стоит владение Linux, это не означает, что DevOps должен на Windows заниматься настройкой сертификатов, что постановка задачи, это маленькое ТЗ исполнителю и должно содержать максимум информации для успешного выполнения.
Надеюсь данная статья привлечет внимание хорошего работодателя с которым можно было бы остаться на долгосрочное сотрудничество.