Применение практик DevOps
Глава посвящена применению практик DevOps как ключевому фактору ускорения цифровой трансформации. DevOps рассматривается как продолжение идей Agile и бережливого производства, охватывающее весь цикл создания ценности в ИТ. Анализируются предпосылки его появления: эволюция гибких методов разработки, виртуализация, облачные технологии и управление инфраструктурой как кодом. Подробно раскрываются задачи DevOps – сокращение времени вывода продуктов на рынок, снижение технического долга и устранение хрупкости ИТ-систем. Рассматриваются базовые принципы и практики: поток создания ценности, CI/CD-конвейер, хранение всего в системах контроля версий, автоматизированное управление конфигурациями, тотальная автоматизация и переосмысление понятия «релиз». Подчеркивается, что успешное внедрение DevOps требует культурных и организационных изменений, а не только новых инструментов. DevOps представляется как способ превращения ИТ-подразделения из центра затрат в стратегического партнёра бизнеса.
| Жанр: | Управление бизнесом |
| Цикл: | Не является частью цикла |
| Год публикации: | 2025 |
Читать онлайн Применение практик DevOps
Применение практик DevOps
Методы управления ИТ-деятельностью не стоят на месте. Несколько десятков лет назад использовались одни подходы к разработке и эксплуатации информационных систем, сегодня – уже другие, а завтра придёт время следующих, переосмысленных способов и техник, опирающихся на новые знания, опыт и технологии. Бо́льшую часть времени методы управления развиваются эволюционно, путём систематизации и оттачивания созданных ранее моделей, основанных на неких базовых принципах и постулатах. Однако, время от времени происходят скачкообразные изменения, позволяющие отдельным организациям-лидерам сделать существенный шаг вперёд в вопросах эффективности и рациональности применения информационных технологий.
На передовой ИТ-менеджмента находится движение DevOps (сокр. от англ. Development &
Operations), названное так, в целом, довольно случайно. Новое имя собственное настолько же далеко от вкладываемого в него смысла, насколько аббревиатура ITIL далека от понятия «библиотека», а COBIT – от целей контроля (дополнительные сведения можно найти в главе Учебника 4CDTO «Модели и подходы к оценке цифровой зрелости»).
С публикацией COBIT 5 в 2012 году правообладатель подчеркнул, что, несмотря на то, что изначально аббревиатура COBIT являлась сокращением от «Control Objectives for Information and related Technology», теперь она является именем собственным.
Компания AXELOS, управляющая ITIL с 2013 года, также не рекомендует использовать первоначальное наименование «IT Infrastructure Library», ограничиваясь именем собственным ITIL.
Эксперты DevOps, стоявшие у истоков этого движения, признают ограниченность получившегося названия, призывая использовать более точные, на их взгляд, «BizDevOps», «DevSecOps» и подобные. Однако, вероятность изменения названия в настоящее время является незначительной.
Для дальнейшего изложения можно использовать следующее авторское определение, не претендующее на полноту, универсальность и уж тем более истину в последней инстанции: DevOps – продолжение идей гибкой разработки программного обеспечения и бережливого производства, применённое к полной цепочке создания ценности в ИТ, позволяющее добиваться большего от современных информационных технологий за счёт культурных, организационных и инструментальных изменений. Можно утверждать, что появлению DevOps в наибольшей степени способствовали два фактора: развитие гибких методов разработки программного обеспечения и управление ИТ-инфраструктурой, как программным кодом. Рассмотрим каждый из них.
Развитие гибких методов разработки программного обеспечения
В конце прошлого столетия доминирующей методологией разработки программного обеспечения была так называемая «водопадная модель» (или «каскадная модель»): последовательное выполнение заранее определённых этапов, каждый из которых занимает существенное время и завершается достижением заранее согласованных результатов, при этом переход на следующий этап во многих случаях происходит после полного и формального завершения предыдущего этапа (Рис. 1).
Рис. 1. Пример водопадной модели разработки ПО.
Дополнительным отличительным признаком такой модели является функциональная специализация исполнителей отдельных этапов: аналитиков, архитекторов, разработчиков, тестировщиков и т.д.
При разработке крупных информационных систем с конечной функциональностью, которую возможно определить и зафиксировать в самом начале работ, а также при отсутствии требования максимально быстрого завершения полного цикла разработки такая модель позволяет получать качественные выходные результаты при достаточно детальном контроле расходов. Однако в конце 90-х годов XX века, с бурным развитием Интернет-технологий и webпрограммирования, недостатки водопадной модели стали негативно влиять на взаимодействие и взаимопонимание заказчиков (бизнес-подразделений компании, либо внешних организаций) и исполнителей (программистов компании, либо внешних разработчиков программного обеспечения).
