Всем привет! Меня зовут Дима, я «наовертаймил» уже 14 лет опыта в IT, 8 из которых — проповедуя непосредственно DevOps и занимаясь в основном проектами, так или иначе завязанными на активном использовании методологии и «тулсэта».
Проработав немало лет в индустрии, я с уверенностью могу сказать, что DevOps — не профессия, это подход к работе и жизни в целом. Если вы хотите стать DevOps-инженером просто потому, что это популярно, наверное, шансы стать PRO не очень велики. Наслаждаться работой вы уж точно будете не сполна. Что хуже, ваши коллеги и руководитель уж и подавно не будут или будут, но недолго :) Так что сначала не помешает разобраться, что же стоит за этим понятием, с какого рода задачами работают DevOps-инженеры. Кому нужно, тот задумается о подобном витке в профессиональной жизни и с чего начать этот путь.
DevOps — профессия или часть обязанностей?
Итак, кто такой DevOps-инженер или кто может им стать? Могу точно сказать, что не существует общего профиля DevOps-специалиста. Каждый отдельный профессионал отличается с точки зрения технической экспертизы и опыта построения специфических систем. Конечно, есть определенный спектр навыков и знаний, общий для всех: DevOps-инженер должен нести, как знамя, и передавать в массы Software Development Life Cycle (SDLC), а еще — отлично ориентироваться в процедурах внедрения изменений в компании (это то, что широкие массы называют инновациями).
Например, на курсах нашей академиимы в первую очередь учим кандидатов координированной работе над единым проектом, спроектированным на основе одного из текущих актуальных проектов компании, но в упрощенном, адаптированном виде (и без нарушения NDA, естественно). Лишь после осознания подходов и выработки умения на практике выстроить рабочий процесс с только что сформированной командой поступивших на курсы молодых специалистов мы начинаем толкать их в сторону осознания и использования технических средств.
Условную техническую базу вполне спокойно наши студенты подтягивают в академии за несколько месяцев, но сама по себе она не имеет смысла без понимания, ЗАЧЕМ это всё великолепие нужно бизнесу.
Вторым важным требованием к DevOps-инженеру являются хорошо развитые soft skills. Ты должен уметь взаимодействовать с командой, понимать мотивацию и проблемы каждого из сотрудников, уметь доносить и «продавать» свою идею так, чтобы зажечь свою команду на внедрение изменений (aka innovations). В придачу ко всему этому ты должен уметь планировать, расставлять приоритеты и активно подключаться к процессу реализации. Неприемлема ситуация, когда DevOps «научил как надо» и ушел дальше думать, кого и чему бы еще научить. Святая обязанность DevOps-специалиста — возглавить движение к светлому будущему независимо от уровня должности. Чтобы действительно приносить плоды, культура должна жить на всех уровнях команды и организации.
Итак, вы дочитали до этого места, и вам кажется, что пробил час, пора двигаться именно в этом дивном (пару лет назад даже хайповом) направлении. Что же делать?
Для начала вы должны стать как минимум специалистом в одной из IT-сфер middle-уровня с хорошей технической базой, soft skills и сильным желанием мыслить стратегически. Затем неплохо было бы подумать, есть ли у вас желание развивать в себе «менеджерский функционал» и при этом не отказываться от сильной технической части. Подумали? Оценили свой текущий уровень? Если уверены в своих силах, давайте читать дальше :)
Кстати, если вы еще новичок в IT, трезво оцените свои силы, рано вам еще в DevOps. Рановато вам учить других и помогать проектам двигаться в светлое будущее за счет своего опыта. Но почитать и понять для себя, о чём эта методология, смысл есть.
«Сначала была теория»
Особенность DevOps заключается в том, что процессы начинаются с бизнеса и движутся в сторону инженерии. К сожалению, очень часто происходит наоборот: в разработке решения для клиента начинают с технической реализации и только потом, когда-нибудь доходят до бизнес-потребностей. Если деньги не успеют закончиться.
Святая обязанность методологии DevOps — находить золотую середину и всегда двигаться от потребностей бизнеса, всячески избегая пробуксовки в тех самых пресловутых направлениях «чисто дев» и «чисто опс». Идеальный продукт, как говорится, — никогда не выпускавшийся продукт. DevOps-специалист обязан очень хорошо ориентироваться как в архитектурных, так и в бизнес-практиках; думать сначала стратегически, и лишь потом уже тактически; понимать закономерности и методологии.
Очень мало смысла перечислять книги и ресурсы, которые рекомендуются новичкам. Это всегда индивидуально и зависит от уже приобретенного опыта. Очень опытные ребята обычно предлагают следующие must have:
- Phoenix Project — прочтением этой книги принято хвастаться и обсуждать её содержимое в celebrity-кругах DevOps;
- DevOps handbook — практические советы и опыт;
- Site Reliability Engineering — а вот тут вы сможете понять, что «мы в ответе за то, что создали», да и вообще, посмотреть, как работать не за еду или идею;
- Continuous Delivery — несмотря на то, что книга написана в 2008 году, ее актуальность для многих команд и компаний остается очень высокой;
- Release it!— отличное и легкое чтиво о том, как правильно или неправильно подходить к релизу программного обеспечения;
- Lean Software Development — качественные рекомендации по поводу оптимизации процессов и культуры waste-анализа в целом, для того чтобы избежать груды ненужной работы, которая рушит святое — магию девелопмента;
- множество других книг, которые можно найти тут.
Мир меняется
В современном мире новые подходы постоянно абсорбируются и добавляются в список обязательных требований в выполнении обычной ежедневной работы. Ведь когда-то Agile/Scrum были модными фишками, и были весьма распространены отдельные роли «мастеров» ведения этих практик в командах. Теперь же вся ответственность лежит на плечах разработчиков, просто добавилось дополнительное требование. Это нормальная ситуация — инфляция навыков и умений. Чтобы не стоять на месте, нужно очень быстро бежать за технологиями и методологиями.
Аналогичная ситуация сейчас с DevOps-направлением: оно активно перетекает в разряд must have-подходов к разработке. Еще вчера мы искали единорога — DevOps-инженера, а уже завтра все станут ожидать от любого инженера быть единорогом по этому критерию. Такова жизнь. Вопрос лишь в том, кто будет брать на себя эти новые роли, а кто — до последнего сопротивляться и в итоге проиграет рынку.
Инициатива не наказуема
Если вы уже готовы применять теорию на практике, видите, как можете внедрить изменения в проекте, и готовы брать на себя эту ответственность, не бойтесь проявлять инициативу и делиться идеями с командой.
DevOps — командный игрок, это крайне важно осознать и принять. DevOps-инженером за одну ночь не становятся, но шаг за шагом вы можете расширять опыт и постепенно трансформировать свою роль. Конечно, это возможно при условии, что ваша команда и менеджеры готовы ответить на инициативу. В противном случае рекомендую бежать от этой команды и искать среду, в которой поощряют внедрение новых идей и развитие. Сейчас многие гоняются за прорывными технологиями и классными проектами, но я рекомендую всё-таки сделать ставку на команду.
Научитесь учиться
Если вы уверены, что изучили что-то идеально, скорее всего, оно устарело еще до того, как вы приобрели эту уверенность. Это особенно остро чувствуется в IT-индустрии, ведь технические реализации устаревают, наверное, уже через полгода после создания или того быстрее. DevOps не исключение, поэтому всегда нужно быть в курсе последних новинок, трендов и практик. Для этого нет подхода лучше, чем постоянное обучение: посещения конференций, митапов; подписки на тематические блоги, форумы, чаты, рассылки и т.п. Ниже привожу самые популярные каналы:
- Например, Олег ведет замечательные дайджесты по DevOps;
- telegram-канал devopsengineer;
- Medium, например;
- Reddit;
- Slack — ukrops.club;
- Skype DevOps UA (пригласить может другой участник чата, можно писать напрямую nonflet с просьбой добавить) — здесь еще ни один вопрос не остался без ответа. Так что, если нужен совет или просто хотите пообщаться, обязательно загляните сюда;
- конференции, например FWdays Highload, DevOps Stage, XP Days.
Вывод
Многие авторы заканчивают вдохновляющими фразами типа «Вот вам умный текст о том, как достичь успешного успеха! Вперёд и с песней, у вас всё выйдет!». Я сделаю немного иначе. Существует теория, что человек никогда не делает ошибок. Все наши решения в жизни — лучшие из всех доступных нам опций в конкретный период времени при условии обладания доступным нам спектром знаний и ресурсов. Не имеет смысла жалеть о своём выборе в той или иной ситуации, ведь в тот момент мы сделали самый лучший выбор.
К чему я это? А к тому, что мы должны постоянно расширять спектр доступных нам знаний и умений. Именно это увеличит число опций для принятия нами решений. К примеру, вас заставляют работать в стесненных условиях унылого проекта, а вы взяли и ушли в другую компанию DevOps’ом. Конечно же, это шутка :) В идеале нужно нести свет и учение в массы, ведь все мы живем в тех условиях, которые сами себе и создали (или мы просто just fine with it).
DevOps — это те дополнительные знания, которые расширяют спектр доступных вам вариантов в разрезе карьерных опций. А вот принимать решения каждый должен уже сам, это основная фишка взрослой жизни. Если будет желание обсудить данный текст, я всегда к вашим услугам.