Faion

• Писать (и читать) код минимум на одном из скриптовых языков (bash/python/go).

• Уметь в автотесты, или хотя бы понимать как их запускать, править, получать результат.

• Рассчитывать нагрузку на сервера, знать на каких ОС работают разработчики, знать сетевой стек хотя бы на слабом уровне. Знать как операционная система работает "под капотом".

• Анализировать работу смежных отделов, налаживать их взаимодействие между собой, производя поиск тех мест которые можно автоматизировать.

Само слово DevOps является наименованием методологии, весь смысл которой в автоматизации рабочего процесса, и интеграции работы смежных команд между собой. Позволю себе вольную трактовку - "если что то можно автоматизировать - это нужно автоматизировать, если что то можно интегрировать - это нужно интегрировать". Отсюда и требуемая широта навыков - автоматизировать можно очень много чего, чем больше ты знаешь и умеешь, чем лучше ты проанализируешь боли разработки, тестировщиков, интеграторов, аналитиков и прочих - тем больше пользы будет от твоей автоматизации. По интеграции та же картина, только зачастую интеграции прописываются самостоятельно за счёт приложений-прокладок, что и потребует навыков писать код.

Вот прямо сейчас отдельно хотелось бы сказать что на мой взгляд есть 2 разных направления DevOps - инфраструктурное и продуктовое. И там отличаются подходы и набор используемых технологий. В инфраструктурном стараются автоматизировать развёртывание серверов, часто пишут какие то свои инструменты и приложения, обслуживают внутренние сервисы переводя их на IaC и тд.

В продуктовом направлении все направлено на работу с кодом и с конечным продуктом. Я опишу именно его процессы, если нужно будет, то позже напишу и про инфраструктурное направление.

Примеры того что автоматизируют DevOps инженеры:

• Анализ кода на плохие штуки - уязвимости, баги, плохой код (Sonarqube, owasp и любые другие сканеры) и сигнализация об этом разработчику.

• Сборка кода (в один или несколько пакетов для установки/docker образ и тд).

• Запуск автотестов, выдача понятных результатов по итогу.

• Поднятие и уничтожение тестовых сред для тестов.

• Загрузка пакета/образа в хранилище.

• Доставка пакета/образа клиенту.

• Развёртывание приложения.

• И иные мелкие и крупные операции.

Задачи нам говорят о том что DevOps всегда работают на стыке инфраструктуры и приложения. Часто они могут отвечать за то, как именно будет развёрнуто приложение, по какой схеме будет обновляться и как будет доставляться это обновление к клиенту.

А если инженер знает как приложение разворачивается, то он так же может работать с мониторингом этого приложения, настройке уведомлений от мониторинга при проблемах, сбором логов и прочее прочее прочее - тут очень много опций, в зависимости от потребности и возможностей команды.

Подводя итог, говоря простым языком - DevOps инженер занимается тем что ищет возможности как улучшить жизнь смежным отделам которые занимаются разработкой приложения. Найдя, он автоматизирует эти процессы, а затем и объединяет их в единую систему. В том числе, кстати, это касается и бизнес-процессов.

Ну и наконец, а почему они собственно так ценятся в IT?

Хотелось бы подойти к ответу не с самой очевидной стороны. Все знают что больше всего ценятся узкие специалисты, те кто знает свою область просто идеально. Ну и так же думаю все понимают что знать всё - нереально. Так какой смысл разработчику при необходимости быстро расти в своей области ещё и изучать инфраструктурные вопросы и подходы?

DevOps инженер позволяет разработчику не придумывать как развернуть приложение на тестовой среде, как эту среду вообще поднять (а ведь очень важно чтобы тестовая среда была всегда точно вспроизводима), как точно быть уверенным что код не содержит уязвимостей и отвечает заданной стилистике, как загрузить приложение чтобы его мог скачать клиент и тд и тп.

Наверно сейчас ты скажешь - так я все умею, знаю и сделаю без всякой автоматизации! Конечно ты все можешь сделать это сам, без сомнений. Ну а если в команду взяли нового молодого разработчика, он сможет? Сколько ему придётся погружаться в продукт и инфраструктуру чтобы гарантированно делать все перечисленное выше на нужном уровне?

Автоматика допускает ошибки, но делает это намного реже людей.

Вот и Devops инженеры нужны для того чтобы специалисты других областей могли расти быстрее, не изучая дополнительно кучу материала для эффективной работы, легче вливались в новые команды, с первого дня имели чёткие границы что можно тащить в продукт, а что нет.

Ну и конечно денег много за счёт автоматизации и соответственно снижения трудозатрат могут сэкономить копаниям, но это уж совсем очевидно :) .

Во время собеса при решении задач - рассуждай вслух. Казалось бы зачем? Ответ прост - задача джуна в перспективе стать мидлом и тд. Для этого нужно уметь решать задачи самостоятельно (по факту это на 80% и отличает джуна от остальных позиций). И если ты перед сложностями просто останавливаешься, пытаясь накидывать какие то предполагаемые ответы к которым пришёл каким то образом в голове - это не всегда хорошо. Есть вероятность что в затруднительных ситуациях тебя придётся вести за руку, доводя до решения. Возможно есть сложности с построением логической цепи от задачи до решения при недостатке исходных данных.
А если ты рассуждаешь, показывая как именно происходит мыслительный процесс, то во первых - тебя могут поправить на какой то стадии решения задачи, что позволит дать правильный ответ если решение в голове складывалось не так. Во вторых - рассуждающий кандидат располагает к себе намного больше стеснительного молчуна. Данный совет можно использовать как хитрость - если даже известен точный ответ, но ситуация располагает к разговору - можно рассказать как прийти к ответу, а не просто выдать его. Это 100% сыграет в плюс.

Улыбайся. Чаще всего люди любят когда их не боятся. Умеренная улыбка и шутки (в меру) располагают к себе. Улыбающийся кандидат заставляет подсознательно снимать риск что будут проблемы с коммуникациями в команде, что сыграет в плюс. Кроме того - улыбка прямо влияет на то, каким тоном ты говоришь - сложно говорить зажато не улыбаясь. Речь конечно не о том чтобы хохотать на собеседовании, просто стоит хотя бы вежливо улыбаться.

Формулировки - очень важны. Я бы сказал крайне важны. Если я ведя диалог с кандидатом услышал что то, что он сказал не подумав и ошибочно - я обязательно зацеплюсь за сказанное и постараюсь конкретизировать вопросы именно на ошибке, чтобы понять "как глубока кроличья нора". При этом я не скажу что кандидат ошибся до того момента, пока не проясню все что интересует. В эту ловушку попадаются очень многие, когда одно - два слова брошенных необдуманно там, где важна чёткая формулировка заваливают весь ответ. Дело не в том что я плохой, дело в том что зачастую у кандидатов отсутствует база. И вот такие ошибки это выдают. А моя задача как интервьюера эту базу прощупать со всех сторон. Отсюда вывод - если вопрос формата "а как работает эта штука" или "как сделать вот это" - подумай секунду-две перед тем как отвечать, сформулируй ответ из тех фактов, в которых ты уверен на 100%. Это не даст тому кто проводит собеседование "цепляться" за пробелы в знаниях.

Техническое обеспечение. В 99,9% случаев у нас собеседования - это удалённый формат, созвон по зуму например. Если ты идёшь на собеседование в IT компанию - не надо подключаться с телефона, открой собес на компьютере. Нет камеры? Включи камеру на телефоне одним сеансом и поставь его на стол, а с компа подключись вторым и смотри на тех с кем разговариваешь. Невозможно давать какие то задания на собеседовании когда кандидат с трясущегося телефона в руках зажимая микрофон что то рассказывает. Жутко бесит.

Ну и последнее сейчас что приходит в голову, но наверно это не про то как пройти собес, просто на что стоит обратить внимание уже тебе - адекватная уважительность. Раскрою что имею в виду - с одной стороны ты пришёл искать работу в компанию и тебя собеседуют специалисты которые чаще всего знают и умеют больше тебя, возможно намного. С другой стороны - лично тебе сейчас эти люди вообще никто. Вы собрались поговорить о тебе, твоих навыках, перспективах и о том что может дать их компания опять же лично тебе (на вопрос что ты можешь дать компании ты не сможешь ответить, идя на позицию джуна). Не надо в общем относиться к интервьюерам с опаской или чрезмерным уважением, но и фамильярничать не стоит. Чаще всего в нормальных компаниях стараются выстроить диалог так, чтобы поставить на один уровень всех участников собеседования, и я считаю это один из показателей нормальной команды.
В противовес хочу сказать - даже если ты готов работать за еду, выстраивай рамки общения уже на собеседовании. Если к тебе совсем пренебрежительно обращаются или допускают обидную критику твоих навыков - а так ли нужна такая команда для старта?

Если что извиняюсь за возможный сумбур, выгрузил то что было в голове, не продумывая пост заранее, спасибо за внимание :).

2 - Здорово понимать, куда может увести карьера, начиная работать в какой то области IT. Приведу пример роста (там много ответвлений и вариантов, просто как пример): Тестировщик - джун/мидл/серьор разработчик фронта/бэка/фулстек - архитектор сервисов.
Или в сторону devops например: системный администратор - джун/мидл/сеньор devops - джун/мидл/сеньор SRE - техлид - архитектор.
Соответственно если я хотел бы стать разработчиком я бы не пошёл в дизайн или если бы я хотел быть SRE инженером я не пошёл бы работать тестировщиком.
Сразу оговорюсь - есть куча примеров движения людей вне вышеописанных рамок, но я описал только рельсы, т.е. сисадмину будет легче уйти в devops нежели тестировщику или аналитику - стек технологий близкий и переход будет относительно лёгким.

3 - Профильные курсы.
У большинства (не у всех наверно) курсов цель - быть проданными как можно большему числу людей. Это важно понимать. По сути, компании продающей курсы без разницы найдёте ли вы работу потом, они живут именно продажами. Не буду тут останавливаться, все и так всё знают.

4 - Не программированием едины.
Я ушёл в devops из сетевого администрирования за 45к в месяц, и зарплата у меня вполне попадала под запросы большинства людей кто хочет войти в IT где то через год.
Не обязательно стремиться быть разработчиком и идти учить языки 24/7 своего времени, есть очень много разных специальностей. Тестирование, аналитика, системное администрирование, сети, дизайн и многое многое другое. И в каждой из сфер будут айтишные зарплаты.

5 - Конкуренция.
Могу сказать что кадровый голод в IT есть почти везде на уровне от мидла. Рынок буквально пылесосят, компании сами пишут и приглашают прийти к ним на собеседование. Но если вы джун то все не так радужно и довольно сложно. Отсюда и появляются разные "начни работать за еду" и прочее.

Стоит понимать - если сейчас например ото всюду сыпется реклама курсов Python разработчика то и конкуренция там будет огромная, и именно на позицию джуна. Все эти вакансии на 180к это все лишь замануха для продажи курсов.
Если цель просто "войти в IT", то стоит выбирать те направления где конкуренция ниже.

Немного оффтоп - не скажу за всех, но я к себе в команду например не возьму человека который не знает базовых необходимых вещей, но готов работать за еду, только бы учили. Мы учим, и как показывает опыт очень эффективно учим, но ресурс на обучение не бесконечен, это так же затрата сил и времени. Поэтому наличие крепкой базы знаний всегда приоритетнее демпинга оплаты труда.

Буду закругляться, и так много текста. Если пост найдёт отклик, мог бы написать так же как я сам дошёл до текущей работы, на что смотрим при собеседованиях, что то по devops тематике для тех кто думает пойти именно в этом направлении. Спасибо за внимание.