Linux и инструменты devops что это

Обновлено: 04.07.2024

Важные инструменты, которые должен знать DevOps-инженер: от закостенелых Jenkins и Splunk, до современных Loki и Lens.

Система управления исходным кодом, которой пользуются, пожалуй, вся индустрия. Это стандарт трекинга исходного кода. Git — единственная поддерживает все современные паттерны разработки и обязательна для изучения DevOps-инженеру.

Gitlab

Если вы работаете с молодой командой, то я бы посоветовал изучить Gitlab. Система поддерживает полный цикл разработки, включающий управление исходным кодом на Git, Continuous integration, Continuous Delivery, issue tracking.

На одном Gitlab можно полностью вести разработку «мерджиться», «деплоиться» и прочее. Однако система навязывает определенный workflow, который не всегда подходит проекту. Это возможно обойти, но редко результат получается хорошим.

Jenkins

Старожил на поприще систем автоматизации сегодня чаще используется в уже «вставших на ноги» компаниях. Jenkins разрабатывался, как инструмент непрерывной интеграции, но развился до системы способной запустить ракеты в космос благодаря плагинам.

Это его достоинство и недостаток. Из-за обилия необходимых плагинов система становится тяжёлой. Постоянные обновления и риски, что все разрушится, а также отвратительный UI могут превратить работу в ад. Сегодня немногие новые команды выбирают Jenkins, но в проектах около пятилетней давности система встречается часто.

Решения Atlassian уже стали определенным индустриальным стандартом. Работая с крупными заказчиками, вы, скорее всего, будете использовать именно Jira. Ежедневно в системе я завожу тикеты, трекаю время на выполнение задач, состояние спринтов, создаю release notes и решаю другие задачи. Несмотря на ряд аналогов, плюс Jira — интеграция с другими системами Atlassian, например Confluence.

Confluence

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

Docker

Система контейнеризации и одна из основных технологий для DevOps-инженера. ПО для автоматизации развёртывания и изоляции приложений. Мы используем для сборки и запуска контейнеров в DEV окружениях.

Kubernetes

Платформа для автоматизации управления контейнерами приложений. Kubernetes стал стандартом, обойдя немногочисленных конкурентов, типа Rancher. Система предоставляет механизмы решения всех стандартных задач IT по управлению приложениями. Управляется декларативно — оператор передает контроллеру Kubernetes желаемое состояние окружения, и тот сам выполняет все необходимые действия для его достижения.

Графический интерфейс для управления и мониторинга Kubernetes кластеров. Также известен, как GUI для Kubernetes, где возможно увидеть все их сущности, включая пользовательские ресурсы. Хоть это и не обязательный инструмент для DevOps-инженера, но я рекомендую его использовать. Здесь много разных крутых возможностей. Например, доступ к приватным кластерам через собственный прокси.

Prometheus

Grafana

Dashboard-решение для визуализации полученных данных. Мы используем Grafana в связке с Prometheus. Система демонстрирует графики, таблицы, и используется в современных стеках больших решений.

Молодая система сбора логов с приложений, вдохновленная Prometheus. До Loki логи всегда хранились, как текст в файлах либо индексировались в системе вроде Elasticsearch. Это приводило к большому весу на диске и нагрузке при поиске и агрегации. Loki индексирует метадату, позволяя хранить логи в достаточно медленном и дешёвом хранилище вроде Object Storage (AWS S3 etc), так как для поиска и агрегации не используется весь текст. Они занимают меньше места и поиск происходит быстрее по стандартизированным лейблам.

Splunk

Большая неповоротливая система по мониторингу всех данных. Старая, мощная но малопроизводительная. Крупные компании не хотят изменять Splunk с Prometheus и Grafana. Отчасти из-за платной поддержки. Поэтому, DevOps-инженеру в большой организации придется научиться работать с Splunk.

Terraform

Система управления инфраструктурой с помощью API, облачными провайдерами, приватными облаками. Terraform стала первой, позволившей нам работать с разными облачными провайдерами. Для описания и применения окружения в коде не нужно идти в консоль. Система сама создает необходимые сети, кластера и так далее.

ABBYY , Москва, можно удалённо , От 230 000 до 330 000 ₽

Большая часть из названных инструментов — обязательна для DevOps-инженера. Однако единый список для каждого разработчика составить невозможно. Выбор инструментов зависит от выбора языка. Поэтому умение использовать инструменты — только часть необходимых навыков.

DevOps-инженеру нужно постоянно автоматизировать шаги. Вам понадобится «клей», который бы связывал все инструменты в общий пайплайн. Для этого помимо инструментов необходимо изучить сценарные языки — Python, JavaScript, Ruby, Go, Bash и другие.

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

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

Основы языка Python

Курс проходит в дистанционном формате, поэтому присоединиться к занятиям можно из любого города или региона. Вебинары проходят 2-3 раза в неделю. Слушатели получают обратную связь к выполненным домашним заданиям. Это позволит лучше разобраться в материалах курса и быстрее усвоить новую информацию.

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

Часов в программе

Цель программы

Получение компетенции, необходимой для выполнения нового вида профессиональной деятельности – внедрение DevOps практик; приобретение новой квалификации -DevOps-инженер.

Актуальность

Несколько лет назад в IT появилась новая специальность DevOps-инженер. Она очень быстро стала одной из наиболее популярных и востребованных на рынке. Сам термин расшифровывается как Development Operations. Это не столько специальность, сколько подход к организации работы в средней или крупной компании при подготовке продукта или сервиса. Дело в том, что в процессе подготовки участвуют разные отделы одной компании, и действия их далеко не всегда хорошо скоординированы. DevOps-инженер, который помогает координировать процесс разработки, способствует автоматизации процессов, улучшает их прозрачность.

Итоговая аттестация 2 часа

защита выпускной аттестационной (квалификационной) работы- защита проектной работы

Компетенции

Способен к интеграционному тестированию ИС, исправлению дефектов и несоответствий в коде ИС и документации к ИС

Инструменты и методы интеграционного тестирования
Основы управления изменениями
Предметную область автоматизации
Возможности ИС
Основы современных операционных систем
Основы современных систем управления базами данных
Теорию баз данных
Системы хранения и анализа баз данных
Современные методики тестирования разрабатываемых ИС: основы интеграционного тестирования

Тестировать ИС с использованием тест-планов
Работать с записями по качеству (в том числе с корректирующими действиями, предупреждающими действиями, запросами на исправление несоответствий)
Кодировать на языках программирования
Тестировать результаты собственной работы
Работать с записями по качеству (в том числе с корректирующими действиями, предупреждающими действиями, запросами на исправление несоответствий)

Стадии разработки ПО. Подходы к разработке ПО. DevOps. CI/CD. Работа в команде. Другие подходы. Сборщики ПО. Идея контейнеров. Docker. Команды Docker. Docker registry. Другие системы контейнеризации. CI/CD. Delivery Pipeline. TeamCity. Kubernetes. Octopus. OpenShift.

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

Александр Титов управляющий партнер Экспресс 42, основатель сообщества DevOps Moscow: Я живу в понимании DevOps как набора практик по организации целиком всей разработки

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

В целом я живу в понимании DevOps как набора практик по организации целиком всей разработки — и это не про сисадминов, и не про то, как Kubernetes выстраивается. Это про общее формирование подхода к продуктовой разработке. Тут ключевым моментом является формирование практики совместного сотворчества.

В сервисном подходе к IT это сотворчество было не обязательно — там все фокусируются просто на поддержке отдельных бизнес-функций. Сейчас же все сообщество ищет подходы в формировании творческой продуктовой разработки — в соединении производства и творчества. Для меня именно это является определением термина DevOps.

Какие практики входят в DevOps?

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

Как бизнес начинает использовать эти практики?

— В первую очередь компании нужно понять, что IT-направление — не сервисная история, а основная производственная функция. Нужно перевести IT из поддерживающей истории в зарабатывающую. Это первый шаг на уровне ментальности с точки зрения бизнеса. Дальше — нужно понять, каких компетенций тебе для этого не хватает, посмотреть на другие компании, которые в эту игру уже играют. Например, посмотреть на Google и Facebook — и увидеть, как они строят свои рабочие процессы, сравнить с производственными процессами в вашей компании.

После этого станут видны те компетенции, которых в принципе не хватает компании и продукту, который она делает. Их придется отстраивать каждой компании индивидуально — как организован процесс поставки ПО, как организована вокруг этого команда. Это те задачи, которые каждая компания решает только самостоятельно. По сути, решения этих проблем нельзя просто взять и скопировать — такая модель пришла из сервисного подхода, который мы стараемся изменить.

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

Кто тогда такие DevOps-инженеры?

— К ним я отношусь как к временному эффекту. Мы сейчас находимся на водоразделе: моменте перехода IT из сервисной модели в продуктовую. В сервисной модели всегда такой подход, нужно закрывать функцию — для этого нужен специалист. Появилась странная штука DevOps? Не проблема, нужна роль, которая это закроет. И так появляется DevOps-инженер, который как Ops-инженер, но еще умеет что-то. Это мышление из старой модели, но уже про новые вещи. Люди еще не научились думать, как это делают настоящие продуктовые команды. Поэтому они ищут специалистов вот так — и просто не понимают до конца набор компетенций, который им нужен.

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

Я могу сравнить это с периодом начала интернета — тогда была позиция веб-мастера, который и почтовые сервера настраивал, и верстку на HTML делал, и продукт курировал, и дизайн создавал. Сейчас каждая компетенция ушла отдельному специалисту. Точно так же произойдет и DevOps-инженером.

Зачастую в этом DevOps-инженере соединены все противоречия и недостатки текущей сервисной модели. Как только в компанию приходит DevOps-инженер, то у руководства сразу можно спросить — чем он будет заниматься. Окажется, что это либо фулстек веб-мастер, либо специалист с четко выраженными компетенциями — например, сисадмин. Тогда его так и нужно называть — инженер, например, по Continuous Integration. Однако пока в головах менеджеров, которые занимаются управлением в IT, это направление еще не разделилось, и они продолжают существовать в сервисной парадигме, а не думать продуктом и потребностями клиента или пользователей.

Думаю, что пройдет еще несколько лет, и DevOps-инженеры уйдут в историю, как веб-мастера. На их место придут отдельные инженеры по Continuous Integration, продакшн-инженеры, платформенные инженеры, которые работают с Kubernetes, специалисты, работающие с большими бэкенд-системами, такими как базы данных, и так далее. Так разделится эта профессия.

Что будет с DevOps в ближайшие годы?

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

С точки зрения технологий у нас все уже есть, а вот с точки зрения культурных и организационных парадигм IT ждут серьезные перемены.

Важные ссылки про DevOps:

— Базовые вещи от гуру сферы

Владимир Утратенко, Head of Technology Platform в Сравни.ру, со-организатор сообщества DevOps Moscow: Многие крупные компании, которые к 2023 году не начнут внедрять DevOps, просто не удержатся на рынке

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

Кто в компании должен внедрять DevOps?

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

Как технически устроен DevOps?

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

Каким будет будущее DevOps?

— Сейчас становится понятно, что все больше и больше бизнеса использует DevOps. Было какое-то исследование, что многие крупные компании, которые к 2023 году не начнут внедрять DevOps, просто не удержатся на рынке. Это очень вероятно, учитывая, что темпы производства программного обеспечения растут и необходимы новые эффективные способы взаимодействия между участниками процесса разработки и процесса поставки ПО.

Всем ли это нужно? Конечно, нет. DevOps имеет смысл внедрять преимущественно технологическим компаниям, которые разрабатывают цифровой продукт и для которых важен Time-to-Market в своей нише (время от начала разработки идеи, до того момента, как её увидят пользователи).

Можно подумать: «А что, собственно, не так? Почему нельзя просто взять и релизить чаще, ничего не меняя?»

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

изоляция между отделами, благодаря которой нет обмена информацией и необходимой глубины коммуникаций и доверия
отсутствие ответственного за весь продукт
разные KPI и приоритеты у dev, qa и ops команд, благодаря чему каждый «тянет одеяло на себя» и делает так, как ему лучше
каждая команда изобретает свой велосипед, в котором понимает только она (крайне трудно переиспользовать опыт).

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

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

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

Три пути: принцип потока, принцип непрерывной обратной связи, принцип непрерывного обучения и экспериментирования
CALMs
Accelerate

Чем занимается DevOps-инженер в команде?

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

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

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

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

Ясность приходит позже. По мере взросления компании и смены парадигмы коммуникаций и вообще процессов, каждую роль занимает отдельный человек/люди с конкретной специализацией. И вот у нас уже появляются build-инженер, релиз-инженер, инженер платформы, DBA, Linux-инженер, SRE, специалист по безопасности и так далее.

Может ли программист стать DevOps-инженером? Как вообще становятся DevOps?

— Поговорим не совсем про реальность, но про идеальный случай, раз уж имеем дело с подобным собирательным образом. В идеальном случае DevOps-инженер, помимо глубокой технической экспертизы, разбирается в теме этого самого DevOps, и помогает распространять знания и практики, компетенции внутри компании (часть enabling team).

Стать таким персонажем может любой инженер: системный администратор, разработчик, инженер автоматизации, инженер платформы и т.д. Достаточно серьёзно углубить soft-skills, hard-skills, изучить культуру и практики.

Программист в некотором роде — идеальный кандидат, так как он изначально ближе всех к продукту и процессу разработки. Ему легче всех понять новые концепции, подходы и понять боль как Dev, так и Ops. You code it, you build it, you run it, you own it.

Как же приходят к DevOps? Это вот когда человек получил некий опыт работы в IT, затем начитался книжек, наслушался докладов, и в нём это откликается. Человек понимает, что больше нельзя жить как раньше! Хватит это терпеть! У него появляется жгучее желание сделать эту компанию лучше, изменить процессы, инструменты и подходы к работе и избавить коллег вокруг от регулярной боли и рутины!

Что стоит прочитать в первую очередь:

Проект «Феникс»
DevOps HandBook
Accelerate

В чём разница между DevOps-инженером и системным администратором?

— В зарплате. Если серьёзно, могу предположить, что DevOps-инженер:

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

Куда расти DevOps-инженеру?

— На самом деле — куда угодно. Самый популярный вектор — в SRE. Однако можно расти и в разработчика продуктовой команды, разработчика/инженера платформенной команды, архитектора, возглавить центр-компетенции, заняться развитием внутренних сообществ или перейти в enabling team. Всё очень зависит от кругозора, желаний и конкретной ситуации в конкретной компании. Каких-то конкретных ограничений нет, просто каждая из ролей подразумевает углублённую специализацию в ту или иную сторону.

Какие инструменты и технологии должен знать DevOps-инженер?

— Он однозначно должен знать базу и иметь хотя бы представление о многих вещах. Полноценный Ж-shape person. ОС/linux, сети, git, Docker, навыки разработки, базы данных, SQL, SDLC, CI, мониторинг и т.д. и т.п. Вот, кстати, довольно популярный универсальный «DevOps-roadmap» по инструментам и технологиям для изучения. А дальше нужно углубляться в конкретные инструменты под конкретные задачи, выполнения которых от тебя ожидают. Как мы помним, DevOps-инженер в разных компаниях будет заниматься абсолютно разным. Но ему точно потребуются soft-skills и навыки общения, так как общаться предстоит очень много.

Порекомендую пару известных сайтов для подбора инструмента под конкретную сферу/задачу, так как нынче их слишком много: раз, два.

Какие подходы и практики в своей работе используют DevOps-инженеры?

— Все принципы, подходы и практики трудно описать «коротко» и понятно. Перечислю основные технические практики:

Быстрое и надёжное автоматизированное тестирование
Динамические тестовые стенды
Непрерывная поставка (CI, CD, TBD)
IaC и версионирование всего как подход
Непрерывный мониторинг и обратная связь
Использование PaaS
Кросс-функциональные команды
Слабосвязанная архитектура
Общая ответственность всех за свои решения
Распространение знаний по командам и компании
Привлечение команды безопасности на всех этапах SDLC
и другие

Какое будущее ждет сферу DevOps?

— 2020 год наглядно показал, что переход в онлайн и цифровая трансформация для многих компаний не то что неизбежны, а жизненно необходимы. А значит, и перестройка на рельсы DevOps как часть цифровой трансформации – лишь вопрос времени, и останутся и выживут те, кто это осилит.

Познакомьтесь поближе с практиками DevOps на нашем интенсиве «DevOps для программистов»

DevOps — подход, про который вы наверняка слышали. Про него любят рассуждать многие, но есть ли понимание того, что это такое на самом деле? По данным рекрутинговых порталов, профессия DevOps-инженера — актуальна и хорошо оплачивается. Общее количество вакансий в России — около 500. Это значит, что хороших специалистов на рынке не так много, несмотря на обилие обучающих курсов. Разбираемся — что же такое DevOps и как он устроен.

Основа DevOps-подхода — это документ. «DevOps Manifesto», в котором подробно расписаны области его применения. Согласно ему, DevOps — это не просто утвержденные способы сертификации, набор ролей, инструментов или предписаний, а целая «философия», которая состоит из следующих установок:

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

Инструменты

Devops должен очень хорошо быть знакомым с процессом организации разработки программного обеспечения. Можно выделить 2 наиболее распространенных подхода:

GitHub Flow

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

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

GitLab Flow

Фактически, это расширение GitHub Flow, цель которого — еще больше стандартизировать процесс разработки и сделать связь между кодом и решаемыми проблемами более прозрачной. Для этого здесь введены дополнительные виды веток, например, ветки среды и выпуска. Также важная вещь здесь следующая — любое значительное изменение в коде должно сопровождаться подробным объяснением причин этого.

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

Практики DevOps

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

Непрерывная интеграция. Ее суть в том, что команда постоянно объединяет изменения программного кода в центральном репозитории, после чего автоматически происходят его сборка, тестирование и запуск. Главные преимущества этой практики — быстрый поиск и исправление ошибок, улучшение качества ПО и сокращение временных затрат на проверку и выпуск обновлений.

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

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

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

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

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

Итоги применения DevOps-подхода

Среди итогов применения DevOps можно назвать следующие:

высокая удовлетворенность пользователей продуктом;
быстрое добавление функциональности;
активное применения инноваций в работе;
постоянное улучшение рабочих процессов;
мониторинг прогресса в проектах в наглядном визуальном виде;
рациональное и оправданное использование имеющихся ресурсов.

Таким образом, DevOps-подхода подойдет любой компании, где в разработке ПО участвуют более 5 человек. В этом случае внедрение DevOps уже имеет смысл и способно сделать работу эффективнее. Эта методика активно применяется в FAANG, телекоме, финтехе и других технологических компаниях.

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

Читайте также: