Развенчиваем распространённые мифы о DevOps05.06.2023 21:33

Понятие DevOps (Development Operations) включает в себя не просто технологии, специалистов и методологии — это целая культура работы в ИТ-отрасли. И в ней, как и в любой другой культуре, встречаются ошибочные мнения и заблуждения.

Руководитель разработки ИТ-компании TAGES Данил Мишин развеивает часто встречающиеся мифы о 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-инженер ― это надёжный товарищ разработчика, который всегда поможет, облегчит работу, подскажет нужный инструмент, ускорит процесс и сделает релиз качественнее.

 Профессия

DevOps-инженер с нуля

Узнать больше

• На практике отстроите процесс DevOps с помощью облачных сервисов
• Выполните более 200 практических заданий, основанных на реальных задачах инженеров
• Курс создан вместе с DevOps-специалистами и архитекторами Yandex Cloud

Миф
DevOps нужен любой компании, в которой есть ИТ-отдел

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

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

Если разработчику не нужно проектировать и развёртывать инфраструктуру ― как в standalone-разработке, не работающей в облаках, не имеющей функции web-приложения и интеграционных взаимодействий с другими приложениями или сервисами ― и он пишет приложение, которое запускается на одном компьютере, то здесь DevOps-процессы могут вообще не пригодиться. Особенно если над проектом работает 1–2 человека.

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

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

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

Часто компаниям нет смысла нанимать внутреннюю команду DevOps-инженеров, так как можно привлечь внешнюю для закрытия определённых потребностей. Существует даже отдельная практика ― DevOps-as-a-Service, когда компания не занимается инфраструктурными вещами, а нанимает команду, которая настраивает пайплайны, автоматизацию процессов и прочее. Например, мы в TAGES нередко оказываем подобные услуги для внешних команд. У нас есть свои dev-сервера, на которых мы настраиваем всю автоматизацию для клиента: предоставляем инструменты для мониторинга, логирования и других обслуживающих процессов.

Миф
DevOps-инженеры нужны только для настройки процессов CI/CD

Процессы нужно не только автоматизировать, но и отладить. Следовательно, за ними требуется постоянное наблюдение ― контроль рабочей среды в режиме реального времени. DevOps-инженеры называют это англоязычным термином «observability».

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

Миф
Не нужно создавать кастомные решения под потребности компании — достаточно копировать опыт лучших компаний

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

Нет универсальных решений, но есть множество инструментов, среди которых DevOps-команда выбирает нужные.

Скопировать в любом случае не получится ― каждая компания решает свои проблемы.На создание инфраструктуры, её поддержку и автоматизацию тратятся ресурсы — и вопрос будет заключаться в целесообразности таких трат. Например, каким-то компаниям будет достаточно только настроить простой CI/CD на GitLab, который будет поднимать виртуальную машину в облаке и запускать нужный сервис, а для мониторинга будет хватать Grafana с визуализацией примитивных метрик.

Иными словами, зачем покупать шуруповёрт ради пары маленьких шурупов, если можно обойтись обычной отвёрткой?

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

Мнение автора и редакции может не совпадать. Хотите написать колонку для Нетологии? Читайте наши условия публикации. Чтобы быть в курсе всех новостей и читать новые статьи, присоединяйтесь к Телеграм-каналу Нетологии.