DevOps

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

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

Название произошло от двух сокращений: Dev — development (разработка) и Ops — operations (поддержка). Раньше это были две разные сферы. Идея DevOps в том, чтобы приблизить эти сферы друг к другу и наладить между ними эффективную коммуникацию.

Для чего нужен DevOps-подход

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

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

Чем занимается DevOps-инженер

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

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

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

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

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

Практики и инструменты методологии DevOps

Чтобы понимать, что такое DevOps, нужно иметь представление о его конкретных практиках. Основных всего пять:

• непрерывная интеграция, поставка и развертывание, или CI/CD;
• непрерывное тестирование;
• непрерывный мониторинг;
• микросервисы;
• инфраструктура как код, или IaC.

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

CI/CD

Иногда ее разделяют на два пункта — непрерывная интеграция (CI) и непрерывные поставка и развертывание (CD).

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

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

Непрерывное тестирование

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

Только после прохождения юнит-тестов продукт уйдет на функциональное тестирование — «со взгляда пользователя». Его уже могут проводить люди, а не скрипты.

Непрерывный мониторинг

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

Микросервисы

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

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

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

Инфраструктура как код

Подход сокращенно называют IaC — Infrastructure as Code. Чтобы реализовать идеи выше, нужно множество инфраструктурных решений: использование контейнеров, виртуальных систем, оркестраторов и так далее. Суть IaC в том, что управлять всей этой инфраструктурой лучше программно, с помощью кода, а не вручную. Так настройки и контроль проводятся быстрее, точнее и лишены человеческого фактора. Для IaC тоже существуют специальные решения. На практике это выглядит так: вместо того чтобы вручную настраивать среду, DevOps-инженер создает конфигурационные файлы, которые в нужный момент запускаются из консоли — достаточно пары строчек с командами. Среда и окружение настраиваются автоматически согласно этим файлам.

Технологии для DevOps

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

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

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

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

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

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

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

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

Облачные серверы. Для реализации CI/CD также используются другие решения, не настолько специализированные. Например, DevOps-инженеры часто работают с облачными провайдерами серверов, такими как Azure или AWS. Эти компании предоставляют виртуальные серверы, работу с которыми легче автоматизировать. А это опять же важно для непрерывного развертывания и доставки.

Системы конфигурации. Для управления инфраструктурой используются специальные программные решения. Таких систем довольно много: Ansible, Chef, Puppet и другие. Еще есть Vagrant — она нужна для создания и конфигурирования виртуальных систем. Эти программы помогают создавать скрипты для конфигураций и запускать их на всех серверах — так автоматизируются рутинные однотипные действия. Это пример того, как реализуют принцип IaC.

Системы мониторинга. Наконец, для непрерывного отслеживания тоже нужны специальные решения. Обычно это комплексные системы, которые автоматизируют процесс мониторинга. Они автоматически запускают проверки состояния серверов, собирают нужную информацию, генерируют отчеты и отправляют специалистам. Примеры таких систем — Prometheus, Zabbix или Nagios, а также Icinga, созданная на его основе. Еще есть Cactu для построения графиков и Grafana — инструмент для визуализации результатов мониторинга в виде интерактивного дашборда.

Что еще нужно знать DevOps-инженеру

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

Языки программирования. Считается, что хороший DevOps-инженер должен знать хотя бы один язык программирования. Лучше, чтобы это был язык общего назначения, причем такой, который удобно использовать для автоматизации: Python, Golang и так далее. Возможны и другие варианты.

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

Операционные системы и сети. Чтобы успешно работать с Bash, писать скрипты и настраивать окружение, нужно понимать, как работают эти системы. Поэтому девопсам нужно знать Linux и разбираться в устройстве сетей.

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

Как начать работать с DevOps

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