DevOps

Материал из Википедии — свободной энциклопедии
Это старая версия этой страницы, сохранённая 84.47.152.2 (обсуждение) в 11:08, 21 октября 2024 (Новая система AIOps - подключаем ИИ к DevOps). Она может серьёзно отличаться от текущей версии.
Перейти к навигации Перейти к поиску
Разработка программного обеспечения
Ключевые процессы
Парадигмы и модели
Методологии
Инструменты
Схема взаимодействия в методологии Devops. Разработка + Тестирование + Эксплуатация = DevOps
Иллюстрация, показывающая вариант DevOps как пересечения разработки, эксплуатации и тестирования

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

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

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

Задача инженеров автоматизации технологических процессов сборки, настройки и развёртывания программного обеспечения (DevOps engineers) — сделать процессы разработки и поставки программного обеспечения согласованным с эксплуатацией, объединив их в единое целое с помощью инструментов автоматизации.

Движение за автоматизацию технологических процессов сборки, настройки и развёртывания программного обеспечения (DevOps-движение) возникло в 2009 году и было призвано решить проблемы взаимодействия команд разработки и эксплуатации программных продуктов. В том же году в Бельгии была организована серия конференций «DevOps Days»[1][2]. Затем «DevOps-дни» проходили в различных городах и странах мира.

Возникновение

Истоками того, что стало современным DevOps, включая некоторые стандартные принципы, такие как: автоматизация сборки и тестирование, непрерывная интеграция и непрерывная доставка — возникли в мире Agile, который (неофициально) датируется 1990-ми годами, а формально — 2001 годом. Команды разработчиков, использующие такие методы, как экстремальное программирование, не смогли бы «удовлетворить потребности заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения»[3], если бы эти методы не включали в себя обязанности по настройке операций и поддержанию инфраструктуры разрабатываемого приложения (в максимально автоматизированном режиме). Поскольку Scrum стал доминирующей гибкой структурой в начале 2000-х годов, и в нем отсутствовали инженерные методы, которые были частью многих Agile команд, движение за автоматизацию операций/функций инфраструктуры отделилось от Agile и расширилось до того, что стало современными DevOps. Сегодня DevOps фокусируется на развертывании разработанного программного обеспечения, независимо от того, разработано ли оно с помощью гибких или других методологий.

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

Набор инструментов

Поскольку DevOps — это командная работа (между сотрудниками, занимающимися разработкой, операциями и тестированием), нет единого инструмента «DevOps»: это скорее набор (или «инструментальная цепочка DevOps»), состоящий из нескольких инструментов. Как правило, инструменты DevOps вписываются в одну или несколько из этих категорий, что отражает ключевые аспекты разработки и доставки программного обеспечения[4]:

  1. Кодирование — разработка и анализ кода, инструменты контроля версий, слияние кода;
  2. Сборка — инструменты непрерывной интеграции, статус сборки;
  3. Тестирование — инструменты непрерывного тестирования, обеспечивающие быструю и своевременную оценку бизнес-рисков;
  4. Упаковка — репозиторий артефактов, предварительная установка приложения;
  5. Релиз — управление изменениями, официальное утверждение выпуска, автоматизация выпуска;
  6. Настройка — конфигурация и управление инфраструктурой, Инфраструктура как инструменты кода;
  7. Мониторинг — измерение производительности приложений, взаимодействие с конечным пользователем;
  8. Непрерывная поставка;
  9. Непрерывная интеграция.

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

Такие инструменты, как управление контейнеризацией (Docker, Kubernetes), непрерывной интеграцией (Jenkins, GitLab), развёртывания сред по шаблону (Puppet, Ansible, Terraform) и многие другие — часто используются и часто упоминаются в дискуссиях по инструментам DevOps[6].

Сравнение с Continuous delivery

Continuous delivery и DevOps похожи по своим значениям (и часто сочетаются), но они представляют собой две разные концепции:

DevOps применяется в более широких аспектах и сосредоточен вокруг:

  1. Организационных изменений: в частности, для поддержки более тесного сотрудничества между различными типами работников, занимающихся поставкой программного обеспечения;
  2. Разработчиков;
  3. Операций;
  4. Гарантии качества;
  5. Управления;
  6. Системного администрирования;
  7. Администрирования базы данных;
  8. Координаторов
  9. Автоматизации процессов в поставке программного обеспечения[7].

Continuous delivery — это подход к автоматизации аспекта поставки, который фокусируется на:

  1. Объединении различных процессов;
  2. Выполнении их быстрее и чаще.

Они имеют общие конечные цели и часто используются вместе для их достижения. DevOps и Continuous delivery используют гибкие методы: небольшие и быстрые изменения с целенаправленным результатом для конечного клиента.

Цели

Конкретные цели DevOps охватывают весь процесс поставки программного обеспечения. Они включают:

  1. Сокращение времени для выхода на рынок;
  2. Снижение частоты отказов новых релизов;
  3. Сокращение времени выполнения исправлений;
  4. Уменьшение количества времени на восстановления (в случае сбоя новой версии или иного отключения текущей системы).

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

Интеграция DevOps предназначена для доставки продукта, непрерывного тестирования, тестирования качества, разработки функций и обновлений обслуживания для повышения надежности и безопасности и обеспечения более быстрого цикла разработки и развертывания[8].

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

Преимущества

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

Однако, исследование, выпущенное в январе 2017 года компанией «F5 Labs», на основе опроса почти 2200 ИТ-руководителей и специалистов отрасли, показало, что только один из пяти опрошенных полагает, что DevOps оказывает стратегическое влияние на их организацию, несмотря на рост использования. В том же исследовании было установлено, что только 17 % определили DevOps как ключевой инструмент[9]

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

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

Архитектурные условия

Чтобы эффективно использовать DevOps, прикладные программы должны соответствовать набору архитектурно значимых требований (ASR), таких как: возможность развертывания, изменяемость, тестируемость и возможности мониторинга.

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

GitOps

GitOps эволюционировал из DevOps[10][11][12]. В рамках этого подхода, специфическое состояние конфигурации коммитится в Git, давшего имя подходу. В теории, вместо Git может использоваться другая система контроля версий, но на практике это почти всегда Git. Использование системы контроля версий позволяет применять практики код ревью, и откатывать конфигурацию назад. На практике и в обычном DevOps система контроля версий применяется практически всегда.

AIOps

AIOps внедряет искусственный интеллект (ИИ) в DevOps. AIOps [13] расшифровывается как Artificial Intelligence for IT Operations. По сути это искусственный интеллект для управления ИТ на базе многослойной платформы, который автоматизирует обработку данных и принятие решения с помощью машинного обучения и аналитики больших данных, которые приходят с различных элементов ИТ-инфраструктуры в режиме реального времени.

Gartner для того чтобы иметь возможность сравнивать различные решения определил 9 функциональных элементов, которые должна иметь AIOps платформа:

  1. Управление накопленными данными — программное обеспечение или аппаратный комплекс, которые позволяют записывать, индексировать и хранить полуструктурированные данные, которые поступают в больших объемах и с высокой скоростью. По своей сути это управление большими данными.
  2. Потоковое управление данными — программное обеспечение или аппаратный комплекс, которые позволяют осуществлять захват, возможную нормализацию и индексацию, а также представление в реальном времени одного или нескольких типов данных, представленных ниже. Для управления данными в режиме реального времени, программное обеспечение должно не только представлять входящие данные во времени, которые пользователь будет считать реальными, но и фактически предоставлять данные пользователю непосредственно в момент приема, так сказать на лету, не требуя доступа к базе данных.
  3. Прием логов — программное обеспечение, которое позволяет принимать текстовые лог файлы от различных источников с целью дальнейшей обработки и индексирования для хранения.
  4. Прием пакетных данных — программное обеспечение, которое позволяет осуществлять захват пакетных данных напрямую с зеркальных портов или ответвителей трафика. Все пакеты или записи о потоках (flow) должны быть подготовлены к записи и проиндексированы.
  5. Прием цифровых показателей — программное обеспечение, которое позволяет принимать любые цифровые показатели, к которым может быть применена обработка путем математических операций или агрегации по времени.
  6. Прием документов — программное обеспечение, которое позволяет принимать документы и осуществлять семантический и синтаксический анализ документов. По своей сути это обработка естественного языка - natural-language processing (NLP).
  7. Автоматизированное обнаружение и прогнозирование шаблонов — программное обеспечение, которое на основе исторических или потоковых данных одного или нескольких из упомянутых выше типов создает математические или структурные шаблоны, описывающие новые корреляции, которые могут быть выведены из наборов данных, но не непосредственно присутствуют в них. Затем эти закономерности могут использоваться для прогнозирования инцидентов с различной степенью вероятности.
  8. Обнаружение аномалий – программное обеспечение, которое использует различные шаблоны, обнаруженные предыдущими компонентами, чтобы сначала определить базовую производительность или состояние элемента или сервиса, а затем определяет любые отклонения и их степень важности.
  9. Определение истинного источника проблемы – программное обеспечение, которое отключает корреляцию, установленную элементом автоматического обнаружения и прогнозирования шаблонов, для изоляции тех звеньев зависимости, которые представляют подлинные причинно-следственные связи в смысле предоставления шагов и действий для эффективного устранения проблемы.

IBM выпустил продукт IBM Concert [14] для автоматизации внедрения AIOps в существующую инфраструктуру DevOps.


Примечания

  1. ↑ Debois, Patrick. DevOps Days Ghent. DevopsDays. Дата обращения: 19 августа 2019. Архивировано 24 марта 2011 года.
  2. ↑ Один из соавторов DevOps Cookbook, Джон Уиллис, написал фантастический пост Архивная копия от 25 августа 2019 на Wayback Machine об этом событии.
  3. ↑ Основополагающие принципы Agile-манифеста. agilemanifesto.org. Дата обращения: 10 ноября 2021. Архивировано 20 января 2022 года.
  4. ↑ Gartner Market Trends: DevOps – Not a Market, but Tool-Centric Philosophy That supports a Continuous Delivery Value Chain (англ.) : journal. — Gartner, 2015. — 18 February.
  5. ↑ Theakanath, Thomas. DevOps Stack on a Shoestring Budget. laptrinhx.com. Дата обращения: 5 февраля 2016. Архивировано 21 марта 2022 года.
  6. ↑ Stronger DevOps Culture with Puppet and Vagrant. Puppet Labs. Дата обращения: 22 октября 2015. Архивировано из оригинала 29 января 2016 года.
  7. ↑ Humble, Jez; Farley, David. Continuous Delivery: reliable software releases through build, test, and deployment automation (англ.). — Pearson Education[англ.], 2011. — ISBN 978-0-321-60191-9.
  8. ↑ 1 2 Chen, Lianping. Continuous Delivery: Huge Benefits, but Challenges Too (англ.) // IEEE Software[англ.] : journal. — 2015. — Vol. 32, no. 2. — P. 50. — doi:10.1109/MS.2015.27. Архивировано 9 июня 2016 года.
  9. ↑ Bourne, James. New research questions strategic importance of DevOps despite rise in usage (англ.) // CloudTech : journal. — 2017. — 23 January. Архивировано 1 марта 2017 года.
  10. ↑ Getting Started with GitOps. TheNewStack.io (13 декабря 2021). Дата обращения: 5 апреля 2022. Архивировано 20 сентября 2022 года.
  11. ↑ GitOps Workflows and Principles for Kubernetes. ContainerJournal.com (1 апреля 2022). Дата обращения: 5 апреля 2022. Архивировано 20 сентября 2022 года.
  12. ↑ Kubernetes at Scale without GitOps Is a Bad Idea. TheNewStack.io (7 марта 2022). Дата обращения: 5 апреля 2022. Архивировано 20 сентября 2022 года.
  13. ↑ https://networkguru.ru/AIOps-Artificial-Intelligence-for-IT-Operations/
  14. ↑ https://www.ibm.com/products/concert
Источник — https://ru.wikipedia.org/w/index.php?title=DevOps&oldid=140948271