«Обучиться с нуля тяжело». Специалист Mail.ru Group про будни DevOps-инженера

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 не оставил для тебя инструкций и по разным причинам эта информация недоступна, ты должен сам разобраться в проекте. 

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

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

Но ведь со временем любой новый проект становится устоявшимся и перерастает в первый вариант?

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

А бывают и авралы, когда нужно вносить большие изменения в существующий проект или запускать новый. Допустим, в игре нужно не просто поменять имена персонажей, но и внести существенные изменения в сюжет, инструментарий, графику и т. д. Тогда работа становится максимально сосредоточенной. Небольшая ошибка, пропуск одной команды или буквы — это может обернуться катастрофой. У меня за последние четыре года пару раз после изменения проекта просили все вернуть назад. Объемы данных были большие и возврат назад занимал часов пять. А все потому, что разработчики не те инструкции прислали. Не указали пару пунктов. Возвращаешь назад и начинаешь все делать по-новому, но с внесенными правками. 

Чем больше вы умеете, тем выше ваша стоимость

В DevOps  приходят те, кто любит эту работу. Есть закон Парето, который я очень люблю цитировать. 80% результата дают 20% усилий. И о второй части как правило все забывают. Потому что вторая часть значит, что 80% усилий дадут вам всего 20% результата. Нюанс в том, что профессионал высокой квалификации ценен теми 20% результата, на которые затрачивается 80% усилий. То есть когда вы приходите в профессию, у вас прирост знаний идет очень быстро. Когда вы чего-то достигли и у себя по полочкам разложили, дальше прирост знаний идет очень медленно, а времени вы тратите не меньше, если не больше. И если вы не любите то, чем занимаетесь, вы не выдержите. 

Второе, немаловажное качество для DevOps — желание постигать новое. Например, я — сторонник виртуализации. Сегодня этот подход устаревает, потому что есть более быстрые и простые решения. И вот буквально недавно мне прилетела задача развернуть определенную систему, взаимосвязанные друг с другом компоненты именно в систему контейнеризации. Для меня это некомфортно, не люблю я это. Но есть задача, и я начинаю ее решать, погружаться в эту тему, понимать, как там все взаимодействует, как это все настроить, связать воедино. Вроде бы не хочется, но я понимаю, что это современное направление и точно знания лишними не будут. Это то, о чем я постоянно говорю студентам — чем больше вы умеете, тем выше ваша стоимость, все достаточно просто.

GeekBrains онлайн-университет, который обучает DevOps-инженеров с нуля. 

  • Дадим необходимые знания
  • Вместе оформим резюме
  • Предложим подходящие вакансии
  • Поможем получить работу мечты

Начинал изучение операционки с книги «Linux для чайников» и через год получил работу

Я считаю, что профессии DevOps можно научиться любому. По образованию я инженер, но Linux в универе мы не изучали. И вот в один прекрасный момент я понял, что моя комфортная жизнь зависит от того, напрягаю я мозг или нет. Когда напрягаю, мне комфортно. Когда нет — мне плохо. Я в тот момент подумал, а не почитать ли мне высшую математику, которую ненавидел в универе? Но потом решил совместить приятное с полезным и думаю, вроде как-то Linux давно хотел изучить, но не складывалось. И вроде как мозг можно напрячь, и платят за это неплохо. Памятуя книжный магазин, видел полки «для чайников». Оказалось, был и Linux для чайников. Изучил. А дальше — практика-теория-практика-теория. На практике сначала были какие-то примитивные вещи, начало получаться, я продолжал изучать систему, постигать ее структуру, что там внутри, как что с чем взаимодействует, откуда что идет, кому что сообщает, примерно такой путь. Первую работу по Linux я получил через год после начала изучения этой системы. Взяли меня с пробелами в знаниях, но в процессе работы я продолжал постигать эту систему.  И вот научился. Сейчас работаю специалистом по Unix-системам Mail.Ru Group.

Если вы входите в профессию с нуля — вам будет тяжело

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

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

В компании GreekBrains есть факультет DevOps, где можно обучаться с нуля. Я там работаю, веду всего 3 курса:

  • Linux рабочая станция
  • Операционные системы
  • Системный администратор: стажировка

Мне нравится обучать новичков. Как дать им понять, подходит ли им профессия DevOps? Я говорю так: попробуйте ввести запрос в поисковике и нажать enter. Если вам интересно узнать, что происходит с операционной системой во время совершения запроса, как она выполняет команду, через какие процессы проходит с момента нажатия на клавишу до выдачи результата — стоит попробовать. 

Записаться на курс

Хотите сообщить важную новость? Пишите в Телеграм-бот.

А также подписывайтесь на наш Телеграм-канал.

btc
Bitcoin
btc
$50 861,00
+3,93%
eth
eth
$4 320,20
+1,97%
xrp
xrp
$0,82
+2,91%
shib
shib
$0,00
+4,25%

Читайте также

IBM, Яндекс, EPAM: собрали самые популярные курсы за ноябрь
IBM, Яндекс, EPAM: собрали самые популярные курсы за ноябрь
IBM, Яндекс, EPAM: собрали самые популярные курсы за ноябрь
Вакансии для DevOps-инженеров на jobs.dev.by
Вакансии для DevOps-инженеров на jobs.dev.by
Вакансии для DevOps-инженеров на jobs.dev.by
Спросили у мидла и сеньора, сколько реально нужно времени, чтобы стать разрабом
Спросили у мидла и сеньора, сколько реально нужно времени, чтобы стать разрабом
Спросили у мидла и сеньора, сколько реально нужно времени, чтобы стать разрабом
Сколько должно пройти времени, чтобы зарабатывать хотя бы $1000? Есть смысл вписываться в курсы? Нужны ли кому-то их выпускники? И вообще, курсы или университет? А какие нетехнические скиллы должны быть у любого айтишника? Поговорили с двумя айтишниками разных поколений — Александром, Senior Software Engineer, и Владом, Middle Frontend Engineer — узнали, что они думают по этому поводу, и обсудили актуальные вопросы вайтишки.
13 комментариев
Карго-культ вокруг DevOps: как навредить проекту из лучших побуждений
Карго-культ вокруг DevOps: как навредить проекту из лучших побуждений
Карго-культ вокруг DevOps: как навредить проекту из лучших побуждений
DevOps родился для того, чтобы команды разработки и поддержки работали эффективно и слаженно. Но иногда использование его практик может привести к реальным провалам. Как с помощью DevOps-практик не только не помочь, но и навредить проекту, рассказывает Александр Селезнёв, релиз-менеджер в Luxoft. 
2 комментария

Обсуждение

Комментариев пока нет.
Спасибо! 

Получать рассылки dev.by про белорусское ИТ

Что-то пошло не так. Попробуйте позже