Автоматизация разработки и эксплуатации ПО

Методология, принципы, подходы и технологии DevOps

Аладин Дмитрий Владимирович

iu5edu.ru/wiki/devops/

План

  1. DevOps как методология.
  2. DevOps как сочетание культурных принципов.
  3. DevOps как сочетание разработки и поддержки продуктов.
  4. DevOps как совместная деятельность.
  5. DevOps как сочетание подходов.
  6. DevOps как сочетание технологии.
  7. Эволюция концепций разработки.
  8. Гибкая методология разработки.
  9. Agile и DevOps.

Сегодня в выпуске

center

В конце выпуска

center

center

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

Определение термина DevOps

DevOps (development & operations) — методология автоматизации технологических процессов сборки, настройки и развёртывания программного обеспечения. В любом процессе разработки участвует три команды:

  • Dev — программисты, которые непосредственно пишут код;
  • QA/QC (часто рассматривают как часть Dev) тестировщики, которые выявляют ошибки в коде, вручную или автоматически;
  • Ops — инженеры, которые поддерживают инфраструктуру для написания кода, например сервера, а также берут уже рабочий код и запускают на реальные сервера, чтобы клиент получил доступ к сайту, сервису или приложению.

Определение термина методология

Методология - в узком смысле слова – совокупность процедур, приёмов и методов науки, объединённых в единую конструктивную программу и служащих средствами для постижения того или иного объекта научного знания.

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

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

Методика — это практический подход или набор инструкций, которые используются для достижения определенных целей или решения конкретных задач.

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

DevOps как методология

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

center

В чем выражается методология DevOps

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

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

P.S. Как эти цели достигаются мы рассматривали в предыдущих лекциях.

DevOps безусловно не на 100% заимствовал все подходы из Agile, но он взял лучшее, а некоторые моменты даже преобразил.

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

Из статьи Жертвы Agile: почему гибкая методология разработки губит крупный бизнес и помогает малому

P.S. Позже обсудим проблемы Agile.

Определение терминов принцип и культурный принцип

Принцип (лат. principium – первоначало, основа) – основополагающая, фундаментальная идея, правило поведения, следование которым помогает наилучшим образом достигать поставленных целей.

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

Принцип - исходное, не требующее доказательств положение теории (то же, что аксиома или постулат); внутреннее убеждение, неизменная позиция или правило поведения (то же, что максима или заповедь).

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

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

DevOps как сочетание культурных принципов

DevOps — это ещё и культурное явление в разработке и сочетание культурных принципов, подходов и средств. В Agile есть: аналитики (бизнес и системные), разработка, тестирование, инженеры, которые отвечают непосредственно за поддержку продакшена. В DevOps появляются новые роли и ответвления.

Ответвления DevOps

  • Методология SRE (site reliability engineering). Эта методология делает упор на мониторинг и на качество продукта и услуги сервиса предоставляемым клиентам компании.
  • Клауд-инженеринг (cloud engineering). Он нацелен на работу с различными облачными решениями, как классическими облаками, так и multi-clouds и содержимого в них.
  • ChatOps. Это подход к управлению операционными задачами и коммуникации внутри команды и организации с использованием чат-платформы и инструментов для мгновенного обмена сообщениями, а так же управлению инфраструктурой и стэком CI/CD через мессенджеры.
  • ArchOps. Это направление фокусируется на архитектурных аспектах разработки, начиная от проработки дизайна архитектуры, заканчивая стоимостью оборудования под разрабатываемое ПО.

Кажется, что

Давайте к любому слову добавим -Ops и все будет клево!

На деле, нужно смотреть на то, как новое слово с -Ops применяется и какие смысловые нагрузки оно несет. Чаще всего это применение ранее существовавшей практики/методологии/подхода/метода в DevOps/Agile. Насколько хорошо он/она/они применены для разработки зависит от многого.

P.S. Интересный доклад: Dev.+Ops, или Строим идеальный процесс поставки.

NoOps

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

P.S. Некоторые наблюдатели рассматривают NoOps как катастрофу, которая вот-вот произойдет.

В основе DevOps лежат конфликты

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

Спустя десятилетия разговорный ИИ решит проблемы всех трех групп, сократив их количество 😈 Останутся только тестировщики.

ОПСов много, а ОПСОСы — это ОПераторы СОтовой Сети.

center

DevOps как сочетание разработки и поддержки продуктов

  • Dev — development (разработка).
  • Ops — operation (эксплуатация).

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

За что могут отвечать DevOps-инженеры

  • за продуктивный контур;
  • за все контура и стэк CI/CD;
  • за всё, что связано с CI/CD и тестовые контуры.

А могут только исключительно за развитие продуктов, внедрение новых технологий и всего, что связано с CI/CD-конвейером.

Все зависит от компании и от зрелости процессов разработки в ней.

DevOps как совместная деятельность

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

center

Шаг 1: Планирование

Сначала на, основе требований бизнеса, бизнес-аналитиком пишутся бизнес-требования (БТ), потом архитектура приложения и, если она всех устраивает, то бизнес-требования перерабатываются системным-аналитиком в техническое задание (ТЗ).

На этом шаге DevOps — это какие-либо тикетные системы планирования, проджект-системы.

Шаг 2: Кодинг (разработка)

Разработчики пишут код на основе ТЗ, результатом чего появляется некая первая версия приложения (ПО) в сыром виде.

Здесь DevOps — это IDE разработчиков и репозиторий исходных кодов. Важно, на данном этапе так же важно покрытия кода функциональными и unit-тестами, а так же проверка кода на код-дизайн (code-style), и code-review (ревью кода).

Шаг 3: Компиляция

Скомпилированное (собранное) приложение собирается с прохождением проверок на код-дизайн, покрытие кода функциональными и unit-тестами. Если все проверки прошли успешно, то сборка приложения помещается в реестр скомпилированных приложений, или артефактов.

Шаг 4: Тестирование

Чтобы сборку протестировать, её нужно задеплоить или развернуть на некий тестовый контур. Это может быть выделенная тестовая тестировщика, виртуальная машина (ВМ) или набор тестовых контуров. После чего происходит различного рода тестирования, которое всегда начинается с мануального, а далее - smoke, функциональное, UI, регресс, нагрузочное и т.д., в зависимости от зрелости методологии тестирования в компании.

Шаг 5: Формирование релиза

Его могут собирать, как сами девопс-инженеры или лид-разработки, или ответственный разработчик, либо отдельно отведённые под это специалисты, которые отвечают за сам релиз. Ими могут быть - скрам-мастера, delivery-manager, release-manager и т.д.

Шаг 6: Деплой в продакшен

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

Шаг 7: Мониторинг

Разработчики и специалисты из подразделения поддержки (operations) и/или мониторинга, наблюдаем за ранее развёрнутым релизом: насколько все прошло хорошо, нужна ли поддержка или дополнительный мониторинг.

Определение термина подход

Подход - это совокупность приёмов, способов.

Подход - это способ решения, осуществления, объяснения чего-либо

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

DevOps как сочетание подходов

  • Continuous Integration (CI)
  • Automated Testing (AT)
  • Continuous Testing (CT)
  • Continuous Deployment (CD)
  • Automated Recovery (AR)
  • Release Management (RM)
  • Infrastructure as Code (IaС)
  • Performance Monitoring (PM)
  • Application Monitoring (AM)
  • Business Monitoring (BM)
  • Configuration Managment (CM)
  • CI/CD

Continuous Integration (CI)

Непрерывная интеграция — это процесс работы с исходным кодом, сборка и тестирования покрытия кода функциональными и unit-тестами, проверка кода code-style и code-review. Результатом этого подхода будет артефакт (artefact) — скомпилированное приложение.

center

Automated Testing (AT)

Когда приложение переваливает за десятки или сотни версий, мануально его тестировать становится уже невыгодно и слишком медленно. Тут нам на помощь приходят автотесты, которые встраивают в pipeline.

center

Continuous Testing (CT)

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

center

Continuous Deployment (CD)

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

center

Automated Recovery (AR)

Это подход, при котором можно восстанавливать любой контур, прежде всего, контур продакшна на предыдущую версию приложения со всеми вытекающими, как слой app, так и слой DB. Некоторые приложения не умеют автоматически откатываться на предыдущую версию. Даже если такой конвейер настроен из коробки с учетом CI/CD инструментов. Соответственно, некоторые приложения фиксят свои баги только путём доустановкой следующего релиза. Они не могут откатиться назад, могут идти только докатками.

center

Release Management (RM)

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

center

Infrastructure as Code (IaС)

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

center

Performance Monitoring (PM)

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

center

Application Monitoring (AM)

Это история про поведение приложения, в которую входят его метрики: connection treadpool, connection db pool, расходование именно самим приложением памяти, нагрузку на утилизацию ядер, попадание в SWAP, деградация свершения запросов в БД и т.д. Слой app затрагивает все компоненты приложения. Не забываем, что сюда входит не только классический app мониторинг, но и log-tracing.

center

Business Monitoring (BM)

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

center

Configuration Managment (CM)

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

center

CI/CD

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

center

Continuous Delivery и Continuous Deployment

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

center

Определение термина технология

Технология - (от греч. искусство, мастерство, умение и греч. изучение) – совокупность методов и инструментов для достижения желаемого результата; метод преобразования данного в необходимое; способ производства.

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

Технология - в узком смысле - способ преобразования вещества, энергии, информации в процессе изготовления продукции, обработки и переработки материалов, сборки готовых изделий, контроля качества, управления.

DevOps как сочетание технологии

Ключевые инструменты, без которых внедрить подход DevOps нельзя:

  • Системы контроля версий;
  • CI/CD-системы;
  • Системы мониторинга.

Как мы дошли до всего этого?

center

Что было до DevOps

C 1970-ых годов каскадная модель процесса разработки программного обеспечения, известная как Waterfall. Методика предполагала последовательный переход между этапами без пропусков и возвращений на предыдущие стадии.

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

Гибкие методики разработки

Гибкие методики разработки (agile software development) — обобщающий термин для целого ряда подходов и практик, основанных на ценностях Манифеста гибкой разработки программного обеспечения и 12 принципах, лежащих в его основе.

center

Agile-манифест

Agile-манифест увидел свет в феврале 2001 года в городе Сноуберд (США). Тогда встретились 17 экспертов и практиков в области разработки ПО. Они поставили цель — создать метод, который позволит эффективно справляться с вызовами и изменениями IT-индустрии. Среди участников были представители различных методологических школ: экстремального программирования (XP), Scrum, DSDM и других.

center

Принципы и ценности Agile-манифеста

По Agile, люди важнее процессов и инструментов. Нельзя следовать жестким правилам, если это мешает взаимодействию сотрудников и продуктивной работе.

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

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

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

Фреймворки Agile

  • Scrum. Фреймворк управления проектами по Agile, ориентированный на итеративное и инкрементное создание продукта. Подход определяет роли, события и артефакты, которые делают процесс более гибким и прозрачным.
  • Канбан. Метод управления, в основе которого — визуализация потока работы. Команда заполняет Kanban-доску, на которой отражается текущее состояние каждой задачи: от идеи до завершения. Все в курсе, какие процессы в работе, что только предстоит сделать, а какие цели уже достигнуты.
  • Экстремальное программирование (XP). Акцент на практиках, которые повышают качество кода, автоматизируют тестирование и обеспечивают частую поставку работающего продукта.
  • Lean Software Development. Производное от методов Toyota Production System. Здесь акцент на минимизации потерь и обосновании ценности для клиента.
  • SAFe (Scaled Agile Framework). Набор инструментов для внедрения аджайл-практик в больших компаниях. SAFe помогает множеству команд работать в рамках Agile, сохраняя координацию и высокий темп выполнения задач. Это как управление маленькими лодками в большом океане: каждое судно (agile-команда) движется своим путем, но все равно остается частью большой системы.
  • LeSS (Large Scale Scrum). Подход к масштабированию Scrum, более простой, чем SAFe. Вместо множества процессов и дополнительных ролей LeSS стремится к минимальной этапности и отсутствию иерархии.

Критика Agile

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

Частые изменения и усовершенствования продукта могут привести к массовому рефакторингу и плавающей стоимости проекта в итоге.

При этом Agile не рассматривает инструменты разработки.

Идея и культура DevOps

Методология DevOps получила широкое распространение после организованной бельгийским разработчиком Патриком Дебуа в 2009 году конференции DevOpsDays.

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

Принципы DevOps

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

Аббревиатура CAMS расшифровывается следующим образом:

  • культура (culture);
  • автоматизация (automation);
  • измерение (measurement);
  • обмен (sharing).

CAMS: Культура

Классические бизнес-модели в IT разделяют специалистов по разработке и эксплуатации на две отдельные группы.

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

CAMS: Автоматизация

В идеале автоматизировать нужно почти все:

  • инфраструктуру;
  • выпуски программного обеспечения (software releases);
  • тестирование;
  • развертывание;
  • основные задачи по безопасности;
  • политику соглашений;
  • задачи управления конфигурацией.

CAMS: Измерение

Измерять нужно показатели следующих процессов:

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

CAMS: Обмен

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

DevOps и Agile

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

center

Основные различия между DevOps и Agile:

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

center

  • Agile выступает за поэтапное развертывание после каждого спринта. Для DevOps характерна непрерывная доставка (до нескольких раз в день).

В результате имеем

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

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

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

Использованные источники

  1. DevOps: методология, принципы, подходы и технологии
  2. Разница между Agile и DevOps
  3. Agile и DevOps методологии в тестировании ПО
  4. Как взаимосвязаны Agile и DevOps?
  5. Agile, DevOps, CI/CD. Как менялись концепции разработки
  6. Основы методологии DevOps
  7. The 13-Types Of Ops
  8. The Many Flavors of Ops
  9. Что такое DevOps: зачем он нужен, где применяется и в чём его плюсы и минусы
  10. AT THE HEART OF DEVOPS LIES CONFLICT
  1. Люди и конфликты в DevOps // Ахмед Шериев, независимый эксперт по DevOps
  2. Пора закончить холодную войну между DevOps и разработчиками ПО
  3. Agile-манифест: ключевые положения, принципы, история и развитие

Вопросы?

center

If not, just clap your hands!