Как прокачать знания Junior DevOps

Представляем вам советы, которыми поделились опытные DevOps-инженеры с начинающими в специальной рубрике на сайте DOU.UA.

Олег Федотов, Engineer Level 2 в CoreValue

18 лет опыта в ІТ, из них 5 — в DevOps

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

• TCP/IP — очень важно понимать, как работает сеть (классический вопрос на собеседовании — Что на самом деле происходит, когда пользователь вбивает в браузер адрес google.com). Вот Cisco CCNA курс, достаточно именно TCP/IP раздела.
• Linux (дистрибутив не имеет значения, главное — свежий). Лично мне очень помогло в своё время понимание, что происходит под капотом во время загрузки операционной системы. «Linux from Scratch», — наверное, лучшее из бесплатного, но придется с ней повозиться.
• Python — наверное, самый простой в изучении и одновременно самый востребованный язык в мире DevOps и не только.
• AWS — облачная инфраструктура, которая очень сильно упрощает жизнь DevOps инженеру, беря на себя огромную часть рутинных задач. При этом так называемый AWS Free Tier даёт возможность новичкам абсолютно бесплатно пощупать львиную долю сервисов. Для меня идеальным в изучении оказался курс AWS Certified Solutions Architect — гайд к нему.

Это далеко не всё, но достаточно для уверенного старта. А впереди Docker, Ansible, Jenkins и пр. — это те технологии, изучать которые будет намного легче, освоив базу. А дальше ITIL, DevOps методологии и еще много-много интересного и важного. И я нарочно не упомянул Windows! Я считаю, что освоив Linux, освоить Windows будет куда легче, но не наоборот.

Дмитрий Замаруев, Technical Director, Cloud Solutions в Grid Dynamics

Более 14 лет опыта в ІТ

В последнее время все почему-то ищут специалистов на позицию DevOps Engineer, но для тех, кто разбирается в терминологии, это звучит приблизительно как Agile Engineer — термин, который не говорит вообще ничего и ни о чем. А все потому, что DevOps — это методология, а не специальность. Методология, которая описывает взаимодействие между различными командами, дает рекомендации по вопросам разработки и доставки приложений, управления инфраструктурой.

Наиболее часто компании на позицию «DevOps Engineer» ищут людей, которые будут отвечать за CI/CD инфраструктуру для проекта/компании, заниматься доставкой приложений (deployment engineer) или автоматизировать создание инфраструктуры (infrastructure engineer). Это все самодостаточные отдельные специализации, о каждой из которых можно долго говорить.

Попробуем обобщить знания, которые помогут инженеру начать разбираться в этих областях. DevOps охватывает много определений: это и continuous delivery (CI/CD), и infrastructure automation, и configuration management:

• Совсем базовые знания — Computer Science. Любая работа в области информационных технологий подразумевает базовые знания в области компьютерных наук. Если в институте этот предмет «не зашел», то можно посмотреть курс CS101 от Stanford University — он находится в свободном доступе и дает хорошее понимание основ.
• Scripting basics — без написания скриптов в век тотальной автоматизации никак не обойтись, поэтому не нужно бояться командной строки и написания собственных скриптов. Если что-то нужно сделать больше, чем один раз, это нужно автоматизировать.
• Для тех кому мир Linux Shell совсем не известен: Intro to Bash, Bash scripting tutorial.
• CI/CD — непрерывная интеграция и доставка приложений сейчас тесно связана с понятием DevOps, поэтому необходимо понимать, что это такое и для чего нужно. Концепция отлично описана в книге Фаулера «Continuous Delivery». Если книгу не достать, то основные концепции описаны у автора на сайте (сайт вообще весь хороший, советую прочитать от и до).
• Инструментарий для непрерывной интеграции довольно разнообразный, но лидирует с большим отрывом Jenkins, поэтому советую начать изучение именно с него. Вместе с этим крайне желательно ознакомиться с системами сборки тех языков, с которыми планируется работать, так как это одна из точек соприкосновения с разработчиками (Maven/Gradle/sbt/CMake etc.).
• Clouds — современная инфраструктура уже давно вышла за пределы дата-центров. Поэтому без опыта/знаний облачных провайдеров сейчас мало что можно сделать. Благо крупные провайдеры предоставляют пробные периоды на доступных условиях и попробовать, что такое облако, можно легко. А главное, что бесплатные планы можно использовать для изучения различных инструментов и оттачивания навыков.
• AWS предоставляет 1 год использования некоторых типов ресурсов совершенно бесплатно (но нужно настроить оповещения на возможную оплату, так как доступны и платные ресурсы, которые по незнанию можно случайно запустить).
• Google Cloud дает кредит $300 сроком на один год на любые ресурсы — этого вполне достаточно для обучения.
• Microsoft Azure — $200 на месяц — немного по времени, но достаточно, если нужно просто познакомиться с системой.
• Infrastructure automation — автоматизация создания инфраструктуры тесно переплетается с понятием infrastructure-as-a-code. Описание инфраструктуры кодом пытается решить проблему повторяемости, тестирования и ревью, то есть применить принципы CI/CD для уровня инфраструктуры (ссылка на Фаулера).
• Из инструментария наиболее популярными, наверное, являются поделия-на-коленке и Terraform — к нему-то и стоит присмотреться.
• Configuration management — создание повторяемой и предсказуемой настройки системы/приложений. Также большинство инструментов из этой области могут использоваться для автоматизации доставки приложений (deployment automation). Изучение стоит начать с Ansible, так как у него ниже порог вхождения. Но также следует его сравнить с похожими инструментами, такими как Chef и Puppet.

Инструментария и областей, которые сейчас входят в DevOps слишком много, чтобы браться их изучать разом. Следует разобраться в нескольких инструментах и дальше сравнивать уже известные инструменты/подходы с новыми.

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

Евгений Волченко, DevOps Engineer в Luxoft Ukraine

12 лет в IT, 5 лет опыта в DevOps

3 must-have навыка

Хороший DevOps специалист должен свободно себя чувствовать с людьми, с которыми работает. Развитые soft skills однозначно этому поспособствуют. Общение со специалистами разного профиля в ежедневной деятельности требует развитых коммуникативных навыков. Потому если вам сложно коммуницировать — начинайте развивать этот навык с первых дней работы, научиться этому можно.

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

Также начинающему специалисту важно иметь технический бэкграунд, а еще лучше — техобразование. Понимание компьютерных сетей и инфраструктуры, а также основ построения отказоустойчивых решений пригодится. Сейчас можно выделить некий тренд, когда DevOps становятся бывшие программисты. Мой опыт показывает, что это не самые лучшие девопсы, но есть и исключения. Я считаю, что как раз из-за нехватки понимания инфраструктуры.

Чего делать не надо

DevOps команда всегда в меньшинстве, а на небольших проектах это и вовсе один человек. Поэтому не стоит ставить себя выше других и считать себя единственным и неповторимым носителем знаний, недоступных другим. Нужно общаться с командой и определять ее приоритеты, понимать, как удобнее для всех взаимодействовать, как оптимизировать работу и быть единым целым. Поэтому не рекомендую опираться лишь на теорию, выловленную из книг и статей, и пытаться ее навязать своим коллегам, а прислушиваться к чужим словам и делать выбор, исходя из потребностей команды. На ранних этапах вашей карьеры — уж точно 🙂

Тем не менее даже начинающий специалист должен быть достаточно твердым в своих решениях и не идти на поводу всех просьб и предложений коллег по проекту. Нужно находить некий баланс между командным духом и best practices, прочитанными в книгах, хоть это и непросто.

Снова же, из-за того, что DevOps специалистов на проектах зачастую не больше одного, возникает некий вакуум общения с коллегами, интересующимися девопс-направлением и технологиями. Несмотря на противоречивое отношение к профильным мероприятиям, я рекомендую не пренебрегать ими. Митапы, конференции — все это подойдет, особенно, на первых этапах. Как я говорил, DevOps должен сам заниматься своим развитием, иногда даже больше, чем другие специалисты. Программистам разного профиля проще найти более опытных коллег, которые направят и подскажут, даже в рамках одного проекта. По опыту добавлю, что не стоит игнорировать и навыки программирования. Знание архитектуры Web-приложений и умение работать с Rest API точно пригодятся.

Что почитать

С первой книгой начинающим DevOps’ам повезло — она написана в художественном стиле и вряд ли когда устареет. Это «The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win» авторства Gene Kim. Для понимания этапов и процессов в production рекомендую «Site Reliability Engineering: How Google Runs Production Systems» Niall Richard Murphy. И книга по программированию — «Go in Practice: Includes 70 Techniques», автор — Matt Butcher. Чтобы быть успешным DevOps специалистом, нужно уметь программировать хотя бы на базовом уровне.

Антон Чудаев, TeamLead DevOps в V.I.Tech

8 лет опыта в Ops + 4 года в DevOps

В DevOps часто приходят либо из программистов (Dev), либо из админов (Ops). Так получается, что это смесь и культура разных направлений, поэтому и изучать новые технологии DevOps инженеру приходится быстрее, чем рядовому айтишнику. Еще накладывается зависимость от конкретных технологий, используемых в проекте. Я советую изучить хотя бы одну тулзу в каждой области, а уже потом расширять и углублять знания по мере необходимости.

Публичные облака. Вычислительные ресурсы — это основа, на которую дальше все накладывается. Если выбор пал на «Амазон» (как в большинстве случаев), то дождитесь скидки и купите курс по AWS за 10$. Он даст общее представление о сервисах и ресурсах. Для автоматизации развертывания и поддержки инфраструктуры (Infrastructure-as-Code) используйте нативный для AWS CloudFormation — будет проще начать и всегда up-to-date. Если не «Амазон» или не желаете вендор-лока, то используйте Terraform.

После того как «сетку раскинули», инстансы подняли, нужно упаковать аппликацию. Тут нам помогает контейнеризация. В этой области правит Docker. Начните с простого создания имиджей и деплоя контейнеров и уже по мере запросов от бизнеса переходите к кластеризации и сервисам в Kubernetes.

Чтобы управление и настройка сервера/сервисами были прозрачными и стандартизированными, используйте тулзы для config-менеджмента. Мой фаворит, особено для начинающих — Ansible. Изучайте примеры на Ansible Galaxy и пробуйте модифицировать их на своих рутинных задачах. Из альтернатив — SaltStack или Chef.

Уже построенный work-flow сборки, тестирования и деплоя нужно упаковать и красиво визуализировать с помощью пайплайнов, например вот пайплайн для Дженкинса. Это поможет масштабировать процессы на разные энвайронменты.

Мониторинг. Следить и поддерживать сервисы поможет, если еще не внедренный, старичок Zabbix. Также посмотрите на более новые: Prometheus или TICK Stack.

Главная задача девопса — ускорение доставки продукта от бизнеса до потребителей. Автоматизация — это только одно из основных средств, а не самоцель. CI/CD, blue-green, Phoenix, Canary Deployments — это тоже средства, которые возникают по мере необходимости. Чтобы это почувствовать, понять философию DevOps культуры, помогут классические книги:

• «The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win» by Gene Kim, Kevin Behr, George Spafford;
• «The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations» by Gene Kim, Patrick Debois, John Willis, Jez Humble;
• «Site Reliability Engineering» edited by Betsy Beyer, Chris Jones, Jennifer Petoff and Niall Richard Murphy.

При этом всегда нужно «смотреть в завтрашний день» и следить за новинками, но не перегружать бизнес гонкой за трендами, если он пока еще не дорос до таких потребностей.

Чтобы быть в курсе новостей, читайте дайджесты и статьи на DOU и подписывайтесь на телеграм-каналы:

• CatOps;
• UkropsDigest;
• ДевОпс Инженер;
• DevOps&SRE Library.

Hints&tips

Не выдумывайте велосипеды, поищите популярные решения для задач, так будет проще суппортить не только вам.

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

Автоматизируйте, только то, что действительно уже хорошо работает и будет использоваться в дальнейшем регулярно.

Внедряйте новые технологии только при действительном их эффекте в будущем. Ошибка на уровне архитектуре самая дорогая.

Сергей Марченко, Head of IT Department в Dev-Pro

6 лет опыта в IT

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

Мой план с рекомендациями, как освоить специальность:

Сначала Ops, потом Dev

Заказчики постоянно беспокоятся про uptime, безопасность, в общем, обычный IT Operations никуда не делся. Поэтому сначала понадобятся хорошие знания системного администрирования, troubleshooting и поиск bottlenecks. Infrastructure as a code, CI/CD и прочее стоит рассматривать как продолжение карьеры системного администратора, а не отдельный путь.

Не стоит становиться человеком, который разворачивает инфраструктуру MySQL High Availability на Ansible, не понимая, как работает репликация. Что уж там, иногда даже процесс резервного копирования базы вызывает вопросы. Изучайте основы networking, Linux/Windows, web servers (NGINX, Apache), DBs, monitoring и только потом DevOps практики.

Clouds

DevOps почти равно Clouds. Поэтому стоит разобраться хотя бы с одним Cloud Provider — AWS, Azure, Google Cloud Platform. У AWS можно зарегистрировать Free Tier, которого достаточно, чтобы познакомиться с этой платформой.

Automation

Во время изучения Cloud Platforms стоит обратить внимание на Configuration Management and Provisioning Tools. Я бы рекомендовал Ansible и Terraform. Вместе с изучением Terraform советую смотреть на контейнеры, Docker, Kubernetes — это позволит лучше понять сильные стороны Provisioning Tools.

Копайте вглубь

Важно, чтобы после лабораторной, тестового задания, PoC, работы на проекте не осталось открытых вопросов. Подходите системно: выписывайте вопросы, потом обсуждайте с коллегами, читайте литературу. Главная цель — полное понимание происходящего. Почему выбрали тот или иной инструмент, почему именно так написали код — у вас должны быть ответы на эти вопросы.

Пишите код

Кроме кода, который необходимо писать для разворачивания новой инфраструктуры, стоит подумать про написание своего приложения. Тут поможет какой-нибудь Pet Project. Это может быть веб-сайт, чат-бот или IoT-приложение, которое доливает воду в кофеварку (в IТ-компаниях и не такое встретишь). Главное — глубже понять работу и проблемы разработчиков. Для написания такого приложения я бы предложил воспользоваться языком, который потом пригодится DevOps инженеру: Python или Golang в самый раз. В случае Go забудьте про книги, A Tour of Go — то, что вы ищите.

Читайте чужой код

Изучая Terraform, я подсмотрел tips and tricks, хорошие практики из Terraform Module Registry. Чтение чужого кода позволяет посмотреть другие практики и, если они окажутся лучше ваших, перенять их. Кстати, говоря о Terraform, я бы рекомендовал начать с Terraform: Up and Running.

Security

DevOps подходы ускоряют разворачивания инфраструктур и добавляют еще больше проблем для Security Engineers. Так что стоит сразу избавляться от простых ошибок, например, не класть ключи и секреты в открытом виде в version control, немного углубиться в тему security. Тут вам помогут ключевые слова DevSecOps, OWASP, Key Vault.

Сообщество

Когда вы определитесь со списком software, с которым вы работаете, стоит принимать активное участие в жизни продукта. Читать форумы (Stack Overflow), следить за обновлениями на GitHub, возможно, даже контрибьютить свой код.

Не решайте проблем, которых нет

AI, Big Data… в мире столько новых течений. Как тут удержаться и не внедрить что-то новенькое в свой проект. Мой совет — внедряйте только то, в чем вы действительно нуждаетесь, вы должны знать, какую проблему решаете. Большинство модных технологий вам не нужны или не подходят. You are not Google.

Максим Зинькевич, Lead Systems Engineer в EPAM Kharkiv

5 лет опыта в DevOps

DevOps нельзя выучить по книгам и курсам, а потом выйти на проект и сделать все классно. Практика и только практика может сформировать инженера в этом направлении. Нужно быть готовым, что придется прилагать много усилий и постоянно преодолевать себя, особенно в самом начале. Чем тяжелее в начале освоения профессии, тем легче на проектах.

Еще будучи студентом, я работал системным администратором в различных бизнесах. Начинал с Windows и Linux. Постепенно перешел к поддержке серверов и автоматизации. Когда я впервые использовал такие инструменты как Puppet, Jenkins, системы контроля версий (Subversion, Git), ко мне пришло осознание, что за гранью сисадминистрирования есть огромный мир DevOps. Чтобы двигаться дальше, я присоединился к EPAM. Именно тогда, 5 лет назад, в компании запускалось пилотное направление DevOps. Сейчас мы активно развиваем эту компетенцию внутри компании.

Опираясь на свой опыт, мои рекомендации начинающим специалистам будут выглядеть так:

• Выбирайте работодателя и проекты, которые будут вас профессионально формировать. Все мои смены работы были продиктованы исключительно желанием развиваться. Как только чувствуете, что начинаете деградировать — меняйте работу.
• Не бойтесь браться за новые или сложные проекты, которые выше вашего уровня. А лучше всего сразу подключаться к нескольким проектам. Такой активный режим очень поможет в прокачке практических знаний и навыков. Но не забывайте о балансе, чтобы быстро не перегореть.
• Задавайте вопросы вашему ментору / лиду проекта / тимлиду. Если в течение двух дней вы не задали вопрос по тому, что вам непонятно — вы потеряли два дня в познании профессии, и кому-то придется переделывать вашу работу. Отбросьте стеснение, абсолютно все начинали так же, как и вы. Будьте инициативны и любознательны.
• Учитесь на своих ошибках. Завершили проект — проанализируйте, что было сделано хорошо, а что можно и нужно улучшить. Подход continuous improvement должен стать неотъемлемой частью проектной работы.
• Выучите или доучите такие несложные языки программирования, как Ruby и Python. Python и так давно уже используется в системном администрировании. Почему Ruby? Системы автоматизации Puppet и Сhef используют DSL, основанный на Ruby, поэтому некоторые тонкие вещи придется писать на этом языке. Хоть программирование в основном и функциональное, но без основ объектно-ориентированного программирования развиваться в DevOps будет сложно.
• Следите за авторами и читайте профильные материалы на Habr и DZone. Там же есть подкасты и видео.
• Пройдите обучающие курсы на Coursera и Codecademy.com.

На самом деле сейчас есть огромное количество ресурсов по теме DevOps, сложно посоветовать что-то конкретное. Главное — не останавливать процесс изучения новых технологий и закрепления актуальных.

За весь свой опыт работы я прочитал только одну книгу «Непрерывная интеграция» Jez Humble, David Farley. Она очень легко читается и будет понятна начинающим специалистам. Там еще используются примеры старого ПО, но все принципы будут актуальны и сегодня. Она мне помогла структурировать уже имеющиеся знания. Остальное же — практика, актуальные статьи по теме, документация и, конечно же, коллеги.

[customscript]techrocks_custom_after_post_html[/customscript]

[customscript]techrocks_custom_script[/customscript]