У айтишников появилось новое слово — 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). Естественным образом в этот процесс оказываются вовлеченными тестировщики. Когда разработка начинает дружить с эксплуатацией, им просто деваться некуда. Приходится дружить тоже. Так что акцент на качестве так же попадает в главные ценности.
Теперь несколько слов об архитектуре. Когда все со всеми начинают дружить, архитектура тоже оказывается востребованной. Во-первых, потому, что надо быть очень опрометчивым человеком, чтоб автоматически развертывать всю систему целиком. Когда те или иные интернет-ресурсы меряются количеством релизов в день речь идет либо о локальных изменениях, либо о реализации некоторого иногда довольно продолжительного плана переключения. Во-вторых, основная задача архитектора в том и состоит, чтоб подружить всех со всеми. На протяжении многих лет в моих презентациях присутствует примерно такая картинка о роли архитектора в современной организации:
Однако считать DevOps вещью банальной и бесполезной тоже не правильно. Мы начали разработку High Level Design примерно лет семь назад (что такое HLD см в заметке High Level Desig). Сейчас, задумываясь над вопросом: можно ли было что-то придумать лучше, чтобы следовало изменить в HLD, я безусловно говорю слово deployment. Развертывание не в узком смысле этого слова, не в смысле размещение программных компонент по серверам, а развертывание в широком смысле. Развертывание это и подготовка продуктивной конфигурации и создание обратной связи от конфигурации в продуктиве с средами разработчиков. Развертывание это и настройка интерфейсов и связывание бизнес-отчетности и технологического мониторинга с основными сценариями продукта, описанным в HLD. С мониторингом вообще отдельная история. Обычно на вопрос о доступности системы эксплуатация не задумываясь отвечает 99,9%, а на вопрос где еще одна десятая, регулярно приходится получать ответ: а это не работал пробник системы мониторинга. Похожая ситуация с операционной отчетностью. Что они там считают и затем показывают бизнес-заказчику ответить порой не просто. Развертывание это еще и о том, какие подразделения и каким образом будут отображаться в профили доступа системы (проще говоря, о заявках на ИТ услуги) и о том, почему автоматизация катастрофически улучшив процесс на одном участке привела к его деградации в целом.
Одним словом, в теме DevOps есть о чем подумать. Только если уж кого-то с кем-то «дружить», то лучше делать это не сепаратно (сначала разработку с заказчиком, посредством agile, потом сопровождение с разработкой посредством devops), а всех вместе.