{"id":33725,"date":"2019-10-31T21:54:21","date_gmt":"2019-10-31T18:54:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/chto-takoe-devops\/"},"modified":"2019-10-31T21:54:21","modified_gmt":"2019-10-31T18:54:21","slug":"chto-takoe-devops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/chto-takoe-devops","title":{"rendered":"Cos'\u00e8 il DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La definizione di DevOps \u00e8 molto complessa, quindi \u00e8 necessario avviare la discussione ogni volta da capo. Solo su Habr ci sono mille pubblicazioni su questo tema. Ma se stai leggendo questo, sicuramente sai cosa sia DevOps. Perch\u00e9 io, purtroppo, non lo so. Ciao, mi chiamo Aleksandr Titov (@osminog<\/a><\/noindex><\/b>), e semplicemente parleremo di DevOps e io condivider\u00f2 la mia esperienza.<\/p>\n

\"Cos'\u00e8
\n
\nHo pensato a lungo a come rendere utile il mio racconto, quindi ci saranno molte domande \u2013 quelle che faccio a me stesso e quelle che faccio ai clienti della nostra azienda. Rispondendo a queste domande, la comprensione migliora. Spiegher\u00f2 perch\u00e9 DevOps \u00e8 necessario dal mio punto di vista, cosa sia, ancora una volta, dalla mia prospettiva, e come capire se stai avanzando verso DevOps, di nuovo secondo il mio punto di vista. L'ultimo punto sar\u00e0 attraverso domande. Rispondendo a queste domande da solo, potrai capire se la tua azienda sta procedendo verso DevOps o se ci sono problemi.
\n<\/a><\/noindex>
\n

\r\n \"Riproduci\r\n
<\/div>\r\n <\/div><\/center>
\nUn tempo navigavo tra le onde di fusioni e acquisizioni. Inizialmente ho lavorato in una piccola startup chiamata Qik, poi \u00e8 stata acquisita da una compagnia un po' pi\u00f9 grande, Skype, che \u00e8 stata successivamente acquistata da un'altra compagnia ancora pi\u00f9 grande, Microsoft. In quel momento ho avuto la visione di come si trasforma la percezione di DevOps nelle diverse aziende a seconda delle loro dimensioni. Da l\u00ec, ho cominciato a guardare al DevOps dal punto di vista del mercato, e insieme ai miei colleghi abbiamo fondato l'azienda Ekspress 42. Da sei anni ci muoviamo con essa sulle onde del mercato.<\/p>\n

Oltre a tutto ci\u00f2, sono uno dei fondatori della comunit\u00e0 DevOps Moscow e ho organizzato i DevOps Days 2017, ma nel 2018 non ho organizzato. Ekspress 42 collabora con molte aziende. Coltiviamo l\u00ec il DevOps, osserviamo come avviene, traiamo conclusioni, analizziamo e condividiamo le nostre scoperte, formando le persone nelle pratiche DevOps. In generale, stiamo facendo crescere l'esperienza e l'expertise in questo campo.<\/p>\n

Perch\u00e9 DevOps<\/h2>\n

\nLa prima domanda che inquieta tutti, sempre, \u00e8: perch\u00e9? Molti credono che DevOps sia semplicemente automazione o qualcosa di simile, che \u00e8 gi\u00e0 presente in ogni azienda.<\/p>\n

\u2014 Abbiamo avuto Continuous Integration, il che significa che gi\u00e0 esisteva DevOps, ma a cosa serve tutto questo? All'estero si divertono, mentre noi siamo ostacolati nel lavoro!<\/i><\/p>\n

Dopo 9 anni di sviluppo della comunit\u00e0 e della metodologia, \u00e8 chiaro che non si tratta di semplici abbellimenti di marketing, ma non \u00e8 ancora del tutto chiaro a cosa serva. Come per qualsiasi strumento e processo, DevOps ha obiettivi specifici che risolve nel lungo termine.<\/p>\n

Tutto ci\u00f2 \u00e8 legato al fatto che il mondo sta cambiando. Sta abbandonando l'approccio enterprise, dove le aziende si muovono direttamente verso il sogno, come cantava il nostro classico di San Pietroburgo, dal punto A al punto B seguendo una strategia definita, con una struttura costruita appositamente per questo. <\/p>\n

\"Cos'\u00e8
\n<\/p>\n

In linea di principio, tutto in IT dovrebbe essere costruito su questo approccio. Qui l'IT \u00e8 utilizzato esclusivamente per l'automazione dei processi.<\/p><\/blockquote>\n

\nL'automazione cambia raramente, perch\u00e9 quando un'azienda scorre lungo una strada gi\u00e0 tracciata, cosa c'\u00e8 da cambiare? Funziona, non toccarlo. Oggi nel mondo gli approcci stanno cambiando, e quello che chiamiamo Agile indica che il punto finale B non \u00e8 subito visibile.<\/p>\n

\"Cos'\u00e8
\n
\nQuando un'azienda esplora il mercato e collabora con i clienti, sta costantemente analizzando l'ambiente circostante e adattando i propri obiettivi. Maggiore \u00e8 la frequenza con cui l'azienda cambia direzione, maggiore \u00e8 la sua probabilit\u00e0 di successo, poich\u00e9 riesce a cogliere pi\u00f9 opportunit\u00e0 di mercato.<\/p>\n

Un esempio interessante di strategia \u00e8 una compagnia che ho recentemente scoperto. One Box Shave \u00e8 un servizio di consegna di rasoi e accessori per la rasatura in abbonamento. Sono capaci di personalizzare la loro \"scatola\" per i diversi clienti. Questo \u00e8 gestito da un software specifico che invia poi l'ordine a una fabbrica coreana che produce il prodotto.<\/p>\n

Questo prodotto \u00e8 stato acquistato da Unilever per 1 miliardo di dollari. Attualmente compete con Gillette e ha sottratto una significativa quota di mercato ai consumatori americani. Di One Box Shave si dice:<\/p>\n

\u2014 Quattro lame? Sul serio? Perch\u00e9 avete bisogno di questo? Non migliora affatto la qualit\u00e0 della rasatura. Una crema selezionata, una fragranza e un rasoio di qualit\u00e0 con due lame risolvono molte pi\u00f9 questioni rispetto a queste stupide quattro lame di Gillette! Presto arriveremo a dieci?<\/i><\/p>\n

Cos\u00ec il mondo sta cambiando. Unilever afferma di avere un sistema IT eccezionale che permette di farlo. Il risultato \u00e8 una concezione. Time-to-market<\/b>, di cui si \u00e8 gi\u00e0 parlato ampiamente.<\/p>\n

\"Cos'\u00e8
\n
\nIl significato di Time-to-market non riguarda quanto spesso facciamo il deployment. Possiamo fare il deployment frequentemente, ma i cicli di rilascio potrebbero essere lunghi. Se si sovrappongono cicli di rilascio di tre mesi, scalando di una settimana, sembra che l'azienda faccia il deployment ogni settimana. Ma da un'idea alla realizzazione finale passano 3 mesi.<\/p>\n

Il Time-to-market riguarda la minimizzazione del tempo dall'idea alla realizzazione finale.<\/p><\/blockquote>\n

\nIn questo caso, il software interagisce con il mercato. Cos\u00ec, il sito web di One Box Shave interagisce con il cliente. Non hanno venditori \u2013 solo un sito dove il visitatore clicca e lascia commenti. Pertanto, il sito deve continuamente presentare novit\u00e0, aggiornandosi in base alle richieste. Ad esempio, in Corea del Sud ci si rade in modo diverso che in Russia, e preferiscono una fragranza di carota alla vaniglia anzich\u00e9 il profumo di pino.<\/p>\n

Poich\u00e9 \u00e8 necessario modificare rapidamente il contenuto del sito, lo sviluppo del software sta cambiando notevolmente. Attraverso il software dobbiamo capire cosa desidera il cliente. In passato, lo scoprivamo in modi indiretti, ad esempio tramite la gestione aziendale. Poi progettavamo, stabilivamo i requisiti nel sistema IT, e tutto funzionava perfettamente. Oggi \u00e8 diverso: il software \u00e8 progettato da tutti coloro che sono coinvolti nel processo, compresi gli ingegneri, perch\u00e9 apprendono dalle specifiche tecniche come funziona il mercato e condividono anche le loro intuizioni con il business.<\/p>\n

Ad esempio, in Qik abbiamo scoperto improvvisamente che alle persone piace molto caricare elenchi di contatti sul server, e ci hanno fornito un'app. Inizialmente non ci avevamo pensato. In un'azienda tradizionale, tutti avrebbero pensato che si trattasse di un bug, poich\u00e9 nel documento non era scritto che doveva funzionare bene e, in effetti, era stato realizzato in modo affrettato; avrebbero disattivato la funzionalit\u00e0 e detto: \"Non serve a nessuno, l'importante \u00e8 che la funzionalit\u00e0 principale funzioni\". Ma in un'azienda tecnologica si vede un'opportunit\u00e0 e si inizia a modificare il software di conseguenza.<\/p>\n

\"Cos'\u00e8
\n
\nNel 1968, il visionario Melvin Conway formul\u00f2 la seguente idea.<\/p>\n

Un'organizzazione che crea un sistema \u00e8 limitata dal design che copia la struttura di comunicazione al suo interno.<\/p><\/blockquote>\n

\nSe approfondiamo, per produrre sistemi di un altro tipo, \u00e8 necessario disporre anche di una struttura di comunicazione interna di un altro tipo. Se la vostra struttura di comunicazione \u00e8 altamente gerarchica, questo non consentir\u00e0 di creare sistemi che possono garantire un elevato Time-to-market.<\/p>\n

Leggi sulla legge di Conway<\/a><\/noindex> \u00e8 possibile ai link<\/a><\/noindex>. \u00c8 fondamentale per comprendere la cultura o la filosofia DevOps, poich\u00e9 l'unica cosa che cambia fondamentalmente in DevOps \u00e8 proprio la struttura di comunicazione tra i team.<\/b>.<\/p>\n

Dal punto di vista del processo, prima di DevOps tutte le fasi: analisi, sviluppo, testing, operazioni, avvenivano in modo lineare.\"Cos'\u00e8
\nNel caso di DevOps, tutti questi processi avvengono simultaneamente.<\/p>\n

\"Cos'\u00e8
\n
\nSolo cos\u00ec pu\u00f2 essere realizzato il Time-to-market. Per le persone che hanno lavorato nel vecchio processo, questo pu\u00f2 sembrare piuttosto futuristico, e in generale non molto pratico.<\/p>\n

Allora, a cosa serve DevOps?<\/h3>\n

\nPer lo sviluppo di prodotti digitali.<\/b>. Se nella tua azienda non c'\u00e8 prodotto digitale, DevOps non \u00e8 necessario \u2014 questo \u00e8 molto importante.<\/p>\n

DevOps supera i limiti di velocit\u00e0 dei processi di produzione software sequenziali.<\/b>. In esso, tutti i processi avvengono simultaneamente.<\/p>\n

Aumenta la complessit\u00e0.<\/b> Quando gli evangelisti del DevOps dicono che con esso diventa pi\u00f9 facile rilasciare software \u2014 \u00e8 pura follia.<\/p>\n

Con DevOps, tutto diventa solo pi\u00f9 difficile.<\/p><\/blockquote>\n

\nAlla conferenza, allo stand di Avito, si poteva vedere cosa significa deployare un container Docker \u2014 un compito irrealizzabile. La complessit\u00e0 diventa insostenibile, bisogna giocolare con molteplici palline contemporaneamente.<\/p>\n

DevOps cambia completamente i processi e l'organizzazione in azienda.<\/b>\u00a0\u2014 pi\u00f9 precisamente, non \u00e8 DevOps a cambiare, ma il prodotto digitale. Per arrivare al DevOps, bisogna comunque modificare completamente questo processo.<\/p>\n

Domande per gli specialisti<\/h3>\n

\nE da voi? Domande che puoi porti mentre lavori in azienda e cresci come specialista.<\/p>\n

Hai una strategia per la creazione di un prodotto digitale?<\/b> Se s\u00ec \u2014 gi\u00e0 bene. Questo significa che la tua azienda sta procedendo verso DevOps.<\/p>\n

La tua azienda sta gi\u00e0 creando un prodotto digitale?<\/b> Questo significa che puoi salire un ulteriore gradino, impegnandoti in attivit\u00e0 pi\u00f9 interessanti \u2014 dal punto di vista del DevOps, per essere chiari. Sto parlando proprio da questo punto di vista.<\/p>\n

La tua azienda \u00e8 uno dei leader di mercato in un settore di prodotto digitale?<\/b> Spotify, Yandex, Uber \u2014 aziende che sono attualmente al vertice del progresso tecnologico.<\/p>\n

Poniti queste domande e se tutte le risposte sono negative, forse non dovresti occuparti di DevOps in questa azienda. Tuttavia, se il tema del DevOps ti interessa davvero, potrebbe essere\u2026 opportuno passare a un'altra azienda? Se la tua azienda desidera intraprendere la strada del DevOps ma hai risposto 'No' a tutte le domande, allora assomiglia a quel bellissimo rinoceronte che non cambier\u00e0 mai.<\/p>\n

\"Cos'\u00e8
\n<\/p>\n

Organizzazione<\/h2>\n

\nCome gi\u00e0 detto, secondo la Legge di Conway, l'organizzazione di un'azienda cambia. Inizio da ci\u00f2 che ostacola l'integrazione del DevOps all'interno dell'azienda, precisamente dal punto di vista organizzativo.<\/p>\n

Il problema dei 'silos'<\/h3>\n

\nLa parola inglese 'Silo' \u00e8 tradotta qui in russo come '\u043a\u043e\u043b\u043e\u0434\u0435\u0446'. Il senso di questo problema \u00e8 che non c'\u00e8 scambio di informazioni tra i team.<\/b>. Ogni team scava la propria esperienza in profondit\u00e0, senza per\u00f2 costruire una mappa comune sulla quale orientarsi.<\/p>\n

Questo ricorda un po' una persona che \u00e8 appena arrivata a Mosca e non \u00e8 ancora in grado di orientarsi sulla mappa della metropolitana. I moscoviti di solito conoscono bene il proprio quartiere e si orientano in tutta Mosca grazie alla mappa della metropolitana. Quando arrivi a Mosca per la prima volta, non hai questa abilit\u00e0 e ti senti semplicemente disorientato.<\/p>\n

Il DevOps offre la possibilit\u00e0 di superare questo momento di disorientamento e di costruire insieme a tutti i dipartimenti una mappa comune di interazione.<\/p><\/blockquote>\n

\nDue fattori ostacolano questo.<\/p>\n

La conseguenza di un sistema di gestione corporate.<\/b> \u00c8 costruito su 'pozzi' gerarchici separati. Ad esempio, ci sono determinati KPI nelle aziende che supportano questo sistema. D'altra parte, ci sono le menti delle persone, che faticano a uscire dai propri ambiti di competenza e a orientarsi all'interno dell'intero sistema. \u00c8 semplicemente scomodo. Immaginate di essere all'aeroporto di Bangkok: l\u00ec non ci si orienta facilmente. Anche nel DevOps \u00e8 difficile orientarsi, ed \u00e8 per questo che le persone dicono che bisogna trovare una guida per entrarci.<\/p>\n

Ma la cosa pi\u00f9 importante \u00e8 che il problema dei \"pozzi\" per un ingegnere che ha abbracciato lo spirito del DevOps, ha letto Fowler e un sacco di altri libri, si esprime nel fatto che i \"pozzi\" non consentono di fare le cose \"ovvie\"<\/b>. Spesso ci incontriamo dopo DevOps Moscow, parliamo tra di noi e le persone si lamentano:<\/p>\n

\u2014 Volevamo semplicemente avviare il CI, ma \u00e8 risultato che alla gestione non interessa.<\/i><\/p>\n

Questo accade proprio perch\u00e9\u00a0CI <\/b>e\u00a0il processo di Continuous Delivery<\/b> si trova al confine di molte competenze. Non superando il problema dei \"pozzi\" a livello organizzativo, non potr\u00e0 progredire ulteriormente, qualunque cosa facciate e per quanto sia triste.<\/p>\n

\"Cos'\u00e8
\n
\nOgni partecipante del processo in azienda: sviluppatori backend e frontend, testing, DBA, operazioni, rete, scava dalla propria parte, mentre nessuno ha una mappa condivisa, tranne il manager che in un certo modo li osserva e gestisce con il metodo \"divide et impera\".<\/p>\n

Le persone lottano per qualche stella o bandierina, ognuno scava nella propria area di competenza.<\/p><\/blockquote>\n

\nAlla fine, quando si presenta il compito di mettere tutto insieme e costruire un pipeline comune, e non \u00e8 pi\u00f9 necessario combattere per le stelle e le bandierine, sorge la domanda: cosa dobbiamo fare? Bisogna trovare un accordo, ma come si fa? A scuola nessuno ci ha insegnato. Siamo stati educati fin dalle scuole medie: l'ottavo anno \u00e8 wow! - rispetto al settimo anno! Qui \u00e8 la stessa cosa.<\/p>\n

\u00c8 cos\u00ec anche nella vostra azienda?<\/h3>\n

\nPer verificare ci\u00f2, \u00e8 possibile porsi le seguenti domande.<\/p>\n

Le squadre utilizzano strumenti comuni e contribuiscono a modifiche di questi strumenti condivisi?<\/p>\n

\u041d\u0430\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0447\u0430\u0441\u0442\u043e \u043a\u043e\u043c\u0430\u043d\u0434\u044b \u043f\u0435\u0440\u0435\u0444\u043e\u0440\u043c\u0438\u0440\u0443\u044e\u0442\u0441\u044f\u00a0\u2014 \u043e\u0434\u043d\u0438 \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0441\u0442\u044b \u0438\u0437\u00a0\u043e\u0434\u043d\u043e\u0439 \u043a\u043e\u043c\u0430\u043d\u0434\u044b \u043f\u0435\u0440\u0435\u0445\u043e\u0434\u044f\u0442 \u0432\u00a0\u0434\u0440\u0443\u0433\u0443\u044e \u043a\u043e\u043c\u0430\u043d\u0434\u0443?<\/b> \u0418\u043c\u0435\u043d\u043d\u043e \u0432\u00a0DevOps-\u0441\u0440\u0435\u0434\u0435 \u044d\u0442\u043e \u0441\u0442\u0430\u043d\u043e\u0432\u0438\u0442\u0441\u044f \u043d\u043e\u0440\u043c\u0430\u043b\u044c\u043d\u044b\u043c, \u043f\u043e\u0442\u043e\u043c\u0443 \u0447\u0442\u043e \u0438\u043d\u043e\u0433\u0434\u0430 \u0447\u0435\u043b\u043e\u0432\u0435\u043a \u043f\u0440\u043e\u0441\u0442\u043e \u043d\u0435\u00a0\u043c\u043e\u0436\u0435\u0442 \u043f\u043e\u043d\u044f\u0442\u044c, \u0447\u0435\u043c \u0437\u0430\u043d\u0438\u043c\u0430\u0435\u0442\u0441\u044f \u0434\u0440\u0443\u0433\u0430\u044f \u0437\u043e\u043d\u0430 \u044d\u043a\u0441\u043f\u0435\u0440\u0442\u0438\u0437\u044b. \u041e\u043d\u00a0\u043f\u0435\u0440\u0435\u0445\u043e\u0434\u0438\u0442 \u0432\u00a0\u0434\u0440\u0443\u0433\u043e\u0439 \u043e\u0442\u0434\u0435\u043b, \u0434\u0432\u0435 \u043d\u0435\u0434\u0435\u043b\u044c\u043a\u0438 \u0442\u0430\u043c \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442, \u0447\u0442\u043e\u0431\u044b \u0441\u043e\u0437\u0434\u0430\u0442\u044c \u0434\u043b\u044f \u0441\u0435\u0431\u044f \u043a\u0430\u0440\u0442\u0443 \u043e\u0440\u0438\u0435\u043d\u0442\u0430\u0446\u0438\u0438 \u0438\u00a0\u0432\u0437\u0430\u0438\u043c\u043e\u0434\u0435\u0439\u0441\u0442\u0432\u0438\u044f \u0441\u00a0\u044d\u0442\u0438\u043c \u043e\u0442\u0434\u0435\u043b\u043e\u043c.<\/p>\n

\u00c8 possibile creare un comitato per le modifiche e apportare delle modifiche? <\/b>O serve una mano forte della dirigenza pi\u00f9 alta e un ordine? Recentemente ho scritto su Facebook di come una banca poco conosciuta implementi strumenti attraverso ordini: abbiamo dato un ordine, stiamo implementando da un anno, vediamo cosa succede. Certamente, \u00e8 un processo lungo e triste.<\/p>\n

Quanto \u00e8 importante per i manager ottenere risultati personali senza considerare i risultati dell'azienda? <\/b><\/p>\n

Se risponderete a queste domande, sar\u00e0 pi\u00f9 chiaro se avete un problema simile in azienda.<\/p>\n

Infrastruttura come codice<\/h2>\n

\nUna volta superato questo problema, la prima pratica importante, senza la quale \u00e8 difficile progredire nel DevOps \u00e8 infrastruttura come codice<\/b>. <\/p>\n

Spesso l'infrastruttura come codice viene percepita cos\u00ec:<\/p>\n

- Automatizziamo tutto in bash, sommergiamoci di script, cos\u00ec i sysadmin faranno meno lavoro manuale!<\/i><\/p>\n

Ma non \u00e8 cos\u00ec.<\/p>\n

L'infrastruttura come codice implica che il sistema IT con cui lavorate venga descritto in forma di codice, per capire costantemente il suo stato.<\/p><\/blockquote>\n

\nInsieme ad altri team, create una mappa in forma di codice, comprensibile per tutti, che si pu\u00f2 seguire e navigare. Non importa su cosa sia realizzata: Chef, Ansible, Salt, o se vengono utilizzati file YAML in Kubernetes \u2014 non fa differenza.<\/p>\n

Durante la conferenza, un collega di 2GIS ha raccontato come hanno creato il loro strumento interno per Kubernetes, che descrive la configurazione dei singoli sistemi. Per descrivere 500 sistemi, hanno avuto bisogno di uno strumento separato che genera questa descrizione. Una volta che c'\u00e8 questa descrizione, ognuno pu\u00f2 confrontarsi, monitorare le modifiche, vedere come cambiarla e migliorarla, e identificare cosa manca. <\/p>\n

Ammettiamolo, i singoli script bash di solito non offrono questa comprensione. In una delle aziende in cui ho lavorato, c'era addirittura il termine 'script write only' \u2014 quando lo script \u00e8 scritto, ma non \u00e8 pi\u00f9 possibile leggerlo. Penso che anche a voi suoni familiare.<\/p>\n

L'infrastruttura come codice \u00e8 il codice che descrive lo stato attuale dell'infrastruttura<\/b>. Su questo codice collaborano numerosi team di prodotto, infrastruttura e servizio, e, cosa pi\u00f9 importante, tutti devono capire come funziona questo codice.<\/p>\n

Il codice \u00e8 accompagnato secondo le migliori pratiche di programmazione.<\/b>: sviluppo collaborativo, revisione del codice, programmazione XP, test, richieste di pull, CI per l'infrastruttura del codice \u2013 tutto ci\u00f2 \u00e8 valido e pu\u00f2 essere utilizzato.<\/p>\n

Il codice diventa un linguaggio comune per tutti gli ingegneri.<\/p><\/blockquote>\n

\nLa modifica dell'infrastruttura nel codice non richiede molto tempo.<\/b>. S\u00ec, anche nel codice dell'infrastruttura pu\u00f2 esserci un debito tecnico. Di solito, i team si imbattono in questo dopo un anno e mezzo dall'inizio dell'implementazione dell'\u00abinfrastruttura come codice\u00bb sotto forma di una serie di script o persino Ansible, che scrivono come codice spaghetti, e gettano dentro anche script bash! <\/p>\n

Importante<\/b>: se non avete ancora provato questa cosa, ricordate che Ansible non \u00e8 bash<\/b>! Leggete attentamente la documentazione, studiate cosa viene scritto a riguardo.<\/p>\n

L'infrastruttura come codice \u00e8 una separazione del codice infrastrutturale in strati distinti.<\/p><\/blockquote>\n

\nNella nostra azienda distinguiamo 3 strati di base, che sono molto chiari e semplici, ma potrebbero essere di pi\u00f9. Puoi controllare il tuo codice infrastrutturale e verificare se hai questa condizione o meno. Se non ci sono strati distinti, \u00e8 necessario dedicare del tempo a fare un po' di refactoring.
\n\"Cos'\u00e8
\n
\nStrato di base<\/b>\u00a0\u2014 \u00e8 come si configura il sistema operativo, i backup e altre cose di basso livello, ad esempio, come viene implementato Kubernetes a livello di base.<\/p>\n

Livello dei servizi<\/b>\u00a0\u2014 sono i servizi che offri agli sviluppatori: registrazione come servizio, monitoraggio come servizio, database come servizio, bilanciatore come servizio, coda come servizio, Continuous Delivery come servizio \u2014 una serie di servizi che diversi team possono fornire allo sviluppo. Tutto questo deve essere descritto come moduli separati nel tuo sistema di gestione della configurazione.<\/p>\n

Strato dove vengono creati le applicazioni<\/b> e viene descritto come verranno implementate sopra i due strati precedenti.<\/p>\n

Domande di controllo<\/h3>\n

\nAvete un repository infrastrutturale comune nella vostra azienda? Controllate il debito tecnico nell'infrastruttura? Utilizzate pratiche di sviluppo nel repository infrastrutturale? La vostra infrastruttura \u00e8 suddivisa in livelli? Potete fare riferimento allo schema Base-service-APP. Quanto \u00e8 complesso apportare una modifica? <\/p>\n

Se vi \u00e8 capitato di trovare che modificare qualcosa richiedesse un giorno e mezzo, significa che avete accumulato debito tecnico e dovete lavorare su di esso. Vi siete appena imbattuti in trappole del debito tecnico nel codice infrastrutturale. Ricordo molte storie in cui, per cambiare un CCTL, era necessario riscrivere met\u00e0 del codice infrastrutturale, perch\u00e9 la creativit\u00e0 e il desiderio di automatizzare tutto ha portato a un ingorgo ovunque, tutte le maniglie rimosse, e c'\u00e8 bisogno di rifattorizzare.<\/p>\n

Consegna continua<\/h2>\n

\nConfrontiamo il debito con il credito. Inizialmente viene fornita una descrizione dell'infrastruttura, che pu\u00f2 essere piuttosto basilare. Non \u00e8 necessario descrivere tutto nel dettaglio, ma \u00e8 richiesta una qualche descrizione di base per poter lavorare con questo. Altrimenti, non \u00e8 chiaro su cosa effettuare la distribuzione continua. Tutte queste pratiche si sviluppano simultaneamente quando arrivate al DevOps, ma bisogna cominciare dalla comprensione di cosa si ha e come gestirlo. Questa \u00e8 proprio la pratica dell'infrastruttura come codice.<\/p>\n

Dopo aver compreso cosa si ha e come gestirlo, iniziate a pensare a come inviare il codice del developer il pi\u00f9 rapidamente possibile in produzione. Intendo dire insieme al developer - ricordiamo il problema dei 'pozzi', ovvero non sono singole persone a pensarci, ma un team.<\/p>\n

Quando ci siamo\u00a0incontrati con Ivan Yevtukhovich<\/b> e abbiamo visto il primo libro di Jez Humble<\/b> e del gruppo di autori \u00abContinuous Delivery\u00bb<\/b>, che \u00e8 stata rilasciata nel 2009, abbiamo a lungo riflettuto su come tradurre il suo titolo in russo. Volevamo tradurlo come \u00abConsegna continua\u00bb, ma, sfortunatamente, \u00e8 stato tradotto come \u00abFornitura continua\u00bb. Penso che ci sia qualcosa di profondamente russo nel nostro titolo, con una certa determinazione.<\/p>\n

Consegna continua significa<\/h3>\n

\nIl codice che si trova nel repository di prodotto pu\u00f2 sempre essere rilasciato in produzione<\/b>. Potrebbe non essere rilasciato, ma \u00e8 sempre pronto per farlo. Di conseguenza, scrivete sempre codice con una certa sensazione difficile da spiegare di disagio alla base della schiena. Questo sentimento di disagio spesso emerge quando si distribuisce codice infrastrutturale. Questa sensazione di disagio dovrebbe essere presente: provoca processi mentali che permettono di scrivere codice in modo un po' diverso. Questo dovrebbe essere registrato nelle regole all'interno dello sviluppo.<\/p>\n

Per garantire una consegna continua, \u00e8 necessario un formato dell'artefatto che passi attraverso la piattaforma infrastrutturale. <\/b>Se butti \u00abrifiuti biologici\u00bb su una piattaforma infrastrutturale di formati diversi, diventa non unificata, difficile da mantenere, e sorgono problemi di debito tecnico. \u00c8 necessario allineare il formato dell'artefatto \u2014 questo \u00e8 un compito collettivo: dobbiamo riunirci e lavorare insieme per inventare questo formato.<\/p>\n

L'artefatto viene continuamente migliorato e modificato per l'ambiente di produzione durante il passaggio attraverso il pipeline di fornitura. <\/b>Quando l'artefatto si muove lungo il pipeline, incontra costantemente elementi scomodi che sembrano quelli con cui si scontra l'artefatto che stai distribuendo in produzione. Se nella sviluppo tradizionale a occuparsene \u00e8 un amministratore di sistema che effettua la distribuzione, nel processo DevOps questo avviene costantemente: qui \u00e8 stato testato con vari test, l\u00e0 \u00e8 stato caricato in un cluster Kubernetes che \u00e8 pi\u00f9 o meno simile a produzione, e qui \u00e8 stato improvvisamente avviato un test di carico.<\/p>\n

Questo ricorda in parte il gioco di Pac-Man: l'artefatto segue una certa storia. \u00c8 importante controllare se il codice realmente segue la storia e se questa \u00e8 in qualche modo collegata al vostro ambiente di produzione. Le storie con produzione possono essere integrate nel processo di Continuous Delivery: c'era un problema quando qualcosa \u00e8 andato storto, ora programmiamo semplicemente questo scenario nel sistema. Ogni volta il codice seguir\u00e0 anche questo scenario, e non vi ritroverete pi\u00f9 di fronte a questo problema. Ne sarete a conoscenza molto prima che si presenti al vostro cliente.<\/p>\n

Diverse strategie di deployment. <\/b>Ad esempio, utilizzate A\/B testing o deployment canary per 'testare' il codice su diversi clienti, raccogliendo informazioni su come funziona, molto prima che venga distribuito a 100 milioni di utenti.<\/p>\n

\u00abDelivering continuously\u00bb appare cos\u00ec.<\/p>\n

\"Cos'\u00e8
\n<\/p>\n

Il processo di fornitura Dev, CI, Test, PreProd, Prod non \u00e8 un ambiente separato, ma fasi o stazioni con somme intoccabili, attraverso le quali passa il vostro artefatto.<\/p><\/blockquote>\n

\nSe avete codice infrastrutturale descritto come Base Service APP, questo aiuta a non dimenticare tutti gli scenari.<\/b>, e scrivere anche il codice per questo artefatto, promuovere l'artefatto<\/b> e modificarlo lungo il percorso.<\/p>\n

Domande per l'autovalutazione<\/h3>\n

\nIl tempo dalla descrizione della funzionalit\u00e0 al rilascio in produzione \u00e8 inferiore a una settimana nel 95% dei casi? La qualit\u00e0 dell'artefatto migliora a ogni fase del pipeline? Esiste una storia che lo accompagna? Utilizzate diverse strategie di deployment?<\/p>\n

Se tutte le risposte sono s\u00ec, allora siete incredibilmente bravi! Scrivete le risposte nei commenti e sar\u00f2 felice).<\/p>\n

Feedback<\/h3>\n

\nQuesta \u00e8 la pratica pi\u00f9 complessa di tutte. Alla conferenza DevOpsConf, un collega di Infobip, parlando di essa, si confuse un po' con le parole, perch\u00e9 \u00e8 davvero una pratica molto complicata che riguarda il monitoraggio di tutto!<\/p>\n

\"Cos'\u00e8
\n
\nAd esempio, tanto tempo fa, quando lavoravo in Qik e ci siamo resi conto che dovevamo monitorare davvero tutto. Lo abbiamo fatto e abbiamo avuto 150.000 elementi che venivano monitorati costantemente in Zabbix. Era spaventoso, il CTO girava il dito alla tempia:<\/p>\n

\u2014 Ragazzi, perch\u00e9 state stressando il server con cose incomprensibili?<\/i><\/p>\n

Ma poi \u00e8 successo un episodio che ha dimostrato che questa \u00e8 davvero una strategia molto valida.<\/p>\n

Purtroppo, uno dei servizi ha iniziato a cadere frequentemente. Inizialmente non si verificava, e cosa interessante, non c'era stata alcuna modifica al codice, poich\u00e9 si trattava di un broker di base, che praticamente non aveva funzionalit\u00e0 aziendali \u2014 si limitava a inoltrare messaggi tra i vari servizi. Il servizio non era cambiato per 4 mesi, e all\u2019improvviso ha cominciato a cadere con l'errore \u00abSegmentation fault\u00bb.<\/p>\n

Siamo rimasti scioccati, abbiamo aperto i nostri grafici in Zabbix, e abbiamo scoperto che, a quanto pare, circa un mese e mezzo fa, il comportamento delle richieste nell'API del servizio, che utilizza questo broker, \u00e8 cambiato drasticamente. Poi abbiamo osservato che \u00e8 cambiata la frequenza di invio di un certo tipo di messaggi. Dopo abbiamo scoperto che si trattava di client Android. Abbiamo chiesto:<\/p>\n

\u2014 Ragazzi, cosa \u00e8 successo circa un mese e mezzo fa?<\/i><\/p>\n

In risposta, abbiamo sentito un'interessante storia su come abbiano riprogettato l'interfaccia utente. Difficilmente qualcuno potrebbe dire subito che \u00e8 stata cambiata la libreria HTTP. Per i clienti Android \u00e8 come cambiare il sapone nel bagno: semplicemente non lo ricordano. Alla fine, dopo 40 minuti di conversazione, abbiamo scoperto che avevano effettivamente cambiato la libreria HTTP, e che questa aveva modificato i tempi predefiniti. Questo ha portato a un cambiamento nel comportamento del traffico sul server API, il che ha causato una situazione che ha generato una corsa all'interno del broker, portando al suo crash.<\/p>\n

Senza un monitoraggio approfondito, \u00e8 praticamente impossibile individuarlo.<\/b>Se nell'organizzazione esiste anche il problema dei \u2018pozzi\u2019, dove ognuno scarica sugli altri, questo pu\u00f2 durare anni. Si riavvia semplicemente il server perch\u00e9 non \u00e8 possibile risolvere il problema. Quando monitori, tracci, segui tutti gli eventi che hai e utilizzi il monitoraggio come collaudo \u2014 scrivi il codice e subito indichi come monitorarlo, sempre sotto forma di codice (abbiamo gi\u00e0 un'infrastruttura come codice), tutto diventa chiaro come il palmo di una mano. Anche problemi cos\u00ec complessi possono essere facilmente tracciati.<\/p>\n

\"Cos'\u00e8
\n<\/p>\n

Raccogli tutte le informazioni su ci\u00f2 che accade all'artefatto in ogni fase del processo di consegna - non in produzione.<\/p><\/blockquote>\n

\nCarica il monitoraggio su CI, dove potrai gi\u00e0 vedere alcune informazioni di base. Poi li vedrai anche in Test, in PredProd e nei test di carico. Raccogli le informazioni in tutte le fasi, non solo metriche e statistiche, ma anche i log: come \u00e8 stata rilasciata l'applicazione, anomalie - raccogli tutto. <\/p>\n

In caso contrario, sar\u00e0 difficile capire. Ho gi\u00e0 detto che DevOps comporta maggiore complessit\u00e0. Per affrontare questa complessit\u00e0, \u00e8 necessario avere una buona analisi.<\/b>.<\/p>\n

Domande per l'autocontrollo.<\/h3>\n

\nIl tuo monitoraggio e logging sono strumenti di sviluppo per te?<\/b> I tuoi sviluppatori, e tu stesso, quando scrivono codice, pensano a come monitorarlo?<\/p>\n

Scopri i problemi dai clienti? Comprendi meglio il cliente dal monitoraggio e dal logging?<\/b> Comprendi meglio il sistema dal monitoraggio e dal logging?<\/b> Cambiate il sistema semplicemente perch\u00e9 vedete che la tendenza nel sistema sta aumentando e capite che fra 3 settimane tutto collasser\u00e0? <\/p>\n

Quando hai questi tre componenti, puoi iniziare a pensare a quale piattaforma infrastrutturale hai nella tua azienda.<\/p>\n

Piattaforma infrastrutturale <\/h2>\n

\nIl punto non \u00e8 che si tratti di un insieme di strumenti disgiunti, presenti in ogni azienda.<\/p>\n

Il senso della piattaforma infrastrutturale \u00e8 che tutte le squadre utilizzano questi strumenti e li sviluppano insieme.<\/p><\/blockquote>\n

\n\u00c8 chiaro che ci sono squadre separate che sono responsabili dello sviluppo di singoli pezzi della piattaforma infrastrutturale. Ma ogni ingegnere \u00e8 responsabile dello sviluppo, del funzionamento e della promozione della piattaforma infrastrutturale. A livello interno, questo diventa uno strumento comune<\/b>. <\/p>\n

Tutte le squadre sviluppano la piattaforma infrastrutturale, trattandola con cura come se fosse il proprio IDE.<\/b>. Nel tuo IDE installi vari plugin affinch\u00e9 tutto sia bello e veloce, e configuri le scorciatoie da tastiera. Quando apri Sublime, Atom o Visual Studio Code, ti trovi subito di fronte a errori nel codice e capisci che \u00e8 impossibile lavorare, ti senti subito gi\u00f9 e corri a sistemare il tuo IDE.<\/p>\n

Tratta la tua piattaforma infrastrutturale allo stesso modo. Se ti rendi conto che c'\u00e8 qualcosa che non va, invia una richiesta se non puoi risolvere il problema da solo. Se si tratta di un problema semplice, correggilo da solo e invia una pull request: il team la esaminer\u00e0 e l'aggiunger\u00e0. Questo rappresenta un approccio diverso agli strumenti ingegneristici nella mente dello sviluppatore.<\/p>\n

La piattaforma infrastrutturale garantisce il trasferimento dell'artefatto dallo sviluppo al cliente, con un costante miglioramento della qualit\u00e0.<\/b>Nella IP \u00e8 programmato un set di storie che si verificano con il codice in produzione. Negli anni di sviluppo, queste storie sono diventate numerose, molte di esse sono uniche e si riferiscono solo a te: non possono essere trovate su Google. <\/p>\n

A questo punto, la piattaforma infrastrutturale diventa il tuo vantaggio competitivo<\/b>, poich\u00e9 contiene ci\u00f2 che non \u00e8 presente nello strumento del concorrente. Pi\u00f9 profonda \u00e8 la tua IP, maggiore \u00e8 il tuo vantaggio competitivo in termini di Time-to-market. Qui emerge il problema del vendor lock.<\/b>Puoi adottare una piattaforma di qualcun altro, ma utilizzando l'esperienza altrui non capirai quanto sia rilevante per te. S\u00ec, non tutte le aziende possono costruire una piattaforma come Amazon. Si tratta di una sottile distinzione, in cui l'esperienza di un'azienda \u00e8 pertinente alla sua posizione di mercato, e non si pu\u00f2 abbattere il vendor lock. \u00c8 importante pensarci.<\/p>\n

Schema<\/h3>\n

\nQuesto \u00e8 uno schema di base per una piattaforma infrastrutturale che ti aiuter\u00e0 a organizzare tutte le pratiche e i processi in un'azienda DevOps.<\/p>\n

\"Cos'\u00e8
\n
\nEsaminiamo quali elementi la compongono.<\/p>\n

Sistema di orchestrazione delle risorse<\/b>, che fornisce CPU, memoria, disco alle applicazioni e ad altri servizi. Sopra questo c'\u00e8 servizi di basso livello<\/b>: monitoraggio, logging, CI\/CD Engine, archiviazione degli artefatti, infrastruttura come codice.<\/p>\n

Servizi di livello superiore<\/b>: database come servizio, code come servizio, Load Balance come servizio, ridimensionamento delle immagini come servizio, Big Data factory come servizio. Sopra questo c'\u00e8 un pipeline che fornisce codice costantemente modificato al tuo cliente.<\/b>.<\/p>\n

Ricevi informazioni su come il tuo software funziona per il cliente, apporta modifiche, fornisci nuovamente questo codice, ottieni feedback e sviluppa continuamente sia l'infrastruttura della piattaforma che il tuo software.<\/p>\n

Nello schema, la delivery pipeline \u00e8 composta da numerosi stadi. Ma \u00e8 uno schema fondamentale, presentato a titolo esemplificativo: non \u00e8 necessario replicarlo alla lettera. Gli stadi interagiscono con i servizi come servizi: ogni singolo mattoncino della piattaforma ha una propria storia: come vengono allocati le risorse, come l'applicazione viene avviata, come opera con le risorse, come viene monitorata e modificata.<\/p>\n

\u00c8 importante comprendere che ogni parte della piattaforma ha una storia, e porsi la domanda: quale storia racconta questo mattoncino? Forse vale la pena scartarlo e sostituirlo con un servizio esterno. Ad esempio, possiamo sostituire un mattoncino con Okmeter? \u00c8 possibile che loro abbiano gi\u00e0 sviluppato questa expertise molto pi\u00f9 di noi. Ma potrebbe anche non essere cos\u00ec: forse abbiamo un'expertise unica, e dobbiamo implementare Prometheus e svilupparlo ulteriormente.<\/p>\n

Creazione della piattaforma<\/h3>\n

\nSi tratta di un processo comunicativo complesso. Quando hai delle pratiche di base, avvii la comunicazione tra diversi ingegneri e specialisti che definiscono requisiti e standard, e li modificano continuamente in base a diversi strumenti e approcci. Qui la cultura che esiste in DevOps \u00e8 fondamentale.<\/p>\n

\"Cos'\u00e8
\nCon la cultura \u00e8 tutto molto semplice \u2014 \u00e8 collaborazione e comunicazione<\/b>, ovvero il desiderio di lavorare insieme in un campo comune, voglia di possedere uno strumento insieme. Non \u00e8 certo una rocket science \u2014 \u00e8 tutto molto semplice, banale. Ad esempio, viviamo tutti nello stesso condominio e ne manteniamo la pulizia \u2014 questo \u00e8 un livello di cultura.<\/p>\n

E voi?<\/h3>\n

\nDi nuovo domande che potete porvi.<\/p>\n

\u00c8 stata designata una piattaforma infrastrutturale? Chi \u00e8 responsabile del suo sviluppo? Comprendete i vantaggi competitivi della vostra piattaforma infrastrutturale?<\/p>\n

Queste domande devono essere poste continuamente. Se qualcosa pu\u00f2 essere esternalizzato a servizi di terze parti \u2014 \u00e8 necessario farlo; se un servizio esterno inizia a bloccare il vostro movimento, \u00e8 necessario costruire un sistema all'interno di s\u00e9.<\/p>\n

\u0418\u0442\u0430\u043a, DevOps…<\/h2>\n

\n\u2026 \u00e8 un sistema complesso, deve includere:<\/p>\n