Recentemente, tali annunci pubblicitari hanno inondato Internet. Nonostante il piacevole stipendio, non si può fare a meno di essere imbarazzati dal fatto che all'interno sia scritta un'eresia selvaggia. Inizialmente si presuppone che "DevOps" e "ingegnere" possano in qualche modo essere riuniti in un'unica parola, quindi viene visualizzato un elenco casuale di requisiti, alcuni dei quali sono chiaramente copiati dal posto vacante di amministratore di sistema.
In questo post vorrei parlare un po' di come siamo arrivati a questo punto della vita, di cos'è veramente DevOps e di cosa farne adesso.
Tali posti vacanti possono essere condannati in ogni modo possibile, ma resta il fatto: ce ne sono molti, ed è così che funziona il mercato al momento. Abbiamo tenuto una conferenza devops e dichiariamo apertamente: “ - non per gli ingegneri DevOps." A molti sembrerà strano e assurdo: perché le persone che fanno un evento completamente commerciale vanno contro il mercato. Ora spiegheremo tutto.
A proposito di cultura e processi
Partiamo dal fatto che DevOps non è una disciplina ingegneristica. Tutto è iniziato con il fatto che la divisione dei ruoli storicamente stabilita non funziona per la qualità dei prodotti. Quando i programmatori si limitano a programmare, ma non vogliono sentire nulla di test, il software è pieno di bug. Quando agli amministratori non interessa come o perché viene scritto il software, il supporto si trasforma in un inferno.
Ad esempio, descrivendo la differenza tra un amministratore di sistema e un approccio SRE alla gestione dei servizi . All'interno sono stati condotti studi interessanti – è chiaro che i migliori sviluppatori riescono in qualche modo a implementare nuove modifiche in produzione più velocemente di una volta all’ora. Testano con le mani non più del 10% (questo può essere visto da ). Come fanno? "Eccellere o morire" recita uno dei titoli del rapporto. Per una discussione dettagliata di queste statistiche nel contesto dei test, si può fare riferimento al keynote di Baruch Sadogursky all'altra nostra conferenza, Heisenbug.
“Quando non c’è accordo tra compagni,
Non funzioneranno bene.
E non ne uscirà, solo farina.
C'erano una volta un cigno, un gambero e un luccio..."
Quale parte dei programmatori web pensi che comprenda veramente le condizioni in cui le loro applicazioni vengono utilizzate in produzione? Quanti di loro si rivolgeranno agli amministratori e cercheranno di capire cosa accadrà se il database si blocca? E chi di loro andrà dai tester e chiederà loro di insegnare loro come scrivere correttamente i test? E ci sono anche guardie di sicurezza, product manager e un sacco di altre persone.
L’idea generale di DevOps è creare collaborazione tra ruoli e dipartimenti. Innanzitutto, ciò non si ottiene con un software abilmente configurato, ma con la pratica della comunicazione. DevOps riguarda cultura, pratiche, metodologia e processi. Non esiste una specialità ingegneristica che possa rispondere a queste domande.
Circolo vizioso
Da dove nasce allora la disciplina del “devops engineering”? Abbiamo una versione! Le idee DevOps erano buone, così buone che sono diventate vittime del loro stesso successo. Alcuni loschi reclutatori e trafficanti di esseri umani, che hanno la loro atmosfera, hanno iniziato a girare intorno a questo argomento.
Immagina: ieri stavi preparando shawarma a Khimki, e oggi sei già un grande uomo, un reclutatore senior. C'è un intero processo di ricerca e selezione dei candidati, non tutto è facile, devi capire. Mettiamo il caso che il capo dipartimento dica: trova uno specialista in X. Assegniamo a X la parola “ingegnere” e il gioco è fatto. Hai bisogno di Linux? Bene, questo è sicuramente un ingegnere Linux, se vuoi DevOps, allora un ingegnere DevOps. Il posto vacante non consiste solo nel titolo, ma anche nel testo che deve essere inserito. Il modo più semplice è inserire una serie di parole chiave da Google, a seconda della tua immaginazione. DevOps è composto da due parole: "Dev" e "Ops", il che significa che dobbiamo incollare insieme le parole chiave relative a sviluppatori e amministratori, tutte in un'unica pila. Ecco come appaiono i posti vacanti sulla competenza in 42 linguaggi di programmazione e 20 anni di utilizzo simultaneo di Kubernetes e Swarm. Diagramma di funzionamento.
È così che si è radicata nella mente delle persone l'immagine priva di significato e spietata di un certo supereroe "devops", che configurerà tutti per schierarsi con Jenkins e la felicità arriverà. Oh, se solo fosse tutto così semplice. “Ed è anche così che si possono dare la caccia agli amministratori di sistema”, pensa HR, “è una parola di moda, le parole chiave sono le stesse, dovrebbero abboccare”.
La domanda crea offerta e tutti questi posti vacanti sono stati riempiti da un numero folle di amministratori di sistema che hanno capito: puoi fare tutto come prima, ma ottenere molto di più chiamandoti "devops". Proprio come hai configurato manualmente i server tramite SSH uno alla volta, continuerai a configurarli, ma ora questa è presumibilmente una pratica devops. Questo è un fenomeno complesso, in parte legato alla sottovalutazione degli amministratori classici e al clamore attorno a DevOps, ma in generale, quello che è successo, è successo.
Quindi abbiamo domanda e offerta. Un circolo vizioso che si autoalimenta. Questo è ciò contro cui stiamo combattendo (anche creando la conferenza DevOops).
Naturalmente, oltre agli amministratori di sistema che si sono rinominati "devops", ci sono altri partecipanti, ad esempio SRE professionisti o sviluppatori di Infrastructure-as-Code.
Cosa fanno le persone in DevOps (davvero)
Quindi vuoi andare avanti nell'apprendimento e nell'applicazione delle pratiche DevOps. Ma come farlo, in quale direzione guardare? Ovviamente, non dovresti fare affidamento ciecamente sulle parole chiave più popolari.
Se c'è un lavoro, qualcuno dovrebbe farlo. Abbiamo già scoperto che questi non sono “ingegneri devops”, allora chi sono? Sembra più corretto formularlo non in termini di posizioni, ma in termini di aree di lavoro specifiche.
Innanzitutto, puoi affrontare il cuore di DevOps: processi e cultura. La cultura è un affare lento e difficile e, sebbene sia tradizionalmente responsabilità dei manager, tutti sono coinvolti in un modo o nell'altro, dai programmatori agli amministratori. Un paio di mesi fa Tim Lister :
“La cultura è determinata dai valori fondamentali dell’organizzazione. Di solito le persone non se ne accorgono, ma avendo lavorato per tanti anni nella consulenza, siamo abituati a notarlo. Entri in un'azienda e letteralmente in pochi minuti inizi a sentire cosa sta succedendo. Lo chiamiamo "sapore". A volte questo profumo è davvero buono. A volte provoca nausea. (...) Non è possibile cambiare una cultura finché non si comprendono i valori e le convinzioni che stanno dietro alle azioni specifiche. Il comportamento è facile da osservare, ma la ricerca delle credenze è difficile. DevOps è solo un ottimo esempio di come le cose stiano diventando sempre più complesse”.
Naturalmente c’è anche una parte tecnica della questione. Se il tuo nuovo codice viene testato in un mese, ma viene rilasciato solo un anno dopo, ed è fisicamente impossibile accelerare il tutto, potresti non essere all’altezza delle buone pratiche. Le buone pratiche sono supportate da buoni strumenti. Ad esempio, tenendo presente l'idea di Infrastructure-as-Code, puoi utilizzare qualsiasi cosa, da AWS CloudFormation e Terraform a Chef-Ansible-Puppet. Bisogna sapere ed essere in grado di fare tutto questo, e questa è già una disciplina abbastanza ingegneristica. È importante non confondere causa con effetto: prima si lavora secondo i principi della SRE e solo successivamente si implementano questi principi sotto forma di alcune soluzioni tecniche specifiche. Allo stesso tempo, SRE è una metodologia molto completa che non spiega come impostare Jenkins, ma cinque principi di base:
- Miglioramento della comunicazione tra ruoli e dipartimenti
- Accettare gli errori come parte integrante del lavoro
- Apportare modifiche gradualmente
- Utilizzo di strumenti e altre automazioni
- Misurare tutto ciò che può essere misurato
Questo non è solo un insieme di affermazioni, ma uno specifico . Ad esempio, nel percorso per accettare gli errori, dovrai comprendere i rischi, misurare la disponibilità e l'indisponibilità dei servizi utilizzando qualcosa come SLI () e SLO (), impara a scrivere autopsie e fai in modo che scriverle non sia spaventoso.
Nella disciplina SRE, l’uso degli strumenti è solo una parte del successo, sebbene importante. Dobbiamo svilupparci costantemente dal punto di vista tecnico, guardare cosa sta succedendo nel mondo e come può essere applicato nel nostro lavoro.
A loro volta, le soluzioni Cloud Native sono ormai diventate molto popolari. Come definito oggi dalla Cloud Native Computing Foundation, le tecnologie Cloud Native consentono alle organizzazioni di sviluppare ed eseguire applicazioni scalabili negli ambienti dinamici di oggi, come cloud pubblici, privati e ibridi. Gli esempi includono contenitori, mesh di servizi, microservizi, infrastruttura immutabile e API dichiarative. Tutte queste tecniche consentono ai sistemi liberamente accoppiati di rimanere elastici, gestibili e altamente osservabili. Una buona automazione consente agli ingegneri di apportare grandi modifiche frequentemente e con risultati prevedibili senza renderlo un compito ingrato. Tutto questo è supportato da una serie di strumenti noti come Docker e Kubernetes.
Questa definizione piuttosto complicata e ampia è dovuta al fatto che l'area è anche piuttosto complessa. Da un lato si sostiene che le nuove modifiche a questo sistema dovrebbero essere apportate in modo molto semplice. D'altro canto, capire come creare una sorta di ambiente containerizzato in cui i servizi liberamente accoppiati risiedono su un'infrastruttura definita dal software e vengono forniti lì utilizzando CI/CD continui e costruire pratiche DevOps attorno a tutto ciò: tutto ciò richiede di più di uno mangia il cane.
Cosa fare con tutto questo
Ognuno risolve questi problemi a modo suo: ad esempio, puoi pubblicare normali posti vacanti per spezzare il circolo vizioso. Puoi capire cosa significano parole come DevOps e Cloud Native e usarle correttamente e al punto. Puoi sviluppare in DevOps e dimostrare gli approcci giusti con il tuo esempio.
Stiamo facendo una conferenza , che offre l'opportunità di approfondire le cose di cui abbiamo appena parlato. A questo scopo esistono diversi gruppi di report:
- Processi e cultura;
- Ingegneria dell'affidabilità del sito;
- Nativo del cloud;
Come scegliere dove andare? C'è un punto sottile qui. Da un lato, DevOps riguarda l'interazione e vogliamo davvero che tu partecipi alle presentazioni da diversi blocchi. D'altra parte, se sei un responsabile dello sviluppo che è venuto alla conferenza per concentrarsi su un compito specifico, nessuno ti limiterà: ovviamente questo sarà un blocco sui processi e sulla cultura. Non dimenticare che avrai le registrazioni dopo la conferenza (dopo aver compilato il modulo di feedback), così potrai sempre guardare le presentazioni meno importanti in seguito.
Ovviamente al convegno in sé non si può andare su tre binari contemporaneamente, quindi organizziamo il programma in modo tale che ogni fascia oraria abbia argomenti per tutti i gusti.
Non resta che capire cosa fare se sei un ingegnere DevOps! Per prima cosa, prova a determinare cosa fai effettivamente. Di solito a loro piace chiamare questa parola:
- Sviluppatori che lavorano sulle infrastrutture. I gruppi di report su SRE e Cloud Native sono più adatti a te.
- Amministratori di sistema. Qui è più complicato. DevOops non riguarda l'amministrazione del sistema. Fortunatamente su Internet si trovano moltissime conferenze, libri, articoli, video ecc. eccellenti sul tema dell'amministrazione di sistema. D'altra parte, se sei interessato a svilupparti in termini di comprensione della cultura e dei processi, di conoscere le tecnologie cloud e i dettagli della vita con Cloud Native, allora ci piacerebbe vederti! Pensa a questo: ti occupi di amministrazione, e poi cosa farai? Per evitare di ritrovarti improvvisamente in una situazione spiacevole, dovresti imparare ora.
C'è un'altra opzione: persisti e continui a sostenere di esserlo in particolare un ingegnere DevOps e nient'altro, qualunque cosa significhi. Allora dobbiamo deludervi, DevOops non è una conferenza per ingegneri DevOps!
Scorri da a Monaco di Baviera
DevOops 2020 Mosca si terrà il 29-30 aprile a Mosca, i biglietti sono già disponibili .
In alternativa, puoi fino all'8 febbraio. Tieni presente che durante la compilazione del modulo, devi selezionare il pubblico di destinazione che trarrà maggiori benefici dal tuo rapporto (c'è una sorpresa sepolta all'interno della lista).
Fonte: habr.com