Negli ultimi tempi, questi annunci hanno invaso Internet. Nonostante uno stipendio allettante, non si può non essere disturbati dal fatto che all'interno ci sia una vera assurdità. All'inizio si presume che "DevOps" e "ingegnere" possano essere in qualche modo uniti in una sola parola, e poi segue un elenco casuale di requisiti, parte dei quali è chiaramente copiato da un annuncio per sistemisti.
In questo post vogliamo parlare un po' di come siamo arrivati a questa situazione, cosa significa realmente DevOps e cosa fare adesso.
Si possono criticare questi annunci in tutti i modi, ma il fatto è che ci sono tanti posti di lavoro e il mercato funziona così al momento. Abbiamo organizzato una conferenza su DevOps e dichiariamo apertamente: “ — non è per gli ingegneri DevOps”. Qui a molti sembrerà strano e folle: perché delle persone che organizzano un evento commerciale vanno contro il mercato. Ora spiegheremo tutto.
Sulla cultura e i processi
Iniziamo col dire che DevOps non è una disciplina ingegneristica. È iniziato tutto perché la tradizionale divisione dei ruoli non funziona per la qualità dei prodotti. Quando i programmatori si limitano a programmare e non vogliono sentire nulla sul testing, il software è pieno di bug. Quando agli amministratori non importa come e perché è stato scritto il software, il supporto diventa un inferno.
Per esempio, la differenza tra l'approccio sistemistico e quello SRE alla gestione dei servizi . Interessanti ricerche sono state condotte nell'ambito — si vede che i migliori sviluppatori riescono in qualche modo a rilasciare nuove modifiche in produzione più velocemente di una volta all'ora. Inoltre, testano manualmente non più del 10% (come mostrato dal ). Come ci riescono? "Excel or die" – dice uno dei titoli del rapporto. Per una discussione dettagliata di queste statistiche nel contesto del testing, si può fare riferimento al keynote di Baruch Sadogursky alla nostra altra conferenza, Heisenbug.
“Quando tra i compagni non c'è accordo,
Nessun affare andrà bene,
E non ne verrà nulla, solo sofferenza.
Una volta il Cigno, il Granchio e la Luccio…”
Cosa ne pensate, quale parte dei web programmer capisce realmente in quali condizioni le loro applicazioni vengono eseguite in produzione? Quanti di loro si recheranno dagli amministratori di sistema per cercare di capire cosa succede in caso di caduta del database? E chi di loro si rivolgerà ai tester e chiederà di imparare a scrivere test in modo corretto? E poi ci sono i responsabili della sicurezza, i product manager, e un sacco di altre persone.
L'idea generale del DevOps è quella di ottimizzare l'interazione tra ruoli e dipartimenti. Questo si ottiene innanzitutto non con software sofisticati, ma attraverso la pratica della comunicazione. DevOps riguarda la cultura, la pratica, la metodologia e i processi. Non esiste una professione ingegneristica che possa rispondere a queste questioni.
Un circolo vizioso
Da dove viene allora la disciplina della «devops engineering»? Abbiamo una versione! Le idee del DevOps si sono rivelate buone — così buone da diventare vittime del loro stesso successo. Attorno a questo tema hanno iniziato a girare alcuni reclutatori ambigui e commercianti di persone, con una loro atmosfera particolare.
Immaginate: ieri a Chimki preparavate shawarma, e oggi siete già una figura importante, un senior recruiter. Qui c'è un intero processo di ricerca e selezione dei candidati, non è semplice, bisogna capire. Supponiamo che il capo dipartimento dica: trova uno specialista in X. A X aggiungiamo la parola «ingegnere», e la cosa è fatta. Serve un Linux? Beh, è sicuramente un ingegnere Linux, volete DevOps — ingegnere DevOps. L'offerta di lavoro non consiste solo nel titolo, ma dentro bisogna includere un certo testo. Il modo più semplice è inserire un insieme di parole chiave da Google, a seconda di quanta fantasia si ha. Il DevOps è composto da due parole — «Dev» e «Ops», quindi bisogna unire parole chiave relative a sviluppatori e amministratori, tutte insieme. Così nascono le offerte di lavoro che richiedono la conoscenza di 42 linguaggi di programmazione e 20 anni di utilizzo simultaneo di Kubernetes e Swarm. Uno schema di lavoro.
Così nella mente delle persone si è radicato l'immagine insensata e spietata di un supereroe «devops», che configurerà il deploy per tutti su Jenkins, e allora arriverà la felicità. Ah, se solo fosse così semplice. «E così si possono anche reclutare sysadmin», pensa l’HR, «è una parola alla moda, le parole chiave sono le stesse, dovrebbero abboccare».
La domanda genera offerta, e per tutte queste offerte ridicole si è riversato un numero strabiliante di amministratori di sistema che hanno capito: è possibile fare esattamente quel che si faceva prima, ma guadagnando molto di più, chiamandosi "DevOps". Come configuravi i server tramite SSH a mano, uno per uno, così continuerai a farlo, ma ora si tratta di una presunta pratica DevOps. È un fenomeno complesso, parzialmente legato alla sottovalutazione degli amministratori classici e al clamore attorno al DevOps, ma in generale — quel che è fatto, è fatto.
Dunque, abbiamo domanda e offerta. Un circolo vizioso che si alimenta da solo. Ecco cosa stiamo combattendo (inclusa la creazione della conferenza DevOops).
Naturalmente, oltre agli amministratori di sistema che si sono ribattezzati "DevOps", ci sono altri partecipanti — ad esempio, professionisti SRE o sviluppatori di Infrastructure-as-Code.
Cosa fanno realmente le persone in DevOps
Quindi, vuoi progredire nello studio e nell'applicazione delle pratiche DevOps. Ma come fare, in quale direzione guardare? Ovviamente, non è saggio seguire ciecamente le parole chiave popolari.
Se c'è lavoro, qualcuno deve occuparsene. Abbiamo già chiarito che non si tratta di "ingegneri DevOps", quindi chi? Sembra più corretto formulare questo non in termini di posizioni, ma in termini di specifici ambiti di lavoro.
Innanzitutto, puoi occuparti del cuore stesso di DevOps — processi e cultura. La cultura è un affare lento e difficile, e anche se tradizionalmente è di responsabilità dei dirigenti, in un modo o nell'altro coinvolge tutti, dai programmatori agli amministratori. Qualche mese fa, Tim Lister :
"La cultura è determinata dai valori fondamentali dell'organizzazione. Di solito le persone non se ne accorgono, ma noi, lavorando nella consulenza per molti anni, ci siamo abituati a notarlo. Entri in un'azienda e dopo pochi minuti inizi a sentire cosa sta succedendo. Noi chiamiamo questo 'aroma'. A volte questo aroma è davvero buono. Altre volte provoca nausea. (…) Non puoi cambiare la cultura finché non sono stati compresi i valori e le convinzioni che stanno alla base delle singole azioni. È facile osservare i comportamenti, mentre è difficile cercare le convinzioni. Il DevOps è proprio un ottimo esempio di come tutto diventa sempre più complesso."
C'è anche un aspetto tecnico della questione, naturalmente. Se il tuo nuovo codice arriva per il test dopo un mese, ma viene rilasciato solo dopo un anno, e accelerare tutto ciò non è fisicamente possibile, potresti non arrivare mai alle buone pratiche. Le buone pratiche sono supportate da buoni strumenti. Ad esempio, mantenendo a mente l'idea di Infrastructure-as-Code, puoi usare qualsiasi cosa, da AWS CloudFormation e Terraform a Chef-Ansible-Puppet. È tutto da sapere e da saper fare, e questo è già un vero e proprio discipline ingegneristica. È importante non confondere le cause con gli effetti: all'inizio lavori secondo i principi SRE e solo in seguito concretizzi questi principi in specifiche soluzioni tecniche. Inoltre, SRE è una metodologia molto complessa, che non parla di come configurare Jenkins, ma di cinque principi fondamentali:
- Miglioramento dell'interazione tra ruoli e dipartimenti
- Accettazione degli errori come parte integrante del lavoro
- Attuazione graduale dei cambiamenti
- Utilizzo di tool e automazione
- Misurazione di tutto ciò che può essere misurato
Non è solo un insieme di affermazioni, ma un concreto . Ad esempio, lungo il percorso di accettazione degli errori, sarà necessario affrontare i rischi, misurare la disponibilità e l'indisponibilità dei servizi utilizzando qualcosa come SLI () e SLO (), imparare a scrivere postmortem e fare in modo che non sia spaventoso scriverli.
Nella disciplina SRE, l'uso degli strumenti è solo una parte del successo, sebbene importante. Dobbiamo costantemente svilupparci dal punto di vista tecnico, osservare cosa succede nel mondo e come possiamo applicarlo nel nostro lavoro.
A sua volta, le soluzioni Cloud Native sono diventate molto popolari. Secondo la moderna comprensione della Cloud Native Computing Foundation, le tecnologie Cloud Native consentono alle organizzazioni di sviluppare e lanciare applicazioni scalabili in ambienti dinamici moderni come cloud pubblici, privati e ibridi. Un esempio possono essere i container, i service mesh, i microservizi, l'infrastruttura immutabile e le API dichiarative. Tutte queste tecniche consentono ai sistemi a bassa interconnessione di rimanere elastici, gestibili e ben monitorati. Una buona automazione consente agli ingegneri di apportare grandi cambiamenti frequentemente e con risultati prevedibili, senza trasformarlo in un lavoro estenuante. Tutto ciò è supportato da un stack di strumenti ben noti, come Docker e Kubernetes.
Questa definizione piuttosto complessa e articolata è legata al fatto che anche il campo è piuttosto difficile. Da un lato si afferma che le nuove modifiche a questo sistema devono essere aggiunte in modo relativamente semplice. Dall'altro, per capire come creare un certo ambiente containerizzato, in cui i servizi poco interconnessi vivono su un'infrastruttura software-defined e vengono forniti attraverso un CI/CD continuo, e costruire intorno a tutto questo pratiche DevOps, è necessario avere un certo livello di esperienza.
Cosa fare con tutto ciò
Ognuno affronta questi problemi a modo suo: ad esempio, è possibile pubblicare annunci di lavoro normali per rompere il circolo vizioso. Si può cercare di capire cosa significano parole come DevOps e Cloud Native e usarle in modo corretto e pertinente. Si può progredire nel DevOps e dimostrare con il proprio esempio approcci corretti.
Noi stiamo organizzando una conferenza , che offre l'opportunità di approfondire argomenti di cui abbiamo appena parlato. A tal fine, ci sono diversi gruppi di relazioni:
- Processi e cultura;
- Site Reliability Engineering;
- Cloud Native;
Come scegliere dove andare? C'è un punto sottile. Da un lato, il DevOps riguarda l'interazione, e ci piacerebbe molto che partecipaste a presentazioni di vari settori. D'altra parte, se siete un responsabile dello sviluppo che è venuto alla conferenza per concentrarsi su un compito specifico, non c'è alcun problema — chiaramente, sarà il settore sui processi e sulla cultura. Non dimenticate che dopo la conferenza avrete accesso alle registrazioni (dopo aver compilato il modulo di feedback), quindi potrete sempre visualizzare presentazioni meno importanti in seguito.
È evidente che durante la conferenza non potete partecipare a tre tracce contemporaneamente, quindi formiamo il programma in modo tale che in ogni slot temporale ci siano argomenti per tutti i gusti.
Rimane solo capire cosa fare se siete un ingegnere DevOps! Innanzitutto, provate a definire cosa fate realmente. Di solito, questo termine viene usato per indicare:
- Sviluppatori che si occupano di infrastruttura. Per voi, i gruppi di presentazioni su SRE e Cloud Native saranno i più appropriati.
- Amministratori di sistema. Qui è più complicato. DevOops non riguarda l'amministrazione di sistema. Fortunatamente, ci sono molte conferenze, libri, articoli, video su internet ecc. dedicati all'amministrazione di sistema. D'altra parte, se siete interessati a svilupparvi in termini di comprensione della cultura e dei processi, studio delle tecnologie cloud e dettagli della vita con Cloud Native, saremo felici di vedervi! Riflettete su questo: se lavorate come amministratori, e dopo? Per non trovarvi improvvisamente in una situazione spiacevole, è utile iniziare a studiare già ora.
C'è un'altra possibilità: voi insistete e continuate a sostenere di essere proprio un ingegnere DevOps e non in altro modo, qualunque cosa significhi. Allora dobbiamo deludervi, DevOops non è una conferenza per ingegneri DevOps!
Diapositiva da a Monaco
DevOops 2020 Mosca si terrà il 29-30 aprile a Mosca, i biglietti sono già disponibili .
Inoltre, potete fino all'8 febbraio. Si prega di notare che durante la compilazione del modulo dovete selezionare il pubblico di destinazione al quale la vostra presentazione porterà maggiori benefici (una sorpresa è nascosta all'interno dell'elenco).
Fonte: habr.com
