Учасник приходить на курс чи інтенсив. Бачить стрункі лави техпідтримки, акуратно проведені силові кабелі, шаховий порядок лекційного залу, яскраві картинки та схеми слайдів. Спікери з жартами та посмішками видаються інформацію так, що тільки встигай вникати. Стенди налаштовані, завдання на практиці просто відлітають від пальців, хіба що часом потрібна допомога тих. підтримки.
А ще кавобрейки з однодумцями, бадьора та драйва атмосфера, обмін досвідом, найнесподіваніші питання спікерам. І відповіді, і інформація, яку не зустрінеш у мануалах, а лише на практиці.
Як думаєте, скільки пішло часу, сил і нервів, щоб воно виглядало саме так?
Дякую Володі Гур'янову, сертифікованому адміністратору Kubernetes та інженеру/тимліду в Southbridge, який із самого початку був свідком та діяльним учасником створення багатьох курсів Сльорма.
Він бачив виворот створення курсів — складності та шиповані граблі, інсайти та несподівані рішення. І звичних вже інтенсивних Kubernetes, таких як Слерм Базовий і Слерм Мега. І нового, багато в чому переробленого курсу , який невблаганно наближається та розпочнеться 19 серпня.
Але, мабуть, досить лірики, перейдемо до самої історії. Як із пари тем інтенсивно поступово виріс цілком собі самодостатній та багатогранний . Так що почну розповідь, як створюються і розвиваються курси - прямо-таки "A long time ago in a galaxy far, far away ..."
А що ж там за лаштунками?
Якщо запитаєте, як ми робимо курси і з чого все починається, я відповім просто "Все починається з ідеї".
Зазвичай ідея приходить звідкись — ми не сидимо прикуті кайданками у підвалі, доки не придумаємо: «А на яку тему нам зробити курс?». Ідеї приходять самі звідкись із зовнішніх джерел. Іноді люди починають активно запитувати: «А що ви знаєте про конкретну технологію?». Або як з Докером було, що його не виходило вмістити в таймінг до інтенсивності — його треба було очевидно виносити назовні, щоб встигнути в рамках інтенсивності щось розповідати.
Саме так з'являється ідея.
Після того, як вона з'явилася, починається, на мій погляд, найскладніший момент - взагалі зрозуміти, що ж включити в цей курс - це дуже порівняно з тим, як готуються спікери для будь-яких конференцій.
Там є один основний біль, коли ти начебто вибрав тему і думаєш: «А що про неї розповісти? Ось це надто просто, це очевидно, це теж усі знають».
Але насправді це ніфіга негаразд. І я особисто дуже багато де кажу, що те, що здається тобі очевидним, тим, хто прийде тебе слухати або проходити курс, це зовсім не очевидно. І тут виникає такий великий пласт роботи та внутрішнього конфлікту, а що ж включити до курсу. В результаті якого виходить такий список голів такими розгонистими великими мазками, про що буде курс.
А далі починається проста рутинна робота:
- Підбір матеріалу
- Читання уважно документації за поточною версією, оскільки IT-світ зараз розвивається якимись космічними швидкостями. Навіть якщо ти з чимось працюєш і робиш про це курс, тобі доводиться йти в документацію і дивитися, що там з'явилося нового, про що цікаво розповісти, про що особливо корисно згадати.
- І з'являється якийсь скелет курсу, де вже більша частина тим, загалом, розписана і начебто там - записуй ролики і запускай у продакшен.
- Але насправді ні, далі починається важка робота, але вже не для авторів курсу, а тих, хто тестує. Зазвичай у нас альфа-тестерами виступає технічна підтримка, яка, по-перше, вираховує курси на наявність усіляких синтаксичних, граматичних помилок. По-друге, боляче б'ють нас палицями і лаються, коли є якісь такі зовсім неочевидні, незрозумілі місця. Коли виникають у текстах якісь складно складені підлеглі речення на пару сторінок або очевидна маячня. Вони все це вичитують, виглядають.
- Потім починається етап тестування практики, де теж якісь очевидні неробочі речі вловлюються і показуються якісь моменти, які можна або навпаки ускладнити, оскільки це стає не дуже цікавим — просто сидіти копіювати — і виявляються місця, де дуже складно, і ми дуже багато чого. хочемо від людей, які проходитимуть цей курс. І тоді приходять рекомендації: "Зробіть, хлопці, тут простіше, це буде легше сприйматися і буде користь від цього більше".
- Після того, як цей обсяг роботи зроблено, написана та частина, яка відноситься до відео, начебто все добре. І можна вже віддавати на випуск, рекламу цього курсу. Але знову ж таки теж немає, рано — оскільки останнім часом ми перестали трошки довіряти собі і в принципі почали більше працювати зі зворотним зв'язком. З'явилася така штука, як бета-тестування – це коли запрошуються люди взагалі сторонні, ніяк не пов'язані з нашою компанією та за якісь плюшки їм показують усі частини курсу, відео, текст, практичні завдання, щоб вони оцінили якість матеріалу, доступність матеріалу та Допомогли нам зробити курс максимально добре.
- І коли проходить кілька таких ітерацій, спікерами, альфа-тестуванням у вигляді техпідтримки, бета-тестуванням, доробками. І потім починається все за новою – технічна підтримка, бета-тестування, доопрацювання.
- І в певний момент приходить розуміння, що, або ми зав'язуємо вже з доопрацюваннями, тому що зробити так, щоб подобалося всім - зовсім нереально, або приймаються якісь кардинальні рішення. Коли дуже багато зауважень щодо якихось певних місць критичні — переробити їх глобально, бо щось пішло не так.
- Потім настає час мінорних правок — десь пропозиція не дуже гарно сформульована, десь комусь шрифт не подобається, 14,5, а хотілося б 15,7.
- Ось коли залишаються такого зауваження, то все, курс більш-менш відкривається, починаються офіційні продажі.
І на перший погляд коротке і просте завдання зробити курс, воно виявляється зовсім не простим і займає неймовірно багато часу.
І є ще один момент важливий, що робота з курсом не закінчується, коли курс випущено. По-перше, ми уважно читаємо коментарі, які залишають до тих чи інших частин. І навіть незважаючи на всі зусилля, які ми доклали, все одно виявляються якісь огріхи, якісь косяки, які по ходу, в реал-таймі правляться, допрацьовуються, щоб кожен наступний користувач отримував якісніший сервіс.
Кожен курс має свій product owner, який крім того, що визначає загальну концепцію, перевіряє терміни, він робить собі замітки на полях, що коли дійде час для того, щоб повністю перезаписати курс, а воно точно прийде, тому що через роки два, а то й рік, частина того, що ми розповідаємо, стане неактуальним просто тому, що воно морально застаріє. Product owner робить нотатки на полях, що найчастіше люди запитують, які моменти були незрозумілі, які завдання здалися дуже складними, а які здалися, навпаки, дуже простими. І це все враховується при повторному записі курсу, при якомусь рефакторингу, щоб кожна ітерація глобального курсу ставала кращою, зручнішою та комфортнішою.
Отак з'являються курси.
Як народився курс з Docker
Це окрема і навіть незвичайна для нас тема. Тому що з одного боку, ми не планували його робити, тому що багато онлайн шкіл його пропонують. А з іншого боку, він сам попросився на волю і знайшов логічне місце в нашій концепції підготовки IT-фахівця з Kubernetes.
Якщо говорити дуже глобально, то спочатку все почалося з курсу Kubernetes, коли його тільки почали, на мою думку, після першого Сльорма. Ми зібрали зворотний зв'язок і побачили, що дуже багато хто хоче ще десь щось додатково почитати про docker і взагалі багато хто приходить на базовий курс з Kubernetes, не знаючи, що таке .
Тому до другого Слерма зробили курс — точніше навіть не курс, а зробили пару розділів з docker'ів. Де розповідали якісь самі базові речі, щоб люди, які приходять на інтенсив, не почувалися обділеними та взагалі розуміли, що відбувається.
А потім події розвивалися приблизно так. Кількість матеріалу зростала і перестала залазити за 3 дні. І з'явилася логічна і очевидна ідея: чому б не зробити з того, що ми розповідаємо на Сльорм Базовий, якийсь такий невеликий курс, на який можна було б відправляти людей, які хочуть перед інтенсивним Kubernetes подивитися щось про 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'а йде , потім , потім . Все вибудовується логічно - людина проходить і виходить цілісна професія.
У принципі, набір курсів дозволяє закривати дуже багато кейсів, прямих сучасних. Є ще зони, які залишаються сірою плямою, я сподіваюся, що ми скоро зробимо якісь курси, які дозволяють закрити ці сірі області, зокрема, про безпеку щось придумаємо. Тому що це стає дуже актуальним.
Якщо коротко, то у нас є якісь сірі області, які було б дуже непогано закрити, щоб це була взагалі цілісна-цільна картина — і люди могли прийти, і як сам Kubernetes з себе представляє конструктор лего, з нього можна різні штуки збирати, якщо ще не вистачає — доповнювати, так само з нашими курсами, щоб люди могли розуміти, що їм треба з цього треба, збирати якийсь пазл, якийсь конструктор із наших курсів.
Якщо поставити самому собі правильне і чесне загалом питання: "Кому зараз знадобиться активний курс Docker?", то:
- Студентам, які лише починають вникати.
- Співробітникам відділу тестування.
- Насправді є багато компаній, у яких досі не те, що не користуються docker'ами, а ніхто не чув про таку технологію і в принципі не знають, як її використовувати. І я знаю прямий кілька в тому ж Пітері великих компаній, які займаються вже багато років розробкою, і вони як використовували якісь старі технології, вони в цьому напрямку йдуть. Зокрема, для таких компаній, для інженерів у таких компаніях, цей курс може бути дуже цікавим, оскільки він, по-перше, дозволить швидко зануритися в цю технологію, а по-друге, як тільки з'являється кілька інженерів, які розуміють, як це все працює, вони можуть приносити це в компанію і всередині компанії вже розвивати цю культуру та ці напрямки.
- На мій погляд, цей курс може ще стати в нагоді тим, хто вже працював з docker'ом, але дуже трохи і більше в стилі «роби раз, роби два» — і зараз вони збираються так чи інакше якось взаємодіяти з тим же Kubernetes, і це накладає на них якісь зобов'язання, якщо є зовсім поверхневі знання, що таке docker, як його запускати, але при цьому ти не знаєш, як він працює зсередини, ти не знаєш, що краще з ним робити, а чого краще не робити, ось тоді цей курс добре підійде для систематизації та поглиблення знань.
Але якщо у вас знання на рівні: "Я не знаю, як правильно писати ті ж docker-файли, я уявляю собі, що таке namespaces, як працюють контейнери, як вони реально реалізовані на рівні операційної системи" - тоді точно немає сенсу йти до нам, нового ви нічого не дізнаєтесь і буде трошки сумно за витрачені гроші та час.
Якщо сформулювати, які переваги нашого курсу, то:
- ми цей курс постаралися зробити з достатньою кількістю практичних кейсів, які дозволять вам не тільки розібратися з тією теоретичною частиною, яка є, але й зрозуміти, навіщо це вам потрібно, і як ви це використовуватимете надалі;
- там є кілька розділів, які дуже рідко де зустрічаються - і взагалі по них не так багато матеріалів. Належать вони до взаємодії docker'а з операційною системою, навіть трохи не так. Які механізми docker взяв у операційної системи, щоб реалізувати систему контейнеризації - і це дає таке глибше розуміння взагалі всього питання запуску контейнерів у рамках операційної системи Linux. Як це працює, як це взаємодіє один з одним всередині операційної системи, зовні і таке інше.
Це такий глибокий погляд, що буває досить рідко, і при цьому, на мій погляд, це дуже важливо. Якщо ви хочете взагалі з будь-якою технологією розібратися добре і розуміти, що від неї чекати, потрібно хоча б загалом уявляти, як вона працює на низькому рівні.
Наш курс показує та розповідає, як це влаштовано з точки зору операційної системи. З одного боку, всі системи контейнеризації використовують одні й самі механізми операційної системи. З іншого боку, вони беруть те, що є в операційній системі Linux як docker. Інші системи контейнеризації не придумали нічого нового — вони взяли те, що вже є в Linux і написали просто зручну обгортку, яка дозволяє це швидко викликати, запускати або якось з цим взаємодіяти. Той же докер – це не дуже великий прошарок між операційною системою та командним рядком, це якась така утиліта, яка дозволяє не писати кілотонни команд, або якогось си-шного коду, щоб зробити контейнер, а щоб зробити це шляхом введення пари рядків у терміналі.
І плюс ще, якщо ми говоримо про docker, що реально привніс у світ IT docker – це стандарти. Як має запускатися додаток, як він має працювати, які є вимоги до логів, які є вимоги до масштабування, конфігурування самої програми.
Багато в чому docker – це стандарти.
Стандарти так само переїжджають у Kubernetes — і там рівно ті самі стандарти, якщо ви вмієте запускати свою програму добре в докері, то на 99% вона так само добре працюватиме і в рамках Kubernetes.
Якщо вам виявилося цікаво не тільки, як створювався курс Docker, а й інші курси, а ще й зацікавив курс з практичної точки зору, то
Будемо раді Вас бачити!
Джерело: habr.com