Comments 136
Мы прямо сейчас ищем (или уже нашли?) человека с релокацией и пачкой плюшек. Мы написали в вакансии devops, чтобы отсеить эникейщиков. А на самом деле мы искали системного администратора linux.
И вы знаете, что я обнаружил? Что чем больше человек devops, тем меньше он администратор. В какой-то момент в рамках коррекции сложности вопросов я стал спрашивать такой: "предположим, у вас на сервере есть непривилегированный пользователь, и вы не хотите возиться с sudo, но вам надо разрешить этому пользователю редактировать файл в каталоге /etc. Как бы вы это сделали?". Если вы думаете, что я хочу подловить тут человека на SELinux, AppArmor, xattr и ещё какой-то волшебной хрени, то нет. Вопрос на chmod/chgrp/addgroup. Вопрос с подсказками, если человек идёт в правильном направлении, его поддерживают.
Так вот, чем больше человек использует слова staging, preprod, стенды, ci/cd, тем хуже он отвечает на этот вопрос. А когда его про вот эти 'preprod' спрашиваешь подробнее, выясняется, что да, там пайплайны, и они проверяют софт. Как проверяют? Откуда берут данные? O_o Ну, они деплоят и проверяют. Как? O_o.
Моя гипотеза: нахватавшиеся по верхам умных слов про ci/cd имеют эти слова как центр профессии и ничего кроме них не знают.
А для системного администратора ci/cd в (условном) jenkins — это всего лишь ещё одна простыня из баша, ансибла и какой-то матери (или другой комбинации технологий и какой-то матери), которая частный случай от того, чем он обычно занимается.
Вангую, что несколько лет, и слово devops станет условно-ругательным (как 1с-ник для вакансии программиста).
Если кто-то решил выучиться на 'devops'а — учите основы. Файлы, пайпы, процессы, пакетные менеджеры, сокеты, блочные устройства, маршрутизацию в ip.
Я назвал это явление new school devops по аналогии с new school developer, который пишет код, но вообще ни малейшего представления не имеет как и где это работает. А потом приходит с "дайте мне хотя бы гигов 256 на сервере и ниче не будет тормозить. А чё, сейчас в игровых тачках уже столько ставят, а мы тут не лапти вяжем" или "Да ты знаешь сколько стоит время разработчика? Да нам проще всё закидать железом, чем оптимизировать код".
Ну вот собственно и приходят такие devops, которые клик-клик амазон гугл клауд и оно в продакшне, а если что-то вдруг сломалось или пошло не так, то хз, давай в супорт звонить кто знает индусский
Ну вот собственно и приходят такие devops, которые клик-клик амазон гугл клауд и оно в продакшне, а если что-то вдруг сломалось или пошло не так, то хз, давай в супорт звонить кто знает индусскийу меня часто ситуация наоборот, возможно из-за того, что сам работаю DevOps инженером. Приходишь к девелоперу и говоришь, я конечно утрирую, но суть примерно такова — не надо делать «SELECT * from TABLE WHERE FIELD1 'LIKE %abc%' », на что часто получаю ответ вида — мое время дорого стоит, я мега senior full stack архитектор, мне некогда заниматься оптимизацией, добавь 100500 ГБ памяти, у нас же облако — там же две кнопки кликнуть. И таких примеров очень много
Поправьте меня, если я ошибаюсь, но разве в DevOps уже не содержится Developer? Зачем куда-то ходить и кому-то говорить?
Если Вы добавляете памяти в базу, а разработчик дергает в ней
SELECT 1 FROM users WHERE name = 'admin' AND password = ''; DROP TABLE users; --' LIMIT 1, то почему это зовется DevOps?
Поправьте меня, если я ошибаюсь, но разве в DevOps уже не содержится Developer? Зачем куда-то ходить и кому-то говорить?
Потому что, править код (а ведь речь идет о проде) — это не задача devops. Почитайте что такое методология devops и что подразумевается под devops инженером.
Для справки
DevOps – это набор практик для повышения эффективности процессов разработки (Development) и эксплуатации (Operations) программного обеспечения (ПО) за счет их непрерывной интеграции и активного взаимодействия профильных специалистов с помощью инструментов автоматизации
Так что devops engineer != developer
P.S.
мой пример был сильно утрирован и упрощен, для передачи общей картины. Не надо его воспринимать буквально ;)
Я вот работаю вроде как DevOps, но по факту большую часть времени приходится разбираться с разными системами, установкой софта и т. Д. В чём отличие от Линукс сисадмина не знаю.
Недавно проходил собеседование на девопса, но блин, я даже забыл чем отличается CI от CD. Ну как-бы оно на столько отличается от реальной работы… и как-бы сертификат от AWS есть… просто впадло рассказывать то, что нафиг не надо на работе. Но в общем я не обижен… Ибо перебить зарплату не смогли. Так что что им нужно не понятно.
Хз к чему я. Devops это скорее слово которое сейчас обозначает нормально сисадмина. Ну то есть сейчас сисадмин=эникейщик. А devops=сисадмин. А облака, пайплайны, cicd мелочи которые учатся в процессе использования.
Потому, что, как минимум половина ваших страданий — это заслуга работадателя, который сам не знает, чего хотит. Но точно знает, что денег ему жалко. Вот кандидаты и подстариваются, кто более самоуверенный.
И все остальное ставиться так же и настраивается таким же образом.
Оно (слово devops) в моем окружении уже года три как ругательное.
Если есть возможность, то я ищу просто нормального админа.
С ним хотя бы работать можно.
Потому что нам нужен человек, чтобы "заниматься devops'ом". У нас вся инфраструктура целиком и полностью в git'е, обычный рабочий процесс с review и тестами всех уровней. Но, опыт предыдущих собеседований показал, что если запостить вакансию "сисамдина", то придётся выслушивать тысячи историй о том, как человек протирал бэкапы и что он умеет заводить учётные записи.
Когда мы собеседуем мы обсуждаем и высокие материи (например, как обеспечить воспроизводимость билда при наличии внешних зависимостей? Кто следит за актуальностью используемых артефактов и какими средствами?), но мы были вынужены сделать этот фильтр "101 администрирования", чтобы отсеять людей, которые консоль только в кино видели.
А вот насчёт того, надо ли devops'у хорошо знать как устроена маршрутизация или нет, давайте побеседуем.
Допустим, у вас приложение с высокой доступностью. Вы хотите, чтобы а) оно было высоко доступно б) обслуживало пользователя из ближайшего к нему дата-центра.
Является ли такая задача достойной devops'а или нет? А если достойна, то вот вам, и эникаст и маршрутизация.
Дальше. Если у вас в кубе сеточка себя плохо чувствует (потому что… определите почему), то надо вам знать как там в оверлейных сетях arp'ы бегают или нет?
Должен ли devops понимать, что такое переменные среды окружения, и почему программа на Go их не может поменять для родительского процесса иначе, чем через вызов наподобие eval?
Мы предлагаем весьма хорошую зарплату. (понятно, что тут же прибегут аналитики, которые уверены, что платить надо минимум в 5 раз больше).
На рынке труда никто никому ничего не должен, но есть спрос и есть предложение. У нас есть спрос на человека, который одновременно знает как работает маршрутизация ip, знает как менять права на файлах в posix, умеет выходить из vim'а (и мы за это даже не доплачиваем), знает как устроены зависимости юнитов в systemd, который умеет писать на питоне (на админском уровне) и хорошо знает Ансибл. Этот человек будет писать те самые "пайплайны" и разворачивать стейджинги с всеми видами тестирования. Но глубокого знания ни jenkins, ни gitlabci, ни github actions не требуется — эту ерунду любой (подходящий под наши критерии) человек выучит за несколько дней во время онбординга.
Кофе-машиной тоже пользоваться надо уметь, если кандидат ожидает халявный (и вкусный) кофе во время работы.
Надо. Просто мы не считаем это крупным навыком. vim'у выучиться и то сложнее.
UDP: А как можно настраивать CI/CD pipeline не зная что там внутри? Ну вот есть приложение. Оно подключается по ip и порту в базе данных. Что такое порт? Что такое IP? Откуда они берутся? Почему номер порта не может быть больше 70000? почему цифры в ip не могут быть больше 300? Почему их 4 но иногда дофига и через двоеточия? Что значит "абсолютный путь" и какой такой симлинк у nginx'а в sites-enabled?
Вы же понимаете, что "знание ci/cd pipelines" это как "знание ооп" у программистов, в отрыве от реальных навыков никакого смысла не имеет?
Ой, как интересно. Вот вы учите "девов" "деплоить на стейдж". А "стейдж" кто поднимает? Робот, вероятнее всего. Этому роботу, вероятнее всего, кто-то написал как поднимать стейджинг. Кто? Программисты? Т.е. у нас программисты сидят и решают проблему "как же правильно сделать создание кастомной chain в iptables", да?
У меня ощущение, что вы хотите рассказать, что "специалисты по devops'у", это как "коучи по agile'у" — рассказывают программистам и их начальникам как должны работать программисты.
Нет, devops'ы — это те, кто закатывает рукава и залазит по пояс в башепитон, пытаясь понять, почему gradle игнорирует настройки локали, переданные через userdata в cloud-init.
У вас интересные впечатления. Это не то, что я говорил, но, разве это важно?
Нас интересует человек для решения конкретных технических задач в рамках реализации девопс-практик.
Мы не переплачиваем за "девопса", потому что примерно треть нашего кода — это тесты, а сам код примерно на 2/3 существует только ради reproducibility, идемпотентности и прочих ценных факторов.
В нашем отделе на сервера "руками" заходят только если там что-то невероятно интересное образовалось. Но это не отменяет того, что нам нужны люди, которые всё это знают начиная с вопроса об автономном хранении артефактов и заканчивая вопросом "почему systemd не хочет делать reload для PartsOf сервисов в 14.04 и как нам с этим жить".
Забавно, но я обычно говорю наоборот. "Если у вас есть "devops-инженеры", то у вас нет devops"
Если у вас нет девопс практики в компании, то вам нужны простые сисадмины, а не девопс инженеры.
А наладить быструю передачу когда между девами и тестировщиками, научить девов наконец-то писать и использовать юнит тесты, деплоить на стейдж и отбить охоту лезть на сервер и менять там что-то руками и т.д. и т.п. — все это требует хорошего понимания процессов разработки, обезьяну вы этому уже не научите.
А это не задача девопс инженера. Это задача девопс практики, и отбивать охоту лезть на сервер и менять там что-либо должен либо програм менеджер, либо систем архитект, либо в первую очередь секьюрити аудит, который шлет алерты на менеджера и угрожает лишить его премии.
А девопс инженер может просто это заметить заранее и предложить менеджеру обязать разработчиков этого не делать.
Но организовать работу не имея полномочий менеджера — он не сможет.
В ваших вопросов не вижу ничего сложного, хоть в теме меньше полугода.
Ладно макс порт 65535 помнить на изусть не обязательно, но хоть что это 65,5к можно помнить, а вот ip4 2^8 — 1 (подсчет с нуля — подсесть) = 255 думаю знать должен каждый эникей, увы правда ловлю многих что rfc1918 — не знают Т_Т, как и apipa. А вот как выглядит IPv6 знают многие, а как с ним работать и в чем его особенности — пока знают только единицы и то лично таких еще не собеседовал.
3 года работаю с jenkins, до сих пор нахожу много чего нового. Не знаю как можно его за два дня изучить во время онбординга да ещё и groovy в придачу. За годы работы в shared lib много скопилось groovy кода, куча трюков и хаков. Уверен, человек за два дня вряд-ли там что-то поймёт в этом коде.
Вы абсолютно правы, что изучать jenkins можно долго. У нас обычно достаточно компактные скрипты самого jenkins'а, а вся реальная работа уровнем выше (поскольку мы её переиспользуем между продакшеном и jenkins'ом).
Да, если jenkins является не "вспомогательной утилитой" то 3х-дневным онбордингом не обойтись.
В нашем случае (хостинг) у нас многоуровневая оркестрация (условно говоря — кто вам leaf-коммутаторы настраивает при заказе доп. IP адреса?), и код нашего отдела — это жирный кусок оного, но не всё целиком. Ci/CD его проверяет в имитации полного стека с упором на важные нам элементы, так что от jenkins'а мы в основном ожидаем "покорми обезъяну и ничего не трогай" (т.е. запусти/сообщи результаты и не мешай работать куску кода в середине).
А какая з/п была указана в вакансии?
Я просто очень сомневаюсь, что спецы, которые писали пайплайны и деплой в других компаниях, затрудняются ответить на вопросы как эти самые пайплайны у них были устроены. Либо такой человек обманывает, либо он просто был рядом и видел как это делал его старший коллега.
Кто в вашем понимании devops-то? А то я только критику слышу, а конструктива нет
Гипотеза: в его представлении devops — это "специалист по внедрению devops'а", специальный вид agile-couch'а/евангелиста, который пытается осваивать смежные рынки. Надо рассказывать какие должны быть пайплайны, что надо писать интеграционные тесты и обещать при этом невероятный velocity и повышение всех kpi.
Всякие aglie-guru, превращающиеся в devops-guru.
Допустим, у вас приложение с высокой доступностью. Вы хотите, чтобы а) оно было высоко доступно б) обслуживало пользователя из ближайшего к нему дата-центра.
Является ли такая задача достойной devops'а или нет?
Для начала тут нужен Systems Architect, который бы разработал, соответственно, архитектуру.
В процессе реализации продукта DevOPS нужен для «автоматизации процесса разработки, тестирования и передачи продукта клиенту».
Касательно «Если у вас в кубе сеточка себя плохо чувствует (потому что… определите почему), то надо вам знать как там в оверлейных сетях arp'ы бегают или нет?». Тут можно с разных сторон подойти и посмотреть. Если следовать определению на yodo.im то я бы сказал, что такая работа — не функция DevOPS, тут нужен системный администратор с глубокими знаниями «куба». Но, опять же, вряд ли тут можно говорить про окончательную истинность определений.
Спасибо. Закрываем компанию, поскольку должности у нас такой нет и не предвидется (в силу необъятности поставленных задач).
Вы предлагаете свою модель, в которой есть роль "system architect". Почему это обязательно так?
Ну, если перестать ругаться — системный архитектор, как выделенный человек, нужен для проектов, в которых исполнители (те, кто реализуют проект) не понимают что нужно сделать и почему.
У нас — хостинговая компания. Мы eats our own dog food в полном объёме, так что разработка архитектуры (а у нас весьма и весьма специальные случаи — редкто кто оперирует понятием "20G в потолок" в списке обыденного) специально выделенным человеком означает что:
а) Если это наёмный варяг, к нему нужно 100500 человек переводчиков технических требований, бизнес-аналитиков и прочей бюрократии
б) Если это свой человек, то почему ему нужно выделять эту деятельность на фоне остальной? Надо сделать — покумекал, поговорил с соседями, предложил варианты, подняли MVP, выбрали какой лучше.
(более того, если такого человека выделить в отдельную область, он тут же начнёт терять контакт с реальностью).
Я долго искал работу сисАдмином с норм зп. Потом написал что я девопс… и всё завертелось… за год поменял 2 работы… hr звонят и уговаривают… нет отбоя..
DevOps (как человек, а не как практика) — это очень опытный сисадмин с навыками программирования, тестирования, чтения чужого кода, опытом управления зависимостями и навыком работы с инфраструктурой в git'е (я не люблю идею IaC, но что-то очень близкое к этому).
Если вы думаете, что devops (человек) — это что-то другое, попробуйте описать какие навыки ему нужны.
Я получаю зарплату как ДевОпс.
Но я скорее Опс чем Дев. То есть я работаю Админом…
Да Работодатель хочет Чтобы Я обладал: "навыками программирования, тестирования, чтения чужого кода итд итп ",
Чтоб я работал за десятерых — Да и он готов платить тройной оклад НО работать надо за десятерых.
Если Опытный админ может "быстро все разрулить" и неважно как это называется: " тестирование, автоматизация, интеграция итд ci/cd "
Если получилось все по Феншуй (Девопс) значит вы (Мы) Феншуй Инженер.
Что такое Феншуй? Это когда все ( красиво — практично — гармонично). Один в один Девопс.
Исследование Зарплат Системных Администраторов
У системных администраторов принято писать все слова с большой буквы?
Я перестал иметь отношение к Windows в 2009 году. Но, всё-таки, попробую. Наверное, можно сделать групповую полиси, вроде бы, там были (поля? записи?), где можно произвольный код выполнить при логине Ещё я помню про login.bat или что-то подобное, но не помню, то ли он local, то ли с netlogin шары прилетает.
… ничерта уже по виндам не помню.
А… А что это такое? В смысле, gp — это же текст (хоть и структурированый).
… или нет? Что такое внутри group policy? Бинарь? Архив?
А вот смотрите, вы говорите, что это "текст"- а как там тогда ярлыки сохраняются mime?
Вот после ответа про "вставление ярлыков" я начинаю подозревать, что там внутри бинарная мешанина, и, может быть, даже подобие rpc/dcom.
Я ушел из средних windows админов в linux а потом в DevOps. Вот с Линукс развитие гладкое. А по Виндоус от эникейщика до нормального админа пропасть. И таких специалистов почти нет.
Наверное по тому, что по Линукс от установки софта набором комманд до установки с помощью bash скрипта один шаг. А под Винду, от установки мышкой до установки через GPO пропасть.
Не знаю что сложного может быть в редактировании GPO, это все то клики мышкой… Никто вам не мешает пойти и поучить powershell, winrm, посмотреть в сторону chocolatey, да сейчас даже ansible может с windows10&server2019 работать https://docs.ansible.com/ansible/latest/user_guide/windows_usage.html, а chef работал еще давно. Так что главное желание.
Учтивая, что она, скорее всего не входит не в какие best practice, то человек, даже очень квалифицированный который с ней не сталкивался, сходу не назовет ее решение.
Да и с best practice у microsoft не сказать что б идеально, наверно с windows server 2008, во всяком случае по более свежим релизам я не находил русскоязычной литературы( да и англоязычной ) которая описывала реальный путь от эникея до win админа, с описание того как делать надо и почему.
У меня приличный опыт win администрирования, но с ходу мне приходят в голову только несколько идей:
1. Логон скрипт.
2. Удаленное выполнение скрипта.
3. Если перемещаемые профили, положить ночью в него.( не факт что сработает )
4. Положить в default user профиль первым или вторым методом + включить в wds дистриб.
5. Положить на сетевую шару и предложить по необходимости все его забрать.
6. Руками через системную шару раскидать( что скорее всего будет самым быстрым до примерно 100 машин, если нет постоянной необходимости выполнять действия из пункта 2, поскольку нужно будет вспоминать как это сделать, отлаживать, писать скрипт и т.д. ).
Но я абсолютно уверен, есть способ значительно проще и лучше, наверно его тоже можно загуглить, но не на собеседовании.
Воу, даже вот не удивлен;) я встречал подобных «админов».
По наблюдениям-сейчас сложно с соискателями среднего скилла. Многие даже до эникея не дотягивают.
А Ваша задача решается множеством способов:
Ярлык через стандартные механизмы пользовательской настройки gpo
Ярлык через логон/логоф скрипт пользовательской настройки или настройки компьютера gpo
Ярлык ВСЕМ пользователям каждого/определённого АРМ через deefault profile
Да их масса, на самом деле;)
Плюсом бы еще поспрашивал уточнение о фильтрации для кого ( пользователи ) или для чего (какие именно АРМ) необходима политика.
Это к тому, что «Вы использует скрипты для новых пользователей?», а эти новые пользователи появляются по 2 в год в уже установившейся структуре групп. Мне не в падлу и руками их завести.
«Всем ли» это было бы мое первое уточнение, понимаете?
То есть слишком много неизвестных в задаче и я бы уточнил полное условие, т.к. способов и методов масса.
Все зависит, опять же, от масштабов структуры. Я сторонник того чтобы все делать через группы и скрипты по рассписанию для автоматизации рутины, эксэпшны оьрабатываются отдельно при их наличии.
Попробуй игру симулятор от 0 до DevOPS
выбрал linux и вижу
Это первый курс Linux. После которого ты научишься решать практические задачи и полноценно администрировать.
Минимум теории максимум практики
21:10
Ты будешь решать практические задачи, которые стоят перед компанией:
Развернуть сайт,
Телефонный сервер,
Почтовый сервер и т.д.
так вот, современые курсы по линуксу давно отказались от идеи обучать поднять веб-сервер, а больше учат с азов безопасности и как правильно читать логи, между прочим ориентиром выступают linux essentials
Может вам все-таки ориентироваться на LPI? По крайней мере так вы дадите людям шанс получить сертификаты по актуальным направлениям и не превратите курсы в лишнюю преграду для самостоятельного переобучения, а подавать материал в легкой и воспринимаемой форме, это больше из области искусства и личных талантов преподавателей.
Вот для примера:
курсы в специалисте
курсы в МЭИ
Линукс, как веб-сервер уже давно не воспринимается.
Но по СПБ буквально только, что закончи искать даже не windows админа, а эникея.
Вводные 55.000 на руки, минимальный опыт.
За две недели 250 откликов на вакансию( половина в первые четрые дня ).
Половина сразу мимо, это люди без самого минимального опыта( в прямом смысле, вчера грузчик или из армии, сегодня админ, из знаний, поставил соседке windows ).
Из 250 отобрал примерно 50 резюме.
Провел примерно 25 собеседований.
Из 25, 6 человек, смогли ответить более менее на вопрос о том, что такое маска подсети и зачем она нужна( без всякой науки про биты, своим словами ).
Из 6 человек, только два сказали что по двум ip адресам нельзя определить в одной они подсети или в разных( 192.168.88.16 и 192.168.89.19. ) и нужна еще маска, остальные 4 уверенно сказали, что в разных подсетях.
Только один человек знал, что-то про таблицы маршрутизации( именно, что-то, т.е. самые азы, прямо даже не азы, а хотя бы что оно такое бывает ), NAT и зависит ли скорость передачи данных от задержки в канале.
Из 25, только 5 ответили, что такое nslookup, еще двое знали, что такое sfc и mmc.
Один знал, вернее предположил, от куда взялся на интерфейсе адрес 169.254.1.36 и что это значит, почему при нем не работает интернет.
Про типы групп в домене( безопасности и распространения, локальные, глобальные, универсальные ) не знал никто, про работу DNS, что такое DNS forwarding аналогично.
Вообще за 55.000 знания у людей по большей части нулевые совсем.
Наверно если очень долго искать, можно среди них найти и нормальных начинающих специалистов. Но по моим представлениям они в этой категории задерживаются максиму на год или два, дальше уходят за 70.000 и выше.
Есть правда исключение, возрастные администраторы, там немного лучше и за эти деньги можно найти более менее windows администратора( но тоже совсем не спеца ).
Но тут две проблемы, первая их как эникеев уже не по использовать, под потолок лазать и под столами, бегать к пользователям.
Второе у них с обучаемостью уже совсем плохо, да и со здоровьем есть проблемы.
А у тех у которых и обучаемость сохранилась и знания есть, за 55.000 работать не пойдут.
Сам оцениваю рынок в СБП примерно так:
до — 35.000
не специалист, вход в профессию с низкими личностными характеристиками.
самостоятельная деятельность невозможна, максимум, что можно доверить протянуть кабель или заменить картридж.
до — 55.000
начинающий специалист или вход в профессию с высокими личностными характеристиками.
вероятно после минимального обучения может оказывать пользовательскую поддержку, настройку и администрирование рабочих мест, протянуть кабель, заменить картридж,
провести переучет оборудования, частичная диагностика сетевых проблем если личностные характеристика позволяют, то обучаем, но тогда достаточно быстро растет по ЗП.
до 90.000
достаточно квалифицированный специалист или старший сотрудник технической поддержки пользователей.
Чаше всего эти сотрудники уже не обслуживают конечных пользователей( или делают это только в сильно сложных ситуациях ), а занимаются поддержкой инфраструктуры( сервера, сети, телефония ). Здесь уже формируется специализация, т.е. специалист не может одновременно эффективно заниматься всем.
Может самостоятельно внедрять некоторый сервисы в рамках свой специализации, но слабо «видит» связность различных сервисов.
При общей настройке требует контроля со стороны более квалифицированного сотрудника в области зависимостей между различными частями системы.
до 140.000
высококлассный узкий специалист. очень хорошо разбирается, но в рамках свой специализации, работает с ПО или железом энтерпрайз уровня.
Способен решать сложные проблемы в рамках свой специализации. Частично видит связность сервисов.
до 200.000
Архитектор системы. Обладает менее узкой специализацией нежели на предыдущем уровне, но очень хорошо видит связность сервисов и обладает широкой специализацией. Или супер квалифицированный штучный специалист по какой-то технологии.
… по двум ip адресам нельзя определить в одной они подсети или в разных( 192.168.88.16 и 192.168.89.19. ) и нужна еще маска, остальные 4 уверенно сказали, что в разных подсетях.
Спасибо, утащил в коллекцию вопросов.
Такой вопрос у меня есть, но это на самом деле прелюдия к "поговорить о маршрутах". В общем случае надо начинать очень медленно и пристально читать man ip route.
У route'а есть type, rtproto, scope (в том числе numeric!), metric, preference… Где-то там луркает авто mpls. И это мы ip rule даже не упоминали.
Короче, для начала разговора хороший вопрос, но это именно поговорить, потому что целиком ответить на общий вопрос про маршрутзацию (со всеми нюнсами, включая "уважать link down для device или нет) может только эксперимент.
У нас в городе толковый сисадмин получает максимум 40к. При этом, зачастую, выполняют работу эникея, а порой и программиста (Чаще — веб).
Что, собственно, вынудило меня искать работу на удаленке.
На самом деле там конечно не только этот вопрос, там несколько вопросов, для того, чтобы понять имеет ли смысл кандидату давать задачу на маршрутизацию.
Поскольку если кандидат не понимает основы, записи вида
ip 10.17.44.55/27
default_gw 10.17.44.38
его полностью ставят в тупик.
Но благодаря вам добавил к себе в копилку еще один вопрос, что будет если не выдать клиенту маску. Действительно, подобная задача может иметь смысл в разрезе VPN или в разрезе сетевого траблшутинга.
Но думаю это уже не на эникейску должность, а скорее на сетевого админа.
# ifconfig lo:1 192.168.10.1
# ifconfig lo:1
lo:1: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 192.168.10.1 netmask 255.255.255.0
loop txqueuelen 1000 (Локальная петля (Loopback))
Ubuntu 20.04.1 LTS — достаточно свежая?
Справедливости ради, у «iproute2» маска по умолчанию /32.
Windows 10 (2004) также подставляет маску исходя из класса сети.
noname@MacBook-Air-Evgeny ~ % sudo ifconfig en0 172.16.20.4
noname@MacBook-Air-Evgeny ~ % ifconfig en0
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=400<CHANNEL_IO>
ether 3c:22:fb:ea:a2:55
inet 172.16.20.4 netmask 0xffff0000 broadcast 172.16.255.255
nd6 options=201<PERFORMNUD,DAD>
media: autoselect
status: active
Я могу нарезать хоть тысячи сеток с 10.x.x.x и масками, это тут ни при чем. Типы сетей определены в каком-то из RFC.
Вы указали, что «дефолтные» значения масок подсети определяются согласно классам сетей, я указал вам, что это на практике не всегда так, для 10.x.x.x классовая маска /8, но у меня имеется оборудование которое вешает на интерфейс 16 маску если не получает маску от DHCP сервера.
Вот выдержка из вполне официальной доки от актуального соляркиного ipadm, который работает именно так, как вы отрицаете: prefixlen — Specifies the length of the network ID that is part of the IPv4 address when you use CIDR notation. In the address 12.34.56.78/24, 24 is the prefixlen. If you do not include prefixlen, then the netmask is computed according to the sequence listed for netmask in the name-service/switch service or by using classful address semantics.
Что до конкретных реализаций — самолично работал с железкой, которая отказывалась принимать адрес /32 на интерфейсе PPP, её устроило только /30.
поскольку требуют дальнейшего диалога. Формально минимальная маска 32, но насколько ее реально использовать, когда и на каком оборудовании. Да, это позволит раскрыть диалог и посмотреть с чем человек реально сталкивался. Но на эникея это очень большой перебор. Если он знает про формат записи /x, может написать марштуры в простой сети из трех роутеров, это уже очень хорошо для данной позиции.
Лично для меня ценно не когда кандидат знает ответ на вопрос, а когда его база позволяет с небольшой помощью до ответа дойти( понятно, что это не касается вопросов указанных выше ). Тогда возникает диалог, можно посмотреть как человек думает, как он ищет решение, видно как на человека влияет стресс, будет ли он погружаться в задачу и стресс от собеседования снизится или у него начнется «паника» и стресс только усилится( а как иначе он будет работать, если у него на собеседовании стресс паралич, что у него будет когда у него что-то серьезное упадет и пользователи будут дергать ).
Но это по младшим позициям.
На старшие позиции есть вообще замечательные прием, перевернуть собеседование и предложить кандидату самому вас прособеседовать или провести самопрезентацию.
Ну и мы даем полный объем знаний чтобы попасть на начальную позицию. Дальше уже компания «заточит» под себя, когда будет давать задачи и нужно будет читать документацию и разбираться с тем стеком технологий, который используется.
Сначала вы что-то пробуете и у вас получается. Вам это нравится и вы берете задачи посложнее параллельно читая теорию, чтобы понять как это работает и решить задачу. Это наш метод.
Про типы групп в домене( безопасности и распространения, локальные, глобальные, универсальные ) не знал никто
Здесь я могу даже пояснить причину. Пока человек не работал с лесом (был только один домен) — его не беспокоила классификация групп совершенно. Равно как и группы распространения он, скорее всего, создавал через оснастку exchange (если у них он вообще был). Причём создавал, скорее всего, один раз (если домен создавал в компании он) или вообще ни разу, если создали до него. В большой распределенной компании таким он занимался бы чаще, но и денег уже хотел бы больше.
Но если конечно делать согласно рекомендациям microsoft (согласно курсам), то минимально в конторе должно быть минимум 3 леса с правильно настроенными трастами (лес для пользователей, лес для ресурсов, лес для админских учеток). Еще у вас может быть лес для shielded vm. Может еще какой забыл.
Я просто напишу тут 3 буквы:
SRE
Это набор рекомендация фиксировать свои действия в повторяемом коде.
НЕЛЬЗЯ ИЗ ЧЕЛОВЕКА СДЕЛАТЬ НОРМАЛЬНОГО ДЕВОПСА ЕСЛИ ОН НЕ ПОНИМАЕТ ЧТО У НЕГО В ХОЗЯЙСТВЕ ТВОРИТЬСЯ.
Вот есть масса проектов в которых приходят заказчики и говорят нам нужен крутой CI/CD но
Берешь и делаешь ( кушать хочеться однако)
Есть заказчики которые не позволят выход в интернет ряду серверов ( а манагеры модные классные -кучу слов знают)
берешь и делаешь ( особенно люблю когда проекы в закрытых контурах на питоне и node.js вообще красота )
Не говоря о том что задачи на тест вообще тестировщики выводят по нажатию волшебной кнопки.
Бывают заказчики у котрых закупка оборудования 1 раз в год и ты тут тресни но обеспечь полный цикл ( ах да нам бы еще еластик прикрутить… ЭЭЭЭЭ а че так много? ну это давайте другими методами логи обрабатывать.)
Так что заказчик разные ( деньги у него) — команды разные ( но все хотят MagicButton)
и ненавижу yml
bash такой теплый уютный
Вот мне совершенно непонятно вся эта возня вокруг девупсов/админов/сре.
Это три совершенно разных слова! Сисадмин делает инфраструктуру. Девопс ничего не делает! Девопс это список! Список мать их рекомендаций! SRE это конкретный человек ( не зря там Е — енженегр).
В начале года активно хантил в команду админа, а ещё дежурного искал (удаленка, другой часовой пояс и все такое). Так вот заметил что все хотят в девУпсы. А ведь это диктуется рынком — девУпсы больше получают, а знать так особо и не надо — сиди и пиши свои ямлики. А когда человеку (который деплоил абсолютно все на старой работе, даже эктив директори деплоил) как понять почему при виртуалка не разрешает простому пользователю что-либо записать на диск (подразумеваться поиск проблем и плавный подвод к вопросу про inodes) человек отвечает что никогда с таким не сталкивался и вы спрашиваете какие-то слишком сложные вещи.
Другой (с 10-летним стажем на одном месте из которых последние 7 это руководитель отдела на 5-10 человек) на вопрос про резервное копирование (как устроено, нахрена оно вам вообще, ротация, шедулинг) сказал дословно: «А оно там было до меня сделано, а я особо не вникал как и что там».
А ведь оба данных персонажа хотят стать девУпсами! Чтоб 100500ккк наносек получать.
А основной косяк такой картины именно на стороне компаний, которые пишут «девупс», а нужен им даже не сисадмин, а эникейщик, который будет делать все и за доширак.
Сисадмины тоже разделились
* эникейщики — достаточно для небольших контор либо техсаппорт (базовая настройка и установка, сборка и обслуживание оргтехники, юзер саппорт)
* сисадмины для крупных контор — Архитектура инфраструктуры, безопасность, все эти AD и профилирование, автоматизация
* сетевики — протоколы, маршрутизаторы, всякие BGP, роуты, циски, оптика, радио, оборудование.
* девопсы — инфраструктура, автоматизация и поддержка инфраструктуры и инструментов для нее, и важный момент — настройка деливери.
Все вышеупомянутые направления требуют своей проф.ориентации и в каждой из них можно достичь определенного уровня ЗП. Феномен девопсов заключается в основном в том, что девопсы нужны в крупных проектах и аутсорсе, а там обычно ЗП выше. С другой стороны джуниор девопс — несуществующее понятие.
В одних и тех же компаниях зарплата ведущих девопсос в полтора раза выше ведущих админов.
Правда в безоблачной России это может быть доплатой за вредность, так как им приходится сопровождать инфраструктуру для инфраструктуры, а не только заниматься прикладным слоем в готовом облаке.
Компаний, которые четко понимаю кто и за каким им нужен, категорически мало. Несколько раз и мне прилетали предложения о работе на позиции DevOps, DevOps-инженер, Expert DevOps, НО! Довольно часто в описании вакансии на позицию человека который должен решить/решать проблему бизнеса указано: настройка резервного копирования для ms exchange, опыт 1С обязателен.
После таких предложений начинаешь задумываться: а тем ли я в своей жизни занимаюсь? Может пойти в каменщики (я умею/я могу)? Или в автомеханики?
В одних и тех же компаниях зарплата ведущих девопсос в полтора раза выше ведущих админов.
Потому что админ работает на компанию, является расходной статьей по обслуживанию локальной инфраструктуры.
А девопс работает на проект, приносит прибыль как и разработчики.
Если мы говорим про аутсорс, то админы вообще работают на локальную компанию, а девопсы на конкретного (зарубежного) заказчика, подписывают NDA.
С другой стороны: как оно в «забугорье» я не скажу, да и за всех сразу тоже не отвечу, а вот по моему опыту — админ (как и ИТ-отдел в целом) в средней отечественной компании, для которой разработка (продукта/сервиса/приложеньки) не является основной статьей дохода, это всего лишь «мальчик», который должен сделать так чтоб и кофе-машина на кухне работала, и почта у генерального на айпэде работала, и 1С'ка работала без тормозов, а в случае чего вся инфраструктура исчезла с радаров по команде.
Могу так заявлять, т.к. сам был таким «мальчиком» каких-то 5-6 лет назад. Спасло от неба в клеточку, только врожденное желание выживать.
DevOps работает на проект и решает конкретную задачу бизнеса, а админ работает на инфраструктуру, только забывается одно — такой подход и расклад дел жизнеспособен только если речь идет об облаках. А за облаками стоят такие же админы, которые на железо накатывают ОСи, утилиты, софт, etc. И только по верх этого появляется облако.
Если кто-то считает, что я не прав — я готов к дискуссии :|
Часто прогеры делают код, который падает сам по себе, но виноваты естественно не они. Очень удобно все это межгрупповое взаимодействие слить на девопс инженера и сделать его крайним.
Исследование зарплат системных администраторов