Il fondatore e direttore di «Otomato Software», uno dei promotori e istruttori della prima certificazione DevOps in Israele, Anton Weiss, ha parlato lo scorso anno della teoria del caos e dei principi fondamentali dell'ingegneria del caos, e ha anche spiegato come sarà organizzata l'ideale organizzazione DevOps del futuro.
Abbiamo preparato una versione testuale della presentazione.
Buongiorno!
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 è ora di parlare di cosa rappresenta DevOps nel 2018.
Alzate la mano quelli che pensano che nel 2018 DevOps sia già una professione? Ci sono? Ci sono ingegneri DevOps in sala, il cui lavoro è descritto come «ingegnere DevOps»? Ci sono manager DevOps in sala? Non ce ne sono. Architetti DevOps? Neanche. Appena pochi. Davvero nessuno ha la qualifica di ingegnere DevOps?
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.
Chi ha sentito parlare del nuovo tema chiamato DevDevOps? È un nuovo metodo che consente di garantire una collaborazione efficace tra sviluppatori e DevOps. E non è poi così nuovo. Giudicando dai tweet, già quattro anni fa si parlava di questo. E ancora adesso, l'interesse continua a crescere, quindi il problema esiste. Il problema va risolto.
Siamo persone creative, non ci accontentiamo facilmente. Diciamo: DevOps è 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.
La logica è 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à con «Ops», e il problema sarà risolto.
Così chiamo questo approccio: «Ops, e il problema è risolto».
Tutto questo passa in secondo piano se ci ricordiamo perché abbiamo progettato tutto ciò. Abbiamo creato tutto questo DevOps per rendere la consegna del software e il nostro lavoro in questo processo il più fluido, indolore, efficiente e, soprattutto, piacevole possibile.
Il DevOps è nato dal dolore. E ci siamo stancati di soffrire. E per far sì che tutto ciò accada, ci basiamo su pratiche sempreverdi: collaborazione efficace, pratiche di flusso e, ciò che è più importante, pensiero sistemico, perché senza di esso nessun DevOps funziona.
Che cos'è un sistema?
E se stiamo parlando di pensiero sistemico, ricordiamoci cosa sia un sistema.
Se sei un hacker rivoluzionario, per te un sistema è un male assoluto. È una nube che incombe su di te e ti costringe a fare ciò che non vuoi fare.
Dal punto di vista del pensiero sistemico, un sistema è un insieme che consiste di parti. In questo senso, ognuno di noi è un sistema. Le organizzazioni in cui lavoriamo sono sistemi. E ciò che stiamo costruendo insieme si chiama proprio sistema.
Tutto ciò è parte di un grande sistema sociotecnologico. E solo se comprendiamo come questo sistema sociotecnologico funzioni insieme, allora potremo veramente ottimizzarlo.
Dal punto di vista del pensiero sistemico, un sistema ha diverse proprietà interessanti. In primo luogo, è 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ù parti ha un sistema, più difficile è capire o prevedere il suo comportamento.
Dal punto di vista del comportamento, c'è un altro fatto interessante. Un sistema può fare qualcosa che nessuna delle sue singole parti può fare.
Come disse il dottor Russell Ackoff (uno dei padri del pensiero sistemico), è abbastanza facile dimostrarlo attraverso un esperimento mentale. Ad esempio, chi in sala sa scrivere codice? Molte mani, ed è normale, perché è 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: «Non sono le mie mani a scrivere codice, è il mio cervello a scrivere codice». E il cervello può scrivere codice separatamente da te? Beh, molto probabilmente no.
Il cervello è una macchina straordinaria; non conosciamo neanche il 10% di come funzioni, ma non può operare separatamente dal sistema, che è il nostro organismo. E questo è facile da dimostrare: apri il tuo cranio, estrai il cervello e posizionalo davanti a un computer; provate a scrivere qualcosa di semplice. «Hello, world» in Python, per esempio.
Se un sistema può compiere qualcosa che nessuna delle sue parti, da sola, può fare, significa che il suo comportamento non è determinato dal comportamento delle sue parti. Ma da cosa è allora determinato? È determinato dalle interazioni tra queste parti. Pertanto, più parti ci sono, più complesse sono le interazioni, più difficile è comprendere e prevedere il comportamento del sistema. E questo rende tale sistema caotico, perché qualsiasi, anche il più insignificante, cambiamento invisibile all'occhio in una qualsiasi delle parti del sistema può portare a risultati completamente imprevedibili.
Questa sensibilità alle condizioni iniziali è stata scoperta e studiata per la prima volta dal meteorologo americano Edward Lorenz. In seguito è stata chiamata «effetto farfalla» ed ha portato allo sviluppo di un movimento di pensiero scientifico chiamato «teoria del caos». Questa teoria è diventata uno dei principali spostamenti di paradigma nella scienza del XX secolo.
Teoria del caos
Le persone che si occupano di studiare il caos si definiscono caosologi.
La vera ragione di questa relazione è che, lavorando con sistemi complessi distribuiti e grandi organizzazioni internazionali, a un certo punto ho capito che questa è la mia identità. Sono un caosologo. È, in generale, un modo astuto per dire: «Non capisco cosa sta succedendo qui e non so cosa farci».
Credo che molti di voi si sentano spesso così, quindi anche voi siete caosologi. Vi invito nella gilda dei caosologi. I sistemi che studieremo, cari colleghi caosologi, sono chiamati «sistemi adattivi complessi».
Che cos'è l'adattabilità? L'adattabilità 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è, il sistema si adatta ai cambiamenti attraverso l'auto-organizzazione. E questa capacità di auto-organizzazione si basa sulla collaborazione volontaria e completamente decentralizzata di agenti autonomi e liberi.
Un'altra interessante caratteristica di tali sistemi è 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 è determinato dall'interazione delle sue parti, cosa dovremmo osservare? L'interazione.
Ci sono due interessanti conclusioni.
Innanzitutto, comprendiamo che non è possibile semplificare un sistema complesso semplificando le sue parti. In secondo luogo, l'unico modo per semplificare un sistema complesso è semplificare le interazioni tra le sue parti.
Come interagiamo? Noi siamo tutte parti di un grande sistema informativo che si chiama società umana. Interagiamo attraverso una lingua comune, se ne abbiamo una, se la troviamo.
Ma la lingua di per sé è un sistema adattivo complesso. Pertanto, per interagire in modo più efficace e semplice, è necessario creare protocolli. Cioè, una certa sequenza di simboli e azioni che renda lo scambio di informazioni tra di noi più semplice, più prevedibile, più chiaro.
Voglio dire che le tendenze verso la complessità, l'adattabilità, la decentralizzazione e il caos si riscontrano ovunque. E nei sistemi che costruiremo insieme, e nei sistemi di cui facciamo parte.
E per non rimanere nell'ambiguità, diamo un'occhiata a come cambiano i sistemi che costruiamo insieme.
Ti aspettavi questa parola, lo capisco. Siamo alla conferenza DevOps, oggi questa parola verrà pronunciata circa centomila volte e poi ci apparirà nei sogni di notte.
I microservizi sono la prima architettura software che è emersa come risposta alle pratiche DevOps, concepita per rendere i nostri sistemi più 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à delle interazioni tra queste parti, il che porta a nuovi problemi che dobbiamo affrontare.
I microservizi non sono ancora la fine, i microservizi sono, in effetti, già un ricordo del passato, perché 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 è gestito dagli eventi. Bellezza, pulizia, silenzio, non ci sono eventi, nulla accade, tutto in ordine.
Dove sta la complessità? La complessità, come è ovvio, sta nelle interazioni. Quanto può 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.
I microservizi e il Serverless sono tutto ciò che noi, hippy informatici, chiamiamo Cloud Native. È tutto incentrato sul cloud. Ma il cloud, per sua natura, è anche limitato nella scalabilità. 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.
Oggi comprendiamo che l'Internet delle Cose non è più solo un termine altisonante, ma che, anche secondo le stime più modeste, nei prossimi cinque-dieci anni ci aspettano miliardi di dispositivi connessi a Internet. Un'enorme quantità di dati utili e inutili che saranno raccolti nel cloud e scaricati dal cloud.
Il cloud non reggerà, ed è per questo che parliamo sempre di più di ciò che chiamiamo "computing perimetrale". O ancora, mi piace utilizzare la meravigliosa definizione "fog computing". È avvolto da una certa misticità romantica e misteriosità.
Calcoli nebbiosi. Si parla del fatto che le nuvole sono agglomerati centralizzati di acqua, vapore, ghiaccio e rocce. La nebbia è composta da gocce d'acqua che sono disperse attorno a noi nell'atmosfera.
Nella parabola nebbiosa, gran parte del lavoro è svolta da queste gocce in modo completamente autonomo o in collaborazione con altre gocce. E si rivolgono alla nuvola solo quando è veramente necessario.
Insomma, di nuovo decentralizzazione, autonomia, e naturalmente, molti di voi già comprendono a cosa conduce tutto questo, perché non si può parlare di decentralizzazione senza menzionare la blockchain.
Ci 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ò avere un'opinione diversa al riguardo. Esiste una tecnologia, una cosa nuova e incomprensibile, ci sono problemi. Come ogni nuova tecnologia, solleva più domande di quante ne risponda.
L'hype intorno alla blockchain è comprensibile. Anche se si ignora la corsa all'oro, la tecnologia stessa offre promesse straordinarie per un futuro luminoso: più libertà, maggiore autonomia, fiducia globale distribuita. Cosa non c'è da desiderare?
Di conseguenza, sempre più ingegneri in tutto il mondo iniziano a sviluppare applicazioni decentralizzate. Ed è una forza dalla quale non si può semplicemente distogliere lo sguardo dicendo: «Ah, la blockchain è solo un database distribuito mal implementato». O come amano dire gli scettici: «Per la blockchain non ci sono applicazioni reali». Se ci si pensa, 150 anni fa dicevano la stessa cosa riguardo all'elettricità. E in qualche modo avevano ragione, perché ciò che l'elettricità rende possibile oggi, nel XIX secolo era assolutamente impensabile.
A proposito, chi sa che cos'è il logo sullo schermo? È Hyperledger. È un progetto sviluppato sotto l'egida della Linux Foundation, includendo un insieme di tecnologie blockchain. È realmente la forza della nostra comunità open source.
Ingegneria del caos
Bene, il sistema che stiamo sviluppando diventa sempre più complesso, sempre più caotico e sempre più adattivo. Netflix è 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ù noto dei quali è . Ha definito ciò che è diventato noto come .
A proposito, durante il lavoro sulla presentazione abbiamo persino tradotto questo testo in russo, quindi visitate il , leggete, commentate, criticategli.
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.
Dobbiamo noi stessi cercare di introdurre questi errori nei nostri sistemi di produzione, per testare i nostri sistemi su questa capacità di adattamento, su questa capacità di auto-organizzazione, sulla resilienza.
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.
Protocolli di integrazione dei sistemi distribuiti
Di conseguenza, questo richiede ai nostri sistemi di cambiare in qualche modo. Per diventare più resilienti, hanno bisogno di nuovi protocolli di interazione tra le loro parti. Affinché 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".
Di cosa sto parlando? In primo luogo, del progetto . Un tentativo di creare un protocollo comune per il tracciamento distribuito, uno strumento assolutamente indispensabile per il debug di sistemi distribuiti complessi.
In seguito — . Diciamo che non possiamo prevedere ciò che accadrà al sistema, quindi dobbiamo migliorare la sua osservabilità. Opentracing appartiene a un insieme di strumenti che forniscono osservabilità ai nostri sistemi. Ma abbiamo bisogno di osservabilità 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.
Come abbiamo detto, i nostri sistemi sono sempre più orientati agli eventi. Serverless è 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 è ciò che si occupa del progetto chiamato .
Un flusso continuo di cambiamenti che pervade i nostri sistemi, destabilizzandoli costantemente, è 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 è stato verificato e quali verifiche ha subito. Questo è ciò che si occupa del progetto chiamato . Ossia, un protocollo comune per i metadati degli artefatti software.
Infine, 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 si occupa proprio di questo. È anche un progetto sotto l'egida della Cloud Native Computing Foundation.
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.
Ma DevOps non è mai stato prima di tutto una questione di tecnologia, è 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à, stiamo già cambiando, non abbiamo molte scelte.
C'è un'ottima della scrittrice britannica Rachel Botsman, nella quale scrive sull'evoluzione della fiducia nel corso della storia umana. Dice che inizialmente, nelle società primitive, la fiducia era locale, cioè ci si fidava solo di coloro che conoscevamo personalmente.
Poi c'è stato un lungo periodo — 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.
Ecco cosa vediamo nel nostro mondo moderno: la fiducia sta diventando sempre più distribuita e decentralizzata, basata sulla libertà dei flussi informativi e sull'accessibilità dell'informazione.
Se ci pensiamo, è proprio quest'accessibilità, che rende possibile questa fiducia, che noi mettiamo in atto. Ciò significa che deve cambiare anche il modo in cui collaboriamo e come lo facciamo, perché le organizzazioni IT centralizzate e gerarchiche del vecchio tipo smettono di funzionare. Cominciano a estinguersi.
Le fondamenta delle organizzazioni DevOps
L'organizzazione DevOps ideale del futuro è 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.
Certo, tutto questo è impossibile senza cambiamenti culturali. Dobbiamo avere una leadership trasformativa, responsabilità personale, motivazione intrinseca.
Questa è la base delle organizzazioni DevOps: trasparenza dell'informazione, comunicazioni asincrone, leadership trasformativa, decentralizzazione.
Burnout
I sistemi di cui siamo parte, e quelli che costruiamo, sono sempre più caotici, e a noi, come esseri umani, è difficile affrontare questo pensiero, è 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.
Il burnout si verifica quando cerchiamo di controllare ciò che per sua natura non è controllabile. Quando bruciamo, tutto perde di significato, perché perdiamo il desiderio di creare qualcosa di nuovo, ci mettiamo sulla difensiva e iniziamo a proteggere ciò che abbiamo.
La professione di ingegnere, come amo ricordare, è 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.
A mio avviso, solo accettando la forza creativa del caos, solo costruendo collaborazioni secondo i suoi principi, possiamo preservare ciò che di buono abbiamo nella nostra professione.
Ciò che vi auguro è di amare il vostro lavoro, di amare ciò 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à scoperto, sono inevitabili; e quando si presenteranno, diremo semplicemente 'Ops!', e il problema sarà risolto.
Cosa c'è oltre Chaos Monkey?
In realtà, 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à creato.
Cercate di capire come si rompono i vostri sistemi e iniziate a romperli, osservando come sopportano i colpi. Questo è il primo passo. Gli strumenti possono essere cercati. Ci sono vari progetti.
Non ho ben capito il punto quando parlavate del fatto che non si può 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.
Esatto, i microservizi sono un tema molto controverso in generale. In realtà, semplificare le parti aumenta la flessibilità. Cosa ci danno i microservizi? Ci danno flessibilità e velocità, ma di certo non ci danno semplificazione. Aumentano la complessità.
Quindi, nella filosofia DevOps, i microservizi non sono così vantaggiosi?
Ogni bene ha il suo rovescio. C'è un vantaggio: questo aumenta la flessibilità, ci consente di apportare modifiche più rapidamente, ma aumenta anche la complessità e, di conseguenza, la fragilità dell'intero sistema.
Su cosa dobbiamo concentrarci di più: semplificare le interazioni o semplificare le parti?
L'attenzione è senza dubbio rivolta alla semplificazione dell'interazione, perché 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é 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à creativa, non funziona affatto.
È vero che tutto ciò che avete raccontato vive in un mondo senza concorrenza, e il caos lì è così gentile, e non ci sono contraddizioni all'interno di questo caos, nessuno vuole mangiare o uccidere qualcuno? Come devono convivere concorrenza e DevOps?
Beh, dipende da quale concorrenza stiamo parlando. Della concorrenza sul posto di lavoro o della concorrenza tra le aziende?
Della concorrenza dei servizi esistenti, perché i servizi non sono solo un insieme di aziende. Stiamo creando un nuovo tipo di ambiente informatico, e nessun ambiente può esistere senza concorrenza. Ovunque c'è concorrenza.
Prendiamo esempio dai Netflix, considerandoli come un modello di riferimento. L'hanno ideato, perché dovevano essere competitivi. Questa flessibilità e rapidità di movimento è proprio quella richiesta competitiva, porta il caos nei nostri sistemi. Cioè, il caos non è qualcosa che facciamo consapevolmente perché lo desideriamo, è ciò che accade perché il mondo lo richiede. Dobbiamo semplicemente adattarci. E il caos è proprio il risultato della concorrenza.
Significa quindi che il caos è 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à, si basa sul fatto che abbiamo obiettivi chiari, e sappiamo dove arriveremo ad ogni momento successivo. Questo, secondo me, è il significato di DevOps.
È anche un punto di vista sulla questione. Penso che l'obiettivo di tutti noi sia uno: sopravvivere e farlo con
il massimo piacere. E l'obiettivo competitivo di qualsiasi organizzazione è lo stesso. La sopravvivenza avviene spesso nella lotta competitiva, non possiamo farci nulla.
Quest'anno la conferenza si svolgerà il 7 dicembre a "Technopolis". Accettiamo proposte di relazioni fino all'11 novembre. se desiderate intervenire.
La registrazione per i partecipanti è aperta, il biglietto costa 7000 rubli. Unisciti a noi!
Fonte: habr.com
