DevOps

menu icon

DevOps

DevOps ускоряет доставку программного обеспечения и повышает качество кода за счет объединения усилий команд разработки ПО и эксплуатации ИТ-систем и автоматизации их работы.

Что такое DevOps?

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

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

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

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

История появления DevOps

До 2000 года в основном применялась каскадная модель разработки и обновления ПО c последовательной реализацией масштабных проектов. У разработчиков ПО могло уйти несколько месяцев на создание больших блоков нового кода, затрагивавших все приложение или большую его часть. Из-за огромного числа изменений для интеграции нового кода требовалось еще несколько месяцев.

Последующее тестирование кода с участием специалистов по обеспечению качества (QA), безопасности и эксплуатации занимало еще какое-то время. В результате новые версии ПО, обновления или исправления ошибок выходили с интервалом в несколько месяцев или даже лет. Такой способ доставки компонентов методом «большого взрыва» (big bang) обычно сопровождался сложными, рискованными планами развертывания, трудностями при планировании синхронизации с системами выше и ниже уровнем, а также большими надеждами на то, что бизнес-требования не изменятся существенным образом спустя несколько месяцев, когда продукт будет готов к развертыванию в рабочей среде.

В целях ускорения разработки и повышения качества коллективы разработчиков начали применять гибкие методологии разработки программного обеспечения, которые носят итерационный, а не линейный характер и фокусируются на более мелких и частых обновлениях базы исходного кода приложения. Одним из важнейших представителей данной группы методологий является CI/CD или непрерывная интеграция и непрерывная доставка. Согласно принципам CI/CD, небольшие фрагменты нового кода добавляются в базу исходного кода каждую одну-две недели, с последующей автоматической интеграцией, тестированием и подготовкой к развертыванию в рабочей среде. Гибкая модель разработки ПО заменила метод «большого взрыва» на серию «небольших шагов», ограничив при этом риски.

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

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

Принцип работы DevOps: жизненный цикл DevOps

Диаграмма, иллюстрирующая жизненный цикл DevOps

Рис. 1. Жизненный цикл DevOps

Жизненный цикл DevOps, который иногда называют конвейером непрерывной доставки в линейном представлении, является последовательностью итерационных, автоматизированных процессов разработки (или рабочих процессов), выполняемых в рамках более крупного, автоматизированного и итерационного жизненного цикла разработки, с целью оптимизации сроков доставки ПО высокого качества. Названия рабочих процессов и их количество могут отличаться от команды к команде, но обычно выделяют шесть этапов:

  • Планирование (или формирование идеи). На этом этапе команды определяют новые функции и компоненты следующего выпуска, опираясь на приоритетные отзывы конечных пользователей, практический опыт и мнение всех внутренних заинтересованных сторон. Основная задача на этапе планирования — максимально повысить коммерческую ценность продукта путем составления списка функций, которые обеспечат требуемый результат.
  • Разработка. На этом этапе программирования разработчики создают и тестируют исходный код и разрабатывают новые и улучшенные функции, опираясь на пользовательские требования и элементы списка. Методы разработки (например, разработка, основанная на тестировании (TDD), парное программирование и равноправный анализ кода) часто комбинируются между собой. Разработчики часто используют локальные рабочие станции для реализации «внутреннего цикла» создания и тестирования исходного кода, прежде чем он будет отправлен на следующий этап конвейера непрерывной доставки.
  • Интеграция (сборка или непрерывная интеграция и непрерывная доставка CI/CD). Как отмечалось выше, на данном этапе новый код интегрируется в существующую базу исходного кода, тестируется и компонуется в виде исполняемого файла для развертывания. К типичным операциям автоматизации относятся объединение изменений в коде в «главную» копию, извлечение кода из репозитория и автоматизация процессов компиляции, модульного тестирования и сборки исполняемого файла. Рекомендуется сохранить результаты, полученные на этапе непрерывной интеграции, в репозиторий двоичных файлов для следующего этапа.
  • Развертывание (или непрерывное развертывание). На данном этапе выполняется развертывание выходных данных сборки (после интеграции) в среде выполнения, в роли которой обычно выступает среда разработки, предназначенная для тестирования качества, безопасности и соблюдения нормативных требований. У разработчиков есть возможность выявить и устранить любые ошибки или дефекты, прежде чем с ними столкнутся конечные пользователи. Для целей разработки, тестирования и эксплуатации применяются отдельные среды с постепенно повышающимися требованиями к качеству. На этапе развертывания в рабочей среде рекомендуется сначала развернуть продукт для небольшой группы конечных пользователей и, убедившись в его стабильной работе, предоставить доступ всем пользователям.
  • Эксплуатация. После развертывания компонентов в рабочей среде («День 1») наступает этап эксплуатации («День 2»). Выполняя мониторинг производительности, поведения и доступности компонентов, можно удостовериться в том, что компоненты обеспечивают дополнительную ценность для конечных пользователей. На этапе эксплуатации необходимо обеспечить бесперебойную, слаженную работу всех компонентов, включая сетевые ресурсы, ресурсы хранения данных, платформу, вычислительные ресурсы и функции безопасности. В случае возникновения неполадок необходимо обеспечить выявление инцидентов, отправку уведомлений соответствующим сотрудникам, локализацию проблемы и применение исправлений.
  • Обучение (или непрерывная обратная связь). На этом этапе выполняется сбор отзывов о компонентах, функциях, производительности и коммерческих результатах от конечных пользователей и заказчиков. Полученные данные передаются на этап планирования для подготовки улучшений и новых функций в следующем выпуске. Необходимо также принять во внимание любые результаты и списки задач, полученные на этапе эксплуатации. Это поможет разработчикам предотвратить повторное возникновение известных инцидентов в будущем. В этой точке происходит «циклический возврат» на этап планирования и продолжается «непрерывное улучшение»!

Между этими рабочими процессами существует еще три важных этапа:

Непрерывное тестирование: в классическом жизненном цикле DevOps существует отдельный этап «тестирования», расположенный между этапами интеграции и развертывания. Однако современная концепция DevOps позволяет выполнять отдельные элементы тестирования на этапе планирования (разработка через реализацию поведения), разработки (модульное тестирование, контрактное тестирование), интеграции (статический анализ кода, сканирование CVE, проверка соблюдения стандартов кодирования), развертывания (дымовое тестирование, тестирование защиты от несанкционированного доступа, конфигурационное тестирование), эксплуатации (хаос-тестирование, тестирование на соответствие) и обучения (A/B-тестирование). Тестирование — эффективный способ обнаружения рисков и уязвимостей, позволяющий принять, минимизировать или устранить риски.

Безопасность: если каскадная модель разработки и гибкие методологии присоединяют рабочие процессы безопасности уже после доставки или развертывания, то DevOps стремится решать вопросы безопасности с первого этапа (планирования), когда для этого достаточно минимальных усилий и затрат, а затем непрерывно в течение всего последующего цикла разработки. Такой подход к обеспечению безопасности получил название сдвиг влево (shift left) (см. Рис. 1). Поскольку попытки реализовать эту идею не всегда заканчивались успешно, возникла концепция DevSecOps (см. ниже).

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

Культура DevOps

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

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

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

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

Инструменты DevOps: создание цепочки инструментов DevOps

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

  • Инструменты для управления проектами — инструменты, с помощью которых команды могут создавать списки пользовательских требований для формирования проектов, разбивать их на более мелкие задачи и отслеживать ход реализации. Многие инструменты поддерживают гибкие методики управления проектами, такие как Scrum, Lean и Kanban, применяемые в DevOps. Примеры популярных инструментов с открытым исходным кодом: GitHub Issues и Jira.
  • Общие репозитории для хранения исходного кода — среды программирования с системой контроля версий, которые позволяют нескольким разработчикам работать с одной базой исходного кода. Репозитории исходного кода должны поддерживать интеграцию с инструментами CI/CD, тестирования и безопасности для автоматической передачи исходного кода на следующий этап жизненного цикла. Примеры репозиториев с открытым исходным кодом: GiHub и GitLab.
  • Конвейеры CI/CD — инструменты, автоматизирующие извлечение, разработку, тестирование и развертывание исходного кода. Самым популярным инструментом с открытым исходным кодом в этой категории является Jenkins; многие бесплатные изначально инструменты, например CircleCI, теперь распространяются на коммерческой основе. Что касается инструментов непрерывного развертывания (CD), Spinnaker находится на стыке приложения и инфраструктуры. ArgoCD — еще один популярный инструмент с открытым исходным кодом для CI/CD на основе Kubernetes.
  • Среды автоматизации тестирования: к ним относятся программные инструменты, библиотеки и передовые методики в области автоматизации модульного тестирования, функционального тестирования, тестирования производительности, тестирования удобства использования, тестирования защиты от несанкционированного доступа и тестирования безопасности. Лучшие инструменты в этой категории поддерживают несколько языков; в некоторых применяется искусственный интеллект (ИИ) для автоматической настройки тестов после внесения изменений в исходный код. Инструменты и среды тестирования невероятно разнообразны! К популярным средам автоматизации тестирования с открытым исходным кодом относятся Selenium, Appium, Katalon, Robot Framework и Serenity (прежнее название — Thucydides).
  • Инструменты для управления конфигурациями (инфраструктура как код): предоставляют инженерам DevOps возможность настраивать и предоставлять инфраструктуру с полноценной системой контроля версий и документацией на основе сценария. Примеры инструментов с открытым исходным кодом: Ansible (Red Hat), Chef, Puppet и Terraform. Kubernetes выполняет аналогичную функцию для контейнерных приложений (см. раздел «DevOps и облачная разработка» ниже).
  • Инструменты для мониторинга: помогают командам DevOps обнаруживать и устранять системные неполадки; кроме того, они осуществляют сбор и анализ данных в режиме реального времени для выявления изменений, влияющих на производительность приложения. Примеры инструментов для мониторинга с открытым исходным кодом: Datadog, Nagios, Prometheus и Splunk.
  • Инструменты для получения непрерывной обратной связи: обеспечивают сбор отзывов пользователей путем создания таблиц пользовательской активности (регистрации действий пользователей на экране), проведения опросов или с помощью средств для самостоятельной регистрации заявок.

DevOps и облачная разработка

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

Как правило, современные облачные приложения:

  • Создаются с использованием микросервисов — слабосвязанных компонентов, поддерживающих независимое развертывание, которые имеют собственный стек и взаимодействуют между собой посредством REST API, потоков событий или агентов сообщений.
  • Развертываются в контейнерах — исполняемых блоках кода, содержащих весь код, среды выполнения и зависимости операционной системы, необходимые для выполнения приложения. (Для большинства организаций термин «контейнеры» синонимичен с контейнерами Docker, однако существуют и другие типы контейнеров.)
  • Эксплуатируются (в нужном масштабе) с помощью Kubernetes — контейнерной платформы с открытым исходным кодом для планирования и автоматизации развертывания, управления и масштабирования контейнерных приложений.

Во многих отношениях облачная разработка и DevOps созданы друг для друга.

Например, разработка и обновление микросервисов, т. е. итеративная доставка небольших блоков кода в небольшую базу исходного кода, идеально подходит для коротких жизненных циклов DevOps. Было бы сложно справиться со сложной микросервисной архитектурой без процедур развертывания и эксплуатации DevOps.Согласно недавнему опросу, проведенному IBM среди разработчиков и ИТ-руководителей, 78% пользователей микросервисов планируют вкладывать больше времени, денег и усилий в развитие микросервисной архитектуры, а 56% организаций, не использующих микросервисы, планируют их внедрение в ближайшие два года. Дополнительная информация о преимуществах и сложностях микросервисов представлена на следующем интерактивном изображении:

(Источник: «Микросервисы на предприятии: реальные преимущества, превосходящие усилия», 2021 г.)

Упаковывая и исправляя все зависимости ОС, контейнеры ускоряют процессы развертывания и CI/CD, поскольку все задачи интеграции, тестирования и развертывания выполняются в одной и той же среде. Платформа координации Kubernetes выполняет те же задачи непрерывной настройки для контейнерных приложений, что и Ansible, Puppet и Chef для неконтейнерных приложений.

Большинство ведущих поставщиков услуг облачных вычислений, включая AWS, Google, Microsoft Azure и IBM Cloud, предлагают своего рода управляемые решения для конвейера DevOps.

Что такое DevSecOps?

DevSecOps — это DevOps с непрерывной интеграцией и автоматизацией задач в области безопасности на всех этапах жизненного цикла DevOps, от планирования до сбора обратной связи.

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

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

Посмотрите видеоролик «Что такое DevSecOps?», чтобы узнать больше о принципах, преимуществах и сценариях использования DevSecOps:

DevOps и проектирование надежности сайтов (SRE)

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

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

В поиске оптимального баланса инженеры по надежности сайтов определяют приемлемый уровень операционных рисков со стороны приложений — так называемый «бюджет на ошибки» — и автоматизируют операции для достижения требуемого уровня.

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

Дополнительная информация о проектировании надежности сайтов

DevOps и IBM Cloud

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

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

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

Сделайте следующий шаг:

Начните работу с учетной записью IBM Cloud уже сегодня.

IBM Cloud Pak for Watson AIOps использует технологии машинного обучения и понимания естественного языка для сопоставления структурированных и неструктурированных данных в инструментах управления операциями в режиме реального времени с целью обнаружения ценных скрытых знаний и более быстрого выявления основных причин. Устраняя необходимость в нескольких панелях мониторинга, Watson AIOps передает информацию и рекомендации непосредственно в рабочие процессы вашей команды, чтобы ускорить устранение проблем.

Об авторе

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

https://twitter.com/acmthinks (внешняя ссылка)

https://medium.com/@acmThinks (внешняя ссылка)