В этом материале Александра Романенко, которая сотрудничает с компанией EPAM в качестве Lead Software Engineer, делится своим взглядом на переквалификацию и рассказывает, на что обращать внимание, если вы хотите стать DevOps-специалистом.
Источник фото: pexels.com
Со специальностью DevOps я столкнулась, еще будучи разработчиком в ходе работы на проекте, с использованием бессерверных технологий. В классических проектах на Java роли тестировщика, разработчика и DevOps четко разграничены, а serverless-системы – принципиально другие. Эта новая, интересная тема «подогрела» мое профессиональное любопытство, я начала углубляться в проект, изучать его, не ограничиваясь лишь своим участком работы. После чего начала готовить доклады по теме serverless сервисов Амазон и выступать с ними на митапах DevOps. На мою нынешнюю позицию я идеально подошла по навыкам, так и произошла переориентация.
Мой опыт показывает, что в DevOps, как правило, «приходят» из системных администраторов и, реже, разработчиков. Для того, чтобы быть надежным «мостиком» между процессом разработки и операционной деятельностью, нужно иметь знания в обеих областях. На практике такое встречается крайне редко, потому в процессе работы коллегам приходится обмениваться опытом. Мне, например, не хватало знаний в области system engineering. Я не изучала необходимые дисциплины в вузе и не сталкивалась с ними на практике. Заполнить пробелы помогали коллеги с опытом администрирования сетей, с которыми я, в свою очередь, делилась своими знаниями. В хорошей команде всегда царит симбиоз и взаимопомощь, иначе – никак.
На мой взгляд, специалистам с бэкграундом девелопера легче освоиться в DevОps по двум причинам:
Правда, есть и другая сторона медали. Если, к примеру, один из инструментов, которые необходимы DevOps, не работает должным образом, коллеги-сисадмины могут лишь громко высказать свое неудовольствие. В это же время я как девелопер — добавляю себе работы: ищу ошибку в коде и даже пытаюсь починить баг. Но это возможно лишь в том случае, если инструмент написан на языке, которым я владею, если же нет – наступает горькое разочарование. Один из моих докладов называется «Почему я ненавижу Terraform»: изначально потому, что он часто ломается из-за багов. Но то, что он написан на GO, которым я не владею и, следовательно, баги устранить не могу, тоже не помогает
Я за то, чтобы не следовать за другими слепо, а прокладывать свой путь. Поэтому советую использовать те возможности, которые есть под рукой и развиваться с комфортным для вас темпом.
Моя знакомая купила макбук. С ним что-то пошло не так, она решила «спросить» у Интернета выход. На одном из форумов нашла самый «заплюсованный» ответ и решила им воспользоваться. Как она узнала потом, за этот комментарий голосовали любители сарказма. В ответе на форуме было написано: «Выполнить в командной строке «sudo rm -rf»». В результате одним махом она снесла себе все на новом компьютере. Если бы она проверила, какая задача у этого кода перед тем, как им пользоваться, проблемы можно было бы избежать.
Лучше потратить 3 часа, чтобы понять, как работает код или скрипт, чем 5 минут на копирование чужого ответа в Интернете и 3 дня на разборку, почему что-то сломалось.
Эти навыки вы будете автоматически развивать. Задействовать их придется каждый день. Главное, быть готовым и знать, что вас ожидает.
Предусловием для смены специализации является интерес. Именно он побуждает изучать смежные области. Для профессионального развития крайне важно изучать не только своим профильные темы, в которых уже есть опыт, но и знакомиться с совершенно новыми для вас направлениями, если они вдохновляют. Возможно, одно из них определит вектор дальнейшего развития карьеры.
Нужно пробовать разные вещи. «Сумасшествие делать одно и то же, надеясь получить разный результат» — я очень люблю это выражение.
Специалистам, которые хотят быть «на гребне волны», работать с передовыми технологиями, больше зарабатывать, нельзя останавливаться ни на секунду. Им важно ежедневно следить за трендами, интересоваться новыми проектами компании, отслеживать актуальные тенденции.
Но лично у меня более романтичный подход к профессиональной реализации: я люблю спокойно наслаждаться любимой работой, оттачивать мастерство, если хотите – «плыть по течению», а заставлять себя переориентироваться на нечто новое лишь потому, что это популярно, не мой стиль.
Источник фото: pexels.com
Моя история
Со специальностью DevOps я столкнулась, еще будучи разработчиком в ходе работы на проекте, с использованием бессерверных технологий. В классических проектах на Java роли тестировщика, разработчика и DevOps четко разграничены, а serverless-системы – принципиально другие. Эта новая, интересная тема «подогрела» мое профессиональное любопытство, я начала углубляться в проект, изучать его, не ограничиваясь лишь своим участком работы. После чего начала готовить доклады по теме serverless сервисов Амазон и выступать с ними на митапах DevOps. На мою нынешнюю позицию я идеально подошла по навыкам, так и произошла переориентация.
Откуда «приходят» DevOps-специалисты
Мой опыт показывает, что в DevOps, как правило, «приходят» из системных администраторов и, реже, разработчиков. Для того, чтобы быть надежным «мостиком» между процессом разработки и операционной деятельностью, нужно иметь знания в обеих областях. На практике такое встречается крайне редко, потому в процессе работы коллегам приходится обмениваться опытом. Мне, например, не хватало знаний в области system engineering. Я не изучала необходимые дисциплины в вузе и не сталкивалась с ними на практике. Заполнить пробелы помогали коллеги с опытом администрирования сетей, с которыми я, в свою очередь, делилась своими знаниями. В хорошей команде всегда царит симбиоз и взаимопомощь, иначе – никак.
На мой взгляд, специалистам с бэкграундом девелопера легче освоиться в DevОps по двум причинам:
- Им более понятны запросы от команд разработки и тестирования, они «говорят на одном языке».
- Программисты привыкли к структурной сложности. У них вырабатывается сноровка в работе с большими объемами данных, тысячами файлов и папок. Любой проект, на любом языке программирования, сложнее, чем код, с которым имеет дело DevОps, потому им, как говорится, не привыкать. А вот коллегам без навыков разработки приходится немного сложнее.
Правда, есть и другая сторона медали. Если, к примеру, один из инструментов, которые необходимы DevOps, не работает должным образом, коллеги-сисадмины могут лишь громко высказать свое неудовольствие. В это же время я как девелопер — добавляю себе работы: ищу ошибку в коде и даже пытаюсь починить баг. Но это возможно лишь в том случае, если инструмент написан на языке, которым я владею, если же нет – наступает горькое разочарование. Один из моих докладов называется «Почему я ненавижу Terraform»: изначально потому, что он часто ломается из-за багов. Но то, что он написан на GO, которым я не владею и, следовательно, баги устранить не могу, тоже не помогает
Источники знаний
Я за то, чтобы не следовать за другими слепо, а прокладывать свой путь. Поэтому советую использовать те возможности, которые есть под рукой и развиваться с комфортным для вас темпом.
- Начните со своего проекта. Наверняка на вашем проекте есть DevOps-специалист. Проанализируйте чем он занимается, какие навыки задействует. Если есть вопросы – спросите напрямую. Ваша задача – стать DevOps-ом на своем проекте. Всегда проще переквалифицироваться в знакомой среде, чем прийти на новую работу в другой роли. Вы знаете задачи своего проекта, вам знакома команда, комфортные условия. К непривычности новых навыков будет адаптироваться легче.
- Очные встречи, лекции, митапы. Если на вашем проекте нет DevOps-специалиста, профессиональные мероприятия – отличное решение. На таких конференциях и встречах у вас есть доступ к практикам. Разработчикам можно задавать вопросы и просить совет. А темы докладов подскажут, что сейчас актуально в этой профессии.
- Работа с официальной документацией. Я не приверженец онлайн-курсов и обучающих видео-пособий. Вся необходимая информация содержится в официальной документации. Часто люди сталкиваются с проблемой, гуглят решение, копируют и вставляют код или скрипт из самого «заплюсованного» ответа на форуме. Глобально, это проблему не решает. Человек все равно не понимает, как что работает или почему все еще не работает. Более того, вы можете искать решение, а создать еще больше проблем.
Моя знакомая купила макбук. С ним что-то пошло не так, она решила «спросить» у Интернета выход. На одном из форумов нашла самый «заплюсованный» ответ и решила им воспользоваться. Как она узнала потом, за этот комментарий голосовали любители сарказма. В ответе на форуме было написано: «Выполнить в командной строке «sudo rm -rf»». В результате одним махом она снесла себе все на новом компьютере. Если бы она проверила, какая задача у этого кода перед тем, как им пользоваться, проблемы можно было бы избежать.
Лучше потратить 3 часа, чтобы понять, как работает код или скрипт, чем 5 минут на копирование чужого ответа в Интернете и 3 дня на разборку, почему что-то сломалось.
Ключевые качества DevOps-а
- Усидчивость. Нужно быть готовым к тому, что многое не получится не только с первого раза, но и со второго, или даже с третьего. Но бросать начатое на полпути нельзя. Потому людям, которым кропотливая, упорная работа не подходит по складу характера, будет очень тяжело.
- Внимание к деталям. Невнимательный DevOps подобен слону в посудной лавке. Одно неосторожное действие повлечет за собой существенный урон. Можно нанести компании огромные убытки, случайно нажав не на ту кнопку.
- Аналитическое мышление.Некоторые DevOps считают, что идут по пути наименьшего сопротивления, пытаясь найти готовые примеры и применить их в своем проекте вместо того, чтобы изучить техническую документацию. На самом же деле они вырабатывают вредную привычку и сами себя загоняют в тупик. Хорошо, если найденный пример сработает, но если нет, то человек теряет время на очередные поиски. Помните цитату из мультфильма «Крылья, ноги и хвосты»: «Лучше день потратить, но потом за 5 минут долететь»? Я советую читать документацию, в которой четко описан принцип работы того или иного инструмента. Она позволяет изначально правильно организовать и запустить процесс. Берите пример с хороших разработчиков: они изучают вопрос, анализируют, думают, а потом пишут.
- Многозадачность. DevOps-специалистам приходится совмещать работу по поддержке и разработке. С одной стороны, я постоянно помогаю команде в части саппорта. Что-то ломается, не работает, чего-то не хватает, что-то нужно изменить, добавить, объяснить. При этом есть постоянная фоновая активность по программированию. Конечно, заниматься разработкой всегда проще, когда никто не дергает хотя бы пару часов. Будучи DevOps-ом, мне пришлось смириться с тем, что кому-то нужна моя помощь постоянно. Необходимо привыкнуть делать несколько задач параллельно, быстро переключаться и адаптироваться.
Эти навыки вы будете автоматически развивать. Задействовать их придется каждый день. Главное, быть готовым и знать, что вас ожидает.
Мой подход к переквалификации
Предусловием для смены специализации является интерес. Именно он побуждает изучать смежные области. Для профессионального развития крайне важно изучать не только своим профильные темы, в которых уже есть опыт, но и знакомиться с совершенно новыми для вас направлениями, если они вдохновляют. Возможно, одно из них определит вектор дальнейшего развития карьеры.
Нужно пробовать разные вещи. «Сумасшествие делать одно и то же, надеясь получить разный результат» — я очень люблю это выражение.
Специалистам, которые хотят быть «на гребне волны», работать с передовыми технологиями, больше зарабатывать, нельзя останавливаться ни на секунду. Им важно ежедневно следить за трендами, интересоваться новыми проектами компании, отслеживать актуальные тенденции.
Но лично у меня более романтичный подход к профессиональной реализации: я люблю спокойно наслаждаться любимой работой, оттачивать мастерство, если хотите – «плыть по течению», а заставлять себя переориентироваться на нечто новое лишь потому, что это популярно, не мой стиль.
Комментарии (11)
nad_oby
27.03.2019 13:13Небольшой фидбек с
тёмнойобратной стороны.
Сисадмины как и программисты бывают разные.
Для неплохого сисадмина прочитать и понять, а иногда и поправить, код на большинстве мейнстрим языков — не проблема.
При переходе такого в DevOps акценты просто смещаются в сторону большего количества кода и меньшего ковыряния в операционке/железе.
Ключевые качества прагматичного DevOps-а:
- Усидчивость — без вопростов
- Внимание к деталям — без вопростов.
Но главное не зарываться и знать когда остановиться.
Чрезмерный перфекционизм не всегда полезен. - Аналитическое мышление — в формулировке в приведенной в статье — не соглашусь.
Противопоставлять примеры и тех. доки — зачем? У них цели разные.
Если есть готовое решение, и оно подходит, я не буду чего-то искать.
Если подходит не полностью — склонирую и допилю напильником.
- Многозадачность — нафиг, нафиг, и ещё миллиард раз нафиг!
Так никакие проекты не будут продвигаться.
В нормальной команде будет on-call дежурство, так вот именно on-call будет чинить то, что сломалось.
В это время свободные от дежурства спокойно делают запланированные таски и о факапах узнают на post-mortem.
Если вам «повезло» быть единственным DevOps на проекте, то во первых — мои соболезнования, во вторых — заставляйте всех открывать тикеты, даже для misson critical, начинайте чинить сразу, но чтоб тикет был.
Ну или сами открывайте ставя нужного человека requester-ом - Знает свои инструменты — Это не только к DevOps относится.
- Считает деньги и время — для меня большим открытием было то что я могу чего-то не делать потому, что суммарный выхлоп даст выгоды меньше чем моя зарплата за время разработки.
Или не заскриптовать таск, который хочется потому, что он прикольно на скрипт ляжет, а на самом деле не надо — он одноразовый (до сих пор иногда не могу удержаться и количество скриптов в ~/src/scratch растёт).
Если не относиться к профессии с прагматизмом и некоторой долей цинизма, выгоришь быстрее и эффекктивность будет страдать.
Мира и добра, кстати у нас есть печеньки.
navion
28.03.2019 14:06Для неплохого сисадмина прочитать и понять, а иногда и поправить, код на большинстве мейнстрим языков — не проблема.
Где вы таких находите? В ентерпрайзе большинство админов в лучшем случае умеет писать небольшие скрипты на Bash или PowerShell.nad_oby
28.03.2019 16:29Вот не знаю где их брать когда интервью делал то обычно мрак и ужас. Редко кто попадался с правильно настроенной головой.
Из личного опыта.
Мне повезло поддерживать R&D почти на всех работах и было просто любопытно что там разрабы пилят.
Пришлось освоить несколько языков на базовом уровне.
Тоесть программировать нормально я не умею, скилл и налёт часов нужен но в логике программы разберусь.
В предпоследней команде половина DevOps были выходцами из системщиков.
Так perl, python, Java вообще никого не пугали.
Не говоря уже о bash.
Хорошим тоном было найти место в коде, которое падало с ошибкой и если проблема маленькая и тривиальная то можно было к разрабу с пулл-реквестом прийти.
Но это редко было.
Разработчики в разы лучше ориентируются в коде.
arheops
27.03.2019 22:12+3Вот почему я как, сисадмин, если не знаю языка — разбираюсь в языке, а вот девопс-разработчик «не владеет GO» на достаточном уровне для устранения бага(причем по контексту — не первый раз сталкивается) и ничего с этим не делает?
Это что, новые требования к разработчикам — не понимать, что написано на другом языке?
vsantonov
28.03.2019 00:05+5В это же время я как девелопер — добавляю себе работы: ищу ошибку в коде и даже пытаюсь починить баг.
А я ищу неполадки в сети или несовместимости пакетов. Тут в чистом виде проф деформация, люди ищут неполадки там, где лучше разбираются.
На мой взгляд, специалистам с бэкграундом девелопера легче освоиться в DevОps по двум причинам
А на мой взгяд, специалистам с бэкграундом админа легче освоиться в DevOps…
Очень однобокий у вас получился рассказ. На моем опыте, когда дело касается облаков, контейнеров, виртуализации, девелоперы тоже могут только громко выругаться если что-то не работает, а админы с легкостью лезут «под капот» и прописывают системные переменные для обхода прокси через пробрасывание трафика сквозь 22 порт.
Я бы сказал что DevOps это шкала между программированием и администрированием и в каждой отдельной команде человек с такой должностью находится ближе к той части где он разбирается, а команде нужно чтобы разбирался. Например у нас в проекте в задачи девопса входит организовать доставку приложения на физические машины находящиеся в чистом поле без интернета и вообще какой либо сети. Это чистый админский кейс, с использованием инструментов автоматизированного развертывания образов, тут концепты вроде terraform ломаются о суровую действительность и нужно закатать рукава с реальной железкой на столе.
gsl23
28.03.2019 11:24В классических проектах на Java роли тестировщика, разработчика и DevOps четко разграничены, а serverless-системы – принципиально другие.
Эх ребята, все не так, все не так ребята (с)
Вообще в классическом понимании DevOps нет такой роли, есть набор практик, технологий и методологий.
DevOps должны заниматься и админы и разработка и тестирование. Если вы кого-то конкретного (админа, разработчика или тестировщика) в девопс назначаете, такой девопс у вас и получится — однобокий. Что собственно противоречит его сути.
farcaller
Как-то забавно что на КДПВ в фокусе самые девопсовые инструменты — Photoshop и Premiere (и последний открыт на весь экран)
denaspireone
это фронтенд дев или верстальщик, но явно не devops
просто картинка красивая ;)
Oz_Alex
After Effects там же.