С чего начать изучение devops

Как обучиться на DevOps-инженера

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

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

Кто такой DevOps-инженер и чем он занимается

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

• подготавливает инфраструктуру для разработки и тестирования, устанавливает нужное ПО на серверы и настраивает его;
• создает и поддерживает CI/CD — процессы автоматического тестирования и развёртывания кода;
• настраивает мониторинг, чтобы собирать все нужные метрики по работе систем.

Мы составили план обучения DevOps-инженера, следуя которому вы сможете освоить методологию Development Operations с нуля.

С чего начать изучение DevOps

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

Компьютерные сети

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

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

Операционные системы

Linux — важная составляющая DevOps обучения, так как чаще всего такие специалисты работают с Linux или другими *nix-системами, но иногда может встретиться и Windows Server. Поэтому нужно научиться работать в разных ОС, понимать их отличия и особенности, а также знать принципы работы операционных систем: что такое ядро ОС, как система работает с памятью и выделяет ее процессам, как устроены файловые системы и так далее.

Эти знания помогут понять архитектуру систем и инструментов, которые предстоит изучить дальше. Также это поможет в решении проблем, которые так или иначе будут возникать: служба не запускается, сервис выдает ошибку и т. п.

Еще нужно уметь работать в консоли (особенно это касается *nix-систем) и знать основные команды и утилиты. Для *nix-систем предстоит работать с командной оболочкой Bash, а для Windows — с PowerShell.

Python

Python — один из основных языков программирования, которым пользуются девопсы. Это простой и удобный язык с низким порогом вхождения для написания скриптов автоматизации. Намного реже для этого используют Ruby или Go.

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

Виртуализация

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

Изучение DevOps: продвинутый уровень

Теперь разберём те инструменты девопса, с помощью которых вы и будете решать поставленные перед вами задачи.

Системы управления конфигурацией

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

CI/CD-процессы

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

Для этого используются готовые инструменты вроде Jenkins или Gitlab CI. А DevOps-специалист должен знать все стадии разработки ПО, понимать, какие системы в этом участвуют, и как все это автоматизировать.

Облачные технологии

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

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

Микросервисная архитектура и контейнеризация

Другой популярный тренд — микросервисная архитектура и контейнеры. Многие компании разрабатывают свое ПО так, что оно оборачивается и работает в Docker-контейнерах. Если контейнеров становится слишком много, появляется оркестратор вроде Kubernetes, который помогает автоматизировать управление ими.

И если разработчик еще может написать Docker-файл и обернуть свое приложение в контейнер, то вот развертыванием контейнеров и управлением Kubernetes будет заниматься DevOps-инженер.

Мониторинг

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

Для этого используются готовые инструменты вроде Prometheus и Grafana. Вы должны уметь устанавливать и настраивать их, а также понимать, какие именно метрики нужно собирать и на что обращать внимание.

DevOps-инженер — эффективное обучение с нуля

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

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

Следите за новыми постами по любимым темам

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

Как стать DevOps инженером за полгода или даже быстрее. Часть 1. Введение

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

Что это вообще такое?

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

Хорошо, но что же все-таки означает это сокращение? Оно означает, что традиционно разработчики Developers (люди, создающие программное обеспечение) в своей работе руководствовались стимулами, которые значительно отличались от стимулов Operations (операционистов, или людей, которые управляют программным обеспечением). Например, как разработчик, я хочу как можно быстрее создать как можно больше новых функций. В конце концов, это моя работа, и именно этого требуют клиенты! Однако, если я человек Ops, то мне нужно как можно меньше новых функций, потому что каждая новая функция — это изменение, а любое изменение чревато неполадками. В результате такого рассогласования стимулов и родился DevOps.

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

Пуристы скажут вам, что нет такой вещи, как ”инженер DevOps». «DevOps — это культура, а не роль”, — скажут они вам. Конечно, с технической точки зрения они правы, но, как это часто бывает, этот термин вышел за пределы своего первоначального значения. Так вот, инженер DevOps – это что-то вроде “системного инженера 2.0». Другими словами, это тот, кто понимает жизненный цикл разработки программного обеспечения и создает инструменты и процессы разработки программного обеспечения для решения классических операционных задач.

DevOps в конечном счете означает создание цифровых конвейеров, которые берут код с ноутбука разработчика и превращают его в доход от использования конечного продукта, вот в чем все дело. Обратите внимание на то, что выбор карьеры DevOps достаточно высоко компенсируется финансовым вознаграждением, причем почти каждая компания либо “делает DevOps”, либо претендует на это. Независимо от того, где находятся эти компании, общие возможности трудоустройства в качестве DevOps довольно высоки и подразумевают «веселую» и значимую занятость на долгие годы вперед.

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

Отказ от ответственности

А теперь давайте на минутку отставим в сторону стакан «Кул-Эйда» и подумаем о следующем. Вы слышали старую пословицу «младших инженеров DevOps не бывает?”. Если нет, то знайте, что это популярный троп на Reddit и StackOverflow. Но что он значит?

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

Опять же, инструменты отличаются от навыков, поэтому, пока вы изучаете инструменты, убедитесь, что вы не пренебрегаете своими навыками (опросы, создание сетей, письменное общение, устранение неполадок и т. д.). Главное, не упускайте из виду то, что мы хотим найти – способ создания полностью автоматизированного цифрового конвейера, который берет идеи и превращает их в приносящие доход фрагменты кода. Это единственный и самый важный вывод из всей этой статьи!

Хватит болтовни, когда я смогу начать?

Ниже приведена дорожная карта «Фундаментальные знания DevOps». Освоив все, что там изображено, можете смело и честно называть себя инженером DevOps! Или облачным инженером, если вам не нравится название “DevOps”.

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

Вы должны пройти этот путь постепенно, слой за слоем. Начать (и продолжать!) следует с фундаментальных основ, изучив сначала элементы, обозначенные синим цветом — Linux, Python и AWS. Затем, если позволит время или спрос на рынке труда, займитесь фиолетовыми вещами — Golang и Google Cloud.

Честно говоря, основополагающий верхний слой — это то, что вам придется изучать бесконечно. OS Linux очень сложна, и на ее освоение уходят годы. Python требует постоянной практики, чтобы оставаться в курсе событий. AWS развивается так быстро, что то, что вы знаете сегодня, через год составит лишь часть общего портфеля знаний. Как только изучите основы, переходите к реальному набору навыков. Обратите внимание, что всего существует 6 синих колонок (Конфигурирование, Версия, Пакетирование, Развертывание, Запуск, Мониторинг), по одной на месяц изучения.

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

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

Ладно, давайте копнем немного глубже!

Фундаментальные знания

Под верхней ступенькой с надписью Foundation вы видите навыки, которыми должен овладеть каждый инженер DevOps. Эти навыки – уверенное обращение с тремя «столпами» отрасли, коими являются: операционная система, язык программирования и публичное облако. Эти вещи не являются тем, с чем можно по-быстрому ознакомиться и пойти дальше. Эти навыки нужно постоянно совершенствовать и оттачивать мастерство обращения с ними, чтобы находится в авангарде отрасли и актуализировать окружающую вас профессиональную среду. Давайте пройдемся по ним по очереди.

Linux это то, где все работает. Можете ли вы быть потрясающим практиком DevOps, полностью оставаясь в рамках экосистемы Microsoft? Конечно, можете! Нет такого закона, который предписывал бы использовать только Linux. Однако учтите – не смотря на то, что все вещи Linux можно проделать и в Windows, там это происходит гораздо болезненней и с меньшими функциональными возможностями. На данный момент можно смело предположить, что без знания Linux невозможно стать настоящим профессионалом DevOps, поэтому Linux это то, что вы должны изучать и изучать.

Честно говоря, лучший способ сделать это — просто установить Linux (Fedora или Ubuntu) дома и пользоваться им как можно больше. Конечно, вы переломаете кучу вещей, будете застревать в рабочих процессах, вам придется все исправлять, зато вы узнаете Linux!

Кстати, в Северной Америке более распространены варианты RedHat, поэтому имеет смысл начать с Fedora или CentOS. Если вы задаетесь вопросом, следует ли вам приобрести KDE или Gnome edition, выберите KDE. Это то, чем пользуется сам Линус Торвальдс.

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

Amazon Web Services: опять же, невозможно стать опытным профессионалом DevOps без твердого понимания того, как работает публичное облако. И если вы хотите узнать об этом как можно больше, изучите Amazon Web Services. Это ведущий игрок в данной области услуг, который предлагает самый богатый набор рабочих инструментов.

Можно ли вместо этого начать с Google Cloud или Azure? Конечно, можно! Но помня последний финансовый кризис, следует учесть, что AWS — это самый безопасный вариант, по крайней мере, в 2018 году, так как позволяет бесплатно зарегистрировать аккаунт и приступить к изучению возможностей облачных сервисов. Кроме того, AWS console предоставляет пользователю простое и понятное меню для выбора. Хорошая новость заключается в том, что для этого вам не нужно знать все технологии Amazon.

Начните со следующего: VPC, EC2, IAM, S3, CloudWatch, ELB (Elastic Load Balancing под прикрытием EC2) и Security Group. Этих вещей достаточно, чтобы начать работу, и каждое современное, облачное предприятие достаточно активно использует эти инструменты. Собственный учебный сайт AWS — хорошее место для начала работы.

Я рекомендую вам ежедневно уделять 20-30 минут изучению и практике с языком Python, операционной системой Linux и облачным сервисом AWS в дополнение к другим вещам, которые вам придется изучить. В целом, я считаю, что тратить по часу в день пять раз в неделю достаточно, чтобы понять происходящие в отрасли DevOps процессы в течение 6 месяцев или даже меньше. Существует в общей сложности 6 основных составляющих, каждая из которых соответствует месяцу обучения. Это все, что вам понадобится для приобретения базовых знаний.
В последующих статьях мы рассмотрим следующий уровень сложности: как полностью автоматизировать настройку, версию, пакетирование, развертывание, запуск и мониторинг программного обеспечения.

Немного рекламы 🙂

Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?

• Блог компании ua-hosting.company
• Программирование
• IT-инфраструктура
• Карьера в IT-индустрии
• DevOps

С чего начать DevOps?

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

Философия

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

В своей практике мы встречаем несколько различных определений DevOps. Достаточно распространённым является то, в котором DevOps представляет собой использование специальных инструментов для построения CI/CD для деплоя новых версий приложения.

Основная проблема такого понимания в том, что оно не даёт ответа на вопрос для чего и как это делается. В действительности попытки применить в проекте DevOps именно в такой трактовке приводят к серьёзным проблемам. Мы не раз сталкивались с этим, когда только начинали предлагать нашим клиентам DevOps как услугу.

Например, если в проект с таким замечательным набором ПО для деплоя как FileZilla и бэкапами в качестве системы контроля версий добавить DevOps в обозначенной выше формулировке, и при этом не донести до разработчиков философскую составляющую, то это с высокой вероятностью приведёт к тому, что они продолжат править код прямо на production-сервере, особенно в случае обнаружения критических ошибок. Бывало и такое, что для этих целей нас даже просили поставить SSH-сервер в Docker-контейнеры.

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

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

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

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

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

Давайте посмотрим из чего она состоит:

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

Что касается теории, то кроме первого базового элемента, а именно понимания тех самых принципов DevOps, приведённых выше, имеются и другие. Следующим из которых является коллективное владение продуктом (shared ownership):

Говоря другими словами — совместное владение различного рода информацией и знаниями о разрабатываемом продукте. Это важнейшая составляющая культуры DevOps, т.к. является тем самым “склеивающим раствором” между разработкой и эксплуатацией, поскольку первые начинают думать не только над тем, как будет выглядеть тот или иной функционал для конечного пользователя, но и, понимая как всё это будет работать, выбирать более правильные методы реализации, учитывая особенности работы системного ПО. Ops’ы, обладая соответствующей информацией, со своей стороны тоже смогут выбирать и предлагать более качественные, оптимальные и удобные решения с точки зрения разработки проекта. Это касается всего, что позволило бы максимально учесть все нюансы будущего приложения, от проектирования инфраструктуры и до выбора конкретных программных элементов, таких как, например, БД.

Такое вовлечение в общий процесс различных участников проекта позволяет каждому из них рассматривать проблему с разных точек зрения и наладить максимально тесное взаимодействие:

Это повысит командный дух и решение даже самых сложных задач станет интересным и увлекательным занятием.

Ещё одной значимой составляющей в философии DevOps является культура, направленная на совершенствование имеющихся процессов:

Не надо бояться экспериментировать и пробовать новые методологии и практики. Единственное, эти эксперименты должны быть контролируемыми, а все изменения хорошо прорабатываться перед внедрением. Данный момент ещё будет затронут далее в статье.

Процессы

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

MVP

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

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

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

Continuous Integration

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

но помните, что так или иначе вы столкнётесь с необходимостью интеграции в единое целое не только отдельных частей проекта, таких как новые фичи, исправление багов и прочее, но и других процессов.

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

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

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

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

При выстраивании CI нужно учесть:

• В системе контроля версий помимо кода приложения должно располагаться всё необходимое для его сборки и самотестирования
• Автоматизация сборки
• Автоматизация тестирования
• Разработка всех новых фич только в отдельных ветках
• Каждый пуш во временные ветки должен сопровождаться сборкой приложения
• Ежедневные пуши в центральный репозиторий всеми участниками проекта
• Наличие stage-ветки

Continuous Testing

После того как ваш код написан и до того, как будет доставлен в production — он должен быть тщательно протестирован. Казалось бы, это очевидно, но на деле об этом заботятся далеко не все. Часто ограничиваются проведением только unit-тестов, а некоторые вообще тестируют на конечных пользователях в продуктовой среде и сейчас я имею в виду не A/B тестирование))

Помимо Dev и Ops одной из составляющих DevOps, правда, не такой явной, является QA. И обеспечение качества тоже должно быть частью общего Continuous!

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

В прошлом году на IT-Nights я выступал с докладом, где рассказывал про микросервисную архитектуру. В нём я приводил схему, которую мы придумали и внедрили в рамках реализации одного из проектов:

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

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

Continuous Deployment

Теперь, когда всё интегрировано и протестировано, найдены и устранены все основные дефекты (ну или почти все . ), пришла пора переходить к доставке кода.

Что хотелось бы получить от этого процесса:

• Автоматическое обновление ПО
• Предоставление нового функционала постепенно
• Быстрое получение отклика от клиентов
• Быстрое реагирование на изменения рынка и бизнеса
• Снижение количества ошибок в production
• Упрощение работы Dev’ам и Ops’ам

Т.е. и к этому процессу предъявляются требования автоматизации и непрерывности. Так мы получаем Continuous Deployment.

Непосредственная реализация деплоя зависит от среды назначения и не обязательно должна производиться в Kubernetes. Помимо того, это может быть и одиноко стоящий bare-metal server, и кластер на железе, и даже пакетный репозиторий. И, очевидно, что выбор инструментария для решения этой задачи будет зависеть от того, куда именно потребуется делать деплой.

Если говорить именно о разработке и доставке сервиса, то придётся познакомиться с такими понятиями как stateless и stateful, а также столкнуться со множеством проблем, основными из которых будут:

• Простои при деплое
  Естественно, всем хотелось бы выкатывать новые версии своих приложений так, чтобы при этом пользователи не наблюдали перебоев в их работе. Но, порой, это весьма дорогостоящий процесс, обеспечение которого может занять неоправданно много сил и времени.
• Откат версии приложения
  А когда приходится иметь дело с БД и миграциями, всё становится совсем печально.

Вообще тема Zero downtime и откат версии приложения в совокупности с БД — это действительно непростой процесс, который всегда надо чётко контролировать. В рамках данной публикации всё это рассказать будет не реально, но у нас по этой теме есть несколько статей на Habr’e (вот и вот), а также в прошлом году я делал доклад на Стачку “Rest API сервер от кода до деплоя”, там освещаются основные аспекты и те моменты, на которые стоит обратить внимание при построении деплоя с нулевым простоем совместно с прямыми и обратными миграциями БД. На эту тему я так же планирую позже написать статью.

И, кстати, Continuous Deployment тоже должен быть обёрнут в тесты. Т.е. проверка качества должна происходить не только перед доставкой кода, но и даже после этого. Разумеется, это будут разные типы тестирования.

Continuous Infrastructure

Теперь давайте поговорим о том, где будет работать всё то, что мы закодим и задеплоим — об инфраструктуре. Так же как и для остальных процессов в общей методологии DevOps, для инфраструктуры тоже есть свой Continuous — Continuous Infrastructure.

Одним из ключевых составляющих которой является Infrastructure as Code. Т.е. это описание инфраструктуры, необходимой для работы проекта в виде кода. Который, как и код самого приложения хранится в репозитории и версионируется. Для него точно также должны быть определены механизмы ветвления, версионирования, сборки и тестирования (например, с помощью Molecule, если речь идёт об Ansible). Т.е. процесс по своему виду очень напоминает Continuous Integration.

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

IaC может быть построена вокруг очень разных технологий, от обычных bash-скриптов, описывающих процесс настройки, до систем управления конфигурациями и описания инфраструктуры, такими как Ansible, Terraform и прочими.

Если вы сомневаетесь относительно необходимости наличия данного процесса в общем стеке, будучи уверенным в том, что “да я и вручную очень быстро web-сервера настраиваю”, то помните про Disaster Recovery и попробуйте ответить себе на два вопроса:

• Сколько времени займёт восстановление инфраструктуры после её полного краха? Например, метеорит упал на ДЦ и срочно потребовалось переподнять всё в другом месте.
• Как этот простой повлияет на бизнес?

Continuous Monitoring

И завершающим процессом во всей этой цепочке является Continuous Monitoring. Основным назначением которого является поддержание в актуальном состоянии конфигурации мониторинга различных элементов проекта, от инфраструктуры и до приложений, входящих в его состав. Причём отслеживание и мониторинг всех необходимых метрик должен производиться автоматически. Для этого придётся постараться всем, в том числе и программистам, которые часто просто не понимают необходимость реализации в коде механизмов, позволяющих получить метрики конкретного сервиса и им достаточно простого принципа “процесс запущен, значит всё хорошо”.

Оптимизация процессов

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

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

С какими проблемами можно столкнуться:

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

И это действительно очень хороший философский вопрос, на который не существует однозначного ответа. Но, как правило, истина где-то посередине или почти посередине.

Инструменты

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

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

DevOps-минимум

Понятно, что реализация всех описанных процессов в рамках даже небольшого проекта может быть делом весьма продолжительным и сложным. Поэтому многие команды задаются логичным вопросом: “С чего начать DevOps? Какой минимум необходим? И какие элементы нужны в первую очередь?”.

Реализовав множество проектов различной сложности по внедрению DevOps, на основе полученного опыта наша команда может ответить на этот вопрос так:

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

Что касается процессов, то тут уже не всё из обозначенного выше имеет критическое значение на начальных этапах появления DevOps. Здесь нам никак не обойтись без двух “continuous”: Integration и Deployment. В первую очередь потому, что без этого DevOps так останется просто теорией и не будет иметь никакого практического смысла.

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

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

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

Заключение

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

Также читайте другие статьи в нашем блоге:

• Canary Deployment в Kubernetes #1: Gitlab CI
• Аутентификация и чтение секретов в HashiCorp’s Vault через GitLab CI
• Fluentd: почему важно настроить выходной буфер
• С чем нам пришлось столкнуться при использовании утилиты Csync2
• Создание дополнительного kube-scheduler’a с кастомным набором правил планирования

Первые шаги в DevOps: с чего начать знакомство

Всем привет! Меня зовут Дима, я «наовертаймил» уже 14 лет опыта в IT, 8 из которых — проповедуя непосредственно DevOps и занимаясь в основном проектами, так или иначе завязанными на активном использовании методологии и «тулсэта».

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

DevOps — профессия или часть обязанностей?

Итак, кто такой DevOps-инженер или кто может им стать? Могу точно сказать, что не существует общего профиля DevOps-специалиста. Каждый отдельный профессионал отличается с точки зрения технической экспертизы и опыта построения специфических систем. Конечно, есть определенный спектр навыков и знаний, общий для всех: DevOps-инженер должен нести, как знамя, и передавать в массы Software Development Life Cycle (SDLC), а еще — отлично ориентироваться в процедурах внедрения изменений в компании (это то, что широкие массы называют инновациями).

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

Условную техническую базу вполне спокойно наши студенты подтягивают в академии за несколько месяцев, но сама по себе она не имеет смысла без понимания, ЗАЧЕМ это всё великолепие нужно бизнесу.

Вторым важным требованием к DevOps-инженеру являются хорошо развитые soft skills. Ты должен уметь взаимодействовать с командой, понимать мотивацию и проблемы каждого из сотрудников, уметь доносить и «продавать» свою идею так, чтобы зажечь свою команду на внедрение изменений (aka innovations). В придачу ко всему этому ты должен уметь планировать, расставлять приоритеты и активно подключаться к процессу реализации. Неприемлема ситуация, когда DevOps «научил как надо» и ушел дальше думать, кого и чему бы еще научить. Святая обязанность DevOps-специалиста — возглавить движение к светлому будущему независимо от уровня должности. Чтобы действительно приносить плоды, культура должна жить на всех уровнях команды и организации.

Итак, вы дочитали до этого места, и вам кажется, что пробил час, пора двигаться именно в этом дивном (пару лет назад даже хайповом) направлении. Что же делать?

Для начала вы должны стать как минимум специалистом в одной из IT-сфер middle-уровня с хорошей технической базой, soft skills и сильным желанием мыслить стратегически. Затем неплохо было бы подумать, есть ли у вас желание развивать в себе «менеджерский функционал» и при этом не отказываться от сильной технической части. Подумали? Оценили свой текущий уровень? Если уверены в своих силах, давайте читать дальше 🙂

Кстати, если вы еще новичок в IT, трезво оцените свои силы, рано вам еще в DevOps. Рановато вам учить других и помогать проектам двигаться в светлое будущее за счет своего опыта. Но почитать и понять для себя, о чём эта методология, смысл есть.

«Сначала была теория»

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

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

Очень мало смысла перечислять книги и ресурсы, которые рекомендуются новичкам. Это всегда индивидуально и зависит от уже приобретенного опыта. Очень опытные ребята обычно предлагают следующие must have:

• Phoenix Project — прочтением этой книги принято хвастаться и обсуждать её содержимое в celebrity-кругах DevOps;
• DevOps handbook — практические советы и опыт;
• Site Reliability Engineering — а вот тут вы сможете понять, что «мы в ответе за то, что создали», да и вообще, посмотреть, как работать не за еду или идею;
• Continuous Delivery — несмотря на то, что книга написана в 2008 году, ее актуальность для многих команд и компаний остается очень высокой;
• Release it! — отличное и легкое чтиво о том, как правильно или неправильно подходить к релизу программного обеспечения;
• Lean Software Development — качественные рекомендации по поводу оптимизации процессов и культуры waste-анализа в целом, для того чтобы избежать груды ненужной работы, которая рушит святое — магию девелопмента;
• множество других книг, которые можно найти тут.

Мир меняется

В современном мире новые подходы постоянно абсорбируются и добавляются в список обязательных требований в выполнении обычной ежедневной работы. Ведь когда-то Agile/Scrum были модными фишками, и были весьма распространены отдельные роли «мастеров» ведения этих практик в командах. Теперь же вся ответственность лежит на плечах разработчиков, просто добавилось дополнительное требование. Это нормальная ситуация — инфляция навыков и умений. Чтобы не стоять на месте, нужно очень быстро бежать за технологиями и методологиями.

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

Инициатива не наказуема

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

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

Научитесь учиться

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

• Например, Олег ведет замечательные дайджесты по DevOps;
• telegram-канал devopsengineer;
• Medium, например;
• Reddit;
• Slack — ukrops.club;
• Skype DevOps UA (пригласить может другой участник чата, можно писать напрямую nonflet с просьбой добавить) — здесь еще ни один вопрос не остался без ответа. Так что, если нужен совет или просто хотите пообщаться, обязательно загляните сюда;
• конференции, например FWdays Highload, DevOps Stage, XP Days.

Вывод

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

К чему я это? А к тому, что мы должны постоянно расширять спектр доступных нам знаний и умений. Именно это увеличит число опций для принятия нами решений. К примеру, вас заставляют работать в стесненных условиях унылого проекта, а вы взяли и ушли в другую компанию DevOps’ом. Конечно же, это шутка 🙂 В идеале нужно нести свет и учение в массы, ведь все мы живем в тех условиях, которые сами себе и создали (или мы просто just fine with it).

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

�� Подобається Сподобалось 1

До обраного В обраному 2