Comments 48
бэкапшикиОговорочка по Фрейду, не убирайте пожалуйста)
Жыза.
"Задачи, которые выполняет девопс – это та же разработка, только инфраструктуры и процессов".
Ну как и следует из названия — "DEVeloper OPerationS". Во всех индустриях роль operations вполне себе определена (как и остальных бизнес-функций), а в IT до сих пор жаркие споры и непонятки. :-)
И с operations все просто en.wikipedia.org/wiki/Data_center_management#Operations. Боюсь, что непонятки исключительно на великом и могучем.
Ну вот же: https://en.wikipedia.org/wiki/DevOps
Первая строчка.
DevOps это набор технологий которые обьеденяют разработку програмного обеспечения и системное администрирование.
Если вернуться к истокам и просмотреть первую презентацию с употреблением слова DevOps, то можна услышать что автор презентации рассказывает о шаблоне — когда разаработчики пишут код, который сдают на определенном этапе готовности админам. Что создает много проблем. Методология DevOps предполагает активное участвие админов на более раннем этапе разработки — еще во время проектирования и тд тп
Для иллюстрации пример, который подвернулся на скорую руку
Плохой пример. docker и compose примитивные, а в кубер манифесте намутили все подряд — секреты, лимиты, политики все подряд, pvc. Ну вот совсем разные.
Да, кубер будет длиннее, но эквивалентный манифест будет существенно короче, чем в примере, и подавляющая его часть будет шаблонной, а суть будет помещаться примерно в тоже число строк, что у compose. При этом по определению это все равно будет не эквивалентным примером, потому как мы все еще говорим о statefulSet за куберовским сервисом.
Он не просто длиннее будет из-за kind, apiVersion и прочих spec, но и содержать больше сущностей в принципе.
А эквивалентно или нет — это от точки зрения зависит. Кто-то считает, по определению не может быть эквивалентно, потому что если нода упадёт, то контейнер переедет в кубере и сдохнет в докере (забывая, впрочем, об однонодовых сетапах кубера и многонодовых, понимающих compose ), а для кого-то эквивалентность означает, прежде всего, возможность увидеть свой hello world в браузере и пофиг на HA, автомасштабирование и прочую безопасность.
Да вы правильно поняли, должность по прежнему так и называется "системный администратор", а девопс — это методы его работы, но так уж сложилось что все подгузники — памперсы, а все внедорожники — джипы
Почему админ, а не разработчик? )
А код пишут разработчики обычно...
Очень разное понимание есть кто такой девопс и в чём его функции. Один раз встречал, что девы пишут код и манифесты для него, админы пишут плэйбуки и манифесты для инфры, а девопс коммитит и в репы девов, и в админов, чтобы код и манифесты первых работал на инфре вторых, принимая решения где пойти навстречу девам, а где админам, а где адаптер какой-то написать.
А код пишут разработчики обычнону вот например научным сотрудникам некоторых областей тоже приходится писать код на питоне, но они не перестают быть учеными и не становятся программистами от этого. А с еще более другой стороны — devops стал должностью во многих компаниях, и должность эта — сис.админская, но начинался devops как набор практик, как подход к выполнению работы.
И "админ, переименованный по-модному" сможет создать csi к8с оператора?! Со всеми необходимыми процесамми для разработки и поддержки? Или это задача для девелоперов?
Современная эксплуатация, если говорить за решения хотя бы среднего размера, по сложности освоения и обширности необходимых знаний весьма велика и весомо так превосходит объем знаний об этой области линейного программиста. И даже не особо линейного. И, возможно, она вообще по объему больше, чем обычный frontend/backend программист знает в рамках обязанностей по созданию продуктов.
Отсюда появляется специализация. Очень сложно хорошо знать две хоть и смежные, но очень объемные и разные области.
И эта самая специализация и приводит нас к тому, что «devops-разработчик» внезапно появляется в команде, потому что хоть кто-то должен обладать полнотой знаний в области «как заставить это правильно работать в рамках инфраструктуры». Люди, которые могут и продукт хороший написать, и качественно его поддерживать конечно существуют, но их 1. мало, 2. они стоят ну очень много денег и как следствие нанимаются каким-нибудь гуглом на позицию SRE, о которой ниже.
Есть еще вариант купить экспертизу на стороне, но проблемы как таковой это не решает.
Кстати Google эту проблему компетенций осознал весьма давно и вместо внедрения DevOps придумал структуры работы, где появляется позиция SRE, на которую нанимаются те редкие люди, которые неплохо понимают и в программирование как таковое, в рамках создания продукта, и в эксплуатацию этих продуктов. Вкупе с жесткими правилами и условиями попадания продукта в прод это в целом позволяет им неплохо и стабильно работать. Что конечно не исключает наличия больших выделенных команд, которые занимаются более специализированными вещами — сервера, сети, базы, автоматизация и вот это все.
То есть нет, devops — это далеко не классический админ, его область ответственности и знаний гораздо шире. DevOps как методология в целом не исключает наличие в команде человека, который специализируется на эксплуатации. Ни у кого же не вызывает удивление, что frontend/backend/mobile/embedded программисты имеют специализацию, так почему не может быть еще одной, с фокусом на интеграцию и эксплуатацию?
Более того, эта методология в реальной жизни в целом не исключает и команду поддержки инфраструктуры. В любом случае, работы в эксплуатации много и вопрос ее распределения каждая компания решает как может.
DevOps как методология в целом не исключает наличие в команде человека, который специализируется на эксплуатации. ...
... , эта методология в реальной жизни в целом не исключает и команду поддержки инфраструктуры. В любом случае, работы в эксплуатации много и вопрос ее распределения каждая компания решает как может.
Золотые слова! Вот бы ещё эти самые "девопсы" и особенно манагеры от девопсов это могли осознать и принять.
Devops Developer есть в линкедине с обьяснением, что это такое.
Не будучи в силах терпеть проделки этого вечно дремлющего устройства и дабы преподнести ему урок бодрости, товарищ решительно разбудил его точным ударом в Enter.
А вот стоял бы скринсэйвер с паролем, и была бы у коллег привычка устанавливать голого Джигурду людям, которые оставляют разблокированный экран… В общем, пример, в котором плохо сразу всё
Самая типичная ошибка — называть людей девопсами
Девопс это человек, программирующий на ямле
товарищ решительно разбудил его точным ударом в Enter
Однажды в детстве (буквально — мне тогда было лет 10) я совершил похожий факап на домашнем компе, и с тех пор имею привычку будить комп исключительно нажатием Esc.
Всем удачи!!! Как и компаниям, которые оказывают услуги аутсорсинга.
А где должна быть граница между обязанностями девопса и дева? Есть крайние точки зрения, от "девы пишут код, а за попытки лезть в IaaC нужно бить по рукам” до “девопс обеспечивает инфраструктуру для разворачивания приложений (грубо, кубер и гитлаб), а всё остальное (манифесты, чарты, пайплайны ) делают девы, а девопс не знает и не должен знать даже какие приложения крутятся там, этакое внутреннее managed IaaS решение. Понятно, что это крайности, но где разумный компромисс?
но где разумный компромисскогда очень много людей — второй подход проявляется. Там обычно есть «девопсы по внутренним решениям» и «девопсы в командах разработки».
PS. Я правильно понимаю, что DevOps это как клапана без гидрокомпенсаторов, в перманентно не настроенном состоянии? :)
Первый абзац раздела "Байка про хромого девопса" — так и не понятно, какая была задача.
А арт-директора из вступления не Андреем звали?;)
Я так понимаю посыл статьи: "девопс сложно, там ни кто ни чего не понимает — приходите к нам"?
Или все же про бизнес который требует от бекенд разрабов еще и деплоем заниматься, не позаботившись спросить об опыте и желании? Ну и за одно приглядеть за сервером, чтоб 2 раза не вставать… Если человек уволился, это явно не от радости.
Про сеть замачено правильно, предмет сложный и потому нередко их разделяют, например на продопс и нетопс, потому винить девопс за то что на них повесили все… притянуто за уши.
В сухом остатке статью можно изтолковать так: Приходите к нам, заплатите в "5 раз больше" и будете это делать постоянно, за то не надо будет разбираться как управлять ит.
И в этом нет ни чего плохого, с покупкой бу или нового авто ситуация аналогичная.
Я пропущу детали и остановлюсь на «devops» решении анализа логов. Традиционный ELK сжигал примерно 70% сетевого трафика, на минимальном датасете (20% от максимального) терял до 40% логов.
Примерно лет 15 назал linkedin ввел понятие application monitoring'a. Например в ELK мы посылаем около 500 разных строк лога, которые ELK нам парсит, классифицирует и токенизирует. В результате — таймстемп + текст + 2-3 цифры на строку лога. Текст не меняется. Инновация в том, что бы вместо 800 байт строки лога отсылать упомянутые 2-3 цифры. Мы очень много экономим на трафике и обработке. Красивые маркетинговые ролики можно посмотреть на сайте AppDynamics и разных других аналогах.
Но для такого подхода вместо строки в лог нужно проектировать саму систему логирования. Срабатывает стереотип — они усложняют — мы сделаем проще… но проще не работает.
Подведя итог — методологии у крупного аутсорсера несколько другого уровня чем у среднестатического «девопса».
от программистов микроконтроллеров до арт-директора, который после 40 вдруг узрел новое призвание. Был даже студент-африканец, который едва говорил по-русски, но уже сделал головокружительную карьеру ростовой куклы, распугивающей пассажиров у выхода из метро.
Эхх ничего не меняется.
Это было в начале 2000-х каждый кулик кто занимался перепродажей компов и принтеров мнил себя аутсорсером и супер-мега интегратором.
Это было с печатной техникой. Каждый мнил себя инженером в печатном и допечатном оборудовании. Был живым свидетелем как товарищи сломали А0 и как на демо-образцах садились на проекционное стекло.
Это было когда зарождалась мода на ЕРП и прочее внедренчество. Каждый кулик мнил себя гуру ит-консалтинга.
Это было в начале второго десятилетия. Каждый кулик мнил себя если уж не офицером по безопасности, то как внедренец с многолетним опытом.
Хорошая, злободневная статья.
Касательно автоматизации есть хороший комикс от xkcd, по которому легко понять — нужно ли ею заниматься, или проще закидать людьми (дешевле будет):
https://xkcd.com/1205/
Свидетели DevOps: мифы и байки про девопсов и тех, кто их нанимает