Основы DevOps: концепции, культура, история и преимущества
2026-02-21 03:23 Diff
https://skillbox.ru/media/code/vvedenie-v-devops-osnovnye-kontseptsii-kultura-istoriya-i-preimushchestva/

#статьи

  • 27 май 2025
  • 0

Краткая экскурсия по миру DevOps, в которой мы расскажем о топологиях, практиках, культуре и взаимодействии команд.

Иллюстрация: Colowgee для Skillbox Media

Фулстек-разработчик. Любимый стек: Java + Angular, но в хорошей компании готова писать хоть на языке Ада.

Об авторе

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

Переводчик

Екатерина Степанова

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

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

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

Содержание

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

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

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

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

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

Инфографика: BMC / Skillbox Media

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

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

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

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

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

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

Инфографика: BMC / Skillbox Media

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

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

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

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

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

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

Инфографика: BMC / Skillbox Media

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

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

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

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

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

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

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

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

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

Примечание переводчика

Функциональные тесты (ФТ) проверяют работу приложения снаружи, как если бы это делал пользователь, а модульные тесты (МТ, юнит-тесты) — изнутри, с точки зрения разработчика.

ФТ помогают создать приложение, которое делает ровно то, чего хочет клиент. Они гарантируют, что вы никогда не сломаете логику работы. МТ помогают писать чистый код без ошибок — надёжный, производительный, не вызывающий утечек памяти, расширяемый и так далее.

Согласно ISTQB, модульное тестирование может проверять и функциональность — в случае, если компонент (модуль, программу, функцию, объект, класс и так далее) можно тестировать отдельно от других.

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

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

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

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

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

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

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

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

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

Микросервисная архитектура — распространённое решение, и это неслучайно:

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

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

Инфографика: BMC / Skillbox Media

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

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

Такая топология применяется в Netflix. Её суть в том, чтобы в команде разработки были не только программисты, но и специалисты технической поддержки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Практический курс: «Профессия DevOps-инженер» Узнать о курсе