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, нужно иметь представление о его конкретных практиках. Основных всего пять:

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

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

CI/CD

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

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

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

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

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

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

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

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

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

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

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

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

Инфраструктура как код (IaC)

Подход сокращенно называют 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, созданная на его основе. Еще есть Grafana - инструмент для визуализации результатов мониторинга в виде интерактивного дашборда.

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

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

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

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

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

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

Source: Skillfactory