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 актуальна в Україні? Які навички необхідні для такого спеціаліста? (1: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. Не проґавте!

👍НравитсяПонравилось6
В избранноеВ избранном2
Подписаться на автора
LinkedIn



Підписуйтесь: Soundcloud | Google Podcast | YouTube


67 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Сертифікати це як диплом про вищу освіту в Україні. Людина вчилась 5 років і 2 рази на рік відповідала на питання, складала іспити.

Цікаво, це новий тренд на ДОУ — запрошувати українських експертів, який не розуміють і не розмовляють українською?

який

wasted

Так і не розповіли, чим ДевОпс відрізняється від просто Ops чи від просто сісадміна... Ось про гроші поговорили, а нашо потрібні — не сказали.

На YouTube-каналі DOU відбулась дискусія з українськими DevOps:
DevOps — это идеология, культура, куча всего, чтобы ускорить релизы, чтобы фича, которую разработали, как можно быстрее попала на продакшн, при этом ничего не поломав, не испортив.

Так Devops то культура или человек?))

DevOps повністю провалився. Замість того щоб розробники знали як розгортаються та працюють їх аппи, ми зараз маємо окремий прошарок спеціалістів які достатньо розумні щоб не бути сисадмінами, але ще недостатньо розумні щоб стати програмістами.

Девопс інструменти які є зараз на ринку це тотальне антилюдське сміття. Для того щоб крутити кубернетес вам треба тримати окрему людину яка буде в цьому шарити. Не цього я хотів. Замість спрощення та наближення девів до інфраструктури девопс все далі і далі відгороджується, замикається в собі, та поскладнює стан речей.

Чим швидше вся ця махіна впаде під власною вагою, тим краще буде для всіх.

Бачив я таких девів з «наближенням до інфраструктури», які лізли в базу, міняли всяку хрень чи писали пайплайни. Прод лежав довго і нудно...

Саме тому девів ні в якому разі на продакшн не пущать! І на стейджинг теж не пущать, а то поламають все.

А ще краще взагалі їх позвільняти, бо вони одні проблеми створюють та постійно заважають вам дивитися графіки де шість дев’яток аптайма.

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

Твій комент якраз і є чудовою ілюстрацією стану речей в «девопсі». Якщо ти мене не зрозумів то я вважаю що це ненормально коли для базових інфраструктурних речей, наприклад контейнерної оркестрації мені треба тримати цілий відділ людей у светрах.
Так не має бути.

Из той же серии — почему требуется держать отдел QA, почему бы не писать сразу программы без ошибок?

Так QA же тестируют разные вещи.
а оркестрация выполняется на одном и том же крайне ограниченом наборе железок, но скрипты оркестрации все так же не срабатывают на этом железе без бубна уже сколько? лет 10?

Почему бы программистам сразу не тестировать те самые разные вещи в процессе разработки?
И почему программы, написанные программистами имеют фатальные ошибки, которые приводят к различным катастрофам?

Тому що пошук помилок це творчий процес який неможливо або складно автоматизувати (fuzz-юніт тести поки що слабенькі).

А інфраструктуру можна зробити простою та доступною для всіх, а девопсів перекваліфікувати у програмістів.

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

Серьезно, если для тебя процесс инфраструктуры столь прост по сравнению с QA, то наверное ты настоящий талант. Грешно зарывать его в землю. Предлагаю начать с чего по-проще, например — ru.pcisecuritystandards.org/...​_DSS_v3_2_RU-RU_Final.pdf

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

если это для все так просто

А шо там складного? Ти сам надав специфікацію, значить її можна запрограмувати.

Це так само складно як гайки на СТО крутити, просто часу багато треба.

мы будет продавать эту программу разным финтекам и банкам

З цього треба починати. В тебе є багато клієнтів? Мені здається що ринок для такої послуги надто малий у порівнянні з ресурсами які треба вкласти в автоматизацію розгортання.

Це так само складно як гайки на СТО крутити, просто часу багато треба.

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

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

Тем не менее, программисты пишут программы с ошибками, а заказчик оплачивает отдельно QA. Почему?

оже самое я могу сказать про написание программ без ошибок.

Ні, тому що програму можна запрограмувати багатьма способами якщо задача ставиться «зроби мені реєстрацію юзера». Якщо ж є повна специфікація то це дійсно як гайки крутити.

Все задокументировано же

Так ніколи не буває.

Ні, тому що програму можна запрограмувати багатьма способами якщо задача ставиться «зроби мені реєстрацію юзера»

Я совсем не про то. Речь не о вариации решения а о банальном качестве кода. Например — умение писать код без сборщика мусора так, чтоб не текла память.

Так ніколи не буває.

Интересно, а почему? Ведь писать документацию намного проще, чем работать с инфраструктурой.

Интересно, а почему?

Тому що пишуть документацію не програмісти?

Например — умение писать код без сборщика мусора так, чтоб не текла память.

Ти зараз кажеш про те з чим я борюсь. Очевидно що люди в принципі не можуть писати програми як без помилок, так і без протікання пам’яті. Тому ті ж самі люди зробили софт який фіксить протікання за них.

Те саме я хочу бачити і від опсів. Але натомість опси городять нові складні абстракції. Зробили кубер, але написати дефінішн сервісу самотужки—це вбивство, тому придумали купу тулінгу навколо. Але навіть цей тулінг надто складний і зупинилися на хелмі, який теж для людини без підготовки надто складний.

Я хочу щоб вся інфра стала як хероку. Запушив—і воно само працює. Але це нікому (і особливо опсам) нецікаво. Тому вони все більше ускладнюють стан справ.

О, теперь я все вижу.
Ты очень все обесцениваешь. По-твоему мнению программисты не могут писать документацию, код без ошибок — то есть вести себя как дети, которые имеют право накосячить, а взрослые — подтереть за ними косяки.
И тут ты видишь повзрослевших программистов, которые называются девопсами, и как у любого ребенка со временем у тебя возникает когнитивный диссонанс — сначала тебе кажется что повзрослевшие программисты всемогущи, а потом приходит понимание того, что они делают все не так (максимализм).

Ну что, этап инфантилизма в IT у тебя заканчивается, начинается этап пубертата. Скажу что будет дальше — ты возьмешь на себя ответственность предложить решение, профакапишь, ошибки будут стоить реальных денег (возможно больших), но для заказчика.
У тебя начнется фрустрация и понимание того, что мы живем не в идеальном мире — кругом одни ошибки и надо что-то с этим делать.

Конечно, очень удобно фигачить код в хероку, когда твои ошибки в утечке памяти и O(хз) оплачивается за чей-то счет.

Другое дело, когда ты предлагаешь реальное бизнес-решение, убеждаешь всех его принять, когда на кону ошибка в инфраструктуре будет стоить компании яхты в день (привет aws lambda).

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

"

Но как только ты им станешь, то сразу напишешь еще одну абстракцию. Не из мести, а потому что посчитаешь свою единственно верной. Точно также как считали единственно верными свои абстракции все остальные программисты.

" очень по взрослому ))

Все мы через это проходим. Такова жизнь.

Більшість компаній мають хоча би 1 людину компетентну в цьому, так що цілий відділ тримати не обов’язково. Плюс є різні таски аля міграції з датацентру тощо. Девелопер пише код, опс команда відповідає за інфраструктуру. Всі щасливі, довольні

Ну зачем же так сразу с козырей заходить-то.

Всі щасливі, довольні

...кожен в своєму загончику.
Девелопери продовжують заявляти «працює на локалхості» та «це не моя робота»
Девопси продовжують городити все більш та більш складні штуки для інфраструктури та дбайливо захищають девелоперів від зайвих знань

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

Вот и все, теперь ты тоже девопс. Живи с этой мыслью :)

Андріє, я знаю що таке докер, ба більше, я суттєву частку своєї кар’єри займався саме автоматизацією інфраструктури.

Проблема не в тому, що я не можу розібратися в інструментах.

Я бачу проблему в тому, що інструменти керування інфраструктурою дедалі складнішають замість того щоб спрощуватися.

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

Я бачу проблему в тому що ніхто не хоче будувати прості рішення, натомість винаймаючи цілі відділи «девопс інженерів» які місяці поспіль крутять кубер та дивляться в графану.

Замість об’єднання ми отримали розділення.

Я бачу проблему в тому що ніхто не хоче будувати прості рішення, натомість винаймаючи цілі відділи «девопс інженерів» які місяці поспіль крутять кубер та дивляться в графану.

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

нет того, кто будет отдавать свои деньги за то, чтоб работать было проще. Ибо в этом нет никакой ценности

???

Та контори б з радістю занесли бабла тому хто позбавить їх від необхідності тримати відділи людей у светрах. Але це не є трендом.

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

А ти сам думав щоб написати? Я от думав :)

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

Я думаю та й ти сам розумієш що зробити коробку PCI/DSS яку не треба буде допилювати ще пару років тим самим фінтехам буде нереально, це ж не штука в яку код запхав і воно працює. Там потрібна тісна інтеграція з клієнтом і на це буде витрачено купа часу.

Реально. Есть как минимум 3 таких решения :)

А ну покаж. Чим ми будемо кращі ніж ті три рішення?

Мы не будем — вообще. Потому что на это уйдет огромная туча человеко-часо-какосек

Та ну. Ти сам не зможеш зробити купку тераформ шаблонів, хай навіть за рік часу?

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

коли для базових інфраструктурних речей, наприклад контейнерної оркестрації мені треба тримати цілий відділ людей у светрах

Мне кажется ты про NoOps говоришь. А для этого можно hosted k8s кластер юзать или что-то типа Rancher. Там не rocket science и за пару-тройку лет все можно освоить.

hosted k8s кластер юзать

...поверх якого все одно треба писати купу автоматизації та тримати окремого бородача у светрі.

Справжнє no-ops це хероку або якісь серверлесс платформи. Але вони так і не стали мейнстрімом, натомість девопс спільнота виригала нам k8s який схожий на звіра який вилізає з моря у Апокаліпсисі.

GitOps, на самом деле очень похож в приницпе на Heroku, так что к этому идет. K8s сделали для решения проблем другого масштаба. Он сложный, но чем больше я с ним работаю, тем больше он мне нравится.

И опять же, для hosted решений бородачи не нужны. У нас в команде вообще DevOps нет. Разве что некоторые, вроде меня, стали отдаленно напоминать бородачей. Но это, скорее, отголоски удаленной работы.

так что к этому идет

Та ну куди воно йде :)

Натомість кубер стає де-факто стандартом коли говорять про рішення для інфраструктури навіть якщо продукт не буде використовувати і 10% його можливостей.

Хайп он такой. Как и с микросервисами и со всем остальным.

О каких возможностях идет речь? О том что ты можешь туда деплоить стандартным и общеизвестным и общепринятым способом? О том что написано куча документации? О том что за тебя уже умные люди написали приведение к желаемому состоянию любого твоего декларативного описания? О том что есть куча инженеров на рынке которые могут и умеют его поддерживать а не только установить?

так эти все возможности использует любой проект даже если он из одной апки состоит

Дай угадаю. У тебя проекты куя-куяк и в продакшен при 2 посетителях в месяц (в пике) и с 0 сапортом и слабым пониманием что где задеплоено ибо нужно побырому.

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

Проскролив вашу замітку за посиланням. Як і цей коментар, ваш посил нагадує ниття дитини, для якої чергове «лего» виявилось заскладним. Ви самі перелічили цілий ряд компонентів який сьогодні де-факто став стандартом для розгортання апп: балансер, S3, черги... Кожен з них підтримується окремими великими комюніті, тисячами розробників.

А тепер порівняйте це з тим, що було коли ви починали, у 2007 році. Кількома роками раніше мені достатньо було шарити якийсь варіант *nix-а з apache (tomcat) чи windows/iis для більшості задач, про складні сервісні архітектури я лише читав лекції студентам шевченка. Тепер же мені знадобилося б кілька місяців щоб бодай якось ознайомити їх з сучасними принципами розгортання.

Складність зросла астрономічно і так само астрономічно швидко змінюється. Така правда 🤷‍♂️.

виявилось заскладним

Я добре розбираюсь в «девопс» інструментах, навіть писав свої, коли ще не було потрібних опенсорс аналогів. В мене немає проблем з тим щоб розібратись з черговою тулзою. В мене є проблема з тим, що цей час витрачається марно. Замість того щоб грати на гітарі, я кручу лампи в підсилювачі.

Складність зросла астрономічно

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

Інструменти не спрощуються а лише поскладнюються, хоча я не бачу для цього ніяких передумов. Хай би хто навіть писав свій control plane зверху кубера, але ці проекти на стають мейнстрімом на який переповзає ринок. А ринок перевозає в бік дедалі складнішої архітектури та «девопс відділів».

Я вас розумію, у мене так само від цього горить. З того що я бачу, такий control plane швидко застаріє або ж підтримка його сумісності з інструментами нижчого рівня чи вендорів (AWS, Azure) виявиться занадто повільною і супер дорогою.

ті самі апачі — це вже не просто апп усередині одного сервера, а як мінімум окрестратор, двіжок, ізольовані (на рівні network, fs) контейнери, це все складається з купи нашарувань ледь не по всім рівням OSI. Думаю що навіть вже те що є, це достатньо просунутий рівень абстракції. Це доводиться тим, що без девопсів можна обійтись для невеликих проектів.

ті самі файли — зауважте, це вже диск амазону, S3, теж абстракція зі своїми правилами і купою варіантів налаштування (можна напряму, можна access point, CDN, ...). Звісно можна собі тупо його примаунтити на сервер і не морочитись, але знову з нові вимоги безпеки.

Скажу так, для певних типових речей як на мене наразі усе є (хеллоу хероку) і девопси непотрібні. Для складних як раніше були бородаті сисадміни, так вони і лишаються, тільки називаються більш модним і красивим словом.

Хероку непопулярний, про нього вже ніхто й не пам’ятає, а де-факто стандартом навіть для маленьких проектів зараз стає кубер, завдяки потужному маркетингу CNCF.

підтримка його сумісності з інструментами нижчого рівня чи вендорів (AWS, Azure)

Ну тераформ ж зараз саппортять якось.

Ну тераформ ж зараз саппортять якось.

Так ось якраз тулзи типу тераформа і дозволяють обійтись без бородатих адмінів як раніше. Хіба ні?

Я бачив різні команди — де деви писали «пайплайни», «алерти» і «дашборди» а опси нажимали кнопку бо тіки у них був доступ і навпаки де деви на кожну помилку в білді створювали «тікети» і «скопіпасти» k8s «ямл-и» не могли без 10 помилок. Гугл с їх концепцією SRE підійшов дуже близько до вирішення проблеми — якщо дев команда може сама підтримувати свій сервіс то молодці а іншим — дають команду SRE, яка як правило підтримує декілька сервісів і дев команда багато чим перестає паритись.

Важливо зрозуміти що ви не гугл, я не гугл та ми не гугл щоб просто брати і застосовувати їх підходи.

Я допускаю що рівень абстракцій та масштаб в гуглах настільки серйозний що там треба тримати відділ програмістів які 24×7 допилюють та моніторять Borg.

Але більшість компаній та проектів достатньо невеликі що програміст сам вмів робити інфраструктуру та пильнувати прод. Проблема лише в тому що інструментів для цього йому не дали—все що є на ринку надто складне.

Кстати еще мнение хочу спросить у «архитектора». А что делать с продукт и прожект менеджерами? Ведь разрабы сами могут разговаривать с бизнесом и управлять своими тасками. Да вообщем и эйчары тоже лишний рот на проекте, разрабы могут сами искать и нанимать себе подобных. Прекрасный опыт, поможет пофиксить интравертов.

Цей сисадмін зламався, деплойте наступного.

На вопрос ответь «орхитектар». Ведь все перечисленные согласно твоему постулату тоже недостаточно умные чтобы стать разрабом.

Дядь, йди краще деплой сервіси що девелопери найняти рекрутерами написали по специфікаціям продукт менеджерів в кубернетис який придумали в гуглі, це ж твоя робота. Не витрачай час на порожні балачки.

Boy ну как то не достаточно вумный ответ для того кто назначил себя шибко вумным.

в DevOps и учиться-то нечему, просто достаточно много информации надо держать в голове.

фейспалм.тхт

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

Якщо Всеволод зміг би представити ці 36 пунктів тут у вигляді коментаря або навіть окремої статті, думаю що спільнота було б дуже вдячна)

Дякую за дискусію, було цікаво послухати.

Подписаться на комментарии