DevOps инженер, релиз инженер, системный администратор в команде разработки
Invite pending
Итак, поискав по списку вакансий, на современном рынке труда наткнулся на большое количество относительно новых вакансий, но их описание меня достаточно удивило и стало непонятно, почему описания не соответствуют названиям. По сути страшного в этом ничего нет, многие компании пишут в описании вакансии перечень знаний явно завышенный, а при личном общении на собеседовании выясняется, что знаний которые есть у соискателя достаточно для работы, хоть они и не соответствуют описанию.
Посетив несколько из таких собеседований, был неприятно удивлен, один из ярких примеров — это вакансия “DevOps инженер” и таких вакансий много.
Примеры требований по данной позиции:
• Опыт работы с Linux виртуализацией на базе KVM от 3 лет
• Глубокие навыки и опыт администрирования и автоматизирования Linux сред
• Глубокие технические знания общих принципов работы операционных систем, обязательные знания ядра Linux;
• Опыт работы с bash и одним другим языком программирования (Желательно Python)
• автоматизацией изменений в инфраструктуре
• настройкой JIRA
• поддержкой масштабных Linux проектов
• ведением всего, что связано с puppet
• написанием скриптов на ruby, python или bash
• Опыт администрирования PostgreSQL, MySQL
• Знание аппаратных сред, аппаратных вычислительных ресурсов, систем хранения данных
• Разработка драйверов аппаратных средств в среде Linux
• Понимание взаимодействия между HW, операционной системой и приложениями в Linux
Это только несколько примеров указывать все нет смысла. Из всех описаний следует, что все это обязанности системного администратора высокого уровня (зависит от компании).
Итак, попытался разобраться подробнее на примере нескольких позиций, указанных собственно в заголовке поста.
Что есть DevOps?
Подробно описывать нет смысла, уже есть множество статей на эту тему, укажу основное, дабы не потерять мысль статьи. DevOps это не профессия и не должность, а подход к разработке, такой же как например Agile, следовательно и позиции “DevOps инженер” по моему мнению быть не может, либо это неправильное название.
Более понятным понятие DevOps сделает следующая картинка:
В жизненном цикле продукта существует несколько неотъемлемых этапов основные из них:
• разработка
• тестирование
• эксплуатация
Подход DevOps должен и призван сделать для всех участников все процессы прозрачными и минимизировать “пропасть” между разработкой, отделом контроля качества и эксплуатацией.
Решить проблему разрозненности отделов DevOps подходом бесспорно можно, но так же можно поставить в центр между всеми этими человека который и будет тем прозрачным элементом цепочки, процессов и отделов. И напрашивается вот же он “DevOps инженер”, решение проблемы. Посмотрев в описание вакансий на рынке, как-то не складывается.
“DevOps инженер“
На данной позиции требуют глубочайшие знания ОС(на уровне глубокого администрирования), ну еще пара вещей из категории администрирования, все это скорее из категории системного администрирования и эксплуатации.
А где требования по знаниям и опыту тестирования, где требования по знаниям хотя бы основ подходов к разработке, если только это подразумевается само собой, что врядли. Я был на собеседованиях и кроме вопросов по системному администрированию других не задают.
Из этого можно сделать вывод, что проблему разрозненности команд работодатель не решает, а “DevOps инженер” для него это всего лишь новое модное словечко и название для позиции системный администратор.
“Релиз инженер” и “Системный администратор в команде разработки”
“Системный администратор в команде разработки”. Данное звено в цикле разработки закрывает многое, к примеру он знает как работает продукт в бою, как протекает разработка, даже что покатится в ближайший релиз и как оно работает ну соответственно он знает куда он это будет разворачивать и как. Кажется что этого достаточно, но стоп а тестирование, так называемый отдел контроля качества(QA). Снова получается нет DevOps, QA “вывалился” из процесса.
“Релиз инженер”
Работает в команде разработки, участвует в спринтах, частично знает код и ревьювит его, следовательно погружен в разработку, сам он код так же может писать но более низком уровне чем разработчики его команды.
Знает что команда выпускает с точки зрения продукта, и передает информацию в QA и координирует их работу(в рамках продукта), как тестировать и что тестировать, сам естественно не пишет авто тестов, но полностью понимает кат работает тестирование.
Знает как деплоится продукт, какими средствами, на какие машины и как это все работает в бою, не следит за мониторингом за состоянием машин, но знает, как решать проблемы в работе компонентов, в идеале еще и сам деплоит в бой. Занимается всей автоматизацией.
В итоге вот звено которое связывает все процессы и команды участвующие в жизни продукта. И судя по моему опыту именно такой подход (с релиз инженером в команде) уменьшает процесс поставки до минимализма, при этом качество продукта ни сколько не страдает.
Стоит конечно сказать, что такие подходы актуальны для достаточно больших компаний, где много компонентов, команд и отделов. В компании в которой на текущий момент 5 человек, 1 разработчик и один системный администратор конечно пока это не нужно с этой ролью справится может и тот и тот.
И выше изложенного можно сказать, что позиция “DevOps инженер” на нашем рынке не более чем красивое модное название для системного администратора.
Посетив несколько из таких собеседований, был неприятно удивлен, один из ярких примеров — это вакансия “DevOps инженер” и таких вакансий много.
Примеры требований по данной позиции:
• Опыт работы с Linux виртуализацией на базе KVM от 3 лет
• Глубокие навыки и опыт администрирования и автоматизирования Linux сред
• Глубокие технические знания общих принципов работы операционных систем, обязательные знания ядра Linux;
• Опыт работы с bash и одним другим языком программирования (Желательно Python)
• автоматизацией изменений в инфраструктуре
• настройкой JIRA
• поддержкой масштабных Linux проектов
• ведением всего, что связано с puppet
• написанием скриптов на ruby, python или bash
• Опыт администрирования PostgreSQL, MySQL
• Знание аппаратных сред, аппаратных вычислительных ресурсов, систем хранения данных
• Разработка драйверов аппаратных средств в среде Linux
• Понимание взаимодействия между HW, операционной системой и приложениями в Linux
Это только несколько примеров указывать все нет смысла. Из всех описаний следует, что все это обязанности системного администратора высокого уровня (зависит от компании).
Итак, попытался разобраться подробнее на примере нескольких позиций, указанных собственно в заголовке поста.
Что есть DevOps?
Подробно описывать нет смысла, уже есть множество статей на эту тему, укажу основное, дабы не потерять мысль статьи. DevOps это не профессия и не должность, а подход к разработке, такой же как например Agile, следовательно и позиции “DevOps инженер” по моему мнению быть не может, либо это неправильное название.
Более понятным понятие DevOps сделает следующая картинка:
В жизненном цикле продукта существует несколько неотъемлемых этапов основные из них:
• разработка
• тестирование
• эксплуатация
Подход DevOps должен и призван сделать для всех участников все процессы прозрачными и минимизировать “пропасть” между разработкой, отделом контроля качества и эксплуатацией.
Решить проблему разрозненности отделов DevOps подходом бесспорно можно, но так же можно поставить в центр между всеми этими человека который и будет тем прозрачным элементом цепочки, процессов и отделов. И напрашивается вот же он “DevOps инженер”, решение проблемы. Посмотрев в описание вакансий на рынке, как-то не складывается.
“DevOps инженер“
На данной позиции требуют глубочайшие знания ОС(на уровне глубокого администрирования), ну еще пара вещей из категории администрирования, все это скорее из категории системного администрирования и эксплуатации.
А где требования по знаниям и опыту тестирования, где требования по знаниям хотя бы основ подходов к разработке, если только это подразумевается само собой, что врядли. Я был на собеседованиях и кроме вопросов по системному администрированию других не задают.
Из этого можно сделать вывод, что проблему разрозненности команд работодатель не решает, а “DevOps инженер” для него это всего лишь новое модное словечко и название для позиции системный администратор.
“Релиз инженер” и “Системный администратор в команде разработки”
“Системный администратор в команде разработки”. Данное звено в цикле разработки закрывает многое, к примеру он знает как работает продукт в бою, как протекает разработка, даже что покатится в ближайший релиз и как оно работает ну соответственно он знает куда он это будет разворачивать и как. Кажется что этого достаточно, но стоп а тестирование, так называемый отдел контроля качества(QA). Снова получается нет DevOps, QA “вывалился” из процесса.
“Релиз инженер”
Работает в команде разработки, участвует в спринтах, частично знает код и ревьювит его, следовательно погружен в разработку, сам он код так же может писать но более низком уровне чем разработчики его команды.
Знает что команда выпускает с точки зрения продукта, и передает информацию в QA и координирует их работу(в рамках продукта), как тестировать и что тестировать, сам естественно не пишет авто тестов, но полностью понимает кат работает тестирование.
Знает как деплоится продукт, какими средствами, на какие машины и как это все работает в бою, не следит за мониторингом за состоянием машин, но знает, как решать проблемы в работе компонентов, в идеале еще и сам деплоит в бой. Занимается всей автоматизацией.
В итоге вот звено которое связывает все процессы и команды участвующие в жизни продукта. И судя по моему опыту именно такой подход (с релиз инженером в команде) уменьшает процесс поставки до минимализма, при этом качество продукта ни сколько не страдает.
Стоит конечно сказать, что такие подходы актуальны для достаточно больших компаний, где много компонентов, команд и отделов. В компании в которой на текущий момент 5 человек, 1 разработчик и один системный администратор конечно пока это не нужно с этой ролью справится может и тот и тот.
И выше изложенного можно сказать, что позиция “DevOps инженер” на нашем рынке не более чем красивое модное название для системного администратора.