Удзельнік прыходзіць на курс ці інтэнсіў. Бачыць стройныя шэрагі тэхпадтрымкі, акуратна праведзеныя сілавыя кабелі, шахматны парадак лекцыйнай залы, яркія карцінкі і схемы слайдаў. Спікеры з жартамі і ўсмешкамі выдаюцца інфармацыю так, што толькі паспявай унікаць. Стэнды настроены, задачы па практыцы проста адлятаюць ад пальцаў, хіба што часам патрэбна дапамога тых. падтрымкі.
А яшчэ кавабрэйкі з аднадумцамі, бадзёрая і драйвовая атмасфера, абмен досведам, самыя нечаканыя пытанні спікерам. І адказы, і інфармацыя, якую не сустрэнеш у мануалах, а толькі на практыцы.
Як думаеце, колькі сышло чакай, сіл і нерваў, каб яно выглядала менавіта так?
Дзякуй Валодзю Гур'янаву, сертыфікаванаму адміністратару 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