За последние несколько лет термин DevOps стал настолько привычным, что без него не обходится ни один проект. К большому сожалению, в подавляющем большинстве случаев люди упускают из внимания первопричину появления DevOps движения и те проблемы, которое оно призвано было решить. Еще печальнее осознавать, что неправильное понимание до такой степени укоренилось и распространилось, что воспринимается большинством как стандарт де-факто. Даже на встрече DevOps сообщества в докладах говорят только про обязанности конкретных людей и инструменты для конкретной роли в проекте.

Самым распространенным заблуждением является то, что DevOps – это конкретный человек, который обладает по сравнению с традиционным системным администратором дополнительными навыками и знаниями определенных инструментов: компоненты CI/CD (CI сервер, репозиторий артефактов, динамические языки для написания конфигураций, инструменты сборки приложений и т.д.), централизованное логирование (ELK стек, Splunk и прочие), управление облачной инфраструктурой (AWS, Azure, Heroku и т.д.), инструменты для деплоя приложений и конфигурации окружения (Ansible, Chef, Puppet и другие), контейнеризация (Docker, Kubernetes, Swarm и т.д.). Эдакий эксперт, который будет помогать несмышленым разработчикам собрать и задеплоить свой код на разные окружения.

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

Вторым по популярности действием в этой области является простое переименование существующих системных администраторов в DevOps инженеров, чтобы соответствовать трендам и удовлетворять запросы заказчиков. Этот способ зарабатывать больше уже давно освоили аутсорсинговые компании, ведь можно заработать гораздо больше денег на востребованных DevOps инженерах чем на старых добрых сисадминах. Потом проводишь собеседование с такими специалистами и задаешь простой вопрос: “Расскажите как вы работали с разработчиками на протяжение итерации (планирование, разработка фичей, демо, ретроспектива)”. А в ответ: “Никак, они нам в JIRA задачки делали и мы когда было время их брали и реализовывали. У нас была своя команда, которая отвечала за инфраструктуру и инструменты”.

Я хочу собрать многочисленные забавные истории из мира DevOps и подготовить доклад “Funny stories and anti-patterns from DevOps landscape” на ближайшую конференцию XP Days Ukraine 2017, которая запланирована на 10-11 ноября.

Ведь изначально DevOps движение зародилось как попытка объединить усилия разработчиков с другими ролями для более плотной командной работы над единой целью – разработать качественный и ценный продукт. Предполагалось, что более тесная работа на всех этапах жизненного цикла разработки позволит избежать целого ряда проблем в обеспечении стабильной работы продукта, установке его на различные окружения, нахождении, анализе и исправлении проблем в работающих сервисах. Название DevOps сфокусировано на двух группах: Dev и Ops. Но на самом деле идея гораздо шире и скорее должна называться TeamWork, DesignDevOAOps или devops без выделения заглавными буквами конкретных ролей.

То есть, на самом деле речь идет о культурных изменениях, о вовлеченности всех ролей на разных стадиях разработки и принятии совместных решений по вопросам разработки, инфраструктуры, CI/CD, инженерным практикам, инструментарию и т.д. На примере все тех же Dev и Ops это означает, что разработчики должны понимать как устроена инфраструктура и как с ней работать, участвовать в ее построении и нести такую же ответственность за проблемы в этой области как и инженеры поддержки. Инженеры поддержки, в свою очередь, должны участвовать во всех активностях, связанных с разработкой, чтобы понимать как устроен продукт, его архитектуру, ограничения, нефункциональные требования, откуда берутся требования к инфраструктуре и как реализовать их максимально эффективно.

Культурные изменения не внедряются просто, но и попытка заменить их на конкретные дополнительные роли не приносит успеха и не решает изначальные задачи…