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

DevOps как методология

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

Перейдём к примеру применения DevOps. Например, возможность вносить изменения и направленность на прибыль и пользу. DevOps безусловно не на 100% заимствовал все подходы из Agile, но он взял лучшее, а некоторые моменты даже преобразил.

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

Вот в чем это выражается:

• Увеличивается скорость разработки. DevOps, за счёт сквозной автоматизации и интеграции процессов, позволяет сократить время, необходимое для запуска новых функций (фич) или исправления ошибок (багов) ПО, и сделать процесс разработки более гибким и быстрым.

• Улучшение сотрудничества и коммуникации. DevOps снимает барьеры между разработчиками, операционными командами и остальными участниками цикла разработки.

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

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

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

DevOps как сочетание культурных принципов

DevOps —  это ещё и культурное явление в разработке и сочетание культурных принципов, подходов и средств. В Agile есть: аналитики (бизнес и системные), разработка, тестирование, инженеры, которые отвечают непосредственно за поддержку продакшена. А в DevOPs появляются новые роли и ответвления.

Ответвления от DevOps:

• Методология SRE (site reliability engineering). Эта методология делает упор на мониторинг и на качество продукта и услуги сервиса предоставляемым клиентам компании.

• Клауд-инженеринг (cloud engineering). Он нацелен на работу с различными облачными решениями, как классическими облаками, так и multi-clouds и содержимого в них.

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

• ArchOps. Это направление фокусируется на архитектурных аспектах разработки, начиная от проработки дизайна архитектуры, заканчивая стоимостью оборудования под разрабатываемое ПО.

Про всевозможные тренды OPS можно более подробно узнать из доклада Дмитрия Сугробова - Dev.+Ops, или Строим идеальный процесс поставки.

Кажется, что это просто тренды. Все решили: «Давайте к любому слову добавим -Ops и все будет клево!». Но на самом деле это не так! Примером тому служит классический DevSecOps, когда у нас в цикл разработки добавляется безопасность с использованием подходов SAST/DAST. То есть фокус на безопасность разработки кода и поиск устранение уязвимостей, бэкдоров, а также сканирование работающего приложения, penetration-тестирование. На мой взгляд, при сочетании с DevOps DevSecOps — это вполне себе работающая методология. Она хорошо встроилась в цикл разработки. Казавшиеся странными методологии, вроде ChatOps или ArchOps, тоже работают, если понимать о чём это и как правильно внедрить под свои задачи.

DevOps как сочетание разработки и поддержки продуктов

Dev — development (разработка).

Ops — operation (эксплуатация).

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

• за продуктивный контур;

• за все контура и стэк CI/CD;

• за всё, что связано с CI/CD и тестовые контуры;

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

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

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

То есть благодаря данной методологии компании становятся более конкурентоспособными для выхода на рынок. Это касается и стартапов и крупных неповоротливых энтерпрайс-компаний.

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

DevOps и участники разработки

Рассмотрим пошагово, как проявляется DevOps на каждом из этапов разработки, на примере написания ПО с 0. Понятно, что тут всё крайне верхнеуровнево, но для понимания, этого будет достаточно.

Шаг 1: Планирование

Сначала на, основе требований бизнеса, бизнес-аналитиком пишутся бизнес-требования (БТ), потом архитектура приложения и, если она всех устраивает, то бизнес-требования перерабатываются системным-аналитиком в техническое задание(ТЗ). На этом шаге DevOps — это какие-либо тикетные системы планирования, проджект-системы.

Шаг 2: Кодинг (разработка)

Разработчики пишут код на основе ТЗ, результатом чего появляется некая первая версия приложения (ПО) в сыром виде. Здесь DevOps — это IDE разработчиков и репозиторий исходных кодов. Важно, на данном этапе так же важно покрытия кода функциональными и unit-тестами, а так же проверка кода на код-дизайн (code-style), и code-review (ревью кода).

Шаг 3: Компиляция

Скомпилированное (собранное) приложение собирается с прохождением проверок на код-дизайн, покрытие кода функциональными и unit-тестами. Если все проверки прошли успешно, то сборка приложения помещается в реестр скомпилированных приложений, или артифактов, например, Jfrog Artifactory.

Шаг 4: Тестирование

Чтобы сборку протестировать, её нужно задеплоить или развернуть на некий тестовый контур. Это может быть выделенная тестовая тестировщика, виртуальная машина (ВМ) или набор тестовых контуров. После чего происходит различного рода тестирования, которое всегда начинается с мануального, а далее - smoke, функциональное, UI, регресс, нагрузочное и т.д., в зависимости от зрелости методологии тестирования в Вашей компании.

Подробнее про тестирование можно ознакомиться в интервью с Ольгой Ермолаевой.

Шаг 5: Формирование релиза

Его могут собирать, как сами девопс-инженеры или лид-разработки, или ответственный разработчик, либо отдельно отведённые под это специалисты, которые отвечают за сам релиз. Ими могут быть - скрам-мастера, delivery-manager, release-manager и т.д.

Шаг 6: Деплой в продакшен

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

Шаг 7: Мониторинг

Мы, или коллеги из подразделения поддержки (operations) и/или мониторинга, наблюдаем за ранее развёрнутым релизом: насколько все прошло хорошо, нужна ли поддержка или дополнительный мониторинг.

Добавлю ещё про мониторинг. Он может быть на трёх уровнях:

1. Перформанс мониторинг (performance monitoring). Следим за железом, инфраструктурой - memory, cpu, swap, hdd, etc.

2. Апликейшн мониторинг (application monitoring). Наблюдаем за поведением работающего приложения и сервера со всеми его компонентами. Мониторим доступность ПО, что оно работает корректно (его функционал), БД ПО, если она есть.

3. Бизнес мониторинг (business monitoring). Отслеживаем практическую пользу для компании, которую несет приложение. Собираем метрики и логи приложения, наблюдаем за бизнес-функционалом ПО.

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

Какие есть подходы в рамках DevOps?

Continuous Integration (CI)

Непрерывная интеграция — это процесс работы с исходным кодом, сборка и тестирования покрытия кода функциональными и unit-тестами, проверка кода code-style и code-review. Результатом этого подхода будет артефакт (artefact) — скомпилированное приложение. Например, jar-файл или docker-image.

Automated testing (AT)

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

Continuous testing (CT)

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

Continuous Deployment (CD)

Суть этого подхода — сделать конвейер, который позволит каждое успешно пройденное изменение кода автоматически разворачивать в рабочую среду или производственную среду без вмешательства человека. Согласно классической модели разработки у нас должно быть минимум 3 контура: тест, предпрод и прод. В зависимости от проекта и наличия видов тестирования, добавляются другие варианты контуров. Continuous Deployment — это хорошая широко распространенная практика, но не во всех компаниях зрелость процессов до неё, к сожалению, доходят.

Automated Recovery (AR)

Это важный подход, про который зачастую забывают. Некоторые приложения не умеют автоматически откатываться на предыдущую версию. Даже если такой конвейер настроен из коробки с учетом CI/CD инструментов. Соответственно, некоторые приложения фиксят свои баги только путём доустановкой следующего релиза. Они не могут откатиться назад, могут идти только докатками. Automated Recovery — это подход, при котором можно восстанавливать любой контур, прежде всего, контур продакшна на предыдущую версию приложения со всеми вытекающими, как слой app, так и слой DB.

Release Management (RM)

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

IaС — инфраструктура как код

 

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

Performance Monitoring (PM)

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

Application monitoring (AM)

Это история про поведение приложения, в которую входят его метрики: connection treadpool, connection db pool, расходование именно самим приложением памяти, нагрузку на утилизацию ядер, попадание в SWAP, деградация свершения запросов в БД и т.д. Слой app затрагивает все компоненты приложения. Не забываем, что сюда входит не только классический app мониторинг, но и log-tracing.

Business Monitoring (BM)

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

Configuration managment (CM)

Это неотъемлемая часть CI/CD — управление конфигурациями, причём, не только контуров, но и самого ПО. Конфигурации должны быть обвешены автоматизацией и управляться через неё. Речь идет о конфигах серверов ПО, конфигах логирования и мониторинга, интеграционных, авторизации, кеш и так далее. Всем этим нужно уметь управлять через код, через систему управления и развертывания. Если у вас часто происходят изменения какой-то конфигурации, приходится каждый раз залезать туда ручками, или вообще эта конфигурация находится внутри скомпилированного приложения, и вам каждый раз для его изменения нужно пересобирать приложение, так делать не надо. Сразу отказываемся от этого, конфиг выносим за скобки приложения и управляем ими через репозиторий исходного кода и скрипты развертывания.

CI/CD

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

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

Continuous Delivery — это все то же самое с автоматизацией, но здесь добавляется поставка в продакшен. Но она делается мануально: по кнопочке, в определенное время, с простоем или без простоя.

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

В чём же основное отличие Continuous Delivery и Continuous Deployment спросите Вы? В той самой кнопочке deploy to production - она либо автоматом запускается, либо мануально. Это наглядно показано на схеме ниже.

Основные принципы CI/CD:

●       Распределение ответственности;

●       Минимизация рисков и человеческого фактора;

●       Быстрая обратная связь.

Технологии DevOps

Версионирование

История технологий, связанных с CI/CD начинается с контроля версий. В зависимости от того, что мы хотим версионировать, это могут быть разного рода системы:

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

• Версионирование артефактов. Для этого есть репозитории артефактов.

• Версионирование моделей данных (в случае с ML).

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

Традиционное развертывание — это когда у нас есть железка в серверной, есть на ней ОС, и на ней приложение. Чаще всего это называют on premise bare metal архитектурой.

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

Контейнеризация — это такой же hardware, такая же ОС, но вместо гипервизора — container runtime. Нет классической ОС, но есть контейнеры, которые запускаются на базе некого образа (image). Дальше уже идут необходимые бинарники с библиотеками для запуска и собственно само приложение.

Что необходимо для CI/CD

1. Система контроля версий кода: Git, Bamboo, GitabCI, Mercurial.

2. Инструмент CI/CD: GitlabCI, TeamCity, Jenkins, Bamboo, CircleCI.

3. Система управления артефактами: Sonatype Nexus, Jfrog Artifactory, Docker Registry.

4. Система управления конфигурацией: Ansible, Terraform, Chef, Pippet.

 

Я не отметил инструменты из российского реестра ПО, потому что они пока что ещё сейчас сырые, но уже активно пилотируются, развиваются.

А вот так выглядит топ инструментов логирования в 2023 году:

1. Datadog Log Collection & Management – EDITOR’S CHOICE

2. SolarWinds Security Event Manager (FREE TRIAL)

3. SolarWinds Papertrail (FREE PLAN)

4. Graylog (FREE PLAN)

5. Loggly (FREE TRIAL)

6. ManageEngine EventLog Analyzer (FREE TRIAL)

7. SematextLogs (FREE TRIAL)

8. FirstWaveopEvents (FREE TRIAL)

9. ManageEngine Log360 (FREE TRIAL)

10. Paessler PRTG Network Monitor

11. Splunk

12. Fluentd

13. Logstash

14. Kibana

15. XpoLog

16. Managelogs 

Подробнее можно ознакомиться тут.

Подробный список с описанием тут.

И вы спросите: «Это все нужно освоить?». Охватить всё просто нереально. Но имеет смысл потрогать как минимум 2 инструмента из каждого блока и выбрать то, что нужно вам.

Если говорить о лучшем, то есть такое мнение за 2023 год выделяют такой набор сэтов, как наиболее лучший:

Очень многие из этих инструментов — open source.

Процессы DevOps

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

Какие вопросы нужно задать

Шаг 1: Зачем?

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

Шаг 2: Какая выгода от внедрения?

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

Шаг 3: Какие команды затронет или зааффектит (в худшую сторону) данный процесс?

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

Шаг 4: Есть ли те, кто в явном виде будет против?

Потому что это те люди, которые будут на старте вставлять палки в колеса.

Шаг 5: Есть ли те, кто будут сразу согласны? Это будут союзники, те, кто вас поддерживают.

Например, мы хотим добавить некий процесс по внедрению новых технологий в компанию. Допустим, вы находитесь на роли девопс-инженера или просто инженера поддержки. Что может быть вам полезно?

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

Мы идем к тем, кто будет "за", ищем доверие, прорабатываем, что мы решаем, как мы решаем, в какие сроки. А дальше, в зависимости от того, как построено у вас в компании, вы защищаете эти идеи перед руководством.

Сопротивление возникнет неизбежно. Постепенно находим аргументацию, которая будет сопротивление убирать. Например, если изменение коснется поддержки и им придется расширять компетенции они могут сказать: «У нас мало ресурсов, мы не хотим расширять компетенции». Мы им тогда отвечаем: «Вы научитесь этому и этому, вы станете более высокооплачиваемым специалистами, которые знают больше инструментов. Мы проведем вам дополнительно обучение». Все эти аргументы должны быть, чтобы это сопротивление постепенно преодолеть.

Заключение

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