Комментарии 18
Зачем ещё раз пережёвывать одно и тоже вручную? Уже давно есть GPT-3, и она про "это методология" может писать гигабайтами и не напрягаться.
Развернуть приложение в kubernetes несравнимо сложней, чем развернуть сайт на LAMP. А потому разрабатываемым проектам нужны эксплуатационные специалисты, у которых будет знание как последних технологий, так и базовых инструментов и принципов, на которых они построены.
И откуда же, по-вашему, начинающие девопсы получат опыт работы с, как вы это называете, «базовыми инструментами», если всем работодателям подавай высокоуровневые абстракции?
Получается, хорошим девопсом можно стать, только набрав опыт на инфраструктуре без использования «модных» технологий, а затем захотев объять и их? Много вы таких знаете, выросших из админов, а не пришедших сразу в облака и Ансибл с Терраформом?
И откуда же, по-вашему, начинающие девопсы получат опыт работы с, как вы это называете, «базовыми инструментами», если всем работодателям подавай высокоуровневые абстракции?
Получается, хорошим девопсом можно стать, только набрав опыт на инфраструктуре без использования «модных» технологий, а затем захотев объять и их?
Именно так. Без базовых навыков администрирования, все высокие технологии рано или поздно наткнутся на низкоуровневую ошибку, которую не победить, не понимая что находится под ними.
Много вы таких знаете, выросших из админов, а не пришедших сразу в облака и Ансибл с Терраформом?
Честно говоря, большинство. Я не уверен, что смогу назвать девопсов, которые стартанули "с места в карьер", без какого-то опыта администрирования.
что интересно - я знаю достаточное (но не многое!) количество "devops", выросших из разработки, которым интересно было - как же их система работает. Поэтому, во-первых, не нужно говорить, что девопсы получаются из опсов. Во-вторых, как выше правильно было замечено - нет такого, как девопс инженер. Я уже приводил аналогию. Если девопс - это философия и методология, то давайте разработчиков уж называть "канбан-разработчик", "agile-разработчик"... и прочее
что интересно - я знаю достаточное (но не многое!) количество "devops", выросших из разработки, которым интересно было - как же их система работает. Поэтому, во-первых, не нужно говорить, что девопсы получаются из опсов.
Я тоже знаю пару девопсов, которые выросли из разработки. Так что вы правы, может и не из опсов, что не отменяет необходимости учить "базу".
Во-вторых, как выше правильно было замечено - нет такого, как девопс инженер. Я уже приводил аналогию. Если девопс - это философия и методология, то давайте разработчиков уж называть "канбан-разработчик", "agile-разработчик"... и прочее
Тут проблема в том, что понятие DevOps "пошло в народ". Если посмотреть вакансии по ключевому слову DevOps, большая часть будет не про методологию и трансформацию процессов взаимодействия, а про опсов с конкретным набором технологий.
Я потому и взялся за эту статью - под словом DevOps разные люди подразумевают слишком разные вещи, и мне захотелось посмотреть на путь понятия. Откуда взялось, чем стало в коллективном бессознательном :)
Тут проблема в том, что понятие DevOps "пошло в народ". Если посмотреть вакансии по ключевому слову DevOps, большая часть будет не про методологию и трансформацию процессов взаимодействия, а про опсов с конкретным набором технологий.
варианты:
инженер по клаудам
инженер мониторинга
релиз инженер
инженер поддержки (в целом)
сантехник (оке, build engineer или прочищальщик пайплайнов)
...
легион их
Я уж не говорю о том, что часто под вывеской "DevOps engineer" идет вакансия типикал админа, просто с новой лычкой, чтобы не отставать от трендов (и, да, платят конкурентно, но точно так же придется ковыряться в паппете, искать узкие места в базульках и линуксах)
Как сказал один мой хороший высокооплачиваемый друг девопс (больше 120к после налогов) - джуниор девопсов не бывает. Прийти ты можешь откуда угодно, если из сетей - то учи программирование, если из разработки, то сеть. Но это все ямл писатель пайплайнов если ты не овнеришь/участвуешь в процессах улучшения процессов в компании.
Куча бывших админов из ops просто не могут больше. Их и нанимают на «девопс, надо что бы сервера и сеть»
ну и да это фигня все. Девопсы по большей части все же разработчики. Про
сеть например фигня, в крупной компании тебя никто к сети не подпустит.
Да тебе даже тот же Кубер будет нужен только на самом верхнем уровне.
Потому что админить его будут совсем другие инженеры. А у тебя прав не
будет.
Т.е. по вашему разработчик не должен понимать технологии с которыми работает? Полагаю, что примерно с такими мыслями, разработчики uTorrent изобретали свой мега-протокол, который до внесения исправлений укладывал провайдерские сети.
Давайте не будем сразу в крайности бросаться =). Я вижу что у вас своя личная война с сетями, но постарайтесь быть объективнее.
В общем виде, знание сетей (и других смежных областей) разработчику или DevOps-у нужно хотя бы на уровне - продиагностировать проблему и выдать корректную задачу узкому специалисту. Как максимум самому влезть и починить, т.к. обычные проблемы с сетью на стенде это уровень ccna.
Что касается разработчика мобильных приложений. Если эти приложения работают с сетью, то разработчику придется погрузиться в эту предметную область и знать как работают используемые им протоколы и также учитывать особенности используемых каналов связи. Иначе может получиться как с uTorrent, когда они переизобретали tcp поверх udp.
То же касается и других смежных предметных областей.
Когда закончились аргументы, то дело стало не в сетях и появились новые "удивительные истории" не по теме? Ясно. Понятно =).
Напоминаю что беседа началась вот с этого сообщения https://habr.com/ru/company/X5Group/blog/652387/comments/#comment_24092751
Что же касается вот этого:
Возвращаясь к uTorrent. Что они сделали в целом плевать, просто потому что это самый спешный Torrent клиент. Важен результат, а не путь к нему.
Это был пример того, как при игнорировании смежных предметных областей, можно усложнить себе путь, вплоть до невозможности дойти его до конца. Ребята не "топали ножкой" как вы, а вникли таки в сети и исправили свою разработку. Видимо поэтому у них самое успешное приложение, а вы жалуетесь в интернете, что с вас много требуют и пытаетесь увести цель беседы куда-то в сторону каждый раз.
Когда им это потребовалось и возникла реальная проблема. А не когда "Ой надо все знать может пригодится"
Тут не должен был вставать вопрос насчет пригодится, т.к. сетевой протокол же делали =).
Это называется недостаточная подготовка к работе. При систематическом подходе будет называться уже разгильдяйством.
Почему то большей частью сталкиваюсь с девопсами, которые задают вопросы типа: у нас не работает скрипт из джобы, падает с ошибками "python3 error while loading shared libraries: libpython... cannot open shared object file. No such file or directory" или немогу в контейнере посмотреть логи, там пишет "cd /logs Permission denied". Зато знают как настроить новую джобу в jenkins (не экзотика, просто запросить новую сборку из git).
Неполное руководство по DevOps