О DevOps говорят всё больше и больше, но это понятие настолько многогранное, что в нём легко запутаться. Спикер нашего курса DevOps Upgrade Александр Крылов раскладывает всё по полочкам: о принципах, подходах и технологиях, которые используют инженеры, чтобы повысить качество разработки и эксплуатации приложений.
DevOps как методология
DevOps — это методология взаимодействия всех участников цикла разработки и взаимная интеграция их рабочих процессов, которая помогает обеспечивать качество продукта. Она появилась на базе Agile — гибкой методологии разработки, где основной фокус на качество продукта и все, от чего это зависит. Например, возможность вносить изменения и направленность на прибыль и пользу. DevOps безусловно не на 100% заимствовал все подходы из Agile, но он взял лучшее, а некоторые моменты даже преобразил.
Методология DevOps предназначена для эффективной организации, создания и обновления программных продуктов и услуг.
Вот в чем это выражается:
Увеличивается скорость разработки. DevOps благодаря автоматизации и интеграции процессов позволяет сократить время, необходимое для запуска новых функций или исправления ошибок, и сделать процесс разработки более гибким и быстрым.
Улучшение сотрудничества и коммуникации. DevOps снимает барьеры между разработчиками и операционными командами.
Улучшение качества продукта. DevOps позволяет обнаруживать и исправлять ошибки раньше, снижает риски сбоев и инцидентов, связанных с человеческим фактором, повышает надежность системы в целом.
Сокращение затрат и оптимизация ресурсов. DevOps стремится к автоматизации и оптимизации процессов разработки и развертывания, что позволяет сократить издержки и использование ресурсов, таких как время и оборудование.
Подходы этой методологии при правильном построении процессов позволяют работать эффективнее. Но нужно помнить, что в каждой компании есть нюансы. Взять и внедрить DevOps в компании А, также как в компании Б, не получится. Нужно учитывать особенности, но при этом не пренебрегать чужим опытом.
DevOps как сочетание культурных принципов
DevOps — это ещё и культурное явление в разработке и сочетание культурных принципов, подходов и средств. В Agile есть: аналитики (бизнес и системные), разработка, тестирование, инженеры, которые отвечают непосредственно за поддержку продакшена. А в DevOPs появляются новые роли и ответвления.
Ответвления от DevOps:
Методология SRE. Эта методология делает упор на мониторинг и на качество продукта и услуги сервиса предоставляемым клиентам компании.
Клауд-инженеринг. Он нацелен на работу с облаками.
ChatOps. Это подход к управлению операционными задачами и коммуникации внутри команды или организации с использованием чат-платформы или инструментов мгновенного обмена сообщениями.
ArchOps. Это направление фокусируется на архитектурных аспектах разработки.
Кажется, что это просто тренды. Все решили: «Давайте к любому слову добавим -Ops и все будет клево!». Но на самом деле это не так. И примером тому служит классический DevSecOps, когда у нас в цикл разработки добавляется безопасность с использованием подходов SAST/DAST. То есть фокус на безопасность разработки кода и поиск устранение уязвимостей, бэкдоров, а также сканирование работающего приложения, penetration-тестирование. На мой взгляд, при сочетании с DevOps DevSecOps — это вполне себе работающая методология. Она хорошо встроилась в цикл разработки. Казавшиеся странными вещи вроде ChatOps и ArchOps тоже работают.
DevOps как сочетание разработки и поддержки продуктов
Dev — development (разработка)
Ops — operation (эксплуатация).
DevOps — это сочетание разработки и поддержки продуктов, но, в зависимости от процессов компании, это выглядит по-разному. Где-то в компании девопс-инженеры отвечают за продакшен, где-то за всё, что связано с CI/CD и тестовые контуры. А где-то девопс-инженеры отвечают исключительно за развитие продуктов, внедрение новых технологий и всего, что связано с CI/CD-конвейером. Поэтому все зависит от компании и от зрелости процессов.
Можно внести еще другой вариант термина. DevOps — это некое объединение людей, процессов и технологий, позволяющее постоянно предоставлять преимущества клиентам. DevOps позволяет представителям ранее разрозненных подразделений (разработки, IT-операций, обеспечения качества и безопасности) координировать свои действия и совместно создавать более качественные и надежные продукты.
То есть благодаря данной методологии компании становятся более конкурентоспособными для выхода на рынок. Это касается и стартапов и крупных неповоротливых энтерпрайс-компаний.
Также DevOps — это дополнительные инфраструктурные подразделения и администраторы конкретных направлений. Ими также могут быть product owner’ы, техруки, скрам-мастера.
DevOps и участники разработки
Рассмотрим пошагово, как проявляется DevOps на каждом из этапов разработки.
Шаг 1: Планирование.
Сначала пишутся бизнес требования, потом архитектура приложения и, если она всех устраивает, то бизнес-требования перерабатываются в техническое задание. На этом шаге DevOps — это какие-либо тикетные системы планирования, проджект-системы.
Шаг 2: Кодинг.
Разработчики пишут код и появляется некая первая версия приложения в сыром виде. Здесь DevOps — это IDE разработчиков и репозиторий исходных кодов.
Шаг 3: Компиляция и сборка.
Скомпилированное приложение хранится в реестре скомпилированных приложений, например Artifactory. Это тоже сфера DevOps.
Шаг 4: Тестирование.
Чтобы сборку протестировать, её нужно задеплоить или развернуть на некий тестовый контур. Это может быть выделенная тестовая машина тестировщика, виртуальная машина или набор тестовых контуров. И это DevOps.
Шаг 5: Формирование релиза.
Его могут собирать сами девопс-инженеры или лид-разработка или ответственный разработчик.
Шаг 6: Деплой в продакшен. Мы его деплоим в продакшен.
Шаг 7: Мониторинг. Мы наблюдаем за ним: насколько все прошло хорошо, нужна ли поддержка или дополнительный мониторинг.
Добавлю ещё про мониторинг. Он может быть на трёх уровнях:
Перформанс мониторинг. Следим за железом, инфраструктурой.
Апликейшн мониторинг. Здесь следим за поведением работающего приложения и сервера со всеми его компонентами.
Бизнес мониторинг. Отслеживаем практическую пользу для компании, которую несет приложение. Собираем метрики логи.
После этого начинается следующая итерация. И так будет долго, пока наше программное обеспечение не будет выведено из промышленной эксплуатации или заменено чем-то другим.
Какие есть подходы в рамках DevOps?
Continuous Integration
Непрерывная интеграция — это процесс работы с исходными кодами, то есть сборка и тестирования кода. Результатом этого подхода будет артефакт — скомпилированное приложение. Например, jar-файл или docker-image.
Automated testing
Когда приложение переваливает за десятки или сотни версий, мануально его тестировать становится уже невыгодно и слишком медленно. Тут нам на помощь приходят автотесты, которые встраивают в пайп-лайн. Важно добавить, что лучше всего в пайп-лайн встраивать тесты вместе с репортинговой системой, которая будет фиксировать все прогоны тестов, процент успешных и неуспешных, их потенциальную деградацию или, наоборот, что все хорошо от релиза к релизу.
Continuous Deployment
Суть этого подхода — сделать конвейер, который позволит каждое успешно пройденное изменение кода автоматически разворачивать в рабочую среду или производственную среду без вмешательства человека. Согласно классической модели разработки у нас должно быть минимум 3 контура: тест, предпрод и прод. В зависимости от проекта и наличия видов тестирования добавляются другие варианты контуров. Continuous Deployment — это хорошая широко распространенная практика.
Automated Recovery
Это важный подход про который зачастую забывают. Некоторые приложения не умеют автоматически откатываться на предыдущую версию. Даже если такой конвейер настроен из коробки с учетом CI/CD инструментов. Соответственно, некоторые приложения фиксят свои баги только доустановкой следущего релиза. Они не могут откатиться назад, могут идти только докатками. Automated Recovery — это подход, при котором можно восстанавливать любой контур, прежде всего, контур продакшна на предыдущую версию приложения со всеми вытекающими.
Release Management
Релиз менеджмент — управление релизным циклом всего приложения, а не каких-то отдельных элементов или сервисов. Основная задача релиз менеджмента — планировать релизы, сроки, релизный цикл. DevOps-инженер не всегда напрямую управляет в релиз-менеджменте, но в самом цикле он участвует.
IaС — инфраструктура как код
Подход заключается в том, что через репозиторий исходного кода можно полностью уметь управлять вашей инфраструктурой. То есть CD — это установка приложений на какой-то контур, а здесь мы и сам контур можем развернуть с нуля одной кнопкой. Начиная с виртуальной машины, заканчивая операционной системой и всеми настройками, зависимостями компонентов приложений, конфигурациями, переменными окружения. Это подход до которого далеко не все компании дорастают. Но в ситуациях, когда это реализовано — это очень классная вещь.
Performance Monitoring
Основная суть подхода в том, что у нас должен быть только тот мониторинг, который необходим на всех слоях. Если у нас какая нибудь виртуализация, нам нужно мониторить гипервизор, железо, мы должны мониторить конкретную виртуальную машину по CPU, memory и т.д. Это база, про которую не стоит забывать, особенно, если у вас идёт виртуализация или контейнеризация, обвешанная перформанс-метриками. Особенно в ситуациях, когда у нас большой хайлоад — это нужная вещь. Нужно не просто бездумно обвесить алёртами всё подряд, нужно сделать это только там, где это необходимо, и на тех ответственных, которые напрямую отвечают за этот кусок инфраструктуры. Не нужно делать рассылку на всех.
Application monitoring
Это история про метрики приложений: конекшн-предпулы, конекшн дибипулы, расходование именно самим приложением памяти, нагрузку на утилизации ядер, попадание в своп. Слой апликейшн затрагивает все компоненты приложения.
Business Monitoring
Это мониторинг фактического получения прибыли вашей компании, то есть бизнес-операций. Если мы покупаем какую-нибудь страховку, то это значит регистрация пользователя, калькуляция страховки, работа с регуляторами. Это важно, потому что на базе этого мониторинга вы можете прогнозировать и наблюдать за реальным количеством продаж за перспективу времени и за другие полезные аспекты, которые на эти продажи влияют с точки зрения пользовательского бизнес-функционала. Как пользователей внешних, если например у вас интернет-магазин, так и внутренних.
Configuration managment
Это неотъемлемая часть CI/CD — управление конфигурациями. Конфигурации должны быть обвешены автоматизацией и управляться через автоматизацию. Речь идет о конфигах серверов приложения, конфигах логирования, конфигах мониторинга, интеграционных, авторизации, кеш и так далее. Всем этим нужно уметь управлять через код, через систему управления и развертывания. Если у вас часто происходят изменения какой-то конфигурации, приходится каждый раз залезать туда ручками, или вообще эта конфигурация находится внутри скомпилированного приложения, и вам каждый раз для его изменения нужно пересобирать приложение, так делать не надо. Сразу отказываемся от этого, конфиг выносим за скобки приложения и управляем ими через репозиторий исходного кода и скрипты развертывания.
CI/CD
Это конвейер. Допустим у нас есть: код, коммиты, релизы, сборки, проверка кода тестами, интеграционные тесты, итоговое ревью, состав релиза, итоговое нагрузочное тестирование и развертывание на конечный продакшн. Прежде чем нагромождать его автоматизацией и безопасностью, нужно убедиться, что он успешно работает.
Continuous Integration — это история автоматизирования вокруг сборки, юнит-тестов и другие тестов, деплоймент на тестовые контуры, возможность прогона тестов и автоматические проверки.
Continuous Delivery — это все то же самое с автоматизацией, но здесь добавляется поставка в продакшен. Но она делается мануально: по кнопочке, в определенное время, с простоем или без простоя.
Continuous Deployment — это полностью автоматизированный цикл, когда автоматически происходит раскатка в продакшн. Причем она может быть по расписанию.
Основные принципы CI/CD:
Распределение ответственности;
Минимизация рисков;
Быстрая обратная связь.
Continuous testing
Этот подход заключается в том, что полный цикл тестирования автоматизирован. Когда у вас зрелое приложение, зрелые процессы в компании и присутствуют все необходимые виды тестирования и код хорошо покрыт тестами.
Технологии DevOps
Версионирование
История технологий, связанных с CI/CD начинается с контроля версий. В зависимости от того, что мы хотим версионировать, это могут быть разного рода системы:
Версионирование кода. По сути это репозиторий исходного кода. В зависимости от того, что используют в вашей компании, есть свои нюансы.
Версионирование артефактов. Для этого есть репозитории артефактов.
Версионирование моделей данных.
Виртуализация
Традиционное развертывание — это когда у нас есть железка в серверной, есть на ней ОС, и на ней приложение.
Виртуализация — это такая же железка, на которую накатана ОС, но у нее присутствует уже и гипервизор, который управляет сущностями виртуальных машин, на которые накатаны ОС. Есть набор бинарников и библиотек, которые необходимы для работы приложения и непосредственно приложение.
Контейнеризация — это такой же hardware, такая же ОС, но вместо гипервизора — container runtime. Нет классической ОС, но есть контейнеры, которые запускаются на базе некого образа (image). Дальше уже идут необходимые бинарники с библиотеками для запуска и собственно само приложение.
Что необходимо для CI/CD
1. Система контроля версий кода: Git, Mercurial.
2. Инструмент CI/CD: Gitlab CI, TeamCity, Jenkins, Bamboo.
3. Система управления артефактами: Nexus, Artifactory, Docker Registry.
4. Система управления конфигурацией: Ansible, Terraform.
Я не отметил инструменты из российского реестра ПО, потому что они пока что ещё сейчас сырые, но уже активно пилотируются, развиваются.
А вот так выглядит топ инструментов логирования в 2023 году:
Datadog Log Collection & Management – EDITOR’S CHOICE
SolarWinds Security Event Manager (FREE TRIAL)
SolarWinds Papertrail (FREE PLAN)
Graylog (FREE PLAN)
Loggly (FREE TRIAL)
ManageEngine EventLog Analyzer (FREE TRIAL)
Sematext Logs (FREE TRIAL)
FirstWave opEvents (FREE TRIAL)
ManageEngine Log360 (FREE TRIAL)
Paessler PRTG Network Monitor
Splunk
Fluentd
Logstash
Kibana
XpoLog
Managelogs
И вы спросите: «Это все нужно освоить?». Охватить всё просто нереально. Но имеет смысл потрогать как минимум 2 инструмента из каждого блока и выбрать то, что нужно вам.
Если говорить о лучшем, то есть такое мнение:
Очень многие из этих инструментов — open source.
Процессы DevOps
Держите лайфхак о внедрении новых процессов. Когда вы внедряете DevOps, обязательно будут изменения в процессах. Где-то небольшие, где-то большие, в том числе создание новых. Сейчас я вам дам некий рабочий подход, возможно, вам где-то придется его под себя его подработать, но этот подход уже опробован на большом количестве внедрений процессов, как в рамках одной компании, так и в рамках нескольких.
Какие вопросы нужно задать
Шаг 1: Зачем?
Прежде всего мы должны ответить на вопросы: зачем мы внедряем этот процесс и какую боль мы этим процессом решаем?
Шаг 2: Какая выгода от внедрения?
Причем выгода может делиться на несколько слоев: лично вам, подразделению, компании.
Шаг 3: Какие команды затронет или зааффектит (в худшую сторону) данный процесс?
Будьте готовы, что может быть сопротивление, дискуссии и нужно будет продавать идею.
Шаг 4: Есть ли те, кто в явном виде будет против?
Потому что это те люди, которые будут на старте вставлять палки в колеса.
Шаг 5: Есть ли те, кто будут сразу согласны? Это будут союзники, те, кто вас поддерживают.
Например, мы хотим добавить некий процесс по внедрению новых технологий в компанию. Допустим, вы находитесь на роли девопс-инженера или просто инженера поддержки. Что может быть вам полезно?
Мы идем к тем, кто будет "за", ищем доверие, прорабатываем, что мы решаем, как мы решаем, в какие сроки. А дальше, в зависимости от того, как построено у вас в компании, вы защищаете эти идеи перед руководством.
Сопротивление возникнет неизбежно. Постепенно находим аргументацию, которая будет сопротивление убирать. Например, если изменение коснется поддержки и им придется расширять компетенции они могут сказать: «У нас мало ресурсов, мы не хотим расширять компетенции». Мы им тогда отвечаем: «Вы научитесь этому и этому, вы станете более высокооплачиваемым специалистами, которые знают больше инструментов. Мы проведем вам дополнительно обучение». Все эти аргументы должны быть, чтобы это сопротивление постепенно преодолеть.
Заключение
Подумайте, нужен ли вам DevOps в компании, а главное — зачем. Просто так внедрение ради внедрения — это очень плохая история, так делать не надо. Если вам нужен DevOps, то выбирайте технологии исходя из компетенций и рынка. То есть выбирайте те технологии, которые актуальны в данный момент времени и подходят под ваши нужды. Не бойтесь использовать существующие подходы и переделывать их под себя.
Интересные статьи
Интересные статьи
