{"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":"Che cos'\u00e8 DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La definizione di DevOps \u00e8 molto complessa, quindi si \u00e8 costretti a riavviare ogni volta la discussione su questo argomento. Solo su Habr ci sono migliaia di pubblicazioni su questo tema. Ma se stai leggendo questo, probabilmente sai gi\u00e0 cosa significa DevOps. Perch\u00e9 io non lo so. Ciao, mi chiamo Alessandro Titov (@osminog<\/a><\/noindex><\/b>), e parleremo semplicemente di DevOps e io condivider\u00f2 la mia esperienza.<\/p>\n

\"Che
\n
\nHo pensato a lungo su come rendere utile la mia storia, quindi ci saranno molte domande, quelle che io stesso mi pongo e quelle che faccio ai clienti della nostra azienda. Rispondendo a queste domande, la comprensione migliora. Ti dir\u00f2 a cosa serve DevOps dal mio punto di vista, che cos'\u00e8, ancora una volta dal mio punto di vista, e come capire se stai progredendo verso DevOps, sempre dal mio punto di vista. L'ultimo punto sar\u00e0 attraverso le domande. Rispondendo a queste domande, potrai capire se la tua azienda si sta dirigendo verso DevOps o se ci sono problemi.
\n<\/a><\/noindex>
\n

\r\n \"Guarda\r\n
<\/div>\r\n <\/div><\/center>
\nUn tempo ho navigato tra le onde delle fusioni e acquisizioni. All'inizio ho lavorato in una piccola startup chiamata Qik, poi \u00e8 stata acquistata da una societ\u00e0 un po' pi\u00f9 grande, Skype, che a sua volta \u00e8 stata acquistata da una azienda ancora pi\u00f9 grande, Microsoft. A questo punto ho cominciato a vedere come la percezione di DevOps si trasforma in aziende di diverse dimensioni. Da l\u00ec in poi, mi sono interessato a guardare DevOps dal punto di vista del mercato, e con i miei colleghi abbiamo fondato l'azienda Express 42. Gi\u00e0 da 6 anni ci muoviamo su queste onde di mercato.<\/p>\n

Oltre a tutto ci\u00f2, sono uno degli organizzatori della comunit\u00e0 DevOps Moscow e ho organizzato DevOps -Days 2017, ma nel 2018 non ho organizzato nulla. Express 42 lavora con molte aziende. Sviluppiamo DevOps l\u00ec, osserviamo come avviene, traiamo conclusioni, analizziamo e condividiamo le nostre intuizioni con tutti, formando le persone nelle pratiche DevOps. In generale, stiamo accrescendo in questo senso l'esperienza e l'esperienza.<\/p>\n

Perch\u00e9 DevOps<\/h2>\n

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

\u2014 Avevamo Continuous Integration, quindi c'era gi\u00e0 DevOps, e a cosa serve tutta questa confusione? L\u00ec all'estero si divertono, mentre a noi disturbano nel lavoro!<\/i><\/p>\n

Dopo 9 anni di sviluppo della comunit\u00e0 e della metodologia, \u00e8 gi\u00e0 chiaro che non si tratta di semplici scintillii di marketing, ma allo stesso tempo non \u00e8 ancora chiaro a cosa serva. Come per ogni strumento e processo, DevOps ha obiettivi specifici che alla fine risolve.<\/p>\n

Tutto questo \u00e8 legato al fatto che il mondo sta cambiando. Si sta allontanando dall'approccio enterprise, quando le aziende si dirigono verso un sogno, come cantava il nostro classico di San Pietroburgo, dal punto A al punto B secondo una strategia definita, con una struttura specificamente progettata per questo. <\/p>\n

\"Che
\n<\/p>\n

Fondamentalmente, in IT tutto dovrebbe essere costruito secondo questo approccio. Qui l'IT viene utilizzato esclusivamente per l'automazione dei processi.<\/p><\/blockquote>\n

\nL'automazione non cambia frequentemente, perch\u00e9 quando un'azienda segue un percorso gi\u00e0 tracciato\u2014cosa cambiare? Funziona\u2014non toccare. Ora nel mondo gli approcci stanno cambiando, e quello che viene chiamato Agile dice che il punto finale B non \u00e8 immediatamente visibile.<\/p>\n

\"Che
\n
\nQuando un'azienda si muove nel mercato, lavora con il cliente\u2014sta continuamente esplorando il mercato e cambiando il punto finale B. Inoltre, pi\u00f9 un'azienda cambia direzione, pi\u00f9 ha successo, perch\u00e9 sceglie pi\u00f9 nicchie di mercato.<\/p>\n

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

Questo prodotto \u00e8 stato acquistato dalla Unilever per 1 miliardo di dollari. Ora compete con Gillette e ha sottratto a quest'ultima una significativa quota di consumatori nel mercato americano. Dicono da One Box Shave:<\/p>\n

\u2014 4 lame? Sei serio? Perch\u00e9 hai bisogno di questo\u2014non migliora affatto la qualit\u00e0 della rasatura. Una crema specificamente selezionata, una fragranza e un rasoio di qualit\u00e0 con due lame risolvono molte pi\u00f9 questioni rispetto a queste stupide 4 lame Gillette! Cos\u00ec arriveremo presto a 10?<\/i><\/p>\n

E cos\u00ec il mondo cambia. La Unilever dichiara di avere un ottimo sistema IT che consente di farlo. Alla fine, questo appare come un concetto Time-to-market<\/b>, di cui chiunque ne abbia parlato.<\/p>\n

\"Che
\n
\nIl significato di Time-to-market non \u00e8 quanto spesso effettuiamo il deployment. Si pu\u00f2 fare il deployment frequentemente, ma i cicli di rilascio possono essere lunghi. Se sovrapponiamo cicli di rilascio di tre mesi uno sull'altro, spostandoli di una settimana, sembra che l'azienda si stia deployando ogni settimana. Ma dal momento dell'idea fino 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, One Box Shave interagisce con il cliente attraverso il sito. Non hanno venditori, solo un sito dove il visitatore clicca e lascia le proprie preferenze. Pertanto, \u00e8 necessario aggiornare costantemente il sito con nuove informazioni, in linea con queste preferenze. Ad esempio, in Corea del Sud si rade diversamente rispetto alla Russia, e apprezzano odori diversi, come ad esempio carota e vaniglia, piuttosto che il profumo di pino.<\/p>\n

Poich\u00e9 \u00e8 necessario modificare rapidamente il contenuto del sito, lo sviluppo del software cambia notevolmente. Attraverso il software dobbiamo scoprire cosa desidera il cliente. In passato lo scoprivamo attraverso vie indirette, come la gestione aziendale. Poi progettavamo, definendo i requisiti nel sistema IT, ed era tutto fantastico. Ora \u00e8 diverso: il software viene progettato da tutti coloro che sono coinvolti nel processo, compresi gli ingegneri, poich\u00e9 apprendono tramite le specifiche tecniche come funziona il mercato e condividono anche con il settore commerciale le loro intuizioni.<\/p>\n

Ad esempio, nella compagnia Qik abbiamo scoperto improvvisamente che alle persone piace molto caricare liste di contatti sul server, e ci hanno proposto un'applicazione. Inizialmente non avevamo considerato questa possibilit\u00e0. In una compagnia tradizionale, tutti avrebbero pensato che fosse un bug, poich\u00e9 nella specifica non era scritto che dovesse funzionare bene e in generale era stato realizzato in modo frettoloso. Avrebbero disattivato la funzionalit\u00e0 e avrebbero detto: 'Non serve a nessuno, l'importante \u00e8 che la funzionalit\u00e0 principale funzioni.' Ma un'azienda tecnologica vede in questo un'opportunit\u00e0 e inizia a modificare il software di conseguenza.<\/p>\n

\"Che
\n
\nNel 1968, l'illuminato Melvin Conway formul\u00f2 l'idea seguente.<\/p>\n

Un'organizzazione che crea un sistema \u00e8 limitata dal design che replica la struttura di comunicazione in questa organizzazione.<\/p><\/blockquote>\n

\nSe approfondiamo, per produrre sistemi di un altro tipo, \u00e8 necessario avere anche una struttura di comunicazione all'interno dell'azienda di un altro tipo. Se avete una struttura di comunicazione verticale, questo non vi permetter\u00e0 di creare sistemi che possano garantire un elevato indice di Time-to-market.<\/p>\n

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

Dal punto di vista del processo, prima del DevOps tutte le fasi: analisi, sviluppo, testing, operativit\u00e0, avvenivano in modo lineare.\"Che
\nNel caso del DevOps, tutti questi processi si svolgono contemporaneamente.<\/p>\n

\"Che
\n
\nIl Time-to-market pu\u00f2 essere rispettato solo in questo modo. Per le persone che hanno lavorato nel vecchio processo, questo appare un po' fantascientifico e, in generale, poco pratico.<\/p>\n

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

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

Il DevOps supera i limiti di velocit\u00e0 dello schema sequenziale di produzione software<\/b>. In esso, tutti i processi avvengono contemporaneamente.<\/p>\n

Aumenta la complessit\u00e0.<\/b> Quando gli evangelisti del DevOps dicono che con esso sar\u00e0 pi\u00f9 facile rilasciare software, \u00e8 una sciocchezza.<\/p>\n

Con il DevOps tutto sar\u00e0 solo pi\u00f9 complicato.<\/p><\/blockquote>\n

\nAlla conferenza, presso lo stand di Avito, si poteva vedere cosa significasse deployare un contenitore Docker: un compito irrealistico. La complessit\u00e0 diventa stratosferica, bisogna giocolare con molte palle contemporaneamente.<\/p>\n

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

Domande per lo specialista<\/h3>\n

\nE voi? Domande che potete porvi mentre lavorate in azienda e cresciete come professionisti.<\/p>\n

Avete una strategia per la creazione di un prodotto digitale?<\/b> Se c'\u00e8, \u00e8 gi\u00e0 un buon segno. Significa che la vostra azienda sta andando nella direzione del DevOps.<\/p>\n

La vostra azienda sta gi\u00e0 creando un prodotto digitale?<\/b> Questo significa che potete salire a un livello superiore, occupandovi di questioni pi\u00f9 interessanti \u2013 dal punto di vista del DevOps. Parlo solo da questo punto di vista.<\/p>\n

La vostra azienda \u00e8 uno dei leader di mercato nella nicchia dei prodotti digitali?<\/b> Spotify, Yandex, Uber \u2014 aziende che sono al vertice del progresso tecnologico attuale.<\/p>\n

Fatti queste domande e, se tutte le risposte sono negative, forse non dovresti occuparti di DevOps in questa azienda. Se invece il tema DevOps ti interessa veramente, forse\u2026 dovresti trasferirti in un'altra azienda? Se la tua azienda vuole approdare nel DevOps, ma a tutte le domande hai risposto 'No', allora ricorda questo bellissimo rinoceronte che non cambier\u00e0 mai.<\/p>\n

\"Che
\n<\/p>\n

L'Organizzazione<\/h2>\n

\nCome ho gi\u00e0 detto, secondo la legge di Conway, l'organizzazione dell'azienda cambia. Inizier\u00f2 con ci\u00f2 che impedisce al DevOps di penetrare all'interno dell'azienda proprio dal punto di vista dell'organizzazione.<\/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 nella propria area di competenza senza costruire una mappa comune in cui orientarsi.<\/p>\n

Questo ricorda un po' una persona che \u00e8 appena arrivata a Mosca e non sa ancora orientarsi sulla mappa della metropolitana. I moscoviti di solito conoscono benissimo il proprio quartiere, mentre si orientano nella grande Mosca tramite la mappa della metropolitana. Quando arrivi a Mosca per la prima volta, non hai queste competenze e sei completamente disorientato.<\/p>\n

Il DevOps propone di superare questo momento di disorientamento e di costruire insieme a tutti i dipartimenti una mappa dell'interazione comune.<\/p><\/blockquote>\n

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

Le conseguenze del sistema di gestione aziendale.<\/b> \u00c8 costruito su 'silos' gerarchici separati. Ad esempio, ci sono determinati KPI nelle aziende che supportano questo sistema. Dall'altro lato, ci sono le menti delle persone, che trovano difficile uscire al di fuori della propria area di competenza e orientarsi in tutto il sistema. \u00c8 semplicemente scomodo. Immagina di trovarti all'aeroporto di Bangkok \u2014 l\u00ec non ti orienti facilmente. Anche nel DevOps \u00e8 difficile orientarsi e per questo motivo le persone dicono che bisogna trovare una guida per entrarci.<\/p>\n

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

\u2014 Volevamo solo avviare il CI, ma \u00e8 risultato che alla direzione non serviva.<\/i><\/p>\n

Questo accade proprio a causa del\u00a0CI <\/b>e\u00a0processo di Continuous Delivery<\/b> che si trova al confine di molte competenze. Semplicemente, senza superare il problema dei \u00abpozzi\u00bb a livello organizzativo, non si riuscir\u00e0 ad andare avanti, qualsiasi cosa facciate e per quanto triste possa sembrare.<\/p>\n

\"Che
\n
\nOgni partecipante al processo in azienda: sviluppatori backend e frontend, testing, DBA, operazioni, rete, scava nella propria direzione, e nessuno ha una mappa comune, tranne il manager, che in qualche modo li osserva e gestisce con il metodo \u00abdividi e conquista\u00bb.<\/p>\n

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

\nAlla fine, quando arriva il momento di mettere tutto insieme e costruire un pipeline comune, e per le stelline e le bandierine non \u00e8 pi\u00f9 necessario combattere, sorge la domanda \u2013 e cosa dobbiamo fare esattamente? Dobbiamo in qualche modo metterci d'accordo, ma come si fa, a scuola nessuno ci ha insegnato. Siamo stati educati fin dalla scuola: l'ottavo grado \u2013 wow! \u2013 in confronto al settimo grado! Qui \u00e8 lo stesso.<\/p>\n

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

\nPer verificare questo, potete porvi le seguenti domande.<\/p>\n

Le squadre utilizzano strumenti comuni, contribuiscono alle modifiche di questi strumenti comuni?<\/p>\n

Quanto spesso i team vengono riorganizzati, con alcuni specialisti che passano da un team a un altro?<\/b> Questo sta diventando normale nell'ambiente DevOps, perch\u00e9 a volte una persona non riesce semplicemente a capire cosa fa un'altra area di competenza. Passa a un altro dipartimento, lavora l\u00ec per un paio di settimane per creare la propria mappa di orientamento e interazione con quel dipartimento.<\/p>\n

\u00c8 possibile creare un comitato per il cambiamento e modificare qualcosa? <\/b>Oppure per questo \u00e8 necessaria la mano forte della massima direzione e un ordine? Recentemente ho scritto su Facebook di come una banca poco conosciuta implementa strumenti attraverso ordini: abbiamo emesso un ordine, lo stiamo implementando da un anno, vediamo cosa succede. Questo, ovviamente, \u00e8 lungo e triste.<\/p>\n

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

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

Infrastruttura come codice<\/h2>\n

\nDopo aver superato questo problema, la prima pratica importante, senza la quale \u00e8 difficile progredire ulteriormente in DevOps, \u00e8 infrastruttura come codice<\/b>. <\/p>\n

Spesso l'infrastruttura come codice viene percepita in questo modo:<\/p>\n

\u2014 Automizziamo tutto su bash, ricopriamoci di script, cos\u00ec gli amministratori avranno meno lavoro manuale!<\/i><\/p>\n

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

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

\nInsieme ad altri team, crei una mappa sotto forma di codice, che \u00e8 chiara a tutti e dalla quale \u00e8 possibile orientarsi, navigare. Non importa su cosa sia fatto \u2014 Chef, Ansible, Salt, o se si utilizzano file YAML in Kubernetes \u2014 non fa differenza.<\/p>\n

A una conferenza, un collega di 2GIS ha raccontato come hanno realizzato il loro strumento interno per Kubernetes, che descrive il funzionamento di sistemi specifici. Per descrivere 500 sistemi, hanno necessitato di uno strumento speciale che genera tale descrizione. Quando c'\u00e8 questa descrizione, ognuno pu\u00f2 confrontarsi con gli altri, monitorare le modifiche, capire come modificarla e migliorarla, e cosa manca. <\/p>\n

Ammettiamolo, script bash separati di solito non offrono questa comprensione. In una delle aziende in cui ho lavorato, esisteva persino il termine \"script write only\" \u2014 quando lo script \u00e8 scritto, ma non \u00e8 pi\u00f9 leggibile. Credo che sia familiare anche a voi.<\/p>\n

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

Il codice \u00e8 accompagnato secondo le migliori pratiche lavorative col codice<\/b>: sviluppo collaborativo, code review, XP-programming, testing, pull request, CI per infrastrutture di codice \u2014 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

\nModificare l'infrastruttura nel codice non richiede molto tempo<\/b>. S\u00ec, anche nel codice infrastrutturale pu\u00f2 esserci debito tecnico. Di solito, i team si trovano ad affrontarlo circa un anno e mezzo dopo aver iniziato a implementare \"infrastruttura come codice\" sotto forma di una serie di script o persino Ansible, che scrivono come codice spaghetti, e aggiungono ancora script bash nella mistura! <\/p>\n

Importante<\/b>: se non hai ancora provato questa schifezza, ricorda che Ansible non \u00e8 bash<\/b>! Leggi attentamente la documentazione, studia cosa ne dicono.<\/p>\n

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

\nNoi nella nostra azienda definiamo 3 strati di base, che sono molto chiari e semplici, ma possono essercene di pi\u00f9. Puoi esaminare il tuo codice infrastrutturale e dire se hai o meno questa condizione. Se non ci sono strati distinti, \u00e8 necessario dedicare del tempo a rifattorizzare un po'.
\n\"Che
\n
\nStrato di base<\/b>\u00a0\u00e8 come viene configurato il sistema operativo, i backup e altre cose a basso livello, ad esempio, come viene distribuito Kubernetes a livello di base.<\/p>\n

Livello dei servizi<\/b>\u00a0sono i servizi che offri agli sviluppatori: logging come servizio, monitoraggio come servizio, database come servizio, bilanciatore come servizio, coda come servizio, Continuous Delivery come servizio\u2014una miriade di servizi che team distinti possono fornire allo sviluppo. Tutto questo deve essere descritto in moduli separati nel tuo sistema di gestione della configurazione.<\/p>\n

Strato, dove vengono creati le applicazioni<\/b> e si descrive come saranno distribuite sopra i due strati precedenti.<\/p>\n

Domande di controllo<\/h3>\n

\nHai nella tua azienda un repository infrastrutturale comune? Controllate il debito tecnico nell'infrastruttura? Utilizzi pratiche di sviluppo nel repository infrastrutturale? La tua infrastruttura \u00e8 suddivisa in strati? Puoi confrontarti con lo schema Base-service-APP. Quanto \u00e8 difficile apportare una modifica? <\/p>\n

Se hai riscontrato che apportare modifiche richiedeva un giorno e mezzo, significa che hai un debito tecnico e che devi affrontarlo. Sei proprio inciampato nei problemi del debito tecnico nel codice infrastrutturale. Ricordo molte storie simili, quando per cambiare qualche CCTL, dovevi riscrivere met\u00e0 del codice infrastrutturale, perch\u00e9 la creativit\u00e0 e il desiderio di automatizzare tutto hanno portato al fatto che ovunque era tutto incasinato, tutte le manopole erano nascoste, e bisognava rifattorizzare.<\/p>\n

Continuous Delivery<\/h2>\n

\nFacciamo un bilancio tra debito e credito. Prima appare una descrizione dell'infrastruttura, che pu\u00f2 essere piuttosto basilare. Non \u00e8 necessario descrivere tutto nei dettagli, ma \u00e8 richiesta una certa descrizione di base affinch\u00e9 tu possa lavorarci. Altrimenti, non \u00e8 chiaro su cosa costruire ulteriormente la consegna continua. Tutte queste pratiche si sviluppano simultaneamente quando arrivi a DevOps, ma bisogna partire dalla comprensione di ci\u00f2 che hai e come gestirlo. Questa \u00e8 proprio la pratica dell'infrastruttura come codice.<\/p>\n

Dopo aver capito cosa hai e come gestirlo, inizi a pensare a come inviare il codice dello sviluppatore il pi\u00f9 rapidamente possibile in produzione. Quello che intendo \u00e8 insieme allo sviluppatore \u2014 ricordiamoci del problema dei \"pozzi\", ovvero non lo fanno singole persone, ma un team.<\/p>\n

Quando eravamo con\u00a0Ivan Evtuovich<\/b> abbiamo visto il primo libro di Jez Humble<\/b> e un gruppo di autori \"Continuous Delivery\"<\/b>, pubblicato nel 2009, ci siamo soffermati a riflettere su come tradurre il suo titolo in russo. Volevamo tradurlo come \"Consegna continua\", ma, sfortunatamente, \u00e8 stato tradotto come \"Consegna ininterrotta\". Mi sembra che nel nostro titolo ci sia qualcosa di russo, con una certa energia.<\/p>\n

Conseguire in modo continuo significa<\/h3>\n

\nIl codice che si trova nel repository di produzione pu\u00f2 sempre essere lanciato in produzione<\/b>. Pu\u00f2 anche non essere lanciato, ma \u00e8 sempre pronto a farlo. Di conseguenza, scrivi sempre codice con un'inspiegabile sensazione di inquietudine alla base della colonna vertebrale. Questa sensazione spesso emerge quando rilasci codice infrastrutturale. Questa sensazione di inquietudine deve esserci \u2014 genera processi mentali che consentono di scrivere codice in modo leggermente diverso. Deve essere registrata nelle regole interne allo sviluppo.<\/p>\n

Per consegnare in modo continuo, \u00e8 necessario un formato di artefatto che passi attraverso la piattaforma infrastrutturale. <\/b>Se lanci rifiuti di formati diversi sulla piattaforma infrastrutturale, questa diventa non unificata, difficile da gestire, con il problema del debito tecnico. Il formato dell'artefatto deve essere uniformato \u2014 anche questo \u00e8 un compito collettivo: tutti devono riunirsi, mettersi a pensare e concepire questo formato.<\/p>\n

L'artefatto viene costantemente migliorato e cambiato in base all'ambiente di produzione durante il suo passaggio nel pipeline di distribuzione. <\/b>Quando l'artefatto si muove nel pipeline, incontra sempre alcune cose che gli risultano scomode, simili a quelle che affronta l'artefatto che stai distribuendo in produzione. Se nella sviluppo tradizionale questo compito \u00e8 svolto da un sistemista, che effettua il deployment, nel processo DevOps avviene costantemente: qui viene sottoposto a diversi test, l\u00ec \u00e8 stato inserito in un cluster Kubernetes, che \u00e8 pi\u00f9 o meno simile alla produzione, qui \u00e8 stata improvvisamente avviata una prova di carico.<\/p>\n

Questo ricorda un po' il gioco del Pac-Man: l'artefatto attraversa una certa storia. \u00c8 importante verificare se il codice attraversa effettivamente la storia e se \u00e8 in qualche modo correlato alla tua produzione. Le storie di produzione possono essere integrate nel processo di Continuous Delivery: \u00e8 successo che qualcosa sia andato storto, ora programmiamo semplicemente questo scenario all'interno del sistema. Ogni volta il codice passer\u00e0 anche attraverso questo scenario, e non ti troverai pi\u00f9 ad affrontare questo problema. Verr\u00e0 a galla molto prima, rispetto a quando si presenter\u00e0 al tuo cliente.<\/p>\n

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

\"Consegna continua\" appare cos\u00ec.<\/p>\n

\"Che
\n<\/p>\n

Il processo di distribuzione Dev, CI, Test, PreProd, Prod non \u00e8 un ambiente separato, ma fasi o stazioni con somme non combustibili, in cui il tuo artefatto passa.<\/p><\/blockquote>\n

\nSe hai codice infrastrutturale descritto come Base Service APP, esso aiuta a non dimenticare tutti gli scenari<\/b>, e a registrarli anche come codice per questo artefatto, a promuovere l'artefatto<\/b> e a modificarlo nel corso del tempo.<\/p>\n

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

\nIl tempo che intercorre dalla descrizione della funzione al deployment in produzione \u00e8 inferiore a una settimana nel 95% dei casi? La qualit\u00e0 dell'artefatto migliora ad ogni fase del pipeline? C'\u00e8 una storia attraverso la quale passa? Stai utilizzando diverse strategie di deployment?<\/p>\n

Se tutte le risposte sono s\u00ec, allora sei incredibilmente bravo! Scrivi le risposte nei commenti - sar\u00f2 felice di leggerle).<\/p>\n

Feedback<\/h3>\n

\nQuesta \u00e8 la pratica pi\u00f9 complessa di tutte. Durante la conferenza DevOpsConf, un collega di Infobip, parlando di essa, si \u00e8 un po' confuso con le parole, perch\u00e9 \u00e8 davvero una pratica molto complessa riguardo a cosa bisogna monitorare in generale tutto!<\/p>\n

\"Che
\n
\nAd esempio, tanto tempo fa, quando lavoravo in Qik e abbiamo capito che dovevamo monitorare tutto. Lo abbiamo fatto, e in Zabbix ci sono apparsi 150.000 items, che vengono monitorati costantemente. Era spaventoso, il direttore tecnico si girava il dito alla tempia:<\/p>\n

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

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

Ha iniziato a cadere costantemente uno dei servizi. Inizialmente non cadeva, il che \u00e8 interessante, il codice non veniva modificato perch\u00e9 era un broker di base, in cui praticamente non c'era funzionalit\u00e0 aziendale: semplicemente trasmetteva messaggi tra diversi servizi. Il servizio non \u00e8 cambiato per 4 mesi, e all'improvviso ha iniziato a cadere con l'errore \u00abSegmentation fault\u00bb.<\/p>\n

Eravamo in shock, abbiamo aperto i nostri grafici in Zabbix e abbiamo scoperto che, a quanto pare, circa due settimane fa il comportamento delle richieste nel servizio API che utilizza questo broker era cambiato significativamente. Poi abbiamo visto che era cambiata la frequenza di invio di un certo tipo di messaggi. Abbiamo scoperto che si trattava di client Android. Abbiamo chiesto:<\/p>\n

\u2014 Ragazzi, cosa \u00e8 successo circa due settimane fa?<\/i><\/p>\n

In risposta abbiamo sentito una storia interessante sul fatto che avevano rifatto l'UI. Difficilmente qualcuno dir\u00e0 subito che hanno cambiato la libreria HTTP. Per i client Android \u00e8 come cambiare il sapone in bagno: semplicemente non lo ricordano. Alla fine, dopo 40 minuti di conversazione, abbiamo scoperto che avevano effettivamente cambiato la libreria HTTP, e i suoi tempi predefiniti erano cambiati. Questo ha portato a un cambiamento nel comportamento del traffico sul server API, che ha causato la situazione che ha scatenato una corsa all'interno del broker, e ha iniziato a cadere.<\/p>\n

Senza un monitoraggio approfondito, questo \u00e8 davvero impossibile da rilevare<\/b>. Se nella vostra organizzazione c'\u00e8 ancora il problema dei \"pozzi\", dove ognuno scarica responsabilit\u00e0 sugli altri, questo pu\u00f2 durare anni. \u00c8 solo un riavvio del server, perch\u00e9 non \u00e8 possibile risolvere il problema. Quando monitorate, seguite e tracciate tutti gli eventi che avete, e usate il monitoraggio come test - scrivete il codice e indicate subito come monitorarlo, anche in forma di codice (abbiamo gi\u00e0 l'infrastruttura come codice), tutto diventa chiaro come il palmo della mano. Anche problemi complessi sono facilmente tracciabili.<\/p>\n

\"Che
\n<\/p>\n

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

\nCaricate il monitoraggio su CI, e l\u00ec gi\u00e0 appariranno alcune cose di base. Poi le vedrete sia in Test, che in PredProd, e nel test di carico. Raccogliete informazioni in tutte le fasi, non solo metriche e statistiche, ma anche log: come \u00e8 stato rilasciato l'applicativo, anomalie - raccogliete tutto. <\/p>\n

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

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

\nIl vostro monitoraggio e logging sono strumenti di sviluppo per voi?<\/b> I vostri sviluppatori, compreso voi, quando scrivono codice, pensano a come monitorarlo?<\/p>\n

Scoprite i problemi dai clienti? Comprendete meglio il cliente tramite il monitoraggio e il logging?<\/b> Capite meglio il sistema tramite il monitoraggio e il logging?<\/b> Modificate il sistema solo perch\u00e9 avete visto che una tendenza nel sistema sta crescendo e capite che tra 3 settimane tutto collasser\u00e0? <\/p>\n

Quando avete questi tre componenti, potete riflettere su quale sia la vostra piattaforma infrastrutturale in azienda.<\/p>\n

Piattaforma infrastrutturale <\/h2>\n

\nIl punto non \u00e8 che si tratta di un insieme di strumenti disconnessi, che si trovano in ogni azienda.<\/p>\n

Il senso della piattaforma infrastrutturale \u00e8 che tutti i team usano questi strumenti e li sviluppano insieme.<\/p><\/blockquote>\n

\n\u00c8 chiaro che ci sono team separati che sono responsabili dello sviluppo di singoli pezzi della piattaforma infrastrutturale. Ma la responsabilit\u00e0 dello sviluppo, della funzionalit\u00e0 e della promozione della piattaforma infrastrutturale \u00e8 di ogni ingegnere. A livello interno, questo diventa uno strumento comune.<\/b>. <\/p>\n

Tutti i team sviluppano la piattaforma infrastrutturale, trattandola con cura come un proprio IDE.<\/b>. Nel tuo IDE installi vari plugin per avere tutto bello e veloce, configurando le scorciatoie da tastiera. Quando apri Sublime, Atom o Visual Studio Code, ricevi errori di codice e capisci che \u00e8 impossibile lavorare, ti senti subito gi\u00f9 e corri a sistemare il tuo IDE.<\/p>\n

Allo stesso modo, tratta la tua piattaforma infrastrutturale. Se capisci che c'\u00e8 qualcosa che non va, invia una richiesta se non riesci a sistemarlo da solo. Se si tratta di qualcosa di semplice, sistemandolo autonomamente, invia una pull request: i ragazzi esamineranno e aggiungeranno. \u00c8 un approccio diverso rispetto agli strumenti ingegneristici nella mente dello sviluppatore.<\/p>\n

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

In questo momento la piattaforma infrastrutturale diventa il tuo vantaggio competitivo.<\/b>, perch\u00e9 contiene ci\u00f2 che non \u00e8 presente nello strumento del concorrente. Pi\u00f9 profonda \u00e8 la tua piattaforma infrastrutturale, maggiore \u00e8 il tuo vantaggio competitivo in termini di Time-to-market. Qui sorge 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. \u00c8 una linea sottile, dove l'esperienza di un'azienda \u00e8 pertinente alla sua posizione sul mercato, e non si pu\u00f2 consentire il vendor lock. \u00c8 importante considerare anche questo.<\/p>\n

Schema<\/h3>\n

\nQuesto \u00e8 lo schema di base della piattaforma infrastrutturale, che ti aiuter\u00e0 a stabilire tutte le pratiche e i processi nella tua azienda DevOps.<\/p>\n

\"Che
\n
\nAnalizziamo di cosa \u00e8 composta.<\/p>\n

Il sistema di orchestrazione delle risorse<\/b>, che fornisce CPU, memoria e disco alle applicazioni e ad altri servizi. Sopra di esso ci sono servizi di basso livello<\/b>: monitoraggio, registrazione, motore CI\/CD, archiviazione degli artefatti, infrastruttura come codice dei sistemi.<\/p>\n

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

Ricevi informazioni su come il tuo software funziona presso il cliente, apporti modifiche, fornisci di nuovo quel codice, ottieni informazioni - e cos\u00ec sviluppi costantemente sia la tua piattaforma infrastrutturale che il tuo software.<\/p>\n

Nello schema, il delivery pipeline consiste in molti stadi. Ma \u00e8 uno schema principe, presentato come esempio - non \u00e8 necessario replicarlo alla lettera. Gli stadi interagiscono con i servizi, proprio come servizi - ogni mattoncino della piattaforma porta la sua storia: come vengono allocate le risorse, come l'applicazione viene avviata, lavora con le risorse, viene monitorata, e viene cambiata.<\/p>\n

\u00c8 importante comprendere che ogni parte della piattaforma porta una storia e chiedersi - quale storia porta questo mattoncino, forse vale la pena eliminarlo e sostituirlo con un servizio esterno. Ad esempio, si pu\u00f2 mettere Okmeter al posto di un mattoncino? Forse i ragazzi hanno gi\u00e0 sviluppato questa competenza molto di pi\u00f9 di noi. Ma potrebbe anche non essere cos\u00ec - magari abbiamo competenze uniche, dobbiamo aggiungere Prometheus e svilupparlo ulteriormente.<\/p>\n

Creazione della piattaforma<\/h3>\n

\n\u00c8 un processo di comunicazione complesso. Quando hai pratiche di base, avvii una comunicazione tra diversi ingegneri e specialisti che sviluppano requisiti e standard, e li modificano costantemente rispetto a diversi strumenti e approcci. Qui la cultura \u00e8 fondamentale, quella che esiste in DevOps.<\/p>\n

\"Che
\nCon la cultura \u00e8 tutto molto semplice - \u00e8 collaborazione e comunicazione<\/b>, cio\u00e8 la volont\u00e0 di lavorare insieme in un campo comune, la volont\u00e0 di utilizzare uno strumento condiviso. Non c'\u00e8 niente di complesso - \u00e8 tutto molto semplice, banale. Ad esempio, viviamo tutti nello stesso condominio e manteniamo la sua pulizia - questo \u00e8 il livello di cultura.<\/p>\n

E voi?<\/h3>\n

\nDi nuovo domande che puoi porti.<\/p>\n

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

Queste domande devono essere costantemente poste. Se qualcosa pu\u00f2 essere esternalizzato a servizi esterni, bisogna farlo; se un servizio esterno inizia a ostacolare il tuo movimento, allora \u00e8 necessario costruire un sistema all'interno di s\u00e9 stessi.<\/p>\n

Quindi, DevOps\u2026<\/h2>\n

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