Comments 141
Просто программирование в работе девопса очень важно) зачастую приходится разбираться в двух трех языках, для того что бы все работало хорошо)
или рядовая задача написать какой нибудь экспортер для прометеуса, или написать оператор для кубернетиса, это типовые задачи, которые без знания программирования не решить(((
плюсанул бы, но не довопс :)
а так да… кстати, там еще про нейросети и машинное обучение забыли. какой девопс без ML?
Ещё ради спортивного интереса я проходила цикл интервью и получила оффер миддл бэкэнд разработчика (писать REST API на Flask/ORM/MySQL/Mongo/swagger), и там было меньше, чем на сеньёрской DevOps позиции.
Абсолютные цифры "у нас" мало что говорят. Насколько больше-меньше получают у вас девопсы по сравнению с разработчиками на тех же грейдах? У нас вот плюс-минус одинаково. Даже хантят на одни суммы хоть на сеньор девопса, хоть на сеньор разработчика. Тысяч 50-70 американских долларов в год.
Абсолютные цифры «у нас» мало что говорят. Насколько больше-меньше получают у вас девопсы по сравнению с разработчиками на тех же грейдах?
Зависит от стека. Более того, я считаю девопсов разработчиками, но инфраструктуры. Есть стеки, где разработчики получают больше, есть где меньше. Внутри девопсов тоже не одинаково, те же Golang/Kubernetes девопсы явно дороже других.
при этом "у вас" — это не то же самое, что "у нас" (применительно, я думаю, к любым странам/территориям).
В некоторых странах DevOps больше или сопоставимо получает, чем разработчики
И там тебе не будут рвать мозг.
Зачем люди, не хотящие учиться, вообще нужны? Девопс это не эферемизм для админов, которые считают себя немножко лучше других, научившись писать баш скрипты, и прочитавшие пару книжек по terraform, запустившие кликанием мышки разок в жизни Google Kubernetes Engine, в сравнении со своими коллегами, всё ещё мышкатыкающими в MS AD,
К слову а то про что говорите называется SRE или Software Engineer ну или DBA или ML-инженер
Разница между DevOps и SRE в том, что первый с уклоном в в CI/CD, а второй в инфраструктуру как код. Но это в теории. На практике этим занимаются одни и те же люди, в смысле в одной команде ты делаешь пайплайны, в другой, например, экспортёры для Prometheus. И обеим специализациям нужно уметь в кодинг, или no hire. Сейчас нужны задачи по написанию операторов Kubernetes, по написанию Serverless функций по обслуживанию инфраструктуры. Погуглите термин ChatOps, и учите кодинг, если не хотите завтра оказаться за бортом:
И там тебе не будут рвать мозг.
Не получится так ничего
Ага это в целом даже не специальность, а методология для работы в команде).
Уже специальность благодаря хрюшам
Но по факту, хитрые работодатели пытаются заменить эту команду одним человеком оркестром который будет делать все, платя может на 20% больше.
Клёво же. Деньги это хорошо. Ну и не на 20%, имхо.
P.S. К слову согласно методологии, не должно быть отдельного человека который будет например, экспортёры для Prometheus делать
Нет разница в том что DevOps это методология.
Методология и прочий сферический Agile/Kanban/etc в вакууме отдельно, реальный рынок труда отдельно. В нашей и в куче других контор SRE это кто больше (но не исключительно) пишет тераформ, кубернетес операторы и лямбда функции для инфраструктуры, а DevOps это те, кто пишет врапперы вокруг тест кейсов, проектирует CI/CD пайплайны, соединяет в одно целое ops, dev и qa. Я работала и в качестве SRE(в других компаниях) и DevOps (сейчас и в других конторах). Мне больше нравится DevOps, т.к. не отвечаешь за продакшен, а отвечаешь за пайплайны и другую инфраструктуру для разработки, которые ночью и в выходные не нужны. Обычно DevOps может работать SRE, а SRE девопсом. Собственно, я могу работать и QA, и BackEnd разрабом. А вот одмин, который боится перегружать головку, нет.
То с работой все куда легче и вакансии в разы интереснее. Так что ещё вопрос кто остается за бортом
У нас (я в Канаде) вакансий админов уже вообще нет. Есть вакансии хэлпдеска, а люди без кодинг скиллов не нужны. Другое дело, что те, кто их клеймят их не имеют на самом деле, лол
А по факту есть люди-программисты инфраструктуры, со скиллами одминов, разрабов и QA, и это и есть моя специальность. Проблем с количеством офферов, когда я ищу работу у меня никогда не было, как и с тем, чтобы учить новые технологии. Почему Вы боитесь сложных задач я тоже не понимаю.
Специальность мне нравится, но не нравятся некоторые возможные задачи. Например, писать кубернетес операторы или лямбды, или чатботы, или тесты для бэкапов мне нравится, но мне не нравятся овертаймы, которые у админов постоянно и у SRE тоже частенько (если напишут кривой кубернетес оператор, который должен автоматически чинить продакшен).
Ничего сложного в том же кубере
Хм, как много патчей Вы писали для тех или других Kubernetes операторов?
Может быть, у Вас есть свой оператор, как pet project?
К слову вы не видели наверное какие интересные штуки лет 15 назад админы на перле писали. Там реально были иногда просто офигенные вещи. От которых не знаешь или плакать или восхищаться. И это все равно не делало их программистами. И не говорило о том что они умели программировать.
Мне тоже не нравится говорить «я умею программировать», это очень громкое заявление, если его сделает Ритчи, Керниган, или Гвидо, или Торвальдс, оно будет звучать достаточно весомо. Я предпочитаю считать себя говнокодером-инфраструктурщицей, но проблема в том, что большая часть людей на рынке DevOps/SRE/ops не умеет ничего даже отдалённо похожего.
Причём даже далеко не все backend разработчики знают то, что должны, в общем-то, знать, увы.
Считаю что писать yaml'ы
ХЗ, хз, в последнее время я пишу(пытаясь не говнокодить по-возможности) чаще всего на питоне и голэнге. С yaml'ами я работаю, конечно, но я их скорее создаю, в смысле, структуру yaml'ов для кубернетес оператора, например. А serverless/AWS lambda это вообще не про ямлы, как и chatops подход.
Кстати, terraform'овский диалект вполне себе вещь в себе. Круто, например, что он декларативный (как Puppet). Нет ничего плохого в том, чтобы кодить на декларативных диалектах, это вовсе не стыдная работа, а очень нужная, и требует достаточно глубокие знания, чтобы делать это хорошо и правильно.
Ну или например, берёшь ямлы из банального ансибла, и цепляешь их к утилите через питоновский модуль ansible-runner, и вызываешь из питон кода. Эта утилита вызывается, например, из test suite/CI. Может, это у Вас задачи такие, с «программированием только на ямле», не знаю :(
У меня, например, сейчас задачки по написанию пишу инфраструктурного тулчейна для тех, кто, собственно, пишет код продуктов.
Разница между хипстером с бородой пьющим смузи и опытным админом только в том что хипстер начнет все без разбора пихать в терраформ, кубер и т.д. И будет делать это пол года.
«в наше время трава была зеленее», вы бы ещё перфокарты вспомнили и программирование в машинных кодах с помощью дырокола. Это звучит не очень профессионально, сорри
А админ сначала оценит задачу и если что спросит
И это тоже
Пофиг сколько времени это решение займет. Пофиг сколько денег компании потребует.
Тулчейн для разработчиков даёт очень много денег компании: представьте сотни разработчиков, и сэкономить им час-другой в день — это же офигенно!
А ещё, меня по-настоящему удивляет, что для кого-то написание кода на питоне и голэнге это что-то сложное, нестандартное и трата ресурсов работодателя бесцельная. Странно это. Вы в курсе, например, что сейчас считается правильным подходом автоматизировать ops работу написанием Кубернетес операторов, перенося в них все те инструкции, которые обычно компании имеют, как что-то пофиксить руками (вроде зайти в AWS консольку и ткнуть во что-то, или через ssh и запустить команды, если какая-то специфическая ошибка в логе/мониторинге)?
Мне кажется, люди, для кого писать на ямле легко и быстро, а на питоне(js, golang, итд — хотя бы на одном языке) сложно и долго, просто не нужны на рынке.
Меня удивляет что кто то не понимает что эти костыли и велосипеды нужно поддерживать. Как и любой другой код.
Конечно. А меня удивляет, что кто-то думает, что лапшу в ямле поддерживать проще, чем аккуратный компактный оператор в кубере или лямбда функции. Если же для кого-то на самом деле так, точно профессия была выбрана верно? Может, этому человеку лучше всё-таки в курьеры?
Вот назовите хоть одну причину, зачем это все тащить в go инфраструктуру и кубер?
Даже один час десятка-другого девелоперов, сэкономленные, позволят сэкономить компании тысячи долларов на длинной дистанции
Вот назовите хоть одну причину, зачем это все тащить в go инфраструктуру и кубер? Или зачем под подобные задачи делать кубер, го скрипты и прочую дичь?
А вы читали вообще что я писала? Например, автохилинг через кубернетес операторы: если прод упал ночью, пока кто-то проснётся, пока включит комп, пока запустит VPN, пока разберётся что произошло, и прочитает инструкции, контора может потерять кучу денег. Если есть инструкция, как чинить продакшен, её можно описать в кубернетес операторе.
Да, бывают случаи, не описанные там, но речь, собственно, не о них.
Или, например, юнит-тесты для инфраструктуры, функциональные для бэкапов и дизастер рекавери сценариев — я должна и это объяснять, зачем нужно?
Ещё вы почему-то проигнорировали насчёт chatops: а ведь сейчас девопсы очень часто пишут чат-боты для слака и жиры (на фронтэнде), или для github, gitlab, итд и с инфраструктурой на бэкэнде, и это экономит бэк, фронт, DBA разработчикам кучу времени.
Чат-боты Вы тоже собираетесь «программировать на ямле»?
Да одна только сертификация
Всегда сочувствовала тем, кто работает в госпараше. Как вы там боретесь с burn-out'ами? Не скучно?
К слову про автохилинг. Если у тебя есть проблема которая появляется несколько раз, ты знаешь причины и как её лечить. То какого черта. Почему ты не сделаешь так что бы она не повторялась? Это как раз стандартная работа админа/разраба.
Есть одна команда, она пишет бэк. Есть другая команда, она пишет инфраструктуру как код. Баги в беке фиксит команда, которая пишет бек, нет? А автохилинг это страховка продакшена от багов в беке. Как и CI/CD и автотесты — часть из которых (юнит) пишет бэк команда сама, а часть QA команда (функциональные, end2end, интеграционные итд)
То в конце месяца счет очень порадует руководство.
Так это проблема как раз программистов на ямле, за хайринг которых Вы так топите. Они не понимают как это всё работает, делают неподдерживаемую лапшу, т.к. кем-то считается, что не нужно обладать глубокими знаниями, чтобы программировать инфраструктуру. Как раз нормальный SRE будет чекать что там в биллинге — например, у него будет алерт в мониторинге на превышение бюджетов
Если есть инструкция, как чинить продакшен, её можно описать в кубернетес операторе.
обычно эта инструкция — перезапуск, что и без оператора решается обычной liveness пробой. А всё, что сложнее, это уникальные случаи, сломалось — починили — починили в коде так, чтобы оно больше не ломалось в этом месте. И тут без человека никуда. А если у вас в компании чинят код костылями и лейкопластырем — бегите оттуда.
Микросервисы модная штукану да. А что такое микросервисы? Это слабосвязанные сущности, их можно деплоить независимо. А если у вас зависимости — у вас монолит, просто разделенный на несколько приложений/контейнеров/etc, но монолит.
А работать всё будет без etcd или без kube-proxy?
Какое отношение эта фраза имеет к разговору выше? Окей, возможно вы меня не поняли, давайте я перефразирую. Вы говорите, что вам приходится писать k8s-операторы, чтобы не было проблем с деплоем приложений, состоящих из N контейнеров, связанных жестко друг с другом (т.е. которые нельзя деплоить в произвольном порядке). И далее называете такое — микросервисами. А я вам пытаюсь объяснить, что это — не микросервисная архитектура, это всё равно архитектура «монолит». Т.к. вся фишка микросервисов в том, что каждый из них имеет свой собственный релизный цикл, независящий от других. Захотел — обновил, захотел — перезапустил. Каждый микросервис сам поддерживает какую-то обратную совместимость с собственной прошлой версией через фиксацию соглашений, feature-флаги или как-то еще. Запускать свой монолит вы можете где угодно, хоть в k8s, но он от этого не перестаёт быть приложением, построенным по архитектурному принципу «монолит».
связанных жестко друг с другом (т.е. которые нельзя деплоить в произвольном порядке).
Я этого не говорила. Я сказала другое: что обычно в компаниях есть ранбуки, которые написаны для того, чтобы пофиксить те или иные типичные проблемы. Так вот, вместо того, чтобы поддерживать страничку в вики с ранбуком, лучше поддерживать k8s оператор, который сам применяет логику ранбука, а как и что он делает пояснить в комментах к коду.
Я этого не говорила.
Возможно я неправильно понял, объясните пожалуйста, что значит фраза
достаточно сложной инфраструктурой с большим числом внутренних зависимостейк которой в продолжение были упомянуты микросервисы?
Порядок запуска обычно ни при чём (разве что для легаси какого). Речь о всяких стейтфул штуках, о репликации баз данных и брейн сплитах, о реакции на внутренние метрики микросервиса, которое оно отдаёт наружу, и которые как раз может обрабатывать оператор, меняя инфраструктуру, итд
Вы в курсе, например, что сейчас считается правильным подходом автоматизировать ops работу написанием Кубернетес операторов
У кого считается правильным? Не у всех считается правильным внедрять не то что Кубернетес, а Докер или другие контейнеры.
У кого-то считается правильным автоматизировать работу ops плэйбуками ansible, у кого-то рецептами chef, у кого-то простынями bash или вообще php :)
А в целом вы слишком категоричны. Никто не говорит, что внедрение того же Кубернетес бесцельная трата ресурсов компании. Но это и не однозначно выгодная инвестиция.
Я вот взял бы себе в команду "yaml-программиста", чтобы остальную команду вообще "devops" и ops вопросы мало касались. Пускай поднимает Кубернетес, пускай поднимает пайплайны и пишет докерфайлы. Даже операторы пускай использует, но только те, у которых тысячи звёзд на гитхабе. Самописные — нет. Кто в них потом разбираться будет, когда ему у нас станет скучно, а какая-то крупная компания предложит ему позицию разработчика операторов?
На рынке есть ниша для людей, которые легко и быстро пишут на yaml в рамках популярных продуктов, а на языках общего назначения только в случае крайней необходимости.
Я вот взял бы себе в команду «yaml-программиста», чтобы остальную команду вообще «devops» и ops вопросы мало касались.
пускай поднимает пайплайны и пишет докерфайлы. Даже операторы пускай использует, но только те, у которых тысячи звёзд на гитхабе. Самописные — нет.
Вы тоже не понимаете, что лапша в ямле ничем не лучше лапши в голэнге, питоне, js итд. Она не лучше в вопросах поддержки.
Ещё раз, компактный оператор на golang куда лучше километровых yaml конфигов, которые писал туповатый чел, боящийся «программирования»
Чем лапша на ямле хуже лапши на питоне или го?
Ну и как бы вот вы меня сейчас туповатым назвали. Я километровые конфиги на ямле пишу, а операторы нет. Да, боюсь. Я уверен, что у меня недостаточно квалификации, чтоб писать операторы. Я даже слабо представляю, что это такое, но подозреваю, что могу легко кластер положить.
Мой предел в экосистеме Кубернетес — это adhoc хелм-чарты, которые те же километровые ямлл-конфиги, вернее шаблоны для них с вырвиглазным синтаксисом гоу-шаблонизатора. Мне не место в индустрии, потому что я не хочу глубоко разбираться в личное время с очень узкоспециализированными знаниями и приобретать несильно востребованные в рамках моей основной специализации навыки? А на ямле и обычные конфиги приложений, и CI/CD, и конфигурация серверов, и облака, и куча всего ещё.
Особенно учитывая, что Кубернетес в обозримом будущем я использовать не буду. AWS или docker swarm — возможно, но k8s маловероятно — хлопотно это.
Чем лапша на ямле хуже лапши на питоне или го?
Ничем не лучше. Я сказала, что если задача решается километровым и невнятным, сложно поддерживаемым yaml-конфигом, и оператором на golang (python, etc) в несколько строчек, то нужно выбрать оператор на полноценном языке программирования. А со страхом писать не на ямле можно бороться, например, походами к психологу
На рынке есть ниша для людей, которые легко и быстро пишут на yaml в рамках популярных продуктов, а на языках общего назначения только в случае крайней необходимости.
а что значит "писать на yaml"?
Или обычными программистами, которым проще написать по туториалам ямл для задачи, сопутствующей основной, чем изучать новый язык и системное программирование на нём.
так конфигурятся или пишутся?
а то, получается, я умею писать на ямле, джейсоне, иксэмэле, ини (есть такое название?) и даже, о ужас, на плайнтексте.
а что значит «писать на yaml»?фраза родилась из ситуации, когда ты вроде бы как сис.админ, автоматизатор и короче не программист, а тут наступил кубернейтс и вот ты месяц просидел в текстом редакторе и только yaml и правил.
И сделать нормально на 5-10 дедик серверах.
интересно, 5 — это уже не один, тут уже автоматизация нужна. Может быть им надо «нормально на AWS» или вообще как угодно, лишь бы «нормально», потому что у них просто бардак?
Возможно, простой перенос с "нормально на дедиках" привёл к "проблемы на AWS" или "очень дорого на AWS", потому что, например, условный ansible с AWS не очень дружит и вообще надо было архитектуру менять или хотя бы частично на managed сервисы/серверлесс переходить, а не поднимать rabbitmq кластер на ec2 просто чтобы письма слать асинхронно
а люди без кодинг скиллов не нужны.
ого, у всех уже поднят кубик, развернуты ci/cd и т.д.? До более-менее программирования типа написания операторов еще дожить надо (а может они и вообще не понадобятся, ну точнее возьмешь всё готовое и переписывать не будешь).
Ну, из открытой инфы зарплаты "девопсов" плюс-минус равны зарплатам разработчиков того же уровня. Это если иметь в виду под "девопсом" специалиста, основной обязанностью которого является инфраструктурное обеспечение процессов разработки и эксплуатации: развертывание инфраструктуры и приложений от локальной машины разработчика до продакшена, обеспечение их мониторинга, логирования и прочей обозреваемости, настройка пайплайнов и т. п.
А можно примеры? По моим представлениям обычный девопс получают примерно столько же как обычный разраб.
У девопсов/SRE так же: chatOps, gitOps:kubernetes/golang devops'ы дороже, чем «программисты ямлом на ансибле»
Собственно, DevOps кубернетес стека точно дороже большинства веб-бэк и фронт разработчиков, но сипипишники и Scala разработчики точно дороже.
Если же мы возьмём «девопса» с опытом написания автоматизации на баше, то Django разработчик будет дороже.
Я несколько раз меняла свой стек:
Puppet > Puppet/OpenStack > Puppet/Ansible + Python / OpenStack > CI/CD (написание фреймворков для автотестов итд, дженкинсы, argoCD, итд) + Kubernetes + Golang + Python.
Сейчас тоже самое, только ещё serverless добавился
Возможно зависит от географии, но я беру европу, штаты, израиль.
Ну а в России — на одном уровне. Если ты senior — так хоть девопс, хоть php. Есть другая проблема — по факту сеньор может боятся менять работу, или идти на удаленку или че-то еще, и получать ниже, чем мог бы. А в этой же конторе может работать условный программист, который будет получать по рынку, потому что он на такую зп пришел.
Я вот по себе смотрю: 5-7 лет не работал с сетями и все знания улетучились. Я без жёсткого повторения не порисую строение пакета и разные бинарные/сокральные значения в tcpdump.
Да и за 7 лет второй родной язык забыт — могу понимать, но не говорить :(
А за 10 последних лет в сетях надобность резко сокращается, и в iptables и в прокси серверах и в баше и т.д.
С другой стороны на Амазоне столько штук, что можно докторскую делать по одной — обновления каждый месяц.
Не видно ещё Spark, Flink, Kafka, Hadoop, Storm, Redis, Nginx, DNS( Route53, Akamai, dyn ), CDN.
Блин чего только nginx или Akamai стоит.
Но все эти технологии не помогут человеку решать задачи или же общаться с другими командами или в команде.
Вообще сейчас за год можно сделать скачек и изучить многое. А если в команде есть тот, кто поможет...
нужно решать проблему в корне
Это не всегда работает. У меня был клиент у которого приложение постоянно убивалось из-за недостатка памяти, в ответ на ествественный совет докупить памяти он упорно отмахивался — "ну рестартанет, не проблема". Приложением было mysqld.
Про корневой протокол
Это что за протокол?
Новичок, не знающий Docker, спокойно в нем разберется, если у него есть понимание, что такое HTTP, TLS и сети
А какая взаимосвязь между http и docker? В смысле как знание http поможет в освоение docker?
Типичная задача: поднять публичное (читай — https must have) веб-приложения на Докере. Усложнение сам Докер должен удалённо управляться, на сервере есть только он по сути.
Типичная задача: поднять публичное (читай — https must have) веб-приложения на Докере.и как знание http протокола поможет в данной ситуации?
Усложнение сам Докер должен удалённо управляться, на сервере есть только он по сути.Что в вашем понятии управление докером?
Ну надо понимать что будут идти http запросы, знать про коды возврата, что должны слушаться 80/443 порты, настроить веб-сервера, повесить TSL и т. п.
Обращение к API Докер демона. Чаще всего CLI клиентом Docker. По дефолту обычно он стучится к локальному серверу, но может и к удалённому
Можно зайти на СО или в документацию и настроить. В гугле на медиуме будут статьи о том как надо «правильно» с командами.
А вот знания http не помогут кастомно соединить контейнеры методом построения своих неймспейсов, бриджей и цгрупп.
Я хочу услышать, чем отличаются TCP и UDP. Хороший спец ответит мне, почему критичные системы (например, Domain Name System) используют протокол без гарантированной доставки сообщений (UDP).
Вы ведь в курсе, что DNS и по tcp работает? И в большинстве случаев "критичные системы" работают таки по tcp ибо он гарантирует доставку. Например трансфер зон в dns не просто так работает по tcp ;)
Протокол DNS использует для работы TCP или UDP-порт 53 для ответов на запросы. Традиционно запросы и ответы отправляются в виде одной UDP-датаграммы. TCP используется, когда размер данных ответа превышает 512 байт, и для AXFR-запросов.
Гугловые TXT записи весили меньше 512 байт и спокойно приходили по UDP, а вот яндексовые уже не влезали.
Двоякое впечатление. Вроде по всем темам могу поговорить, по каким-то более предметно, по каким-то менее. Но увидев в вакансии в требованиях все названия даже откликаться бы не стал с фразой типа "за 30 лет в ИТ я с почти всем этим сталкивался, но кроме разработки по остаточному принципу, вернее по принципу" кто если не я поднимет и настроит"
У меня к статье то же недовольство и занудство, что и к 90% вакансий с упоминанием devops, и к лично вашему практикуму, собственно (к практикуму не только это, ну да ладно). Это все чисто инженерные навыки, которые к devops имеют весьма косвенное отношение. Перестаньте лепить ярлык devops на людей, которые просто админят все, что админится. Этим занимаются обычные админы, никаким devops тут и не пахнет. Бд тут вообще ни к селу, ни к городу. Лучше б про мониторинг и логирование темы включили, про гит и ветвление там, да хоть про облака, уж это куда более в тему.
Как вопросы на собеседование чисто админу, это вполне ок. Не без удовольствия пытался отвечать самому себе, подметил какие-то пробелы (закрывать я их конечно же не буду, пока мне не потребуется это в работе или еще где).
Разве тебе не любопытно было узнать, как работают все эти штуки, в которых ты тыкаешь курсором мышки?
Мне вот как-то задали подобный вопрос после собеседования, которое я завалил, я тогда ничего не ответил, потому что был ненужным никому студентом. Да, любопытно, а еще мне любопытны тысячи тем, про которые вы не спросили, а еще я готов эти знания подтянуть, иначе бы я и сам отказался, даже если бы мне сделали оффер, а то и вообще не пришел, если бы вы все эти требования включили в вакансию, а не преподнесли в виде сюрприза. Что это за обвинения людей в недостаточном любопытстве? Человек пришел собеседоваться на конкретную должность с конкретными требованиями, а его проверяют на совпадение интересов и бэкграунда.
Дело впрочем ваше, можете хоть просить кандидатов продать ручку. Не нравится только, что вы и других если не учите тому же, то подаете им на мой взгляд не самый лучший пример.
Как-то слабо. А почему нет terraform, k8s, grafana, tsdb на худой конец? Где IPv6? И почему ни слова про http/2 или http/3. Последний, кстати, основан на UDP, так что не надо про критичные сервисы. А ещё не коснулись облачных провайдеров типа GCP или AWS (я уже молчу про специфичные типа Aptible).
А если серьёзно, то DevOps он может быть разный от компании к компании. Ваш список хорош, но потому что он подходит под ваши запросы. Ультимативным я б его всё-таки не назвал.
Всё, что перечислил автор, в той или иной степени (всесто докера были начальные системы полной вируализации, потом OpenVZ, lxc… и так далее) было «сисадминством» ещё когда я начинал в нулевые.
Скрипты для выполнения рутинных задач писали и раньше, только вместо ныне модного Python — на Perl, tcl, awk… Без разницы какой год, посмотрите на зоопарк утилит в Юникс-компатибильных системах.
При этом человек может ответить на все вопросы, а код писать очень плохой (используется эвфемизм к более распространённому эпитету), и толку от него как от девопса, того самого девопса, который может сесть с программистами бэкенда и вместе сделать как надо, будет ноль.
Знает ли мой собеседник, что такое MX-запись, как работает spf или как работает DKIM.
А вы сами точно уверены что знаете как оно работает? Тогда скажите зачем человека расспрашивать о технологиях защиты от подлога электронных писем в SMTP, на вопросах о DNS?
Или как распарсить какой-нибудь access.log в Nginx средствами BASH. Чтобы человек рассказал про awk, про cat, про sort, про все, что помогает быстрой работе.
Так вы про Bash спрашиваете, или всё же про кучу других утилит/языков, к Bash имеющих такое-же отношение как и PowerShell?
А то «распарсить какой-нибудь лог» на чистом баше, это тот ещё кактус пожевать.
Новичок, не знающий Docker, спокойно в нем разберется, если у него есть понимание, что такое HTTP, TLS и сети.
Оказывается чтобы разобраться во внутриустройстве докера надо не о принципах работы ядра линукса (и интерфейсов им предоставляемых) иметь предствавление, а о нескольких протоколах из стека TCP/IP.
Я это на самом деле злорадствую, подражая тону статьи.
Ваш гайд ультимативный, но точно не по DevOps.
Про айноды ещё надо спросить обязательно!
Или например про OSI — я помню что там 7 уровней, но на вскидку я их не назову и за что они отвечают.
Надо знать все юниксовое, все Unix-like системы. Нужно уметь работать с Shell и Bash, знать основные команды. ls-ы всякие, mkdir и т.д.ну разве что для джуна/мидла. Если бы мне задавали бы подобные вопросы на собеседовании — то я просто бы сказал, что дальше общаться нет смысла
…
По Linux спрошу, как заменить в файле строчки другими строчками. Или как распарсить какой-нибудь access.log в Nginx средствами BASH. Чтобы человек рассказал про awk, про cat, про sort, про все, что помогает быстрой работе.
Просто: нужно выключить fsync,ну такое, может стоило бы включить логирование долгих запросов и посмотреть какие запросы, например, не используеют индексы? А то ведь от условного запроса вида select * from table1 where field1 like '%some text%' ни один fsync не поможет.
А еще разработчики любят писать
1: Кандидат не знает ответ на вопрос, не хочет говорит об этом, проблема с признанием ишибки/незнания
2: У кандидата сильно большое эго он «недостоин» этого вопроса
3: Вместо того что бы спокойно ответить и объяснить почему этот вопрос не из его темы отвергает вопрос, проблемы со стабильностью, будет проблемно работать
4: Кандидат не понимает что в вакансии описан всегда идеальный кандидат, а люди приходят разные, кто то пишет на баше а кто то давно перепрыгнул это черту, мы знать не можем заранее что у вас с опытом.
Таким образом я просто экономлю и свое и их время и все довольны. Не вижу смысла в подобных ситуациях тратить свое время. Все же на junior/middle/senior позиции вопросы и их уровень должны отличаться, имхо
Есть разные подходы, например, начинать с простого, для разминки, и прсикпкнно повышать уровень, а есть наоборот. Обычно первый нормально работает, если подготовить собеседника фразой типа "мы.сначала по азам пробежимся, не против?"
Обычно в компаниях которые очень любят хитрые тесты по башу — творится бардак.
О нам нужно логи авком чекать, а заимплентируй нам Logstash за 20 минут в баше.
DevOps != Системный инженер
Что насчет овнерства процесса перехода на короткоживущие ветки в команде, в следствии изменений бизнесс процессов, только не для нового проекта, а для команды которая живет в долгоживущих бранчах уже года 4, а бизнесс процессы поменялись например пол года назад и до всех стало доходить, что дальше так продолжатся не может, а по другому они не умеют? (Не ну я не про тех, кто просто меняет компании и команды в этом случае, кому-то это все равно придеться разгребать)
Экономика разных облаков? Когда лучше в ажуре, а когда лучше в авсе? А когда лучше потратить месяц, но переехать и почему? А может on premise для этого проекта лучше?
Пол команды за ангуляр, а вторая половина за реакт, вставите свои 5 копеек? А с 11 явой в докер лучше? Настолько, что стоит переписать старый кусок с 8й или нет? А стоит ли вписать в проект эластик между бекендом микросервисов в (не суть, мезосе, кубере, да хоть сворме) и клиентским mssql? А вот если надо, что бы переводы на 12 языков шли вместе с релизом который едет по готовности сам по себе в любой момент, то как это может выглядеть? (сейчас оставание 4 недели после релиза, надо не больше дня — какие мысли ?)
Может и не во всех деталях, но в целом представление и понимание о таком надо иметь?
Как насчет умеющего вот это всё в сеть (я если че ex ccnp&ccvp, хоть и забил на ccie) но в конфлю\any wiki он доки не пишет? Возьмете такого?
А что кандидат думает про дейлики? А он кстати знает зачем груминг&планинг вон у тех ребят? А он кстати на них ходит\участвует? Я стараюсь спрашивать, а зачем он в них участвует (если) и как. (ответ на этот вопрос, это не плохо или хорошо, просто дает понимание о взаимодействии и опыте). А у него кстати опыт работы в выделенной команде девопсов на множество команд или он часть команды? А как больше нравится и почему?
Тестовое задание — вы собираетесь апнуть EC2 с продакшен постгресом, напишите письмо не более чем в 200 слов для своей компании, целевая аудитория письма — сапорт инженеры и лидеры команд.
Так долго можно продолжать и это все будет ни про сеть, ни про баш, ни про логгинг, ни про трейсинг ни про модель OSI.
Лично мне кажется, что эти моменты зря пропущены.
А вот для девопсов которые бывает из программистов конвертируются, мне кажется эта статья может помочь выявить стороны, которые стоит изучить :)
И еще я думаю, это прекрасно иллюстрирует то, почему джуниор девопсов не бывает. (где-то на хабре кстати эту мысль прочитал, спасибо тебе неизвестный мне автор).
— А с 11 явой в докер лучше? Настолько, что стоит переписать старый кусок с 8й или нет?это однозначно не компетенция devops инженера и он не должен знать ответы на подобные вопросы, имхо
— Пол команды за ангуляр, а вторая половина за реакт, вставите свои 5 копеек?
Мои примеры не для выставления оценки «хорошо\плохо» и тут нет «должен» или «не должен» знать. А для составлении представления об имеющемся опыте и знаниях. И это определенно не ограничиваетя переченем вопросов из этой статьи.
Вот прямо хорошие вопросы!
Тестовое задание — вы собираетесь апнуть EC2 с продакшен постгресом, напишите письмо не более чем в 200 слов для своей компании, целевая аудитория письма — сапорт инженеры и лидеры команд.Более прекрасного тестового задания ещё не встречал. Браво!
Мне кажется 90% разработчиков которые учились в университете на IT специальности должны ответить по тем сетевым вопросам что в топике. Что такое маска, IP, DNS, ISO уровни, ARP, RIP, это всё впихивается в 1 семестр. И остаточных знаний достаточно. Я вот читая статью и строча этот коммент вспомнил что это такое, хотя учил более 10 лет назад :D
А что такое 127.0.0.1?
DevOps тут и не пахнет.
P.S. За разбор логов вручную — в 2020 принято бить по рукам. Где централизация логов? Где SIEM? Где алертинг? Вот это все…
В быстром отборе резюме помогает правило: чем больше технологий я встречаю, тем лучшеЛучше чего? И на сколько? Человек может написать много разного, с которым он имел шапочное знакомство или вообще мимо проходил.
Хороший спец ответит мне, почему критичные системы (например, Domain Name System) используют протокол без гарантированной доставки сообщенийХороший спец, который знает цену потерянной обратной связи с объектом в критичной системе, вам наверно не ответит.
Инженеру нужно понимать это хотя бы на базовом уровне — есть корневой центр сертификации, он подписал сертификат, и сертификат где-то используется.Только вот зачем? Асимметричная криптография это не про то что кто-то где-то подписал сертификат и его используют.
Обычная виртуализация, виртуализация через гипервизор.Виртуализация через гипервизор — это понятное дело. Бывает первого рода и второго. А что тогда обычная виртуализация? На чём она работает?
Скажи мне, как человек деплоит, и я все пойму. Он может деплоиться с помощью Helm в Kubernetes, Ansible, скриптами или чем-то еще самописным.Что вы скажете о человеке, который пишет операторы для K8s и деплоит их через kubectl?
Допустим, база сейчас сидит и упирается в диск. И с ней ничего не сделать — больше сервер никто покупать не будет. Как сделать так, чтобы оно работало быстрее прямо сейчас?Это точно вопрос к девопсу и вообще к техническому специалисту? Бизнес хочет чтобы его данные были целыми и сохранными, но не хочет за это платить. Чем это может закончится, очень хорошо знаю. Прям ну очень хорошо. Наверное не один такой. Почему из-за скаредности бизнеса надо грех на душу брать?
Просто: нужно выключить fsync, чтобы база не дожидалась записи с данных на диск, а как бы сохраняла.Что уже тогда мелочиться? Давайте vacuum отключим и check point сделаем как можно реже, вообще перестанем писать WAL.
контейнерная и гипервизорнаяПрошу простить меня за занудство, но контейнерной виртуализации (если мы имеем в виду стек CRI) не существует.
Есть ещё масса вопросов, но важен пока один. На какое вознаграждение по ЗП может рассчитывать кандидат после успешного прохождения такого отбора? Предполагаю, ответ на этот вопрос будет интересен многим читателям этой статьи.
Как я собеседовал "девопсов":
- составил картинку того, что у нас есть уже и чего нам хотелось бы через год-другой
- спросил несколько вопросов как бы они решали те или иные задачи уже нами решенные "на коленках", выслушал, рассказал р наших способах, попросил сравнить, назвать плюсы и минусы этих подходов
- спросил как бы решали задачи из списка наших хотелок
А фиг знает, что ещё спрашивать: знал бы — мы бы "девопса" не искали, сам бы всё сделал
Ультимативный гайд по собеседованию DevOps-инженеров — что спрашивать и к чему готовиться