Облачные технологии быстро развиваются, знание инструментов дает возможность автоматизировать процесс тестирования кода и сборки приложений. Вышеперечисленные этапы работы происходят в проектах, которые разрабатываются с нуля. Но бывают и такие случаи, когда инженер приходит работать уже в запущенный проект, где разработчики приступили к созданию продукта без планирования и выбора архитектуры. А когда проект встал, пригласили DevOPS-инженера для решения проблем и автоматизации работы. Цикл за циклом, появляются различные системы упрощающие разработку и/или администрирование, появляются системы оркестрации, которые, ровно до тех пор, пока не требуется отойти от стандартного процесса, просты в использовании. Микросервисная архитектура также появилась с целью упрощения всего описанного выше — меньше взаимосвязей, проще в управлении.

Под страхом развязывания холивара, постараюсь объяснить глазами бывшего разработчика, как я представлял себе DevOps в целом. Чтобы успешно работать с Bash, писать скрипты и настраивать окружение, нужно понимать, как работают эти системы. Поэтому девопсам нужно знать Linux и разбираться в устройстве сетей. Выше мы перечисляли конкретные технологии, но это не единственное, с чем должен уметь работать девопс. Вот на что еще стоит обратить внимание, если вы хотите развиваться в этом направлении.

В Чём Разница Между Devops-инженером И Системным Администратором?

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

Но я знаю два случая из жизни, когда senior developers становились DevOps, потому что им надоело, как работает эксплуатация. И, к слову, помимо технических навыков вам точно потребуются некоторые софт скилы. Как минимум вы будете очень много общаться со всеми заинтересованными сторонами. Также вы будете продвигать новые идеи и технологии, что потребует от вас умения ясно и четко доносить свои мысли и умение спорить. Про стрессоустойчивость писать не буду, но терпение вам точно понадобится, поскольку внедрить новую крутую технологию зачастую невозможно в течение одного дня. Очень важная вещь, хотя про это забывают многие разработчики.

Мы пообщались с профессионалами, которые связали свою карьеру сначала с разработкой и системным администрированием, но со временем перешли в DevOps. Основываясь на DevOps-подходе и инженерах, которые его обеспечивают, проект получает гибкость, автоматизацию, непрерывность devops-инженер и отказоустойчивость, управление костами, ресурсами и т. Джон Арундел и Джастин Домингус «Kubernetes для DevOps». В ней рассказывается о работе Kubernetes — одном из основных DevOps-инструментов, а также о проверенных решениях повседневных проблем.

Глафира Иванова, Devops Engineer Компании Medindex

Все это вновь наложило ограничения на уровень знаний как разработчиков, так администраторов. В итоге именно вы решаете в каком направлении двигаться – стать системным администратором, разработчиком или перейти в DevOps. Как и во многих смежных направлениях, эти роли частично пересекаются. Системные администраторы уже имеют опыт написания сценариев и могут быть знакомы с технологиями автоматизации развертывания приложений, управления конфигурациями и так далее. Многие разработчики имеют представление о системном администрировании, так что изучать неофиту придется не половину (Dev или Ops), а немного меньше. Вдохновляйтесь выступлениями на конференциях и двигайте идею DevOps в свою команду.

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

Но мне повезло вскоре устроиться на работу джуном-питонистом. Было сложно и страшно, условия были отвратительными, а работа бесперспективной и выматывающей. Это одна из крупнейших конференций по DevOps, которая проходит в России. Можно вдохновиться практиками и выступления коллег, чтобы внедрить культуру и инструменты в своей работе. Помимо всего этого DevOps-инженер занимается просветительской деятельностью в командах и рассказывает о новых инструментах, которые позволяют снизить количество багов. Термин DevOps — это комбинация слов «разработка» (development) и «эксплуатация» (operations), которая отражает процесс интеграции этих дисциплин в единый непрерывный процесс.

Корректно будет сказать, что DevOps — это не конечная чётко определённая цель, это движение, по которому идёт вся компания. DevOps — это когда люди, технологии и процессы объединяются ради одной миссии — клиентоориентированности. Единственные настоящие DevOps-специалисты — это DevOps-евангелисты, которые несут в себе культуру, практики и организационные изменения. А тех, кого сейчас в сфере обычно называют DevOps-инженерами — сисадмины, на которых свалили все что можно, от поддержки продакшна до построения процесса поставки и релиза программного обеспечения.

• Компания должна пройти этапы от «зарождения и прорастания идеи», к «DevOps-трансформации» и затем к финальному «непрерывному улучшению».
• Поэтому часто от сисадмина ждут, что он будет выполнять ещё и работу DevOps-инженера — поддерживать разработчиков и помогать тестировщикам.
• Среди последних – коммуникация, ее можно выделить как один из важнейших навыков для хорошего DevOps-инженера.
• К слову, именно благодаря этому я и нашел свою первую работу, где разрабатывал небольшие проекты на QT/C++, занимался настройкой Cisco, а также поднимал почтовые сервера.
• Но без непосредственного участия людей, которые управляют разработкой и эксплуатацией, ничего не заведется.

Разработчики выполняют какие-то шаблонные действия вручную. Задача DevOps-инженера — заметить это, предложить им решение по автоматизации, продумать и внедрить это решение. Скажем, написать скрипт, который будет автоматизировать рутину. В небольших стартапах можно себе позволить выкатить релиз побыстрее силами разработчика, чтобы проверить «идею».

Для примера возьмем ‘construct framework’ Make, коего фреймворком я, к слову, не считаю. Да, я знаю про моду пихать Make куда угодно, где нужно и не нужно — обернуть Maven в Make например, серьезно? По сути Make просто обертка над shell, упрощающая именно команды компиляции, линковки, окружения компиляции, так же как и k8s. Когда человек решает стать DevOps, в первую очередь он должен понимать что это такое.