Согласен с комментатором ниже, что всё зависит от масштаба. Скорее всего, в Вашем случае, масштаб, как мне кажется, совсем небольшой, т.к. для меня, например, странно слышать, что разработчик "рассказывает о потребностях бизнеса" админу, как и то, что он также "настраивает кластер, заводит квоты, масштабирует, доступы ограничивает" и т.п. А кодит-то этот разработчик когда? Разработка — это же творческая работа, для написания качественного кода требующая соответствующего настроя, погружения в процесс, нахождения в определённом состоянии и т.п. Все эти вхождения, погружения, настрой требуют времени, поэтому постоянное выпадание из процесса разработки очень сильно влияет и на производительность, и на качество кода. Скажем так, "забивание гвоздей микроскопом" позволительно на небольших масштабах.
Кстати, Ваш опыт яркий пример того, что в девопс часто приходят из дева.
Я же пытаюсь Вам донести, что в любом коллективном действии без человека, который это действие колективное возглавляет, получается "колхоз". Согласен, выражался я иносказательно, если Вы это не поняли, назвав это всё Лебедем, Раком и Щукой.
Хочу ещё добавить, что когда такой инженер по внедрению devops-практик или для краткости — devops-инженер начинает непосредственно эти практики внедрять, он становится в прямом смысле влиятельным субъектом, потому что начинает влиять на многие процессы. Иногда особо ранимым девам или опсам трудно это пережить. От сюда и занудство крайней степени, и хайп по поводу зарплат.
Следуя Вашей логике получается проджект-менеджер есть, а проекта как такового нет. Одна копи-паста безумная. Ну а что, проект — это же совместная работа нескольких подразделений. Не может этим заниматься один человек. Далее по ходу пьесы (зачем-то) следует перечисление ролей, которые он выполняет. Это в первом случае.
Во втором случае Вы описали Лебедя, Рака и Щуку.
Ну, и информация для размышления касательно обоих случаев: как Вы считаете, выстраивание какого-либо процесса (с дальнейшим его поддержкой, развитием, изменением и т.п.) с одной стороны и участие в самом этом процессе с другой стороны — суть одно и то же или всё-таки разное?
Полностью согласен по поводу "грамотного спеца", а также, что "деньги там платятся далеко не просто так". Только, может, всё-таки не "грамотный спец", а devops-инженер?
Ни в коем случае не хотел Вас в чём-то переубедить. Хотел всего лишь понять, как выражение "Devops — это методология" обосновывает утверждение "Нет людей devops-инженеров". (При этом devops-евангелисты почему-то всё-таки есть.) ???
Далее мне вот, ещё что не понятно. Почему из факта владения devops-инженером необходимыми для выстраивания процессов по методологии devops инструментами делается вывод, что "основу ее (методологии) составляют далеко не инструменты"? Тем самым, как я понял, подразумевается, что devops-инженером незаслуженно называют человека, просто владеющим определёнными инструментами. Согласитесь, что, если devops-инженер, не будет владеть соответствующими инструментами, то и процессы он необходимым образом выстроить не сможет. Это же очевидно.
Я бы сказал так, devops-инженер — это не только про инструменты. Инструменты — суть необходимое условие для devops-инженера, но недостаточное. Это же тоже очевидно.
Конечно, если видеть в devops-инженере только инструменты, то могут возникнуть вопросы. Но только чьи это проблемы-то: devops-инженера или того, кто до конца не разобрался и так видит?
И ещё. А почему сисадмин-то? Почему не разработчик? В слове devops "dev" стоит на первом месте, между прочим.
Я недавно был в Пушкинском музее на выставке коллекции картин импрессионистов Щукина. Картины очень дорогие. Вот, теперь в замешательстве. Получается, нет никаких импрессионистов. Импрессиониизм — это же направление в искусстве, а не человек. Подождите, может, инструменты у них какие-то особенные? Да, вроде, нет — обыкновенные: кисти, краски. Значит, они всё-таки — просто художники. Подождите. А, может, и художников тоже нет, а все эти люди на самом деле — обыкновенные моляры? У тех тоже инструменты — кисти и краски.
А такая высокая стоимость картин этих моляров — это всё из-за хайпа.
Выскажу сугубо своё личное мнение.
Могу предположить, что если бы зарплаты devops-инженеров были ниже зарплат Девов или Опов, такого хайпа бы не было.
Какая-то неделя зависти к зарплатам devops-инженеров на Хабре.
Нет людей devops-инженеров. Devops — это методология.
Тогда, следуя Вашей логике:
Нет людей android-разработчиков. Android — это операционная система. Нет?
Девопс — это методология направленная на ускорение поставки "инкремента" путем сращивания процессов разработки, operations и на самом деле многих других подразделений. Выставления общих целей.
Так чем должен заниматься devops-евангелист при таком подходе?
Черепаху тоже надо было делать деревянной. :)
Не пойдут на лейтенантские должности генералы. Как не крути. Либо должность должна быть генеральской, либо выращивать генерала надо самим.
Давайте подойдём с другой стороны. :)
"Не пользоваться" не значит "не владеть".
Возглавить — это в первую очередь про ответственность.
Согласен с комментатором ниже, что всё зависит от масштаба. Скорее всего, в Вашем случае, масштаб, как мне кажется, совсем небольшой, т.к. для меня, например, странно слышать, что разработчик "рассказывает о потребностях бизнеса" админу, как и то, что он также "настраивает кластер, заводит квоты, масштабирует, доступы ограничивает" и т.п. А кодит-то этот разработчик когда? Разработка — это же творческая работа, для написания качественного кода требующая соответствующего настроя, погружения в процесс, нахождения в определённом состоянии и т.п. Все эти вхождения, погружения, настрой требуют времени, поэтому постоянное выпадание из процесса разработки очень сильно влияет и на производительность, и на качество кода. Скажем так, "забивание гвоздей микроскопом" позволительно на небольших масштабах.
Кстати, Ваш опыт яркий пример того, что в девопс часто приходят из дева.
Вот, согласен полностью.
По-моему, ответственность — это даже в первую очередь.
Я бы сказал так, хайп поднимают исполнители, не понимающие роль руководителя.
Собака лает, а караван идёт.
Не, ну, если выстраивание паплайнов — суть девопс, кто ж будет с Вами спорить.
Я же пытаюсь Вам донести, что в любом коллективном действии без человека, который это действие колективное возглавляет, получается "колхоз". Согласен, выражался я иносказательно, если Вы это не поняли, назвав это всё Лебедем, Раком и Щукой.
Хотел бы заметить, что в слове "девопс" кроме "опс" есть ещё и "дев", причём на первом месте. :)
"Понедельник начинается в субботу".
Вот, согласен со всем полностью.
Хочу ещё добавить, что когда такой инженер по внедрению devops-практик или для краткости — devops-инженер начинает непосредственно эти практики внедрять, он становится в прямом смысле влиятельным субъектом, потому что начинает влиять на многие процессы. Иногда особо ранимым девам или опсам трудно это пережить. От сюда и занудство крайней степени, и хайп по поводу зарплат.
Это ошибка. Владеть и пользоваться — суть разные вещи.
Следуя Вашей логике получается проджект-менеджер есть, а проекта как такового нет. Одна копи-паста безумная. Ну а что, проект — это же совместная работа нескольких подразделений. Не может этим заниматься один человек. Далее по ходу пьесы (зачем-то) следует перечисление ролей, которые он выполняет. Это в первом случае.
Во втором случае Вы описали Лебедя, Рака и Щуку.
Ну, и информация для размышления касательно обоих случаев: как Вы считаете, выстраивание какого-либо процесса (с дальнейшим его поддержкой, развитием, изменением и т.п.) с одной стороны и участие в самом этом процессе с другой стороны — суть одно и то же или всё-таки разное?
Полностью согласен по поводу "грамотного спеца", а также, что "деньги там платятся далеко не просто так". Только, может, всё-таки не "грамотный спец", а devops-инженер?
Ни в коем случае не хотел Вас в чём-то переубедить. Хотел всего лишь понять, как выражение "Devops — это методология" обосновывает утверждение "Нет людей devops-инженеров". (При этом devops-евангелисты почему-то всё-таки есть.) ???
Далее мне вот, ещё что не понятно. Почему из факта владения devops-инженером необходимыми для выстраивания процессов по методологии devops инструментами делается вывод, что "основу ее (методологии) составляют далеко не инструменты"? Тем самым, как я понял, подразумевается, что devops-инженером незаслуженно называют человека, просто владеющим определёнными инструментами. Согласитесь, что, если devops-инженер, не будет владеть соответствующими инструментами, то и процессы он необходимым образом выстроить не сможет. Это же очевидно.
Я бы сказал так, devops-инженер — это не только про инструменты. Инструменты — суть необходимое условие для devops-инженера, но недостаточное. Это же тоже очевидно.
Конечно, если видеть в devops-инженере только инструменты, то могут возникнуть вопросы. Но только чьи это проблемы-то: devops-инженера или того, кто до конца не разобрался и так видит?
И ещё. А почему сисадмин-то? Почему не разработчик? В слове devops "dev" стоит на первом месте, между прочим.
Я недавно был в Пушкинском музее на выставке коллекции картин импрессионистов Щукина. Картины очень дорогие. Вот, теперь в замешательстве. Получается, нет никаких импрессионистов. Импрессиониизм — это же направление в искусстве, а не человек. Подождите, может, инструменты у них какие-то особенные? Да, вроде, нет — обыкновенные: кисти, краски. Значит, они всё-таки — просто художники. Подождите. А, может, и художников тоже нет, а все эти люди на самом деле — обыкновенные моляры? У тех тоже инструменты — кисти и краски.
А такая высокая стоимость картин этих моляров — это всё из-за хайпа.
Выскажу сугубо своё личное мнение.
Могу предположить, что если бы зарплаты devops-инженеров были ниже зарплат Девов или Опов, такого хайпа бы не было.
Какая-то неделя зависти к зарплатам devops-инженеров на Хабре.
Тогда, следуя Вашей логике:
Нет людей android-разработчиков. Android — это операционная система. Нет?
Так чем должен заниматься devops-евангелист при таком подходе?
Девопс — это методология, однако, devops-евангелисты есть, а devops-инженеров нет.