Хотите дальше читать devby? 📝
Support us

«Все ищут DevOps-инженера — но мало кто знает, зачем он нужен»

Оставить комментарий
«Все ищут 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 — ответственность всей команды: это взаимодействие всех узлов, и если кто-то сопротивляется, особенно программисты, нужный эффект получить не удастся.

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

Помогаете devby = помогаете ИТ-комьюнити.

Засапортить сейчас.

Читайте также
8 актуальных и интересных курсов по Rust (июнь 2023) + бонус от GitHub
8 актуальных и интересных курсов по Rust (июнь 2023) + бонус от GitHub
8 актуальных и интересных курсов по Rust (июнь 2023) + бонус от GitHub
Рассмотрели преимущества и особенности языка Rust, а также сделали подборку курсов по нему, которые будут интересны как новичкам, так и опытным программистам.
7 комментариев
11 курсов DevOps, чтобы разобраться в теме и прокачать скиллы (июнь 2023)
11 курсов DevOps, чтобы разобраться в теме и прокачать скиллы (июнь 2023)
11 курсов DevOps, чтобы разобраться в теме и прокачать скиллы (июнь 2023)
DevOps-инженеров можно назвать одними из самых востребованных и высокооплачиваемых специалистов в ИТ-сфере. Поэтому, если вы хотите освоить эту профессию, разобраться в том, что такое DevOps-подход или просто усовершенствовать свои навыки, обратите внимание на список курсов, подготовленный Digitaldefynd и дополненный нами. 
5 комментариев
Разработчик создал дверной звонок, который реагирует на мяуканье кота
Разработчик создал дверной звонок, который реагирует на мяуканье кота
Разработчик создал дверной звонок, который реагирует на мяуканье кота
Мануал для джуна. Что нужно знать начинающему в DevOps: 30 вопросов и советы опытного лида
Мануал для джуна. Что нужно знать начинающему в DevOps: 30 вопросов и советы опытного лида
dev.ua
Мануал для джуна. Что нужно знать начинающему в DevOps: 30 вопросов и советы опытного лида

Хотите сообщить важную новость? Пишите в Telegram-бот

Главные события и полезные ссылки в нашем Telegram-канале

Обсуждение
Комментируйте без ограничений

Релоцировались? Теперь вы можете комментировать без верификации аккаунта.

Комментариев пока нет.