Проведя анализ литературы по управлению рисками, риски практически не упоминались, хотя практические специалисты их часто идентифицируют. Кроме того, в литературе в основном основное внимание уделялось неотъемлемым рискам, которые были непосредственно связаны с концепцией DevOps, в то время как практики также упоминали практические риски, связанные с последствиями использования DevOps. Данная статья посвящена рассмотрению и разработке структуры и стратегии управления рисков при использовании DevOps методологии.
Сравнение методов управления рисками в литературе и на практике показывает, что в литературе предлагается множество технически продвинутых автоматизированных средств контроля, в то время как на практике компании все еще полагаются на более традиционные методы, поскольку они еще недостаточно зрелы [1] в своих процессах, чтобы полагаться на другие средства контроля. Большинство средств контроля, описанных в литературе, также были признаны на практике, хотя технически продвинутые средства контроля были найдены только в очень зрелых компаниях. Кроме того, элементы управления из литературы были в основном сосредоточены на операционных процессах, связанных с поставкой программного обеспечения, и в меньшей степени касались вспомогательных механизмов, таких как роль отдела безопасности.
Основные элементы, составляющие эффективное управление рисками DevOps, представлены на рисунке 1. Уровень 0 – это категории риска и требования соответствия, которые применяются к компании и должны определять все варианты организационной структуры. Уровень 1 – это четко распределенные роли, обязанности и политики являются всеобъемлющими требованиями для эффективной работы с этими рисками и соблюдением требований, общие механизмы поддерживаются Уровнем 2: первые три представляют модель трех линий защиты в контексте DevOps. В первой строке рассматриваются операционные процессы, связанные с доставкой программного обеспечения и эксплуатацией, и содержатся автоматизированные и ручные элементы управления. Сами команды DevOps являются владельцами рисков и несут ответственность за внедрение и выполнение средств контроля первой линии. Вторая линия содержит вспомогательные и контролирующие функции, методы, которые активно управляют рисками, также отделы, которые были признаны важными для поддержки команд DevOps. Помимо отдела безопасности, юридического отдела и отдела контроля качества, упомянутых на рисунке 1, в процесс DevOps могут быть вовлечены и другие отделы в зависимости от конкретных действий команд. Уровень 3 – это последняя линия защиты, которая обеспечивает уверенность в форме внутреннего аудита. Процессы DevOps повышают ценность бизнеса и операционную эффективность, т.к. некоторые процессы DevOps естественным образом пересекаются с предлагаемыми элементами управления.
На рисунке 1 представлены все важные элементы управления рисками, он не дает информации ни о разработке стратегии управления рисками, которой должны руководствоваться компании, ни о конкретных методах, которые она должна внедрять. В ходе обзора литературы было выявлено множество средств контроля и механизмов, однако не все они подходят для каждой ситуации.
Было выявлено два основных фактора, которые преимущественно влияют на характер методов управления рисками, - это требования соответствия, которым подчиняются компании, а также методы DevOps, которые внедряют. Распространение этих концепций на более широкие категории, которые они представляют, приводит к предположению, что двумя основными факторами, которые влияют на компании при разработке их средств контроля, являются склонность к риску, а также зрелость DevOps.
Сопоставление этих двух факторов в матрице дает нам фигуру, представленную на рисунке 2а, с четырьмя основными ситуациями, в которых могут оказаться команды. На рисунке 2 приведено базовое описание стратегии снижения риска, которое подходит для каждой ситуации.
Цвета фона в матрице представляют гибкость, которой команды могут достичь на каждом этапе пути DevOps, сохраняя при этом контроль: светлые цвета фона представляют высокую гибкость, а темные цвета – низкую гибкость (см. рисунок 2б). Это деление также объясняет основную движущую силу, почему команды хотят стать более зрелыми в своих процессах: повышение зрелости DevOps [1] приводит к повышению гибкости и позволяет им получать больше преимуществ DevOps. Хоть риски и зрелость DevOps [1] кажутся двумя разными факторами, важно отметить, что эти две оси не полностью независимы друг от друга. Команды, которые работали в среде с более низким уровнем риска, в целом были более зрелыми в своих процессах DevOps, чем команды в среде с более высоким риском. Таким образом, командам, которые менее способны брать на себя определенные риски, будет сложнее перейти из квадранта процессов DevOps с низкой зрелостью в квадрант высокой зрелости [1].
После изучения основных стратегий снижения рисков и построения матрицы управления рисков на рисунке 2а, становится ясно, что риски имеют разные приоритеты в разных квадрантах. Хотя компании, конечно, всегда должны учитывать все типы рисков и определять, применимы ли они к конкретной ситуации, очевидно, что некоторые риски, применимы только к компаниям с низкой зрелостью DevOps, в то время как другие, такие как командные риски, в основном связаны с высокой степенью зрелости [1]. Особенности команды, которые развертывают относительно часто, но еще не реализовали много функциональных тестов, особенно подвержены риску развертывания неисправных продуктов и выпуску не качественного программного кода. Было обнаружено, что организационные и проектные риски не связаны с влиянием риска или зрелостью DevOps, а зависят от характера организации и типа работы, которую выполняют команды.
Было выявлено, что компании должны уделять особое внимание внедрению дополнительных средств контроля, которые возникают из-за рисков, а для снижения одних и тех же рисков можно использовать несколько средств контроля. Следовательно, средства контроля, которые выбирает компания, должны зависеть от ее положения в квадрате и соответствующей стратегии, которой она должна следовать, а также от рисков, которые имеют особое значение для ситуации в команде.
Высокая зрелость DevOps – низкий риск: непрерывная доставка, такие компании должны уделять гораздо больше внимания разработке коллективных средств контроля, такие команды могут автоматизировать большую часть своих процессов и использовать DevOps в своих интересах. Проведение критических функциональных тестов и тестов безопасности перед каждым развертыванием повысит качество и безопасность продукта, поскольку исключает возможность человеческих ошибок.
Высокая зрелость DevOps – склонность к высокому риску: непрерывное развертывание. Этот квадрант, несомненно, является наиболее желательным для команд, поскольку он позволяет им достичь максимально возможной скорости и гибкости, а также позволяет им автоматизировать, как можно больше ручных задач, включая развертывание продукта. Однако эта стратегия оправдана только в том случае, если последствия развертывания частично неисправного продукта или невыполнения командой своих обязанностей относительно невелики и компания готова их нести. Компании, использующие эту стратегию, могут предоставить своим командам большую автономию и ответственность и могут сделать упор на использование средств контроля обнаружения (мониторинга), а не средств контроля предотвращения.
Низкая зрелость DevOps – высокая склонность к риску: экспериментальное обучение. Третий квадрант описывает компании или команды, которые готовы пойти на некоторые просчитанные риски, но еще не очень зрелы в своих процессах и действиях из-за своей готовности мириться с последствиями небольших ошибок команды в этом квадранте могут свободно экспериментировать с различными средствами контроля и методами, чтобы выяснить, что лучше всего подходит для их ситуации.
Низкая зрелость DevOps - низкий риск: Agile-команды, отвечающие за Dev и Ops. Команды, которые еще не созрели в своих процессах DevOps, но не могут или не хотят идти на большой риск, работают в довольно опасной среде. Поэтому они должны быть чрезвычайно осторожны при внедрении новых функций и методов. На данный момент автоматизация еще не играет (большой) роли, потому что для команд важнее привыкнуть к культуре DevOps и их расширенным обязанностям.
Список литературы
1. Карапетян С.А. «Построение модели зрелости управления релизами для ИТ предприятий на основе DevOps методологии» Материалы 60-й Международной научной студенческой конференции МНСК-2022: Информационные технологии 10 - 20 апреля 2022 г. – Новосибирск: Новосиб. гос. ун-т., 2022. – С. 358
2. Х. Ясар. «Внедрение безопасной оценки DevOps для строго регулируемых сред», Материалы 12-й Международной конференции по доступности, надежности и безопасности: 29 августа 2017 г. - 1 сентября 2017 г. – Реджо-ди-Калабрия, Италия: ACM, 2017, С. 1 – 3
3. О. Плант, «Управление рисками в DevOps: обзор современной литературы. Темы исследований в области информационных технологий для бизнеса» – ун-т Твенте, 2018 г.
