Относительно неплохое начало, но чем дальше читал — тем больше «скрежетал мозг».
Не знаю зачем это пишу, просто делюсь мнением, возможно будет интересен взгляд со стороны инженера.
Технические моменты:
Не «CitHub Actoinс», а «GitHub Actions»
Для контейнеризации не «OpenStack», а «OpenShift»
Лингвистические:
«Откуда есть быть пошли и пришли...»
АААА… кхм… иногда хочется чтобы KISS применялся не только в проектировании
Поведенческие:
«Девопс-инженеры… будем называть их так. Потому что деваться им некуда… Придется им смириться»
А с какого такого, простите, невероятного события «деваться им некуда» и «придется им смириться»?
Подход, в котором кто-либо решает за группу людей, к которой никакого отношения не имеет — вызывает только отторжение.
"… мы с вами не инженеры и углубляться не будем."
Не хотите разбираться в спцифике найма определённых специалистов — и не надо, дело ваше.
Такое ощущение создаётся что "углубляться" это тлен и он только для инженеров
Субъективное мнение о том, что выглядит иллюзорным:
«Первая и самая многочисленная группа: бывшие и действующие системные администраторы. Им проще всего: освоили доп. инструменты и готово.»
Освоили доп. инструменты и готово? Ну-ну.
Во первых инструментов сотни. Во вторых — каждый со своей спецификой. В третьих — сильно влияет глубина, на которую необходимо погружаться.
И самое важное тут — системные администраторы очень разные.
Кто-то админит десяток сервисов, кто-то тысячи. Кто-то на десятках серверов, а кто-то на сотнях и более. Кто-то умеет обеспечивать HighLoad, а кто-то даже не сталкивался с этим.
И это далеко не всё. И по каждому нужно принимать решение исходя из контекста конкретного проекта.
«Вторая группа: разработчики, которые решили уйти в девопс-практики. Их меньше, им нужно осваивать линукс и админство.»
Почти всем разрабам, кто запускает приложения в контейнерах и/или на linux-серверах приходится знать ряд нюансов работы Linux-систем. Так что момент спорный.
По поводу админства промолчу, т.к. не знаю какой смысл вложен в этот термин.
При этом, не раз встречал сильных системных инженеров, пришедших из разработки в SRE. С точки зрения глубины (в т.ч. Linux систем) познания часто лучше, чем у среднего админа (увы, с кругозором не всегда также хорошо).
«Третья группа: “я проснулся и понял, что это — мое” — ребята, прошедшие курсы “Девопс за 3 недели” или что-то более внятное.»
"… нет опыта и понимания ни в администрировании, ни в разработке"
и тут же
«Есть фраза: учил на курсах… — это студент.»
Курсы в IT это уже часть посведневности. Даже senior инженеры и архитекторы их проходят.
Тут ключевой момент что на middle и senior позицию человека, без опыта, в принципе не рассматривают.
А человек прошедший «Linux за 3 недели, Сети за 3 недели, DevOps за 3 недели» (в идеале с кейсами и практикой)- интересный на рассмотрение джун, мотивированный развиваться.
Блок «Джун-миддл-синьор» — крайне субъективный.
Пожалуй скажу что ожидание «может поставить все девопс-практики с 0» — слишком оптимистично.
Ставить (внедрять) организационную структуру это больше про Team Lead и в целом руководителей.
Задача senior специалистов (как я это привык видеть) — быть способным разобраться в любой задаче конкретного стека (а где-то даже и смежных) и решить её.
«Должно быть:
GitLab, GitLabCI, Ansible, Docker, Terraform, Zabbix, KVM, MySQL and PostgreSQL, Prometheus, Grafana, ELK-стек, Jenkins, K8S/Kubernetes, AWS\Azure\GCP/Яндекс-облако/Mail Cloude.
Это — девопс.»
М… нет, это перечень инструментов и технологий, большая часть из них существует и используется без всякого DevOps.
«Есть что-то из этого и слова Windows 7\8\10\Server 2012\Server 2016 и п.р. — бывший админ винды.»
почему бывший?
Винда до сих пор актуальна в ряде проектов. И даже больше скажу, если говорить о виндовом облаке — CI/CD там тоже есть (привет, Azure Pipelines!).
«Azure...GCP, AWS и пр. — это облака… С облаками работают не все.
Девопс, не работающий с облаками — это девопс, работающий в закрытом контуре, ЦОД, ДЦ и пр. Ему нужно развиваться =) За облачными технологиями — будущее.»
Что, правда? А кто будет тогда обслуживать эти самые облака изнутри? (тут вот можно написать про OpenStack)
Да и потом, не говоря о бэкенде облаков и внутренних облаках (о которых умалчивается), есть множество проектов, где облачные технологии вообще не нужны.
Облака, если грубо обобщать — сервис выделения мощностей оборудования пользователям.
Если компания не предоставляет услуги по использованию каких-либо мощностей (внутри компании или внешним клиентам) — облаков там может не быть и на качество сервисов это не повлияет.
Из того, что понравилось:
Задумка. Донести до коллег-рекрутеров чуть больше про инженеров и нюансы их найма это хорошо.
Условия, стек, вилка и бонусы это действительно важно.
Фидбек — крайне важен, особенно когда его запрашивают.
Искренне желаю успехов как в найме инженеров, так и в дальнейшем изучении нюансов IT индустрии.
Ваш senior system engineer.
Не знаю зачем это пишу, просто делюсь мнением, возможно будет интересен взгляд со стороны инженера.
Технические моменты:
Лингвистические:
АААА… кхм… иногда хочется чтобы KISS применялся не только в проектировании
Поведенческие:
А с какого такого, простите, невероятного события «деваться им некуда» и «придется им смириться»?
Подход, в котором кто-либо решает за группу людей, к которой никакого отношения не имеет — вызывает только отторжение.
Не хотите разбираться в спцифике найма определённых специалистов — и не надо, дело ваше.
Такое ощущение создаётся что "углубляться" это тлен и он только для инженеров
Субъективное мнение о том, что выглядит иллюзорным:
Освоили доп. инструменты и готово? Ну-ну.
Во первых инструментов сотни. Во вторых — каждый со своей спецификой. В третьих — сильно влияет глубина, на которую необходимо погружаться.
И самое важное тут — системные администраторы очень разные.
Кто-то админит десяток сервисов, кто-то тысячи. Кто-то на десятках серверов, а кто-то на сотнях и более. Кто-то умеет обеспечивать HighLoad, а кто-то даже не сталкивался с этим.
И это далеко не всё. И по каждому нужно принимать решение исходя из контекста конкретного проекта.
Почти всем разрабам, кто запускает приложения в контейнерах и/или на linux-серверах приходится знать ряд нюансов работы Linux-систем. Так что момент спорный.
По поводу админства промолчу, т.к. не знаю какой смысл вложен в этот термин.
При этом, не раз встречал сильных системных инженеров, пришедших из разработки в SRE. С точки зрения глубины (в т.ч. Linux систем) познания часто лучше, чем у среднего админа (увы, с кругозором не всегда также хорошо).
и тут же
Курсы в IT это уже часть посведневности. Даже senior инженеры и архитекторы их проходят.
Тут ключевой момент что на middle и senior позицию человека, без опыта, в принципе не рассматривают.
А человек прошедший «Linux за 3 недели, Сети за 3 недели, DevOps за 3 недели» (в идеале с кейсами и практикой)- интересный на рассмотрение джун, мотивированный развиваться.
Пожалуй скажу что ожидание «может поставить все девопс-практики с 0» — слишком оптимистично.
Ставить (внедрять) организационную структуру это больше про Team Lead и в целом руководителей.
Задача senior специалистов (как я это привык видеть) — быть способным разобраться в любой задаче конкретного стека (а где-то даже и смежных) и решить её.
почему бывший?
Винда до сих пор актуальна в ряде проектов. И даже больше скажу, если говорить о виндовом облаке — CI/CD там тоже есть (привет, Azure Pipelines!).
Что, правда? А кто будет тогда обслуживать эти самые облака изнутри? (тут вот можно написать про OpenStack)
Да и потом, не говоря о бэкенде облаков и внутренних облаках (о которых умалчивается), есть множество проектов, где облачные технологии вообще не нужны.
Облака, если грубо обобщать — сервис выделения мощностей оборудования пользователям.
Если компания не предоставляет услуги по использованию каких-либо мощностей (внутри компании или внешним клиентам) — облаков там может не быть и на качество сервисов это не повлияет.
Из того, что понравилось:
Искренне желаю успехов как в найме инженеров, так и в дальнейшем изучении нюансов IT индустрии.
Ваш senior system engineer.
Чаще других, лично мне, встречаются WDS (в среде Windows) и Cobbler (в среде Linux).
Ещё есть pxelinux, kickstart, preceed и наверняка другие решения.
По сути всё сводится к настройке шаблона и организации механизма его доставки.