<\/a><\/noindex>DevOps comprende molteplici concetti (continua consegna, continua integrazione, automazione, ecc.), quindi estrarre l'essenza pu\u00f2 risultare complesso, specialmente se si ha una certa passione per l'argomento. Tuttavia, questa abilit\u00e0 \u00e8 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.<\/p>\n
Cos'\u00e8 DevOps: 6 definizioni e analogie<\/h3>\n \nAbbiamo chiesto agli esperti di spiegare la sostanza di DevOps nel modo pi\u00f9 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\u00f9 vivide e le formulazioni incisive che vi aiuteranno a costruire il vostro racconto su DevOps.<\/p>\n
1. DevOps \u00e8 un movimento culturale<\/h4>\n \n\u00abDevOps \u00e8 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. \u2013 Pertanto, entrambe queste parti garantiscono insieme una rapida e qualitativa consegna del software\u00bb.<\/p>\n
2. DevOps \u00e8 ci\u00f2 che conferisce potere agli sviluppatori<\/h4>\n \n\u00abDevOps conferisce ai programmatori il potere di possedere le applicazioni, avviarle e gestire la consegna dalla partenza all'arrivo\u00bb<\/b><\/p>\n
\u00abDi 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, \u2013 afferma Jai Schniepp, direttore delle piattaforme DevOps presso Liberty Mutual. \u2013 Ma per me \u00e8 qualcosa di molto pi\u00f9 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\u00e0 e guida tutti i partecipanti del processo a creare un'infrastruttura automatizzata e gestita dai programmatori\u00bb.<\/p>\n
3. DevOps \u00e8 collaborazione nella creazione e consegna delle applicazioni<\/h4>\n \n\u00abIn parole semplici, DevOps \u00e8 un approccio alla produzione e consegna del software in cui tutti lavorano insieme\u00bb, \u2013 sottolinea Gur Staff, presidente e responsabile della divisione di automazione del business digitale di BMC.<\/p>\n
4. DevOps \u00e8 una catena di montaggio<\/h4>\n \n\u00abLa costruzione in serie \u00e8 possibile solo se tutte le parti si adattano tra loro\u00bb.<\/b><\/p>\n
\u00abParagonerei DevOps a una catena di montaggio di automobili, \u2013 continua Gur Staff. \u2013 L'idea \u00e8 di progettare e costruire tutte le parti in anticipo in modo che possano essere assemblate senza adattamenti individuali. La costruzione in serie \u00e8 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\u00ec via. Allo stesso modo deve essere con il software.\u00bb <\/p>\n
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\u00e9 come tutto ci\u00f2 funzioner\u00e0 quando il servizio inizier\u00e0 a servire un'ampia, forse anche multimilionaria, audience di utenti.\u00bb<\/p>\n
\u00abFare 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 \u2013 questo \u00e8 il pi\u00f9 grande ostacolo da superare. Se ci riesci, hai ottime possibilit\u00e0 di una trasformazione digitale\u00bb, aggiunge Gur Staff.<\/p>\n
5. DevOps \u00e8 la giusta combinazione di persone, processi e automazione<\/h4>\n \nJayne Groll, CEO dell'Institute DevOps, ha proposto un'ottima analogia per spiegare il DevOps. Secondo lei, \u00abDevOps \u00e8 come una ricetta culinaria, che ha tre categorie principali di ingredienti: persone, processi e automazione. La maggior parte di questi ingredienti pu\u00f2 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\u00e0 e l'efficacia del lavoro nell'ideazione e nel rilascio delle applicazioni\u00bb.<\/p>\n
6. DevOps \u00e8 quando i programmatori lavorano come una squadra di Formula 1<\/h4>\n \n\u00abLa gara \u00e8 pianificata non dalla partenza all'arrivo, ma al contrario, dall'arrivo alla partenza\u00bb.<\/b><\/p>\n
\u00abParlando di cosa aspettarsi dall'iniziativa DevOps, porto come esempio una squadra di corse NASCAR o di Formula 1\u00bb, afferma Chris Short, Chief Marketing Manager delle piattaforme cloud Red Hat e publisher della newsletter DevOps'ish. \u00abIl 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 \u00e8 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\u00e9 vengono suddivisi in sottocompiti e delegati ai membri del team\u00bb.<\/p>\n
\u00abPer 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\u00e0 implica una crescita della sicurezza\u00bb, afferma Shorth.<\/p>\n
\u00abNon si tratta di fare le \u201ccose giuste\u201d, 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\u00e0, in modo da minimizzarne l'impatto sul raggiungimento degli obiettivi. Questo \u00e8 ci\u00f2 che ci attende nel mondo DevOps\u00bb.<\/p>\n
Come scalare DevOps: 10 consigli dagli esperti<\/h3>\n \nDevOps semplice e DevOps su larga scala sono due cose assolutamente diverse. Vi spiegheremo come superare le barriere per passare dal primo al secondo.<\/b><\/p>\n
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.<\/p>\n
Sfortunatamente, questo \u00e8 solo un falso splendore, un'illusione di progresso, come afferma Ben Grinnell, direttore generale e responsabile del dipartimento delle tecnologie digitali della societ\u00e0 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.<\/p>\n
\u00c8 facile vedere come si formi una cultura della divisione tra \u00abnoi\u00bb e \u00abloro\u00bb.<\/b><\/p>\n
\u00abSpesso 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\u00bb, spiega Ben Grinnell. \u00abI team assegnati a progetti di questo tipo sono di solito composti da \"vichinghi\" sicuri di s\u00e9, che hanno gi\u00e0 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. \u00c8 facile vedere come si formi una cultura di divisione tra \u201cnoi\u201d e \u201cloro\u201d, che ostacola il trasferimento di conoscenze e competenze\u00bb.<\/p>\n
\u00abE questo problema culturale \u00e8 solo uno dei motivi per cui il DevOps \u00e8 difficile da scalare. I team DevOps si trovano ad affrontare un aumento delle complessit\u00e0 tecniche, caratteristiche delle aziende in rapida crescita che puntano sulle tecnologie IT\u00bb, afferma Steve Newman, fondatore e presidente del consiglio di Scalyr.<\/p>\n
\u00abNel mondo moderno, i servizi cambiano non appena sorge la necessit\u00e0. Implementare e introdurre continuamente nuove funzioni \u00e8 sicuramente fantastico, ma coordinare questo processo e risolvere i problemi che sorgono \u00e8 una vera e propria sfida\u00bb, aggiunge Steve Newman. \u00abNelle organizzazioni in rapida crescita, gli ingegneri dei team cross-funzionali lottano per mantenere la capacit\u00e0 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\u00e0, il che rende pi\u00f9 difficile comprendere la natura dei problemi che si presentano\u00bb.<\/p>\n
Come si possono superare le difficolt\u00e0 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 \u00e8 accelerare il ciclo di sviluppo del software e i processi aziendali.<\/b><\/p>\n1. Ricordate che i cambiamenti nella cultura richiedono tempo.<\/h4>\n
\nJayne Groll, CEO dell'Institute for DevOps:<\/b> \u00abA 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\u00f9 persone che adottano nuovi metodi di lavoro, il che porta a una significativa trasformazione culturale\u00bb.<\/p>\n2. Dedica abbastanza tempo alla pianificazione e alla scelta della piattaforma<\/h4>\n
\nEran Kinsbruner, evangelista tecnico di Perfecto:<\/b> \u00abAffinch\u00e9 la scalabilit\u00e0 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\u00f9 adatti per ramificare e unire il codice\u00bb.<\/p>\n
\u00abDopo segue la fase di integrazione e testing, dove \u00e8 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. <\/p>\n
La fase successiva \u00e8 il deployment nell'ambiente di produzione, e deve essere completamente automatizzato utilizzando strumenti di orchestrazione e contenitori. \u00c8 importante avere ambienti virtualizzati in tutte le fasi del DevOps (simulatore dell'ambiente di produzione, ambiente di controllo qualit\u00e0 e, effettivamente, ambiente di produzione) e utilizzare sempre per i test solo i dati pi\u00f9 recenti, in modo da ottenere conclusioni pertinenti. L'analitica deve essere intelligente e in grado di gestire grandi quantit\u00e0 di dati con feedback rapido ed efficace\u00bb.<\/p>\n
3. Liberate la responsabilit\u00e0 dal gusto di colpa<\/h4>\n \nGordon Haff, evangelista di RedHat:<\/b> \u00abLa 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 \u00e8 pi\u00f9 responsabile per i fallimenti. In realt\u00e0, identificare il responsabile diventa persino pi\u00f9 semplice, poich\u00e9 'essere responsabile' non significa pi\u00f9 'essere il colpevole dell'incidente'. In altre parole, la natura della responsabilit\u00e0 cambia qualitativamente. In questo contesto, quattro fattori diventano estremamente importanti: l'entit\u00e0 del fallimento, gli approcci, i processi produttivi e gli stimoli\u00bb. (Puoi leggere di pi\u00f9 su questi fattori nell'articolo di Gordon Haff 'DevOps lessons: 4 aspects of healthy experiments').<\/p>\n4. Spiana la strada<\/h4>\n
\nBen Grinnell, Managing Director e Head of Digital Technologies presso la societ\u00e0 di consulenza North Highland:<\/b> \u00abPer ottenere scalabilit\u00e0, consiglio di avviare insieme ai progetti pionieristici un programma di 'spianamento della strada'. L'obiettivo di questo programma \u00e8 eliminare i rifiuti che rimangono dietro i pionieri del DevOps, come regole obsolete e simili, affinch\u00e9 la strada avanti rimanga libera\u00bb.<\/p>\n
\u00abDai alle persone supporto organizzativo e stimola la comunicazione che va ben oltre il gruppo pionieristico, celebrando ampiamente i successi delle nuove modalit\u00e0 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\u00bb.<\/p>\n
5. Rendi gli strumenti pi\u00f9 democratici<\/h4>\n \nSteve Newman, Fondatore e Presidente della societ\u00e0 Scalyr:<\/b> \u00abNon 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\u00e0 di richiedere i log \u00e8 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\u00f2 portare a conseguenze significative (per il business)\u00bb.<\/p>\n6. Crea condizioni ideali per il lavoro di squadra<\/h4>\n
\nTom Clark, Head of Common Platform presso la compagnia ITV:<\/b> \u00abPuoi 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\u00e0 da s\u00e9\u00bb.<\/p>\n7. Non dimenticare la legge di Conway e le bacheche Kanban<\/h4>\n
\nLogan Daigle, direttore per la consegna del software e la strategia DevOps di CollabNetVersionOne:<\/b> \u00ab\u00c8 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\u00bb.<\/p>\n
\u00abSe in un\u2019organizzazione c\u2019\u00e8 alta disconnessione e nella pianificazione, creazione e rilascio del software il controllo passa spesso di mano, l\u2019effetto della scalabilit\u00e0 sar\u00e0 nullo o di breve durata. Se invece l\u2019organizzazione forma team interfunzionali attorno a prodotti finanziati orientati al mercato, le possibilit\u00e0 di successo aumentano drasticamente\u00bb.<\/p>\n
\u00abUn altro aspetto importante della scalabilit\u00e0 \u00e8 quello di visualizzare su bacheche Kanban tutto il lavoro attualmente in corso (WIP, work in progress). Quando in un\u2019organizzazione c\u2019\u00e8 un luogo dove le persone possono vedere queste cose, stimola notevolmente la collaborazione, il che beneficia la scalabilit\u00e0\u00bb.<\/p>\n
8. Cerca vecchie cicatrici<\/h4>\n \nManuel Pais, consulente DevOps e coautore del libro \u00abTeam Topologies\u00bb:<\/b> \u00abPortare le pratiche DevOps oltre Dev e Ops e cercare di applicarle ad altre funzioni difficilmente pu\u00f2 essere considerato un approccio ottimale. Questo dar\u00e0 sicuramente un certo effetto (ad esempio, grazie all'automazione della gestione manuale), ma si pu\u00f2 ottenere molto di pi\u00f9 se si inizia comprendendo i processi di consegna e feedback\u00bb.<\/p>\n
\u00abSe ci sono vecchie cicatrici nel sistema IT dell'organizzazione \u2013 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) \u2013 allora devono certamente essere rimossi o appianati, e non automatizzati processi inefficaci o non necessari\u00bb.<\/p>\n
9. Non create varianti di DevOps<\/h4>\n \nAnthony Edwards, direttore della produzione della societ\u00e0 Eggplant:<\/b> \u00abDevOps \u00e8 un termine molto vago, quindi ogni team ha la propria versione di DevOps. E non c'\u00e8 niente di peggio che avere 20 varianti di DevOps in un'organizzazione, che non convivono bene tra loro. Non pu\u00f2 essere che ognuno dei tre team di sviluppo abbia la propria interfaccia specifica tra lo sviluppo e la gestione del prodotto. Cos\u00ec come non pu\u00f2 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.\u00bb<\/p>\n10. Predicate il valore di DevOps per il business<\/h4>\n
\nSteve Newman, Fondatore e Presidente della societ\u00e0 Scalyr:<\/b> \u00abLavorate per il riconoscimento del valore di DevOps. Imparate e non esitate a parlare dei benefici di ci\u00f2 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\u00bb.<\/p>\nBONUS<\/h3>\n
\nA Red Hat Forum Russia<\/a><\/noindex> Il 13 settembre arriver\u00e0 il nostro DevOps personale \u2013 s\u00ec, Red Hat, in quanto produttore di software, ha propri team e pratiche DevOps.<\/b><\/p>\nIl nostro ingegnere Mark Birger, che sviluppa servizi di automazione interna per altri gruppi in tutta l'organizzazione, racconter\u00e0 nella nostra lingua russa la sua storia \u2013 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.<\/p>\n
Ma non \u00e8 tutto:<\/b><\/p>\n
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.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-news"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Parliamo](\"\/wp-content\/uploads\/2019\/08\/c3df26c470065767bc37e7d1c732d0b5.jpeg\")