fbpx
DevOps – это не конкретный человек или роль на проекте!

За последние несколько лет термин 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 это означает, что разработчики должны понимать как устроена инфраструктура и как с ней работать, участвовать в ее построении и нести такую же ответственность за проблемы в этой области как и инженеры поддержки. Инженеры поддержки, в свою очередь, должны участвовать во всех активностях, связанных с разработкой, чтобы понимать как устроен продукт, его архитектуру, ограничения, нефункциональные требования, откуда берутся требования к инфраструктуре и как реализовать их максимально эффективно.

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

Обсуждение (
Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280

Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280

Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280

Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280

Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280

Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280
0)

Добавить комментарий

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

Мы используем файлы cookies для различных целей, включая аналитику и персонализированный маркетинг. Продолжая пользоваться сайтом, вы соглашаетесь на использование файлов cookies. Подробно ознакомиться с правилами работы с файлами cookies можно здесь

принять
Pkv Games BandarQQ Online Terbaik Dengan Deposit Super Modern permainan paling populer di situs poker online terbaik di indonesia di situs bukaqq Poker Online Aman dan Terpercaya slot online