Как [не] быть DevOps Engineer
Усі статті, обговорення, новини про DevOps — в одному місці. Підписуйтеся на DOU | DevOps!
Добрый день, меня зовут Дмитрий. Я с недавних пор веду telegram канал ДевОпс Трансформация (t.me/devops_transform).
Начать писать меня побудили несколько причины: 1) накопилось достаточно опыта, чтобы делится мыслями не только с коллегами на работе; 2) хочу развеять несколько мифов о DevOps, в частности, почему позиция «DevOps Engineer» так укоренилась в украинском IT (такой позиции или роли в культурном движении DevOps не существует); 3) повлиять, по возможности, на проблему перенасыщенных требований к вакансиям, потому что ищут Человека Швейцарский Ножик (такие безусловно есть). По второму пункту я не собираюсь вступать в святые войны с сообществом (тут я опоздал на
Не хочу оскорбить кого-то из читающих мой пост DevOps-ов, а лишь отмечу что для того, чем Вы занимаетесь есть более удачное название, вот некоторые из них — Site Reliability Engineer или Automation Engineer (не путать с Test Automation). Однако, просто переименовать себя в LinkedIn не достаточно. Все окружающие Вас люди в организации должны участвовать, принимать изменения и способствовать внедрению DevOps.
Это методология, которая описывает интеграцию между Develoment и Operations, коммуникации, процесс взаимодействия, изменения отношения к тому, как доставляются изменения и разрушение барьеров между разными отделами организации.
DevOps нужен прежде всего для того, чтобы доставлять на production изменения и улучшения, используя существующие человеческие ресурсы эффективно, и создавая синергию между ними (и это достигается не только техническими стредствами).
Я люблю посещать различные митапы по этой тематике, знакомиться с людьми и обсуждать различные аспекты методологии DevOps. Часто приходилось слышать об «удачном опыте создания экспертной группы DevOps инженеров или целой DevOps команды» (что само по себе противоречит методологии), чтобы быть «тем самым недостающим звеном» организации, которое (по-факту) делает автоматизацию развертывания, интеграцию инструментов, поддержку production... И таких примеров, к сожалению, большинство.
Для себя сделал вывод, что outsource — это краеугольный камень данного феномена. Потому, как в прошлом, ассоциируемые обязанности в основном оставались на стороне заказчика. В наши дни, украинское IT получило достаточный кредит доверия, чтобы выполнять задачи, связанные с поддержкой (в самом широком смысле) production окружения. Это, конечно, большой плюс для нас, но украинские компании стараются применить всю ту же, опробованную годами организационную модель.
Если Вас зацепил текст, согласны или не очень, я буду рад обсудить это в комментариях. Подписывайтесь на telegram канал @devops_transform, в котором я делюсь мыслями, практическими советами и личным опытом. Основной фокус на том, как компании применяет DevOps практики. А также полезные инструменты, новости, события и люди. Спасибо за внимание.
17 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів