È difficile cogliere l'essenziale quando si parla di DevOps? Abbiamo raccolto per voi analogie vivide, formulazioni incisive e consigli da esperti che aiuteranno anche i non specialisti a raggiungere il nocciolo della questione. Alla fine, un bonus – il DevOps personale dei dipendenti di Red Hat.
Il termine DevOps è emerso 10 anni fa e ha percorso un cammino che va dall'hashtag su Twitter a un potente movimento culturale nel mondo IT, una vera e propria filosofia che incoraggia gli sviluppatori a ottenere risultati più rapidamente, a sperimentare e a progredire attraverso iterazioni. DevOps è diventato indissolubilmente legato al concetto di trasformazione digitale. Ma, come spesso accade con la terminologia IT, in dieci anni DevOps ha accumulato una moltitudine di definizioni, interpretazioni e malintesi su di sé.
Pertanto, riguardo a DevOps si possono spesso sentire domande come: è la stessa cosa di agile? O è una metodologia particolare? O è semplicemente un altro sinonimo della parola 'collaborazione'?
DevOps comprende molteplici concetti (continua consegna, continua integrazione, automazione, ecc.), quindi estrarre l'essenza può risultare complesso, specialmente se si ha una certa passione per l'argomento. Tuttavia, questa abilità è molto utile, che si stia cercando di comunicare le proprie idee ai dirigenti o semplicemente raccontando del proprio lavoro a familiari o amici. Pertanto, per ora mettiamo da parte le sottigliezze terminologiche di DevOps e concentriamoci sul quadro generale.
Cos'è DevOps: 6 definizioni e analogie
Abbiamo chiesto agli esperti di spiegare la sostanza di DevOps nel modo più semplice e conciso possibile, in modo che il suo valore risultasse chiaro ai lettori di qualsiasi livello di preparazione tecnica. A seguito di queste conversazioni, abbiamo selezionato le analogie più vivide e le formulazioni incisive che vi aiuteranno a costruire il vostro racconto su DevOps.
1. DevOps è un movimento culturale
«DevOps è un movimento culturale, all'interno del quale entrambe le parti (sviluppatori di software e professionisti delle operazioni IT) riconoscono che il software non porta vantaggi concreti fino a quando non comincia a essere utilizzato da qualcuno: clienti, utenti, dipendenti, non importa, sostiene Eveline Oehrlich, analista senior presso l'Istituto DevOps. – Pertanto, entrambe queste parti garantiscono insieme una rapida e qualitativa consegna del software».
2. DevOps è ciò che conferisce potere agli sviluppatori
«DevOps conferisce ai programmatori il potere di possedere le applicazioni, avviarle e gestire la consegna dalla partenza all'arrivo»
«Di solito si parla di DevOps come di un modo per accelerare la consegna delle applicazioni in produzione attraverso la costruzione e l'applicazione di processi automatizzati, – afferma Jai Schniepp, direttore delle piattaforme DevOps presso Liberty Mutual. – Ma per me è qualcosa di molto più fondamentale. DevOps conferisce ai programmatori il potere di possedere le applicazioni o parti specifiche del software, di avviarle e di gestire la consegna dalla partenza all'arrivo. DevOps elimina la confusione con le responsabilità e guida tutti i partecipanti del processo a creare un'infrastruttura automatizzata e gestita dai programmatori».
3. DevOps è collaborazione nella creazione e consegna delle applicazioni
«In parole semplici, DevOps è un approccio alla produzione e consegna del software in cui tutti lavorano insieme», – sottolinea Gur Staff, presidente e responsabile della divisione di automazione del business digitale di BMC.
4. DevOps è una catena di montaggio
«La costruzione in serie è possibile solo se tutte le parti si adattano tra loro».
«Paragonerei DevOps a una catena di montaggio di automobili, – continua Gur Staff. – L'idea è di progettare e costruire tutte le parti in anticipo in modo che possano essere assemblate senza adattamenti individuali. La costruzione in serie è possibile solo se tutte le parti si adattano tra loro. Coloro che progettano e costruiscono il motore devono considerare come fissarlo al telaio o al corpo dell'auto. Coloro che realizzano i freni devono pensare alle ruote, e così via. Allo stesso modo deve essere con il software.»
Un programmatore che crea logiche aziendali o interfacce utente deve considerare il database che memorizza le informazioni sui clienti, le misure di sicurezza per proteggere i dati degli utenti, nonché come tutto ciò funzionerà quando il servizio inizierà a servire un'ampia, forse anche multimilionaria, audience di utenti.»
«Fare in modo che le persone collaborino e pensino alle parti del lavoro che vengono svolte dagli altri, e non si concentrino esclusivamente sui propri compiti – questo è il più grande ostacolo da superare. Se ci riesci, hai ottime possibilità di una trasformazione digitale», aggiunge Gur Staff.
5. DevOps è la giusta combinazione di persone, processi e automazione
Jayne Groll, CEO dell'Institute DevOps, ha proposto un'ottima analogia per spiegare il DevOps. Secondo lei, «DevOps è come una ricetta culinaria, che ha tre categorie principali di ingredienti: persone, processi e automazione. La maggior parte di questi ingredienti può provenire da altre aree e fonti: Lean, Agile, SRE, CI/CD, ITIL, leadership, cultura, strumenti. Il segreto del DevOps, come quello di qualsiasi buona ricetta, sta nel scegliere correttamente le proporzioni e mescolare questi ingredienti per aumentare la velocità e l'efficacia del lavoro nell'ideazione e nel rilascio delle applicazioni».
6. DevOps è quando i programmatori lavorano come una squadra di Formula 1
«La gara è pianificata non dalla partenza all'arrivo, ma al contrario, dall'arrivo alla partenza».
«Parlando di cosa aspettarsi dall'iniziativa DevOps, porto come esempio una squadra di corse NASCAR o di Formula 1», afferma Chris Short, Chief Marketing Manager delle piattaforme cloud Red Hat e publisher della newsletter DevOps'ish. «Il leader di una tale squadra ha un obiettivo: ottenere il miglior piazzamento possibile alla fine della gara, tenendo conto delle risorse disponibili e delle sfide affrontate. Inoltre, la gara è pianificata non dalla partenza all'arrivo, ma al contrario, dall'arrivo alla partenza. Inizialmente si stabilisce un obiettivo ambizioso, poi si definiscono i modi per raggiungerlo, dopodiché vengono suddivisi in sottocompiti e delegati ai membri del team».
«Per tutta la settimana prima della gara, il team affina il pit stop. Si dedica ad allenamenti di forza e cardio per essere in forma in un giorno di gara estenuante. Lavora sulle azioni congiunte per risolvere eventuali problemi che possono sorgere durante la gara. Allo stesso modo, il team di sviluppatori deve allenare le proprie competenze per il rilascio frequente di nuove versioni. Con tali competenze e un sistema di sicurezza ben collaudato, anche il rilascio di nuove versioni in produzione avviene con maggiore frequenza. In questo contesto, la crescita della velocità implica una crescita della sicurezza», afferma Shorth.
«Non si tratta di fare le “cose giuste”, aggiunge Shorth, ma di rimuovere il maggior numero possibile di ostacoli che si frappongono tra noi e il risultato desiderato. Collaborate e adattatevi tenendo conto dei feedback che ricevete in tempo reale. Siate pronti ad affrontare anomalie e lavorate per migliorare la qualità, in modo da minimizzarne l'impatto sul raggiungimento degli obiettivi. Questo è ciò che ci attende nel mondo DevOps».
Come scalare DevOps: 10 consigli dagli esperti
DevOps semplice e DevOps su larga scala sono due cose assolutamente diverse. Vi spiegheremo come superare le barriere per passare dal primo al secondo.
Per molte organizzazioni, il cammino verso DevOps inizia in modo semplice e piacevole. Si creano piccoli team appassionati, i vecchi processi vengono sostituiti da nuovi e i primi successi non tardano ad arrivare.
Sfortunatamente, questo è solo un falso splendore, un'illusione di progresso, come afferma Ben Grinnell, direttore generale e responsabile del dipartimento delle tecnologie digitali della società di consulenza North Highland. Le prime vittorie possono certamente incoraggiare, ma non aiutano a raggiungere l'obiettivo finale, ovvero l'adozione su larga scala di DevOps nell'organizzazione.
È facile vedere come si formi una cultura della divisione tra «noi» e «loro».
«Spesso le organizzazioni avviano progetti pionieristici, pensando che questi apriranno la strada a un DevOps di massa, senza considerare se gli altri vorranno e possono seguire questo percorso», spiega Ben Grinnell. «I team assegnati a progetti di questo tipo sono di solito composti da "vichinghi" sicuri di sé, che hanno già fatto qualcosa di simile altrove, ma sono nuovi nella vostra organizzazione. Vengono incentivati a infrangere e distruggere le regole, che restano obbligatorie per tutti gli altri. È facile vedere come si formi una cultura di divisione tra “noi” e “loro”, che ostacola il trasferimento di conoscenze e competenze».
«E questo problema culturale è solo uno dei motivi per cui il DevOps è difficile da scalare. I team DevOps si trovano ad affrontare un aumento delle complessità tecniche, caratteristiche delle aziende in rapida crescita che puntano sulle tecnologie IT», afferma Steve Newman, fondatore e presidente del consiglio di Scalyr.
«Nel mondo moderno, i servizi cambiano non appena sorge la necessità. Implementare e introdurre continuamente nuove funzioni è sicuramente fantastico, ma coordinare questo processo e risolvere i problemi che sorgono è una vera e propria sfida», aggiunge Steve Newman. «Nelle organizzazioni in rapida crescita, gli ingegneri dei team cross-funzionali lottano per mantenere la capacità di monitorare le modifiche e gli effetti a cascata che ne derivano a livello di dipendenze. Inoltre, gli ingegneri non sono affatto felici quando vengono privati di questa capacità, il che rende più difficile comprendere la natura dei problemi che si presentano».
Come si possono superare le difficoltà sopra descritte e passare a un utilizzo di massa del DevOps in una grande organizzazione? Gli esperti esortano ad avere pazienza, anche se il vostro obiettivo finale è accelerare il ciclo di sviluppo del software e i processi aziendali.
1. Ricordate che i cambiamenti nella cultura richiedono tempo.
Jayne Groll, CEO dell'Institute for DevOps: «A mio avviso, l'espansione del DevOps dovrebbe essere altrettanto graduale e iterativa quanto lo sviluppo agile (e coinvolgere in ugual misura la cultura). In Agile e DevOps, ci si concentra su piccoli team. Ma man mano che il numero e l'integrazione di questi team cresce, abbiamo sempre più persone che adottano nuovi metodi di lavoro, il che porta a una significativa trasformazione culturale».
2. Dedica abbastanza tempo alla pianificazione e alla scelta della piattaforma
Eran Kinsbruner, evangelista tecnico di Perfecto: «Affinché la scalabilità funzioni, i team DevOps devono inizialmente imparare a combinare processi, strumenti e competenze tradizionali, e poi far crescere lentamente ogni singola fase del DevOps e stabilizzarla. Tutto inizia con una pianificazione accurata delle storie utente e dei flussi di creazione valore, seguita dalla fase di scrittura del software e di controllo delle versioni utilizzando lo sviluppo basato su trunk o altri approcci più adatti per ramificare e unire il codice».
«Dopo segue la fase di integrazione e testing, dove è necessaria una piattaforma scalabile per l'automazione. Qui i team DevOps devono scegliere la piattaforma giusta, che corrisponda al loro livello di competenza e agli obiettivi finali del progetto.
La fase successiva è il deployment nell'ambiente di produzione, e deve essere completamente automatizzato utilizzando strumenti di orchestrazione e contenitori. È importante avere ambienti virtualizzati in tutte le fasi del DevOps (simulatore dell'ambiente di produzione, ambiente di controllo qualità e, effettivamente, ambiente di produzione) e utilizzare sempre per i test solo i dati più recenti, in modo da ottenere conclusioni pertinenti. L'analitica deve essere intelligente e in grado di gestire grandi quantità di dati con feedback rapido ed efficace».
3. Liberate la responsabilità dal gusto di colpa
Gordon Haff, evangelista di RedHat: «La creazione di un sistema e di un'atmosfera che consenta e incoraggi esperimenti, consente di realizzare i cosiddetti fallimenti di successo nello sviluppo agile del software. Questo non significa che nessuno è più responsabile per i fallimenti. In realtà, identificare il responsabile diventa persino più semplice, poiché 'essere responsabile' non significa più 'essere il colpevole dell'incidente'. In altre parole, la natura della responsabilità cambia qualitativamente. In questo contesto, quattro fattori diventano estremamente importanti: l'entità del fallimento, gli approcci, i processi produttivi e gli stimoli». (Puoi leggere di più su questi fattori nell'articolo di Gordon Haff 'DevOps lessons: 4 aspects of healthy experiments').
4. Spiana la strada
Ben Grinnell, Managing Director e Head of Digital Technologies presso la società di consulenza North Highland: «Per ottenere scalabilità, consiglio di avviare insieme ai progetti pionieristici un programma di 'spianamento della strada'. L'obiettivo di questo programma è eliminare i rifiuti che rimangono dietro i pionieri del DevOps, come regole obsolete e simili, affinché la strada avanti rimanga libera».
«Dai alle persone supporto organizzativo e stimola la comunicazione che va ben oltre il gruppo pionieristico, celebrando ampiamente i successi delle nuove modalità di lavoro. Forma le persone coinvolte nella prossima ondata di progetti DevOps e ansiose di utilizzare il DevOps per la prima volta. E ricorda che queste persone sono molto diverse dai pionieri».
5. Rendi gli strumenti più democratici
Steve Newman, Fondatore e Presidente della società Scalyr: «Non bisogna nascondere gli strumenti alle persone, e devono essere relativamente facili da apprendere per chiunque sia disposto a dedicare del tempo a questo. Se la possibilità di richiedere i log è concessa solo a tre persone 'certificate' per utilizzare un certo strumento, avrai sempre al massimo tre persone in grado di risolvere il problema corrispondente, anche se hai un ambiente computazionale molto grande. In altre parole, si crea un collo di bottiglia, che può portare a conseguenze significative (per il business)».
6. Crea condizioni ideali per il lavoro di squadra
Tom Clark, Head of Common Platform presso la compagnia ITV: «Puoi fare qualsiasi cosa, ma non tutto subito. Quindi fissa obiettivi ambiziosi, inizia in piccolo e vai avanti con rapide iterazioni. Col tempo guadagnerai la reputazione di un team che ottiene risultati, quindi anche gli altri vorranno utilizzare i tuoi metodi. E non inseguire la costruzione di un team altamente efficiente. Invece, crea condizioni ideali per il lavoro e l'efficienza arriverà da sé».
7. Non dimenticare la legge di Conway e le bacheche Kanban
Logan Daigle, direttore per la consegna del software e la strategia DevOps di CollabNetVersionOne: «È importante essere consapevoli delle conseguenze della legge di Conway. In una mia libera interpretazione, questa legge afferma che i prodotti che creiamo e i processi che utilizziamo, compreso il DevOps, sono organizzati proprio come la nostra organizzazione».
«Se in un’organizzazione c’è alta disconnessione e nella pianificazione, creazione e rilascio del software il controllo passa spesso di mano, l’effetto della scalabilità sarà nullo o di breve durata. Se invece l’organizzazione forma team interfunzionali attorno a prodotti finanziati orientati al mercato, le possibilità di successo aumentano drasticamente».
«Un altro aspetto importante della scalabilità è quello di visualizzare su bacheche Kanban tutto il lavoro attualmente in corso (WIP, work in progress). Quando in un’organizzazione c’è un luogo dove le persone possono vedere queste cose, stimola notevolmente la collaborazione, il che beneficia la scalabilità».
8. Cerca vecchie cicatrici
Manuel Pais, consulente DevOps e coautore del libro «Team Topologies»: «Portare le pratiche DevOps oltre Dev e Ops e cercare di applicarle ad altre funzioni difficilmente può essere considerato un approccio ottimale. Questo darà sicuramente un certo effetto (ad esempio, grazie all'automazione della gestione manuale), ma si può ottenere molto di più se si inizia comprendendo i processi di consegna e feedback».
«Se ci sono vecchie cicatrici nel sistema IT dell'organizzazione – procedure e meccanismi di gestione che sono stati implementati a seguito di incidenti passati, ma che hanno perso rilevanza (a causa di cambiamenti nei prodotti, tecnologie o processi) – allora devono certamente essere rimossi o appianati, e non automatizzati processi inefficaci o non necessari».
9. Non create varianti di DevOps
Anthony Edwards, direttore della produzione della società Eggplant: «DevOps è un termine molto vago, quindi ogni team ha la propria versione di DevOps. E non c'è niente di peggio che avere 20 varianti di DevOps in un'organizzazione, che non convivono bene tra loro. Non può essere che ognuno dei tre team di sviluppo abbia la propria interfaccia specifica tra lo sviluppo e la gestione del prodotto. Così come non può essere che i prodotti abbiano le proprie aspettative uniche in merito alla gestione del feedback al momento del passaggio alla simulazione dell'ambiente di produzione. Altrimenti, non riuscirete mai a scalare DevOps.»
10. Predicate il valore di DevOps per il business
Steve Newman, Fondatore e Presidente della società Scalyr: «Lavorate per il riconoscimento del valore di DevOps. Imparate e non esitate a parlare dei benefici di ciò che fate. DevOps risparmia incredibilmente tempo e denaro (pensate: meno tempi di fermo, minore tempo medio di ripristino), e i team di DevOps devono incessantemente sottolineare (e predicare) l'importanza di queste iniziative per il successo del business. In questo modo, potrete ampliare la cerchia dei sostenitori e rafforzare l'influenza di DevOps nell'organizzazione».
BONUS
A Il 13 settembre arriverà il nostro DevOps personale – sì, Red Hat, in quanto produttore di software, ha propri team e pratiche DevOps.
Il nostro ingegnere Mark Birger, che sviluppa servizi di automazione interna per altri gruppi in tutta l'organizzazione, racconterà nella nostra lingua russa la sua storia – come il team DevOps di Red Hat ha migrato applicazioni da ambienti virtuali Hat Virtualization, gestiti da Ansible, a un formato containerizzato completo sulla piattaforma OpenShift.
Ma non è tutto:
Dopo che le organizzazioni hanno spostato i carichi di lavoro nei contenitori, i metodi tradizionali di monitoraggio delle applicazioni potrebbero non funzionare. Nel secondo rapporto spiegheremo la nostra motivazione per cambiare il modo di registrare e mostreremo il proseguimento del percorso che ci ha portato ai moderni metodi di registrazione e monitoraggio.
Fonte: habr.com
