DevOps и DevSecOps: как доставить ценность быстро и безопасно

Представьте мир, в котором владельцы продукта, разработчики, специалисты QA, ИТ и информационной безопасности работают вместе – не только помогая друг другу, но и обеспечивая успех всей организации.

Сотрудничая ради общей цели, эти специалисты обеспечивают быстрый поток доставки запланированных результатов работ в производственную среду, при сохранении высоких стандартов стабильности, надежности, доступности и безопасности. [1].

DevOps Handbook

Что такое DevOps?

Определение

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

DevOps входит в компетенцию Agile Доставка Продукта (Agile Product Delivery) и объединяет понятия development (разработка) и operations (эксплуатация). При отсутствии DevOps часто возникает напряжение между командами, создающими решения, и другими командами, которые их поддерживают. DevOps снижает проблемы компаний, связанные с организационными силосами (башнями, колодцами, функциональными подразделениями) и формирует Конвейер Непрерывной Доставки (Continuous Delivery Pipeline, CDP) – высокопроизводительный механизм инноваций, способный доставлять конкурентоспособные решения с темпом, необходимым для бизнеса.

Рисунок 1. Конвейер непрерывной доставки

Бизнес-цели DevOps

Цель DevOps – обеспечить доставку ценности при возникновении бизнес‑потребности. Исследования показывают, что команды, успешно внедрившие DevOps, получают значительные преимущества:

• выполняют развёртывания в 208 раз чаще;
• делают это в 106 раз быстрее;
• сталкиваются с отказами в 7 раз реже;
• восстанавливаются после инцидентов в 2 604 раза быстрее по сравнению с командами, имеющими низкую производительность. [2]

DevSecOps – безопасность в потоке доставки

DevSecOps – термин, подчёркивающий необходимость также внедрения информационной безопасности в процессы непрерывной доставки (Continuous Delivery). На ранних этапах развития DevOps безопасность не всегда рассматривалась как приоритет наравне с разработкой и эксплуатацией, поэтому позднее появился отдельный термин DevSecOps, чтобы исключить риск рассмотрения вопросов безопасности «задним числом».

Сообщество специалистов по безопасности способствовало развитию DevOps подхода, расширив его за пределы исключительно разработки и эксплуатации. Отчёт «State of DevOps» демонстрирует, что уровень безопасности в организации повышается, когда управление безопасностью полностью интегрировано в поток создания ценности. [3] Как отмечает RedHat, «устаревшие практики безопасности способны свести на нет даже самые эффективные DevOps инициативы». [4]

Список десяти наиболее распространённых уязвимостей программного обеспечения от Open Web Application Security Project (OWASP) стал ключевым инструментом для координации работы команд разработки, эксплуатации и безопасности. [5]

Инициатива DevSecOps Platform (DSOP), внедрённая ВВС США, показала, что сочетание продвинутых практик DevOps и безопасности позволяет даже строго регулируемым организациям создавать готовые к использованию фабрики программного обеспечения по принципу «подключи и используй» и существенно упрощать процессы доставки.

Интеграция безопасности в DevOps

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

Рисунок 2. Безопасность встроена в DevOps в SAFe

Как SAFe закрепляет безопасность

В SAFe безопасность рассматривается как первоочередная задача. В контексте SAFe термин «DevOps» подразумевает в том числе обязательно и «DevSecOps». Защита клиентов, сотрудников, граждан, военнослужащих, семей и бизнеса – не дополнительная опция, а базовое требование. Современные практики безопасности интегрированы в ключевые элементы SAFe: Большая Картина (Big Picture), статьи фреймворка, учебные материалы, способы проведения оценки и т.д.

Способы интеграции управления безопасностью в поток ценности

• Релизный Поезд (Agile Release Train, ART) – основной организационный элемент доставки ценности в SAFe. Каждый ART обладает всеми навыками и компетенциями, необходимыми для разработки и выпуска решения, и включает в том числе специалистов по безопасности, соответствию регуляторным требованиям (Compliance), обеспечению качества (Quality Assurance, QA), тестированию и верификации/валидации (Verification and Validation, V&V).
• Каждый инкремент, выпускаемый поездом (ART), оценивает жизнеспособность решения и прогресс по безопасности, качеству и соответствию, обеспечивая раннюю обратную связь о пригодности системы к использованию.
• Спецификации создаются на ранних этапах и эволюционируют малыми партиями, что ускоряет получение обратной связи и позволяет регулярно пересматривать решения.
• Безопасность нельзя обеспечить только посредством проверки уже после внедрения – она должна быть встроена в решение на каждой итерации.
• Тестирование безопасности следует «смещать влево», чтобы предотвращать уязвимости, и по возможности автоматизировать, чтобы повысить скорость и точность подтверждения фактов соответствия.

DevOps и Конвейер Непрерывной Доставки (CDP) в SAFe

DevOps делает возможной непрерывную доставку (Continuous Delivery). Организациям, стремящимся постоянно поставлять ценность клиентам и заинтересованным лицам, необходимо освоить DevOps мышление и соответствующие технические практики. Эти навыки критически важны в условиях постоянных цифровых изменений и инноваций. Достижение непрерывной доставки в масштабе остаётся непростой задачей. Подход SAFe к DevOps помогает предприятиям справляться с этими сложностями.

Сдвиг парадигмы

ИТ‑организации по всему миру сталкиваются с устойчивым конфликтом интересов: процессы доставки технологий задействуют команды с разными, иногда противоречивыми, целями и стимулами. [1] Agile команды стремятся быстро внедрять изменения, чтобы соответствовать требованиям бизнеса. Операционные команды регулируют поток изменений, сохраняя стабильность критически важных систем. Команды безопасности формируют политики, направленные на предотвращение уязвимостей и утечек данных.

«Фабрика ПО» – новая система доставки

Для удовлетворения требований бизнеса нужна новая система доставки – «фабрика ПО» (software factory), которая со-направляет (синхронизирует) работу команд и повышает скорость доставки, одновременно улучшая качество, безопасность и стабильность решений. Только при таком подходе потребности клиентов и команд смогут удовлетворяться предсказуемо и эффективно.

Примечание: «Фабрика ПО» – всё более распространённый термин для обозначения этой новой системы доставки. В статье для SAFe Community Питер Волльмер (Peter Vollmer), Distinguished Technologist в Micro Focus, определяет «фабрику ПО» (software factory) как «стандартизированные инструменты и инженерные сервисы», поддерживающие и улучшающие поток создания ценности.» [6]

Описание «фабрик ПО»

«Фабрики ПО» представляют собой интегрированные наборы инструментов, сервисов, данных и процессов, которые помогают продвигать продукты через циклы планирования, сборки, тестирования и релиза. [7] Министерство обороны США формирует растущую экосистему «фабрик ПО», используя общую платформу DevSecOps (DSOP) для ускоренного выпуска специализированных цифровых продуктов и сервисов. [8] Независимо от используемого термина, компании используют DevOps для достижения подобного уровня зрелости в своих потоках ценности.

Необходимость сдвига парадигмы

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

Как Agile изменил подход к работе команд, так и DevOps трансформирует способ создания решений. Использование DevOps для внедрения нового способа создания цифровых решений и переход к Конвейеру Непрерывной Доставки (Continuous Delivery Pipeline, CDP) – ключ к модернизации устаревших жизненных циклов разработки.

Непрерывное обучение и эксперименты

Конвейер Непрерывной Доставки (Continuous Delivery Pipeline, CDP) – результат эффективного применения DevOps к построению эффективного потока создания ценности. Понимание потока ценности в таком подходе отличается от традиционной модели, поскольку в современном мире меняются цели и способы использования технологий.

Скорость обучения важнее количества релизов

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

Конвейер Непрерывной Доставки как цикл обучения

На рисунке 3 показано, что в SAFe Конвейер Непрерывной Доставки рассматривается как замкнутый цикл, поощряющий быстрые, низкорисковые эксперименты и непрерывное обучение с целью понимания потребностей, привычек и предпочтений клиентов.

Рисунок 3. CDP как цикл непрерывного обучения

Отличия от традиционных процессов

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

Большие партии, разрозненные команды, передачи работ «из рук в руки», монолитные архитектуры, разной направленности комитеты по рассмотрению изменений, избыточные внутренние регламенты и «героизм» не работают в этой системе.

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

Роль DevOps

Рисунок 4. DevOps обеспечивает работу Конвейера Непрерывной Доставки (CDP)

DevOps выступает как образ мышления, которое формирует поведение и направляет принятие решений по всему потоку ценности. Подход CALMR в SAFe воплощает это мышление, занимая центральное место в Конвейере Непрерывной Доставки (CDP) и пронизывая все его аспекты.

Технические навыки, практики и инструменты DevOps непосредственно развивают и поддерживают Решения. В SAFe домены практик (practice domains) представляют эти знания во внутренних кольцах модели CDP, показанной на рисунке 4.

Измерение и управление зрелостью DevOps

Регулярное измерение эффективности DevOps и инкрементальное отслеживание прогресса критичны для формирования устойчивой культуры DevOps.

DevOps Health Radar

Радар здоровья SAFe DevOps (Рисунок 5) – инструмент, который помогает Релизным Поездам (Agile Release Train, ART) и Поездам Решения (Solution Train) оптимизировать производительность потока ценности.

Радар даёт комплексную оценку «здоровья» DevOps, измеряя зрелость 4 аспектов и 16 активностей CDP. С помощью этого инструмента можно определить базовый уровень зрелости на любом этапе DevOps трансформации и направить усилия туда, где они в первую очередь необходимы.

Рисунок 5. SAFe DevOps Health Radar

Примечание: участники SAFe Studio имеют доступ ко всем оценкам SAFe, включая DevOps Health Radar, который доступен как готовый Excel файл или как продвинутое решение от партнёра вендора – Comparative Agility. Вариант партнёра представляет собой готовое SaaS средство для сбора данных, их анализа, сравнения и построения трендов для повышения эффективности. Доступ к любому формату радара осуществляется со страницы «Measure and Grow» внутри SAFe Studio.

Дополнение от Алексея Ионова, ASPC:

Почему современная продуктовая разработка невозможна без DevOps?

DevOps – не просто набор практик для ИТ; это основа предпосылка современной продуктовой разработки. Давайте рассмотрим аргументы, почему это так.

1. Современная продуктовая разработка ориентирована не на разовую, а на постоянную доставку ценности

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

DevOps предоставляет процессы и технологические инструменты (CI/CD, автоматизированное тестирование, инфраструктура как код и т.д.), позволяющие выпускать малые инкременты с управляемым уровнем риска.

2. Повышение скорости обучения требует автоматизации и интеграции

На самом деле одним из немногих реальных конкурентных преимуществ на сегодня является скорость обучения (а не просто частота релизов).

Для этого необходимы управленческая интеграция команд с разной специализацией (стеки, зоны основной экспертизы и ответственности), автоматизация сборки, тестов и развертываний и сквозная полностековая телеметрия продукта.

DevOps обеспечивает именно такую интеграцию и автоматизацию.

3. Управление рисками и безопасность не совместимы с ручным процессом, где решения принимаются менеджерами «по месту»

Без встроенных непосредственно в поток ценности практик безопасности (DevSecOps), проверки безопасности будут проводится после окончания разработки, что замедлит релизы и, как ни странно, увеличит риск уязвимостей.

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

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

Чтобы масштабировать выпуск продукта по нескольким Релизным Поездам (ART) и/или Поезду Решения, нужна стандартизированная платформа инструментов и инженерных сервисов – «фабрика ПО». Создание такой платформы – задача DevOps культуры и практик: шаблоны конвейеров, общие конвейеры, автоматизация сред и процедур восстановления.

5. Операционная стабильность при частых релизах невозможна без мониторинга и продвинутых практик восстановления

Быстрое восстановление после инцидента (mean time to recover, MTTR) и управление изменениями в продуктовой среде требуют мониторинга, автоматизированных процедур отката, инфраструктуры как кода и процессов реагирования на инциденты (incident response) – все это элементы DevOps/CALMR.

Без них частые релизы приведут к нестабильности, а не к ускорению обучения. Нестабильность в свою очередь сделает невыгодными для бизнеса любые инновации, что может «поставить крест» на развитии бизнеса в принципе.

6. Управленческая синхронизация и единая продуктовая ответственность

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

В рамках DevOps требуется, чтобы Команда команд (для небольших продуктов это может быть и одна команда) отвечала за весь путь фичи: формирование требований, разработку, тестирование, доставку в продакшн, эксплуатацию и наблюдение за поведением пользователей и кода в реальной среде. Цель — не просто «отработать спеку/ТЗ», а обеспечить, чтобы релиз был пригоден к использованию и приносил ожидаемую бизнес‑ценность.

Эксплуатационная пригодность продукта (fitness for purpose) – это понятие шире качества кода. Оно включает соответствие требованиям пользователей и бизнеса, стабильность, безопасность, производительность, удобство использования и способность поддерживать бизнес‑цели. Команда команд (Поезд в SAFe) отвечает за то, чтобы продукт действительно решал поставленную задачу в реальных условиях.

Одна команда редко обладает всеми компетенциями для поддержания всего потока создания ценности, поэтому в SAFe команды объединяются в ART/Solution Train. И получившаяся команда команд уже несет коллективную ответственность за доставку инкрементов, их пригодность (соответствие требованиям и назначению) и весь непрерывный поток ценности.

DevOps‑практики дают ART/Solution Train реальные инструменты для исполнения этой работы.

Практические рекомендации для команд и менеджмента:

Команды команд должны владеть не только разработкой, но и навыками развёртывания, мониторинга и реагирования на инциденты (или иметь доступ к этим компетенциям внутри ART).

• KPI и цели должны измерять результаты в продуктовой среде (например, пользовательские метрики, MTTR, частота развертываний, доля автоматизированных тестов), а не только количество закрытых задач в беклоге.
• Владелец Продукта и Менеджмент Продукта отвечают за ценность и приоритизацию, но команды – за её достижение в продуктовой среде.
• Организационные стимулы (оценка эффективности, бонусы, цели) должны поощрять совместную ответственность за качество и эксплуатационную пригодность, а не только скорость релизов.

Краткое заключение

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

Без DevOps Конвейер непрерывной доставки (CDP) просто не сможет функционировать должным образом: автоматизация, интеграция команд, встроенная безопасность и платформенная инженерия – все это неотъемлемые компоненты эффективного CDP.

Вопросы-ответы:

Что такое DevOps и чем он отличается от DevSecOps?

DevOps — это культура и набор практик для интеграции разработки и эксплуатации; DevSecOps подразумевает встроенную безопасность в эти процессы, когда security (безопасность) становится частью потока создания ценности.

Что такое Конвейер Непрерывной Доставки (Continuous Delivery Pipeline, CDP)?

CDP – это автоматизированный конвейер, охватывающий исследования (discovery), планирование, сборку, тестирование, развёртывание и эксплуатацию, организованные как замкнутый цикл «строить – измерять – учиться».

Что такое «фабрика ПО» (software factory)?

«Фабрика ПО» — стандартизированная платформа инструментов и инженерных сервисов, обеспечивающая автоматизацию и со-направленность (выравнивание, синхронизацию) работы команд для ускорения доставки ПО.

Как измерить зрелость DevOps?

Используйте инструменты вроде SAFe DevOps Health Radar для оценки ключевых аспектов DevOps и приоритизации инкрементальных улучшений.

Узнать больше:

[1] Kim, Gene, Jez Humble, Patrick Debois, and John Willis. The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. IT Revolution Press, 2016.

[2] Accelerate – State of DevOps 2019. https://services.google.com/fh/files/misc/state-of-devops-2019.pdf

[3] 2019 State of DevOps Report. https://puppet.com/resources/report/2019-state-of-devops-report

[4] What is DevSecOps? https://www.redhat.com/en/topics/devops/what-is-devsecops

[5] OWASP Top 10 Application Security Risks. https://owasp.org/www-project-top-ten/

[6] Accelerating Flow with DevSecOps and the Software Factory. https://www.framework.scaledagile.com/accelerating-flow-with-devsecops-and-the-software-factory/

[7] Why a Software Factory Is Key to Your DevOps Success. https://techbeacon.com/devops/why-software-factory-key-your-enterprise-devops-success

[8] U.S. Air Force Software Factories. https://software.af.mil/

Оригинал: Scaled Agile, Inc. (вендор), статья «DevOps». Материал не является официальным переводом.

Перевод и адаптация: Алексей Ионов, Lean-Agile коуч организаций, Advanced SPC, Ионов и Партнеры.

Основано на версии статьи вендора от 14.03.2023.

Почитать дополнительно по теме:

Конвейер Непрерывной Доставки (Continuous Delivery Pipeline, CDP)

Разработческие потоки ценности

© «Ионов и Партнеры» (ИП Ионов Алексей Константинович), 2018-2025. Все права защищены. Цитирование материалов и размещение ссылок на материалы для формирования сторонних баз знаний, рубрикаторов или агрегаторов допускается только с письменного согласия «Ионов и Партнеры».

SAFe® and Scaled Agile Framework® are registered trademarks of Scaled Agile, Inc.