Что нужно для успеха IT-компании в 2019 году? Лекторы на конфах и митапах говорят много громких и не всегда понятных нормальным людям слов. Борьба за время деплоя, микросервисы, отказ от монолита, DevOps-трансформация и много-много чего ещё. Если отбросить словесную красоту и говорить прямо и по-русски, то всё сводится к простому тезису: делайте качественный продукт, причем делайте его с комфортом для команды.
Последнее стало критически важно. Бизнес наконец-то пришел к мысли, что комфортный процесс разработки повышает продуктивность, а если все отлажено и работает как часы, то ещё и даёт некоторое пространство для маневра в критических ситуациях. Когда-то ради этого маневра некий умный человек придумал бэкапы, но индустрия развивается, и мы пришли к DevOps-инженерам — людям, которые превращают процесс взаимодействия разработки и внешней инфраструктуры во что-то адекватное и не связанное с шаманизмом.
Вся эта история от «по модулю» прекрасна, но… Так получилось, что часть админов резко окрестили в DevOps, а от самих DevOps-инженеров стали требовать, как минимум, навыков телепатии и ясновидения.
Прежде чем говорить о современных проблемах обеспечения инфраструктуры, давайте определимся, что мы под этим термином подразумеваем. К текущему моменту ситуация сложилась таким образом, что мы вышли на двойственность этого понятия: инфраструктура может быть условно внешней и условно внутренней.
Под внешней инфраструктурой стоит подразумевать всё то, что обеспечивает работоспособность сервиса или продукта, разработкой которой занимается команда. Это серверы приложения или сайта, хостинг и прочие сервисы, обеспечивающие работоспособность продукта.
Внутренняя инфраструктура включает в себя сервисы и оборудование, которыми пользуется сама команда разработки и прочие сотрудники, коих обычно тоже немало. Это внутренние серверы систем хранения кода, локально развернутый таск-менеджер и всё-всё-всё, что существует в рамках корпоративного интранета.
Чем же занимается в компании системный администратор? Кроме работы по администрированию этого самого корпоративного интранета, на нем частенько лежит груз хозяйственных забот по обеспечению работоспособности офисного оборудования. Админ — это тот самый парень, который быстро притащит из подсобки новый системник или готовый к работе запасной ноутбук, выдаст свежую клавиатуру и будет ползать на четвереньках по кабинетам, протягивая Ethernet-кабель. Админ — это локальный хозяин и повелитель не только внутренних и внешних серверов, но еще и хозяйственник. Да, некоторые администраторы могут работать только в системной плоскости, без железа. Их стоит выделить в отдельный подкласс «инфраструктурных системных администраторов». А кто-то специализируется на обслуживании исключительно офисного оборудования, благо, если компания насчитывает больше сотни человек, работа не кончается никогда. Но ни те, ни другие девопсами не являются.
А кто такие DevOps? Девопсы — это ребята, которые про взаимодействие разработки программного обеспечения с внешней инфраструктурой. Точнее, современные девопсы вовлечены в процессы разработки и деплоя намного глубже, нежели были когда-либо вовлечены админы, просто заливавшие апдейты на ftp. Одна из ключевых задач DevOps-инженера сейчас — это обеспечение комфортного и эффективно выстроенного процесса взаимодействия команд разработки и инфраструктуры продукта. Именно эти люди ответственны за развёртывание систем откатов и деплоя, именно эти люди снимают часть нагрузки с девелоперов и максимально концентрируются на своей крайне важной задаче. При этом девопс никогда не будет протягивать новый кабель или выдавать новый ноутбук из подсобки (с) КО
В чём подвох?
На вопрос «А кто такой DevOps?» половина работников сферы начинает отвечать что-то вроде «Ну, это, короче, такой админ, который…» и далее по тексту. Да, когда-то давно, когда профессия DevOps-инженера только-только выпочковывалась из самых талантливых в плане обслуживания сервисов админов, различия между ними были не всем очевидны. Но сейчас, когда функции девопса и админа в команде стали радикально различаться, путать их между собой, а то и вовсе ставить между ними знак равенства — недопустимо.
Но во что это выливается для бизнеса?
Найм, всё дело в нем.
Вы открываете вакансию «Системный администратор», а там перечислены требования «взаимодействие с разработкой и заказчиками», «система доставки CI/CD», «обслуживание серверов и оборудования компании», «администрирование внутренних систем» и так далее; вы понимаете, что наниматель несет какую-то чушь. Подвох в том, что вместо «Системный администратор» в заголовке вакансии должно стоять «DevOps-инженер», и если этот заголовок поменять, то все становится на свои места.
Однако какое впечатление создается при прочтении такой вакансии? Что компания ищет многостаночника, который и систему контроля версий и мониторинга развернет, и витуху обожмет зубами…
А ведь для того, чтобы не повышать градус наркомании на рынке труда, достаточно называть вакансии своими именами и чётко понимать, что DevOps-инженер и системный администратор — это две разные сущности. Вот только неуёмное желание некоторых работодателей предъявить к кандидату как можно более широкий список требований приводит к тому, что «классические» системные администраторы перестают понимать, что происходит вокруг них. Что, профессия мутирует и они отстали от жизни?
Нет, нет и ещё раз нет. Инфраструктурные админы, которые будут рулить внутренними серверами компании, или занимать позиции L2/L3-саппорта и помогать другим сотрудникам, никуда не делись и деваться не собираются.
А могут ли эти специалисты стать DevOps-инженерами? Конечно, могут. По факту, это родственная им среда, которая требует навыков системного администрирования, но помимо этого, добавляется работа с мониторингом, системами доставки и, в целом, плотное взаимодействие с командой разработки и тестирования.
Еще одна проблема DevOps
На самом деле, только наймом и постоянной путаницей между админами и девопсами всё не ограничивается. В какой-то момент бизнес столкнулся с проблемой доставки обновлений и взаимодействия команды разработки с конечной инфраструктурой.
Возможно, это было тогда, когда на сцену какой-то конференции поднялся дядя с горящими глазами и сказал «А мы делаем вот так и называем это DevOps. Эти ребята решат все ваши проблемы» — и начал рассказывать, как хорошо живется в компании после внедрения DevOps-практик.
Однако недостаточно нанять DevOps-инженера для того, чтобы все стало работать «как надо». Компания должна целиком пройти DevOps-трансформацию, то есть роль и возможности нашего девопса должны четко осознавать ещё и на стороне команды разработки и тестирования продукта. На эту тему у нас есть «прекрасная» история, которая в полной мере иллюстрирует всю происходящую местами жесть.
Ситуация. От девопса требуют развернуть систему отката версий, особо не вникая, как она будет работать. Предположим, внутри системы Users — это отдельные поля под имя, фамилию и пароль. Выходит новая версия продукта, но для разработчиков «откат» — это просто волшебная палочка, которая всё починит, и они даже не представляют, как она работает. Так вот, к примеру, разработчики в очередном патче объединили поля имени и фамилии, выкатили это в прод, а версия тормозит по каким-то причинам. Что происходит? Руководство приходит к девопсу и говорит «Дёргай рубильник!», то есть просит его откатиться на предыдущую версию. Что делает девопс? Он откатывается на предыдущую версию, но так как разработчики не захотели разбираться, как делается этот откат, то никто девопсу не сказал, что откатить нужно еще и базу. В итоге у нас падает вообще всё, и пользователи вместо тормозящего сайта видят ошибку «500», потому что старая версия не работает с полями новой базы. Девопс об этом не в курсе. Разрабы молчат. Руководство начинает терять нервы и деньги и вспоминает о бэкапах, предлагая откатиться с них, чтобы «хоть что-нибудь да работало». В результате пользователи теряют все свои данные за какой-то промежуток времени.
На орехи достается, конечно же, девопсу, который «не сделал правильную систему отката», а то что лоси в этой истории — разработчики, никого не волнует.
Вывод простой: без нормального подхода к DevOps как таковому толку от него не очень много.
Главное, что нужно помнить: DevOps-инженер — не волшебник, и без качественных коммуникаций и двустороннего взаимодействия с разработкой он не будет справляться со своими задачами. Девопсов нельзя оставить один на один с их «проблемами» или дать команду «не лезь к разрабам, их дело кодить», а потом надеяться, что в критический момент всё будет работать, как надо. Так это не работает.
По сути, DevOps — это компетенции на грани между менеджментом и технологиями. Причём, далеко не очевидно, что в этом коктейле технологий должно быть больше, чем менеджмента. Если вы действительно хотите построить более быстрые и эффективные процессы разработки, вы должны доверять своему девопсу. Он знает нужные инструменты, он реализовывал подобные проекты, он знает, как делать. Помогите ему, прислушайтесь к его советам, не пытайтесь изолировать в какое-то автономное подразделение. Если админы могут работать сами по себе, то девопсы в таком случае бесполезны, они не смогут помочь вам стать лучше, если вы сами не захотите эту помощь принять.
Ну и последнее: хватит обижать администраторов-инфраструктурщиков. У них свой, крайне важный фронт работ. Да, админ может стать DevOps-инженером, но это должно происходить по желанию самого человека, а не из-под палки. И нет ничего плохого в том, что системный администратор хочет остаться системным администратором — это его отдельная профессия и его право. Если же есть желание пройти профессиональную трансформацию, то надо ни в коем случае не забывать, что наращивать придется не только технологические навыки, но еще и управленческие. Всех этих людей сводить вместе и учить общаться на одном языке, скорее всего, придется именно вам как руководителю.
Комментарии (47)
GritsanY
09.08.2019 10:51Напридумывают терминов и обмазываются. Примерно такие же пространные обсуждения были, когда придумали термин «облако».
Всё просто — чем меньше организация, тем больше ролей может взять на себя один человек. Может человек быть и системным администратором, и DevOps-инженером, и даже кадровиком и водителем, если компания на 5-10 человек. И если кто-то в вакансии указывает в требованиях, что ему нужен «многостаночник», то так и есть — отдельно сисадмин, и отдельно DevOps-инженер просто не будут достаточно загружены.
aakhamef
09.08.2019 11:30А зачем компании 5-10 человек DevOps-инженер и админ?
nikweter
09.08.2019 11:59+1Ну вот у нас 3 программиста, 1 тестировшик и я — он же админ, он же девопс, и тд и тп. Правда я на удаленке, потому что незагружен. Но и без меня никак — локальную серверную ферму и кучу вдс кто-то же должен администрировать.
Lehas
09.08.2019 12:05+1какая путаница?
у людей куб проде по 2+ года уже
четко по вакансии понимает контора чтото или нет
пара наводящих вопросов к команде так же все проясняет
4umak
09.08.2019 13:11Ну тут скорее про то, что классический админ-инфраструктурщик может придти на такую вакансию, точно не знать, какие правильные наводящие вопросы задать и попасть не совсем туда, куда он хотел бы. Собственно, для небольшого ликбеза этот материал и написан.
gecube
10.08.2019 23:52классический админ-инфраструктурщик
Не придет, не принимайте его за дурачка.
А если и придет, то будет понимать зачем (например, лычка Девопс даёт +30% к з/п) и какой ценой для него это дастся.
testopatolog
09.08.2019 12:29+1Ситуация:
Есть Разработчик и Заказчик (разные компании), у каждого есть отделы админов (спецы с соответствующими ролями), поддерживающих в работоспособном состоянии it-инфраструктуры (вы их в статье называете внутренней — разработки и внешней — типа заказчика).
У Заказчика есть чёткое понимание рисков, связанных с обеспечением безопасности и владением полного спектра компетенций в рамках эксплуатируемого ПО в своей инфраструктуре.
Вопрос:
Я правильно Вас понимаю, что DevOps-инженер из команды Разработки хозяйничает (накатывает/проверяет/откатывает/тюнингует системное и прикладное ПО, занимается устранением последствий аварий/сбоев, ...) в инфраструктуре Заказчика?4umak
09.08.2019 13:14Очень интересный вопрос! Не уверен, что на него есть единый правильный ответ. Мне кажется, тут всё решается «на земле», в конкретном случае. Разработчики могут быть и изолированы от инфраструктуры Заказчика.
Например, у них может быть свой препрод-сервер, куда они выкатывают все обновы и показывают заказчику. А он уже по их документации далее каким-то образом выкатывает обновления у себя на производственных серверах. Будь то новые docker-образы из хранилища или код из репозитория.
Либо же наоборот, Заказчик может захотеть никак не связываться с «цифровой» частью проекта и целиком отдать всё на откуп Разработчика.
fessmage
09.08.2019 13:18+1Если речь идет про отчуждаемый сервис от остальной инфраструктуры заказчика — заказчик выделяет разработчику отдельный пул ресурсов (например группа виртуалок у облачного провайдера), развертыванием и сопровождением полностью может заниматься разработчик.
Если сервис интегрируемый и неотчуждаем от инфраструктуры заказчика — то развертывание осуществляется заказчиком, а разработчик просто не реализует этап Continuous Deployment, т.е. делает всё вплоть до поставки готового артефакта заказчику.
catharsis
09.08.2019 15:56Если это разные команды, и Dev команда не имеет отношения к эксплуатации (Ops), то DevOps сюда не подходит
gecube
10.08.2019 23:50DevOps — как вместо одной стены (dev vs ops) получить две (dev vs "devops" vs ops).
Типичный пример:
Продакшен сломался.
Разработчики — "Ты же Девопс, иди чини продакшен!!"
nomhoi
09.08.2019 13:31+1Просто найдите курс на EMC: "DevOps: What, Why, and How".
catharsis
09.08.2019 16:26Нашел только educast.emc.com/learn/devops-what-why-and-how-2016,
который закончился в 2016 году и даже обзорное видео уже не открываетсяnomhoi
10.08.2019 04:22
inkvizitor68sl
09.08.2019 15:27+1> что DevOps-инженер и системный администратор — это две разные сущности
Ага, только ни у кого денег нет на то, чтобы они были отдельными сущностями.
Классическим администраторам работа осталась только в достаточно специфических компаниях, которые по факту продают инфраструктуру (либо настолько крупные, что сами у себя вынуждены поддерживать парочку крупных облаков). При этом в последних тоже не всё гладко с этим.
osminog
09.08.2019 16:25+3Коллеги, различалка «DevOps инженер — это про технологии и про менеджмент, а админ — это только про технологии» так себе и не дает ответов на многие вопросы, например а чем/кем управляет DevOps инженер, если он про менеджмент?
Я все же стою на позиции, что DevOps — это область, а в ней есть множество ролей, минимум их шесть:
— инфраструктурный инженер (строит платформу или работает с уже готовой, например инженер по Amazon)
— сервисный инженер (например строит сервис аналитики или балансировки нагрузки)
— разработчик со знанием DevOps подходов и 12-factor app
— инженер по автоматизированному тестированию
— релиз-менеджер (синхронизирует выкатки и бизнес)
— CTO, который умеет этим всем управлять
Выделение DevOps инженера никаких реальных проблем не решает, кроме появления козла отпущения, да и еще запутывает команды, где вышеописанные роли надо явно определять. В итоге получается такое.
onegreyonewhite
10.08.2019 03:01Получается, что само понятие "DevOps-инженер" лишено смысла, ведь есть конкретные понятия. Либо это некий тип very-fullstack-разработчика.
gecube
10.08.2019 23:47+1Именно! Я про это же, но с другой стороны пишу выше
Что может быть, вероятно, это менеджер по внедрению девопс-практик. Ведь есть же эджайл коучи? Но это больше не техническая должность тогда.
Andrey_Rogovsky
10.08.2019 04:23+1Все просто! Бизнес требует CDO по цене DevOps, DevOps по цене сисадмина и сисадмина по цене аникея.
valis
10.08.2019 06:43Самая большая боль рынка в том, что народ путает роли и профессии.
Я думаю что DevOps это роль для профессии Software Engeenear и пока не понимаю как их начали роднить с админами (не в обиду инженерам инфраструктурщикам)
Merkat0r
10.08.2019 10:54точно так же, как и прям в начале статьи породнили эникейщика и обычного админа
bhavenger
12.08.2019 11:16Devops — это идея, из которой вышел некоторый набор практик.
Это точно не отдельный человек и не роль. Отдельные люди, которых скорее всего и ищут — это:
- Билд\релиз инженер — человек, который отвечает за сервисы сборки, релиза, деплоя, помогает выстроить процесс сбора обратной связи.
- Инженер инфраструктурных сервисов — человек, который строит удобное внутреннее\внешнее облако для запуска сервисов. Это он делает мониторинг aaS, базу aaS, сбор трейсинг-спанов aaS, что-то ещё aaS.
- Инженер по надёжности систем — человек, который радеет за то, что сервис будет работать, редко падать и быстро чиниться. Это он учит людей правильным архитектурным паттернам.
Эти роли могут быть распределены внутри команды разработки, а могут исполняться отдельными командами.
P.S. Системный администратор — это администратор какой-то\каких-то систем. Это нормально — называть сисадминами людей, один из которых рулит флотом серверов на амазоне, а второй отвечает за работоспособность двух серверов 1С-Бухгалтерия и локальной сети. Должности одинаковы, системы (а скорее всего и уровни ответственности\оплаты) — разные.
osminog
12.08.2019 12:19Дима, нам нужно про это написать статью! Хотя конечно комментарий твой весь смысл отражает очень полно.
vsantonov
12.08.2019 16:59А бывает наоборот. На собеседовании на DevOps спрашивают
-«А на каких языках вы программируете?»
-«Эмм… не на каких, я пишу скрипты автоматизации, пайплайны CI/CD»
-«Ой вы нам не подходите, нам нужен девопс который помогает разработчикам указать что у них может быть не так в коде»
-«Лолшто??»
И так больше половины вакансий, я конечно могу сказать разрабу что у него не хватает пакета в requirements.txt по тексту ошибки питона, но если бы я хотел писать код то стал разработчиком сам.
Многим маленьким командам нужен как тут правильно сказали «многостаночник», а поскольку инфраструктуры в основном облачные то желательно девелопер, который будет еще и виртуалочки в амазоне поднимать. Ну что же, удачи этим смелым парням найти такого.
onegreyonewhite
Это всё результат того, что на волне хайпа люди не разобравшись внедряют что-то своё, а потом называют это хайповым словом.
Было бы неплохо, чтобы вы раскрыли более подробно, что имеется в виду, потому что как раз именно это все трактуют кто как хочет. Хотя вы в статье начали объяснять, но как-то очень абстрактно.
4umak
Условно говоря, девопс вырос из попытки найти крайнего за эволюцию процесса разработки продукта. В его зоне ответственности понимание современных принципов сборки и резервирования приложений, выкатки новых версий, отката на старые.
При этом, он ещё должен научить разработчиков определённым поведенческим паттернам. Т.к. с точки зрения отдельно взятого программиста, его работа по кодированию меняется не очень сильно, ему надо объяснить, о каких вещах в разработке стоит сильнее задумывать в контексте новой парадигмы, о чём стоит советоваться с коллегами-инфраструктурщиками, о каких подводных камнях заранее знать.
Эту технологическую и социальную интеграцию и обеспечивает девопс.
onegreyonewhite
Получается что DevOps-инженер это фактически Системный архитектор и Team Lead/менеджер в одном лице?
Мне понятно что такое DevOps, но я нигде не могу найти первоисточник или хотя бы внятное объяснение кто такой DevOps-инженер. Это либо каждый сотрудник отделов разработки, тестирования и эксплуатации (ведь они все так или иначе используют эти инструменты и практики), либо некий руководитель, который связывает все эти отделы воедино (но это же Архитектор или Директор по ИТ).
Но все же что-то свое подразумевают: кто-то думает, что это автоматизатор, кто-то — что чувак, который шарит именно в Ansible/K8s/IasS, кто-то вообще думает что это админ, который должен программировать. В этой сфере какая-то анархия вообще.
kvaps
Всё ведь просто, DevOps-инженер — это тот, кто выстраивает пайплайны.
onegreyonewhite
Загадка.
Кейс: Иван Иванович посмотрел на проект и понял, что погоняв тесты, можно создать автоматически новый тег и начать сборку боевого пакета с отправкой его пользователям. Он заводит задачу на создание в gitlab ci новой job'ы, которая будет запускаться после успешных тестов и назначает на Семёна Семёновича. Тот успешно её делает и отправляет MR на своего Team Lead'а Сергея Сергеевича, который принимает этот MR в мастер-ветку.
Вопрос: кто здесь DevOps-инженер?
avengerweb
onegreyonewhite ну у вас тут набор — целая ДевОпс тим! Видимо большая компания :) Нет девопс не тимлид и не менеджер, это точно такой же тайтел, который имеет своих менеджеров, лидов, джунов и тд. При том никто не говорит что девопсы не пишут код, увы не все заканчивается на пейплайнах в «Пополурная CI». Дак кто же он такой?
Человек который хорошо понимает процесс разработки, доставки и тестирование в компании (или DO lead/manager кто может быстро его понять).
Человек которому интереснее делать хорошо команде, чем писать крутой HL сервис
Человек которому интересно всего понемногу (full-stack разработчик) — которого демотивирует нудятина в бакенд отделе HL проекта или битва с очередным фреймворком в отделе фронтенда.
Человек который любит автоматизировать, а не разрабатывать «умную корзину»
Который иногда любит пошарить на сервере в конфигурационных файликах и почувствовать себя хакером из кино.
onegreyonewhite
Т.е. получается все остальные не делают хорошо для команды? То что вы написали очень похоже на отдел по автоматизации.
Вообще у нас постоянная команда 4 человека +несколько удаленщиков для некоторых проектов.
Но у нас все DevOps (как я понимаю, всё как код включает и сотрудников). У нас все делают хорошо для команды, но по разному. Вот Рома, например, делает так чтобы фичи как можно быстрее попадали в GUI (https://habr.com/ru/post/456146/), а ещё один парень занимается тем, чтобы эти фичи могли быть как можно быстрее сделаны. Есть и тот, кто делает, чтобы мы могли управлять инфраструктурой этой через кнопку "Сделать хорошо" из Gitlab'а.
Каждый занимается и внедрением самих фич, но в рамках своей компетенции (front-, backend, сборка и установка). Мы придерживаемся Bus Factor, чтобы команда как можно дольше могла работать без одного из членов и быстро подхватить то, что было недоделано. Релиз-менеджер у нас тот, кто может апрувить мердж в мастер-ветку.
Мне сложно сказать кто у нас DevOps-инженер — наверное все.
avengerweb
В не больших командах оно так. А теперь представьте что таких команд 2-3 и у каждого есть желание имплементировать кнопку так как хочет он используя какой то набор инструментов предпочтительных ему. В итоге вы получаете зоопарк инструментов технологий и напряжёнка в команде, ведь Вася из отдела Х почемуто может имеет большую свободу чем Петя из отдела Y
onegreyonewhite
А в маленьких командах, получается, Вася и Петя всегда равноправны по умолчанию?
Проблема, которую вы описали, не в размере. Проблема в том, что кто-то этим размером не умеет пользоваться: нет коммуникации и адекватного централизованного управления. Когда мы говорим о DevOps, то мы говорим о принципиальном подходе к разработке, тестированию и эксплуатации где "все как код" и "все как сервис". В старых подходах есть для каждого продукта своя команда и там каждый делает как удобно ему. В DevOps лучше всего когда есть "облако ресурсов" и оттуда берутся силы для проекта. Таким образом есть минимальная команда (они же "Совет", который решает как это всё должно реализовываться), а есть "подключаемые ресурсы" (это могут быть удаленщики или просто резервная группа для только для непосредственного решения четко описанных задач).
У нас была команда где каждый творил что хотел и как хотел — это был ужас. Но я очень много вдохновлялся командой Gitlab и в целом Open Source сообществом и это очень оживило процесс разработки.
gecube
Так в "новом" подходе все то же самое. Только вот уже получается, что в команде должны быть представлены все компетенции (от DBA до девопса). Причем на высоком уровне. Иначе не работает.
onegreyonewhite
Вы про реальную практику внедрения? Тогда соглашусь — именно так и делают. Иногда DevOps "натягивают" на что угодно, но в итоге ЭТО невозможно даже причислить к DevOps практикам.
Как вы сказали, если команды разделены, то там должны быть все, но это ж форменный беспредел и неразумный расход ресурсов.
Я согласен с вами в другом комменте, что речь в статье про "единорожку", которой быть не может. Просто если сводить используемый термин только к инструментам оркестровки и мониторинга, то это всё равно что слону отрезать "второй" хобот, повесить на шею и говорить, что носишь слона: так-то да, но по факту что-то другое. А говоря про DevOps-инженера многие именно менеджера по оркестровке и имеют в виду, хотя это всего лишь инженер автоматизации.
gecube
Да. Могу только добавить, что единый пул ресурсов не всегда ведёт к экономии средств. Потому что есть разные задачи и их эффективнее каждую решать наиболее подходящим для этого способом. Иначе это напоминает попытку использовать единый инструмент для всего, что есть порочная практика. Т.е. нужен некий баланс между унификацией и "у каждого свой огород".
К сожалению, это обычно приводит к борьбе между отделами, т.к. у всех свои цели и свои kpi.
Простой пример. Если есть в компании некое платформенное решение (скажем, oracle или хадуп), то внедрить другое такое же решение, которое будет эффективно решать проблемы какого-то продукта (пускай он лучше будет лететь на монге и s3, соответственно) — от сложно до почти невозможно. Экономия? Эффективность? Нет, не слышал.
В случае же настоящего стартапа даётся карт-бланш, что позволяет быстро вносить изменения. И это является необходимым условием существования стартапа, иначе он очень быстро загнётся. Энтерпрайз же живёт в другой парадигме — максимального сохранения статус-кво.
gecube
Не понимаю проблемы.
Смотрите. Если мы придерживаемся продуктового подхода, то, да, действительно каждая команда вправе выбирать каким тулингом пользоваться. И какими средствами решать задачу бизнеса в рамках, первую очередь, бюджета. Действительно, нет двух абсолютно одинаковых команд и двух абсолютно одинаковых продуктов. Но если мы рассматриваем ситуацию крупного энтерпрайза, который может себе позволить штат архитекторов, менеджеров, безопасников, админов и пр… Ну, там действительно возможна централизация инструментария и предоставление инфры командам как сервиса. Но в этом случае душатся все начинания девопса и эджайла. Универсальной формулы как "сделать все эффективно" пока не изобрели. Вот и ходим кругами и называем явления и вещи неподходящими терминами.
Почему вдруг Вася из отдела Х пересекается с Петей из отдела У. Суть разбивки по отделам какая? По функциональностям или всё-таки по продуктам?
gecube
То бишь билд инженер?
Дьявол в том, что Девопс инженера нет. Это такой единорог. Мифический зверь. Который нужен всем. Фактически же это история как с врачами. Никто не будет заставлять нейрохирурга лечить простату. С Девопс инженером фактически такая же ситуация. Это может быть билд инженер, разработчик софта, инженер по мониторингу и пр. И в чем разница между "разработчик инфраструктуры" и "администратор инфраструктуры"? Только лишь в том, что первый ее развивает, а второй только поддерживает?
Поэтому, мое мнение, статья вредная. Ибо называет вещи не своими именами.
Но м разумное зерно тоже есть, т.к. недостаточно присовокупить админа к разрабам и надеяться, что внезапно будет все хорошо
kvaps
Называйте как хотите — но если, допустим, вы являетесь разработчиком софта и самостоятельно настраиваете пайплайн, то есть настраиваете development operations, а соответственно от части вы являетесь DevOps-инженером)
gecube
Повторюсь. Я строго против наименования DevOps инженер. Оно затуманивает смысл.
Если же в примере разраб настраивает пайплайн, то он настраивает пайплайн. Не больше и не меньше.
ppl2scripts
Исторически примерно так:
Стали распространяться компьютеры, для них появились администраторы. Они ползали по полу, протягивая кабели и вставляя в слоты диски с Windows.
Компьютеров стало больше. Выяснилось что специалисты кладут кабели и вставляют диски лучше. Их стали называть PC–техниками.
Компьютеров и админов под них стало очень много. Появились средства автоматизации, пайплайнов и т.д. Произошло разделение на «админов старой школы» и Девопс. (Одновременно PC–техников стали заменять на программы вроде Foreman)
Теперь стало понятно, что инфраструктура это код. Её всю можно описать в коде, и управлять как кодом, и автоматизировать вообще всю. А это уже смена парадигмы. Как разрабатывать код мы знаем, и это значит знания программирования, тесты, версии, среды разработки, проверки синтаксиса и т.д.
Сейчас всех, кто использует эти инструменты называют «ДевОпс инженеры», но одновременно идёт разделение на тех кто может программировать, и не может.
Те кто не может, в конце-концов будут скачивать и настраивать программы от тех кто может. Появятся какие-нибудь «ДевОпс техники».
Sergey-S-Kovalev
ppl2scripts
Кабели отдали на аутсорс специализированным компаниям ;)