Pull to refresh

Comments 109

Девопс это когда под лозунгами стандартизации и упрощения разворачивания приложений создаётся множество прослоек и раздуваются штаты инженеров. И если в случае очень большого Ынтерпрайза это имеет смысл, то когда девопсом обмазывается всякая мелочь... мартышка и очки.

Прочитайте определение DevOps из вики

Методология активного взаимодействия специалистов по разработке со специалистами по информационно-технологическому обслуживанию и взаимная интеграция их рабочих процессов друг в друга для обеспечения качества продукта.

Вашу ж мать! Где здесь DevOps- инженеры?

А кто будет выстраивать методологию?

В истории с кранами DevOps-инженер - это не дядя Вася из ЖЭКа, а человек, придумавший сетку стандартных размеров труб и кранов.

Тут нет человека. Тут есть культура стандартизации, понимаете? Не сетка размеров, а сам подход

Но кто-то же должен придумать сетку. Конкретные размеры. Тут без человека пока не обойтись.

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

без человека можно, нельзя без подхода. Если в производственный цикл заложено...

Откуда подход возьмется? Кем заложено? Не человеком?

Сетка размеров сама по себе возникнет...

И будут у нас размеры 5.51, 5.52, 7.(3) - просто потому, что кому-то захотелось их внести.

ну мы например используем дифференциальные уравнения при расчетах - нам нужен математик в штате? Или математическое образование aka культура у исполнителей?

Если вам хватает методов, разработанных другими математиками - нет. Если существующие методы не подходят - да.

Исполнителя, умеющего решать дифуры, вряд ли кто-то назовет гуманитарием.

если вам в массовом производстве - а я веду речь именно о нем - не хватает математики, то математика должна быть частью инженерной культуры. За МЛ мы сейчас не ходим в университеты - у нас есть технологии. Но кроме технологий должны быть знания в головах тех, кто эти технологии использует - и это и есть культура инженера. Раньше если я занимался производством или обслуживанием аппаратуры я должен был понимать как она функционирует. А сейчас процветает не культура, а культы - подобные культу карго. И здесь ничего не решает наличие выделенного "шамана" - девопса.

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

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

И здесь ничего не решает наличие выделенного "шамана" - девопса.

Если девопс действует на уровне шамана, может, не стоит его называть инженером? Может, он и не devops вовсе, а простой внедренец? Тот самый "специалист по информационно-технологическому обслуживанию"?

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

Еще раз: тот, кто действует ТОЛЬКО в рамках шаблонов - не инженер, а техник, в лучшем случае. Такой человек, действительно, нужен только в очень редких случаях - когда не работают механизмы коммуникации.

Но это не работа девопса.

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

у меня есть стойкое впечатление, что я просто вторгаюсь в ваш уютный мирок того самого инженера - DevOps'а? :)

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

О чем статья я понял. Но понять не значит согласиться. В некоторых случаях такой человек может быть полезен.

у меня есть стойкое впечатление, что я просто вторгаюсь в ваш уютный мирок того самого инженера - DevOps'а? :)

Ни в коем случае.

Как-то я поторопился ответить. Да, сама доставка должна быть частью работы разработчиков. Или внедренцев. Это не важно.

Работа девопса не в самой доставке, а втом, чтобы ее наладить. В том числе, внедрив некоторые стандарты.

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

И для наладки непременно нужна команда, которая будет этой наладкой заниматься? Или этим вполне могут (и даже должны) заниматтся те, кто собственно доставку осуществляют? Как-то не вытекает одно из другого.

Это ззависит от масштабов. Если есть одир разработчик и один внедренец - вряд ли.

Могут таким и разработчики заниматься. Если у них нет более полезных занятий.

А что, доставка пользы, не расплескав, к конечному потребителю - это прям совсем бесполезное занятие? Ну я на такую ересь не замахивался, сейчас вы вообще скажете что DevOps как таковой не нужен)

Бухгалтерия тоже очень полезное занятие. Вы предложите и этим заняться разработчикам?

Каждым делом должен заниматься максимально узкий специалист. Можно в одиночку ваять фронт и бэк, если это пет-проект. Но Вы же не будете говорить, что и коммерческие продукты должны так же производиться?

бухгалтерия не живет внутри разработки продукта. Фронт и бэк тоже - они каждый делают свою часть. Я говорю о том что от начала разработки до эксплуатации - этот ответственность одних и тех же организационных единиц, если быть буквальным. Как сюда бухгалтерию прикрутить?

Я, здесь в США, не перестаю удивляться. ГОСТ нет, система метрическая только в лабораториях и больницах, десятичные дроби не в ходу, но все ко всему подходит! То есть сетка таки образовывается. И вилки подходят к розеткам, купленный вчера светильник садятся как влитой на гнезда которые поставили в стену 30 лет назад. Лучшие практики и война стандартов как она есть.

А сколько времени эти стандарты развивались? Сто лет? Вы готовы потратить 100 лет на стандартизацию внутри своего коллектива?

Это красиво выглядит для розеток и кранов. А посмотрите, что творится сейчас в области стандартов более современных. Те же разъемы для зарядки смартфонов только только становятся стандартными. А стандарты в ПО?

Да, каждая система стремится к самосохранению и девопсы тоже, но...
Большая часть программистов не разбираются в той среде, под которую они пишут программы, я имею в виду операционные системы(Linux, Unix, Windows, не имеет значения), про сети и какой-то уровень безопасности, даже говорить не приходится и кто-то должен заставить все то, что граждане программисты написали функционировать и фактически создать производственный конвеер для разработки и тестирования программного продукта, а также для обозначения зон ответственности.
Еще нужно объяснить особо несознательным личностям, почему это может работать так, а не иначе, исследовать ограничения тех программных продуктов(библиотек, баз данных, и.т.п), на которые они опираются, стандартизировать рабочие места и процесс разработки, построить архитектуру.
Вы серьезно считаете, что Дядя Вася справится?
Ну, если он учился в институте городского хозяйства и умеет проектировать сети городской канализации, водопровода и прочих коммуникаций, то возможно, а если нет... Привлекайте Дядю Васю и молитесь...

Если продолжать аналогию с дядей Васей - я не говорю что дядя Вася совсем не нужен. Я говорю, что если считаете что он нужен - так пусть он на заводе со всеми работает, и разделяет ответственность за продукт, а не на себя работает и свои интересы, но почему-то за деньги завода.

А разве не все работники на заводе работают на себя и ради своих интересов?

Людям на работе дают материальные и нематериальные стимулы для того, чтобы они исполняли те или иные роли. У людей одни интересы, но мы же не Васю Пупкина нанимаем, а исполнителя роли инженера например?

сорри, но нет. DevOps приходит и настравиает конвейер и цепочки, а само наполнение конвейера и цепочек (из чего оно состоит) - придумывают кто-угодно но не devops-ы: разрабы, когда говорят, что хотят bitBucket, а не gitLabs, инфо-безы, когда говорят, что обязательно надо SonarQube со своими свистелками, админы, когда говорят, что нафиг ваш k8s, прод будет на OpenShift и т.п. а DevOps-ы с грустной миной "ну ок" и пошли пилить, то есть фланец на 1 и 1/4 и левой резьбой искать.

все правильно. Именно о таком пессимистичном сценарии я и говорю. В "правильном" DevOps учитываются требования к скорости изменения и доставки продукта, а согласование процессов, набор технологий, и прочие договоренности - это результат коммуникации команд разработки (производства) и эксплуатации (админов). Иначе возникает такой человек-прокладка, который якобы методолог, а по факту блокер.

к вашей тираде (статье) тоже комментов много ) практика показывает, что нужен кто-то между дев и опс, кто поможет и тем и другим, чтоб все работало четко, быстро и прогнозируемо. Это и есть практики devops и культура и люди их воплощающие. В сильно большой организации, когда девам и админам нет времени все это настраивать и выстраивать проще нанять людей, можно в дев, можно в опс, а можно их выделить в отдельную структуру и обозвать девопс. суть в том, чтоб две шестеренки крутились лучше и нужна не прокладка, а смазка. а так, в целом да - наверное и админы с этим справяться, просто дайте им время и ресурсы. Да и разрабы, но им немного непривычнее в тоннах конфигов копаться (простите, я все эти ansible-playbook-и и прочие deployment-ы считаю конфигами)

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

Дык вам к начальству нужно идти, а не на хабр, приведите им пример о сантехнике Васе. Девопсы - люди в основном подневольные - делают то, что их просят. В моменты, когда они хотят как-то улучшить/изменить процесс, - все обижаются и бегут жаловаться.

Революции не делают одиночки) Между прочим вот эта статья мне очень помогла в аргументации своей позиции

Что именно "нет"?

"Нет, не надо выстраивать методологию"?

"Нет, это делает не человек"?

"Нет, DevOps-инженер (инженер!) - это дядя Вася из ЖЭКа"?

перестаньте вести себя как бестолковый тролль. Сорри, но нет, не девопсы придумывают эту "сетку".

Тогда кто?

Только, пожалуйста, без тупого перехода на личности.

Что возникает раньше - требования к унификации или сетка размеров? Ваш человек, придумавший сетку - это такой аналог Бога. "И только дух божий парил над волнами". Правильный ответ в том, что нам извините, наплевать на то, кто придумал, зачем и прочие заморочки - мы могли практику стандартизации взять со стороны, изобрести сами, она нам могла присниться. Просто потому что это часть нашей инженерной культуры, образования если хотите - мы как инженеры осознаем пользу стандартизации. Сетка - это РЕЗУЛЬТАТ применения подхода, нет никакого резона ее придумывать. Если вы сядете на песок, и на нем останется след - вы же его не рисовали специально, это следствие того, что у вас есть телесная практика отдыха сидя. А вы причину со следствием путаете. Так понятнее?

Что Вы называете "требования к унификации"? Общее пониманиеее необходимости или конкретные требования? Если второе, то непонятно почему Вы отказываетесь включить в них условный "размер сетки". Если первое, то это ни о чем - те самые благие намерения, которые известно куда могут пригодиться.

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

И не зацикливайтесь так на сетке. Она всего лишь пример. Как и Ваш "след на песке".

Вы вообще не поняли суть статьи. Я говорю о том, что DevOps не живет вне разработки, и если у вас есть DevOps - он проходит через Development в Operations. И выделенная организационная единица если хотите - не человек, а команда из одного и более человека, она ущербна в принципе, потому что у нее в фокусе не система в процессе принесения пользы, а некий пресловутый DevOps, под которым каждый понимает свой набор технологических шаблонов. Делаем CI/CD, описываем инфраструктуру терраформом, камлаем - ай какой хороший у нас девопс.

Мне кажется, это Вы не понимаете суть работы девопс-инженера.

Девопс должен настроить взаимодействие, а дальше оно уже должно работать без него.

Ну я такой картины никогда и нигде не наблюдал. Скорее наблюдается то, что devops команда/инженер/оргзвено отгрызает себе кусок ответственности за доставку изменений, и плотно на ней сидит. Влажные мечты оставим за кадром. Я не ставлю под сомнение задачу организации процесса доставки. Я говорю о том, что выделенная devops команда это зло. Из вашего комментария следует, что ее вообще можно уволить после наладки процесса - т.е. после того как его будут поддерживать разработчики. И вот получается что в принципе вы о том же - что после запуска процесса разработки devops инженер не нужен)

Из вашего комментария следует, что ее вообще можно уволить после наладки процесса - т.е. после того как его будут поддерживать разработчики.

Вы, может быть, считаете, что и сисадмин не нужен, если все работает?

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

https://ru.wikipedia.org/wiki/V-Model -посмотрите сюда и сами догадайтесь где живут devops практики.

Сисадмин - как пример "ненужного" персонала. Некоторые именно так и думают - зачем платить сисадмину, если все работает? Продукт здесь ни при чем.

...где живут devops практики

Вы уже перестали называть их инженерами. Это прогресс.

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

А, в этом смысле.

Впрочем, возможно, это я неправильно понимаю кто такой девопс. (По принципу: "правильное мнение - мнение большинства".) В таком случае, Вы, конечно, правы и такие люди не нужны.

А как обстоят дела с унификацией в разработке? Вижу, что не очень. Сколько там языков программирования и фреймворков?

Ее нет нигде. Мир - это плюрализм идей.

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

Ну так посмотрите сколько существует архитектур цпу и как там работают фреймворки, если они есть. Посмотрите на разнообразие дистрибутивов Линукс.

Есть стандартизация где собираются комитеты и вместе договариваются или что-то идёт в мейнстрим как архитектура цпу. Например производители железа. Или вы думаете соберётся Девопс комитет и разработает схемы деплоя?

Если поглубже погрузиться, то это мода на "барабаны Страдивари". Ситуация аналогична внедрению SAP, когда вместо подбора инструмента под задачи выбирают задачи под инструмент.

Мода есть а вот сравнение с SAP не совсем корректное. Когда покупают ЕРП, платят не только за софт, Верне не столько за софт как за практики и процессы. И если компания покупает SAP тоько как супер Эксель - результат соответствующий.

Откуда возмется "инженерная культура", если ее никто не "воспитывает"? ..да и инженеров тоже: https://habr.com/ru/post/233851/

Кому нужны эти проверки ценности идеи / можно и без высшего образования / главное чтоб работало / тяп-ляп и в продакшн...

Возможно кто-то и воспитывает, но системно, в массовом порядке - нет. В библиотеке много полезного и интересного, но кто ж туда ходит?

https://youtu.be/8oBiybIPVGk?t=1376

Любой "нормальный" инженер стремиться все стандартизировать и свести к готовым решениям. Если нет, то это "герой". А от героя всем вокруг сплошь проблемы. Почему? Потому как поддерживать решения энтузиаста который: "devops это взаимодействия для обеспечения качества....." не возможно без самого энтузиаста. А энтузиасту что, он накостылял, навоял нетлеку и пошел дальше.

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

Вы так пишите, как будто: " ограничении решений набором готовых шаблонов" это что-то плохое. Ограничение решений набором готовых шаблонов позволяет прогнозировать риски, создавать стабильные, предсказуемые по срокам и затратам, дешевые, поддерживаемые системы.

Не нравится? Наймите себе "творца". Это будет дорого, не предсказуемо и не поддерживаемо, но зато без всяких неосознанных ограничений.

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

Все, что за пределами шаблонов, это НИОКР, с соответствующими рисками и стоимостью.

не подрезайте мои аргументы, я говорил о "неоправданном и неосознанном" ограничении - просто на основании все так делают и раньше я так делал, и дед делал, и вон парни из той компании так делают, а остальное все от лукавого.

Так я вам и отвечаю: "Не бывает неоправданного и неосознанного ограничения решения набором готовых шаблонов".

Не мешайте в кучу НИОКР и производство и будет вам счастье. Производство это шаблоны, любой отход от шаблона по умолчанию не оправданный.

Бывает, и я неоднократно с этим сталкивался. Ваш НИОКР (который собственно об RnD) в производстве ПО предельно близок к основному циклу производства. Сегодня вы потыкали технологию, а завтра она улетела в продакшн. И тут важно осознанно понимать, почему та или иная технология подходит. В случае выделенной роли девопс-инженера он страдает шизофренией. Обычный пример из жизни - когда девопс-инженера делают крайним и за доставку изменений в продакшн, и за саму эксплуатацию. В этом случае он естественно ограничивает набор возможных решений просто потому, что его мало и он блокер. Это именно то, что я называю неоправданным и неосознанным ограничением - если хотите, рефлексией на возрастающую технологическую сложность.

Сегодня вы потыкали технологию, а завтра она улетела в продакшн.

Это называется х.... х... и в продакшен.

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

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

Это зависит от того, насколько бизнес вообще жизнеспособен без такой скорости изменений в продукте. Я не знаю ваших там методологий, я знаю что надо обычно вчера - и чем быстрее изменения в продукт долетят тем лучше. Что касается оправданности и осознанности -он блокер потому что у него нет радостного интереса внедрять новые технологии. Вообще никак - он выделенный товарищ(команда), которая отвечает только за доставку изменений и зачем ему новые технологии если и так все работает? Ему не за это платят. И таким образом с его точки зрения он все делает правильно, но в целом он вредитель.

Держу пари, что досконально изучить все особенности работы какой-нибудь postgresql куда сложнее, чем концепт работы с k8s.

Возможно именно поэтому средний девопс старается держаться подальше от более-менее нагруженных СУБД. Для них куда сложнее придумать «ритуальные приседания» :)

Дело в том чего хочет бизнес. Бизнес хочет кубенетис - все учат кубернетис.

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

Мой опыт показывает примерно обратное — инструменты и процессы разработки/эксплуатации в нормальных компаниях выбираются и выстраиваются исходя в первую очередь из технических аспектов и экспертизы инженеров.

Откройте какой-то агрегатор вакансий и посмотрите что там просят.

Все верно в статье, раньше команды договориться не могли, админы с разработчиками
Теперь есть виноватый во всем девопс =))) это он должен был их всех договорить и настроить как они хотят. Заставить согласованно работать админа и разработчика это и есть девопс, чтобы конвеер работал и склад не пустел, и бизнес был от прибыли доволен

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

В каком учебном заведении учат на этого вот DevOps'а?

в каком учебном заведении могут учить на специалиста по пусконаладке программного обеспечения?

ну наверное должны там же где учат это ПО писать, нет? Иначе какой смысл писать то, что мы не знаем как отправить в эксплуатацию?

Я понимаю что я часть проблемы, т.к. работаю девопсом в кровавом энтерпрайзе, но в моем опыте очень редко дев команды говорят "стоп а давайте сейчас пересмотрим все узкие места, доделаем CI нормально наведем порядок в кодовой базе, посоветуемся с другими командами может они уже решали проблемы как у нас и.т.д.

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

Конечно, культуру развивать надо, но сама по себе она не не придёт (все пацаны, завтра выучим ансибл, и заживем!) , надо организовать тренинги, планерки, работать с людьми... Это организационная дыра куда уходит много времени и сил чтобы допустим деплоить не 4 а 6 раз в день.

смотрите, все что тут описано звучит как "бла-бла-бла" или танец шамана с бубном. Придет шаман, покамлает и все станет хорошо. С каждым нужно говорить на его языке. Для бизнеса DevOps практики приносят ускорение увеличения полезности продукта - за это он будет платить. Разработчики не видят ценности только потому, что им этой самой культуры не хватает. Так она и не возникнет, если кто-то будет делать DevOps за них, при этом еще и ответственность за доставку в эксплуатацию на себя забирая

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

Ну и край это инфоцыгане и всякие админы с комплексом вахтера. Но таких немного.

ДевОпс это монетизация опенсурса за счет намеренного повышения сложности системы, ускоения ее мобильности, и занятости опенсурсников на зарплате у энтерпрайза. Можно обфусцировать код, можно просто повесить лицензионный замок, можно написать такую монстру, и так часто веосить изменения, что бы в одну голову не влазило. В мутной луже больше золота, по завернию Флинта, Били Бонса, и Слепого Пью.

Не в бровь а прям в глаз. Нас гнать в шею надо, на гитхабе качем, стаковерфлоу читаем, а нам еще деньги за это платят! :) А если серьезно, то да, хайп есть, и очень много людей бездумно делает то что им сказали а Гартнер репорте.

На самом деле слегка обидно за дядю Васю, как стереотип работника руками.
И из-за вот такой вот аналогии мне кажется, что все аргументы( с которыми я отчасти согласен), умножаются на 0, так как нет элементарного уважения к другим. И сквозь строки статьи читается: "Все <censored>, а я — д'Артаньян", отсюда степень доверия к статье, к сожалению, падает.

ну не надо за дядю Васю обижаться. Дядя Вася нашел свою нишу - и прекрасно себя в ней чувствует. В разработке ПО нам дядя Вася как раз не нужен - мы живем в другом технологическом стеке, и нам не нужен такой вот посредник. А где вы подобное вычитали - я не понял, честно говоря. Я всегда пишу не о людях, а о ролях. Если вас коробит дядя Вася - могу заменить на Super Mario, суть от этого не изменится.

К сожалению, я не корректно выразил мысль, за что искренне прошу прощения.
Сейчас попробую сформулировать более точно.
Вы описали проблему, и эта проблема действительно имеет место быть, так как является тем самым рычагом спобоным свести на нет процессы разработки, тем самым порождаю тонны техдолга.
Так вот, я хотел отметить, что было бы лучше, если бы вы формулировали мысли несколько более корректно, что показывало бы вас как настоящего профессионала, коим вы и являеетесь. И эффект от вашей статьи, как мне кажется был бы больше.
Опять же, видимо тут начинается диалог с самим собой, вы индивидуальны и ни в коем случае ни мне, говорить вам что писать, и как писать. Я просто выразил свое наблюдение.

Спасибо, на самом деле это скорее затравочная статья, и несколько провокационный ее тон является всего лишь средством вызвать дискуссию)

Отчасти согласен. С другой стороны. Разрабам за настройку ансибла не платят. А если они будут его настраивать то через год станут девопсами.

Это может проканать в компании на 5 человек. Когда ты и швец и жнец. В крупных компаниях же одно только изучение всех требований безопасников займет несколько месяцев.

А через пол года выйдут новые стандарты.

простите, ансибл уже давно не тренд. Сейчас практики DevOps живут в k8s, и даже терраформ чувствует себя несколько напряжно, поглядывая на всякие pulumi/cdk. Но это опять не про то

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

Это уже проходили - толку от этого ноль


Ну начнем с во-первых. Развитие компетенций - это первое с чего начинается внедрение новых технологий. Это прямо то, с чего должен собственно начинаться DevOps. Дальше, насчет копипаста - все копируют, все не делают нормальную документацию, все торопятся. Дальше - не хотят разгребать. Скорее тоже не хватает культуры понять, что отдача техдолга, как и создание его - это нормальный производственный процесс. Ну и тут скорее компетенция технического менеджмента важна. Как я бы сказал, плохо можно сделать все, что угодно.

UFO landed and left these words here

Проблемы, на которых я фокусируюсь, две 1) это разделение ответственности за доставку продукта между орг-единицами, из которых одна разрабатывает, но не ответственна за доставку и эксплуатацию, а вторая отвечает исключительно за доставку, всецело наплевав на все остальное. "Такой devops нам не нужен"(с). 2) Это ограничение технологического стека - потому что мы вынуждены весь стек подгонять под компетенции каждого звена в цепочке. Проще говоря, разработчики умеют в Docker, а DevOps инженеры в kubernetes, и этим живут, находя здесь точку сопряжения. Проблемы возникают, когда начинаются велосипеды - и например разработчики не используют SaaS - ибо ничего о них не знают, а даже если знают - у devops-команд нет никакого интереса эти сервисы использовать, а в свою очередь devops команда не пытается адаптировать код, чтобы выстроить интеграцию, если появляются новые возможности с той стороны - просто не умеют в код.

Проблема решается просто - когда вне зависимости от компетенций все отвечают за доставку от старта разработки до запуска в эксплуатацию и саму эксплуатацию.

UFO landed and left these words here
  1. Да, но платит за весь этот бардак владелец бизнеса, а пользу приносим конечному потребителю. Да и в конечном счете разработчик, работающий в неэффективном бизнесе, рано или поздно вынужден будет уйти. Как мотивировать разработчика работать на бизнес давайте обсуждать не будем - у каждого свои интересы

  2. Опять же - правильный интерес - меньше магии, больше возможностей для бизнеса. Я не говорю о том, что надо кидаться в крайности и заиспользовать все подряд.

  3. Нет, так не работает. Тот же AWS формирует SaaS исходя из использования - берет низкоуровневые сервисы и объединяет в высокоуровневые, в их объединении находя новую, эмержентную функцию. А все юзкейсы ни один клауд провайдер предусмотреть не в состоянии.

UFO landed and left these words here

Вероятно надо шатнуть этот храм.

С добрым утром. Уважаемый автор, поздравляю, вы только что открыли суть всех работников нашей индустрии. Agile-цыган, консалтеров, архитекторов, разработчиков, тестеров и тд.

И все они - такие же Васи пусконаладчики.

Но да ладно. Внезапно, не "DevOps" инженеры решают хоть что-то. Кубернетесы, докеры и прочие радости жизни решают внедрять еще более пусконаладочные Васи - архитекторы и Васи - руководители IT.

И не DevOps инженеры решают внедрять культуру или не внедрять культуру. Это делают кто?Правильно. Васи - agile цыгане пусконаладчики.

У нас не могут существовать культуры. Мы жители СНГ, у нас другой менталитет. А то что называется культурой - чаще будет лицемерной занавеской. Где все по старому. Почему?

Потому что культура требует "САМОДИСЦИПЛИНЫ" и "ДОВЕРИЯ". А этим наш менталитет не страдает.

Поэтому в итоге IT - как бабки с очередным бадом. Был БАД Agile - пришел БАД DevOps.

Могут существовать DevOps отделы. Могут быть Agile отделы. Можно сделать реально все что угодно. Можно конфигурировать, как угодно в каком угодно виде разные специализации. Итог один. Для всего нужна внятная цель. Не имея внятной осознанной цели, можно говорить про любые специальности, как про Вась. Особенно про архитекторов. Там иногда Вася на Васе.

Поэтому прежде чем писать о криках души - сначала все же рекомендовал бы остановиться. Не Америку открыли. И не убедили, что таблетка это не создавать DevOps отделы или делать из разработчиков админов - автоматизаторов. Они будут подвержены тем же законам Конвея, когда начнут становится и швецами и жнецами и на дуде-дудедцами.

Очень классно этот принцип пихать везде где можно. Любят у нас "Закон Конвея". Пугают им, как страшной сказкой на ночь. Только закономерный вопрос. А автоматизация что...разве не продукт внутри продукта?)Это разве не отдельная система? А конвеер на заводе, который передвигает болванку от одного станка до другого, разве не сложное инженерное решение, которое создано, разработано, и уже только потом "ПУСКОНАЛАЖЕНО"? Уберем devops отдел, и? Поставить devops коуча, который будет забирать тонну времени разработчиков, чтобы их научить, поставить, их руками наладить? А дальше через 5 лет имеем зоопарк систем, которые обеспечивают работу разработчиков, но их поддержка стоит столько, сколько не хочется даже на слайдиках смотреть.

Ну и в конце концов. Энто што за глупости такие. Расскажи вы сейчас всему миру, что надо делать хорошо и качественно - вас быстро умолчат)

Принципы затоваривания рынка работают и в ИТ. Делать качественно не выгодно никому. Все без работы останутся. Поэтому да. Будут продукты внутри продуктов, отсутствие инженерной культуры. Потому что круговая порука. Васи-исполнители делают плохо, потому что тем же Васям-средним прокладкам между исполнителями и дальше требуется докладываться наверх, рассказывать как все плохо и менять Васей-исполнителей на других. И еще нанимать Васей-консалтеров. Те же Васи, которые факапят проекты, должны иметь виновных, чтобы продолжать сосать деньги из заказчиков. Это закон рынка. Он одинаков для всех.

И удивляться и писать громогласные статьи из разряда "Agile не оправдал!" "Долой DevOps!" - из разряда набивания кармы.

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

Ни разу не удивлюсь. И даже знаю кем и как должны были стать DevOps инженеры. Но только рынок живет по своим правилам. И компании которым нужна культура - они и так поймут, что надо сделать. Те самые 0.01 процентов компаний поймут, что внедрять и как. А остальные 99.99 будут жить по законам рынка.

А написать взрывной пост и я могу.

"Долой DEVOPS!" "Во всем виноваты DevOps отделы!"

Пишите, с удовольствием посмотрю, как вы аргументируете.

Аргумент простой.

Есть системы обеспечивающие автоматизацию. Их надо поддерживать, их надо обновлять, и саму автоматизацию надо дорабатывать. Постоянно. Внезапно!

Потому что у автоматизации нет конечной точки. Ибо из-за постоянного изменения технологий - автоматизация постоянно будет дорабатываться. Так же как и с ростом любой системы.

Разработчик не будет поддерживать обновление систем и конвеера. Ему писать код надо. Ему нужно дать кнопку. Потому что траты на "обучение разработчика" вместо Васи пусконаладчика, гораздо больше, нежели Вася-пусконаладчик.

Хорошо, уберем команду DevOps. Оставим по одному Васе. Вот у нас контора. 100 команд, 10 тыщ человек. 100 команд в, каждой по Васе. 100 команд поставили...100 дженкинсов. 100 дженкинсов съели...100 виртуальных машин. по 2 ядра и 4 оперативы....Организация только что выкинула в воздух деньги на стойку, работу инженеров, сетевиков, подключение, закупку доп лицензий на оборудование. Это уже не сотня тысяч. И не 5. И даже уже не 10

100 дженкисов требуют....постоянных обновление и проверок инфобеза. Потому что внезапно они сами по себе дырявые. 100 дженкинсов требуют....тонну документации у администраторов, потому что они вынуждены знать, что за инструменты стоят на виртуалках. А еще десятки тысяч сетевых правил (куда же без этого)

Далее следим за руками. 100 Вась - devop ушли из всех 100 команд. Документации естессно не оставили. Дальше загадка. Где первое узкое горлышко, которое зарубило компании и разработке всю работу и поставило их на грань траты миллионов?) Правильно, чертов пароль от виртуалки. По закону жанра, он у девопса, и девопс свалил вместе с ним.

Хм. А что если разработчики - уникальные и прошаренные. Этакие супермены. Убираем Васю.

100 команд разработчиков развернули на коленке под столом у себя на компе 100 дженкинсов....

Круг замкнулся.

Если сюда еще привязать реалии agile - то получается костыль на костыле. Все тоже самое.

И в итоге - статья больше похожа на призыв - давайте сделаем человека отделом разработчика, вместо человека - отдела devops. Забывая, что уровень разработчика сейчас не выше уровня Васи. Что Вася разработчик гавнокодит, что Вася девопс.

IT изначально не умеет в нормальное производство. Каждый божий день оно пытается придумать свое, потому что всем нужно кушать. Вместо того чтобы налаживать производственный офис - оно взваливает все на проектный. Вместо того, чтобы внедрять просто культуру из простых тезисов - компании проще менять людей. Внезапно. Потому что толпа возомнивших себя не бог весть чем разработчиков, архитекторов, девопсов - всего лишь такая же толпа на заводе. Просто пока с вольностями. И это такие же винтики, которых просто менять достаточно. Особенно с нашим менталитетом.

Проблема только в том, что ресурсы инженера ограничены.
И если он выучит условный ansible, то за то же время не выучит чего-то, что на его непосредственную работу влияет сильнее.
А так да, в идеале, конечно, чтоб все инженеры были полными fullstack еще и в каждом направлении были гуру. Но так не бывает за разумные деньги, вот ведь в чем засада.

во-первых, там уже давно нет никакого rocket science, и мне странно слышать, что знание инфраструктуры опционально для инженера. Во-вторых, ну еще раз повторюсь - я не против наличия DevOps инженеров в команде, я против того, чтобы они представляли собой выделенную организационную единицу.

Да во всем ИТ уже нету никакого RS
Но все равно на это надо тратить время. И не просто так один раз, а обновлять знания за изменением инструментов.

сразу видно эффективного менеджера, который не понимает всю суть работы девопса (ну и как эти тимы образуются).

простой пример:
имеем несколько тим девелоперов, несколько тим тестеров. Для их работы что нужно? Правильно: инфраструктура. Которую нужно как-то поддерживать. Видал я как программеры пытались в сетевые задачи, особенно доставила фраза "ну да, у нас задержка выросла в 3 раза. С другой стороны это все раво 120мс, что пофиг". У чувака на нулевом траффике задержки в 3 раза выросли, а его это не волнует ваще :) но то такое.

Если Вы не фанат метода "каждый девелопер собирает модуль на своём компе с хуй пойми каким энвайрментом, чтобы остальные охуели собирать его модуль когда он уйдёт в отпуск\уволится" - то нам нужна компиляционная инфраструктура.
если Вы не фанат метода "каждый девелопер работает со своей базой данных из под рута, правя системные параметры на лету" - то нужны несколько дев.баз данных.
если Вы не фанат метода "каждый кодер ранит свой модуль в своём энвайрменте, а потом тестеры ебутся чтобы заставить его работать в связке с остальными модулями, каждый на своей машине с хуй пойми каким энвайрментом" - то нужны тестовые энвы.
Методика "каждый программер деливерит свой модуль сам" охуенная, да. До тех пор, пока у Вас не появляется количество тестеров, отличное от 1 человека на халфтайм. Которым нужно в день потестить разные ветки\версии\билды\как оно у вас называется. Причем проверить совместимость в том числе с разными версиями других модулей. Да, это делается через дженкинсы. Которые - сюрприз, надо поддерживать и как-то насетапить.

про клиентские энвы я вообще молчу: Вы когда-нибудь пробовали толпе девелоперов давать рута на клиентских системах?:) Нет? Тогда рекомендую дать человекам 15-20 рутовый доступ на клиентах и пускай они сами деливерят. Гарантирую много положительных эмоций от клиентов :)


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

ну вы на личности пожалуйста не переходите, и пальцем в меня не тыкайте, я в IT можно сказать уже лет 20, и потрогал очень многое. К тому же мне претит ваш стиль общения, мат на мате - это для усиления аргументации? Я понимаю, что ваша позиция это позиция типичного "девопса", но я с вами диалог вести и не хочу - не интересно, заранее понятен интерес и какую точку зрения будете защищать.

обычный рабочий стиль общения, не более.Или хотите сказать что коллеги не охуеют при попытке повторить конфиг энва Василия, в котором он поставил патченый openssl пол года назад, благополучно забыл про это и потому у него все было норм, но больше его модули сбилдить никто не смог (реальный случай кстати)?

Что лет 20 - то без вопросов. Но в комментах выше было Ну граничные случаи меня менее всего интересуют, однако сами-же скатываетесь к граничному случаю: небольшие тимы, 2-3 модуля в продукте, так? В них да, отдельно взатый девопс как таковой не нужен, а программеры сами и оттестировать это все смогут. Тут без вопросов, одозначно.

Некоторое время назад я работал в довольно таки крупной компании, так там один продукт состоял из десятка модулей, которые должны были активироваться в зависимости от потребностей клиента и, в том числе, интегрироваться с другими программными продуктами. Просто для справки хочу уточнить что этот конкретный продукт пилило порядка 200 человек, плюс смежные продукты (порядка 7 основных + десятка полтора второстепенных), плюс армада тестеров. И это не прямо какой-нибудь фейсбукоайбиэм, это средней величины контора, коих дофига.

это я к чему: тестеры в день реквестили по 2-3 конфигурации каждого энва (ибо тестеров на данном конкретном продукте было около 40 человек), дабы проверять разные билды разных продуктов на совместимость с новым билдом). Энвов только для этого софта было порядка 30 штук. Да, есть дженкинсы, но за ними тоже нужно следить, как ни странно. Да и пайплайны не сами по себе зарождаются, удивительное дело.

а теперь представим как толпа программеров (ну ладно, 2-3 программера из разных локейшенов) одновременно заходят на энв и начинают запускать апдейты базы, деплоить все ручками, ибо дженкинс не отработал а ему сейчас лениво разбираться что не так, и вообще производить разные манипуляции. Какова вероятность того, что что-то пойдёт не так?:)

и нет, я не девопс, однако некоторое время был сисадмином, потому в курсе событий что и как у них происходит. Но всё понятно по фразе:
Я понимаю, что ваша позиция это позиция типичного "девопса", но я с вами диалог вести и не хочу - не интересно, заранее понятен интерес и какую точку зрения будете защищать.

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

ваше мнение мне неинтересно, потому что вы не поняли суть статьи, и следовательно, отвечаете мне в духе "я про Фому, а он про Ерему", а не потому что не правы.

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

не правильно :) Для их работы нужны всего три вещи:

  1. требования - Что от нас вообще хотят ? что мы вообще хотим сделать и зачем?

  2. критерии приемки - как мы будем доказывать, что то что мы сделали, именно то что ожидал бизнес. За что мы деньги берем?

  3. Что нам может помешать выполнить ожидания п1 в рамках п2 ? Где и кто может "накосячить" и на кого вешать "косяки"?

Артефакты типа - ифраструктура\билды\девелоперы\DevOps и т.д. это просто инструменты достижения п1 в рамках п2 с минимизацией п3 и не более.

"ну да, у нас задержка выросла в 3 раза. С другой стороны это все раво 120мс, что пофиг"

Хоть почтовыми улитками на глиняных табличках с клинописью пусть пакеты доставляются. Укладывается в критерии приемки ? Критерий разумной достаточности соблюден ? Ну болт на задержку. Хотите выигрывать наносекунды ? без проблем - платите из своего кармана, клиент точно не будет оплачивать такое колупание.

Если Вы не фанат метода "каждый девелопер собирает модуль на своём компе с хуй пойми каким энвайрментом, чтобы остальные охуели собирать его модуль когда он уйдёт в отпуск\уволится"

...

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

Это п3 :)

Вы когда-нибудь пробовали толпе девелоперов давать рута на клиентских системах?:)

Это называется таким волшебным словом "квалификация специалиста". Их в нее входят как знание технических, так и организацонных приемов решения задач. Умение прогнозировать и деклариоовать ожидания своих решений. И самое главное правило - если ты не знаешь, прочти наконец инструкцию! Это может быть как техническая инструкция, так и административная.

Если ее нет - то ее нет.

Да, это делается через дженкинсы. Которые - сюрприз, надо поддерживать и как-то насетапить.

Сюрприз - прочти инструкцию! И если ты "настраиваешь дженкинсы каждый день", то ты не квалифицирован и "Убери свои руки от инструмента". Нет в нем ничего магического! Один раз настроил и .... все работает месяцами\годами.

Причем проверить совместимость в том числе с разными версиями других модулей.

Ну... если вы таким занимаетесь, то сюрприз - у вас сломаны "инженерные практики". Такие вещи проверяются на стадии дизайна решения, и в случае положительного решения, идут в разработку. Если у вас такое всплывает на стадии QA - мои соболезнования. Вас удивляет бухой сантехник пытающийся вкрутить шуруп в гайку? Но не вызывает изумление ИТ специалист делающий тоже самое, но с кодом ?

Я прекрасно понимаю, что сработавший "да фигня, заработает" может сэкономить денег подрядчику. А как же правило - кроилово, приводит к попадалову ? :)

Ой, кажется я только что описал работу девопс тимы, да?:)

Нет, это не работа devops тимы. Зто раздолбайство, которе плодят\потакают devops. Может я не видел нормальных DevOps, но ко мне еще ни разу не пришел Devops с вопросом -"Ты мудила! Где деплоймент план ? Какого черта нету требований под инфраструктуру решения ? Что с безопастностью ? Допиши бумажку, а потом мы приступим к работе" и т.д. Зато кучу раз видел - "Фигня вопрос, шас развернем...." ну и потом "извращенный секс" на тему "А чего это оно творит ? Какого ... оно падает рандомно ?" и на вопрос к DevOps "а какие соображения ?" слышишь ответ "а хз, надо траблшутить..." и т.д.

Вопрос инженерных практик - стоит очень остро. Карго культ - процветает, к сожалению. Почему-то считается, что покачать спеца за год - это дорого, но нанять 12 "обезъянок" за месяца - это дешевле. Быстрее ? да. Качественнне ? однозначно нет.

отлично, аргументированный ответ.

Артефакты типа - ифраструктура\билды\девелоперы\DevOps и т.д. это просто инструменты достижения п1 в рамках п2 с минимизацией п3 и не более.

абсолютно согласен. Дженкинс для сайта на народе абсолютно не нужен, но нужен в более сложных проектах. Девопс специалист - аналогично: в веб студиях о 10 студентах на халфдей (образно говоря) он нафиг не нужен

Это называется таким волшебным словом "квалификация специалиста". Их в нее входят как знание технических, так и организацонных приемов решения задач. Умение прогнозировать и деклариоовать ожидания своих решений. И самое главное правило - если ты не знаешь, прочти наконец инструкцию! Это может быть как техническая инструкция, так и административная.

как показывает практика, человек может быть замечательным программером, но никудышним админом (если надо что-то поставить\изменить на рантайме).И временами дешевле держать специального человека для этих ченджей, а программер пускай лучше делает что умеет. Обычное разделение труда, как у стройбанов\в металлообработке\везде в производстве. Вы ведь не будете посылать токаря 5 разряда разгружать фуру со сталью?:)

Сюрприз - прочти инструкцию! И если ты "настраиваешь дженкинсы каждый день", то ты не квалифицирован и "Убери свои руки от инструмента". Нет в нем ничего магического! Один раз настроил и .... все работает месяцами\годами.

то-есть секьюрити апдейты мы опускаем? Опять таки: если у нас веб студия и 10 студентов на халфдей - то дженкинс один, и херли его там обновлять. Если у нас несколько выделенных дженкинсов (местами необходимо) - то секьюрити апдейт занимает уже не 5 минут, а 5*N минут, где N - количество дженкинсов (время с оговоркой, но мы ж не эффективная сова чтобы к этому придраться, сделав вид что не уловили суть?). Да и кроме дженкинса есть другие сервисы, которые в том числе нуждаются в мониторинге и апдейтах.

Ну... если вы таким занимаетесь, то сюрприз - у вас сломаны "инженерные практики". Такие вещи проверяются на стадии дизайна решения, и в случае положительного решения, идут в разработку. Если у вас такое всплывает на стадии QA - мои соболезнования. Вас удивляет бухой сантехник пытающийся вкрутить шуруп в гайку? Но не вызывает изумление ИТ специалист делающий тоже самое, но с кодом ?

то-есть тестирование продукта, состоящего из кучи модулей которые пилят разные люди на протяжении многих лет, не нужно?:) Всегда есть место для ошибки.

Нет, это не работа devops тимы. Зто раздолбайство, которе плодят\потакают devops. Может я не видел нормальных DevOps, но ко мне еще ни разу не пришел Devops с вопросом -"Ты мудила! Где деплоймент план ? Какого черта нету требований под инфраструктуру решения ? Что с безопастностью ? Допиши бумажку, а потом мы приступим к работе" и т.д. Зато кучу раз видел - "Фигня вопрос, шас развернем...." ну и потом "извращенный секс" на тему "А чего это оно творит ? Какого ... оно падает рандомно ?" и на вопрос к DevOps "а какие соображения ?" слышишь ответ "а хз, надо траблшутить..." и т.д.

ну таких инженеров дохера. Мы их называем "кожаные дженкинсы". Только в отличие от электрических дженкисов кожаные могут затупить и шото провтыкать :)

я-же говорю как раз таки про людей, которых Вы не встречали: который одной рукой раздаёт им оплеухи, а другой подтирает сопли если у программера случился фейл. Но этот человек встречается редко, ибо Вы правильно заметили

Почему-то считается, что покачать спеца за год - это дорого, но нанять 12 обезъянок - это дешевле.

это факт: почему-то большинство контор берёт админов, обучает их настраивать пайплайны\терраформы\прочие штуки, называет их "девопс" и они потом сами оверинжинириг 40 часов в неделю творят. Причем нафига - непонятно, если все можно сделать куда проще. Но "у нас есть процедуры и мы их повторяем в скриптах", вместо того чтобы просто изменять процедуры в сторону упрощения

я хочу подчеркнуть - проблема не только в инженерных практиках - понятно что всегда есть разделение по компетенциям, кто-то делает одно, кто-то другое. Проблема в локализации DevOps практик ЗА ПРЕДЕЛАМИ КОМАНДЫ РАЗРАБОТКИ в первую очередь, а уже во вторую - в отсутствии этих практик в головах тех, кто пишет код.

Никогда такого не было и вот опять.

Замените DevOps-a в тексте на "сисадмина который теперь ещё и Jenkins настроить может и в k8s по мануалу умеет" и все встанет на свои места.

И что в итоге получается: "мы" вам всё настроили, теперь "вы" с этим возитесь как хотите. Хочешь джоб для обновления бд? Напиши сам, глупый разработчик. Да, запустить и дебажить ты его не сможешь. Это будем делать мы. А ответственность будет на тебе. Ухахаха...

Тоже самое и "QA-ями". Нельзя просто так взять и тестировщика, подтянувшего юнит тестирование и прочитавшего "1001 способ описать один и тот же кейс", назвать QA-инженером.

Или "аналитики" которые ни на один вопрос ответить не могут. Ах да! Они же анализируют и решают важные бизнес проблемы. Никто же не говорил что они должны закончить до того, как будет закончена фича.

И все такие важные и нежные. Как говорит моя бабушка: "кошка н'агрудь не вступи".

справедливости ради надо отметить что и в другую сторону тоже плохо работает. "Я написал" - "Не могу запустить" - "На моей машине все работает".

Написано как бы гладко, но зачем всё - непонятно, с положительной точки зрения 🚱

Лайк. Шейр. Репост. Подпишусь под каждым словом, статья просто в точку

Only those users with full accounts are able to leave comments. Log in, please.