DevOps

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Динамическое тестирование проводится без знания внутреннего устройства программного обеспечения. В DevSecOps оно реализуется посредством динамического анализа безопасности приложений (DAST) и пентестов: приоритетом является раннее выявление уязвимостей (например, siteler arası betik çalıştırma, SQL-инъекция и др.). Стандарты угроз формулируются, в частности, OWASP (например, TOP10)^[85].

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

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

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

• Искусственный интеллект (ИИ) и машинное обучение (ML). ИИ становится стержнем DevSecOps, применяясь для автоматического обнаружения угроз, предиктивного управления рисками и интеллектуальной автоматизации. Инструменты на базе ИИ способны анализировать большие объёмы данных для выявления аномалий, прогнозировать потенциальные векторы атак и даже автоматически исправлять некоторые уязвимости без вмешательства человека^[89][90].
• Безопасность цепочек поставок ПО. В ответ на рост атак на цепочки поставок ключевым элементом становится Software Bill of Materials (SBOM) — полный перечень всех компонентов, библиотек и зависимостей, используемых в приложении^[91]. Для автоматического сканирования зависимостей на наличие уязвимостей и проверки лицензионной чистоты активно используются инструменты анализа состава программного обеспечения (SCA)^[92].
• Гиперавтоматизация безопасности в CI/CD. Происходит переход к гиперавтоматизации, когда сложные и рутинные процессы, такие как сканирование секретов, проверка на соответствие нормативным требованиям (compliance) и укрепление безопасности контейнеров, полностью автоматизируются в конвейере CI/CD^[93].
• Безопасность облачно-нативных технологий. Фокус смещается на защиту контейнеров, микросервисов и бессерверных вычислений. Особое внимание уделяется безопасности управления инфраструктурой как кодом (IaC Security) и обеспечению сквозной видимости в мультиоблачных и гибридных средах^[87].
• Культурная трансформация. Подход «сдвиг влево» (Shift-Left Security), подразумевающий интеграцию безопасности на самых ранних этапах разработки, становится мейнстримом^[94]. Безопасность становится общей ответственностью команд разработки, эксплуатации и ИБ, что требует непрерывного обучения разработчиков практикам безопасного кодирования^[87][94].

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

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

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

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

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

К 2025 году GitOps утвердился в качестве стандартной методологии для управления инфраструктурой и приложениями, став «новой нормой» в облачно-нативных средах^[102][103]. Согласно опросу CNCF, проведённому в 2024 году, 64 % компаний уже внедрили GitOps, а 81 % из них отметили рост надёжности инфраструктуры^[102]. Основными причинами для перехода на GitOps компании назвали ускорение доставки программного обеспечения, улучшенное управление конфигурациями и повышение согласованности развёртываний^[104].

Ключевыми тенденциями 2024—2025 годов стали глубокая интеграция с искусственным интеллектом, усиление фокуса на безопасности и становление в качестве основы для платформенной инженерии^[105]. ИИ применяется для интеллектуальной автоматизации рабочих процессов (AI-Powered GitOps), включая автоматизацию ревью кода, проверку манифестов Kubernetes и предиктивный анализ инцидентов^[106][105]. В области безопасности GitOps способствует внедрению практик DevSecOps, поскольку все изменения в конфигурации отслеживаются, проходят аудит и контролируются через Git, что обеспечивает прозрачность и позволяет легко отслеживать, кто, когда и почему внёс изменения^[107]. Кроме того, GitOps становится ключевым элементом внутренних платформ для разработчиков (IDP), позволяя им управлять инфраструктурой и развёртываниями через привычные инструменты^[105]. Ключевыми инструментами для реализации GitOps остаются проекты CNCF, такие как Argo CD и Flux CD^[102].