Комментарии 111
Например, фронтендер держит у себя на ноутбуке все элементы приложения, включая базу данных, эмулятор S3 (minio) и прочее. То есть тратит много времени на поддержание этой локальной инфраструктуры и в одиночку борется со всеми проблемами такого решения. Вместо того, чтобы разрабатывать код для фронта. Такие люди могут сильно сопротивляться любым изменениям.
Здравствуйте, я такой фронтендщик, есть ли какое-то решение проблемы? Или предлагается «принять философию»?
Я бы объявил идеальным девопс-специалистом не такого своего коллегу, который хорош в коммуникации и взаимоотношениях, а такого, который смог бы организовать процесс не требующий столько моего внимания. В идеале я вообще хотел бы не знать, кто у нас там девопс. Как, например, я не знаю, кто у нас в фирме настраивает wifi, потому что мне никогда не приходилось к ним обращаться.
В идеале я вообще хотел бы не знать, кто у нас там девопс. Как, например, я не знаю, кто у нас в фирме настраивает wifi, потому что мне никогда не приходилось к ним обращаться.
Не берусь судить об организации DevOps в вашей компании, но невозможно получить DevOps и не общаться с теми, кто его реализует. Мы просто не сможем узнать, что у разработчиков в головах. Я не могу построить пайплайн без участия девелопера: нужно знать тысячу мелочей, которые необходимо учитывать при сборке и деплое.
Хотя вынуждать разработчиков самостоятельно настраивать пайплайны и прочие инструменты, а самим (DevOps-инженерам) выступать в качестве консультантов — немного странно. На мой взгляд.
Как вы считаете, куда сейчас «дует ветер»: это правильное впечатление, и нам всё же следует всё это осваивать, или нормально было бы в нашем случае возмущаться и требовать, чтоб девопсы приходили и сами пилили свои дженкинсфайлы в наших проектах?
Как альтернатива — лиды разработки и просто продвинутые разрабы бывает сами на основе наших компонент или самостоятельно лепят билд-процессы посложнее, если сильно специфичное решение или у нас нехватает ресурсов на помощь. Потом мы смотрим, что они слепили, и если это имеет смысл — стараемся стандартизировать.
По-моему второй год так живем уже, все довольны, из основных плюсов — пропал головняк с чистотой окружений и сопутствующее перекидывание какашками между отделами, стало относительно легко делать что-угодно-as-a-code.
В общем что-то у вас не так там с вашими девопсами похоже. Ну или может вы с ними мало дружите, хотя это тоже проблема девопсов, на мой взгляд.
Да, все верно, но здесь вопрос в том, кто ответственный. Как распределяются задачи. То что вы говорите — это инфраструктура + поддержка разработки. По уму "devops'ы" должны продать внутреннему потребителю некий пакет услуг по заворачиванию кода в продукт и доставке его. Далее этот процесс уже не требует поддержки — он растиражирован на все команды и может централизованно меняться (например, добавление новых модулей — статический анализ и все прочее), либо ребята девопсы предоставляют 90% пайплайна, а вы сами кастомизируете под свои задачи — но это ТЕМ БОЛЕЕ ПОКАЗЫВАЕТ НЕОБХОДИМОСТЬ КОММУНИКАЦИИ. Чтобы очертить границы, договориться о правилах игры, помогать друг другу в случае проблем, делиться компетенциями.
Разработчики, без собственного интереса вообще не в курсах как у нас там всё тикает. Все конфиги, докерфайлы, k8s ямлы, пайплайны полностью в моей собственности. Я лишь прошу меня оповещать о каких-то изменениях, касающиеся либо сервера, либо конфигов: библиотеку новую подтянуть, новую переменную в конфиг нужно прописать, миграции и т.д.
И для разработки я в осном полностью предоставляю проект в докере, который запускается одной командой, включая бэкенд(ы), базу и т.д.
Т.е. в принципе, как Вы и хотите, но конечно, полностью без общения — никуда.
Но тут фишечка то вот в чём. Я девопс из разработки, а не из сисадмина стал… Т.е. я знаю по себе боль разработчика, и понимаю многие необходимые моменты.
С другой стороны я сисадмина заменить не могу… Сети, фаерволы и т.д., но я перенимаю коммуникацию с ним.
Просто вы уже ощутили их на себе, а {некоторые люди} еще нет.
Статья про «DevOps это методология», а ответ «найдите/родите/украдите девопс инженера», вот это номер.
Ситуация в том, что узкие специалисты за пределами своей песочницы, как правило, ничего не видят и не хотят смотреть (есть ещё вариант, что им не дают под соусом «некогда объяснять, надо фичи пилить»). Для того, чтобы координировать действия таких не очень смотрящих по сторонам людей, придумали менеджмент, в обязанности которого и входит обустройство коммуникаций между людьми и подразделениями. Если этот менеджмент действительно считает, что основной задачей разработчика является написание кода, то можно дивизию девопсов нанять и ничего не получить в итоге. Это объясняется в самой статье прямо словами «девопс это про организацию».
Это всё правильно, но я бы сдох пилить бизнес-фичи и параллельно писать какой-нибудь Helm chart и его интеграцию в пайплайн.
Все равно не будет такого, что все могут всё, поэтому надо просто активно взаимодействовать, слушать и понимать друг друга. Мне кажется, это и есть девопс. А какие технологии в итоге использовать — да какие угодно, лишь бы они были понятны и комфортны в использовании: разработчикам, девопсам, админам, тестерам, бизнесу.
Т.е. процесс должен быть организован так, чтобы инфраструктурные вещи были частью процесса разработки, если это необходимо для реализации фич.
То есть чарт писать всё-таки разработчику? А девопс инженер что будет делать? Или разработчик оценит, что девопс у нужно три часа или три девопс поинта и создаст таску на него какой чарт ему нужен?
Или разработчик оценит, что девопс у нужно три часа или три девопс поинта и создаст таску на него какой чарт ему нужен?
Здесь вы описываете классический процесс с опсами без девопса. Нам что-то надо поменять в инфре — мы ставим задачу опсам. Они его когда-то сделают, у них там свой беклог задач, может через полгода до нашей доберуться. А там как раз и снова про наш проект вспомнят.
Само по себе наличие задачи «написать чарт» или использование волшебных технологий не делает процесс «девопсным». Все эти технологии можно использовать и с классической схемой «отдел разработки пишет код, отдел эксплуатации его деплоит и саппортит».
Так что да, идея как раз в том, что разработчику — самому писать чарт. При этом крайне желательно (по крайней мере мы стараемся усиленно развивать эту тему и вроде даже относительно успешно), чтобы это мог сделать не какой-то один разработчик в команде (и тем более не один на отдел), а любой в команде для минимизации бас фактора.
В этом случае вы сможете командой оценить трудозатраты и командой же реализовать проект от и до не в мифических «девопс поинтах», а именно в тех единицах, в которых работает команда.
А девопс инженер не будет ничего делать. Потому что нет никакого девопс инженера (вроде про это и написана статья). Есть команды разработки и есть команды опсов, которые вместе пытаются сделать отлаженный процесс доставки продукта в прод
Я больше про специалиста в составе команды, у которого общий со всеми командами бэклог и на которого в ходе планирования спринта (если говорим о чем-то скрамоподобном) назначаются (под)таски из общих сторей. Смысл как раз в создании кроссфункциональной команды, которая способна практически любую стори или кейс провести от проектирования до выкатки на продакшен с последующей поддержкой, не завися от опсов или ещё кого.
У нас такая команда есть, но бас-фактор где-то 1,3, где 1 — это я. И вот честно отдавать половину, а иногда и больше рабочего времени разработчика на подобные задачи, мне больше совсем не хочется. Не хочется просыпаться по ночам с "гениальной" мыслью, что перезагружать автоматически под при изменении конфигмапы можно добавив контрольную сумму этой конфиг мапы в аннотации пода или что инит контейнеры можно использовать для проверки что в файловой системе все права правильно установлены, а не всобачить такую проверку в ентрипоинт.
Подправить что-то, типа добавить новую енв переменную в ту же конфигмапу — ради бога (для меня лично, а половина команды разбираться не хочет). А вот разбираться как заблокировать PV/PVC от удаления и как его перемонтировать туда же в нормальном состоянии, когда уже в deleting — это перебор.
Извините, наболело.
А вот разбираться как заблокировать PV/PVC от удаления и как его перемонтировать туда же в нормальном состоянии, когда уже в deleting — это перебор.
А вот в этот момент надо вспомнить что в DevOps кроме Dev есть Ops. Которые (ну опять же в моем понимании и мы у себя к этому вроде идем) помогут разобраться, отревьюят твои изменения в чартах, дадут свои рекомендации и какие-то общие направления для всех разаработчиков (ну типа «давайте все перестанем делать так и будем делать так, потому что..»).
В вашей ситуации я вижу наболело потому что Dev полностью погружается в опсовую историю (при том походу самостоятельно, если ему приходится разбираться про pv\pvc). Но должно быть не так. Опсы должны давать удобные инструменты и инфраструктуру в котрую девелоперы смогут заезжать самостоятельно и без боли. Если не самостоятельно или с болью, то где-то недоработки и надо побольше пообщаться чтобы решить эти проблемы
Мне кажется, вы в первом абзаце сами себе противоречите.
А, ну да, в вашем комментарии ниже:
Так что да, идея как раз в том, что разработчику — самому писать чарт.
А если он отлично знает бизнес-логику, ну просто в совершенстве, но очень далёк от инфраструктуры и она ему неинтересна. Заставлять "интересоваться"? Уволить и искать другого?
Мы все люди, а не роботы. Поэтому если взять какую-нибудь унифицированную концепцию, будь то девопс, аджайл или что там ещё, и пытаться дословно сверху-вниз её применить, ничего не получится.
На самом деле, нужно просто налаживать простое и человеческое взаимопонимание в коллективе. Тогда и техника заработает как надо.
А если он отлично знает бизнес-логику, ну просто в совершенстве, но очень далёк от инфраструктуры и она ему неинтересна. Заставлять «интересоваться»? Уволить и искать другого?
Это уже вопрос микро-менеджмента в конкретно взятой команде. Насколько вы управляете бас фактором, насколько вы шарите знания и т.д.
Этот вопрос вообще к девопсу никакого отношения не имеет. Тот же самый вопрос может возникнуть если у вас в команде есть несколько направлений (например в нашей команде на поддержке несколько систем разных) и человеку может нравится заниматься одним и не нравится заниматься другим. Что вы сейчас делаете в таком случае? Увольняете и ищете другого? Я думаю что подход (какой бы он у вас ни был) будет примерно таким же.
Да, конечно, все решается человеческим взаимопониманием, тут абсолютно согласен. В частности у нас в команде нет принудиловки в этом плане, но в целом 3 человека могут заниматься этим полноценно и еще пара понимает как это работает, что уже, на мой взгляд, позволяет нам грамотно оценивать и планировать такие задачи и ставить их в спринт как обычные.
Это уже вопрос микро-менеджмента в конкретно взятой команде.
Этот вопрос вообще к девопсу никакого отношения не имеет.
А что тогда такое девопс? Организация процесса работы команды. Вы себе опять противоречите.
Решение всегда есть, но оно для каждого своё. У нас, например, фронтенд и бэкенд в разных проектах. У бэкенда есть stage, с которым фронтендеры и соединяются. И не нужно каждому держать всё на своём лаптопе, хотя, это возможно и есть и такие примеры.
при должном развертывании содержание кластера Kubernetes стоит в 2-3 раза дороже, чем развертывание приложения по обычной кластерной схеме
Хм, а что есть «обычная кластерная схема»? Вроде, то, что Kubernetes становится стандартом — один из его главных плюсов. Можно отладить на одном кластере и почти не ждать траблов на другом
Кубернетес не серебряная пуля. В него действительно можно засунуть все. Только вопрос цены. Как засовывания, так и поддержки. Почитайте какой гемор туда тащить стейтфул. Вообще есть подозрение, что кубернетес — это инструмент черного плана Гугла по подсаживанию всех на свое облако
Действительно, где ещё кубернетес может быть лучше, чем у гуглклауда ?
Почему Jenkins? Что такое Jenkins? В чём практическая разница решения аналогичной задачи в Jenkins, GitLab CI, TeamСity?
Какой результат нужен руководству, когда ставит мне какую-либо задачу?
Есть ли какие-то альтернативные варианты?
Каковы при этом будут финансовые и временные затраты?
Как только самостоятельно начнете искать ответы на них (обычно сквозь боль и полученный опыт), то станете видеть общую картину процессов. Это и есть «путь DevOps».
Именно, познание смысла всех инструментов через пекло (в первую очередь, а какие проблемы эти инструменты решают и почему мне должно быть дело до этих проблем) и приближает "сисадмина кубера" к DevOps-дзену. А то вон как комментатор ниже, жонглирование баззвордами без какой-либо осознанности и их же продажа таким же неосознающему смысла происходящего работодателю.
Добавлю про такую штуку как диаграмма value stream. Она интересна тем, что показывает как выглядит процесс разработки продукта по этапам от начала до конца, и вот поняв смысл ее и поняв какое отношение к ней имеет идея DevOps, можно будет говорить об осознании, что это и зачем оно нужно.
Я бы сказал так, идея DevOps сделать понятным, прозрачным и быстрым процесс от идеи до продукта. Чем и как вы этот процесс реализуете не регламентировано. Но суть именно в словах выше.
В частности, как следствие, возникают задачи автоматизации, ведь только так можно ускориться, и только так можно непрерывно улучшать процедуры избегая проблем с ручными ошибками. Короче это сродни построению конвейера на производстве.
До сих пор нет устоявшегося термина, что или кто это.
и ко мне пришло осознание, насколько важно четко понимать суть термина.
WTF?
Если сократить, то девопс это все же специализация инженера (должность сисадмина всеобъемлюща поэтому уточнил =) ). Кто-то поддерживает сети, кто-то AD, а кто-то рабочую среду для программистов.
Весь этот налет магии, филосфии и таинственности как раз и генерирует людей, которые вам так наскучили на собеседовании. Вместо вопроса «что такое девопс» лучше задавать вопросы на понимание того как он должен обеспечивать разработчикам комфортную среду, а работодателю эффективную отдачу от вложений в инфраструктуру.
Позиция «я не могу сформулировать, но вы сами должны понимать» не очень конструктивна. Вам не кажется?
Девопс это не специализация.
Смотрите. Сейчас девопсом кого называют? Админа, который поддерживает пайплайнов. Инфраструктурщика, который поддерживает кубернетес или Хадуп платформу. Инженера по автоматизации процессов. Да и черт знает кого. Ну, или как сейчас модно — инженер, разбирающийся в облаках (в каком-то одном облаке — ажур, Амазон, гугл...)
Но. Есть же эджайл коучи — люди, которые могут помочь внедрить эджайл а отдельно взятой организации, наладить процессы. В этом смысле (в отличие от предыдущего) девопс инженер существует. Но это тогда не технарь, не тот человек, который будет все делать руками. Не так ли ?
И хотелось бы услышать от вас, как вы понимаете слово инженер. А то пока сложилось мнение, что вы не знаете значение этого слова. Это не наезд. Просто если два человека вкладывают в одно и то же слово разный смысл — они не поймут друг друга.
Пока сложилось мнение, что вы можете мальчика, который освоил 3 кнопки в облачном сервисе амазона, назвать не только «специалистом по облакам» но и инженером.
Хорошая книга на эту тему "Руководство по DevOps"
И совершеннейшая неправда.
«Х##к-х##к, и в продакшн» — это CI/CD.
А DevOps и SRE — это надмножество «Х##к-х##к, и в продакшн».
PS. вспомнилось из старого анекдота — совещание в некой фирме:
— И хочу напомнить отделу продаж, что выражение «всякая х… ня» не в полной мере раскрывает всё многообразие ассортимента продуктов и услуг нашей компании.
Даёт ли bash идемпотентность? Джейлы — лишь небольшая часть паззла решения по доставке и запуска иммутабельных артефактов, которое формирует Docker и его последователи. Современный эксплутационный стэк, в первую очередь, теперь позволяет решать типичные эксплутационнные проблемы, ради которых раньше требовалось организовывать отдел, одним инженером с нужной экспертизой. И простое наличие нужных баззвордов в CV экспертизы не даст. Ansible, Docker, Kubernetes, Terraform и прочие — лишь инструменты, позволяющие реализовать подход, дающий все релевантные бенефиты разработчикам и бизнесу — и вот поэтому "DevOps-инженерам" и готовы платить деньги.
Условно говоря, люди десять лет назад на условном Puppet управляли состоянием инфры и получали за это инженерные деньги, то что HR-зомби ищут "мифического девопса" на каждом шагу, квалифицированному инженеру погоды не сделает.
Ну и про "вывалить в прод" — это не DevOps никак вообще. Graceful degradation, blast radius limitation — все эти концепции были выкованы огнём и мечом, ваша картина восприятия той индустрии, которая вас кормит — как бы мягко сказать неверна.
Если убрать твой сарказм, ты-то сам понял что написал? Я говорю что один специалист теперь может рулить инфрой на 100+ хостов минимум (а при правильно построенных практиках на уровне департамента и 1000+), в которой постоянно что-то тестируется, выкатывается, мониторится, алертится и т.д. и требуемый для этого набор навыков — один из элементов эксплутационной части DevOps-парадигмы, ты же мне зачем-то говоришь про ничего не делающий отдел, когда я как раз чёрным по белому написал полностью наоборот.
И я с ним в целом согласен. Слишком много шума вокруг обычной специализации инженера.
А знаете, что подумал. Если взглянуть на это со стороны, ну можем мы всё это, и что? Бизнес видит, что один инженер может не 1-10, а 100-1000 хостов координировать и увеличивает свои запросы.
И бежит белочка дальше по своему колесу, только на колесе теперь написано Ansible вместо bash или Kubernetes вместо vSphere...
И если с первого предложения идет явная логическая ошибка, то можно ли доверять другим вашим доводам? Неверные данные на входе, дают неправильные данные на выходе даже при самой лучшей методике.
Разумеется язык программирования не может дать никаких подобных гарантий. Я имел ввиду что один из основных принципов Ansible как системы управления конфигурациями это идемпотентность применяемых ресурсов. Хотя в отличии от например Chef, Ansible позволяет себя использовать как тот же Bash на стероидах. Хотя как по мне, нужно сразу двигаться к правильному использованию инструмента.
Насчёт логической ошибки — даже если это и так, хотя я развернул сейчас свою мысль, такой подход в диалоге называется сверхобобщением — идущие после него выводы не могут быть правдивы.
Кто такой DevOps и когда он не нужен
Можно ли использовать DevOps, помимо разработки ПО, в других отраслях?
Вообще, не надо хотеть от разработчика внедрения этого вашего DevOps или от инженера — PDCA. Это прерогатива совсем других людей в компании, quality assurance department их зовут или отдел качества, по-нашему. И к «технарям» они относятся почти что никак. Они уже и занимаются всем этим «сектантством», и для «технарей» разрабатывают (ну или должны разрабатывать) простые и понятные процедуры выполнения рабочих процессов в рамках своих теорий управления.
Ясен перец, что даже для средних компаний держать свой развёрнутый и действующий QA, ну так себе идея. Хотя просто следовать идеям цикла улучшения качества «из общих соображений», конечно, ни разу не возбраняется.
потому что получается вот так
agile и devops — очень хорошо пушат друг друга
p.s. картинка уперта из https://habr.com/ru/company/jugru/blog/489488/
я искренне хочу верить, что где-то эта сказка стала явью, а пока что вижу только сплошной маркетинг
"Но есть команды, которые, наоборот, рады внедрению новых инструментов и методов, и живо участвуют в этом процессе. "
"Выгоревший миллениал mode on"
Скажите честно, вы с такими работали? Они вообще существуют в природе? Я 4 года внедряю в нашу уездную корпорацию всякие улучшалки: автотесты, дженкинс, контейнеры, а иногда начинать приходится тупо с битбакета. От силы 1 человеку из 10 (кроме менеджера) это хоть как-то интересно, остальные пользуются только если их заставляют. Тренинги, демо не особо помогают, а я их провела немеряно. Помогает только публичное унижение, если каждый день на дейли спрашивать как бы невзначай, запушил ли Петя свои изменения в битбакет, то рано или поздно, скорее всего, после пары писем от менеджера, Петя сподобится и запушит. Ура. Теперь надо чтобы он билдил и деплоил через дженкинс, а не локальным мавеном, копируя джарники через путти. 2020 год на дворе, чо.
Если команда распределеная, с временной разницей, это вообще швах. Их не видно, не слышно, и саботировать нововведения они могут бесконечно, пока большой начальник не напишет гневное письмо всем департаментам, начальники поменьше забегают как вши по сковородке и не возьмут своих раздолбаев за одно место. Тогда начинают сыпаться письма: — Надя, срочно, у нас есть пайплайн??? Надя, нам сегодня же нужен пайплайн!!! Да елки-палки, уже 3 месяца как сделано, презентовано, стори закрыты, один фиг никто ни разу не запустил.
И, что бесит больше всего, что реальной власти у девопса никакой нет. Он не начальник, требовать и карать не может. И это необычайно горько, да.
"Выгоревший милениал mode off"
Ну ну да, никто не говорил что будет легко. И ценность сотрудника как раз и определяется тем, на колько он может свои идеи воплотить в реальную жизнь. Улыбаемся и пашем.
На самом деле в моей практике есть случаи, когда работу принимают с огромной благодарностью и энтузиазмом. Но это скорее исключения. Например, в одном крупном банке инициатором контракта был отдел тестирования ПО для ДБО ЮЛ. Там вся работа тестировщиков была только «врукопашную». Мы пришли целой командой с автоматизаторами и нагрузочниками. И нам помогали всеми силами и возможностями. Заказчик остался очень доволен результатами.
Я 4 года внедряю в нашу уездную корпорацию всякие улучшалки
Зачем? Из Вашего описания следует, что это корпорации не нужно. Можно довольно долго и успешно партизанить через этого одного из десяти, но это дорого, и крыша едет со временем всё равно от несоответствия декларации и действительности.
ценность сотрудника как раз и определяется тем, на колько он может свои идеи воплотить в реальную жизнь
«Я выкопал котлован под дом чайной ложкой, я ценный сотрудник» — ну нет же. Как и любого наёмника, Вас заменят быстро, без сожалений, на более лояльного и, возможно, менее квалифицированного человека. При первой необходимости.
Ещё раз, если менеджмент не понимает, что происходит, от него надо валить, потому что любые изменения превращаются либо в шапито, либо в карго-культ.
Не так все печально, какой-никакой прогресс есть. Учатся помаленьку. Есть возможность новые штуки ковырять. Деньги платят, кпи там, то сё. И я не особо верю, что где-то сильно иначе, честно. Менеджмент все прекрасно понимает и использует наработки для, так скажем, самопрезентации, независимо от практического выхлопа. Ну и я так же решила делать, чем я хуже. На любую хрень принудительный фидбек, чтобы было что на годовом ревью показать.
Может и пора валить, пока внутренний художник совсем не загнулся.
Можно коммитить в опенсурс — там поле непаханное, где можно силы применить. Лишь бы не мешали на работе...
И я не особо верю, что где-то сильно иначе, честно.
А я не верю, что есть так как описываете вы :)
На самом деле верю — я работал в самом начале полгода в такой конторе. Но благополучно свалил и работаю в нормальных конторах с нормальными процессами.
И, что бесит больше всего, что реальной власти у девопса никакой нет. Он не начальник, требовать и карать не может. И это необычайно горько, да.
Это плата за то, что подыграли рынку на хайпе и назвали себя DevOps-ом. Потому что вы не были DevOps-ом. Никто не мог быть DevOps-ом, потому что человек-human-being не может быть методологией.
DevOps, по определению, — ответственность Dev-ов перед Ops-ами и обратно.
Как только какая-то компания берет на службу DevOps-а, то тем самым она, какбэ, говорит:
"Я снимаю ответственность с Dev-ов перед Ops-ами. Снимаю также ответственность Ops-ов перед Dev-ами. Теперь у нас есть специальный выделенный человек, который несет на себе ответственность за обоих. А задача его заключается в том, чтобы сочинять костыли автоматизацию для связки двух подводов труб, по которым с завидным постоянством стекает дерьмо безответственных людей."
И тут у нас начинается все то, то нам завещали все эти карломарксы: делают одни, отвечают другие. Неубиваемая мотивация насрать еще! Наступает рай! Но не для всех и не надолго...
Я себя девопсом не называла, они сами так меня назвали, когда слово модное услышали. Была тестером изначально. Мне что, девопс так девопс, лишь бы скрипты писать не мешали.
Думаю да, один человек не может заменить налаженную коммуникацию между командами и всех замотивировать, если это не Тони Робинс. Но начальству проще свалить это на инженера, конечно, чтобы было с кого спросить.
Разработчик — у меня код отрабатывает идеально, сами посмотрите. Ну давайте я опциями поиграю.
Сисадмин — у меня сервера настроены идеально, сами посмотрите. Ну давайте я настройками поиграю.
…
Или стабильно но дико тормозит, или очень быстро но с вылетами
…
Бизнес: подать мне такого, кто решит эту задачу!
…
DevOps — проблема решена раз и навсегда
Бизнес — о, вот спасибо, а то уже замучались!
Разработчик — подумаешь, пару опций сменил. Я бы и сам мог сменить (если бы знал).
Сисадмин — подумаешь, изменил пару настроек. Я бы и сам мог изменить (если бы знал).
Очевидно, что DevOps как персона — это некто с опытом разработки и системного администрирования от 5 лет каждого, который может решить задачи бизнеса, потому что понимает, что идеально настроенные сервера или прекрасная отработка кода на лаптопе разработчика — совсем не то, что нужно для бизнеса.
Для решения этих задач нужно понимание и экспертиза. Как в том анекдоте про удар молотком и место, куда надо бить.
Так большинство девопсов и есть хорошие админы, которые нормально сотрудничают с разработчиками, а не плюют через губу "ваша программа не работает, код у вас дрянь, да и сам ты дурак, не знаешь как cisco настраивать". Таких ведь админов тоже достаточно.
И любой адекватный разраб, точно так же разберется в мой кухне. Что он не сможет ансибл править и коросинх настраивать с цефом. Да без проблем. Просто ему с этим нужно будет поработать и приложить пару продовых серверов).
Вопрос в том, нужно ли это лично ему? Субъективно большинству разработчиков не нужно, как и большинству админов с кодом разбираться, вот тут и возникает потребность в людях, которые достаточно хорошо разбираются в обеих областях, и если не сами будут решать задачи на стыке, то ставить задачи обеим сторонам.
Пускать на самотёк взаимодействие разработки и эксплуатации...
В IT может/не может определяется не только набором знаний и умений, но и мотивацией. Ну да, опытный разработчик без труда может решать задачи администрирования. И потестировать может, и настроить wifi. Но ему это не интересно, и потому неэффективно давать ему такие задачи, так что условно скажем, что делать он этого не может.
Но ему это не интересно, и потому неэффективно давать ему такие задачи, так что условно скажем, что делать он этого не может.
Ну так это потому, что вы из снобизма придумали примитивные задачи про Wi-Fi, чтобы показать, как администрирование примитивно.
А вы дайте реальные админские задачи: пусть dracut потраблшутит, пусть pivot линуксового ядра сделает наживую на продакшене или пусть Rook развернет, чтобы Ceph'ом управлять в Кубернетесе. И чтобы "ни единого разрыва".
Сразу появится мотивация расти от не останется следа от проблем с Wi-Fi :-)
Wi-Fi тоже пусть починит. Не все коту масленица.
А что касаемо ситуации — то там либо неквалифицированный персонал, либо саботаж рабочего процесса на фоне личных загонов.
Разработчик должен писать только код и тесты. Для этого ему не нужен супермощный ноутбук, на котором он будет разворачивать и поддерживать локально всю инфраструктуру проекта. Например, фронтендер держит у себя на ноутбуке все элементы приложения, включая базу данных, эмулятор S3 (minio) и прочее. То есть тратит много времени на поддержание этой локальной инфраструктуры и в одиночку борется со всеми проблемами такого решения. Вместо того, чтобы разрабатывать код для фронта. Такие люди могут сильно сопротивляться любым изменениям.
У нас централизовано распространяется набор скриптов и конфигов для поднятия системы локально фронтендерами, бэкендерами и QA. Собственно набор это баш скрипты для поднятия локального k8s и отдельно баз данных и т. п., плюс отдельный набор values для чартов. Ну и поднять это всё локально довольно мощный комп нужен. И сопротивляться никто особо не сопротивляется, скорее высказывают хотелки типа "зачем 4 скрипта запускать — сделайте один", "слишком долго билдится — сделайте какой-то кэш и персистентность", "сложно в списке из 15 реп каждый поставить на нужную ветку", "надоело отслеживать, что IP поменялся — автоматизруйте запись в /etc/hosts". В целом наша команда хочет девопса, чтобы как раз не заниматься этим всем, чтобы разработчики писали код и тесты, чтобы тестировщики писали тесты и руками тестировали, а CTO рукводил процессами, а не фиксил локальные окружения.
Не соглашусь с единственным постулатом статьи о том, что необходимость DevOps определяется наличием развитых клиентских сервисов. Возможно, вы путаете DevOps с SRE (хотя если вы постоянно внедряете DevOps, то наверное не путаете).
На мой взгляд, ван нужен DevOps, когда у вас есть развитая разработка ПО. И не важно, это высоконагруженный клиентский сервис или сложная система управления производством. DevOps практики — это практики именно разработки ПО, а не его поддержки. И когда ваша команда начинает задаваться вопросами управления конфигурациями, CI/CD, автоматизированными тестами, когда становятся data-driven и начинают считать метрики и эффективность — вот тогда на помощь команде разработчиков приходят devops-инженеры. А уж откуда они придут — будут наняты или выделятся из команды — не так важно (хотя конечно нанять инженера, который уже решал все такие вопросы в разных компаниях кажется более эффективным).
Ещё эффективность в мотивации. Если судить по мне, то все эти CI/CD и кубернетесы/свормы мне интересны, чтобы понять их возможности и ограничения, чтобы разрабтывать софт с учетом этого, чтоб понимать какую часть сложности лучше переложить на IaC, а какую проще на код. Автоматизировать свою работу. Вот для только что созданного мною сервиса и пайплайн написать, и чарт не просто жалко, а в удовольствие. А вот когда приходят и говорят "у нас тут новый сервис соседняя команда написала, нужен пайп лайн и чарт" совсем другое отношение
Кому-то интересно этим заниматься, кому-то нет. Но все равно такие задачи никуда не деваются. У нас вот есть несколько разработчиков, которые сами пишут terraform для деплоя в AWS своих сервисов. Для кого-то это кажется нормальным, другие считают, что они делают чужую работу. Но если им есть с кем обсудить проблему, кого попросить с чем-то помочь, то мотивации у них прибавляется.
В комментах больше пользы чем в ней.
Причем автор сам признает, что правильных ответов вообщем и нет, все очень зыбко, терминология не устоялась…
Должность это или не должность — какая вообще разница? Тебе шашечки или ехать?
Нанимаешь инженера с конкретным кругом обязанностей — администрить то то и то то, знать такие то системы. Ну так это и спрашивай. Нашел тоже место для удовлетворения своего эго — интервью соискателя. Мол, я понимаю философи девопса, а вы нет.
Иди вот на открытые площадки со своими идеями, доказывай в открытых дискуссиях. Зачем этим заниматься на интервью?
Ну не все так просто. Девопс-инженер должен обладать еще и «софт-скилами», то есть уметь общаться, брать ответственность, работать под давлением и в цейтноте. Иначе от него будет один дискомфорт, даже если он разбирается во всех технических тонкостях. Разрабу или админу это нужно в меньшей степени, мне кажется.
- Два админа (настройка сети офисов, VPN, wifi, Azure AD, покупка офисного железа).
- 9 продуктовых команд (стек в основном .net (и новый и старый), angular)
- 10+ DevOps/SRE, делятся на 3 команды:
- infra — настройка pipelines, ресурсов в Azure, и т.д. (3 человека)
- reactive — Фикс критических багов, мониторинг систем (в том числе on-call), консультация support команды
- proactive — разработка внутренних тулов (админки для продуктов, тулы для support команды и для devops, и т.д.), настройка и улучшение мониторинг систем, помощь продуктовым командам.
Команды reactive и proactive динамические, т.е. каждые 3 недели (длинна спринта) команды меняются. В reactive и proactive все девелоперы (т.е. умеют писать production ready код, пилить фичи, «общаться» с бизнесом) и умеют настраивать инфраструктуру и мониторинг.
По сути наша задача:
1. Обеспечить работоспособность всех продуктов
2. Заметить и починить проблемы до того как они повлияют на пользователей
3. Улучшить жизнь работникам компании через разработку внутренних тулзов
4. Оградить продуктовые команды от критических багов (обычные баги они фиксят сами) что бы не отвлекать их от целей спринта.
Не знаю соответствует ли это «философии» DevOps или нет, но работает довольно хорошо.
А чья задача обеспечить ввод в эксплуатацию, в том числе опытную/тестовую нового сервиса или приложения, созданного разработчиками? Проще говоря, настроить пайплайны, мониторинг, сбор логов и т. п. для кодовой базы, которая пока только локально у разработчика запускается, когда он ее локлаьно сбилдит
То есть разработчики все-таки довольно глубоко должны погражутся в тот же k8s? Или по желанию, но так получается что хотя бы один желающий в команде находится?
Ну вот как и куда — это одно дело, а вот самому писать скрипты/конфиги/рецепты/манифесты/чарты и т. п. — совсем другое.
просто нереально разрабатывать не зная про слой инфраструктуры
Вот из-за такого неверия в собственные силы вам 10 девпосов и нужно. А ведь потом ещё можно и похвалу от начальства за превозмогание плохой, некачественной инфраструктуры получить.[/sarcasm]
Например, можно в переписанном с нуля сервисе использовать половину от всего функционала Amazon S3, а потом с удивлением обнаружить, что в проде всю дорогу используется не «настоящий» S3, а его on-premise опенсурсная реализация, и функционал хитрее «дай мне вот этот объект» там работает из рук вон плохо. Зато как можно причитать на тему «ну как же, в документации к Amazon S3 написано, а вы, а у вас, нам тут полгода переделывать тогда, что же ваша инфраструктура такая негодная-то».
Тема Хренотени за последние несколько лет стала очень популярной. Многие мечтают в нее влиться, но, как показывает практика, часто только из-за уровня зарплат.
Некоторые указывают в своем резюме Хренотень, хотя не всегда знают и понимают суть термина. Кто-то считает, что изучив Ansible, GitLab, Jenkins, Terraform и им подобные (список можно продолжать на свой вкус), то сразу станет «Хренотенопсом». Это, конечно, не так.
Несколько последних лет я занимаюсь в основном внедрением Хренотени в различных компаниях. До этого более 20 лет работал на позициях от системного администратора до IT-директора. Сейчас — Хренотень Lead Engineer в Playgendary.
...
Подобные вещи практически один в один напоминают систему менеджмента качества. Много лозунгов и никакой конкретики. Зато плакатом можно завесить дырку в стене, которую влом заштукатурить.
Представьте себе заводской цех.
Вот стоит токарь и фигачит болты. Показатель его производительности (можно я по-русски буду?) — колво болтов в смену.
Вот у токаря закончилась заготовка.
Он останавливает станок и идет на склад за заготовкой. А она, зараза, тяжелая и поэтому он идет искать тележку/машину/кран — неважно, в зависимости от. Главное чтобы она в данное время была свободна. Если занята таким же токарем — ждет освобождения.
После чего притаскивает заготовку к станку, устанавливает и работает дальше.
Все ли у нас хорошо?
Во-1 наш станок какое-то время неизбежно простаивает.
Во-2 чтобы притащить тележку, токарь (помимо умений совладать с чпу-станком) должен обладать еще и достаточной физической силой.
Да, он теперь называется не просто токарем (девом), а токарем-потаскуном — я тут опять по-русски: не от слова таск, а от слова таскать — (девопсом). Да, завод смог сократить бригаду потаскунов (опсов) и сэкономить. Да, управлению приходится искать в профильных учебных заведениях не только умных (это ж ЧПУ), но и сильных (это же таскать надо) парней одновременно.
Это выгодно? Это позволяет заводу работать больше/лучше/быстрее? Посчитайте каждый на своем заводе.
Много лет назад Генри Форд изобрел разделение труда, которое придало производствам самый мощный скачок в истории. Давайте же сейчас снова откатимся назад и поработаем так Х лет для того, чтобы кто-то смог придумать разделение труда снова. И может быть даже не нахватал минусов за инакомыслие на своем отраслевом форуме.
Ага, но разделение труда приводит к необходимости создания НОВЫХ должностей — типа людей, которые внедряют конвейер, поддерживают его, имеют целостную картину, чтобы управлять этой сворой (командой) узкоспециализированных чуваков. В общем — без работы не останешься. Вот и с разрабами такая же история — типичный разраб не хочет ни вникать в бизнес-специфику, ни в окружение (мониторинг, пайплайны, продакшен среда) — поэтому под это все нужна отдельная роль. С другой стороны, эти компетенции НУЖНО шарить в сторону продуктовых команд, иначе получается фигня
Кто такой DevOps и когда он не нужен