В октябре Владислав Килин, Кирилл Борисов и учебная команда Слёрм проведут «DevOps Tools для разработчиков» — практический интенсив в новом формате. Его цель — расширить стек специалистов и познакомить их популярными эксплуатационными инструментами. Мы провели интервью с автором идеи интенсива и руководителем одной из учебных команд Слёрма, Евгением Бутыриным. Он рассказал, в чём идея «DevOps Tools для разработчиков» и кому он будет полезен, почему было принято решение внедрить изменения в отработанный формат обучения.

Что это за интенсив 

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

Цель интенсива — расширить стек специалиста. Мы пройдёмся по основным эксплуатационным инструментам без ухода в глубину. При необходимости в дальнейшем студенты смогут самостоятельно копнуть в нужную им технологию по документации. Мы осознанно не идём вглубь, потому что глубина — это частные кейсы. А наша задача — посмотреть на проблему комплексно и познакомить разработчиков со всем, что окружает их кроме кода. В этом принципиальное отличие нашего интенсива от других образовательных продуктов на рынке. 

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

Кому будет полезно

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

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

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

Делить студентов по уровню подготовки не хотелось бы, так как специалист специалисту рознь. Если всё-таки говорить в таком контексте, в первую очередь мы ориентируемся на джунов и мидлов. Но и сеньорам интенсив тоже будет полезен. 

Всё дело в стеке: вы можете быть сеньором, но работать только с одним набором инструментов. В таком случае интенсив — отличная возможность познакомиться с разными сервисами. Тогда, придя на новое место, где будет другой брокер сообщений или другая база данных, вы будете уже знать, как и что работает. Останется только освежить знания и идти в частные нюансы.

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

С какими проблемами нужно идти на «DevOps Tools для разработчиков»:

• не знаете best practice;

• не понимаете, как архитектурно связаны инструменты;

• вам сложно общаться с командой эксплуатации.

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

Первый интенсив в новом формате

«DevOps Tools для разработчиков» — наш первый интенсив в новом формате. Раньше обучение на интенсивах выглядело так: на протяжении трёх дней вы слушали спикера, задавали вопросы и сразу выполняли практику. В новом формате мы предлагаем сосредоточиться на учебном контенте, а задания выполнить уже по окончанию интенсива в удобное время, в комфортном темпе. Три дня вы будете слушать лекции, смотреть, как спикер решает разные задачи, и задавать вопросы по ходу. А после у вас останутся стенды, на которых можно будет закрепить пройденный материал и набить руку.

По сути, это мой эксперимент как директора курса: я считаю, такое нововведение должно улучшить образовательный процесс. Когда интенсив не подразумевает командной работы, и каждый уходит индивидуально делать практику, возникает проблема, что кто-то быстрее, кто-то медленнее. При этом у интенсива есть жесткий тайминг, когда на выполнение заданий отводится 30-60 минут. Вы либо успеваете, и всё хорошо. Либо не успеваете, и здесь возможны два варианта развития событий. Первый — всё, что вы делаете становится абсолютно бесполезным, потому задания не доделаны, непонятно, правильно там или нет, и даже вопросы толком сформулировать не получается. Второй — вы продолжаете решать задачу, когда начинается объяснение следующей темы, и не усваиваете материал. 

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

Такой подход идёт ещё со школы, когда на уроке ученикам даётся одинаковое время на задания, но скорость выполнения у всех разная. Приведу пример из своего опыта: мне тяжеловато давалась стереометрия, хотя всегда была твердая четвёрка. Я мог сидеть с домашними заданиями до 2-3 часов ночи. Времени уходило много, но в итоге всё получалось. 

Понимая это, я подумал: а зачем требовать синхронного выполнения практики в три дня интенсива? DevOps Tools — сложная штука, и какие-то моменты могут доходить очень медленно. Эффективнее, если студенты сейчас сосредоточатся на объяснениях спикера и вопросах, а позже сделают задания на стендах. 

Кстати, это не единственное нововведение. Концепция, как будем учить, тоже новая — на этом интенсиве мы будем двигаться не по темам, а по этапам. 

Двигаемся не по темам, а по этапам

Всё будет строиться вокруг API Gateway, frontend, backend — трех сервисов приложения на Python. Возьмем каждый сервис и проведём через все этапы: от локального окружения до деплоя. Может показаться странным, что у нас отдельно CI и CD — инструменты же вроде одни. Но этапы разные. А идея интенсива как раз в том, чтобы пронести приложение через все этапы.

Мы взяли приложение Python, которое уже было у Слёрма. Этот интенсив не про написание кода, поэтому здесь не так важен язык программирования. Python довольно легко читается, но самостоятельно разбираться ни в чем не придётся, так как спикер будет проговаривать все моменты.

На интенсиве два спикера — из разработки и администрирования

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

У Слёрма есть Клуб Инженеров — закрытый чат для выпускников. Я поделился в нём идеей интенсива и спросил, кому интересно. Ко мне пришёл Влад, и мы обсудили, какие инструменты он может взять. Ко второму спикеру, Кириллу Борисову, я уже пошёл сам. До этого мы вместе работали над курсом по Jenkins, и я понимал, что его экспертиза отлично ложится на стек, который оставалось закрыть. 

Сейчас распределение примерно такое: 2/3 материала покрывает Влад, и 1/3 — Кирилл. На первом методическом синке мы обсудили программу, поговорили об этапах и стеке. Круто, что Влад сейчас техлид, который когда-то был фронтенд-разработчиком, а Кирилл инфраструктурный инженер. За счёт этого получилось посмотреть на инструменты с разных сторон: убрать что-то устаревшее, добавить актуальное и неочевидное. 

Дальше смотрели приложение, на основе которого будет строиться практика. Выделили сервисы, которые возьмём. Дополнительно обсудили идею универсальности знаний — получится ли подать информацию так, что было полезно разработчику на любом языке программирования. Ответ: получится.

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

Как будем интегрировать разный стек на практике

Будет основная ветка — стек, которого мы придерживаемся. Условно, это приложение с Docker, PostgreSQL, Nginx, Gitlab CI и Kafka. Но на каждом этапе, где возможны вариации, мы будем делать ответвления на разные стеки. Например, на этапе настройки Nginx или Apache, возьмём приложение с Docker, PostgreSQL и Gitlab CI. Получится одно приложение на Nginx, и одно на Apache.

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