La definizione di DevOps è molto complessa, quindi ogni volta dobbiamo ricominciare la discussione da capo. Solo su Habré esistono un migliaio di pubblicazioni su questo argomento. Ma se stai leggendo questo articolo, probabilmente sai cos'è DevOps. Perché non lo sono. Ciao il mio nome è Aleksandr Titov (@), parleremo solo di DevOps e condividerò la mia esperienza.
Ho pensato a lungo a come rendere utile la mia storia, quindi ci saranno molte domande qui: quelle che pongo a me stesso e quelle che pongo ai clienti della nostra azienda. Rispondendo a queste domande la comprensione migliora. Ti dirò perché DevOps è necessario dal mio punto di vista, cos'è, ancora una volta, dal mio punto di vista e come capire che ti stai muovendo di nuovo verso DevOps dal mio punto di vista. L'ultimo punto sarà attraverso le domande. Rispondendo tu stesso potrai capire se la tua azienda si sta muovendo verso DevOps o se ci sono problemi in qualche modo.
Un tempo stavo cavalcando l’onda delle fusioni e acquisizioni. All'inizio ho lavorato per una piccola startup chiamata Qik, poi è stata acquistata da un'azienda leggermente più grande chiamata Skype, che è stata poi acquistata da un'azienda leggermente più grande chiamata Microsoft. In quel momento ho iniziato a vedere come l’idea di DevOps si stava trasformando in aziende di diverse dimensioni. Successivamente, mi sono interessato a guardare DevOps dal punto di vista del mercato e io e i miei colleghi abbiamo fondato la società Express 42. Da 6 anni ci muoviamo lungo le onde del mercato.
Tra le altre cose, sono uno degli organizzatori della comunità DevOps di Mosca e l'organizzatore dei DevOps-Days 2017, ma non ho organizzato il 2018. Express 42 funziona con molte aziende. Coltiviamo DevOps lì, osserviamo come accade, traiamo conclusioni, analizziamo, comunichiamo a tutti le nostre conclusioni e formiamo le persone nelle pratiche DevOps. In generale, stiamo facendo del nostro meglio per aumentare la nostra esperienza e competenza in questo senso.
Perché DevOps
La prima domanda che tormenta tutti e sempre è: perché? Molte persone pensano che DevOps sia solo automazione o qualcosa di simile già presente in ogni azienda.
— Avevamo l'integrazione continua: questo significa che avevamo già DevOps, e perché sono necessarie tutte queste cose? Si divertono all'estero, ma ci impediscono di lavorare!
In 9 anni di sviluppo della comunità e della metodologia, è già diventato chiaro che non si tratta ancora di glitter di marketing, ma non è ancora del tutto chiaro il motivo per cui è necessario. Come ogni strumento e processo, DevOps ha obiettivi specifici che alla fine raggiunge.
Tutto ciò è dovuto al fatto che il mondo sta cambiando. Si allontana dall'approccio aziendale, quando le aziende si muovono direttamente verso un sogno, come cantava il nostro classico di San Pietroburgo, dal punto A al punto B secondo una certa strategia, con una certa struttura costruita per questo.
In linea di principio, tutto nell’IT dovrebbe essere costruito secondo questo approccio. Qui l'IT viene utilizzata esclusivamente per automatizzare i processi.
L'automazione non cambia spesso, perché quando un'azienda cade su una routine consolidata, cosa c'è da cambiare? Funziona: non toccarlo. Ora gli approcci nel mondo stanno cambiando e quello chiamato Agile suggerisce che il punto finale B non è immediatamente visibile.
Quando un'azienda attraversa il mercato, lavora con un cliente, esplora costantemente il mercato e cambia il punto finale B. Inoltre, più spesso l'azienda cambia direzione, maggiore sarà il successo alla fine, perché sceglie più mercati nicchie.
La strategia è dimostrata da un'azienda interessante di cui sono venuto a conoscenza di recente. One Box Shave è un servizio di consegna in abbonamento di rasoi e accessori da barba in scatola. Sanno come personalizzare la loro “scatola” per diversi clienti. Ciò viene fatto da un determinato software, che poi invia l'ordine alla fabbrica coreana che produce la merce.
Questo prodotto è stato acquistato da Unilever per 1 miliardo di dollari. Ora compete con Gillette e ha portato via una quota significativa di consumatori nel mercato americano. One Box Shave dice:
— 4 lame? Sei serio? Perché ne hai bisogno: non migliora la qualità della rasatura. Una crema appositamente selezionata, una fragranza e un rasoio di alta qualità con due lame risolvono molti più problemi di quelle stupide 4 lame Gillette! Arriveremo presto a 10?
Ecco come cambia il mondo. Unilever afferma di avere un ottimo sistema IT che ti consente di farlo. Alla fine sembra un concetto Time-to-market, di cui nessuno ha già parlato.
Il punto del time-to-market non è la frequenza con cui eseguiamo l'implementazione. Puoi spesso eseguire la distribuzione, ma i cicli di rilascio saranno lunghi. Se i cicli di rilascio di tre mesi vengono sovrapposti l'uno all'altro, spostandoli di una settimana, si scopre che l'azienda sembra effettuare il deploy una volta alla settimana. E dall'idea alla realizzazione finale ci vogliono 3 mesi.
Il time-to-market significa ridurre al minimo il tempo che intercorre tra l'idea e l'implementazione finale.
In questo caso, il software interagisce con il mercato. Ecco come il sito Web One Box Shave interagisce con il cliente. Non hanno venditori: solo un sito Web in cui i visitatori fanno clic e lasciano desideri. Di conseguenza, qualcosa di nuovo deve essere costantemente pubblicato sul sito e aggiornato secondo i desideri. Ad esempio, in Corea del Sud si radono in modo diverso rispetto alla Russia e a loro piace il profumo non di pino, ma, ad esempio, di carote e vaniglia.
Poiché è necessario modificare rapidamente il contenuto del sito, lo sviluppo del software cambia notevolmente. Attraverso il software dobbiamo scoprire cosa vuole il cliente. In precedenza, lo abbiamo imparato attraverso alcuni modi indiretti, ad esempio attraverso la gestione aziendale. Poi l'abbiamo progettato, inserito i requisiti nel sistema IT e tutto è andato alla grande. Ora è diverso: il software viene progettato da tutti coloro che sono coinvolti nel processo, compresi gli ingegneri, perché attraverso le specifiche tecniche apprendono come funziona il mercato e condividono anche le loro intuizioni con l’azienda.
Ad esempio, in Qik abbiamo improvvisamente scoperto che alle persone piaceva molto caricare elenchi di contatti sul server e ci hanno fornito un'applicazione. Inizialmente non ci pensavamo. In un'azienda classica, tutti avrebbero deciso che si trattava di un bug, poiché le specifiche non dicevano che avrebbe dovuto funzionare alla grande ed era generalmente implementato sul ginocchio, avrebbero disattivato la funzionalità e avrebbero detto: "Nessuno ne ha bisogno, la cosa più importante è che la funzionalità principale funzioni." . E l'azienda tecnologica vede questa come un'opportunità e inizia a modificare il software di conseguenza.
Nel 1968, un uomo visionario, Melvin Conway, formulò la seguente idea.
L'organizzazione che crea il sistema è vincolata da un progetto che replica la struttura di comunicazione di quell'organizzazione.
Più nel dettaglio, per produrre impianti di tipologia diversa è necessario avere anche una struttura di comunicazione all'interno di un'azienda di tipologia diversa. Se la tua struttura di comunicazione è gerarchica, ciò non ti consentirà di creare sistemi in grado di fornire un indicatore di time-to-market molto elevato.
Leggere si può . È importante per comprendere la cultura o la filosofia DevOps perché l'unica cosa che cambia radicalmente in DevOps è la struttura della comunicazione tra i team.
Da un punto di vista del processo, prima di DevOps, tutte le fasi: analisi, sviluppo, test, funzionamento, erano lineari.
Nel caso di DevOps, tutti questi processi avvengono contemporaneamente.
Il time-to-market è l’unico modo per farlo. Per le persone che hanno lavorato nel vecchio processo, questo sembra in qualche modo cosmico, e generalmente così così.
Allora perché hai bisogno di DevOps?
Per lo sviluppo di prodotti digitali. Se la tua azienda non dispone di un prodotto digitale, DevOps non è necessario: è molto importante.
DevOps supera i limiti di velocità della produzione sequenziale di software. In esso tutti i processi avvengono simultaneamente.
La difficoltà aumenta. Quando gli evangelisti DevOps ti dicono che ti renderà più semplice rilasciare software, non ha senso.
Con DevOps le cose diventeranno solo più complicate.
Alla conferenza presso lo stand Avito avete potuto vedere com'era l'implementazione di un container Docker: un compito irrealistico. La complessità diventa proibitiva; devi destreggiarti tra più palline contemporaneamente.
DevOps cambia completamente il processo e l'organizzazione in azienda — più precisamente, non è DevOps a cambiare, ma il prodotto digitale. Per arrivare a DevOps, devi ancora cambiare completamente questo processo.
Domande per uno specialista
Cosa hai? Domande che puoi porti mentre lavori in un'azienda e sviluppi come specialista.
Hai una strategia per creare un prodotto digitale? Se c’è, va già bene. Ciò significa che la tua azienda si sta muovendo verso DevOps.
La tua azienda sta già creando un prodotto digitale? Ciò significa che puoi salire di un altro livello e fare le cose in modo più interessante, sempre dal punto di vista DevOps. Parlo solo da questo punto di vista.
La tua azienda è uno dei leader di mercato nella nicchia dei prodotti digitali? Spotify, Yandex, Uber sono aziende che ora sono all'apice del progresso tecnologico.
Ponetevi queste domande e, se tutte le risposte sono no, forse non dovreste fare DevOps in questa azienda. Se l'argomento DevOps ti interessa davvero, forse... dovresti trasferirti in un'altra azienda? Se la tua azienda vuole passare a DevOps, ma hai risposto “No” a tutte le domande, allora è come quel bellissimo rinoceronte che non cambierà mai.
Organizzazione
Come ho detto, secondo la Legge di Conway, l'organizzazione di un'azienda cambia. Inizierò con ciò che impedisce al DevOps di penetrare all’interno dell’azienda dal punto di vista organizzativo.
Il problema dei “pozzi”
La parola inglese "Silo" qui è tradotta in russo come "bene". Il punto di questo problema è questo non c'è scambio di informazioni tra le squadre. Ogni team approfondisce le proprie competenze, senza costruire una mappa comune su cui navigare.
In un certo senso questo mi ricorda una persona che è appena arrivata a Mosca e non sa ancora come orientarsi sulla mappa della metropolitana. I moscoviti di solito conoscono molto bene la loro zona e possono spostarsi in tutta Mosca utilizzando la mappa della metropolitana. Quando vieni a Mosca per la prima volta non hai questa capacità e sei semplicemente disorientato.
DevOps suggerisce di superare questo momento di disorientamento e di collaborare tutti i dipartimenti per costruire una mappa di interazione comune.
Due fattori lo ostacolano.
Conseguenza del sistema di gestione aziendale. È costruito in “pozzi” gerarchici separati. Ad esempio, ci sono alcuni KPI nelle aziende che supportano questo sistema. D'altra parte, il cervello di una persona che ha difficoltà ad andare oltre i confini delle proprie competenze e navigare nell'intero sistema si mette in mezzo. E' semplicemente scomodo. Immagina di essere all'aeroporto di Bangkok: non troverai la strada velocemente. Anche DevOps è difficile da navigare ed è per questo che le persone dicono che è necessario trovare una guida per arrivarci.
Ma la cosa più importante è che il problema dei "pozzi" per un ingegnere intriso dello spirito DevOps, che ha letto Fowler e molti altri libri, si esprime nel fatto che I "pozzi" non ti permettono di fare cose "ovvie".. Ci riuniamo spesso dopo DevOps Mosca, ci parliamo e le persone si lamentano:
— Volevamo solo lanciare la CI, ma si è scoperto che il management non ne aveva bisogno.
Ciò accade proprio perché CI и Processo di consegna continua sono al limite di molti esami. Semplicemente senza superare il problema dei “pozzi” a livello organizzativo, non sarai in grado di andare avanti, qualunque cosa tu faccia e non importa quanto sia triste.
Ogni partecipante al processo in azienda: sviluppatori backend e frontend, testing, DBA, operazione, rete, scava nella propria direzione, e nessuno ha una mappa comune tranne il manager, che in qualche modo li monitora e li gestisce utilizzando il “divide e conquistare”.
Le persone combattono per alcune stelle o bandiere, tutti mettono alla prova la propria esperienza.
Di conseguenza, quando si presenta il compito di collegare tutto questo insieme e costruire un gasdotto comune, e non è più necessario lottare per stelle e bandiere, sorge la domanda: cosa fare comunque? Dobbiamo in qualche modo raggiungere un accordo, ma nessuno ci ha insegnato come farlo a scuola. Ci viene insegnato fin dalla scuola: terza media - wow! - rispetto alla seconda media! È lo stesso qui.
È lo stesso nella tua azienda?
Per verificarlo puoi porti le seguenti domande.
I team utilizzano strumenti comuni e contribuiscono alle modifiche a tali strumenti comuni?
Con quale frequenza i team si riorganizzano: alcuni specialisti di un team si spostano in un altro team? È nell'ambiente DevOps che questo diventa normale, perché a volte una persona semplicemente non riesce a capire cosa sta facendo un'altra area di competenza. Si trasferisce in un altro dipartimento, lavora lì per due settimane per creare una mappa di orientamento e interazione con questo dipartimento.
È possibile formare un comitato di cambiamento e cambiare le cose? Oppure richiede la mano forte del management e della direzione più elevati? Recentemente ho scritto su Facebook come una banca poco conosciuta sta implementando strumenti tramite ordini: scriviamo un ordine, lo implementiamo per un anno e vediamo cosa succede. Questo, ovviamente, è lungo e triste.
Quanto è importante per i manager ricevere i risultati personali senza considerare i risultati dell'azienda?
Se rispondi tu stesso a queste domande, diventerà più chiaro se hai un problema del genere nella tua azienda.
Infrastruttura come codice
Dopo aver superato questo problema, la prima pratica importante, senza la quale è difficile avanzare ulteriormente in DevOps, è infrastruttura come codice.
Molto spesso, l'infrastruttura come codice viene percepita come segue:
— Automatizziamo tutto in bash, copriamoci di script in modo che gli amministratori abbiano meno lavoro manuale!
Ma non è vero.
Infrastruttura come codice significa descrivere il sistema IT con cui lavori sotto forma di codice per comprenderne costantemente lo stato.
Insieme ad altri team, crei una mappa sotto forma di codice che tutti possono comprendere e navigare e navigare. Non importa su cosa viene fatto (Chef, Ansible, Salt o utilizzando file YAML in Kubernetes): non c'è differenza.
Alla conferenza, un collega di 2GIS ha raccontato come hanno realizzato la propria cosa interna per Kubernetes, che descrive la struttura dei singoli sistemi. Per descrivere 500 sistemi, avevano bisogno di uno strumento separato che generasse questa descrizione. Quando c'è questa descrizione, tutti possono verificare tra loro, monitorare i cambiamenti, come cambiarla e migliorarla, cosa manca.
D'accordo, i singoli script bash di solito non forniscono questa comprensione. In una delle aziende in cui lavoravo, c'era persino un nome per la sceneggiatura "di sola scrittura" - quando la sceneggiatura è scritta, ma non è più possibile leggerla. Penso che anche questo ti sia familiare.
L'infrastruttura come è il codice codice che descrive lo stato attuale dell’infrastruttura. Molti team di prodotto, infrastruttura e servizio lavorano insieme su questo codice e, cosa più importante, tutti devono capire come funziona effettivamente questo codice.
Il codice viene mantenuto secondo le migliori pratiche di codice: sviluppo congiunto, revisione del codice, programmazione XP, test, richieste pull, CI per infrastrutture di codice: tutto questo è adatto 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ì, il codice delle infrastrutture può avere anche un debito tecnico. Di solito i team lo incontrano un anno e mezzo dopo aver iniziato a implementare "l'infrastruttura come codice" sotto forma di un mucchio di script o addirittura Ansible, che scrivono come spaghetti code, e inseriscono anche script bash nel mix!
È importante: Se non hai ancora provato queste cose, ricordalo Ansible non è una bomba! Leggi attentamente la documentazione, studia cosa scrivono a riguardo.
L'infrastruttura come codice è la separazione del codice dell'infrastruttura in livelli separati.
Nella nostra azienda distinguiamo 3 livelli base, che sono molto chiari e semplici, ma potrebbero essercene di più. Puoi guardare il codice della tua infrastruttura e capire se hai questa condizione o meno. Se non sono evidenziati livelli, è necessario prendersi un po' di tempo e rifattorizzare un po'.
livello base - ecco come vengono configurati il sistema operativo, i backup e altri elementi di basso livello, ad esempio come viene distribuito Kubernetes a livello base.
Livello di servizio - questi sono i servizi che fornisci allo sviluppatore: registrazione come servizio, monitoraggio come servizio, database come servizio, bilanciatore come servizio, coda come servizio, consegna continua come servizio - un insieme di servizi offerti dai singoli team può fornire allo sviluppo. Tutto questo deve essere descritto in moduli separati nel sistema di gestione della configurazione.
Il livello in cui vengono effettuate le applicazioni e descrive come si svolgeranno sopra i due strati precedenti.
Domande sulla sicurezza
La tua azienda dispone di un repository infrastrutturale comune? Gestisci il debito tecnico della tua infrastruttura? Utilizzi pratiche di sviluppo in un repository di infrastrutture? La tua infrastruttura è suddivisa in strati? Puoi controllare il diagramma Servizio Base-APP. Quanto è difficile apportare un cambiamento?
Se hai sperimentato che ci è voluto un giorno e mezzo per apportare modifiche, significa che hai un debito tecnico e devi lavorarci. Ti sei appena imbattuto in una percentuale di debito tecnico nel tuo codice infrastrutturale. Ricordo molte di queste storie in cui, per modificare alcuni CCTL, è necessario riscrivere metà del codice dell'infrastruttura, perché la creatività e il desiderio di automatizzare tutto hanno portato al fatto che tutto è corroso ovunque, tutte le maniglie sono state rimosse e è necessario effettuare il refactoring.
Consegna continua
Confrontiamo il debito con il credito. Innanzitutto viene fornita una descrizione dell'infrastruttura, che può essere piuttosto elementare. Non è necessario descrivere tutto in dettaglio, ma è necessaria una descrizione di base per poter lavorare con esso. Altrimenti non è chiaro cosa fare dopo con la consegna continua. Tutte queste pratiche si svolgono simultaneamente quando si arriva a DevOps, ma tutto inizia con la comprensione di ciò di cui si dispone e come gestirlo. Questa è precisamente la pratica dell’infrastruttura come codice.
Una volta che diventa chiaro di averlo e come gestirlo, inizi a capire come inviare il codice sviluppatore alla produzione il più rapidamente possibile. Voglio dire, insieme allo sviluppatore: ricordiamo il problema dei "pozzi", cioè non sono le singole persone a inventarlo, ma una squadra.
Quando siamo con Vanja Evtukhovich visto il primo libro Jez Humble e gruppi di autori "Consegna continua", uscito nel 2009, abbiamo pensato a lungo a come tradurre il suo titolo in russo. Volevano tradurlo come “Consegna costante”, ma sfortunatamente è stato tradotto come “Consegna continua”. Mi sembra che ci sia qualcosa di russo nel nostro nome, con pressione.
Fornire costantemente mezzi
Il codice presente nel repository del prodotto può sempre essere scaricato in produzione. Potrebbe non essere sgonfiato, ma è sempre pronto per questo. Di conseguenza, scrivi sempre codice con una sensazione di ansia difficile da spiegare sotto il coccige. Appare spesso quando si implementa il codice dell'infrastruttura. Questa sensazione di ansia dovrebbe essere presente: attiva processi cerebrali che ti consentono di scrivere il codice in modo leggermente diverso. Ciò dovrebbe essere registrato nelle regole all'interno dello sviluppo.
Per una distribuzione coerente, è necessario un formato di artefatto che venga eseguito su una piattaforma infrastrutturale. Se si gettano "rifiuti vitali" di diversi formati su una piattaforma infrastrutturale, questa diventa unificata, è difficile da mantenere e sorge il problema del debito tecnico. Il formato dell'artefatto deve essere allineato: anche questo è un compito collettivo: dobbiamo riunirci tutti, armeggiare con le nostre menti e inventare questo formato.
L'artefatto viene continuamente migliorato e modificato per adattarsi all'ambiente di produzione mentre si sposta attraverso la pipeline di distribuzione. Quando un artefatto si muove lungo la pipeline, incontra costantemente alcune cose che gli sono scomode, che sono simili a ciò che incontra l'artefatto che hai messo in produzione. Se nello sviluppo classico questo viene fatto da un amministratore di sistema che si occupa del rollout, nel processo DevOps questo accade continuamente: qui lo hanno testato con alcuni test, qui lo hanno gettato in un cluster Kubernetes, che è più o meno simile alla produzione, poi all'improvviso hanno iniziato i test di carico.
Questo ricorda in qualche modo il gioco Pac-Man: l'artefatto attraversa una sorta di storia. Allo stesso tempo, è importante controllare se il codice attraversa effettivamente la storia e se è in qualche modo correlato alla tua produzione. Le storie della produzione possono essere trascinate nel processo di Continuous Delivery: era così quando qualcosa cadeva, ora programmiamo questo scenario all’interno del sistema. Ogni volta il codice eseguirà anche questo scenario e la prossima volta non incontrerai questo problema. Lo imparerai molto prima che raggiunga il tuo cliente.
Diverse strategie di distribuzione. Ad esempio, utilizzi i test AB o le distribuzioni Canary per testare il codice in modo diverso su client diversi, ottenere informazioni su come funziona il codice e molto prima rispetto a quando viene distribuito a 100 milioni di utenti.
"Consegnare costantemente" assomiglia a questo.
Il processo di consegna Dev, CI, Test, PreProd, Prod non è un ambiente separato, si tratta di fasi o stazioni con somme ignifughe attraverso le quali passa il tuo artefatto.
Se disponi di un codice di infrastruttura descritto come APP del servizio di base, può essere d'aiuto non dimenticare tutti gli scripte trascrivili come codice per questo artefatto, promuovere l'artefatto e cambialo mentre procedi.
Domande per l'autotest
Il tempo che intercorre tra la descrizione delle funzionalità e il rilascio in produzione nel 95% dei casi è inferiore a una settimana? La qualità dell'artefatto migliora in ogni fase della pipeline? C'è una storia che attraversa? Utilizzi strategie di distribuzione diverse?
Se tutte le risposte sono sì, allora sei incredibilmente forte! Scrivi le tue risposte nei commenti - ne sarò felice).
Contattaci
Questa è la pratica più difficile di tutte. Alla conferenza DevOpsConf, un collega di Infobip, parlandone, è rimasto un po' confuso nelle sue parole, perché questa è davvero una pratica molto complessa in quanto bisogna monitorare tutto!
Ad esempio, molto tempo fa, quando lavoravo a Qik e ci siamo resi conto che bisognava monitorare tutto. Lo abbiamo fatto e ora abbiamo 150 articoli in Zabbix, costantemente monitorati. È stato spaventoso, il direttore tecnico si è girato il dito alla tempia:
- Ragazzi, perché violentate il server con qualcosa di poco chiaro?
Ma poi si è verificato un incidente che ha dimostrato che questa è davvero una strategia davvero interessante.
Uno dei servizi ha iniziato a bloccarsi costantemente. Inizialmente, non si è bloccato, il che è interessante, il codice non è stato aggiunto lì, perché si trattava di un broker di base, che praticamente non aveva funzionalità aziendali: inviava semplicemente messaggi tra singoli servizi. Il servizio non è cambiato per 4 mesi e improvvisamente ha iniziato a bloccarsi con l'errore "Errore di segmentazione".
Siamo rimasti scioccati, abbiamo aperto i nostri grafici in Zabbix e si è scoperto che una settimana e mezza fa il comportamento delle richieste nel servizio API utilizzato da questo broker è cambiato notevolmente. Successivamente abbiamo visto che la frequenza di invio di un certo tipo di messaggio era cambiata. Successivamente abbiamo scoperto che si trattava di client Android. Noi abbiamo chiesto:
— Ragazzi, cosa vi è successo una settimana e mezza fa?
In risposta, abbiamo ascoltato una storia interessante su come avevano riprogettato l'interfaccia utente. È improbabile che qualcuno dica immediatamente di aver cambiato la libreria HTTP. Per i clienti Android è come cambiare il sapone in bagno: semplicemente non se lo ricordano. Di conseguenza, dopo 40 minuti di conversazione, abbiamo scoperto che avevano cambiato la libreria HTTP e che i suoi tempi predefiniti erano cambiati. Ciò ha portato a un cambiamento del comportamento del traffico sul server API, che ha portato a una situazione che ha causato una corsa all'interno del broker e ha iniziato a bloccarsi.
Senza un monitoraggio approfondito è generalmente impossibile aprirlo. Se l’organizzazione ha ancora il problema dei “pozzi”, quando tutti si lanciano soldi a vicenda, questo può durare per anni. Riavvia semplicemente il server perché è impossibile risolvere il problema. Quando monitori, tieni traccia, tieni traccia di tutti gli eventi che hai e usi il monitoraggio come test - scrivi codice e indichi immediatamente come monitorarlo, anche sotto forma di codice (abbiamo già l'infrastruttura come codice), tutto diventa chiaro come sul palmo. Anche problemi così complessi possono essere facilmente rintracciati.
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 e alcune cose di base saranno già visibili lì. Successivamente li vedrai in Test, PredProd e test di carico. Raccogli informazioni in tutte le fasi, non solo metriche, statistiche, ma anche registri: come è stata lanciata l'applicazione, anomalie: raccogli tutto.
Altrimenti sarà difficile capirlo. Ho già detto che DevOps è più complesso. Per far fronte a questa complessità, è necessario disporre di analisi normali.
Domande per l'autocontrollo
Il monitoraggio e la registrazione sono lo strumento di sviluppo adatto a te? Quando scrivi il codice, i tuoi sviluppatori, te compreso, pensano a come monitorarlo?
Hai sentito parlare di problemi da parte dei clienti? Comprendi meglio il client dal monitoraggio e dal logging? Comprendi meglio il sistema dal monitoraggio e dalla registrazione? Cambiate il sistema semplicemente perché avete visto che la tendenza nel sistema è in crescita e capite che tra altre 3 settimane tutto morirà?
Una volta che hai questi tre componenti, puoi pensare a che tipo di piattaforma infrastrutturale hai nella tua azienda.
Piattaforma infrastrutturale
Il punto non è che si tratti di un insieme di strumenti disparati che ogni azienda possiede.
Lo scopo di una piattaforma infrastrutturale è che tutti i team utilizzino questi strumenti e li sviluppino insieme.
È chiaro che esistono team separati responsabili dello sviluppo di singole parti della piattaforma infrastrutturale. Ma allo stesso tempo, ogni ingegnere è responsabile dello sviluppo, delle prestazioni e della promozione della piattaforma infrastrutturale. A livello interno diventa uno strumento comune.
Tutti i team sviluppano la piattaforma dell'infrastruttura e la trattano con cura come il proprio IDE. Nel tuo IDE installi diversi plugin per rendere tutto bello e veloce e configuri i tasti di scelta rapida. Quando apri Sublime, Atom o Visual Studio Code, compaiono errori di codice e ti rendi conto che è impossibile lavorare, ti senti immediatamente triste e corri a riparare il tuo IDE.
Tratta la tua piattaforma infrastrutturale allo stesso modo. Se capisci che c'è qualcosa che non va, lascia una richiesta se non puoi risolverlo da solo. Se c'è qualcosa di semplice, modificalo tu stesso, invia una richiesta pull, i ragazzi lo prenderanno in considerazione e lo aggiungeranno. Questo è un approccio leggermente diverso agli strumenti di ingegneria nella testa dello sviluppatore.
La piattaforma infrastrutturale garantisce il trasferimento dell'artefatto dallo sviluppo al cliente con un continuo miglioramento della qualità. L'IP è programmato con una serie di storie che accadono al codice in produzione. Nel corso degli anni di sviluppo, sono apparse molte di queste storie, alcune sono uniche e riguardano solo te: non possono essere cercate su Google.
A questo punto, la piattaforma infrastrutturale diventa il tuo vantaggio competitivo, perché ha qualcosa di incorporato che non è nello strumento della concorrenza. Più profondo è il tuo IP, maggiore sarà il tuo vantaggio competitivo in termini di Time-to-market. Appare qui problema del blocco del fornitore: Puoi prendere la piattaforma di qualcun altro, ma usando l'esperienza di qualcun altro, non capirai quanto sia rilevante per te. Sì, non tutte le aziende possono costruire una piattaforma come Amazon. Questa è una linea difficile in cui l’esperienza dell’azienda è rilevante per la sua posizione nel mercato e in quel caso non è possibile utilizzare il blocco del fornitore. Anche questo è importante su cui riflettere.
Guida
Questo è un diagramma di base di una piattaforma infrastrutturale che ti aiuterà a impostare tutte le pratiche e i processi in un'azienda DevOps.
Vediamo in cosa consiste.
Sistema di orchestrazione delle risorse, che fornisce CPU, memoria, disco alle applicazioni e altri servizi. In cima a questa - servizi di basso livello: monitoraggio, logging, motore CI/CD, archiviazione degli artefatti, infrastruttura come codice di sistema.
Servizi di livello superiore: database come servizio, code come servizio, bilanciamento del carico come servizio, ridimensionamento immagini come servizio, Big Data Factory come servizio. In cima a questa - pipeline che fornisce codice costantemente modificato al tuo cliente.
Ricevi informazioni su come funziona il tuo software per il cliente, lo modifichi, fornisci nuovamente questo codice, ricevi informazioni - e così sviluppi costantemente sia la piattaforma dell'infrastruttura che il tuo software.
Nel diagramma, la pipeline di consegna è composta da molte fasi. Ma questo è un diagramma schematico fornito come esempio: non è necessario ripeterlo uno per uno. Le fasi interagiscono con i servizi come se fossero servizi: ogni elemento della piattaforma porta con sé la propria storia: come vengono allocate le risorse, come viene avviata l'applicazione, come funziona con le risorse, come viene monitorata e come cambia.
È importante capire che ogni parte della piattaforma porta con sé una storia e chiedersi quale storia porta questo mattone, forse dovrebbe essere buttato via e sostituito con un servizio di terze parti. Ad esempio, è possibile installare Okmeter al posto del brick? Forse i ragazzi hanno già sviluppato questa competenza molto più di noi. Ma forse no: forse abbiamo competenze uniche, dobbiamo installare Prometheus e svilupparlo ulteriormente.
Creazione della piattaforma
Questo è un processo di comunicazione complesso. Una volta acquisite le pratiche di base, si avvia la comunicazione tra diversi ingegneri e specialisti che sviluppano requisiti e standard e li modificano costantemente con strumenti e approcci diversi. La cultura che abbiamo in DevOps è importante qui.
Con la cultura tutto è molto semplice - si tratta di collaborazione e comunicazione, cioè il desiderio di lavorare insieme in un campo comune, il desiderio di maneggiare insieme uno strumento. Non c'è scienza missilistica qui: tutto è molto semplice, banale. Ad esempio, viviamo tutti nell'ingresso e lo manteniamo pulito: un tale livello di cultura.
Cosa hai?
Ancora una volta, domande che puoi porti.
La piattaforma infrastrutturale è dedicata? Chi è responsabile del suo sviluppo? Comprendi i vantaggi competitivi della tua piattaforma infrastrutturale?
È necessario porsi costantemente queste domande. Se qualcosa può essere trasferito a servizi di terze parti, dovrebbe essere trasferito; se un servizio di terze parti inizia a bloccare i tuoi movimenti, allora devi costruire un sistema dentro di te.
Quindi, DevOps...
...questo è un sistema complesso, deve avere:
- Prodotto digitale.
- Moduli aziendali che sviluppano questo prodotto digitale.
- Team di prodotto che scrivono codice.
- Pratiche di consegna continua.
- Piattaforme come servizio.
- Infrastruttura come servizio.
- Infrastruttura come codice.
- Pratiche separate per il mantenimento dell'affidabilità, integrate in DevOps.
- Una pratica di feedback che descrive tutto.
Puoi utilizzare questo diagramma, evidenziando in esso ciò che già hai nella tua azienda in qualche forma: si è sviluppato o deve ancora essere sviluppato.
Sarà tutto finito tra un paio di settimane . come parte del RIT++. Vieni alla conferenza, dove troverai molti report interessanti sulla distribuzione continua, sull'infrastruttura come codice e sulla trasformazione DevOps. , l'ultima scadenza del prezzo è il 20 maggio
Fonte: habr.com