Развенчиваем распространённые мифы о DevOps

Миф
DevOps-инженер — это управленец, которому для работы достаточно базового знания системного администрирования и программирования

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

Управленцы в DevOps обычно отвечают за центры компетенций и за то, как формируется стек, какие инструменты используются и как распространяются знания в команде.

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

DevOps-инженеров можно сравнить с врачами: и у тех, и у других есть разные специализации. В инженерии их много — вот лишь несколько:

• TechOps — приближенная к области системного администрирования;
• DataOps — с упором на анализ данных;
• CloudOps — связанная с облачными решениями;
• SRE (Site Reliability Engineering) — с фокусом на обеспечение бесперебойной работы высоконагруженных сервисов;
• DevSecOps — направленная на обеспечение безопасности в рамках пайплайнов автоматизации.

Для примера более детально остановимся на последней специализации. DevSecOps-инженер ― это специалист, который применяет инструменты, отвечающие за безопасность самих приложений, проверяет валидность кода, его функцию, что делает приложение, а также определяет и создаёт инструменты, позволяющие следить за поведением приложения и искать аномалии.

Говоря о сферах, из которых наиболее плавно можно переквалифицироваться в DevOps, то по своему опыту могу сказать, что это разработка. Особенно то, что связано с backend-разработкой. Я пришёл в TAGES на место разработчика, но постепенно всё больше хотел погружаться в разные контексты. Было интересно узнать, что происходит с кодом после его написания, как всё это взаимодействует с другими компонентами приложения, как влияет на общие цепочки процессов, сколько ресурсов потребляет приложение, как мониторить, обслуживать и поддерживать.

Миф
Начинающий DevOps-инженер обязан разбираться в программировании и в системном администрировании на уровне Middle+ или Senior

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

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

Для начала будет достаточно базовых знаний в системном администрировании и программировании:

• понимать командные оболочки Bash и PowerShell, системы управления версиями Git, сетевые модели OSI и TCP/IP;
• знать объектно-ориентированное программирование, взаимодействие с интерфейсами REST и RPC, базы данных SQL и NoSQL.

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

Помимо языков программирования, есть ещё системные утилиты для управления, мониторинга и отладки работы приложения и сервисы обвязки — или инфраструктура обвязки — для обеспечения надёжности, масштабируемости и быстроты в разработке и доставке приложений. Они включают в себя системы контроля версий, автоматизированные сборщики и инструменты для развёртывания, системы мониторинга и управления конфигурацией.

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

Таким образом, на старте DevOps-пути глубокие знания в программировании и администрировании не обязательны.

Миф
DevOps-инженера достаточно привлечь к проекту один раз, чтобы он сказал, как всё должно работать, а дальше уже программисты могут работать сами по выстроенному плану

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

Индустрия развивается, появляются новые инструменты доставки контента, инструменты запуска самих приложений ― runtime. Раньше нужно было подключаться к FTP-серверам, загружать на них свои файлы и самому настраивать Apache-серверы. Потом появились полностью управляемые виртуальные машины, а сейчас на их смену пришёл Kubernetes, который позволяет заниматься автоматизацией и оркестрированием приложений.

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

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

Постоянная коммуникация DevOps с разработчиками позволяет глубоко погружаться в проблематику и предлагать наилучшее решение для упрощения процесса разработки.

Можно сказать, что DevOps-инженер ― это надёжный товарищ разработчика, который всегда поможет, облегчит работу, подскажет нужный инструмент, ускорит процесс и сделает релиз качественнее.