Anton Weiss, fondatore e direttore di Otomato Software, uno dei promotori e docenti della prima certificazione DevOps in Israele, è intervenuto all'edizione dello scorso anno sulla teoria del caos e sui principi fondamentali dell'ingegneria del caos, e ha anche spiegato come funziona l'organizzazione DevOps ideale del futuro.
Abbiamo preparato una versione testuale del rapporto.
Buongiorno!
DevOpsDays a Mosca per il secondo anno consecutivo, questa è la mia seconda volta su questo palco, molti di voi sono in questa stanza per la seconda volta. Cosa significa? Ciò significa che il movimento DevOps in Russia sta crescendo, moltiplicandosi e, soprattutto, significa che è giunto il momento di parlare di cosa sia DevOps nel 2018.
Alzi la mano chi pensa che DevOps sia già una professione nel 2018? Ce ne sono. Sono presenti ingegneri DevOps nella stanza la cui descrizione del lavoro dice "Ingegnere DevOps"? Sono presenti responsabili DevOps nella stanza? Non esiste tale. Architetti DevOps? Anche no. Non abbastanza. È proprio vero che nessuno dice di essere un ingegnere DevOps?
Quindi molti di voi pensano che questo sia un anti-modello? Che una professione del genere non dovrebbe esistere? Possiamo pensare quello che vogliamo, ma mentre pensiamo, il settore avanza solennemente al suono della tromba DevOps.
Chi ha sentito parlare di un nuovo argomento chiamato DevDevOps? Questa è una nuova tecnica che consente una collaborazione efficace tra sviluppatori e devops. E non così nuovo. A giudicare da Twitter, hanno già iniziato a parlarne 4 anni fa. E fino ad ora, l'interesse per questo cresce e cresce, cioè c'è un problema. Il problema deve essere risolto.
Siamo persone creative, non ci limitiamo a riposare facilmente. Diciamo: DevOps non è una parola abbastanza completa; manca ancora tutta una serie di elementi diversi e interessanti. E andiamo nei nostri laboratori segreti e iniziamo a produrre mutazioni interessanti: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
La logica è ferrea, giusto? Il nostro sistema di consegna non funziona, i nostri sistemi sono instabili e i nostri utenti sono insoddisfatti, non abbiamo tempo per implementare il software in tempo, non rientriamo nel budget. Come risolveremo tutto questo? Troveremo una nuova parola! Si concluderà con "Ops" e il problema sarà risolto.
Quindi chiamo questo approccio: "Ops, e il problema è risolto".
Tutto questo passa in secondo piano se ricordiamo a noi stessi il motivo per cui abbiamo inventato tutto questo. Abbiamo ideato tutta questa faccenda DevOps per rendere la distribuzione del software e il nostro lavoro in questo processo il più possibile senza ostacoli, indolore, efficiente e, soprattutto, divertente.
DevOps è nato dal dolore. E siamo stanchi di soffrire. E affinché tutto ciò accada, ci affidiamo a pratiche sempreverdi: collaborazione efficace, pratiche di flusso e, soprattutto, pensiero sistemico, perché senza di esso nessun DevOps funziona.
Che cos'è un sistema?
E se stiamo già parlando di pensiero sistemico, ricordiamoci cos’è un sistema.
Se sei un hacker rivoluzionario, allora per te il sistema è chiaramente malvagio. È una nuvola che incombe su di te e ti costringe a fare cose che non vuoi fare.
Dal punto di vista del pensiero sistemico, un sistema è un tutto costituito da parti. In questo senso ognuno di noi è un sistema. Le organizzazioni in cui lavoriamo sono sistemi. E quello che tu ed io stiamo costruendo si chiama sistema.
Tutto questo fa parte di un grande sistema socio-tecnologico. E solo se capiamo come funziona questo sistema socio-tecnologico, solo allora saremo in grado di ottimizzare veramente qualcosa in questa materia.
Dal punto di vista del pensiero sistemico, un sistema ha varie proprietà interessanti. Innanzitutto è costituito da parti, il che significa che il suo comportamento dipende dal comportamento delle parti. Inoltre, tutte le sue parti sono anche interdipendenti. Si scopre che maggiore è il numero di parti di un sistema, più difficile è comprenderne o prevederne il comportamento.
Dal punto di vista comportamentale c’è un altro dato interessante. Il sistema può fare qualcosa che nessuna delle sue singole parti può fare.
Come ha affermato il dottor Russell Ackoff (uno dei fondatori del pensiero sistemico), questo è abbastanza facile da dimostrare con un esperimento mentale. Ad esempio, chi nella stanza sa scrivere codice? Ci sono molte mani, e questo è normale, perché questo è uno dei requisiti principali della nostra professione. Sai scrivere, ma le tue mani possono scrivere codice separatamente da te? Ci sono persone che diranno: “Non sono le mie mani che scrivono il codice, è il mio cervello che scrive il codice”. Il tuo cervello può scrivere codice separatamente da te? Beh, probabilmente no.
Il cervello è una macchina straordinaria, non sappiamo nemmeno il 10% di come funzioni, ma non può funzionare separatamente dal sistema che è il nostro corpo. E questo è facile da dimostrare: apri il tuo cranio, tira fuori il tuo cervello, mettilo davanti al computer, lascialo provare a scrivere qualcosa di semplice. "Hello, world" in Python, per esempio.
Se un sistema può fare qualcosa che nessuna delle sue parti può fare separatamente, ciò significa che il suo comportamento non è determinato dal comportamento delle sue parti. Da cosa è allora determinato? È determinato dall'interazione tra queste parti. E di conseguenza, più sono le parti, più complesse sono le interazioni, più difficile è comprendere e prevedere il comportamento del sistema. E questo rende un sistema del genere caotico, perché qualsiasi cambiamento invisibile, anche il più insignificante, in qualsiasi parte del sistema può portare a risultati completamente imprevedibili.
Questa sensibilità alle condizioni iniziali è stata scoperta e studiata per la prima volta dal meteorologo americano Ed Lorenz. Successivamente venne chiamato “effetto farfalla” e portò allo sviluppo di un movimento di pensiero scientifico chiamato “teoria del caos”. Questa teoria è diventata uno dei principali cambiamenti di paradigma nella scienza del 20° secolo.
Teoria del caos
Le persone che studiano il caos si definiscono caosologi.
In realtà, il motivo di questo rapporto è che, lavorando con sistemi distribuiti complessi e grandi organizzazioni internazionali, ad un certo punto mi sono reso conto che questo è quello che sento. Sono un caosologo. Questo è fondamentalmente un modo intelligente per dire: “Non capisco cosa sta succedendo qui e non so cosa fare al riguardo”.
Penso che anche molti di voi si sentano spesso così, quindi anche voi siete dei caosologi. Ti invito alla gilda dei caosologi. I sistemi che voi ed io, cari colleghi caotologi, studieremo sono chiamati “sistemi adattivi complessi”.
Cos'è l'adattabilità? Adattabilità significa che il comportamento individuale e collettivo delle parti di un sistema adattivo cambia e si auto-organizza, rispondendo a eventi o catene di micro-eventi nel sistema. Cioè, il sistema si adatta ai cambiamenti attraverso l’autorganizzazione. E questa capacità di auto-organizzazione si basa sulla cooperazione volontaria e completamente decentralizzata di agenti liberi e autonomi.
Un'altra proprietà interessante di tali sistemi è che sono liberamente scalabili. Ciò che dovrebbe indubbiamente interessarci, come ingegneri-caosologi. Quindi, se dicessimo che il comportamento di un sistema complesso è determinato dall'interazione delle sue parti, allora a cosa dovremmo interessarci? Interazione.
Ci sono altri due risultati interessanti.
Innanzitutto comprendiamo che un sistema complesso non può essere semplificato semplificandone le parti. In secondo luogo, l’unico modo per semplificare un sistema complesso è semplificare le interazioni tra le sue parti.
Come interagiamo? Tu ed io siamo tutti parti di un grande sistema informativo chiamato società umana. Interagiamo attraverso un linguaggio comune, se lo abbiamo, se lo troviamo.
Ma il linguaggio stesso è un sistema adattivo complesso. Di conseguenza, per interagire in modo più efficiente e semplice, dobbiamo creare una sorta di protocolli. Cioè, una sequenza di simboli e azioni che renderà lo scambio di informazioni tra noi più semplice, più prevedibile, più comprensibile.
Voglio dire che le tendenze verso la complessità, verso l'adattabilità, verso la decentralizzazione, verso il caos si possono rintracciare in ogni cosa. E nei sistemi che tu ed io stiamo costruendo, e in quei sistemi di cui facciamo parte.
E per non essere infondati, diamo un'occhiata a come stanno cambiando i sistemi che creiamo.
Stavi aspettando questa parola, capisco. Siamo ad una conferenza DevOps, oggi questa parola verrà sentita circa centomila volte e poi la sogneremo di notte.
I microservizi sono la prima architettura software emersa come reazione alle pratiche DevOps, progettata per rendere i nostri sistemi più flessibili, più scalabili e garantire una distribuzione continua. Come fa? Riducendo il volume dei servizi, riducendo la portata dei problemi che questi servizi elaborano, riducendo i tempi di consegna. Cioè, riduciamo e semplifichiamo parti del sistema, aumentiamo il loro numero e, di conseguenza, la complessità delle interazioni tra queste parti aumenta invariabilmente, cioè sorgono nuovi problemi che dobbiamo risolvere.
I microservizi non sono la fine, i microservizi sono, in generale, già ieri, perché sta arrivando Serverless. Tutti i server sono bruciati, nessun server, nessun sistema operativo, solo puro codice eseguibile. Le configurazioni sono separate, gli stati sono separati, tutto è controllato dagli eventi. Bellezza, pulizia, silenzio, nessun evento, non succede nulla, ordine completo.
Dov'è la complessità? La difficoltà, ovviamente, sta nelle interazioni. Quanto può fare una funzione da sola? Come interagisce con le altre funzioni? Code di messaggi, database, bilanciatori. Come ricreare un evento quando si è verificato un errore? Tante domande e poche risposte.
Microservizi e Serverless sono ciò che noi hipster geek chiamiamo Cloud Native. È tutta una questione di cloud. Ma il cloud è anche intrinsecamente limitato nella sua scalabilità. Siamo abituati a pensarlo come un sistema distribuito. Infatti, dove risiedono i server dei fornitori di servizi cloud? Nei data center. Cioè, qui abbiamo una sorta di modello centralizzato, molto limitato e distribuito.
Oggi capiamo che l'Internet delle cose non è più solo parolone che, anche secondo modeste previsioni, miliardi di dispositivi connessi a Internet ci aspettano nei prossimi cinque-dieci anni. Un'enorme quantità di dati utili e inutili che verranno fusi nel cloud e caricati dal cloud.
Il cloud non durerà, quindi parliamo sempre più spesso di qualcosa chiamato edge computing. Oppure mi piace anche la meravigliosa definizione di “fog computing”. È avvolto nel misticismo del romanticismo e del mistero.
Calcolo della nebbia. Il punto è che le nuvole sono grumi centralizzati di acqua, vapore, ghiaccio e pietre. E la nebbia sono goccioline d'acqua sparse intorno a noi nell'atmosfera.
Nel paradigma della nebbia, la maggior parte del lavoro viene svolto da queste goccioline in modo completamente autonomo o in collaborazione con altre goccioline. E si rivolgono al cloud solo quando sono veramente pressati.
Cioè, ancora una volta decentralizzazione, autonomia e, ovviamente, molti di voi capiscono già dove porterà tutto questo, perché non si può parlare di decentralizzazione senza menzionare la blockchain.
C'è chi ci crede, questi sono quelli che hanno investito nella criptovaluta. C'è chi crede ma ha paura, come me, per esempio. E c'è chi non ci crede. Qui puoi trattare diversamente. C'è la tecnologia, una nuova materia sconosciuta, ci sono problemi. Come ogni nuova tecnologia, solleva più domande che risposte.
L’hype attorno alla blockchain è comprensibile. Corsa all’oro a parte, la tecnologia stessa contiene notevoli promesse per un futuro migliore: più libertà, più autonomia, fiducia globale distribuita. Cosa non c'è da volere?
Di conseguenza, sempre più ingegneri in tutto il mondo stanno iniziando a sviluppare applicazioni decentralizzate. E questo è un potere che non può essere ignorato semplicemente dicendo: “Ahh, la blockchain è solo un database distribuito mal implementato”. O come amano dire gli scettici: “Non esistono reali applicazioni per la blockchain”. Se ci pensate, 150 anni fa si diceva la stessa cosa dell’elettricità. E in un certo senso avevano anche ragione, perché ciò che l’elettricità rende possibile oggi non era assolutamente possibile nel XIX secolo.
A proposito, chi sa che tipo di logo c'è sullo schermo? Questo è Hyperledger. Questo è un progetto sviluppato sotto gli auspici della Linux Foundation e include una serie di tecnologie blockchain. Questa è davvero la forza della nostra comunità open source.
Ingegneria del caos
Quindi, il sistema che stiamo sviluppando sta diventando sempre più complesso, sempre più caotico e sempre più adattivo. Netflix è pioniere dei sistemi di microservizi. Furono tra i primi a capirlo, svilupparono una serie di strumenti che chiamarono Simian Army, il più famoso dei quali fu . Ha definito ciò che è diventato noto come .
A proposito, mentre lavoriamo al rapporto, abbiamo anche tradotto questo testo in russo, quindi vai a , leggi, commenta, sgrida.
In breve, i principi dell’ingegneria del caos dicono quanto segue. I sistemi distribuiti complessi sono intrinsecamente imprevedibili e intrinsecamente difettosi. Gli errori sono inevitabili, il che significa che dobbiamo accettarli e lavorare con questi sistemi in un modo completamente diverso.
Noi stessi dobbiamo cercare di introdurre questi errori nei nostri sistemi di produzione per testare nei nostri sistemi questa stessa adattabilità, questa stessa capacità di auto-organizzazione, di sopravvivenza.
E questo cambia tutto. Non solo come mettiamo in produzione i sistemi, ma anche come li sviluppiamo, come li testiamo. Non esiste alcun processo di stabilizzazione o di congelamento del codice; al contrario, esiste un costante processo di destabilizzazione. Stiamo cercando di uccidere il sistema e di vederlo continuare a sopravvivere.
Protocolli di integrazione di sistemi distribuiti
Di conseguenza, ciò richiede che i nostri sistemi cambino in qualche modo. Affinché diventino più stabili, hanno bisogno di alcuni nuovi protocolli per l'interazione tra le loro parti. In modo che queste parti possano accordarsi e arrivare a una sorta di auto-organizzazione. E nascono tutti i tipi di nuovi strumenti, nuovi protocolli, che io chiamo “protocolli per l’interazione di sistemi distribuiti”.
Di cosa sto parlando? Innanzitutto, il progetto . Alcuni tentano di creare un protocollo di tracciamento distribuito generale, che è uno strumento assolutamente indispensabile per il debug di sistemi distribuiti complessi.
Ulteriore - . Diciamo che non possiamo prevedere cosa accadrà al sistema, cioè dobbiamo aumentarne l'osservabilità, l'osservabilità. Opentracing appartiene a una famiglia di strumenti che danno osservabilità ai nostri sistemi. Ma abbiamo bisogno dell’osservabilità per determinare se il sistema si comporta come ci aspettiamo oppure no. Come definiamo il comportamento atteso? Definendo una sorta di politica, un insieme di regole. Il progetto Open Policy Agent sta lavorando per definire questo insieme di regole attraverso uno spettro che va dall’accesso all’allocazione delle risorse.
Come abbiamo detto, i nostri sistemi sono sempre più guidati dagli eventi. Serverless è un ottimo esempio di sistemi guidati dagli eventi. Per poter trasferire eventi tra sistemi e tenerne traccia, abbiamo bisogno di un linguaggio comune, di un protocollo comune su come parliamo degli eventi, su come li trasmettiamo gli uni agli altri. Così si chiamava un progetto .
Il flusso costante di cambiamenti che investe i nostri sistemi, destabilizzandoli costantemente, è un flusso continuo di artefatti software. Per poter mantenere questo flusso costante di cambiamenti, abbiamo bisogno di una sorta di protocollo comune attraverso il quale possiamo parlare di cos'è un artefatto software, come viene testato, quale verifica ha superato. Così si chiamava un progetto . Cioè, un protocollo di metadati comune per gli artefatti software.
E infine, se vogliamo che i nostri sistemi siano completamente indipendenti, adattivi e auto-organizzati, dobbiamo dare loro il diritto all’autoidentificazione. Progetto chiamato Questo è esattamente ciò che fa. Anche questo è un progetto sotto gli auspici della Cloud Native Computing Foundation.
Tutti questi progetti sono giovani, hanno tutti bisogno del nostro amore, della nostra convalida. Tutto questo è open source, i nostri test, la nostra implementazione. Ci mostrano dove sta andando la tecnologia.
Ma DevOps non ha mai riguardato principalmente la tecnologia, ma ha sempre riguardato la collaborazione tra le persone. E, di conseguenza, se vogliamo che i sistemi che sviluppiamo cambino, allora dobbiamo cambiare noi stessi. In effetti, stiamo cambiando comunque; non abbiamo molta scelta.
C'è un meraviglioso La scrittrice britannica Rachel Botsman, in cui scrive dell'evoluzione della fiducia nel corso della storia umana. Dice che inizialmente, nelle società primitive, la fiducia era locale, cioè ci fidavamo solo di coloro che conoscevamo personalmente.
Poi c'è stato un periodo molto lungo, un periodo oscuro in cui la fiducia era centralizzata, in cui abbiamo cominciato a fidarci di persone che non conosciamo sulla base del fatto che apparteniamo alla stessa istituzione pubblica o statale.
E questo è ciò che vediamo nel nostro mondo moderno: la fiducia sta diventando sempre più distribuita e decentralizzata, e si basa sulla libertà dei flussi di informazioni, sulla disponibilità delle informazioni.
Se ci pensi, proprio questa accessibilità, che rende possibile questa fiducia, è ciò che tu ed io stiamo implementando. Ciò significa che sia il modo in cui collaboriamo sia il modo in cui lo facciamo devono cambiare, perché le vecchie organizzazioni IT centralizzate e gerarchiche non funzionano più. Cominciano a morire.
Fondamenti dell'organizzazione DevOps
L'organizzazione DevOps ideale del futuro è un sistema decentralizzato e adattivo composto da team autonomi, ciascuno composto da individui autonomi. Questi team sono sparsi in tutto il mondo e collaborano efficacemente tra loro utilizzando la comunicazione asincrona, utilizzando protocolli di comunicazione altamente trasparenti. Molto bello, non è vero? Un futuro molto bello.
Naturalmente, nulla di tutto ciò è possibile senza un cambiamento culturale. Dobbiamo avere leadership trasformazionale, responsabilità personale, motivazione interna.
Questa è la base delle organizzazioni DevOps: trasparenza delle informazioni, comunicazioni asincrone, leadership trasformazionale, decentralizzazione.
zapping
I sistemi di cui facciamo parte e quelli che costruiamo sono sempre più caotici, ed è difficile per noi umani far fronte a questo pensiero, è difficile rinunciare all’illusione del controllo. Cerchiamo di continuare a controllarli e questo spesso porta al burnout. Lo dico per esperienza personale, anch'io mi sono bruciato, sono stato anche disabilitato da guasti imprevisti nella produzione.
Il burnout si verifica quando cerchiamo di controllare qualcosa che è intrinsecamente incontrollabile. Quando ci esauriamo, tutto perde significato perché perdiamo la voglia di fare qualcosa di nuovo, ci mettiamo sulla difensiva e iniziamo a difendere ciò che abbiamo.
La professione di ingegnere, come spesso mi piace ricordarmi, è prima di tutto una professione creativa. Se perdiamo il desiderio di creare qualcosa, allora ci trasformiamo in cenere, ci trasformiamo in cenere. Le persone si esauriscono, intere organizzazioni si esauriscono.
Secondo me, solo accettare la forza creativa del caos, solo costruire una cooperazione secondo i suoi principi è ciò che ci aiuterà a non perdere ciò che c'è di buono nella nostra professione.
Questo è ciò che ti auguro: amare il tuo lavoro, amare ciò che facciamo. Questo mondo si nutre di informazioni, noi abbiamo l'onore di alimentarle. Quindi studiamo il caos, diventiamo caosologi, portiamo valore, creiamo qualcosa di nuovo, beh, i problemi, come abbiamo già scoperto, sono inevitabili, e quando appariranno diremo semplicemente “Ops!” E il problema è risolto.
Cos'altro oltre alla Scimmia del Caos?
In effetti, tutti questi strumenti sono così giovani. Lo stesso Netflix ha creato strumenti per se stesso. Costruisci i tuoi strumenti. Leggi i principi dell'ingegneria del caos e rispettali piuttosto che cercare di trovare altri strumenti che qualcun altro ha già costruito.
Cerca di capire come i tuoi sistemi si guastano e inizia a romperli e vedi come reggono. Questo viene prima. E puoi cercare strumenti. Ci sono tutti i tipi di progetti.
Non ho capito bene il momento in cui hai detto che il sistema non può essere semplificato semplificandone i componenti, e sono subito passato ai microservizi, che semplificano il sistema semplificando i componenti stessi e complicando le interazioni. Si tratta essenzialmente di due parti che si contraddicono a vicenda.
Esatto, i microservizi sono un argomento molto controverso in generale. In effetti, la semplificazione delle parti aumenta la flessibilità. Cosa forniscono i microservizi? Ci danno flessibilità e velocità, ma di certo non ci danno la semplicità. Aumentano la difficoltà.
Quindi, nella filosofia DevOps, i microservizi non sono una buona cosa?
Ogni bene ha un rovescio. Il vantaggio è che aumenta la flessibilità, permettendoci di apportare modifiche più velocemente, ma aumenta la complessità e quindi la fragilità dell’intero sistema.
Tuttavia, cos'è più enfasi: sulla semplificazione dell'interazione o sulla semplificazione delle parti?
L'enfasi, ovviamente, è sulla semplificazione delle interazioni, perché se la consideriamo dal punto di vista di come lavoriamo con voi, allora, prima di tutto, dobbiamo prestare attenzione alla semplificazione delle interazioni e non alla semplificazione del lavoro. di ciascuno di noi separatamente. Perché semplificare il lavoro significa trasformarsi in robot. Qui da McDonald's funziona normalmente quando hai istruzioni: qui metti l'hamburger, qui ci versi sopra la salsa. Questo non funziona affatto nel nostro lavoro creativo.
È vero che tutto quello che hai detto vive in un mondo senza concorrenza, e il caos è così gentile, e non ci sono contraddizioni in questo caos, nessuno vuole mangiare o uccidere nessuno? Come dovrebbero comportarsi la concorrenza e DevOps?
Beh, dipende di che tipo di competizione stiamo parlando. Si tratta di concorrenza sul posto di lavoro o di concorrenza tra aziende?
Sulla concorrenza dei servizi che esiste perché i servizi non sono diverse società. Stiamo creando un nuovo tipo di ambiente informativo e qualsiasi ambiente non può vivere senza concorrenza. C'è concorrenza ovunque.
Lo stesso Netflix, li prendiamo come modello. Perché hanno inventato questo? Perché avevano bisogno di essere competitivi. Questa flessibilità e velocità di movimento è proprio il requisito stesso della concorrenza; introduce il caos nei nostri sistemi. Cioè, il caos non è qualcosa che facciamo consapevolmente perché lo vogliamo, è qualcosa che accade perché il mondo lo richiede. Dobbiamo solo adattarci. E il caos è proprio il risultato della competizione.
Questo significa che il caos è l’assenza di obiettivi, per così dire? O quegli obiettivi che non vogliamo vedere? Stiamo in casa e non comprendiamo gli obiettivi degli altri. La competizione, infatti, è dovuta al fatto che abbiamo obiettivi chiari e sappiamo dove andremo a finire in ogni momento successivo. Questa, dal mio punto di vista, è l'essenza di DevOps.
Anche uno sguardo alla domanda. Penso che abbiamo tutti lo stesso obiettivo: sopravvivere e farcela
più grande piacere. E l’obiettivo competitivo di qualsiasi organizzazione è lo stesso. La sopravvivenza spesso avviene attraverso la competizione, non puoi farci niente.
La conferenza di quest'anno avrà luogo il 7 dicembre al Technopolis. Accettiamo richieste di report fino all'11 novembre. noi se vuoi parlare.
La registrazione per i partecipanti è aperta, i biglietti costano 7000 rubli. Unisciti a noi!
Fonte: habr.com