Il partecipante arriva al corso o all'intensivo. Vede file ordinate di assistenza tecnica, cavi di alimentazione ben organizzati, l'aula con layout impeccabile, immagini vivaci e schemi sulle slide. I relatori forniscono informazioni con battute e sorrisi, rendendo tutto facilmente comprensibile. Gli stand sono pronti e le attività pratiche si svolgono senza intoppi, tranne quando è necessario l'aiuto del supporto tecnico.
Inoltre, ci sono pause caffè con persone affini, un'atmosfera energica e coinvolgente, scambio di esperienze e domande inaspettate ai relatori. Le risposte e le informazioni non si trovano nei manuali, ma solo nella pratica.
Pensate, quanto tempo, energie e nervi sono stati necessari affinché tutto apparisse proprio così?
Grazie a Volodya Guryanov, amministratore certificato Kubernetes e ingegnere/team leader in Southbridge, che fin dall'inizio è stato testimone e attivo partecipante alla creazione di molti corsi di Slurm.
Ha visto il dietro le quinte della creazione dei corsi: complessità e le difficoltà inaspettate, intuizioni e soluzioni sorprendenti. E i corsi intensivi già conosciuti su Kubernetes, come Slurm Basic e Slurm Mega. E il nuovo corso, che è stato in gran parte rielaborato. , che si avvicina inesorabilmente e inizierà il 19 agosto.
Ma forse basta con la poesia, passiamo alla vera storia. Come da un paio di argomenti dell'intensivo è gradualmente emerso un corso autosufficiente e multiforme. . Inizierò quindi a raccontare come vengono creati e sviluppati i corsi, proprio come in "Tanto tempo fa in una galassia lontana lontana..."
E cosa c'è dietro le quinte?
Se mi chiedete come facciamo i corsi e da cosa inizia tutto, risponderò semplicemente: "Tutto inizia da un'idea".
Di solito l'idea arriva da qualche parte: non siamo incatenati in un seminterrato aspettando di pensare: «Su quale tema dovremmo creare un corso?». Le idee arrivano spontaneamente da fonti esterne. A volte la gente inizia a chiedere attivamente: «Cosa sapete di una certa tecnologia?». Oppure, come è successo con Docker, che non riusciva a rientrare nei tempi dell'intensivo — era ovvio che dovevamo portarlo all'esterno per riuscire a trattare un argomento durante l'intensivo.
Così nasce l'idea.
Dopo che si è manifestata, inizia, a mio avviso, il momento più difficile: capire bene cosa includere in questo corso — è molto paragonabile a come i relatori si preparano per varie conferenze.
C'è un grande problema principale quando hai scelto un tema e pensi: «E cosa posso dire su di esso? Questo è troppo semplice, è ovvio, anche questo lo sanno tutti».
Ma in realtà non è affatto così. E personalmente parlo molto del fatto che ciò che ti sembra ovvio, per chi verrà a seguirti o a seguire il corso, non è affatto ovvio. Qui emerge un grande carico di lavoro e un conflitto interiore su cosa includere nel corso. Di conseguenza, si ottiene un elenco di capitoli come delle grandi linee guida di cosa tratterà il corso.
E poi inizia il lavoro di routine semplice:
- Scelta dei materiali
- Leggere con attenzione la documentazione della versione attuale, poiché il mondo IT si sta sviluppando a velocità incredibili. Anche se lavori con qualcosa e stai preparando un corso al riguardo, devi consultare la documentazione e vedere cosa c'è di nuovo, di cosa è interessante parlare e cosa potrebbe essere particolarmente utile menzionare.
- E si crea una sorta di scheletro del corso, dove già gran parte degli argomenti è in qualche modo delineata e sembrerebbe che ora si possa registrare i video e lanciarli in produzione.
- Ma in realtà no, inizia un lavoro pesante, ma non per gli autori del corso, bensì per coloro che testano. Di solito, i nostri tester alfa sono il supporto tecnico, che, prima di tutto, controlla i corsi per errori sintattici e grammaticali. In secondo luogo, ci colpiscono duramente e si lamentano quando ci sono parti completamente non evidenti e incomprensibili. Quando nei testi emergono frasi subordinate complesse che si estendono per pagine o chiacchiere ovvie. Tutto questo viene revisionato e scrutinato.
- Successivamente, inizia la fase di test pratico, dove vengono rilevati anche alcuni aspetti ovvi non funzionanti e vengono messi in evidenza alcuni punti che possono essere semplificati, poiché diventa poco interessante semplicemente copiare; e vengono identificati i punti in cui abbiamo grandi aspettative dalle persone che seguiranno questo corso. E quindi arrivano raccomandazioni: «Ragazzi, rendete questo aspetto più semplice, sarà più facilmente comprensibile e apporterà maggior beneficio».
- Dopo aver svolto questa quantità di lavoro, è stata scritta la parte relativa al video, sembrerebbe che tutto sia a posto. E si potrebbe già procedere con il rilascio e la pubblicità di questo corso. Ma di nuovo non è così, è presto — poiché ultimamente abbiamo smesso un po' di fidarci di noi stessi e in generale abbiamo iniziato a lavorare di più con il feedback. È emersa una cosa come il beta testing - quando vengono invitati persone completamente esterne, non collegate alla nostra azienda e, in cambio di alcune agevolazioni, mostrano tutte le parti del corso, video, testi, compiti pratici, per valutare la qualità del materiale, l'accessibilità del materiale e aiutarci a rendere il corso il migliore possibile.
- E quando passano diverse iterazioni, presentazioni, test alpha sotto forma di supporto tecnico, beta testing, miglioramenti. E poi tutto ricomincia - supporto tecnico, beta testing, miglioramenti.
- E a un certo punto arriva la consapevolezza che dobbiamo smettere di fare modifiche, perché far sì che piaccia a tutti è assolutamente impossibile, oppure vengono prese decisioni radicali. Quando ci sono molte osservazioni critiche su alcune parti specifiche — è necessario rielaborarle in modo globale, perché qualcosa è andato storto.
- Dopo arriva il momento delle correzioni minori - dove una frase non è formulata molto bene, dove a qualcuno non piace il carattere, 14,5, mentre vorrebbe 15,7.
- Quando restano osservazioni di questo tipo, il corso più o meno si apre, iniziano le vendite ufficiali.
E a prima vista, il compito di creare un corso, sembra semplice e breve, ma si rivela tutt'altro che semplice e richiede incredibilmente molto tempo.
E c'è un altro aspetto importante, che il lavoro con il corso non finisce quando il corso viene rilasciato. In primo luogo, leggiamo attentamente i commenti che vengono lasciati su alcune parti. E anche nonostante tutti gli sforzi che abbiamo fatto, emergono comunque alcune imperfezioni, errori che vengono corretti in tempo reale, affinché ogni utente successivo riceva un servizio di qualità superiore.
Ogni corso ha il suo product owner, il quale, oltre a definire il concetto generale e a controllare le tempistiche, prende appunti a margine. Quando arriverà il momento di riscrivere completamente il corso, e quel momento arriverà sicuramente, visto che dopo un paio d'anni, o anche un anno, parte di ciò che trattiamo diventerà obsoleto solo perché diventerà moralmente superato. Il product owner fa annotazioni sui margini riguardo a quali aspetti le persone trovano poco chiari, quali attività sembrano molto difficili e quali, al contrario, sembrano molto semplici. Tutto ciò viene preso in considerazione nella nuova registrazione del corso e durante eventuali rifattorizzazioni, affinché ogni iterazione globale del corso diventi migliore, più comoda e più piacevole.
Ecco come nascono i corsi.
Come è nato il corso su Docker
Si tratta di un tema separato, e persino insolito per noi. Da un lato, non avevamo pianificato di realizzarlo, poiché molte scuole online lo propongono. D'altro canto, si è imposto da solo e ha trovato un posto logico nella nostra concezione della formazione di specialisti IT su Kubernetes.
Parlando in modo molto globale, tutto è iniziato con il corso su Kubernetes, quando è stato avviato, credo, dopo il primo Slearma. Abbiamo raccolto feedback e abbiamo visto che molti volevano leggere ulteriormente su Docker e, in generale, molte persone si avvicinavano al corso base di Kubernetes senza sapere cosa fosse. .
Pertanto, per il secondo Slearma abbiamo creato un corso — anzi, non un corso vero e proprio, ma abbiamo realizzato alcuni capitoli su Docker. Dove abbiamo illustrato alcune delle nozioni più basilari, affinché le persone che partecipano all'intensivo non si sentissero escluse e comprendessero appieno cosa stesse accadendo.
Poi gli eventi si sono sviluppati all'incirca in questo modo. La quantità di materiale cresceva e non riusciva più a stare in 3 giorni. E arriva l'idea logica e ovvia: perché non creare un piccolo corso basato su ciò che trattiamo nel Slearma Base, da inviare a chi desidera vedere qualcosa su Docker prima dell'intensivo di Kubernetes?
Slearma Junior è, di fatto, l'unione di diversi corsi di base. Alla fine, il corso su Docker è diventato parte di Slearma Junior. Cioè, questa è una sorta di livello zero prima di e . E poi c'erano astrazioni davvero molto basilari.
A un certo punto, le persone hanno iniziato a chiedere: «Ragazzi, è tutto fantastico, ma dove posso leggere di più su cosa può fare Docker, come funziona e cosa rappresenta?». Così è nata l'idea di creare un , in modo che, da un lato, potesse essere indirizzato a tutte le persone che partecipano al Slyrm riguardo a Kubernetes, e dall'altro, per coloro a cui Kubernetes non interessa in questa fase. In modo che un professionista IT possa venire a vedere il nostro corso su Docker e iniziare il proprio percorso evolutivo partendo semplicemente da Docker puro. Affinché avessimo un corso completo e finito — e molti, dopo aver visto questo corso e lavorato per un po’ con Docker puro, sono cresciuti a quel livello in cui hanno già bisogno di Kubernetes o di un altro sistema di orchestrazione. E sono venuti, in particolare, da noi.
A volte viene posta la domanda: «A chi potrebbe non servire Kubernetes al momento?». Ma questa domanda non riguarda le persone, riguarda più le aziende. Qui bisogna capire che Kubernetes ha determinate casistiche in cui si adatta bene e compiti che risolve efficacemente, ma esistono anche scenari in cui l'uso di Kubernetes porta solo ulteriore dolore e difficoltà. Quindi, non dipende tanto dalle persone quanto da cosa e come le aziende stanno sviluppando.
Ad esempio, un terribile monolite legacy — probabilmente non è il caso di inserirlo in Kubernetes, perché causerebbe più problemi che vantaggi. Oppure, se si tratta di un progetto piccolo — con carichi leggeri o con risorse economiche limitate. Allora non ha senso portarlo in Kubernetes.
E in generale, come hanno già detto in molti, se ti stai chiedendo: «Ho bisogno di Kubernetes?», probabilmente non ne hai bisogno. Non ricordo chi lo abbia detto per primo, penso sia stato Pasha Selivanov. Sono totalmente d'accordo con questo. Devi crescere fino a Kubernetes — e quando cominci a capire che hai bisogno proprio di Kubernetes e che alla tua azienda serve, e che può aiutarti a risolvere certe problematiche, allora ha senso andare a studiare e capire come configurarlo bene, affinché il processo di transizione a Kubernetes non sia troppo doloroso.
Ci sono alcuni problemi minori e persino cose semplici, e anche non così semplici, che possono essere apprese da noi, invece di dover affrontare da soli le difficoltà e il dolore.
Molte aziende hanno inizialmente avuto un'infrastruttura semplice senza containerizzazione. Poi, quando è diventato difficile gestire tutto, sono passate ai Docker e, a un certo punto, sono arrivate alla situazione in cui all'interno di Docker e delle sue offerte si sentiva un certo limite. E hanno iniziato a guardarsi attorno, per scoprire quali sistemi potessero risolvere questi problemi e, in particolare, Kubernetes è uno di quei sistemi che permette di affrontare le sfide quando in puro Docker ci si sente stretti e manca funzionalità. Questo è un buon esempio di come le persone procedano gradualmente, capendo che questa tecnologia è insufficiente e passando al livello successivo. Usano qualcosa, nuovamente diventa insufficiente — e proseguono.
È una scelta consapevole — ed è molto positiva.
Vedo che il nostro sistema si sta strutturando molto bene, ad esempio, , anche attraverso videocorsi. Poi, dopo Docker, segue , poi , poi . Tutto si struttura in modo logico — la persona segue il percorso e acquisisce una professione completa.
In linea di principio, il pacchetto di corsi permette di coprire molti casi, davvero moderni. Ci sono ancora aree che rimangono grigie, spero che presto realizzeremo corsi che possano coprire queste aree grigie, in particolare inventeremo qualcosa sulla sicurezza. Perché sta diventando molto rilevante.
In breve, ci sono alcune aree grigie che sarebbe molto utile chiudere, affinché si possa avere un quadro davvero completo — e la gente possa arrivare, proprio come Kubernetes rappresenta un costruttore Lego, da cui si possono assemblare diverse cose, se qualcosa manca — integrare, lo stesso deve accadere con i nostri corsi, affinché le persone possano capire cosa di cui hanno bisogno, assemblando un certo puzzle, un certo costruttore dai nostri corsi.
Se ci si pone la domanda giusta e onesta: "A chi potrebbe tornare utile un corso attivo di Docker al momento?", allora:
- Agli studenti che cominciano a immergersi nella materia.
- Ai dipendenti del dipartimento di testing.
- In realtà, ci sono molte aziende dove ancora oggi, non solo non utilizzano Docker, ma nessuno ha mai sentito parlare di questa tecnologia e in generale non sanno come usarla. E conosco diverse grandi aziende a San Pietroburgo che si occupano di sviluppo da molti anni e continuano ad usare tecnologie obsolete. In particolare, per queste aziende e per gli ingegneri che vi lavorano, questo corso può essere molto interessante, perché, da un lato, consentirà di immergersi rapidamente in questa tecnologia e, dall'altro, non appena ci sono alcuni ingegneri che comprendono come funziona, possono portarla all'interno dell'azienda e sviluppare questa cultura e queste pratiche all'interno dell'organizzazione.
- A mio avviso, questo corso può essere utile anche a chi ha già lavorato con Docker, ma molto poco e più in modo superficiale, e ora si sta preparando a interagire in qualche modo con Kubernetes. Questo comporta alcune responsabilità, soprattutto se si hanno conoscenze molto superficiali su cosa sia Docker, come si avvia, ma non si sa come funzioni internamente, né cosa sia meglio fare o evitare. In questo caso, questo corso è ideale per sistematizzare e approfondire le proprie conoscenze.
Ma se le vostre conoscenze sono a livello: "Non so come scrivere correttamente i file Docker, ho un'idea di cosa siano i namespaces, come funzionano i contenitori e come siano realizzati a livello di sistema operativo" — allora non ha senso venire da noi, non imparerete nulla di nuovo e vi sentirete un po' delusi per i soldi e il tempo spesi.
Se dovessimo esprimere quali sono i vantaggi del nostro corso, diremmo che:
- Abbiamo cercato di strutturare questo corso con un numero sufficiente di casi pratici che vi permetteranno non solo di comprendere la parte teorica, ma anche di capire perché ne avete bisogno e come lo utilizzerete in futuro;
- Ci sono diverse sezioni che si incontrano molto raramente, e in generale non ci sono molti materiali su di esse. Si riferiscono all'interazione di Docker con il sistema operativo, in un modo un po' diverso. Quali meccanismi Docker ha preso dal sistema operativo per realizzare un sistema di containerizzazione — e questo fornisce una comprensione più profonda di tutta la questione dell'esecuzione dei container all'interno del sistema operativo Linux. Come funziona, come interagisce tra di loro all'interno del sistema operativo, all'esterno e così via.
È uno sguardo molto profondo, che non si vede spesso, e secondo me è molto importante. Se vuoi davvero comprendere bene qualsiasi tecnologia e capire cosa aspettarti da essa, devi almeno avere una visione generale di come funziona a basso livello.
Il nostro corso mostra e spiega come è strutturato dal punto di vista del sistema operativo. Da un lato, tutte le piattaforme di containerizzazione utilizzano gli stessi meccanismi del sistema operativo. Dall'altro lato, prendono ciò che esiste nel sistema operativo Linux, come Docker. Altri sistemi di containerizzazione non hanno inventato nulla di nuovo — hanno preso ciò che c'è già in Linux e hanno scritto solo un'interfaccia comoda che consente di richiamarlo, eseguirlo rapidamente o interagire con esso. Anche Docker è un’interfaccia non molto complessa tra il sistema operativo e la riga di comando, è un'utilità che consente di non dover scrivere chilometriche righe di comandi o del codice C per creare un container, ma di farlo semplicemente digitando un paio di righe nel terminale.
E in aggiunta, se parliamo specificamente di Docker, ciò che Docker ha davvero portato nel mondo IT sono gli standard. Come deve essere avviata un'applicazione, come deve funzionare, quali sono i requisiti per i log, quali sono i requisiti per la scalabilità e la configurazione dell'applicazione stessa.
In gran parte Docker è una questione di standard.
Gli standard si trasferiscono anche in Kubernetes — e lì ci sono esattamente gli stessi standard; se riesci a far funzionare bene la tua applicazione in Docker, ci sono il 99% di probabilità che funzioni altrettanto bene anche in Kubernetes.
Se sei interessato non solo a come è stato creato il corso Docker, e altri corsi, ma anche al corso stesso dal punto di vista pratico, allora
Saremo felici di vederti!
Fonte: habr.com
