DevOps-дискусія на DOU. Обговорюємо тренди, розвиток та інструменти

На YouTube-каналі DOU відбулась дискусія з українськими DevOps: Владом Волошиним, Станіславом Коленкіним, Олегом Миколайченком і Всеволодом Поляковим. Публікуємо запитання спільноти та тези відповідей експертів. Якщо хочете почути більше — користуйтесь таймкодами або слухайте повний запис розмови. І не забудьте підписатись на YouTube-канал DOU!

Тренди на українському ІТ-ринку

Зараз на DOU є понад 400 вакансій (станом на 25 квітня) і в середньому трохи більше як два відгуки на кожну з них. Це порівняно небагато. Отже, попит на DevOps-інженерів є, але самих DevOps’ів на ринку недостатньо. Скільки, на ваш погляд, ще буде затребуваний цей напрям? (1:37)

Станислав Коленкин: В связи с пандемией многие компании, которые работали в офлайне, поняли: чтобы выжить, надо трансформироваться — перейти в онлайн. Соответственно, начался рост этих проектов и людей стало не хватать.

Если посмотрим на то, что должен знать DevOps на данный момент, там огромнейший список, и он растет с каждым годом. И человек, который хочет начать работать DevOps’ом, должен знать большое количество инструментов и технологий.

Влад Волошин: Есть много направлений, за которые отвечает DevOps-инженер. Из-за этого увеличивается зона ответственности. Также нет какой-то чёткой стандартизации: у каждой компании свои требования, спектр навыков очень большой.

З розробника — у DevOps

Якщо є попит, хороші зарплати, можливості вчитися і розвиватися, чому все одно ми бачимо дефіцит спеціалістів? Чому розробники не перекваліфіковуються? (7:48)

Станислав Коленкин: Потому что это разные профессии. DevOps больше связан с инфраструктурой, а девелопер разрабатывает код. Соответственно, кому что ближе к сердцу.

В стартапах человек должен уметь всё. Недавно я общался с ребятами из одного из стартапов, и оказалось, что им нужен человек и девелопер, и DevOps, всё вместе. И так у многих стартапах.

Пока работаешь на большой галере, у тебя не будет проблем с тем, что надо делать всё.

Олег Миколайченко: Мені здається, такого поняття, як джун-DevOps, не існує. Якщо хтось почав розбиратися з клаудами, платформами, Kubernetes, контейнерами, навчився програмувати, то це вже повноцінний інженер. Його потрібно відразу переводити далі. Тому виходить, що поріг входження супервисокий і це відповідь на питання, що не так з іншими і чому DevOps у тренді, а інші ні? Відповідь: все добре з іншими, просто в DevOps поріг входження з нуля величезний.

Градація DevOps

Чи є градація? (11:12)

Олег Миколайченко: На мій погляд, градація створена для того, щоб не виплачувати інженерам гроші. Тобто часто, коли компанія шукає мідла, у вакансії пишуть вимоги до сеньйора. І по факту сеньйор повинен отримувати $5000, а компанія бере мідла з вимогами до сеньйора на $3000.

Станислав Коленкин: Хоть порог вхождения большой, но всё равно градация есть. Джуниора нельзя пустить работать самостоятельно. Сеньор — это тот человек, которому ты поставил задачу, он пошел, сделал, пришел и отчитался. А многие не могут и не хотят расти выше, они готовы работать, имеют багаж знаний, но хотят, чтобы им все четко расписали: сделай пункт второй, третий, четвертый, пятый и получишь вот такое решение.

Всеволод Поляков: Я фундаментально не согласен, что у DevOps высокий порог вхождения. В целом в DevOps и учиться-то нечему, просто достаточно много информации надо держать в голове.

Як стати DevOps

Хто може бути DevOps з огляду на знання і навички? Яке потрібно мати підґрунтя для старту? (14:07)

Станислав Коленкин: Многие компании проводят внутренние и даже внешние тренинги, в основном на направление сисадмина. Потому что если человек после университета, то у него вообще нет знаний и нужно больше времени на его обучение. А сисадмины отлично переквалифицируются в DevOps.

Тем же разработчикам приходится работать с инфраструктурой, серверами, клаудами, даже Kubernetes. Как-то я занимался проектом, где девелопер лидил проект миграции в Kubernetes, распиливание монолита на микросервисы. Он педалил интенсивно и на Jenkins, и на Groovy, и на Java. То есть он сам по себе разработчик, но выполнял и функции DevOps.

Всеволод Поляков: Я как-то разрабатывал программу обучения для DevOps из 36 пунктов и пошёл к ребятам, которые занимаются именно преподаванием. Они прямо разнесли ее, сказали, что это нужно учить несколько лет, потому что сложно. Так что, может, и сложно, хотя мне кажется, просто надо брать и делать, ничего сложного нет.

Олег Миколайченко: Я думаю, що найкращим DevOps буде розробник, який знайшов спосіб комунікувати з командою DevOps-інженерів, перейнявся всім, що відбувається, і почав працювати в інфраструктурному напрямі.

Розвиток DevOps

Що робити, щоб розвиватися в напрямі DevOps? (20:34)

Олег Миколайченко: Стежити за CNCF Meetups, конференцією Monitorama і всім, що можна знайти на YouTube. Варто дивитися того ж дня, коли вийшло, сортувати за кількістю переглядів і забирати core-знання і core-фічі, які щойно з’явились. Також ми з командою і з Владом Волошиним робимо DevOps digest на DOU. Важливий knowledge-sharing, так можна витратити 10 хвилин і не наробити помилок, які розгрібав би кілька місяців.

Станислав Коленкин: Кроме сказанного Олегом, я смотрю Linux Academy, Cloud Guru, разные онлайн-сервисы. И стараюсь делиться опытом на своих ивентах, рассказываю о набитых шишках. DevOps community должно развиваться, и DevOps-инженеры должны делиться опытом. Хотя я знаю людей, которые принципиально не хотят это делать. Они говорят: «Я сейчас расскажу о том, как я сделал, и на рынке упаду в цене».

Влад Волошин: На roadmap.sh есть диаграмма, которая описывает постепенный путь от каких-то базовых знаний до уже высокоуровневых клаудов и так дальше. Можно смело идти по ней. В целом это, конечно же, операционные системы, базы данных, нетворкинг и языки программирования.

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

Станислав Коленкин: Да, на интервью надо ходить, чтобы быть уверенным и не теряться, когда задают вопросы. Всего знать нельзя, всё можно подучить. Надо понимать базу, основные моменты и не бояться. Даже если не знаешь, но работал с похожими технологиями, просто скажи: «Я работал с другим инструментом, делал вот так вот и думаю, что вот тут будет тоже по такому-то флоу делаться».

Запитання на співбесідах

Що ви запитуєте на співбесідах у кандидатів? Яких навичок, софт/хард скілів їм не вистачає? (28:39)

Станислав Коленкин: Я часто провожу интервью и вижу людей, которые не знают даже базовых вещей. Они считают, что пришли в DevOps и учить ничего не должны, их задача, например, прописать AWS ​Formation, а всё остальное это не DevOps. Говорят: «Я использую Amazon Linux, всё, я его задеплоил, дальше не мои проблемы». Для этого и есть SRE-команда. Я стараюсь людям задавать не четкие вопросы, чтобы понять логику. Для меня это важнее, потому что знание технологий человек всегда подтянет. Если он умеет мыслить и матчится на этот проект, я всегда дам апрув.

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

Скорее всего, если будете идти собеседоваться джуном или мидлом, у вас будут спрашивать, что вы выучили за последние полгода. Потому что всё меняется и надо постоянно развиваться.

Также всегда стоит проверять софт скилы. Это суперважная штука.

Сертифікація DevOps

Чи варто здавати сертифікацію AWS? (34:54)

Всеволод Поляков: Сертификаты никому не нужны. Надо понимать, что при собеседовании на DevOps вам часто будут задавать вопросы люди, которые не умеют делать интервью, которые не понимают, кого они ищут и зачем. Вот только для них сертификат и нужен.

Советую прочитать книгу «Карьера программиста», выучить всё, что там говорят про нотацию, а потом получить какие-то сертификаты, чтобы важно сидеть и надувать губы. В реальности я не встречал человека, кому это было нужно.

Станислав Коленкин: В стартапах не надо, я согласен. Если брать энтерпрайз, там часто требуют сертификат. Но самому DevOps’у я рекомендую сдавать сертификацию, чтобы закрыть свои пропуски и прокачаться. Когда готовишься к ней, ты подтягиваешь свои скилы, если ты не готовишься по дампам, конечно.

Олег Миколайченко: Вважаю корисним сертифікат CKA — Certified Kubernetes Administrator, тому що він єдиний з практикою, тобто там неможливо наклацати, а потрібно попрацювати в командному рядку, показати, що ти справді вмієш працювати з kubectl і kubeadm і можеш щось пофіксити.

Але всі сертифікати, що стосуються AWS, як і будь-які папірці, не підтверджують знань. Але як елемент особистісного розвитку можна рекомендувати своїм інженерам пройти сертифікацію Kubernetes.

Станислав Коленкин: Не только CKA, ещё Certified Kubernetes Application Developer и Security — они практические.

Влад Волошин: При найме продуктовая компания не смотрит на сертификат. Но относительно недавно я слушал подкаст с Юрой Рочняком, который ведет CatOps, он сказал о том, что сертификаты могут расцениваться как инструмент, показатель того, что инженер за какой-то краткий период времени смог овладеть этой технологией. Если действительно инженер раньше не работал с Google Cloud и ставит цель за месяц-два выучить его на хорошем уровне, можно сдать сертификацию.

Всеволод Поляков: Можно попросить человека выучить случайный набор символов. Сколько страниц выучит, настолько быстро научится. Сертификаты и любой тест знаний — это не особо актуальная штука. В любой сертификации всегда будет набор вопросов, которые вообще никому не нужны, их в жизни не бывает, это просто вопросы ради вопросов. И надо ли проверять, способны ли люди выучить какие-то вещи, которые никому не нужны?

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

Стек

Який стек технологій рекомендуєте знати, щоб вважатися бажаним DevOps-інженером? (43:53)

Влад Волошин: Это зависит от компании, от её стека. Потому что невозможно быть экспертом везде, это нормально.

Станислав Коленкин: Сейчас большие компании, те же ЕРАМ, Intellias, SoftServe, GlobalLogic, Nix Solution и так далее, имеют свои ІТ-курсы. И это уже не опция, а насущная потребность для самой отрасли, которая в год у нас растет примерно на 20%. Дефицит квалифицированных кадров огромнейший, и это является сейчас узким местом для роста ІТ-индустрии в Украине. Поэтому большие компании уже строят долгосрочное планы на 5+ лет. Они готовят кадры под свои требования, свой стек. И ты, проучившись на курсах компании, уже заходишь готовый на нужный проект.

Олег Миколайченко: Якщо є завдання вивчити стек, то загалом не дуже важливо, що саме це буде. Це можна валідувати ринком: достатньо зайти на DOU в розділ «Робота» і пошукати ту технологію, яку ви зібрались вивчити. Якщо вона там трапляється часто або частіше, ніж інші технології цього напряму, то це правильний вибір і можна на це робити ставку.

Також вважаю, що у кожного має бути core skill. Наприклад, людина говорить на співбесіді, що добре знає Prometheus. Я можу взяти її в команду, щоб вона навчила інших.

Всеволод Поляков: В любом вопросе главное понимать, зачем вам ответ на этот вопрос. Если человек спрашивает, что надо учить, чтобы стать DevOps’ом — значит он хочет стать DevOps и получать деньги. Чтобы получать деньги, надо устроиться на работу. Чтобы устроиться на работу, надо просто посмотреть, что самое популярное, что надо и что будет надо.

Тестові завдання

Які тестові завдання мають сенс, які ні? (49:57)

Олег Миколайченко: Якщо у компанії є завдання відсіяти інженерів, яких два з половиною на вакансію, можна давати тестове завдання, причому висилати його до першої співбесіди і не платити за нього. Якщо є бажання зрозуміти, що перед вами за інженер, краще провести якесь hands-on, тобто сісти поруч і натискати на кнопки.

Всеволод Поляков: Тестовые задания не нужны. Они нужны, только если вы хотите отфильтровать адекватных людей, чтобы они к вам не приходили.

Конкуренция за DevOps’ов большая, за адекватных специалистов — ещё выше. Если хотите их отфильтровать, то да, давайте тест, полиграф и всё такое. Я на собеседовании даю тестовые только тогда, когда не уверен в кандидате. Чаще всего, чтобы разобраться, чего он не знает. Например, приходит какой-то человек, у нас с ним знания вообще не совпадают, ничего из моего стека он не знает, проверить его не могу. Можно дать ему в чем-то разобраться, посмотреть, как быстро он это сделает.

Як часто змінювати місце роботи/проєкти

З якою періодичністю бажано змінювати середовище? Чи можна розвиватися в межах однієї компанії? (1:02:20)

Станислав Коленкин: У меня все проекты до трех месяцев, бывает несколько проектов параллельно. Я имею возможность прокачиваться и не засиживаюсь на одном проекте. Если такого нет, я бы рекомендовал каждые два года менять компанию.

Влад Волошин: Можно развиваться в рамках одной компании, это всё зависит от менеджмента — насколько он хорошо выстроил процессы. Если смотреть на приходящее резюме кандидатов, то всегда задаёшь себе вопрос: если человек поработал меньше года где-то, то почему?

Всеволод Поляков: Менять место работы надо минимум раз в три года. Я прихожу в компанию, что-то делаю, потом всё начинает работать и становится скучно, а мне хочется развиваться и учиться. Плюс надо успеть за жизнь поработать в разных компаниях, чтобы сформировать мнение о мире. Это просто интересно, не говоря уже про технологии, стеки и про всякие тонкости и разные акценты.

Олег Миколайченко: Універсальної відповіді немає. Джуну бажано піти через рік, якщо його не промоутять. Сеньйору можна перебувати в компанії довго, якщо вона зростає швидше, ніж сам спеціаліст: відкриваються нові офіси, нові позиції, людина бачить зростання і може розвиватися, змінювати рівень відповідальності. Якщо ця компанія вже перейшла на стадію сапорту, там робити нічого: усе вже працює, ніхто нікуди не рухається. Моя особиста рекомендація — не робити дурних світчингів. Я не бачу сенсу переходити з однієї аутсорсингової компанії в іншу і займатися тим самим. А ще за рік переходити знову і теж крутити той же Terraform на +300 баксів, це дурість. Є сенс переходити між посадами, рівнями, відчутною компенсацією, зонами відповідальності, стеками, ринками.

Site Reliability Engineer в Україні

Наскільки спеціальність SRE актуальна в Україні? Які навички необхідні для такого спеціаліста? (08:29)

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

Я видел компании, где 100 человек просто ходили на сервера и руками запускали апдейты, чтобы засинхронизировать. Нужны ли они в Украине? Вот такие, наверное, нужны.

Станислав Коленкин: Я встречал SRE-инженеров, которые отвечают за мониторинг, патчинг кода и могли еще написать код. Но это западные компании, в Украине я вообще SRE-инженеров не встречал.

DevOps vs Database Administrator

Де закінчується DevOps і починається Database Administrator? (1:14:05)

Станислав Коленкин: DevOps может автоматизировать создание инстанса, но он не експерт. А DBA понимает, как оптимизировать структуру данных в базе, найти медленный запрос, построить правильную структуру таблиц, индексов и так далее. DBA понимает базу данных более глубоко.

Влад Волошин: В последнее время есть тенденция, что оптимизацию баз данных передают в руки DevOps. В целом от компании зависит, как она выстроит процесс. Крупные компании отдельно нанимают Database Reliability-инженеров, то есть существует отдельное направление, которым занимается отдельная команда людей. У мелких компаний нет такой возможности, и над этим работают DevOps-инженеры.

Credentials

Де зберігати різні credentials? Чому всю конфігурацію не зберігати в тому самому місці і чи мають розробники, які не є DevOps, доступ до них? (1:20:59)

Станислав Коленкин: Есть два основных подхода — это принцип наименьших привилегий и разделение обязанностей. Все индивидуально.

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

Олег Миколайченко: Я б максимально широко роздав доступ розробникам. Колись в AnchorFree ми пробували робити one-time password для баз даних, які створюються і експайрятся. В результаті виявилося, що Vault тієї ітерації не оновлював пароль за TTL, і ми завели bug issue на GitHub.

З хороших рішень, які себе нормально зарекомендували, — це Hashicorp Vault і Terraform провайдер.

Влад Волошин: Лучше всего выдавать какие-то шорт-лист секреты, которые даже если утекут, то нестрашно. Если действительно есть требования по секьюрити, то, чтобы не заводить что-то громоздкое, есть куча примочек для Git. Git-crypt, который будет в зашифрованном виде хранить секреты в коде. Если у вас там нет capacity в команде, чтобы менеджить Vault, не надо заводить ради того, чтобы оно было.

Всеволод Поляков: Есть такая классная книга «Проект Феникс», роман о DevOps. И там есть классная история про безопасника, который делал очень много вещей, а оказалось, что это не надо. Каждый раз спрашивайте себя, а надо ли вообще это делать? Какую проблему это решает? Решает ли это проблему? Не решается ли эта проблема где-то на другом уровне? Я часто наблюдаю, как люди, которые не разбираются в теме, делают много вещей и думают, что это безопасность, но просто усложняют всем жизнь.

6 квітня, у вівторок, о 19:00 відбудеться дискусія про Front-end, а 20 квітня — про QA. Не проґавте!