La definizione di DevOps è molto complessa, quindi si è 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à cosa significa DevOps. Perché io non lo so. Ciao, mi chiamo Alessandro Titov (@), e parleremo semplicemente di DevOps e io condividerò la mia esperienza.
Ho 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ò a cosa serve DevOps dal mio punto di vista, che cos'è, 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à attraverso le domande. Rispondendo a queste domande, potrai capire se la tua azienda si sta dirigendo verso DevOps o se ci sono problemi.
Un tempo ho navigato tra le onde delle fusioni e acquisizioni. All'inizio ho lavorato in una piccola startup chiamata Qik, poi è stata acquistata da una società un po' più grande, Skype, che a sua volta è stata acquistata da una azienda ancora più grande, Microsoft. A questo punto ho cominciato a vedere come la percezione di DevOps si trasforma in aziende di diverse dimensioni. Da lì 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à da 6 anni ci muoviamo su queste onde di mercato.
Oltre a tutto ciò, sono uno degli organizzatori della comunità DevOps Moscow e ho organizzato DevOps -Days 2017, ma nel 2018 non ho organizzato nulla. Express 42 lavora con molte aziende. Sviluppiamo DevOps lì, 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.
Perché DevOps
La prima domanda che perseguita tutti e sempre è: perché? Molti pensano che DevOps sia semplicemente automazione o qualcosa di simile, che era già presente in ogni azienda.
— Avevamo Continuous Integration, quindi c'era già DevOps, e a cosa serve tutta questa confusione? Lì all'estero si divertono, mentre a noi disturbano nel lavoro!
Dopo 9 anni di sviluppo della comunità e della metodologia, è già chiaro che non si tratta di semplici scintillii di marketing, ma allo stesso tempo non è ancora chiaro a cosa serva. Come per ogni strumento e processo, DevOps ha obiettivi specifici che alla fine risolve.
Tutto questo è 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.
Fondamentalmente, in IT tutto dovrebbe essere costruito secondo questo approccio. Qui l'IT viene utilizzato esclusivamente per l'automazione dei processi.
L'automazione non cambia frequentemente, perché quando un'azienda segue un percorso già tracciato—cosa cambiare? Funziona—non toccare. Ora nel mondo gli approcci stanno cambiando, e quello che viene chiamato Agile dice che il punto finale B non è immediatamente visibile.
Quando un'azienda si muove nel mercato, lavora con il cliente—sta continuamente esplorando il mercato e cambiando il punto finale B. Inoltre, più un'azienda cambia direzione, più ha successo, perché sceglie più nicchie di mercato.
Una strategia è dimostrata da un'azienda interessante che ho recentemente scoperto. One Box Shave è 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 è gestito da un software specifico che poi inoltra l'ordine a una fabbrica coreana che produce il prodotto.
Questo prodotto è 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:
— 4 lame? Sei serio? Perché hai bisogno di questo—non migliora affatto la qualità della rasatura. Una crema specificamente selezionata, una fragranza e un rasoio di qualità con due lame risolvono molte più questioni rispetto a queste stupide 4 lame Gillette! Così arriveremo presto a 10?
E così 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, di cui chiunque ne abbia parlato.
Il significato di Time-to-market non è quanto spesso effettuiamo il deployment. Si può 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.
Il Time-to-market riguarda la minimizzazione del tempo dall'idea alla realizzazione finale.
In questo caso, il software interagisce con il mercato. Così, 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, è 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.
Poiché è 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 è diverso: il software viene progettato da tutti coloro che sono coinvolti nel processo, compresi gli ingegneri, poiché apprendono tramite le specifiche tecniche come funziona il mercato e condividono anche con il settore commerciale le loro intuizioni.
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à. In una compagnia tradizionale, tutti avrebbero pensato che fosse un bug, poiché nella specifica non era scritto che dovesse funzionare bene e in generale era stato realizzato in modo frettoloso. Avrebbero disattivato la funzionalità e avrebbero detto: 'Non serve a nessuno, l'importante è che la funzionalità principale funzioni.' Ma un'azienda tecnologica vede in questo un'opportunità e inizia a modificare il software di conseguenza.
Nel 1968, l'illuminato Melvin Conway formulò l'idea seguente.
Un'organizzazione che crea un sistema è limitata dal design che replica la struttura di comunicazione in questa organizzazione.
Se approfondiamo, per produrre sistemi di un altro tipo, è 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à di creare sistemi che possano garantire un elevato indice di Time-to-market.
Leggere è possibile . È importante per comprendere la cultura o la filosofia del DevOps, poiché l'unica cosa che cambia fondamentalmente nel DevOps è proprio la struttura della comunicazione tra i team.
Dal punto di vista del processo, prima del DevOps tutte le fasi: analisi, sviluppo, testing, operatività, avvenivano in modo lineare.
Nel caso del DevOps, tutti questi processi si svolgono contemporaneamente.
Il Time-to-market può 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.
Allora, a cosa serve il DevOps?
Per lo sviluppo di prodotti digitali. Se nella vostra azienda non c'è un prodotto digitale, il DevOps non è necessario – è molto importante.
Il DevOps supera i limiti di velocità dello schema sequenziale di produzione software. In esso, tutti i processi avvengono contemporaneamente.
Aumenta la complessità. Quando gli evangelisti del DevOps dicono che con esso sarà più facile rilasciare software, è una sciocchezza.
Con il DevOps tutto sarà solo più complicato.
Alla conferenza, presso lo stand di Avito, si poteva vedere cosa significasse deployare un contenitore Docker: un compito irrealistico. La complessità diventa stratosferica, bisogna giocolare con molte palle contemporaneamente.
Il DevOps cambia completamente il processo e l'organizzazione in azienda — più precisamente, non è il DevOps a cambiare, ma il prodotto digitale. Per arrivare al DevOps, è comunque necessario cambiare completamente questo processo.
Domande per lo specialista
E voi? Domande che potete porvi mentre lavorate in azienda e cresciete come professionisti.
Avete una strategia per la creazione di un prodotto digitale? Se c'è, è già un buon segno. Significa che la vostra azienda sta andando nella direzione del DevOps.
La vostra azienda sta già creando un prodotto digitale? Questo significa che potete salire a un livello superiore, occupandovi di questioni più interessanti – dal punto di vista del DevOps. Parlo solo da questo punto di vista.
La vostra azienda è uno dei leader di mercato nella nicchia dei prodotti digitali? Spotify, Yandex, Uber — aziende che sono al vertice del progresso tecnologico attuale.
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… 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à mai.
L'Organizzazione
Come ho già detto, secondo la legge di Conway, l'organizzazione dell'azienda cambia. Inizierò con ciò che impedisce al DevOps di penetrare all'interno dell'azienda proprio dal punto di vista dell'organizzazione.
Il problema dei 'silos'
La parola inglese 'Silo' è tradotta qui in russo come 'колодец'. Il senso di questo problema è che non c'è scambio di informazioni tra i team. Ogni team scava nella propria area di competenza senza costruire una mappa comune in cui orientarsi.
Questo ricorda un po' una persona che è 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.
Il DevOps propone di superare questo momento di disorientamento e di costruire insieme a tutti i dipartimenti una mappa dell'interazione comune.
Due fattori ostacolano questo.
Le conseguenze del sistema di gestione aziendale. È 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. È semplicemente scomodo. Immagina di trovarti all'aeroporto di Bangkok — lì non ti orienti facilmente. Anche nel DevOps è difficile orientarsi e per questo motivo le persone dicono che bisogna trovare una guida per entrarci.
Ma la cosa più importante è 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'. Spesso ci riuniamo dopo DevOps Moscow, parliamo tra di noi e le persone si lamentano:
— Volevamo solo avviare il CI, ma è risultato che alla direzione non serviva.
Questo accade proprio a causa del CI e processo di Continuous Delivery che si trova al confine di molte competenze. Semplicemente, senza superare il problema dei «pozzi» a livello organizzativo, non si riuscirà ad andare avanti, qualsiasi cosa facciate e per quanto triste possa sembrare.
Ogni 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 «dividi e conquista».
Le persone lottano per qualche stellina o bandierina, ognuno scava nella propria competenza.
Alla fine, quando arriva il momento di mettere tutto insieme e costruire un pipeline comune, e per le stelline e le bandierine non è più necessario combattere, sorge la domanda – 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 – wow! – in confronto al settimo grado! Qui è lo stesso.
È così anche nella vostra azienda?
Per verificare questo, potete porvi le seguenti domande.
Le squadre utilizzano strumenti comuni, contribuiscono alle modifiche di questi strumenti comuni?
Con quale frequenza le squadre si riorganizzano – alcuni specialisti da una squadra passano a un'altra? Nella cultura DevOps questo sta diventando normale, perché a volte una persona semplicemente non riesce a capire di cosa si occupa un'altra area di competenza. Cambia dipartimento, lavora lì per un paio di settimane, per creare per se stessa una mappa di orientamento e interazione con quel dipartimento.
È possibile creare un comitato per il cambiamento e modificare qualcosa? Oppure per questo è 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, è lungo e triste.
Quanto è importante per i manager ottenere successi personali senza considerare i successi dell'azienda?
Se rispondete a queste domande, sarà più chiaro se avete questo problema in azienda.
Infrastruttura come codice
Dopo aver superato questo problema, la prima pratica importante, senza la quale è difficile progredire ulteriormente in DevOps, è infrastruttura come codice.
Spesso l'infrastruttura come codice viene percepita in questo modo:
— Automizziamo tutto su bash, ricopriamoci di script, così gli amministratori avranno meno lavoro manuale!
Ma non è così.
L'infrastruttura come codice implica che il sistema IT con cui lavori venga descritto sotto forma di codice, per comprendere costantemente il suo stato.
Insieme ad altri team, crei una mappa sotto forma di codice, che è chiara a tutti e dalla quale è possibile orientarsi, navigare. Non importa su cosa sia fatto — Chef, Ansible, Salt, o se si utilizzano file YAML in Kubernetes — non fa differenza.
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'è questa descrizione, ognuno può confrontarsi con gli altri, monitorare le modifiche, capire come modificarla e migliorarla, e cosa manca.
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" — quando lo script è scritto, ma non è più leggibile. Credo che sia familiare anche a voi.
L'infrastruttura come codice è codice che descrive lo stato attuale dell'infrastruttura. Su questo codice collaborano numerosi team di prodotto, infrastruttura e servizi, e, cosa più importante, tutti devono capire come funziona questo codice.
Il codice è accompagnato secondo le migliori pratiche lavorative col codice: sviluppo collaborativo, code review, XP-programming, testing, pull request, CI per infrastrutture di codice — tutto ciò è valido e può essere utilizzato.
Il codice diventa un linguaggio comune per tutti gli ingegneri.
Modificare l'infrastruttura nel codice non richiede molto tempo. Sì, anche nel codice infrastrutturale può 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!
Importante: se non hai ancora provato questa schifezza, ricorda che Ansible non è bash! Leggi attentamente la documentazione, studia cosa ne dicono.
L'infrastruttura come codice è la separazione del codice infrastrutturale in strati distinti.
Noi nella nostra azienda definiamo 3 strati di base, che sono molto chiari e semplici, ma possono essercene di più. Puoi esaminare il tuo codice infrastrutturale e dire se hai o meno questa condizione. Se non ci sono strati distinti, è necessario dedicare del tempo a rifattorizzare un po'.
Strato di base è come viene configurato il sistema operativo, i backup e altre cose a basso livello, ad esempio, come viene distribuito Kubernetes a livello di base.
Livello dei servizi sono 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—una 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.
Strato, dove vengono creati le applicazioni e si descrive come saranno distribuite sopra i due strati precedenti.
Domande di controllo
Hai nella tua azienda un repository infrastrutturale comune? Controllate il debito tecnico nell'infrastruttura? Utilizzi pratiche di sviluppo nel repository infrastrutturale? La tua infrastruttura è suddivisa in strati? Puoi confrontarti con lo schema Base-service-APP. Quanto è difficile apportare una modifica?
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à del codice infrastrutturale, perché la creatività e il desiderio di automatizzare tutto hanno portato al fatto che ovunque era tutto incasinato, tutte le manopole erano nascoste, e bisognava rifattorizzare.
Continuous Delivery
Facciamo un bilancio tra debito e credito. Prima appare una descrizione dell'infrastruttura, che può essere piuttosto basilare. Non è necessario descrivere tutto nei dettagli, ma è richiesta una certa descrizione di base affinché tu possa lavorarci. Altrimenti, non è 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ò che hai e come gestirlo. Questa è proprio la pratica dell'infrastruttura come codice.
Dopo aver capito cosa hai e come gestirlo, inizi a pensare a come inviare il codice dello sviluppatore il più rapidamente possibile in produzione. Quello che intendo è insieme allo sviluppatore — ricordiamoci del problema dei "pozzi", ovvero non lo fanno singole persone, ma un team.
Quando eravamo con Ivan Evtuovich abbiamo visto il primo libro di Jez Humble e un gruppo di autori "Continuous Delivery", pubblicato nel 2009, ci siamo soffermati a riflettere su come tradurre il suo titolo in russo. Volevamo tradurlo come "Consegna continua", ma, sfortunatamente, è stato tradotto come "Consegna ininterrotta". Mi sembra che nel nostro titolo ci sia qualcosa di russo, con una certa energia.
Conseguire in modo continuo significa
Il codice che si trova nel repository di produzione può sempre essere lanciato in produzione. Può anche non essere lanciato, ma è 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 — genera processi mentali che consentono di scrivere codice in modo leggermente diverso. Deve essere registrata nelle regole interne allo sviluppo.
Per consegnare in modo continuo, è necessario un formato di artefatto che passi attraverso la piattaforma infrastrutturale. 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 — anche questo è un compito collettivo: tutti devono riunirsi, mettersi a pensare e concepire questo formato.
L'artefatto viene costantemente migliorato e cambiato in base all'ambiente di produzione durante il suo passaggio nel pipeline di distribuzione. 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 è svolto da un sistemista, che effettua il deployment, nel processo DevOps avviene costantemente: qui viene sottoposto a diversi test, lì è stato inserito in un cluster Kubernetes, che è più o meno simile alla produzione, qui è stata improvvisamente avviata una prova di carico.
Questo ricorda un po' il gioco del Pac-Man: l'artefatto attraversa una certa storia. È importante verificare se il codice attraversa effettivamente la storia e se è in qualche modo correlato alla tua produzione. Le storie di produzione possono essere integrate nel processo di Continuous Delivery: è successo che qualcosa sia andato storto, ora programmiamo semplicemente questo scenario all'interno del sistema. Ogni volta il codice passerà anche attraverso questo scenario, e non ti troverai più ad affrontare questo problema. Verrà a galla molto prima, rispetto a quando si presenterà al tuo cliente.
Diverse strategie di deployment. 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.
"Consegna continua" appare così.
Il processo di distribuzione Dev, CI, Test, PreProd, Prod non è un ambiente separato, ma fasi o stazioni con somme non combustibili, in cui il tuo artefatto passa.
Se hai codice infrastrutturale descritto come Base Service APP, esso aiuta a non dimenticare tutti gli scenari, e a registrarli anche come codice per questo artefatto, a promuovere l'artefatto e a modificarlo nel corso del tempo.
Domande per l'autovalutazione
Il tempo che intercorre dalla descrizione della funzione al deployment in produzione è inferiore a una settimana nel 95% dei casi? La qualità dell'artefatto migliora ad ogni fase del pipeline? C'è una storia attraverso la quale passa? Stai utilizzando diverse strategie di deployment?
Se tutte le risposte sono sì, allora sei incredibilmente bravo! Scrivi le risposte nei commenti - sarò felice di leggerle).
Feedback
Questa è la pratica più complessa di tutte. Durante la conferenza DevOpsConf, un collega di Infobip, parlando di essa, si è un po' confuso con le parole, perché è davvero una pratica molto complessa riguardo a cosa bisogna monitorare in generale tutto!
Ad 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:
— Ragazzi, perché state torturando il server con cose incomprensibili?
Ma poi è successo un episodio che ha dimostrato che è davvero una strategia molto interessante.
Ha iniziato a cadere costantemente uno dei servizi. Inizialmente non cadeva, il che è interessante, il codice non veniva modificato perché era un broker di base, in cui praticamente non c'era funzionalità aziendale: semplicemente trasmetteva messaggi tra diversi servizi. Il servizio non è cambiato per 4 mesi, e all'improvviso ha iniziato a cadere con l'errore «Segmentation fault».
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:
— Ragazzi, cosa è successo circa due settimane fa?
In risposta abbiamo sentito una storia interessante sul fatto che avevano rifatto l'UI. Difficilmente qualcuno dirà subito che hanno cambiato la libreria HTTP. Per i client Android è 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.
Senza un monitoraggio approfondito, questo è davvero impossibile da rilevare. Se nella vostra organizzazione c'è ancora il problema dei "pozzi", dove ognuno scarica responsabilità sugli altri, questo può durare anni. È solo un riavvio del server, perché non è 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à l'infrastruttura come codice), tutto diventa chiaro come il palmo della mano. Anche problemi complessi sono facilmente tracciabili.
Raccogliete tutte le informazioni su ciò che accade con l'artefatto ad ogni fase del processo di consegna - non in produzione.
Caricate il monitoraggio su CI, e lì già 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 è stato rilasciato l'applicativo, anomalie - raccogliete tutto.
In caso contrario, sarà difficile capire. Ho già detto che DevOps è una maggiore complessità. Per affrontare questa complessità, è necessario avere un'analisi adeguata..
Domande per l'autocontrollo.
Il vostro monitoraggio e logging sono strumenti di sviluppo per voi? I vostri sviluppatori, compreso voi, quando scrivono codice, pensano a come monitorarlo?
Scoprite i problemi dai clienti? Comprendete meglio il cliente tramite il monitoraggio e il logging? Capite meglio il sistema tramite il monitoraggio e il logging? Modificate il sistema solo perché avete visto che una tendenza nel sistema sta crescendo e capite che tra 3 settimane tutto collasserà?
Quando avete questi tre componenti, potete riflettere su quale sia la vostra piattaforma infrastrutturale in azienda.
Piattaforma infrastrutturale
Il punto non è che si tratta di un insieme di strumenti disconnessi, che si trovano in ogni azienda.
Il senso della piattaforma infrastrutturale è che tutti i team usano questi strumenti e li sviluppano insieme.
È chiaro che ci sono team separati che sono responsabili dello sviluppo di singoli pezzi della piattaforma infrastrutturale. Ma la responsabilità dello sviluppo, della funzionalità e della promozione della piattaforma infrastrutturale è di ogni ingegnere. A livello interno, questo diventa uno strumento comune..
Tutti i team sviluppano la piattaforma infrastrutturale, trattandola con cura come un proprio IDE.. 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 è impossibile lavorare, ti senti subito giù e corri a sistemare il tuo IDE.
Allo stesso modo, tratta la tua piattaforma infrastrutturale. Se capisci che c'è 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. È un approccio diverso rispetto agli strumenti ingegneristici nella mente dello sviluppatore.
La piattaforma infrastrutturale garantisce il trasferimento dell'artefatto dallo sviluppo al cliente con un costante incremento della qualità.. Nella piattaforma infrastrutturale è 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.
In questo momento la piattaforma infrastrutturale diventa il tuo vantaggio competitivo., perché contiene ciò che non è presente nello strumento del concorrente. Più profonda è la tua piattaforma infrastrutturale, maggiore è il tuo vantaggio competitivo in termini di Time-to-market. Qui sorge il problema del vendor lock: puoi adottare una piattaforma di qualcun altro, ma utilizzando l'esperienza altrui, non capirai quanto sia rilevante per te. Sì, non tutte le aziende possono costruire una piattaforma come Amazon. È una linea sottile, dove l'esperienza di un'azienda è pertinente alla sua posizione sul mercato, e non si può consentire il vendor lock. È importante considerare anche questo.
Schema
Questo è lo schema di base della piattaforma infrastrutturale, che ti aiuterà a stabilire tutte le pratiche e i processi nella tua azienda DevOps.
Analizziamo di cosa è composta.
Il sistema di orchestrazione delle risorse, che fornisce CPU, memoria e disco alle applicazioni e ad altri servizi. Sopra di esso ci sono servizi di basso livello: monitoraggio, registrazione, motore CI/CD, archiviazione degli artefatti, infrastruttura come codice dei sistemi.
Servizi di livello superiore.: 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.
Ricevi informazioni su come il tuo software funziona presso il cliente, apporti modifiche, fornisci di nuovo quel codice, ottieni informazioni - e così sviluppi costantemente sia la tua piattaforma infrastrutturale che il tuo software.
Nello schema, il delivery pipeline consiste in molti stadi. Ma è uno schema principe, presentato come esempio - non è 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.
È 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ò mettere Okmeter al posto di un mattoncino? Forse i ragazzi hanno già sviluppato questa competenza molto di più di noi. Ma potrebbe anche non essere così - magari abbiamo competenze uniche, dobbiamo aggiungere Prometheus e svilupparlo ulteriormente.
Creazione della piattaforma
È 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 è fondamentale, quella che esiste in DevOps.
Con la cultura è tutto molto semplice - è collaborazione e comunicazione, cioè la volontà di lavorare insieme in un campo comune, la volontà di utilizzare uno strumento condiviso. Non c'è niente di complesso - è tutto molto semplice, banale. Ad esempio, viviamo tutti nello stesso condominio e manteniamo la sua pulizia - questo è il livello di cultura.
E voi?
Di nuovo domande che puoi porti.
La piattaforma infrastrutturale è stata identificata? Chi è responsabile del suo sviluppo? Comprendete i vantaggi competitivi della vostra piattaforma infrastrutturale?
Queste domande devono essere costantemente poste. Se qualcosa può essere esternalizzato a servizi esterni, bisogna farlo; se un servizio esterno inizia a ostacolare il tuo movimento, allora è necessario costruire un sistema all'interno di sé stessi.
Quindi, DevOps…
… è un sistema complesso, deve includere:
- Prodotto digitale.
- Moduli aziendali che sviluppano questo prodotto digitale.
- Team di prodotto che scrivono codice.
- Pratiche di Continuous Delivery.
- Piattaforme come servizio.
- Infrastruttura come servizio.
- Infrastruttura come codice.
- Pratiche di mantenimento della affidabilità, integrate all'interno di DevOps.
- Pratica del feedback che descrive tutto questo.
Puoi utilizzare questo schema, colorando in esso ciò che già hai nella tua azienda in qualche forma: si è sviluppato o deve ancora essere sviluppato.
Tra un paio di settimane si terrà . all'interno di RIT++. Vieni alla conferenza, dove ti aspettano molte interessanti relazioni sulla fornitura continua, infrastruttura come codice e trasformazione DevOps. , ultima scadenza per i prezzi il 20 maggio
Fonte: habr.com
