<\/a><\/noindex>DevOps comprende molteplici concetti (consegna continua, integrazione continua, automazione, ecc.), quindi isolare l'essenza pu\u00f2 non essere semplice, soprattutto se sei appassionato dell'argomento. Tuttavia, questa abilit\u00e0 \u00e8 molto utile, sia che tu stia cercando di comunicare le tue idee ai superiori, sia che tu stia spiegando il tuo lavoro a familiari o amici. Quindi, per ora lasciamo da parte le sfumature terminologiche di DevOps e concentriamoci sul quadro generale.<\/p>\n
Cos'\u00e8 DevOps: 6 definizioni e analogie<\/h3>\n \nAbbiamo chiesto a esperti di spiegare l'essenza di DevOps in modo semplice e conciso, affinch\u00e9 il suo valore fosse comprensibile a lettori di qualsiasi livello tecnico. Al termine di questi colloqui, abbiamo selezionato le analogie pi\u00f9 illuminate e le frasi contundenti che ti aiuteranno a costruire il tuo discorso su DevOps.<\/p>\n
1. DevOps \u00e8 un movimento culturale<\/h4>\n \n\u00abDevOps \u00e8 un movimento culturale in cui entrambe le parti (sviluppatori software e specialisti IT) riconoscono che il software non porta valore reale finch\u00e9 non viene utilizzato da qualcuno: clienti, utenti, dipendenti, non importa, - afferma Eveline Oehrlich, analista senior presso l'Istituto DevOps. - Pertanto, entrambe le parti lavorano insieme per garantire una rapida e qualitativa consegna del software\u00bb.<\/p>\n
2. DevOps \u00e8 ci\u00f2 che conferisce potere agli sviluppatori<\/h4>\n \n\u00abDevOps consente agli sviluppatori di avere il controllo sulle applicazioni, gestendo la loro distribuzione dall'inizio alla fine\u00bb.<\/b><\/p>\n
\u00abDi solito si parla di DevOps come di un modo per accelerare la consegna delle applicazioni in produzione attraverso la creazione e l'implementazione di processi automatizzati\u00bb, afferma Jai Schniepp, direttore delle piattaforme DevOps della compagnia assicurativa Liberty Mutual. - \u00abMa per me \u00e8 qualcosa di molto pi\u00f9 fondamentale. DevOps consente agli sviluppatori di detenere il controllo sulle applicazioni o su determinate parti del software, gestendo la loro distribuzione dall'inizio alla fine. DevOps elimina la confusione sulla responsabilit\u00e0 e guida tutti i partecipanti del processo verso la creazione di un'infrastruttura automatizzata e gestita dagli sviluppatori\u00bb.<\/p>\n
3. DevOps \u00e8 collaborazione nella creazione e nella consegna delle applicazioni<\/h4>\n \n\u00abIn parole povere, DevOps \u00e8 un approccio alla produzione e consegna del software in cui tutti lavorano insieme\u00bb, osserva Gur Staff, presidente e responsabile del settore automazione del business digitale della societ\u00e0 BMC.<\/p>\n
4. DevOps \u00e8 una catena produttiva<\/h4>\n \n\u00abUn'assemblaggio in catena \u00e8 possibile solo se tutte le parti si adattano perfettamente tra loro\u00bb.<\/b><\/p>\n
\u00abParagonerei DevOps a una catena di montaggio di automobili\u00bb, continua Gur Staff. \u00abL'idea \u00e8 che tutte le parti devono essere progettate e realizzate in modo che possano essere assemblate senza requisiti di adattamento individuale. Un'assemblaggio in catena \u00e8 possibile solo se tutte le parti si adattano perfettamente. Coloro che progettano e costruiscono il motore devono pensare a come fissarlo al telaio. Chi realizza i freni deve considerare le ruote, e cos\u00ec via. Allo stesso modo deve essere anche con il software. <\/p>\n
Uno sviluppatore che crea la logica aziendale o l'interfaccia utente deve considerare il database che memorizza le informazioni dei clienti, i sistemi di sicurezza per proteggere i dati degli utenti, e come tutto questo funzioner\u00e0 quando il servizio inizier\u00e0 a servire un'ampia, forse anche multimilionaria, base di utenti\u00bb.<\/p>\n
\u00abFar s\u00ec che le persone collaborino e pensino alle parti del lavoro svolto da altri, piuttosto che concentrarsi esclusivamente sulle proprie attivit\u00e0, \u00e8 il pi\u00f9 grande ostacolo da superare. Se ci riesci, hai ottime possibilit\u00e0 di realizzare una trasformazione digitale\u00bb, conclude Gur Staff.<\/p>\n
5. DevOps \u00e8 la giusta combinazione di persone, processi e automazione<\/h4>\n \nJane Grohl, CEO dell'Institute for DevOps, ha proposto un'ottima analogia per spiegare il DevOps. Secondo lei, \"DevOps \u00e8 come una ricetta culinaria che ha tre categorie principali di ingredienti: persone, processi e automazione. La maggior parte di questi ingredienti pu\u00f2 essere presa da altri campi e fonti: Lean, Agile, SRE, CI\/CD, ITIL, leadership, cultura, strumenti. Il segreto del DevOps, come per qualsiasi buona ricetta, \u00e8 come bilanciare e mescolare correttamente questi ingredienti per aumentare la velocit\u00e0 e l'efficacia nella creazione e distribuzione delle applicazioni.\"<\/p>\n
6. DevOps \u00e8 quando i programmatori lavorano come una squadra di Formula 1<\/h4>\n \n\"La gara non \u00e8 pianificata dal via al traguardo, ma piuttosto dal traguardo all'inizio.\"<\/b><\/p>\n
\"Parlando di cosa aspettarsi dalla iniziativa DevOps, faccio l'esempio di un team di corsa NASCAR o Formula 1\", afferma Chris Short, Chief Marketing Officer delle piattaforme cloud di Red Hat e publisher della newsletter DevOps\u2019ish. \"Il leader di un tale team ha un solo obiettivo: ottenere il miglior risultato possibile in base alle risorse della squadra e alle sfide affrontate. La gara \u00e8 pianificata non dal via al traguardo, ma viceversa, partendo dal traguardo. Prima si stabilisce un obiettivo ambizioso, poi si determinano i percorsi per raggiungerlo. Successivamente, questi vengono suddivisi in compiti e delegati ai membri del team.\"<\/p>\n
\"Per tutta la settimana prima della corsa, il team affina il pit stop. Si dedica ad allenamenti di forza e cardio per essere in forma durante il giorno faticoso della corsa. Lavora insieme per risolvere eventuali problemi che potrebbero sorgere durante la gara. Allo stesso modo, il team di sviluppo deve allenare le competenze per il rilascio frequente di nuove versioni. Con tali competenze e un sistema di sicurezza ben collaudato, il lancio di nuove versioni in produzione avviene anche pi\u00f9 frequentemente. Nell'ambito di questa mentalit\u00e0, la crescita della velocit\u00e0 significa crescita della sicurezza\", afferma Short.<\/p>\n
\"Non si tratta di fare le 'cose giuste', aggiunge Short, ma di eliminare il maggior numero possibile di ostacoli tra voi e il risultato desiderato. Collaborate e adattatevi in base al feedback che ricevete in tempo reale. Siate pronti per le anomalie e lavorate per migliorare la qualit\u00e0 per ridurre al minimo il loro impatto nel raggiungere il vostro obiettivo. Questo \u00e8 ci\u00f2 che ci aspetta nel mondo del DevOps.\"<\/p>\n
Come scalare il DevOps: 10 consigli dagli esperti<\/h3>\n \nSimple DevOps e mass DevOps sono due cose completamente diverse. Vi mostreremo come superare le barriere per passare dal primo al secondo.<\/b><\/p>\n
Per molte organizzazioni, il cammino verso il DevOps inizia in modo facile e piacevole. Nascono piccoli team appassionati, i vecchi processi vengono sostituiti da nuovi e i primi successi non tardano ad arrivare.<\/p>\n
Purtroppo, questo \u00e8 solo un falso splendore, un'illusione di progresso, come dice Ben Grinnell, Managing Director e Head of Digital Transformation della societ\u00e0 di consulenza North Highland. Le prime vittorie possono certamente essere incoraggianti, ma non aiutano a raggiungere l'obiettivo finale, ovvero l'adozione su vasta scala del DevOps nell'organizzazione.<\/p>\n
\u00c8 facile vedere che si forma una cultura di divisione tra 'noi' e 'loro'.<\/b><\/p>\n
\"Spesso le organizzazioni avviano progetti pionieristici credendo che apriranno la strada al DevOps su vasta scala, senza riflettere se gli altri vorranno e saranno in grado di intraprendere questo percorso\", spiega Ben Grinnell. \"I team per realizzare tali progetti sono solitamente composti da 'estranei' fiduciosi che hanno gi\u00e0 fatto qualcosa di simile in altri posti, ma sono nuovi nella vostra organizzazione. Allo stesso tempo, sono incoraggiati a infrangere e demolire le regole che rimangono vincolanti per tutti gli altri. \u00c8 facile vedere che si forma una cultura di divisione tra 'noi' e 'loro', che ostacola il trasferimento di conoscenze e competenze.\"<\/p>\n
\"E questo problema culturale \u00e8 solo una delle ragioni per cui il DevOps \u00e8 difficile da scalare. I team DevOps affrontano un aumento delle complessit\u00e0 puramente tecniche, caratteristiche delle aziende in rapida evoluzione che hanno scommesso sulle tecnologie IT\", afferma Steve Newman, fondatore e presidente della societ\u00e0 Scalyr.<\/p>\n
Nel mondo moderno, i servizi cambiano rapidamente non appena sorge la necessit\u00e0. Implementare e lanciare nuove funzionalit\u00e0 \u00e8 certamente positivo, ma coordinare questo processo e risolvere i problemi che sorgono \u00e8 una vera sfida. Steve Newman sottolinea che nelle organizzazioni in rapida crescita, gli ingegneri delle squadre cross-funzionali lottano per mantenere la possibilit\u00e0 di monitorare i cambiamenti e gli effetti a cascata a livello di dipendenze. Inoltre, gli ingegneri non sono affatto contenti quando vengono privati di questa possibilit\u00e0, rendendo loro pi\u00f9 difficile comprendere la natura dei problemi emergenti.<\/p>\n
Come si possono superare le difficolt\u00e0 sopra descritte e passare a un'adozione su vasta scala di DevOps in una grande organizzazione? Gli esperti invitano a essere pazienti, anche se l'obiettivo finale \u00e8 accelerare il ciclo di sviluppo del software e i processi aziendali.<\/b><\/p>\n1. Ricordate che i cambiamenti culturali richiedono tempo<\/h4>\n
\nJayne Groll, CEO del DevOps Institute:<\/b> \u00abA mio avviso, l'espansione di DevOps dovrebbe avvenire in modo graduale e iterativo, proprio come lo sviluppo agile, e dovrebbe riguardare in egual misura la cultura. In Agile e DevOps, c'\u00e8 un focus su piccole squadre. Ma man mano che il numero di queste squadre cresce e si integrano, vediamo sempre pi\u00f9 persone che adottano nuovi metodi di lavoro, e di conseguenza, si verifica una trasformazione culturale su larga scala\u00bb.<\/p>\n2. Dedicate abbastanza tempo alla pianificazione e alla scelta della piattaforma<\/h4>\n
\nEran Kinsbruner, Chief Evangelist di Perfecto:<\/b> \u00abPer far funzionare la scalabilit\u00e0, le squadre DevOps devono imparare inizialmente a integrare processi, strumenti e competenze tradizionali, e poi sviluppare lentamente ogni fase di DevOps e stabilizzarla. Tutto inizia con una pianificazione attenta delle storie utente e dei flussi di creazione valore, seguita dallo sviluppo software e dal controllo delle versioni usando sviluppo trunk-based o altri approcci pi\u00f9 adatti al branching e al merging del codice\u00bb.<\/p>\n
\u00abSubito dopo viene la fase di integrazione e testing, dove \u00e8 necessaria una piattaforma scalabile per l'automazione. \u00c8 qui che le squadre DevOps devono scegliere la piattaforma giusta, che sia adeguata alle loro competenze e agli obiettivi finali del progetto. <\/p>\n
La fase successiva \u00e8 il deployment nell'ambiente di produzione, completamente automatizzato tramite strumenti di orchestrazione e container. \u00c8 importante avere ambienti virtualizzati in tutte le fasi di DevOps (simulatore dell'ambiente di produzione, ambiente di controllo qualit\u00e0 e, ovviamente, l'ambiente di produzione) e utilizzare sempre i dati pi\u00f9 recenti per i test, in modo da ottenere riscontri pertinenti. L'analitica deve essere intelligente e capace di gestire big data con feedback rapidi e incisivi\u00bb.<\/p>\n
3. Liberate la responsabilit\u00e0 dal senso di colpa<\/h4>\n \nGordon Haff, evangelista di RedHat:<\/b> \u00abCreare un sistema e un'atmosfera che permettano e incoraggino esperimenti consente di realizzare quelli che noi chiamiamo insuccessi costruttivi nello sviluppo agile del software. Ci\u00f2 non significa che nessuno sia pi\u00f9 responsabile degli errori. In realt\u00e0, \u00e8 diventato anche pi\u00f9 semplice individuare il responsabile, poich\u00e9 'essere responsabili' non significa pi\u00f9 'essere il colpevole del fallimento'. La natura della responsabilit\u00e0 cambia qualitativamente in questo senso. Quattro fattori diventano estremamente importanti: la dimensione del fallimento, gli approcci, i processi produttivi e gli incentivi\u00bb. (Per ulteriori dettagli su questi fattori, potete leggere l'articolo di Gordon Haff 'Lezioni di DevOps: 4 aspetti di esperimenti sani').<\/p>\n4. Spianate la strada<\/h4>\n
\nBen Grinnell, managing director e leader della digital transformation di North Highland:<\/b> \u00abPer raggiungere la scalabilit\u00e0, consiglio di avviare un programma di 'spianamento della strada' insieme ai progetti pionieristici. L'obiettivo di questo programma \u00e8 rimuovere i detriti lasciati dai pionieri di DevOps, come le regole obsolete e affini, in modo che la strada da percorrere resti libera\u00bb.<\/p>\n
\u00abFornite supporto organizzativo e generate impulso attraverso comunicazioni che vadano ben oltre il gruppo di pionieri, celebrando ampiamente i successi dei nuovi metodi di lavoro. Formate le persone coinvolte nella prossima ondata di progetti DevOps, che si sentono ansiose perch\u00e9 stanno usando DevOps per la prima volta. E ricordate, queste persone sono molto diverse dai pionieri\u00bb.<\/p>\n
5. Rendete gli strumenti pi\u00f9 democratici<\/h4>\n \nSteve Newman, fondatore e presidente di Scalyr:<\/b> \"Non bisogna nascondere gli strumenti alle persone; devono essere relativamente facili da imparare per chiunque sia disposto a dedicare tempo. Se la possibilit\u00e0 di richiedere i log \u00e8 riservata solo a tre persone 'certificate' per utilizzare uno strumento, avrete sempre al massimo tre persone in grado di affrontare il problema corrispondente, anche in una grande infrastruttura informatica. In altre parole, questo crea un collo di bottiglia che pu\u00f2 avere gravi conseguenze (per il business).\"<\/p>\n6. Create le condizioni ideali per il lavoro del team<\/h4>\n
\nTom Clark, responsabile della piattaforma comune presso ITV:<\/b> \"Potete fare qualsiasi cosa, ma non tutto insieme. Pertanto, ponete obiettivi ambiziosi, cominciate in piccolo e avanzate con iterazioni rapide. Col tempo, guadagnerete una reputazione come team capace, cos\u00ec che anche altri vorranno adottare i vostri metodi. Non cercate di costruire un team ad alta performance; piuttosto, create condizioni ideali per il lavoro delle persone, e l'efficacia arriver\u00e0 di conseguenza.\"<\/p>\n7. Non dimenticate la legge di Conway e le lavagne Kanban<\/h4>\n
\nLogan Daigle, direttore delle operations software e della strategia DevOps di CollabNetVersionOne:<\/b> \"\u00c8 importante essere consapevoli delle implicazioni della legge di Conway. In sintesi, questa legge afferma che i prodotti che creiamo e i processi che utilizziamo, compreso DevOps, sono organizzati in modo simile alla nostra organizzazione.\"<\/p>\n
\"Se c'\u00e8 una scarsa integrazione all'interno dell'organizzazione e la gestione passa da una mano all'altra durante la pianificazione, creazione e distribuzione del software, l'effetto della scalabilit\u00e0 sar\u00e0 nullo o effimero. Se invece l'organizzazione forma team cross-funzionali attorno a prodotti finanziati orientati al mercato, le probabilit\u00e0 di successo aumentano drasticamente.\"<\/p>\n
\"Un altro aspetto importante della scalabilit\u00e0 \u00e8 visualizzare su lavagne Kanban tutto il lavoro in corso (WIP, work in progress). Quando in un'organizzazione esiste uno spazio dove le persone possono vedere queste informazioni, stimola fortemente la collaborazione, il che ha un impatto positivo sulla scalabilit\u00e0.\"<\/p>\n
8. Cercate le cicatrici del passato<\/h4>\n \nManuel Pais, consulente DevOps e coautore del libro 'Team Topologies':<\/b> \"Portare le pratiche DevOps al di fuori di Dev e Ops e tentare di applicarle ad altre funzioni non \u00e8 un approccio ottimale. Questo dar\u00e0 un certo effetto (ad esempio, attraverso l'automazione della gestione manuale), ma si possono ottenere risultati molto maggiori partendo dalla comprensione dei processi di delivery e feedback.\"<\/p>\n
\"Se ci sono cicatrici nel sistema IT dell'organizzazione \u2013 procedure e meccanismi di controllo implementati a seguito di eventi passati che hanno perso rilevanza (a causa di cambiamenti in prodotti, tecnologie o processi) \u2013 \u00e8 fondamentale rimuoverle o correggerle, piuttosto che automatizzare processi inefficaci o non necessari.\"<\/p>\n
9. Non create varianti di DevOps<\/h4>\n \nAntony Edwards, direttore della produzione di Eggplant:<\/b> \"DevOps \u00e8 un termine molto vago, quindi ogni team finisce per avere la sua versione di DevOps. E non c'\u00e8 nulla di peggio che avere 20 varianti di DevOps in un'organizzazione, che non si integrano bene tra loro. Non si pu\u00f2 permettere che ogni team di sviluppo abbia la propria interfaccia unica tra sviluppo e gestione del prodotto. Analogamente, i prodotti non devono avere aspettative uniche riguardo al feedback durante il trasferimento nel simulatore dell'ambiente di produzione. In caso contrario, non riuscirete mai a scalare DevOps.\"<\/p>\n10. Predicate il valore di DevOps per il business<\/h4>\n
\nSteve Newman, fondatore e presidente di Scalyr:<\/b> \"Lavorate per far riconoscere il valore di DevOps. Imparate a comunicare senza timore i benefici delle vostre attivit\u00e0. DevOps fa risparmiare tempo e denaro (basti pensare: meno downtime, tempi di ripristino pi\u00f9 brevi), e i team DevOps dovrebbero costantemente sottolineare (e predicare) l'importanza di queste iniziative per il successo del business. In questo modo, potrete ampliare il numero di sostenitori e accrescere l'influenza di DevOps nell'organizzazione.\"<\/p>\nBONUS<\/h3>\n
\nSu Red Hat Forum Russia<\/a><\/noindex> Il nostro DevOps arriver\u00e0 il 13 settembre \u2013 s\u00ec, Red Hat, come produttore di software, ha i suoi team e pratiche DevOps.<\/b><\/p>\nIl nostro ingegnere Mark Birger, che si occupa dello sviluppo di servizi di automazione interna per altri gruppi all'interno dell'organizzazione, racconter\u00e0 in chiaro la sua storia \u2013 come il team DevOps di Red Hat ha migrato applicazioni da ambienti virtuali gestiti da Ansible a un formato container completo sulla piattaforma OpenShift.<\/p>\n
Ma non \u00e8 tutto:<\/b><\/p>\n
Dopo che le organizzazioni hanno spostato i carichi di lavoro nei container, i metodi tradizionali di monitoraggio delle applicazioni potrebbero non funzionare pi\u00f9. Nella seconda relazione, spiegheremo la nostra motivazione a cambiare il modo di registrare e mostreremo il percorso che ci ha portato a metodi moderni di registrazione e monitoraggio.habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0422\u0440\u0443\u0434\u043d\u043e \u0443\u043b\u043e\u0432\u0438\u0442\u044c \u0433\u043b\u0430\u0432\u043d\u043e\u0435, \u0433\u043e\u0432\u043e\u0440\u044f \u043e DevOps? \u041c\u044b \u0441\u043e\u0431\u0440\u0430\u043b\u0438 \u0434\u043b\u044f \u0432\u0430\u0441 \u044f\u0440\u043a\u0438\u0435 \u0430\u043d\u0430\u043b\u043e\u0433\u0438\u0438, \u0443\u0434\u0430\u0440\u043d\u044b\u0435 \u0444\u043e\u0440\u043c\u0443\u043b\u0438\u0440\u043e\u0432\u043a\u0438 \u0438 \u0441\u043e\u0432\u0435\u0442\u044b \u043e\u0442 \u044d\u043a\u0441\u043f\u0435\u0440\u0442\u043e\u0432, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043f\u043e\u043c\u043e\u0433\u0443\u0442 \u0434\u043e\u0439\u0442\u0438 \u0434\u043e \u0441\u0443\u0442\u0438 \u0434\u0430\u0436\u0435 \u043d\u0435\u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0441\u0442\u0430\u043c. \u0412 \u043a\u043e\u043d\u0446\u0435 \u0431\u043e\u043d\u0443\u0441 \u2013 \u0441\u043e\u0431\u0441\u0442\u0432\u0435\u043d\u043d\u044b\u0439 DevOps \u0441\u043e\u0442\u0440\u0443\u0434\u043d\u0438\u043a\u043e\u0432 Red Hat. \u0422\u0435\u0440\u043c\u0438\u043d DevOps \u0432\u043e\u0437\u043d\u0438\u043a 10 \u043b\u0435\u0442 \u043d\u0430\u0437\u0430\u0434 \u0438 \u043f\u0440\u043e\u0448\u0435\u043b \u043f\u0443\u0442\u044c \u043e\u0442 \u0445\u044d\u0448\u0442\u0435\u0433\u0430 \u0432 \u0422\u0432\u0438\u0442\u0442\u0435\u0440\u0435 \u0434\u043e \u043c\u043e\u0449\u043d\u043e\u0433\u043e \u043a\u0443\u043b\u044c\u0442\u0443\u0440\u043d\u043e\u0433\u043e \u0434\u0432\u0438\u0436\u0435\u043d\u0438\u044f \u0432 \u043c\u0438\u0440\u0435 \u0418\u0422, \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0435\u0439 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28183,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[702],"tags":[],"class_list":["post-37551","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-novosti-interneta"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Parliamo](\"\/wp-content\/uploads\/2019\/08\/c3df26c470065767bc37e7d1c732d0b5.jpeg\")