DevOps-инженер, в Mail.ru Group и преподаватель курсов DevOps в GreenBrains Андрей Буранов рассказывает о профессии, пороге входа и уровне зарплаты (один из самых высоких на рынке).
DevOps-инженер, в Mail.ru Group и преподаватель курсов DevOps в GreenBrains Андрей Буранов рассказывает о профессии, пороге входа и уровне зарплаты (один из самых высоких на рынке).
Если представить, что ИТ-проект — это пазл, где за каждую деталь отвечает определенный специалист, то DevOps — это тот, кто собирает все пазлы-компоненты в единую картину и в итоге запускает проект.
DevOps изучает особенности работы каждого компонента, их взаимодействие друг с другом, возможность их запуска в той или иной системе и т. д. Моя задача — знать операционную систему, с которой я работаю от и до, чтобы уметь решать любые задачи, организовывать работу, например, приложений внутри этой системы.
Например, команда разработки создала два приложения, которые должны работать друг с другом. Каждый разработчик знает характеристики своего продукта, но до меня эту информацию не донесли или по каким-то причинам я не могу получить эту информацию. Я, используя свой инструментарий, выясняю, как это все взаимодействует друг с другом и внешней средой. Как-то был такой нюанс: нам предложили схему проекта, который в теории должен был работать хорошо и предоставлял определенные сервисы, но после того, как я провел расследование и установил, как работают вместе эти два сервиса, выяснилось, что такая схема работать не может в принципе. Мы ее изменили: учли архитектуру приложений, структуру взаимодействия и в общем-то пришли к другому варианту решения. Все это разработчиков не коснулось — каждый отвечал за свое приложение. А вот как структурировать их взаимодействие — это уже моя задача.
Основной инструментарий DevOps — знание и понимание операционной системы, опыт, желание учиться новому и постигать сложные задачи.
Я работаю в операционной системе Linux. Работаю при помощи знания этой системы, моего опыта работы в ней, изучения изменений и трендов и логического мышления — вот, пожалуй, мои главные интрументы. Притом необходимо постоянное развитие. Новые версии операционных систем могут серьезно отличаться от старых, и моя задача — найти, в чем эти отличия и как с ними работать.
DevOps должен обладать объемлющим взглядом на архитектуру всей системы, критическим мышлением, умением локализовать вопрос, который вызывает затруднения, и предложить решения.
Обязательно должно быть желание объять всю структуру целиком, а не маленький элемент. Опыт подсказал, что всегда нужно выходить за рамки сегмента, даже если вам поручен только он. Благодаря этим качествам начинается складываться общая картина.
Возможно, другие мои коллеги, рассказывая про DevOps, включили бы в это понятие программирование, стратегическое планирование развития… По мне же, DevOps включает в себя то же самое, что и профессия сисадмина. Разница в масштабе мышления и в способности обучаться.
Вот пример из моего опыта. Я недавно подписался на один благотворительный проект помощи животным. В команду требовался DevOps. В процессе работы над проектом я доносил информацию, предлагал варианты построения архитектуры их приложения, настраивал сервер и спрашивал, что им надо и при этом что я могу им предложить. То есть по факту руководил небольшой группой разработчиков в техническом плане и с предложенным вариативом подходов. Поэтому, наверное, самым точным разделением профессий сисадмина и DevOps будет то, что первый занимается техническим выполнением поставленных задач, второй непосредственно ищет решения, знает, какие требования нужны для команд, в какой-то степени руководит процессом.
Сисадмин ждет информации о том, что ему нужно делать. DevOps видит единую картину и сам предлагает оптимальный вариант для решения тех или иных задач, ориентируется в разработке. Это следующая ступень развития системного администратора.
Спокойные дни, когда задачи сводятся к поддержанию проекта в рабочем состоянии, сменяются авралами, когда запускаются новые проекты или вносятся изменения в существующие.
DevOps формируются, исходя из конкретного проекта, над которым вы работаете. В моем мировоззрении эти проекты можно разделить на два типа. Первый, достаточно ответственный и устоявшийся, это когда вы приходите в проект, где все работает, и вам нужно его поддерживать или что-то менять, если будет требоваться.
С точки зрения «интересности» — это самый неинтересный проект. Когда ты входишь в систему, где все стабильно, работает и там все хорошо, то для тебя это становится миром инструкций.
Уже есть какой-то набор команд, порядок действий, согласований, вариантов решения, ошибок, в которых ты начинаешь существовать. И твоя задача — сделать так, чтобы проект не простаивал ни секунды. Максимальная ответственность, минимальная самодеятельность. Хотя иной раз, если предыдущий DevOps не оставил для тебя инструкций и по разным причинам эта информация недоступна, ты должен сам разобраться в проекте.
Второй вариант — вы строите новый проект. Если поступила задача, которая подразумевает конечную цель, определенный набор компонентов, группу разработчиков, ты начинаешь все собирать воедино, выстраивать архитектуру в правильной форме, которая будет удовлетворять потребности клиента, проекта в целом и ваши потребности в частности. Чтобы вы не создали структуру, в которой сами через пару месяцев не сможете ориентироваться.
Такие проекты интересны тем, что тебе нужно объединять и внедрять приложения и другие разработки, в такой комбинации с которой никто до этого не работал.
Но ведь со временем любой новый проект становится устоявшимся и перерастает в первый вариант?
Совершенно верно, но ты продолжаешь работать в нем — на поддержание, внедрение чего-то нового. Никогда не бывает такого, что вы приходите на работу и вам нечего делать. Всегда есть задачи. Как правило, вы следите за работой существующего, иногда вносите определенные изменения — например, нужно изменить имена персонажей в игре. Это достаточно спокойно, рутинно. Ваша задача — чтобы все работало и не было простоев проекта.
А бывают и авралы, когда нужно вносить большие изменения в существующий проект или запускать новый. Допустим, в игре нужно не просто поменять имена персонажей, но и внести существенные изменения в сюжет, инструментарий, графику и т. д. Тогда работа становится максимально сосредоточенной. Небольшая ошибка, пропуск одной команды или буквы — это может обернуться катастрофой. У меня за последние четыре года пару раз после изменения проекта просили все вернуть назад. Объемы данных были большие и возврат назад занимал часов пять. А все потому, что разработчики не те инструкции прислали. Не указали пару пунктов. Возвращаешь назад и начинаешь все делать по-новому, но с внесенными правками.
В DevOps приходят те, кто любит эту работу. Есть закон Парето, который я очень люблю цитировать. 80% результата дают 20% усилий. И о второй части как правило все забывают. Потому что вторая часть значит, что 80% усилий дадут вам всего 20% результата. Нюанс в том, что профессионал высокой квалификации ценен теми 20% результата, на которые затрачивается 80% усилий. То есть когда вы приходите в профессию, у вас прирост знаний идет очень быстро. Когда вы чего-то достигли и у себя по полочкам разложили, дальше прирост знаний идет очень медленно, а времени вы тратите не меньше, если не больше. И если вы не любите то, чем занимаетесь, вы не выдержите.
Второе, немаловажное качество для DevOps — желание постигать новое. Например, я — сторонник виртуализации. Сегодня этот подход устаревает, потому что есть более быстрые и простые решения. И вот буквально недавно мне прилетела задача развернуть определенную систему, взаимосвязанные друг с другом компоненты именно в систему контейнеризации. Для меня это некомфортно, не люблю я это. Но есть задача, и я начинаю ее решать, погружаться в эту тему, понимать, как там все взаимодействует, как это все настроить, связать воедино. Вроде бы не хочется, но я понимаю, что это современное направление и точно знания лишними не будут. Это то, о чем я постоянно говорю студентам — чем больше вы умеете, тем выше ваша стоимость, все достаточно просто.
GeekBrains онлайн-университет, который обучает DevOps-инженеров с нуля.
Я считаю, что профессии DevOps можно научиться любому. По образованию я инженер, но Linux в универе мы не изучали. И вот в один прекрасный момент я понял, что моя комфортная жизнь зависит от того, напрягаю я мозг или нет. Когда напрягаю, мне комфортно. Когда нет — мне плохо. Я в тот момент подумал, а не почитать ли мне высшую математику, которую ненавидел в универе? Но потом решил совместить приятное с полезным и думаю, вроде как-то Linux давно хотел изучить, но не складывалось. И вроде как мозг можно напрячь, и платят за это неплохо. Памятуя книжный магазин, видел полки «для чайников». Оказалось, был и Linux для чайников. Изучил. А дальше — практика-теория-практика-теория. На практике сначала были какие-то примитивные вещи, начало получаться, я продолжал изучать систему, постигать ее структуру, что там внутри, как что с чем взаимодействует, откуда что идет, кому что сообщает, примерно такой путь. Первую работу по Linux я получил через год после начала изучения этой системы. Взяли меня с пробелами в знаниях, но в процессе работы я продолжал постигать эту систему. И вот научился. Сейчас работаю специалистом по Unix-системам Mail.Ru Group.
Нужно постичь все: архитектуру компьютера, системы, вам нужно быть специалистом во всех областях или, как минимум, понимать все области, связанные с ИТ. Здесь нельзя сказать: я знаю определенный язык программирования и все. Нужно знать все.
Вам скажут: у нас есть такой набор данных, такой набор приложений и вот есть такая инфраструктура — запускай. И вы не можете сказать: знаете, я привык работать только с такими программами и т. д. Нет. У вас есть задачи, решения, вы DevOps — запускайте.
В компании GreekBrains есть факультет DevOps, где можно обучаться с нуля. Я там работаю, веду всего 3 курса:
Мне нравится обучать новичков. Как дать им понять, подходит ли им профессия DevOps? Я говорю так: попробуйте ввести запрос в поисковике и нажать enter. Если вам интересно узнать, что происходит с операционной системой во время совершения запроса, как она выполняет команду, через какие процессы проходит с момента нажатия на клавишу до выдачи результата — стоит попробовать.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.