Как стать автором
Обновить

Комментарии 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, это такой, образно выражаясь, middleware, между миром разработки и миром эксплуатации и тестирования.

Я вот работаю вроде как DevOps, но по факту большую часть времени приходится разбираться с разными системами, установкой софта и т. Д. В чём отличие от Линукс сисадмина не знаю.


Недавно проходил собеседование на девопса, но блин, я даже забыл чем отличается CI от CD. Ну как-бы оно на столько отличается от реальной работы… и как-бы сертификат от AWS есть… просто впадло рассказывать то, что нафиг не надо на работе. Но в общем я не обижен… Ибо перебить зарплату не смогли. Так что что им нужно не понятно.


Хз к чему я. Devops это скорее слово которое сейчас обозначает нормально сисадмина. Ну то есть сейчас сисадмин=эникейщик. А devops=сисадмин. А облака, пайплайны, cicd мелочи которые учатся в процессе использования.

НЛО прилетело и опубликовало эту надпись здесь
Недавно чел со старой работы рассказывал, что к ним на вакансию DevOps'а пришол чел, который не знает что такое sed/awk/grep…
А какой у него бэкграунд, интересно? Девелоперский? Админский?

Не знает = вообще не слышал про них или не смог составить пайп без SO?

Давайте сделаем вместе тест, через который будем прогонять кандидатов. Вы сможете сразу сеять стажеров, я буду использовать его для курса. Как вам идея?
НЛО прилетело и опубликовало эту надпись здесь
Угу, а ещё сделайте тест, который будет отсеивать работадателей с ваканиями девопсов за 35к. Когда человек приходит на вакансию — поставить сервер, на нём lamp, написать десяток правил в файрвол, завести пользователей и при этом завётся девопсом, то через год или три он захочет корьерного роста и зарплаты. И будет искать вакансию… кого? Может быть эникея?
Потому, что, как минимум половина ваших страданий — это заслуга работадателя, который сам не знает, чего хотит. Но точно знает, что денег ему жалко. Вот кандидаты и подстариваются, кто более самоуверенный.
Если девопс имеет только дев бэкграунд, это плохо, но поправимо. Если девопс имеет только админский бэкграунд, это уже гораздо лучше. «Поправлять» гораздо меньше. Ну а уж если имеется и админский и девелоперский(или бэк тестировщика, что в каком-то смысле ещё лучше), то вообще идеально… Но бывают девопсы вообще без всего вышеперечисленного… и вот это реальная *опа!
Это порождение культа тяп ляп и в продакшен. А потом спрашиваешь у человека, какие меры безопасности вы предпринимаете для изоляции контейнеров( приложении в контейнерах ) и оказывается, а зачем, «sudo apt-get install docker» и дальше doker run.
И все остальное ставиться так же и настраивается таким же образом.

Оно (слово 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"


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


А это не задача девопс инженера. Это задача девопс практики, и отбивать охоту лезть на сервер и менять там что-либо должен либо програм менеджер, либо систем архитект, либо в первую очередь секьюрити аудит, который шлет алерты на менеджера и угрожает лишить его премии.
А девопс инженер может просто это заметить заранее и предложить менеджеру обязать разработчиков этого не делать.
Но организовать работу не имея полномочий менеджера — он не сможет.
Интересные читать комментарии. Как человек, который проходит курсы по DevOps. Linux, безопасность и сети там есть. Это основы.
В ваших вопросов не вижу ничего сложного, хоть в теме меньше полугода.
Какие курсы если не секрет проходите?

Ладно макс порт 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, тут нужен системный администратор с глубокими знаниями «куба». Но, опять же, вряд ли тут можно говорить про окончательную истинность определений.

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

Можно ведь говорить про роли. Понятно, что один человек может выполнять несколько ролей, но вот конкретно сочетать Systems Architect и DevOPS я бы не хотел. Systems Architect и какой-нибудь Senior Developer — норм.

Вы предлагаете свою модель, в которой есть роль "system architect". Почему это обязательно так?

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

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


У нас — хостинговая компания. Мы eats our own dog food в полном объёме, так что разработка архитектуры (а у нас весьма и весьма специальные случаи — редкто кто оперирует понятием "20G в потолок" в списке обыденного) специально выделенным человеком означает что:
а) Если это наёмный варяг, к нему нужно 100500 человек переводчиков технических требований, бизнес-аналитиков и прочей бюрократии
б) Если это свой человек, то почему ему нужно выделять эту деятельность на фоне остальной? Надо сделать — покумекал, поговорил с соседями, предложил варианты, подняли MVP, выбрали какой лучше.


(более того, если такого человека выделить в отдельную область, он тут же начнёт терять контакт с реальностью).

Я долго искал работу сисАдмином с норм зп. Потом написал что я девопс… и всё завертелось… за год поменял 2 работы… hr звонят и уговаривают… нет отбоя..

НЛО прилетело и опубликовало эту надпись здесь

DevOps (как человек, а не как практика) — это очень опытный сисадмин с навыками программирования, тестирования, чтения чужого кода, опытом управления зависимостями и навыком работы с инфраструктурой в git'е (я не люблю идею IaC, но что-то очень близкое к этому).


Если вы думаете, что devops (человек) — это что-то другое, попробуйте описать какие навыки ему нужны.

Я получаю зарплату как ДевОпс.
Но я скорее Опс чем Дев. То есть я работаю Админом…
Да Работодатель хочет Чтобы Я обладал: "навыками программирования, тестирования, чтения чужого кода итд итп ",
Чтоб я работал за десятерых — Да и он готов платить тройной оклад НО работать надо за десятерых.
Если Опытный админ может "быстро все разрулить" и неважно как это называется: " тестирование, автоматизация, интеграция итд ci/cd "
Если получилось все по Феншуй (Девопс) значит вы (Мы) Феншуй Инженер.


Что такое Феншуй? Это когда все ( красиво — практично — гармонично). Один в один Девопс.

Исследование Зарплат Системных Администраторов

У системных администраторов принято писать все слова с большой буквы?

Нет, только у Исследователей Зарплат Системных Администраторов. CamlCase, всё такое.

Оу, да ладно? Реально такое встречается?
Политикой это можно сделать двумя способами, не говоря уже об экзотический с планировщиком;)

Искали администратора Windows с опытом работы с Active Directory. Приглашали на собеседование соискателей, в резюме которых был упомянут AD. Никто из них не справился с простой задачей: добавить всем пользователям домена ярлык на калькулятор на рабочем столе. Очень странное нынче время.
Расскажу страшную тайну — не все люди, которые разворачивали домен, знают про gpo. Парадокс, но для офиса из 10-40 человек не все заморачиваются. А для тех кого можно переманить из контор за 100+ человек уже нужна хорошая зарплата.

Я перестал иметь отношение к Windows в 2009 году. Но, всё-таки, попробую. Наверное, можно сделать групповую полиси, вроде бы, там были (поля? записи?), где можно произвольный код выполнить при логине Ещё я помню про login.bat или что-то подобное, но не помню, то ли он local, то ли с netlogin шары прилетает.


… ничерта уже по виндам не помню.

НЛО прилетело и опубликовало эту надпись здесь

А… А что это такое? В смысле, gp — это же текст (хоть и структурированый).


… или нет? Что такое внутри group policy? Бинарь? Архив?

НЛО прилетело и опубликовало эту надпись здесь

А вот смотрите, вы говорите, что это "текст"- а как там тогда ярлыки сохраняются mime?


Вот после ответа про "вставление ярлыков" я начинаю подозревать, что там внутри бинарная мешанина, и, может быть, даже подобие rpc/dcom.

Штатная шутка фидошной эхи RU.OS.CMP, занесённая в анналы FAQ:
Реестр — единая точка отказа всей системы, имеющая бинарный формат.

GP — не реестр (вроде бы).

Давно было, я даже свою любимую книжку Станека куда-то подевал, но, по моему оно всё-же как-то через реестр работало. ;-) Так что у нас у обоих походу склероз вызванный передозом *nix систем.

Там внутри несколько секций, каждая из которых в своём формате: есть и бинарные файлы, и ini, и XML

Я ушел из средних windows админов в linux а потом в DevOps. Вот с Линукс развитие гладкое. А по Виндоус от эникейщика до нормального админа пропасть. И таких специалистов почти нет.


Наверное по тому, что по Линукс от установки софта набором комманд до установки с помощью bash скрипта один шаг. А под Винду, от установки мышкой до установки через GPO пропасть.

Не знаю что сложного может быть в редактировании GPO, это все то клики мышкой… Никто вам не мешает пойти и поучить powershell, winrm, посмотреть в сторону chocolatey, да сейчас даже ansible может с windows10&server2019 работать https://docs.ansible.com/ansible/latest/user_guide/windows_usage.html, а chef работал еще давно. Так что главное желание.

Мало того, ещё со времён аж 2000-го сервера в винде большой набор cli инструментов, для работы с AD вообще и GPO в частности.

С CLI для GPO там к сожалению плохо как раз

Это задача решается множеством способов.
Учтивая, что она, скорее всего не входит не в какие best practice, то человек, даже очень квалифицированный который с ней не сталкивался, сходу не назовет ее решение.
Да и с best practice у microsoft не сказать что б идеально, наверно с windows server 2008, во всяком случае по более свежим релизам я не находил русскоязычной литературы( да и англоязычной ) которая описывала реальный путь от эникея до win админа, с описание того как делать надо и почему.

У меня приличный опыт win администрирования, но с ходу мне приходят в голову только несколько идей:
1. Логон скрипт.
2. Удаленное выполнение скрипта.
3. Если перемещаемые профили, положить ночью в него.( не факт что сработает )
4. Положить в default user профиль первым или вторым методом + включить в wds дистриб.
5. Положить на сетевую шару и предложить по необходимости все его забрать.
6. Руками через системную шару раскидать( что скорее всего будет самым быстрым до примерно 100 машин, если нет постоянной необходимости выполнять действия из пункта 2, поскольку нужно будет вспоминать как это сделать, отлаживать, писать скрипт и т.д. ).

Но я абсолютно уверен, есть способ значительно проще и лучше, наверно его тоже можно загуглить, но не на собеседовании.
НЛО прилетело и опубликовало эту надпись здесь
Хммм… Уж насколько я давно не сталкивался с виндой и то помню что это можно сделать через GPO. Ну или, в случае перемещаемых профилей, можно костыльнуть скрипт, который прям на сервере по профилям пробежится.

Воу, даже вот не удивлен;) я встречал подобных «админов».
По наблюдениям-сейчас сложно с соискателями среднего скилла. Многие даже до эникея не дотягивают.
А Ваша задача решается множеством способов:
Ярлык через стандартные механизмы пользовательской настройки gpo
Ярлык через логон/логоф скрипт пользовательской настройки или настройки компьютера gpo
Ярлык ВСЕМ пользователям каждого/определённого АРМ через deefault profile
Да их масса, на самом деле;)
Плюсом бы еще поспрашивал уточнение о фильтрации для кого ( пользователи ) или для чего (какие именно АРМ) необходима политика.

И «всем» — это скольким. А то может это 6 человек в 2х кабинетах, и без политик тут никак.
Это к тому, что «Вы использует скрипты для новых пользователей?», а эти новые пользователи появляются по 2 в год в уже установившейся структуре групп. Мне не в падлу и руками их завести.

«Всем ли» это было бы мое первое уточнение, понимаете?
То есть слишком много неизвестных в задаче и я бы уточнил полное условие, т.к. способов и методов масса.
Все зависит, опять же, от масштабов структуры. Я сторонник того чтобы все делать через группы и скрипты по рассписанию для автоматизации рутины, эксэпшны оьрабатываются отдельно при их наличии.

Зашел я по ссылке
Попробуй игру симулятор от 0 до DevOPS

выбрал linux и вижу
Это первый курс Linux. После которого ты научишься решать практические задачи и полноценно администрировать.
Минимум теории максимум практики
21:10
Ты будешь решать практические задачи, которые стоят перед компанией:
Развернуть сайт,
Телефонный сервер,
Почтовый сервер и т.д.

так вот, современые курсы по линуксу давно отказались от идеи обучать поднять веб-сервер, а больше учат с азов безопасности и как правильно читать логи, между прочим ориентиром выступают linux essentials
Я сделал этот блок таким, чтобы у человека, который боялся подойти к Linux, сразу что-то получилось. Поднять сайт. Этот успех мотивирует продолжать дальше и разбираться с безопасностью и логами. Я с вами в этом абсолютно согласен.
Эмммм… может я не сталкиваюсь с людьми, которым при знакомстве с линуксом первым делом надо сайт поднимать, но если честно, то чтение логов и раздача прав внутри операционки требуется чаще, чем поднять апач или нжинкс.
Может вам все-таки ориентироваться на 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к. При этом, зачастую, выполняют работу эникея, а порой и программиста (Чаще — веб).
Что, собственно, вынудило меня искать работу на удаленке.
вообще, следуя классам сетей, 192.168.88.16 и 192.168.89.19 без указания маски относятся к сети класса C. Следовательно, без указания маски, маска обеих адресов 255.255.255.0, соответсвенно эти два адреса из разных сетей.
Если бы кандидат подобным образом ответил на вопрос, меня бы это вполне устроило, хотя ваша формулировка не корректна, поскольку вы ввели в задачу доп.условие которого там нет и предположили, что маска дефолтая.
На самом деле там конечно не только этот вопрос, там несколько вопросов, для того, чтобы понять имеет ли смысл кандидату давать задачу на маршрутизацию.
Поскольку если кандидат не понимает основы, записи вида
ip 10.17.44.55/27
default_gw 10.17.44.38
его полностью ставят в тупик.

Но благодаря вам добавил к себе в копилку еще один вопрос, что будет если не выдать клиенту маску. Действительно, подобная задача может иметь смысл в разрезе VPN или в разрезе сетевого траблшутинга.
Но думаю это уже не на эникейску должность, а скорее на сетевого админа.
НЛО прилетело и опубликовало эту надпись здесь
Вы дополнили задачу условием которого в ней нет. Это условие, маска имеет дефолтное значение. Если маска подсети вам не известна по условиям задачи, это не значит, что она имеет дефолтное значение. Не говоря о том, что дефолтность данного значения может зависеть от реализации. Не так давно сталкивался с устройством у которого на подсеть 10.x.x.x была дефолтная маска 16.
НЛО прилетело и опубликовало эту надпись здесь
но у cird адресации нету никаких дефолтных значений, а классы подсетей ушли в прошлое. Попробуй назнач ip на своей винде/линуксе с «дефолтной» маской, нигде ее не прописывая.
# 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) также подставляет маску исходя из класса сети.
Ubuntu 20.04.1 LTS — достаточно свежая?

достаточно
ifconfig

гавно мамонта.
Как ты сам заметил iproute2 работает по-другому
Суть в том, что я поддерживаю мысль ТС о том, что человек должен знать что классовая адресация это пережитки прошлого и не должен думать что есть какое-то «умолчание» которое разводит 192.168.0.1 и 192.168.1.15 по разным подсетям.

P.S. было как-то собеседование в билайн. был вопрос
— Есть 2 интерфейса, соедененных кабелем, на одном адрес 1.1.1.1 на втором 7.3.2.1, какую минимальную маску надо выделить, чтоб соеденить эти адреса.
— Ну я такие большие маски в голове не считал, ну примерно /5.
— нет, /30, смотри, выделяем 192.168.1.1/30 на одном интерфейсе, 192.168.1.2/30 на другом, и настраиваем маршрутилазцию
— …

надо было рассказать про ip unnumbered, про то что маршрутилацию можно настроить и без выделение дополнительных адресов. но чет замешкался.
тоже самое в MacOS 10.15.6
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
ну так а то что ifconfig это старье, которое, по крайней мере в линуксе считается устаревшим, это ничего? Из-за того что некоторый старый софт(именно некоторый, который еще следует покапать) следует классовой адресации, мы будем считать что есть какие-то умолчания?
В ядро передается маска? я думаю да. Если я напишу скрипт который будет передавать параметр маски /2, для любого ip, будет ли это считаться каким-то «умолчанием» для сетевого протокола?
Я могу нарезать хоть тысячи сеток с 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, может написать марштуры в простой сети из трех роутеров, это уже очень хорошо для данной позиции.
НЛО прилетело и опубликовало эту надпись здесь
Такой вопрос у меня есть. Я его немного сузил, до одного коммутатора.
Что интересно, все уверенно ответили петля, но никто не смог объяснить, что же такое петля и чем это плохо, ну вернее симптомы многие назвали достаточно уверенно, но вот почему они возникают.
Давайте сделаем вместе тест, через который будем прогонять кандидатов. Вы сможете сразу сеять стажеров, я буду использовать его для курса. Как вам идея?
Это не имеет большого смысла. Не нужно натаскивать людей на ЕГЭ, нужно учить их думать и давать базис.
Лично для меня ценно не когда кандидат знает ответ на вопрос, а когда его база позволяет с небольшой помощью до ответа дойти( понятно, что это не касается вопросов указанных выше ). Тогда возникает диалог, можно посмотреть как человек думает, как он ищет решение, видно как на человека влияет стресс, будет ли он погружаться в задачу и стресс от собеседования снизится или у него начнется «паника» и стресс только усилится( а как иначе он будет работать, если у него на собеседовании стресс паралич, что у него будет когда у него что-то серьезное упадет и пользователи будут дергать ).
Но это по младшим позициям.
На старшие позиции есть вообще замечательные прием, перевернуть собеседование и предложить кандидату самому вас прособеседовать или провести самопрезентацию.
Моя задача сломать психологический барьер и дать возможность людям пойти на junior позиции, где их научат нужным технологиям. Крупные компании ориентированы на выращивание специалистов из тех кто умеет думать. Так вот задача тестов выделить тех кто умеет думать и отдать их корпорациям.
Странный подход, если честно. В более других местах, учат как теории, так и натаскивают на применение теоретических знаний на реальных, пусть и учебных, практических, кейсах. Что-бы придя на новое место человек уже не боялся сам принимать решения и реализовывать то что от него требуется. А учить «в корпорациях» не любят. Там любят уже, хотя-бы наполовину, готовый «продукт», а не «полуфабрикат». ;-) Кстати, сколько ваша программа занимает времени по часам? А соотношение теория / практика? Мало того, более другие конторы выкладывают / организуют туеву хучу вебинаров в свободный доступ, по которым приблизительно можно оценить качество обучения. Например у одной известной и очень раскрученной, конторы лично мне качество не понравилось (там есть ну просто адские косяки), зато у другой я реально стараюсь не пропускать вебинары ибо просто получаю удовольствие от просмотра и участия.
У нас только практические задания. Мы учим читать документацию и разбираться в непонятном. Теорию гуглишь сам, когда нужно выполнить задание. Подход «сначала практика, потом теория». Обычно учат теории, а потом дают практику. Никто не запоминает теорию, потому что мозг считает эту инфу лишней. Проще читать теорию, когда знаешь где это будешь использовать.

Ну и мы даем полный объем знаний чтобы попасть на начальную позицию. Дальше уже компания «заточит» под себя, когда будет давать задачи и нужно будет читать документацию и разбираться с тем стеком технологий, который используется.
Эммм… Ужас, если всё выглядит именно так как вы описываете. Человек изначально должен понимать что, для чего и почему он делает именно так, а не иначе. А без хорошей теоретической базы, наложенной на не менее хорошую практику он будет не способен исправить даже собственные косяки, не говоря уж о чём-то более сложном, чем условный «Hello World!». Это в условной средней школе теорию дают ради теории, а в IT теория существует исключительно для того что-бы применять её на практике.
Подскажите а вы сначала книжку по теории файловых систем и отом как устроено ядро Linux прочитали, а только потом за консоль взялись?

Сначала вы что-то пробуете и у вас получается. Вам это нравится и вы берете задачи посложнее параллельно читая теорию, чтобы понять как это работает и решить задачу. Это наш метод.
По теории чего? O_O А в общем плане — параллельно… Точнее даже так, мой путь в IT начинался с чтения всяких интересных книжек и ессесно руки чесались реализовать прочитанное на практике. Кстати гуглить (или копипастить с условного SO) — плохая практика, как по мне. К сожалению навык чтения понимания, поиска и использования штатной документации мало кто даёт, что прекрасно видно во всяких девопс и админских чатах в телеграме.
Поддержу оттачивание навыка чтения документации, иногда ловлю себя на мысли, что моим конкурентным преимуществом является то, что я умею читать документацию и делаю это ДО того, как приступаю к работам. Особенно стал ценить документацию после того, как сам начал её писать :) И про «сначала практика, а потом теория» тоже нравится подход — были в практике эпизоды, когда сначала начинал плотно работать с продуктом, а потом примерно через год курсы с теорией случились — сразу столько вопросов по архитектуре продукта! :)
вот и я про тоже. Выбор университета был бы более осознанным, если бы сначала я пошел поработать помощником инженером связи. Сначала практика, а потом уже теория.
Про типы групп в домене( безопасности и распространения, локальные, глобальные, универсальные ) не знал никто

Здесь я могу даже пояснить причину. Пока человек не работал с лесом (был только один домен) — его не беспокоила классификация групп совершенно. Равно как и группы распространения он, скорее всего, создавал через оснастку exchange (если у них он вообще был). Причём создавал, скорее всего, один раз (если домен создавал в компании он) или вообще ни разу, если создали до него. В большой распределенной компании таким он занимался бы чаще, но и денег уже хотел бы больше.

Формально это уровень админа (AGUDLP идёт в курсе MCSA), а хелпдеску достаточно знать названия групп в которые включать пользователей.
В принципе даже в большой распределенной компании встретить мультидоменную или многолесовую архитектуру можно крайне редко. У меня в предыдущей компании мультилес появился только из-за миграции в другой домен в связи с продажей части компании. Вот в тот момент я и познакомился с различиями групп.

Но если конечно делать согласно рекомендациям microsoft (согласно курсам), то минимально в конторе должно быть минимум 3 леса с правильно настроенными трастами (лес для пользователей, лес для ресурсов, лес для админских учеток). Еще у вас может быть лес для shielded vm. Может еще какой забыл.
Ресурсный лес, PAM и guarded fabric — это игрушки для очень больших компаний, где админов обучают перед внедрением.

Я просто напишу тут 3 буквы:
SRE

DevOps это все набор рекомендаций.
Это набор рекомендация фиксировать свои действия в повторяемом коде.

НЕЛЬЗЯ ИЗ ЧЕЛОВЕКА СДЕЛАТЬ НОРМАЛЬНОГО ДЕВОПСА ЕСЛИ ОН НЕ ПОНИМАЕТ ЧТО У НЕГО В ХОЗЯЙСТВЕ ТВОРИТЬСЯ.

Вот есть масса проектов в которых приходят заказчики и говорят нам нужен крутой CI/CD но dicker cocker docker использовать нельзя.
Берешь и делаешь ( кушать хочеться однако)

Есть заказчики которые не позволят выход в интернет ряду серверов ( а манагеры модные классные -кучу слов знают)
берешь и делаешь ( особенно люблю когда проекы в закрытых контурах на питоне и node.js вообще красота )

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

Бывают заказчики у котрых закупка оборудования 1 раз в год и ты тут тресни но обеспечь полный цикл ( ах да нам бы еще еластик прикрутить… ЭЭЭЭЭ а че так много? ну это давайте другими методами логи обрабатывать.)

Так что заказчик разные ( деньги у него) — команды разные ( но все хотят MagicButton)

и ненавижу yml
bash такой теплый уютный
У вас, кстати, косяк… Вот эта ссылка недоступна даже залогиненым пользователям. В результате выбор у новичка превращается в /dev/random
;-)
image

Вот мне совершенно непонятно вся эта возня вокруг девупсов/админов/сре.
Это три совершенно разных слова! Сисадмин делает инфраструктуру. Девопс ничего не делает! Девопс это список! Список мать их рекомендаций! SRE это конкретный человек ( не зря там Е — енженегр).
В начале года активно хантил в команду админа, а ещё дежурного искал (удаленка, другой часовой пояс и все такое). Так вот заметил что все хотят в девУпсы. А ведь это диктуется рынком — девУпсы больше получают, а знать так особо и не надо — сиди и пиши свои ямлики. А когда человеку (который деплоил абсолютно все на старой работе, даже эктив директори деплоил) как понять почему при виртуалка не разрешает простому пользователю что-либо записать на диск (подразумеваться поиск проблем и плавный подвод к вопросу про inodes) человек отвечает что никогда с таким не сталкивался и вы спрашиваете какие-то слишком сложные вещи.
Другой (с 10-летним стажем на одном месте из которых последние 7 это руководитель отдела на 5-10 человек) на вопрос про резервное копирование (как устроено, нахрена оно вам вообще, ротация, шедулинг) сказал дословно: «А оно там было до меня сделано, а я особо не вникал как и что там».
А ведь оба данных персонажа хотят стать девУпсами! Чтоб 100500ккк наносек получать.
А основной косяк такой картины именно на стороне компаний, которые пишут «девупс», а нужен им даже не сисадмин, а эникейщик, который будет делать все и за доширак.

Можно ли сказать, что девопс с точки зрения практик это некий аналог ITIL только для разработки, а не для сервиса?
Разработчики в свое время делились по языкам программирования и по прикладным и системным. Теперь еще бэкенд, фронтенд, DBA и так далее.

Сисадмины тоже разделились

* эникейщики — достаточно для небольших контор либо техсаппорт (базовая настройка и установка, сборка и обслуживание оргтехники, юзер саппорт)

* сисадмины для крупных контор — Архитектура инфраструктуры, безопасность, все эти AD и профилирование, автоматизация

* сетевики — протоколы, маршрутизаторы, всякие BGP, роуты, циски, оптика, радио, оборудование.

* девопсы — инфраструктура, автоматизация и поддержка инфраструктуры и инструментов для нее, и важный момент — настройка деливери.

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

В одних и тех же компаниях зарплата ведущих девопсос в полтора раза выше ведущих админов.


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

Это вполне естественно. Ты всего лишь админ. А они девупсы и они пришли сюда не принтеры чинить или в AD'шку добавлять пользователя, и уж тем более не настраивать постфикс.А пришли собственно девупсы за тем, чтобы решать конкретные бизнесов задачи. Должны приходить за этим. А компании должны искать девупсов именно для этого — для решения конкретных бизнесовых задач. А не потому что это стильно/модно/молодежно.
Компаний, которые четко понимаю кто и за каким им нужен, категорически мало. Несколько раз и мне прилетали предложения о работе на позиции DevOps, DevOps-инженер, Expert DevOps, НО! Довольно часто в описании вакансии на позицию человека который должен решить/решать проблему бизнеса указано: настройка резервного копирования для ms exchange, опыт 1С обязателен.
После таких предложений начинаешь задумываться: а тем ли я в своей жизни занимаюсь? Может пойти в каменщики (я умею/я могу)? Или в автомеханики?
В одних и тех же компаниях зарплата ведущих девопсос в полтора раза выше ведущих админов.

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

Если мы говорим про аутсорс, то админы вообще работают на локальную компанию, а девопсы на конкретного (зарубежного) заказчика, подписывают NDA.
А что мешает админа нанять для внешнего заказчика и подписать с ним NDA?
С другой стороны: как оно в «забугорье» я не скажу, да и за всех сразу тоже не отвечу, а вот по моему опыту — админ (как и ИТ-отдел в целом) в средней отечественной компании, для которой разработка (продукта/сервиса/приложеньки) не является основной статьей дохода, это всего лишь «мальчик», который должен сделать так чтоб и кофе-машина на кухне работала, и почта у генерального на айпэде работала, и 1С'ка работала без тормозов, а в случае чего вся инфраструктура исчезла с радаров по команде.
Могу так заявлять, т.к. сам был таким «мальчиком» каких-то 5-6 лет назад. Спасло от неба в клеточку, только врожденное желание выживать.

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

Так девопс это и есть отдельный админ. Просто он умеет работать с инструментами для разработчика.
Если рассуждать о сферическом вакууме, то, как по мне, такая аналогия уместна. Из того, что я вижу/наблюдаю, DevOps это не столько про разработку, сколько про «дружбу народов» дружбу developers и operations. DevOps это о том, как подружить разработку и инфраструктуру, чтобы достичь конкретной цели — уменьшить время которое проходит от момента появления идеи до момента когда код реализующий данную идею становится доступен пользователям. DevOps более логично применять именно к продукту, которым пользуются «внешние клиенты» для продуктовых компаний (самый простой пример: wildberries[.]ru — там довольно большой список технологий/сервисов которые работают на клиентов/покупателей — прим.: я не сотрудник данного сервиса). ITIL же в свою очередь больше направлен на внутренние сервисы, клиентами которых являются сотрудники компании (вся инфраструктура, которая обеспечивает позволяет компании жить и функционировать).
Если кто-то считает, что я не прав — я готов к дискуссии :|
Ну вопрос был не про направленность на внешние/внутренние дела, а именно про то, что девопс это просто способ организации процессов или нет? Если да, то он чем то похож на ITIL, который тоже есть способ организации процессов. Ну что то вроде «чтобы получить результат Х оптимальным быстрым образом, надо делать А, В, С». В ITIL у нас X это внутренний сервис, а в devops это сервис по доставке кода. И поэтому как в ITIL не было специальности «ITIL», а можно было лишь говорить о том, что в компании есть выстроенные по ITIL процессы, так и про devops корректнее говорить, что нет специальности devops, а есть просто выстроенные по devops процессы, которые вполне себе может освоить грамотный админ. Я прав или нет?
В целом я могу согласиться таким утверждением.
Девопс это набор практик. А дальше каждый в это понятие сует то что ему удобно. И каждый хочет что то свое и яростно защищает свой набор требований к тому какой должен быть тру девопс, хотя если приглядеться там просто намешали сетевых инженеров, админов поддержки и релиз инженеров, ну и сверху присыпали прогером немного.

Часто прогеры делают код, который падает сам по себе, но виноваты естественно не они. Очень удобно все это межгрупповое взаимодействие слить на девопс инженера и сделать его крайним.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории