$10 тысяч в месяц и неограниченный отпуск: как обстоят дела с DevOps в Украине и почему подаваться стоит сразу на мидла
12 ноября вышел новый выпуск подкаста «Неправильный DevOps» от организатора конференции DevOps Stage, судьи Ukrainian IT Awards в номинации DevOps Дениса Васильева. Гостем стал Олег Миколайченко, Head of Infrastructure в SQUAD, автор статей на Highload, который ведет Telegram-канал «ДевОпс Инженер» и является сооснователем сообщества Kyiv DevOps Community.
Олег Миколайченко — Head of Infrastructure в SQUAD
Highload публикует самое интересное из подкаста: почему Junior DevOps не бывает, три способа, как стать DevOps-инженером, какая польза от DEV Challenge и про ужасный опыт неограниченного оплачиваемого отпуска. Начнем!
DevOps-магии не существует, расходимся. Будут ли скидки на DevOps на черную пятницу?
Скидок не будет, будет только дорожать. Но в черную пятницу можно выключить логирование и экономить IOPS — помочь компании выдержать Black Friday.
Из-за глобализации рынка наши ребята могут заключать прямые контракты с Канадой, Америкой — поэтому подтянулись зарплаты.
Нет смысла нанимать посредственного DevOps-инженера за $120 000
годовая зарплата в США, если можно нанять топ-перформера за эти деньги в Украине.
Конечно, будет разрыв во времени из-за разных часовых поясов и communication lag, но достижения специалиста это перекроют.
Статистика DOU
В среднем — 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 дней, но они будут ваши.
Как оказалось, unlimited PTO — плохая идея
Как ты нанимаешь людей? Вакансия, стек на кубере — что еще?
Стараюсь относиться к людям по-человечески. Например, пришел на собеседование джуниор, ответил что-то не то, но я вижу — нормальный парень. Начали работать — получился бесконечный источник 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-каналов
Сообщить об опечатке
Текст, который будет отправлен нашим редакторам: