Fondatorul și directorul «Otomato Software», unul dintre inițiatorii și instructorii primei certificări DevOps din Israel, Anton Vais, a vorbit la evenimentul de anul trecut despre teoria haosului și principalele principii ale ingineriei haosului, precum și despre cum este organizată organizația ideală DevOps a viitorului.
Am pregătit o versiune textuală a raportului.
Bună dimineața!
DevOpsDays se desfășoară la Moscova pentru al doilea an consecutiv, iar eu sunt din nou pe această scenă, mulți dintre voi sunt a doua oară în această sală. Ce înseamnă asta? Înseamnă că mișcarea DevOps din Rusia crește, se multipli-că și, mai presus de toate, înseamnă că a venit timpul să discutăm despre ce înseamnă DevOps în 2018.
Ridicați mâinile cei care cred că în 2018 DevOps este deja o profesie? Există astfel de persoane. Există în sală ingineri DevOps ai căror descrieri ale locurilor de muncă includ «inginer DevOps»? Există în sală manageri DevOps? Nu sunt. Arhitecți DevOps? De asemenea, nu sunt. Prea puțini. Nu există nimeni care să aibă scris că este inginer DevOps?
Asta înseamnă că majoritatea dintre voi cred că acesta este un anti-tipar? Că o astfel de profesie nu ar trebui să existe? Putem gândi orice, dar în timp ce gândim, industria avansează solemn sub sunetele trompetei DevOps.
Cine a auzit despre o nouă temă numită DevDevOps? Este o nouă metodologie care permite o colaborare eficientă între dezvoltatori și specialisti DevOps. De fapt, nu este așa de nouă. Judecând după Twitter, acum 4 ani au început deja discuțiile despre aceasta. Și până acum interesul pentru acest subiect continuă să crească, deci problema există. Trebuie rezolvată problema.
Noi suntem oameni creativi, nu ne oprim atât de ușor. Spunem: DevOps este un termen care nu acoperă totul, lipsește o varietate de elemente interesante. Și ne îndreptăm spre laboratoarele noastre secrete și începem să generăm mutații Curioase: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Logica este clară, nu? Sistemul nostru de livrare nu este funcțional, sistemele noastre sunt instabile și utilizatorii sunt nemulțumiți, nu reușim să lansăm software-ul la timp, nu ne încadrăm în buget. Cum vom rezolva toate acestea? Vom inventa un nou cuvânt! Va termina în „Ops” și problema este rezolvată.
Așa numesc eu această abordare — «Ops, și problema este rezolvată».
Toate acestea se estompează în fundal atunci când ne amintim de ce am creat tot acest lucru. Am conceput DevOps pentru a face livrarea de software și munca noastră în acest proces cât mai fluentă, fără dureri, eficientă și, mai ales, plăcută.
DevOps a crescut din suferință. Și ne-am săturat să suferim. Pentru ca toate acestea să devină realitate, ne bazăm pe practici durabile: colaborare eficientă, practici de flux și, cel mai important, gândire sistemică, deoarece fără aceasta, DevOps nu funcționează.
Ce este un sistem?
Și dacă tot am vorbit despre gândirea sistemică, să ne amintim ce înseamnă un sistem.
Dacă ești un hacker revoluționar, atunci pentru tine un sistem este un rău absolut. Este un nor care se abate asupra ta și te obligă să faci lucruri pe care nu vrei să le faci.
Din perspectiva gândirii sistemice, un sistem este un întreg care este compus din părți. În acest sens, fiecare dintre noi este un sistem. Organizațiile în care lucrăm sunt sisteme. Iar ceea ce construim împreună se numește sistem.
Toate acestea sunt parte dintr-un mare sistem sociotehnologic. Și doar dacă înțelegem cum funcționează împreună acest sistem sociotehnologic, abia atunci putem să optimizăm cu adevărat ceva în această privință.
Din perspectiva gândirii sistemice, sistemul are diverse proprietăți interesante. În primul rând, acesta este compus din părți, ceea ce înseamnă că comportamentul său depinde de comportamentul părților. În același timp, toate părțile sale sunt interdependente. Așadar, cu cât un sistem are mai multe părți, cu atât mai dificil este să înțelegem sau să prezicem comportamentul său.
Din perspectiva comportamentului, există un alt aspect interesant. Un sistem poate face ceva ce niciuna dintre părțile sale individuale nu poate face.
Așa cum spunea doctorul Russell Ackoff (unul dintre fondatorii gândirii sistemice), este destul de ușor să dovedim acest lucru printr-un experiment mental. De exemplu, cine din sală știe să scrie cod? Multe mâini se ridică, și aceasta este normal, deoarece este una dintre cerințele de bază ale profesiei noastre. Tu știi să scrii, iar mâinile tale pot scrie cod separat de tine? Există oameni care ar spune: „Mâinile mele nu scriu cod, creierul meu scrie cod”. Și poate creierul să scrie cod separat de tine? Probabil că nu.
Creierul este o mașină uimitoare; nici măcar 10% din ceea ce se întâmplă acolo nu-l cunoaștem. Totuși, el nu poate funcționa separat de sistemul din care face parte, adică organismul nostru. Și este ușor de demonstrat: deschide-ți craniul, scoate creierul, așază-l în fața unui calculator și lasă-l să încerce să scrie ceva simplu. „Hello, world” în Python, de exemplu.
Dacă un sistem poate realiza ceva ce niciuna dintre părțile sale nu ar putea face separat, atunci comportamentul său nu este determinat de comportamentul părților sale. Atunci ce îl determină? Se determină prin interacțiunile dintre aceste părți. Așadar, cu cât sunt mai multe părți, cu atât interacțiunile devin mai complexe, iar înțelegerea și prezicerea comportamentului sistemului sunt mai dificile. Aceasta face ca sistemul să fie haotic, deoarece chiar și cea mai mică modificare, invizibilă ochiului, în oricare dintre părțile sistemului poate conduce la rezultate complet imprevizibile.
Această sensibilitate la condițiile inițiale a fost descoperită și studiată pentru prima dată de meteorologul american Edward Lorenz. Ulterior, a primit denumirea de „efectul fluturelui” și a dus la dezvoltarea unei direcții în gândirea științifică numită „teoria haosului”. Această teorie a devenit una dintre schimbările de paradigmă fundamentale în știință în secolul XX.
Teoria haosului
Persoanele care se ocupă cu studiul haosului se numesc haosologi.
De fapt, motivul acestui raport a fost că, lucrând cu sisteme complexe distribuite și mari organizații internaționale, la un moment dat am realizat că așa mă simt eu. Eu sunt haosolog. Este, în general, o modalitate ingenioasă de a spune: „Nu înțeleg ce se întâmplă aici și nu știu ce să fac cu asta”.
Cred că mulți dintre voi se simt la fel de des, așa că sunteți și voi haosologi. Vă invit în guildiha haosologilor. Sistemele pe care noi, 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 adaptabil se schimbă și se autoorganizează, reacționând la evenimente sau lanțuri de microevenimente în sistem. Cu alte cuvinte, sistemul se adaptează la schimbări prin autoorganizare. Iar această capacitate de autoorganizare se bazează pe colaborarea voluntară, complet descentralizată a agenților autonomi liberi.
O altă proprietate interesantă a acestor sisteme este că sunt liber scalabile. Ce ne-ar trebui să ne intereseze ca ingineri ai haosului? Ei bine, dacă am spus că comportamentul unui sistem complex este determinat de interacțiunea părților sale, ce ar trebui să ne intereseze? Interacțiunea.
Mai există încă două concluzii 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? Noi toți suntem părți ale unei mari sisteme informaționale, care se numește societate umană. Interacționăm prin intermediul unui limbaj comun, dacă avem unul, dacă îl găsim.
Însă limbajul în sine este un sistem complex adaptabil. Prin urmare, pentru a interacționa mai eficient și mai simplu, este necesară crearea unor protocoale. Adică, o secvență de simboluri și acțiuni care să facă schimbul de informații între noi mai simplu, mai previzibil, mai clar.
Vreau să spun că tendințele de complexificare, adaptabilitate, descentralizare și haoticitate sunt prezente în tot. Atât în sistemele pe care le construim noi, cât și în sistemele de care suntem parte.
Și pentru a nu fi doar vorbe în vânt, haideți să ne uităm cum se transformă acele sisteme pe care le creăm.
Înțeleg că ați așteptat această vorbă. Suntem la conferința DevOps, astăzi acest cuvânt va fi pronunțat de vreo o sută de mii de ori și apoi ne va apărea în vise noaptea.
Microserviciile sunt prima arhitectură software care a apărut ca o reacție la practicile DevOps, având scopul de a face sistemele noastre mai flexibile, mai scalabile și de a asigura livrarea continuă. Cum reușește să facă acest lucru? Prin reducerea volumului de servicii, micșorarea limitelor problemelor pe care aceste servicii le gestionat și scurtarea timpului de livrare. Asta înseamnă că reducem și simplificăm părțile sistemului, mărind în același timp numărul acestora; astfel, complexitatea interacțiunilor dintre aceste părți crește inevitabil, generând noi probleme pe care trebuie să le rezolvăm.
Microserviciile încă nu sunt sfârșitul. De fapt, microserviciile sunt deja un concept depășit, deoarece ne așteptăm la sosirea Serverless. Toate serverele s-au ars; nu mai există servere, nu mai există sisteme de operare, doar cod executabil pur. Configurațiile sunt separate, stările sunt separate, totul este gestionat prin evenimente. Frumusețe, curățenie, liniște; nu există evenimente, nimic nu se întâmplă, totul este în ordinea corespunzătoare.
Unde este complexitatea? Complexitatea, desigur, constă în interacțiuni. Cât de mult poate face o funcție singură? Cum interacționează cu alte funcții? Cozi de mesaje, baze de date, balance-uri de sarcină. Cum putem recrea un eveniment atunci când apare o defecțiune? O mulțime de întrebări și câteva răspunsuri.
Microserviciile și Serverless sunt tot ceea ce noi, hipsterii tehnologici, numim Cloud Native. Totul se referă la cloud. Dar cloud-ul, în esența sa, este de asemenea limitat în scalabilitate. Ne-am obișnuit să-l considerăm un sistem distribuit. De fapt, unde își desfășoară activitatea serverele furnizorilor de cloud? În centre de date. Asta înseamnă că avem aici un model distribuit, centralizat și foarte limitat.
Astăzi înțelegem că Internet of Things (IoT) nu este doar un cuvânt la modă, ci conform estimărilor rezervate, în următorii cinci-zece ani ne așteaptă miliarde de dispozitive conectate la internet. O cantitate enormă de date utile și inutile care vor curge spre cloud și vor fi transferate din cloud.
Cloud-ul nu va face față, de aceea tot mai mult vorbim despre ceea ce se numește „calcul la margine”. Sau îmi place să definesc frumos „fog computing”. Este o definiție umbrită de misticismul romantic și de mister.
Computația în ceață se referă la faptul că norii sunt aglomerări centralizate de apă, abur, gheață și rocă. Iar ceața este alcătuită din picături de apă dispersate în atmosfera noastră.
În paradigma ceață, cea mai mare parte a muncii este realizată de aceste picături în mod autonom sau în colaborare cu alte picături. Ele apelează la nor doar atunci când este cu adevărat nevoie.
Deci, din nou, este vorba de descentralizare, autonomie și, bineînțeles, mulți dintre voi deja înțeleg încotro se îndreaptă toate aceste lucruri, deoarece nu poți vorbi despre descentralizare fără a menționa blockchain-ul.
Există oameni care cred în aceste lucruri, aceștia fiind cei care au investit în criptomonedă. Există cei care cred, dar se tem, ca mine, de exemplu. Iar alții nu cred. Se poate avea o viziune diferită asupra acestei situații. Există o tehnologie, un domeniu nou și confuz, există probleme. Asemenea oricărei noi tehnologii, aceasta ridică mai multe întrebări decât răspunsuri.
Hype-ul din jurul blockchain-ului este destul de clar. Chiar și dacă lăsăm la o parte goana după aur, tehnologia în sine oferă promisiuni extraordinare pentru un viitor strălucit: mai multă libertate, mai multă autonomie, încredere globală distribuită. Ce nu ți-ai dori?
Prin urmare, tot mai mulți ingineri din întreaga lume încep să dezvolte aplicații descentralizate. Și aceasta este o forță de care nu poți scăpa spunând pur și simplu: „Aaa, blockchain-ul este doar o bază de date distribuită prost implementată”. Sau cum îi place scepticilor să spună: „Nu există aplicații reale pentru blockchain”. Gândindu-ne la asta, cu 150 de ani în urmă spuneau același lucru despre electricitate. Și în unele privințe aveau dreptate, deoarece ceea ce electricitatea face acum, în secolul 19 era complet imposibil.
Apropo, cine știe ce logo apare pe ecran? Aceasta este Hyperledger. Este un proiect dezvoltat sub egida The Linux Foundation, care include un set de tehnologii blockchain. Aceasta este cu adevărat forța comunității noastre de cod deschis.
Ingineria haotică
Așadar, sistemul pe care îl dezvoltăm devine tot mai complex, tot mai haotic, tot mai adaptabil. Netflix a fost pionier în sistemele microserviciu. Au fost printre primii care au înțeles acest lucru, dezvoltând un set de instrumente numit Simian Army, cel mai cunoscut dintre ele fiind . El a definit ceea ce a devenit cunoscut sub numele de .
De fapt, în timpul lucrului la raport, am tradus acest text în limba rusă, așa că vizitați , citiți, comentați, criticiți.
În esență, principiile ingineriei haosului spun următoarele. Sistemele distribuite complexe sunt, prin natura lor, imprevizibile și au 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.
Trebuie să încercăm să introducem aceste erori în sistemele noastre de producție pentru a le testa adaptabilitatea, capacitatea de auto-organizare și supraviețuire.
Și asta schimbă totul. Nu doar modul în care lansăm sistemul în producție, ci și modul în care le dezvoltăm și le testăm. Nu există niciun proces de stabilizare sau de înghețare a codului, dimpotrivă, există un proces constant de destabilizare. Încercăm să distrugem sistemul și să vedem că el continuă să supraviețuiască.
Protocoalele de integrare a sistemelor distribuite
În consecință, acest lucru necesită ca sistemele noastre să se schimbe într-un fel. Pentru a deveni mai rezistente, au nevoie de noi protocoale de interacțiune între părțile lor. Astfel, aceste părți pot ajunge la un acord și pot realiza o auto-organizare. Apar tot felul de instrumente noi, protocoale noi, pe care eu le numesc «protocoale de interacțiune a sistemelor distribuite».
Despre ce vorbesc? În primul rând, proiectul . O încercare de a crea un protocol comun 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, deci este necesar să-i creștem observabilitatea. Opentracing face parte din familia 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 putem determina comportamentul așteptat? Prin definirea unei politici, a unui set de reguli. Proiectul Open Policy Agent se ocupă cu definirea acestui set de reguli pe o gamă largă: de la acces până la plasarea resurselor.
Așa cum am spus, sistemele noastre devin din ce în ce mai gestionate pe baza evenimentelor. Serverless este un exemplu remarcabil de sisteme gestionate pe baza evenimentelor. Pentru a putea transmite evenimente între sisteme și a le urmări, avem nevoie de un limbaj comun, un protocol comun pentru modul în care discutăm despre evenimente, cum le transmitem între noi. Acest lucru este gestionat de proiectul numit .
Fluxul continuu de modificări care inundă sistemele noastre le destabilizează constant, acesta este un flux perpetuu de artefacte software. Pentru a putea susține acest flux constant de modificări, avem nevoie de un protocol comun prin care să putem discuta despre ce este un artefact software, cum este verificat, ce validare a trecut. Acest lucru este gestionat de proiectul numit . Deci, un protocol comun de metadate pentru artefactele software.
Și, în cele din urmă, dacă vrem ca sistemele noastre să fie complet autonome, adaptive, auto-organizate, trebuie să le oferim dreptul la autoidentificare. Proiectul numit se ocupă exact de acest lucru. Acesta este, de asemenea, un proiect sub egida Cloud Native Computing Foundation.
Toate aceste proiecte sunt tinere, au nevoie de dragostea și validarea noastră. Toate sunt cod deschis, testarea noastră, implementarea noastră. Ele ne arată în ce direcție se îndreaptă tehnologia.
Dar DevOps nu a fost niciodată înainte de tehnologie, în primul rând a fost întotdeauna despre colaborarea între oameni. Prin urmare, dacă dorim ca sistemele pe care le dezvoltăm să se schimbe, atunci trebuie să ne schimbăm și noi. De fapt, se pare că ne schimbăm oricum, nu avem o alegere în acest sens.
Există o minunată scriere a autoarei britanice Rachel Botsman, în care vorbește despre evoluția încrederii de-a lungul istoriei umane. Ea spune că, de la început, în societățile primitive, încrederea era locală, adică ne încredeam doar în aceia pe care îi cunoșteam personal.
Apoi a fost o perioadă foarte lungă – o epocă întunecată, când încrederea era centralizată, când am început să ne încredem în oameni pe care nu-i cunoaștem pe baza faptului că ne aparținem unui anumit institut social sau de stat.
Și iată ce vedem în lumea noastră modernă: încrederea devine din ce în ce mai distribuită și descentralizată, bazându-se pe libertatea fluxurilor informaționale și pe accesibilitatea informației.
Dacă ne gândim bine, această accesibilitate, care face posibilă această încredere, o realizăm noi înșine. Asta înseamnă că trebuie să se schimbe atât modul în care colaborăm, cât și modul în care facem acest lucru, deoarece organizațiile IT centralizate și ierarhice de odinioară încetează să funcționeze. Ele încep să dispară.
Fundamentele organizațiilor DevOps
Organizația DevOps ideală a viitorului este un sistem descentralizat și adaptiv, format din echipe autonome, fiecare dintre ele compusă din indivizi autonomi. Aceste echipe sunt răspândite în întreaga lume și colaborează eficient unele cu altele prin comunicare asincronă, utilizând protocoale de schimb informațional foarte transparente. Este foarte frumos, nu-i așa? O viitoare foarte frumoasă.
Desigur, toate acestea sunt imposibile fără schimbări culturale. Trebuie să avem un leadership transformațional, responsabilitate personală și motivație internă.
Aceasta este baza organizațiilor DevOps: transparența informației, comunicările asincrone, leadershipul transformațional, descentralizarea.
Epuizarea
Sistemele de care facem parte, și cele pe care le construim, devin din ce în ce mai haotice, iar nouă, oamenilor, ne este greu să facem față acestui gând, ne este greu să renunțăm la iluzia controlului. Încercăm să le controlăm în continuare, iar asta duce adesea la epuizare. Spun asta din experiența proprie, m-am ars și eu, sunt un invalid al defecțiunilor neprevăzute în producție.
Epuizarea are loc atunci când încercăm să controlăm ceea ce de fapt nu poate fi controlat. Când ne epuizăm, totul își pierde sensul, deoarece pierdem dorința de a face ceva nou, ne punem în defensivă și începem să protejăm ceea ce avem.
Profesia de inginer, așa cum îmi place adesea să-mi amintesc, este în primul rând o profesie creativă. Dacă pierdem dorința de a crea ceva, ne transformăm în cenușă, ne schimbăm în cenușă. Oamenii se epuizează, organizațiile întregi se epuizează.
Din punctul meu de vedere, doar acceptarea puterii creatoare a haosului, doar construirea colaborării pe principiile acestuia – acesta este ceea ce ne va ajuta să nu pierdem ceea ce este bun în profesia noastră.
Ce vă doresc: să iubiți munca voastră, să iubiți ceea ce facem. Această lume se hrănește cu informație și avem privilegiul de a o hrăni. Așa că haideți să studiem haosul, să fim haosologi, să aducem valoare, să creăm ceva nou, iar problemele, așa cum am stabilit, sunt inevitabile și, când apar, vom spune simplu „Ops!”, iar problema se rezolvă.
Ce este în afară de Chaos Monkey?
De fapt, toate aceste instrumente sunt foarte tinere. La fel, Netflix a construit instrumentele pentru nevoile proprii. Construiește instrumente pentru tine. Citește principiile ingineriei haosului și respectă aceste principii, în loc să cauți alte instrumente pe care altcineva le-a construit deja.
Încercați să înțelegeți cum se distrug sistemele voastre și începeți să le distrugeți pentru a observa cum rezistă. Asta este prioritatea. Și instrumentele pot fi căutate. Există tot felul de proiecte.
Nu am înțeles foarte bine momentul când ai spus că sistemul nu poate fi simplificat prin simplificarea componentelor sale și imediat ai trecut la microservicii, care de fapt simplifică sistemul prin simplificarea componentelor în sine și complicând interacțiunile. Aceasta sunt, în esență, două părți care se contrazic una pe cealaltă.
Așa este, microserviciile sunt o temă foarte controversată. De fapt, simplificarea părților crește flexibilitatea. Ce ne oferă microserviciile? Ne oferă flexibilitate și viteză, dar cu siguranță nu ne oferă simplificare. Ele cresc complexitatea.
Deci, în filosofia DevOps, microserviciile nu sunt un lucru atât de benefic?
Orice bine are o latură întunecată. Există un bine: aceasta crește flexibilitatea, ne oferă posibilitatea de a face modificări mai rapid, dar crește complexitatea și, în consecință, fragilitatea întregului sistem.
Totuși, pe ce se pune mai mult accent: pe simplificarea interacțiunii sau pe simplificarea părților?
Focalizarea se face, fără îndoială, pe simplificarea interacțiunii, pentru că, dacă ne uităm la acest lucru din perspectiva modului în care lucrăm, mai întâi trebuie să ne concentrăm asupra simplificării interacțiunilor, nu asupra simplificării muncii fiecăruia dintre noi. Deoarece simplificarea muncii înseamnă a ne transforma în roboți. La McDonald's, acest lucru funcționează normal, când ai stabilit: aici pui burgerul, aici torni sosul. Acest lucru nu funcționează deloc în munca noastră creativă.
Este adevărat că tot ceea ce ați spus trăiește într-o lume fără competiție, unde haosul este atât de binevoitor, iar în interiorul acestui haos nu există contradicții, nimeni nu vrea să mănânce sau să omoare pe nimeni? Cum ar trebui să coexiste competiția și DevOps?
Ei bine, depinde despre ce fel de competiție vorbim. Despre competiția la locul de muncă sau despre competiția între companii?
Despre competiția serviciilor care există, pentru că serviciile nu sunt doar câteva companii. Creăm un nou tip de mediu informațional, iar orice mediu nu poate trăi fără competiție. În cele din urmă, există competiție.
Luăm aceleași Netflix, considerându-i ca un model de referință. De ce au gândit acest lucru? Deoarece aveau nevoie să fie competitivi. Această flexibilitate și rapiditate de mișcare reprezintă cerința competitivă, adăugând haoticitate sistemelor noastre. Așadar, haosul nu este ceva ce facem conștient, pentru că îl vrem, ci este rezultatul cerințelor lumii. Trebuie doar să ne adaptăm. Și haosul este, de fapt, rezultatul competiției.
Asta înseamnă, oare, că haosul este o lipsă de scopuri? Sau acele scopuri pe care nu dorim să le vedem? Suntem în căsuță și nu înțelegem scopurile altora. Competitia, de fapt, se bazează pe faptul că avem scopuri clare și știm încotro ne îndreptăm în fiecare moment. Acesta este, din punctul meu de vedere, esența DevOps.
Este, de asemenea, o perspectivă asupra problemei. Cred că scopul nostru comun este același: să supraviețuim și să facem acest lucru cu
cât mai multă plăcere. Scopul competitiv al oricărei organizații este la fel. Supraviețuirea se desfășoară adesea într-o luptă competitivă, nu avem ce face.
În acest an, conferința va avea loc pe 7 decembrie la „Technopolis”. Până pe 11 noiembrie primim propuneri pentru prezentări. nouă dacă doriți să vorbiți.
Înscrierea pentru participanți este deschisă, biletul costă 7000 de ruble. Alăturați-vă!
Sursa: habr.com
