Открыть список
Как стать автором
Обновить

Комментарии 47

бэкапшики
Оговорочка по Фрейду, не убирайте пожалуйста)
Раньше было: Хуяк-хуяк и в продакшн.
Теперь: Хуяк-хуяк и в контейнер.

И это называется красивым термином "Continuous integration"

— У нас БД упала! Где бэкапшик?
— Уволился.

"Задачи, которые выполняет девопс – это та же разработка, только инфраструктуры и процессов".


Ну как и следует из названия — "DEVeloper OPerationS". Во всех индустриях роль operations вполне себе определена (как и остальных бизнес-функций), а в IT до сих пор жаркие споры и непонятки. :-)

А откуда вы взяли такое название? в wikipedia немного по другому…
И с operations все просто en.wikipedia.org/wiki/Data_center_management#Operations. Боюсь, что непонятки исключительно на великом и могучем.
>DevOps is a set of practices that combines software development (Dev) and IT operations (Ops).
DevOps это набор технологий которые обьеденяют разработку програмного обеспечения и системное администрирование.
Если вернуться к истокам и просмотреть первую презентацию с употреблением слова DevOps, то можна услышать что автор презентации рассказывает о шаблоне — когда разаработчики пишут код, который сдают на определенном этапе готовности админам. Что создает много проблем. Методология DevOps предполагает активное участвие админов на более раннем этапе разработки — еще во время проектирования и тд тп

Не технологий, а практик. Практики не только и не столько в технологиях заключаются.

Для иллюстрации пример, который подвернулся на скорую руку

Плохой пример. docker и compose примитивные, а в кубер манифесте намутили все подряд — секреты, лимиты, политики все подряд, pvc. Ну вот совсем разные.

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

Он не просто длиннее будет из-за kind, apiVersion и прочих spec, но и содержать больше сущностей в принципе.


А эквивалентно или нет — это от точки зрения зависит. Кто-то считает, по определению не может быть эквивалентно, потому что если нода упадёт, то контейнер переедет в кубере и сдохнет в докере (забывая, впрочем, об однонодовых сетапах кубера и многонодовых, понимающих compose ), а для кого-то эквивалентность означает, прежде всего, возможность увидеть свой hello world в браузере и пофиг на HA, автомасштабирование и прочую безопасность.

Скажите, я правильно понял, что devops-разработчик — это просто переименованный админ? Ведь концепция DevOps (в идеале) состоит в том, чтобы слить команды разработки и эксплуатации

Да вы правильно поняли, должность по прежнему так и называется "системный администратор", а девопс — это методы его работы, но так уж сложилось что все подгузники — памперсы, а все внедорожники — джипы

Почему админ, а не разработчик? )

потому что ты администрируешь инфраструктуру по прежнему, только теперь через код

А код пишут разработчики обычно...

отчасти поэтому в слове devops есть «dev» :-) но строго говоря devops это все же в основном эксплуатация, мы же не будем взаправду называть плейбуки и манифесты настоящим исполняемым кодом?

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

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

И "админ, переименованный по-модному" сможет создать csi к8с оператора?! Со всеми необходимыми процесамми для разработки и поддержки? Или это задача для девелоперов?

А как это зависит от названия должности? Вопрос же не в названии, а в том, есть ли отдельная команда эксплуатации/развёртывания, или это делают те же самые люди, что и разрабатывают продукт. В последнем случае — это методология devops.

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

Так то оно так, но тут есть некоторый неочевидный эм, изъян.
Современная эксплуатация, если говорить за решения хотя бы среднего размера, по сложности освоения и обширности необходимых знаний весьма велика и весомо так превосходит объем знаний об этой области линейного программиста. И даже не особо линейного. И, возможно, она вообще по объему больше, чем обычный frontend/backend программист знает в рамках обязанностей по созданию продуктов.
Отсюда появляется специализация. Очень сложно хорошо знать две хоть и смежные, но очень объемные и разные области.
И эта самая специализация и приводит нас к тому, что «devops-разработчик» внезапно появляется в команде, потому что хоть кто-то должен обладать полнотой знаний в области «как заставить это правильно работать в рамках инфраструктуры». Люди, которые могут и продукт хороший написать, и качественно его поддерживать конечно существуют, но их 1. мало, 2. они стоят ну очень много денег и как следствие нанимаются каким-нибудь гуглом на позицию SRE, о которой ниже.
Есть еще вариант купить экспертизу на стороне, но проблемы как таковой это не решает.
Кстати Google эту проблему компетенций осознал весьма давно и вместо внедрения DevOps придумал структуры работы, где появляется позиция SRE, на которую нанимаются те редкие люди, которые неплохо понимают и в программирование как таковое, в рамках создания продукта, и в эксплуатацию этих продуктов. Вкупе с жесткими правилами и условиями попадания продукта в прод это в целом позволяет им неплохо и стабильно работать. Что конечно не исключает наличия больших выделенных команд, которые занимаются более специализированными вещами — сервера, сети, базы, автоматизация и вот это все.
То есть нет, devops — это далеко не классический админ, его область ответственности и знаний гораздо шире. DevOps как методология в целом не исключает наличие в команде человека, который специализируется на эксплуатации. Ни у кого же не вызывает удивление, что frontend/backend/mobile/embedded программисты имеют специализацию, так почему не может быть еще одной, с фокусом на интеграцию и эксплуатацию?
Более того, эта методология в реальной жизни в целом не исключает и команду поддержки инфраструктуры. В любом случае, работы в эксплуатации много и вопрос ее распределения каждая компания решает как может.
Нет, вы неправильно поняли. Devops-разработчик это разработчик который внедряет DevOps практики или методологии при разработке приложения.
Devops Developer есть в линкедине с обьяснением, что это такое.
Не будучи в силах терпеть проделки этого вечно дремлющего устройства и дабы преподнести ему урок бодрости, товарищ решительно разбудил его точным ударом в Enter.

А вот стоял бы скринсэйвер с паролем, и была бы у коллег привычка устанавливать голого Джигурду людям, которые оставляют разблокированный экран… В общем, пример, в котором плохо сразу всё

Я обычно чёрного властелина ставлю.
Но все-таки не скринсевйер с паролем а таки «попу поднял win+L нажал». Скринсейвер слишком легко обойти.
Или просто завести привычку пробуждать по ctrl например (даже удобно — кнопка в углу), ну или alt ;)

Самая типичная ошибка — называть людей девопсами

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

Девопс это человек, программирующий на ямле

товарищ решительно разбудил его точным ударом в Enter

Однажды в детстве (буквально — мне тогда было лет 10) я совершил похожий факап на домашнем компе, и с тех пор имею привычку будить комп исключительно нажатием Esc.

Как раз опасения подобных факапов бужу экран чем-то более «noop», к примеру, Ctrl или Shift, а вот Esc может и чего-то отменить лишний раз :)
Читается, как «подгорело от того что приходят новенькие и в случае проблем и поиска их решений, все остается на месте». Все что написано так и есть, также как есть запуск контейнеров, которые перед тем как запустится выполняют ряд предварительных ласк и не факт что запустится. Есть проблема — бери и делай, называй инженера хоть Сьюзана, хоть DevOps главное достойная оплата ожиданиям кандидата и такие же ожидания от работодателя. В случае если всех все устраивает, то радуемся. Если какую то из сторон не особо, то мы знаем где находится выход.
Всем удачи!!! Как и компаниям, которые оказывают услуги аутсорсинга.

А где должна быть граница между обязанностями девопса и дева? Есть крайние точки зрения, от "девы пишут код, а за попытки лезть в IaaC нужно бить по рукам” до “девопс обеспечивает инфраструктуру для разворачивания приложений (грубо, кубер и гитлаб), а всё остальное (манифесты, чарты, пайплайны ) делают девы, а девопс не знает и не должен знать даже какие приложения крутятся там, этакое внутреннее managed IaaS решение. Понятно, что это крайности, но где разумный компромисс?

Кажется, единого рецепта тут нет, и каждая команда решает, как удобнее именно ей. Границы тут условные, и надо делать так, как лучше всего получается. Где-то девопс больше дев, где-то меньше. Если человеку интересно лезть в код, и это реально приносит пользу – наверное, за это не надо бить по рукам. Жестко разграничивать зоны ответственности следует только объективно есть вред от несогласованного вмешательства.
но где разумный компромисс
когда очень много людей — второй подход проявляется. Там обычно есть «девопсы по внутренним решениям» и «девопсы в командах разработки».
Ну в общем-то да, если человек ищет в процессии новое мЫшление, то он найдет только профессиональный идиотизм.

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

Первый абзац раздела "Байка про хромого девопса" — так и не понятно, какая была задача.

А зачем? Тут же в концовке все поясняют…
"Лучше поищите стороннюю экспертизу для подстраховки."

А арт-директора из вступления не Андреем звали?;)

Я так понимаю посыл статьи: "девопс сложно, там ни кто ни чего не понимает — приходите к нам"?
Или все же про бизнес который требует от бекенд разрабов еще и деплоем заниматься, не позаботившись спросить об опыте и желании? Ну и за одно приглядеть за сервером, чтоб 2 раза не вставать… Если человек уволился, это явно не от радости.
Про сеть замачено правильно, предмет сложный и потому нередко их разделяют, например на продопс и нетопс, потому винить девопс за то что на них повесили все… притянуто за уши.
В сухом остатке статью можно изтолковать так: Приходите к нам, заплатите в "5 раз больше" и будете это делать постоянно, за то не надо будет разбираться как управлять ит.
И в этом нет ни чего плохого, с покупкой бу или нового авто ситуация аналогичная.

Ну аутсорсинг имеет смысл на мой взгляд. Например небольшая продактовая компания вышла на большого заказчика. Потом оказалось, что у них очень много ботлнеков и на обьеме данных заказчика ничего не работает. Заказчику концептуальная идея продукта понравилась и он согласился на доработку. После 2х лет вливания денег и нулевых результатов большой заказчик обратился к аутсорсерам. Он получил код продукта, кое какую документацию и уныло работающий продакшен в амазоне.
Я пропущу детали и остановлюсь на «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/

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.