Введение в DevOps: основные концепции, культура, история и преимущества

DevOps (Development Operations) — это популярная методология, которую применяют, чтобы повысить производительность компании — независимо от того, в какой отрасли она работает. С каждым днём всё больше компаний внедряют у себя эту модель.

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

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

Содержание

Что такое DevOps

Раньше в IT были отдельные команды разработки (developers, Dev-команда) и сопровождения, или поддержки (operations, Ops-команда). У этих команд были разные руководители, обязанности и цели. Во многих компаниях они даже работали на разных этажах и почти не пересекались.

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

Успехи DevOps помогли сломать эту стену. Теперь эти команды:

• работают сообща;
• разделяют обязанности;
• вместе отвечают за каждую часть ПО на протяжении его жизненного цикла.

Сегодня DevOps широко используется в IT-индустрии. Этой методологии доверяют даже техногиганты вроде Amazon, Google, Netflix и BMC Software. И всё чаще компании задумываются, как распространить принципы DevOps на всю организацию, то есть применять их не только в IT.

Откуда взялся DevOps

До 2000 года большинство IT-компаний применяли линейный подход к разработке ПО — каскадную модель, или «водопад» (waterfall).

При таком подходе:

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

В итоге в выпуске ПО образовывались большие перерывы (порой в несколько лет). А само оно часто выходило забагованным, и эти баги затыкали многочисленными патчами между выпусками.

С появлением методологии Agile отрасль перешла к итеративной разработке ПО с более частыми релизами. Заработавшие в этой модели непрерывная интеграция (Continuous Integration, CI) и непрерывная поставка (Continuous Delivery, CD) позволили быстрее и чаще выпускать ПО для пользователей.

Культура DevOps

Чтобы перейти к культуре DevOps, организациям придётся:

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

По этой методологии Dev- и Ops-команды должны работать сообща и часто общаться друг с другом.

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

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

DevOps-практики

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

А теперь подробнее об этих практиках и инструментах.

Непрерывная интеграция
(Continuous Integration, CI)

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

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

Эта практика помогает быстрее выявлять ошибки и повышает качество ПО.

Непрерывная поставка и развёртывание
(Continuous Delivery и Continuous Deployment)

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

Все эти задачи помогают выполнять Jenkins, Bamboo, Travis, TeamCity и другие CI- и CD-утилиты.

(Подробнее о разнице между CI и CD читайте тут.)

Непрерывное тестирование
(Continuous Testing)

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

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

Таким образом, код будет развёрнут в среде контроля качества (QA environment) для функционального тестирования, только если успешно пройдёт все модульные тесты.

В числе популярных инструментов для непрерывного тестирования — Selenium, Travis и Appium.

Непрерывное наблюдение
(Continuous Monitoring)

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

Большинство компаний следят за такими показателями:

• использование CPU и памяти;
• использование дискового пространства;
• действия клиентов;
• политики безопасности.

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

Популярные инструменты непрерывного мониторинга: Nagios, Sensu, Prometheus.

Инфраструктура как код
(Infrastructure as Code, IaC)

Инфраструктура как код (Infrastructure as Code, IaC) — это модель, при которой инфраструктура — виртуальные машины, балансировщики нагрузки, сети и так далее — настраивается и управляется программно, а не вручную. Такая инфраструктура стала необходимым компонентом DevOps в организациях, которые специально перешли на облачные платформы.

Например, Amazon Web Services (AWS) предоставляет API для программного взаимодействия со своей облачной инфраструктурой. Использование программного кода для определения конфигурации помогает сделать процесс стандартным и быстро развёртывать ресурсы в облаке.

Микросервисы
(Microservices)

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

Микросервисная архитектура — распространённое решение в DevOps-культуре. И это не случайно. Она:

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

Топологии DevOps

Способы применения DevOps сильно зависят от конкретной организации. По словам Мэттью Скелтона (Matthew Skelton) и Мануэля Пайса (Manuel Pais), чтобы внедрение DevOps проходило успешно, компании применяют разные типы топологий или командных структур. Скелтон и Пайс выделяют девять типов топологий.

Сотрудничество Dev- и Ops-команд

Это идеальная командная структура для DevOps. В ней Dev- и Ops-группы тесно взаимодействуют друг с другом:

• Разработчики серьёзно относятся к задачам команд поддержки и прислушиваются к Ops-коллегам, если это необходимо.
• Члены команд поддержки отлично понимают, чем занимаются разработчики.

Распределённые операционные обязанности

Такая топология применяется в Facebook и Netflix. Она состоит из команд разработчиков, в которые вплетены команды поддержки. Dev и Ops при этом почти не различаются.

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

Ops в качестве «инфраструктуры как услуги»

Эта топология подходит для организаций с различными/несколькими службами, расположенными на облачных платформах, но с традиционным IT-отделом, реструктурировать который не планируется. При таком подходе Ops-группа — это, по сути, «инфраструктура как услуга» (Infrastructure as a Service, IaaS).

DevOps как внешний сервис

Некоторые организации не обладают достаточным опытом или не могут себе позволить организацию отдельной Ops-команды. В таком случае они могут поручить управление операционными аспектами ПО внешнему провайдеру.

DevOps-команды «по требованию»

Dev- и Ops-команды временно объединяются, чтобы достичь какой-то конкретной цели. Как только задача выполнена, команду распускают.

Команда DevOps advocacy

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

SRE-команда

Эту топологию придумали в Google. В такой структуре есть группа, которая занимается «проектированием надёжности сайта» (Site Reliability Engineering, SRE). Разработчики доказывают сотрудникам этой команды, что их ПО соответствует стандартам. SRE могут откатить изменения, если не согласны с ними.

Сотрудничество на основе контейнеров

При контейнеризации требования к развёртыванию и времени выполнения переносятся на слой контейнеров. Это убирает часть взаимозависимостей между Dev- и Ops-командами.

Такая структура подходит для организаций с хорошо развитой инженерной культурой.

Сотрудничество Dev и DBA

С такой топологией экспериментировали некоторые организации, у которых есть приложения, подключённые к крупным централизованным базам данных. Суть структуры в том, что как в DBA (DataBase Administrator), так и в Dev-командах определены взаимосвязанные роли для сотрудников, отвечающих за базы данных. Тем самым преодолевается разрыв между этими двумя группами.

Ключевые преимущества DevOps

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

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

На этом видео Дэвид Риццо (David Rizzo), вице-президент по разработке ПО в BMC Software, и Дэвид Кеннеди, архитектор решений, рассказывают о том, как внедрили DevOps в Compuware, чтобы подстегнуть инновации, уменьшить число ошибок и уменьшить показатель MTTR.

DevOps выходит за рамки бизнес-модели

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

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

При правильном применении культура DevOps может дать компаниям огромные возможности для успешного выпуска ПО.