{"id":33725,"date":"2019-10-31T21:54:21","date_gmt":"2019-10-31T18:54:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/chto-takoe-devops\/"},"modified":"2019-10-31T21:54:21","modified_gmt":"2019-10-31T18:54:21","slug":"chto-takoe-devops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/chto-takoe-devops","title":{"rendered":"Ce este DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Definirea DevOps este foarte complex\u0103, a\u0219a c\u0103 trebuie s\u0103 relu\u0103m discu\u021bia de fiecare dat\u0103. Numai pe Habr sunt o mie de publica\u021bii pe acest subiect. Dar dac\u0103 cite\u0219ti asta, este evident c\u0103 \u0219tii ce este DevOps. Pentru c\u0103 eu nu \u0219tiu. Bun\u0103, m\u0103 numesc Alexandru Titov (@osminog<\/a><\/noindex><\/b>), \u0219i vom vorbi despre DevOps iar eu voi \u00eemp\u0103rt\u0103\u0219i experien\u021ba mea.<\/p>\n

\"Ce
\n
\nAm reflectat mult la cum s\u0103 fac povestea mea util\u0103, a\u0219a c\u0103 vor fi multe \u00eentreb\u0103ri \u2013 cele pe care mi le pun singur \u0219i cele pe care le adresez clien\u021bilor companiei noastre. R\u0103spunz\u00e2nd la aceste \u00eentreb\u0103ri, \u00een\u021belegerea devine mai bun\u0103. Voi explica de ce este nevoie de DevOps din perspectiva mea, ce \u00eenseamn\u0103, din nou, din punctul meu de vedere \u0219i cum s\u0103 \u00een\u021belegi dac\u0103 progresezi c\u0103tre DevOps, din aceea\u0219i perspectiva a mea. Ultimul punct va fi prin \u00eentreb\u0103ri. R\u0103spunz\u00e2nd la ele, vei putea s\u0103 \u00een\u021belegi dac\u0103 compania ta se \u00eendreapt\u0103 c\u0103tre DevOps sau dac\u0103 exist\u0103 probleme.
\n<\/a><\/noindex>
\n

\r\n \"Reda\u021bi\r\n
<\/div>\r\n <\/div><\/center>
\nO vreme, am navigat prin valurile fuziunilor \u0219i achizi\u021biilor. La \u00eenceput am lucrat \u00eentr-un mic startup numit Qik, apoi a fost achizi\u021bionat de o companie un pic mai mare, Skype, care a fost apoi cump\u0103rat\u0103 de Microsoft, o companie \u0219i mai mare. \u00cen acel moment, am avut o viziune despre cum se transform\u0103 percep\u021bia asupra DevOps \u00een companii de diferite dimensiuni. Dup\u0103 aceea, am devenit interesat de DevOps din punct de vedere al pie\u021bei, iar \u00eempreun\u0103 cu colegii am organizat compania Express 42. De 6 ani, navig\u0103m pe aceast\u0103 companie pe valurile pie\u021bei.<\/p>\n

\u00cen plus, sunt unul dintre organizatorii comunit\u0103\u021bii DevOps Moscow \u0219i organizator al DevOps Days 2017, dar \u00een 2018 nu am organizat. Express 42 colaboreaz\u0103 cu multe companii. Dezvolt\u0103m DevOps acolo, observ\u0103m cum se \u00eent\u00e2mpl\u0103, facem concluzii, analiz\u0103m, \u00eemp\u0103rt\u0103\u0219im concluziile noastre tuturor, instruim oamenii \u00een practicile DevOps. \u00cen general, cre\u0219tem experien\u021ba \u0219i expertiza \u00een acest sens.<\/p>\n

De ce DevOps<\/h2>\n

\nPrima \u00eentrebare care \u00eei urm\u0103re\u0219te pe to\u021bi mereu este: de ce? Mul\u021bi consider\u0103 c\u0103 DevOps este doar automatizare sau ceva asem\u0103n\u0103tor, care a existat deja \u00een fiecare companie.<\/p>\n

\u2014 Am avut Continuous Integration \u2014 asta \u00eenseamn\u0103 c\u0103 deja aveam DevOps, a\u0219a c\u0103 de ce avem nevoie de tot acest lucru? Acolo \u00een str\u0103in\u0103tate se distreaz\u0103, iar nou\u0103 ne stau \u00een cale!<\/i><\/p>\n

\u00cen cei 9 ani de dezvoltare a comunit\u0103\u021bii \u0219i a metodologiei, s-a \u00een\u021beles deja c\u0103 nu este doar o atrac\u021bie de marketing, dar nu este \u00eenc\u0103 clar de ce este necesar. Ca orice instrument \u0219i proces, DevOps are obiective specifice pe care le rezolv\u0103 \u00een cele din urm\u0103.<\/p>\n

Toate acestea sunt legate de faptul c\u0103 lumea se schimb\u0103. Se \u00eendep\u0103rteaz\u0103 de abordarea enterprise, c\u00e2nd companiile \u00ee\u0219i ating visul, a\u0219a cum c\u00e2nta clasicul nostru din Sankt Petersburg, din punctul A \u00een punctul B conform unei strategii definite, cu o structur\u0103 specific\u0103 construit\u0103 pentru aceasta. <\/p>\n

\"Ce
\n<\/p>\n

\u00cen principiu, IT-ul ar trebui s\u0103 fie construit pe aceast\u0103 abordare. Aici, IT-ul este utilizat exclusiv pentru automatizarea proceselor.<\/p><\/blockquote>\n

\nAutomatizarea nu se schimb\u0103 adesea, deoarece atunci c\u00e2nd compania merge pe un drum b\u0103t\u0103torit - ce s\u0103 schimbi? Func\u021bioneaz\u0103 - nu atinge. Acum, \u00een lume, abord\u0103rile se schimb\u0103, iar cel numit Agile spune c\u0103 punctul final B nu este vizibil imediat.<\/p>\n

\"Ce
\n
\nC\u00e2nd o companie se deplaseaz\u0103 pe pia\u021b\u0103, lucreaz\u0103 cu clien\u021bi - ea exploreaz\u0103 constant pia\u021ba \u0219i \u00ee\u0219i schimb\u0103 punctul final B. \u00cen plus, cu c\u00e2t o companie \u00ee\u0219i schimb\u0103 direc\u021bia mai des, cu at\u00e2t mai mult va avea succes, deoarece alege mai multe ni\u0219e de pia\u021b\u0103.<\/p>\n

Strategia este demonstrat\u0103 de o companie interesant\u0103 de care am aflat recent. One Box Shave - un serviciu de livrare de rasuri \u0219i accesorii de ras printr-o subscrip\u021bie \u00een cutie. Ei pot personaliza \"cutia\" lor pentru diferi\u021bi clien\u021bi. Acest lucru este realizat de un software specific, care apoi trimite comanda c\u0103tre o fabric\u0103 din Coreea de Sud care produce produsul.<\/p>\n

Acest produs a fost cump\u0103rat de compania Unilever pentru 1 miliard de dolari. Acum competi\u021bioneaz\u0103 cu Gillette \u0219i i-a furat o parte semnificativ\u0103 din consumatori pe pia\u021ba american\u0103. One Box Shave spune:<\/p>\n

- 4 lame? Chiar a\u0219a? De ce ai nevoie de asta - nu \u00eembun\u0103t\u0103\u021be\u0219te deloc calitatea b\u0103rbieritului. O crem\u0103 special aleas\u0103, un parfum \u0219i un aparat de ras de calitate cu dou\u0103 lame rezolv\u0103 mult mai multe probleme dec\u00e2t cele patru lame stupide de la Gillette! A\u0219a c\u0103, \u00een cur\u00e2nd, ajungem la 10?<\/i><\/p>\n

A\u0219a se schimb\u0103 lumea. Unilever afirm\u0103 c\u0103 au un sistem IT grozav, care permite acest lucru. \u00cen cele din urm\u0103, acesta arat\u0103 ca o concep\u021bie Time-to-market<\/b>, despre care au vorbit deja mul\u021bi.<\/p>\n

\"Ce
\n
\nSensul Time-to-market nu const\u0103 \u00een c\u00e2t de des ne desf\u0103\u0219ur\u0103m. Se poate desf\u0103\u0219ura frecvent, dar ciclurile de lansare vor fi lungi. Dac\u0103 suprapunem ciclurile de lansare de trei luni, mut\u00e2ndu-le cu o s\u0103pt\u0103m\u00e2n\u0103, se pare c\u0103 compania desf\u0103\u0219oar\u0103 o dat\u0103 pe s\u0103pt\u0103m\u00e2n\u0103. Dar \u00eentre idee \u0219i realizarea final\u0103 trec 3 luni.<\/p>\n

Time-to-market se refer\u0103 la minimizarea timpului de la idee la realizarea final\u0103.<\/p><\/blockquote>\n

\n\u00cen acest caz, software-ul interac\u021bioneaz\u0103 cu pia\u021ba. Astfel, One Box Shave interac\u021bioneaz\u0103 cu clientul prin intermediul site-ului. Nu au v\u00e2nz\u0103tori - doar un site, unde vizitatorul face clic \u0219i las\u0103 dorin\u021bele. Prin urmare, pe site trebuie s\u0103 post\u0103m constant ceva nou, actualiz\u00e2ndu-l conform dorin\u021belor. De exemplu, \u00een Coreea de Sud se rade altfel dec\u00e2t \u00een Rusia, iar lor le place s\u0103 miroas\u0103 nu a pin, ci, de exemplu, a vanilie cu morcov.<\/p>\n

Deoarece este necesar s\u0103 schimba\u021bi rapid con\u021binutul site-ului, dezvoltarea software-ului se schimb\u0103 semnificativ. Prin software trebuie s\u0103 afl\u0103m ce vrea clientul. \u00cen trecut, aflam acest lucru prin anumite metode indirecte, de exemplu, prin managementul afacerilor. Apoi proiectam, integrau cerin\u021bele \u00een sistemele IT, \u0219i totul era grozav. Acum lucrurile stau diferit - software-ul este proiectat de to\u021bi cei implica\u021bi \u00een proces, inclusiv inginerii, deoarece ei afl\u0103 din specifica\u021biile tehnice cum func\u021bioneaz\u0103 pia\u021ba \u0219i \u00ee\u0219i \u00eemp\u0103rt\u0103\u0219esc \u0219i cu afacerea insights-urile lor.<\/p>\n

De exemplu, \u00een compania Qik am aflat brusc c\u0103 oamenilor le place foarte mult s\u0103 \u00eencarce listele de contacte pe server \u0219i ne-au dat o aplica\u021bie. Ini\u021bial, nu ne g\u00e2ndisem la asta. \u00centr-o companie clasic\u0103, to\u021bi ar fi decis c\u0103 este un bug, deoarece \u00een specifica\u021bii nu este men\u021bionat c\u0103 trebuie s\u0103 func\u021bioneze grozav \u0219i, \u00een general, a fost realizat \u00een prip\u0103, ar fi dezactivat func\u021bia \u0219i ar fi spus: \u201eNu este nevoie de asta, cel mai important este c\u0103 func\u021bionalitatea principal\u0103 func\u021bioneaz\u0103\u201d. Dar o companie tehnologic\u0103 vede aici o oportunitate \u0219i \u00eencepe s\u0103 schimbe software-ul \u00een conformitate cu acest lucru.<\/p>\n

\"Ce
\n
\n\u00cen 1968, un tip prezic\u0103tor pe nume Melvin Conway a formulat urm\u0103toarea idee.<\/p>\n

O organiza\u021bie care creeaz\u0103 un sistem este limitat\u0103 de designul care copiaz\u0103 structura comunic\u0103rii \u00een aceast\u0103 organiza\u021bie.<\/p><\/blockquote>\n

\nDac\u0103 detaliem, pentru a produce sisteme de alt tip, trebuie de asemenea s\u0103 ave\u021bi o structur\u0103 de comunicare diferit\u0103 \u00een cadrul companiei. Dac\u0103 ave\u021bi o structur\u0103 de comunicare ierarhic\u0103 superioar\u0103, aceasta nu v\u0103 va permite s\u0103 crea\u021bi sisteme care pot oferi un timp de lansare pe pia\u021b\u0103 foarte ridicat.<\/p>\n

Citi\u021bi despre legea lui Conway<\/a><\/noindex> poate prin linkuri<\/a><\/noindex>. Este important pentru \u00een\u021belegerea culturii sau filozofiei DevOps, deoarece singurul lucru care se schimb\u0103 fundamental \u00een DevOps este chiar structura de comunicare dintre echipe.<\/b>.<\/p>\n

Din punct de vedere al procesului, \u00eenainte de DevOps, toate etapele: analiza, dezvoltarea, testarea, operarea, se desf\u0103\u0219urau linear.\"Ce
\n\u00cen cazul DevOps, toate aceste procese se desf\u0103\u0219oar\u0103 simultan.<\/p>\n

\"Ce
\n
\nTimpul de lansare pe pia\u021b\u0103 poate fi realizat doar astfel. Pentru persoanele care au lucrat \u00een vechiul proces, acest lucru pare oarecum SF \u0219i, \u00een general, nu este deloc bine.<\/p>\n

Deci, de ce avem nevoie de DevOps?<\/h3>\n

\nPentru dezvoltarea produselor digitale.<\/b>Dac\u0103 \u00een compania dumneavoastr\u0103 nu exist\u0103 un produs digital, DevOps nu este necesar - acest lucru este foarte important.<\/p>\n

DevOps dep\u0103\u0219e\u0219te limitele de vitez\u0103 ale schemei de produc\u021bie secven\u021bial\u0103 a software-ului.<\/b>\u00cen cadrul s\u0103u, toate procesele au loc simultan.<\/p>\n

Complexitatea cre\u0219te.<\/b> C\u00e2nd evangheli\u0219tii DevOps spun c\u0103 va deveni mai u\u0219or s\u0103 lansa\u021bi software - aceasta este o prostie.<\/p>\n

Cu DevOps, totul va deveni doar mai complicat.<\/p><\/blockquote>\n

\nLa conferin\u021b\u0103, la standul Avito, putea\u021bi observa ce \u00eenseamn\u0103 s\u0103 desf\u0103\u0219ura\u021bi un container Docker - o sarcin\u0103 nerealist\u0103. Complexitatea devine excesiv\u0103, trebuie s\u0103 jongla\u021bi cu foarte multe mingi simultan.<\/p>\n

DevOps schimb\u0103 complet procesul \u0219i organiza\u021bia din companie<\/b>\u00a0\u2014 mai precis, nu DevOps schimb\u0103, ci produsul digital. Pentru a ajunge la DevOps, trebuie totu\u0219i s\u0103 schimba\u021bi complet acest proces.<\/p>\n

\u00centreb\u0103ri pentru specialist<\/h3>\n

\nDar dumneavoastr\u0103 ce ave\u021bi? \u00centreb\u0103ri pe care v\u0103 pute\u021bi pune lucr\u00e2nd \u00een companie \u0219i dezvolt\u00e2ndu-v\u0103 ca specialist.<\/p>\n

Ave\u021bi o strategie pentru crearea unui produs digital?<\/b> Dac\u0103 da - deja este bine. Asta \u00eenseamn\u0103 c\u0103 compania dumneavoastr\u0103 se \u00eendreapt\u0103 spre DevOps.<\/p>\n

Compania dumneavoastr\u0103 produce deja un produs digital?<\/b> Asta \u00eenseamn\u0103 c\u0103 pute\u021bi s\u0103 urca\u021bi \u00eenc\u0103 pe o treapt\u0103 mai sus, ocup\u00e2ndu-v\u0103 de lucruri mai interesante - din punct de vedere al DevOps, din nou. Asta doar din acest punct de vedere spun.<\/p>\n

Compania dumneavoastr\u0103 este unul dintre liderii de pia\u021b\u0103 \u00een ni\u0219a cu produsul digital?<\/b> Spotify, Yandex, Uber - companii care se afl\u0103 la v\u00e2rful progresului tehnologic \u00een prezent.<\/p>\n

Pune\u021bi-v\u0103 aceste \u00eentreb\u0103ri, \u0219i dac\u0103 toate r\u0103spunsurile sunt negative, atunci poate c\u0103 nu ar trebui s\u0103 v\u0103 ocupa\u021bi de DevOps \u00een aceast\u0103 companie. Dac\u0103, totu\u0219i, subiectul DevOps v\u0103 intereseaz\u0103 cu adev\u0103rat, poate c\u0103 ar trebui s\u0103 trece\u021bi \u00een alt\u0103 companie? Dac\u0103 compania dumneavoastr\u0103 dore\u0219te s\u0103 adopte DevOps, dar a\u021bi r\u0103spuns \u201eNu\u201d la toate \u00eentreb\u0103rile, atunci aceasta se aseam\u0103n\u0103 cu un rinocer minunat, care nu se va schimba niciodat\u0103.<\/p>\n

\"Ce
\n<\/p>\n

Organizare<\/h2>\n

\nA\u0219a cum am spus deja, conform legii lui Conway, organiza\u021bia din companie se schimb\u0103. Voi \u00eencepe cu ceea ce \u00eempiedic\u0103 DevOps s\u0103 p\u0103trund\u0103 \u00een interiorul companiei, din perspectiva organiza\u021biei.<\/p>\n

Problema \u201esilo-urilor\u201d<\/h3>\n

\nCuv\u00e2ntul englezesc \u201eSilo\u201d a fost tradus aici \u00een rus\u0103 ca \u201esilo\u201d. Sensul acestei probleme const\u0103 \u00een faptul c\u0103 \u00eentre echipe nu exist\u0103 schimb de informa\u021bii<\/b>. Fiecare echip\u0103 \u00ee\u0219i sape expertiza \u00een ad\u00e2ncime, f\u0103r\u0103 a construi o hart\u0103 comun\u0103, pe care s\u0103 se poat\u0103 orienta.<\/p>\n

Acest lucru aduce aminte de o persoan\u0103 care a venit recent \u00een Moscova \u0219i care nu \u0219tie \u00eenc\u0103 s\u0103 se orienteze pe harta metroului. Moscovi\u021bii cunosc de obicei bine zona lor, iar pentru \u00eentreaga Moscov\u0103 se bazeaz\u0103 pe harta metroului. C\u00e2nd vii \u00een Moscova pentru prima dat\u0103, nu ai aceast\u0103 abilitate \u0219i e\u0219ti pur \u0219i simplu dezorientat.<\/p>\n

DevOps propune s\u0103 treac\u0103 peste acest moment de dezorientare \u0219i s\u0103 construiasc\u0103 \u00eempreun\u0103 cu toate subdiviziunile o hart\u0103 comun\u0103 de interac\u021biune.<\/p><\/blockquote>\n

\nAcest lucru este \u00eempiedicat de doi factori.<\/p>\n

Consecin\u021b\u0103 a sistemului de gestionare corporativ.<\/b> Este construit din silo-uri ierarhice separate. De exemplu, exist\u0103 anumite KPI-uri \u00een companii care sus\u021bin acest sistem. Pe de alt\u0103 parte, dificult\u0103\u021bile sunt cauzate de faptul c\u0103 oamenii le este greu s\u0103 ias\u0103 dincolo de expertiza lor \u0219i s\u0103 se orienteze \u00een \u00eentregul sistem. Este pur \u0219i simplu inconfortabil. Imagina\u021bi-v\u0103 c\u0103 a\u021bi ajuns \u00een aeroportul din Bangkok - acolo nu te po\u021bi orienta rapid. La fel este \u0219i \u00een DevOps, \u0219i din acest motiv oamenii spun c\u0103 trebuie s\u0103 g\u0103se\u0219ti un ghid pentru a ajunge acolo.<\/p>\n

Dar cel mai important, problema \u201esilo-urilor\u201d pentru un inginer care a adoptat spiritul DevOps, a citit Fowler \u0219i o mul\u021bime de alte c\u0103r\u021bi, se prezint\u0103 astfel c\u0103 \u201esilo-urile\u201d nu permit efectuarea lucrurilor \u201eevidente\u201d<\/b>. Adesea, ne \u00eent\u00e2lnim dup\u0103 DevOps Moscow, discut\u0103m \u00eentre noi \u0219i oamenii se pl\u00e2ng:<\/p>\n

\u2014 Voiam s\u0103 lans\u0103m doar CI, dar se pare c\u0103 managementul nu are nevoie de asta.<\/i><\/p>\n

Acest lucru se \u00eent\u00e2mpl\u0103 tocmai din cauza c\u0103\u00a0CI <\/b>\u0219i\u00a0procesul Continuous Delivery<\/b> se afl\u0103 la grani\u021ba mai multor expertize. Pur \u0219i simplu, f\u0103r\u0103 a dep\u0103\u0219i problema \u201ef\u00e2nt\u00e2nilor\u201d la nivel organiza\u021bional, nu ve\u021bi putea avansa mai departe, indiferent de ceea ce face\u021bi \u0219i c\u00e2t de trist ar fi acest lucru.<\/p>\n

\"Ce
\n
\nFiecare participant la proces \u00een companie: dezvoltatori de backend \u0219i frontend, testeri, DBA, opera\u021biuni, re\u021bea, \u00ee\u0219i \u00eendreapt\u0103 aten\u021bia spre direc\u021bia sa, iar nimeni nu de\u021bine o hart\u0103 comun\u0103, \u00een afar\u0103 de manager, care somehow \u00eei observ\u0103 \u0219i \u00eei gestioneaz\u0103 prin metoda \u201edivide \u0219i conduci\u201d.<\/p>\n

Oamenii se lupt\u0103 pentru anumite stele sau steaguri, fiecare \u00ee\u0219i aprofund\u00e2nd expertiza.<\/p><\/blockquote>\n

\n\u00cen cele din urm\u0103, c\u00e2nd apare sarcina de a conecta toate acestea \u00eempreun\u0103 \u0219i de a construi un pipeline comun, \u0219i nu mai este nevoie s\u0103 se lupte pentru stele \u0219i steaguri, apare \u00eentrebarea \u2014 ce trebuie s\u0103 facem de fapt? Trebuie s\u0103 ne \u00een\u021belegem cumva, dar cum s\u0103 facem asta, nimeni nu ne-a \u00eenv\u0103\u021bat la \u0219coal\u0103. \u00cenc\u0103 din \u0219coal\u0103, am fost \u00eenv\u0103\u021ba\u021bi: clasa a opta \u2014 wow! \u2014 comparativ cu clasa a \u0219aptea! Aici este acela\u0219i lucru.<\/p>\n

A\u0219a este \u0219i \u00een compania dumneavoastr\u0103?<\/h3>\n

\nPentru a verifica acest lucru, pute\u021bi s\u0103 v\u0103 pune\u021bi urm\u0103toarele \u00eentreb\u0103ri.<\/p>\n

Folosesc echipele instrumente comune, contribuie la modific\u0103rile acestor instrumente comune?<\/p>\n

C\u00e2t de des echipele se reorganizeaz\u0103 - unii speciali\u0219ti dintr-o echip\u0103 trec \u00een alta?<\/b> \u00cen mediul DevOps, acest lucru devine o norm\u0103, deoarece uneori o persoan\u0103 pur \u0219i simplu nu poate \u00een\u021belege ce face o alt\u0103 zon\u0103 de expertiz\u0103. El se mut\u0103 \u00een alt departament, lucreaz\u0103 acolo timp de dou\u0103 s\u0103pt\u0103m\u00e2ni pentru a-\u0219i crea o hart\u0103 de orientare \u0219i interac\u021biune cu acel departament.<\/p>\n

Se poate crea un comitet pentru schimbare \u0219i se poate schimba ceva? <\/b>Sau pentru asta este nevoie de o m\u00e2n\u0103 puternic\u0103 a conduc\u0103torilor cei mai \u00eenal\u021bi \u0219i de un ordin? Recent am scris pe Facebook despre cum o banc\u0103 pu\u021bin cunoscut\u0103 implementeaz\u0103 instrumente prin ordine: au emis un ordin, implement\u0103m timp de un an, observ\u0103m ce se \u00eent\u00e2mpl\u0103. Este, desigur, \u00eendelungat \u0219i trist.<\/p>\n

C\u00e2t de important este pentru manageri s\u0103 ob\u021bin\u0103 realiz\u0103ri personale f\u0103r\u0103 a lua \u00een considerare realiz\u0103rile companiei? <\/b><\/p>\n

Dac\u0103 r\u0103spunde\u021bi la aceste \u00eentreb\u0103ri pentru dumneavoastr\u0103, va fi mai clar dac\u0103 ave\u021bi o astfel de problem\u0103 \u00een companie.<\/p>\n

Infrastructure as Code<\/h2>\n

\nDup\u0103 ce am dep\u0103\u0219it aceast\u0103 problem\u0103, prima practic\u0103 important\u0103, f\u0103r\u0103 de care este greu s\u0103 avansezi \u00een DevOps, este infrastructura ca cod<\/b>. <\/p>\n

Cel mai adesea, infrastructura ca \u0219i cod este perceput\u0103 astfel:<\/p>\n

\u2014 S\u0103 automatiz\u0103m totul pe bash, s\u0103 ne umplem de scripturi, pentru ca adminii s\u0103 aib\u0103 mai pu\u021bin de lucru manual!<\/i><\/p>\n

Dar nu este a\u0219a.<\/p>\n

Infrastructura ca \u0219i cod implic\u0103 faptul c\u0103 sistemul IT cu care lucrezi \u00eel descrii sub form\u0103 de cod, pentru a \u00een\u021belege constant starea acestuia.<\/p><\/blockquote>\n

\n\u00cempreun\u0103 cu alte echipe, creezi o hart\u0103 sub form\u0103 de cod, care este clar\u0103 pentru to\u021bi, pe baza c\u0103reia se poate naviga. Nu are importan\u021b\u0103 ce folosesc pentru aceasta - Chef, Ansible, Salt, sau dac\u0103 se folosesc fi\u0219iere YAML \u00een Kubernetes - nu conteaz\u0103.<\/p>\n

La conferin\u021b\u0103, un coleg de la 2GIS povestea cum au realizat un instrument intern pentru Kubernetes, care descrie structura sistemelor individuale. Pentru a descrie 500 de sisteme, le-a trebuit un instrument special care genereaz\u0103 aceast\u0103 descriere. C\u00e2nd exist\u0103 aceast\u0103 descriere, fiecare poate verifica informa\u021biile \u00eentre ei, monitoriza schimb\u0103rile, cum s\u0103 le modifice \u0219i s\u0103 le \u00eembun\u0103t\u0103\u021beasc\u0103, ce lipse\u0219te. <\/p>\n

Fi\u021bi de acord, scripturile bash separate de obicei nu ofer\u0103 aceast\u0103 \u00een\u021belegere. La una dintre companiile unde am lucrat, exista chiar o denumire \u201escript write only\u201d - c\u00e2nd scriptul este scris, dar nu mai poate fi citit. Cred c\u0103 \u0219i pentru voi este familiar.<\/p>\n

Infrastructura ca \u0219i cod este cod care descrie starea actual\u0103 a infrastructurii<\/b>. Acest cod este colaborativ \u00eentre numeroase echipe de produs, infrastructur\u0103 \u0219i servicii \u0219i, cel mai important, toate acestea trebuie s\u0103 \u00een\u021beleag\u0103 cum func\u021bioneaz\u0103 acest cod.<\/p>\n

Codul este gestionat conform celor mai bune practici de lucru cu codul<\/b>: dezvoltare colaborativ\u0103, revizuirea codului, XP-programming, testare, pull requests, CI pentru codul infrastructural - toate acestea sunt utile \u0219i pot fi utilizate.<\/p>\n

Codul devine un limbaj comun pentru to\u021bi inginerii.<\/p><\/blockquote>\n

\nModificarea infrastructurii \u00een cod nu dureaz\u0103 mult timp.<\/b>. Da, \u00een codul infrastructural poate exista \u0219i o datorie tehnic\u0103. De obicei, echipele se confrunt\u0103 cu aceasta dup\u0103 aproximativ un an \u0219i jum\u0103tate de la implementarea \u201einfrastructurii ca cod\u201d sub form\u0103 de mul\u021bime de scripturi sau chiar Ansible, pe care le scriu ca \u0219i cum ar fi cod spaghetti \u0219i mai adaug\u0103 \u0219i scripturi bash \u00een mixtur\u0103! <\/p>\n

Este important<\/b>: dac\u0103 nu a\u021bi \u00eencercat p\u00e2n\u0103 acum aceast\u0103 porc\u0103rie, re\u021bine\u021bi c\u0103 Ansible nu este bash<\/b>! Citi\u021bi cu aten\u021bie documenta\u021bia, studia\u021bi ce se scrie despre aceasta.<\/p>\n

Infrastructura ca \u0219i cod - este separarea codului infrastructural \u00een straturi distincte.<\/p><\/blockquote>\n

\nLa compania noastr\u0103, distingem 3 straturi fundamentale, care sunt foarte clare \u0219i simple, dar pot exista mai multe. Pute\u021bi s\u0103 v\u0103 verifica\u021bi codul infrastructural \u0219i s\u0103 spune\u021bi dac\u0103 ave\u021bi sau nu aceast\u0103 condi\u021bie. Dac\u0103 nu sunt delimitate straturi, trebuie s\u0103 aloca\u021bi timp pentru a refactoriza pu\u021bin.
\n\"Ce
\n
\nStratul de baz\u0103<\/b>\u00a0este modul \u00een care se configureaz\u0103 OS-ul, backup-urile \u0219i alte lucruri de nivel inferior, de exemplu, modul \u00een care se desf\u0103\u0219oar\u0103 Kubernetes la nivel de baz\u0103.<\/p>\n

Nivelul serviciilor<\/b>\u00a0este acele servicii pe care le oferi\u021bi dezvoltatorului: logging ca serviciu, monitorizare ca serviciu, baz\u0103 de date ca serviciu, load balancer ca serviciu, queue ca serviciu, Continuous Delivery ca serviciu - o mul\u021bime de servicii pe care echipe separate le pot oferi dezvolt\u0103rii. Este important s\u0103 descrie\u021bi toate acestea prin module separate \u00een sistemul dumneavoastr\u0103 de gestionare a configura\u021biei.<\/p>\n

Stratul \u00een care se dezvolt\u0103 aplica\u021biile<\/b> \u0219i se descrie modul \u00een care acestea vor fi desf\u0103\u0219urate peste cele dou\u0103 straturi anterioare.<\/p>\n

\u00centreb\u0103ri de control<\/h3>\n

\nAve\u021bi \u00een compania dumneavoastr\u0103 un depozit infrastructural comun? Controla\u021bi datoria tehnic\u0103 \u00een infrastructur\u0103? Utiliza\u021bi practici de dezvoltare \u00een depozitul infrastructural? Este infrastructura dumneavoastr\u0103 \u00eemp\u0103r\u021bit\u0103 \u00een straturi? Pute\u021bi verifica schema Base-service-APP. C\u00e2t de dificil este s\u0103 face\u021bi o modificare? <\/p>\n

Dac\u0103 v-a\u021bi lovit de faptul c\u0103 efectuarea schimb\u0103rilor dura o zi \u0219i jum\u0103tate, \u00eenseamn\u0103 c\u0103 a\u021bi acumulat o datorie tehnic\u0103 \u0219i trebuie s\u0103 lucra\u021bi cu ea. A\u021bi dat peste capcanele datoriei tehnice \u00een codul infrastructural. \u00cemi amintesc multe astfel de pove\u0219ti, c\u00e2nd, pentru a schimba un anumit CCTL, trebuie s\u0103 rescrie\u021bi jum\u0103tate din codul infrastructural, pentru c\u0103 creativitatea \u0219i dorin\u021ba de a automatiza totul au dus la situa\u021bia \u00een care totul este complet \u00eencurcat, toate manetele au fost eliminate, iar acum trebuie s\u0103 refactoriza\u021bi.<\/p>\n

Livrare continu\u0103<\/h2>\n

\nS\u0103 punem cap la cap debitul \u0219i creditul. Ini\u021bial apare o descriere a infrastructurii, care poate fi destul de bazic\u0103. Nu este obligatoriu s\u0103 descrie\u021bi totul \u00een detaliu, dar este necesar\u0103 o descriere de baz\u0103 pentru a putea lucra cu acest lucru. Altfel, nu este clar cum s\u0103 realiza\u021bi livrarea continu\u0103. Toate aceste practici se desf\u0103\u0219oar\u0103 simultan, atunci c\u00e2nd ajunge\u021bi la DevOps, dar trebuie s\u0103 \u00eencepe\u021bi prin a \u00een\u021belege ce ave\u021bi \u0219i cum s\u0103 gestiona\u021bi acest lucru. Aceasta este practica infrastructurii ca \u0219i cod.<\/p>\n

Dup\u0103 ce a devenit clar ce ave\u021bi \u0219i cum s\u0103 gestiona\u021bi, \u00eencepe\u021bi s\u0103 n\u0103scoci\u021bi cum s\u0103 trimite\u021bi rapid codul dezvoltatorului \u00een produc\u021bie. M\u0103 refer la \u00eempreun\u0103 cu dezvoltatorul - s\u0103 ne amintim de problema \u201ef\u00e2nt\u00e2nilor\u201d, adic\u0103 nu o echip\u0103 separat\u0103 vine cu idei, ci este un efort comun.<\/p>\n

C\u00e2nd ne-am\u00a0\u00eent\u00e2lnit cu Vania Evtuhovich<\/b> \u0219i am v\u0103zut prima c\u0103rticic\u0103 a lui Jez Humble<\/b> \u0219i a grupului de autori \u00abContinuous Delivery\u00bb<\/b>, care a fost publicat\u0103 \u00een 2009, ne-am g\u00e2ndit mult la cum s\u0103 traducem titlul ei \u00een limba rom\u00e2n\u0103. Am vrut s\u0103-l traducem ca \u00abLivrare continu\u0103\u00bb, dar, din p\u0103cate, l-am tradus ca \u00abLivrare continu\u0103\u00bb. Mi se pare c\u0103 \u00een titlul nostru exist\u0103 ceva rom\u00e2nesc, cu o for\u021b\u0103 aparte.<\/p>\n

Livrarea continu\u0103 \u00eenseamn\u0103<\/h3>\n

\nCodul care se afl\u0103 \u00een depozitul de produse poate fi oric\u00e2nd trimis \u00een produc\u021bie<\/b>. El poate s\u0103 nu fie trimis, dar este \u00eentotdeauna gata pentru asta. \u00cen consecin\u021b\u0103, \u00eentotdeauna scrie\u021bi cod cu un sentiment greu de explicat de nelini\u0219te \u00een zona inferioar\u0103 a spatelui. Acest sentiment de nelini\u0219te ar trebui s\u0103 fie prezent - el declan\u0219eaz\u0103 procese mentale care permit scrierea codului \u00eentr-un mod pu\u021bin diferit. Acesta trebuie s\u0103 fie documentat \u00een regulile din cadrul dezvolt\u0103rii.<\/p>\n

Pentru a livra continuu, este necesar un format de artefact care trece prin platforma de infrastructur\u0103. <\/b>Dac\u0103 arunca\u021bi pe platforma de infrastructur\u0103 de\u0219euri de format diferit, aceasta devine neuniform\u0103, este greu de \u00eentre\u021binut, apare problema datoriei tehnice. Formatul artefactului trebuie s\u0103 fie standardizat - este o sarcin\u0103 colectiv\u0103: trebuie s\u0103 ne adun\u0103m cu to\u021bii, s\u0103 ne punem min\u021bile la contribu\u021bie \u0219i s\u0103 g\u00e2ndim acest format.<\/p>\n

Artifactul se \u00eembun\u0103t\u0103\u021be\u0219te continuu \u0219i se adapteaz\u0103 la mediul de produc\u021bie \u00een timpul fluxului de livrare. <\/b>C\u00e2nd artifactul se mi\u0219c\u0103 prin flux, se confrunt\u0103 tot timpul cu diverse obstacole, asem\u0103n\u0103toare cu cele pe care le \u00eent\u00e2lne\u0219te artefactul pe care \u00eel publica\u021bi \u00een produc\u021bie. Dac\u0103 \u00een dezvoltarea clasic\u0103 acest lucru este gestionat de un administrator de sistem care efectueaz\u0103 livrarea, \u00een procesul DevOps se \u00eent\u00e2mpl\u0103 constant: aici este supus unor teste, acolo este aruncat \u00eentr-un cluster Kubernetes, care este mai mult sau mai pu\u021bin similar cu produc\u021bia, iar apoi este supus unor teste de stres.<\/p>\n

Acest lucru aminte\u0219te cumva de jocul Pac-Man - artifactul parcurge o anumit\u0103 poveste. Este important s\u0103 controla\u021bi dac\u0103 codul trece prin acea poveste \u0219i dac\u0103 este legat\u0103 de produc\u021bia dumneavoastr\u0103. Pove\u0219tile despre produc\u021bie pot fi integrate \u00een procesul Continuous Delivery: a fost a\u0219a c\u00e2nd ceva a e\u0219uat, acum haide\u021bi s\u0103 program\u0103m acest scenariu \u00een sistem. De fiecare dat\u0103, codul va trece prin acest scenariu \u0219i nu ve\u021bi mai \u00eent\u00e2lni aceast\u0103 problem\u0103. Ve\u021bi afla despre ea mult mai devreme dec\u00e2t va ajunge la clientul dumneavoastr\u0103.<\/p>\n

Diverse strategii de livrare. <\/b>De exemplu, utiliza\u021bi testarea AB sau livr\u0103ri canar pentru a \"sim\u021bi\" codul diferit pe clien\u021bi diferi\u021bi, ob\u021bin\u00e2nd informa\u021bii despre cum func\u021bioneaz\u0103 codul, cu mult \u00eenainte ca acesta s\u0103 fie livrat la 100 de milioane de utilizatori.<\/p>\n

\"Livrarea continu\u0103\" arat\u0103 a\u0219a.<\/p>\n

\"Ce
\n<\/p>\n

Procesul de livrare Dev, CI, Test, PreProd, Prod - nu este un mediu separat, ci etape sau sta\u021bii cu sume ineficiente, pe care artifactul dumneavoastr\u0103 le parcurge.<\/p><\/blockquote>\n

\nDac\u0103 ave\u021bi cod infrastructural descris ca Base Service APP, acesta ajut\u0103 s\u0103 nu uita\u021bi toate scenariile<\/b>, \u0219i s\u0103 le \u00eenregistra\u021bi \u0219i sub forma de cod pentru acest artifact, s\u0103 avansa\u021bi artifactul<\/b> \u0219i s\u0103 \u00eel modifica\u021bi pe parcurs.<\/p>\n

\u00centreb\u0103ri pentru autoevaluare<\/h3>\n

\nEste timpul de la descrierea func\u021bionalit\u0103\u021bii p\u00e2n\u0103 la livrarea \u00een produc\u021bie \u00een 95% din cazuri mai mic de o s\u0103pt\u0103m\u00e2n\u0103? Se \u00eembun\u0103t\u0103\u021be\u0219te calitatea artifactului la fiecare etap\u0103 a fluxului? Exist\u0103 o poveste pe care o parcurge? Folosi\u021bi diferite strategii de livrare?<\/p>\n

Dac\u0103 toate r\u0103spunsurile sunt da, atunci sunte\u021bi incredibil de buni! Scrie\u021bi r\u0103spunsurile \u00een comentarii - a\u0219 fi \u00eenc\u00e2ntat).<\/p>\n

Feedback-ul<\/h3>\n

\nAceasta este cea mai complicat\u0103 practic\u0103 dintre toate. La conferin\u021ba DevOpsConf, un coleg de la Infobip s-a \u00eencurcat u\u0219or \u00een cuvinte vorbind despre ea, pentru c\u0103 este cu adev\u0103rat o practic\u0103 foarte complex\u0103 despre ceea ce trebuie s\u0103 monitoriz\u0103m de fapt totul!<\/p>\n

\"Ce
\n
\nDe exemplu, cu mult timp \u00een urm\u0103, c\u00e2nd lucram la Qik \u0219i ne-am dat seama c\u0103 trebuie s\u0103 monitoriz\u0103m de fapt totul. Am f\u0103cut asta \u0219i am avut \u00een Zabbix 150.000 de itemi, care sunt monitoriza\u021bi constant. A fost \u00eenfrico\u0219\u0103tor, directorul tehnic \u00ee\u0219i \u00eenv\u00e2rtea degetul la t\u00e2mpl\u0103:<\/p>\n

\u2014 Baieti, de ce maltrata\u021bi serverul cu lucruri neclare?<\/i><\/p>\n

Dar apoi a avut loc un incident care a ar\u0103tat c\u0103 aceasta este \u00eentr-adev\u0103r o strategie foarte bun\u0103.<\/p>\n

Unul dintre servicii a \u00eenceput s\u0103 cad\u0103 constant. Ini\u021bial nu c\u0103dea, ceea ce este interesant, acolo nu se ad\u0103uga cod, pentru c\u0103 era un broker de baz\u0103, \u00een care practic nu exista func\u021bionalitate de afaceri \u2014 pur \u0219i simplu transmitea mesaje \u00eentre servicii separate. Serviciul nu s-a schimbat timp de 4 luni \u0219i, dintr-o dat\u0103, a \u00eenceput s\u0103 cad\u0103 cu eroarea \u201eSegmentation fault\u201d.<\/p>\n

Ficeam \u00een \u0219oc, am deschis graficele \u00een Zabbix \u0219i am aflat c\u0103, de fapt, cu o s\u0103pt\u0103m\u00e2n\u0103 \u0219i jum\u0103tate \u00een urm\u0103, comportamentul cererilor \u00een serviciul API s-a schimbat semnificativ. Apoi am verificat c\u0103 s-a schimbat frecven\u021ba trimiterii unui anumit tip de mesaje. Dup\u0103 aceea, am aflat c\u0103 este vorba despre clien\u021bii Android. Am \u00eentrebat:<\/p>\n

\u2014 B\u0103ie\u021bi, ce s-a \u00eent\u00e2mplat acum o s\u0103pt\u0103m\u00e2n\u0103 \u0219i jum\u0103tate?<\/i><\/p>\n

\u00cen r\u0103spuns am auzit o poveste interesant\u0103 despre faptul c\u0103 au reproiectat UI-ul. Pu\u021bine persoane ar spune imediat c\u0103 au schimbat biblioteca HTTP. Pentru clien\u021bii Android este ca \u0219i cum ai schimba s\u0103punul din baie \u2014 pur \u0219i simplu nu \u00ee\u0219i amintesc. \u00cen cele din urm\u0103, dup\u0103 40 de minute de discu\u021bie, am aflat c\u0103 au schimbat totu\u0219i biblioteca HTTP \u0219i aceasta a avut timpii default schimba\u021bi. Asta a dus la schimbarea comportamentului traficului pe serverul API, ceea ce a dus la o situa\u021bie care a generat o competi\u021bie \u00een interiorul brokerului, f\u0103c\u00e2ndu-l s\u0103 cad\u0103.<\/p>\n

F\u0103r\u0103 monitorizare profund\u0103, este complet imposibil s\u0103 ne d\u0103m seama de asta.<\/b>. Dac\u0103 \u00een organiza\u021bie exist\u0103 \u0219i problema \"f\u00e2nului\", c\u00e2nd fiecare arunc\u0103 vina pe altcineva, aceasta poate continua ani de zile. Pur \u0219i simplu reporni\u021bi serverul, pentru c\u0103 nu este posibil s\u0103 rezolva\u021bi problema. C\u00e2nd monitoriza\u021bi, urm\u0103ri\u021bi, verifica\u021bi toate evenimentele pe care le ave\u021bi \u0219i folosi\u021bi monitorizarea ca testare \u2014 scrie\u021bi codul \u0219i imediat specifica\u021bi cum s\u0103 fie monitorizat, tot \u00een form\u0103 de cod (deja avem infrastructur\u0103 ca \u0219i cod), totul devine clar ca lumina zilei. Chiar \u0219i problemele complexe sunt u\u0219or de urm\u0103rit.<\/p>\n

\"Ce
\n<\/p>\n

Aduna\u021bi toate informa\u021biile despre ceea ce se \u00eent\u00e2mpl\u0103 cu artefactul \u00een fiecare etap\u0103 a procesului de livrare \u2014 nu \u00een produc\u021bie.<\/p><\/blockquote>\n

\n\u00cenc\u0103rca\u021bi monitorizarea \u00een CI, \u0219i acolo vor fi vizibile c\u00e2teva lucruri de baz\u0103. Mai departe le ve\u021bi vedea \u0219i \u00een Test, \u0219i \u00een PredProd, \u0219i \u00een testarea de \u00eenc\u0103rcare. Aduna\u021bi informa\u021bii \u00een toate etapele, nu doar metrici, statistici, ci \u0219i jurnale: cum a fost lansat\u0103 aplica\u021bia, anomalii \u2014 aduna\u021bi totul. <\/p>\n

\u00cen caz contrar, va fi greu s\u0103 v\u0103 descurca\u021bi. Am spus deja c\u0103 DevOps reprezint\u0103 o complexitate mai mare. Pentru a face fa\u021b\u0103 acestei complexit\u0103\u021bi, trebuie s\u0103 ave\u021bi o analiz\u0103 normal\u0103.<\/b>.<\/p>\n

\u00centreb\u0103ri pentru autoevaluare<\/h3>\n

\nMonitorizarea \u0219i logarea voastr\u0103 sunt un instrument de dezvoltare pentru voi?<\/b> Dezvoltatorii vo\u0219tri, inclusiv voi, atunci c\u00e2nd scriu cod, se g\u00e2ndesc la cum s\u0103-l monitorizeze?<\/p>\n

Afla\u021bi problemele de la clien\u021bi? \u00cei \u00een\u021belege\u021bi mai bine pe clien\u021bi din monitorizare \u0219i logare?<\/b> \u00cen\u021belege\u021bi mai bine sistemul din monitorizare \u0219i logare?<\/b> Schimba\u021bi sistemul doar pentru c\u0103 a\u021bi observat c\u0103 tendin\u021ba din sistem cre\u0219te \u0219i \u00een\u021belege\u021bi c\u0103 mai sunt 3 s\u0103pt\u0103m\u00e2ni \u0219i totul va colapsa? <\/p>\n

C\u00e2nd ave\u021bi aceste trei componente, pute\u021bi s\u0103 v\u0103 g\u00e2ndi\u021bi la ce infrastructur\u0103 are compania dumneavoastr\u0103.<\/p>\n

Infrastructur\u0103 platform\u0103 <\/h2>\n

\nSensul nu este c\u0103 acesta este un set de instrumente fragmentate, care exist\u0103 \u00een fiecare companie.<\/p>\n

Sensul infrastructurii platformei este c\u0103 toate echipele folosesc aceste instrumente \u0219i le dezvolt\u0103 \u00eempreun\u0103.<\/p><\/blockquote>\n

\nEste clar c\u0103 exist\u0103 echipe separate care sunt responsabile pentru dezvoltarea unor p\u0103r\u021bi distincte ale infrastructurii platformei. Dar \u00een acela\u0219i timp, responsabilitatea pentru dezvoltarea, func\u021bionalitatea, promovarea infrastructurii platformei revine fiec\u0103rui inginer. La nivel intern, acesta devine un instrument comun<\/b>. <\/p>\n

Toate echipele dezvolt\u0103 platforma infrastructural\u0103, trat\u00e2nd-o cu grij\u0103 ca pe propriul IDE<\/b>. \u00cen IDE-ul dvs. instala\u021bi diferite plugin-uri pentru a avea totul frumos \u0219i rapid, set\u00e2nd taste rapide. C\u00e2nd deschide\u021bi Sublime, Atom sau Visual Studio Code, apar erori de cod \u0219i \u00een\u021belege\u021bi c\u0103 este imposibil s\u0103 lucra\u021bi, v\u0103 sim\u021bi\u021bi imediat trist \u0219i fugi\u021bi s\u0103 v\u0103 repara\u021bi IDE-ul.<\/p>\n

La fel ar trebui s\u0103 trata\u021bi platforma dvs. infrastructural\u0103. Dac\u0103 \u00een\u021belege\u021bi c\u0103 nu este bine, l\u0103sa\u021bi o solicitare, dac\u0103 nu pute\u021bi s\u0103 o repara\u021bi singuri. Dac\u0103 este ceva simplu, corecta\u021bi singuri, trimite\u021bi un pull request - b\u0103ie\u021bii \u00eel analizeaz\u0103, \u00eel adaug\u0103. Aceasta este o abordare pu\u021bin diferit\u0103 fa\u021b\u0103 de instrumentarul ingineresc din mintea dezvoltatorului.<\/p>\n

Platforma infrastructural\u0103 asigur\u0103 transferul artefactului de la dezvoltare la client, cu o cre\u0219tere constant\u0103 a calit\u0103\u021bii<\/b>. \u00cen IP sunt programate un set de pove\u0219ti care se \u00eent\u00e2mpl\u0103 cu codul \u00een produc\u021bie. De-a lungul anilor de dezvoltare, devin foarte multe pove\u0219ti, unele dintre ele fiind unice \u0219i referindu-se doar la dvs. - nu sunt u\u0219or de g\u0103sit pe Google. <\/p>\n

\u00cen acest moment, platforma infrastructural\u0103 devine avantajul dvs. competitiv<\/b>, pentru c\u0103 con\u021bine ceea ce nu are instrumentul competitorului. Cu c\u00e2t platforma dvs. este mai profund\u0103, cu at\u00e2t avantajul dvs. competitiv \u00een termeni de Time-to-market este mai mare. Aici apare problema vendor lock<\/b>: pute\u021bi lua o platform\u0103 str\u0103in\u0103, dar folosind experien\u021ba altora, nu ve\u021bi \u00een\u021belege c\u00e2t de relevant\u0103 este pentru dvs. Da, nu orice companie poate construi o platform\u0103 de tip Amazon. Este o limit\u0103 complex\u0103, unde experien\u021ba companiei este relevant\u0103 pentru pozi\u021bia sa pe pia\u021b\u0103, iar vendor lock nu trebuie s\u0103 fie permis \u00een acea zon\u0103. Despre acest lucru este important s\u0103 reflecta\u021bi.<\/p>\n

Schema<\/h3>\n

\nAceasta este schema de baz\u0103 a platformei infrastructurale, care v\u0103 va ajuta s\u0103 stabili\u021bi toate practicile \u0219i procesele dintr-o companie DevOps.<\/p>\n

\"Ce
\n
\nS\u0103 vedem din ce este format\u0103.<\/p>\n

Sistemul de orchestrare a resurselor<\/b>, care ofer\u0103 CPU, memorie, disc aplica\u021biilor \u0219i altor servicii. Deasupra acestuia - servicii de nivel inferior<\/b>: monitorizare, \u00eenregistrare, CI\/CD Engine, stocare de artefacte, infrastructur\u0103 ca cod a sistemelor.<\/p>\n

Servicii de nivel superior<\/b>: baze de date ca serviciu, queue ca serviciu, Load Balance ca serviciu, redimensionarea imaginilor ca serviciu, Big Data fabrica ca serviciu. Deasupra acestora \u2014 un pipeline care furnizeaz\u0103 cod modificat constant clientului dumneavoastr\u0103<\/b>.<\/p>\n

Ob\u021bine\u021bi informa\u021bii despre cum func\u021bioneaz\u0103 software-ul dumneavoastr\u0103 la client, modifica\u021bi-l, livra\u021bi din nou acest cod, ob\u021bine\u021bi informa\u021bii \u2014 \u0219i a\u0219a dezvolta\u021bi constant at\u00e2t platforma infrastructural\u0103, c\u00e2t \u0219i software-ul dumneavoastr\u0103.<\/p>\n

\u00cen diagram\u0103, delivery pipeline-ul const\u0103 dintr-o serie de etape. Dar acesta este un model concept, care este oferit ca exemplu \u2014 nu este necesar s\u0103-l repeta\u021bi unul la unul. Etapele interac\u021bioneaz\u0103 cu serviciile, ca servicii \u2014 fiecare c\u0103r\u0103mid\u0103 a platformei are propria poveste: cum sunt alocate resursele, cum este lansat\u0103 aplica\u021bia, cum lucreaz\u0103 cu resursele, cum este monitorizat\u0103 \u0219i modificat\u0103.<\/p>\n

Este important s\u0103 \u00een\u021belege\u021bi c\u0103 fiecare parte a platformei poart\u0103 o poveste \u0219i s\u0103 v\u0103 \u00eentreba\u021bi \u2014 ce poveste poart\u0103 aceast\u0103 c\u0103r\u0103mid\u0103, poate ar trebui s\u0103 o elimina\u021bi \u0219i s\u0103 o \u00eenlocui\u021bi cu un serviciu extern. De exemplu, este posibil s\u0103 putem folosi Okmeter \u00een loc de c\u0103r\u0103mid\u0103? Posibil, b\u0103ie\u021bii au dezvoltat aceast\u0103 expertiz\u0103 mult mai mult dec\u00e2t noi. Dar poate c\u0103 nu \u2014 poate c\u0103 avem o expertiz\u0103 unic\u0103, trebuie s\u0103 implement\u0103m Prometheus \u0219i s\u0103 dezvolt\u0103m asta mai departe.<\/p>\n

Crearea platformei<\/h3>\n

\nEste un proces de comunicare complex. C\u00e2nd ave\u021bi practici de baz\u0103, lansa\u021bi comunicarea \u00eentre diferi\u021bi ingineri \u0219i speciali\u0219ti care dezvolt\u0103 cerin\u021be \u0219i standarde, \u0219i le modific\u0103 constant pentru diferite instrumente \u0219i abord\u0103ri. Aici cultura este important\u0103, ceea ce exist\u0103 \u00een DevOps.<\/p>\n

\"Ce
\nCu cultura, totul este foarte simplu \u2014 este colaborare \u0219i comunicare<\/b>, adic\u0103 dorin\u021ba de a lucra \u00eempreun\u0103 \u00een acela\u0219i domeniu, dorin\u021ba de a de\u021bine un singur instrument \u00eempreun\u0103. Aici nu exist\u0103 \u0219tiin\u021ba rachetelor \u2014 totul este foarte simplu, banal. De exemplu, to\u021bi tr\u0103im \u00een aceea\u0219i scara \u0219i men\u021binem cur\u0103\u021benia \u2014 un astfel de nivel de cultur\u0103.<\/p>\n

\u0218i la voi?<\/h3>\n

\nDin nou, \u00eentreb\u0103ri pe care vi le pute\u021bi pune.<\/p>\n

Este platforma infrastructural\u0103 definit\u0103? Cine este responsabil pentru dezvoltarea ei? \u00cen\u021belege\u021bi avantajele competitive ale platformei dumneavoastr\u0103 infrastructurale?<\/p>\n

Aceste \u00eentreb\u0103ri trebuie s\u0103 \u021bi le pui constant. Dac\u0103 po\u021bi externaliza ceva la servicii ter\u021be, ar trebui s\u0103 faci asta; dac\u0103 un serviciu ter\u021b \u00eencepe s\u0103 blocheze mi\u0219carea ta, trebuie s\u0103 construie\u0219ti un sistem intern.<\/p>\n

A\u0219adar, DevOps...<\/h2>\n

\n... este un sistem complex, \u00een care trebuie s\u0103 existe:<\/p>\n