È difficile cogliere il punto principale quando si parla di DevOps? Abbiamo raccolto per te vivide analogie, formulazioni sorprendenti e consigli di esperti che aiuteranno anche i non specialisti ad arrivare al punto. Alla fine, il bonus è rappresentato dal DevOps dei dipendenti Red Hat.
Il termine DevOps è nato 10 anni fa ed è passato da un hashtag di Twitter a un potente movimento culturale nel mondo IT, una vera filosofia che incoraggia gli sviluppatori a fare le cose più velocemente, sperimentare e ripetere. DevOps è diventato indissolubilmente legato al concetto di trasformazione digitale. Ma come spesso accade con la terminologia IT, negli ultimi dieci anni DevOps ha acquisito molte definizioni, interpretazioni e idee sbagliate su se stesso.
Pertanto, puoi spesso sentire domande su DevOps come: è la stessa cosa di Agile? O si tratta di una metodologia speciale? O è solo un altro sinonimo della parola “collaborazione”?
DevOps include molti concetti diversi (consegna continua, integrazione continua, automazione, ecc.), quindi distillare ciò che è importante può essere difficile, soprattutto quando si è appassionati dell'argomento. Tuttavia, questa abilità è molto utile, non importa se stai cercando di trasmettere le tue idee ai tuoi superiori o semplicemente di parlare del tuo lavoro a qualcuno della tua famiglia o dei tuoi amici. Pertanto, per ora mettiamo da parte le sfumature terminologiche di DevOps e concentriamoci sul quadro generale.
Cos'è DevOps: 6 definizioni e analogie
Abbiamo chiesto agli esperti di spiegare l'essenza di DevOps nel modo più semplice e breve possibile in modo che il suo valore diventi chiaro ai lettori con qualsiasi livello di conoscenza tecnica. Sulla base dei risultati di queste conversazioni, abbiamo selezionato le analogie e le formulazioni più sorprendenti che ti aiuteranno a costruire la tua storia su DevOps.
1. DevOps è un movimento culturale
"DevOps è un movimento culturale in cui entrambe le parti (sviluppatori di software e specialisti del funzionamento dei sistemi IT) riconoscono che il software non porta vantaggi reali finché qualcuno non inizia a usarlo: clienti, committenti, dipendenti, non è questo il punto", afferma Eveline Oehrlich, ricercatrice senior analista presso il DevOps Institute. "Pertanto, entrambe le parti garantiscono congiuntamente una consegna rapida e di alta qualità del software."
2. DevOps significa dare più potere agli sviluppatori.
"DevOps consente agli sviluppatori di possedere applicazioni, eseguirle e gestirne la distribuzione dall'inizio alla fine."
"In genere, si parla di DevOps come di un modo per accelerare la consegna delle applicazioni alla produzione costruendo e implementando processi automatizzati", afferma Jai Schniepp, direttore delle piattaforme DevOps presso la compagnia assicurativa Liberty Mutual. “Ma per me è una cosa molto più fondamentale.” DevOps consente agli sviluppatori di possedere applicazioni o componenti software specifici, eseguirli e gestirne la distribuzione dall'inizio alla fine. DevOps elimina la confusione in materia di responsabilità e guida tutti i soggetti coinvolti nella creazione di un’infrastruttura automatizzata e guidata dagli sviluppatori”.
3. DevOps riguarda la collaborazione nella creazione e distribuzione di applicazioni.
“In parole povere, DevOps è un approccio alla produzione e distribuzione del software in cui tutti lavorano insieme”, afferma Gur Staf, presidente e responsabile dell’automazione aziendale digitale presso BMC.
4. DevOps è una pipeline
“L’assemblaggio del trasportatore è possibile solo se tutte le parti si incastrano tra loro.”
“Confronterei DevOps con una catena di montaggio di automobili”, continua Gur Staff. – L’idea è quella di progettare e realizzare in anticipo tutte le parti in modo che possano poi essere assemblate senza modifiche individuali. L'assemblaggio del trasportatore è possibile solo se tutte le parti si incastrano tra loro. Chi progetta e costruisce un motore deve considerare come montarlo sulla carrozzeria o sul telaio. Chi fa i freni deve pensare alle ruote, e così via. Lo stesso dovrebbe valere per il software.
Uno sviluppatore che crea una logica aziendale o un'interfaccia utente deve pensare al database che memorizza le informazioni sui clienti, alle misure di sicurezza per proteggere i dati degli utenti e a come tutto ciò funzionerà quando il servizio inizierà a servire un pubblico di utenti vasto, forse addirittura multimilionario. ."
“Convincere le persone a collaborare e a pensare alle parti del lavoro che svolgono gli altri, invece di concentrarsi esclusivamente sui propri compiti, è l’ostacolo più grande da superare. Se riesci a farlo, hai ottime possibilità di trasformazione digitale”, aggiunge Gur Staff.
5. DevOps è la giusta combinazione di persone, processi e automazione
Jayne Groll, direttore esecutivo del DevOps Institute, ha offerto un'ottima analogia per spiegare DevOps. Nelle sue parole, “DevOps è come una ricetta con tre categorie principali di ingredienti: persone, processi e automazione. La maggior parte di questi ingredienti possono essere presi da altre aree e fonti: Lean, Agile, SRE, CI/CD, ITIL, leadership, cultura, strumenti. Il segreto di DevOps, come ogni buona ricetta, è come ottenere le giuste proporzioni e mescolare questi ingredienti per aumentare la velocità e l’efficienza della creazione e del rilascio delle applicazioni”.
6. DevOps è quando i programmatori lavorano come un team di Formula 1
"La gara non è pianificata dall'inizio alla fine, ma al contrario, dall'arrivo all'inizio."
"Quando parlo di cosa aspettarmi da un'iniziativa DevOps, penso ad esempio a un team di corse NASCAR o di Formula 1", afferma Chris Short, senior manager del marketing della piattaforma cloud presso Red Hat ed editore della newsletter DevOps'ish. – Il leader di una squadra di questo tipo ha un obiettivo: prendere il posto più alto possibile alla fine della gara, tenendo conto delle risorse a disposizione della squadra e delle sfide che l’hanno colpita. In questo caso la gara non è pianificata dall'inizio alla fine, ma al contrario, dall'arrivo all'inizio. Innanzitutto viene fissato un obiettivo ambizioso e poi vengono determinate le modalità per raggiungerlo. Quindi vengono suddivisi in sottoattività e delegati ai membri del team”.
“La squadra trascorre tutta la settimana prima della gara a perfezionare il pit-stop. Fa allenamenti di forza e cardio per mantenersi in forma in vista di una giornata di gara estenuante. Pratiche di collaborazione per risolvere eventuali problemi che potrebbero sorgere durante la gara. Allo stesso modo, il team di sviluppo dovrebbe allenare la capacità di rilasciare frequentemente nuove versioni. Se si dispone di tali competenze e di un sistema di sicurezza ben funzionante, anche il lancio di nuove versioni in produzione avviene più spesso. In questa visione del mondo, una maggiore velocità significa maggiore sicurezza”, afferma Short.
“Non si tratta di fare la” cosa giusta “”, aggiunge Short, “si tratta di eliminare quante più cose possibili che ostacolano il raggiungimento del risultato desiderato. Collabora e adattati in base al feedback che ricevi in tempo reale. Preparati alle anomalie e lavora per migliorare la qualità per ridurre al minimo il loro impatto sui progressi verso il tuo obiettivo. Questo è ciò che ci aspetta nel mondo DevOps”.
Come scalare DevOps: 10 consigli dagli esperti
È solo che DevOps e DevOps di massa sono cose completamente diverse. Ti diremo come superare le barriere nel percorso dal primo al secondo.
Per molte organizzazioni, il viaggio verso DevOps inizia in modo semplice e piacevole. Si creano piccoli team appassionati, i vecchi processi vengono sostituiti con nuovi e i primi successi non tardano ad arrivare.
Purtroppo, questo è solo un falso sfarzo, un’illusione di progresso, afferma Ben Grinnell, amministratore delegato e responsabile del digitale presso la società di consulenza North Highland. I primi successi sono certamente incoraggianti, ma non aiutano a raggiungere l’obiettivo finale di un’adozione diffusa di DevOps all’interno dell’organizzazione.
È facile vedere che il risultato è una cultura di divisione tra “noi” e “loro”.
"Spesso le organizzazioni lanciano questi progetti pionieristici pensando che apriranno la strada al DevOps tradizionale, senza considerare se altri saranno in grado o disposti a seguire quella strada", spiega Ben Grinnell. – I team per l’implementazione di tali progetti vengono solitamente reclutati tra “Varangiani” sicuri di sé che hanno già fatto qualcosa di simile in altri luoghi, ma sono nuovi nella tua organizzazione. Allo stesso tempo, sono incoraggiati a infrangere e distruggere le regole che restano vincolanti per tutti gli altri. È facile vedere che il risultato è una cultura di “noi” e “loro” che inibisce il trasferimento di conoscenze e competenze”.
“E questo problema culturale è solo uno dei motivi per cui DevOps è difficile da scalare. I team DevOps si trovano ad affrontare crescenti sfide tecniche tipiche delle aziende IT-first in rapida crescita”, ha affermato Steve Newman, fondatore e presidente di Scalyr.
“Nel mondo moderno, i servizi cambiano non appena se ne presenta la necessità. È fantastico implementare e implementare costantemente nuove funzionalità, ma coordinare questo processo ed eliminare i problemi che si presentano è un vero grattacapo, aggiunge Steve Newman. – Nelle organizzazioni in rapida crescita, gli ingegneri dei team interfunzionali faticano a mantenere la visibilità del cambiamento e degli effetti a cascata che crea a livello di dipendenza. Inoltre, gli ingegneri non sono contenti quando vengono privati di questa opportunità e, di conseguenza, diventa per loro più difficile comprendere l’essenza dei problemi che si presentano”.
Come superare queste sfide sopra descritte e passare all'adozione di massa di DevOps in una grande organizzazione? Gli esperti sollecitano la pazienza, anche se il tuo obiettivo finale è accelerare il ciclo di sviluppo del software e i processi aziendali.
1. Ricorda che il cambiamento culturale richiede tempo.
Jayne Groll, Direttore esecutivo, DevOps Institute: “Secondo me, l’espansione di DevOps dovrebbe essere incrementale e iterativa quanto lo sviluppo agile (e toccando ugualmente la cultura). Agile e DevOps enfatizzano i piccoli team. Ma man mano che questi team crescono in numero e integrazione, ci ritroviamo con più persone che adottano nuovi modi di lavorare e, di conseguenza, si verifica una massiccia trasformazione culturale”.
2. Dedica abbastanza tempo alla pianificazione e alla scelta di una piattaforma
Eran Kinsbruner, Lead Technical Evangelist presso Perfecto: “Affinché la scalabilità funzioni, i team DevOps devono prima imparare a combinare processi, strumenti e competenze tradizionali, quindi coltivare e stabilizzare lentamente ogni singola fase di DevOps. Tutto inizia con un’attenta pianificazione delle storie degli utenti e dei flussi di valore, seguita dalla scrittura del software e dal controllo della versione utilizzando lo sviluppo basato su trunk o altri approcci più adatti per la ramificazione e l’unione del codice”.
“Poi arriva la fase di integrazione e test, in cui è già necessaria una piattaforma scalabile per l’automazione. È qui che è importante che i team DevOps scelgano la piattaforma giusta adatta al loro livello di competenze e agli obiettivi finali del progetto.
La fase successiva è la distribuzione in produzione e questa dovrebbe essere completamente automatizzata utilizzando strumenti e contenitori di orchestrazione. È importante disporre di ambienti virtualizzati in tutte le fasi di DevOps (simulatore di produzione, ambiente di QA e ambiente di produzione effettivo) e utilizzare sempre solo i dati più recenti per i test per ottenere conclusioni pertinenti. L’analisi deve essere intelligente e in grado di elaborare big data con feedback rapido e fruibile”.
3. Togliere la colpa dalla responsabilità.
Gordon Haff, evangelista di RedHat: “La creazione di un sistema e di un’atmosfera che consenta e incoraggi la sperimentazione consente quelli che sono noti come fallimenti di successo nello sviluppo agile del software. Ciò non significa che nessun altro sia responsabile dei fallimenti. Infatti, individuare i responsabili diventa ancora più semplice, poiché “essere responsabili” non significa più “provocare un incidente”. Cioè, l'essenza della responsabilità cambia qualitativamente. Quattro fattori diventano critici: l’entità della disruption, gli approcci, i processi di produzione e gli incentivi”. (Puoi leggere ulteriori informazioni su questi fattori nell'articolo di Gordon Huff "Lezioni DevOps: 4 aspetti di esperimenti salutari".)
4. Cancella il percorso da seguire
Ben Grinnell, amministratore delegato e responsabile del digitale presso la società di consulenza North Highland: “Per raggiungere dimensioni maggiori, consiglio di lanciare un programma di “sviluppo del percorso” insieme a progetti pionieristici. L’obiettivo di questo programma è ripulire la spazzatura che i pionieri di DevOps lasciano dietro di sé, come regole obsolete e cose del genere, in modo che il percorso da seguire rimanga chiaro”.
“Offrire alle persone supporto organizzativo e slancio attraverso una comunicazione che va ben oltre il gruppo pionieristico, celebrando ampiamente i successi di nuovi modi di lavorare. Formare le persone coinvolte nella prossima ondata di progetti DevOps e che sono nervose all'idea di utilizzare DevOps per la prima volta. E ricorda che queste persone sono molto diverse dai pionieri”.
5. Democratizzare gli strumenti
Steve Newman, fondatore e presidente di Scalyr: “Gli strumenti non dovrebbero essere nascosti alle persone e dovrebbero essere relativamente facili da apprendere per chiunque sia disposto a dedicarci del tempo. Se la capacità di interrogare i log è limitata a tre persone "certificate" per l'uso di uno strumento, avrai sempre un massimo di tre persone disponibili per gestire il problema, anche se disponi di un ambiente informatico molto grande. In altre parole, qui c’è un collo di bottiglia che può portare a gravi conseguenze (economiche)”.
6. Creare le condizioni ideali per il lavoro di squadra
Tom Clark, capo della piattaforma comune presso ITV: “Puoi fare qualsiasi cosa, ma non tutto in una volta. Quindi stabilisci grandi obiettivi, inizia in piccolo e vai avanti con rapide iterazioni. Col tempo, svilupperai la reputazione di saper portare a termine le cose, quindi anche altri vorranno usare i tuoi metodi. E non preoccuparti di costruire un team altamente efficace. Forniamo invece alle persone condizioni di lavoro ideali e l’efficienza ne conseguirà”.
7. Non dimenticare la Legge di Conway e le bacheche Kanban
Logan Daigle, Direttore della distribuzione del software e della strategia DevOps presso CollabNetVersionOne: “È importante comprendere le conseguenze della legge di Conway. Nella mia parafrasi approssimativa, questa legge afferma che i prodotti che creiamo e i processi che utilizziamo per farlo, incluso DevOps, risultano essere strutturati allo stesso modo della nostra organizzazione.
“Se in un’organizzazione sono presenti molti silos e il controllo cambia di mano molte volte durante la pianificazione, la creazione e il rilascio del software, l’effetto della scalabilità sarà pari a zero o di breve durata. Se un’organizzazione crea team interfunzionali attorno a prodotti finanziati con un focus sul mercato, le possibilità di successo aumentano notevolmente”.
“Un altro aspetto importante del ridimensionamento è visualizzare tutto il lavoro in corso (WIP, workinprogress) sui tabelloni Kanban. Quando un’organizzazione dispone di un luogo in cui le persone possono vedere queste cose, incoraggia notevolmente la collaborazione, che ha un impatto positivo sulla scalabilità”.
8. Cerca vecchie cicatrici
Manuel Pais, consulente DevOps e coautore di Team Topologies: “Portare le pratiche DevOps oltre Dev e Ops e provare ad applicarle ad altre funzioni non è certo un approccio ottimale. Ciò avrà sicuramente un certo impatto (ad esempio, automatizzando il controllo manuale), ma si può ottenere molto di più se iniziamo con la comprensione dei processi di consegna e feedback”.
"Se ci sono vecchie cicatrici nel sistema IT di un'organizzazione - procedure e meccanismi di gestione che sono stati implementati a seguito di incidenti passati, ma che hanno perso la loro rilevanza (a causa di cambiamenti nei prodotti, nelle tecnologie o nei processi) - allora devono certamente essere rimossi o appianati, invece di automatizzare processi inefficienti o non necessari”.
9. Non creare opzioni DevOps
Anthony Edwards, Direttore delle operazioni di Eggplant: “DevOps è un termine molto vago, quindi ogni team si ritrova con la propria versione di DevOps. E non c’è niente di peggio quando un’organizzazione dispone improvvisamente di 20 varietà di DevOps che non vanno molto d’accordo tra loro. È impossibile che ciascuno dei tre team di sviluppo abbia una propria interfaccia speciale tra sviluppo e gestione del prodotto. Né i prodotti dovrebbero avere aspettative specifiche sulla gestione del feedback quando vengono trasferiti a un simulatore di produzione. Altrimenti non sarai mai in grado di scalare DevOps”.
10. Diffondere il valore aziendale di DevOps
Steve Newman, fondatore e presidente di Scalyr: “Lavorare per riconoscere il valore di DevOps. Impara e sentiti libero di parlare dei vantaggi di ciò che fai. DevOps consente un incredibile risparmio di tempo e denaro (basti pensare: meno tempi di inattività, tempi medi di ripristino più brevi) e i team DevOps devono enfatizzare (e predicare) instancabilmente l'importanza di queste iniziative per il successo aziendale. In questo modo puoi espandere la cerchia degli aderenti e aumentare l’influenza di DevOps nell’organizzazione.”
BONUS
Su Il nostro DevOps arriverà il 13 settembre: sì, Red Hat, in quanto produttore di software, ha i propri team e pratiche DevOps.
Il nostro ingegnere Mark Birger, che sviluppa servizi di automazione interni per altri gruppi all'interno dell'organizzazione, racconterà la sua storia in puro russo: come il team Red Hat DevOps ha migrato le applicazioni dagli ambienti virtuali Hat Virtualization gestiti da Ansible a un formato contenitore completo su la piattaforma OpenShift.
Ma non è tutto:
Una volta che le organizzazioni hanno spostato i carichi di lavoro nei container, i metodi tradizionali di monitoraggio delle applicazioni potrebbero non funzionare. Nel secondo intervento spiegheremo la nostra motivazione per aver cambiato il modo in cui registriamo e mostreremo la continuazione del percorso che ci ha portato ai moderni metodi di registrazione e monitoraggio.
Fonte: habr.com