Принимайте участие в зарплатном опросе! Уже собрано почти 8 000 анкет.
×Закрыть

Как [не] быть DevOps Engineer

Добрый день, меня зовут Дмитрий. Я с недавних пор веду telegram канал ДевОпс Трансформация (t.me/devops_transform).

Начать писать меня побудили несколько причины: 1) накопилось достаточно опыта, чтобы делится мыслями не только с коллегами на работе; 2) хочу развеять несколько мифов о DevOps, в частности, почему позиция «DevOps Engineer» так укоренилась в украинском IT (такой позиции или роли в культурном движении DevOps не существует); 3) повлиять, по возможности, на проблему перенасыщенных требований к вакансиям, потому что ищут Человека Швейцарский Ножик (такие безусловно есть). По второму пункту я не собираюсь вступать в святые войны с сообществом (тут я опоздал на 2-3 года), а скорее на примере компании Just Eat (Ciklum), в которой я работаю, расскажу (в telegram) как мы трансформируемся и адаптируем практики DevOps.

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

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Как я наблюдал эволюцию понятия:
automation engineer—>build engineer—>release engineer—>devops engineer—>sre—>?
Суть работы не изменилась, но с каждой итерацией бабла насыпают побольше)))

После SRE будет что-то типа DevSecOpsTestPMDMRM engineer

по сути вы протестуете против того что названием методологии\практики «devops» назвали вид деятельности «devops engineer». В этом нет ничего плохого, более того — я вижу именно с таким названием вакансии на американских сайтах работы, где требуют классические для девопса навыки linux,aws,ci/cd и прочее.

Это нормально, что наши компании клонируют требования и названия позиций. Методология это все понятно — но поймите и вы, ну нету ресурса у девов знать глубоко как работает докер и проходить авс сертификации. Им нужно поспевать у себя. Конечно, вопрос кто должен собирать и деплоить (писать пайплайны) — он по сути также и про «девопс», но все же с моего опыта — это очень зависит от организации до организации. Нету правильного ответа, где-то стараются жить по вашему умыслу и получется, или нет. Но вот ваше игнорирование успешного опыта груп девопсов что и деливерят, и автоматизируют, и занимаются продом и маштабированием — это странно.
Допустим вы называете «админа» SRE теперь. Окей, это понятно, но вот людям более привычно этот вид деятельности называть девопсами. Прижилось название. Ну и, девопс все же не класический админ — админы ленивы, а девопсы умеют в питон, авс, и дальше все что надо уметь.

Девопсы это лишнее звено. Для настройки разработческой инфраструктуры, достаточно кодерков. Для настройки организационной/аппаратной — админов. Зачем нужны девопсы?

Я тоже не знаю :) Потому что считаю это практикой (культурным движением), а не ролью. У нас в организации все настраивает команда разработчиков и автоматизаторов в паре с сетевыми инжинерами, безопасниками и другими операционными службами.

QA, по суті, також не потрібні

Отлично, пропатчим сознание и избавимся от термина DevOps инженер! Я бы только заменил слово методология DevOps на философия (или курльтура) DevOps.

Хорошее замечание, спасибо.

Настала неделя девпосов, количество постов на доу про сабж увеличилось вдвое.

Чем Ukrops не подходит?

Очень даже подходит, конкурировать не собираюсь :) У меня есть, чем поделится с сообществом.

Devops это просто модный термин за смыслом которого ничего нового не стоит.

А як їх тоді називати?

кого их и с чего у «них» должно быть какое то особое название? Чего такого особого «они» делают чего не делают другие профессионально и грамотно выполняющие работу люди, которые себя девопсами не называют. Девопс не более чем маркетинговый термин.

Якщо не вигадувати для людей нових назв, але змінити їх відношення та участь до процесу безперервного розгортання додатків (змін) на продакшн середовище, то це буду перший крок на шляху змін ддя реалізації DevOps практик.

Подписаться на комментарии