$10 тысяч в месяц и неограниченный отпуск: как обстоят дела с DevOps в Украине и почему подаваться стоит сразу на мидла

12 ноября вышел новый выпуск подкаста «Неправильный DevOps» от организатора конференции DevOps Stage, судьи Ukrainian IT Awards в номинации DevOps Дениса Васильева. Гостем стал Олег Миколайченко, Head of Infrastructure в SQUAD, автор статей на Highload, который ведет Telegram-канал «ДевОпс Инженер» и является сооснователем сообщества Kyiv DevOps Community.

Highload публикует самое интересное из подкаста: почему Junior DevOps не бывает, три способа, как стать DevOps-инженером, какая польза от DEV Challenge и про ужасный опыт неограниченного оплачиваемого отпуска. Начнем!

DevOps-магии не существует, расходимся. Будут ли скидки на DevOps на черную пятницу? 

Скидок не будет, будет только дорожать. Но в черную пятницу можно выключить логирование и экономить IOPS — помочь компании выдержать Black Friday. 

Из-за глобализации рынка наши ребята могут заключать прямые контракты с Канадой, Америкой — поэтому подтянулись зарплаты.

Нет смысла нанимать посредственного DevOps-инженера за $120 000годовая зарплата в США, если можно нанять топ-перформера за эти деньги в Украине.

Конечно, будет разрыв во времени из-за разных часовых поясов и communication lag, но достижения специалиста это перекроют. 

В среднем — 0,8 откликов на вакансию. Днем с огнем не найти DevOps: что происходит? 

Имеется ввиду, что 0,8 откликов — это пассивный поиск, так вы к себе никого не найдете. В первую очередь для того, чтобы найти инженера, нужно посмотреть, что происходит в технологическом стеке. Если вы работаете со старым legacy, даже заспамив LinkedIn — ничего не получится. Нужно накачать и подтянуть стек, и «продавать» его в своей вакансии. Это улучшит общий уровень компании и даст преимущества для закрытия остальных вакансий. 

Не вижу странностей в малом количестве откликов: например, мы открыли две вакансии и быстро их закрыли.

Просят переделать вакансию, упростить, это странно — может быть, на рынке нет людей? 

Я бы предложил усложнять вакансию, а не упрощать. Наоборот, накидывать технологии и вектор в ближайшее будущее (чтобы показывать перспективу и движение). 

Не думаю, что что-то изменится или лопнет в ближайшее время — все будет ок, все будут зарабатывать, люди нужны, компании масштабируются, бизнес растет. Пока мы все на росте — расти легко. Если рост остановится — тогда вопрос будет актуальным. 

Когда замечательными условиями приглашают DevOps — это не подогрев рынка с точки зрения компаний? Что делать Junior DevOps? 

Я не против, если какая-то компания платит больше, чем компания с которой я сотрудничаю — придется позаботиться о том, чтобы сотрудник получал конкурентную компенсацию.

Если сейчас уже где-то может мелькать цифра в $10 000, то это больше edge caseпограничные условия, которые, скорее всего, не возникнут. Такую вакансию сложно найти и туда очень сложно попасть. Вилка может быть $7000-$10 000 и в результате собеседования тебя погоняют по какой-то суперузкой технологии, которую никто не знает, и предложат, конечно, $7000. 

В Украине, согласно LinkedIn, около 8000 DevOps-инженеров. Сюда входят все DevOps/SRE/Infra/SysOps-инженеры, и 4000 из них — в UkrOps.

Совет для джуниоров: если вы подходите под вакансии Junior, скорее всего, вы подходите и под вакансии Middle. Поэтому вам могут недоплачивать. Junior DevOps, которые получают ~$1000, подавайтесь на вакансии Middle и пробуйте получить $2000 +.

Junior DevOps не бывает — это фикция. Если вы что-то можете делать — вы не Junior. 

На Highload я видел несколько твоих статей: как затащить разработчика в DevOps и как вскочить в DevOps. Зачем себе растить конкурентов или это PR-ход? 

Я был бы очень рад, если бы 8-10 лет назад были бы статьи о том, как стать DevOps-инженером. Второй момент: чем больше инженеров, тем больше конкуренция, тем выше средний уровень. В свою очередь, чем больше средний уровень — тем более высокие зарплаты будут готовы предлагать компании, которые конкурируют за качество. Я всегда отталкиваюсь от пользы: если мне есть, что сказать — всегда готов этим поделиться бесплатно. 

Не кажется ли тебе, что если взять трех джуниоров вместо одного сеньора — это приведет к падению уровня качества этих проектов? 

Тебе же команда нужна не только из сеньоров, правильно? Если у всех будет лычка «сеньор» — кто будет делать простые задачи? Такая высокая экспертиза не всегда нужна. Тебе нужна команда, которой будет куда расти: 

• сеньоры — локомотивы, которые «тащат» важные приоритеты и делятся экспертизой;
• мидлы — могут подхватить важный приоритет, размывают bus-factor количество участников проекта, после потери которых проект не сможет быть завершен оставшейся командой и деливерят приоритеты средней важности;
• джуниоры — инженеры, которых ты растишь, с ними все делятся экспертизой и они становятся бесконечно лояльны компании, которая их обучила: win-win.

Мы хорошо «стелим» для внешних кандидатов, а что по поводу внутренних? Довольно сложно добиться пересмотра внутри компании — как с этим быть? Кто виноват? 

Это проблема тимлида. Допустим, ты — мой менеджер, и я к тебе прихожу, прошу накинуть зарплату.

Аргументирую стандартно: мне мало денег, рынок вырос, хочу больше. Если ты этот вопрос не решаешь — сорри, будешь выходить на рынок и три месяца искать нового сотрудника. 

Есть абсолютно нездоровые политики, например у некоторых компаний из MANGA — увольнять 5-10% сотрудников каждый год. Это практика hire to fire, и это делают для того, чтобы впустить энергию, свежий взгляд. 

Но не всегда, если человек уходит — это плохо. Например, у меня из команды ушел инженер, устроился напрямую в компанию из Ванкувера, она его релоцирует в Канаду. Я ходил три дня в депрессии, грузился, думал: «Рома, какого чуда, нормально же общались, все было хорошо». Но понял, что это его точка роста и я должен его поддержать, чтобы у него все получилось. 

Читайте также: «Если сидеть весь день в наушниках и пилить функционал, то медаль получат все, кроме тебя»: почему быть хорошим инженером недостаточно, если хочешь повышения

Расскажи немного о своем опыте с unlimited PTO.

Unlimited Paid Time Off неограниченный оплачиваемый отпуск — ужасная практика. У меня был опыт такого: вам «продают» бесконечный отпуск, а в результате — полный завал на работе, горение во всех местах и полная невозможность хоть что-то успеть, плюс личный роадмап на год вперед. 

В таком жестком окружении можно попробовать себе выпросить из unlimited PTO день-два (это именно выпрашивание отпуска), и в момент апрува обязательно найдется что-то срочное и важное именно на эти пару дней. 

Берегитесь unlimited PTO — это не работает. Пусть будет 15-20 дней, но они будут ваши. 

Как ты нанимаешь людей? Вакансия, стек на кубере — что еще? 

Стараюсь относиться к людям по-человечески. Например, пришел на собеседование джуниор, ответил что-то не то, но я вижу — нормальный парень. Начали работать — получился бесконечный источник deliveries. 

Пришел сеньор — накидываю перспективу, сложность, технологии и масштаб — это отлично продает. 

В процессе работы стараюсь соблюдать принципы How to Lead a Team из книги Software Engineering at Google. Самая важная практика — Lose an Ego.

Суть в том, чтобы дать команде прийти к решению, чтобы это было их решение и их победа. Ни в коем случае не микроменеджить и доверять.

Но в то же время, если кто-то начнет филонить — я это увижу по количеству или сложности закрытых приоритетов. 

Вторую работу легко заметить по метрикам: 

• нестабильная производительность;
• частый оффлайн по самым разным причинам;
• выгорание (из-за того, что требуют в два раза больше);
• неожиданно низкий уровень качества.

Могут случиться проблемы со здоровьем или семейные обстоятельства — но это кратковременные показатели. Если человек не деливерит, пропадает, рассказывает басни — у него явно вторая работа. 

А может разработчик взять на себя инфраструктуру?

DevOps Engineer, который пришел из программирования — ценится вдвое больше. Более того, из него получиться отличный SRE Site Reliability Engineering (инженер по надежности сайта) — это одна из форм реализации DevOps. У меня был друг, который перешел из PHP в инфраструктуру, хорошо понял все области тьмы и сейчас работает в Tesla. Success story! 

Если взять команду, которая сама хочет строить инфраструктуру — у нее получится. Найдется член команды, который начнет это делать больше остальных — получит интересную экспертизу и в результате будет знать IaaC, Kubernetes и облако лучше всех.

Кого команда получила в результате? DevOps-инженера! Он вырос сам. Минусы: будет допускать простые ошибки, например, не проверять backups. 

Назови три способа, как стать DevOps-инженером.

Первый — самый каноничный: повторить опыт старших и сильных DevOps-инженеров. Отучиться в университете, попробовать программировать, попробовать автоматизацию инфраструктуры, выучить классно Linux, результат — фундаментальный DevOps-инженер. 

Второй вариант — пойти на курсы компаний-аутсорсеров и через 3-6 месяцев попасть на первый проект. Эти курсы неплохо качнут знания, но минус — на такие курсы тяжело попасть. Более того, если получилось сразу пройти все собеседования на курсы — скорее всего, уже есть все необходимое для работы, нужно искать сразу работу. 

Третий вариант — вариант беженца. Инженер, которому интересно, начинает штудировать DigitalOcean Tutorials (единственные туториалы, которые работают), через пару месяцев подключает видеокурсы с торрент-трекеров, смотрит интересных ребят на YouTube (например, ADV-IT). Дальше нужно пробовать писать сервисы, делать простенькие инфраструктуры, найти ментора, и за 9 месяцев-год попасть на реальную позицию. 

DEV Challenge — ты и в прошлом, и в этом году участвовал как судья. Зачем? 

8-10 лет назад DevOps-хакатонов или конкурсов невозможно было найти. Были для программистов, а DevOps стояли в стороне. Первый раз, когда появился конкурс — я захотел его поддержать, получилось, были классные результаты.

В этом году, я надеюсь, получится еще лучше. Заявок достаточное количество, сообщество поддерживает, тратит свое время, плюс это крутая возможность. Твой код проревьювит Всеволод Поляков, Денис Васильев, и ты получишь фидбек — это очень круто. 

За пять-шесть часов получится сделать интересное MVP — чат-бот для деплоймента из Telegram (Github Actions, Docker, Terraform, etc). 

Как затащить DevOps? 

Я бы советовал построить T-shaped-модель, выбрать себе основную экспертизу и разобрать ее на молекулы. Это должна быть самая сильная экспертиза. Таким образом все остальные знания будут ее усиливать и подтверждать монументальные знания. 

Для новичков — лучше брать самый стандартный стек: AWS, Kubernetes, CNCF (kube-prometheus-operator), Hashicorp (Terraform). Потребность рынка можно проверять по количеству вакансий. Чем больше вакансий с упоминанием технологии — тем лучше. Если вы — опытный DevOps, тогда, конечно, конференции. 

Читайте также: Где читать новости и общаться с коллегами DevOps-инженеру в Украине? Подборка сообществ, конференций и Telegram-каналов