Comments 58
Это всё результат того, что на волне хайпа люди не разобравшись внедряют что-то своё, а потом называют это хайповым словом.
Девопсы — это ребята, которые про взаимодействие разработки программного обеспечения с внешней инфраструктурой.
Было бы неплохо, чтобы вы раскрыли более подробно, что имеется в виду, потому что как раз именно это все трактуют кто как хочет. Хотя вы в статье начали объяснять, но как-то очень абстрактно.
При этом, он ещё должен научить разработчиков определённым поведенческим паттернам. Т.к. с точки зрения отдельно взятого программиста, его работа по кодированию меняется не очень сильно, ему надо объяснить, о каких вещах в разработке стоит сильнее задумывать в контексте новой парадигмы, о чём стоит советоваться с коллегами-инфраструктурщиками, о каких подводных камнях заранее знать.
Эту технологическую и социальную интеграцию и обеспечивает девопс.
Получается что DevOps-инженер это фактически Системный архитектор и Team Lead/менеджер в одном лице?
Мне понятно что такое DevOps, но я нигде не могу найти первоисточник или хотя бы внятное объяснение кто такой DevOps-инженер. Это либо каждый сотрудник отделов разработки, тестирования и эксплуатации (ведь они все так или иначе используют эти инструменты и практики), либо некий руководитель, который связывает все эти отделы воедино (но это же Архитектор или Директор по ИТ).
Но все же что-то свое подразумевают: кто-то думает, что это автоматизатор, кто-то — что чувак, который шарит именно в Ansible/K8s/IasS, кто-то вообще думает что это админ, который должен программировать. В этой сфере какая-то анархия вообще.
Всё ведь просто, DevOps-инженер — это тот, кто выстраивает пайплайны.
Загадка.
Кейс: Иван Иванович посмотрел на проект и понял, что погоняв тесты, можно создать автоматически новый тег и начать сборку боевого пакета с отправкой его пользователям. Он заводит задачу на создание в gitlab ci новой job'ы, которая будет запускаться после успешных тестов и назначает на Семёна Семёновича. Тот успешно её делает и отправляет MR на своего Team Lead'а Сергея Сергеевича, который принимает этот MR в мастер-ветку.
Вопрос: кто здесь DevOps-инженер?
Человек который хорошо понимает процесс разработки, доставки и тестирование в компании (или DO lead/manager кто может быстро его понять).
Человек которому интереснее делать хорошо команде, чем писать крутой HL сервис
Человек которому интересно всего понемногу (full-stack разработчик) — которого демотивирует нудятина в бакенд отделе HL проекта или битва с очередным фреймворком в отделе фронтенда.
Человек который любит автоматизировать, а не разрабатывать «умную корзину»
Который иногда любит пошарить на сервере в конфигурационных файликах и почувствовать себя хакером из кино.
Т.е. получается все остальные не делают хорошо для команды? То что вы написали очень похоже на отдел по автоматизации.
Вообще у нас постоянная команда 4 человека +несколько удаленщиков для некоторых проектов.
Но у нас все DevOps (как я понимаю, всё как код включает и сотрудников). У нас все делают хорошо для команды, но по разному. Вот Рома, например, делает так чтобы фичи как можно быстрее попадали в GUI (https://habr.com/ru/post/456146/), а ещё один парень занимается тем, чтобы эти фичи могли быть как можно быстрее сделаны. Есть и тот, кто делает, чтобы мы могли управлять инфраструктурой этой через кнопку "Сделать хорошо" из Gitlab'а.
Каждый занимается и внедрением самих фич, но в рамках своей компетенции (front-, backend, сборка и установка). Мы придерживаемся Bus Factor, чтобы команда как можно дольше могла работать без одного из членов и быстро подхватить то, что было недоделано. Релиз-менеджер у нас тот, кто может апрувить мердж в мастер-ветку.
Мне сложно сказать кто у нас DevOps-инженер — наверное все.
В не больших командах оно так. А теперь представьте что таких команд 2-3 и у каждого есть желание имплементировать кнопку так как хочет он используя какой то набор инструментов предпочтительных ему. В итоге вы получаете зоопарк инструментов технологий и напряжёнка в команде, ведь Вася из отдела Х почемуто может имеет большую свободу чем Петя из отдела Y
А в маленьких командах, получается, Вася и Петя всегда равноправны по умолчанию?
Проблема, которую вы описали, не в размере. Проблема в том, что кто-то этим размером не умеет пользоваться: нет коммуникации и адекватного централизованного управления. Когда мы говорим о DevOps, то мы говорим о принципиальном подходе к разработке, тестированию и эксплуатации где "все как код" и "все как сервис". В старых подходах есть для каждого продукта своя команда и там каждый делает как удобно ему. В DevOps лучше всего когда есть "облако ресурсов" и оттуда берутся силы для проекта. Таким образом есть минимальная команда (они же "Совет", который решает как это всё должно реализовываться), а есть "подключаемые ресурсы" (это могут быть удаленщики или просто резервная группа для только для непосредственного решения четко описанных задач).
У нас была команда где каждый творил что хотел и как хотел — это был ужас. Но я очень много вдохновлялся командой Gitlab и в целом Open Source сообществом и это очень оживило процесс разработки.
В старых подходах есть для каждого продукта своя команда и там каждый делает как удобно ему.
Так в "новом" подходе все то же самое. Только вот уже получается, что в команде должны быть представлены все компетенции (от DBA до девопса). Причем на высоком уровне. Иначе не работает.
Вы про реальную практику внедрения? Тогда соглашусь — именно так и делают. Иногда DevOps "натягивают" на что угодно, но в итоге ЭТО невозможно даже причислить к DevOps практикам.
Как вы сказали, если команды разделены, то там должны быть все, но это ж форменный беспредел и неразумный расход ресурсов.
Я согласен с вами в другом комменте, что речь в статье про "единорожку", которой быть не может. Просто если сводить используемый термин только к инструментам оркестровки и мониторинга, то это всё равно что слону отрезать "второй" хобот, повесить на шею и говорить, что носишь слона: так-то да, но по факту что-то другое. А говоря про DevOps-инженера многие именно менеджера по оркестровке и имеют в виду, хотя это всего лишь инженер автоматизации.
Да. Могу только добавить, что единый пул ресурсов не всегда ведёт к экономии средств. Потому что есть разные задачи и их эффективнее каждую решать наиболее подходящим для этого способом. Иначе это напоминает попытку использовать единый инструмент для всего, что есть порочная практика. Т.е. нужен некий баланс между унификацией и "у каждого свой огород".
К сожалению, это обычно приводит к борьбе между отделами, т.к. у всех свои цели и свои kpi.
Простой пример. Если есть в компании некое платформенное решение (скажем, oracle или хадуп), то внедрить другое такое же решение, которое будет эффективно решать проблемы какого-то продукта (пускай он лучше будет лететь на монге и s3, соответственно) — от сложно до почти невозможно. Экономия? Эффективность? Нет, не слышал.
В случае же настоящего стартапа даётся карт-бланш, что позволяет быстро вносить изменения. И это является необходимым условием существования стартапа, иначе он очень быстро загнётся. Энтерпрайз же живёт в другой парадигме — максимального сохранения статус-кво.
Не понимаю проблемы.
Смотрите. Если мы придерживаемся продуктового подхода, то, да, действительно каждая команда вправе выбирать каким тулингом пользоваться. И какими средствами решать задачу бизнеса в рамках, первую очередь, бюджета. Действительно, нет двух абсолютно одинаковых команд и двух абсолютно одинаковых продуктов. Но если мы рассматриваем ситуацию крупного энтерпрайза, который может себе позволить штат архитекторов, менеджеров, безопасников, админов и пр… Ну, там действительно возможна централизация инструментария и предоставление инфры командам как сервиса. Но в этом случае душатся все начинания девопса и эджайла. Универсальной формулы как "сделать все эффективно" пока не изобрели. Вот и ходим кругами и называем явления и вещи неподходящими терминами.
В итоге вы получаете зоопарк инструментов технологий и напряжёнка в команде, ведь Вася из отдела Х почемуто может имеет большую свободу чем Петя из отдела Y
Почему вдруг Вася из отдела Х пересекается с Петей из отдела У. Суть разбивки по отделам какая? По функциональностям или всё-таки по продуктам?
То бишь билд инженер?
Дьявол в том, что Девопс инженера нет. Это такой единорог. Мифический зверь. Который нужен всем. Фактически же это история как с врачами. Никто не будет заставлять нейрохирурга лечить простату. С Девопс инженером фактически такая же ситуация. Это может быть билд инженер, разработчик софта, инженер по мониторингу и пр. И в чем разница между "разработчик инфраструктуры" и "администратор инфраструктуры"? Только лишь в том, что первый ее развивает, а второй только поддерживает?
Поэтому, мое мнение, статья вредная. Ибо называет вещи не своими именами.
Но м разумное зерно тоже есть, т.к. недостаточно присовокупить админа к разрабам и надеяться, что внезапно будет все хорошо
Стали распространяться компьютеры, для них появились администраторы. Они ползали по полу, протягивая кабели и вставляя в слоты диски с Windows.
Компьютеров стало больше. Выяснилось что специалисты кладут кабели и вставляют диски лучше. Их стали называть PC–техниками.
Компьютеров и админов под них стало очень много. Появились средства автоматизации, пайплайнов и т.д. Произошло разделение на «админов старой школы» и Девопс. (Одновременно PC–техников стали заменять на программы вроде Foreman)
Теперь стало понятно, что инфраструктура это код. Её всю можно описать в коде, и управлять как кодом, и автоматизировать вообще всю. А это уже смена парадигмы. Как разрабатывать код мы знаем, и это значит знания программирования, тесты, версии, среды разработки, проверки синтаксиса и т.д.
Сейчас всех, кто использует эти инструменты называют «ДевОпс инженеры», но одновременно идёт разделение на тех кто может программировать, и не может.
Те кто не может, в конце-концов будут скачивать и настраивать программы от тех кто может. Появятся какие-нибудь «ДевОпс техники».
Всё просто — чем меньше организация, тем больше ролей может взять на себя один человек. Может человек быть и системным администратором, и DevOps-инженером, и даже кадровиком и водителем, если компания на 5-10 человек. И если кто-то в вакансии указывает в требованиях, что ему нужен «многостаночник», то так и есть — отдельно сисадмин, и отдельно DevOps-инженер просто не будут достаточно загружены.
какая путаница?
у людей куб проде по 2+ года уже
четко по вакансии понимает контора чтото или нет
пара наводящих вопросов к команде так же все проясняет
Например, у них может быть свой препрод-сервер, куда они выкатывают все обновы и показывают заказчику. А он уже по их документации далее каким-то образом выкатывает обновления у себя на производственных серверах. Будь то новые docker-образы из хранилища или код из репозитория.
Либо же наоборот, Заказчик может захотеть никак не связываться с «цифровой» частью проекта и целиком отдать всё на откуп Разработчика.
Если речь идет про отчуждаемый сервис от остальной инфраструктуры заказчика — заказчик выделяет разработчику отдельный пул ресурсов (например группа виртуалок у облачного провайдера), развертыванием и сопровождением полностью может заниматься разработчик.
Если сервис интегрируемый и неотчуждаем от инфраструктуры заказчика — то развертывание осуществляется заказчиком, а разработчик просто не реализует этап Continuous Deployment, т.е. делает всё вплоть до поставки готового артефакта заказчику.
Если это разные команды, и Dev команда не имеет отношения к эксплуатации (Ops), то DevOps сюда не подходит
Просто найдите курс на EMC: "DevOps: What, Why, and How".
который закончился в 2016 году и даже обзорное видео уже не открывается
Ага, только ни у кого денег нет на то, чтобы они были отдельными сущностями.
Классическим администраторам работа осталась только в достаточно специфических компаниях, которые по факту продают инфраструктуру (либо настолько крупные, что сами у себя вынуждены поддерживать парочку крупных облаков). При этом в последних тоже не всё гладко с этим.
Я все же стою на позиции, что DevOps — это область, а в ней есть множество ролей, минимум их шесть:
— инфраструктурный инженер (строит платформу или работает с уже готовой, например инженер по Amazon)
— сервисный инженер (например строит сервис аналитики или балансировки нагрузки)
— разработчик со знанием DevOps подходов и 12-factor app
— инженер по автоматизированному тестированию
— релиз-менеджер (синхронизирует выкатки и бизнес)
— CTO, который умеет этим всем управлять
Выделение DevOps инженера никаких реальных проблем не решает, кроме появления козла отпущения, да и еще запутывает команды, где вышеописанные роли надо явно определять. В итоге получается такое.
Все просто! Бизнес требует CDO по цене DevOps, DevOps по цене сисадмина и сисадмина по цене аникея.
Я думаю что DevOps это роль для профессии Software Engeenear и пока не понимаю как их начали роднить с админами (не в обиду инженерам инфраструктурщикам)
Devops — это идея, из которой вышел некоторый набор практик.
Это точно не отдельный человек и не роль. Отдельные люди, которых скорее всего и ищут — это:
- Билд\релиз инженер — человек, который отвечает за сервисы сборки, релиза, деплоя, помогает выстроить процесс сбора обратной связи.
- Инженер инфраструктурных сервисов — человек, который строит удобное внутреннее\внешнее облако для запуска сервисов. Это он делает мониторинг aaS, базу aaS, сбор трейсинг-спанов aaS, что-то ещё aaS.
- Инженер по надёжности систем — человек, который радеет за то, что сервис будет работать, редко падать и быстро чиниться. Это он учит людей правильным архитектурным паттернам.
Эти роли могут быть распределены внутри команды разработки, а могут исполняться отдельными командами.
P.S. Системный администратор — это администратор какой-то\каких-то систем. Это нормально — называть сисадминами людей, один из которых рулит флотом серверов на амазоне, а второй отвечает за работоспособность двух серверов 1С-Бухгалтерия и локальной сети. Должности одинаковы, системы (а скорее всего и уровни ответственности\оплаты) — разные.
-«А на каких языках вы программируете?»
-«Эмм… не на каких, я пишу скрипты автоматизации, пайплайны CI/CD»
-«Ой вы нам не подходите, нам нужен девопс который помогает разработчикам указать что у них может быть не так в коде»
-«Лолшто??»
И так больше половины вакансий, я конечно могу сказать разрабу что у него не хватает пакета в requirements.txt по тексту ошибки питона, но если бы я хотел писать код то стал разработчиком сам.
Многим маленьким командам нужен как тут правильно сказали «многостаночник», а поскольку инфраструктуры в основном облачные то желательно девелопер, который будет еще и виртуалочки в амазоне поднимать. Ну что же, удачи этим смелым парням найти такого.
У каждого термина должно быть определение, иначе каждый вкладывает то, что он фантазирует, в итоге получаем бардак.
Становится всё просто и понятно если сказать что: DevOps — автоматизация текущих процессов.
Уметь писать pipeline'ы для CI/CD это не так много знаний, и это часто делают админы (которые в статье почему-то превратились в людей у которых компетенций таких нет). Infrastructure as code появилась задолго до слово «devops», админы давно эти практики используют. Да, в небольших компаниях ты можешь одновременно писать инфраструктурный код, выстраивать CI/CD, мониторинг, логирование, тюнить базы данных, поддерживать и дорабатывать внутренние проекты компании, внедрять kuberentes и docker, и при этом менять коллегам мышки, ползать на четвереньках, обжимать витую пару — и твоя должность будет называться системный администратор. На практике в больших компаниях этим просто будут заниматься отдельные люди (DBA, SRE, ops-инженеры, админы внутренней инфраструктуры компании, эникеи), но чем здесь заниматься будет человек с должностью «devops» не очень понятно. А непонятно, на мой взгляд, потому что это все таки процесс.
Если задача приходит в отдел разработки, они там что-то месяц делают, а потом бегут к человеку с должностью «devops» и говорят настрой нам срочно CI/CD, мониторинг, логирование этого дела — это не DevOps. Мне кажется DevOps это про тесное взаимодействие ops и dev, когда они параллельно решают задачу и быстро обмениваются информацией. А как называть людей, которые реализуют пайплайны, деплой и т.д. это уже дело десятое. Да и делать это могут люди совершенно с разными ролями, потому что как правило CI/CD касается как и разработчиков, так и людей которые отвечают за инфраструктуру, поэтому делать это скорее всего они будут вместе, а не отдельно взятый человек.
С другой стороны, мне как админу нравится слово DevOps. Говоришь что ты DevOps и получаешь больше денег.
Об админах, девопсах, бесконечной путанице и DevOps-трансформации внутри компании