Что такое DevOps

devops ying yangУ айтишников появилось новое слово – DevOps, получившееся в результате слияния слов Development(разработка) и Operations (эксплуатация). Основные культовые книжки этого нового течения «The Phoenix Project» и “The Visible Ops Handbook: Implementing ITIL in 4 Practical and Auditable Steps” на русский язык пока не переведены и потому разобраться с тем, что же такое DevOps совсем не просто. Есть неплохой перевод статьи What is DevOps на русский язык с немного странным названием DevOps – новая методология разработки. Есть симпатичный блог DevOpsHub, включающий несколько интересных публикаций и небольшую DevOpsWiki

В общем, дело темное. Что можно утверждать однозначно, так это что DevOps это о дружбе между разработкой и эксплуатацией. В первой статье есть даже поясняющая картинка о том, что если agile – это о наведении мостов между заказчиком и разработкой, то DevOps это как agile, но только между разработкой и эксплуатацией. Чем же подкреплена эта дружба? В англоязычной блогосфере есть множество заметок о том, что DevOps это не о том, чтоб дать разработчикам все доступы и пароли к продуктивной среде и не о том, чтоб разрешить администраторам чуточку программировать. DevOps это об изменении культуры и налаживании взаимодействия – в первую очередь. Об общих между разработкой и эксплуатацией процессах и инструментах и естественно целях. Некоторый акцент делается на автоматической сборке и развертывании систем, т.е. на том о чем нам всем известно еще со времен непрерывной интеграции (continuous integration). Естественным образом в этот процесс оказываются вовлеченными тестировщики. Когда разработка начинает дружить с эксплуатацией, им просто деваться некуда. Приходится дружить тоже. Так что акцент на качестве так же попадает в главные ценности.

Теперь несколько слов об архитектуре. Когда все со всеми начинают дружить, архитектура тоже оказывается востребованной. Во-первых, потому, что надо быть очень опрометчивым человеком, чтоб автоматически развертывать всю систему целиком. Когда те или иные интернет-ресурсы меряются количеством релизов в день речь идет либо о локальных изменениях, либо о реализации некоторого иногда довольно продолжительного плана переключения. Во-вторых, основная задача архитектора в том и состоит, чтоб подружить всех со всеми. На протяжении многих лет в моих презентациях присутствует примерно такая картинка о роли архитектора в современной организации:

respect-and-integrate

Однако считать DevOps вещью банальной и бесполезной тоже не правильно. Мы начали разработку High Level Design примерно лет семь назад (что такое HLD см в заметке High Level Desig). Сейчас, задумываясь над вопросом: можно ли было что-то придумать лучше, чтобы следовало изменить в HLD, я безусловно говорю слово deployment. Развертывание не в узком смысле этого слова, не в смысле размещение программных компонент по серверам, а развертывание в широком смысле. Развертывание это и подготовка продуктивной конфигурации и создание обратной связи от конфигурации в продуктиве с средами разработчиков. Развертывание это и настройка интерфейсов и связывание бизнес-отчетности и технологического мониторинга с основными сценариями продукта, описанным в HLD. С мониторингом вообще отдельная история. Обычно на вопрос о доступности системы эксплуатация не задумываясь отвечает 99,9%, а на вопрос где еще одна десятая, регулярно приходится получать ответ: а это не работал пробник системы мониторинга. Похожая ситуация с операционной отчетностью. Что они там считают и затем показывают бизнес-заказчику ответить порой не просто. Развертывание это еще и о том, какие подразделения и каким образом будут отображаться в профили доступа системы (проще говоря, о заявках на ИТ услуги) и о том, почему автоматизация катастрофически улучшив процесс на одном участке привела к его деградации в целом.

Одним словом, в теме DevOps есть о чем подумать. Только если уж кого-то с кем-то «дружить», то лучше делать это не сепаратно (сначала разработку с заказчиком, посредством agile, потом сопровождение с разработкой посредством devops), а всех вместе.

Что такое DevOps: 13 комментариев

    1. Пусть будут “девопы”. Главное, чтоб волна интереса к этой теме не схлынула раньше, чем случаться какие-либо реальные преобразования в ИТ-организациях. Сейчас между этими подразделениями – каменная стена. С одной стороны стены релизами швыряются, а в обратную сторону дефекты летят

  1. Т.е. DevOps, фактически, о том, что разработка и эксплуатация – это этапы жизненного цикла ИС, и весьма полезно их рассматривать как части целого, чем по отдельности?

  2. На одном из проектов поймал себя на мысли о взаимосвязи 3-х процессов:
    1. реализация проектов (создание какого либо ИТ-продукта внутри организации)
    2. техническая поддержка
    3. изменение ПО (в т.ч. релизы)

    Все 3 очень жестко взаимоувязаны и можно сказать что образуют одну ИТ-услугу.

    в п.3 задачи могут попасть как из п.1, так и из п.2, т.е. как в ходе поддержки, так и в ходе разработки.

    в идеале, на всех 3-х процессах должны сидеть разные люди и отвечать за разные показатели.

    Оценивать и рассматривать один элемент без остальных двух – мало эффективно. Изменения в поддержке сказываются на проектах и разработке. В разработке на проектах и поддержке. И даже изменения в проектах – сказываются на разработке и поддержке. Это 3 части одного целого – ИТ-услуги. Будь то 1С Бухгалтерия или ERP SAP.

    Как то так )

  3. Русскоязычных статей про devops по-прежнему мало. В свое время в переводил статью автора Phoenix Project – Gene Kim, 11 things to know about devops (http://habrahabr.ru/company/scrumtrek/blog/166039/). Есть так же про антипаттерны devops http://habrahabr.ru/company/scrumtrek/blog/170661/. Ну и рассказывал про devops на конференции agile days http://www.youtube.com/watch?feature=player_embedded&v=ZGLoLfOqh7Y.
    Если говорить про то, что такое devops, то текущее мнение основных апологетов движения (Patrick Debois, Edward Daemon, Gene Kim и других) звучит следующим образом: DevOps это 4 простых вещи:
    – Culture (культура процесса и взаимоотношений)
    – Automation (автоматизация направленная на облегчение работы)
    – Measurement (работа с техническими и продуктовыми метриками)
    – Sharing (непрерывный обмен знаниями между разными участниками команды)
    И эти работа над этими 4 вещами ведется с целью организации непрерывной поставки высококачественного ПО.

  4. Максим, а можно привести какой-нибудь простой пример как выглядит

    “связывание бизнес-отчетности и технологического мониторинга с основными сценариями продукта, описанным в HLD”

    С технологическим мониторингом более-менее ясно, как я понял, имеется ввиду измерение работы системы не в абстрактных единицах (% загрузки CPU, RAM и т.п.) и не доступность системы (например состояние сетевых интерфейсов), а скажем отображение выполненных системой транзакций в секунду и подобные приближенные к решаемой бизнес-задачи показатели доступности/производительности сервиса.

    А как быть с бизнес-отчетностью ? Что тут имелось ввиду: генерируемая самой системой отчетность или же какая-то внешняя отчетность по работе самой системы (не знаю, может соотношение затрат и результата) ?

    Можете пояснить ?

    Спасибо.

    1. Наверное, правильнее было бы говорить об управленческой отчетности. Задача состоит в том, чтоб вписаться в существующую систему показателей, по возможности, не меняя её.
      Например, есть отчет по объему подключенных услуг за период времени. Всегда есть возможность вольного трактования того, как считать этот показатель. Можно тупо взять число подключений за период. Можно взять дельту между количеством подключений и отключений или посмотреть использование услуги и учитывать только тех, кто хотя бы раз услугой воспользовался. Это знание не всегда где-либо зафиксировано, а новые проекты любят придумывать свои показатели не вникая в то, как организованы уже имеющиеся в компании

Добавить комментарий для Gleb Belokrys Отменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *