«Разработчик должен знать только необходимый минимум для своего грейда», — сказал никто. Даже если от мидла не требуют понимания какой-то темы, это не значит, что он не встретится с ней в работе. Поэтому мы добавили дополнительные уроки для тех, кто хочет получить больше от обучения на курсе «Мидл Python-разработчик».
Всем привет! Я Рома Володин, ведущий разработчик в Т-Банке и человек-оркестр на курсе по разработке на Python. Я и автор, и техлид, и наставник, и немножко ревьюер, но в большей мере всё-таки техлид: руковожу направлением и его развитием. Расскажу, почему мы добавили новый модуль, из чего он состоит и в чём его польза для разработчиков.
Почему появился новый модуль
На курсе по Python-разработке студенты работают с Docker Compose — это самый начальный уровень DevOps, который точно должен знать любой разработчик. С этим он работает каждый день: пишет код, деплоит, проверяет, что всё работает, и передаёт SRE-инженерам. Они уже развернут его в проде и сделают доступным для пользователей.
Во время обучения мы немного упоминаем Docker Swarm, мимоходом. Рассказываем, что это уже устаревшая технология и сейчас все пользуются Kubernetes. Раньше на этом разговор про Kubernetes и заканчивался.
Студентам этого не хватало. По работе они волей-неволей сталкивались с темой: например, коллеги обсуждают между собой что-то, а разработчик даже терминологию не очень понимает. Приходилось идти гуглить и разбираться самому, а хотелось сразу во время учёбы закрыть эти пробелы.
Мы в Практикуме решили не ограничиваться вебинарами, а сделать полноценный учебный модуль. Обратились к нашим коллегам с курса по DevOps, тем самым DevOps-инженерам, которые что-то непонятное между собой обсуждают на совещаниях.
Курс по DevOps не рассчитан на бэкенд-разработчиков: он занимает несколько месяцев и глубоко раскрывает тему. Разработчикам столько подробностей пока что не нужно — им нужна выжимка, чтобы понимать основы. Поэтому мы взяли из курса самое важное и сделали упрощённую версию.
Из чего состоит дополнительный модуль
В модуле три основных раздела: паттерны микросервисной архитектуры, Health Check + K8S, сбор и мониторинг метрик в сервисах. Первый раздел небольшой и относительно лёгкий для понимания, практической части в нём нет. Оставшиеся два — уже сложнее и с практикой. Рассказываю, что находится внутри каждого из них.
1. Паттерны микросервисной архитектуры: в этом разделе рассказали про тонкости микросервисной архитектуры, разобрали основные паттерны для разбиения приложения на микросервисы и шаблоны проектирования. Модуль теоретический, поэтому сильно углубляться не буду. Добавили в него довольно много схем для наглядности.
2. Health check + K8S: здесь сначала мы разбираемся, что такое оркестрация и зачем она вообще нужна. Рассказываем про разные системы оркестрации контейнеров и подбираемся к Kubernetes. Дальше уже переходим к более практическим вопросам и деталям.
Перечислю примерно темы уроков: запуск Kubernetes-кластера для тестирования и разработки, архитектура Kubernetes, базовые и продвинутые сущности, сетевая архитектура Kubernetes и Ingress, Deploy и Rollback, Helm (пакетный менеджер). А в конце темы практическая работа.
Мы пошагово рассказываем про все сущности, которые используются в Kubernetes, как с ними работать, для чего они нужны, как для них писать манифесты, конфигурационные файлы. Вообще, что это, где, чего, куда. Для закрепления знаний студенты разворачивают проект на Fast API в minicube-кластере и в Яндекс Облаке.
Дальше переходим к тому, как работает HealthCheck. Это довольно несложно, и раздел небольшой. Знать про HealthCheck тоже нужно, потому что, например, развернули мы много разных сервисов, а тут один упал, потерялся, перестал работать. Такое нужно отслеживать и контролировать.
3. Сбор и мониторинг метрик в сервисах: когда у нас уже всё работает, начинаем студентам рассказывать, что можно ещё и собирать метрики с приложения. Нам нужно контролировать, как загружен процессор, как загружена сеть, какое у нас время отклика.
Рассказываем про метрики и как их визуализировать. Зачем нужны, как подключить новые, как сделать свои кастомные метрики, какие способы забора метрик бывают. Показываем средства визуализации.
У нас есть красивая Grafana, где можно строить все графики. Заходишь и видишь: ой, на моём сервере свободная память за последнюю неделю интенсивно уменьшается, нужно принимать какие-то меры.
Там же рассказываем и показываем, как работает алертинг. Даже заходить не обязательно: можно настроить так, что в случае чего, когда что-то пошло не по плану, тебе придёт СМС или, например, в Telegram придет сообщение. Ты просто идёшь и быстро устраняешь все эти проблемы.
В финальном практическом задании студенты готовят приложение к публикации: пишут манифесты, деплоят, собирают метрики. визуализируют их и настраивают систему алертинга.
Зачем эти знания бэкенд-разработчику
Дополнительный модуль больше относится к DevOps или SRE, чем к бэкенду. Но нам, бэкендерам, важно это всё понимать. Как работает Kubernetes, как проводятся health-чеки, собираются метрики — все эти знания огромный плюс в резюме.
Например, про Kubernetes довольно большой раздел: много практики, много примеров и теории. Но примеры такие, что их легко применить — скопировал, развернул, посмотрел, что действительно работает, и пошёл дальше. Опять какой-нибудь пример конфига — скопировал, вставил, запустил, убедился, что всё работает. Сильно вникать в это не нужно. Один раз пробежался — и у тебя всегда будет доступ к теории. Любой наш студент всегда может использовать этот материал потом как закладочку, чтобы освежить память.
Потом студент приходит на новое место работы, его спрашивают, понимает ли он что-то в этой теме. Он может сказать, мол, да, я разворачивал кластер. Это было в учебных целях, но по крайней мере, я точно знаю, как он разворачивается в Яндекс Облаке. Я точно знаю, как он разворачивается в minikube, в локальном окружении.
В некоторых компаниях это уже может стать поводом для предложения более высокой позиции. Не говорю, что так будет всегда, но, например, человек может проходить собеседование на мидла, а благодаря этим знаниям ему могут предложить позицию синьора.
Если вы не понимаете, как работает инфраструктура, что с ней нужно делать и как её обслуживать, то у вас возникают ситуации типа: «О, у нас упало приложение, что-то там не работает, и в чём дело — непонятно». А если бы вы хотя бы примерно представляли, как работает инфраструктура, то вам было бы проще хотя бы понять, куда бежать, где копать.
Когда вы понимаете, как работает Kubernetes, понимаете, как работает та же Grafana, как собираются метрики, как делаются health-чеки — вам гораздо проще разобраться, почему что-то упало. Если вы этого не понимаете, то у вас просто куча неизвестных, и вы даже не знаете, как подступиться к проблеме.
Часто бывает, что приходишь в команду в крупную компанию, и там всё перемешано. На ежедневных созвонах сидят ребята SRE, инженеры, которые занимаются железом, сидят бэкенд-разработчики, и все обсуждают одну общую тему.
Ещё есть такое понятие, как дежурство, где ты сидишь и раз в две недели отвечаешь на вопросы пользователей, а вопросы часто бывают и на такие темы. И будет странно, если ты не будешь понимать, о чём они спрашивают.
Ты можешь переадресовать вопрос кому-то более компетентному, но хотя бы должен знать, о чём идёт речь. А для того, чтобы знать, ты должен владеть как минимум терминологией, а ещё лучше — понимать, как происходят все эти процессы в Kubernetes и так далее.
Почему нет дедлайнов и обратной связи
Мы специально добавили этот модуль в качестве опционального, потому что для большинства мидл-разработчиков это действительно не критично. Но это огромный плюс, когда вы идёте на следующую ступень — синьор-разработчика или тимлида.
Потому что, когда вы приходите в команду, где от вас ожидают понимания таких вещей, а вы ничего не знаете, — это будет серьёзным минусом. Вам придётся потратить массу времени на то, чтобы разобраться в том, что можно было бы понять ещё на этапе middle. Поэтому мы и решили сделать этот материал доступным, чтобы вы могли его изучить, когда посчитаете нужным.
Мы понимаем, что там много информации и она не обязательная для нашей профессии. Она интересная, но не такая уж и простая. Поэтому, пожалуйста, можно выпуститься, получить у нас диплом, а потом спокойно в течение двух-трех месяцев изучать всю эту теорию и практиковаться. Когда уже выпустился, какое может быть сопровождение?
Советую не пропускать этот модуль. Даже если вы сейчас не видите в этом необходимости, возможно, скоро вы столкнётесь с ситуацией, когда знание этих вещей станет очень полезным. Тем более, что сейчас всё больше компаний начинают внедрять Kubernetes и вообще более сложные DevOps-процессы. И даже если у вас пока нет такой задачи — лучше подготовиться заранее. Ведь как известно, предупреждён — значит вооружён.