Comments 22
Многие, кто изучает DevOps, ориентируются на Roadmap.sh. Но в нём очень много информации, начинающие специалисты рискуют утонуть в деталях.
Так там же кнопочкой можно переключить на Beginner View - https://roadmap.sh/devops?r=devops-beginner
За пять месяцев? И тераформ и кубернетис, и остальное? Там на один линукс только апгрейдиться минимум полгода, наверное. Что за темп, интересно, будет.
Да, вы верно заметили, что там интенсивный темп. Поэтому заранее настраиваем студентов на то, что это «курс с высокой нагрузкой» :)
Мы думаем о том, чтобы некоторые темы рассмотреть подробнее, но тогда придётся растягивать учёбу, жертвовать чем-то другим или увеличить цену. Это может быть неприемлемо для других.
Может быть, в скором будущем DevOps Upgrade тоже ждёт какой-нибудь свой upgrade. Но пока мы видим этот баланс именно таким. Расчёт на то, что студент получает неплохой буст и базу, которая помогает ему понять свои собственные пробелы, задать себе правильные вопросы и без особых сложностей нарастить скиллы по этим темам. Либо самостоятельно, либо, взяв отдельный курс по инструменту.
Если не удалось без гугла вспомнить хотя бы треть этих команд
Когда переходил в devops прочитал целиком книжку по гиту пробую чуть ли не каждый пример из неё. Попав на работу, оказалось что кроме базовых команд ничего остальное и не нужно...
Бывает и так. За это время задачи по работе с Git'ом вообще не усложнялись?
Смотря что под этим считать.
Как можно усложнить задачи по созданию/удалению веток, МР и коммитов?)
добавить хуки / авторебейз / слияние нескольких веток / автооткаты и прочее)
Это все давно делается не в гите, а в каком-нить битбакете.
Современные девелоперы вообще не знают о том, что гит и система код ревью - это два отдельных продукта.
да ну) наверняка знают) зачем бы им не знать этого?)
Ну давайте так. У себя на работе сделайте опрос, как в гите сделать pull request, и посморите кто начнет думать над командой, а кто сразу скажет что гит это не умеет. Поделитесь результатами.
У меня то выборка из примерно 200 собеседований... и ОЧЕНЬ мало видят разницу, я даже перестал сильно реагировать на это незнание.
Я не девопс, но абсолютно тоже самое делаю в автоматизации... Насколько теперь расплылись границы кто есть кто
Ходил на подобные курсы, дали мне неплохой буст, которого хватило, чтобы устроиться системным инженером по линуксу. Но объективно сильно горел с темпа обучения - неделя на модуль терраформ, неделя на модуль ансибл.
Выбился из темпа, но терраформ учил последовательно больше месяца, как итог курс не закончил, но востребованные навыки получил...
С тех пор мое мнение о "пятимесячных курсах" резко отрицательное, заявленные сроки для такой специализации - полный отстой.
Выбиваешься из сроков бумажку не получаешь. Имеем конфликт интересов - либо пашем на бумажку, либо забиваем на бумажку и пашем на знания.
либо пашем на бумажку, либо забиваем на бумажку и пашем на знания
Респект за фразу.
А вы с каким бэкграундом приходили на курс? Был уже какой-то опыт?
Если отмотать время назад, то сейчас как бы вы поступили: поискали курс с более длительным обучением или брали бы несколько маленьких по нужным инструментам? Или как-то иначе?
Для DevOps должна быть не Roadmap, а Playbooks - как развернуть специалиста из студента / разраба / системного администратора (что "установить"). Это было бы антуражнее для статьи.
Сарказм =)
Вообще, в энтерпрайзе, меня отпугивает требование для некоторых девопс уметь прям в настоящее сетевое администрирование, хотя это прям отдельная ветка со своими сертификатами и неочевидными приколами на конкретных сетевых железках и под эту ветку точат свои навыки отдельные специалисты. Фаервол - это только пол "беды". Понятно, что такой спрос с девопса не везде, но на мой взгляд это оправданно.
Ну, в идеале, девопс должен понимать сетевой стек. Но в крупных компаниях, обычно, есть и сисадмины и дба и нетопс и много других опсов. Суть девопса понимать, хотябы, немножко, на миддл уровне, во всех этих сферах и соединять ВСЕ структуры.
Т.е. девопс ДОЛЖЕН объяснить что и как нужно. Как это будет реализовано -- задача этих опсов.
Спасибо за ваш труд и проделанную работу, только боюсь, что от неё больше вреда чем пользы. Это больше напоминает гайд по силовым проводам, электрическим щиткам и изолентам для электриков. К сожалению, нет ни слова о законах электротехники. Девопс это не набор инструментов - это методология. Инструменты перечислили (те самые провода различного сечения, электрические щитки, защитные автоматы), хотя многие довольно спорные, только о самом главном ни слова (законы электротехники).
Вы пишите, почти поголовно все твердят, что девопс - это про автоматизацию. Разве только про неё? А как же культура, средства измерения и взаимодействие (culture, automation, measurement, sharing)? Сколько читаю статей, об этом практически не слова, только без этого никуда. DevOps - это совсем не про Kubernetes и микросервисы его никак не касаются, это про взаимодействие между отделами разработки и эксплуатации. И человек приходящий к разработчикам, должен уметь разговаривать с ними на их языке (а они редко говорят про микросервисы), а когда приходит в отдел эксплуатации должен уметь общаться на языке этого отдела - те самые culture и sharing.
Также не по себе становится, когда во время беседы узнаёшь, что человек, реализующий эту методологию не знает такие вещи как "12 Factors" и такой подход как "Инфраструктура как код", не говоря уже различиях между процедурной и декларативной реализациях.
Другой момент, почему почти во всех статьях про девопс красной нитью, если архитектура, то микросервисная? Ну во-первых, надо ещё посмотреть насколько микросервисный этот распределённый монолит (в подавляющем числе случаев). Во-вторых, почему не сервис ориентированная или событийно ориентированная архитектуры? Тоже очень распространены. Почему, если девопс, то сразу кубернетес? Есть довольно неплохой serverless подход, причём, с заметно низким порогом входа, чем в случае с кубернетес. Кубернетес это про высокую доступность сервисов, но у многих облачных провайдеров из коробки куча инструментов для обеспечения высокой доступности и их часто достаточно для многих проектов. Тем более девопс - это про облачные решения, когда специалист больше занимается продуктом, а не поддержкой и настройкой серверов.
В целом неплохой roadmap. Сам когда-то входил в профессию. Путь у большинства в общем то как обычно или из разработки, или из администрирования. Видел бывших сотрудников технической поддержки. Что касается обучения, увы нельзя объять необъятное, тем более в весьма сжатые сроки. Базовые вещи в тех, в которых практически нет компетенций, познать думаю можно, но всё решает опыт. Что можно сказать достаточно уверенно, опираясь на опыт, очень большое значение имеют софт скилы. При прочих равных, более открытый и общительный специалист будет предпочтительнее. Ему взаимодействовать с РП, с командой разработки, возможно с бизнесом. Эту часть профессии тоже не стоит забывать.
Роадмап хороший для энтузиастов, наверное, пару команд изучить и понять для чего нужны, а так всем компаниям нужны именно линукс админы.
Roadmap для тех, кто собирается в DevOps