24.07.2020 10:04:54 |
Автор: Участник приходит на курс или интенсив. Видит стройные ряды техподдержки, аккуратно проведённые силовые кабели, шахматный порядок лекционного зала, яркие картинки и схемы слайдов. Спикеры с шутками и улыбками выдаются информацию так, что только успевай вникать. Стенды настроены, задачи по практике просто отлетают от пальцев, разве что порой нужна помощь тех. поддержки.
А ещё кофебрейки с единомышленниками, бодрая и драйвовая атмосфера, обмен опытом, самые неожиданные вопросы спикерам. И ответы, и информация, которую не встретишь в мануалах, а только на практике.
Как думаете, сколько ушло времени, сил и нервов, чтобы оно выглядело именно так?
Спасибо Володе Гурьянову, cертифицированному администратору Kubernetes и инженеру/тимлиду в Southbridge, который с самого начала был свидетелем и деятельным участником создания многих курсов Слёрма.
Он видел изнанку создания курсов сложности и шипованные грабли, инсайты и неожиданные решения. И привычных уже интенсивов по Kubernetes, таких как Слёрм Базовый и Слёрм Мега. И нового, во многом переработанного курса Слёрм DevOps:Tools&Cheats, который неумолимо приближается и начнётся 19 августа.
Но, наверное, хватит лирики, перейдём к самой истории. Как из пары тем интенсива постепенно вырос вполне себе самодостаточный и многогранный курс Docker. Так что начну рассказ, как создаются и развиваются курсы прямо-таки "A long time ago in a galaxy far, far away..."
А что же там за кулисами?
Если спросите, как мы делаем курсы и с чего всё начинается, я отвечу просто "Все начинается с идеи".
Обычно идея приходит откуда-то мы не сидим прикованные наручниками в подвале, пока не придумаем: А на какую же тему нам сделать курс?. Идеи приходят сами откуда-то из внешних источников. Иногда люди начинают активно спрашивать: А что вы знаете про такую-то конкретную технологию?. Или как с Докером было, что его не получалось вместить в тайминг к интенсиву его надо было очевидно выносить вовне, чтобы успеть в рамках интенсива что-то рассказывать.
Именно так появляется идея.
После того как она объявилась, начинается, на мой взгляд, самый сложный момент вообще понять, что же включить в этот курс это очень сопоставимо с тем, как готовятся спикеры для всяких конференций. Там есть такая одна основная проблема\боль, когда ты вроде выбрал тему и думаешь: А что про нее рассказать? Вот это слишком просто, это очевидно, это тоже все знают.
Но на самом деле это нифига не так. И я лично очень много где говорю, что то, что кажется очевидным тебе, тем, кто придет тебя слушать или проходить курс, это совсем не очевидно. И здесь возникает такой большой пласт работы и внутреннего конфликта, а что же включить в курс. В результате которого получается такой список глав эдакими размашистыми большими мазками, про что будет курс.
А дальше начинается простая рутинная работа:
- Подбор материала
- Чтение внимательно документации по текущей версии, поскольку IT-мир сейчас развивается какими-то космическими скоростями. Даже если ты с чем-то работаешь и делаешь про это курс, тебе приходится идти в документацию и смотреть, что там появилось нового, про что интересно рассказать, про что может быть особенно полезно упомянуть.
- И появляется некий скелет курса, где уже большая часть тем, в общем, расписана и вроде бы что там записывай ролики и запускай в продакшен.
- Но на самом деле нет, дальше начинается тяжелая работа, но уже не для авторов курса, а для тех, кто тестирует. Обычно у нас альфа-тестерами выступает техническая поддержка, которая, во-первых, вычитывает курсы на наличие всяких синтаксических, грамматических ошибок. Во-вторых, больно бьют нас палками и ругаются, когда есть какие-то такие совсем неочевидные, непонятные места, какие-нибудь сложно сочиненные\подчиненные приложения на пару страниц или очевидный бред. Потому что, когда ты писал, тебя отвлекли телефонным звонком, и ты начал писать вообще про что-то другое. Они все это вычитывают, высматривают.
- Потом начинается этап тестирования практики, где тоже какие-то очевидные нерабочие вещи улавливаются и показываются какие-то моменты, которые можно либо наоборот усложнить, поскольку это становится не очень интересным просто сидеть копировать и выявляются места, где очень сложно и мы очень многого хотим от людей, которые будут проходить этот курс. И тогда приходят рекомендации: Сделайте, ребята, здесь попроще, это будет легче восприниматься и будет польза от этого больше.
- После того, как этот объем работы проделан, написана та часть, которая относится к видео, вроде бы все хорошо. И можно уже отдавать на выпуск, на рекламу этого курса. Но опять же тоже нет, рано поскольку в последнее время мы перестали немножко доверять себе и в принципе начали побольше работать с обратной связью. Появилась такая штука, как бета-тестирование это когда приглашаются люди вообще сторонние, никак не связанные с нашей компанией и за какие-то плюшки им показывают все части курса, видео, текст, практические задачи, чтобы они оценили качество материала, доступность материала и помогли нам сделать курс максимально хорошо.
- И когда проходит несколько таких итераций, спикерами, альфа-тестированием в виде техподдержки, бета-тестированием, доработками. И потом начинается все по новой техническая поддержка, бета-тестирование, доработки.
- И в какой-то определенный момент приходит понимание, что, либо мы завязываем уже с доработками, потому что сделать так, чтобы нравилось всем совсем нереально, либо принимаются какие-то кардинальные решения. Когда очень многие замечания по каким-то определенным местам критичны переделать их глобально, потому что что-то пошло не так.
- Затем приходит время минорных правок где-то предложение не очень красиво сформулировано, где-то кому-то шрифт не нравится, 14,5, а хотелось бы 15,7.
- Вот когда остаются такого типа замечания, то все, курс более-менее открывается, начинаются официальные продажи.
И на первый взгляд короткая и простая задача сделать курс, она оказывается совсем не простой и занимает невероятно много времени.
И есть еще один момент важный, что работа с курсом не заканчивается, когда курс выпущен. Во-первых, мы читаем внимательно комментарии, которые оставляют к тем или иным частям. И даже несмотря на все те усилия, которые мы приложили, все равно выявляются какие-то огрехи, какие-то косяки, которые по ходу, в реал-тайме правятся, дорабатываются, чтобы каждый последующий пользователь получал более качественный сервис.
Но и product owners. У каждого курса есть свой product owner, который помимо того, что определяет общую концепцию, проверяет сроки, он делает себе заметки на полях, что когда дойдет время для того, чтобы полностью перезаписать курс, а оно точно придет, потому что через года два, а то и год, часть из того, что мы рассказываем, станет неактуальным просто потому, что оно морально устареет. Product owner делает заметочки на полях, что чаще всего люди спрашивают, какие моменты были непонятны, какие задачи показались очень сложными, а какие показались, наоборот, очень простыми. И это все учитывается при повторной записи курса, при каком-то рефакторинге, чтобы каждая итерация глобальная курса становилась лучше, удобнее и комфортнее.
Вот так появляются курсы у нас в Слёрме.
Как родился курс по Docker
Это отдельная, и даже необычная для нас тема. Потому что с одной стороны, мы не планировали его делать, потому что многие онлайн школы его предлагают. А с другой стороны, он сам попросился на волю и обрёл логичное место в нашей концепции подготовки IT-специалиста по Kubernetes.
Если говорить очень глобально, то изначально все началось с курса по Kubernetes, когда его только начали, по-моему, после первого Слёрма. Мы собрали обратную связь и увидели, что очень многие хотят еще где-то что-то дополнительно почитать про docker и вообще многие приходят на базовый курс по Kubernetes, не зная, что такое Docker.
Поэтому ко второму Слёрму сделали курс точнее даже не курс, а сделали пару глав по dockerам. Где рассказывали какие-то самые базовые вещи, чтобы люди, которые приходят на интенсив, не чувствовали себя обделенными и вообще понимали, что происходит.
А потом события развивались, примерно, так. Количество материала росло и перестало влезать в 3 дня. И появилась логичная и очевидная идея: почему бы не сделать из того, что мы рассказываем на Слёрм Базовый, какой-то такой небольшой курс, на который можно было бы отправлять людей, которые хотят перед интенсивом по Kubernetes посмотреть что-то про Docker.
Слёрм Джуниор это, по факту, объединение нескольких таких вот базовых курсов. В итоге курс по dockerу стал куском Слёрм Джуниор. То есть это такая нулевая ступень перед Базовым и Мегой. А потом там были прям совсем базовые абстракции.
В какой-то момент люди начали спрашивать: Ребят, это все здорово, этого достаточно для того, чтобы понимать, что вы рассказываете на интенсивах. А где можно подробнее почитать вообще про то, что может docker и как с ним работать, и что он из себя представляет?. Так появилась идея сделать из него прям полноценный курс по Docker, чтобы, во-первых, в него можно было отправлять все так же людей, которые приходят на Слёрм по Kubernetes, а с другой стороны, для тех, кому даже не интересен на данном этапе развития Kubernetes. Чтобы IT-специалист мог прийти посмотреть наш курс по dockerу и начать свой эволюционный путь просто с чистого dockerа. Чтобы у нас был вот такой полноценный законченный курс и многие потом, посмотрев этот курс, поработав какое-то время с чистым dockerом, выросли до того уровня, когда им необходимо уже Kubernetes или какая-то другая система оркестрации. И пришли в частности к нам.
Порой задают вопрос: "А каким же людям сейчас может не нужно быть Kubernetes?" Но этот вопрос не про людей, это скорее вопрос про компании. Тут нужно понимать, у Kubernetes есть определенные кейсы, где он хорошо подходит и задачи, которые он хорошо решает, а есть наоборот какие-то такие сценарии использования Kubernetes, когда он доставляет дополнительную боль и дополнительные страдания. Поэтому здесь даже не от людей зависит, а от того, что и как давно разрабатывают компании.
Например, какой-то жуткий монолит Legacy наверное, не стоит его пихать в Kubernetes, потому что это доставит больше проблем, чем преимуществ. Или, например, если это какой-то маленький проект у него небольшие нагрузки или в принципе не очень много денег и ресурсов. То его тащить в Kubernetes нет никакого смысла.
И вообще, наверное, в общем, как уже много кто говорил, что если вы задаетесь вопросом: Нужен ли мне Kubernetes?, то скорее всего он вам не нужен. Я не помню, кто это первый придумал, по-моему, Паша Селиванов. Я с этим согласен на 100%. И до Kubernetes нужно дорасти и вот когда уже появляется понимание, что мне нужен именно Kubernetes и нашей компании он нужен, вот он поможет решить такие-то вопросы, то, наверное, есть смысл пойти поучиться и разбираться, как конкретно его настроить хорошо, чтобы процесс перехода на Kubernetes не был очень болезненным.
Какие-то там детские болячки и какие-то прям простые вещи и даже не очень простые, можно узнать в частности у нас, а не проходить через собственные грабли и боль.
Очень многие компаний прошли именно путь, что сначала была какая-то просто инфраструктура без контейнеризации. Потом они перешли к тому, что стало тяжело этим всем управлять, они перешли на dockerы и в какой-то момент доросли до того состояния, что в рамках dockerа и того, что он предлагает становится тесно. И они начали смотреть, что есть вокруг, какие системы решают эти проблемы и в частности Kubernetes это одна из таких систем, которые позволяют решать проблемы, когда в чистом dockerе становится тесно и не хватает функционала, это прям хороший кейс, когда люди снизу вверх идут поэтапно, понимают, что этой технологии мало и переходят на следующий уровень. Попользовались чем-то, снова стало мало и они идут дальше.
Это осознанный выбор и это очень классно.
Я вообще вижу, что очень у нас красиво выстраивается система, например, курс по dockerу, даже по видеокурсам. Потом после dockerа идет базовый Kubernetes, потом Мега Kubernetes, потом Ceph. Всё выстраивается логично человек проходит и получается цельная профессия.
В принципе набор курсов позволяет закрывать очень много кейсов, прям современных. Есть еще зоны, которые остаются серым пятном, я надеюсь, что мы скоро сделаем какие-то курсы, которые позволяют закрыть эти серые области, в частности, про безопасность что-нибудь придумаем. Потому что это становится очень актуально.
Если кратко, то у нас есть какие-то серые области, которые было бы очень неплохо закрыть, чтобы это прям была вообще цельная-цельная картина и люди могли прийти, и как сам Kubernetes из себя представляет конструктор лего, из него можно разные штуки собирать, если еще не хватает дополнять, вот так же с нашими курсами, чтобы люди могли понимать, что им надо из этого надо, собирать некий пазл, некий конструктор из наших курсов.
Если задать самому себе правильный и честный в общем-то вопрос: "Кому сейчас пригодится активный курс Docker?", то:
- Студентам, которые только начинают вникать.
- Сотрудникам отдела тестирования.
- На самом деле есть много компаний, в которых до сих пор, не то, что не пользуются dockerами, а никто не слышал о такой технологии и в принципе не знают, как ее использовать. И я знаю прям несколько в том же Питере крупных компаний, которые занимаются уже много лет разработкой, и они как использовали какие-то старые технологии, они в этом направлении идут. В частности, для таких компаний, для инженеров в таких компаниях, этот курс может быть прям очень интересен, поскольку он, во-первых, позволит быстро погрузиться в эту технологию, а во-вторых, как только появляется несколько инженеров, которые понимают, как это все работает, они могут приносить это в компанию и внутри компании уже развивать эту культуру и эти направления.
- На мой взгляд, этот курс может еще пригодиться тем, кто уже работал с docker'ом, но очень немного и больше в стиле делай раз, делай два и сейчас они собираются так или иначе как-то взаимодействовать с тем же Kubernetes, и это накладывает на них некие обязательства, если есть совсем поверхностные знания, что такое docker, как его запускать, но при этом ты не знаешь, как он работает изнутри, ты не знаешь, что лучше с ним делать, а чего лучше не делать, вот тогда этот курс хорошо подойдет для систематизации и углубления знаний.
Но если у вас знания на уровне: Я не знаю, как правильно писать те же docker-файлы, я представляю себе, что такое namespaces, как работают контейнеры, как они реально реализованы на уровне операционной системы тогда точно смысла нет идти к нам, нового вы ничего не узнаете и будет немножко грустно за потраченные деньги и время.
Если сформулировать, какие преимущества у нашего курса, то:
- мы этот курс постарались сделать с достаточным количеством практических кейсов, которые позволят вам не только разобраться с той теоретической частью, которая есть, но и понять, зачем это вам нужно, и как вы это будете использовать в дальнейшем;
- там есть несколько разделов, которые очень редко где встречаются и вообще по ним не так уж много материалов. Относятся они к взаимодействию dockerа с операционной системой, даже немножко не так. Какие механизмы docker взял у операционной системы, чтобы реализовать систему контейнеризации и это дает такое более глубинное понимание вообще всего вопроса запуска контейнеров в рамках операционной системы Linux. Как это работает, как это взаимодействует друг с другом внутри операционной системы, снаружи и так далее.
Это такой прям глубокий взгляд, что бывает достаточно редко, и при этом, на мой взгляд, это очень важно. Если вы хотите вообще с любой технологией разобраться хорошо и понимать, что от нее ждать, нужно хотя бы в общих чертах представлять, как она работает на низком уровне.
Наш курс показывает и рассказывает, как это устроено с точки зрения операционной системы. С одной стороны, что все системы контейнеризации используют одни и те же механизмы операционной системы. С другой стороны, они берут то, что есть в операционной системе Linux, как docker. Другие системы контейнеризации не придумали ничего нового они взяли то, что есть уже в Linux и написали просто удобную обертку, которая позволяет это быстро вызывать, запускать или как-то с этим взаимодействовать. Тот же докер это не очень большая прослойка между операционной системой и командной строкой, это некая такая утилита, которая позволяет не писать килотонны команд, или какого-то си-шного кода, чтобы сделать контейнер, а чтобы сделать это путем введения пары строк в терминале.
И плюс еще, если мы говорим именно про docker, что реально привнёс в мир IT docker это стандарты. Как должно запускаться приложение, как оно должно работать, какие есть требования к логам, какие есть требования к масштабированию, конфигурированию самого приложения.
Во многом docker это про стандарты.
Стандарты так же переезжают в Kubernetes и там ровно те же стандарты, если вы умеете запускать свое приложение хорошо в докере, то на 99% оно будет так же хорошо работать и в рамках Kubernetes.
Если вам оказалось интересно не только как создавался курс Docker, да и другие курсов, а ещё и заинтересовал сам курс с практической точки зрения, то ещё есть время приобрести его по скидке предзаказа 5000 рублей до 30 июля.
Будем рады вас видеть!
Категории: 
Пруф про суахили
Пример записи в ворклоге, кое-как нашёл,
ибо такие вещи очень динамичны и лишнее потом просто удаляется
Кроме каверов на песни мы также
пробовали делать каверы на плакаты. Кто не узнал - это Sonne от
Rammstein.
Очень хорошая привычка - документировать
всё что можно. Сколько раз на репетиции во время свободной
импровизации были найдены отличные идеи, но к следующей репетиции
эти идеи забывались напрочь :( Всё превращать в бумажный документ
слишком затратно, но вот записывать репетиции целиком - это просто
и в некоторых случаях бесценно!
Трёхактная
схема, классика.
Тексты писать сложно. Здесь есть своя
теория и свои инструменты, кому интересно - могу рассказать и про
этот аспект, я как-то потратил приличное количество времени,
пытаясь автоматизировать это дело, но на данном этапе развития
технологий в нашем случае эффективнее писать вручную.
Очередной эксперимент - добавили женский
вокал, организовав фит с коллегами. В центре в светлой футболке -
наш слайд-жокей, он же критик. И не просто критик - эксперт в
тяжёлой музыке, автор статей в музыкальные журналы!
Клавишник группы Sun-Techniki, он же Core Tech Lead.
