Devops курсы онлайн

DevOps — инженер

Linux

Курсы Java

Информационная безопасность

Программирование и СУБД

IT-менеджмент

Вы получите все необходимые навыки для успешной работы на востребованной позиции DevOps-инженер/SRE (Site Reliability Engineer) *.

Программа предназначена для слушателей, имеющих базовый опыт программирования.**

DevOps-инженер/SRE — специалист, необходимый любой крупной IT-компании. Количество вакансий по этому направлению достигает 2 000 в России, а уровень зарплаты — до 200 000 рублей.

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

Сейчас DevOps — это набор технологий (начиная от навыков системного администрирования до применения специализированных инструментов) и практик.

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

Востребованность

Сложность

от 6 месяцев
Время освоения

до 200 т.р.
Средняя зарплата

* Если у Вас есть опыт работы программистом или тестировщиком, обучение станет дополнительным преимуществом при трудоустройстве на позицию DevOps-инженер/SRE — Site Reliability Engineer (в зависимости от вашего опыта).

** Требование к подготовке: курсы Основы сетей, сетевые операционные системы и практикум Wi-Fi и Основы программирования и баз данных или эквивалентные знания (знаете стек TCP/IP, владеете одним языком программирования, умеете работать с реляционными СУБД, знаете язык SQL).

По окончании обучения Вы сможете получить международные сертификации:

• Junior Level Linux Professional (LPIC-1)
• Advanced Level Linux Professional (LPIC-2)
• DASA DevOps Fundamentals
• DASA® Professional.

Как Вы будете учиться

1. На курсе «Linux. Уровень 1. Основы администрирования систем Debian, Ubuntu, CentOS» Вы изучите основы работы в UNIX-подобных системах. Научитесь устанавливать Linux, работать в командной строке, выполнять базовые задачи системного администратора. После прохождения курса Вы сможете сдать престижные сертификационные экзамены LPIC1 и LPIC2.
2. Курс «Linux. Уровень 2. Администрирование сервисов и сетей» научит Вас работать с основными сетевыми сервисами, такими как DHCP, DNS, NTP, SFTP, NFS, NAT и Proxy. Вы сможете настраивать веб-серверы и почтовые серверы и развернуть полноценную инфраструктуру любого небольшого предприятия.
3. Пора сделать следующий шаг: начинаем производить сканирования, атаки, перехваты конфиденциальной информации, чтобы, впоследствии, научиться защищать системы от таких действий. Все это на курсе «Linux. Уровень 3. Обеспечение безопасности систем, сервисов и сетей».
4. Теперь, когда все работает, пора задуматься о надежности промышленной инфраструктуры. Здесь Вам поможет курс «Linux. Уровень 5. Zabbix. Мониторинг IT инфраструктуры предприятия». Вы настроите мониторинг так, чтобы узнавать о возникающих проблемах заранее.
5. На курсе «Linux. Уровень 6. Создание отказоустойчивых кластерных решений» Вы отработаете наиболее часто встречаемые конфигурации сервисов во время лабораторных работ.
6. Курс «Система управления версиями Git» научит работать в системе контроля версий, которую используют и программисты и DevOps-инженеры.
7. Курс «DASA: DevOps – базовый уровень» представит DevOps как методологию, Вы изучите культуру, процессы DevOps, управление изменениями. Курс подготовит Вас к сдаче экзамена DASA DevOps Fundamentals.
8. «DASA: Практик DevOps по организации работы команды Подготовка к экзамену DASA DevOps Professional. Уровень 2» научит Вас технологическому лидерству, работе в команде и подготовит к сдаче экзамена DASA® Professional.

Ваше резюме после прохождения дипломной программы

• Работа в GNU/Linux, навыки работы в Debian/Ubuntu/Centos
• bash, vim, awk, syslog
• TCP/IP, DHCP, DNS, NTP, SFTP, NAT, SNMP, ssh
• netfilter/iptables, iproute2, Postfix, bind, zabbix
• ansible, puppet, vagrant, terraform
• LXC, docker, kubernetes
• git
• CI/CD: jenkins, gitlab
• DevOps-методология, Agile/Scrum

Что такое дипломные программы в «Специалисте»:

1. Очный или очно-заочный формат обучения.
2. Инновационная методика с использованием современных технологий.
3. При прохождении дипломной программы в формате очного обучения, Вам будет предоставлен доступ к записям онлайн-обучения для самостоятельной подготовки и закрепления учебного материала.
4. При очно-заочном обучении – дистанционное обучение в удобном темпе по записям онлайн-обучения, 1 очная консультация в неделю по расписанию (не менее 1/3 от общего времени обучения).
5. Оплата в рассрочку: первоначальный взнос – 20% от стоимости дипломной программы.
6. Престижные документы об окончании: диплом о профессиональной переподготовке по окончании всей программы, сертификат Центра международного образца (если предусмотрен), международный сертификат вендора после каждого авторизованного курса.
7. Максимальная бесплатная поддержка при трудоустройстве к «работодателю вашей мечты»!
   Для наших выпускников на ежемесячной основе мы организуем Дни карьеры, семинары по теме «Трудоустройство». Каждую среду с 10-00 до 17-00 проводим карьерные консультации, запись по адресу job@specialist.ru. Предлагаем рассмотреть вакансии и стажировки в крупных и известных компаниях, лидерах рынка!

Повышение квалификации

Хотите усилить резюме? Тогда рекомендуем пройти дополнительные курсы. Освойте Python для написания скриптов автоматизации и самую популярную СУБД PostgreSQL. Не забудьте подтянуть разговорный английский, чтобы участвовать в международных командировках и конференциях.

Специально для Вас — скидка 50% на данные курсы в формате онлайн (обращайтесь к менеджеру):

Ваше резюме после прохождения дипломной программы и рекомендованных курсов

• Работа в GNU/Linux, навыки работы в Debian/Ubuntu/Centos
• bash, vim, awk, syslog
• TCP/IP, DHCP, DNS, NTP, SFTP, NAT, SNMP, ssh
• netfilter/iptables, iproute2, Postfix, bind, zabbix
• ansible, puppet, vagrant, terraform
• LXC, docker, kubernetes
• git
• CI/CD: jenkins, gitlab
• DevOps-методология, Agile/Scrum
• + Написание скриптов автоматизации на python
• + администрирование PostgreSQL
• + разговорный английский язык

Получите диплом и станьте настоящим специалистом!

Обучение в рассрочку для дипломных программ — это выгодно и удобно!

Не ломайте голову, где взять всю сумму на обучение по дипломной программе, у нас Вы можете оплачивать его частями. Мы предлагаем Вам рассрочку на оплату обучения!

Кто такой DevOps и как им стать: план обучения

Кто такой DevOps и как им стать: план обучения

• Планы обучения , 17 мая 2018 в 9:41
• Типичный программист

Рассказывает Василий Озеров, SVP of Infrastructure

В этой статье я постараюсь рассказать о том, что требуется ИТ-специалисту, чтобы стать DevOps инженером. Но сначала несколько слов о себе, чтобы познакомиться поближе. Меня зовут Василий, работаю SVP of Infrastructure в одной из рекламных компаний, владею собственным бизнесом и на досуге пишу в свой канал Хмельной DevOps.

С Unix системами я познакомился в далеком 2005 году, еще будучи учеником лицея. О да, те незабываемые ночи, проведенные за установкой FreeBSD и компиляцией KDE из исходников. К слову, именно благодаря этому я и нашел свою первую работу, где разрабатывал небольшие проекты на QT/C++, занимался настройкой Cisco, а также поднимал почтовые сервера. И вот, наконец, я попал в геймдев компанию, где и начал свою карьеру DevOps инженера. Активное взаимодействие разработчиков и команды эксплуатации погрузили меня в доселе невиданный мир. До этого момента путь кода от разработчика на продакшн виделся мне огромной черной бездной, в которой было невозможно ничего разглядеть. Но, окунувшись в нее с головой, я понял, что все не так уж и страшно. Я увидел, как приложения собираются, как тестируются, как уходят в продакшн, где их видит весь интернет. Давайте приподнимем завесу тайны и посмотрим, как же стать успешным DevOps инженером.

Что такое DevOps?

DevOps — это сокращение от Development Operations, и, на самом деле, это не название профессии. Это культура, методика, если угодно. DevOps движение возникло в 2008 году и было призвано решить накопившиеся проблемы. Очень много компаний видели проблему во взаимодействиях команд разработки и эксплуатации. Разработчики считали, что если код запустился у них локально, то нет проблем – можно запускать в продакшн. Если все же проблемы возникали, то со стороны команды эксплуатации звучало: «Да это проблемы с кодом, пусть разработчики разбираются!». Из-за такого подхода релизы продуктов постоянно затягивались и зачастую страдало качество конечного продукта. Сильно накладывало отпечаток еще и то, что за один релиз выкатывалось очень много изменений и было очень трудно разобраться, что же породило проблемы на продакшене.

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

• Build Engineer — человек, отвечающий за сборку кода. Подтягивание зависимостей, разбор конфликтов в коде — это все про него.
• Release Engineer — отвечает за доставку кода от разработки в продакшн. Какая ветка пойдет в тестирование, какой билд попадет на продакшн, релиз-инженер занимается именно этим.
• Automation Engineer — инженер по автоматизации. Автоматизирует все, что движется. А что не движется, двигает и тоже автоматизирует. Автоматическая сборка при пуше в гит, прогон тестов, деплой на staging, деплой в продакшн — это все его задачи. Ключевая роль в DevOps подходе.

В целом можно выделить еще несколько ролей. Например, Security Engineer, который будет отвечать за прогон security-тестов и изучение уязвимостей в используемых компонентах. В реальном мире все (или почти все) эти роли по отдельности обычно совмещает какой-нибудь другой человек. К примеру, роль билд инженера можно отдать в руки разработчика. Да и автоматизация настройки серверов обычно отдается системным администраторам. А DevOps инженеру остается проработать и автоматизировать процесс сборки и доставки кода от разработчика в продакшн.

Минимальные знания, необходимые DevOps инженеру

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

Senior System Administrator

Или хотя бы middle. Идея в том, что вы должны на хорошем уровне разбираться в среде, в которой будут работать ваши приложения. Как они стартуют (init, systemd), что делать, если вы видите ошибку too many open files, использовать или не использовать swap. Все это очень сильно пригодится, когда вы будете запускать реальные проекты.

Sportmaster Lab, Москва

1. Пройдите базовый курс по Linux.
2. Я учился по сайту lissyara.su, речь тут идет больше о FreeBSD, но, изучив все статьи, получится хорошо расширить свой кругозор по часто используемом софту.
3. Самое главное во время обучения — с головой окунуться в происходящее. Этому очень способствуют тематические форумы и телеграмм-каналы.

Networking — CCNA

Очень важная вещь, хотя про это забывают многие разработчики. Я считаю, что нельзя писать онлайн-сервисы, не понимая, как работает сеть. Никто не говорит, что надо заучивать семь уровней модели OSI, но точно потребуется знать, как работает IP, TCP/UDP и, конечно, протокол уровня приложения — например, HTTP, HTTP/2. Это сохранит вам кучу нервов выискивая причины ошибки Connection Refused.

1. Запишитесь на курс CCNA.
2. Установите себе GNS 3 и прокачивайтесь в настройке сетевого оборудования.

Junior Developer

Да-да. Вы должны представлять, как пишется код, что такое ООП, что такое потоки и еще кучу разных вещей. В общем, чем больше у вас знаний в этом пункте, тем легче вам будет собрать и выкатить приложение.

Многие могут не согласиться со мной, аргументируя это тем, что код должен писать разработчик. Но, простите, если вы не понимаете, как создается программный продукт, то как вы будете автоматизировать его сборку, тестирование и депплой? Сможете ли вы заметить узкое место в архитектурном решении до того, как оно попадет на продакшн? Чтобы ответить на эти вопросы, все же необходимо немного углубиться в основные понятия.
С чего начать:

1. Изучить основные типы используемых данных.
2. Посмотреть на основные применяемые алгоритмы.
3. Почитать про паттерны программирования.
4. Пройти простой курс по любому языку программирования, например, у golang есть неплохой интерактивный онлайн-туториал.

Junior DBA

На самом деле это входит в предыдущий пункт, но я все же решил его вынести отдельно. Поскольку все текущие проекты в любом случае используют базы данных, было бы неплохо уметь писать SQL запросы, использовать explain и понимать, как работают и зачем нужны index‘ы. Ну и до кучи посмотреть на популярные nosql решения.

1. Самое простое — это пройти какой-нибудь курс, например от Enterprise DB.
2. Если курс не хочется,то открываем документацию по postgres, устанавливаем базу, создаем таблички и изучаем основные команды, такие как select , insert , join . Смотрим на execution plan запроса, создаем индексы, а также бекапим, восстанавливаем и настраиваем репликацию.

Судя по моей личной статистике, чаще всего в DevOps приходят люди из эксплуатации, поскольку у разработчиков обычно не прокачан первый скилл из списка. Но я знаю два случая из жизни, когда senior developers становились DevOps, потому что им надоело, как работает эксплуатация ? И, к слову, помимо технических навыков вам точно потребуются некоторые софт скиллз. Как минимум вы будете очень много общаться со всеми заинтересованными сторонами. Также вы будете продвигать новые идеи и технологии, что потребует от вас умения ясно и четко доносить свои мысли и умение спорить. Про стрессоустойчивость писать не буду, но терпение вам точно понадобится, поскольку внедрить новую крутую технологию зачастую невозможно в течение одного дня.

Как стать DevOps инженером

Вообще DevOps инженер — это больше про опыт, нежели про знание конкретного софта. Девопс-ребята постоянно учатся, изучают и тестируют новые проекты и технологии. Они должны постоянно задавать себе вопрос: улучшит ли эта технология наш проект? Что лучше выбрать в качестве языка: ruby, python, golang или написать на чистых плюсах? А как мы будем доставлять изменения в продакшн, чтобы не поломать работающие системы?

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

1. Сразу напишем небольшое приложение. Язык выбираем абсолютно любой. Приложение будет отдавать информацию о пользователях через HTTP. По сути, простенькое API.
2. Теперь давайте добавим работу с базой: пусть наши пользователи хранятся в базе. Идеально структуру базы хранить рядом с кодом и научиться прогонять миграции при новых изменениях. Таким образом ваше приложение само синхронизирует базу до нужной структуры.
3. Регистрируемся на github.com/bitbucket.org и закидываем весь исходный код нашего приложения туда.
4. На своей машине поднимаем jenkins/teamcity и настраиваем автоматическую сборку приложения из нашего репозитория по кнопке.
5. Усложняем задачу. Настроим webhooks на github/bitbucket, которые будут автоматически запускать сборку на jenkins/teamcity.
6. Добавим тестов в jenkins: как минимум можно прогонять lint по нашему коду или набросать unit тесты.
7. Переключимся на настройку dev окружения. Берем в руки ansible/chef/puppet/salt и настраиваем виртуалку с нуля: создаем пользователей, устанавливаем необходимые библиотеки и зависимости.
8. Подводим все это дело под vagrant: виртуалка должна автоматически подниматься и настраиваться.
9. Подключаем vagrant к jenkins с помощью соответствующего плагина: при пуше в git наше приложение собирается, и поднимается виртуальное окружение с помощью vagrant + configuration system management.
10. Ищем best practices по деплою приложений на языке, который вы выбрали. Можно заворачивать все в deb/rpm пакеты, можно деплоить ruby с помощью capistrano. Главное — выбрать решение.
11. Выбор сделан, реализуем его и конфигурируем jenkins, чтобы после пуша в репозиторий, jenkins, помимо сборки приложения и развертывания окружения, выкладывал и запускал наш код.
12. Добавляем смоук тесты: после запуска jenkins должен запросить список пользователей у нашего API и убедиться, что получает ответ.
13. Добавляем мониторинг нашего проекта: изучаем time series базы, настраиваем prometheus, grafana, автоматически подключаем новый инстанс нашего приложения к мониторингу.
14. Улучшаем мониторинг: интегрируемся со slack и pagerduty, чтобы получать нотификации.
15. Читаем про докер, пишем Dockerfile и оборачиваем наше приложение.
16. Изучаем увлекательные статьи про настройку систем оркестрации swarm, kubernetes, rancher cattle. Следуем рекомендациям и поднимаем кластер.
17. Меняем Jenkins: собираем docker образ, прогоняем тесты, запускаем собранный докер на кластере kubernetes, проводим smoke тесты, вводим наше приложение в балансировку.

Главной целью всех этих шагов является получение опыта работы с различными технологиями. Я уже говорил, что самое главное для DevOps инженера — это кругозор, так что берем эти же 17 пунктов и в каждом из них меняем технологию на новую. Писали приложение на golang? Теперь пишем на ruby. Использовали jenkins? Берем teamcity. Поднимали kubernetes? Настраиваем swarm. Таким нехитрым образом через несколько месяцев вы заранее сможете понять, что лучше использовать в конкретной ситуации, а это — самое главное качество грамотного и успешного DevOps.

Заключение

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

Выпуск №30 — Мой путь к DevOps через курсы на Otus

В этом выпуске хочу сказать пару слов про DevOps и про курсы, которые я проходил осенью 2017 года.

— https://otus.ru/lessons/devops-praktiki-i-instrumenty/
— http://hangops.ru/
— https://devopsdeflope.ru/

Масштаб моей инфраструктуры на работе не велик — число серверов можно пересчитать по пальцам рук, часть в облаке, часть на своём железе. И стек технологий достаточно проверенный: в ряде проектов это PHP+MySQL, в одном случае NodeJS+MongoDB. Немного Go, и немного 1С. Обычный малый, или быть может, слегка средний бизнес.

Я стараюсь по минимуму хостить что-то у себя, по максимуму использовать готовые SaaS сервисы: мониторинг в NewRelic и okmeter.io, YouTrack в облаке, Bitbucket для репозиториев и даже Continues Integration в облаке Bitbucket Pipelines, о чём я рассказывал в прошлом выпуске, короче, по максимуму в SaaS! Для малого бизнеса и моих нагрузок все эти SaaS сервисы укладываются в минимальные или даже бесплатные тарифные планы, нет смысла заниматься обслуживанием инфраструктуры самостоятельно.

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

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

Чтобы навести порядок я где-то год назад начал использовать Ansible, описав текущую инфраструктуру и поддерживаю плейбуки в актуальном состоянии.

Если не слышали про Ansible, или слышали, но не в курсе что это и зачем, поясню в двух словах. Допустим, нам нужно установить на сервер php-fpm и nginx и подложить правильные файлы конфигурации.

Чтобы автоматизировать, можно написать простейший bash скрипт, который последовательно выполнит нужные команды apt install и скопирует файлы конфигурации, которые должны идти в комплекте с этим скриптом.

Ansible — это утилита написанная на Python, для которой мы подготавливаем некий yaml файл (называемый плейбуком), в нём описываем требуемую конфигурацию софта на сервере. Запускаем утилиту ansible-playbook с yaml-плейбуком в качестве параметра и Ansible производит установку и настройку описанной конфигурации на удалённом сервере.

Обычно запуске самой утилиты ansible-playbook делается локальной машине и он ходит на сервер по ssh, в том числе перекидывает туда с локальной машины заранее подготовленные файлы конфигов.

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

Кстати, это не единственный в природе инструмент оркестрации, из тех что на слуху есть ещё Chef, Puppet, Salt Stack. Я их не пробовал, но что я читал в обзорных статьях и слышал в подкастах, в частности в DevOps Дефлопе и Hangops.ru — Ansible проще и идеально подходит для маленьких и средних инфраструктур.

Из популярных DevOps инструментов я также использовал (и сейчас использую) Docker для окружения разработки в некоторых проектах.

Также я что-то читал и слышал о Hashicorp Stack (такие инструменты как Packer, Terraform, …), то тут то там всё чаще всплывал Kubernetes.

Одновременно с этим я ощущал, что мои знания не систематизированы и обрывочны, хотелось всё разложить по полочкам. Я в первую очередь разработчик, а не системный администратор, у меня не было желания и времени углубляться в темы администрирования Linux, но хотелось овладеть базовыми инструментами на стыке Dev и Ops.

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

Прочитав программу, я выделил для себя темы которые были однозначно актуальны (Ansible, Docker), и прочие для расширения кругозора. Финальным аргументом «ЗА» стало то, что среди преподавателей увидел знакомые имена из подкастов про DevOps, а к этим ребятам уже было какое-то доверие. Также авторами и преподавателями на курсе являются специалисты из широко известной в узких DevOps кругах компании Express42.

Вкратце, пройдусь по некоторым пунктам программы: общие слова про DevOps, история развития и всё такое, ChatOps, VPN и Bastion Host, знакомство с Google Cloud Platform, Packer, Terraform, Ansible, тестирование Ansible ролей в Vagrant, Docker, Docker Machine, Docker Compose, технологии непрерывной поставки на примере GitLab CI, мониторинг и алертинг, Prometheus и Grafana, логирование, distributed tracing, контейнерная оркестрация в целом и Docker Swarm и Kubernetes в частности, Ingress, Helm, Интеграция Kubernetes в GitlabCI, Масштабирование в Kubernetes.

Как видите, программа довольно мощная.

Я проходил курс с первым потоком (первым набором) и иногда это было заметно, материал был шероховат. Иногда в презентациях были ошибки или опечатки, но они быстро разрешались либо смекалкой, либо обсуждением в Slack чате, чувствовалось что ведущие курса реально переживали за своё дело, старались помочь, разъяснить, исследовать возникшие проблемы – честно говоря, я такого не ожидал!

Сквозной нитью через все занятия проходило некое приложение, аналог Reddit, инфраструктуру для которого мы постепенно описывали и разворачивали различными инструментами. Практические занятия, на мой взгляд, составляют 80% всей ценности в этом курсе и составлены они весьма хорошо. Представляю какой титанический труд был проделан для проектирования и описания всей этой учебной инфраструктуры.

Самой большой трудностью для меня было то, что часть учебного приложения написана на Ruby и puma, с которыми я никогда не работал и не имею никакого опыта. Править код приложения не требовалось, но были сложности с установкой и настройкой systemd сервиса puma с использованием rvm — эта часть была задана как ДЗ. Через час слепых попыток по мотивам ответов на StackOverflow я понял, что просто теряю время. Разбираться с нюансами запуска Ruby мне было совершенно не интересно и не практично, я посмотрел как выполнили это задание мои коллеги по курсу (другие студенты) и просто использовал их решение. Таких моментов было несколько и я не стеснялся брать чужие решения, если считал тему не интересной для собственного глубокого погружения.

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

Большую часть лекций я смотрел в записи, т.к. время online вещания лично для меня было не удобно. Кажется, всего 3 лекции я посмотрел в режиме реального времени. И оказалось это даже эффективнее. Во-первых, записи я смотрел с ускорением 1.25-1.5x – очень экономит время без ущерба восприятию материала. Во-вторых, мог ставить на паузу, некоторые лекции смотрел в метро по дороге.

По ходу курса я сильно отстал, пропустил около 1,5 месяцев, но не чувствовал себя «за бортом», потому что получал помощь и полезные советы от преподавателей на ровне со всеми. Судя по чату, больше меня отстал всего один человек и это даже как-то подбадривало, что я не самый последний.

В конце был дипломный проект, по желанию, но только для тех кто сдал домашние работы по 23 лекцию включительно (всего лекций было около 30). Я поставил себе цель наверстать эти лекции и сдать домашние задания вплоть до 23-го, чтобы переходить к проекту. Таким образом я сознательно пропустил последнюю часть курса про Kubernetes, мне банально не хватало времени, зато успешно поработал над дипломным проектом.

В качестве дипломного проекта предлагалось готовое приложение, которое нужно было развернуть в Google Cloud Platform с использованием лучших практик и полученных знаний. Выбор конкретных инструментов оставался за студентом. Как вариант, можно было использовать своё собственное приложение.

Я взял своё приложение, над которым трудился по работе. Сначала описал предполагаемую архитектуру и обосновал выбор инструментов в отдельном документе в Google Docs, расшарил в Slack чате, получил пару рекомендаций, начал работать.

Как я быстро обнаружил, дипломный проект является важной частью обучения – это закрепления материала. Пересматривая слайды старых презентаций и выполненное мной когда-то ДЗ, некоторые темы открывал для себя в новом свете. И, хотя эти темы были давно пройдены, я не стеснялся задавать свои свежие вопросы в чате и получал помощь от коллег-студентов и преподавателей.

По ходу дипломной работы пришлось уменьшить амбиции касательно архитектуры, иначе я бы просто не успел к сроку показа первой минимально-рабочей версии. Успел! Дмитрий Мишенко, один из преподавателей, сделал очень подробное ревью, показал слабые места в архитектуре, за что ему огромное спасибо!

В итоге я успешно сдал более-менее работающий проект, получив зачёт. А ещё через пару недель, доведя всё до ума, вывел этот проект в production, ведь это с самого начала была реальная живая задача по работе, которая к тому же прошла тщательное ревью специалистом из Express 42. Если бы я нанимал компанию Express 42 в качестве внешних консультантов на проект, их работа могла бы оказаться дороже, чем я заплатил за курс обучения на Otus. Такой лайфхак, берите на заметку 😉

Пропущенные лекции и ДЗ по Kubernetes так и лежат на моём компьютере, возможно, я к ним вернусь, но уже без возможности получить проверку домашней работы.

В конце курса выдаётся сертификат. Наверное, он доступен где-то в личном кабинете, но, честно говоря, вряд ли он мне пригодится.

Также было предложение пройти собеседование в компаниях-партнёрах: Avito, Крок, Новые облачные технологии, EPAM, Sitronics, Лаборатория Касперского, ЛАНИТ и Яндекс. Я отказался, т.к. вакансии operations инженера, связанные с работой над инфраструктурой, меня не интересовали. Я лишь хотел подтянуть свои знания современных инструментов, чтобы стать более эффективным и полезным как разработчик. Мне всё-таки больше нравится создавать софт, а не эксплуатировать.

В общем, материалом курса и самим процессом остался очень доволен. А результат, в частности реально запущенный проект, превзошёл все мои ожидания!

Для кого порекомендую подобные курсы? Для тех, кто не хочет тратить время на самостоятельный сбор информации и не знает, а что именно нужно изучать и зачем. На курсе очень эффективно всё разложат по полочкам, и главное, замотивируют применять лучшим практики и следовать философии DevOps! Звучит прям как секта какая-то. На том же Otus раз в несколько месяцев происходит набор в новый поток — посмотрите расписание.

Как стать DevOps-инженером за полгода или раньше? Часть 1

Примечание: это первая часть из цикла статей, посвященных DevOps.

Целевая аудитория

Вы разработчик и хотите направить свою карьеру в DevOps русло?

Или вы IT-специалист и хотите получить представление о том, что же такое DevOps?

А может быть вы ни тот, ни другой и просто хотите изменить свою карьеру, но не знаете с чего начать?

Если ответ на все вышеперечисленные вопросы — да, то наш цикл статей призван помочь вам во всем этом разобраться!

Кстати, даже если вы много лет занимаетесь DevOps, то данная статья все равно может стать полезной для вас.

Что же такое DevOps?

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

Что же, для вас я очистил определение от лишнего мусора и вот что получилось:

DevOps- это способ доставки программного обеспечения до конечного потребителя через коллективные боль и ответственность.

Хорошо, но что же это значит на самом деле?

Это значит, что, испокон веков, разработчики (люди, создающие программное обеспечение) имеют совершенно другие мотивы, нежели IT-специалисты (люди, которые запускают программное обеспечение).

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

Однако, как IT-специалист, мне нужно внедрить в продукт как можно меньше функций, так как каждая новая функция — это перемены, а перемены рискованны.

В результате этого разительного контраста и зародился DevOps.

DevOps пытается объединить разработку и обслуживание ПО в один рабочий процесс. Идея заключается в том, что коллектив будет делить между собой как боль, так и ответственность (и, предположительно, вознаграждение) за создание, внедрение и получение дохода от программного обеспечения, ориентированного на клиента.

Пуристы скажут вам, что не существует такого понятия как «DevOps-инженер». «DevOps — это культура, а не должность» — будут они вам говорить.

Да, да мы поняли. Технически они правы, но, как часто бывает, термин в конце концов вышел за рамки своего первоначального смысла.

Теперь, DevOps-инженер — это что-то вроде «Программного инженера версии 2.0»

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

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

Обратите внимание, что если вы выберете в качестве карьеры DevOps сферу, вы легко сможете найти себе рабочее место, так как сейчас почти все компании поддерживают DevOps. Ну либо утверждают, что поддерживают.

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

ПРИМЕЧАНИЕ: Будьте осторожны с объявлениями, наподобие: «Требуется DevOps-команда» или «DevOps-отдел». Грубо говоря, такие объявления не должны существовать, так как DevOps — это культура и «способ доставки» программного обеспечения, а не специальный отдел или команда.

Дисклеймер

Теперь, отставим стакан газировки в сторону и рассмотрим следующее.

Слышали ли вы когда-нибудь изречение о том, что «в DevOps нет junior-инженеров»?

Если не слышали, то знайте, что это очень популярный троп на таких платформах как Reddit и Stack Overflow. Но что он означает?

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

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

Однако! Существует примерно согласованный (трендовый, если вам так удобнее) список инструментов и концепций, которые используют большинство компаний. О них и пойдет речь в этой статье.

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

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

Достаточно болтовни, с чего мне начать?

Ниже дан план, который приведет вас к желаемой должности.

Если вы пройдете его от начала до конца, то сможете смело называть себя DevOps-инженером! Или Cloud-инженером, если вам не нравится предыдущее название.

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

ПРИМЕЧАНИЕ: Вы должны преодолеть этот путь шаг за шагом. Начните с фундамента, не пропускайте его! Сначала изучите технологии, помеченные синим цветом (Linux|Python|AWS), затем, если позволяет время или этого требует нынешний рынок труда, изучите технологии, помеченные фиолетовым (Golang|Google Cloud).

Повторюсь, синий цвет обязателен, а фиолетовый нужен для углубления уже имеющихся знаний.

После того, как вы усвоите весь «фундамент», переходите к изучению навыков, использующихся в реальных «боевых» условиях:

ПРИМЕЧАНИЕ: В схеме выше намеренно отсутствуют навыки, необходимые для тестирования ПО. Написание блоков кода, интеграция, приемочное тестирование традиционно ложатся на плечи разработчиков. Упущение фазы «тестирования» является преднамеренным действием, так как цель данной статьи — быстрое освоение новых навыков и инструментов. По мнению автора статьи, отсутствие опыта в тестировании — крайне незначительная помеха для трудоустройства.

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

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

Хорошо, копнем немного глубже!

Фундаментальные знания

Вверху статьи есть план под названием «Фундамент» с навыками, которыми должен овладеть любой DevOps-инженер.

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

Давайте разберем эти три столпа шаг за шагом.

Linux

Linux: там, где происходит вся магия. Можно ли быть DevOps-инженером, оставаясь при этом в экосистеме Microsoft? Конечно вы можете! Не существует закона, который бы предписывал работать исключительно в системе Linux.

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

Как проще всего выучить Linux? Установите на домашний компьютер дистрибутивы Fedora или Ubuntu и используйте их как можно чаще! В процессе использования вам не раз придется ломать и чинить систему, сталкиваться с различными проблемами, благодаря которым, в конце концов, вы познаете Linux.

Для справки, в Северной Америке очень распространен дистрибутив Linux от компании Red Hat. Поэтому имеет смысл начать с Fedora или CentOS. Кстати, если не можете выбрать графическое окружение — KDE или Gnome, ставьте KDE. Его использует Линус Торвальдс.

Python

Python: самый распространенный язык для back-end’а в наши дни. С него легко начать, и он повсеместно используется во многих сферах. Бонус: Python широко распространен в сфере искусственного интеллекта и машинного обучения, поэтому, если решите этим заняться в будущем — вам практически ничего не придется учить.

Amazon Web Services: Без понимания того, как работает открытый облачный сервис невозможно стать DevOps-инженером. Amazon Web Services, пожалуй, лучшее место для изучения всей отрасли, так как он предлагает наиболее богатый набор инструментов для работы.

Вы спросите, можно ли начать с Google Cloud или Azure? Безусловно! Но после серьезного падения доллара, самым безопасным вариантом, по крайней мере, в 2018 году остается AWS.

При регистрации на AWS, вы получаете бесплатный уровень пользования сервисом на 1 месяц.

Когда вы залогинитесь в AWS, вас поприветствует простое и понятное меню выбора их продуктов.

Шучу, это был сарказм. Хорошая новость в том, что вам не нужно знать каждую функцию AWS.

Начните со следующего: VPC, EC2, IAM, S3, CloudWatch, ELB и всех продуктов из меню «Безопасность, идентификация и соответствие требованиям». Этого достаточно для начала работы с облачными сервисами.

У AWS есть собственный веб-сайт предназначенный для изучения их функций и это отличное место для начала обучения.

Я рекомендую вам уделять хотя бы по 30 минут в день на практику Python, Linux и AWS.

ПРИМЕЧАНИЕ: В целом, я считаю, что тратить ежедневно по часу, пять раз в неделю, достаточно для того, чтобы за 6 месяцев или меньше сложилось четкое представление о том, что происходит в DevOps сфере.

Но это касается только фундаментальных знаний!

В следующих статьях нашего цикла мы рассмотрим этапы: Конфигурирования, Версии, Пакеты, Внедрение, Запуск и Мониторинг программного обеспечения полностью автоматизированным способом.