La definizione di DevOps è molto complessa, quindi è 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é io, purtroppo, non lo so. Ciao, mi chiamo Aleksandr Titov (@), e semplicemente parleremo di DevOps e io condividerò la mia esperienza.
Ho pensato a lungo a come rendere utile il mio racconto, quindi ci saranno molte domande – quelle che faccio a me stesso e quelle che faccio ai clienti della nostra azienda. Rispondendo a queste domande, la comprensione migliora. Spiegherò perché DevOps è 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à attraverso domande. Rispondendo a queste domande da solo, potrai capire se la tua azienda sta procedendo verso DevOps o se ci sono problemi.
Un tempo navigavo tra le onde di fusioni e acquisizioni. Inizialmente ho lavorato in una piccola startup chiamata Qik, poi è stata acquisita da una compagnia un po' più grande, Skype, che è stata successivamente acquistata da un'altra compagnia ancora più 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ì, 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.
Oltre a tutto ciò, sono uno dei fondatori della comunità DevOps Moscow e ho organizzato i DevOps Days 2017, ma nel 2018 non ho organizzato. Ekspress 42 collabora con molte aziende. Coltiviamo lì 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.
Perché DevOps
La prima domanda che inquieta tutti, sempre, è: perché? Molti credono che DevOps sia semplicemente automazione o qualcosa di simile, che è già presente in ogni azienda.
— Abbiamo avuto Continuous Integration, il che significa che già esisteva DevOps, ma a cosa serve tutto questo? All'estero si divertono, mentre noi siamo ostacolati nel lavoro!
Dopo 9 anni di sviluppo della comunità e della metodologia, è chiaro che non si tratta di semplici abbellimenti di marketing, ma non è ancora del tutto chiaro a cosa serva. Come per qualsiasi strumento e processo, DevOps ha obiettivi specifici che risolve nel lungo termine.
Tutto ciò è 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.
In linea di principio, tutto in IT dovrebbe essere costruito su questo approccio. Qui l'IT è utilizzato esclusivamente per l'automazione dei processi.
L'automazione cambia raramente, perché quando un'azienda scorre lungo una strada già tracciata, cosa c'è da cambiare? Funziona, non toccarlo. Oggi nel mondo gli approcci stanno cambiando, e quello che chiamiamo Agile indica che il punto finale B non è subito visibile.
Quando un'azienda esplora il mercato e collabora con i clienti, sta costantemente analizzando l'ambiente circostante e adattando i propri obiettivi. Maggiore è la frequenza con cui l'azienda cambia direzione, maggiore è la sua probabilità di successo, poiché riesce a cogliere più opportunità di mercato.
Un esempio interessante di strategia è una compagnia che ho recentemente scoperto. One Box Shave è 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 è gestito da un software specifico che invia poi l'ordine a una fabbrica coreana che produce il prodotto.
Questo prodotto è 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:
— Quattro lame? Sul serio? Perché avete bisogno di questo? Non migliora affatto la qualità della rasatura. Una crema selezionata, una fragranza e un rasoio di qualità con due lame risolvono molte più questioni rispetto a queste stupide quattro lame di Gillette! Presto arriveremo a dieci?
Così il mondo sta cambiando. Unilever afferma di avere un sistema IT eccezionale che permette di farlo. Il risultato è una concezione. Time-to-market, di cui si è già parlato ampiamente.
Il 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.
Il Time-to-market riguarda la minimizzazione del tempo dall'idea alla realizzazione finale.
In questo caso, il software interagisce con il mercato. Così, il sito web di One Box Shave interagisce con il cliente. Non hanno venditori – solo un sito dove il visitatore clicca e lascia commenti. Pertanto, il sito deve continuamente presentare novità, 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é il profumo di pino.
Poiché è 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 è diverso: il software è progettato da tutti coloro che sono coinvolti nel processo, compresi gli ingegneri, perché apprendono dalle specifiche tecniche come funziona il mercato e condividono anche le loro intuizioni con il business.
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é nel documento non era scritto che doveva funzionare bene e, in effetti, era stato realizzato in modo affrettato; avrebbero disattivato la funzionalità e detto: "Non serve a nessuno, l'importante è che la funzionalità principale funzioni". Ma in un'azienda tecnologica si vede un'opportunità e si inizia a modificare il software di conseguenza.
Nel 1968, il visionario Melvin Conway formulò la seguente idea.
Un'organizzazione che crea un sistema è limitata dal design che copia la struttura di comunicazione al suo interno.
Se approfondiamo, per produrre sistemi di un altro tipo, è necessario disporre anche di una struttura di comunicazione interna di un altro tipo. Se la vostra struttura di comunicazione è altamente gerarchica, questo non consentirà di creare sistemi che possono garantire un elevato Time-to-market.
Leggi è possibile . È fondamentale per comprendere la cultura o la filosofia DevOps, poiché l'unica cosa che cambia fondamentalmente in DevOps è proprio la struttura di comunicazione tra i team..
Dal punto di vista del processo, prima di DevOps tutte le fasi: analisi, sviluppo, testing, operazioni, avvenivano in modo lineare.
Nel caso di DevOps, tutti questi processi avvengono simultaneamente.
Solo così può essere realizzato il Time-to-market. Per le persone che hanno lavorato nel vecchio processo, questo può sembrare piuttosto futuristico, e in generale non molto pratico.
Allora, a cosa serve DevOps?
Per lo sviluppo di prodotti digitali.. Se nella tua azienda non c'è prodotto digitale, DevOps non è necessario — questo è molto importante.
DevOps supera i limiti di velocità dei processi di produzione software sequenziali.. In esso, tutti i processi avvengono simultaneamente.
Aumenta la complessità. Quando gli evangelisti del DevOps dicono che con esso diventa più facile rilasciare software — è pura follia.
Con DevOps, tutto diventa solo più difficile.
Alla conferenza, allo stand di Avito, si poteva vedere cosa significa deployare un container Docker — un compito irrealizzabile. La complessità diventa insostenibile, bisogna giocolare con molteplici palline contemporaneamente.
DevOps cambia completamente i processi e l'organizzazione in azienda. — più precisamente, non è DevOps a cambiare, ma il prodotto digitale. Per arrivare al DevOps, bisogna comunque modificare completamente questo processo.
Domande per gli specialisti
E da voi? Domande che puoi porti mentre lavori in azienda e cresci come specialista.
Hai una strategia per la creazione di un prodotto digitale? Se sì — già bene. Questo significa che la tua azienda sta procedendo verso DevOps.
La tua azienda sta già creando un prodotto digitale? Questo significa che puoi salire un ulteriore gradino, impegnandoti in attività più interessanti — dal punto di vista del DevOps, per essere chiari. Sto parlando proprio da questo punto di vista.
La tua azienda è uno dei leader di mercato in un settore di prodotto digitale? Spotify, Yandex, Uber — aziende che sono attualmente al vertice del progresso tecnologico.
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… 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à mai.
Organizzazione
Come già detto, secondo la Legge di Conway, l'organizzazione di un'azienda cambia. Inizio da ciò che ostacola l'integrazione del DevOps all'interno dell'azienda, precisamente dal punto di vista organizzativo.
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 la propria esperienza in profondità, senza però costruire una mappa comune sulla quale orientarsi.
Questo ricorda un po' una persona che è appena arrivata a Mosca e non è 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à e ti senti semplicemente disorientato.
Il DevOps offre la possibilità di superare questo momento di disorientamento e di costruire insieme a tutti i dipartimenti una mappa comune di interazione.
Due fattori ostacolano questo.
La conseguenza di un sistema di gestione corporate. È 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. È semplicemente scomodo. Immaginate di essere all'aeroporto di Bangkok: lì non ci si orienta facilmente. Anche nel DevOps è difficile orientarsi, ed è per questo che le persone dicono che bisogna trovare una guida per entrarci.
Ma la cosa più importante è 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". Spesso ci incontriamo dopo DevOps Moscow, parliamo tra di noi e le persone si lamentano:
— Volevamo semplicemente avviare il CI, ma è risultato che alla gestione non interessa.
Questo accade proprio perché CI e il processo di Continuous Delivery si trova al confine di molte competenze. Non superando il problema dei "pozzi" a livello organizzativo, non potrà progredire ulteriormente, qualunque cosa facciate e per quanto sia triste.
Ogni 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".
Le persone lottano per qualche stella o bandierina, ognuno scava nella propria area di competenza.
Alla fine, quando si presenta il compito di mettere tutto insieme e costruire un pipeline comune, e non è più 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 è wow! - rispetto al settimo anno! Qui è la stessa cosa.
È così anche nella vostra azienda?
Per verificare ciò, è possibile porsi le seguenti domande.
Le squadre utilizzano strumenti comuni e contribuiscono a modifiche di questi strumenti condivisi?
Con quale frequenza le squadre si riorganizzano - gli esperti di un team passano a un altro team? Questo sta diventando normale nell'ambiente DevOps, perché a volte una persona semplicemente non riesce a capire cosa fa un'altra area di competenza. Passa a un altro dipartimento, ci lavora per un paio di settimane per creare una mappa di orientamento e interazione con quello dipartimento.
È possibile creare un comitato per le modifiche e apportare delle modifiche? O serve una mano forte della dirigenza più 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, è un processo lungo e triste.
Quanto è importante per i manager ottenere risultati personali senza considerare i risultati dell'azienda?
Se risponderete a queste domande, sarà più chiaro se avete un problema simile in azienda.
Infrastruttura come codice
Una volta superato questo problema, la prima pratica importante, senza la quale è difficile progredire nel DevOps è infrastruttura come codice.
Spesso l'infrastruttura come codice viene percepita così:
- Automatizziamo tutto in bash, sommergiamoci di script, così i sysadmin faranno meno lavoro manuale!
Ma non è così.
L'infrastruttura come codice implica che il sistema IT con cui lavorate venga descritto in forma di codice, per capire costantemente il suo stato.
Insieme ad altri team, create una mappa in forma di codice, comprensibile per tutti, che si può seguire e navigare. Non importa su cosa sia realizzata: Chef, Ansible, Salt, o se vengono utilizzati file YAML in Kubernetes — non fa differenza.
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'è questa descrizione, ognuno può confrontarsi, monitorare le modifiche, vedere come cambiarla e migliorarla, e identificare cosa manca.
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' — quando lo script è scritto, ma non è più possibile leggerlo. Penso che anche a voi suoni familiare.
L'infrastruttura come codice è il codice che descrive lo stato attuale dell'infrastruttura. Su questo codice collaborano numerosi team di prodotto, infrastruttura e servizio, e, cosa più importante, tutti devono capire come funziona questo codice.
Il codice è accompagnato secondo le migliori pratiche di programmazione.: sviluppo collaborativo, revisione del codice, programmazione XP, test, richieste di pull, CI per l'infrastruttura del codice – tutto ciò è valido e può essere utilizzato.
Il codice diventa un linguaggio comune per tutti gli ingegneri.
La modifica dell'infrastruttura nel codice non richiede molto tempo.. Sì, anche nel codice dell'infrastruttura può esserci un debito tecnico. Di solito, i team si imbattono in questo dopo un anno e mezzo dall'inizio dell'implementazione dell'«infrastruttura come codice» sotto forma di una serie di script o persino Ansible, che scrivono come codice spaghetti, e gettano dentro anche script bash!
Importante: se non avete ancora provato questa cosa, ricordate che Ansible non è bash! Leggete attentamente la documentazione, studiate cosa viene scritto a riguardo.
L'infrastruttura come codice è una separazione del codice infrastrutturale in strati distinti.
Nella nostra azienda distinguiamo 3 strati di base, che sono molto chiari e semplici, ma potrebbero essere di più. Puoi controllare il tuo codice infrastrutturale e verificare se hai questa condizione o meno. Se non ci sono strati distinti, è necessario dedicare del tempo a fare un po' di refactoring.
Strato di base — è come si configura il sistema operativo, i backup e altre cose di basso livello, ad esempio, come viene implementato Kubernetes a livello di base.
Livello dei servizi — 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 — 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.
Strato dove vengono creati le applicazioni e viene descritto come verranno implementate sopra i due strati precedenti.
Domande di controllo
Avete un repository infrastrutturale comune nella vostra azienda? Controllate il debito tecnico nell'infrastruttura? Utilizzate pratiche di sviluppo nel repository infrastrutturale? La vostra infrastruttura è suddivisa in livelli? Potete fare riferimento allo schema Base-service-APP. Quanto è complesso apportare una modifica?
Se vi è 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à del codice infrastrutturale, perché la creatività e il desiderio di automatizzare tutto ha portato a un ingorgo ovunque, tutte le maniglie rimosse, e c'è bisogno di rifattorizzare.
Consegna continua
Confrontiamo il debito con il credito. Inizialmente viene fornita una descrizione dell'infrastruttura, che può essere piuttosto basilare. Non è necessario descrivere tutto nel dettaglio, ma è richiesta una qualche descrizione di base per poter lavorare con questo. Altrimenti, non è 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 è proprio la pratica dell'infrastruttura come codice.
Dopo aver compreso cosa si ha e come gestirlo, iniziate a pensare a come inviare il codice del developer il più rapidamente possibile in produzione. Intendo dire insieme al developer - ricordiamo il problema dei 'pozzi', ovvero non sono singole persone a pensarci, ma un team.
Quando ci siamo incontrati con Ivan Yevtukhovich e abbiamo visto il primo libro di Jez Humble e del gruppo di autori «Continuous Delivery», che è stata rilasciata nel 2009, abbiamo a lungo riflettuto su come tradurre il suo titolo in russo. Volevamo tradurlo come «Consegna continua», ma, sfortunatamente, è stato tradotto come «Fornitura continua». Penso che ci sia qualcosa di profondamente russo nel nostro titolo, con una certa determinazione.
Consegna continua significa
Il codice che si trova nel repository di prodotto può sempre essere rilasciato in produzione. Potrebbe non essere rilasciato, ma è 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.
Per garantire una consegna continua, è necessario un formato dell'artefatto che passi attraverso la piattaforma infrastrutturale. Se butti «rifiuti biologici» su una piattaforma infrastrutturale di formati diversi, diventa non unificata, difficile da mantenere, e sorgono problemi di debito tecnico. È necessario allineare il formato dell'artefatto — questo è un compito collettivo: dobbiamo riunirci e lavorare insieme per inventare questo formato.
L'artefatto viene continuamente migliorato e modificato per l'ambiente di produzione durante il passaggio attraverso il pipeline di fornitura. 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 è un amministratore di sistema che effettua la distribuzione, nel processo DevOps questo avviene costantemente: qui è stato testato con vari test, là è stato caricato in un cluster Kubernetes che è più o meno simile a produzione, e qui è stato improvvisamente avviato un test di carico.
Questo ricorda in parte il gioco di Pac-Man: l'artefatto segue una certa storia. È importante controllare se il codice realmente segue la storia e se questa è 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 è andato storto, ora programmiamo semplicemente questo scenario nel sistema. Ogni volta il codice seguirà anche questo scenario, e non vi ritroverete più di fronte a questo problema. Ne sarete a conoscenza molto prima che si presenti al vostro cliente.
Diverse strategie di deployment. 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.
«Delivering continuously» appare così.
Il processo di fornitura Dev, CI, Test, PreProd, Prod non è un ambiente separato, ma fasi o stazioni con somme intoccabili, attraverso le quali passa il vostro artefatto.
Se avete codice infrastrutturale descritto come Base Service APP, questo aiuta a non dimenticare tutti gli scenari., e scrivere anche il codice per questo artefatto, promuovere l'artefatto e modificarlo lungo il percorso.
Domande per l'autovalutazione
Il tempo dalla descrizione della funzionalità al rilascio in produzione è inferiore a una settimana nel 95% dei casi? La qualità dell'artefatto migliora a ogni fase del pipeline? Esiste una storia che lo accompagna? Utilizzate diverse strategie di deployment?
Se tutte le risposte sono sì, allora siete incredibilmente bravi! Scrivete le risposte nei commenti e sarò felice).
Feedback
Questa è la pratica più complessa di tutte. Alla conferenza DevOpsConf, un collega di Infobip, parlando di essa, si confuse un po' con le parole, perché è davvero una pratica molto complicata che riguarda il monitoraggio di tutto!
Ad 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:
— Ragazzi, perché state stressando il server con cose incomprensibili?
Ma poi è successo un episodio che ha dimostrato che questa è davvero una strategia molto valida.
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é si trattava di un broker di base, che praticamente non aveva funzionalità aziendali — si limitava a inoltrare messaggi tra i vari servizi. Il servizio non era cambiato per 4 mesi, e all’improvviso ha cominciato a cadere con l'errore «Segmentation fault».
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, è cambiato drasticamente. Poi abbiamo osservato che è cambiata la frequenza di invio di un certo tipo di messaggi. Dopo abbiamo scoperto che si trattava di client Android. Abbiamo chiesto:
— Ragazzi, cosa è successo circa un mese e mezzo fa?
In risposta, abbiamo sentito un'interessante storia su come abbiano riprogettato l'interfaccia utente. Difficilmente qualcuno potrebbe dire subito che è stata cambiata la libreria HTTP. Per i clienti Android è 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.
Senza un monitoraggio approfondito, è praticamente impossibile individuarlo.Se nell'organizzazione esiste anche il problema dei ‘pozzi’, dove ognuno scarica sugli altri, questo può durare anni. Si riavvia semplicemente il server perché non è possibile risolvere il problema. Quando monitori, tracci, segui tutti gli eventi che hai e utilizzi il monitoraggio come collaudo — scrivi il codice e subito indichi come monitorarlo, sempre sotto forma di codice (abbiamo già un'infrastruttura come codice), tutto diventa chiaro come il palmo di una mano. Anche problemi così complessi possono essere facilmente tracciati.
Raccogli tutte le informazioni su ciò che accade all'artefatto in ogni fase del processo di consegna - non in produzione.
Carica il monitoraggio su CI, dove potrai già 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 è stata rilasciata l'applicazione, anomalie - raccogli tutto.
In caso contrario, sarà difficile capire. Ho già detto che DevOps comporta maggiore complessità. Per affrontare questa complessità, è necessario avere una buona analisi..
Domande per l'autocontrollo.
Il tuo monitoraggio e logging sono strumenti di sviluppo per te? I tuoi sviluppatori, e tu stesso, quando scrivono codice, pensano a come monitorarlo?
Scopri i problemi dai clienti? Comprendi meglio il cliente dal monitoraggio e dal logging? Comprendi meglio il sistema dal monitoraggio e dal logging? Cambiate il sistema semplicemente perché vedete che la tendenza nel sistema sta aumentando e capite che fra 3 settimane tutto collasserà?
Quando hai questi tre componenti, puoi iniziare a pensare a quale piattaforma infrastrutturale hai nella tua azienda.
Piattaforma infrastrutturale
Il punto non è che si tratti di un insieme di strumenti disgiunti, presenti in ogni azienda.
Il senso della piattaforma infrastrutturale è che tutte le squadre utilizzano questi strumenti e li sviluppano insieme.
È chiaro che ci sono squadre separate che sono responsabili dello sviluppo di singoli pezzi della piattaforma infrastrutturale. Ma ogni ingegnere è responsabile dello sviluppo, del funzionamento e della promozione della piattaforma infrastrutturale. A livello interno, questo diventa uno strumento comune.
Tutte le squadre sviluppano la piattaforma infrastrutturale, trattandola con cura come se fosse il proprio IDE.. Nel tuo IDE installi vari plugin affinché 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 è impossibile lavorare, ti senti subito giù e corri a sistemare il tuo IDE.
Tratta la tua piattaforma infrastrutturale allo stesso modo. Se ti rendi conto che c'è 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à e l'aggiungerà. Questo rappresenta un approccio diverso agli strumenti ingegneristici nella mente dello sviluppatore.
La piattaforma infrastrutturale garantisce il trasferimento dell'artefatto dallo sviluppo al cliente, con un costante miglioramento della qualità.Nella IP è 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.
A questo punto, la piattaforma infrastrutturale diventa il tuo vantaggio competitivo, poiché contiene ciò che non è presente nello strumento del concorrente. Più profonda è la tua IP, maggiore è il tuo vantaggio competitivo in termini di Time-to-market. Qui emerge 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. Si tratta di una sottile distinzione, in cui l'esperienza di un'azienda è pertinente alla sua posizione di mercato, e non si può abbattere il vendor lock. È importante pensarci.
Schema
Questo è uno schema di base per una piattaforma infrastrutturale che ti aiuterà a organizzare tutte le pratiche e i processi in un'azienda DevOps.
Esaminiamo quali elementi la compongono.
Sistema di orchestrazione delle risorse, che fornisce CPU, memoria, disco alle applicazioni e ad altri servizi. Sopra questo c'è servizi di basso livello: monitoraggio, logging, CI/CD Engine, archiviazione degli artefatti, infrastruttura come codice.
Servizi di livello superiore: database come servizio, code come servizio, Load Balance come servizio, ridimensionamento delle immagini come servizio, Big Data factory come servizio. Sopra questo c'è un pipeline che fornisce codice costantemente modificato al tuo cliente..
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.
Nello schema, la delivery pipeline è composta da numerosi stadi. Ma è uno schema fondamentale, presentato a titolo esemplificativo: non è 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.
È 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? È possibile che loro abbiano già sviluppato questa expertise molto più di noi. Ma potrebbe anche non essere così: forse abbiamo un'expertise unica, e dobbiamo implementare Prometheus e svilupparlo ulteriormente.
Creazione della piattaforma
Si 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 è fondamentale.
Con la cultura è tutto molto semplice — è collaborazione e comunicazione, ovvero il desiderio di lavorare insieme in un campo comune, voglia di possedere uno strumento insieme. Non è certo una rocket science — è tutto molto semplice, banale. Ad esempio, viviamo tutti nello stesso condominio e ne manteniamo la pulizia — questo è un livello di cultura.
E voi?
Di nuovo domande che potete porvi.
È stata designata una piattaforma infrastrutturale? Chi è responsabile del suo sviluppo? Comprendete i vantaggi competitivi della vostra piattaforma infrastrutturale?
Queste domande devono essere poste continuamente. Se qualcosa può essere esternalizzato a servizi di terze parti — è necessario farlo; se un servizio esterno inizia a bloccare il vostro movimento, è necessario costruire un sistema all'interno di sé.
Quindi, DevOps…
… è un sistema complesso, deve includere:
- Un 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.
- Singole pratiche di mantenimento dell'affidabilità integrate nel DevOps.
- Pratica di feedback che descrive tutto questo.
Puoi utilizzare questo schema, evidenziando ciò che hai già nella tua azienda in qualche modo: è già sviluppato o deve ancora essere migliorato.
Tra un paio di settimane si svolgerà . come parte di RIT++. Unisciti alla conferenza, dove ti aspettano molte presentazioni interessanti su Continuous Delivery, infrastruttura come codice e trasformazione DevOps. , ultima scadenza dei prezzi il 20 maggio
Fonte: habr.com
