Definiția DevOps este foarte complexă, așa că trebuie să începem discuția despre asta de la capăt de fiecare dată. Există o mie de publicații pe această temă numai despre Habré. Dar dacă citiți asta, probabil că știți ce este DevOps. Pentru că nu sunt. buna numele meu este Alexander Titov (@), și vom vorbi doar despre DevOps și îmi voi împărtăși experiența.
M-am gândit de mult timp la cum să-mi fac povestea utilă, așa că vor fi o mulțime de întrebări aici - cele pe care mi le pun și cele pe care le pun clienților companiei noastre. Răspunzând la aceste întrebări, înțelegerea devine mai bună. Vă voi spune de ce este nevoie de DevOps din punctul meu de vedere, ce este, din nou, din punctul meu de vedere și cum să înțelegeți că vă îndreptați din nou către DevOps din punctul meu de vedere. Ultimul punct va fi prin întrebări. Răspunzând la ele personal, poți înțelege dacă compania ta se îndreaptă către DevOps sau dacă există probleme într-un fel.
La un moment dat călăream pe valurile fuziunilor și achizițiilor. Mai întâi, am lucrat pentru un mic startup numit Qik, apoi a fost cumpărat de o companie puțin mai mare numită Skype, care a fost apoi cumpărată de o companie puțin mai mare numită Microsoft. În acel moment, am început să văd cum se transforma ideea DevOps în companii de diferite dimensiuni. După aceea, am devenit interesat să privesc DevOps din punct de vedere al pieței, iar eu și colegii mei am fondat compania Express 42. De 6 ani ne mișcăm de-a lungul valurilor pieței.
Printre altele, sunt unul dintre organizatorii comunității DevOps Moscova și organizatorul DevOps-Days 2017, dar nu am organizat 2018. Express 42 lucrează cu multe companii. Creștem DevOps acolo, vedem cum se întâmplă, tragem concluzii, analizăm, spunem tuturor concluziile noastre și instruim oamenii în practicile DevOps. În general, facem tot posibilul pentru a ne spori experiența și expertiza în acest sens.
De ce DevOps
Prima întrebare care bântuie pe toată lumea și mereu este - de ce? Mulți oameni cred că DevOps este doar automatizare sau un lucru similar pe care îl avea deja fiecare companie.
— Am avut integrare continuă - asta înseamnă că avem deja DevOps și de ce este nevoie de toate aceste lucruri? Se distrează în străinătate, dar ne împiedică să lucrăm!
Peste 9 ani de dezvoltare a comunității și a metodologiei, a devenit deja clar că acesta nu este încă sclipici de marketing, dar încă nu este complet clar de ce este necesar. Ca orice instrument și proces, DevOps are obiective specifice pe care le atinge în cele din urmă.
Toate acestea se datorează faptului că lumea se schimbă. Se îndepărtează de abordarea întreprinderii, când companiile se îndreaptă direct către un vis, așa cum a cântat clasicul nostru din Sankt Petersburg, de la punctul A la punctul B după o anumită strategie, cu o anumită structură construită pentru asta.
În principiu, totul în IT ar trebui să fie construit conform acestei abordări. Aici IT este folosit exclusiv pentru automatizarea proceselor.
Automatizarea nu se schimbă des, pentru că atunci când o companie coboară pe un drum bine bătut, ce este de schimbat? Funcționează - nu-l atingeți. Acum abordările din lume se schimbă, iar cea numită Agile sugerează că punctul final B nu este vizibil imediat.
Când o companie trece prin piață, lucrează cu un client, explorează constant piața și schimbă punctul final B. Mai mult, cu cât compania își schimbă mai des direcția, cu atât are mai mult succes în final, pentru că alege mai multă piață. nişe.
Strategia este demonstrată de o companie interesantă despre care am aflat recent. One Box Shave este un serviciu de livrare prin abonament pentru aparate de ras și accesorii de bărbierit într-o cutie. Ei știu să își personalizeze „cutia” pentru diferiți clienți. Acest lucru este realizat de un anumit software, care trimite apoi comanda către fabrica coreeană care produce marfa.
Acest produs a fost cumpărat de Unilever pentru 1 miliard de dolari. Acum concurează cu Gillette și a luat o cotă semnificativă de consumatori de pe piața americană. One Box Shave spune:
— 4 lame? esti serios? De ce ai nevoie de asta - nu îmbunătățește calitatea bărbieritului. O cremă special selectată, parfum și un aparat de ras de înaltă calitate cu două lame rezolvă mult mai multe probleme decât acele 4 lame proaste Gillette! Vom ajunge la 10 în curând?
Așa se schimbă lumea. Unilever susțin că au un sistem IT cool care vă permite să faceți acest lucru. Până la urmă pare un concept Timpul pentru cumparaturi, despre care nimeni nu a vorbit deja.
Scopul Time-to-market nu este cât de des implementăm. Puteți implementa adesea, dar ciclurile de lansare vor fi lungi. Dacă ciclurile de lansare de trei luni sunt suprapuse una peste alta, deplasându-le cu o săptămână, se dovedește că compania pare să se desfășoare o dată pe săptămână. Iar de la idee până la implementarea finală durează 3 luni.
Time-to-market se referă la minimizarea timpului de la idee până la implementarea finală.
În acest caz, software-ul interacționează cu piața. Așa interacționează site-ul One Box Shave cu clientul. Nu au agenți de vânzări - doar un site web pe care vizitatorii dau clic și își lasă urări. În consecință, ceva nou trebuie postat constant pe site și actualizat în conformitate cu dorințele. De exemplu, în Coreea de Sud se bărbieresc diferit decât în Rusia și le place nu mirosul de pin, ci, de exemplu, de morcovi și vanilie.
Deoarece este necesar să se schimbe rapid conținutul site-ului, dezvoltarea software-ului se schimbă foarte mult. Prin software trebuie să aflăm ce vrea clientul. Anterior, am învățat acest lucru prin câteva moduri giratorii, de exemplu, prin managementul afacerii. Apoi l-am proiectat, am introdus cerințele în sistemul IT și totul a fost cool. Acum este diferit - software-ul este conceput de toți cei implicați în proces, inclusiv de ingineri, deoarece prin specificațiile tehnice ei învață cum funcționează piața și, de asemenea, își împărtășesc cunoștințele cu afacerea.
De exemplu, la Qik am aflat brusc că oamenilor le plăcea foarte mult să încarce liste de contacte pe server și ne-au furnizat o aplicație. Inițial nu ne-am gândit la asta. Într-o companie clasică, toată lumea ar fi decis că acesta este o eroare, deoarece specificațiile nu spuneau că ar trebui să funcționeze grozav și ar fi fost implementat în general pe genunchi, ar fi dezactivat caracteristica și ar fi spus: „Nimeni nu are nevoie de asta, cel mai important lucru este că funcționalitatea principală funcționează.” . Și compania de tehnologie vede acest lucru ca pe o oportunitate și începe să schimbe software-ul în conformitate cu aceasta.
În 1968, un tip vizionar, Melvin Conway, a formulat următoarea idee.
Organizația care creează sistemul este constrânsă de un design care reproduce structura de comunicare a acelei organizații.
Mai detaliat, pentru a produce sisteme de alt tip, trebuie să ai și o structură de comunicare în cadrul unei companii de alt tip. Dacă structura dvs. de comunicare este ierarhică de sus, atunci acest lucru nu vă va permite să creați sisteme care să ofere un indicator de Time-to-Market foarte ridicat.
Citit Se poate . Este important pentru înțelegerea culturii sau filozofiei DevOps deoarece Singurul lucru care se schimbă fundamental în DevOps este structura de comunicare între echipe.
Din punct de vedere al procesului, înainte de DevOps, toate etapele: analiză, dezvoltare, testare, operare, erau liniare.
În cazul DevOps, toate aceste procese au loc simultan.
Time-to-market este singurul mod în care se poate face. Pentru oamenii care au lucrat în vechiul proces, acest lucru pare oarecum cosmic și, în general, așa este.
Deci, de ce aveți nevoie de DevOps?
Pentru dezvoltarea produselor digitale. Dacă compania ta nu are un produs digital, DevOps nu este necesar - este foarte important.
DevOps depășește limitările de viteză ale producției secvențiale de software. În ea, toate procesele au loc simultan.
Dificultatea crește. Când evangheliștii DevOps vă spun că vă va fi mai ușor să lansați software, acest lucru este un nonsens.
Cu DevOps, lucrurile se vor complica doar.
La conferința de la standul Avito, ați putut vedea cum a fost să implementați un container Docker - o sarcină nerealistă. Dificultatea devine prohibitivă; trebuie să jonglezi cu mai multe bile în același timp.
DevOps schimbă complet procesul și organizarea în companie — mai exact, nu DevOps se schimbă, ci produsul digital. Pentru a veni la DevOps, trebuie totuși să schimbați complet acest proces.
Întrebări pentru un specialist
Ce ai? Întrebări pe care ți le poți pune în timp ce lucrezi într-o companie și te dezvolți ca specialist.
Aveți o strategie pentru crearea unui produs digital? Dacă există, este deja bine. Aceasta înseamnă că compania dumneavoastră se îndreaptă către DevOps.
Compania dvs. creează deja un produs digital? Acest lucru înseamnă că puteți să vă ridicați un alt nivel mai sus și să faceți lucrurile mai interesant - din nou din punct de vedere DevOps. Eu vorbesc doar din acest punct de vedere.
Este compania dumneavoastră unul dintre liderii de piață pe nișa produselor digitale? Spotify, Yandex, Uber sunt companii care se află acum în vârful progresului tehnologic.
Pune-ți aceste întrebări și dacă toate răspunsurile sunt nu, atunci poate că nu ar trebui să faci DevOps la această companie. Dacă subiectul DevOps este cu adevărat interesant pentru tine, poate... ar trebui să te muți la altă companie? Dacă compania ta vrea să intre în DevOps, dar ai răspuns „Nu” la toate întrebările, atunci este ca acel rinocer frumos care nu se va schimba niciodată.
Organizație
După cum am spus, conform Legii lui Conway, organizarea unei companii se schimbă. Voi începe cu ceea ce împiedică DevOps să pătrundă în interiorul companiei din punct de vedere organizațional.
Problema „fântânilor”
Cuvântul englezesc „Silo” este tradus aici în rusă ca „bine”. Ideea acestei probleme este că nu există schimb de informații între echipe. Fiecare echipă sapă adânc în expertiza sa, fără a construi o hartă comună pentru a naviga.
Într-un fel, acest lucru îmi amintește de o persoană care tocmai a sosit la Moscova și încă nu știe cum să navigheze pe harta metroului. De obicei, moscoviții își cunosc foarte bine zona, iar în toată Moscova pot naviga folosind harta metroului. Când vii la Moscova pentru prima dată, nu ai această abilitate și ești doar dezorientat.
DevOps sugerează să treacă peste acest moment de dezorientare și toate departamentele să lucreze împreună pentru a construi o hartă comună de interacțiune.
Doi factori împiedică acest lucru.
Consecința sistemului de management corporativ. Este construit în „fântâni” ierarhice separate. De exemplu, există anumite KPI-uri în companii care susțin acest sistem. Pe de altă parte, creierul unei persoane căreia îi este greu să depășească limitele expertizei și să navigheze în întregul sistem iese în cale. Este pur și simplu incomod. Imaginați-vă că vă aflați pe aeroportul din Bangkok - nu vă veți găsi repede drumul. DevOps este, de asemenea, dificil de navigat și de aceea oamenii spun că trebuie să găsești un ghid pentru a ajunge acolo.
Dar cel mai important lucru este că problema „puțurilor” pentru un inginer care este impregnat de spiritul DevOps, care a citit Fowler și o grămadă de alte cărți, se exprimă în faptul că „fântânile” nu vă permit să faceți lucruri „evidente”.. Ne întâlnim adesea după DevOps Moscova, vorbim unii cu alții și oamenii se plâng:
— Am vrut doar să lansăm CI, dar s-a dovedit că managementul nu avea nevoie de el.
Acest lucru se întâmplă tocmai pentru că CI и Proces de livrare continuă sunt la granița multor examene. Pur și simplu fără a depăși problema „fântânilor” la nivel organizațional, nu vei putea merge mai departe, indiferent ce faci și oricât de trist ar fi.
Fiecare participant la proces în companie: dezvoltatori backend și frontend, testare, DBA, operare, rețea, sapă în propria direcție și nimeni nu are o hartă comună în afară de manager, care îi monitorizează cumva și îi gestionează folosind „divide”. și cucerește”.
Oamenii se luptă pentru niște stele sau steaguri, toată lumea își sapă expertiza.
Drept urmare, atunci când apare sarcina de a conecta toate acestea împreună și de a construi o conductă comună și nu mai este nevoie să luptăm pentru stele și steaguri, apare întrebarea - ce ar trebui să facem? Trebuie să ajungem la o înțelegere cumva, dar nimeni nu ne-a învățat cum să facem asta la școală. Am fost învățați încă de la școală: clasa a VIII-a - wow! - comparativ cu clasa a VII-a! La fel este și aici.
Este la fel și în compania dumneavoastră?
Pentru a verifica acest lucru, vă puteți adresa următoarele întrebări.
Folosesc echipele instrumente comune și contribuie la schimbările aduse acestor instrumente comune?
Cât de des se reorganizează echipele – unii specialiști dintr-o echipă se mută în altă echipă? Acest lucru devine normal într-un mediu DevOps, deoarece uneori o persoană pur și simplu nu poate înțelege ce face un alt domeniu de expertiză. Se mută într-un alt departament, lucrează acolo două săptămâni pentru a-și crea o hartă de orientare și interacțiune cu acest departament.
Este posibil să se formeze un comitet de schimbare și să se schimbe lucrurile? Sau necesită mâna puternică a celui mai înalt management și direcție? Am scris recent pe Facebook cum o bancă puțin cunoscută implementează instrumente prin comenzi: scriem o comandă, o implementăm timp de un an și vedem ce se întâmplă. Acest lucru, desigur, este lung și trist.
Cât de important este ca managerii să primească realizări personale fără a lua în considerare realizările companiei?
Dacă răspundeți singur la aceste întrebări, va deveni mai clar dacă aveți o astfel de problemă în compania dumneavoastră.
Infrastructura ca cod
După ce această problemă este trecută, prima practică importantă, fără de care este dificil să avansezi mai departe în DevOps, este infrastructura ca cod.
Cel mai adesea, infrastructura ca cod este percepută după cum urmează:
— Să automatizăm totul în bash, să ne acoperim cu scripturi, astfel încât administratorii să aibă mai puțină muncă manuală!
Dar asta nu este adevărat.
Infrastructura ca cod înseamnă că descrii sistemul IT cu care lucrezi sub formă de cod pentru a înțelege constant starea acestuia.
Împreună cu alte echipe, creați o hartă sub formă de cod pe care toată lumea îl poate înțelege și poate naviga și naviga. Nu contează pe ce se face – Chef, Ansible, Salt sau folosirea fișierelor YAML în Kubernetes – nu există nicio diferență.
La conferință, un coleg de la 2GIS a povestit cum și-au creat propriul lucru intern pentru Kubernetes, care descrie structura sistemelor individuale. Pentru a descrie 500 de sisteme, aveau nevoie de un instrument separat care generează această descriere. Când există această descriere, toată lumea poate verifica între ei, monitoriza modificările, cum să o schimbe și să o îmbunătățească, ce lipsește.
De acord, scripturile bash individuale nu oferă de obicei această înțelegere. Într-una dintre companiile în care am lucrat, a existat chiar și un nume pentru scriptul „numai scris” - atunci când scenariul este scris, dar nu mai este posibil să îl citești. Cred că îți este familiar și asta.
Infrastructura așa cum este codul cod care descrie starea actuală a infrastructurii. Multe echipe de produse, infrastructură și servicii lucrează împreună la acest cod și, cel mai important, toate trebuie să înțeleagă cum funcționează de fapt acest cod.
Codul este menținut conform celor mai bune practici de cod: dezvoltare în comun, revizuire de cod, programare XP, testare, cereri de extragere, CI pentru infrastructuri de cod - toate acestea sunt potrivite și pot fi utilizate.
Codul devine un limbaj comun pentru toți inginerii.
Schimbarea infrastructurii în cod nu necesită mult timp. Da, codul de infrastructură poate avea și datorii tehnice. De obicei, echipele se confruntă cu asta la un an și jumătate după ce au început să implementeze „infrastructura ca cod” sub forma unei grămadă de scripturi sau chiar Ansible, pe care le scriu ca un cod spaghetti și, de asemenea, aruncă scripturi bash în amestec!
Este important: Dacă nu ați încercat încă aceste lucruri, amintiți-vă Ansible nu este bash! Citiți cu atenție documentația, studiați ce scriu despre ea.
Infrastructura ca cod este separarea codului infrastructurii în straturi separate.
În compania noastră, distingem 3 straturi de bază, care sunt foarte clare și simple, dar pot fi mai multe. Puteți să vă uitați la codul de infrastructură și să spuneți dacă aveți această condiție sau nu. Dacă nu sunt evidențiate straturi, atunci trebuie să vă luați ceva timp și să refactorați puțin.
strat de baza - așa sunt configurate sistemul de operare, backup-urile și alte lucruri de nivel scăzut, de exemplu, modul în care Kubernetes este implementat la nivel de bază.
Nivel de servicii - acestea sunt serviciile pe care le oferiți dezvoltatorului: logare ca serviciu, monitorizare ca serviciu, bază de date ca serviciu, echilibrare ca serviciu, coadă ca serviciu, Livrare continuă ca serviciu - o grămadă de servicii pe care echipele individuale poate asigura dezvoltare. Toate acestea trebuie descrise în module separate în sistemul dumneavoastră de management al configurației.
Stratul în care se fac aplicațiile și descrie modul în care se vor desfășura deasupra celor două straturi anterioare.
Întrebări de control
Compania dvs. are un depozit comun de infrastructură? Gestionați datoria tehnică în infrastructura dvs.? Folosiți practici de dezvoltare într-un depozit de infrastructură? Infrastructura dvs. este tăiată în straturi? Puteți verifica diagrama Base-service-APP. Cât de greu este să faci o schimbare?
Dacă ați experimentat că a durat o zi și jumătate pentru a face modificări, aceasta înseamnă că aveți datorii tehnice și trebuie să lucrați cu ea. Tocmai ați dat peste o rake de datorii tehnice în codul dvs. de infrastructură. Îmi amintesc multe astfel de povești când, pentru a schimba unele CCTL, trebuie să rescrii jumătate din codul de infrastructură, pentru că creativitatea și dorința de a automatiza totul au dus la faptul că totul este corodat peste tot, toate mânerele au fost îndepărtate și este necesară refactorizarea.
Livrare continuă
Să comparăm debitul cu creditul. Mai întâi vine o descriere a infrastructurii, care poate fi destul de simplă. Nu trebuie să descrii totul în detaliu, dar este necesară o descriere de bază pentru a putea lucra cu ea. În caz contrar, nu este clar ce să faci în continuare cu livrarea continuă. Toate aceste practici se desfășoară simultan atunci când veniți la DevOps, dar începe cu înțelegerea a ceea ce aveți și cum să le gestionați. Aceasta este tocmai practica infrastructurii ca cod.
Odată ce devine clar că îl aveți și cum să îl gestionați, începeți să vă dați seama cum să trimiteți codul de dezvoltator la producție cât mai repede posibil. Adică împreună cu dezvoltatorul - ne amintim despre problema „puțurilor”, adică nu oamenii individuali vin cu asta, ci o echipă.
Când suntem cu Vania Evtuhovici am vazut prima carte Jez Humble și grupuri de autori „Livrare continuă”, care a fost lansat în 2009, ne-am gândit mult timp la cum să-i traducem titlul în rusă. Au vrut să-l traducă ca „Livrare constantă”, dar, din păcate, a fost tradus ca „Livrare continuă”. Mi se pare că e ceva rusesc în numele nostru, cu presiune.
Livrarea constantă a mijloacelor
Codul care se află în depozitul de produse poate fi oricând descărcat în producție. Poate că nu este dezumflat, dar este întotdeauna pregătit pentru asta. În consecință, scrii întotdeauna cod cu un sentiment greu de explicat de oarecare anxietate sub coccis. Apare adesea când lansați codul de infrastructură. Acest sentiment de anxietate ar trebui să fie prezent - declanșează procese cerebrale care vă permit să scrieți cod puțin diferit. Acest lucru ar trebui să fie înregistrat în regulile din cadrul dezvoltării.
Pentru a livra în mod constant, aveți nevoie de un format de artefact care rulează pe o platformă de infrastructură. Dacă aruncați „deșeuri de viață” de diferite formate pe o platformă de infrastructură, atunci aceasta devine unificată, este dificil de întreținut și apare problema datoriei tehnice. Formatul artefactului trebuie aliniat - aceasta este și o sarcină colectivă: trebuie să ne unim cu toții, să ne foșnim creierul și să venim cu acest format.
Artefactul este îmbunătățit continuu și se modifică pentru a se potrivi mediului de producție pe măsură ce trece prin conducta de livrare. Când un artefact se mișcă de-a lungul conductei, întâlnește în mod constant unele lucruri care sunt incomode pentru el, care sunt similare cu ceea ce întâlnește artefactul pe care îl puneți în producție. Dacă în dezvoltarea clasică acest lucru este făcut de un administrator de sistem care face lansarea, atunci în procesul DevOps asta se întâmplă tot timpul: aici l-au testat cu niște teste, aici l-au aruncat într-un cluster Kubernetes, care este mai mult sau mai puțin similar. la producție, apoi brusc au început testarea încărcării.
Acest lucru amintește oarecum de jocul Pac-Man - artefactul trece printr-un fel de poveste. În același timp, este important să controlați dacă codul trece de fapt prin poveste și dacă are legătură într-un fel cu producția dvs. Poveștile din producție pot fi târâte în procesul de livrare continuă: așa a fost când a căzut ceva, acum să programăm acest scenariu în interiorul sistemului. De fiecare dată, codul va trece și prin acest scenariu și nu veți mai întâlni această problemă data viitoare. Veți afla despre asta mult mai devreme decât ajunge la clientul dvs.
Diferite strategii de implementare. De exemplu, utilizați testarea AB sau implementările Canary pentru a testa codul diferit pe diferiți clienți, pentru a obține informații despre cum funcționează codul și mult mai devreme decât atunci când este lansat la 100 de milioane de utilizatori.
„Livrare în mod constant” arată astfel.
Procesul de livrare Dev, CI, Test, PreProd, Prod nu este un mediu separat, acestea sunt etape sau stații cu sume rezistente la foc prin care trece artefactul tău.
Dacă aveți un cod de infrastructură care este descris drept APP Serviciu de bază, atunci vă ajută nu uitați toate scripturileși notează-le ca cod pentru acest artefact, promovează artefactul și schimbă-l pe măsură ce mergi.
Întrebări pentru autoexaminare
Timpul de la descrierea caracteristicii până la lansarea în producție în 95% din cazuri este mai mic de o săptămână? Se îmbunătățește calitatea artefactului în fiecare etapă a conductei? Există vreo poveste prin care trece? Utilizați diferite strategii de implementare?
Dacă toate răspunsurile sunt da, atunci ești incredibil de cool! Scrieți răspunsurile dvs. în comentarii - voi fi bucuros).
Feedback-ul
Aceasta este cea mai dificilă practică dintre toate. La conferința DevOpsConf, un coleg de la Infobip, vorbind despre asta, a fost puțin confuz în cuvintele sale, pentru că aceasta este într-adevăr o practică foarte complexă despre faptul că trebuie să monitorizezi totul!
De exemplu, cu mult timp în urmă, când lucram la Qik și ne-am dat seama că trebuie să monitorizăm totul. Am făcut asta și acum avem 150 de articole în Zabbix, care sunt monitorizate constant. A fost înfricoșător, directorul tehnic și-a răsucit degetul la tâmplă:
- Băieți, de ce violați serverul cu ceva neclar?
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ă se prăbușească în mod constant. Inițial, nu s-a prăbușit, ceea ce este interesant, codul nu a fost adăugat acolo, deoarece era un broker de bază, care practic nu avea nicio funcționalitate de afaceri - pur și simplu trimitea mesaje între serviciile individuale. Serviciul nu s-a schimbat timp de 4 luni și brusc a început să se blocheze cu eroarea „Eroare de segmentare”.
Am fost șocați, ne-am deschis topurile în Zabbix și s-a dovedit că în urmă cu o săptămână și jumătate, comportamentul solicitărilor în serviciul API pe care îl folosește acest broker s-a schimbat foarte mult. Apoi am văzut că frecvența de trimitere a unui anumit tip de mesaj s-a schimbat. Mai târziu am aflat că aceștia erau clienți Android. Noi am intrebat:
— Băieți, ce s-a întâmplat cu voi acum o săptămână și jumătate?
Ca răspuns, am auzit o poveste interesantă despre modul în care au reproiectat interfața de utilizare. Este puțin probabil ca cineva să spună imediat că a schimbat biblioteca HTTP. Pentru clienții Android, este ca și cum ai schimba săpunul în baie - pur și simplu nu își amintesc. Drept urmare, după 40 de minute de conversație, am aflat că au schimbat biblioteca HTTP, iar momentele implicite ale acesteia s-au schimbat. Acest lucru a dus la schimbarea comportamentului de trafic pe serverul API, ceea ce a dus la o situație care a provocat o cursă în cadrul brokerului și a început să se prăbușească.
Fără o monitorizare profundă, este în general imposibil să deschideți acest lucru. Dacă organizația mai are problema „fântânilor”, când toată lumea aruncă cu bani unii în alții, asta poate trăi ani de zile. Pur și simplu reporniți serverul pentru că este imposibil să rezolvați problema. Când monitorizați, urmăriți, urmăriți toate evenimentele pe care le aveți și utilizați monitorizarea ca testare - scrieți codul și indicați imediat cum să îl monitorizați, tot sub formă de cod (avem deja infrastructura ca cod), totul devine clar cum pe palmă. Chiar și astfel de probleme complexe sunt ușor de urmărit.
Colectaț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 unele lucruri de bază vor fi deja vizibile acolo. Mai târziu le veți vedea în Test, PredProd și testare de încărcare. Colectați informații în toate etapele, nu numai valori, statistici, ci și jurnale: cum a fost lansată aplicația, anomalii - colectați totul.
Altfel, va fi dificil să-ți dai seama. Am spus deja că DevOps este mai complex. Pentru a face față acestei complexități, trebuie să aveți analize normale.
Întrebări pentru autocontrol
Monitorizarea și înregistrarea dvs. sunt instrumentul de dezvoltare pentru dvs.? Când scrieți cod, dezvoltatorii dvs., inclusiv dvs., se gândesc cum să-l monitorizeze?
Ați auzit de probleme de la clienți? Înțelegeți mai bine clientul din monitorizare și logare? Înțelegeți mai bine sistemul din monitorizare și înregistrare? Schimbați sistemul pur și simplu pentru că ați văzut că trendul în sistem este în creștere și înțelegeți că în alte 3 săptămâni totul va muri?
Odată ce ai aceste trei componente, te poți gândi la ce fel de platformă de infrastructură ai în compania ta.
Platformă de infrastructură
Ideea nu este că este un set de instrumente disparate pe care le are fiecare companie.
Scopul unei platforme de infrastructură este că toate echipele folosesc aceste instrumente și le dezvoltă împreună.
Este clar că există echipe separate care sunt responsabile pentru dezvoltarea pieselor individuale ale platformei de infrastructură. Dar, în același timp, fiecare inginer poartă responsabilitatea pentru dezvoltarea, performanța și promovarea platformei de infrastructură. La nivel intern, devine un instrument comun.
Toate echipele dezvoltă platforma de infrastructură și o tratează cu grijă ca pe propriul lor IDE. În IDE-ul dvs. instalați diferite plugin-uri pentru a face totul frumos și rapid și configurați tastele rapide. Când deschideți Sublime, Atom sau Visual Studio Code, erorile de cod se revarsă și vă dați seama că este imposibil să lucrați deloc, vă simțiți imediat trist și alergați să vă reparați IDE-ul.
Tratează-ți platforma de infrastructură în același mod. Dacă înțelegeți că este ceva în neregulă, lăsați o solicitare dacă nu puteți remedia singur. Dacă există ceva simplu, editați-l singur, trimiteți o cerere de tragere, băieții îl vor lua în considerare și îl vor adăuga. Aceasta este o abordare ușor diferită a instrumentelor de inginerie în capul dezvoltatorului.
Platforma de infrastructură asigură transferul artefactului de la dezvoltare la client cu îmbunătățirea continuă a calității. IP-ul este programat cu un set de povești care se întâmplă cu codul în producție. De-a lungul anilor de dezvoltare, există o mulțime de aceste povești, unele dintre ele sunt unice și se referă doar la tine - nu pot fi căutate pe Google.
În acest moment, platforma de infrastructură devine avantajul tău competitiv, pentru că are ceva încorporat în el care nu se află în instrumentul concurentului. Cu cât IP-ul dvs. este mai profund, cu atât este mai mare avantajul competitiv în ceea ce privește Time-to-market. Apare aici problema de blocare a furnizorului: Poți lua platforma altcuiva, dar folosind experiența altcuiva, nu vei înțelege cât de relevantă este pentru tine. Da, nu orice companie poate construi o platformă precum Amazon. Aceasta este o linie dificilă în care experiența companiei este relevantă pentru poziția sa pe piață și nu puteți utiliza o blocare a furnizorului acolo. De asemenea, este important să ne gândim.
Schema
Aceasta este o diagramă de bază a unei platforme de infrastructură care vă va ajuta să configurați toate practicile și procesele dintr-o companie DevOps.
Să vedem în ce constă.
Sistem de orchestrare a resurselor, care furnizează CPU, memorie, disc aplicațiilor și altor servicii. Deasupra acesteia - servicii de nivel scăzut: monitorizare, logare, CI/CD Engine, stocare artefacte, infrastructură ca cod de sistem.
Servicii de nivel superior: baza de date ca serviciu, cozi ca serviciu, Load Balance ca serviciu, redimensionarea imaginii ca serviciu, Big Data Factory ca serviciu. Deasupra acesteia - pipeline care furnizează cod modificat constant clientului dvs.
Primiți informații despre cum funcționează software-ul dvs. pentru client, îl schimbați, furnizați din nou acest cod, primiți informații - și astfel dezvoltați constant atât platforma de infrastructură, cât și software-ul dvs.
În diagramă, conducta de livrare constă din mai multe etape. Dar aceasta este o diagramă schematică care este dată ca exemplu - nu este nevoie să o repetați una câte una. Etapele interacționează cu serviciile ca și cum ar fi servicii — fiecare cărămidă a platformei poartă propria sa poveste: cum sunt alocate resursele, cum este lansată aplicația, cum funcționează cu resurse, este monitorizată și se modifică.
Este important să înțelegeți că fiecare parte a platformei poartă o poveste și întrebați-vă ce poveste poartă această cărămidă, poate ar trebui să fie aruncată și înlocuită cu un serviciu terță parte. De exemplu, este posibil să instalați Okmeter în loc de o cărămidă? Poate că băieții au dezvoltat deja această experiență mult mai mult decât noi. Dar poate nu - poate că avem o expertiză unică, trebuie să instalăm Prometheus și să-l dezvoltăm în continuare.
Crearea platformei
Acesta este un proces de comunicare complex. Când aveți practici de bază, începeți comunicarea între diferiți ingineri și specialiști care dezvoltă cerințe și standarde și le schimbați în mod constant la diferite instrumente și abordări. Cultura pe care o avem în DevOps este importantă aici.
Cu cultura totul este foarte simplu - este vorba de colaborare și comunicare, adică dorința de a lucra într-un domeniu comun unii cu alții, dorința de a mânui un instrument împreună. Nu există știință rachetă aici - totul este foarte simplu, banal. De exemplu, toți locuim la intrare și o păstrăm curată - un astfel de nivel de cultură.
Ce ai?
Din nou, întrebări pe care ți le poți pune.
Platforma de infrastructură este dedicată? Cine este responsabil pentru dezvoltarea lui? Înțelegeți avantajele competitive ale platformei dvs. de infrastructură?
Trebuie să vă puneți în mod constant aceste întrebări. Dacă ceva poate fi transferat către servicii terțe, ar trebui să fie transferat; dacă un serviciu terță parte începe să vă blocheze mișcarea, atunci trebuie să construiți un sistem în interiorul dvs.
Deci, DevOps...
... acesta este un sistem complex, trebuie să aibă:
- Produs digital.
- Module de afaceri care dezvoltă acest produs digital.
- Echipe de produse care scriu cod.
- Practici de livrare continuă.
- Platformele ca serviciu.
- Infrastructura ca serviciu.
- Infrastructura ca cod.
- Practici separate pentru menținerea fiabilității, integrate în DevOps.
- O practică de feedback care descrie totul.
Puteți folosi această diagramă, adăugând culoare la ceea ce aveți deja în compania dvs. într-o formă oarecare: s-a dezvoltat sau mai trebuie să fie dezvoltat.
Se va termina în câteva săptămâni . ca parte a RIT++. Vino la conferință, unde vei găsi multe rapoarte interesante despre livrarea continuă, infrastructura ca cod și transformarea DevOps. , ultimul termen limită pentru preț este 20 mai
Sursa: www.habr.com