Эта статья о вреде выделенных команд DevOps инженеров в организации. Начну издалека. В книге Джорджа Массера "Нелокальность" приводится такой интересный момент оценки расстояния с точки зрения влияния. "Лев близко, значит он может напасть" - это о влиянии через определение пространства. Однако концепция "Лев может напасть, значит он близко" - нивелирует саму концепцию пространства. Так и альтернативный взгляд на DevOps может переопределить само понимание об его месте в производственном процессе. К сожалению, в сфере DevOps все скатывается в набор ритуалов и надутые щеки DevOps методологов-футурологов-идеологов и много чего. Речь разумеется не идет про лидеров индустрии, речь идет скорее про среднестатистические компании на рынке. Давайте перевернем все с головы на ноги!
Темна вода в облацех...
Пойдем по пути аналогий - если мы правильные инженеры, то нам нет особой разницы какое производство организовывать. Допустим у нас есть производство обычных водопроводных кранов, и есть конечный потребитель, желающий понежиться в ванной по утрам. Где у нас здесь DevOps-инженер? А вот он - тот самый дядя Вася из ЖЭС. И весь производственный цикл заточен в том числе и под то, чтобы дядя Вася пришел, взял стандартизированный инструмент, и прикрутил этот кран к стандартным трубам по стандартной процедуре. Улавливаете мысль? DevOps это пусконаладка. Мы не можем преуменьшать важность любой составляющей жизненного цикла продукта - потому что нам важны все они, но в первую очередь для нас важен конечный потребитель, тот самый хозяин квартиры. С этой точки зрения важен не дядя Вася, а непрерывная связь между производителем и потребителем, звеном которого он является. Никакой особенной DevOps трансформации или культуры нет - кроме важности понимания непрерывности цикла производства. Вроде бы очевидная вещь. Но нет лучше способа прослыть мудрецом, чем говорить очевидные вещи - "вода мокрая", "снег холодный", "программы пишутся для конечного потребителя".
DevOps инженеры занимаются самым сложным
Правда состоит в том, что эта сложность в большинстве своем шаблонная (пресловутые best practices). Она не имеет отношения к сложности продукта, она относится к сложности инфраструктурной и технологической зрелости. Если взять набор компаний примерно одинакового размера из одного домена, то окажется, что с некоторыми вариациями технологии и подходы в них совпадают. Часто DevOps инженеры подобны муравьям - без всякой осознанности они выстраивают одни и те же термитники согласно заложенной в их ДНК программе независимо от продукта. Поэтому DevOps часто не культура, а целая религия - со своими шаманами и ритуалами. Возьмите среднестатистического DevOps инженера и потыкайте палочкой - из него посыпятся Docker, Terraform и Kubernetes. Даже если это приложение, состоящее из одного HTTP эндпойнта. Правда в том, что в большинстве случаев сложность вообще не нужна - можно сделать просто и быстро, либо сильно преувеличена - и такой подход пропагандируется самими разработчиками по принципу "у меня лапки".
DevOps инженеры занимаются самым важным
Важность эта опять же возникает из того, что DevOps инженеры в любой компании являются блокером, причем практически в любой активности. Вместо того чтобы обеспечить гибкость в доставке и внедрении новых технологий, они эту самую доставку присваивают, а поскольку их как обычно не хватает - то стремятся в целях сохранения status quo свести опять же все к шаблонам. Иначе все к чертям развалится. Вот и получается, что вместо того чтобы способствовать гибкости конфигурации продукта, выделенная DevOps команда замыкает этот продукт в рамках своего технологического стека. Важность DevOps инженера по сути сводится к важности вахтера - без него вы внутрь здания не попадете. Но кто сказал, что он вообще нужен?
Если все так плохо - почему все продолжают есть кактус?
Прочитайте определение DevOps из вики
Методология активного взаимодействия специалистов по разработке со специалистами по информационно-технологическому обслуживанию и взаимная интеграция их рабочих процессов друг в друга для обеспечения качества продукта.
Вашу ж мать! Где здесь DevOps- инженеры? Ирония заключается в том, что попытка автоматизировать и упростить рабочие процессы нас приводит к тому, что мы помещаем людей прямо на пути изменения конфигурации продукта. Нам нужно проверить миллионы продуктовых гипотез - а у нас тут люди. Сколько DevOps инженеров нужно на одного разработчика? А вот нет такого соотношения. Мы формируем бэклог, считаем эстимейты, делаем архитектуру - а в середине упираемся в ограничения, причем в ограничения с головой загруженной группы специалистов, которых слишком много, чтобы ничего не делать, но слишком мало, чтобы удовлетворить все запросы. А ответ простой - на каждого разработчика нужен ровно один DevOps инженер. Как? А так, каждый разработчик является ответственным за доставку тех изменений в продукте, которые он вносит. Продолжая аналогию с дядей Васей - сделал кран - сходи сам его поставь. А дальше напиши "повторить так еще 10000 раз". Но на практике оказывается, что позволить сейчас себе подобный подход могут лишь несколько лидеров индустрии. В чем дело? В людях или в технологиях?
Если говорить о технологиях, то тот же Kubernetes, облачные провайдеры и тп не представляют никакой особой технологической сложности. Держу пари, что досконально изучить все особенности работы какой-нибудь postgresql куда сложнее, чем концепт работы с k8s. Ситуация сильно колеблется - в условиях дефицита специалистов с разработчика спрос минимален - код хотя бы писать мог, а на остальное наймем DevOps инженера, ведь все DevOps инженеры делают одно и то же.
Выход где?
Выхода нет. Потому что нет пресловутой инженерной культуры. Однако можно хотя бы начать с того, чтобы организационно убрать из структуры предприятия выделенные DevOps команды. Помните про Конвея? Выделенная DevOps команда всегда будет строить свой продукт внутри вашего. Нужен ли вам DevOps? Ну конечно да, как набор практик, которые пронизывают весь ваш цикл производства.
UPD. Под выделенной командой я понимаю организационное звено, которое само по себе осуществляет все процессы доставки продукта, неся отвественность исключительно за эту доставку. В комментариях много непонимания, но в целом если команда/человек DevOps разделяет ответственность доставки вместе с командой разработчиков, представляя собой единую структурную единицу, ничего против я не имею.
UPD. Проблемы, на которых я фокусируюсь, две 1) это разделение ответственности за доставку продукта между орг-единицами, из которых одна разрабатывает, но не ответственна за доставку и эксплуатацию, а вторая отвечает исключительно за доставку, всецело наплевав на все остальное. "Такой devops нам не нужен"(с). 2) Это ограничение технологического стека - потому что мы вынуждены весь стек подгонять под компетенции каждого звена в цепочке.
Проблема решается просто - когда вне зависимости от компетенций все отвечают за доставку от старта разработки до запуска в эксплуатацию и саму эксплуатацию. Общая ответственность подразумевает общую организационную структуру. Практики использования DevOps должны жить в команде разработки.
Комментарии (109)
Ulys-ses
01.11.2021 13:12+5Прочитайте определение DevOps из вики
Методология активного взаимодействия специалистов по разработке со специалистами по информационно-технологическому обслуживанию и взаимная интеграция их рабочих процессов друг в друга для обеспечения качества продукта.
Вашу ж мать! Где здесь DevOps- инженеры?
А кто будет выстраивать методологию?
В истории с кранами DevOps-инженер - это не дядя Вася из ЖЭКа, а человек, придумавший сетку стандартных размеров труб и кранов.
random1st Автор
01.11.2021 13:17-1Тут нет человека. Тут есть культура стандартизации, понимаете? Не сетка размеров, а сам подход
Ulys-ses
01.11.2021 13:44Но кто-то же должен придумать сетку. Конкретные размеры. Тут без человека пока не обойтись.
random1st Автор
01.11.2021 13:55+3без человека можно, нельзя без подхода. Если в производственный цикл заложено, что при создании нового размера вы должны внести его в стандарт по определенной процедуре - это и есть культура использования стандарта. Сетка размеров сама по себе возникнет и даже будет развиваться - если только принять как требование что мы не запускаем в производство не стандартизированную продукцию. В случае с DevOps мы тоже должны учитывать определенные требования к эксплуатации на этапе разработки. Нам как разработчикам не нужен получеловек-полудевопс, который будет эти требования воплощать за нас.
Ulys-ses
01.11.2021 14:19+1без человека можно, нельзя без подхода. Если в производственный цикл заложено...
Откуда подход возьмется? Кем заложено? Не человеком?
Сетка размеров сама по себе возникнет...
И будут у нас размеры 5.51, 5.52, 7.(3) - просто потому, что кому-то захотелось их внести.
random1st Автор
01.11.2021 14:21ну мы например используем дифференциальные уравнения при расчетах - нам нужен математик в штате? Или математическое образование aka культура у исполнителей?
Ulys-ses
01.11.2021 14:25+2Если вам хватает методов, разработанных другими математиками - нет. Если существующие методы не подходят - да.
Исполнителя, умеющего решать дифуры, вряд ли кто-то назовет гуманитарием.
random1st Автор
01.11.2021 14:35+2если вам в массовом производстве - а я веду речь именно о нем - не хватает математики, то математика должна быть частью инженерной культуры. За МЛ мы сейчас не ходим в университеты - у нас есть технологии. Но кроме технологий должны быть знания в головах тех, кто эти технологии использует - и это и есть культура инженера. Раньше если я занимался производством или обслуживанием аппаратуры я должен был понимать как она функционирует. А сейчас процветает не культура, а культы - подобные культу карго. И здесь ничего не решает наличие выделенного "шамана" - девопса.
Ulys-ses
01.11.2021 14:47+1Раньше если я занимался производством или обслуживанием аппаратуры я должен был понимать как она функционирует. А сейчас процветает не культура, а культы
Так это потому, что сейчас этим не инженеры занимаются. Когда-то и для управления автомобилем надо было знать его устройство. Сейчас техника продвинулась настолько, что большинству это просто не нужно.
И здесь ничего не решает наличие выделенного "шамана" - девопса.
Если девопс действует на уровне шамана, может, не стоит его называть инженером? Может, он и не devops вовсе, а простой внедренец? Тот самый "специалист по информационно-технологическому обслуживанию"?
random1st Автор
01.11.2021 15:11девопс-инженер будет действовать на уровне шамана, поскольку в описанной ситуации работает в рамках шаблонов. Неосознанно и без разделения интересов участников проекта. Практики девопса может воплощать один человек, два человека и тп - но они должен быть частью команды разработки, а не выделенной организационной единицы.
Ulys-ses
01.11.2021 16:18+3Еще раз: тот, кто действует ТОЛЬКО в рамках шаблонов - не инженер, а техник, в лучшем случае. Такой человек, действительно, нужен только в очень редких случаях - когда не работают механизмы коммуникации.
Но это не работа девопса.
random1st Автор
01.11.2021 16:23нет никакой работы девопса. Есть только необходимость доставлять изменения ПО в эксплуатацию и связанные с этим практики. Статья о том, что доставка должна быть частью инженерной культуры разработчиков, а не выделенной команды или человека.
random1st Автор
01.11.2021 16:34у меня есть стойкое впечатление, что я просто вторгаюсь в ваш уютный мирок того самого инженера - DevOps'а? :)
Ulys-ses
01.11.2021 17:05+1Статья о том, что доставка должна быть частью инженерной культуры разработчиков, а не выделенной команды или человека.
О чем статья я понял. Но понять не значит согласиться. В некоторых случаях такой человек может быть полезен.
у меня есть стойкое впечатление, что я просто вторгаюсь в ваш уютный мирок того самого инженера - DevOps'а? :)
Ни в коем случае.
Как-то я поторопился ответить. Да, сама доставка должна быть частью работы разработчиков. Или внедренцев. Это не важно.
Работа девопса не в самой доставке, а втом, чтобы ее наладить. В том числе, внедрив некоторые стандарты.
random1st Автор
01.11.2021 17:17Ну граничные случаи меня менее всего интересуют - это раз, ну и даже эти случаи вы ни одного не привели. Вы скорее пытаетесь найти уязвимости в моих аргументах, а не опровергнуть.
random1st Автор
01.11.2021 17:20-2И для наладки непременно нужна команда, которая будет этой наладкой заниматься? Или этим вполне могут (и даже должны) заниматтся те, кто собственно доставку осуществляют? Как-то не вытекает одно из другого.
Ulys-ses
01.11.2021 17:23Это ззависит от масштабов. Если есть одир разработчик и один внедренец - вряд ли.
Могут таким и разработчики заниматься. Если у них нет более полезных занятий.
random1st Автор
01.11.2021 17:26А что, доставка пользы, не расплескав, к конечному потребителю - это прям совсем бесполезное занятие? Ну я на такую ересь не замахивался, сейчас вы вообще скажете что DevOps как таковой не нужен)
Ulys-ses
01.11.2021 17:35+1Бухгалтерия тоже очень полезное занятие. Вы предложите и этим заняться разработчикам?
Каждым делом должен заниматься максимально узкий специалист. Можно в одиночку ваять фронт и бэк, если это пет-проект. Но Вы же не будете говорить, что и коммерческие продукты должны так же производиться?
random1st Автор
01.11.2021 17:42бухгалтерия не живет внутри разработки продукта. Фронт и бэк тоже - они каждый делают свою часть. Я говорю о том что от начала разработки до эксплуатации - этот ответственность одних и тех же организационных единиц, если быть буквальным. Как сюда бухгалтерию прикрутить?
mikhailidi
02.11.2021 04:05+2Я, здесь в США, не перестаю удивляться. ГОСТ нет, система метрическая только в лабораториях и больницах, десятичные дроби не в ходу, но все ко всему подходит! То есть сетка таки образовывается. И вилки подходят к розеткам, купленный вчера светильник садятся как влитой на гнезда которые поставили в стену 30 лет назад. Лучшие практики и война стандартов как она есть.
Ulys-ses
02.11.2021 11:34+1А сколько времени эти стандарты развивались? Сто лет? Вы готовы потратить 100 лет на стандартизацию внутри своего коллектива?
Это красиво выглядит для розеток и кранов. А посмотрите, что творится сейчас в области стандартов более современных. Те же разъемы для зарядки смартфонов только только становятся стандартными. А стандарты в ПО?
Sorceress
02.11.2021 14:06Да, каждая система стремится к самосохранению и девопсы тоже, но...
Большая часть программистов не разбираются в той среде, под которую они пишут программы, я имею в виду операционные системы(Linux, Unix, Windows, не имеет значения), про сети и какой-то уровень безопасности, даже говорить не приходится и кто-то должен заставить все то, что граждане программисты написали функционировать и фактически создать производственный конвеер для разработки и тестирования программного продукта, а также для обозначения зон ответственности.
Еще нужно объяснить особо несознательным личностям, почему это может работать так, а не иначе, исследовать ограничения тех программных продуктов(библиотек, баз данных, и.т.п), на которые они опираются, стандартизировать рабочие места и процесс разработки, построить архитектуру.
Вы серьезно считаете, что Дядя Вася справится?
Ну, если он учился в институте городского хозяйства и умеет проектировать сети городской канализации, водопровода и прочих коммуникаций, то возможно, а если нет... Привлекайте Дядю Васю и молитесь...random1st Автор
02.11.2021 14:08Если продолжать аналогию с дядей Васей - я не говорю что дядя Вася совсем не нужен. Я говорю, что если считаете что он нужен - так пусть он на заводе со всеми работает, и разделяет ответственность за продукт, а не на себя работает и свои интересы, но почему-то за деньги завода.
restlesss
02.11.2021 20:17А разве не все работники на заводе работают на себя и ради своих интересов?
random1st Автор
02.11.2021 20:33Людям на работе дают материальные и нематериальные стимулы для того, чтобы они исполняли те или иные роли. У людей одни интересы, но мы же не Васю Пупкина нанимаем, а исполнителя роли инженера например?
Karroplan
01.11.2021 14:15сорри, но нет. DevOps приходит и настравиает конвейер и цепочки, а само наполнение конвейера и цепочек (из чего оно состоит) - придумывают кто-угодно но не devops-ы: разрабы, когда говорят, что хотят bitBucket, а не gitLabs, инфо-безы, когда говорят, что обязательно надо SonarQube со своими свистелками, админы, когда говорят, что нафиг ваш k8s, прод будет на OpenShift и т.п. а DevOps-ы с грустной миной "ну ок" и пошли пилить, то есть фланец на 1 и 1/4 и левой резьбой искать.
random1st Автор
01.11.2021 14:19все правильно. Именно о таком пессимистичном сценарии я и говорю. В "правильном" DevOps учитываются требования к скорости изменения и доставки продукта, а согласование процессов, набор технологий, и прочие договоренности - это результат коммуникации команд разработки (производства) и эксплуатации (админов). Иначе возникает такой человек-прокладка, который якобы методолог, а по факту блокер.
Karroplan
01.11.2021 14:53+1к вашей тираде (статье) тоже комментов много ) практика показывает, что нужен кто-то между дев и опс, кто поможет и тем и другим, чтоб все работало четко, быстро и прогнозируемо. Это и есть практики devops и культура и люди их воплощающие. В сильно большой организации, когда девам и админам нет времени все это настраивать и выстраивать проще нанять людей, можно в дев, можно в опс, а можно их выделить в отдельную структуру и обозвать девопс. суть в том, чтоб две шестеренки крутились лучше и нужна не прокладка, а смазка. а так, в целом да - наверное и админы с этим справяться, просто дайте им время и ресурсы. Да и разрабы, но им немного непривычнее в тоннах конфигов копаться (простите, я все эти ansible-playbook-и и прочие deployment-ы считаю конфигами)
random1st Автор
01.11.2021 15:00+1еще раз - нужен не кто-то, нужна культура коммуникации и работы с требованиями. Есть законы построения организаций, которые говорят о том, что выделенная структурная единица всегда строит свою часть продукта. Не работает так, просто потому что не работает. Нанять как исполнителей - наверное можно, но вот decision making сюда отдавать нельзя - потому что это игра в испорченный телефон.
Ipeacocks
02.11.2021 00:23Дык вам к начальству нужно идти, а не на хабр, приведите им пример о сантехнике Васе. Девопсы - люди в основном подневольные - делают то, что их просят. В моменты, когда они хотят как-то улучшить/изменить процесс, - все обижаются и бегут жаловаться.
random1st Автор
02.11.2021 10:46Революции не делают одиночки) Между прочим вот эта статья мне очень помогла в аргументации своей позиции
Ulys-ses
01.11.2021 14:30Что именно "нет"?
"Нет, не надо выстраивать методологию"?
"Нет, это делает не человек"?
"Нет, DevOps-инженер (инженер!) - это дядя Вася из ЖЭКа"?
Karroplan
01.11.2021 14:45перестаньте вести себя как бестолковый тролль. Сорри, но нет, не девопсы придумывают эту "сетку".
Ulys-ses
01.11.2021 14:48Тогда кто?
Только, пожалуйста, без тупого перехода на личности.
random1st Автор
01.11.2021 14:55Что возникает раньше - требования к унификации или сетка размеров? Ваш человек, придумавший сетку - это такой аналог Бога. "И только дух божий парил над волнами". Правильный ответ в том, что нам извините, наплевать на то, кто придумал, зачем и прочие заморочки - мы могли практику стандартизации взять со стороны, изобрести сами, она нам могла присниться. Просто потому что это часть нашей инженерной культуры, образования если хотите - мы как инженеры осознаем пользу стандартизации. Сетка - это РЕЗУЛЬТАТ применения подхода, нет никакого резона ее придумывать. Если вы сядете на песок, и на нем останется след - вы же его не рисовали специально, это следствие того, что у вас есть телесная практика отдыха сидя. А вы причину со следствием путаете. Так понятнее?
Ulys-ses
01.11.2021 16:14Что Вы называете "требования к унификации"? Общее пониманиеее необходимости или конкретные требования? Если второе, то непонятно почему Вы отказываетесь включить в них условный "размер сетки". Если первое, то это ни о чем - те самые благие намерения, которые известно куда могут пригодиться.
Вы можете взять стандарт со стороны. Если он есть и подходит вашей команде, то это даже лучше, чем изобретать велосипед. Но кто-то должен решить, что вы должны взять стандарт, выбрать конкретный стандарт, рассмотреть возможные изменения в нем и т.п. Если вас десяток и вы все крутые спецы, то это может сделать любой из вас или вы можете сделать это коллективно. Что это будет значить? Что обязанности девопса у вас исполняет кто-то по совместительству, случайно. Наверное, в такой ситуации вам не нужен выделенный специалист. Но это не значит, что он не нужен никому.
И не зацикливайтесь так на сетке. Она всего лишь пример. Как и Ваш "след на песке".
random1st Автор
01.11.2021 16:29Вы вообще не поняли суть статьи. Я говорю о том, что DevOps не живет вне разработки, и если у вас есть DevOps - он проходит через Development в Operations. И выделенная организационная единица если хотите - не человек, а команда из одного и более человека, она ущербна в принципе, потому что у нее в фокусе не система в процессе принесения пользы, а некий пресловутый DevOps, под которым каждый понимает свой набор технологических шаблонов. Делаем CI/CD, описываем инфраструктуру терраформом, камлаем - ай какой хороший у нас девопс.
Ulys-ses
01.11.2021 17:20Мне кажется, это Вы не понимаете суть работы девопс-инженера.
Девопс должен настроить взаимодействие, а дальше оно уже должно работать без него.
random1st Автор
01.11.2021 17:25Ну я такой картины никогда и нигде не наблюдал. Скорее наблюдается то, что devops команда/инженер/оргзвено отгрызает себе кусок ответственности за доставку изменений, и плотно на ней сидит. Влажные мечты оставим за кадром. Я не ставлю под сомнение задачу организации процесса доставки. Я говорю о том, что выделенная devops команда это зло. Из вашего комментария следует, что ее вообще можно уволить после наладки процесса - т.е. после того как его будут поддерживать разработчики. И вот получается что в принципе вы о том же - что после запуска процесса разработки devops инженер не нужен)
Ulys-ses
01.11.2021 17:39Из вашего комментария следует, что ее вообще можно уволить после наладки процесса - т.е. после того как его будут поддерживать разработчики.
Вы, может быть, считаете, что и сисадмин не нужен, если все работает?
random1st Автор
01.11.2021 17:45-1ваши примеры показывают, что вы не умеете оперировать понятием жизненного цикла. Сисадмин /SysOps живет уже после доставки продукта. Он нужен, чтобы решать проблемы, возникающие у конечных пользователей в процессе эксплуатации.
https://ru.wikipedia.org/wiki/V-Model -посмотрите сюда и сами догадайтесь где живут devops практики.
Ulys-ses
01.11.2021 18:05+2Сисадмин - как пример "ненужного" персонала. Некоторые именно так и думают - зачем платить сисадмину, если все работает? Продукт здесь ни при чем.
...где живут devops практики
Вы уже перестали называть их инженерами. Это прогресс.
random1st Автор
01.11.2021 18:12практики - это не люди) Практики это технологии плюс знание, где их применять. А мы тут обсуждаем именно людей и зачем они нужны) А под DevOps инженерами я понимаю носителей этих практик
Ulys-ses
02.11.2021 11:36А, в этом смысле.
Впрочем, возможно, это я неправильно понимаю кто такой девопс. (По принципу: "правильное мнение - мнение большинства".) В таком случае, Вы, конечно, правы и такие люди не нужны.
Ipeacocks
02.11.2021 00:26+1А как обстоят дела с унификацией в разработке? Вижу, что не очень. Сколько там языков программирования и фреймворков?
Ее нет нигде. Мир - это плюрализм идей.
random1st Автор
02.11.2021 14:11Вы уже живете в среде стандартов - разнообразие смещается туда, где от нее действительно есть польза. А фундамент - он как раз и позволяет этому разнообразию существовать. Много мы бы сейчас имели фреймворков, если под каждую вновь выпущенную модель процессора заново писали эти фреймворки с нуля?
Ipeacocks
02.11.2021 15:01Ну так посмотрите сколько существует архитектур цпу и как там работают фреймворки, если они есть. Посмотрите на разнообразие дистрибутивов Линукс.
Есть стандартизация где собираются комитеты и вместе договариваются или что-то идёт в мейнстрим как архитектура цпу. Например производители железа. Или вы думаете соберётся Девопс комитет и разработает схемы деплоя?
vya
01.11.2021 13:13+7Если поглубже погрузиться, то это мода на "барабаны Страдивари". Ситуация аналогична внедрению SAP, когда вместо подбора инструмента под задачи выбирают задачи под инструмент.
mikhailidi
02.11.2021 04:10Мода есть а вот сравнение с SAP не совсем корректное. Когда покупают ЕРП, платят не только за софт, Верне не столько за софт как за практики и процессы. И если компания покупает SAP тоько как супер Эксель - результат соответствующий.
Sergey-Aleksandrovich
01.11.2021 13:49+5Откуда возмется "инженерная культура", если ее никто не "воспитывает"? ..да и инженеров тоже: https://habr.com/ru/post/233851/
Кому нужны эти проверки ценности идеи / можно и без высшего образования / главное чтоб работало / тяп-ляп и в продакшн...
random1st Автор
01.11.2021 19:42Ну вообще вы не совсем правы - вот познакомьтесь например с https://mybook.ru/author/anatolij-levenchuk-3/obrazovanie-dlyaobrazovannyh-2020/read/ - в курсах от Левенчука много про правильную инженерную культуру.
Sergey-Aleksandrovich
01.11.2021 19:55+1Возможно кто-то и воспитывает, но системно, в массовом порядке - нет. В библиотеке много полезного и интересного, но кто ж туда ходит?
nApoBo3
01.11.2021 14:09+2Любой "нормальный" инженер стремиться все стандартизировать и свести к готовым решениям. Если нет, то это "герой". А от героя всем вокруг сплошь проблемы. Почему? Потому как поддерживать решения энтузиаста который: "devops это взаимодействия для обеспечения качества....." не возможно без самого энтузиаста. А энтузиасту что, он накостылял, навоял нетлеку и пошел дальше.
random1st Автор
01.11.2021 14:13-2спасибо за комментарий. Между делом отмечу, что русский язык это тоже стандарт, и в нем надо придерживатЬся некоторых правил. Что касается сути - речь идет не о вреде использования готовых решений. Речь идет об неоправданном и неосознанном ограничении решений набором готовых шаблонов.
nApoBo3
01.11.2021 14:54+1Вы так пишите, как будто: " ограничении решений набором готовых шаблонов" это что-то плохое. Ограничение решений набором готовых шаблонов позволяет прогнозировать риски, создавать стабильные, предсказуемые по срокам и затратам, дешевые, поддерживаемые системы.
Не нравится? Наймите себе "творца". Это будет дорого, не предсказуемо и не поддерживаемо, но зато без всяких неосознанных ограничений.
Не бывает неоправданного и неосознанного ограничения решения набором готовых шаблонов, это оправданное ограничение, на то они и шаблоны, их нам не на скрижалях передали, бывает не оправданное его расширение за пределы готовых шаблонов, без понимания стоимости такого расширения.
Все, что за пределами шаблонов, это НИОКР, с соответствующими рисками и стоимостью.
random1st Автор
01.11.2021 15:02-2не подрезайте мои аргументы, я говорил о "неоправданном и неосознанном" ограничении - просто на основании все так делают и раньше я так делал, и дед делал, и вон парни из той компании так делают, а остальное все от лукавого.
nApoBo3
01.11.2021 15:13Так я вам и отвечаю: "Не бывает неоправданного и неосознанного ограничения решения набором готовых шаблонов".
Не мешайте в кучу НИОКР и производство и будет вам счастье. Производство это шаблоны, любой отход от шаблона по умолчанию не оправданный.
random1st Автор
01.11.2021 15:41-1Бывает, и я неоднократно с этим сталкивался. Ваш НИОКР (который собственно об RnD) в производстве ПО предельно близок к основному циклу производства. Сегодня вы потыкали технологию, а завтра она улетела в продакшн. И тут важно осознанно понимать, почему та или иная технология подходит. В случае выделенной роли девопс-инженера он страдает шизофренией. Обычный пример из жизни - когда девопс-инженера делают крайним и за доставку изменений в продакшн, и за саму эксплуатацию. В этом случае он естественно ограничивает набор возможных решений просто потому, что его мало и он блокер. Это именно то, что я называю неоправданным и неосознанным ограничением - если хотите, рефлексией на возрастающую технологическую сложность.
nApoBo3
01.11.2021 16:10+1Сегодня вы потыкали технологию, а завтра она улетела в продакшн.
Это называется х.... х... и в продакшен.
В этом случае он естественно ограничивает набор возможных решений просто потому, что его мало и он блокер. Это именно то, что я называю неоправданным и неосознанным ограничением - если хотите, рефлексией на возрастающую технологическую сложность.
Вы уж определитесь, если его "мало", это оправданные и осознанные ограничения. Понятно, что чем выше у вас нагрузка, тем меньше у вас вариантов с сохранением стоимости вплоть до того, что их вообще может не быть.
random1st Автор
01.11.2021 16:42Это зависит от того, насколько бизнес вообще жизнеспособен без такой скорости изменений в продукте. Я не знаю ваших там методологий, я знаю что надо обычно вчера - и чем быстрее изменения в продукт долетят тем лучше. Что касается оправданности и осознанности -он блокер потому что у него нет радостного интереса внедрять новые технологии. Вообще никак - он выделенный товарищ(команда), которая отвечает только за доставку изменений и зачем ему новые технологии если и так все работает? Ему не за это платят. И таким образом с его точки зрения он все делает правильно, но в целом он вредитель.
ky0
01.11.2021 14:18Держу пари, что досконально изучить все особенности работы какой-нибудь postgresql куда сложнее, чем концепт работы с k8s.
Возможно именно поэтому средний девопс старается держаться подальше от более-менее нагруженных СУБД. Для них куда сложнее придумать «ритуальные приседания» :)Ipeacocks
02.11.2021 00:28+1Дело в том чего хочет бизнес. Бизнес хочет кубенетис - все учат кубернетис.
ky0
02.11.2021 12:16Это в каком-то параллельном мире, где грамотный сисадмин не может найти работу и вынужден работать с теми технологиями, которые ему безапелляционно спускают сверху менеджеры, насмотревшиеся презентаций.
Мой опыт показывает примерно обратное — инструменты и процессы разработки/эксплуатации в нормальных компаниях выбираются и выстраиваются исходя в первую очередь из технических аспектов и экспертизы инженеров.
oilmonster
01.11.2021 14:26+1Все верно в статье, раньше команды договориться не могли, админы с разработчиками
Теперь есть виноватый во всем девопс =))) это он должен был их всех договорить и настроить как они хотят. Заставить согласованно работать админа и разработчика это и есть девопс, чтобы конвеер работал и склад не пустел, и бизнес был от прибыли доволенА всякие ваши софтбезы и истерички вроде стекосодержащих команд это уже от бюрократии и централизации, т.е. от лукавого
unsignedchar
01.11.2021 14:30В каком учебном заведении учат на этого вот DevOps'а?
random1st Автор
01.11.2021 14:36в каком учебном заведении могут учить на специалиста по пусконаладке программного обеспечения?
unsignedchar
01.11.2021 15:16Да, в каком?
random1st Автор
01.11.2021 15:19ну наверное должны там же где учат это ПО писать, нет? Иначе какой смысл писать то, что мы не знаем как отправить в эксплуатацию?
Bazilbrush
01.11.2021 15:42+3Я понимаю что я часть проблемы, т.к. работаю девопсом в кровавом энтерпрайзе, но в моем опыте очень редко дев команды говорят "стоп а давайте сейчас пересмотрим все узкие места, доделаем CI нормально наведем порядок в кодовой базе, посоветуемся с другими командами может они уже решали проблемы как у нас и.т.д.
Им вчера надо фичи пилить, и даже если хочется сделать рефакторинг или помогать опсам в настройке то банально нету времени, а там еще надо разбираться с какими-то терраформами...
Конечно, культуру развивать надо, но сама по себе она не не придёт (все пацаны, завтра выучим ансибл, и заживем!) , надо организовать тренинги, планерки, работать с людьми... Это организационная дыра куда уходит много времени и сил чтобы допустим деплоить не 4 а 6 раз в день.
random1st Автор
01.11.2021 15:52-2смотрите, все что тут описано звучит как "бла-бла-бла" или танец шамана с бубном. Придет шаман, покамлает и все станет хорошо. С каждым нужно говорить на его языке. Для бизнеса DevOps практики приносят ускорение увеличения полезности продукта - за это он будет платить. Разработчики не видят ценности только потому, что им этой самой культуры не хватает. Так она и не возникнет, если кто-то будет делать DevOps за них, при этом еще и ответственность за доставку в эксплуатацию на себя забирая
Bazilbrush
01.11.2021 16:15+1Я совершенно согласен, что надо только консультировать, ставить на путь истинный а дальше девы должны сами развивать. Иногда так и получается, и я от этих товарищей слышу раз в пару месяцев, они поняли зачем им это надо, и они теперь сами помогают разрабатывать ci. А кто-то не учится. Или большой босс сказал что надо вот прям сейчас все сделать чтобы работало, и тогда, да неизбежно все завязывается на дядю Васю пусконаладчика.
Ну и край это инфоцыгане и всякие админы с комплексом вахтера. Но таких немного.
Kirikekeks
01.11.2021 16:48ДевОпс это монетизация опенсурса за счет намеренного повышения сложности системы, ускоения ее мобильности, и занятости опенсурсников на зарплате у энтерпрайза. Можно обфусцировать код, можно просто повесить лицензионный замок, можно написать такую монстру, и так часто веосить изменения, что бы в одну голову не влазило. В мутной луже больше золота, по завернию Флинта, Били Бонса, и Слепого Пью.
Bazilbrush
01.11.2021 17:05Не в бровь а прям в глаз. Нас гнать в шею надо, на гитхабе качем, стаковерфлоу читаем, а нам еще деньги за это платят! :) А если серьезно, то да, хайп есть, и очень много людей бездумно делает то что им сказали а Гартнер репорте.
Arashi5
01.11.2021 17:56На самом деле слегка обидно за дядю Васю, как стереотип работника руками.
И из-за вот такой вот аналогии мне кажется, что все аргументы( с которыми я отчасти согласен), умножаются на 0, так как нет элементарного уважения к другим. И сквозь строки статьи читается: "Все <censored>, а я — д'Артаньян", отсюда степень доверия к статье, к сожалению, падает.random1st Автор
01.11.2021 18:19-1ну не надо за дядю Васю обижаться. Дядя Вася нашел свою нишу - и прекрасно себя в ней чувствует. В разработке ПО нам дядя Вася как раз не нужен - мы живем в другом технологическом стеке, и нам не нужен такой вот посредник. А где вы подобное вычитали - я не понял, честно говоря. Я всегда пишу не о людях, а о ролях. Если вас коробит дядя Вася - могу заменить на Super Mario, суть от этого не изменится.
Arashi5
02.11.2021 10:22+2К сожалению, я не корректно выразил мысль, за что искренне прошу прощения.
Сейчас попробую сформулировать более точно.
Вы описали проблему, и эта проблема действительно имеет место быть, так как является тем самым рычагом спобоным свести на нет процессы разработки, тем самым порождаю тонны техдолга.
Так вот, я хотел отметить, что было бы лучше, если бы вы формулировали мысли несколько более корректно, что показывало бы вас как настоящего профессионала, коим вы и являеетесь. И эффект от вашей статьи, как мне кажется был бы больше.
Опять же, видимо тут начинается диалог с самим собой, вы индивидуальны и ни в коем случае ни мне, говорить вам что писать, и как писать. Я просто выразил свое наблюдение.random1st Автор
02.11.2021 10:43Спасибо, на самом деле это скорее затравочная статья, и несколько провокационный ее тон является всего лишь средством вызвать дискуссию)
random1st Автор
01.11.2021 19:08Да, но платит за весь этот бардак владелец бизнеса, а пользу приносим конечному потребителю. Да и в конечном счете разработчик, работающий в неэффективном бизнесе, рано или поздно вынужден будет уйти. Как мотивировать разработчика работать на бизнес давайте обсуждать не будем - у каждого свои интересы
Опять же - правильный интерес - меньше магии, больше возможностей для бизнеса. Я не говорю о том, что надо кидаться в крайности и заиспользовать все подряд.
Нет, так не работает. Тот же AWS формирует SaaS исходя из использования - берет низкоуровневые сервисы и объединяет в высокоуровневые, в их объединении находя новую, эмержентную функцию. А все юзкейсы ни один клауд провайдер предусмотреть не в состоянии.
Jammarra
01.11.2021 18:04+3Отчасти согласен. С другой стороны. Разрабам за настройку ансибла не платят. А если они будут его настраивать то через год станут девопсами.
Это может проканать в компании на 5 человек. Когда ты и швец и жнец. В крупных компаниях же одно только изучение всех требований безопасников займет несколько месяцев.
А через пол года выйдут новые стандарты.
random1st Автор
01.11.2021 18:15простите, ансибл уже давно не тренд. Сейчас практики DevOps живут в k8s, и даже терраформ чувствует себя несколько напряжно, поглядывая на всякие pulumi/cdk. Но это опять не про то
Me1ram
01.11.2021 18:25+2Да не бред.
Разрабы никогда не будут этим заниматься, во первых нет компетенций, во вторых у них тех долг растет и разгребать кучу своего же ... они не хотят.
Постоянный копипаст с прошлых проектов или со стэковерфлоу со всеми не нужными зависимостями.
Торопятся со своими двухнедельными забегами не делаю нормальную документация и код пишут под себя.Это уже проходили - толку от этого ноль
random1st Автор
01.11.2021 18:31Ну начнем с во-первых. Развитие компетенций - это первое с чего начинается внедрение новых технологий. Это прямо то, с чего должен собственно начинаться DevOps. Дальше, насчет копипаста - все копируют, все не делают нормальную документацию, все торопятся. Дальше - не хотят разгребать. Скорее тоже не хватает культуры понять, что отдача техдолга, как и создание его - это нормальный производственный процесс. Ну и тут скорее компетенция технического менеджмента важна. Как я бы сказал, плохо можно сделать все, что угодно.
anonymous
00.00.0000 00:00random1st Автор
01.11.2021 18:51Проблемы, на которых я фокусируюсь, две 1) это разделение ответственности за доставку продукта между орг-единицами, из которых одна разрабатывает, но не ответственна за доставку и эксплуатацию, а вторая отвечает исключительно за доставку, всецело наплевав на все остальное. "Такой devops нам не нужен"(с). 2) Это ограничение технологического стека - потому что мы вынуждены весь стек подгонять под компетенции каждого звена в цепочке. Проще говоря, разработчики умеют в Docker, а DevOps инженеры в kubernetes, и этим живут, находя здесь точку сопряжения. Проблемы возникают, когда начинаются велосипеды - и например разработчики не используют SaaS - ибо ничего о них не знают, а даже если знают - у devops-команд нет никакого интереса эти сервисы использовать, а в свою очередь devops команда не пытается адаптировать код, чтобы выстроить интеграцию, если появляются новые возможности с той стороны - просто не умеют в код.
Проблема решается просто - когда вне зависимости от компетенций все отвечают за доставку от старта разработки до запуска в эксплуатацию и саму эксплуатацию.
devops_sergeant
01.11.2021 18:55+2Вероятно надо шатнуть этот храм.
С добрым утром. Уважаемый автор, поздравляю, вы только что открыли суть всех работников нашей индустрии. Agile-цыган, консалтеров, архитекторов, разработчиков, тестеров и тд.
И все они - такие же Васи пусконаладчики.
Но да ладно. Внезапно, не "DevOps" инженеры решают хоть что-то. Кубернетесы, докеры и прочие радости жизни решают внедрять еще более пусконаладочные Васи - архитекторы и Васи - руководители IT.
И не DevOps инженеры решают внедрять культуру или не внедрять культуру. Это делают кто?Правильно. Васи - agile цыгане пусконаладчики.
У нас не могут существовать культуры. Мы жители СНГ, у нас другой менталитет. А то что называется культурой - чаще будет лицемерной занавеской. Где все по старому. Почему?
Потому что культура требует "САМОДИСЦИПЛИНЫ" и "ДОВЕРИЯ". А этим наш менталитет не страдает.
Поэтому в итоге IT - как бабки с очередным бадом. Был БАД Agile - пришел БАД DevOps.
Могут существовать DevOps отделы. Могут быть Agile отделы. Можно сделать реально все что угодно. Можно конфигурировать, как угодно в каком угодно виде разные специализации. Итог один. Для всего нужна внятная цель. Не имея внятной осознанной цели, можно говорить про любые специальности, как про Вась. Особенно про архитекторов. Там иногда Вася на Васе.
Поэтому прежде чем писать о криках души - сначала все же рекомендовал бы остановиться. Не Америку открыли. И не убедили, что таблетка это не создавать DevOps отделы или делать из разработчиков админов - автоматизаторов. Они будут подвержены тем же законам Конвея, когда начнут становится и швецами и жнецами и на дуде-дудедцами.
Очень классно этот принцип пихать везде где можно. Любят у нас "Закон Конвея". Пугают им, как страшной сказкой на ночь. Только закономерный вопрос. А автоматизация что...разве не продукт внутри продукта?)Это разве не отдельная система? А конвеер на заводе, который передвигает болванку от одного станка до другого, разве не сложное инженерное решение, которое создано, разработано, и уже только потом "ПУСКОНАЛАЖЕНО"? Уберем devops отдел, и? Поставить devops коуча, который будет забирать тонну времени разработчиков, чтобы их научить, поставить, их руками наладить? А дальше через 5 лет имеем зоопарк систем, которые обеспечивают работу разработчиков, но их поддержка стоит столько, сколько не хочется даже на слайдиках смотреть.
Ну и в конце концов. Энто што за глупости такие. Расскажи вы сейчас всему миру, что надо делать хорошо и качественно - вас быстро умолчат)
Принципы затоваривания рынка работают и в ИТ. Делать качественно не выгодно никому. Все без работы останутся. Поэтому да. Будут продукты внутри продуктов, отсутствие инженерной культуры. Потому что круговая порука. Васи-исполнители делают плохо, потому что тем же Васям-средним прокладкам между исполнителями и дальше требуется докладываться наверх, рассказывать как все плохо и менять Васей-исполнителей на других. И еще нанимать Васей-консалтеров. Те же Васи, которые факапят проекты, должны иметь виновных, чтобы продолжать сосать деньги из заказчиков. Это закон рынка. Он одинаков для всех.
И удивляться и писать громогласные статьи из разряда "Agile не оправдал!" "Долой DevOps!" - из разряда набивания кармы.
random1st Автор
01.11.2021 18:58-1Аппрувнул ваш комментарий, потому что уж очень много букав - старались, писали. Вы возможно удивитесь, но многие люди правда любят свою работу - писать код, разворачивать сложные системы и в целом приносить пользу. Иначе зачем на это тратить свою жизнь? На хлеб заработать неглупый человек всегда найдет как.
devops_sergeant
01.11.2021 19:05Ни разу не удивлюсь. И даже знаю кем и как должны были стать DevOps инженеры. Но только рынок живет по своим правилам. И компании которым нужна культура - они и так поймут, что надо сделать. Те самые 0.01 процентов компаний поймут, что внедрять и как. А остальные 99.99 будут жить по законам рынка.
А написать взрывной пост и я могу.
"Долой DEVOPS!" "Во всем виноваты DevOps отделы!"
random1st Автор
01.11.2021 19:10Пишите, с удовольствием посмотрю, как вы аргументируете.
devops_sergeant
02.11.2021 12:50+1Аргумент простой.
Есть системы обеспечивающие автоматизацию. Их надо поддерживать, их надо обновлять, и саму автоматизацию надо дорабатывать. Постоянно. Внезапно!
Потому что у автоматизации нет конечной точки. Ибо из-за постоянного изменения технологий - автоматизация постоянно будет дорабатываться. Так же как и с ростом любой системы.
Разработчик не будет поддерживать обновление систем и конвеера. Ему писать код надо. Ему нужно дать кнопку. Потому что траты на "обучение разработчика" вместо Васи пусконаладчика, гораздо больше, нежели Вася-пусконаладчик.
Хорошо, уберем команду DevOps. Оставим по одному Васе. Вот у нас контора. 100 команд, 10 тыщ человек. 100 команд в, каждой по Васе. 100 команд поставили...100 дженкинсов. 100 дженкинсов съели...100 виртуальных машин. по 2 ядра и 4 оперативы....Организация только что выкинула в воздух деньги на стойку, работу инженеров, сетевиков, подключение, закупку доп лицензий на оборудование. Это уже не сотня тысяч. И не 5. И даже уже не 10
100 дженкисов требуют....постоянных обновление и проверок инфобеза. Потому что внезапно они сами по себе дырявые. 100 дженкинсов требуют....тонну документации у администраторов, потому что они вынуждены знать, что за инструменты стоят на виртуалках. А еще десятки тысяч сетевых правил (куда же без этого)
Далее следим за руками. 100 Вась - devop ушли из всех 100 команд. Документации естессно не оставили. Дальше загадка. Где первое узкое горлышко, которое зарубило компании и разработке всю работу и поставило их на грань траты миллионов?) Правильно, чертов пароль от виртуалки. По закону жанра, он у девопса, и девопс свалил вместе с ним.
Хм. А что если разработчики - уникальные и прошаренные. Этакие супермены. Убираем Васю.
100 команд разработчиков развернули на коленке под столом у себя на компе 100 дженкинсов....
Круг замкнулся.
Если сюда еще привязать реалии agile - то получается костыль на костыле. Все тоже самое.
И в итоге - статья больше похожа на призыв - давайте сделаем человека отделом разработчика, вместо человека - отдела devops. Забывая, что уровень разработчика сейчас не выше уровня Васи. Что Вася разработчик гавнокодит, что Вася девопс.
IT изначально не умеет в нормальное производство. Каждый божий день оно пытается придумать свое, потому что всем нужно кушать. Вместо того чтобы налаживать производственный офис - оно взваливает все на проектный. Вместо того, чтобы внедрять просто культуру из простых тезисов - компании проще менять людей. Внезапно. Потому что толпа возомнивших себя не бог весть чем разработчиков, архитекторов, девопсов - всего лишь такая же толпа на заводе. Просто пока с вольностями. И это такие же винтики, которых просто менять достаточно. Особенно с нашим менталитетом.
arheops
01.11.2021 21:49+3Проблема только в том, что ресурсы инженера ограничены.
И если он выучит условный ansible, то за то же время не выучит чего-то, что на его непосредственную работу влияет сильнее.
А так да, в идеале, конечно, чтоб все инженеры были полными fullstack еще и в каждом направлении были гуру. Но так не бывает за разумные деньги, вот ведь в чем засада.random1st Автор
01.11.2021 22:08-1во-первых, там уже давно нет никакого rocket science, и мне странно слышать, что знание инфраструктуры опционально для инженера. Во-вторых, ну еще раз повторюсь - я не против наличия DevOps инженеров в команде, я против того, чтобы они представляли собой выделенную организационную единицу.
arheops
01.11.2021 22:26+2Да во всем ИТ уже нету никакого RS
Но все равно на это надо тратить время. И не просто так один раз, а обновлять знания за изменением инструментов.
Shumsky90
02.11.2021 11:25+2сразу видно эффективного менеджера, который не понимает всю суть работы девопса (ну и как эти тимы образуются).
простой пример:
имеем несколько тим девелоперов, несколько тим тестеров. Для их работы что нужно? Правильно: инфраструктура. Которую нужно как-то поддерживать. Видал я как программеры пытались в сетевые задачи, особенно доставила фраза "ну да, у нас задержка выросла в 3 раза. С другой стороны это все раво 120мс, что пофиг". У чувака на нулевом траффике задержки в 3 раза выросли, а его это не волнует ваще :) но то такое.Если Вы не фанат метода "каждый девелопер собирает модуль на своём компе с хуй пойми каким энвайрментом, чтобы остальные охуели собирать его модуль когда он уйдёт в отпуск\уволится" - то нам нужна компиляционная инфраструктура.
если Вы не фанат метода "каждый девелопер работает со своей базой данных из под рута, правя системные параметры на лету" - то нужны несколько дев.баз данных.
если Вы не фанат метода "каждый кодер ранит свой модуль в своём энвайрменте, а потом тестеры ебутся чтобы заставить его работать в связке с остальными модулями, каждый на своей машине с хуй пойми каким энвайрментом" - то нужны тестовые энвы.
Методика "каждый программер деливерит свой модуль сам" охуенная, да. До тех пор, пока у Вас не появляется количество тестеров, отличное от 1 человека на халфтайм. Которым нужно в день потестить разные ветки\версии\билды\как оно у вас называется. Причем проверить совместимость в том числе с разными версиями других модулей. Да, это делается через дженкинсы. Которые - сюрприз, надо поддерживать и как-то насетапить.
про клиентские энвы я вообще молчу: Вы когда-нибудь пробовали толпе девелоперов давать рута на клиентских системах?:) Нет? Тогда рекомендую дать человекам 15-20 рутовый доступ на клиентах и пускай они сами деливерят. Гарантирую много положительных эмоций от клиентов :)
да, все эти задачи может выполнять обычный сисадмин, который умеет автоматизировать рутину и помогает программерам понять что не так в их коде, раз он не работает на стандартном энве... Ой, кажется я только что описал работу девопс тимы, да?:)random1st Автор
02.11.2021 14:05-1ну вы на личности пожалуйста не переходите, и пальцем в меня не тыкайте, я в IT можно сказать уже лет 20, и потрогал очень многое. К тому же мне претит ваш стиль общения, мат на мате - это для усиления аргументации? Я понимаю, что ваша позиция это позиция типичного "девопса", но я с вами диалог вести и не хочу - не интересно, заранее понятен интерес и какую точку зрения будете защищать.
Shumsky90
02.11.2021 15:24обычный рабочий стиль общения, не более.Или хотите сказать что коллеги не охуеют при попытке повторить конфиг энва Василия, в котором он поставил патченый openssl пол года назад, благополучно забыл про это и потому у него все было норм, но больше его модули сбилдить никто не смог (реальный случай кстати)?
Что лет 20 - то без вопросов. Но в комментах выше былоНу граничные случаи меня менее всего интересуют, однако сами-же скатываетесь к граничному случаю: небольшие тимы, 2-3 модуля в продукте, так? В них да, отдельно взатый девопс как таковой не нужен, а программеры сами и оттестировать это все смогут. Тут без вопросов, одозначно.
Некоторое время назад я работал в довольно таки крупной компании, так там один продукт состоял из десятка модулей, которые должны были активироваться в зависимости от потребностей клиента и, в том числе, интегрироваться с другими программными продуктами. Просто для справки хочу уточнить что этот конкретный продукт пилило порядка 200 человек, плюс смежные продукты (порядка 7 основных + десятка полтора второстепенных), плюс армада тестеров. И это не прямо какой-нибудь фейсбукоайбиэм, это средней величины контора, коих дофига.
это я к чему: тестеры в день реквестили по 2-3 конфигурации каждого энва (ибо тестеров на данном конкретном продукте было около 40 человек), дабы проверять разные билды разных продуктов на совместимость с новым билдом). Энвов только для этого софта было порядка 30 штук. Да, есть дженкинсы, но за ними тоже нужно следить, как ни странно. Да и пайплайны не сами по себе зарождаются, удивительное дело.
а теперь представим как толпа программеров (ну ладно, 2-3 программера из разных локейшенов) одновременно заходят на энв и начинают запускать апдейты базы, деплоить все ручками, ибо дженкинс не отработал а ему сейчас лениво разбираться что не так, и вообще производить разные манипуляции. Какова вероятность того, что что-то пойдёт не так?:)
и нет, я не девопс, однако некоторое время был сисадмином, потому в курсе событий что и как у них происходит. Но всё понятно по фразе:Я понимаю, что ваша позиция это позиция типичного "девопса", но я с вами диалог вести и не хочу - не интересно, заранее понятен интерес и какую точку зрения будете защищать.то-есть позиция типичного "менеджера" - "его мнение отличается от моего, значит он не прав. Следовательно нет смысла с ним общаться". Слив защитан, великолепно: сливаться на граничный случай мелких тим с парой модулей, при этом заявляя что "граничные случаи не интересуют"
random1st Автор
02.11.2021 17:33-2ваше мнение мне неинтересно, потому что вы не поняли суть статьи, и следовательно, отвечаете мне в духе "я про Фому, а он про Ерему", а не потому что не правы.
Lofer
02.11.2021 15:49+2простой пример:
имеем несколько тим девелоперов, несколько тим тестеров. Для их работы что нужно? Правильно: инфраструктура.не правильно :) Для их работы нужны всего три вещи:
требования - Что от нас вообще хотят ? что мы вообще хотим сделать и зачем?
критерии приемки - как мы будем доказывать, что то что мы сделали, именно то что ожидал бизнес. За что мы деньги берем?
Что нам может помешать выполнить ожидания п1 в рамках п2 ? Где и кто может "накосячить" и на кого вешать "косяки"?
Артефакты типа - ифраструктура\билды\девелоперы\DevOps и т.д. это просто инструменты достижения п1 в рамках п2 с минимизацией п3 и не более.
"ну да, у нас задержка выросла в 3 раза. С другой стороны это все раво 120мс, что пофиг"
Хоть почтовыми улитками на глиняных табличках с клинописью пусть пакеты доставляются. Укладывается в критерии приемки ? Критерий разумной достаточности соблюден ? Ну болт на задержку. Хотите выигрывать наносекунды ? без проблем - платите из своего кармана, клиент точно не будет оплачивать такое колупание.
Если Вы не фанат метода "каждый девелопер собирает модуль на своём компе с хуй пойми каким энвайрментом, чтобы остальные охуели собирать его модуль когда он уйдёт в отпуск\уволится"
...
если Вы не фанат метода "каждый кодер ранит свой модуль в своём энвайрменте, а потом тестеры ебутся чтобы заставить его работать в связке с остальными модулями, каждый на своей машине с хуй пойми каким энвайрментом" - то нужны тестовые энвы.
Это п3 :)
Вы когда-нибудь пробовали толпе девелоперов давать рута на клиентских системах?:)
Это называется таким волшебным словом "квалификация специалиста". Их в нее входят как знание технических, так и организацонных приемов решения задач. Умение прогнозировать и деклариоовать ожидания своих решений. И самое главное правило - если ты не знаешь, прочти наконец инструкцию! Это может быть как техническая инструкция, так и административная.
Если ее нет - то ее нет.
Да, это делается через дженкинсы. Которые - сюрприз, надо поддерживать и как-то насетапить.
Сюрприз - прочти инструкцию! И если ты "настраиваешь дженкинсы каждый день", то ты не квалифицирован и "Убери свои руки от инструмента". Нет в нем ничего магического! Один раз настроил и .... все работает месяцами\годами.
Причем проверить совместимость в том числе с разными версиями других модулей.
Ну... если вы таким занимаетесь, то сюрприз - у вас сломаны "инженерные практики". Такие вещи проверяются на стадии дизайна решения, и в случае положительного решения, идут в разработку. Если у вас такое всплывает на стадии QA - мои соболезнования. Вас удивляет бухой сантехник пытающийся вкрутить шуруп в гайку? Но не вызывает изумление ИТ специалист делающий тоже самое, но с кодом ?
Я прекрасно понимаю, что сработавший "да фигня, заработает" может сэкономить денег подрядчику. А как же правило - кроилово, приводит к попадалову ? :)
Ой, кажется я только что описал работу девопс тимы, да?:)
Нет, это не работа devops тимы. Зто раздолбайство, которе плодят\потакают devops. Может я не видел нормальных DevOps, но ко мне еще ни разу не пришел Devops с вопросом -"Ты мудила! Где деплоймент план ? Какого черта нету требований под инфраструктуру решения ? Что с безопастностью ? Допиши бумажку, а потом мы приступим к работе" и т.д. Зато кучу раз видел - "Фигня вопрос, шас развернем...." ну и потом "извращенный секс" на тему "А чего это оно творит ? Какого ... оно падает рандомно ?" и на вопрос к DevOps "а какие соображения ?" слышишь ответ "а хз, надо траблшутить..." и т.д.
Вопрос инженерных практик - стоит очень остро. Карго культ - процветает, к сожалению. Почему-то считается, что покачать спеца за год - это дорого, но нанять 12 "обезъянок" за месяца - это дешевле. Быстрее ? да. Качественнне ? однозначно нет.
Shumsky90
02.11.2021 16:17отлично, аргументированный ответ.
Артефакты типа - ифраструктура\билды\девелоперы\DevOps и т.д. это просто инструменты достижения п1 в рамках п2 с минимизацией п3 и не более.
абсолютно согласен. Дженкинс для сайта на народе абсолютно не нужен, но нужен в более сложных проектах. Девопс специалист - аналогично: в веб студиях о 10 студентах на халфдей (образно говоря) он нафиг не нужен
Это называется таким волшебным словом "квалификация специалиста". Их в нее входят как знание технических, так и организацонных приемов решения задач. Умение прогнозировать и деклариоовать ожидания своих решений. И самое главное правило - если ты не знаешь, прочти наконец инструкцию! Это может быть как техническая инструкция, так и административная.
как показывает практика, человек может быть замечательным программером, но никудышним админом (если надо что-то поставить\изменить на рантайме).И временами дешевле держать специального человека для этих ченджей, а программер пускай лучше делает что умеет. Обычное разделение труда, как у стройбанов\в металлообработке\везде в производстве. Вы ведь не будете посылать токаря 5 разряда разгружать фуру со сталью?:)
Сюрприз - прочти инструкцию! И если ты "настраиваешь дженкинсы каждый день", то ты не квалифицирован и "Убери свои руки от инструмента". Нет в нем ничего магического! Один раз настроил и .... все работает месяцами\годами.
то-есть секьюрити апдейты мы опускаем? Опять таки: если у нас веб студия и 10 студентов на халфдей - то дженкинс один, и херли его там обновлять. Если у нас несколько выделенных дженкинсов (местами необходимо) - то секьюрити апдейт занимает уже не 5 минут, а 5*N минут, где N - количество дженкинсов (время с оговоркой, но мы ж не эффективная сова чтобы к этому придраться, сделав вид что не уловили суть?). Да и кроме дженкинса есть другие сервисы, которые в том числе нуждаются в мониторинге и апдейтах.
Ну... если вы таким занимаетесь, то сюрприз - у вас сломаны "инженерные практики". Такие вещи проверяются на стадии дизайна решения, и в случае положительного решения, идут в разработку. Если у вас такое всплывает на стадии QA - мои соболезнования. Вас удивляет бухой сантехник пытающийся вкрутить шуруп в гайку? Но не вызывает изумление ИТ специалист делающий тоже самое, но с кодом ?
то-есть тестирование продукта, состоящего из кучи модулей которые пилят разные люди на протяжении многих лет, не нужно?:) Всегда есть место для ошибки.
Нет, это не работа devops тимы. Зто раздолбайство, которе плодят\потакают devops. Может я не видел нормальных DevOps, но ко мне еще ни разу не пришел Devops с вопросом -"Ты мудила! Где деплоймент план ? Какого черта нету требований под инфраструктуру решения ? Что с безопастностью ? Допиши бумажку, а потом мы приступим к работе" и т.д. Зато кучу раз видел - "Фигня вопрос, шас развернем...." ну и потом "извращенный секс" на тему "А чего это оно творит ? Какого ... оно падает рандомно ?" и на вопрос к DevOps "а какие соображения ?" слышишь ответ "а хз, надо траблшутить..." и т.д.
ну таких инженеров дохера. Мы их называем "кожаные дженкинсы". Только в отличие от электрических дженкисов кожаные могут затупить и шото провтыкать :)
я-же говорю как раз таки про людей, которых Вы не встречали: который одной рукой раздаёт им оплеухи, а другой подтирает сопли если у программера случился фейл. Но этот человек встречается редко, ибо Вы правильно заметилиПочему-то считается, что покачать спеца за год - это дорого, но нанять 12 обезъянок - это дешевле.
это факт: почему-то большинство контор берёт админов, обучает их настраивать пайплайны\терраформы\прочие штуки, называет их "девопс" и они потом сами оверинжинириг 40 часов в неделю творят. Причем нафига - непонятно, если все можно сделать куда проще. Но "у нас есть процедуры и мы их повторяем в скриптах", вместо того чтобы просто изменять процедуры в сторону упрощения
random1st Автор
02.11.2021 17:21+1я хочу подчеркнуть - проблема не только в инженерных практиках - понятно что всегда есть разделение по компетенциям, кто-то делает одно, кто-то другое. Проблема в локализации DevOps практик ЗА ПРЕДЕЛАМИ КОМАНДЫ РАЗРАБОТКИ в первую очередь, а уже во вторую - в отсутствии этих практик в головах тех, кто пишет код.
pavel_shabalin
02.11.2021 21:08Никогда такого не было и вот опять.
Замените DevOps-a в тексте на "сисадмина который теперь ещё и Jenkins настроить может и в k8s по мануалу умеет" и все встанет на свои места.
И что в итоге получается: "мы" вам всё настроили, теперь "вы" с этим возитесь как хотите. Хочешь джоб для обновления бд? Напиши сам, глупый разработчик. Да, запустить и дебажить ты его не сможешь. Это будем делать мы. А ответственность будет на тебе. Ухахаха...
Тоже самое и "QA-ями". Нельзя просто так взять и тестировщика, подтянувшего юнит тестирование и прочитавшего "1001 способ описать один и тот же кейс", назвать QA-инженером.
Или "аналитики" которые ни на один вопрос ответить не могут. Ах да! Они же анализируют и решают важные бизнес проблемы. Никто же не говорил что они должны закончить до того, как будет закончена фича.
И все такие важные и нежные. Как говорит моя бабушка: "кошка н'агрудь не вступи".
random1st Автор
03.11.2021 14:12справедливости ради надо отметить что и в другую сторону тоже плохо работает. "Я написал" - "Не могу запустить" - "На моей машине все работает".
uyrij
03.11.2021 00:03Написано как бы гладко, но зачем всё - непонятно, с положительной точки зрения ????
ramiil
Девопс это когда под лозунгами стандартизации и упрощения разворачивания приложений создаётся множество прослоек и раздуваются штаты инженеров. И если в случае очень большого Ынтерпрайза это имеет смысл, то когда девопсом обмазывается всякая мелочь... мартышка и очки.