En deltagare kommer till en kurs eller intensivkurs. Han ser ordnade rader av teknisk support, snyggt dragna strömkablar, en schackruta layout av föreläsningssalen, ljusa bilder och bilddiagram. Högtalare med skämt och leenden ger ut information på ett sådant sätt att du bara hinner förstå det. Läktarna är uppställda, övningsuppgifter flyger helt enkelt ur fingrarna, förutom att man ibland behöver hjälp av teknisk personal. Stöd.
Och även fika med likasinnade, en munter och energisk atmosfär, utbyte av erfarenheter, de mest oväntade frågorna för talare. Både svar och information som du inte hittar i manualer, utan bara i praktiken.
Hur mycket tid, ansträngning och nerver tror du det tog att få det att se ut exakt så här?
Tack till Volodya Guryanov, en certifierad Kubernetes-administratör och ingenjör/teamledare på Southbridge, som har bevittnat och aktivt deltagit i skapandet av många Slurm-kurser från första början.
Han såg underlivet naturligtvis skapande – komplexiteter och taggiga krattor, insikter och oväntade lösningar. Och de redan välbekanta Kubernetes-intensiven, som Slurm Basic och Slurm Mega. Och en ny, till stor del reviderad kurs , som obönhörligen närmar sig och börjar den 19 augusti.
Men kanske, nog med texterna, låt oss gå vidare till själva berättelsen. Hur från ett par intensiva ämnen en helt självförsörjande och mångfacetterad . Så jag börjar berättelsen om hur kurser skapas och utvecklas - precis som "Länge sedan i en galax långt, långt borta..."
Vad finns bakom kulisserna?
Om du frågar hur vi gör kurser och var det hela börjar, svarar jag helt enkelt "Allt börjar med en idé."
Vanligtvis kommer idén någonstans ifrån - vi sitter inte handfallna i källaren förrän vi kommer på: "Vilket ämne ska vi göra en kurs om?" Idéer kommer från någonstans på egen hand från externa källor. Ibland börjar människor aktivt fråga: "Vad vet du om sådan och en sådan specifik teknik?" Eller hur det var med Docker att det var omöjligt att passa in honom i tajmingen för intensivkursen – han måste uppenbarligen tas ut för att hinna berätta något under intensivkursen.
Så här framstår en idé.
Efter att det tillkännagavs börjar enligt min mening det svåraste ögonblicket - att generellt förstå vad som ska inkluderas i den här kursen - detta är mycket jämförbart med hur talare förbereds för eventuella konferenser.
Det finns en huvudplåga när du verkar ha valt ett ämne och tänker: ”Vad kan jag berätta om det? Det här är för enkelt, det här är uppenbart, alla vet det här också.”
Men i själva verket är det inte alls så. Och jag säger personligen på många ställen att det som verkar självklart för dig, för de som kommer för att lyssna på dig eller gå en kurs, inte alls är självklart. Och här uppstår ett så stort lager av arbete och intern konflikt, vad som ska ingå i kursen. Som ett resultat får vi en sådan lista med kapitel med så svepande stora drag, vad kursen kommer att handla om.
Och sedan börjar det enkla rutinarbetet:
- Materialval
- Läs noga dokumentationen för den aktuella versionen, eftersom IT-världen nu utvecklas i någon form av kosmisk hastighet. Även om du jobbar med något och gör en kurs om det måste du gå till dokumentationen och se vad som är nytt där, vad som är intressant att prata om, vad som kan vara särskilt användbart att nämna.
- Och ett visst skelett av kursen dyker upp, där de flesta av ämnena i allmänhet redan är täckta och det verkar som om vad som än finns där - spela in videor och sätt i produktion.
- Men faktiskt nej, då börjar det hårda arbetet, men inte för kursförfattarna utan för dem som testar. Våra alfatestare är vanligtvis teknisk support, som för det första korrekturläser kurserna för eventuella syntaktiska och grammatiska fel. För det andra slår de oss smärtsamt med käppar och svor när det finns några helt oförstående, obegripliga ställen. När några komplext sammansatta underordnade meningar på ett par sidor eller uppenbara nonsens dyker upp i texterna. De läser allt, håll utkik efter det.
- Sedan börjar övningsteststadiet, där även några uppenbara icke-fungerande saker fångas upp och några ögonblick visas som antingen kan försvåras, eftersom det inte blir särskilt intressant - bara sitta och kopiera - och platser identifieras där det är mycket svårt och vi har mycket att göra vi vill ha av människor som ska gå den här kursen. Och sedan kommer rekommendationer: "killar, gör det enklare här, det blir lättare att uppfatta och det kommer att bli mer nytta av det."
- Efter att denna mängd arbete är gjort skrivs delen som relaterar till videon, allt verkar vara bra. Och du kan redan donera det för produktion, för att annonsera den här kursen. Men igen, nej, det är för tidigt - för nyligen har vi slutat lita lite på oss själva och har i princip börjat jobba mer med feedback. Det finns en sådan sak som beta-testning - det här är när människor bjuds in från utomstående, som inte är kopplade till vårt företag på något sätt, och för några godbitar visas alla delar av kursen, videor, text, praktiska uppgifter, så att de utvärdera materialets kvalitet, materialets tillgänglighet och hjälpt oss att göra kursen så bra som möjligt.
- Och när flera sådana iterationer går igenom, högtalare, alfatestning i form av teknisk support, betatestning, förbättringar. Och sedan börjar allt om igen - teknisk support, betatestning, förbättringar.
- Och vid någon viss tidpunkt kommer förståelsen att antingen är vi klara med modifieringar, eftersom det är helt orealistiskt att se till att alla gillar det, eller så tas några drastiska beslut. När många kommentarer på vissa platser är kritiska, gör om dem globalt, för något gick fel.
- Sedan är det dags för mindre redigeringar - någonstans är meningen inte särskilt snyggt formulerad, någonstans gillar någon inte typsnittet, 14,5, men vill ha 15,7.
- När den här typen av kommentarer finns kvar, då är det det, kursen öppnar mer eller mindre, den officiella försäljningen börjar.
Och vid första anblicken visar sig den korta och enkla uppgiften att skapa en kurs inte alls vara enkel och tar otroligt lång tid.
Och det finns en annan viktig poäng att arbetet med kursen inte slutar när kursen släpps. För det första läser vi noggrant kommentarerna som lämnas på vissa delar. Och trots alla ansträngningar som vi har gjort, är vissa brister fortfarande identifierade, vissa misstag korrigeras och förbättras längs vägen, i realtid, så att varje efterföljande användare får en bättre service.
Varje kurs har sin egen produktägare, som förutom att definiera det allmänna konceptet kontrollerar deadlines, han gör anteckningar i marginalen att när det är dags att helt skriva om kursen, och det kommer definitivt att komma, för om två år, eller till och med ett år senare kommer en del av det vi berättar att bli irrelevant bara för att det kommer att bli moraliskt föråldrat. Produktägaren gör anteckningar i marginalen att man oftast frågar vilka punkter som var otydliga, vilka uppgifter som verkade väldigt svåra och vilka som tvärtom verkade väldigt enkla. Och allt detta tas med i beräkningen när du spelar in kursen på nytt, under någon form av refactoring, så att varje iteration av den globala kursen blir bättre, bekvämare och bekvämare.
Så här ser kurser ut.
Hur Docker-kursen föddes
Detta är ett separat och till och med ovanligt ämne för oss. För å ena sidan har vi inte planerat att göra det, eftersom många onlineskolor erbjuder det. Däremot bad han själv om frihet och hittade en logisk plats i vårt koncept att utbilda IT-specialister i Kubernetes.
På tal väldigt globalt började allt till en början med en kurs om Kubernetes, när det precis började, enligt min mening, efter den första slurmen. Vi samlade in feedback och såg att många vill läsa något mer om Docker någon annanstans, och generellt kommer många till grundkursen på Kubernetes utan att veta vad det är. .
Därför gjorde de för den andra Slurmen en kurs – eller snarare, inte ens en kurs, utan gjorde ett par kapitel om Dockers. Där de berättade några av de mest grundläggande sakerna, för att människor som kommer till intensiven inte skulle känna sig berövade och generellt sett förstå vad som hände.
Och sedan utvecklades händelserna ungefär så här. Mängden material växte och slutade passa på 3 dagar. Och en logisk och uppenbar idé dök upp: varför inte förvandla det vi tar upp på Slurm Basic till någon slags liten kurs dit du kan skicka folk som vill se något om Docker innan de går en intensivkurs i Kubernetes.
Slurm Junior är i själva verket en kombination av flera sådana grundkurser. Som ett resultat blev Docker-kursen en del av Slurm Junior. Det vill säga, det här är ett sådant nollsteg innan и . Och så var det bara väldigt grundläggande abstraktioner.
Vid något tillfälle började folk fråga: ”Gubbar, det här är jättebra, det här räcker för att förstå vad ni pratar om på intensivkurserna. Var kan jag läsa mer i detalj om vad docker kan göra och hur man arbetar med det, och vad det är?” Så idén kom upp att göra det rakt , så att, för det första, människor som kommer till Slurm med Kubernetes fortfarande kan skickas till den, och å andra sidan, för dem som inte ens är intresserade av Kubernetes i det här utvecklingsstadiet. Så att en IT-specialist kan komma och titta på vår kurs om Docker och börja sin evolutionära väg helt enkelt med ren Docker. Så att vi har en sådan fullfjädrad, komplett kurs - och sedan har många, efter att ha sett den här kursen, efter att ha arbetat en tid med ren Docker, vuxit till den nivå där de behöver Kubernetes eller något annat orkestreringssystem. Och de kom särskilt till oss.
Ibland ställs frågan: "Vilken typ av människor behöver kanske inte Kubernetes nu?" Men den här frågan handlar inte om människor, det är snarare en fråga om företag. Här måste du förstå att Kubernetes har vissa fall där det är väl lämpat och uppgifter som det löser bra, men tvärtom finns det några scenarier för att använda Kubernetes när det orsakar ytterligare smärta och ytterligare lidande. Därför beror det inte ens på människor, utan på vilka företag som har utvecklats och hur länge.
Till exempel en fruktansvärd Legacy-monolit - du borde förmodligen inte trycka in den i Kubernetes, eftersom den kommer att orsaka fler problem än fördelar. Eller om det till exempel är ett litet projekt har det en liten belastning eller i princip inte mycket pengar och resurser. Det är ingen idé att dra den till Kubernetes.
Och i allmänhet, förmodligen, i allmänhet, som många redan har sagt, om du ställer frågan: "Behöver jag Kubernetes?", då behöver du troligen inte det. Jag kommer inte ihåg vem som först kom på det, enligt min mening, Pasha Selivanov. Jag håller med till 100%. Och du måste växa upp till Kubernetes - och när det redan står klart att jag behöver Kubernetes och vårt företag behöver det, och det kommer att hjälpa till att lösa sådana och sådana problem, då är det förmodligen vettigt att gå och lära sig och ta reda på exakt hur man ställer in det fungerar bra, så att processen att byta till Kubernetes inte är särskilt smärtsam.
Vissa barns krämpor och vissa enkla saker, och till och med inte särskilt enkla, kan man få reda på i synnerhet från oss, och inte gå igenom din egen kratta och smärta.
Många företag har gått precis så som det till en början bara fanns någon form av infrastruktur utan containerisering. Sedan kom de till den punkten att det blev svårt att hantera allt, de bytte till Docker och någon gång växte de till att det blev trångt inom ramen för Docker och vad det erbjuder. Och de började titta på vad som fanns runt omkring, vilka system som löser dessa problem, och i synnerhet Kubernetes - det här är ett av de system som låter dig lösa problem när ren Docker blir trångt och saknar funktionalitet, detta är ett riktigt bra fall när människor De går steg för steg nerifrån och upp, förstår att den här tekniken inte räcker och går vidare till nästa nivå. De använde något, det blev ont igen, och de gick vidare.
Det här är ett medvetet val - och det är väldigt coolt.
Generellt ser jag att vårt system är väldigt vackert byggt, t.ex. , även genom videokurser. Sedan efter docker går det då då . Allt stämmer logiskt - en person passerar och ett gediget yrke växer fram.
I princip låter uppsättningen kurser dig täcka många fall, även moderna. Det finns fortfarande områden som förblir en gråzon, jag hoppas att vi snart kommer att skapa några kurser som gör att vi kan stänga dessa gråzoner, i synnerhet kommer vi på något om säkerhet. För det här börjar bli väldigt relevant.
Kort sagt, vi har några gråzoner som det skulle vara väldigt trevligt att stänga, så att det skulle bli en komplett, komplett bild – och folk kunde komma, och precis som Kubernetes i sig är som en Lego-konstruktör kan man göra olika saker från det samlar in, om det fortfarande inte räcker - komplettera, samma sak med våra kurser, så att folk kan förstå vad de behöver av detta, de behöver lägga ett slags pussel, ett slags byggset från våra kurser.
Om du ställer dig själv en allmänt korrekt och ärlig fråga: "Vem skulle kunna använda en aktiv Docker-kurs nu?", då:
- För elever som precis börjat komma in i det.
- Anställda på testavdelningen.
- Faktum är att det finns många företag som fortfarande inte bara inte använder Docker, men ingen har hört talas om sådan teknik och i princip inte vet hur man använder den. Och jag känner flera stora företag i St. Petersburg som har utvecklats i många år, och de använde en del gamla tekniker, de går i den här riktningen. I synnerhet för sådana företag, för ingenjörer i sådana företag, kan den här kursen vara mycket intressant, eftersom den för det första gör att du snabbt kan fördjupa dig i denna teknik, och för det andra så snart flera ingenjörer dyker upp som förstår hur det hela fungerar, kan de ta det till företaget och utveckla denna kultur och dessa riktningar inom företaget.
- Enligt min åsikt kan den här kursen fortfarande vara användbar för dem som redan har arbetat med docker, men väldigt lite och mer i stilen "gör en gång, gör två gånger" - och nu ska de på något sätt interagera med samma Kubernetes, och detta ålägger dem vissa skyldigheter, om man har väldigt ytlig kunskap om vad docker är, hur man kör det, men samtidigt vet man inte hur det fungerar från insidan vet man inte vad som är bäst att göra med det och vad är bättre att inte göra, Då är den här kursen väl lämpad för att systematisera och fördjupa kunskaper.
Men om du har kunskap på nivån: "Jag vet inte hur man skriver samma Docker-filer korrekt, jag kan föreställa mig vad namnutrymmen är, hur behållare fungerar, hur de faktiskt implementeras på operativsystemnivå" - då finns det definitivt ingen idé att gå till oss, du kommer inte att lära dig något nytt och du kommer att vara lite ledsen för pengarna och tiden som spenderas.
Om vi formulerar vilka fördelar vår kurs har, då:
- Vi försökte göra den här kursen med ett tillräckligt antal praktiska fall som gör att du inte bara kan förstå den teoretiska delen som finns, utan också förstå varför du behöver den och hur du kommer att använda den i framtiden;
- det finns flera sektioner som mycket sällan finns någonstans - och i allmänhet finns det inte så mycket material om dem. De relaterar till interaktionen mellan Docker och operativsystemet, även lite annorlunda. Vilka mekanismer tog Docker från operativsystemet för att implementera containeriseringssystemet - och detta ger en så djupare förståelse för hela frågan om att köra containrar inom operativsystemet Linux. Hur det fungerar, hur det interagerar med varandra inuti operativsystemet, utanför, och så vidare.
Det här är en så verkligt djup blick att det händer ganska sällan, och samtidigt är det enligt min mening väldigt viktigt. Om du vill förstå någon teknik väl och förstå vad du kan förvänta dig av den, måste du åtminstone ha en allmän uppfattning om hur den fungerar på en låg nivå.
Vår kurs visar och berättar hur detta fungerar ur operativsystemets synvinkel. Å ena sidan använder alla containeriseringssystem samma operativsystemmekanismer. Å andra sidan tar de det som finns i operativsystemet Linux, som docker. Andra containeriseringssystem kom inte med något nytt - de tog det som redan fanns i Linux och skrev bara ett bekvämt omslag som gör att du snabbt kan kalla det, köra det eller på något sätt interagera med det. Samma Docker är inte ett särskilt stort lager mellan operativsystemet och kommandoraden, det är ett slags verktyg som låter dig inte skriva kiloton med kommandon eller någon form av C-kod för att skapa en behållare, utan att göra detta genom att ange ett par linjer i terminalen.
Och en sak till, om vi pratar specifikt om Docker, vad Docker verkligen tillförde IT-världen är standarder. Hur applikationen ska startas, hur den ska fungera, vilka är kraven på loggar, vilka krav finns det för skalning, konfigurering av själva applikationen.
På många sätt handlar docker om standarder.
Standarder flyttas också till Kubernetes - och det finns exakt samma standarder; om du vet hur du kör din applikation bra i Docker, så kommer det att fungera lika bra inom Kubernetes 99 % av tiden.
Om du fann dig själv intresserad inte bara av hur Docker-kursen skapades, utan också av andra kurser, men också intresserad av själva kursen ur en praktisk synvinkel, då
Vi kommer att bli glada att se dig!
Källa: will.com