{"id":39219,"date":"2019-10-31T22:28:31","date_gmt":"2019-10-31T19:28:31","guid":{"rendered":"https:\/\/prohoster.info\/blog\/devops-i-haos-dostavka-po-v-detsentralizovannom-mire\/"},"modified":"2019-10-31T22:28:31","modified_gmt":"2019-10-31T19:28:31","slug":"devops-i-haos-dostavka-po-v-detsentralizovannom-mire","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/devops-i-haos-dostavka-po-v-detsentralizovannom-mire","title":{"rendered":"DevOps e Chaos: distribuzione software in un mondo decentralizzato","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Il fondatore e direttore di \u00abOtomato Software\u00bb, uno dei promotori e istruttori della prima certificazione DevOps in Israele, Anton Weiss, ha parlato lo scorso anno DevOpsDays Moscow<\/a><\/noindex> della teoria del caos e dei principi fondamentali dell'ingegneria del caos, e ha anche spiegato come sar\u00e0 organizzata l'ideale organizzazione DevOps del futuro.<\/p>\n

Abbiamo preparato una versione testuale della presentazione. <\/p>\n

\r\n \"Guarda\r\n
<\/div>\r\n <\/div><\/center>
\n<\/a><\/noindex>
\nBuongiorno! <\/p>\n

DevOpsDays a Mosca per il secondo anno consecutivo, io sono qui per la seconda volta su questo palco, molti di voi sono qui per la seconda volta in questa sala. E cosa significa questo? Significa che il movimento DevOps in Russia sta crescendo, moltiplicandosi, e soprattutto, significa che \u00e8 ora di parlare di cosa rappresenta DevOps nel 2018. <\/p>\n

Alzate la mano quelli che pensano che nel 2018 DevOps sia gi\u00e0 una professione? Ci sono? Ci sono ingegneri DevOps in sala, il cui lavoro \u00e8 descritto come \u00abingegnere DevOps\u00bb? Ci sono manager DevOps in sala? Non ce ne sono. Architetti DevOps? Neanche. Appena pochi. Davvero nessuno ha la qualifica di ingegnere DevOps?<\/p>\n

Quindi, la maggior parte di voi pensa che sia un antipattern? Che non debba esistere tale professione? Possiamo pensare quello che vogliamo, ma mentre noi pensiamo, l'industria avanza solennemente al suono della tromba DevOps.<\/p>\n

Chi ha sentito parlare del nuovo tema chiamato DevDevOps? \u00c8 un nuovo metodo che consente di garantire una collaborazione efficace tra sviluppatori e DevOps. E non \u00e8 poi cos\u00ec nuovo. Giudicando dai tweet, gi\u00e0 quattro anni fa si parlava di questo. E ancora adesso, l'interesse continua a crescere, quindi il problema esiste. Il problema va risolto.<\/p>\n

\"DevOps
\n
\nSiamo persone creative, non ci accontentiamo facilmente. Diciamo: DevOps \u00e8 una parola troppo restrittiva, manca di vari elementi interessanti. E ci ritiriamo nei nostri laboratori segreti e iniziamo a creare curiose mutazioni: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.<\/p>\n

\"DevOps
\n
\nLa logica \u00e8 ferrea, vero? Abbiamo un sistema di distribuzione non funzionante, i nostri sistemi sono instabili e gli utenti insoddisfatti, non riusciamo a rilasciare il software in tempo, sforiamo il budget. Come risolveremo tutto questo? Inventeremo una nuova parola! Essa finir\u00e0 con \u00abOps\u00bb, e il problema sar\u00e0 risolto.<\/p>\n

Cos\u00ec chiamo questo approccio: \u00abOps, e il problema \u00e8 risolto\u00bb.<\/p>\n

Tutto questo passa in secondo piano se ci ricordiamo perch\u00e9 abbiamo progettato tutto ci\u00f2. Abbiamo creato tutto questo DevOps per rendere la consegna del software e il nostro lavoro in questo processo il pi\u00f9 fluido, indolore, efficiente e, soprattutto, piacevole possibile. <\/p>\n

Il DevOps \u00e8 nato dal dolore. E ci siamo stancati di soffrire. E per far s\u00ec che tutto ci\u00f2 accada, ci basiamo su pratiche sempreverdi: collaborazione efficace, pratiche di flusso e, ci\u00f2 che \u00e8 pi\u00f9 importante, pensiero sistemico, perch\u00e9 senza di esso nessun DevOps funziona.<\/p>\n

Che cos'\u00e8 un sistema?<\/b><\/h3>\n

\nE se stiamo parlando di pensiero sistemico, ricordiamoci cosa sia un sistema.<\/p>\n

\"DevOps
\n
\nSe sei un hacker rivoluzionario, per te un sistema \u00e8 un male assoluto. \u00c8 una nube che incombe su di te e ti costringe a fare ci\u00f2 che non vuoi fare. <\/p>\n

\"DevOps
\n
\nDal punto di vista del pensiero sistemico, un sistema \u00e8 un insieme che consiste di parti. In questo senso, ognuno di noi \u00e8 un sistema. Le organizzazioni in cui lavoriamo sono sistemi. E ci\u00f2 che stiamo costruendo insieme si chiama proprio sistema.<\/p>\n

Tutto ci\u00f2 \u00e8 parte di un grande sistema sociotecnologico. E solo se comprendiamo come questo sistema sociotecnologico funzioni insieme, allora potremo veramente ottimizzarlo. <\/p>\n

Dal punto di vista del pensiero sistemico, un sistema ha diverse propriet\u00e0 interessanti. In primo luogo, \u00e8 composto da parti, il che significa che il suo comportamento dipende dal comportamento delle parti. E tutte le sue parti sono interdipendenti. Risulta che pi\u00f9 parti ha un sistema, pi\u00f9 difficile \u00e8 capire o prevedere il suo comportamento. <\/p>\n

Dal punto di vista del comportamento, c'\u00e8 un altro fatto interessante. Un sistema pu\u00f2 fare qualcosa che nessuna delle sue singole parti pu\u00f2 fare. <\/p>\n

Come disse il dottor Russell Ackoff (uno dei padri del pensiero sistemico), \u00e8 abbastanza facile dimostrarlo attraverso un esperimento mentale. Ad esempio, chi in sala sa scrivere codice? Molte mani, ed \u00e8 normale, perch\u00e9 \u00e8 uno dei requisiti fondamentali della nostra professione. Tu sai scrivere, ma le tue mani possono scrivere codice separatamente da te? Ci sono persone che diranno: \u00abNon sono le mie mani a scrivere codice, \u00e8 il mio cervello a scrivere codice\u00bb. E il cervello pu\u00f2 scrivere codice separatamente da te? Beh, molto probabilmente no. <\/p>\n

Il cervello \u00e8 una macchina straordinaria; non conosciamo neanche il 10% di come funzioni, ma non pu\u00f2 operare separatamente dal sistema, che \u00e8 il nostro organismo. E questo \u00e8 facile da dimostrare: apri il tuo cranio, estrai il cervello e posizionalo davanti a un computer; provate a scrivere qualcosa di semplice. \u00abHello, world\u00bb in Python, per esempio.<\/p>\n

Se un sistema pu\u00f2 compiere qualcosa che nessuna delle sue parti, da sola, pu\u00f2 fare, significa che il suo comportamento non \u00e8 determinato dal comportamento delle sue parti. Ma da cosa \u00e8 allora determinato? \u00c8 determinato dalle interazioni tra queste parti. Pertanto, pi\u00f9 parti ci sono, pi\u00f9 complesse sono le interazioni, pi\u00f9 difficile \u00e8 comprendere e prevedere il comportamento del sistema. E questo rende tale sistema caotico, perch\u00e9 qualsiasi, anche il pi\u00f9 insignificante, cambiamento invisibile all'occhio in una qualsiasi delle parti del sistema pu\u00f2 portare a risultati completamente imprevedibili. <\/p>\n

Questa sensibilit\u00e0 alle condizioni iniziali \u00e8 stata scoperta e studiata per la prima volta dal meteorologo americano Edward Lorenz. In seguito \u00e8 stata chiamata \u00abeffetto farfalla\u00bb ed ha portato allo sviluppo di un movimento di pensiero scientifico chiamato \u00abteoria del caos\u00bb. Questa teoria \u00e8 diventata uno dei principali spostamenti di paradigma nella scienza del XX secolo.<\/p>\n

Teoria del caos<\/b><\/h3>\n

\nLe persone che si occupano di studiare il caos si definiscono caosologi.<\/p>\n

\"DevOps
\n
\nLa vera ragione di questa relazione \u00e8 che, lavorando con sistemi complessi distribuiti e grandi organizzazioni internazionali, a un certo punto ho capito che questa \u00e8 la mia identit\u00e0. Sono un caosologo. \u00c8, in generale, un modo astuto per dire: \u00abNon capisco cosa sta succedendo qui e non so cosa farci\u00bb. <\/p>\n

Credo che molti di voi si sentano spesso cos\u00ec, quindi anche voi siete caosologi. Vi invito nella gilda dei caosologi. I sistemi che studieremo, cari colleghi caosologi, sono chiamati \u00absistemi adattivi complessi\u00bb. <\/p>\n

Che cos'\u00e8 l'adattabilit\u00e0? L'adattabilit\u00e0 significa che il comportamento individuale e collettivo delle parti in un sistema adattivo cambia e si auto-organizza, rispondendo a eventi o a catene di microscopici eventi nel sistema. Cio\u00e8, il sistema si adatta ai cambiamenti attraverso l'auto-organizzazione. E questa capacit\u00e0 di auto-organizzazione si basa sulla collaborazione volontaria e completamente decentralizzata di agenti autonomi e liberi.<\/p>\n

Un'altra interessante caratteristica di tali sistemi \u00e8 che sono liberamente scalabili. Questo deve sicuramente interessarci come ingegneri della teoria del caos. Dunque, se abbiamo detto che il comportamento di un sistema complesso \u00e8 determinato dall'interazione delle sue parti, cosa dovremmo osservare? L'interazione. <\/p>\n

Ci sono due interessanti conclusioni.
\n \"DevOps
\n
\nInnanzitutto, comprendiamo che non \u00e8 possibile semplificare un sistema complesso semplificando le sue parti. In secondo luogo, l'unico modo per semplificare un sistema complesso \u00e8 semplificare le interazioni tra le sue parti. <\/p>\n

Come interagiamo? Noi siamo tutte parti di un grande sistema informativo che si chiama societ\u00e0 umana. Interagiamo attraverso una lingua comune, se ne abbiamo una, se la troviamo.<\/p>\n

\"DevOps
\n
\nMa la lingua di per s\u00e9 \u00e8 un sistema adattivo complesso. Pertanto, per interagire in modo pi\u00f9 efficace e semplice, \u00e8 necessario creare protocolli. Cio\u00e8, una certa sequenza di simboli e azioni che renda lo scambio di informazioni tra di noi pi\u00f9 semplice, pi\u00f9 prevedibile, pi\u00f9 chiaro.<\/p>\n

Voglio dire che le tendenze verso la complessit\u00e0, l'adattabilit\u00e0, la decentralizzazione e il caos si riscontrano ovunque. E nei sistemi che costruiremo insieme, e nei sistemi di cui facciamo parte.<\/p>\n

E per non rimanere nell'ambiguit\u00e0, diamo un'occhiata a come cambiano i sistemi che costruiamo insieme.<\/p>\n

\"DevOps
\n
\nTi aspettavi questa parola, lo capisco. Siamo alla conferenza DevOps, oggi questa parola verr\u00e0 pronunciata circa centomila volte e poi ci apparir\u00e0 nei sogni di notte.<\/p>\n

I microservizi sono la prima architettura software che \u00e8 emersa come risposta alle pratiche DevOps, concepita per rendere i nostri sistemi pi\u00f9 flessibili, scalabili e garantire una consegna continua. Come ci riesce? Riducendo il volume dei servizi, limitando i confini dei problemi che questi servizi gestiscono, accorciando i tempi di consegna. In altre parole, semplifichiamo le parti del sistema, aumentiamo il loro numero, ed inevitabilmente cresce la complessit\u00e0 delle interazioni tra queste parti, il che porta a nuovi problemi che dobbiamo affrontare.<\/p>\n

\"DevOps
\n
\nI microservizi non sono ancora la fine, i microservizi sono, in effetti, gi\u00e0 un ricordo del passato, perch\u00e9 arriva il Serverless. Tutti i server sono andati in fiamme, non ci sono server, non ci sono sistemi operativi, solo puro codice eseguibile. Le configurazioni separatamente, gli stati separatamente, tutto \u00e8 gestito dagli eventi. Bellezza, pulizia, silenzio, non ci sono eventi, nulla accade, tutto in ordine. <\/p>\n

Dove sta la complessit\u00e0? La complessit\u00e0, come \u00e8 ovvio, sta nelle interazioni. Quanto pu\u00f2 fare un singolo funzionamento da solo? Come interagisce con altri processi? Code di messaggi, database, bilanciatori. Come ricreare un evento quando si verifica un guasto? Tante domande e poche risposte.<\/p>\n

I microservizi e il Serverless sono tutto ci\u00f2 che noi, hippy informatici, chiamiamo Cloud Native. \u00c8 tutto incentrato sul cloud. Ma il cloud, per sua natura, \u00e8 anche limitato nella scalabilit\u00e0. Siamo abituati a pensarlo come un sistema distribuito. Ma dove si trovano i server dei fornitori di cloud? Nei data center. Quindi abbiamo un certo modello distribuito, molto limitato e centralizzato.<\/p>\n

Oggi comprendiamo che l'Internet delle Cose non \u00e8 pi\u00f9 solo un termine altisonante, ma che, anche secondo le stime pi\u00f9 modeste, nei prossimi cinque-dieci anni ci aspettano miliardi di dispositivi connessi a Internet. Un'enorme quantit\u00e0 di dati utili e inutili che saranno raccolti nel cloud e scaricati dal cloud. <\/p>\n

Il cloud non regger\u00e0, ed \u00e8 per questo che parliamo sempre di pi\u00f9 di ci\u00f2 che chiamiamo \"computing perimetrale\". O ancora, mi piace utilizzare la meravigliosa definizione \"fog computing\". \u00c8 avvolto da una certa misticit\u00e0 romantica e misteriosit\u00e0.<\/p>\n

\"DevOps
\n
\nCalcoli nebbiosi. Si parla del fatto che le nuvole sono agglomerati centralizzati di acqua, vapore, ghiaccio e rocce. La nebbia \u00e8 composta da gocce d'acqua che sono disperse attorno a noi nell'atmosfera. <\/p>\n

Nella parabola nebbiosa, gran parte del lavoro \u00e8 svolta da queste gocce in modo completamente autonomo o in collaborazione con altre gocce. E si rivolgono alla nuvola solo quando \u00e8 veramente necessario. <\/p>\n

Insomma, di nuovo decentralizzazione, autonomia, e naturalmente, molti di voi gi\u00e0 comprendono a cosa conduce tutto questo, perch\u00e9 non si pu\u00f2 parlare di decentralizzazione senza menzionare la blockchain. <\/p>\n

\"DevOps
\n
\nCi sono coloro che credono, sono quelli che hanno investito nelle criptovalute. Ci sono coloro che credono ma hanno paura, come me, per esempio. E ci sono quelli che non credono. Si pu\u00f2 avere un'opinione diversa al riguardo. Esiste una tecnologia, una cosa nuova e incomprensibile, ci sono problemi. Come ogni nuova tecnologia, solleva pi\u00f9 domande di quante ne risponda. <\/p>\n

L'hype intorno alla blockchain \u00e8 comprensibile. Anche se si ignora la corsa all'oro, la tecnologia stessa offre promesse straordinarie per un futuro luminoso: pi\u00f9 libert\u00e0, maggiore autonomia, fiducia globale distribuita. Cosa non c'\u00e8 da desiderare? <\/p>\n

Di conseguenza, sempre pi\u00f9 ingegneri in tutto il mondo iniziano a sviluppare applicazioni decentralizzate. Ed \u00e8 una forza dalla quale non si pu\u00f2 semplicemente distogliere lo sguardo dicendo: \u00abAh, la blockchain \u00e8 solo un database distribuito mal implementato\u00bb. O come amano dire gli scettici: \u00abPer la blockchain non ci sono applicazioni reali\u00bb. Se ci si pensa, 150 anni fa dicevano la stessa cosa riguardo all'elettricit\u00e0. E in qualche modo avevano ragione, perch\u00e9 ci\u00f2 che l'elettricit\u00e0 rende possibile oggi, nel XIX secolo era assolutamente impensabile.<\/p>\n

A proposito, chi sa che cos'\u00e8 il logo sullo schermo? \u00c8 Hyperledger. \u00c8 un progetto sviluppato sotto l'egida della Linux Foundation, includendo un insieme di tecnologie blockchain. \u00c8 realmente la forza della nostra comunit\u00e0 open source.<\/p>\n

Ingegneria del caos<\/b><\/h3>\n

\n\"DevOps
\n
\nBene, il sistema che stiamo sviluppando diventa sempre pi\u00f9 complesso, sempre pi\u00f9 caotico e sempre pi\u00f9 adattivo. Netflix \u00e8 un pioniere dei sistemi a microservizi. Sono stati tra i primi a capirlo, hanno sviluppato un insieme di strumenti che chiamano Simian Army, il pi\u00f9 noto dei quali \u00e8 Chaos Monkey<\/a><\/noindex>. Ha definito ci\u00f2 che \u00e8 diventato noto come \u00abprincipi dell'ingegneria del caos\u00bb<\/a><\/noindex>.<\/p>\n

A proposito, durante il lavoro sulla presentazione abbiamo persino tradotto questo testo in russo, quindi visitate il link<\/a><\/noindex>, leggete, commentate, criticategli.<\/p>\n

In breve, i principi dell'ingegneria del caos dicono quanto segue. I sistemi distribuiti complessi sono per loro natura imprevedibili e contengono errori. Gli errori sono inevitabili, e questo significa che dobbiamo accettare questi errori e lavorare con questi sistemi in modo completamente diverso. <\/p>\n

Dobbiamo noi stessi cercare di introdurre questi errori nei nostri sistemi di produzione, per testare i nostri sistemi su questa capacit\u00e0 di adattamento, su questa capacit\u00e0 di auto-organizzazione, sulla resilienza. <\/p>\n

E questo cambia tutto. Non solo il modo in cui mettiamo in produzione il sistema, ma anche il modo in cui li sviluppiamo, il modo in cui li testiamo. Non esiste alcun processo di stabilizzazione, di blocco del codice; al contrario, esiste un processo costante di destabilizzazione. Cerchiamo di danneggiare il sistema e vedere se riesce a sopravvivere.<\/p>\n

Protocolli di integrazione dei sistemi distribuiti<\/b><\/h3>\n

\n\"DevOps
\n
\nDi conseguenza, questo richiede ai nostri sistemi di cambiare in qualche modo. Per diventare pi\u00f9 resilienti, hanno bisogno di nuovi protocolli di interazione tra le loro parti. Affinch\u00e9 queste parti possano comunicare e raggiungere una qualche forma di auto-organizzazione. E nascono vari nuovi strumenti, nuovi protocolli che chiamo \"protocolli di interazione dei sistemi distribuiti\".<\/p>\n

\"DevOps
\n
\nDi cosa sto parlando? In primo luogo, del progetto Opentracing<\/a><\/noindex>. Un tentativo di creare un protocollo comune per il tracciamento distribuito, uno strumento assolutamente indispensabile per il debug di sistemi distribuiti complessi.<\/p>\n

\"DevOps
\n
\nIn seguito \u2014 Open Policy Agent<\/a><\/noindex>. Diciamo che non possiamo prevedere ci\u00f2 che accadr\u00e0 al sistema, quindi dobbiamo migliorare la sua osservabilit\u00e0. Opentracing appartiene a un insieme di strumenti che forniscono osservabilit\u00e0 ai nostri sistemi. Ma abbiamo bisogno di osservabilit\u00e0 per determinare se il sistema si comporta come ci aspettiamo o meno. Come possiamo definire il comportamento atteso? Attraverso la definizione di qualche politica, di un insieme di regole. Il progetto Open Policy Agent si occupa di definire questo insieme di regole su un ampio spettro: dall'accesso all'allocazione delle risorse.<\/p>\n

\"DevOps
\n
\nCome abbiamo detto, i nostri sistemi sono sempre pi\u00f9 orientati agli eventi. Serverless \u00e8 un esempio eccellente di sistemi orientati agli eventi. Per poter trasmettere eventi tra i sistemi e tracciarli, abbiamo bisogno di un linguaggio comune, di un protocollo comune che definisca come parliamo degli eventi, come ce li trasferiamo. Questo \u00e8 ci\u00f2 che si occupa del progetto chiamato Cloudevents<\/a><\/noindex>.<\/p>\n

\"DevOps
\n
\nUn flusso continuo di cambiamenti che pervade i nostri sistemi, destabilizzandoli costantemente, \u00e8 un flusso continuo di artefatti software. Per mantenere questo flusso costante di cambiamenti, abbiamo bisogno di un protocollo comune attraverso il quale possiamo parlare di cosa sia un artefatto software, come \u00e8 stato verificato e quali verifiche ha subito. Questo \u00e8 ci\u00f2 che si occupa del progetto chiamato Grafeas<\/a><\/noindex>. Ossia, un protocollo comune per i metadati degli artefatti software.<\/p>\n

\"DevOps
\n
\nInfine, se vogliamo che i nostri sistemi siano completamente autonomi, adattivi e in grado di auto-organizzarsi, dobbiamo concedere loro il diritto all'autoidentificazione. Il progetto chiamato spiffe<\/a><\/noindex> si occupa proprio di questo. \u00c8 anche un progetto sotto l'egida della Cloud Native Computing Foundation.<\/p>\n

Tutti questi progetti sono giovani, hanno bisogno del nostro supporto e della nostra verifica. Sono tutti open source, il nostro test e la nostra implementazione. Ci mostrano in quale direzione sta andando la tecnologia. <\/p>\n

Ma DevOps non \u00e8 mai stato prima di tutto una questione di tecnologia, \u00e8 sempre stato una questione di collaborazione tra le persone. E quindi, se vogliamo che i sistemi che stiamo sviluppando cambino, dobbiamo cambiare noi stessi. In realt\u00e0, stiamo gi\u00e0 cambiando, non abbiamo molte scelte. <\/p>\n

\"DevOps
\n
\nC'\u00e8 un'ottima libro<\/a><\/noindex> della scrittrice britannica Rachel Botsman, nella quale scrive sull'evoluzione della fiducia nel corso della storia umana. Dice che inizialmente, nelle societ\u00e0 primitive, la fiducia era locale, cio\u00e8 ci si fidava solo di coloro che conoscevamo personalmente. <\/p>\n

Poi c'\u00e8 stato un lungo periodo \u2014 un'epoca buia, quando la fiducia era centralizzata, quando abbiamo cominciato a fidarci di persone che non conoscevamo in base al fatto che appartenevamo allo stesso istituto sociale o statale.<\/p>\n

Ecco cosa vediamo nel nostro mondo moderno: la fiducia sta diventando sempre pi\u00f9 distribuita e decentralizzata, basata sulla libert\u00e0 dei flussi informativi e sull'accessibilit\u00e0 dell'informazione. <\/p>\n

Se ci pensiamo, \u00e8 proprio quest'accessibilit\u00e0, che rende possibile questa fiducia, che noi mettiamo in atto. Ci\u00f2 significa che deve cambiare anche il modo in cui collaboriamo e come lo facciamo, perch\u00e9 le organizzazioni IT centralizzate e gerarchiche del vecchio tipo smettono di funzionare. Cominciano a estinguersi. <\/p>\n

Le fondamenta delle organizzazioni DevOps<\/b><\/h3>\n

\nL'organizzazione DevOps ideale del futuro \u00e8 un sistema decentralizzato e adattivo, composto da team autonomi, ciascuno dei quali costituito da individui autonomi. Questi team sono distribuiti in tutto il mondo e collaborano efficacemente tra loro attraverso comunicazioni asincrone e protocolli di scambio informativo ad alta trasparenza. Molto bello, vero? Un futuro molto affascinante.<\/p>\n

Certo, tutto questo \u00e8 impossibile senza cambiamenti culturali. Dobbiamo avere una leadership trasformativa, responsabilit\u00e0 personale, motivazione intrinseca.<\/p>\n

\"DevOps
\n
\nQuesta \u00e8 la base delle organizzazioni DevOps: trasparenza dell'informazione, comunicazioni asincrone, leadership trasformativa, decentralizzazione. <\/p>\n

Burnout<\/b><\/h3>\n

\nI sistemi di cui siamo parte, e quelli che costruiamo, sono sempre pi\u00f9 caotici, e a noi, come esseri umani, \u00e8 difficile affrontare questo pensiero, \u00e8 difficile rinunciare all'illusione del controllo. Cerchiamo di continuare a controllarli, e questo spesso porta al burnout. Lo dico per esperienza personale, anche io ne ho sofferto, anch'io sono una vittima degli imprevisti in produzione.<\/p>\n

\"DevOps
\n
\nIl burnout si verifica quando cerchiamo di controllare ci\u00f2 che per sua natura non \u00e8 controllabile. Quando bruciamo, tutto perde di significato, perch\u00e9 perdiamo il desiderio di creare qualcosa di nuovo, ci mettiamo sulla difensiva e iniziamo a proteggere ci\u00f2 che abbiamo. <\/p>\n

La professione di ingegnere, come amo ricordare, \u00e8 prima di tutto una professione creativa. Se perdiamo il desiderio di creare, ci trasformiamo in cenere, ci riduciamo in polvere. Le persone bruciano, intere organizzazioni bruciano.<\/p>\n

A mio avviso, solo accettando la forza creativa del caos, solo costruendo collaborazioni secondo i suoi principi, possiamo preservare ci\u00f2 che di buono abbiamo nella nostra professione. <\/p>\n

Ci\u00f2 che vi auguro \u00e8 di amare il vostro lavoro, di amare ci\u00f2 che facciamo. Questo mondo si nutre di informazioni, abbiamo l'onore di nutrirlo. Quindi, impariamo a studiare il caos, diventiamo caosologi, portiamo valore, creiamo qualcosa di nuovo, e i problemi, come abbiamo gi\u00e0 scoperto, sono inevitabili; e quando si presenteranno, diremo semplicemente 'Ops!', e il problema sar\u00e0 risolto. <\/p>\n

Cosa c'\u00e8 oltre Chaos Monkey?<\/b><\/p>\n

In realt\u00e0, tutti questi strumenti sono molto giovani. Anche Netflix ha creato strumenti per se stessa. Costruite strumenti per voi stessi. Leggete i principi dell'ingegneria del caos e seguite questi principi, invece di cercare altri strumenti che qualcun altro ha gi\u00e0 creato. <\/p>\n

Cercate di capire come si rompono i vostri sistemi e iniziate a romperli, osservando come sopportano i colpi. Questo \u00e8 il primo passo. Gli strumenti possono essere cercati. Ci sono vari progetti. <\/p>\n

Non ho ben capito il punto quando parlavate del fatto che non si pu\u00f2 semplificare un sistema semplificando i suoi componenti, e immediatamente siete passati ai microservizi, che in effetti semplificano il sistema semplificando i componenti stessi e complicando le interazioni. Sono sostanzialmente due parti, in contrasto tra loro. <\/b><\/p>\n

Esatto, i microservizi sono un tema molto controverso in generale. In realt\u00e0, semplificare le parti aumenta la flessibilit\u00e0. Cosa ci danno i microservizi? Ci danno flessibilit\u00e0 e velocit\u00e0, ma di certo non ci danno semplificazione. Aumentano la complessit\u00e0.<\/p>\n

Quindi, nella filosofia DevOps, i microservizi non sono cos\u00ec vantaggiosi?<\/b><\/p>\n

Ogni bene ha il suo rovescio. C'\u00e8 un vantaggio: questo aumenta la flessibilit\u00e0, ci consente di apportare modifiche pi\u00f9 rapidamente, ma aumenta anche la complessit\u00e0 e, di conseguenza, la fragilit\u00e0 dell'intero sistema. <\/p>\n

Su cosa dobbiamo concentrarci di pi\u00f9: semplificare le interazioni o semplificare le parti?<\/b> <\/p>\n

L'attenzione \u00e8 senza dubbio rivolta alla semplificazione dell'interazione, perch\u00e9 se guardiamo a questo dal punto di vista di come lavoriamo insieme, prima di tutto dobbiamo concentrarci sulla semplificazione delle interazioni, e non sulla semplificazione del lavoro di ciascuno di noi separatamente. Perch\u00e9 semplificare il lavoro significa trasformarsi in robot. Questo funziona bene da McDonald's, dove ti viene prescritto: qui metti il panino, qui ci metti la salsa. Questo, nella nostra attivit\u00e0 creativa, non funziona affatto.<\/p>\n

\u00c8 vero che tutto ci\u00f2 che avete raccontato vive in un mondo senza concorrenza, e il caos l\u00ec \u00e8 cos\u00ec gentile, e non ci sono contraddizioni all'interno di questo caos, nessuno vuole mangiare o uccidere qualcuno? Come devono convivere concorrenza e DevOps?<\/b><\/p>\n

Beh, dipende da quale concorrenza stiamo parlando. Della concorrenza sul posto di lavoro o della concorrenza tra le aziende? <\/p>\n

Della concorrenza dei servizi esistenti, perch\u00e9 i servizi non sono solo un insieme di aziende. Stiamo creando un nuovo tipo di ambiente informatico, e nessun ambiente pu\u00f2 esistere senza concorrenza. Ovunque c'\u00e8 concorrenza.<\/b><\/p>\n

Prendiamo esempio dai Netflix, considerandoli come un modello di riferimento. L'hanno ideato, perch\u00e9 dovevano essere competitivi. Questa flessibilit\u00e0 e rapidit\u00e0 di movimento \u00e8 proprio quella richiesta competitiva, porta il caos nei nostri sistemi. Cio\u00e8, il caos non \u00e8 qualcosa che facciamo consapevolmente perch\u00e9 lo desideriamo, \u00e8 ci\u00f2 che accade perch\u00e9 il mondo lo richiede. Dobbiamo semplicemente adattarci. E il caos \u00e8 proprio il risultato della concorrenza.<\/p>\n

Significa quindi che il caos \u00e8 un'assenza di obiettivi, in un certo senso? O sono quegli obiettivi che non vogliamo vedere? Siamo in una piccola casa e non comprendiamo gli obiettivi degli altri. La concorrenza, in realt\u00e0, si basa sul fatto che abbiamo obiettivi chiari, e sappiamo dove arriveremo ad ogni momento successivo. Questo, secondo me, \u00e8 il significato di DevOps.<\/b><\/p>\n

\u00c8 anche un punto di vista sulla questione. Penso che l'obiettivo di tutti noi sia uno: sopravvivere e farlo con
\nil massimo piacere. E l'obiettivo competitivo di qualsiasi organizzazione \u00e8 lo stesso. La sopravvivenza avviene spesso nella lotta competitiva, non possiamo farci nulla.<\/p>\n

Quest'anno la conferenza DevOpsDays Moscow<\/a><\/noindex> si svolger\u00e0 il 7 dicembre a \"Technopolis\". Accettiamo proposte di relazioni fino all'11 novembre. Scriveteci<\/a><\/noindex> se desiderate intervenire.<\/p>\n

La registrazione per i partecipanti \u00e8 aperta, il biglietto costa 7000 rubli. Unisciti a noi! \n<\/p><\/blockquote>\n

Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041e\u0441\u043d\u043e\u0432\u0430\u0442\u0435\u043b\u044c \u0438 \u0434\u0438\u0440\u0435\u043a\u0442\u043e\u0440 \u00abOtomato Software\u00bb, \u043e\u0434\u0438\u043d \u0438\u0437 \u0438\u043d\u0438\u0446\u0438\u0430\u0442\u043e\u0440\u043e\u0432 \u0438 \u0438\u043d\u0441\u0442\u0440\u0443\u043a\u0442\u043e\u0440\u043e\u0432 \u043f\u0435\u0440\u0432\u043e\u0439 \u0432 \u0418\u0437\u0440\u0430\u0438\u043b\u0435 DevOps-\u0441\u0435\u0440\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u0438 \u0410\u043d\u0442\u043e\u043d \u0412\u0430\u0439\u0441 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b \u043d\u0430 \u043f\u0440\u043e\u0448\u043b\u043e\u0433\u043e\u0434\u043d\u0435\u043c DevOpsDays Moscow \u043f\u0440\u043e \u0442\u0435\u043e\u0440\u0438\u044e \u0445\u0430\u043e\u0441\u0430 \u0438 \u0433\u043b\u0430\u0432\u043d\u044b\u0435 \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u044b \u0445\u0430\u043e\u0441\u043d\u043e\u0439 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u0438\u0438, \u0430 \u0442\u0430\u043a\u0436\u0435 \u043e\u0431\u044a\u044f\u0441\u043d\u0438\u043b, \u043a\u0430\u043a \u0443\u0441\u0442\u0440\u043e\u0435\u043d\u0430 \u0438\u0434\u0435\u0430\u043b\u044c\u043d\u0430\u044f DevOps-\u043e\u0440\u0433\u0430\u043d\u0438\u0437\u0430\u0446\u0438\u044f \u0431\u0443\u0434\u0443\u0449\u0435\u0433\u043e. \u041c\u044b \u043f\u0440\u0438\u0433\u043e\u0442\u043e\u0432\u0438\u043b\u0438 \u0442\u0435\u043a\u0441\u0442\u043e\u0432\u0443\u044e \u0432\u0435\u0440\u0441\u0438\u044e \u0434\u043e\u043a\u043b\u0430\u0434\u0430. \u0414\u043e\u0431\u0440\u043e\u0435 \u0443\u0442\u0440\u043e! DevOpsDays \u0432 \u041c\u043e\u0441\u043a\u0432\u0435 \u0432\u0442\u043e\u0440\u043e\u0439 \u0433\u043e\u0434 \u043f\u043e\u0434\u0440\u044f\u0434, \u044f \u0432\u0442\u043e\u0440\u043e\u0439 \u0440\u0430\u0437 \u043d\u0430 \u044d\u0442\u043e\u0439 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":29435,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-39219","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47DevOps e Chaos: distribuzione del software in un mondo decentralizzato | ProHoster","description":"Il fondatore e direttore di \u00abOtomato Software\u00bb, uno dei promotori e istruttori della prima certificazione DevOps in Israele, Anton Weiss, ha parlato lo scorso anno","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/devops-i-haos-dostavka-po-v-detsentralizovannom-mire","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0414\u0435\u0432\u041e\u043f\u0441 \u0438 \u0425\u0430\u043e\u0441: \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0430 \u041f\u041e \u0432 \u0434\u0435\u0446\u0435\u043d\u0442\u0440\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u043e\u043c \u043c\u0438\u0440\u0435 | ProHoster","og:description":"\u041e\u0441\u043d\u043e\u0432\u0430\u0442\u0435\u043b\u044c \u0438 \u0434\u0438\u0440\u0435\u043a\u0442\u043e\u0440 \u00abOtomato Software\u00bb, \u043e\u0434\u0438\u043d \u0438\u0437 \u0438\u043d\u0438\u0446\u0438\u0430\u0442\u043e\u0440\u043e\u0432 \u0438 \u0438\u043d\u0441\u0442\u0440\u0443\u043a\u0442\u043e\u0440\u043e\u0432 \u043f\u0435\u0440\u0432\u043e\u0439 \u0432 \u0418\u0437\u0440\u0430\u0438\u043b\u0435 DevOps-\u0441\u0435\u0440\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u0438 \u0410\u043d\u0442\u043e\u043d \u0412\u0430\u0439\u0441 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b \u043d\u0430 \u043f\u0440\u043e\u0448\u043b\u043e\u0433\u043e\u0434\u043d\u0435\u043c","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/devops-i-haos-dostavka-po-v-detsentralizovannom-mire","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:28:31+00:00","article:modified_time":"2019-10-31T19:28:31+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"39219","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 01:19:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 00:54:41","updated":"2026-01-24 01:19:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/39219","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=39219"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/39219\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/29435"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=39219"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=39219"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=39219"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}