Почему бизнес хочет devops и что нужно знать инженеру, чтобы говорить с ним на одном языке

Сколько зарабатывает DevOps Engineer?

Заработная плата специалиста DevOps является одной из самых высоких в ИТ-отрасли, но зависит не только от навыков и длительности трудового стажа. На основании опыта специалистов принято делить на несколько категорий, оплата в каждой может существенно разниться:

• Junior – до 1 года опыта;
• Middle – от 1 до 3 лет опыта;
• Senior – свыше 3 лет опыта.

Не менее важно и расположение компании-работодателя: традиционно больше всего зарабатывают DevOps-инженеры в Москве. Уровень средней зарплаты DevOps-инженера в Москве за 2019/начало 2020 года по данным портала по трудоустройству trud.com

Уровень средней зарплаты DevOps-инженера в Москве за 2019/начало 2020 года по данным портала по трудоустройству trud.com

Градация наблюдается и по регионам страны.

Уровень средней зарплаты DevOps-инженера в регионах России за 2019/начало 2020 года по данным портала по трудоустройству trud.com

Также размер оплаты напрямую коррелирует со спектром выполняемых задач и уровнем компании. В целом же, согласно статистике сервиса Хабр Карьера, средняя медианная зарплата DevOps находилась во втором полугодии 2020 года на уровне 155 000 рублей.

Рынок DevOps ресурсов

Давайте рассмотрим несколько вакансий на позицию DevOps от разных компаний.

Итак:

• с 1 по 6 — системный администратор
• 7 — немного сетевого администрирования, что тоже укладывается в сисадмина, уровня Middle
• 8 — немного безопасности, что обязательно для сисадмина уровня Middle
• 9-11 — Middle System Administrator
• 12 — В зависимости от поставленных задач либо Middle System Administrator, либо Build Engineer
• 13 — Виртуализация — Middle System Administrator, либо так называемый CloudOps, расширенные знания именно сервисов конкретной хостинг площадки, для эффективного использования денежных средств и снижения нагрузки на обслуживание

Резюмируя по данной вакансии можно сказать, что ребятам достаточно Middle/Senior System Administrator.

Кстати, не стоит сильно разделять админов на Linux/Windows. Я конечно понимаю, что сервисы и системы этих двух миров различаются, но основа у всех одна и любой уважающий себя админ знаком как с одним, так и с другим, и даже если не знаком, то для грамотного админа не составит труда ознакомится с этим.

Рассмотрим иную вакансию:

Разбираем:

• 1 — Senior System Administrator
• 2 — В зависимости от смысла вкладываемого в этот стэк — Middle/Senior System Administrator
• 3 — Опыт работы, в том числе, может означать — «Кластер не подымал, но создавал и управлял виртуалками, был один Docker хост, доступ к контейнерам натил» — Middle System Administrator
• 4 — Junior System Administrator — да, админ не умеющий писать элементарные скрипты автоматизации, вне зависимости от языка, не админ — эникей.
• 5 — Middle System Administrator
• 6 — Senior System Administrator

Резюмируя — Middle/Senior System Administrator

Еще одна:

Посмотрим:

• 1 — Хм… Что ребята имеют в виду? =) Скорее всего они сами не знают что за этим скрывается
• 2 — Build Engineer
• 3 — Middle System Administrator
• 4 — Софт-скил, рассматривать пока не будем, хотя Agile еще одна вещь, которую интерпретируют так, как удобно.
• 5 — Слишком пространно — это может быть скриптовый язык, либо компилируемый. Интересно, а писал в школе на Pascal и Basic их устроит? =)

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

Однажды, я собеседовал парня, который использовал k8s в своей работе поверх OpenStack, и он рассказывал как развертывал сервисы на нем, однако, когда я спросил именно про OpenStack, оказалось, что он администрируется, равно как и подымается системными администраторами. Вы правда думаете, что человек поднявший OpenStack вне зависимости от того какую платформу он использует позади него не способен использовать k8s?=)
Данный соискатель на самом деле не DevOps, а такой же Системный Администратор и, чтобы быть точнее, Kubernetes Administrator.

Резюмируем в очередной раз — Middle/Senior System Administrator им будет достаточно.

С низов ИТ до DevOps-инженера

Вадим Князев, DevOps-инженер «Нетологии-групп»:

Вадим Князев говорит, что он начинал с самых низов ИТ-фирмы: сначала был оператором call-центра и помогал перезагружать роутеры. Образование у него непрофильное (инженер-физик), поэтому знаний в ИТ практически не было.

Работа разработчиком ему казалось скучной: «у тебя пара строчек кода, за которые ты отвечаешь, и все». А у системного инженера во власти целая интересная инфраструктура со своими особенностями, а также куча серверов, которые взаимодействуют друг с другом.

Работа разработчиком Владимиру Князеву казалась скучной

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

В «Нетологию-групп» он пришел уже на работающую инфраструктуру, нужно было только все поддерживать и развивать. Князев считает, что делать все с нуля гораздо проще, чем принимать то, что уже работает. Зачастую приходится изучать новые инструменты и подходы, которые были внедрены до тебя. Самой большой трудностью для него стал Kubernetes: «я много читал о нем, всегда хотел попробовать, но предыдущие проекты не позволяли его использовать. У меня был страх, что я не разберусь, но когда на собеседовании меня спросили «А не боишься, что не разберешься?», я ответил, что не боюсь. Пришлось разобраться».

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

Источник фото — «Нетология-групп»

Как компаниям выбрать специалиста на development и operations

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

Подбирать специалиста нужно не только по бэкграунду, но и soft-skills, и духу, чтобы человек мог легко влиться в уже существующую команду. Если взять очень крутого, прокаченного, но замкнутого человека-«колючку», он практически не принесет пользы. Более того, такие люди все равно потом уходят. Поэтому лучше потратить больше времени на поиск, чем потом долго адаптировать человека или искать нового после его быстрого ухода.

Роман Гершкович советует делать выбор человека исходя из общих целей компании на данный момент. На каждом этапе развития культуры DevOps оптимальное решение по уровню навыков сотрудников и их количеству в команде будет разным. Иногда лучше нанять одного senior-специалиста за большие деньги, чтобы он решил острые проблемы и повел команду за собой. А в какие-то моменты пара junior-инженеров на вырост будет очень кстати: сначала они принесут меньше пользы, но при правильном развитии будут очень перспективны для компании, смогут закрывать больше задач.

Тем, кто проводит интервью специалистов, лучше подготовить общую для всех interview book и прописать в ней разделы с базовыми вопросами по программированию на уровне автоматизации, операционным системам, сетям, архитектуре распределенных приложений. Также стоит иметь тестовую виртуалку с набором сломанных сервисов, которую человек должен починить, чтобы продемонстрировать свои практические навыки, считает представитель компании. Здесь не стоит создавать дополнительных трудностей — общих вещей по типу сломанных прав на файловой системе, chattr +i, забитого по выводу df диска из-за удаленных файлов будет достаточно.

Сколько зарабатывают DevOps

Средняя медианная зарплата по данным за второй квартал 2019 года у девопсов находится в вилке между 90 и 160 тысячами рублей. Есть предложения дешевле — в основном 60–70 тысяч. Постоянно есть предложения до 200 тысяч, встречаются вакансии с зарплатой до 330 тысяч рублей.

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

Отличным кандидатом на младшую вакансию с зарплатой в 60–90 тысяч станет начинающий системный администратор с опытом около года и профильным дипломом.

NiFi по красоте: HTTPS/LDAP/NiFi Registry/NiFi Cli + CI/CD

Tutorial

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

Есть мануалы о том, как настроить связку NiFi и NiFi Registry со включенной аутентификацией и авторизацией. Но… используются самоподписанные серты.

Есть отдельные мануалы, как прикрутить коммерческий серт для NiFi; соответственно для NiFi Registry «кагбэ так же». Но взаимная аутентификация и авторизация будет происходить с использованием Two way SSL… а у нас же LDAP… и обеспечить потом связность сладкой парочки с использованием только внешнего каталога у вас на голой интуиции не получится.

Есть мануалы по связке с LDAP и для NiFi, и для NiFi Registry. Нооо… как и в предыдущем «но», возникают вопросы, как обойтись потом только LDAP’ом, потому что у нас же еще NiFi Cli, а он в LDAP не умеет.

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

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

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

Если сказать чуть более абстрактно, без привязки к решаемым задачам, то DevOps-инженер должен владеть как минимум одним высокоуровневым языком программирования (Python, Java, Go, C++, C# или любым другим), понимать основы разработки и тестирования ПО. Понимать, как работают операционные системы Windows и Linux и их основные концепции: треды и процессы, разграничение доступа, сокеты, модель OSI, устройства ввода-вывода, память и устройства хранения данных; понимать, как работает виртуализация. Также потребуются навыки работы с терминалом ОС, умение писать batch- и bash-скрипты. Будет совсем не лишним знакомство с направлением infrastructure as code (инфраструктура как код): контейнеризацией (например, с помощью Docker и Docker Compose), написанием сценариев развертывания окружения (например, посредством Salt или Ansible), оркестрацией (Kubernetes), а также со всем, что касается мониторинга инфраструктуры (например, Zabbix, Grafana или Prometheus). Для продуктовой разработки также очень важны навыки работы с системами CI/CD, например TeamCity, Gitlab CI, Travis CI, Jenkins и Azure DevOps

Кроме того, важно умение работать с виртуальной инфраструктурой и облаками, например с vSphere, Azure, AWS или Google Cloud

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

Настройка CI/CD скриптов миграции БД с нуля с использованием GitLab и Liquibase

Tutorial

Добрый день, уважаемые читатели. Совсем недавно мне пришлось осваивать новую для себя область CI/CD, настраивая с нуля доставку скриптов миграции базы данных в одном из проектов. При этом было тяжело преодолеть самый первый этап «глаза боятся», когда задача вроде бы ясна, а с чего начать, не знаешь. Однако вопрос оказался на поверку значительно проще, чем казалось изначально, давая при этом неоспоримые преимущества ценой нескольких часов работы и не требуя никаких дополнительных средств, кроме обозначенных в заголовке.

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

Кто такой DevOps-инженер

DevOps-инженер соединяет:

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

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

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

Индустрии DevOps чуть более 10 лет. Активно о ней заговорили где-то в 2009 году. Сейчас профессия очень популярна во всем мире.

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

• People — люди, которые постоянно взаимодействуют друг с другом,
• Processes — процессы,
• Products — продукты и технологии, с которыми мы работаем. 

Антипаттерны деплоя в Kubernetes. Часть 1

Перевод

В предыдущей статье 10 Docker anti-patterns мы рассказали о популярных ошибках при создании образов контейнеров. Однако создание образов для вашего приложения — это только половина дела. Вам нужен способ развёртывания этих контейнеров в производственной среде. Использование кластеров Kubernetes для решения этой задачи уже стало стандартом.

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

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

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

CI/CD

Jenkins/TeamCity/TravisCI/Bamboo/CircleCI/Drone и, конечно же, GitlabCI — все эти CI/CD-инструменты подходят для выполнения своих задач: сборка и деплой софта. У всех есть свои плюсы и минусы, но так или иначе, каждый выбирает для себя идеальный инструмент, с которым он будет строить свой идеальный Pipeline. Существуют и более продвинутые системы, такие как Tekton, где можно манифестом описать весь CI/CD процесс через crd в Kubernetes. Однако хочется больше внимания уделить именно GitlabCI, как одному из хедлайнеров среди CI/CD-систем.

Нам очень нравится подход, когда весь процесс CI/CD лежит в Git-репозитории непосредственно рядом с кодом. Это позволяет не терять время на то, чтобы вникнуть в сам процесс сборки и деплоя, все находится под рукой.

Ясный и понятный Yaml, в котором описывается весь pipeline, прост в понимании того что происходит. Благодаря Yaml манифестам для Kubernetes, разработчики стали сами писать pipeline и helm чарты, прося проверить мердж реквесты на наличие ошибок. Это говорит о том, что с подобными системами легко и приятно работать. А когда работа в кайф — это круто!

Как написать проект для продакшена командой из одного человека (или небольшой командой)

Перевод

Соло-разработка проекта ПО — непростая задача. Никто не будет подталкивать тебя, проверять код и обеспечивать руководство, ты сам по себе путешествуешь в неизведанное.
Чаще всего неопытные разработчики попадают в одну из следующих ловушек:

1. Пользуются этим как возможностью наплевать на стандарты качества кода и не уделять внимания формату кодинга.
2. Делают совершенно противоположное и переусложняют всё намного сильнее необходимого.

Однако в этой статье я попытаюсь показать, что оба подхода одинаково вредны. Без лишних предисловий перейдём к сути.
Примечание: если вы ищете практические советы, то сразу переходите к разделу «Конкретные рекомендации».

С чего начать, чтобы стать DevOps engineer?

Начните с полезных статей:

• Эффективный DevOps: 6 способов прокачать команду и себя
• Как IT-специалисту ввести культуру DevOps в своей компании
• Кто такой DevOps и как им стать: план обучения

Посмотрите видео на канале ADV-IT, где подробно расписано, что учить и в каком порядке:

Получите более уверенные знания из нескольких книг:

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

DevOps — это не просто набор техник, это философия

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

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

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

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

Эберхард Вольф познакомит вас с популярными передовыми технологиями, облегчающими труд разработчиков: Docker, Chef, Vagrant, Jenkins, Graphite, ELK stack, JBehave и Gatling. Вы пройдёте через все этапы сборки, непрерывной интеграции, нагрузочного тестирования, развёртывания и контроля.

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

И помните, что от этого специалиста требуется тщательная проработка целого ряда вопросов.

Почему в «Нетологию-групп» стали искать человека на DevOps

Компания состоит из четырех проектов: онлайн-школы для детей «Фоксфорд», «Нетологии» для обучения взрослых специальностям из сферы диджитал, EdMarket, университета профессий в онлайн-образовании и школы изучения английского языка Wordika.

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

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

В офисе «Нетологии»

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

В компании поставили перед собой следующие цели:

• обеспечить стабильную работу и постоянную поддержку инфраструктуры;
• кратно увеличить скорость релизных циклов — с двух недель до нескольких раз в день.

Выделили приоритетные задачи:

• автоматизировать развертывание серверного окружения с нуля;
• настроить мониторинг нашей инфраструктуры и приложения;
• запустить централизованный сбор логов;
• выстроить качественные процессы по CI и CD.

Планы были амбициозные: многое из намеченного ранее не было реализовано, а проводить дебаг и отладку процессов при возникновении проблем было очень сложно из-за отсутствия истории и постоянного мониторинга.

Главные принципы DevOps

Рассматривая DevOps как масштабирование Agile-подхода на весь процесс разработки, внедрения и сопровождение ПО, можно выделить 5 основных принципов (CALMS) его реализации с целью увеличения частоты релизов и повышения ответственности команды за продукт :

• Культура (Culture) – кросс-функциональное сотрудничество разнопрофильных специалистов и команд за счет единого информационного пространства проектного контента, открытых каналов коммуникаций и постоянного общения всех участников;
• Автоматизация (Automatization) – использование инструментов непрерывной поставки с прогоном каждой правки кода через серию автоматизированных тестов, часто использующих облачную инфраструктуру, и последующую упаковку успешных сборок с дальнейшим перемещением на рабочий сервер с помощью автоматизированных развертываний и управления инфраструктурой как кодом через конфигурации саморазвертываемых сред;
• Бережливость (Lean) – устранение действий с низкой полезностью и ускорение процессов, непрерывное совершенствование через регулярный ретроспективный анализ, раздельное тестирование различных инструментов, принятие поражений, возможности быстрого обнаружения проблем и их незамедлительного решения;
• Измерения (Measurement) производительности, например, продолжительность работы пользователей с продуктом, частота появления в логах сообщений о критических ошибках – необходимы ясные и четкие критерии оценки работы, показатели эффективности процессов;
• Обмен (Sharing) – совместная ответственность и разделение успехов, выпуск и обеспечение работы приложения осуществляются теми же людьми, что выполняли его сборку, т.е. разработчики (Developers) и операторы (Operators) взаимодействуют на каждом этапе жизненного цикла приложения.

CALMS: главные принципы DevOps 

Как я сломал и починил кластер Kubernetes, работающий на Raspberry Pi

Перевод

В преддверии старта нашего курса по DevOps, делимся с вами продолжением статьи Как я собрал домашний кластер Kubernetes на базе Raspberry Pi.

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

Мой домашний кластерёнок вырос в зрелый кластер из шести нод (всё благодаря супруге, которая знала, что мне подарить на день рождения, — естественно, Raspberry Pi, и не один!), и я встал перед выбором — либо ещё раз выполнить собственные инструкции из статьи об установке кластера Kubernetes на Raspberry Pi, либо, применив системную инженерию (DevOps и SRE), полностью автоматизировать процессы переделки кластера и создания системы управления кластером.

Кто такие девопсы и что они делают

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

Вот что может делать девопс-инженер:

• настра­и­вать сер­ве­ры и авто­ма­ти­че­ски управ­лять их конфигурациями;
• созда­вать и настра­и­вать вир­ту­аль­ные кон­тей­не­ры для быст­ро­го запус­ка нуж­но­го соф­та. Чаще все­го для это­го исполь­зу­ют Docker;
• управ­лять эти­ми кон­тей­не­ра­ми из одно­го места и авто­ма­ти­зи­ро­вать всю их работу;
• настро­ить авто­ма­ти­че­ское тести­ро­ва­ние кода;
• сде­лать так, что­бы код после тестов авто­ма­ти­че­ски попа­дал в гото­вую сборку;
• соби­рать дан­ные для мони­то­рин­га рабо­ты всей систе­мы. Если какой-то сер­вис или про­цесс сло­ма­ет­ся, девопс сра­зу дол­жен это уви­деть и отреагировать.

Глав­ная зада­ча девопса — сде­лать так, что­бы авто­ма­ти­за­ции было как мож­но боль­ше и что­бы она дей­стви­тель­но уско­ря­ла разработку.

Terraform

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

Terraform — идеальный инструмент по управлению ресурсами в облаке. Через него можно полностью управлять: сетями, фаерволами, роутерами, ip-адресами, балансировщиками, жесткими дисками, виртуальными машинами и многим другим. Также есть возможность создания шаблонов, так называемых модулей. Через них можно упростить работу с ресурсами в облаке, достаточно просто указать название модуля и передать нужные переменные, все остальное Terraform сделает сам. Для совместной работы группы DevOps-инженеров есть возможность хранить стейтменты (состояние работы Terraform) в удаленном хранилище от hashicorp или любом S3 совместимом.

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