Negli ultimi tempi, questi annunci hanno invaso il web. Nonostante lo stipendio allettante, non si può fare a meno di notare che dentro ci sono delle vere assurdità. Inizialmente si presume che "DevOps" e "ingegnere" possano essere uniti in un'unica parola, e successivamente si presenta un elenco casuale di requisiti, molti dei quali sembrano chiaramente copiati da un annuncio di lavoro per un amministratore di sistema.
In questo post vogliamo discutere un po' su come siamo arrivati a questo punto, cosa significa davvero DevOps e cosa fare ora con esso.
Queste offerte di lavoro possono essere criticate in vari modi, ma il fatto rimane: ce ne sono molte, e così è strutturato il mercato al momento. Abbiamo organizzato una conferenza DevOps e dichiariamo apertamente: “ — non per gli ingegneri DevOps”. Alcuni troveranno strano e bizzarro che persone che organizzano un evento puramente commerciale si oppongano al mercato. Ora spiegheremo tutto.
Sulla cultura e i processi
Cominciamo col dire che DevOps non è una disciplina ingegneristica. Tutto è iniziato con il fatto che la storicizzata divisione dei ruoli non funziona per la qualità dei prodotti. Quando i programmatori si dedicano esclusivamente alla programmazione senza voler sapere nulla sul collaudo, il software è pieno di bug. Quando agli amministratori non importa come e perché è stato scritto il software, il supporto si trasforma in un incubo.
Ad esempio, descrivendo la differenza tra l'approccio degli amministratori di sistema e quello del SRE alla gestione dei servizi . Sono stati condotti interessanti studi nell'ambito del — è evidente che i migliori sviluppatori riescono in qualche modo a rilasciare nuove modifiche in produzione più frequentemente di una volta all'ora. Essi stessi non testano manualmente più del 10% (questo è evidente dai dati ). Come ci riescono? "Excel or die" – dice uno dei titoli del rapporto. Per un'analisi dettagliata di questa statistica in relazione ai test, si può fare riferimento alla keynote di Baruch Sadogursky alla nostra altra conferenza, Heisenbug.
"Quando tra compagni non c'è accordo,
il loro lavoro non andrà a buon fine,
e da esso non nascerà qualcosa di buono, solo sofferenza."
Una volta, il Cigno, il Granchio e la Rana...
Cosa ne pensate, qual è la parte dei programmatori web che capisce davvero in quali condizioni operano le loro applicazioni in produzione? Quanti di loro andranno dagli amministratori per cercare di capire cosa succede in caso di caduta del database? E chi tra loro andrà dai tester e chiederà di insegnare come scrivere correttamente i test? E ci sono anche i responsabili della sicurezza, i product manager e un sacco di altre persone.
L'idea principale del DevOps è quella di migliorare la comunicazione tra ruoli e reparti. Questo viene raggiunto principalmente non tramite qualche software sofisticato, ma attraverso la pratica della comunicazione. DevOps riguarda la cultura, la pratica, la metodologie e i processi. Non esiste una professione ingegneristica che possa rispondere a queste domande.
Un circolo vizioso
Dove è nata allora la disciplina del "DevOps Engineering"? Abbiamo una nostra teoria! Le idee del DevOps si sono rivelate così buone da diventare vittime del loro stesso successo. Attorno a questo tema si sono radunati reclutatori ambigui e mercanti di persone, che hanno creato un'atmosfera tutta loro.
Immaginate: ieri eravate a Khimki a preparare kebab, e oggi siete già un grande professionista, senior recruiter. Qui c'è un intero processo di ricerca e selezione dei candidati, non è affatto semplice, bisogna capirlo. Supponiamo che il capo dica: trova uno specialista in X. Aggiungiamo la parola «ingegnere» a X, e il gioco è fatto. Serve Linux? Beh, questo è sicuramente un ingegnere Linux, se vuoi DevOps — ingegnere DevOps. Un annuncio di lavoro non consiste solo nel titolo, ma è necessario includere anche un testo. La cosa più facile è scrivere un insieme di parole chiave da Google, a seconda della fantasia di ciascuno. DevOps è composto da due parole — «Dev» e «Ops», quindi bisogna unire parole chiave relative a sviluppatori e amministratori, tutte insieme. Così nascono annunci che richiedono la conoscenza di 42 linguaggi di programmazione e 20 anni di esperienza con Kubernetes e Swarm contemporaneamente. È uno schema di lavoro.
Così nella mente delle persone si è radicata l'immagine insensata e spietata di una sorta di supereroe «DevOps» che configurerà a tutti il deployment su Jenkins, e arriverà la felicità. Ah, se solo fosse così semplice. «E poi si possono anche cercare sistemisti, — pensa l’HR, — è una parola alla moda, le stesse parole chiave, devono abboccare».
La domanda genera offerta, e a tutte queste strambe opportunità di lavoro è accorsa una folla di sistemisti che hanno capito: si può fare esattamente quello che si faceva prima, ma guadagnando molto di più, chiamandosi "DevOps". Come configuravi i server manualmente tramite SSH, così continuerai a farlo, ma ora questo è considerato un presunto approccio DevOps. Si tratta di un fenomeno complesso, parzialmente legato alla sottovalutazione degli amministratori di sistema tradizionali e al clamore attorno a DevOps, ma in generale — ciò che è fatto, è fatto.
Quindi, abbiamo domanda e offerta. Un circolo vizioso che si autoalimenta. È su questo che stiamo combattendo (in parte creando la conferenza DevOops).
Naturalmente, oltre agli amministratori di sistema che si sono rinominati "DevOps", ci sono anche altri partecipanti — come i professionisti SRE o gli sviluppatori di Infrastructure-as-Code.
Cosa fanno realmente le persone nel DevOps
Quindi, vuoi approfondire l'apprendimento e l'applicazione delle pratiche DevOps. Ma come fare, in quale direzione orientarsi? Ovviamente, non è saggio seguire ciecamente le parole chiave popolari.
Se c'è lavoro da fare, qualcuno deve farlo. Abbiamo già stabilito che non si tratta di "DevOps engineer", quindi chi sono? Sembra più appropriato formulare la questione non in termini di posizioni, ma in termini di specifiche aree di lavoro.
Innanzitutto, si può lavorare al cuore del DevOps: processi e cultura. La cultura è un processo lungo e complesso e, sebbene tradizionalmente sia sotto la responsabilità dei leader, in questo sono coinvolti tutti, dai programmatori agli amministratori. Qualche mese fa, Tim Lister :
«La cultura è definita dai valori fondamentali dell'organizzazione. Di solito, le persone non se ne accorgono, ma noi, avendo lavorato nella consulenza per molti anni, abbiamo imparato a notarlo. Entri in un'azienda e, dopo pochi minuti, inizi a percepire ciò che accade. Lo chiamiamo 'profumo'. A volte questo profumo è davvero buono. A volte provoca nausea. (…) Non puoi cambiare la cultura prima di aver compreso i valori e le convinzioni che stanno dietro a determinate azioni. È facile osservare il comportamento, ma è difficile cercare le convinzioni. Il DevOps è un ottimo esempio di come tutto diventi sempre più complesso.»
C'è anche una componente tecnica nella questione, ovviamente. Se il tuo nuovo codice arriva per il testing dopo un mese, ma viene rilasciato solo un anno dopo, e non è fisicamente possibile accelerare il tutto, potresti non arrivare mai alle buone pratiche. Le buone pratiche sono supportate da buoni strumenti. Ad esempio, tenendo a mente l'idea di Infrastructure-as-Code, puoi utilizzare qualsiasi cosa, da AWS CloudFormation e Terraform fino a Chef-Ansible-Puppet. È importante conoscere e padroneggiare tutto questo, e questo è già un vero e proprio campo ingegneristico. È fondamentale non confondere la causa con gli effetti: prima lavori sui principi SRE e solo dopo realizzi questi principi in soluzioni tecniche concrete. Inoltre, SRE è una metodologia molto complessa, che non tratta solo di come configurare Jenkins, ma di cinque principi fondamentali:
- Migliorare la collaborazione tra ruoli e dipartimenti
- Accettare gli errori come parte integrante del lavoro
- Implementare i cambiamenti progressivamente
- Utilizzare strumenti e automazione
- Misurare tutto ciò che può essere misurato
Non è semplicemente un insieme di affermazioni, ma una vera e propria . 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 post mortem e fare in modo che non sia spaventoso farlo.
Nella disciplina SRE, l'uso degli strumenti è solo una parte del successo, sebbene non meno importante. Dobbiamo svilupparci costantemente sul piano tecnico, osservare cosa accade nel mondo e come possiamo applicarlo nel nostro lavoro.
D'altra parte, ora stanno guadagnando molta popolarità le soluzioni Cloud Native. Secondo la comprensione attuale della Cloud Native Computing Foundation, le tecnologie Cloud Native consentono alle organizzazioni di sviluppare e distribuire applicazioni scalabili in ambienti dinamici moderni, come i cloud pubblici, privati e ibride. Un esempio possono essere i container, i service mesh, i microservizi, l'infrastruttura immutabile e le API dichiarative. Tutte queste tecniche permettono a sistemi debolmente accoppiati di rimanere elastici, gestibili e ben osservabili. Una buona automazione consente agli ingegneri di apportare grandi modifiche frequentemente e con risultati prevedibili, senza trasformarlo in un lavoro infernale. Tutto questo è supportato da un ecosistema di strumenti ben noti, come Docker e Kubernetes.
Questa definizione piuttosto complessa e articolata è legata al fatto che il settore stesso è abbastanza difficile. Da un lato, si afferma che le nuove modifiche a questo sistema dovrebbero essere aggiunte in modo relativamente semplice. Dall'altro lato, per capire come creare un ambiente containerizzato in cui servizi debolmente accoppiati operano su un'infrastruttura software-defined e vengono forniti attraverso un CI/CD continuo, e costruire pratiche DevOps attorno a tutto questo, bisogna affrontare molte sfide.
Cosa fare con tutto questo
Ognuno affronta queste problematiche a modo suo: ad esempio, si possono pubblicare annunci di lavoro normali per rompere il circolo vizioso. Si può cercare di comprendere il significato di termini come DevOps e Cloud Native e usarli in modo corretto e pertinente. Si può progredire nel DevOps e dimostrare, con il proprio esempio, approcci adeguati.
Stiamo organizzando una conferenza , che offre l'opportunità di approfondire le questioni di cui abbiamo appena parlato. A tale scopo, ci sono diversi gruppi di relazioni:
- Processi e cultura;
- Site Reliability Engineering;
- Cloud Native;
Come scegliere dove andare? C'è un aspetto sottile. Da un lato, il DevOps riguarda l'interazione, e ci piacerebbe che partecipaste a presentazioni di diverse aree. D'altra parte, se sei un responsabile dello sviluppo che partecipa alla conferenza per concentrarsi su un compito specifico, nessuno ti limita: ovviamente, questo sarà il blocco sui processi e sulla cultura. Ricorda che dopo la conferenza avrai accesso alle registrazioni (dopo aver compilato il modulo di feedback), quindi potrai sempre rivedere le presentazioni meno importanti in un secondo momento.
È chiaro che alla conferenza non puoi partecipare a tre sessioni contemporaneamente, quindi strutturiamo il programma in modo che in ogni slot temporale ci siano temi per tutti i gusti.
Resta solo da capire cosa fare se sei un ingegnere DevOps! Per prima cosa, prova a definire di cosa ti occupi realmente. Di solito, questo termine viene usato per riferirsi a:
- Sviluppatori che si occupano dell'infrastruttura. Per te, i gruppi di presentazioni su SRE e Cloud Native saranno i più adatti.
- Amministratori di sistema. Qui è più complesso. DevOops non riguarda l'amministrazione di sistema. Fortunatamente, ci sono molte ottime conferenze, libri, articoli, video su internet, e così via sull'argomento dell'amministrazione di sistema. D'altra parte, se sei interessato a sviluppare una comprensione della cultura e dei processi, all'apprendimento delle tecnologie cloud e ai dettagli della vita con Cloud Native, saremo felici di vederti! Pensa a questo: stai facendo l'amministratore, e poi? Per evitare di trovarti in una situazione scomoda, è meglio iniziare a studiare già ora.
C'è un'altra opzione: perseveri e continui ad affermare di essere un ingegnere DevOps e niente altro, qualunque cosa significhi. Allora saremo costretti a deluderti, DevOops non è una conferenza per ingegneri DevOps!
Slide da a Monaco
DevOops 2020 Moscow si terrà dal 29 al 30 aprile a Mosca, i biglietti sono già disponibili .
Inoltre, puoi entro l'8 febbraio. Tieni presente che, compilando il modulo, devi selezionare il pubblico target che trarrà maggiore beneficio dalla tua relazione (una sorpresa è nascosta nella lista).
Fonte: habr.com
