АссистентНовый вопросИсторияОбласти знаний
Партнёрские проектыСпецпроектыСтать автором
Сменить язык
О РУВИКИ

DevOps

DevOps — методология в разработке программного обеспечения и информационных технологиях, представляющая собой совокупность практик и инструментов, предназначенных для интеграции и автоматизации процессов с целью улучшения и ускорения жизненного цикла разработки программных систем[1]. Название DevOps образовано объединением английских слов development («разработка») и operations («эксплуатация»). DevOps является дополнением к гибкой разработке программного обеспечения, множество практик DevOps происходит из методов agile.

Определение

Хотя DevOps представляет собой кросс-функциональное объединение понятий разработки («development») и эксплуатации («operations») (а также является порто манто), среди исследователей и практиков не существует универсального определения термина DevOps[2]. DevOps чаще всего описывается через фундаментальные принципы: совместная ответственность, автоматизация процессов и быстрое получение обратной связи. Исследователи Лен Басс, Инго Вебер и Лимин Чжу из CSIRO и Института программной инженерии предложили академическое определение, согласно которому DevOps — это «совокупность практик, направленных на сокращение времени между внесением изменений в систему и внедрением изменений в промышленную эксплуатацию при сохранении высокого качества». Однако термин DevOps используется в различных контекстах, а успешное внедрение предполагает сочетание специфических практик, культурных изменений и инструментов.

К 2026 году DevOps эволюционировал в комплексную систему управления, включающую платформенную инженерию, интеграцию искусственного интеллекта (AIOps) и встроенную безопасность (DevSecOps), с фокусом на бизнес-результаты и отказоустойчивость[3].

История

Идеи объединения методологий разработки программного обеспечения с концепциями доставки и эксплуатации появились в конце 1980-х — начале 1990-х годов[4].

В 2007–2008 годах представители профессиональных сообществ разработки программного обеспечения и ИТ выразили обеспокоенность тем, что разделение между командами, создающими ПО, и командами, занимающимися его эксплуатацией и поддержкой, ведёт к значительным дисфункциям в отрасли[5].

В 2009 году в бельгийском городе Гент состоялась первая конференция под названием DevOps Days, инициатором которой стал бельгийский консультант, менеджер проектов и agile-энтузиаст Патрик Дебуа[6][7]. С тех пор подобные конференции проводятся в различных странах.

В 2012 году специалистка из Puppet Labs Алана Браун опубликовала первый отчёт «Состояние DevOps» (State of DevOps)[8].

Начиная с 2014 года, ежегодный доклад State of DevOps публиковался также Николь Форсгрен, Джином Кимом, Джезом Хамблом и другими, фиксируя увеличение темпов внедрения DevOps. В 2014 году Лиза Криспин и Джанет Грегори написали книгу «More Agile Testing», посвящённую практике тестирования и DevOps[9].

В 2016 году в отчёте State of DevOps были представлены DORA-метрики для оценки производительности DevOps-команд (частота релизов, время доставки изменений, среднее время восстановления и частота сбоев). Методология и используемые метрики, однако, подвергались критике со стороны экспертов[9][10].[11]

В 2017 году отчёт DORA и Puppet сместил акцент с чисто технических практик на важность организационной культуры, выделив трансформационное лидерство как ключевой фактор успеха[12]. Исследование показало, что внедрение DevOps продолжает расти: доля специалистов, работающих в DevOps-командах, увеличилась с 16 % в 2014 году до 27 % в 2017[13].

Отчёт 2018 года, подготовленный DORA в сотрудничестве с Google Cloud, ввёл новую категорию производительности — «элитные» исполнители (Elite performers)[14]. Эти команды демонстрировали значительно более высокие результаты: развёртывали код в 2555 раз быстрее и восстанавливались после сбоев в 2604 раза быстрее, чем низкопроизводительные команды[15]. Введение новой категории привело к статистическому сдвигу: лучшие команды, ранее входившие в группу высокопроизводительных, были перемещены в «элиту», что объясняет кажущееся изменение показателей для группы «высокопроизводительных» по сравнению с 2017 годом[14].

В 2019 году доля «элитных» исполнителей почти утроилась, достигнув 20 % от общего числа опрошенных[16]. Отчёт DORA и Google Cloud показал, что использование облачных технологий является ключевым фактором успеха, в то время как параллельный отчёт от Puppet сделал особый акцент на интеграции безопасности в жизненный цикл разработки (DevSecOps)[17].

В 2020 году основной отчёт State of DevOps был выпущен компанией Puppet (DORA в тот год не публиковала свой ежегодный отчёт)[18]. Исследование было сфокусировано на масштабировании DevOps и выявило, что ключевыми факторами успеха являются создание внутренних платформенных команд и применение принципов DevOps к процессам управления изменениями. 63 % респондентов сообщили, что в их компаниях есть хотя бы одна внутренняя платформа самообслуживания.

Отчёт DORA за 2021 год зафиксировал дальнейший рост доли «элитных» исполнителей до 26 %[19]. При этом пороговые значения для попадания в эту категорию не изменились по сравнению с 2018 годом, что свидетельствует о широком распространении лучших практик в индустрии[20]. Ключевыми факторами успеха были названы синергия практик SRE и DevOps, качественная внутренняя документация и интеграция безопасности в цепочку поставок ПО[21].

В отчёте DORA за 2022 год категория «элитных» исполнителей отсутствовала. Исследователи объяснили это тем, что статистический кластерный анализ не выявил отдельной группы, соответствующей этому уровню, а самая производительная группа 2022 года по своим характеристикам оказалась между «высоким» и «элитным» кластерами 2021 года[22][23]. Основной темой исследования стала безопасность цепочки поставок ПО, а главным выводом — то, что организационная культура с высоким уровнем доверия является более значимым фактором для внедрения практик безопасности, чем технические инструменты[24].

В 2023 году отчёт DORA сместил фокус на три ключевых аспекта: производительность организации, эффективность команды и благополучие сотрудников[25]. Было установлено, что подход, ориентированный на пользователя, является одним из самых сильных предикторов успеха, а влияние искусственного интеллекта на производительность пока находится на ранней стадии по сравнению с фундаментальными практиками, такими как CI/CD и качественная документация[25].

В 2024 году вышло несколько ключевых отчётов. Исследование DORA было посвящено влиянию ИИ и платформенной инженерии, показав, что 81 % организаций изменили свои приоритеты для более активного внедрения ИИ[26]. Отчёт Puppet был полностью сфокусирован на эволюции платформенной инженерии[27]. Отдельное исследование российского рынка показало расширение применения DevOps за пределы IT-отрасли и рост использования отечественных ОС, таких как Astra Linux и «Ред ОС»[28].

Отчёт DORA за 2025 год получил название «Состояние разработки ПО с помощью искусственного интеллекта» (State of AI-Assisted Software Development). Его главный вывод заключается в том, что ИИ действует как «усилитель»: он усугубляет существующие проблемы в неэффективных командах и ускоряет работу уже отлаженных коллективов[29]. Несмотря на то, что около 90 % респондентов используют ИИ, исследование выявило «парадокс доверия»: примерно 30 % специалистов практически не доверяют коду, сгенерированному ИИ[30].

В 2026 году компания Perforce выпустила отчёт «State of DevOps Report», главным выводом которого стало то, что зрелость DevOps-практик стала необходимым условием для успешного масштабирования и внедрения искусственного интеллекта в организациях[31].

Связь с другими подходами

Многие идеи, лежащие в основе практик DevOps, заимствованы или вдохновлены такими концепциями, как бережливое производство, цикл PDCA (Plan–Do–Check–Act) Деминга, метод Тойоты, а также гибкие (agile) методы, предполагающие разбиение задач на мелкие компоненты. В отличие от жёстких и иерархических подходов ITIL 1990-х годов, DevOps основывается на гибкости и низовом (bottom-up) внедрении, подходящем для нужд инженеров-программистов[32].

Гибкая методология (Agile)

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

В 2026 году взаимодействие Agile и DevOps усиливается за счёт внедрения внутренних платформ для разработчиков (IDP), интеграции ИИ-ассистентов и расширения парадигмы «Всё как код» (Everything as Code), что позволяет Agile-командам ускорять итерации[34][35].

ArchOps

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

Концепция ArchOps начала формироваться в 2019 году на основе подхода «Архитектура как код» (Architecture as Code, AaC)[37]. Этот подход предполагает описание и управление архитектурой с помощью исполняемого кода, а не только статичных диаграмм[38]. Архитектурные правила, компоненты и их зависимости описываются в коде, что позволяет создавать автоматизированные тесты («фитнес-функции») для непрерывной проверки соответствия реальной кодовой базы запланированной архитектуре. Все артефакты хранятся в системе контроля версий (например, Git), что обеспечивает прозрачность и сокращает разрыв между проектированием и реализацией[39].

В 2020—2021 годах ArchOps начал привлекать внимание в крупных компаниях как набор принципов для управления сложным IT-ландшафтом. Ключевыми идеями стали прозрачность процесса, инкрементальное внедрение архитектурных изменений и налаживание обратной связи между архитекторами и командами разработки, например, через ведение реестра архитектурных решений (Architecture Decision Records, ADR)[40]. На практике это выражалось в создании архитектурных комитетов для контроля соответствия новым решениям, формализации архитектурных решений с помощью моделей, таких как C4 model, и фокусе на интеграции и переиспользуемости сервисов[41][42].

В 2022—2023 годах произошёл переход от теоретических обсуждений к практической реализации и созданию специализированных инструментов. Подход «Архитектура как код» стал основой для встраивания анализа и проектирования решений непосредственно в производственный процесс DevOps[43]. Появились инструменты, такие как DocHub[44] и Seaf Archtool[45], позволяющие описывать архитектуру с помощью файлов на языках Markdown, PlantUML, Mermaid, Swagger и AsyncAPI. Вокруг этих идей начало формироваться профессиональное сообщество, проводились круглые столы и доклады на конференциях, например, на FlowConf 2023[43][46].

К 2024—2025 годам принципы ArchOps интегрировались в более широкие тенденции. Хотя сам термин не стал общеупотребительным, его идеи развиваются в рамках платформенной инженерии, DevSecOps и применения ИИ в операционных процессах (AIOps)[47]. Современные архитектурные практики включают в себя социотехнический подход, где фокус смещается на людей и команды, а роль архитектора трансформируется из принимающего решения в консультанта[48]. Также в архитектурные требования начинают включать аспекты устойчивого развития и «зелёного» ПО, такие как оценка углеродного следа и энергоэффективности решений[48].

Мобильный DevOps

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

В 2019—2020 годах основной фокус в мобильном DevOps был направлен на построение и оптимизацию конвейеров непрерывной интеграции и доставки (CI/CD) для автоматизации процессов сборки, тестирования и развёртывания[50]. В этот период начала формироваться потребность в выделенных специалистах или командах Mobile DevOps, способных решать специфические задачи, такие как оптимизация времени сборки и управление релизами в условиях фрагментации платформ iOS и Android[51]. Одновременно усилилось внимание к интеграции безопасности в жизненный цикл разработки (DevSecOps), хотя внедрение сталкивалось с нехваткой автоматизированных инструментов для тестирования безопасности мобильных приложений[52]. Также началось обсуждение применения искусственного интеллекта (ИИ) для автоматизации более сложных задач[53].

К 2021—2022 годам DevSecOps стал зрелым мейнстримом, а концепция «сдвига влево» (Shift-Left), подразумевающая интеграцию безопасности на самых ранних этапах, стала критически важной[54][55]. Это было обусловлено специфическими рисками мобильных приложений, такими как доступ к чувствительным данным устройства и наличие уязвимостей в сторонних SDK[56]. В этот период выросла популярность облачных CI/CD-платформ, таких как Bitrise и Codemagic, а для бэкенд-сервисов мобильных приложений стали активно применяться бессерверная архитектура и Kubernetes[57].

В 2023—2024 годах развитие мобильного DevOps определялось тремя ключевыми направлениями: DevSecOps, AIOps и платформенная инженерия. Приоритет безопасности стал абсолютным, что было вызвано данными о наличии уязвимостей в 85 % мобильных приложений[58]. В CI/CD-пайплайны начали массово встраивать инструменты автоматизированного тестирования безопасности (MAST), включая статический (SAST) и динамический (DAST) анализ[58]. Искусственный интеллект нашёл практическое применение в интеллектуальном тестировании, предиктивном анализе сбоев и автоматической генерации документации и кода с помощью ассистентов, таких как Gemini Code Assist[59][60]. В ответ на растущую сложность и для снижения когнитивной нагрузки на разработчиков начала формироваться практика платформенной инженерии — создание внутренних платформ для разработчиков (IDP), унифицирующих инструменты для iOS и Android. По прогнозу Gartner, к 2026 году 80 % крупных инжиниринговых организаций будут иметь такие платформенные команды[61]. Несмотря на прогресс, уровень полной автоматизации оставался невысоким: в 2023 году лишь 6,2 % мобильных команд достигли полной автоматизации процесса выпуска приложений[62].

К 2025 году DevSecOps, ИИ и платформенная инженерия окончательно утвердились в качестве стандартов мобильной разработки[63][64]. Зрелые практики автоматизации, такие как GitOps, стали нормой: по данным CNCF за 2024 год, 64 % компаний уже внедрили этот подход[63]. Продолжился рост популярности кроссплатформенных фреймворков, таких как Flutter, React Native и Kotlin Multiplatform, что ставит перед DevOps-инженерами новые задачи по настройке единых пайплайнов для сборки и развёртывания общего и нативного кода[65].

Непрерывная интеграция и доставка (CI/CD)

Автоматизация — важнейший принцип эффективного DevOps, и инструментальные практики CI/CD (Continuous Integration/Continuous Delivery) играют здесь ключевую роль[66]. Углублённое взаимодействие и коммуникация внутри и между командами DevOps позволяет снизить риски и ускорить выход продукта на рынок[67].

Инженерия надёжности сайта (SRE)

В 2003 году компания Google предложила подход site reliability engineering (SRE), направленный на поддержание высокого качества пользовательского опыта при непрерывном внедрении новых функций в крупномасштабных и высокодоступных системах[68]. Несмотря на то, что SRE возник до развития DevOps, оба подхода часто рассматриваются как взаимодополняющие. SRE предлагает конкретные инженерные практики для достижения целей DevOps, решая операционные задачи с помощью разработки программного обеспечения[69].

К 2017 году, после выхода книги Google, ключевые концепции SRE начали получать широкое распространение. Центральными понятиями стали цели уровня обслуживания (SLO), показатели уровня обслуживания (SLI) и бюджеты ошибок (Error Budgets), которые позволили количественно определять надёжность и находить баланс между скоростью разработки и стабильностью сервиса[70]. Важной задачей стала борьба с «рутиной» (toil) — повторяющейся ручной работой. Целевой показатель Google — не более 50 % времени на операционные задачи[71], однако отраслевые отчёты 2020 года показывали, что в реальности инженеры тратили на них до 75 % времени, что указывало на разрыв между идеальной моделью и практикой. В то же время начала активно продвигаться культура разбора инцидентов без поиска виновных (blameless postmortem)[72].

В 2018—2019 годах, с выходом практического руководства «The Site Reliability Workbook», практики SRE начали активно распространяться за пределы технологических гигантов[69]. В этот период фокус сместился на системный подход к анализу сложных отказов, развитие наблюдаемости (observability) и внимание к человеческому фактору, включая борьбу с выгоранием инженеров на дежурствах[72].

Период 2020—2021 годов был отмечен ростом внедрения SRE, отчасти из-за пандемии COVID-19, повысившей значимость цифровых сервисов[73]. Значительно вырос спрос на SRE-специалистов, а их роль в обеспечении безопасности усилилась, особенно после обнаружения уязвимостей, таких как Log4Shell[74].

К 2022—2023 годам SRE утвердился в качестве стратегически важной функции. Основными тенденциями стали активное внедрение AIOps для предиктивного анализа и автоматизации реагирования на инциденты[75], а также становление платформенной инженерии как эволюции SRE и DevOps[76]. По прогнозу Gartner, к 2027 году 75 % крупных предприятий будут использовать практики SRE[75].

В 2024—2025 годах развитие SRE продолжилось под влиянием глубокой интеграции ИИ, проактивной безопасности и облачных технологий[77]. Стандартной практикой для проверки устойчивости систем стала инженерия хаоса (Chaos Engineering)[78], а сама роль SRE-инженера эволюционировала от «тушения пожаров» к архитектуре надёжности, тесно сближаясь с платформенной инженерией[79].

Производственная система Тойоты, бережливое мышление и кайдзен

Производственная система Тойоты (TPS) оказала влияние на развитие принципов непрерывного совершенствования, кайдзен, оптимизации потоков и работы с малыми партиями; эти идеи легли в основу бережливого мышления и соответствующих практик DevOps. Методика формирования быстрой обратной связи и решения проблем (например, andon) также пришла из TPS[80][81].

FinOps и GreenOps

С развитием облачных технологий в методологию DevOps интегрируются новые смежные дисциплины, направленные на обеспечение эффективности и устойчивости создаваемых систем. FinOps (Financial Operations) представляет собой интегрированную в DevOps практику управления облачными финансами и оптимизации затрат[35][34][82]. Она объединяет инженерные, финансовые и бизнес-команды для принятия решений о расходах на основе данных. В рамках DevOps эта дисциплина позволяет контролировать бюджеты, отключать простаивающие ресурсы и обеспечивать рентабельность систем, находя баланс между скоростью разработки, качеством и стоимостью облачных услуг.

GreenOps — концепция снижения углеродного следа и энергопотребления ИТ-инфраструктуры, возникшая на пересечении FinOps, DevOps и принципов устойчивого развития[83][84][82]. Практика направлена на минимизацию воздействия технологий на окружающую среду. В 2026 году GreenOps приобретает стратегическую актуальность: оптимизация вычислительных ресурсов (например, правильный подбор размеров виртуальных машин) позволяет одновременно снижать как финансовые затраты, так и выбросы углекислого газа[34].

DevSecOps

DevSecOps — расширение DevOps, направленное на интеграцию процессов обеспечения безопасности в саму методологию DevOps. В отличие от традиционного подхода с выделенной командой безопасности, DevSecOps предполагает вовлечение всех delivery-команд в обеспечение безопасности поставки ПО; тесты и меры защиты интегрируются с ранних стадий разработки (т. н. «сдвиг влево»). Безопасность обеспечивается по трём ключевым направлениям: статический анализ, анализ компонентного состава и динамическое тестирование.

Статический анализ безопасности приложений (SAST) особенно востребован при проведении белого ящика с разными инструментами для разных языков программирования. Нужно отслеживать open source-компоненты и версии зависимостей на предмет известных уязвимостей, публикуемых CERT и другими экспертными объединениями, а также лицензии библиотек (что особенно важно для copyleft-лицензий) на соответствие лицензии готового продукта.

Динамическое тестирование проводится без знания внутреннего устройства программного обеспечения. В DevSecOps оно реализуется посредством динамического анализа безопасности приложений (DAST) и пентестов: приоритетом является раннее выявление уязвимостей (например, межсайтовый скриптинг, SQL-инъекция и др.). Стандарты угроз формулируются, в частности, OWASP (актуальной версией является OWASP Top 10: 2025)[85].

DevSecOps также трактуется как культурный сдвиг: создание безопасного ПО за счёт интеграции обучения, принципов «security by design» и автоматизации процедур безопасности[86].

Важной частью DevSecOps является обеспечение безопасности цепочки поставок программного обеспечения. Для этого применяются взаимодополняющие стандарты: обязательное использование SBOM (Software Bill of Materials) обеспечивает прозрачность компонентного состава продукта, а фреймворк SLSA (Supply-chain Levels for Software Artifacts) применяется для защиты процесса сборки от несанкционированного вмешательства и обеспечения целостности артефактов[87].[88]

Тенденции развития

К 2024—2025 годам DevSecOps окончательно утвердился как фундаментальный подход к разработке, сместив фокус с простого реагирования на угрозы к их проактивному предотвращению[89]. Основные тенденции сосредоточены на глубокой автоматизации, использовании искусственного интеллекта и защите облачных сред[90].

Ключевыми направлениями развития стали:

  • Искусственный интеллект (ИИ) и машинное обучение (ML). ИИ становится стержнем DevSecOps, применяясь для автоматического обнаружения угроз, предиктивного управления рисками и интеллектуальной автоматизации. Инструменты на базе ИИ способны анализировать большие объёмы данных для выявления аномалий, прогнозировать потенциальные векторы атак и даже автоматически исправлять некоторые уязвимости без вмешательства человека[91][92]. Фокус применения ИИ смещается к предиктивному управлению уязвимостями и автоматической генерации исправлений, вплоть до самостоятельного создания системами запросов на слияние (pull-request) с предлагаемыми фиксами[93].
  • Безопасность цепочек поставок ПО. В ответ на рост атак на цепочки поставок ключевым элементом становится Software Bill of Materials (SBOM) — полный перечень всех компонентов, библиотек и зависимостей, используемых в приложении[94]. Для автоматического сканирования зависимостей на наличие уязвимостей и проверки лицензионной чистоты активно используются инструменты анализа состава программного обеспечения (SCA)[95].
  • Гиперавтоматизация безопасности в CI/CD. Происходит переход к гиперавтоматизации, когда сложные и рутинные процессы, такие как сканирование секретов, проверка на соответствие нормативным требованиям (compliance) и укрепление безопасности контейнеров, полностью автоматизируются в конвейере CI/CD[96].
  • Безопасность облачно-нативных технологий. Фокус смещается на защиту контейнеров, микросервисов и бессерверных вычислений. Особое внимание уделяется безопасности управления инфраструктурой как кодом (IaC Security) и обеспечению сквозной видимости в мультиоблачных и гибридных средах[89].
  • Культурная трансформация. Подход «сдвиг влево» (Shift-Left Security), подразумевающий интеграцию безопасности на самых ранних этапах разработки, становится мейнстримом[97]. Безопасность становится общей ответственностью команд разработки, эксплуатации и ИБ, что требует непрерывного обучения разработчиков практикам безопасного кодирования[89][97].
  • Ужесточение регуляторных требований. В 2025—2026 годах вступление в силу новых нормативных актов делает внедрение практик DevSecOps фактически обязательным условием для разработки. В Европейском союзе ключевое влияние оказывают регламенты CRA (Cyber Resilience Act) и DORA (Digital Operational Resilience Act), а в России — приказ ФСТЭК № 117, закрепляющий требования к непрерывному циклу защиты и оперативному устранению уязвимостей[98].[99][100]
  • Комплаенс как код (Compliance as Code, CaC). Для автоматизации проверок на соответствие нормам и стандартам требования комплаенса преобразуются в исполняемый код (Policy as Code). Это позволяет встраивать непрерывный аудит непосредственно в конвейеры CI/CD, автоматически валидируя каждое изменение и предотвращая развёртывание при нарушении политик безопасности[101].[102]

Культурные изменения

Внедрение DevOps приводит к существенным сдвигам организационной культуры, меняя способы взаимодействия разработчиков, ИТ-операторов и специалистов по тестированию[103][104]. Согласованная работа этих групп является критическим вызовом при массовом внедрении DevOps на уровне крупных компаний[105]. DevOps связан не только с инструментами, но и с формированием новой культуры организации работы.

Микросервисы

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

Автоматизация DevOps

Стандартизация процессов внутри организации поддерживает согласованность, надёжность и эффективность и часто обеспечивается совместным использованием репозитория исходного кода и систем контроля версий. Исследователь Рави Теджа Ярлагадда отмечает: «DevOps подразумевает, что все бизнес-функции осуществляются, контролируются и управляются из единого центра с помощью кода»[107].

Концепция «Всё как код» (Everything as Code, EaC) эволюционирует, выходя за рамки управления инфраструктурой. Основной фокус смещается к созданию централизованных платформ, абстрагирующих сложность и повышающих продуктивность разработчиков. Доминирующим подходом становится платформенная инженерия (Platform Engineering), в рамках которой создаются внутренние платформы для разработчиков (Internal Developer Platforms, IDP). Они предоставляют стандартизированные инструменты и сервисы через интерфейс самообслуживания, позволяя централизовать управление сложностью и лучшие практики[34].[108][109]

Значимую роль в автоматизации также играют No-code и Low-code платформы, ускоряющие доставку программного обеспечения и снижающие порог входа для настройки процессов. Они способствуют стандартизации за счёт готовых шаблонов и встроенных политик безопасности, формируя «золотые пути» (golden paths) для развёртывания приложений. Несмотря на эти преимущества, использование подобных инструментов сопряжено с рисками зависимости от поставщика (vendor lock-in) и ограничением гибкости, из-за чего они всё чаще становятся частью управляемой среды в рамках платформенной инженерии[110].[111][109]

Автоматизация с помощью системы управления версиями

Многие организации применяют системы контроля версий, виртуализацию, контейнеризацию и инструменты CI/CD для автоматизации процессов DevOps. В исследовании по разработке цепочки инструментов DevOps отмечается: «Всем разработчикам необходимо работать с общей кодовой базой, иногда даже редактировать одни и те же файлы, поэтому система должна помогать избегать конфликтов и отслеживать историю изменений». В качестве примера приводятся Git и платформа GitHub[112].

Новое поколение инструментов на базе искусственного интеллекта (таких как GitHub Copilot, Claude и Amazon Q Developer) применяется для автоматизации рутинных задач, генерации кода и проверки соответствия стандартам непосредственно в среде разработки и процессах CI/CD[113].

Платформенная инженерия

Платформенная инженерия (Platform Engineering) представляет собой эволюционное развитие методологии DevOps, направленное на решение проблем её масштабирования[109].[114][115] Традиционный подход DevOps по мере роста компании часто приводит к увеличению когнитивной нагрузки на разработчиков, вынужденных самостоятельно управлять сложной инфраструктурой[116].[117] Для решения этой проблемы формируются специализированные платформенные команды, которые создают внутренние платформы для разработчиков (Internal Developer Platforms, IDP). Такие платформы абстрагируют сложность базовой инфраструктуры и предоставляют продуктовым командам инструменты самообслуживания, а также заранее настроенные стандартизированные шаблоны для выполнения типовых задач — так называемые «золотые пути» (golden paths). Подобный подход позволяет разработчикам сосредоточиться на написании кода, что существенно снижает их когнитивную нагрузку и повышает общую продуктивность[118].[119]

AIOps

AIOps (Искусственный интеллект для ИТ-операций) — методология, выступающая ключевым компонентом современного DevOps для предиктивного анализа инцидентов. Основная цель подхода заключается в смещении фокуса с реактивного устранения сбоев на их проактивное предотвращение[120].[121]

Платформы AIOps используют модели машинного обучения для непрерывного анализа больших объёмов данных (логов, метрик и трассировок) из различных компонентов ИТ-инфраструктуры[122]. Ключевые возможности применения ИИ в ИТ-операциях включают:

  • Обнаружение аномалий: выявление нестандартного поведения системы, указывающего на скрытые проблемы[123].
  • Прогнозирование сбоев: предиктивная аналитика на основе исторических данных, позволяющая предсказывать будущие инциденты до того, как они повлияют на пользователей[124].
  • Снижение «шума» оповещений: фильтрация, корреляция и группировка событий для быстрого определения первопричины проблемы.
  • Автоматическое реагирование (self-healing): способность систем самостоятельно выполнять действия по устранению проблем, такие как перезапуск сервисов, перераспределение нагрузки или автоматический откат нестабильных обновлений[120].

GitOps

GitOps — развитие DevOps, при котором состояние конфигурации среды развёртывания отслеживается с помощью системы контроля версий, чаще всего Git. Практика GitOps связана с тем, что любые изменения кода и инфраструктуры фиксируются, проходят ревью и могут быть «откатаны» при необходимости. Как отмечает Red Hat, прозрачность изменений резко повышает безопасность и контролируемость процессов[125].

Проект OpenGitOps, являющийся частью CNCF, определяет методологию через четыре основополагающих принципа:[126]

  • Декларативность: состояние всей системы должно быть описано декларативно.
  • Версионируемость и неизменяемость: желаемое состояние хранится в системе контроля версий, что обеспечивает полный аудиторский след и возможность отката изменений.
  • Автоматическое извлечение (Pull): специализированные программные агенты автоматически извлекают декларации желаемого состояния из источника.
  • Непрерывная сверка (Reconciliation): программные агенты постоянно отслеживают фактическое состояние системы и приводят его в соответствие с желаемым состоянием.

Развитие подходов к хранению конфигураций привело к использованию OCI-артефактов (Open Container Initiative) в качестве источника истины для развёртывания. OCI-совместимые реестры применяются для хранения и версионирования конфигурационных артефактов, таких как манифесты Kubernetes и Helm-чарты. Это позволяет унифицировать инфраструктуру хранения, повысить безопасность за счёт криптографической верификации манифестов и улучшить эффективность распространения конфигураций. В этой модели Git остаётся системой для совместной разработки (авторинга), а OCI-реестр служит источником истины для автоматизированных агентов[127].

Сфера применения GitOps также расширилась на управление Edge-инфраструктурой (периферийными вычислениями) и Интернетом вещей (IoT). Для управления распределёнными средами с большим количеством устройств применяется архитектура «Hub-and-Spoke», где центральный узел взаимодействует с агентами на периферийных устройствах. Pull-модель GitOps позволяет эффективно решать проблемы масштабирования и нестабильного сетевого подключения, так как агенты на устройствах самостоятельно запрашивают обновления из репозитория[128].

Тенденции развития

К 2026 году GitOps утвердился в качестве стандартной методологии для управления инфраструктурой и приложениями, став «новой нормой» в облачно-нативных средах[129][130]. Согласно опросу CNCF за 2025 год, 77 % респондентов в той или иной степени внедрили методологию GitOps[131]. Основными причинами для перехода на GitOps компании назвали ускорение доставки программного обеспечения, улучшенное управление конфигурациями и повышение согласованности развёртываний[132].

Ключевыми тенденциями стали глубокая интеграция с искусственным интеллектом, усиление фокуса на безопасности и становление в качестве основы для платформенной инженерии[133]. ИИ применяется для интеллектуальной автоматизации рабочих процессов (AI-Powered GitOps), включая использование инструментов для автоматизации ревью кода и валидации манифестов Kubernetes перед их применением, а также предиктивный анализ инцидентов[134][133][135]. В области безопасности GitOps способствует внедрению практик DevSecOps, поскольку все изменения в конфигурации отслеживаются, проходят аудит и контролируются через Git, что обеспечивает прозрачность и позволяет легко отслеживать, кто, когда и почему внёс изменения[136]. Кроме того, GitOps становится ключевым элементом внутренних платформ для разработчиков (IDP), позволяя им управлять инфраструктурой и развёртываниями через привычные инструменты[133]. Ключевыми инструментами для реализации GitOps остаются проекты CNCF, такие как Argo CD и Flux CD[129].

Оба ведущих инструмента для реализации GitOps имеют статус «Graduated» от CNCF и продолжают активно развиваться: актуальной версией Argo CD является 3.4, а Flux CD — 2.8[137][138].

GitOps всё чаще интегрируется во внутренние платформы для разработчиков (IDP) в качестве скрытого механизма синхронизации («под капотом»). В этой модели разработчики взаимодействуют с интерфейсом самообслуживания IDP, который автоматически генерирует декларативные конфигурации и сохраняет их в Git-репозиторий. Затем специализированные GitOps-агенты непрерывно отслеживают состояние репозитория и синхронизируют утверждённые изменения с целевой инфраструктурой, снижая когнитивную нагрузку на команды разработки[139].

Примечания

  1. ↑ Meredith Courtemanche, Emily Mell, Alexander S. Gills. What Is DevOps? The Ultimate Guide (англ.). TechTarget (22 января 2023). Дата обращения: 28 мая 2026. Архивировано 22 января 2023 года.
  2. ↑ Dyck, Andrej; Penners, Ralf; Lichter, Horst (19 мая 2015). “Towards Definitions for Release Engineering and DevOps”. Proceedings of the 2015 IEEE/ACM 3rd International Workshop on Release Engineering. IEEE: 3. DOI:10.1109/RELENG.2015.10. ISBN 978-1-4673-7070-7. Дата обращения 2024-05-01. |access-date= требует |url= (справка)
  3. ↑ DevOps in 2026: What it really means now and where it's heading fast. dev.to. Дата обращения: 28 мая 2026.
  4. ↑ Chapman, M., Gatti, N: A model of a service life cycle, Proceedings of TINA '93, pp. I-205–I-215, сентябрь 1993.
  5. ↑ History of DevOps (англ.). Atlassian (16 февраля 2023). Дата обращения: 28 мая 2026. Архивировано 16 февраля 2023 года.
  6. ↑ Steve Mezak. The Origins of DevOps: What's in a Name? devops.com (25 января 2018). Дата обращения: 28 мая 2026. Архивировано 24 февраля 2023 года.
  7. ↑ Patrick Debois. Agile 2008 Toronto. Just Enough Documented Information (9 октября 2008). Дата обращения: 28 мая 2026. Архивировано 26 ноября 2021 года.
  8. ↑ Puppet – Alanna Brown. Puppet Labs. Дата обращения: 28 мая 2026. Архивировано 17 декабря 2019 года.
  9. ↑ 1 2 Crispin, Lisa. More Agile Testing / Lisa Crispin, Janet Gregory. — Addison-Wesley, 2014. — ISBN 9780133749571.
  10. ↑ Cliff Saran. Software engineers worry about speaking out - Computer Weekly (англ.), ComputerWeekly.com. Архивировано 24 декабря 2023 года. Дата обращения: 28 мая 2026.
  11. ↑ 75% of software engineers faced retaliation the last time they reported wrongdoing - ETHRWorldSEA (англ.), ETHRWorld.com. Архивировано 13 марта 2024 года. Дата обращения: 28 мая 2026.
  12. ↑ Annual 'State of DevOps' Report Cites Leadership, Automation. ADTmag (6 июня 2017). Дата обращения: 28 мая 2026. Архивировано 18 июня 2025 года.
  13. ↑ 2017 State of DevOps Report. DORA, Puppet (2017). Дата обращения: 28 мая 2026.
  14. ↑ 1 2 Accelerate: State of DevOps 2018. DORA, Google Cloud (2018). Дата обращения: 28 мая 2026. Архивировано 18 мая 2025 года.
  15. ↑ The 2018 State of DevOps Reports. DZone (19 сентября 2018). Дата обращения: 28 мая 2026. Архивировано 14 июня 2025 года.
  16. ↑ The 2019 Accelerate State of DevOps: Elite performance, productivity, and scaling. Google Cloud Blog (22 августа 2019). Дата обращения: 28 мая 2026.
  17. ↑ 2019 State of DevOps Report Reveals Shifting Security Left is Foundational to Unlocking Speed and Stability. Perforce (9 октября 2019). Дата обращения: 28 мая 2026. Архивировано 20 июня 2025 года.
  18. ↑ 2020 research program. DORA. Дата обращения: 28 мая 2026. Архивировано 25 сентября 2025 года.
  19. ↑ Accelerate State of DevOps 2021. DORA, Google Cloud (2021). Дата обращения: 28 мая 2026.
  20. ↑ DORA's 2021 State of DevOps report: 'Elite' performers now 26% of the total. The Register (23 сентября 2021). Дата обращения: 28 мая 2026. Архивировано 29 апреля 2025 года.
  21. ↑ Announcing DORA 2021 Accelerate State of DevOps Report. Google Cloud Blog (14 сентября 2021). Дата обращения: 28 мая 2026.
  22. ↑ 2022 Accelerate State of DevOps Report. DORA, Google Cloud (2022). Дата обращения: 28 мая 2026. Архивировано 10 сентября 2025 года.
  23. ↑ New DevOps performance clusters in the 2022 DORA report. Octopus Deploy (29 сентября 2022). Дата обращения: 28 мая 2026. Архивировано 5 августа 2025 года.
  24. ↑ State of DevOps report 2022: for secure software, team culture counts more than technology. DevClass (6 октября 2022). Дата обращения: 28 мая 2026. Архивировано 25 января 2025 года.
  25. ↑ 1 2 Announcing the 2023 State of DevOps report. Google Cloud Blog (10 октября 2023). Дата обращения: 28 мая 2026.
  26. ↑ 2024 Accelerate State of DevOps Report. DORA, Google Cloud. Дата обращения: 28 мая 2026. Архивировано 14 августа 2025 года.
  27. ↑ The 2024 State of DevOps Report: The Evolution of Platform Engineering. Puppet (25 июня 2024). Дата обращения: 28 мая 2026. Архивировано 3 августа 2025 года.
  28. ↑ Опубликованы данные исследования State of DevOps Russia 2024. CNews (10 сентября 2024). Дата обращения: 3 ноября 2025. Архивировано 18 января 2025 года.
  29. ↑ 2025 State of AI-Assisted Software Development. Google Cloud. Дата обращения: 28 мая 2026.
  30. ↑ DORA 2025: The State of AI-Assisted Software Development. Splunk. Дата обращения: 28 мая 2026.
  31. ↑ State of DevOps Report 2026. Perforce. Дата обращения: 28 мая 2026.
  32. ↑ Tom Geraghty. The History and Evolution of DevOps (англ.) (5 июля 2020). Дата обращения: 28 мая 2026. Архивировано 1 декабря 2020 года.
  33. ↑ Principles behind the Agile Manifesto. agilemanifesto.org. Дата обращения: 28 мая 2026. Архивировано 7 декабря 2020 года.
  34. ↑ 1 2 3 4 Тенденции в разработке программного обеспечения и DevOps в 2026 году. DST Global. Дата обращения: 28 мая 2026.
  35. ↑ 1 2 Roadmap DevOps-инженера в 2026 году: что учить и в каком порядке. Tproger. Дата обращения: 28 мая 2026.
  36. ↑ Castellanos, Camilo. Executing Architectural Models for Big Data Analytics // Software Architecture / Camilo Castellanos, Dario Correal. — 15 сентября 2018. — Vol. 11048. — P. 364-371. — ISBN 978-3-030-00760-7. — doi:10.1007/978-3-030-00761-4_24.
  37. ↑ Эффективность подхода «архитектура как код» в управлении ИТ-архитектурой предприятия. Cyberleninka (2024). Дата обращения: 3 ноября 2025.
  38. ↑ Architecture as a Code. Mikhail Smirnov's blog (6 июня 2019). Дата обращения: 28 мая 2026. Архивировано 19 июня 2025 года.
  39. ↑ Is Architecture-as-Code the Future of Software Design? Architecture & Governance Magazine. Дата обращения: 28 мая 2026. Архивировано 23 января 2025 года.
  40. ↑ Эволюция ИТ: от строительства к реформам. mkomov.com (2023). Дата обращения: 28 мая 2026. Архивировано 17 мая 2025 года.
  41. ↑ ArchOps: как мы ускоряем цифровую трансформацию. Habr (23 ноября 2021). Дата обращения: 28 мая 2026.
  42. ↑ Arch Ops. Процесс архитектурного надзора в Positive Technologies (pdf). Positive Technologies (2021). Дата обращения: 28 мая 2026.
  43. ↑ 1 2 Архитектура как код: от теории к инструментам. Habr (1 февраля 2023). Дата обращения: 28 мая 2026.
  44. ↑ DocHub. GitHub. Дата обращения: 28 мая 2026. Архивировано 27 декабря 2024 года.
  45. ↑ Seaf Archtool. GitVerse. Дата обращения: 3 ноября 2025. Архивировано 21 сентября 2025 года.
  46. ↑ Как мы делали доклад про «Архитектуру как код» для FlowConf 2023. Habr (7 ноября 2023). Дата обращения: 28 мая 2026.
  47. ↑ 8 Key DevOps Trends Shaping the Industry in 2024. DevOps Demystified (2024). Дата обращения: 28 мая 2026.
  48. ↑ 1 2 Тренды архитектуры ПО в 2025 году. Habr (25 июня 2025). Дата обращения: 28 мая 2026.
  49. ↑ Tak, Rohin. Mobile DevOps: Deliver continuous integration and deployment within your mobile applications / Rohin Tak, Jhalak Modi. — Packt Publishing, 2018. — P. 12-18. — ISBN 9781788296243.
  50. ↑ Мобильный DevOps: как ускорить и автоматизировать разработку приложений. Infoshell. Дата обращения: 3 ноября 2025. Архивировано 9 сентября 2025 года.
  51. ↑ Mobile DevOps в большой компании. Habr (21 декабря 2020). Дата обращения: 28 мая 2026.
  52. ↑ The State of Mobile DevSecOps 2019 (pdf). NowSecure. Дата обращения: 28 мая 2026.
  53. ↑ 5 DevOps Trends That You Can Count On In 2019 and Beyond. Daffodil Software. Дата обращения: 28 мая 2026. Архивировано 14 мая 2025 года.
  54. ↑ DevSecOps: Security in mobile CI/CD. Bitrise (21 сентября 2021). Дата обращения: 28 мая 2026. Архивировано 1 февраля 2023 года.
  55. ↑ Transform Mobile DevOps into Mobile DevSecOps. DevOps.com (16 ноября 2021). Дата обращения: 28 мая 2026. Архивировано 20 августа 2022 года.
  56. ↑ DevSecOps for Mobile: Why It's Different and How to Get It Right. DevOps Digest (17 мая 2022). Дата обращения: 28 мая 2026. Архивировано 12 августа 2025 года.
  57. ↑ CI/CD для мобильной разработки в 2023 году. Habr (21 декабря 2022). Дата обращения: 28 мая 2026.
  58. ↑ 1 2 How to Introduce DevSecOps Practices Into a Mobile CI/CD Pipeline. NowSecure (1 февраля 2023). Дата обращения: 28 мая 2026. Архивировано 13 марта 2025 года.
  59. ↑ How to leverage generative AI in mobile DevOps. Novoda (7 июня 2023). Дата обращения: 28 мая 2026. Архивировано 13 августа 2025 года.
  60. ↑ Boost your continuous delivery pipeline with generative AI. Google Cloud Blog (9 апреля 2024). Дата обращения: 28 мая 2026.
  61. ↑ The Intertwined Worlds of Platform and Mobile App Engineering. The New Stack (13 мая 2024). Дата обращения: 28 мая 2026.
  62. ↑ Mobile DevOps Assessment 2023. Bitrise. Дата обращения: 28 мая 2026. Архивировано 26 апреля 2025 года.
  63. ↑ 1 2 DevOps-тренды 2025: 8 ключевых изменений, которые нельзя игнорировать. Adpass (16 сентября 2024). Дата обращения: 3 ноября 2025. Архивировано 10 августа 2025 года.
  64. ↑ Тренды DevOps в 2025 году. Habr (27 февраля 2025). Дата обращения: 28 мая 2026.
  65. ↑ DevOps in Mobile App Development: Trends to Watch in 2025. Codora. Дата обращения: 28 мая 2026. Архивировано 8 июля 2025 года.
  66. ↑ Humble, Jez. Continuous Delivery: reliable software releases through build, test, and deployment automation / Jez Humble, David Farley. — Pearson Education Inc., 2011. — ISBN 978-0-321-60191-9.
  67. ↑ Chen, Lianping (2015). “Continuous Delivery: Huge Benefits, but Challenges Too”. IEEE Software. 32 (2): 50–54. DOI:10.1109/MS.2015.27.
  68. ↑ Beyer, Betsy. Site Reliability Engineering / Betsy Beyer, Chris Jones, Jennifer Petoff … [и др.]. — O'Reilly Media, 2016. — ISBN 978-1-4919-2909-4.
  69. ↑ 1 2 State of DevOps and SRE 2018. Enabling Team. Дата обращения: 28 мая 2026. Архивировано 30 апреля 2025 года.
  70. ↑ Embracing Risk. Google. Дата обращения: 28 мая 2026. Архивировано 8 декабря 2020 года.
  71. ↑ Dealing with Overload. Google. Дата обращения: 28 мая 2026. Архивировано 29 сентября 2025 года.
  72. ↑ 1 2 Nick Groenen. SREcon19 EMEA notes. Дата обращения: 28 мая 2026. Архивировано 10 декабря 2023 года.
  73. ↑ Site Reliability Engineering. Надежность и безотказность как в Google. Читай-город. Дата обращения: 3 ноября 2025.
  74. ↑ 2022 State of SRE Report Reveals Organizations Are Investing More in Site Reliability Engineering. Dynatrace (28 сентября 2022). Дата обращения: 28 мая 2026. Архивировано 23 мая 2025 года.
  75. ↑ 1 2 AIOps, ML, and SRE: The Future of IT Operations. Algomox. Дата обращения: 28 мая 2026.
  76. ↑ Платформенная инженерия: следующий этап эволюции DevOps и SRE. Habr (26 сентября 2024). Дата обращения: 28 мая 2026.
  77. ↑ Top 5 Site Reliability Engineering Future Trends in 2025. Visualpath. Дата обращения: 28 мая 2026.
  78. ↑ The SRE Report 2025. Enabling Team. Дата обращения: 28 мая 2026.
  79. ↑ The Future of the SRE Role: AI, Automation, and Beyond in 2025. Visualpath. Дата обращения: 28 мая 2026.
  80. ↑ Brent Aaron Reed, Willy Schaub. Analyzing the DNA of DevOps (14 ноября 2018). Дата обращения: 28 мая 2026. Архивировано 28 ноября 2023 года.
  81. ↑ Kim, Gene. The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations / Gene Kim, Patrick Debois, John Willis … [и др.]. — 2016. — ISBN 9781942788003.
  82. ↑ 1 2 GreenOps and FinOps: The Perfect Match for Cloud Optimization. mia-platform.eu. Дата обращения: 28 мая 2026.
  83. ↑ GreenOps — концепция, возникшая на пересечении FinOps, устойчивого развития (sustainability) и DevOps. Habr. Дата обращения: 28 мая 2026.
  84. ↑ GreenOps v FinOps: What's the Difference? hyperglance.com. Дата обращения: 28 мая 2026.
  85. ↑ OWASP Top 10: 2025 (англ.). OWASP Foundation. Дата обращения: 28 мая 2026.
  86. ↑ Wilson, Glenn. DevSecOps: A leader's guide to producing secure software with compromising flow, feedback and continuous improvement. — Rethink Press, 2020. — ISBN 978-1781335024.
  87. ↑ SBOM Compliance. SBOMify. Дата обращения: 28 мая 2026.
  88. ↑ SLSA: Supply-chain Levels for Software Artifacts. slsa.dev. Дата обращения: 28 мая 2026.
  89. ↑ 1 2 3 Будущее DevSecOps: ключевые тренды и вызовы на 2025 год. Adpass. Дата обращения: 3 ноября 2025.
  90. ↑ Тренды DevSecOps 2024: как эффективно защитить разработку. Swordfish Security. Дата обращения: 3 ноября 2025. Архивировано 6 сентября 2025 года.
  91. ↑ 2025 DevSecOps Predictions - Part 1. DevOps Digest. Дата обращения: 28 мая 2026. Архивировано 17 января 2025 года.
  92. ↑ Top 5 DevSecOps Trends in 2024. BuildPiper. Дата обращения: 28 мая 2026. Архивировано 3 августа 2025 года.
  93. ↑ Revolutionizing DevSecOps: How AI is Reshaping Software Security. dev.to. Дата обращения: 28 мая 2026.
  94. ↑ The future of DevSecOps: Emerging trends for 2024. Istari. Дата обращения: 28 мая 2026. Архивировано 14 мая 2025 года.
  95. ↑ Key DevSecOps Trends to Shape the Future of Software Development. TechAhead. Дата обращения: 28 мая 2026. Архивировано 15 августа 2025 года.
  96. ↑ DevSecOps Trends: The Future of Secure Software Development. Your Sky Blue. Дата обращения: 28 мая 2026. Архивировано 9 августа 2025 года.
  97. ↑ 1 2 Top 10 Trends Driving DevSecOps Adoption in 2024. Rinf.tech. Дата обращения: 28 мая 2026. Архивировано 29 апреля 2025 года.
  98. ↑ Cyber Resilience Act: summary. European Commission. Дата обращения: 28 мая 2026.
  99. ↑ Compliance as Code Developer Guide. Orbiq. Дата обращения: 28 мая 2026.
  100. ↑ Соображения высшего порядка. IT-Право. Дата обращения: 28 мая 2026.
  101. ↑ Application Security Trends in 2026. OX Security. Дата обращения: 28 мая 2026.
  102. ↑ DevSecOps Best Practices 2026. Miracl. Дата обращения: 28 мая 2026.
  103. ↑ 'Emerging Technology Analysis: DevOps a Culture Shift, Not a Technology', Gartner. 
  104. ↑ Mike Loukides. What is DevOps? O'Reilly Media (7 июня 2012). Дата обращения: 28 мая 2026. Архивировано 25 мая 2019 года.
  105. ↑ Jones, Stephen. Proceedings of the 2nd International Workshop on Quality-Aware DevOps – QUDOS 2016 / Stephen Jones, Joost Noppen, Fiona Lettice. — 21 июля 2016. — P. 7-11. — ISBN 9781450344111. — doi:10.1145/2945408.2945410.
  106. ↑ Chen, Lianping; Babar, Muhammad Ali (2014). “Towards an Evidence-Based Understanding of Emergence of Architecture through Continuous Refactoring in Agile Software Development”. The 11th Working IEEE/IFIP Conference on Software Architecture(WICSA 2014). 2014 IEEE/IFIP Conference on Software Architecture. IEEE. pp. 195–204. DOI:10.1109/WICSA.2014.45. ISBN 978-1-4799-3412-6.
  107. ↑ DevOps and Its Practices by Ravi Teja Yarlagadda :: SSRN. Дата обращения: 24 апреля 2024. Архивировано 15 апреля 2024 года.
  108. ↑ DevOps-инженер 2026: что учить, чтобы не остаться без работы. Хабр Карьера. Дата обращения: 28 мая 2026.
  109. ↑ 1 2 3 Platform engineering vs. DevOps: What's the difference? Google Cloud. Дата обращения: 28 мая 2026.
  110. ↑ No-code и Low-code: преимущества и недостатки. kokoc.com. Дата обращения: 28 мая 2026.
  111. ↑ Understanding Low-Code No-Code Development. Codewave. Дата обращения: 28 мая 2026.
  112. ↑ DevOps: development of a toolchain in the banking domain (лауреатский). Politecnico di Torino. 16 апреля 2021. Архивировано из оригинала 2021-08-16. Дата обращения 2026-05-28. Используется устаревший параметр |url-status= (справка)
  113. ↑ AI Tools for DevOps 2026. Cloud4U (2026). Дата обращения: 28 мая 2026.
  114. ↑ Platform engineering becomes mandatory: The new DevOps standard. platformengineering.com. Дата обращения: 28 мая 2026.
  115. ↑ DevOps vs Platform Engineering in 2026. dev.to. Дата обращения: 28 мая 2026.
  116. ↑ Platform Engineering. Gartner. Дата обращения: 28 мая 2026.
  117. ↑ DevOps повзрослел: почему роль DevOps-инженера трансформируется в Platform-инженера. Habr. Дата обращения: 28 мая 2026.
  118. ↑ What is an Internal Developer Platform (IDP)? IBM. Дата обращения: 28 мая 2026.
  119. ↑ Платформенная инженерия: эволюция DevOps. IT Week. Дата обращения: 28 мая 2026.
  120. ↑ 1 2 AI-Driven DevOps & Infrastructure Automation 2026. Geeks Solutions. Дата обращения: 28 мая 2026.
  121. ↑ AIOps: что это такое? Kurshub. Дата обращения: 28 мая 2026.
  122. ↑ Что такое AIOps? AWS. Дата обращения: 28 мая 2026.
  123. ↑ AI-Driven DevOps на практике: инструменты, которые уже меняют разработку. Adpass. Дата обращения: 28 мая 2026.
  124. ↑ AIOps: Искусственный интеллект на страже производительности высоконагруженных систем. andreyex.ru. Дата обращения: 28 мая 2026.
  125. ↑ What is GitOps? (англ.). www.redhat.com. Дата обращения: 28 мая 2026. Архивировано 30 марта 2023 года.
  126. ↑ GitOps in 2026: Why It's the Gold Standard for Modern Platform Engineering. rightdevops.com. Дата обращения: 28 мая 2026.
  127. ↑ GitOps with OCI artifacts and Config Sync. Google Cloud Blog. Дата обращения: 28 мая 2026.
  128. ↑ Edge Orchestration in 2026: How Enterprises Are Managing Thousands of Distributed Devices Efficiently. itbusinesstoday.com. Дата обращения: 28 мая 2026.
  129. ↑ 1 2 Тренды DevOps 2025. Evrone. Дата обращения: 3 ноября 2025. Архивировано 14 июня 2025 года.
  130. ↑ GitOps in 2025: From old-school updates to the modern way. CNCF (9 июня 2025). Дата обращения: 28 мая 2026. Архивировано 30 сентября 2025 года.
  131. ↑ CNCF Survey Reveals Widespread Kubernetes Adoption, Growing Reliance on Cloud Native Technologies. SC World. Дата обращения: 28 мая 2026.
  132. ↑ New CNCF Survey Highlights GitOps Adoption Trends: 91% of Respondents Are Already Onboard! Codefresh. Дата обращения: 28 мая 2026. Архивировано 23 сентября 2025 года.
  133. ↑ 1 2 3 Тренды DevOps и Kubernetes в 2025 году: хайп и реальность. Deckhouse. Дата обращения: 3 ноября 2025.
  134. ↑ AI-Powered GitOps. SlapTIJack. Дата обращения: 28 мая 2026. Архивировано 27 апреля 2025 года.
  135. ↑ Top 10 DevOps Tools You Need to Learn in 2026. Credo Systemz. Дата обращения: 28 мая 2026.
  136. ↑ Why GitOps Might Be the Future of DevOps: Trends and Predictions for 2025 and Beyond. DevOps.com. Дата обращения: 28 мая 2026. Архивировано 19 мая 2025 года.
  137. ↑ Argo CD. End of Life. Дата обращения: 28 мая 2026.
  138. ↑ Flux v2.8.0 released. Flux CD Blog (февраль 2026). Дата обращения: 28 мая 2026.
  139. ↑ Scale GitOps in the enterprise with an IDP. Humanitec. Дата обращения: 28 мая 2026.

Литература

Категории