{"id":53925,"date":"2019-12-13T00:00:00","date_gmt":"2019-12-12T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/devops-inzhenerov-ne-sushhestvuet-kto-togda-sushhestvuet-i-chto-s-etim-delat"},"modified":"2020-02-18T14:01:52","modified_gmt":"2020-02-18T11:01:52","slug":"devops-inzhenerov-ne-sushhestvuet-kto-togda-sushhestvuet-i-chto-s-etim-delat","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/devops-inzhenerov-ne-sushhestvuet-kto-togda-sushhestvuet-i-chto-s-etim-delat","title":{"rendered":"Gli ingegneri DevOps non esistono. Chi esiste allora e cosa fare al riguardo?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Gli<\/p>\n

<\/p>\n

Negli ultimi tempi, questi annunci hanno invaso il web. Nonostante lo stipendio allettante, non si pu\u00f2 fare a meno di notare che dentro ci sono delle vere assurdit\u00e0. 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.<\/p>\n

<\/p>\n

In questo post vogliamo discutere un po' su come siamo arrivati a questo punto, cosa significa davvero DevOps e cosa fare ora con esso.<\/p>\n

<\/p>\n

Queste offerte di lavoro possono essere criticate in vari modi, ma il fatto rimane: ce ne sono molte, e cos\u00ec \u00e8 strutturato il mercato al momento. Abbiamo organizzato una conferenza DevOps e dichiariamo apertamente: \u201cDevOops<\/a><\/noindex> \u2014 non per gli ingegneri DevOps\u201d. Alcuni troveranno strano e bizzarro che persone che organizzano un evento puramente commerciale si oppongano al mercato. Ora spiegheremo tutto.<\/p>\n

<\/a><\/noindex><\/p>\n

Sulla cultura e i processi<\/h2>\n

<\/p>\n

Cominciamo col dire che DevOps non \u00e8 una disciplina ingegneristica. Tutto \u00e8 iniziato con il fatto che la storicizzata divisione dei ruoli non funziona per la qualit\u00e0 dei prodotti. Quando i programmatori si dedicano esclusivamente alla programmazione senza voler sapere nulla sul collaudo, il software \u00e8 pieno di bug. Quando agli amministratori non importa come e perch\u00e9 \u00e8 stato scritto il software, il supporto si trasforma in un incubo. <\/p>\n

<\/p>\n

Ad esempio, descrivendo la differenza tra l'approccio degli amministratori di sistema e quello del SRE alla gestione dei servizi inizia il famoso Google SRE Book<\/a><\/noindex>. Sono stati condotti interessanti studi nell'ambito del sondaggio DORA<\/a><\/noindex> \u2014 \u00e8 evidente che i migliori sviluppatori riescono in qualche modo a rilasciare nuove modifiche in produzione pi\u00f9 frequentemente di una volta all'ora. Essi stessi non testano manualmente pi\u00f9 del 10% (questo \u00e8 evidente dai dati del DORA dell'anno scorso<\/a><\/noindex>). Come ci riescono? \"Excel or die\" \u2013 dice uno dei titoli del rapporto. Per un'analisi dettagliata di questa statistica in relazione ai test, si pu\u00f2 fare riferimento alla keynote di Baruch Sadogursky \"Abbiamo DevOps. Licenziamo tutti i tester\"<\/a><\/noindex> alla nostra altra conferenza, Heisenbug.<\/p>\n

<\/p>\n

\"Quando tra compagni non c'\u00e8 accordo,
\nil loro lavoro non andr\u00e0 a buon fine,
\ne da esso non nascer\u00e0 qualcosa di buono, solo sofferenza.\"
\nUna volta, il Cigno, il Granchio e la Rana...<\/p><\/blockquote>\n

Cosa ne pensate, qual \u00e8 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\u00e0 dai tester e chieder\u00e0 di insegnare come scrivere correttamente i test? E ci sono anche i responsabili della sicurezza, i product manager e un sacco di altre persone.<\/p>\n

<\/p>\n

L'idea principale del DevOps \u00e8 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.<\/p>\n

<\/p>\n

Un circolo vizioso<\/h2>\n

<\/p>\n

Dove \u00e8 nata allora la disciplina del \"DevOps Engineering\"? Abbiamo una nostra teoria! Le idee del DevOps si sono rivelate cos\u00ec 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.<\/p>\n

<\/p>\n

Immaginate: ieri eravate a Khimki a preparare kebab, e oggi siete gi\u00e0 un grande professionista, senior recruiter. Qui c'\u00e8 un intero processo di ricerca e selezione dei candidati, non \u00e8 affatto semplice, bisogna capirlo. Supponiamo che il capo dica: trova uno specialista in X. Aggiungiamo la parola \u00abingegnere\u00bb a X, e il gioco \u00e8 fatto. Serve Linux? Beh, questo \u00e8 sicuramente un ingegnere Linux, se vuoi DevOps \u2014 ingegnere DevOps. Un annuncio di lavoro non consiste solo nel titolo, ma \u00e8 necessario includere anche un testo. La cosa pi\u00f9 facile \u00e8 scrivere un insieme di parole chiave da Google, a seconda della fantasia di ciascuno. DevOps \u00e8 composto da due parole \u2014 \u00abDev\u00bb e \u00abOps\u00bb, quindi bisogna unire parole chiave relative a sviluppatori e amministratori, tutte insieme. Cos\u00ec nascono annunci che richiedono la conoscenza di 42 linguaggi di programmazione e 20 anni di esperienza con Kubernetes e Swarm contemporaneamente. \u00c8 uno schema di lavoro.<\/p>\n

<\/p>\n

Cos\u00ec nella mente delle persone si \u00e8 radicata l'immagine insensata e spietata di una sorta di supereroe \u00abDevOps\u00bb che configurer\u00e0 a tutti il deployment su Jenkins, e arriver\u00e0 la felicit\u00e0. Ah, se solo fosse cos\u00ec semplice. \u00abE poi si possono anche cercare sistemisti, \u2014 pensa l\u2019HR, \u2014 \u00e8 una parola alla moda, le stesse parole chiave, devono abboccare\u00bb.<\/p>\n

<\/p>\n

La domanda genera offerta, e a tutte queste strambe opportunit\u00e0 di lavoro \u00e8 accorsa una folla di sistemisti che hanno capito: si pu\u00f2 fare esattamente quello che si faceva prima, ma guadagnando molto di pi\u00f9, chiamandosi \"DevOps\". Come configuravi i server manualmente tramite SSH, cos\u00ec continuerai a farlo, ma ora questo \u00e8 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 \u2014 ci\u00f2 che \u00e8 fatto, \u00e8 fatto.<\/p>\n

<\/p>\n

Quindi, abbiamo domanda e offerta. Un circolo vizioso che si autoalimenta. \u00c8 su questo che stiamo combattendo (in parte creando la conferenza DevOops).<\/p>\n

<\/p>\n

Naturalmente, oltre agli amministratori di sistema che si sono rinominati \"DevOps\", ci sono anche altri partecipanti \u2014 come i professionisti SRE o gli sviluppatori di Infrastructure-as-Code.<\/p>\n

<\/p>\n

Cosa fanno realmente le persone nel DevOps<\/h2>\n

<\/p>\n

Quindi, vuoi approfondire l'apprendimento e l'applicazione delle pratiche DevOps. Ma come fare, in quale direzione orientarsi? Ovviamente, non \u00e8 saggio seguire ciecamente le parole chiave popolari.<\/p>\n

<\/p>\n

Se c'\u00e8 lavoro da fare, qualcuno deve farlo. Abbiamo gi\u00e0 stabilito che non si tratta di \"DevOps engineer\", quindi chi sono? Sembra pi\u00f9 appropriato formulare la questione non in termini di posizioni, ma in termini di specifiche aree di lavoro.<\/p>\n

<\/p>\n

Innanzitutto, si pu\u00f2 lavorare al cuore del DevOps: processi e cultura. La cultura \u00e8 un processo lungo e complesso e, sebbene tradizionalmente sia sotto la responsabilit\u00e0 dei leader, in questo sono coinvolti tutti, dai programmatori agli amministratori. Qualche mese fa, Tim Lister ha dichiarato in un'intervista<\/a><\/noindex>:<\/p>\n

<\/p>\n

\u00abLa cultura \u00e8 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\u00f2 che accade. Lo chiamiamo 'profumo'. A volte questo profumo \u00e8 davvero buono. A volte provoca nausea. (\u2026) Non puoi cambiare la cultura prima di aver compreso i valori e le convinzioni che stanno dietro a determinate azioni. \u00c8 facile osservare il comportamento, ma \u00e8 difficile cercare le convinzioni. Il DevOps \u00e8 un ottimo esempio di come tutto diventi sempre pi\u00f9 complesso.\u00bb<\/p><\/blockquote>\n

C'\u00e8 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 \u00e8 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. \u00c8 importante conoscere e padroneggiare tutto questo, e questo \u00e8 gi\u00e0 un vero e proprio campo ingegneristico. \u00c8 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 \u00e8 una metodologia molto complessa, che non tratta solo di come configurare Jenkins, ma di cinque principi fondamentali:<\/p>\n

<\/p>\n