Anton Weiss, fondatorul și directorul Otomato Software, unul dintre inițiatorii și instructorii primei certificări DevOps din Israel, a vorbit la conferința de anul trecut despre teoria haosului și principiile principale ale ingineriei haosului și, de asemenea, a explicat cum funcționează organizația ideală DevOps a viitorului.
Am pregătit o versiune text a raportului.
Bună dimineața!
DevOpsDays la Moscova pentru al doilea an consecutiv, este a doua oară pe această scenă, mulți dintre voi sunteți în această cameră pentru a doua oară. Ce înseamnă? Aceasta înseamnă că mișcarea DevOps din Rusia crește, se înmulțește și, cel mai important, înseamnă că a venit momentul să vorbim despre ce este DevOps în 2018.
Ridicați mâna cine crede că DevOps este deja o profesie în 2018? Există așa ceva. Există ingineri DevOps în sală a căror descriere a postului scrie „Inginer DevOps”? Există manageri DevOps în sală? Nu există așa ceva. Arhitecți DevOps? De asemenea, nu. Insuficient. Este adevărat că nimeni nu spune că sunt inginer DevOps?
Deci majoritatea dintre voi credeți că acesta este un anti-model? Că nu ar trebui să existe o astfel de profesie? Putem gândi orice ne dorim, dar în timp ce ne gândim, industria avansează solemn la sunetul trompetei DevOps.
Cine a auzit despre un subiect nou numit DevDevOps? Aceasta este o tehnică nouă care permite o colaborare eficientă între dezvoltatori și dezvoltatori. Și nu atât de nou. Judecând după Twitter, au început deja să vorbească despre asta acum 4 ani. Și până acum, interesul pentru asta crește și crește, adică există o problemă. Problema trebuie rezolvată.
Suntem oameni creativi, nu ne odihnim doar linistiti. Spunem: DevOps nu este un cuvânt suficient de cuprinzător, îi lipsesc încă tot felul de elemente diferite, interesante. Și mergem la laboratoarele noastre secrete și începem să producem mutații interesante: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Logica este fermă, nu? Sistemul nostru de livrare nu este funcțional, sistemele noastre sunt instabile și utilizatorii noștri sunt nemulțumiți, nu avem timp să lansăm software-ul la timp, nu ne încadram în buget. Cum vom rezolva toate astea? Vom veni cu un cuvânt nou! Se va termina cu „Ops” și problema este rezolvată.
Așa că numesc această abordare - „Ops, iar problema este rezolvată”.
Toate acestea trec în fundal dacă ne amintim de ce am venit cu toate acestea. Am venit cu tot acest lucru DevOps pentru a face ca livrarea de software și propria noastră muncă în acest proces să fie cât mai nestingherite, nedureroase, eficiente și, cel mai important, cât mai plăcute.
DevOps a crescut din durere. Și ne-am săturat de suferință. Și pentru ca toate acestea să se întâmple, ne bazăm pe practici veșnic verzi: colaborare eficientă, practici de flux și, cel mai important, gândire de sistem, pentru că fără ea, DevOps nu funcționează.
Care este sistemul?
Și dacă vorbim deja despre gândirea sistemelor, să ne amintim ce este un sistem.
Dacă ești un hacker revoluționar, atunci pentru tine sistemul este clar rău. Este un nor care atârnă peste tine și te obligă să faci lucruri pe care nu vrei să le faci.
Din punctul de vedere al gândirii sistemice, un sistem este un întreg format din părți. În acest sens, fiecare dintre noi este un sistem. Organizațiile în care lucrăm sunt sisteme. Și ceea ce tu și cu mine construim se numește sistem.
Toate acestea fac parte dintr-un sistem socio-tehnologic mare. Și numai dacă înțelegem cum funcționează împreună acest sistem socio-tehnologic, abia atunci vom putea optimiza cu adevărat ceva în această chestiune.
Din perspectiva gândirii sistemice, un sistem are diverse proprietăți interesante. În primul rând, este format din părți, ceea ce înseamnă că comportamentul său depinde de comportamentul părților. În plus, toate părțile sale sunt, de asemenea, interdependente. Se dovedește că cu cât un sistem are mai multe părți, cu atât este mai dificil să înțelegeți sau să preziceți comportamentul acestuia.
Din punct de vedere comportamental, există un alt fapt interesant. Sistemul poate face ceva ce nici una dintre părțile sale individuale nu poate face.
După cum a spus Dr. Russell Ackoff (unul dintre fondatorii gândirii sistemice), acest lucru este destul de ușor de demonstrat cu un experiment de gândire. De exemplu, cine din cameră știe să scrie cod? Există o mulțime de mâini, iar acest lucru este normal, deoarece aceasta este una dintre cerințele principale pentru profesia noastră. Știi să scrii, dar pot mâinile tale să scrie cod separat de tine? Sunt oameni care vor spune: „Nu mâinile mele scriu codul, ci creierul meu scrie codul.” Poate creierul tău să scrie cod separat de tine? Ei bine, probabil că nu.
Creierul este o mașină uimitoare, nici măcar nu știm 10% cum funcționează acolo, dar nu poate funcționa separat de sistemul care este corpul nostru. Și asta e ușor de demonstrat: deschide-ți craniul, scoate-ți creierul, pune-l în fața computerului, lasă-l să încerce să scrie ceva simplu. „Bună, lume” în Python, de exemplu.
Dacă un sistem poate face ceva ce nici una dintre părțile sale nu poate face separat, atunci aceasta înseamnă că comportamentul său nu este determinat de comportamentul părților sale. Atunci de ce este determinat? Este determinată de interacțiunea dintre aceste părți. Și, în consecință, cu cât mai multe părți, cu cât interacțiunile sunt mai complexe, cu atât este mai dificil să înțelegeți și să preziceți comportamentul sistemului. Și acest lucru face ca un astfel de sistem să fie haotic, deoarece orice schimbare, chiar și cea mai nesemnificativă, invizibilă în orice parte a sistemului poate duce la rezultate complet imprevizibile.
Această sensibilitate la condițiile inițiale a fost descoperită și studiată pentru prima dată de meteorologul american Ed Lorenz. Ulterior, a fost numit „efectul fluture” și a condus la dezvoltarea unei mișcări de gândire științifică numită „teoria haosului”. Această teorie a devenit una dintre principalele schimbări de paradigmă în știința secolului XX.
Teoria haosului
Oamenii care studiază haosul se numesc haosologi.
De fapt, motivul acestui raport a fost că, lucrând cu sisteme complexe distribuite și cu mari organizații internaționale, la un moment dat mi-am dat seama că așa simt. Sunt haosolog. Acesta este practic un mod inteligent de a spune: „Nu înțeleg ce se întâmplă aici și nu știu ce să fac în privința asta”.
Cred că și mulți dintre voi simțiți adesea așa, așa că sunteți și haosologi. Vă invit la breasla haosologilor. Sistemele pe care voi și cu mine, dragi colegi haosologi, le vom studia se numesc „sisteme adaptative complexe”.
Ce este adaptabilitatea? Adaptabilitatea înseamnă că comportamentul individual și colectiv al părților dintr-un astfel de sistem adaptativ se schimbă și se auto-organizează, răspunzând la evenimente sau lanțuri de micro-evenimente din sistem. Adică sistemul se adaptează la schimbări prin auto-organizare. Iar această capacitate de autoorganizare se bazează pe cooperarea voluntară, complet descentralizată a agenților autonomi liberi.
O altă proprietate interesantă a unor astfel de sisteme este că sunt scalabile liber. Ceea ce, fără îndoială, ar trebui să ne intereseze, ca haosologi-ingineri. Deci, dacă am spune că comportamentul unui sistem complex este determinat de interacțiunea părților sale, atunci ce ar trebui să ne intereseze? Interacţiune.
Mai sunt două descoperiri interesante.
În primul rând, înțelegem că un sistem complex nu poate fi simplificat prin simplificarea părților sale. În al doilea rând, singura modalitate de a simplifica un sistem complex este prin simplificarea interacțiunilor dintre părțile sale.
Cum interacționăm? Tu și cu mine suntem toți părți ale unui sistem informațional mare numit societate umană. Interacționăm printr-un limbaj comun, dacă îl avem, dacă îl găsim.
Dar limbajul în sine este un sistem adaptativ complex. În consecință, pentru a interacționa mai eficient și mai simplu, trebuie să creăm un fel de protocoale. Adică o secvență de simboluri și acțiuni care vor face schimbul de informații între noi mai simplu, mai previzibil, mai ușor de înțeles.
Vreau să spun că tendințele spre complexitate, spre adaptabilitate, spre descentralizare, spre haos pot fi urmărite în orice. Și în sistemele pe care tu și cu mine le construim și în acele sisteme din care facem parte.
Și pentru a nu fi neîntemeiat, să vedem cum se schimbă sistemele pe care le creăm.
Așteptați acest cuvânt, am înțeles. Suntem la o conferință DevOps, astăzi acest cuvânt se va auzi de aproximativ o sută de mii de ori și apoi îl vom visa noaptea.
Microserviciile sunt prima arhitectură software care a apărut ca reacție la practicile DevOps, care este concepută pentru a face sistemele noastre mai flexibile, mai scalabile și pentru a asigura livrarea continuă. Cum face ea asta? Prin reducerea volumului de servicii, reducerea sferei problemelor pe care aceste servicii le procesează, reducerea timpului de livrare. Adică, reducem și simplificăm părți ale sistemului, le creștem numărul și, în consecință, complexitatea interacțiunilor dintre aceste părți crește invariabil, adică apar noi probleme pe care trebuie să le rezolvăm.
Microserviciile nu sunt sfârșitul, microserviciile sunt, în general, deja ieri, pentru că vine Serverless. Toate serverele au ars, fără servere, fără sisteme de operare, doar cod executabil pur. Configurațiile sunt separate, stările sunt separate, totul este controlat de evenimente. Frumusețe, curățenie, liniște, fără evenimente, nu se întâmplă nimic, ordine completă.
Unde este complexitatea? Dificultatea, desigur, este în interacțiuni. Cât de mult poate face o singură funcție? Cum interacționează cu alte funcții? Cozi de mesaje, baze de date, echilibrare. Cum să recreați un eveniment când a avut loc o defecțiune? O mulțime de întrebări și puține răspunsuri.
Microservicii și Serverless sunt ceea ce noi hipsterii geek numim Cloud Native. Totul tine de nor. Dar cloud-ul este, de asemenea, limitat în mod inerent în scalabilitatea sa. Suntem obișnuiți să ne gândim la el ca la un sistem distribuit. De fapt, unde locuiesc serverele furnizorilor de cloud? În centrele de date. Adică avem aici un fel de model centralizat, foarte limitat, distribuit.
Astăzi înțelegem că Internetul Lucrurilor nu mai este doar cuvinte mari pe care, chiar și conform previziunilor modeste, miliarde de dispozitive conectate la Internet ne așteaptă în următorii cinci-zece ani. O cantitate imensă de date utile și inutile care vor fi îmbinate în cloud și încărcate din cloud.
Norul nu va dura, așa că vorbim din ce în ce mai mult despre ceva numit edge computing. Sau îmi place și definiția minunată a „fog computing”. Este învăluită în misticismul romantismului și al misterului.
Calcularea ceață. Ideea este că norii sunt pâlcuri centralizate de apă, abur, gheață și pietre. Iar ceața sunt picături de apă care sunt împrăștiate în jurul nostru în atmosferă.
În paradigma ceață, cea mai mare parte a muncii este realizată de aceste picături complet autonom sau în colaborare cu alte picături. Și se îndreaptă către nor numai atunci când sunt cu adevărat presați.
Adică, din nou, descentralizare, autonomie și, bineînțeles, mulți dintre voi înțelegeți deja încotro merg toate acestea, pentru că nu puteți vorbi despre descentralizare fără a menționa blockchain-ul.
Sunt cei care cred, aceștia sunt cei care au investit în criptomonedă. Sunt cei care cred dar le este frică, ca mine, de exemplu. Și sunt cei care nu cred. Aici poți trata diferit. Există tehnologie, o nouă chestiune necunoscută, există probleme. Ca orice tehnologie nouă, ridică mai multe întrebări decât răspunde.
Exagerarea în jurul blockchain-ului este de înțeles. Lăsând deoparte goana aurului, tehnologia în sine deține promisiuni remarcabile pentru un viitor mai luminos: mai multă libertate, mai multă autonomie, încredere globală distribuită. Ce să nu vrei?
În consecință, din ce în ce mai mulți ingineri din întreaga lume încep să dezvolte aplicații descentralizate. Și aceasta este o putere care nu poate fi respinsă spunând pur și simplu: „Ahh, blockchain-ul este doar o bază de date distribuită prost implementată”. Sau cum le place să spună scepticii: „Nu există aplicații reale pentru blockchain”. Dacă te gândești bine, acum 150 de ani spuneau același lucru despre electricitate. Și chiar au avut dreptate în anumite privințe, pentru că ceea ce face posibil electricitatea astăzi nu era în niciun caz posibil în secolul al XIX-lea.
Apropo, cine știe ce fel de logo este pe ecran? Acesta este Hyperledger. Acesta este un proiect care este dezvoltat sub auspiciile Fundației Linux și include un set de tehnologii blockchain. Acesta este cu adevărat punctul forte al comunității noastre open source.
Ingineria haosului
Deci, sistemul pe care îl dezvoltăm devine din ce în ce mai complex, din ce în ce mai haotic și din ce în ce mai adaptabil. Netflix sunt pionierii sistemelor de microservicii. Au fost printre primii care au înțeles acest lucru, au dezvoltat un set de instrumente pe care le-au numit Armata Simiană, dintre care cel mai faimos a fost . El a definit ceea ce a devenit cunoscut ca .
Apropo, în procesul de lucru la raport, am tradus chiar și acest text în rusă, așa că accesați , citește, comentează, certa.
Pe scurt, principiile ingineriei haosului spun următoarele. Sistemele complexe distribuite sunt în mod inerent imprevizibile și în mod inerent cu erori. Erorile sunt inevitabile, ceea ce înseamnă că trebuie să acceptăm aceste erori și să lucrăm cu aceste sisteme într-un mod complet diferit.
Noi înșine trebuie să încercăm să introducem aceste erori în sistemele noastre de producție pentru a ne testa sistemele pentru aceeași adaptabilitate, chiar această capacitate de auto-organizare, de supraviețuire.
Și asta schimbă totul. Nu doar modul în care lansăm sistemele în producție, ci și cum le dezvoltăm, cum le testăm. Nu există un proces de stabilizare sau înghețare a codului, dimpotrivă, există un proces constant de destabilizare. Încercăm să omorâm sistemul și să-l vedem în continuare să supraviețuiască.
Protocoale de integrare a sistemelor distribuite
În consecință, acest lucru necesită ca sistemele noastre să se schimbe cumva. Pentru ca ei să devină mai stabili, au nevoie de niște protocoale noi de interacțiune între părțile lor. Pentru ca aceste părți să fie de acord și să ajungă la un fel de auto-organizare. Și apar tot felul de instrumente noi, protocoale noi, pe care le numesc „protocoale pentru interacțiunea sistemelor distribuite”.
Despre ce vorbesc? În primul rând, proiectul . Unii încearcă să creeze un protocol general de urmărire distribuită, care este un instrument absolut indispensabil pentru depanarea sistemelor distribuite complexe.
Mai departe - . Spunem că nu putem prezice ce se va întâmpla cu sistemul, adică trebuie să creștem observabilitatea, observabilitatea acestuia. Opentracing aparține unei familii de instrumente care oferă observabilitate sistemelor noastre. Dar avem nevoie de observabilitate pentru a determina dacă sistemul se comportă așa cum ne așteptăm sau nu. Cum definim comportamentul așteptat? Prin definirea unui fel de politică, a unui set de reguli. Proiectul Open Policy Agent lucrează la definirea acestui set de reguli într-un spectru care variază de la acces la alocarea resurselor.
După cum am spus, sistemele noastre sunt din ce în ce mai mult bazate pe evenimente. Serverless este un exemplu excelent de sisteme bazate pe evenimente. Pentru a transfera evenimente între sisteme și a le urmări, avem nevoie de un limbaj comun, un protocol comun pentru modul în care vorbim despre evenimente, cum le transmitem unul altuia. Așa se numește un proiect .
Fluxul constant de schimbări care împrăștie sistemele noastre, destabilizandu-le constant, este un flux continuu de artefacte software. Pentru a menține acest flux constant de schimbări, avem nevoie de un fel de protocol comun prin care să putem vorbi despre ce este un artefact software, cum este testat, ce verificare a trecut. Așa se numește un proiect . Adică, un protocol comun de metadate pentru artefacte software.
Și, în sfârșit, dacă dorim ca sistemele noastre să fie complet independente, adaptative și auto-organizate, trebuie să le acordăm dreptul la autoidentificare. Proiect numit Este exact ceea ce face el. Acesta este, de asemenea, un proiect sub auspiciile Cloud Native Computing Foundation.
Toate aceste proiecte sunt tinere, toate au nevoie de dragostea noastră, de validarea noastră. Toate acestea sunt open source, testarea noastră, implementarea noastră. Ele ne arată încotro se îndreaptă tehnologia.
Dar DevOps nu a fost niciodată în primul rând despre tehnologie, a fost întotdeauna despre colaborarea între oameni. Și, în consecință, dacă dorim ca sistemele pe care le dezvoltăm să se schimbe, atunci trebuie să ne schimbăm noi înșine. De fapt, oricum ne schimbăm, nu avem de ales.
Există o minunată Scriitoarea britanică Rachel Botsman, în care scrie despre evoluția încrederii de-a lungul istoriei omenirii. Ea spune că inițial, în societățile primitive, încrederea era locală, adică aveam încredere doar în cei pe care îi cunoaștem personal.
Apoi a fost o perioadă foarte lungă - o perioadă întunecată în care încrederea a fost centralizată, când am început să avem încredere în oameni pe care nu îi cunoaștem pe baza faptului că aparținem aceleiași instituții publice sau de stat.
Și asta vedem în lumea noastră modernă: încrederea devine din ce în ce mai distribuită și descentralizată și se bazează pe libertatea fluxurilor informaționale, pe disponibilitatea informațiilor.
Dacă te gândești bine, tocmai această accesibilitate, care face posibilă această încredere, este ceea ce tu și cu mine implementăm. Aceasta înseamnă că atât modul în care colaborăm, cât și modul în care o facem trebuie să se schimbe, deoarece organizațiile IT centralizate, ierarhice de altădată nu mai funcționează. Încep să moară.
Fundamentele organizației DevOps
Organizația DevOps ideală a viitorului este un sistem descentralizat, adaptiv, compus din echipe autonome, fiecare constând din indivizi autonomi. Aceste echipe sunt împrăștiate în întreaga lume, colaborând eficient între ele folosind comunicarea asincronă, folosind protocoale de comunicare extrem de transparente. Foarte frumos, nu-i așa? Un viitor foarte frumos.
Desigur, nimic din toate acestea nu este posibil fără schimbare culturală. Trebuie să avem leadership transformațional, responsabilitate personală, motivație internă.
Aceasta este baza organizațiilor DevOps: transparență informațională, comunicații asincrone, leadership transformațional, descentralizare.
Ars
Sistemele din care facem parte și cele pe care le construim sunt din ce în ce mai haotice, iar nouă, oamenii, ne este greu să facem față acestui gând, este greu să renunțăm la iluzia controlului. Încercăm să le controlăm în continuare, iar acest lucru duce adesea la burnout. Spun asta din proprie experiență, m-am și ars, am fost și dezactivat de eșecuri neprevăzute în producție.
Burnout-ul apare atunci când încercăm să controlăm ceva care este în mod inerent incontrolabil. Când ne epuizăm, totul își pierde sensul pentru că ne pierdem dorința de a face ceva nou, ne luăm defensivi și începem să apărăm ceea ce avem.
Profesia de inginer, așa cum îmi place adesea să-mi reamintesc, este în primul rând o profesie creativă. Dacă ne pierdem dorința de a crea ceva, atunci ne transformăm în cenușă, ne transformăm în cenușă. Oamenii se consumă, organizații întregi se epuizează.
În opinia mea, doar acceptarea puterii creatoare a haosului, doar construirea cooperării după principiile sale este ceea ce ne va ajuta să nu pierdem ceea ce este bun în profesia noastră.
Iti doresc asta: sa iti iubesti meseria, sa iubesti ceea ce facem. Această lume se hrănește cu informație, avem onoarea să o hrănim. Așa că să studiem haosul, să fim haosologi, să aducem valoare, să creăm ceva nou, ei bine, problemele, așa cum am aflat deja, sunt inevitabile, iar când vor apărea, vom spune pur și simplu „Ops!” și problema este rezolvată.
Ce altceva decât Chaos Monkey?
De fapt, toate aceste instrumente sunt atât de tinere. Aceeași Netflix și-au construit instrumente pentru ei înșiși. Construiește-ți propriile instrumente. Citiți principiile ingineriei haosului și respectați aceste principii, mai degrabă decât să încercați să găsiți alte instrumente pe care altcineva le-a construit deja.
Încercați să înțelegeți cum se defectează sistemele dvs. și începeți să le distrugeți și vedeți cum rezistă. Acesta este primul. Și poți căuta unelte. Sunt tot felul de proiecte.
Nu prea am înțeles momentul în care ați spus că sistemul nu poate fi simplificat prin simplificarea componentelor sale și am trecut imediat la microservicii, care simplifică sistemul simplificând componentele în sine și complicând interacțiunile. Acestea sunt în esență două părți care se contrazic.
Așa e, microserviciile sunt un subiect foarte controversat în general. De fapt, simplificarea pieselor crește flexibilitatea. Ce oferă microserviciile? Ele ne oferă flexibilitate și viteză, dar cu siguranță nu ne oferă simplitate. Ele cresc dificultatea.
Deci, în filosofia DevOps, microserviciile nu sunt un lucru atât de bun?
Orice bun are un revers. Beneficiul este că mărește flexibilitatea, permițându-ne să facem schimbări mai rapid, dar crește complexitatea și deci fragilitatea întregului sistem.
Totuși, ce se pune mai mult accent: pe simplificarea interacțiunii sau pe simplificarea părților?
Accentul se pune, desigur, pe simplificarea interacțiunilor, pentru că dacă ne uităm la asta din punctul de vedere al modului în care lucrăm cu tine, atunci, în primul rând, trebuie să fim atenți la simplificarea interacțiunilor, și nu la simplificarea muncii. a fiecăruia dintre noi separat. Pentru că simplificarea muncii înseamnă transformarea în roboți. Aici la McDonald's merge normal cand ai instructiuni: aici pui burgerul, aici toarni sosul peste el. Acest lucru nu funcționează deloc în munca noastră de creație.
Este adevărat că tot ce ai spus trăiește într-o lume fără concurență, iar haosul de acolo este atât de amabil și nu există contradicții în acest haos, nimeni nu vrea să mănânce sau să omoare pe nimeni? Cum ar trebui să meargă concurența și DevOps?
Ei bine, depinde de ce fel de competiție vorbim. Este vorba despre concurență la locul de muncă sau despre competiție între companii?
Despre concurența serviciilor care există pentru că serviciile nu sunt mai multe companii. Creăm un nou tip de mediu informațional și orice mediu nu poate trăi fără concurență. Peste tot există concurență.
Același Netflix, îi luăm drept model. De ce au venit cu asta? Pentru că trebuiau să fie competitivi. Această flexibilitate și viteză de mișcare este tocmai cerința foarte competitivă ea introduce haos în sistemele noastre. Adică, haosul nu este ceva ce facem în mod conștient pentru că ne dorim, este ceva care se întâmplă pentru că lumea o cere. Trebuie doar să ne adaptăm. Și haosul, este tocmai rezultatul competiției.
Aceasta înseamnă că haosul este absența obiectivelor, așa cum ar fi? Sau acele obiective pe care nu vrem să le vedem? Suntem în casă și nu înțelegem scopurile celorlalți. Concurența, de fapt, se datorează faptului că avem obiective clare și știm unde vom ajunge în fiecare moment următor. Aceasta este, din punctul meu de vedere, esența DevOps.
De asemenea, o privire la întrebare. Cred că toți avem același scop: să supraviețuim și să o facem
cea mai mare plăcere. Și obiectivul competitiv al oricărei organizații este același. Supraviețuirea are loc adesea prin competiție, nu poți face nimic în acest sens.
Conferința de anul acesta va avea loc pe 7 decembrie la Technopolis. Acceptăm cereri pentru rapoarte până pe 11 noiembrie. noi dacă vrei să vorbești.
Înregistrările pentru participanți sunt deschise, biletele costă 7000 de ruble. Alăturaţi-ne!
Sursa: www.habr.com