Definirea DevOps este foarte complexă, așa că trebuie să reluăm discuția de fiecare dată. Numai pe Habr sunt o mie de publicații pe acest subiect. Dar dacă citești asta, este evident că știi ce este DevOps. Pentru că eu nu știu. Bună, mă numesc Alexandru Titov (@), și vom vorbi despre DevOps iar eu voi împărtăși experiența mea.
Am reflectat mult la cum să fac povestea mea utilă, așa că vor fi multe întrebări – cele pe care mi le pun singur și cele pe care le adresez clienților companiei noastre. Răspunzând la aceste întrebări, înțelegerea devine mai bună. Voi explica de ce este nevoie de DevOps din perspectiva mea, ce înseamnă, din nou, din punctul meu de vedere și cum să înțelegi dacă progresezi către DevOps, din aceeași perspectiva a mea. Ultimul punct va fi prin întrebări. Răspunzând la ele, vei putea să înțelegi dacă compania ta se îndreaptă către DevOps sau dacă există probleme.
O vreme, am navigat prin valurile fuziunilor și achizițiilor. La început am lucrat într-un mic startup numit Qik, apoi a fost achiziționat de o companie un pic mai mare, Skype, care a fost apoi cumpărată de Microsoft, o companie și mai mare. În acel moment, am avut o viziune despre cum se transformă percepția asupra DevOps în companii de diferite dimensiuni. După aceea, am devenit interesat de DevOps din punct de vedere al pieței, iar împreună cu colegii am organizat compania Express 42. De 6 ani, navigăm pe această companie pe valurile pieței.
În plus, sunt unul dintre organizatorii comunității DevOps Moscow și organizator al DevOps Days 2017, dar în 2018 nu am organizat. Express 42 colaborează cu multe companii. Dezvoltăm DevOps acolo, observăm cum se întâmplă, facem concluzii, analizăm, împărtășim concluziile noastre tuturor, instruim oamenii în practicile DevOps. În general, creștem experiența și expertiza în acest sens.
De ce DevOps
Prima întrebare care îi urmărește pe toți mereu este: de ce? Mulți consideră că DevOps este doar automatizare sau ceva asemănător, care a existat deja în fiecare companie.
— Am avut Continuous Integration — asta înseamnă că deja aveam DevOps, așa că de ce avem nevoie de tot acest lucru? Acolo în străinătate se distrează, iar nouă ne stau în cale!
În cei 9 ani de dezvoltare a comunității și a metodologiei, s-a înțeles deja că nu este doar o atracție de marketing, dar nu este încă clar de ce este necesar. Ca orice instrument și proces, DevOps are obiective specifice pe care le rezolvă în cele din urmă.
Toate acestea sunt legate de faptul că lumea se schimbă. Se îndepărtează de abordarea enterprise, când companiile își ating visul, așa cum cânta clasicul nostru din Sankt Petersburg, din punctul A în punctul B conform unei strategii definite, cu o structură specifică construită pentru aceasta.
În principiu, IT-ul ar trebui să fie construit pe această abordare. Aici, IT-ul este utilizat exclusiv pentru automatizarea proceselor.
Automatizarea nu se schimbă adesea, deoarece atunci când compania merge pe un drum bătătorit - ce să schimbi? Funcționează - nu atinge. Acum, în lume, abordările se schimbă, iar cel numit Agile spune că punctul final B nu este vizibil imediat.
Când o companie se deplasează pe piață, lucrează cu clienți - ea explorează constant piața și își schimbă punctul final B. În plus, cu cât o companie își schimbă direcția mai des, cu atât mai mult va avea succes, deoarece alege mai multe nișe de piață.
Strategia este demonstrată de o companie interesantă de care am aflat recent. One Box Shave - un serviciu de livrare de rasuri și accesorii de ras printr-o subscripție în cutie. Ei pot personaliza "cutia" lor pentru diferiți clienți. Acest lucru este realizat de un software specific, care apoi trimite comanda către o fabrică din Coreea de Sud care produce produsul.
Acest produs a fost cumpărat de compania Unilever pentru 1 miliard de dolari. Acum competiționează cu Gillette și i-a furat o parte semnificativă din consumatori pe piața americană. One Box Shave spune:
- 4 lame? Chiar așa? De ce ai nevoie de asta - nu îmbunătățește deloc calitatea bărbieritului. O cremă special aleasă, un parfum și un aparat de ras de calitate cu două lame rezolvă mult mai multe probleme decât cele patru lame stupide de la Gillette! Așa că, în curând, ajungem la 10?
Așa se schimbă lumea. Unilever afirmă că au un sistem IT grozav, care permite acest lucru. În cele din urmă, acesta arată ca o concepție Time-to-market, despre care au vorbit deja mulți.
Sensul Time-to-market nu constă în cât de des ne desfășurăm. Se poate desfășura frecvent, dar ciclurile de lansare vor fi lungi. Dacă suprapunem ciclurile de lansare de trei luni, mutându-le cu o săptămână, se pare că compania desfășoară o dată pe săptămână. Dar între idee și realizarea finală trec 3 luni.
Time-to-market se referă la minimizarea timpului de la idee la realizarea finală.
În acest caz, software-ul interacționează cu piața. Astfel, One Box Shave interacționează cu clientul prin intermediul site-ului. Nu au vânzători - doar un site, unde vizitatorul face clic și lasă dorințele. Prin urmare, pe site trebuie să postăm constant ceva nou, actualizându-l conform dorințelor. De exemplu, în Coreea de Sud se rade altfel decât în Rusia, iar lor le place să miroasă nu a pin, ci, de exemplu, a vanilie cu morcov.
Deoarece este necesar să schimbați rapid conținutul site-ului, dezvoltarea software-ului se schimbă semnificativ. Prin software trebuie să aflăm ce vrea clientul. În trecut, aflam acest lucru prin anumite metode indirecte, de exemplu, prin managementul afacerilor. Apoi proiectam, integrau cerințele în sistemele IT, și totul era grozav. Acum lucrurile stau diferit - software-ul este proiectat de toți cei implicați în proces, inclusiv inginerii, deoarece ei află din specificațiile tehnice cum funcționează piața și își împărtășesc și cu afacerea insights-urile lor.
De exemplu, în compania Qik am aflat brusc că oamenilor le place foarte mult să încarce listele de contacte pe server și ne-au dat o aplicație. Inițial, nu ne gândisem la asta. Într-o companie clasică, toți ar fi decis că este un bug, deoarece în specificații nu este menționat că trebuie să funcționeze grozav și, în general, a fost realizat în pripă, ar fi dezactivat funcția și ar fi spus: „Nu este nevoie de asta, cel mai important este că funcționalitatea principală funcționează”. Dar o companie tehnologică vede aici o oportunitate și începe să schimbe software-ul în conformitate cu acest lucru.
În 1968, un tip prezicător pe nume Melvin Conway a formulat următoarea idee.
O organizație care creează un sistem este limitată de designul care copiază structura comunicării în această organizație.
Dacă detaliem, pentru a produce sisteme de alt tip, trebuie de asemenea să aveți o structură de comunicare diferită în cadrul companiei. Dacă aveți o structură de comunicare ierarhică superioară, aceasta nu vă va permite să creați sisteme care pot oferi un timp de lansare pe piață foarte ridicat.
Citiți poate . Este important pentru înțelegerea culturii sau filozofiei DevOps, deoarece singurul lucru care se schimbă fundamental în DevOps este chiar structura de comunicare dintre echipe..
Din punct de vedere al procesului, înainte de DevOps, toate etapele: analiza, dezvoltarea, testarea, operarea, se desfășurau linear.
În cazul DevOps, toate aceste procese se desfășoară simultan.
Timpul de lansare pe piață poate fi realizat doar astfel. Pentru persoanele care au lucrat în vechiul proces, acest lucru pare oarecum SF și, în general, nu este deloc bine.
Deci, de ce avem nevoie de DevOps?
Pentru dezvoltarea produselor digitale.Dacă în compania dumneavoastră nu există un produs digital, DevOps nu este necesar - acest lucru este foarte important.
DevOps depășește limitele de viteză ale schemei de producție secvențială a software-ului.În cadrul său, toate procesele au loc simultan.
Complexitatea crește. Când evangheliștii DevOps spun că va deveni mai ușor să lansați software - aceasta este o prostie.
Cu DevOps, totul va deveni doar mai complicat.
La conferință, la standul Avito, puteați observa ce înseamnă să desfășurați un container Docker - o sarcină nerealistă. Complexitatea devine excesivă, trebuie să jonglați cu foarte multe mingi simultan.
DevOps schimbă complet procesul și organizația din companie — mai precis, nu DevOps schimbă, ci produsul digital. Pentru a ajunge la DevOps, trebuie totuși să schimbați complet acest proces.
Întrebări pentru specialist
Dar dumneavoastră ce aveți? Întrebări pe care vă puteți pune lucrând în companie și dezvoltându-vă ca specialist.
Aveți o strategie pentru crearea unui produs digital? Dacă da - deja este bine. Asta înseamnă că compania dumneavoastră se îndreaptă spre DevOps.
Compania dumneavoastră produce deja un produs digital? Asta înseamnă că puteți să urcați încă pe o treaptă mai sus, ocupându-vă de lucruri mai interesante - din punct de vedere al DevOps, din nou. Asta doar din acest punct de vedere spun.
Compania dumneavoastră este unul dintre liderii de piață în nișa cu produsul digital? Spotify, Yandex, Uber - companii care se află la vârful progresului tehnologic în prezent.
Puneți-vă aceste întrebări, și dacă toate răspunsurile sunt negative, atunci poate că nu ar trebui să vă ocupați de DevOps în această companie. Dacă, totuși, subiectul DevOps vă interesează cu adevărat, poate că ar trebui să treceți în altă companie? Dacă compania dumneavoastră dorește să adopte DevOps, dar ați răspuns „Nu” la toate întrebările, atunci aceasta se aseamănă cu un rinocer minunat, care nu se va schimba niciodată.
Organizare
Așa cum am spus deja, conform legii lui Conway, organizația din companie se schimbă. Voi începe cu ceea ce împiedică DevOps să pătrundă în interiorul companiei, din perspectiva organizației.
Problema „silo-urilor”
Cuvântul englezesc „Silo” a fost tradus aici în rusă ca „silo”. Sensul acestei probleme constă în faptul că între echipe nu există schimb de informații. Fiecare echipă își sape expertiza în adâncime, fără a construi o hartă comună, pe care să se poată orienta.
Acest lucru aduce aminte de o persoană care a venit recent în Moscova și care nu știe încă să se orienteze pe harta metroului. Moscoviții cunosc de obicei bine zona lor, iar pentru întreaga Moscovă se bazează pe harta metroului. Când vii în Moscova pentru prima dată, nu ai această abilitate și ești pur și simplu dezorientat.
DevOps propune să treacă peste acest moment de dezorientare și să construiască împreună cu toate subdiviziunile o hartă comună de interacțiune.
Acest lucru este împiedicat de doi factori.
Consecință a sistemului de gestionare corporativ. Este construit din silo-uri ierarhice separate. De exemplu, există anumite KPI-uri în companii care susțin acest sistem. Pe de altă parte, dificultățile sunt cauzate de faptul că oamenii le este greu să iasă dincolo de expertiza lor și să se orienteze în întregul sistem. Este pur și simplu inconfortabil. Imaginați-vă că ați ajuns în aeroportul din Bangkok - acolo nu te poți orienta rapid. La fel este și în DevOps, și din acest motiv oamenii spun că trebuie să găsești un ghid pentru a ajunge acolo.
Dar cel mai important, problema „silo-urilor” pentru un inginer care a adoptat spiritul DevOps, a citit Fowler și o mulțime de alte cărți, se prezintă astfel că „silo-urile” nu permit efectuarea lucrurilor „evidente”. Adesea, ne întâlnim după DevOps Moscow, discutăm între noi și oamenii se plâng:
— Voiam să lansăm doar CI, dar se pare că managementul nu are nevoie de asta.
Acest lucru se întâmplă tocmai din cauza că CI și procesul Continuous Delivery se află la granița mai multor expertize. Pur și simplu, fără a depăși problema „fântânilor” la nivel organizațional, nu veți putea avansa mai departe, indiferent de ceea ce faceți și cât de trist ar fi acest lucru.
Fiecare participant la proces în companie: dezvoltatori de backend și frontend, testeri, DBA, operațiuni, rețea, își îndreaptă atenția spre direcția sa, iar nimeni nu deține o hartă comună, în afară de manager, care somehow îi observă și îi gestionează prin metoda „divide și conduci”.
Oamenii se luptă pentru anumite stele sau steaguri, fiecare își aprofundând expertiza.
În cele din urmă, când apare sarcina de a conecta toate acestea împreună și de a construi un pipeline comun, și nu mai este nevoie să se lupte pentru stele și steaguri, apare întrebarea — ce trebuie să facem de fapt? Trebuie să ne înțelegem cumva, dar cum să facem asta, nimeni nu ne-a învățat la școală. Încă din școală, am fost învățați: clasa a opta — wow! — comparativ cu clasa a șaptea! Aici este același lucru.
Așa este și în compania dumneavoastră?
Pentru a verifica acest lucru, puteți să vă puneți următoarele întrebări.
Folosesc echipele instrumente comune, contribuie la modificările acestor instrumente comune?
Cât de des se reconfigurează echipele — unii specialiști dintr-o echipă trec în altă echipă? Exact în mediu DevOps, acest lucru devine normal, deoarece uneori o persoană pur și simplu nu poate înțelege ce face o altă zonă de expertiză. Se mută în alt departament, lucrează două săptămâni acolo pentru a crea pentru sine o hartă de orientare și interacțiune cu acest departament.
Se poate crea un comitet pentru schimbare și se poate schimba ceva? Sau pentru asta este nevoie de o mână puternică a conducătorilor cei mai înalți și de un ordin? Recent am scris pe Facebook despre cum o bancă puțin cunoscută implementează instrumente prin ordine: au emis un ordin, implementăm timp de un an, observăm ce se întâmplă. Este, desigur, îndelungat și trist.
Cât de important este pentru manageri să obțină realizări personale fără a lua în considerare realizările companiei?
Dacă răspundeți la aceste întrebări pentru dumneavoastră, va fi mai clar dacă aveți o astfel de problemă în companie.
Infrastructure as Code
După ce am depășit această problemă, prima practică importantă, fără de care este greu să avansezi în DevOps, este infrastructura ca cod.
Cel mai adesea, infrastructura ca și cod este percepută astfel:
— Să automatizăm totul pe bash, să ne umplem de scripturi, pentru ca adminii să aibă mai puțin de lucru manual!
Dar nu este așa.
Infrastructura ca și cod implică faptul că sistemul IT cu care lucrezi îl descrii sub formă de cod, pentru a înțelege constant starea acestuia.
Împreună cu alte echipe, creezi o hartă sub formă de cod, care este clară pentru toți, pe baza căreia se poate naviga. Nu are importanță ce folosesc pentru aceasta - Chef, Ansible, Salt, sau dacă se folosesc fișiere YAML în Kubernetes - nu contează.
La conferință, 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ă această descriere. Când există această descriere, fiecare poate verifica informațiile între ei, monitoriza schimbările, cum să le modifice și să le îmbunătățească, ce lipsește.
Fiți de acord, scripturile bash separate de obicei nu oferă această înțelegere. La una dintre companiile unde am lucrat, exista chiar o denumire „script write only” - când scriptul este scris, dar nu mai poate fi citit. Cred că și pentru voi este familiar.
Infrastructura ca și cod este cod care descrie starea actuală a infrastructurii. Acest cod este colaborativ între numeroase echipe de produs, infrastructură și servicii și, cel mai important, toate acestea trebuie să înțeleagă cum funcționează acest cod.
Codul este gestionat conform celor mai bune practici de lucru cu codul: dezvoltare colaborativă, revizuirea codului, XP-programming, testare, pull requests, CI pentru codul infrastructural - toate acestea sunt utile și pot fi utilizate.
Codul devine un limbaj comun pentru toți inginerii.
Modificarea infrastructurii în cod nu durează mult timp.. Da, în codul infrastructural poate exista și o datorie tehnică. De obicei, echipele se confruntă cu aceasta după aproximativ un an și jumătate de la implementarea „infrastructurii ca cod” sub formă de mulțime de scripturi sau chiar Ansible, pe care le scriu ca și cum ar fi cod spaghetti și mai adaugă și scripturi bash în mixtură!
Este important: dacă nu ați încercat până acum această porcărie, rețineți că Ansible nu este bash! Citiți cu atenție documentația, studiați ce se scrie despre aceasta.
Infrastructura ca și cod - este separarea codului infrastructural în straturi distincte.
La compania noastră, distingem 3 straturi fundamentale, care sunt foarte clare și simple, dar pot exista mai multe. Puteți să vă verificați codul infrastructural și să spuneți dacă aveți sau nu această condiție. Dacă nu sunt delimitate straturi, trebuie să alocați timp pentru a refactoriza puțin.
Stratul de bază este modul în care se configurează OS-ul, backup-urile și alte lucruri de nivel inferior, de exemplu, modul în care se desfășoară Kubernetes la nivel de bază.
Nivelul serviciilor este acele servicii pe care le oferiți dezvoltatorului: logging ca serviciu, monitorizare ca serviciu, bază de date ca serviciu, load balancer ca serviciu, queue ca serviciu, Continuous Delivery ca serviciu - o mulțime de servicii pe care echipe separate le pot oferi dezvoltării. Este important să descrieți toate acestea prin module separate în sistemul dumneavoastră de gestionare a configurației.
Stratul în care se dezvoltă aplicațiile și se descrie modul în care acestea vor fi desfășurate peste cele două straturi anterioare.
Întrebări de control
Aveți în compania dumneavoastră un depozit infrastructural comun? Controlați datoria tehnică în infrastructură? Utilizați practici de dezvoltare în depozitul infrastructural? Este infrastructura dumneavoastră împărțită în straturi? Puteți verifica schema Base-service-APP. Cât de dificil este să faceți o modificare?
Dacă v-ați lovit de faptul că efectuarea schimbărilor dura o zi și jumătate, înseamnă că ați acumulat o datorie tehnică și trebuie să lucrați cu ea. Ați dat peste capcanele datoriei tehnice în codul infrastructural. Îmi amintesc multe astfel de povești, când, pentru a schimba un anumit CCTL, trebuie să rescrieți jumătate din codul infrastructural, pentru că creativitatea și dorința de a automatiza totul au dus la situația în care totul este complet încurcat, toate manetele au fost eliminate, iar acum trebuie să refactorizați.
Livrare continuă
Să punem cap la cap debitul și creditul. Inițial apare o descriere a infrastructurii, care poate fi destul de bazică. Nu este obligatoriu să descrieți totul în detaliu, dar este necesară o descriere de bază pentru a putea lucra cu acest lucru. Altfel, nu este clar cum să realizați livrarea continuă. Toate aceste practici se desfășoară simultan, atunci când ajungeți la DevOps, dar trebuie să începeți prin a înțelege ce aveți și cum să gestionați acest lucru. Aceasta este practica infrastructurii ca și cod.
După ce a devenit clar ce aveți și cum să gestionați, începeți să născociți cum să trimiteți rapid codul dezvoltatorului în producție. Mă refer la împreună cu dezvoltatorul - să ne amintim de problema „fântânilor”, adică nu o echipă separată vine cu idei, ci este un efort comun.
Când ne-am întâlnit cu Vania Evtuhovich și am văzut prima cărticică a lui Jez Humble și a grupului de autori «Continuous Delivery», care a fost publicată în 2009, ne-am gândit mult la cum să traducem titlul ei în limba română. Am vrut să-l traducem ca «Livrare continuă», dar, din păcate, l-am tradus ca «Livrare continuă». Mi se pare că în titlul nostru există ceva românesc, cu o forță aparte.
Livrarea continuă înseamnă
Codul care se află în depozitul de produse poate fi oricând trimis în producție. El poate să nu fie trimis, dar este întotdeauna gata pentru asta. În consecință, întotdeauna scrieți cod cu un sentiment greu de explicat de neliniște în zona inferioară a spatelui. Acest sentiment de neliniște ar trebui să fie prezent - el declanșează procese mentale care permit scrierea codului într-un mod puțin diferit. Acesta trebuie să fie documentat în regulile din cadrul dezvoltării.
Pentru a livra continuu, este necesar un format de artefact care trece prin platforma de infrastructură. Dacă aruncați pe platforma de infrastructură deșeuri de format diferit, aceasta devine neuniformă, este greu de întreținut, apare problema datoriei tehnice. Formatul artefactului trebuie să fie standardizat - este o sarcină colectivă: trebuie să ne adunăm cu toții, să ne punem mințile la contribuție și să gândim acest format.
Artifactul se îmbunătățește continuu și se adaptează la mediul de producție în timpul fluxului de livrare. Când artifactul se mișcă prin flux, se confruntă tot timpul cu diverse obstacole, asemănătoare cu cele pe care le întâlnește artefactul pe care îl publicați în producție. Dacă în dezvoltarea clasică acest lucru este gestionat de un administrator de sistem care efectuează livrarea, în procesul DevOps se întâmplă constant: aici este supus unor teste, acolo este aruncat într-un cluster Kubernetes, care este mai mult sau mai puțin similar cu producția, iar apoi este supus unor teste de stres.
Acest lucru amintește cumva de jocul Pac-Man - artifactul parcurge o anumită poveste. Este important să controlați dacă codul trece prin acea poveste și dacă este legată de producția dumneavoastră. Poveștile despre producție pot fi integrate în procesul Continuous Delivery: a fost așa când ceva a eșuat, acum haideți să programăm acest scenariu în sistem. De fiecare dată, codul va trece prin acest scenariu și nu veți mai întâlni această problemă. Veți afla despre ea mult mai devreme decât va ajunge la clientul dumneavoastră.
Diverse strategii de livrare. De exemplu, utilizați testarea AB sau livrări canar pentru a "simți" codul diferit pe clienți diferiți, obținând informații despre cum funcționează codul, cu mult înainte ca acesta să fie livrat la 100 de milioane de utilizatori.
"Livrarea continuă" arată așa.
Procesul de livrare Dev, CI, Test, PreProd, Prod - nu este un mediu separat, ci etape sau stații cu sume ineficiente, pe care artifactul dumneavoastră le parcurge.
Dacă aveți cod infrastructural descris ca Base Service APP, acesta ajută să nu uitați toate scenariile, și să le înregistrați și sub forma de cod pentru acest artifact, să avansați artifactul și să îl modificați pe parcurs.
Întrebări pentru autoevaluare
Este timpul de la descrierea funcționalității până la livrarea în producție în 95% din cazuri mai mic de o săptămână? Se îmbunătățește calitatea artifactului la fiecare etapă a fluxului? Există o poveste pe care o parcurge? Folosiți diferite strategii de livrare?
Dacă toate răspunsurile sunt da, atunci sunteți incredibil de buni! Scrieți răspunsurile în comentarii - aș fi încântat).
Feedback-ul
Aceasta este cea mai complicată practică dintre toate. La conferința DevOpsConf, un coleg de la Infobip s-a încurcat ușor în cuvinte vorbind despre ea, pentru că este cu adevărat o practică foarte complexă despre ceea ce trebuie să monitorizăm de fapt totul!
De exemplu, cu mult timp în urmă, când lucram la Qik și ne-am dat seama că trebuie să monitorizăm de fapt totul. Am făcut asta și am avut în Zabbix 150.000 de itemi, care sunt monitorizați constant. A fost înfricoșător, directorul tehnic își învârtea degetul la tâmplă:
— Baieti, de ce maltratați serverul cu lucruri neclare?
Dar apoi a avut loc un incident care a arătat că aceasta este într-adevăr o strategie foarte bună.
Unul dintre servicii a început să cadă constant. Inițial nu cădea, ceea ce este interesant, acolo nu se adăuga cod, pentru că era un broker de bază, în care practic nu exista funcționalitate de afaceri — pur și simplu transmitea mesaje între servicii separate. Serviciul nu s-a schimbat timp de 4 luni și, dintr-o dată, a început să cadă cu eroarea „Segmentation fault”.
Ficeam în șoc, am deschis graficele în Zabbix și am aflat că, de fapt, cu o săptămână și jumătate în urmă, comportamentul cererilor în serviciul API s-a schimbat semnificativ. Apoi am verificat că s-a schimbat frecvența trimiterii unui anumit tip de mesaje. După aceea, am aflat că este vorba despre clienții Android. Am întrebat:
— Băieți, ce s-a întâmplat acum o săptămână și jumătate?
În răspuns am auzit o poveste interesantă despre faptul că au reproiectat UI-ul. Puține persoane ar spune imediat că au schimbat biblioteca HTTP. Pentru clienții Android este ca și cum ai schimba săpunul din baie — pur și simplu nu își amintesc. În cele din urmă, după 40 de minute de discuție, am aflat că au schimbat totuși biblioteca HTTP și aceasta a avut timpii default schimbați. Asta a dus la schimbarea comportamentului traficului pe serverul API, ceea ce a dus la o situație care a generat o competiție în interiorul brokerului, făcându-l să cadă.
Fără monitorizare profundă, este complet imposibil să ne dăm seama de asta.. Dacă în organizație există și problema "fânului", când fiecare aruncă vina pe altcineva, aceasta poate continua ani de zile. Pur și simplu reporniți serverul, pentru că nu este posibil să rezolvați problema. Când monitorizați, urmăriți, verificați toate evenimentele pe care le aveți și folosiți monitorizarea ca testare — scrieți codul și imediat specificați cum să fie monitorizat, tot în formă de cod (deja avem infrastructură ca și cod), totul devine clar ca lumina zilei. Chiar și problemele complexe sunt ușor de urmărit.
Adunați toate informațiile despre ceea ce se întâmplă cu artefactul în fiecare etapă a procesului de livrare — nu în producție.
Încărcați monitorizarea în CI, și acolo vor fi vizibile câteva lucruri de bază. Mai departe le veți vedea și în Test, și în PredProd, și în testarea de încărcare. Adunați informații în toate etapele, nu doar metrici, statistici, ci și jurnale: cum a fost lansată aplicația, anomalii — adunați totul.
În caz contrar, va fi greu să vă descurcați. Am spus deja că DevOps reprezintă o complexitate mai mare. Pentru a face față acestei complexități, trebuie să aveți o analiză normală..
Întrebări pentru autoevaluare
Monitorizarea și logarea voastră sunt un instrument de dezvoltare pentru voi? Dezvoltatorii voștri, inclusiv voi, atunci când scriu cod, se gândesc la cum să-l monitorizeze?
Aflați problemele de la clienți? Îi înțelegeți mai bine pe clienți din monitorizare și logare? Înțelegeți mai bine sistemul din monitorizare și logare? Schimbați sistemul doar pentru că ați observat că tendința din sistem crește și înțelegeți că mai sunt 3 săptămâni și totul va colapsa?
Când aveți aceste trei componente, puteți să vă gândiți la ce infrastructură are compania dumneavoastră.
Infrastructură platformă
Sensul nu este că acesta este un set de instrumente fragmentate, care există în fiecare companie.
Sensul infrastructurii platformei este că toate echipele folosesc aceste instrumente și le dezvoltă împreună.
Este clar că există echipe separate care sunt responsabile pentru dezvoltarea unor părți distincte ale infrastructurii platformei. Dar în același timp, responsabilitatea pentru dezvoltarea, funcționalitatea, promovarea infrastructurii platformei revine fiecărui inginer. La nivel intern, acesta devine un instrument comun.
Toate echipele dezvoltă platforma infrastructurală, tratând-o cu grijă ca pe propriul IDE. În IDE-ul dvs. instalați diferite plugin-uri pentru a avea totul frumos și rapid, setând taste rapide. Când deschideți Sublime, Atom sau Visual Studio Code, apar erori de cod și înțelegeți că este imposibil să lucrați, vă simțiți imediat trist și fugiți să vă reparați IDE-ul.
La fel ar trebui să tratați platforma dvs. infrastructurală. Dacă înțelegeți că nu este bine, lăsați o solicitare, dacă nu puteți să o reparați singuri. Dacă este ceva simplu, corectați singuri, trimiteți un pull request - băieții îl analizează, îl adaugă. Aceasta este o abordare puțin diferită față de instrumentarul ingineresc din mintea dezvoltatorului.
Platforma infrastructurală asigură transferul artefactului de la dezvoltare la client, cu o creștere constantă a calității. În IP sunt programate un set de povești care se întâmplă cu codul în producție. De-a lungul anilor de dezvoltare, devin foarte multe povești, unele dintre ele fiind unice și referindu-se doar la dvs. - nu sunt ușor de găsit pe Google.
În acest moment, platforma infrastructurală devine avantajul dvs. competitiv, pentru că conține ceea ce nu are instrumentul competitorului. Cu cât platforma dvs. este mai profundă, cu atât avantajul dvs. competitiv în termeni de Time-to-market este mai mare. Aici apare problema vendor lock: puteți lua o platformă străină, dar folosind experiența altora, nu veți înțelege cât de relevantă este pentru dvs. Da, nu orice companie poate construi o platformă de tip Amazon. Este o limită complexă, unde experiența companiei este relevantă pentru poziția sa pe piață, iar vendor lock nu trebuie să fie permis în acea zonă. Despre acest lucru este important să reflectați.
Schema
Aceasta este schema de bază a platformei infrastructurale, care vă va ajuta să stabiliți toate practicile și procesele dintr-o companie DevOps.
Să vedem din ce este formată.
Sistemul de orchestrare a resurselor, care oferă CPU, memorie, disc aplicațiilor și altor servicii. Deasupra acestuia - servicii de nivel inferior: monitorizare, înregistrare, CI/CD Engine, stocare de artefacte, infrastructură ca cod a sistemelor.
Servicii de nivel superior: baze de date ca serviciu, queue ca serviciu, Load Balance ca serviciu, redimensionarea imaginilor ca serviciu, Big Data fabrica ca serviciu. Deasupra acestora — un pipeline care furnizează cod modificat constant clientului dumneavoastră.
Obțineți informații despre cum funcționează software-ul dumneavoastră la client, modificați-l, livrați din nou acest cod, obțineți informații — și așa dezvoltați constant atât platforma infrastructurală, cât și software-ul dumneavoastră.
În diagramă, delivery pipeline-ul constă dintr-o serie de etape. Dar acesta este un model concept, care este oferit ca exemplu — nu este necesar să-l repetați unul la unul. Etapele interacționează cu serviciile, ca servicii — fiecare cărămidă a platformei are propria poveste: cum sunt alocate resursele, cum este lansată aplicația, cum lucrează cu resursele, cum este monitorizată și modificată.
Este important să înțelegeți că fiecare parte a platformei poartă o poveste și să vă întrebați — ce poveste poartă această cărămidă, poate ar trebui să o eliminați și să o înlocuiți cu un serviciu extern. De exemplu, este posibil să putem folosi Okmeter în loc de cărămidă? Posibil, băieții au dezvoltat această expertiză mult mai mult decât noi. Dar poate că nu — poate că avem o expertiză unică, trebuie să implementăm Prometheus și să dezvoltăm asta mai departe.
Crearea platformei
Este un proces de comunicare complex. Când aveți practici de bază, lansați comunicarea între diferiți ingineri și specialiști care dezvoltă cerințe și standarde, și le modifică constant pentru diferite instrumente și abordări. Aici cultura este importantă, ceea ce există în DevOps.
Cu cultura, totul este foarte simplu — este colaborare și comunicare, adică dorința de a lucra împreună în același domeniu, dorința de a deține un singur instrument împreună. Aici nu există știința rachetelor — totul este foarte simplu, banal. De exemplu, toți trăim în aceeași scara și menținem curățenia — un astfel de nivel de cultură.
Și la voi?
Din nou, întrebări pe care vi le puteți pune.
Este platforma infrastructurală definită? Cine este responsabil pentru dezvoltarea ei? Înțelegeți avantajele competitive ale platformei dumneavoastră infrastructurale?
Aceste întrebări trebuie să ți le pui constant. Dacă poți externaliza ceva la servicii terțe, ar trebui să faci asta; dacă un serviciu terț începe să blocheze mișcarea ta, trebuie să construiești un sistem intern.
Așadar, DevOps...
... este un sistem complex, în care trebuie să existe:
- Un produs digital.
- Module de business care dezvoltă acest produs digital.
- Echipe de produs care scriu cod.
- Practici de livrare continuă.
- Platforme ca serviciu.
- Infrastructură ca serviciu.
- Infrastructură ca și cod.
- Practici separate de menținere a fiabilității, integrate în DevOps.
- Practica feedback-ului, care descrie toate acestea.
Poți folosi această schemă, colorând în ea ceea ce deja ai în companie, în vreun fel: s-a dezvoltat sau trebuie să dezvolți în continuare.
În doar câteva săptămâni va avea loc . în cadrul RIT++. Vino la conferință, unde te așteaptă multe prezentări interesante despre livrarea continuă, infrastructură ca și cod și transformarea DevOps. , ultima dată limită pentru prețuri 20 mai
Sursa: habr.com
