РАБОТА · 13 октября 2016, 11:30 · Отдел информации dev.by
«Все ищут DevOps-инженера — но мало кто знает, зачем он нужен»

В преддверии минской конференции DevOpsBy 2016 dev.by расспросил DevOps-инженера ISsoft Алексея Денисевича о преимуществах и недостатках одной из самых «модных» и востребованных позиций последних лет.

Мода на DevOps: «Звучит круто — значит надо брать»

— В сравнении с остальным миром, где методология DevOps заработала в 2009 году, может показаться, что мы опаздываем на 7 лет: по сути, у нас «девопс» ещё только зарождается. 

Пару лет назад я не видел таких вакансий нигде в Минске — и тут внезапно повсюду «нужен девопс». Когда я поменял профессиональный статус в LinkedIn c админа на DevOps-инженера, то сразу почувствовал этот ажиотаж на себе.  

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

По учебнику, DevOps — это методология, которая позволяет связать мир программистов и других технических подразделений компании (операторы, администраторы, тестировщики, пр.). Людей, которые понимают, как это реализовать на практике, называют DevOps-инженерами. В сравнении с тем же системным администратором, «девопс» — это намного более широкое направление, охватывающее всю структуру работы определенного бизнеса. Я не говорю, что DevOps-инженер — это визионер. Он не бизнес-стратег: не строит бизнес-логику и не вмешивается в планы компании.

6 главных принципов «девопса»

Есть шесть базовых задач «девопса». Умные люди пропагандируют эти подходы уже 7 лет, и они правы, это работает.

1. Связать два мира: наладить общение между программистами и всеми остальными ИТ-отделами. Как правило, эти миры изолированы друг от друга: программисты сами себе «варятся», операторы — сами себе, и в итоге по ряду вопросов начинается противостояние, чего быть не должно. Мы не психологи, но мы должны так наладить работу и выстроить процессы, чтобы другие ребята чувствовали себя комфортно и взаимодействовали.

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

3. Вводить единообразное окружение. Бывает, программисты разворачивают тестовое окружение, создают виртуальные машины и базы, а потом у тех же операторов, тестировщиков, техподдержки это не работает. Начинаются «тёрки». «У меня все отлично работает», — говорит программист. Следовательно, нужно ввести единообразие: позволить и тем и другим оперировать на идентичных окружениях.

4. Автоматизация! Поскольку человек — существо, которому свойственно ошибаться, желательно автоматизировать всё, что нужно делать вручную (в 90% случаев это осуществимая задача), особенно сложные многосоставные ручные действия. Есть конторы, у которых релизы новых версий программ занимают до шести недель (и ещё неизвестно, что сломается по дороге). Если же всё это автоматизировать, можно получить результат и за пару часов.

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

Автоматизация — самая заметная часть в обязанностях «девопса», её сразу видно.

К слову, на предстоящей конференции я буду рассказывать про CloudFormation — это сервис от Amazon, позволяющий создавать другие сервисы и ресурсы в автоматизированном режиме. Этот инструмент облегчает работу DevOps’а во многих аспектах. Постараюсь рассказать, зачем и как им пользоваться на примере наших внутренних разработок в ISsoft.

5. Собирать метрики, чтобы понимать, каковы результаты вашей работы. Во-первых, самые банальные метрики — системные: оперативная память на машинах, загрузка каналов, скорость передачи данных, нагрузка на процессоры. Во-вторых, бизнес-метрики: сколько клиентов что-то купили, сколько не купили, но собирались, почему часть из них ушли. Желательно, чтобы эти два вида метрик коррелировали между собой, чтобы чётко понимать, где проблема: в железе или/и в бизнесе.

6. Процесс улучшения — а улучшить всегда есть чего. Реализация первых 5 пунктов почти всегда несовершенна, поскольку этим опять-таки занимается человек.

Это книжные вещи, но в реальности всё примерно так и происходит. Как правило, к вашим услугам прибегают ИТ-проекты, у которых есть проблемы по всем 6-ти пунктами. Процесс настройки может быть как быстрым, так и долгим. Важно общаться со всеми: DevOps-инженер включён в очень плотное общение, с ежедневными митапами и стендапами. Иногда, в течение дня, может пройти от 6 до 8 «митингов». Если вы любите поговорить, это позиция, где нужно говорить каждый день.

Работа нон-стоп — не помню за год ни одного дня, чтобы я прохлаждался. Даже когда всё сделано, наступает пункт №6: всегда есть, что улучшить.

Сопротивление команд: «Неизвестно кто пришёл и начал диктовать»  

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

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

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

Однако новый рабочий процесс создаётся не для того, чтобы кого-то закабалить и навязать список правил, а для облегчения работы всех подразделений. В итоге должны выиграть все: бизнес, программисты, отделы — и «девопсы».

Нужно дипломатично подходить к общению. Нельзя навязывать новые процессы — это должно выглядеть как взаимодействие. «Давай, друг, я помогу тебе, ты поможешь мне: и тебе меньше работы, и мне здорово». Люди любят взаимодействие, если оно правильно построено, а если в приказном тоне — «неизвестно кто пришёл и начал что-то диктовать»  — то начинают внутренне сопротивляться. «Девопс» должен органично вливаться желательно во все ИТ-процессы отделов заказчика.

Почему лично я ушёл из админов в «девопсы»?

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

Как стать качественным «девопсом»? Тут трудно избежать клише, но важно не лениться. Это бесконечный процесс обучения.

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

Конечно, не получится знать всё: может, «девопсы», которые начинали 7 лет назад, знают и понимают фантастическое количество вещей: как-никак, они стояли у истоков. Но такого рода требования к «молодым» «девопсам» сродни требованию иметь все виды прав на все виды транспорта перед тем, как разрешить вам сесть за руль машины.

Минусы позиции: DevOps «ходит и ничего не делает»?  

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

Конечно, если кому-то нравится сидеть с 10.00 утра до 10.00 утра, «я люблю свою работу, останусь здесь в субботу» — на здоровье, но я не сторонник трудоголизма и тяжёлых нагрузок. Человеку свойственно ошибаться, а невыспавшийся, уставший — и, как результат, злой человек — вдвойне склонен к ошибкам. В случае какого-нибудь ЧП посреди ночи на проекте человек, отработавший 12-14-часовой рабочий день, с большей долей вероятности не сможет быстро и правильно среагировать на возникшую ситуацию.

Некоторым может показаться, что «девопс» «ходит и ничего не делает»: во-первых, такого не бывает, а во-вторых, если и бывает, значит, у него всё настроено, и он обдумывает пункт №6.

Вообще, про «ходит и ничего не делает» — давний парадокс, характерный для многих работ, которые предполагают хорошее исполнение: если вы построили дом хорошо, то вернётесь к капремонту лет через 20.

Также минусом может считаться неправильно выбранная компания: многие нанимают «девопса», не понимая, что он должен делать. В итоге он работает себе админом, как и работал, и думает «что я здесь делаю, я же вроде как «девопс?». Или нанимают на перспективу: мол, я никогда не копаю, но лопата пусть будет, пригодится в хозяйстве. Нужно чётко осознавать, в какую компанию ты идёшь, чем они занимаются, зачем ты им нужен.

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

А как у них: «девопсы» на Западе почти вышли из моды?

Мы продаём услугу «девопса» американцам, которые вроде как должны быть на 7 лет впереди.

Бытует странное мнение, что DevOps-инженеры на Западе уже почти «вышли из моды». Однако, если это так, то как объяснить интерес американских компаний к нашим «девопсам» и регулярные предложения европейских коллег?

Активный поиск «девопсов», в частности, «хантинг» белорусов позволяет мне утверждать, что у нас уже есть хорошие специалисты за небольшие, по меркам Америки или Европы, деньги. Белорусы трудолюбивы, соотношение цены и качества я считаю оптимальным.

Если вы решили переезжать в Европу, а у вас нет за плечами 2-5 лет продуктивного DevOps-стажа, не стоит забывать, что придётся подниматься с низов. Выхлоп может быть по итогу меньше, если с калькулятором посчитать налоги, которые нужно уплатить, стоимость аренды жилья не «на отшибе», да и просто стоимость жизни. Если вы готовы терпеть 2-3 года «айтишной»  нищеты и упорно работать, то наверняка пойдёте вверх.

На текущий момент я не вижу большого смысла уезжать в Европу — вполне вероятно, на меньшие деньги — и доказывать в течение пары лет, что ты достоин быть те же, кем был до этого в Беларуси.

Резюме: DevOps — ответственность всей команды

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

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

Источник: dev.by
Новые комментарии

Обсуждение

Missing

Название компании поправьте

Missing-male
+4

Спасибо, хотел узнать зачем нужны devops. "Узнал"....

>> 1. "Связать два мира", "наладить общение", "наладить работу и выстроить процессы, чтобы другие ребята чувствовали себя комфортно и взаимодействовали", разруливать, когда "по ряду вопросов начинается противостояние из-за того, что программисты сами себе «варятся», операторы — сами себе...

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

>> 2. Хорошо понимать, как работают программисты

это не цель, это требование

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

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

>> 4. Автоматизация!

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

>> 5. Собирать метрики, чтобы понимать, каковы результаты вашей работы.

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

>> 6. Процесс улучшения — а улучшить всегда есть чего.

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

Опять же, непосредственно devops здесь причём?

---

думал увидеть какие-нибудь рассуждения про сontinuous integration и прочее в этом же духе... а такое ощущение, что просто еще раз только подтвердили, что никто не понимает, зачем DevOps-инженер нужен, а если и понимает, то явно для этих целей не использует...

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

Missing-male

Имхо, 1, 3, 4, 5 и ведут к CI & CD, без этого базиса будет тяжело и малоэффективно внедрять. Да и само по себе CD & CI входит в пункт автоматизации, по-идее.

По 1 пункту: менеджер не налаживает технические аспекты взаимодействия. А вот объяснить, как код будет работать в проде да навязать единые стандарты и, к примеру, vagrant виртуалки отделам dev & qa приходилось, особенно в аутсорс командах.

Классические админы сейчас воспринимаются больше с точки зрения настройки сети, железа и голой оси, девопсы ближе к автоматизации и общей архитектуре. Хотя тут больше вопрос классификации и разделения ролей в команде =)

devops, практика 4 годика

Missing-male

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

Я считаю, что такое мнение ошибочно. Просто при расширении каких то функций, админ всё равно будет оставаться админом и концентрироваться не на задаче, а на инструментах. На создании окружения, инфраструктуры, в которой пользователям (в данном случае программистам, тестировщикам и т.д.) будет более удобно и комфортно решать задачу. Даже если это окружение и будет в итоге обеспечивать CI & CD.

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

Как говорится, здесь надо немного чувствовать разницу...

Missing-male

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

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

Большинство разработчиков, к сожалению, до сих пор плохо понимают, как их продукт будет работать в продакшене.

Ситуация меняется в лучшую сторону, но все же далека от идеала...

Missing-male

девопс = админ на продакшене?

вырастает? помощник админа -> админ -> девопс?

---

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

---

админ на продакшене = админ

админ + разработчик + qa -> девопс

Missing-male

А по-моему, неправильно как раз говорить вот такое:

>> Просто при расширении каких то функций, админ всё равно будет оставаться админом и концентрироваться не на задаче, а на инструментах

1) админ тоже концетрируются на задаче, а не на иструментах, как и любой другой адекватный спец

2) Девопс тоже концетрируется на задаче: улучшение процесса разработки, тестирования, поставки и успешного функционирования продукта, зачастую через автоматизацию. И создание окружения напрямую эту задачу решает

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

Missing-male

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

Когда он сконцентрируется на задаче программиста, то есть будет участвовать не с точки зрения ОБЕСПЕЧЕНИЯ решения бизнес задачи программистом, а начнет принимать НЕПОСРЕДСТВЕННОЕ УЧАСТИЕ в решении бизнес задачи, он как тот вурдалак, начнет превращаться в девопса.

Как то так...

Missing-male
+1

Основная бизнес задача большинства организаций - получение прибыли путем оказания услуги или продажи товара клиенту (либо создание видимости для инвесторов), будь то b2b или b2c. Разработка приложения программистом - одно из средств создания этой услуги, а то и одно из состовляющих. Работа qa, админов, девопсов, менеджеров - тоже составляющая этой работы. И они все ПРИНИМАЮТ НЕПОСРЕДСТВЕННОЕ УЧАСТИЕ в решении этой бизнес задачи - получении прибыли. И если бизнес может обойтись без этой технической состовляющей, то выгодняет всю эту братию на мороз без зазрения совести.

И программистов в этой цепочке увольняют далеко не последними.

А вот ОБЕСПЕЧЕНИЕМ РЕШЕНИЯ бизнес ЗАДАЧИ ПРОГРАММИСТОМ занимаются менеджеры, разного рода скрам-мастера и на худой конец тимлиды, ну ни как не админы, девопсы и иже с ними. И никто девопса только ради программистов нанимать не будет, не льстите им ;)

Missing-male

>> И никто девопса только ради программистов нанимать не будет, не льстите им ;)

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

De9d091af792f4b9d1678ec4e24e2a43?1506447130

"думал увидеть какие-нибудь рассуждения про сontinuous integration и прочее в этом же духе... а такое ощущение, что просто еще раз только подтвердили, что никто не понимает, зачем DevOps-инженер нужен, а если и понимает, то явно для этих целей не использует..."

Так вперед - излагайте, мы Вас почитаем :)

Missing-male
+1

Так вперед - сходите на конференцию, узнаете. Зачем мне у ребят хлеб отбирать. 20 у.е. - бутылка неплохого виски билет стоит. ;)

уточнил... хм... даже не 20... тут не виски, тут уже и коньячка можно... ;)

De9d091af792f4b9d1678ec4e24e2a43?1506447130

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

По поводу той самой конференции, думаю, что у тамошних докладчиков интерес вовсе не в 20ти., а как раз изложить свое субъективное видение особенностей DevOps и, возможно, узнать от коллег что-то новое.

Ну а про "виски" и "коньяк" за ~20 у.е. - эт, извините, дичь)

Missing-male
+1

>> а как попросил систематизировать

где? "Так вперед - излагайте"? очуметь "попросил"...

а так, задавайте конкретные вопросы...

>>Ну а про "виски" и "коньяк" за ~20 у.е. - эт, извините, дичь)

ахах... конкуренцию Rich Russian Kids могут составить только Rich Belarusian Developers...

"The Cream of Society", етить-колотить ;))) http://belarusdigest.com/story/programmers-belarus-cream-society-10631

De9d091af792f4b9d1678ec4e24e2a43?1506447130

Это и был мой вопрос к Вам: не нравиться как излагают другие - излагайте сами и не очумевайте :)

Не читал, но осуждаю) Каждому своё ;)

Missing-male

ну так можно было сразу коротко и ясно написать "спервадобейся"

а то начали... я задал вопрос, я вас попросил, где ваш ответ, не хотите бисер метать и т.п. и т.д... :)

Missing-male
+3

фуфел от маркетологов

Missing
+3

Информация подана очень приятно, не пожалел времени

F66e33f1b11b0312e10c2ed1a9e39188?1507617403
Sergey Bodrov
– инженер-программист в Новатех

Судя по английской вики, DevOps это тупо эникейщик для программеров.

Missing-male

>> Белорусы трудолюбивы

Ленивы. Все. Особенно я. Отчасти поэтому приходится скрипеть мозгами чтобы автоматизировать и не выполнять пустую работу. Но вообще это косяк :(

Missing-male

баян про лень как проявления ума и сообразительности слышу его уже более 10 лет. могу сказать что баян не соотв. действительности.

Missing-male

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

Missing-male

"DevOps-инженер"

(facepalm)... жду статей о Agile-архитекторах.

ps добавьте ссылку на первоисточник для картинки

Missing

В журнале «Системный администратор» предложили дискуссию не только о преимуществах и востребованности DevOps-инженеров, но и какой проектный опыт, технические навыки сейчас необходимы для новой вакансии в компаниях. Более подробно https://vk.com/samag?w=wall-26064343_870


Авторизуйтесь, чтобы оставлять комментарии

Использование материалов, размещенных на сайте, разрешается при условии прямой гиперссылки на dev.by. Ссылка должна быть размещена в подзаголовке или в первом абзаце публикации.
datahata — хостинг в Беларуси