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