{"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":"Non esistono ingegneri DevOps. Chi esiste allora, e cosa fare al riguardo?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Non<\/p>\n

<\/p>\n

Negli ultimi tempi, questi annunci hanno invaso Internet. Nonostante uno stipendio allettante, non si pu\u00f2 non essere disturbati dal fatto che all'interno ci sia una vera assurdit\u00e0. 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 \u00e8 chiaramente copiato da un annuncio per sistemisti.<\/p>\n

<\/p>\n

In questo post vogliamo parlare un po' di come siamo arrivati a questa situazione, cosa significa realmente DevOps e cosa fare adesso.<\/p>\n

<\/p>\n

Si possono criticare questi annunci in tutti i modi, ma il fatto \u00e8 che ci sono tanti posti di lavoro e il mercato funziona cos\u00ec al momento. Abbiamo organizzato una conferenza su DevOps e dichiariamo apertamente: \u201cDevOops<\/a><\/noindex> \u2014 non \u00e8 per gli ingegneri DevOps\u201d. Qui a molti sembrer\u00e0 strano e folle: perch\u00e9 delle persone che organizzano un evento commerciale vanno contro il mercato. Ora spiegheremo tutto.<\/p>\n

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

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

<\/p>\n

Iniziamo col dire che DevOps non \u00e8 una disciplina ingegneristica. \u00c8 iniziato tutto perch\u00e9 la tradizionale divisione dei ruoli non funziona per la qualit\u00e0 dei prodotti. Quando i programmatori si limitano a programmare e non vogliono sentire nulla sul testing, il software \u00e8 pieno di bug. Quando agli amministratori non importa come e perch\u00e9 \u00e8 stato scritto il software, il supporto diventa un inferno. <\/p>\n

<\/p>\n

Per esempio, la differenza tra l'approccio sistemistico e quello SRE alla gestione dei servizi \u00e8 descritta nel famoso Google SRE Book<\/a><\/noindex>. Interessanti ricerche sono state condotte nell'ambito del sondaggio DORA<\/a><\/noindex> \u2014 si vede che i migliori sviluppatori riescono in qualche modo a rilasciare nuove modifiche in produzione pi\u00f9 velocemente di una volta all'ora. Inoltre, testano manualmente non pi\u00f9 del 10% (come mostrato dal DORA dello scorso anno<\/a><\/noindex>). Come ci riescono? \"Excel or die\" \u2013 dice uno dei titoli del rapporto. Per una discussione dettagliata di queste statistiche nel contesto del testing, si pu\u00f2 fare riferimento al keynote di Baruch Sadogursky \"Abbiamo DevOps. Licenziamo tutti i tester\"<\/a><\/noindex> alla nostra altra conferenza, Heisenbug.<\/p>\n

<\/p>\n

\u201cQuando tra i compagni non c'\u00e8 accordo,
\nNessun affare andr\u00e0 bene,
\nE non ne verr\u00e0 nulla, solo sofferenza.
\nUna volta il Cigno, il Granchio e la Luccio\u2026\u201d<\/p><\/blockquote>\n

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\u00e0 ai tester e chieder\u00e0 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.<\/p>\n

<\/p>\n

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

<\/p>\n

Un circolo vizioso<\/h2>\n

<\/p>\n

Da dove viene allora la disciplina della \u00abdevops engineering\u00bb? Abbiamo una versione! Le idee del DevOps si sono rivelate buone \u2014 cos\u00ec 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.<\/p>\n

<\/p>\n

Immaginate: ieri a Chimki preparavate shawarma, e oggi siete gi\u00e0 una figura importante, un senior recruiter. Qui c'\u00e8 un intero processo di ricerca e selezione dei candidati, non \u00e8 semplice, bisogna capire. Supponiamo che il capo dipartimento dica: trova uno specialista in X. A X aggiungiamo la parola \u00abingegnere\u00bb, e la cosa \u00e8 fatta. Serve un Linux? Beh, \u00e8 sicuramente un ingegnere Linux, volete DevOps \u2014 ingegnere DevOps. L'offerta di lavoro non consiste solo nel titolo, ma dentro bisogna includere un certo testo. Il modo pi\u00f9 semplice \u00e8 inserire un insieme di parole chiave da Google, a seconda di quanta fantasia si ha. Il 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 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.<\/p>\n

<\/p>\n

Cos\u00ec nella mente delle persone si \u00e8 radicato l'immagine insensata e spietata di un supereroe \u00abdevops\u00bb, che configurer\u00e0 il deploy per tutti su Jenkins, e allora arriver\u00e0 la felicit\u00e0. Ah, se solo fosse cos\u00ec semplice. \u00abE cos\u00ec si possono anche reclutare sysadmin\u00bb, pensa l\u2019HR, \u00ab\u00e8 una parola alla moda, le parole chiave sono le stesse, dovrebbero abboccare\u00bb.<\/p>\n

<\/p>\n

La domanda genera offerta, e per tutte queste offerte ridicole si \u00e8 riversato un numero strabiliante di amministratori di sistema che hanno capito: \u00e8 possibile fare esattamente quel che si faceva prima, ma guadagnando molto di pi\u00f9, chiamandosi \"DevOps\". Come configuravi i server tramite SSH a mano, uno per uno, cos\u00ec continuerai a farlo, ma ora si tratta di una presunta pratica DevOps. \u00c8 un fenomeno complesso, parzialmente legato alla sottovalutazione degli amministratori classici e al clamore attorno al DevOps, ma in generale \u2014 quel che \u00e8 fatto, \u00e8 fatto.<\/p>\n

<\/p>\n

Dunque, abbiamo domanda e offerta. Un circolo vizioso che si alimenta da solo. Ecco cosa stiamo combattendo (inclusa la creazione della conferenza DevOops).<\/p>\n

<\/p>\n

Naturalmente, oltre agli amministratori di sistema che si sono ribattezzati \"DevOps\", ci sono altri partecipanti \u2014 ad esempio, professionisti SRE o sviluppatori di Infrastructure-as-Code.<\/p>\n

<\/p>\n

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

<\/p>\n

Quindi, vuoi progredire nello studio e nell'applicazione delle pratiche DevOps. Ma come fare, in quale direzione guardare? Ovviamente, non \u00e8 saggio seguire ciecamente le parole chiave popolari.<\/p>\n

<\/p>\n

Se c'\u00e8 lavoro, qualcuno deve occuparsene. Abbiamo gi\u00e0 chiarito che non si tratta di \"ingegneri DevOps\", quindi chi? Sembra pi\u00f9 corretto formulare questo non in termini di posizioni, ma in termini di specifici ambiti di lavoro.<\/p>\n

<\/p>\n

Innanzitutto, puoi occuparti del cuore stesso di DevOps \u2014 processi e cultura. La cultura \u00e8 un affare lento e difficile, e anche se tradizionalmente \u00e8 di responsabilit\u00e0 dei dirigenti, in un modo o nell'altro coinvolge tutti, dai programmatori agli amministratori. Qualche mese fa, Tim Lister ha detto in un'intervista<\/a><\/noindex>:<\/p>\n

<\/p>\n

\"La cultura \u00e8 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 \u00e8 davvero buono. Altre volte provoca nausea. (\u2026) Non puoi cambiare la cultura finch\u00e9 non sono stati compresi i valori e le convinzioni che stanno alla base delle singole azioni. \u00c8 facile osservare i comportamenti, mentre \u00e8 difficile cercare le convinzioni. Il DevOps \u00e8 proprio un ottimo esempio di come tutto diventa sempre pi\u00f9 complesso.\"<\/p><\/blockquote>\n

C'\u00e8 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\u00f2 non \u00e8 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. \u00c8 tutto da sapere e da saper fare, e questo \u00e8 gi\u00e0 un vero e proprio discipline ingegneristica. \u00c8 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 \u00e8 una metodologia molto complessa, che non parla di come configurare Jenkins, ma di cinque principi fondamentali:<\/p>\n

<\/p>\n