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