Smashing Podcast Episodio 42 con Jeff Smith: cos'è DevOps?

In questo episodio parliamo di DevOps. Che cos'è ed è una stringa da aggiungere al tuo arco di sviluppo web? Drew McLellan parla con l'esperto Jeff Smith per scoprirlo.

Mostra note

• Jeff su Twitter
• Il libro di Jeff Operations Anti-Patterns, DevOps Solutions
• DevOps raggiungibili

Aggiornamento settimanale

• Colmare il divario tra designer e sviluppatori scritto da Matthew Talebi
• Utili API React per la creazione di componenti flessibili con TypeScript scritto da Gaurav Khanna
• Soluzioni CSS intelligenti per le sfide comuni dell'interfaccia utente scritte da Cosima Mielke
• Suggerimenti e trucchi per la valutazione dei designer UX/UI scritti da Nataliya Sambir
• Risolvere i problemi di CLS in un sito Web di e-commerce basato su Next.js scritto da Arijit Mondal

Trascrizione

Drew McLellan: È un professionista DevOps che si concentra sui livelli raggiungibili delle implementazioni DevOps, indipendentemente da dove ti trovi nel tuo viaggio. È direttore delle operazioni di produzione presso la piattaforma di pubblicità digitale Centro, oltre ad essere un oratore pubblico, condividendo le sue conoscenze DevOps con il pubblico di tutto il mondo. È l'autore del libro Operations Anti-Patterns, DevOps Solutions for Manning Publishing, che mostra come implementare le tecniche DevOps nel tipo di ambienti imperfetti in cui lavora la maggior parte degli sviluppatori. Quindi sappiamo che è un esperto di DevOps, ma lo sapevi George Clooney lo considera il miglior produttore di aeroplani di carta di una generazione? Miei amici Smashing, per favore diamo il benvenuto a Jeff Smith. Ciao Jeff. Come stai?

Jeff Smith: Sto smashing, Drew, come stai?

Drew: Sto bene. Grazie. È bello sentirlo. Quindi volevo parlarti oggi dell'argomento DevOps, che è una delle tue principali aree chiave. Molti dei nostri ascoltatori saranno coinvolti nello sviluppo di app e web, ma forse hanno solo una vaga familiarità con ciò che accade dal lato operativo delle cose. So che quelli di noi che potrebbero lavorare in aziende più grandi avranno interi team di colleghi che stanno facendo operazioni. Siamo solo grati che qualunque cosa facciano, la stiano facendo bene. Ma sentiamo parlare di DevOps sempre di più e sembra una di quelle cose che come sviluppatori dovremmo davvero capire. Allora Jeff, cos'è DevOps?

Jeff: Quindi, se chiedi a 20 persone cos'è DevOps, potresti ottenere 20 risposte diverse. Quindi ti darò la mia opinione, va bene, e sappi che se sei a una conferenza e ne parli, potresti litigare con qualcuno. Ma per me, DevOps riguarda davvero quella relazione tra, e ci concentriamo su sviluppo e operazioni, ma in realtà quella relazione tra i team e come strutturare il nostro lavoro e, cosa più importante, strutturare i nostri obiettivi e incentivi per assicurarci che siano allineati in modo da lavorare verso un obiettivo comune. E molte delle idee e dei concetti fondamentali di DevOps provengono dal vecchio mondo in cui dev e op erano sempre contraddittori, dove c'era questo conflitto costante. E quando ci pensi, è per il modo in cui queste due squadre sono incentivate. Una squadra è incentivata a spingere i cambiamenti. Un'altra squadra è incentivata a mantenere la stabilità, il che significa meno cambiamenti.

Jeff: Quando lo fai, crei questo conflitto intrinseco e tutto fuoriesce da lì. Quindi DevOps consiste davvero nell'allineare quei team e obiettivi in ​​modo da lavorare verso una strategia comune, ma anche adottare pratiche da entrambe le parti, in modo che lo sviluppatore capisca di più sulle operazioni e le operazioni capiscano di più sugli sviluppatori, come un modo per guadagnare e condividere empatia reciproca in modo da comprendere la prospettiva da cui proviene l'altra persona.

Jeff: Ma poi anche per migliorare il nostro lavoro. Perché ancora, se comprendo il tuo punto di vista e ne tengo conto nel mio lavoro, sarà molto più vantaggioso per ognuno di noi. E c'è molto che gli operatori possono imparare dagli sviluppatori in termini di automazione e come affrontiamo le cose in modo che siano facilmente riproducibili. Quindi è questa fusione e abilità. E quello che vedi ora è che questo si applica a diverse combinazioni di gruppi, quindi senti cose come DevSecOps, DevSecFinOps, DevSecFinHROps. Continuerà a crescere e crescere e crescere. Quindi è davvero una lezione che possiamo eliminare in tutta l'organizzazione.

Drew: Quindi è necessario prendere alcuni dei concetti che comprendiamo come sviluppatori e diffondere ulteriormente le nostre idee nell'organizzazione e allo stesso tempo imparare ciò che possiamo dalle operazioni per cercare di far avanzare tutti.

Jeff: Assolutamente sì. E un altro aspetto delle operazioni, di cui l'hai menzionato un po' nell'introduzione, è che pensiamo che sia solo per queste organizzazioni più grandi con team operativi dedicati e cose del genere, ma una cosa a cui pensare è che le operazioni stanno accadendo nella tua organizzazione, indipendentemente dalle dimensioni. È solo questione di farlo tu, o se c'è un team separato che lo fa, ma in qualche modo stai distribuendo codice. In qualche modo hai un server là fuori in esecuzione da qualche parte. Quindi le operazioni esistono da qualche parte nella tua organizzazione, indipendentemente dalle dimensioni. La domanda è: chi lo sta facendo? E se si tratta di una singola persona o di un singolo gruppo, DevOps potrebbe anche essere ancora più particolarmente importante per te, poiché è necessario comprendere il tipo di cose che fanno le operazioni.

Drew: Come sviluppatori professionisti, quanto pensi sia importante per noi avere una buona conoscenza di cosa sia DevOps e cosa significa implementarlo?

Jeff: Penso che sia estremamente importante, specialmente in questa fase del viaggio DevOps. E il motivo per cui penso che sia importante è quello, penso che siamo sempre più efficienti, di nuovo, quando capiamo cosa stanno facendo le nostre controparti. Ma l'altra cosa è essere in grado di tenere conto delle preoccupazioni operative durante lo sviluppo del progetto e l'implementazione di qualsiasi tecnologia. Quindi una cosa che ho imparato nella mia carriera è che anche se pensavo che gli sviluppatori fossero i padroni dell'universo e capissero tutto ciò che aveva a che fare con i computer, in realtà non è così. Si scopre che ci sono molte cose che esternalizzano alle operazioni in termini di comprensione e, a volte, ciò si traduce in particolari scelte di progettazione o scelte di implementazione che potrebbero non essere ottimali per un'implementazione di produzione.

Jeff: Potrebbero andare bene in fase di sviluppo, test e cose del genere, ma una volta che arrivi alla produzione, è un po' diverso. Quindi non per dire che hanno bisogno di possedere quell'intero set di competenze, ma almeno hanno bisogno di sapere abbastanza per sapere ciò che non sanno. Quindi sanno quando coinvolgere le operazioni in anticipo, perché questo è uno schema comune che vediamo è che lo sviluppo fa una scelta. Non dirò nemmeno di fare una scelta perché non sono nemmeno consapevoli che si tratta di una scelta, ma succede qualcosa che porta a una decisione non ottimale per le operazioni e lo sviluppo era completamente all'oscuro. Quindi solo avere un po' più di conoscenza delle operazioni, anche se è appena sufficiente per dire, forse dovremmo portare le operazioni su questo per avere la loro prospettiva prima di andare avanti. Ciò potrebbe far risparmiare un sacco di tempo, energia e stabilità, ovviamente, in quanto si riferisce a qualsiasi prodotto tu stia rilasciando.

Drew: Vedo così tanti parallelismi con il modo in cui parli della relazione tra dev e ops come abbiamo fatto tra design e dev, dove hai designer che lavorano forse su come funziona e appare un'interfaccia e hanno una buona comprensione di come verrà effettivamente costruito nel ruolo di sviluppo e portare gli sviluppatori a consultarsi può davvero migliorare la soluzione generale solo avendo quella comunicazione chiara e una comprensione di ciò che fanno gli altri. Sembra che sia lo stesso principio giocato con DevOps, che è davvero molto bello da ascoltare.

Drew: Quando penso alle cose che sento su DevOps, sento termini come Kubernetes, Docker, Jenkins, CircleCI. Ho sentito parlare di Kubernetes per anni. Non ho ancora idea di cosa sia, ma da quello che stai dicendo, sembra che DevOps non riguardi solo ... Non stiamo parlando solo di strumenti qui, vero? Ma di più sui processi e sui modi di comunicare sui flussi di lavoro, giusto?

Jeff: Assolutamente. Quindi il mio mantra negli ultimi 20 anni è sempre stato gli strumenti di processo delle persone. Fai in modo che le persone accettino la visione. Da lì, definisci qualunque sarà il tuo processo per raggiungere quella visione. E poi usi strumenti che modelleranno qualunque sia il tuo processo. Quindi metto sempre gli strumenti alla fine della conversazione DevOps, principalmente perché se non hai quel buy-in, non importa. Potrei inventare la più grande pipeline di distribuzione continua di sempre, ma se le persone non sono convinte dell'idea di inviare ogni modifica direttamente alla produzione, non importa, giusto? A cosa serve lo strumento? Quindi quegli strumenti fanno sicuramente parte della conversazione, solo perché sono un modo standardizzato per raggiungere alcuni obiettivi comuni che abbiamo definito.

Jeff: Ma devi assicurarti che quegli obiettivi che vengono definiti abbiano un senso per la tua organizzazione. Forse la distribuzione continua non ha senso per te. Forse non vuoi spedire ogni singola modifica nel momento in cui esce. E ci sono molte aziende e organizzazioni e ragioni per cui non vorresti farlo. Quindi forse qualcosa come una pipeline di distribuzione continua non ha senso per te. Quindi, mentre gli strumenti sono importanti, è più importante concentrarsi su ciò che fornirà valore per la tua organizzazione, quindi modellare e implementare gli strumenti necessari per raggiungere questo obiettivo.

Jeff: Ma non andare online e scoprire cosa stanno facendo tutti e pensare, oh, beh, se vogliamo fare DevOps, dobbiamo passare a Docker e Kubernetes perché questa è la catena degli strumenti. No, non è questo. Potresti non aver bisogno di quelle cose. Non tutti sono Google. Non tutti sono Netflix. Smetti di leggere i post di Netflix e Google. Per favore, smettila di leggerli. Perché fa eccitare tutte le persone e pensano, beh, questo è quello che dobbiamo fare. Ed è come, beh, stanno risolvendo problemi molto diversi dai problemi che hai tu.

Drew: Quindi, se dico che sto iniziando un nuovo progetto, forse sono un'azienda in fase di avvio, che crea software come prodotto di servizio. Ho tre sviluppatori, ho un repository Git vuoto e ho sogni di IPO. Per essere completamente coinvolto in un approccio DevOps alla creazione di questo prodotto, quali sono i nomi degli elementi costitutivi che dovrei avere in termini di persone e processi e da dove inizio?

Jeff: Quindi nel tuo esempio specifico, il primo punto da cui inizierei è puntare il più possibile su di esso e usare qualcosa come Heroku o qualcosa di simile. Perché sei così entusiasta di tutta questa roba AWS, roba Docker e, in realtà, è così difficile creare un prodotto di successo. L'idea che ti stai concentrando sulla parte DevOps è come, beh, direi di esternalizzare quanto più possibile di quella roba finché non diventa effettivamente un punto dolente. Ma se sei a quel punto in cui dici okay, siamo pronti a portare questa roba in casa e siamo pronti a portarla al livello successivo. Direi che il primo punto di partenza è, dove sono i tuoi punti deboli? quali sono le cose che ti creano problemi?

Jeff: Quindi per alcune persone è semplice come un test automatizzato. L'idea che, ehi, abbiamo bisogno di eseguire test ogni volta che qualcuno fa un commit, perché a volte spediamo cose che vengono catturate dagli unit test che abbiamo già scritto. Allora forse inizi con l'integrazione continua. Forse le tue implementazioni richiedono ore per essere completate e sono molto manuali, quindi è lì che ti concentri e dici tipo, ok, di quale automazione abbiamo bisogno per essere in grado di renderlo un affare con un solo clic? Ma odio prescrivere un generale, è qui che inizi, solo perché la tua situazione particolare e i tuoi particolari punti dolenti saranno diversi. E il fatto è che, se è un punto dolente, dovrebbe urlarti contro. Dovrebbe assolutamente urlarti contro.

Jeff: Dovrebbe essere una di quelle cose in cui qualcuno dice, oh, cosa fa schifo nella tua organizzazione? E dovrebbe essere come, oh, so esattamente di cosa si tratta. Quindi, quando ti avvicini da quella prospettiva, penso che i passaggi successivi ti diventino abbastanza evidenti in termini di ciò che nella casella degli strumenti DevOps devi decomprimere e iniziare a lavorare. E poi diventano questi cambiamenti incrementali minimi che continuano ad arrivare e noti che man mano che ottieni nuove capacità, il tuo appetito per cose scadenti diventa molto piccolo. Quindi vai da tipo, oh sì, gli schieramenti richiedono tre ore e va bene. Ci hai messo un po' di impegno e la prossima cosa che sai, tra tre settimane, sei tipo, amico, non riesco a credere che lo spiegamento stia ancora impiegando 30 minuti. Come facciamo a farlo scendere da 30 minuti? Il tuo appetito diventa insaziabile per il miglioramento. Quindi le cose in qualche modo fuoriescono da lì.

Drew: Ho letto il tuo libro recente e questo mette in evidenza quelli che tu chiami i quattro pilastri di DevOps. E nessuno di questi è uno strumento, come accennato, ma ci sono queste quattro aree principali di interesse, se vuoi, per DevOps. Ho notato che il primo di questi è la cultura, ne sono rimasto piuttosto sorpreso, in primo luogo, perché mi aspettavo che parlassi di più di strumenti e ora capiamo perché, ma quando si tratta di cultura, sembra proprio strano cosa da avere all'inizio C'è una base per un approccio tecnico. In che modo la cultura influisce sul successo dell'implementazione DevOps all'interno di un'organizzazione?

Drew: … quanto può essere efficace l'implementazione di DevOps all'interno di un'organizzazione.

Jeff: La cultura è davvero la base di tutto quando ci pensi. Ed è importante perché la cultura, e ne parleremo un po' più a fondo nel libro, ma la cultura pone davvero le basi per le norme all'interno dell'organizzazione. Destra. Probabilmente sei stato in un'azienda in cui, se hai inviato un PR senza test automatizzati, non è una cosa importante. La gente lo accetta e va avanti.

Jeff: Ma poi ci sono altre org in cui questo è un peccato capitale. Destra. Dove se l'hai fatto, è come "Whoa, sei pazzo? Cosa stai facendo? Non ci sono casi di test qui". Destra. Questa è cultura però. Questa è la cultura che sta imponendo quella norma per dire come "Questo non è quello che facciamo".

Jeff: Chiunque può scrivere un documento in cui si afferma che avremo casi di test automatizzati, ma la cultura dell'organizzazione è ciò che impone quel meccanismo tra le persone. Questo è solo un piccolo esempio del perché la cultura è così importante. Se hai un'organizzazione in cui la cultura è una cultura della paura, una cultura della retribuzione. È come se commettessi un errore, giusto, quello fosse un sacrilegio. Destra. Ciò equivale a tradimento. Destra.

Jeff: In quell'organizzazione crei comportamenti contrari a tutto ciò che potrebbe essere rischioso o potenzialmente fallire. E questo finisce per lasciare molte opportunità sul tavolo. Mentre se crei una cultura che abbraccia l'apprendimento dal fallimento, abbraccia questa idea di sicurezza psicologica, dove le persone possono sperimentare. E se si sbagliano, possono capire come fallire in sicurezza e riprovare. Ottieni una cultura della sperimentazione. Ottieni un'organizzazione in cui le persone sono aperte a nuove idee.

Jeff: Penso che siamo stati tutti in quelle aziende in cui è stato come, "Beh, questo è proprio il modo in cui è stato fatto. E nessuno lo cambia". Destra. Non lo vuoi perché il mondo è in continua evoluzione. Ecco perché mettiamo la cultura in primo piano e al centro, perché molti dei comportamenti all'interno di un'organizzazione esistono a causa della cultura che esiste.

Jeff: E il fatto è che gli attori culturali possono essere nel bene o nel male. Destra. L'ironia, e ne parliamo anche nel libro, è che non ci vogliono tante persone quante si pensa per cambiare la cultura organizzativa. Destra. Perché la maggior parte delle persone, ci sono i detrattori, e poi ci sono i sostenitori, e poi ci sono i modelli di recinzione quando si tratta di qualsiasi tipo di cambiamento. E la maggior parte delle persone sono sitter di recinzione. Destra. Bastano pochi sostenitori per far pendere davvero la bilancia. Ma nello stesso senso, bastano davvero solo una manciata di detrattori per far pendere la bilancia.

Jeff: È come se non ci vuole molto per cambiare la cultura in meglio. E se ci metti quell'energia, anche senza essere un leader senior, puoi davvero influenzare la cultura della tua squadra, che poi finisce per influenzare la cultura del tuo dipartimento, che poi finisce per influenzare la cultura dell'organizzazione.

Jeff: Puoi apportare questi cambiamenti culturali come contributore individuale, semplicemente sposando queste idee e questi comportamenti ad alta voce e dicendo: "Questi sono i vantaggi che ne stiamo ottenendo". Ecco perché penso che la cultura debba essere in primo piano, perché devi convincere tutti a partecipare a questa idea e loro devono capire che, come organizzazione, ne varrà la pena e la sosterrà.

Drew: Sì. Deve essere uno stile di vita, suppongo.

Jeff: Esatto.

Drew: Sì. Sono molto interessato all'area dell'automazione perché durante la mia carriera non ho mai visto un'automazione messa in atto che non sia stata di beneficio. Destra. Voglio dire, a parte la cosa strana, forse in cui qualcosa è automatizzato e va storto. In genere, quando ti prendi il tempo per sederti e automatizzare qualcosa che hai fatto manualmente, ti fa sempre risparmiare tempo e spazio di testa, ed è solo un peso sulle tue spalle.

Drew: Adottando un approccio DevOps, che tipo di cose cercheresti di automatizzare all'interno dei tuoi flussi di lavoro? E quali vantaggi ti aspetteresti di vedere da questo rispetto al completamento delle cose manualmente?

Jeff: Quando si tratta di automazione, al tuo punto, molto raramente c'è un momento in cui l'automazione non ha migliorato la vita. Destra. Il problema che le persone incontrano è trovare il tempo per costruire quell'automazione. Destra. E di solito, nel mio attuale lavoro, per noi è proprio il punto della richiesta. Destra. Perché a un certo punto devi dire: "Smetterò di farlo manualmente e lo automatizzerò".

Jeff: E potrebbe essere il momento in cui ricevi una richiesta in cui dici: "Sai una cosa? Ci vorranno due settimane. So che normalmente lo risolviamo in un paio d'ore, ma ci vorranno due settimane perché questa è la richiesta che viene automatizzata". In termini di identificazione di ciò che automatizzate. In Central, utilizzo il processo in cui fondamentalmente proverei tutti i diversi tipi di richieste che sono arrivate in un periodo di quattro settimane, diciamo. E li classificherei come lavoro pianificato, lavoro non pianificato, lavoro a valore aggiunto, lavoro duro. La fatica è un lavoro che non è realmente utile, ma per qualche ragione la mia organizzazione deve farlo.

Jeff: E poi identificare quelle cose del tipo: "Ok, qual è il frutto a bassa pendenza di cui possiamo semplicemente sbarazzarci se dovessimo automatizzare questo? Cosa possiamo fare per semplificare tutto questo?" E alcuni dei criteri erano il rischio del processo. Destra. I failover automatici del database sono un po' spaventosi perché non li fai spesso. E le modifiche alle infrastrutture. Destra. Diciamo: "Quante volte facciamo questa cosa?" Se lo facciamo una volta all'anno, potrebbe non valere la pena automatizzarlo perché ha un valore molto scarso. Ma se è una di quelle cose che riceviamo due, tre volte al mese, va bene, diamo un'occhiata a quella. Va bene.

Jeff: Ora, quali sono le cose che possiamo fare per accelerare? E il fatto è che, quando parliamo di automazione, siamo immediatamente passati a: "Farò clic su un pulsante e questa cosa sarà magicamente fatta". Destra. Ma ci sono così tanti passaggi diversi che puoi fare nell'automazione se ti senti nauseato. Destra. Ad esempio, supponiamo che tu abbia 10 passaggi con 10 diversi comandi CLI che normalmente eseguiresti. Il tuo primo passo di automazione potrebbe essere semplice come eseguire quel comando o almeno mostrare quel comando. Destra. Di': "Ehi, questo è ciò che eseguirò. Pensi che vada bene?” "Sì." "Bene. Questo è il risultato che ho ottenuto. Va bene per me andare avanti?” "Sì." "Bene. Questo è il risultato che ho ottenuto". Destra.

Jeff: In questo modo hai ancora un po' di controllo. Ti senti a tuo agio. E poi, dopo 20 esecuzioni, ti rendi conto che stai solo colpendo, sì, sì, sì, sì, sì, sì. Tu dici: "Va bene. Mettiamo insieme tutte queste cose e rendiamole tutte una cosa sola". Non è che devi saltare nella parte più profonda di, fare clic su di esso e dimenticarlo subito dallo strappo. Puoi entrare in questo finché non ti senti a tuo agio.

Jeff: Questi sono i tipi di cose che abbiamo fatto come parte del nostro sforzo di automazione: come possiamo accelerare i tempi di risposta e ridurre il livello di sforzo da parte nostra? Potrebbe non essere al 100% il primo giorno, ma l'obiettivo è sempre arrivare al 100%. Inizieremo con piccoli pezzi di cui automatizzare parti con cui ci sentiamo a nostro agio. Sì. Siamo super fiduciosi che questo funzionerà. Questa parte su cui siamo un po' rischiosi, quindi forse avremo solo una verifica umana prima di procedere.

Jeff: L'altra cosa che abbiamo considerato in termini di automazione, ma qual è il valore che stiamo aggiungendo a un particolare processo? E questo è particolarmente importante per le operazioni. Perché molte volte le operazioni fungono da intermediario per un processo. Quindi il loro coinvolgimento non è altro che una cosa di accesso. Destra. È come se, beh, gli operatori devono farlo perché gli operatori sono l'unica persona che ha accesso.

Jeff: Beh, è ​​come, bene, come esternalizziamo quell'accesso in modo che le persone possano farlo? Perché la realtà è che non siamo preoccupati per gli sviluppatori che hanno accesso alla produzione. Destra. Siamo preoccupati per gli sviluppatori che hanno accesso illimitato alla produzione. E questa è davvero una questione di sicurezza. Destra. È come se la mia cassetta degli attrezzi avesse solo coltelli affilati, starò molto attento a chi li distribuirò. Ma se riesco a confondere la cassetta degli attrezzi con un cucchiaio e un martello in modo che le persone possano scegliere lo strumento giusto per il lavoro, allora è molto più facile prestarlo.

Jeff: Ad esempio, avevamo un processo in cui le persone dovevano eseguire script Ruby ad hoc in produzione, per qualsiasi motivo. Destra. Necessità di ripulire i dati, necessità di correggere qualche record errato, qualunque cosa. E questo sarebbe sempre arrivato attraverso la mia squadra. Ed è come, beh, non stiamo aggiungendo alcun valore a questo perché non posso approvare questo biglietto. Destra. Non ne ho idea. Hai scritto il software, quindi a che serve sedermi dietro le tue spalle e dire: "Beh, penso che sia sicuro"? Destra. Non ho aggiunto alcun valore alla digitazione perché sto solo digitando esattamente ciò che mi hai detto di digitare. Destra.

Jeff: E nel peggiore dei casi, e alla fine, sono davvero solo un ostacolo per te perché stai inviando un biglietto, quindi stai aspettando che torni dal pranzo. Sono tornato da pranzo, ma ho queste altre cose su cui lavorare. Abbiamo detto: "Come possiamo automatizzare questo in modo da poterlo mettere nelle mani degli sviluppatori e allo stesso tempo affrontare uno di questi problemi di audit che potremmo avere?"

Jeff: L' abbiamo inserito in un flusso di lavoro JIRA, in cui avevamo un bot che avrebbe automatizzato l'esecuzione dei comandi specificati nel ticket JIRA. E poi potremmo specificare nel ticket JIRA che richiedeva l'approvazione di uno dei numerosi ingegneri senior. Destra.

Jeff: Ha più senso che un ingegnere approvi il lavoro di un altro ingegnere perché ha il contesto. Destra. Non devono stare seduti ad aspettare le operazioni. Il pezzo di controllo riceve una risposta perché abbiamo un flusso di lavoro chiaro che è stato definito in JIRA che viene documentato come qualcuno approva, come qualcuno ha richiesto. E abbiamo l'automazione che tira quel comando ed esegue quel comando alla lettera nel terminale. Destra.

Jeff: Non devi preoccuparti che io abbia sbagliato a scrivere. Non devi preoccuparti che io prenda il biglietto sbagliato. Ciò ha aumentato il tempo di consegna di quei biglietti, qualcosa come dieci volte. Destra. Gli sviluppatori sono sbloccati. La mia squadra non è impegnata a farlo. E tutto ciò che è veramente servito è stato un investimento di una o due settimane per sviluppare effettivamente l'automazione e le autorizzazioni necessarie per ottenere l'accesso.

Jeff: Ora siamo completamente rimossi da quello. E lo sviluppo è effettivamente in grado di esternalizzare alcune di queste funzionalità a parti inferiori dell'organizzazione. Lo hanno spinto al servizio clienti. È come ora quando l'assistenza clienti sa che questo record deve essere aggiornato per qualsiasi cosa, non ha bisogno di sviluppo. Possono inviare il loro script standard che abbiamo approvato per questa funzionalità. E possono eseguirlo attraverso lo stesso identico flusso di lavoro dello sviluppo. È davvero un vantaggio tutto intorno.

Jeff: E poi ci permette di spingere il lavoro sempre più in basso in tutta l'organizzazione. Perché mentre lo facciamo, il lavoro diventa sempre più economico perché potrei avere uno sviluppatore elegante e costoso che lo esegue. Destra. Oppure posso chiedere a un addetto all'assistenza clienti che lavora direttamente con il cliente, di eseguirlo da solo mentre è al telefono con un cliente che corregge un problema.

Jeff: Penso che l'automazione sia la chiave di qualsiasi organizzazione. E l'ultimo punto che dirò è che ti consente anche di esportare esperienza. Destra. Ora, potrei essere l'unica persona che sa come farlo se avessi bisogno di eseguire un sacco di comandi sulla riga di comando. Ma se lo metto nell'automazione, posso darlo a chiunque. E le persone sanno qual è il risultato finale, ma non hanno bisogno di conoscere tutti i passaggi intermedi. Ho aumentato di dieci volte il mio valore spingendolo all'esterno dell'organizzazione e prendendo la mia esperienza e codificandola in qualcosa che è esportabile.

Drew: Hai parlato di automatizzare le attività che si verificano frequentemente. C'è un argomento per automatizzare anche le attività che accadono così di rado che uno sviluppatore impiega molto tempo per tornare al passo con come dovrebbe funzionare? Perché tutti sono dimenticati. È passato così tanto. È passato un anno, forse nessuno l'ha fatto prima. C'è un argomento per automatizzare anche questo genere di cose?

Jeff: Questo è un atto di equilibrio difficile. Destra. E io dico sempre di valutare caso per caso. E il motivo per cui lo dico è che uno dei mantra in DevOps è se qualcosa di doloroso, fallo più spesso. Destra. Perché più spesso lo fai, più memoria muscolare diventa e puoi allenarti e appianare quei nodi.

Jeff: Il problema che vediamo con l'automazione di attività molto rare è che il panorama dell'ambiente tende a cambiare tra un'esecuzione e l'altra di tale automazione. Destra. Quello che finisce per accadere è che il tuo codice fa ipotesi particolari sull'ambiente e quelle ipotesi non sono più valide. Quindi l'automazione finisce comunque per rompersi.

Drew: E poi hai due problemi.

Jeff: Giusto. Destra. Esattamente. Esattamente. E tu dici: "Ho sbagliato a digitare? O è questo? No, questa cosa in realtà è rotta. Così-

Jeff: Digitando sbagliato o no, questa cosa è in realtà rotta. Quindi, quando si tratta di automatizzare attività poco frequenti, lo prendiamo caso per caso per capire, beh, qual è il rischio se questo non funziona, giusto. Se sbagliamo, siamo in un cattivo stato o è solo che non abbiamo finito questo compito? Quindi, se puoi assicurarti che ciò fallisca con grazia e non abbia un impatto negativo, allora vale la pena provare ad automatizzarlo. Perché almeno, allora hai un quadro di comprensione di cosa dovrebbe succedere perché almeno qualcuno sarà in grado di leggere il codice e capire, va bene, questo è quello che stavamo facendo. E non capisco perché questo non funzioni più, ma ho una chiara comprensione di cosa sarebbe dovuto accadere almeno in base al momento della progettazione quando è stato scritto.

Jeff: Ma se ti trovi in ​​una situazione in cui un errore potrebbe portare a modifiche ai dati o cose del genere, di solito erro per eccesso di cautela e lo tengo manuale solo perché se ho uno script di automazione, se trovo un documento di confluenza sono tre anni che dicono di eseguire questo script, tendo ad avere il cento per cento di fiducia in quello script e lo eseguo. Destra. Considerando che se si tratta di una serie di passaggi manuali che è stata documentata quattro anni fa, dirò che devo fare qualche verifica qui. Destra? Fammi fare un passo avanti e parlare con alcune persone. E a volte, quando progettiamo processi, vale la pena forzare quel processo di pensiero, giusto? E devi pensare alla componente umana ea come si comporteranno. E a volte vale la pena rendere il processo un po' più macchinoso per costringere le persone a pensare che dovrei farlo ora?

Drew: Ci sono altri modi per identificare cosa dovrebbe essere automatizzato attraverso una sorta di monitoraggio dei tuoi sistemi e misurazione delle cose? Voglio dire, penso a DevOps e penso ai dashboard come una delle cose, bei grafici. E sono sicuro che c'è molto di più in quei dashboard oltre al semplice aspetto carino, ma è sempre bello avere dashboard belli. Ci sono modi per misurare ciò che un sistema sta facendo per aiutarti a prendere questo tipo di decisioni?

Jeff: Assolutamente. E quel tipo di passaggio prosegue nella parte relativa alle metriche delle camme, giusto, quali sono le cose che stiamo monitorando nei nostri sistemi per sapere che stanno funzionando in modo efficiente? E uno dei tipi più comuni di insidie ​​delle metriche è che cerchiamo errori invece di verificare il successo. E queste sono due pratiche molto diverse, giusto? Quindi qualcosa potrebbe fluire attraverso il sistema e non necessariamente generare errori, ma non necessariamente attraversare l'intero processo come dovrebbe. Quindi, se lasciamo un messaggio su una coda di messaggi, dovrebbe esserci una metrica corrispondente che dice "E questo messaggio è stato recuperato ed elaborato", giusto? In caso contrario, si avrà rapidamente uno squilibrio e il sistema non funzionerà come dovrebbe. Penso che possiamo usare le metriche come un modo per capire anche diverse cose che dovrebbero essere automatizzate quando entriamo in quegli stati negativi.

Jeff: Giusto? Perché molte volte è un passo molto semplice che deve essere fatto per ripulire le cose, giusto? Per le persone che sono state operative per un po', giusto, l'avviso di spazio su disco, lo sanno tutti. Oh, siamo pieni di dischi. Oh, abbiamo dimenticato che è la fine del mese e la fatturazione è stata eseguita e la fatturazione riempie sempre i registri. E poi il registro VAR sta consumando tutto lo spazio su disco, quindi è necessario eseguire una rotazione del registro. Destra? Potresti svegliarti alle tre del mattino per quello, se è una specie di tua preferenza. Ma se in qualche modo sappiamo che questo è il comportamento, le nostre metriche dovrebbero essere in grado di darci un indizio al riguardo. E possiamo semplicemente automatizzare il comando di rotazione del registro, giusto? Oh, abbiamo raggiunto questa soglia, esegui il comando di rotazione del registro. Vediamo se l'avviso scompare. Se lo fa, continua con la vita. Se così non fosse, allora forse sveglieremo qualcuno, giusto.

Jeff: Lo stai vedendo molto di più anche con l'automazione dell'infrastruttura, giusto, dove è come "Ehi, le nostre richieste al secondo stanno raggiungendo il nostro massimo teorico. Forse dobbiamo ridimensionare il cluster. Forse abbiamo bisogno di aggiungere tre o quattro nodi al pool di bilanciamento del carico". E possiamo farlo senza necessariamente richiedere l'intervento di qualcuno. Possiamo semplicemente esaminare quelle metriche e intraprendere quell'azione e quindi contrarre quell'infrastruttura una volta che scende al di sotto di una determinata soglia, ma devi avere quelle metriche e devi avere quei ganci nel tuo ambiente di monitoraggio per poterlo fare. Ed è qui che entra in gioco l'intera parte relativa alle metriche della conversazione.

Jeff: Inoltre è anche bello poter condividere queste informazioni con altre persone perché una volta che hai i dati, puoi iniziare a parlare di cose in una realtà condivisa, giusto, perché occupato è un termine generico, ma 5.200 richieste al secondo è qualcosa di molto più concreto su cui tutti possiamo ragionare. E penso così spesso quando parliamo di capacità o altro, usiamo questi termini ondulati, quando invece potremmo guardare un dashboard e dare valori molto specifici e assicurarci che tutti abbiano accesso a quei dashboard, che non sono nascosti dietro un muro operativo a cui solo noi abbiamo accesso per qualche motivo sconosciuto.

Drew: So while sort of monitoring and using metrics as a decision-making tool for the businesses is one aspect of it, it sounds like the primary aspect is having the system monitor itself, perhaps, and to respond maybe with some of these automations as the system as a whole gives itself feedback on onto what's happening.

Jeff: Absolutely. Feedback loops are a key part of any real system design, right, and understanding the state of the system at any one time. So while it's easy in the world where everything is working fine, the minute something goes bad, those sorts of dashboards and metrics are invaluable to have, and you'll quickly be able to identify things that you have not instrumented appropriately. Destra. So one of the things that we always talk about in incident management is what questions did you have for the system that couldn't be answered, right. So what is it, or you're like, “Oh man, if we only knew how many queries per second were going on right now.” Destra.

Jeff: Well, okay. How do we get that for next time? How do we make sure that that's radiated somewhere? And a lot of times it's hard when you're thinking green field to sit down and think of all the data that you might want at any one time. But when you have an incident, it becomes readily apparent what data you wish you had. So it's important to sort of leverage those incidents and failures and get a better understanding of information that's missing so that you can improve your incident management process and your metrics and dashboarding.

Drew: One of the problems we sometimes face in development is that teammate members, individual team members hold a lot of knowledge about how a system works and if they leave the company or if they're out sick or on vacation, that knowledge isn't accessible to the rest of the team. It seems like the sort of DevOps approach to things is good at capturing a lot of that operational knowledge and building it into systems. So that sort of scenario where an individual has got all the information in their head that doesn't happen so much. È una valutazione equa?

Jeff: It is. I think we've probably, I think as an industry we might have overstated its efficacy. And the only reason I say that is when our systems are getting so complicated, right? Gone are the days where someone has the entire system in their head and can understand it from beginning to end. Typically, there's two insidious parts of it. One, people typically focus on one specific area and someone doesn't have the whole picture, but what's even more insidious is that we think we understand how the system works. Destra. And it's not until an incident happens that the mental model that we have of the system and the reality of the system come into conflict. And we realize that there's a divergence, right? So I think it's important that we continuously share knowledge in whatever form is efficient for folks, whether it be lunch and learns, documentation, I don't know, presentations, anything like that to sort of share and radiate that knowledge.

Jeff: But we also have to prepare and we have to prepare and define a reality where people may not completely understand how the system works. Destra. And the reason I think it's important that we acknowledge that is because you can make a lot of bad decisions thinking you know how the system behaves and being 100% wrong. Destra. So having the wherewithal to understand, okay, we think this is how the system works. We should take an extra second to verify that somehow. Destra. I think that's super important in these complicated environments in these sprawling complex microservice environments. Whereas it can be very, it's easy to be cavalier if you think, oh yeah, this is definitely how it works. And I'm going to go ahead and shut the service down because everything's going to be fine. And then everything topples over. So just even being aware of the idea that, you know what, we may not know a hundred percent how this thing works.

Jeff: So let's take that into account with every decision that we make. I think that's key. And I think it's important for management to understand the reality of that as well because for management, it's easy for us to sit down and say, “Why didn't we know exactly how this thing was going to fail?” And it's like, because it's complicated, right, because there's 500 touch points, right, where these things are interacting. And if you change one of them, it changes the entire communication pattern. So it's hard and it's not getting any easier because we're getting excited about things like microservices. We're getting excited about things like Kubernetes. We're giving people more autonomy and these are just creating more and more complicated interfaces into these systems that we're managing. And it's becoming harder and harder for anyone to truly understand them in their entirety.

Drew: We've talked a lot about a professional context, big organizations and small organizations too. But I know many of us work on smaller side projects or maybe we volunteer on projects and maybe you're helping out someone in the community or a church or those sorts of things. Can a DevOps approach benefit those smaller projects or is it just really best left to big organizations to implement?

Jeff: I think DevOps can absolutely benefit those smaller projects. And specifically, because I think sort of some of the benefits that we've talked about get amplified in those smaller projects. Destra? So exporting of expertise with automation is a big one, right? If I am… Take your church example, I think is a great one, right? If I can build a bunch of automated tests suites to verify that a change to some HTML doesn't break the entire website, right, I can export that expertise so that I can give it to a content creator who has no technical knowledge whatsoever. Destra. They're a theologian or whatever, and they just want to update a new Bible verse or something, right. But I can export that expertise so that they know that I know when I make this content change, I'm supposed to run this build button.

Jeff: And if it's green, then I'm okay. And if it's red, then I know I screwed something up. Destra. So you could be doing any manner of testing in there that is extremely complicated. Destra. It might even be something as simple as like, hey, there's a new version of this plugin. And when you deploy, it's going to break this thing. Destra. So it has nothing to do with the content, but it's at least a red mark for this content creator to say “Oh, something bad happened. I shouldn't continue. Destra. Let me get Drew on the phone and see what's going on.” Destra. And Drew can say, “Oh right. This plugin is upgraded, but it's not compatible with our current version of WordPress or whatever.” Destra. So that's the sort of value that we can add with some of these DevOps practices, even in a small context, I would say specifically around automation and specifically around some of the cultural aspects too.

Jeff: Right? So I've been impressed with the number of organizations that are not technical that are using get to make changes to everything. Destra. And they don't really know what they're doing. They just know, well, this is what we do. This is the culture. And I add this really detailed commit message here. And then I push it. They are no better than us developers. They know three get commands, but it's the ones they use over and over and over again. But it's been embedded culturally and that's how things are done. So everyone sort of rallies around that and the people that are technical can take that pattern.

Jeff: … around that and the people that are technical can take that pattern and leverage it into more beneficial things that might even be behind the scenes that they don't necessarily see. So I think there's some value, definitely. It's a matter of how deep you want to go, even with the operations piece, right? Like being able to recreate a WordPress environment locally very easily, with something like Docker. They may not understand the technology or anything, but if they run Docker Compose Up or whatever, and suddenly they're working on their local environment, that's hugely beneficial for them and they don't really need to understand all the stuff behind it. In that case, it's worthwhile, because again, you're exporting that expertise.

Drew: We mentioned right at the beginning, sort of putting off as much sort of DevOps as possible. You mentioned using tools like Heroku. And I guess that sort of approach would really apply here on getting started with, with a small project. What sort things can platforms like Heroku offer? I mean, obviously, I know you're not a Heroku expert or representative or anything, but those sorts of platforms, what sort of tools are they offering that would help in this context?

Jeff: So for one, they're basically taking that operational context for you and they're really boiling it down into a handful of knobs and levers, right? So I think what it offers is one, it offers a very clear set of what we call the yellow brick road path, where it's like, “If you go this route, all of this stuff is going to be handled for you and it's going to make your life easier. If you want to go another route, you can, but then you got to solve for all this stuff yourself.” So following the yellow brick road route helps because one, they're probably identifying a bunch of things that you hadn't even thought of. So if you're using their database container or technology, guess what? You're going to get a bunch of their metrics for free. You're going to get a lot of their alerting for free. You didn't do anything. You didn't think anything. It's just when you need it, it's there. And it's like, “Oh wow, that's super are helpful.”

Jeff: Two, when it comes to performance sizing and flexibility, this becomes very easy to sort of manage because the goal is, you're a startup that's going to become wildly successful. You're going to have hockey stick growth. And the last thing you necessarily really want to be doing is figuring out how to optimize your code for performance, while at the same time delivering new features. So maybe you spend your way out of it. You say, “Well, we're going to go up to the next tier. I could optimize my query code, but it's much more efficient for me to be spending time building this next feature that's going to bring in this new batch of users, so let's just go up to the next tier,” and you click button and you move on.

Jeff: So being able to sort of spend your way out of certain problems, I think it's hugely beneficial because tech debt gets a bad rap, but tech debt is no different than any debt. It's the trade off of acquiring something now and dealing with the pain later. And that's a strategic decision that you have to make in every organization. So unchecked tech debt is bad, right? But tech debt generally, I think, is a business choice and Heroku and platforms like that enable you to make that choice when it comes to infrastructure and performance.

Drew: You've written a book, Operations, Anti-Patterns, DevOps Solutions, for Manning. I can tell it's packed with years of hard-earned experience. The knowledge sort of just leaps out from the page. And I can tell it's been a real labor of love. It's packed full of information. Who's your sort of intended audience for that book? Is it mostly those who are already working in DevOps, or is it got a broader-

Jeff: It's got a broader… So one of the motivations for the book was that there were plenty of books for people that we're already doing DevOps. You know what I mean? So we were kind of talking to ourselves and high-fiving each other, like, “Yeah, we're so advanced. Awesome.” But what I really wanted to write the book for were people that were sort of stuck in these organizations. I don't want to use the term stuck. That's unfair, but are in these organizations that maybe aren't adopting DevOps practices or aren't at the forefront of technology, or aren't necessarily cavalier about blowing up the way they do work today, and changing things.

Jeff: Volevo scriverlo a loro, principalmente ai singoli contributori e ai middle manager per dire: "Non è necessario essere un CTO per essere in grado di apportare questo tipo di modifiche incrementali e non è necessario avere questo l'intera rivoluzione delle vendite per poter ottenere alcuni dei vantaggi di DevOps". Quindi è stata davvero una specie di lettera d'amore per loro per dire: "Ehi, puoi farlo a pezzi. Puoi farlo da solo. E ci sono tutte queste cose che potresti non pensare siano correlate a DevOps perché lo consideri strumenti e Kubernetes". Non tutte le organizzazioni... Se tu fossi per questo Stato di New York, come il governo statale, non entrerai e implementerai Kubernetes dall'oggi al domani. Destra? Ma puoi implementare il modo in cui i team parlano tra loro, come lavorano insieme, come comprendiamo i problemi reciproci e come possiamo affrontarli attraverso l'automazione. Queste sono cose che rientrano nella tua sfera di influenza che possono migliorare la tua vita quotidiana.

Jeff: Quindi era davvero una lettera a quelle persone, ma penso che ci siano abbastanza dati e informazioni sufficienti per le persone che fanno parte di un'organizzazione DevOps da cui raccogliere e dire come: "Ehi, questo è ancora utile per noi. " E molte persone, penso, si identifichino rapidamente leggendo il libro, che non fanno parte di un'organizzazione DevOps, hanno solo un cambio di titolo di lavoro. E questo accade un bel po'. Quindi dicono tipo: "Ehi, ora siamo ingegneri DevOps, ma non stiamo facendo questo tipo di pratiche di cui si parla in questo libro e come ci arriviamo?"

Drew: Quindi sembra che il tuo libro sia uno di questi, ma ci sono altre risorse a cui le persone che cercano di iniziare con DevOps potrebbero rivolgersi? Ci sono buoni posti per imparare queste cose?

Jeff: Sì. Penso che DevOps For Dummies di Emily Freeman sia un ottimo punto di partenza. Fa davvero un ottimo lavoro nel sistemare alcuni dei concetti e delle idee fondamentali e per cosa ci stiamo battendo. Quindi sarebbe un buon punto di partenza, solo per avere un'idea del terreno. Penso che il Phoenix Project sia ovviamente un'altra grande fonte di Gene Kim. Ed è fantastico, questo tipo di preparazione pone le basi per i tipi di problemi che il non essere in un ambiente DevOps può creare. E fa un ottimo lavoro nel mettere in evidenza questi modelli e personalità che si verificano in tutti i tipi di organizzazioni più e più volte. Penso che faccia un ottimo lavoro nel metterli in evidenza. E se leggi quel libro, penso che finirai per urlare alle pagine dicendo: “Sì, sì. Questo. Questo." Quindi, questo è un altro posto fantastico.

Jeff: E poi da lì, tuffandoti in qualsiasi manuale DevOps. Mi prenderò a calci per averlo detto, ma il manuale SRE di Google era un altro ottimo posto dove guardare. Capisci che non sei Google, quindi non pensare di dover implementare tutto, ma penso che molte delle loro idee e strategie siano valide per qualsiasi organizzazione e siano ottimi posti dove puoi prendere le cose e dici come: "Ok, stiamo per rendere il nostro ambiente operativo un po' più efficiente". E questo, penso che sarà particolarmente importante per gli sviluppatori che stanno giocando un ruolo operativo, perché si concentra molto sul tipo di approccio programmatico per risolvere alcuni di questi problemi.

Drew: Quindi, ho imparato tutto su DevOps. Cosa stai imparando ultimamente, Jeff?

Jeff: Kubernetes, amico. Sì. Kubernetes è stata per noi una vera e propria fonte di lettura e conoscenza. Quindi stiamo cercando di implementarlo al Centro attualmente, come mezzo per potenziare ulteriormente gli sviluppatori. Vogliamo fare un passo avanti rispetto a dove siamo. Abbiamo un sacco di automazione in atto, ma in questo momento, quando si tratta di integrare un nuovo servizio, il mio team è ancora abbastanza coinvolto in questo, a seconda della natura del servizio. E non vogliamo essere in quella linea di lavoro. Vogliamo che gli sviluppatori siano in grado di portare un'idea dall'ideazione al codice fino alla distribuzione, e lo facciano laddove l'esperienza operativa è codificata all'interno del sistema. Quindi, mentre ti muovi attraverso il sistema, il sistema ti guida. Quindi pensiamo che Kubernetes sia uno strumento che ci aiuterà a farlo.

Jeff: È semplicemente incredibilmente complicato. Ed è un pezzo grosso da mordere. Quindi stai cercando di capire che aspetto hanno le distribuzioni? Come possiamo sfruttare questi operatori all'interno di Kubernetes? Che aspetto ha il CICD in questo nuovo mondo? Quindi ci sono state molte letture, ma in questo campo impari costantemente, giusto? Non importa da quanto tempo ci sei dentro, da quanto tempo lo fai, sei un idiota in qualche aspetto di questo campo da qualche parte. Quindi, è solo qualcosa a cui ti adatti

Drew: Bene, tanto di cappello come ho detto, anche dopo tutti questi anni, anche se in qualche modo capisco dove si trova nello stack, non ho ancora la più pallida idea di cosa stia facendo Kubernetes.

Jeff: A volte mi sento simile. Sembra che stia facendo un po' di tutto, giusto? È il DNS del 21° secolo.

Drew: Se tu, l'ascoltatore, vorresti sentire di più da Jeff, puoi trovarlo su Twitter, dove è oscuro e nerd, e trovare il suo libro e i collegamenti a presentazioni passate e post sul blog sul suo sito, raggiabledevops.com. Grazie per esserti unito a noi oggi, Jeff. Hai avuto qualche parola d'addio?

Jeff: Continua ad imparare, esci, continua ad imparare e parla con i tuoi compagni. Parla, parla, parla. Più puoi parlare con le persone con cui lavori, migliore comprensione, migliore empatia genererai per loro e, se c'è qualcuno in particolare nell'organizzazione che odi, assicurati di parlare prima con loro.