DevOps: задачи, кейсы, основные инструменты системного инженера

В этом году Виктор празднует профессиональный юбилей – 20 лет работы в IT-сфере. Cейчас он работает старшим системным инженером в рязанском офисе EPAM. А еще помогает в профессиональном развитии нескольким специалистам компании, выполняя роль их ресурсного менеджера, участвует в организации рязанского DevOps-комьюнити и помогает обучать начинающих специалистов в тренинг-центре.

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

Задачи DevOps-инженеров

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

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

А еще в специальности много программирования. В задачи Devops-инженера входит написание большого количества кода. Но этот код пишется не на классических языках, а на скриптовых, например, Python, GoLang или Bash.

Роли специалистов в среде DevOps

DevOps – это слияние слов Development and Operations, разработка и функционирование. Соответственно, Devops-специалист может иметь уклон на поддержку разработки. В этом случае он обеспечивает разработчикам информацию о платформе: компеляцию, сборку продукта, тестирование и так далее. А есть специалисты с уклоном в Operations, то есть, в работу самого продукта. Они отвечают за развертывание продукта в различных средах, стабильность работы, наличие необходимых ресурсов для работы приложения. Но это разделение в компании не фиксируется официально, руководители просто знают кто к чему тяготеет. Вообще предполагается, что Devops должен одинаково ориентироваться в двух сферах.

Разница между системным администратором и системным инженером

Чтобы разобраться, почему системный администратор – не системный инженер, нужно уточнить откуда берутся DevOps-ы. Если открыть Google и поискать IT-курсы, то большинство из них будет связано с разработкой или тестированием. Курсы DevOps сейчас найти можно, но они будут в меньшинстве, а где-то 2 года назад их почти не было. Сейчас в EPAM мы активно набираем даже начинающих специалистов на бесплатное обучение по DevOps. Обучение полноценного, серьезного Devops-специалиста – это сложная задача. Правильно будет сказать, что лучшие DevOps-инженеры получаются либо из системных администраторов, которым интересно программирование и применение автоматизации к задачам, либо из программистов, которые не только писали код, но и пытались настроить окружение, чтобы он правильно работал. Поэтому большинство системных инженеров, учитывая, что это направление молодое, пришло из системных администраторов и программистов.

О сочетании методологий DevOps и Agile на проекте

DevOps и Agile связывает то, что их часто используют вместе. Сами по себе они разные, поэтому могут существовать и отдельно друг от друга. Цель Agile – это постепенное внедрение изменений, разделение процесса разработки на небольшие этапы. По результатам каждого из этапов раз в две - три недели мы получаем код, который может быть доставлен клиенту. А DevOps создана для того, чтобы максимально быстро доставлять код. Код можно внедрять по Agile-методологии без DevOps или в DevOps.

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

CI/CD как часть DevOps

CI/CD – это концепции DevOps, которые расшифровываются, как Continuous Integration и Continuous Delivery.

Continuous Integration заключается в том, что, изменения, которые разработчики вносят в код, должны как можно чаще попадать в общий репозиторий. В таком режиме командам максимально удобно работать. Разработчик сразу видит изменения, внесенные коллегами и в соответствии с ними корректирует или разрабатывает свой код. По идеальной методологии CI разработчики размещают часть написанного кода раз в день – это считается необходимым минимумом. Но в реальности возможны разные варианты: как 30 раз в день, так и раз в неделю. Последние 2 года на моём проекте CI построен не в классическом плане. Я мог коммитить код в репозитории до 10 раз в день и больше. Это происходило в отдельных обособленных ветках и разделённых задачах. Каждые мои 20 коммитов в день приводили к компиляции, тестированию и выдаче результата, о том, насколько код нормален.

Continuous Delivery – это вторая часть процесса, доставка кода в виде работающего приложения клиенту. В идеальной DevOps-структуре считается, что протестированная часть кода сразу попадает к клиенту на рабочее приложение. Я пока на практике подобного не встречал, но, говорят, что такие гиганты, как Netflix, так и работают.

Рассказывая о CI/CD, также важно отдельно упомянуть Pipeline. В переводе это слово означает «труба» или «трубопровод». В Devops-мире так называют процесс, по которому обрабатывается ПО как раз, чтобы пройти CI-цикл или CD-цикл. Например, разработчик пишет Java-приложение. При проверке его работоспособности, приложение компилируется, проходит модульные тесты, собирается, запускается и автотестируется – так выглядит CI-цикл для этого приложения. Эти операции собираются и каждая представляет собой отдельный шаг Pipeline-а. А вместе они представляют своебразную трубу, через которое пролетело приложение. Если на одной из стадий возникла проблема, мы это увидим. Если приложение прошло весь Pipeline, значит оно считается рабочим.

Контейнеризация, виртуализация и Docker

Виртуализация, контейнеризация и Docker сокращают накладные расходы на запуск приложения, помогая отказаться, например, от разных операционных систем.

Контейнер – это механизм, который позволяет использовать максимальную часть техники для запуска конкретных приложений, а не для обслуживания операционных систем или чего-то подобного. Он представляет собой легковесную структуру, которая содержит в себе приложения и системные библиотеки. Сделав виртуальным физический сервер, на котором работает одно приложение, можно запустить одновременно 10. Если поставить там ещё и Docker, то максимальное число увеличится до 20. Контейнеры хорошо сочетаются с DevOps, потому что обновить приложение «бесшовно» для клиента гораздо проще, чем на физическом сервере. Сейчас огромная часть программ, например Gmail, работает так, а пользователи об этом даже не догадываются.

Docker – самое популярное, но не единственное средство для запуска приложений в контейнерах. Это программное обеспечение больше подходит для работы с операционной системой Linuх. Полноценный Docker под Windows еще разрабатывается, и в качестве широкоиспользованного продукта пока что не существует. Поэтому пока специалист, знающий Linux имеет больше возможностей, чем DevOps, знающий только Windows.

Использование Jenkins в Devops-инфраструктуре

DevOps-инфраструктура часто строится вокруг центрального компонента, который обеспечивает CI/CD-процессы. Таких систем множество, но самая популярная из них – Jenkins. Это один из самых старых инструментов, из-за чего для него уже существует огромное количество плагинов. Поскольку он бесплатный, начинающий DevOps может им воспользоваться без ограничений, поэтому большинство новичков в DevOps видели или знают, что такое Jenkins. Недостаток этой бесплатной системы в том, что, некому предъявить претензии. если она работет плохо – приходится искать решение проблемы самостоятельно. Как раз поэтому у Jenkins и появились платные конкуренты, которые предоставляют поддержку. Практически все крупные игроки IT рынка предлагают подобные программы: TeamCity, GitLab CI, Bitbucket CI, Azure CI, AWS CI.

DevOps-инфраструктура работает, как конструктор. В Jenkins много инструментов для тестирования, сборки, проверки кода. Для хранения исходного кода к Jenkins можно добавить GitLab, а можно и собственный Git-сервер. Затем нужно выбрать сборщик. Можно запускать его на Jenkins, прикрутить к нему исполнители, на котоых будет проходить сборка. Далее требуется хранилище для артефактов, то есть, того, что получилось в результате сборки кода. При сборе Java-приложения в итоге получается JAR-файл, для Windows – exe-файл, или dll. К Jenkins возможно также прикрутить Nexus или Artifactory, в которые попадут файлы, полученные после сборки. Так в итоге собирается CI-процесс, из инструментов, которые более удобны в использовании.

О сложных задачах и поиске решения

Последний сложный кейс на проекте возник буквально 3 недели назад, когда я должен был приспособить для Azure open-source решение, которое было реализовано для облачного провайдера AWS. Я адаптировал его, что помогло команде с развертыванием окружения и одновременным запуском 150 серверов в облаке Microsoft Azure. Благодаря этому время запуска сократилось с 4,5 часов до 30 минут.

В нестандартных ситуациях в EPAM помогает система юнитов, подразделений. То есть, мы стараемся объединять в сотрудников подразделения с одинаковой экспертизой. DevOps-ы общаются друг с другом, и более опытные сотрудники помогают новичкам, как ресурсные менеджеры. Первый человек, к которому можно придти – это коллега в юните. Далее следует отправиться к DevOps-практике – это все российские DevOps-ы в EPAM. Если никто не смог помочь и там, можно пойти в центр компетенций DevOps – это объединение DevOps-ов EPAM по всему миру.

Если говорить про начинающего специалиста, который пока в нашей компании не работает, но хочет быть DevOps-инженером, то можно проконсультироваться на форумах, к примеру, попросить совет на GitHub или GitLab. Проекты, выложенные на этих сайтах доступны любому зарегестированному пользователю. Там есть раздел «проблемы», куда можно написать и получить решение или обсудить задачу с другими людьми. Мы часто так делаем, обращаясь на этом ресурсе к тем, кто обладает наибольшим опытом. Такого понятия, как глобальное мировое DevOps-комьюнити нет, но часто ПО разрабатывает большое количество энтузиастов, которые готовы на GitHub или других форумах безвозмездно отвечать на вопросы.

Ресурсы для начинающих DevOps-инженеров

Сначала начинающему DevOps-инженеру можно смело заходить на такой ресурс, как Habr и читать там DevOps-раздел. Затем стоит поискать обучающие видео на YouTube. С хорошим английским можно пользоваться такими ресурсами, как PluralSight и Linux Academy. С учетом того, что DevOps состоит из большого количества проектов с открытым кодом, ищите бесплатную информацию в виде подкастов и статей. Основная часть из них, конечно, на английском языке, но на русском тоже много материалов. Также можно пройти по крупным игрокам (Microsoft, Google, Oracle) и посмотреть, что есть у них. Компания Microsoft недавно поняла, что людей нужно обучать использованию своих продуктов и сделала много тренингов. По Azure Cloud материалы бесплатные и доступны на русском и английском языках. Если раньше компании просили за тренинги огромные деньги, то сейчас они существуют в свободном доступе, потому что конкуренция стала высокой, и необходимо активно привлекать людей в свой продукт.

Как резюме, начинайте с Хабра и YouTube. Выбирайте интересные материалы по DevOps и читайте все, что есть в них по ссылкам. Смотрите видео, которое выкладывают официальные источники и DevOps-энтузиасты.