Это попытка сломать эту систему, но это не решение по своей сути. Нам нужна экономическая модель, в которой все ноутбуки будут собирать так, как ThinkPad до 2011 года.
… Там все будет бесплатно, там все будет в кайф
Там ноутбук вообще не будет умирать…
Товарищу хорошо бы ознакомиться с передовым опытом соц стран в производстве надежных товаров массового потребления, а заодно выучить такие слова как дефицит, блат, паек
У нас с вами разные полевые наблюдения. В тех реалиях что я вижу разработчиков
с опытом скорее дефицит, на проектах у них хватает задач и без погружения в чудесные практики devops.
И если их будут насильно заставлять этим заниматься супротив воли (например накинув в довесок поддержку инфры), то они скорее всего просто махнут лапкой.
Ситуации когда разработчики становятся девопс-инженерами тоже встречаются часто, но сугубо как говорил монтер Мечников — «при полном непротивлении сторон».
«И DevOps — это как раз про автоматизацию бизнеса в целом. Когда все процессы ведутся так, как будто бы это работа с кодом.»
Отвечу вашей же цитатой:
«а не пытаться нанимать людей с неопределённо широким кругом умений, и вешать на них неопределённо широкий круг задач… Как я уже сказал, эт ни фига не работает.»
Не знаю и не имею скиллов по автоматизации бухгалтерии, рассылки рекламы, раздачи пиццы на тимбилдингах и прочих таких вещах.
Можете оставить эти спецификации себе а нам несуществующим «девопс-инженерам» оставьте работу с «сугубо техническими вещами»
Меня наняли как девопс-инженера, платят зарплату как девопс-инженеру, собеседуют людей к нам в отдел как девопс-инженеров, заказчику представляют как девопс-инженеров.
Как мне себя еще называть? SRE? Потому что так Гугл хочет?
Я хотел бы в свою очередь понять как называется ваша лично должность, раз уж мы выяснили что devops evangelist это не профессия
Самое забавное что вовлеченность программиста в эти самые терраформы, CI/CD и проч опс части вполне себе соответствует духу «Devops как идеология» и не соответствует практике «Devops engineer как отд боевая единица».
Поэтому я не совсем понимаю нашего дорогого «Devops евангелиста» в том как он поможет бедным разрабам не делать то что они не хотят, просто сказав что «devops инженера» не бывает.
Ну не бывает ок. Кто то за него работу сделает и зарплату получит?
Согласен. Ситуации такие бывают.
Есть альтернатива — компании предоставляющие outsource девопс-инженеров (которых конечно же не существует) и почасовое участие в проектах.
Абсолютно согласен, коллега.
Но если идет трейдофф между срочностью (а он судя по всему идет, раз накликивать IAC через терраформ озадачили аж разраба) и удобством то жизнь внесет свои коррективы.
В любом случае ситуация когда IAC делает разработчик выглядит странной, и именно для этого существуют в том числе outsource devops компании имеющие людей с определенным набором скиллов (тех что на картинках выше)
«Недешевый» в плане стоимости человекочаса конечно же.
Мы же не говорим о случаях когда фирма вдруг внезапно решила одного из своих джунов озадачить IAC?
Если все же речь идет об условных мидл-сеньор девелоперах, то обычно их нанимают заниматься разработкой того самого программного продукта. Если отвлекать человека от этой безусловно важной задачи, то…
похоже у нас в компании переизбыток программистов, люди сидят на скамейке и мучаются чем бы себя занять?
Да, в такой ситуации напрячь кого-либо из программеров задачами выходящими за рамки его опыта и компетенций (то бишь IAC) выглядит как некое соломоново решение, потому что альтернатива это уволить этого бедного разработчика. Опять же я редко встречал такие ситуации, чаще всего для программиста находятся другие задачи по рефакторингу, разгребанию техдолга, допиливанию nice to have фич итд.
Несомненно ситуацию когда опытному разработчику дают не его стек исключить полностью нельзя, уверен такие случаи бывают. Но с другой стороны если бизнес готов платить за эти усилия, а человек сам не против этим позаниматься, то почему нет?
«Сложность» в данном конкретном случае мы рассматриваем Terraform как яркий пример хорошо задокументированного, популярного в своей нише, стабильного инструментария реализации IAC.
Это безусловно не требует таких мозговых усилий как имплементация бизнес логики, хотя конечно же особо хитрые кейсы с tf depends имеют место быть, но чаще всего новичок сделает простые модули без всяких зависимостей, и это БУДЕТ РАБОТАТЬ.
Прокливанием в консоли облака (уточняю) того что требовалось создать терраформом.
Для чего нужна видеозапись? В качестве инструкции. Для повторяемости, если времени разбираться с терраформом нет, а завтра нужно будет это же сделать другому человеку
Какие то абстрактные примеры в вакууме без контекста без ничего.
Что это за организация где полезного и недешового программиста заставляют заниматься относительно простыми вещами (терраформ абсолютно не требует гигантского опыта и довольно прост во вхождении)? Почему тратится время этого специалиста на такие задачи?
Я допускаю тот случай когда руководство подходит к программисту Пете и говорит «ты у нас теперь девопс, будешь меньше уделять времени коду и больше опс части».
Но тогда существуют вполне резонные способы решения «проблемы»:
— Петя может не согласиться и сказать что не в его интересах этим заниматься, и вместо Пети нанимается Вася или нанимается аутсорсер Коля
— Петя попал в мелкий стартап где еще не наняли админа а облачную инфру надо «вчера», при этом удивительно но он единственный человек с опытом в облачной инфре — решается прокликиванием в консоли, с захватом экрана и сохранением видео. Дальше Петя возвращается к своим программописательским делам
Пример с «админа заставляют писать некие инсталляторы» я правильно понял что речь идет о скриптах? Не о части бизнес-кода аппликаций разрабатываемых компанией?
Не знаю ничего насчет «неопределенно широкого круга умений», хотя работаю в outsource компаниях в кач-ве т.н. девопс-инженера уже несколько лет.
Еще ни разу бизнес не требовал от меня того, чего мне не хотелось бы делать, и что противоречило бы моим навыкам и умениям.
Если мне накинут задачу, например настраивать принтеры или тянуть патчкорды то бизнес слишком дорого заплатит за это, т.к. это будет стоить мое рабочее время согласно моей зарплате.
Если же, например, с другой стороны бизнес захочет чтобы я начал фиксить им их приложения, то опять же им это будет стоить слишком дорого так как я на проект не заходил как девелопер, их код не изучал и возможно вообще не практиковал программирование на их стеке несколько лет.
Чего мне стоит бояться? Того что вдруг на следующей неделе мне надо будет сконцентрироваться на CI/CD?
Или послезавтра посмотреть проблемы в AWS?
Где в приведенных выше рисунках, несмотря на то что к ним можно конечно же придраться, области требующие четкого разделения специалистов на какие-то сабкатегории?
Желательно с примерами: вот тут человек отвечает чисто за логи, вот этот за CI, а вот за кубернетис итд итп
Даже если такое разделение и бывает (например в рамках девопс-отделов), то скорее всего каждый из них в итоге заработает при прочих равных меньше чем универсальный солдат могущий быстро найти проблему или банально договориться с тем же девелопером посидеть подебажить вместе.
Резюмируя. Спасибо за заботу лично обо мне, но меня все устраивает.
В тех же случаях когда задача выглядит неадекватной, то в дело вступает мой менеджер умеющий указать заказчику на то что использовать лично меня на ней неэффективно.
А они как суслики, Devops-Евангелисты их не видят, но они есть.
Бизнесу так удобнее нанимать специалистов с определенными знаниями, и никакие (по моему конечно же скромному мнению) бессмысленные эвфемизмы типа SRE это все не вытеснили.
Если прямо сейчас на одном из израильских сайтов по поиску работы вбить словосочетание DevOps Engineer то выйдет порядка 50 упоминаний.
Если же вбить DevOps Evangelist то увы 0
Ядро NT в Windows обеспечивает такую степень обратной совместимости, долгосрочной поддержки и доступности драйверов, к которой Linux только приближается
А качество драйверов при этом становится лучше?
Расскажу свою кулстори:
У меня домашний ноут это Dell с Win10 — пришлось вручную переустановить несколько разных версий Realtek Audio Driver, так как одна из свежих версий дров неадекватно работала с парой наушники/микрофон. Микрофон хрипел, свистел и шипел.
В процессе пришлось изучать тонкости и особенности реалтековского драйвера под производителей ноутбуков.
Как бы справился человек на работающий в айти с этой нетривиальной и нудной задачей? Ждал патча? Отнес наушники в ремонт? Отменил важную встречу по зуму в связи с техническим форс мажором?
При этом MS настойчиво рекомендует обновиться до свеженькой но глючной версии дров, ну новое всегда лучшее не так ли?
сохранить совместимость, за которую платят корпоративные клиенты с критически важными приложениями
Если Microsoft при продаже OS обещал пожизненные гарантии на запуск любого клиентского ПО на любой версии будущих операционных систем то это скорее юридический казус. Наверняка такого не было, поэтому корпоративные клиенты будут иметь полное право оставаться на горячо любимых XP и 98 винде либо заказать разработку под новые ядра
ИМХО Cracking the coding Interview и есть пример такого подхода. Но опять же FANG это FANG, а какой-нибудь мелкий стартап или безымянная энтерпрайз галера скорее просто получат резко уменьшившийся поток кандидатов.
Duster от 912 т.р (АКПП уже 1млн 200т.р.)
New Duster от 945 т.р
… Там все будет бесплатно, там все будет в кайф
Там ноутбук вообще не будет умирать…
Товарищу хорошо бы ознакомиться с передовым опытом соц стран в производстве надежных товаров массового потребления, а заодно выучить такие слова как дефицит, блат, паек
с опытом скорее дефицит, на проектах у них хватает задач и без погружения в чудесные практики devops.
И если их будут насильно заставлять этим заниматься супротив воли (например накинув в довесок поддержку инфры), то они скорее всего просто махнут лапкой.
Ситуации когда разработчики становятся девопс-инженерами тоже встречаются часто, но сугубо как говорил монтер Мечников — «при полном непротивлении сторон».
Отвечу вашей же цитатой:
«а не пытаться нанимать людей с неопределённо широким кругом умений, и вешать на них неопределённо широкий круг задач… Как я уже сказал, эт ни фига не работает.»
Не знаю и не имею скиллов по автоматизации бухгалтерии, рассылки рекламы, раздачи пиццы на тимбилдингах и прочих таких вещах.
Можете оставить эти спецификации себе а нам несуществующим «девопс-инженерам» оставьте работу с «сугубо техническими вещами»
Как мне себя еще называть? SRE? Потому что так Гугл хочет?
Я хотел бы в свою очередь понять как называется ваша лично должность, раз уж мы выяснили что devops evangelist это не профессия
Поэтому я не совсем понимаю нашего дорогого «Devops евангелиста» в том как он поможет бедным разрабам не делать то что они не хотят, просто сказав что «devops инженера» не бывает.
Ну не бывает ок. Кто то за него работу сделает и зарплату получит?
Есть альтернатива — компании предоставляющие outsource девопс-инженеров (которых конечно же не существует) и почасовое участие в проектах.
Но если идет трейдофф между срочностью (а он судя по всему идет, раз накликивать IAC через терраформ озадачили аж разраба) и удобством то жизнь внесет свои коррективы.
В любом случае ситуация когда IAC делает разработчик выглядит странной, и именно для этого существуют в том числе outsource devops компании имеющие людей с определенным набором скиллов (тех что на картинках выше)
Мы же не говорим о случаях когда фирма вдруг внезапно решила одного из своих джунов озадачить IAC?
Если все же речь идет об условных мидл-сеньор девелоперах, то обычно их нанимают заниматься разработкой того самого программного продукта. Если отвлекать человека от этой безусловно важной задачи, то…
похоже у нас в компании переизбыток программистов, люди сидят на скамейке и мучаются чем бы себя занять?
Да, в такой ситуации напрячь кого-либо из программеров задачами выходящими за рамки его опыта и компетенций (то бишь IAC) выглядит как некое соломоново решение, потому что альтернатива это уволить этого бедного разработчика. Опять же я редко встречал такие ситуации, чаще всего для программиста находятся другие задачи по рефакторингу, разгребанию техдолга, допиливанию nice to have фич итд.
Несомненно ситуацию когда опытному разработчику дают не его стек исключить полностью нельзя, уверен такие случаи бывают. Но с другой стороны если бизнес готов платить за эти усилия, а человек сам не против этим позаниматься, то почему нет?
«Сложность» в данном конкретном случае мы рассматриваем Terraform как яркий пример хорошо задокументированного, популярного в своей нише, стабильного инструментария реализации IAC.
Это безусловно не требует таких мозговых усилий как имплементация бизнес логики, хотя конечно же особо хитрые кейсы с tf depends имеют место быть, но чаще всего новичок сделает простые модули без всяких зависимостей, и это БУДЕТ РАБОТАТЬ.
Для чего нужна видеозапись? В качестве инструкции. Для повторяемости, если времени разбираться с терраформом нет, а завтра нужно будет это же сделать другому человеку
Что это за организация где полезного и недешового программиста заставляют заниматься относительно простыми вещами (терраформ абсолютно не требует гигантского опыта и довольно прост во вхождении)? Почему тратится время этого специалиста на такие задачи?
Я допускаю тот случай когда руководство подходит к программисту Пете и говорит «ты у нас теперь девопс, будешь меньше уделять времени коду и больше опс части».
Но тогда существуют вполне резонные способы решения «проблемы»:
— Петя может не согласиться и сказать что не в его интересах этим заниматься, и вместо Пети нанимается Вася или нанимается аутсорсер Коля
— Петя попал в мелкий стартап где еще не наняли админа а облачную инфру надо «вчера», при этом удивительно но он единственный человек с опытом в облачной инфре — решается прокликиванием в консоли, с захватом экрана и сохранением видео. Дальше Петя возвращается к своим программописательским делам
Пример с «админа заставляют писать некие инсталляторы» я правильно понял что речь идет о скриптах? Не о части бизнес-кода аппликаций разрабатываемых компанией?
Еще ни разу бизнес не требовал от меня того, чего мне не хотелось бы делать, и что противоречило бы моим навыкам и умениям.
Если мне накинут задачу, например настраивать принтеры или тянуть патчкорды то бизнес слишком дорого заплатит за это, т.к. это будет стоить мое рабочее время согласно моей зарплате.
Если же, например, с другой стороны бизнес захочет чтобы я начал фиксить им их приложения, то опять же им это будет стоить слишком дорого так как я на проект не заходил как девелопер, их код не изучал и возможно вообще не практиковал программирование на их стеке несколько лет.
Чего мне стоит бояться? Того что вдруг на следующей неделе мне надо будет сконцентрироваться на CI/CD?
Или послезавтра посмотреть проблемы в AWS?
Где в приведенных выше рисунках, несмотря на то что к ним можно конечно же придраться, области требующие четкого разделения специалистов на какие-то сабкатегории?
Желательно с примерами: вот тут человек отвечает чисто за логи, вот этот за CI, а вот за кубернетис итд итп
Даже если такое разделение и бывает (например в рамках девопс-отделов), то скорее всего каждый из них в итоге заработает при прочих равных меньше чем универсальный солдат могущий быстро найти проблему или банально договориться с тем же девелопером посидеть подебажить вместе.
Резюмируя. Спасибо за заботу лично обо мне, но меня все устраивает.
В тех же случаях когда задача выглядит неадекватной, то в дело вступает мой менеджер умеющий указать заказчику на то что использовать лично меня на ней неэффективно.
Бизнесу так удобнее нанимать специалистов с определенными знаниями, и никакие (по моему конечно же скромному мнению) бессмысленные эвфемизмы типа SRE это все не вытеснили.
Если прямо сейчас на одном из израильских сайтов по поиску работы вбить словосочетание DevOps Engineer то выйдет порядка 50 упоминаний.
Если же вбить DevOps Evangelist то увы 0
А качество драйверов при этом становится лучше?
Расскажу свою кулстори:
У меня домашний ноут это Dell с Win10 — пришлось вручную переустановить несколько разных версий Realtek Audio Driver, так как одна из свежих версий дров неадекватно работала с парой наушники/микрофон. Микрофон хрипел, свистел и шипел.
В процессе пришлось изучать тонкости и особенности реалтековского драйвера под производителей ноутбуков.
Как бы справился человек на работающий в айти с этой нетривиальной и нудной задачей? Ждал патча? Отнес наушники в ремонт? Отменил важную встречу по зуму в связи с техническим форс мажором?
При этом MS настойчиво рекомендует обновиться до свеженькой но глючной версии дров, ну новое всегда лучшее не так ли?
Если Microsoft при продаже OS обещал пожизненные гарантии на запуск любого клиентского ПО на любой версии будущих операционных систем то это скорее юридический казус. Наверняка такого не было, поэтому корпоративные клиенты будут иметь полное право оставаться на горячо любимых XP и 98 винде либо заказать разработку под новые ядра
Что тоже смешно