На данный момент это чуть ли не самая дорогая позиция на рынке. Суета вокруг "DevOps" инженеров превосходит все мыслимые пределы, а тем хуже с Senior DevOps инженерами.
Я работаю руководителем отдела интеграции и автоматизации, угадайте английскую расшифровку — DevOps Manager. Отражает ли именно английская расшифровка нашу повседневную деятельность — вряд ли, а вот русский вариант в данном случае более точен. По роду моей деятельности, естественно, что мне, необходимо собеседовать будущих членов моей команды и, за прошедший год, через меня прошло человек 50, а еще столько же срезалось на прескрине с моими сотрудниками.
Мы все еще находимся в поиске коллег, потому как за лейблом DevOps прячется очень большая прослойка разного рода инженеров.
Все написанное ниже является моим личным мнением, вы не обязаны соглашаться с ним, однако допускаю, что внесет оттенок в ваше отношение к теме. Несмотря на риск попасть в немилость, я публикую свое мнение, поскольку считаю что ему есть место быть.
Компании по-разному понимают кто такие DevOps инженеры и ради быстрого найма ресурса вешают этот лейбл всем. Ситуация достаточно странная, поскольку компании готовы платить нереальные вознаграждения этим людям, получая за них, в большинстве случаев, админа-тулзиста.
Так кто же такие DevOps инженеры?
Давайте начнем с истории появления — Development Operations появился как еще один шаг к оптимизации взаимодействия в малых командах для повышения скорости производства продукта, как ожидаемое следствие. Идея заключалась в том, чтобы усилить команду разработки знаниями о процедурах и подходах в управлении продуктовой средой. Иными словами, разработчик должен понимать и знать как его продукт работает в тех или иных условиях, должен понимать как деплоить его продукт, какие характеристики среды подкрутить, чтобы повысить производительность. Так, в течение некоторого времени, появились разработчики с DevOps подходом. DevOps разработчики писали скрипты сборки и упаковки для упрощения своей деятельности и работоспособности продуктивной среды. Однако, сложность архитектуры решений и взаимное влияние компонентов инфраструктуры с течением времени начало ухудшать рабочие показатели сред, с каждой итерацией требовались все более глубокие понимания тех или иных компонентов, снижая продуктивность самого разработчика из-за дополнительных затрат на понимание компонентов и тюнинга систем под конкретную задачу. Собственная стоимость разработчика росла, стоимость продукта вместе с ним, резко подскочили требования к новым разработчикам в команде, ведь им необходимо было также покрывать обязанности «звезды» разработки и, естественно, «звезды» становились все менее доступны. Также стоит отметить, что, по моему опыту, мало кому из разработчиков интересна специфика обработки пакетов ядром операционной системы, правила маршрутизации пакетов, аспекты безопасности хоста. Логичным шагом было привлечь администратора, который именно с этим знаком и возложить подобного формата обязанности именно на него, что, благодаря его опыту, позволило достичь тех же показателей меньшей стоимостью в сравнении со стоимостью «звезды» разработки. Таких администраторов помещали в команду и основной его задачей было управление тестовыми и продуктивными средами, на правилах конкретно взятой команды, с ресурсами выделенными именно этой команде. Так, собственно, и появились DevOps в представлении большинства.
Частично или полностью, со временем, данные системные администраторы начали понимать потребности именно этой конкретной команды в области разработки, как упростить жизнь разработчикам и тестировщикам, как выкатить обновление и не остаться ночевать в пятницу в офисе, исправляя ошибки деплоя. Время шло, теперь «звездами» становились системные администраторы, понимающие чего хотят разработчики. С целью минимизации импакта начали подтягиваться утилиты управления, все вспомнили старые и надежные методы изоляции уровня ОС, которые позволяли минимизировать требования по безопасности, управлению сетевой части, да и конфигурации хоста в целом и, как следствие снизить требования к новым «звездам».
Появилась «замечательная» вещь — docker. Почему замечательная? Да только лишь потому, что создание изоляции в chroot или jail, равно как OpenVZ, требовало нетривиальных знаний ОС, в контру утилите позволяющей элементарно создать изолированную среду приложения на неком хосте со всем необходимым внутри и передать бразды правления разработке вновь, а системному администратору управлять только лишь одним хостом, обеспечивая его безопасность и высокую доступность — логичное упрощение. Но прогресс не стоит на месте и системы вновь становятся все сложнее и сложнее, компонентов все больше и больше, один хост уже не удовлетворяет потребностям системы и необходимо строить кластеры, мы вновь возвращаемся к системным администраторам, которые способны построить данные системы.
Цикл за циклом, появляются различные системы упрощающие разработку и/или администрирование, появляются системы оркестрации, которые, ровно до тех пор, пока не требуется отойти от стандартного процесса, просты в использовании. Микросервисная архитектура также появилась с целью упрощения всего описанного выше — меньше взаимосвязей, проще в управлении. В своем опыте я не застал полностью микросервисную архитектуру, я бы сказал 50 на 50 — 50 процентов микросервисов, черные коробки, пришло на вход, вышло обработанное, другие 50 — разодранный монолит, сервисы неспособные работать отдельно от других компонентов. Все это вновь наложило ограничения на уровень знаний как разработчиков, так администраторов.
Подобные «качели» уровня экспертных знаний того или иного ресурса продолжаются и по сей день. Но мы немного отвлеклись, есть немало моментов которые стоит осветить.
Build Engineer/Release Engineer
Весьма узкоспециализированные инженеры, появившиеся как средство стандартизации процессов сборки ПО и его релизов. В процессе введения повального Agile казалось бы они перестали быть востребованы, однако это далеко не так. Эта специализация появилась как средство стандартизации именно сборки и поставки ПО в промышленных масштабах, т.е. используя стандартные техники для всех продуктов компании. С появлением DevOps разработчиков частично утратили функции, поскольку именно разработчики стали подготавливать продукт к поставке, а учитывая изменяющуюся инфраструктуру и подход в максимально быстрой поставке без оглядки на качество со временем превратились именно в стопор изменений, поскольку следование стандартам качества неизбежно замедляет поставки. Так, постепенно, часть функционала Build/Release инженеров перекочевала на плечи системных администраторов.
Ops'ы такие разные
Мы двигаемся дальше и вновь наличие большого круга обязанностей и недостаток квалифицированных кадров толкает нас на жесткую специализацию, как грибы после дождя, появляются различные Operations:
- TechOps — системные администраторы эникеи aka HelpDesk Engineer
- LiveOps — системные администраторы, преимущественно отвечающие за продуктивные среды
- CloudOps — системные администраторы специализирующиеся на публичных «облаках» Azure, AWS, GCP, etc.
- PlatOps/InfraOps/SysOps — системные администраторы инфраструктуры.
- NetOps — сетевые администраторы
- SecOps — системные администраторы специализирующиеся на информационной безопасности — PCI compliance, CIS compliance, patching, etc.
DevOps — (в теории) персона, не понаслышке понимающая все процессы цикла разработки — разработку, тестирование, понимающая архитектуру продукта, способная оценить риски безопасности, знакомая с подходами и средствами автоматизации, хотя бы на высоком уровне, помимо этого понимающая также пред и пост-релизную поддержку продукта. Персона способная выступать адвокатом как Operations, так Development, что позволяет выстроить благоприятное сотрудничество между этими двумя столпами. Понимающая процессы планирования работ командами и управления ожиданиями заказчика.
Для выполнения подобного рода работ и обязанностей данная персона должна иметь средства управления не только процессами разработки, тестирования, но и управления инфраструктурой продукта, а также планирования ресурсов. DevOps в данном понимании не может находится ни в IT, ни в R&D, ни даже в PMO, он должен иметь влияние во всех этих областях — технический директор компании, Chief Technical Officier.
Так ли это в вашей компании? — Сомневаюсь. В большинстве случаев это или IT, или R&D.
Недостаток средств и возможности влияния хотя бы на одно из этих трех направлений деятельности произведет смещение веса проблем в сторону где эти изменения проще применить, как например применение технических ограничений на релизы в связи с «грязным» кодом по данным систем статического анализатора. То есть когда PMO устанавливает жесткий срок на выпуск функционала, R&D не может выдать качественный результат в эти сроки и выдает его как может, оставив рефакторинг на потом, DevOps относящийся к IT, техническими средствами блокирует релиз. Недостаток полномочий на изменение ситуации, в случае с ответственными сотрудниками ведет к проявлению гиперответственности за то, на что они не могут повлиять, тем паче если эти сотрудники понимают и видят ошибки, и как их исправить — «Счастье в неведении», и как следствие к выгоранию и потери этих сотрудников.
Рынок DevOps ресурсов
Давайте рассмотрим несколько вакансий на позицию DevOps от разных компаний.
Мы готовы с Вами встретится, если Вы:
- Владеете Zabbix и знаете, что такое Prometheus;
- Iptables;
- Аспирант BASH;
- Профессор Ansible;
- Гуру Linux;
- Умеете пользоваться дебагом и совместно с разработчиками находить проблемы приложений (php/java/python);
- Роутинг не вызывает у Вас истерик;
- Уделяете значительное внимание безопасности системы;
- Бекапите “всё и вся“, а также успешно восстанавливаете это “всё и вся“;
- Умеете настроить систему так, чтобы выжать из минимума — максимум;
- Настраиваете репликации перед сном на Postgres и MySQL;
- Настройка и корректировка CI/CD для Вас — это необходимость как завтрак/обед/ужин.
- Имеете опыт работы с AWS;
- Готовы развиваться вместе с компанией;
Итак:
- с 1 по 6 — системный администратор
- 7 — немного сетевого администрирования, что тоже укладывается в сисадмина, уровня Middle
- 8 — немного безопасности, что обязательно для сисадмина уровня Middle
- 9-11 — Middle System Administrator
- 12 — В зависимости от поставленных задач либо Middle System Administrator, либо Build Engineer
- 13 — Виртуализация — Middle System Administrator, либо так называемый CloudOps, расширенные знания именно сервисов конкретной хостинг площадки, для эффективного использования денежных средств и снижения нагрузки на обслуживание
Резюмируя по данной вакансии можно сказать, что ребятам достаточно Middle/Senior System Administrator.
Кстати, не стоит сильно разделять админов на Linux/Windows. Я конечно понимаю, что сервисы и системы этих двух миров различаются, но основа у всех одна и любой уважающий себя админ знаком как с одним, так и с другим, и даже если не знаком, то для грамотного админа не составит труда ознакомится с этим.
Рассмотрим иную вакансию:
- Опыт построения высоконагруженных систем;
- Отличные знания ОС Linuх, общесистемного ПО и веб-стека (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Опыт работы с системами виртуализации (KVM, VMWare, LXC/Docker);
- Владение скриптовыми языками;
- Понимание принципов работы сетей сетевых протоколов;
- Понимание принципов построения отказоустойчивых систем;
- Самостоятельность и инициативность;
Разбираем:
- 1 — Senior System Administrator
- 2 — В зависимости от смысла вкладываемого в этот стэк — Middle/Senior System Administrator
- 3 — Опыт работы, в том числе, может означать — «Кластер не подымал, но создавал и управлял виртуалками, был один Docker хост, доступ к контейнерам натил» — Middle System Administrator
- 4 — Junior System Administrator — да, админ не умеющий писать элементарные скрипты автоматизации, вне зависимости от языка, не админ — эникей.
- 5 — Middle System Administrator
- 6 — Senior System Administrator
Резюмируя — Middle/Senior System Administrator
Еще одна:
- Опыт работы devops;
- Опыт в использовании одного или нескольких продуктов для формирования CI/CD процессов. Gitlab CI будет преимуществом;
- Работа с контейнерами и виртуализацией; Если использовали docker – хорошо, а если k8s – отлично!
- Опыт работы в agile-команде;
- Знание любого языка программирования;
Посмотрим:
- 1 — Хм… Что ребята имеют в виду? =) Скорее всего они сами не знают что за этим скрывается
- 2 — Build Engineer
- 3 — Middle System Administrator
- 4 — Софт-скил, рассматривать пока не будем, хотя Agile еще одна вещь, которую интерпретируют так, как удобно.
- 5 — Слишком пространно — это может быть скриптовый язык, либо компилируемый. Интересно, а писал в школе на Pascal и Basic их устроит? =)
Хотелось бы также оставить ремарку относительно 3 пункта, дабы укрепить понимание, почему этот пункт покрывается сисадмином. Kubernetes всего лишь оркестрация, тулза которая оборачивает прямые команды драйверам сети и хостам виртуализации/изоляции в пару команд и позволяет сделать общение с ними абстрактным, вот и все. Для примера возьмем 'build framework' Make, коего фреймворком я, к слову, не считаю. Да, я знаю про моду пихать Make куда угодно, где нужно и не нужно — обернуть Maven в Make например, серьезно?
По сути Make просто обертка над shell, упрощающая именно команды компиляции, линковки, окружения компиляции, так же как и k8s.
Однажды, я собеседовал парня, который использовал k8s в своей работе поверх OpenStack, и он рассказывал как развертывал сервисы на нем, однако, когда я спросил именно про OpenStack, оказалось, что он администрируется, равно как и подымается системными администраторами. Вы правда думаете, что человек поднявший OpenStack вне зависимости от того какую платформу он использует позади него не способен использовать k8s?=)
Данный соискатель на самом деле не DevOps, а такой же Системный Администратор и, чтобы быть точнее, Kubernetes Administrator.
Резюмируем в очередной раз — Middle/Senior System Administrator им будет достаточно.
Сколько вешать в граммах
Разброс предлагаемых зарплат для указанных вакансий — 90к-200к
Теперь хотелось бы провести параллель между денежными вознаграждениями Системных Администраторов и DevOps Engineers.
В принципе, для упрощения можно грейды по опыту работы раскидать, хоть это и не будет точным, для целей статьи хватит.
Опыт:
- до 3-х лет — Junior
- до 6-ти лет — Middle
- более 6-ти — Senior
Сайт поиска сотрудников предлагает:
System Adminsitrators:
- Junior — 2 года — 50к руб.
- Middle — 5 лет — 70к руб.
- Senior — 11 лет — 100к руб.
DevOps Engineers:
- Junior — 2 года — 100к руб.
- Middle — 3 года — 160к руб.
- Senior — 6 лет — 220к руб.
По стажу «DevOps»'ов использовался стаж, хоть как то затрагивающий SDLC.
Из вышеозначенного следует, что на самом деле компаниям не нужны DevOps'ы, а также что они могли сэкономить не менее 50 процентов от изначально запланированных затрат, наняв именно Администратора, более того, они могли бы четче определить обязанности искомого человека и быстрее закрыть потребность. Не стоит также забывать, что четкое разделение ответственности позволяет снизить требования к персоналу, а также создать более благоприятную атмосферу в коллективе, ввиду отсутствия пересечений. В подавляющем большинстве вакансии пестрят утилитами и DevOps лейблами, однако не имеющие в основе действительно требования к DevOps Engineer, лишь запросы на тулзового администратора.
Процесс обучения DevOps инженеров также ограничен лишь набором специфичных работ, утилит, не дает общего понимания процессов и их зависимостей. Это конечно хорошо, когда человек может используя Terraform задеплоить AWS EKS, в связке с Fluentd сайд-каром в этом кластере и AWS ELK стеком для системы логирования за 10 минут, используя лишь одну команду в консоли, но если он не будет понимать сам принцип обработки логов и для чего они нужны, не знать как собирать метрики по ним и отслеживать деградацию сервиса, то это будет все тот же эникей, умеющий использовать некоторые утилиты.
Спрос, однако, порождает предложение, и мы видим крайне перегретый рынок позиции DevOps, где требования не соответствуют реальной роли, а лишь позволяют системным администраторам зарабатывать больше.
Так кто же они? DevOps'ы или жадные системные администраторы? =)
Как дальше жить?
Работодателям — точнее формулировать требования и искать именно тех кто нужен, а не разбрасываться лейблами. Вы не знаете чем занимаются DevOps — они вам не нужны в таком случае.
Работникам — Учиться. Постоянно совершенствовать свои знания, смотреть на общую картину процессов и отслеживать путь к поставленной цели. Можно стать кем захочешь, надо лишь постараться.
Комментарии (93)
gre
28.09.2019 18:11А можете уточнить — про что вы пишете:
— Зарплаты на рынке — так это ок — рынок же
— Что специалит, который выстраивает процессы стоит дорого?
— То, что кадровики вместе сис.админов нанимают дивопсов?
Ну так они так и нанимают — на 90к со сменным графиком.
axmetishe Автор
28.09.2019 18:16немного о зарплатах на рынке и ожиданиях соискателей;
немного о том, что в действительности ожидают от соискателей;
немного о неправильных подходах в компании и подмене понятий,
в общем обо всем понемногу.gre
28.09.2019 18:38+1Так вот же точная цитата:
```
DevOps — (в теории) персона, не понаслышке понимающая все процессы цикла разработки — разработку, тестирование, понимающая архитектуру продукта, способная оценить риски безопасности, знакомая с подходами и средствами автоматизации, хотя бы высокоуровнево, помимо этого понимающая также пред и пострелизную поддержку продукта. Персона способная выступать адвокатом как Operations, так Development, что позволяет выстроить благоприятное сотрудничество между этими двумя столпами. Понимающая процессы планирования работ командами и управления ожиданиями заказчика.
```
Вся остальная статья вокруг того, что люди неправильно называют других спецов.
Ну или растят своих специалистов под эти требования.
gre
28.09.2019 18:37+1Ну я бы еще отметил пункт про «На данный момент это чуть ли не самая дорогая позиция на рынке»
А вы с кем сравнивали?
Как в одном из чатов утверждают — с финскими уборщицами?
Как только мы уходим в сеньёров — devops/sre далеко не самая дорогая позиция.axmetishe Автор
28.09.2019 19:00Естественно речь идет о российском рынке специалистов в области ИТ и, явным образом, указано сравнение с Системными администраторами.
Я не говорю о стоимости ИТ-специалистов в мире, сравнивать зп между странами в лоб, будет некорректно, и не говорю о разнице в ней между США, Финляндией, Россией, Англией и т.д., естественно разница высока, но и стоимость жизни, равно как размер налогообложения.
Относительно дороговизны — все понимают, что при переходе в Senior грейд, рамки между стоимостью специалистов стираются и Senior DevOps Engineer может стоить столько же, сколько Senior Render Engineer, Senior C++ Developer и т.д. Но Senior должен быть действительно Senior, а не обычный тулзист.gre
28.09.2019 20:28Явно не указано про сравнение с сис.админами — просьба указать более явно прямо в первой строке вашего текста.
Как вы считаете — у DevOps-инженеров больше функций, чем у Системных администраторов?
Обосновано ли, что их зарплата больше?skrimafonolog
29.09.2019 13:48Как вы считаете — у DevOps-инженеров больше функций, чем у Системных администраторов?
Это совсем неважно.
Ибо:
Обосновано ли, что их зарплата больше?
Важно только:
Какой спрос, а какое предложение.
Gerrr
28.09.2019 19:07+8Нет людей devops-инженеров. Devops — это методология. И основу ее составляют далеко не инструменты.
Наверное есть devops-евангелисты, но не более. Все остальное — это извращенное недопонимание рынка.cccco
28.09.2019 20:05Вот, интересно получается, devops-евангелисты есть, а devops-инженеров нет.
Gerrr
28.09.2019 20:14+3А кто-такой девопс-инженер? Чем он занимается? Dev-инфраструктурой и ci, как администратор тестовых сред? Выкаткой в прод, как релиз-инженер? Поддержкой продакшена, как operations-инженер? Думаю можно продолжать. И все это будут другие роли.
Девопс — это методология направленная на ускорение поставки "инкремента" путем сращивания процессов разработки, operations и на самом деле многих других подразделений. Выставления общих целей. Так чем должен заниматься devops-инженер при таком подходе?cccco
28.09.2019 20:27Девопс — это методология, однако, devops-евангелисты есть, а devops-инженеров нет.
Gerrr
28.09.2019 20:30Да. Однако!
cccco
28.09.2019 20:46Нет людей devops-инженеров. Devops — это методология.
Тогда, следуя Вашей логике:
Нет людей android-разработчиков. Android — это операционная система. Нет?
Девопс — это методология направленная на ускорение поставки "инкремента" путем сращивания процессов разработки, operations и на самом деле многих других подразделений. Выставления общих целей.
Так чем должен заниматься devops-евангелист при таком подходе?
Gerrr
28.09.2019 21:23+1Странное сравнение с андройд-разработчиком. Если брать методологию. То более корректный пример был бы со скрам-мастером. Там правда человек который следит за соответствием интерпритации (скрам) такой методолгии как agile. Но все же. Вы когда-нибудь встречали скрам-инженера? Я нет.
Девопс-евангелист — тоже довольно расплывчатая роль. Но более простая для понимания. Это человек, который работает с разработчиками, продакт-менеджерами и владельцами проекта. В направлении изменения процессов разработки. Построению взаимодействия всех заинтересованных отделов и бизнеса. Выправлениям целей. И прочее-прочее. Если продолжать аналогию со скрам-мастером — это как раз этакий центр обучения методологии. К сожалению только вот нет у него такой классной штуки как манифест в скраме. Есть только довольно расплывчатые 3 пути.cccco
28.09.2019 22:19-2Я недавно был в Пушкинском музее на выставке коллекции картин импрессионистов Щукина. Картины очень дорогие. Вот, теперь в замешательстве. Получается, нет никаких импрессионистов. Импрессиониизм — это же направление в искусстве, а не человек. Подождите, может, инструменты у них какие-то особенные? Да, вроде, нет — обыкновенные: кисти, краски. Значит, они всё-таки — просто художники. Подождите. А, может, и художников тоже нет, а все эти люди на самом деле — обыкновенные моляры? У тех тоже инструменты — кисти и краски.
А такая высокая стоимость картин этих моляров — это всё из-за хайпа.Gerrr
28.09.2019 22:47+2Вы все очень сильно расширяете. Думаю надо довести все окончательно до абсурда и прийти выводу, что художник — человек. Ну и что человека нет. И знаете. Тут на границе с абсурдом я с вами полностью согласен. И не придраться ни к чему совсем. Вы правы.
Спасибо большое, за расширение кругозора. Слово инженер заиграло новыми красками для меня.
Полезены ли все эти рассуждения. По мне так они еще более запутывают и так, к сожалению, замученое рынком направление. Так что, я предпочту воздержаться от такого подхода. И остаться при своем мнении.cccco
29.09.2019 00:19-1Ни в коем случае не хотел Вас в чём-то переубедить. Хотел всего лишь понять, как выражение "Devops — это методология" обосновывает утверждение "Нет людей devops-инженеров". (При этом devops-евангелисты почему-то всё-таки есть.) ???
Далее мне вот, ещё что не понятно. Почему из факта владения devops-инженером необходимыми для выстраивания процессов по методологии devops инструментами делается вывод, что "основу ее (методологии) составляют далеко не инструменты"? Тем самым, как я понял, подразумевается, что devops-инженером незаслуженно называют человека, просто владеющим определёнными инструментами. Согласитесь, что, если devops-инженер, не будет владеть соответствующими инструментами, то и процессы он необходимым образом выстроить не сможет. Это же очевидно.
Я бы сказал так, devops-инженер — это не только про инструменты. Инструменты — суть необходимое условие для devops-инженера, но недостаточное. Это же тоже очевидно.
Конечно, если видеть в devops-инженере только инструменты, то могут возникнуть вопросы. Но только чьи это проблемы-то: devops-инженера или того, кто до конца не разобрался и так видит?
И ещё. А почему сисадмин-то? Почему не разработчик? В слове devops "dev" стоит на первом месте, между прочим.
Gerrr
29.09.2019 07:32+1Про разработчика согласен — спокойно может быть человеком, который продвигает девопс в компаниях.
Про девопс-инженера. Выстраивание процессов — это совместная работа нескольких подразделений. Не может этим заниматься один человек.
Точнее, к сожалению, последнее время так многие как раз и стараются поступать. Берут себе девопс-инженера и такие давай. Выстраивай. И что может этот человек. Настроить ci. Написать деплой. Обложить прод мониторингом. Роли, которые он выполняет в этот момент я перечислял выше.
Но если зайти с другим подходом. Когда несколько команд с лидером, назовем его PO. Собираются. Нам надо ускорить разработку. Нам надо выкатывать фичи чаще. Как мы можем построить свою работу для этого? Хм. Ну давайте разбираться с гибкими методологиями разработки. Давайте пройдем обучение по одному из фреймворков (скрам, канбан). Давайте поймем суть 3-х путей. Выстроим линию поставки, наделаем петель обратной связи, будем шарить знания и не будем искать виноватых. Давайте будем все стремиться делиться компетенциями, чтобы говорить совместно на одном языке.
В первом случае человек есть, а девопса как такового нет. Копи-паста бездумная.
Во втором — человека нет. А девопс есть. Ну или можно сказать, что все там девопс-инженеры, и опс, и дев, и тестировщик, и PO, и т.д. Но их можно тогда называть и agile-инженерами, и еще как-то.
Когда я повторяю эту фразу про методологию, я не стремлюсь кого-то обидеть. Я просто хочу обратить внимание рынка на второй вариант.
cccco
29.09.2019 12:03-1Следуя Вашей логике получается проджект-менеджер есть, а проекта как такового нет. Одна копи-паста безумная. Ну а что, проект — это же совместная работа нескольких подразделений. Не может этим заниматься один человек. Далее по ходу пьесы (зачем-то) следует перечисление ролей, которые он выполняет. Это в первом случае.
Во втором случае Вы описали Лебедя, Рака и Щуку.
Ну, и информация для размышления касательно обоих случаев: как Вы считаете, выстраивание какого-либо процесса (с дальнейшим его поддержкой, развитием, изменением и т.п.) с одной стороны и участие в самом этом процессе с другой стороны — суть одно и то же или всё-таки разное?
Gerrr
29.09.2019 12:30+1На тренингах по скраму есть понятие копипаст скрам. Это как раз когда менеджера проекта берут, основные атрибуты добавляют, а мысли и идеологии не придерживаются. Так что да. Бывают пооекты, где менеджер есть, а проекта в полном понимании нет.
Как раз таки и пытаюсь вам объяснить, что выстраивание процесса — это коллективное действие. Один человек не может вместо коллектива этим заниматься. Максимум, что он может — это обучать этот коллектив. Находить единомышленников, работать в направлении внедрения девопс практик. Находить совместно с колегами нужные инструменты. Внедрять их тоже, но опять же понимая зачем это все нужно и доносить это понимание или приобретать с остальными вместе.
Если вам удобно такого человека называть девопс-инженером. То почему бы и нет. Просто термин так себе по-моему. И рынком уже сильно скомпроментирован, к моему сожалению.cccco
29.09.2019 12:50Я же пытаюсь Вам донести, что в любом коллективном действии без человека, который это действие колективное возглавляет, получается "колхоз". Согласен, выражался я иносказательно, если Вы это не поняли, назвав это всё Лебедем, Раком и Щукой.
Gerrr
29.09.2019 12:59Ну да. Это один из вариантов. Возглавить. В моем случае в самом начале моего пути, года 4-5 назад, когда я только пришел в на новую для себя должность девопс-инженер (да я тоже не существующий специалист )) ), это возглавлял на тот момент PO нашего стартапа. Был ли он сам тогда девопс-инженером — нет. Двигал ли он девопс практики — да! Еще как. Сам того тогда до конца возможно не понимая.
А про возглавить. Очень спорный момент. Вся гибкая разработка строится на горизонтальных командах. Но это уже совсем другая история.
VolCh
29.09.2019 13:38Колхоз или что-то вроде "самоорганизованной кроссфункциональной команды профессионалов" из скрама и прочего аджайл.
gecube
29.09.2019 10:14Согласитесь, что, если devops-инженер, не будет владеть соответствующими инструментами, то и процессы он необходимым образом выстроить не сможет. Это же очевидно.
Это ошибка. Можно строить процесс чужими руками, например. Спускаешь сверху задание — хочу пайплайн доставки кода. А деталями реализации пускай технарь занимается, которого автор статьи называет "тулистом"
cccco
29.09.2019 12:05Это ошибка. Владеть и пользоваться — суть разные вещи.
Gerrr
29.09.2019 12:37+1У меня, например, пайплайны в основном разработчики сейчас выстраивают и используют. Причем в нескольких продуктовых командах. И владеют и используют. Вот только скажи им, что они девопс-инженеры, похлопают по плечу и скажут — харе троллить. Мы мол разработчики, которые работают с использованием девопс-практик.
А мне только и остается, что стараться синхронизировать их знания, на их же митапах, чтобы практики в зоопарк не превращались. Людей-то много.cccco
29.09.2019 12:56Не, ну, если выстраивание паплайнов — суть девопс, кто ж будет с Вами спорить.
Gerrr
29.09.2019 13:04Не суть совсем. Я просто ответил в вашем треде.
Но опять же. Смотря что мы понимаем под пайплайном. У девопса по сути из более-менее сформулированных моментов. Это как раз "три пути". Первый как раз — построение линии поставки.cccco
30.09.2019 12:31Давайте подойдём с другой стороны. :)
"Не пользоваться" не значит "не владеть".
ApeCoder
29.09.2019 22:03Вы когда-нибудь встречали скрам-инженера?
https://www.scrumalliance.org/get-certified/developer-track/certified-scrum-developer
Gerrr
30.09.2019 00:22+1Это не совсем то. В скраме есть три роли. Владелец продукта, скрам-мастер и девелопер. Под понятие девелопера подпадают все участники команды. Не забываем про кросс-функциональность к которой стремятся в скрам командах.
Хотя с другой стороны, если бы девопс внедрялся аналогично было бы намного лучше.
igordoge
29.09.2019 11:02+2Зато может быть инженер по внедрению devops-практик. Для краткости таких и называют девопсами. Искать в этом некие ошибки и упирать на отсутствие такой профессии — занудство крайней степени.
cccco
29.09.2019 12:27Вот, согласен со всем полностью.
Хочу ещё добавить, что когда такой инженер по внедрению devops-практик или для краткости — devops-инженер начинает непосредственно эти практики внедрять, он становится в прямом смысле влиятельным субъектом, потому что начинает влиять на многие процессы. Иногда особо ранимым девам или опсам трудно это пережить. От сюда и занудство крайней степени, и хайп по поводу зарплат.
Gerrr
29.09.2019 12:50Полностью с вами согласен. Вот только к пониманию простой мысли, написанной вами, весь рынок идет ужасно кривым путем. Кого только девопсом не называют, лишь бы соответствовать трендам. И это все очень печально.
slonopotamus
28.09.2019 20:27+1Я даже не уверен что методология есть. Если посмотреть на статью про DevOps в википедии, то там сплошные "unreliable source", "citation needed" и вообще:
Academics and practitioners have not developed a unique definition for the term «DevOps.»
.
И обсуждаемая сейчас статья начинается с дисклеймера «это моё личное мнение».Gerrr
28.09.2019 20:36+1Ну да. Тут непростой вопрос. Методолгия часто довольно рпсплывчатая штука. Есть большой набор книг на эту тему. Есть бережливое производство. Есть "три пути" девопс. Но нет четкости в имплементации. Именно поэтому sre-инженеры есть. Там гугл постарался наделить их недостающими в методологии подходами. Хотя понятие sre рынок сейчас тоже коверкает как только хочет.
gre
28.09.2019 20:29смотрите на рынок труда — там такие специалисты есть.
То, что автор видит в них сис.админов — достаточно странная история, но есть такое заблуждение.Gerrr
28.09.2019 20:44+5Знаете. Я не хочу обидеть тех кто считает себя devops-инженерами. В том числе потому, что уже года 4-5 как, так или иначе именуюсь этим термином. Но сам себе врать не хочу. Девопс — это не человек. Это больше про процессы. Про построение взаимодействий и т.д.
А когда очередной раз слышишь, что девопс — это инструменты — docker, kuber, ansible, jenkins, gitlab-ci, etc и дополнительно умение работать с облаками. Становится грустно.
Радует только, что разработчики с которыми я работаю чаще понимают, что это не так.gecube
28.09.2019 21:33+1А когда очередной раз слышишь, что девопс — это инструменты — docker, kuber, ansible, jenkins, gitlab-ci, etc и дополнительно умение работать с облаками. Становится грустно.
Это типичная подмена понятий и карго-культ. Так что — правильно говорите — инструменты — не самоцель и процессов они не заменят.
gre
28.09.2019 21:58вы всё правильно пишете.
Должность DevOps-инженера она должна быть именно про процесссы.
Автор же указывает, что сейчас админов бездумно заместили девопсами.
Ну может хоть в комментах обучим автора )
Andrey_Rogovsky
28.09.2019 20:33+1DevOps — это культура работы с кодом. На всех этапах.
Исходя из культуры и требований формируется методология.
beduin01
28.09.2019 20:33-5Если коротко, то DevOps это неудавшийся админ. Делать культ из этого занятия все равно, что уверять, что есть люди с призванием почтальона.
Главное отличие DevOps — это зачастую полное отсутствие фундаментальных знаний. Спроси такого человека как устроена виртуальная память, он не скажет, зато при первом удобном случае будет Docker'ом мозги полоскать.Gerrr
28.09.2019 21:35+1Мы работаем в изменяющейся отрасли. Об этом нельзя забывать. Сейчас знание докер, зачастую может принести больше денег бизнесу, чем знание того как устроена виртуальная память.
А через несколько лет все изменится еще сильнее. И мы должны это понимать и принимать.
Был бы тут umputun он бы наверное сказал — "вот она смерть сисадмина, о которой я уже не первый год говорю!" Вот только по мне так это скорее перерождение профессии.
cccco
28.09.2019 20:56+2Выскажу сугубо своё личное мнение.
Могу предположить, что если бы зарплаты devops-инженеров были ниже зарплат Девов или Опов, такого хайпа бы не было.
Какая-то неделя зависти к зарплатам devops-инженеров на Хабре.Gerrr
28.09.2019 21:28Ну тут скорее хайп порождает зп, а не наоборот. На самом деле — если компании, которая занимается разработкой, реально удается найти грамотного спеца. Который владеет не только инструментарием, но и хотя бы общий язык может со всеми участниками процесса найти. Не говорю уж о чем-то большем. Там один обычно не вывозит, даже в небольших компаниях. То такая компания получает реальное преимущество над остальными. И деньги там платятся далеко не просто так.
gecube
28.09.2019 21:25И согласен, и не согласен
Микросервисная архитектура также появилась с целью упрощения всего описанного выше — меньше взаимосвязей, проще в управлении.
Каждый элемент — возможно, что и проще, но вся сложность перекочевывает на уровень взаимодействия микросервисов. А там этих связей появляется очень много. И ими действительно сложно управлять, следить за ними. Но — это единственная возможность строить действительно сложные и масштабируемые системы
появляются различные Operations:
Остаётся приложить опрос — "какой ты ОПС (или oops)" — в духе Пикабу и пр.
Kubernetes всего лишь оркестрация, тулза которая оборачивает прямые команды драйверам сети и хостам виртуализации/изоляции в пару команд и позволяет сделать общение с ними абстрактным, вот и все.
И да, и нет. Чтобы эффективно и безопасно пользовать кубернетес нужна очень большая квалификация. Там очень много подводных камней, хотя и развернуть его действительно можно просто. Я уж не говорю, что обучить разрабов правильно писать софт под кубернетес — отдельная большая и нужная задача.
Данный соискатель на самом деле не DevOps, а такой же Системный Администратор и, чтобы быть точнее, Kubernetes Administrator.
- Это способ оправдать низкую з/п тех, кто будет админить кубернетес?
- Вообще забудьте слово "администратор". Оно вызывает неправильные ассоциации. Я уж не говорю про то, что оно существует и в других предметных областях — "администратор торгового зала", например. Говорите — инженер, техник, ну, ops, в крайнем случае.
Это конечно хорошо, когда человек может используя Terraform задеплоить AWS EKS, в связке с Fluentd сайд-каром в этом кластере и AWS ELK стеком для системы логирования за 10 минут, используя лишь одну команду в консоли, но если он не будет понимать сам принцип обработки логов и для чего они нужны, не знать как собирать метрики по ним и отслеживать деградацию сервиса, то это будет все тот же эникей, умеющий использовать некоторые утилиты.
С этим категорически согласен )
VolCh
29.09.2019 09:51А чем-то кардинально отличается написание приложения под k8s от под Docker? Я про прикладные приложения прежде всего, уонечно
gecube
29.09.2019 10:20Тут зависит от подхода. Ответ — от "не отличается никак" до "нужно полностью переписывать".
Дело в том, что докер не говорит нам как именно он будет запущен — в количестве инстансов одна штука или в распределенном режиме. А кубернетес, очевидно, сразу навязывает нам историю, что у нас распределенная система, в любой момент времени любая нода может "уйти", в любой момент времени любой под (контейнер) может быть убит. И это нужно учитывать. Конкретные примеры:
- нода кубернетеса ушла, куб это пока полностью не прочухал — поздравляю, у вас есть один инстанс приложения, который не отвечает и он не будет перезапущен, пока нода не будет помечена как совсем дохлая
- приложение запускаете как деплоймент, но оно не живет в количестве инстансов более 1 штука (ну, там миграции, хранилище какое-то с эксклюзивным доступом) — я вас поздравляю — вы только сделали возможность его запуска в Н копий. Что при этом поломается — можно только догадываться.
Кратко — если у вас стейтлесс (просто обработка данных запросов по хттп или аналогично) — проблемы скорее всего нет. Если же есть хранение данных внутри сервиса — сразу начинается боль. Или если у вас потоковая обработка данных вроде кафка, чат-бот какой-нибудь, что-то с вебсокетом — то приходится делать все аккуратно, учитывая нюансы.
С этим всем можно жить, просто не ожидайте чудес и скорректируйте свои ожидания )
VolCh
29.09.2019 12:44Ну вы больше про общие проблемы распределеных масштабируемых приложений. Тот же Докер в swarm режиме
Crevice
29.09.2019 06:04как выкатить обновление и не остаться ночевать в пятницу в офисе
Время идет, а люди по-прежнему наступают на старые грабли — выкатывают обновления в пятницу, а часто еще и в пятницу вечером.igordoge
29.09.2019 11:05+1А если продакшн обновляется сто раз за день? В пятницу надо прерывать все процессы?
Crevice
29.09.2019 12:02Если у вас отлажена непрерывная разработка и обновление продакшена, значит и все остальные процессы предусмотрены под такую работу, включая людей, которые будут разбираться с проблемами ночью и в выходные. Вышесказанное к вам не относится.
Обычные малые и средние проекты себе чаще всего такого позволить не могут. А девелоперам, работающим 8x5, в выходные дни надо отдыхать, а не баги пятничного релиза ловить.
inf
29.09.2019 09:06Работодателям — точнее формулировать требования и искать именно тех кто нужен, а не разбрасываться лейблами.
Работникам — Учиться.
Это все выводы из статьи? По-моему, что-то более очевидное сложно придумать. Наверное если работодатели сколько то на рынке, то что-то понимают в том кто им нужен и за какие деньги. Как и работники если на рынке, то понимают что нужно постоянно учиться.
beretto
29.09.2019 09:21+1Смотришь на соотношение вакансий админ/девопс, и такое ощущение, что вся ит-прослойка начала пилить свое по. Только вот где оно, свое по? Это так, для размышления.
gecube
29.09.2019 10:22Только вот где оно, свое по?
Те же свои собственные ансибл плейбуки — вроде бы их можно выложить в открытый доступ, но, во-первых, зачем — там и так своего добра полно, во-вторых, код нужно подготовить — вырезать всю специфичную для конкретной компании историю (это не только пароли-ключи). В общем, все не так все просто.
А то, что не выложены — как бы для остального мира и не существует ) и это свои особенные для данной компании велосипеды получаются.
beretto
29.09.2019 10:27Работал с одним типа «девопсом». Человек банально не знал, как в линухе настроить/поднять сетевой интерфейс и что такое подсети. Так что иногда и админы нужны… Увы и ах.
gecube
29.09.2019 11:08Может не "админы нужны", а нужен помимо CI/CD процесс постоянного совершенствования навыков (скажем, Continuous Learning — CL)? Те же админы — если не учатся в процессе работы, то очень быстро через какое-то время становятся на рынке труда неликвидами.
cccco
29.09.2019 12:39+3Хотел бы заметить, что в слове "девопс" кроме "опс" есть ещё и "дев", причём на первом месте. :)
Vaigard
29.09.2019 14:29+3Все-таки девопсы не совсем про администрирование, это подобие фулстека, который должен уметь (или хотя бы понимать), как работать со всеми технологиями (фреймворками, да просто языками) в команде/компании, и вместе с этим должен уметь наладить все процессы автоматизации и развернуть подо все это инфраструктуру. Поэтому и ценник такой, много требуют. Автор верно подметил, что требования размыты, но за этими требованиями можно ожидать, что человек реально много умеет или быстро освоит что-то новое в рамках этих требований, и сможет нести за работу всего ответственность, но пытаться заменить девопсов в нынешнем понимании системными/сетевыми админами — идея во многих случаях неудачная.
VolCh
29.09.2019 14:42Скажем так, неудачная идея попытка внедрить девопс путём переименования, по сути, админов в девопосов.
cccco
30.09.2019 11:36Вот, согласен полностью.
По-моему, ответственность — это даже в первую очередь.
Я бы сказал так, хайп поднимают исполнители, не понимающие роль руководителя.
GnuriaN
29.09.2019 23:31Всему виною деньги, деньги, —
Все зло от них, мне б век их не видать! (с) м/ф "Остров сокровищ"
Ops не может получать больше X, а DevOps может, так же как и любой другой *Ops.
axmetishe Автор
30.09.2019 09:43+1Ребята,
есть несколько проблем которые я попытался затронуть, наверное зря я их скомкал в одной статье, потому и показалось кому-то, что вопрос именно в стоимости — это не так. Кто-то усмотрел, что я вижу в этой специальности админа — тоже некорректно.
DevOps — подход/владелец процесса, позволяющий организовать Процессы разработки (Development Operations) наиболее оптимальным способом в каждой конкретной ситуации, участвуя в таких смежных дисциплинах, как разработка, тестирование, управление поставками, планирование поставок. DevOps, не важно как персона или процесс, включает в себя функции и системного администратора, ops'a кому угодно, и билд-инженера, и даже продукт-оунера, если под продуктом подразумевается процесс поставки, и еще много различных прикладных дисциплин инженерии, в том числе управление рисками.
Это понимание достаточно большого пласта аспектов процессной организации и технических реализаций и возможных ограничений.
Как и написано в статье:
«Для выполнения подобного рода работ и обязанностей данная персона должна иметь средства управления не только процессами разработки, тестирования, но и управления инфраструктурой продукта, а также планирования ресурсов. DevOps в данном понимании не может находится ни в IT, ни в R&D, ни даже в PMO, он должен иметь влияние во всех этих областях — технический директор компании, Chief Technical Officer.»
Касательно стоимости — да, человек, что способен управлять таким набором ожиданий и ограничений, назовем его DevOps, действительно может и должен стоить дорого.
Реалии же рынка таковы, что за лейблом DevOps Engineer, в действительности, часто скрываются именно системные администраторы, умеющие пользоваться теми или иными модными утилитами, зачастую не понимая их функции, назначения, возможностей.
Я собеседовал себе в команду очень большое количество «DevOps» инженеров различных грейдов и в подавляющем большинстве это были именно системные администраторы — IT operations, если угодно.
Если на стадии Junior еще можно не понимать какие-то аспекты разработки, а просто строить как видишь, руководствоваться напрямую, без осмысления, информацией от разработчиков — тоже нормально, опыт есть переосмысление ошибок прошлых, то вот на грейдах от Middle и старше это практически непозволительно.
IT Operations не просто так выставляет определенные ограничения на продуктивных средах, это тоже опыт, опыт поддержания систем в высокой доступности и некорректные действия со стороны разработчика, пусть даже по незнанию, не должны все похоронить. Так появляются регламенты, правила, к слову правило не деплоится в пятницу вечером ровно также появилось. Опыт старших грейдов персоналий участвующих в Development Operations позволяет учесть и оценить риски, возможные взаимные влияния Development и Operations, за счет чего, собственно, и достигается гибкость и скорость.
Вилки з.п. у нас достаточно широкие, я сам бился за их расширение, однако даже это не позволило набирать готовых инженеров, способных на исполнение обязанностей с минимальным обучением, их основная проблема — отсутствие именно процессных знаний, иногда даже основ.
Вакансии компаний представлены, дабы показать, что этим компаниям не нужен DevOps, наоборот, они ищут именно системных администраторов, способных покрыть ту или иную область и, если бы они точнее описали свои желания, они бы поняли, что им нужен системный администратор, способный к быстрым изменениям в инфраструктуре, читать как не закостеневший человек с политикой — «держать и не пущать».
Потому и получается например, что нам приходится брать Operations и добавлять принципы и подходы Development, также пытались в обратку, но единицам из Development интересны Operations, рассматриваются в большинстве случаев лишь как ненужные ограничения.gecube
30.09.2019 09:59Спасибо за разъяснение, но это можно было озвучить в статье, чтобы не быть неправильно истолкованным. Тем более после материала от коллег из БюроБюро — https://habr.com/ru/company/southbridge/blog/468389/#first_unread
Ну, и подскажите, что у вас за компания — посмотрим вакансии. Если боитесь огласки — можно в личку.
VolCh
30.09.2019 10:13А вы уверены, что вообще нужны отдельные DevOps люди? Что просто хороших коммуникаций и единых, скажем так, KPI между dev и ops недостаточно? У меня, как у разработчика или техлида разработчиков, вот как-то обычно с "админами" полное взаимопонимание после того как рассказываю о потребностях бизнеса, известных мне, и специфики нашего программного решения. А уж после того, как кластер настрою (логически), сделаю "скрипты" его разворачивания на новом железе и объясню его плюсы и минусы по сравнению с "деплоем по ftp" вообще, покажу как квоты задавать, масштабировать, доступы ограничивать и т. д., на руках готовы носить :)
axmetishe Автор
30.09.2019 10:31Все зависит от масштабов надо полагать. Если одна команда разработки, то скорее нет, чем да. Если таких команд с десяток, требования пересекаются, но есть уникальные моменты и эти моменты могут так или иначе повлиять на другие, то уже потребуется.
cccco
30.09.2019 12:24Согласен с комментатором ниже, что всё зависит от масштаба. Скорее всего, в Вашем случае, масштаб, как мне кажется, совсем небольшой, т.к. для меня, например, странно слышать, что разработчик "рассказывает о потребностях бизнеса" админу, как и то, что он также "настраивает кластер, заводит квоты, масштабирует, доступы ограничивает" и т.п. А кодит-то этот разработчик когда? Разработка — это же творческая работа, для написания качественного кода требующая соответствующего настроя, погружения в процесс, нахождения в определённом состоянии и т.п. Все эти вхождения, погружения, настрой требуют времени, поэтому постоянное выпадание из процесса разработки очень сильно влияет и на производительность, и на качество кода. Скажем так, "забивание гвоздей микроскопом" позволительно на небольших масштабах.
Кстати, Ваш опыт яркий пример того, что в девопс часто приходят из дева.
Gerrr
30.09.2019 13:08+1Процитирую вас. Если мы имеем дело с кросс-функциональными самоорганизованными командами, на самом деле выделение отдельной компетенции в отдельном человеке — это глупо. Если все или большинство в команде понимают, что такое девопс — это очень хорошо. Так что ситуация, которую вы описываете, намного больше девопс, чем когда целые отделы девопс спецов набирают.
Про масштабы писали в комментариях. Для работы нескольких команд есть "надстройки" над agile-фреймворками. LeSS, к примеру. Это лучшее решение, чем отдельный человек-"синхронизатор" в каком-то вопросе. Правда внедрять все это — большая работа.
cccco
30.09.2019 13:29Не пойдут на лейтенантские должности генералы. Как не крути. Либо должность должна быть генеральской, либо выращивать генерала надо самим.
stroitskiy
30.09.2019 13:34Автору спасибо за отличный обзор. Большинство статей по этой теме здесь было в стиле, хз что это такое DevOps но мы вот эти — они.
Согласен во всем, кроме разве что той части что девопс должен дебажить код и делать прочие активности связанные с работой с кодом.
Уметь — да обязан, но делать — нет. Есть владельцы этого кода, пусть они и дебажат ))) А DevOps им дебаг настраивает. Без полного понимания как это работает в коде- там делать нечего.
Опять же как сказал автор, лучшие DevOps — получается из разработчиков, а разрабы не хотят разбираться с системным администрированием. Вот здесь надо бы и обратную зависимость провести — если человек не пошел в разработчики, а пошел в сферу где сложнее и нужны знания из большего областей, значит он не хочет быть разработчиком.
Тут опять же требования могут разниться- одним достаточно у DevOps понимания что такое Garbage collector, вторым подавай глубокие знания как с ним работать. А человек работал только на проектах с .Net.
dominigato
01.10.2019 11:01+1Я вообще не понимаю при чем тут какое-то системное администрирование к процессам DevOps. Почему все заклинились на сисадминах? Если кто-то настраивал active directory в компании, так он сегодня может CI/CD pipelines создавать? Какая связь вообще?
По-моему из-за этого перекоса в сторону Operations во многих компаниях и происходит такая путаница, многие считают что DevOps это сисадмин, который теперь хочет много денег. Я вообще пришел в DevOps с QA где и занимался на самом деле DevOps когда этого слова вообще не было. Однако процессы были и раньше, и Jenkins появился давно, и CI понятие тоже. Однако это было или на QA или на Dev, но я не видел ни разу чтобы этим сисадмины занимались или кто-то из IT. Они конечно могли понимать процесс разработки — никто не запрещал, но это совершенно их не касалось и не входило в их роль абсолютно.
Мало того в некоторых компаниях даже деплойменты делали девы, а опсы выполняли роль NOC, которые максимум могли там что-то переподнять.
Сейчас гугл вроде форсит новые словечки типа SRE, который что-то вроде бывшего сисадмина, только на стероидах. Может теперь отстанут от DevOps :)
Но самый ужас это интервью на DevOps. Почти никто не знает что это такое, никто не знает что именно спрашивать то и что он должен знать. Поэтому спрашивают то что знают сами — например интервью как на разраба. Всякие там обходы деревьев, whiteboard code interview, и прочие вещи в принципе девопсам не особо нужные. Или какие-то глубоко системные вещи из мира IT, чуть ли не до рейдов и батареек в них. Ну хорошо если человек знает и про батарейки и про обходы деревьев, но нахрена??gecube
01.10.2019 11:51Они конечно могли понимать процесс разработки — никто не запрещал, но это совершенно их не касалось и не входило в их роль абсолютно.
Простой пример — сборка nginx из сорцов и опакечивание — это админская работа? Но пайплайна-то сборки и тестирования она требует!!!
dominigato
01.10.2019 12:00сборка nginx из сорцов и опакечивание — это админская работа?
В принципе нет. [1] Это работа девов, а вот его установка, мониторинг и конфиг — скорее админская работа. И бекап, и т.д.
И даже если где-то это будут делать админы с CI/CD этой сборки nginx, то как это связано с процессом разработки парсера финансовых данных в каком-нибудь финтеке? Который стоит за этим nginx. Они знают как построен процесс разработки, тестирования, изменения требований и т.д. этого парсера? Ну максимум на них могут навесить его билд, и то скорее разрабам дадут делать.
[1] В разных компаниях могут быть разные зоны ответственности и вполне админскую работу могут перевесить на девов, а девелоперскую на админов, или любая другая вариация. Но это никак не значит что если в какой-то компании А девы делают деплойменты, то значит деплойменты это работа девелоперов.gecube
01.10.2019 12:34Это работа девов, а вот его установка, мониторинг и конфиг — скорее админская работа. И бекап, и т.д.
Проблема в том, что нет. Это кусок инфраструктуры. И соответственно — он в зоне ответственности админов. Точно так же как и какое-нибудь платформенное решение типо kubernetes (rancher, okd) или hadoop, поверх которых бегут приложеньки разрабов, решающие конкретные бизнес-задачи. Да, иногда можно этот кусок отдать на сторону — использовать SaaS и managed варианты. Но иногда приходится работать с этим всем in-house.
И даже если где-то это будут делать админы с CI/CD этой сборки nginx, то как это связано с процессом разработки парсера финансовых данных в каком-нибудь финтеке?
Никак. Это два параллельных процесса.
Они знают как построен процесс разработки, тестирования, изменения требований и т.д. этого парсера?
По-разному
Ну максимум на них могут навесить его билд, и то скорее разрабам дадут делать.
А потом начнется очередное перекидывание ответственности — "это не у нас приложенька-печенька не работает, а ваша инфраструктура говно"
dominigato
02.10.2019 16:05Проблема в том, что нет. Это кусок инфраструктуры. И соответственно — он в зоне ответственности админов. Точно так же как и какое-нибудь платформенное решение типо kubernetes (rancher, okd) или hadoop, поверх которых бегут приложеньки разрабов, решающие конкретные бизнес-задачи
Это все очень зависит, скорее «серая зона». Вы игнорируете разрабов, которые разрабатывают сервисные решения. Там админы только сервера в стойки ставят, а все что касается сервисов — на совести разрабов.
Они знают как построен процесс разработки, тестирования, изменения требований и т.д. этого парсера?
Это совершенно не их компетенция.
По-разному
axmetishe Автор
01.10.2019 12:30Ну что же вы снова выдираете админов из контекста:)
Я же говорю, что в большинстве случаев к нам приходят именно админы:)
Я вообще пришел в DevOps с QA где и занимался на самом деле DevOps когда этого слова вообще не было.
И правильно. Сначала это действительно делали разработчики, либо QA-automation инженеры потому что это именно им и необходимо, затем решили высвободить их, так и появились Build engineer, которые автоматизировали то, что им скажут и в точности так, как им скажут. Затем выделились Configuration Management инженеры, были даже такие позиции — CM engineer, которые настраивали именно среды для запуска систем и Build Engineer'ы, которые отвечали за системы сборки. В энтерпрайзе так уже много лет, возможно малым командам было непозволительно содержать такой штат и появились именно подходы "you build it, you run it". И наверное как-то так и появились утилитарные ребята, что пишут код для написанного кода, стандартизируют подходы, и т.д. и т.п.
Была у нас пара попыток QA engineer взять, но одна отказалась, поскольку ей было не интересно заниматься этим, а другой не имел общего представления о SDLC, тест-кейс менеджменте и т.д.
azulen
01.10.2019 16:37+1Моя должность Teamlead DevOps. Я senior, ессно, но считаю, что реально — DevOps — просто продвинутый(и далеко :) ) админ. Но нормальных девопсов без админского опыта — в природе не существует, ибо психология там одна.
dominigato
01.10.2019 19:27Моя должность Teamlead DevOps. Я senior, ессно, но считаю, что реально — DevOps — просто продвинутый(и далеко :) ) админ.
Вот это и грустно. Даже так называемый Teamlead DevOps не знает что такое DevOps.
нормальных девопсов без админского опыта — в природе не существует
А такие стереотипы и создают путаницу как описаны в посте.azulen
01.10.2019 20:19Я не так называемый, а реальный :)
Просто называть должность именем концепции — глупо.
В одной из компаний у нас были DevOps, NetOps, MonOps и тд.
А стереотипы — не всегда плохо — их иногда называют традициями или, как в некоторых странах, скрепами :)
dikkini
Зачастую бывает так что сис админы, которые приходят, знать не знают про ci/cd, разработку и прочее, json/yml для них в диковину, ansible/docker/k8s/swarm для них не имеет значение, ведь есть lxc/vm. Зато ОС и сеть в идеале. Мат часть на уровне. И вот тут начинаются проблемы.
nad_oby
Ну так наверное это не те сисадмины, которые вам нужны.
Как только количество серверов переходит определенный порог системы управления конфигурацией оказываются незаменимы.
А если работать в компании, у которой активное R&D то все волшебные аббревиатуры, внезапно расшифровываются, и тебе все эти системы ставить и настраивать.
Когда пытаюсь объяснить людям далеким от IT чем же я таким занимаюсь использую аналогии вроде «человек-клей» и тому подобную фигню.
garageman
Не, не человек-клей. Человек который может сделать «потогонный конвеер» от разрабов до продакшена.
axmetishe Автор
На самом деле, когда приходит хороший сисадмин, в большинстве случаев, мы отдаем предпочтение именно ему, потому что его проще научить автоматизации и процессной части, нежели когда приходится учить основам человека, который знает эти утилиты, но не знает почему они и для чего они используются.