Definicija DevOps-a je vrlo složena, tako da svaki put moramo započeti raspravu o tome iznova. Samo na Habréu postoji hiljadu publikacija na ovu temu. Ali ako ovo čitate, vjerovatno znate šta je DevOps. Jer nisam. zdravo moje ime je Aleksandar Titov (@), a mi ćemo pričati samo o DevOps-u, a ja ću podijeliti svoje iskustvo.
Dugo sam razmišljao kako da svoju priču učinim korisnom, tako da će ovdje biti mnogo pitanja – onih koja postavljam sebi i onih koje postavljam klijentima naše kompanije. Odgovaranjem na ova pitanja razumijevanje postaje bolje. Reći ću vam zašto je DevOps potreban sa moje tačke gledišta, šta je to, opet, sa moje tačke gledišta, i kako da shvatite da se ponovo krećete ka DevOps-u iz mog ugla. Posljednja tačka će biti kroz pitanja. Ako sami odgovorite na njih, možete shvatiti da li se vaša kompanija kreće ka DevOps-u ili na neki način ima problema.
Jedno vrijeme sam jahao talase spajanja i preuzimanja. Prvo sam radio za mali startup po imenu Qik, zatim ga je kupila malo veća kompanija po imenu Skype, koju je potom kupila malo veća kompanija po imenu Microsoft. U tom trenutku sam počeo da uviđam kako se ideja DevOps-a transformiše u kompanijama različitih veličina. Nakon toga sam se zainteresovao da sagledam DevOps iz tržišne tačke gledišta, a moje kolege i ja osnovali smo kompaniju Express 42. Već 6 godina se krećemo duž talasa tržišta.
Između ostalog, jedan sam od organizatora DevOps moskovske zajednice i organizator DevOps-Dana 2017, ali 2018 nisam organizovao. Express 42 radi sa mnogim kompanijama. Tamo razvijamo DevOps, gledamo kako se to događa, donosimo zaključke, analiziramo, svima kažemo svoje zaključke i obučavamo ljude u DevOps praksi. Općenito, dajemo sve od sebe da povećamo svoje iskustvo i stručnost u ovom pogledu.
Zašto DevOps
Prvo pitanje koje muči sve i uvijek je - zašto? Mnogi ljudi misle da je DevOps samo automatizacija ili slična stvar koju je svaka kompanija već imala.
— Imali smo kontinuiranu integraciju – to znači da smo već imali DevOps, i zašto su sve ove stvari potrebne? Zabavljaju se u inostranstvu, ali nas sprečavaju da radimo!
Tokom 9 godina razvoja zajednice i metodologije, već je postalo jasno da ovo još uvijek nije marketinški sjaj, ali još uvijek nije sasvim jasno zašto je to potrebno. Kao i svaki alat i proces, DevOps ima specifične ciljeve koje na kraju postiže.
Sve je to zbog činjenice da se svijet mijenja. On se udaljava od preduzetničkog pristupa, kada kompanije kreću pravo ka snu, kako je pevao naš peterburški klasik, od tačke A do tačke B prema određenoj strategiji, sa određenom strukturom izgrađenom za to.
U principu, sve u IT-u treba graditi prema ovom pristupu. Ovdje se IT koristi isključivo za automatizaciju procesa.
Automatizacija se ne mijenja često, jer kada kompanija krene utabanom kolotečinom, šta se tu može promijeniti? Radi - ne dirajte ga. Sada se pristupi u svijetu mijenjaju, a onaj koji se zove Agile sugerira da krajnja tačka B nije odmah vidljiva.
Kada kompanija prolazi kroz tržište, radi sa klijentom, stalno istražuje tržište i mijenja krajnju tačku B. Štaviše, što češće kompanija mijenja smjer, to je na kraju uspješnija, jer bira više tržišta. niše.
Strategiju pokazuje jedna zanimljiva kompanija za koju sam nedavno saznao. One Box Shave je pretplatnička usluga dostave brijača i pribora za brijanje u kutiji. Oni znaju kako prilagoditi svoju „kutiju“ za različite klijente. To radi određeni softver, koji zatim šalje narudžbu korejskoj fabrici koja proizvodi robu.
Ovaj proizvod je kupio Unilever za milijardu dolara. Sada se takmiči sa Gilletteom i oduzeo je značajan udio potrošača na američkom tržištu. One Box Shave kaže:
— 4 oštrice? Ozbiljno? Zašto vam je ovo potrebno - ne poboljšava kvalitetu brijanja. Posebno odabrana krema, miris i visokokvalitetan brijač sa dvije oštrice rješavaju mnogo više problema od one glupe 4 Gillette oštrice! Hoćemo li uskoro stići do 10?
Ovako se svijet mijenja. Unilever tvrdi da imaju cool IT sistem koji vam to omogućava. Na kraju to izgleda kao koncept Vrijeme za stavljanje na tržište, o čemu još niko nije pričao.
Poenta vremena za stavljanje na tržište nije koliko često primenjujemo. Često možete implementirati, ali ciklusi izdavanja će biti dugi. Ako se tromjesečni ciklusi izdavanja preklapaju jedan s drugim, pomjerajući ih za sedmicu, ispada da se čini da kompanija implementira jednom sedmično. A od ideje do konačne realizacije potrebno je 3 mjeseca.
Vrijeme do izlaska na tržište podrazumijeva minimiziranje vremena od ideje do konačne implementacije.
U ovom slučaju, softver je u interakciji sa tržištem. Ovako web stranica One Box Shave komunicira s klijentom. Oni nemaju prodavače - samo web stranicu na kojoj posjetitelji kliknu i ostave želje. U skladu s tim, nešto novo se mora stalno objavljivati na stranici i ažurirati u skladu sa željama. Na primjer, u Južnoj Koreji se briju drugačije nego u Rusiji, a ne vole miris bora, već, na primjer, šargarepe i vanile.
Budući da je potrebno brzo promijeniti sadržaj stranice, razvoj softvera se uvelike mijenja. Kroz softver moramo saznati šta klijent želi. Ranije smo to učili kroz neke zaobilazne načine, na primjer, kroz upravljanje poslovanjem. Onda smo to dizajnirali, postavili zahtjeve u IT sistem i sve je bilo super. Sada je drugačije - softver dizajniraju svi koji su uključeni u proces, uključujući inženjere, jer kroz tehničke specifikacije uče kako tržište funkcionira i također dijele svoje uvide s poslovanjem.
Na primjer, u Qik-u smo iznenada saznali da ljudi zaista vole uploadati liste kontakata na server i dali su nam aplikaciju. U početku nismo razmišljali o tome. U klasičnoj kompaniji, svi bi odlučili da je ovo greška, pošto specifikacija nije rekla da treba da radi odlično i generalno je implementirana na kolenima, isključili bi funkciju i rekli: „Ovo nikome ne treba, najvažnije je da glavna funkcionalnost radi.” . A tehnološka kompanija to vidi kao priliku i počinje mijenjati softver u skladu s tim.
1968. vizionar, Melvin Konvej, formulisao je sledeću ideju.
Organizacija koja kreira sistem je ograničena dizajnom koji replicira komunikacijsku strukturu te organizacije.
Detaljnije, da biste proizveli sisteme drugačijeg tipa, morate imati i komunikacijsku strukturu unutar kompanije drugog tipa. Ako je vaša komunikacijska struktura vrhunska, onda vam to neće dozvoliti da kreirate sisteme koji mogu pružiti vrlo visok indikator vremena do tržišta.
Čitaj moći . Važno je za razumijevanje DevOps kulture ili filozofije jer jedina stvar koja se suštinski menja u DevOps-u je struktura komunikacije između timova.
Sa procesne tačke gledišta, prije DevOps-a, sve faze: analitika, razvoj, testiranje, rad, bile su linearne.
U slučaju DevOps-a, svi ovi procesi se odvijaju istovremeno.
Vrijeme izlaska na tržište je jedini način na koji se to može učiniti. Za ljude koji su radili u starom procesu, ovo izgleda pomalo kosmički, i općenito tako-tako.
Pa zašto vam je potreban DevOps?
Za razvoj digitalnih proizvoda. Ako vaša kompanija nema digitalni proizvod, DevOps nije potreban – veoma je važan.
DevOps prevazilazi ograničenja brzine sekvencijalne proizvodnje softvera. U njemu se svi procesi odvijaju istovremeno.
Poteškoće se povećavaju. Kada vam DevOps evanđelisti kažu da će vam to olakšati izdavanje softvera, to je besmislica.
Sa DevOps-om, stvari će biti samo komplikovanije.
Na konferenciji na Avito štandu, mogli ste vidjeti kako je bilo postaviti Docker kontejner - nerealni zadatak. Složenost postaje previsoka; morate žonglirati s više loptica u isto vrijeme.
DevOps u potpunosti mijenja proces i organizaciju u kompaniji — tačnije, ne menja se DevOps, već digitalni proizvod. Da biste došli u DevOps, još uvijek morate potpuno promijeniti ovaj proces.
Pitanja za specijaliste
Šta imaš? Pitanja koja si možete postaviti dok radite u kompaniji i razvijate se kao specijalista.
Imate li strategiju za kreiranje digitalnog proizvoda? Ako postoji, to je već dobro. To znači da se vaša kompanija kreće prema DevOps-u.
Da li vaša kompanija već stvara digitalni proizvod? To znači da se možete podići još jedan nivo više i raditi stvari zanimljivije – opet sa DevOps tačke gledišta. Ja samo govorim sa ove tačke gledišta.
Da li je vaša kompanija jedan od tržišnih lidera u niši digitalnih proizvoda? Spotify, Yandex, Uber su kompanije koje su sada na vrhuncu tehnološkog napretka.
Postavite sebi ova pitanja, a ako su svi odgovori ne, onda možda ne biste trebali raditi DevOps u ovoj kompaniji. Ako vam je tema DevOps-a zaista interesantna, možda... treba da pređete u drugu kompaniju? Ako vaša kompanija želi da uđe u DevOps, ali ste na sva pitanja odgovorili „Ne“, onda je to kao onaj prelepi nosorog koji se nikada neće promeniti.
organizacija
Kao što sam rekao, prema Konvejevom zakonu, organizacija kompanije se menja. Počeću od onoga što sprečava DevOps da prodre u kompaniju sa organizacione tačke gledišta.
Problem "bunara"
Engleska riječ "Silo" ovdje je prevedena na ruski kao "dobro". Poenta ovog problema je u tome nema razmjene informacija između timova. Svaki tim duboko kopa u svoju stručnost, bez izrade zajedničke karte za navigaciju.
Ovo me na neki način podsjeća na osobu koja je upravo stigla u Moskvu i još ne zna kako se kretati mapom metroa. Moskovljani obično vrlo dobro poznaju svoje područje, a širom Moskve mogu se kretati pomoću karte metroa. Kada prvi put dođete u Moskvu, nemate tu vještinu i jednostavno ste dezorijentisani.
DevOps predlaže da se prođe kroz ovaj trenutak dezorijentacije i da svi odjeli rade zajedno na izgradnji zajedničke karte interakcije.
Dva faktora ometaju ovo.
Posljedice korporativnog sistema upravljanja. Izgrađen je u odvojenim hijerarhijskim „bunarima“. Na primjer, postoje određeni KPI u kompanijama koje podržavaju ovaj sistem. S druge strane, mozak osobe kojoj je teško izaći izvan granica svoje stručnosti i kretati se cijelim sistemom, smeta. Samo je neprijatno. Zamislite da ste na aerodromu u Bangkoku - nećete se brzo snaći. DevOps je također težak za navigaciju, i zato ljudi kažu da morate pronaći vodič da biste došli do njega.
Ali najvažnije je da se problem “bušotina” za inženjera koji je prožet duhom DevOps-a, koji je pročitao Fowlera i gomilu drugih knjiga, izražava u činjenici da "bunari" vam ne dozvoljavaju da radite "očigledne" stvari. Često se okupljamo nakon DevOps-a u Moskvi, razgovaramo jedni s drugima i ljudi se žale:
— Samo smo hteli da pokrenemo CI, ali se ispostavilo da menadžmentu to nije potrebno.
Ovo se dešava upravo zato CI и Kontinuirani proces isporuke su na granici mnogih ispitivanja. Jednostavno bez prevazilaženja problema „bunara“ na nivou organizacije, nećete moći da idete dalje, šta god da radite i koliko god da je tužno.
Svaki učesnik u procesu u kompaniji: backend i frontend programeri, testiranje, DBA, rad, mreža, kopa u svom pravcu, a niko nema zajedničku mapu osim menadžera, koji ih nekako prati i upravlja njima koristeći „divide“ i osvoji”.
Ljudi se bore za neke zvijezde ili zastave, svi kopaju svoju stručnost.
Kao rezultat toga, kada se pojavi zadatak da sve to povežemo i izgradimo zajednički cevovod, a više nema potrebe da se borimo za zvezde i zastave, postavlja se pitanje - šta da se radi? Moramo se nekako dogovoriti, ali nas niko nije učio kako se to radi u školi. Od škole su nas učili: osmi razred - vau! - u poređenju sa sedmim razredom! I ovdje je isto.
Da li je tako i u vašoj kompaniji?
Da biste to provjerili, možete sebi postaviti sljedeća pitanja.
Koriste li timovi zajedničke alate i doprinose li promjenama tih zajedničkih alata?
Koliko često se timovi reorganizuju – neki stručnjaci iz jednog tima prelaze u drugi tim? U DevOps okruženju to postaje normalno, jer ponekad osoba jednostavno ne može razumjeti šta druga oblast stručnosti radi. Prelazi u drugi odjel, tamo radi dvije sedmice kako bi sebi napravio mapu orijentacije i interakcije sa ovim odjelom.
Da li je moguće formirati odbor za promjene i promijeniti stvari? Ili je za to potrebna snažna ruka najvišeg menadžmenta i rukovođenja? Nedavno sam napisao na Facebooku kako jedna malo poznata banka implementira alate kroz naloge: napišemo nalog, implementiramo ga godinu dana i vidimo šta će se dogoditi. Ovo je, naravno, dugo i tužno.
Koliko je važno da menadžeri primaju lična dostignuća bez obzira na dostignuća kompanije?
Ako sami sebi odgovorite na ova pitanja, biće vam jasnije da li imate takav problem u vašoj kompaniji.
Infrastruktura kao kod
Nakon što se ovaj problem prođe, prva važna praksa, bez koje je teško napredovati dalje u DevOps-u, je infrastruktura kao kod.
Najčešće se infrastruktura kao kod percipira na sljedeći način:
— Automatizirajmo sve u bash-u, pokrijmo se skriptama kako bi administratori imali manje ručnog rada!
Ali to nije istina.
Infrastruktura kao kod znači da IT sistem s kojim radite opišete u obliku koda kako biste stalno razumjeli njegovo stanje.
Zajedno s drugim timovima kreirate mapu u obliku koda koju svi mogu razumjeti i mogu se kretati i navigirati. Nije važno na čemu se radi – Chef, Ansible, Salt ili koristeći YAML datoteke u Kubernetesu – nema razlike.
Na konferenciji je kolega iz 2GIS-a ispričao kako su napravili svoju internu stvar za Kubernetes, koja opisuje strukturu pojedinačnih sistema. Da bi opisali 500 sistema, bio im je potreban poseban alat koji generiše ovaj opis. Kada postoji ovaj opis, svi mogu međusobno da se proveravaju, prate promene, kako to promeniti i poboljšati, šta nedostaje.
Slažem se, pojedinačne bash skripte obično ne pružaju ovo razumijevanje. U jednoj od firmi u kojoj sam radio postojao je čak i naziv za “write only” skriptu – kada je skripta napisana, ali je više nije moguće pročitati. Mislim da je i vama ovo poznato.
Infrastruktura kakva jeste kod koji opisuje trenutno stanje infrastrukture. Mnogi timovi za proizvode, infrastrukturu i usluge rade zajedno na ovom kodu, i što je najvažnije, svi moraju razumjeti kako ovaj kod zapravo funkcionira.
Kod se održava u skladu s najboljom praksom koda: zajednički razvoj, pregled koda, XP-programiranje, testiranje, pull zahtjevi, CI za kodne infrastrukture - sve je to prikladno i može se koristiti.
Kod postaje zajednički jezik za sve inženjere.
Promjena infrastrukture u kodu ne oduzima puno vremena. Da, infrastrukturni kod može imati i tehnički dug. Obično se timovi susreću s tim godinu i po nakon što su počeli implementirati “infrastrukturu kao kod” u obliku gomile skripti ili čak Ansible-a, koji pišu kao špageti kod, a ubacivaju i bash skripte!
važno: Ako još niste probali ove stvari, zapamtite to Ansible nije bash! Pažljivo pročitajte dokumentaciju, proučite šta pišu o njoj.
Infrastruktura kao kod je odvajanje infrastrukturnog koda u zasebne slojeve.
U našoj kompaniji razlikujemo 3 osnovna sloja, koji su vrlo jasni i jednostavni, ali ih može biti više. Možete pogledati svoj infrastrukturni kod i reći imate li ovo stanje ili ne. Ako nijedan sloj nije istaknut, onda morate odvojiti malo vremena i malo refaktorirati.
osnovni sloj - ovako se konfigurišu OS, rezervne kopije i druge stvari niskog nivoa, na primer, kako se Kubernetes primenjuje na osnovnom nivou.
Nivo usluge - ovo su usluge koje pružate programeru: logiranje kao servis, praćenje kao servis, baza podataka kao usluga, balans kao usluga, red čekanja kao usluga, kontinuirana isporuka kao usluga - gomila usluga koje pojedini timovi može pružiti razvoju. Sve ovo treba opisati u zasebnim modulima u vašem sistemu upravljanja konfiguracijom.
Sloj na kojem se prave aplikacije i opisuje kako će se odvijati na prethodna dva sloja.
Kontrolna pitanja
Da li vaša kompanija ima zajednički infrastrukturni repozitorij? Da li upravljate tehničkim dugom u svojoj infrastrukturi? Koristite li razvojne prakse u infrastrukturnom repozitoriju? Je li vaša infrastruktura podijeljena na slojeve? Možete provjeriti dijagram Base-service-APP. Koliko je teško napraviti promjenu?
Ako ste doživjeli da je za izmjenu trebalo dan i po, to znači da imate tehnički dug i da morate raditi s njim. Upravo ste naišli na tehničku grabu duga u vašem infrastrukturnom kodu. Sjećam se mnogo takvih priča kada, da bi se promijenio neki CCTL, treba prepisati pola infrastrukturnog koda, jer kreativnost i želja da se sve automatizuje doveli su do toga da je sve nagrizalo svuda, sve ručke su skinute, a potrebno je refaktorirati.
Kontinuirana isporuka
Uporedimo debitno i kreditno. Prvo dolazi opis infrastrukture, koji može biti prilično jednostavan. Ne morate sve detaljno opisivati, ali je potreban neki osnovni opis da biste mogli raditi s njim. Inače, nije jasno šta dalje sa kontinuiranom isporukom. Sve ove prakse se odvijaju istovremeno kada dođete u DevOps, ali počinje s razumijevanjem onoga što imate i kako to upravljati. To je upravo praksa infrastrukture kao koda.
Kada postane jasno da ga imate i kako njime upravljate, počinjete da smišljate kako da pošaljete programski kod u proizvodnju što je brže moguće. Mislim zajedno sa programerom - sjećamo se problema "bušotina", to jest, ne dolaze pojedini ljudi, već tim.
Kada smo sa Vanya Evtukhovich videla prvu knjigu Jez Humble i grupe autora "Kontinuirana isporuka", koji je objavljen 2009. godine, dugo smo razmišljali kako da prevedemo njegov naslov na ruski. Htjeli su to prevesti kao “Konstantno isporučiti”, ali je, nažalost, prevedeno kao “Neprekidna isporuka”. Čini mi se da ima nešto rusko u našem imenu, uz pritisak.
Konstantno isporučuju sredstva
Kod koji se nalazi u spremištu proizvoda uvijek se može preuzeti u proizvodnju. Možda nije iscrpljen, ali je uvijek spreman za to. U skladu s tim, uvijek pišete kod sa teško objašnjivim osjećajem neke anksioznosti ispod repa. Često se pojavljuje kada uvedete infrastrukturni kod. Ovaj osjećaj neke anksioznosti trebao bi biti prisutan - on pokreće moždane procese koji vam omogućavaju da napišete kod na malo drugačiji način. To treba zabilježiti u pravilima unutar razvoja.
Za dosljednu isporuku potreban vam je format artefakta koji radi na infrastrukturnoj platformi. Ako bacite “životni otpad” različitih formata preko infrastrukturne platforme, tada se ona objedinjuje, teško je održavati i javlja se problem tehničkog duga. Format artefakta treba uskladiti - ovo je također kolektivni zadatak: svi se trebamo okupiti, zašuškati mozgom i smisliti ovaj format.
Artefakt se kontinuirano poboljšava i mijenja kako bi odgovarao proizvodnom okruženju dok se kreće kroz cjevovod isporuke. Kada se artefakt kreće duž cjevovoda, stalno se susreće sa nekim nezgodnim stvarima koje su slične onima na koje nailazi artefakt koji stavljate u produkciju. Ako u klasičnom razvoju to radi sistem administrator koji radi rollout, onda se u DevOps procesu to stalno dešava: ovdje su ga testirali nekim testovima, ovdje su ga bacili u Kubernetes klaster, što je manje-više slično u proizvodnju, a onda su odjednom počeli testiranje opterećenja.
Ovo donekle podsjeća na igru Pac-Man - artefakt prolazi kroz neku vrstu priče. Istovremeno, važno je kontrolirati da li kod zaista prolazi kroz priču i da li je na neki način povezan s vašom produkcijom. Priče iz produkcije se mogu uvući u proces kontinuirane isporuke: ovako je bilo kada je nešto palo, sada samo programirajmo ovaj scenario unutar sistema. Svaki put će kod proći i kroz ovaj scenarij, a sljedeći put nećete naići na ovaj problem. O tome ćete saznati mnogo ranije nego što dođe do vašeg klijenta.
Različite strategije implementacije. Na primjer, koristite AB testiranje ili canary implementacije da različito testirate kod na različitim klijentima, dobijete informacije o tome kako kod funkcionira i to mnogo ranije nego kada se uvede na 100 miliona korisnika.
„Dosljedna isporuka“ izgleda ovako.
Proces isporuke Dev, CI, Test, PreProd, Prod nije zasebno okruženje, to su faze ili stanice sa vatrostalnim sumama kroz koje prolazi vaš artefakt.
Ako imate infrastrukturni kod koji je opisan kao Base Service APP onda pomaže ne zaboravite sve skripte, i zapišite ih kao kod za ovaj artefakt, promovirati artefakt i mijenjajte ga kako idete.
Pitanja za samotestiranje
Vrijeme od opisa funkcije do puštanja u proizvodnju u 95% slučajeva je manje od jedne sedmice? Da li se kvalitet artefakta poboljšava u svakoj fazi cevovoda? Postoji li priča kroz koju prolazi? Koristite li različite strategije implementacije?
Ako su svi odgovori potvrdni, onda ste nevjerovatno cool! Napišite svoje odgovore u komentarima - bit će mi drago).
Povratne informacije
Ovo je najteža praksa od svih. Na DevOpsConf konferenciji, kolega iz Infobip-a, govoreći o tome, bio je malo zbunjen u svojim riječima, jer je to zaista vrlo složena praksa da sve treba pratiti!
Na primjer, davno, kada sam radio u Qik-u i shvatili smo da moramo sve pratiti. Učinili smo to i sada imamo 150 artikala u Zabbixu, koji se stalno prate. Bilo je strašno, tehnički direktor je zavrnuo prstom na sljepoočnici:
- Ljudi, zašto silujete server nečim nejasnim?
Ali onda se dogodio incident koji je pokazao da je ovo zaista vrlo kul strategija.
Jedan od servisa je počeo stalno da pada. U početku se nije srušio, što je zanimljivo, tu nije dodat kod, jer je to bio osnovni broker, koji praktično nije imao poslovne funkcionalnosti - jednostavno je slao poruke između pojedinih servisa. Usluga se nije mijenjala 4 mjeseca, a odjednom je počela rušiti s greškom “Segmentation fault”.
Bili smo šokirani, otvorili smo naše grafikone u Zabbixu i pokazalo se da se prije tjedan i po dana ponašanje zahtjeva u API servisu koji koristi ovaj broker uvelike promijenilo. Zatim smo vidjeli da se promijenila učestalost slanja određene vrste poruka. Kasnije smo saznali da su to bili android klijenti. pitali smo:
— Ljudi, šta vam se desilo prije nedelju i po?
Kao odgovor, čuli smo zanimljivu priču o tome kako su redizajnirali korisničko sučelje. Malo je vjerovatno da će neko odmah reći da je promijenio HTTP biblioteku. Za Android klijente, to je kao da mijenjaju sapun u kupatilu - jednostavno se ne sjećaju. Kao rezultat toga, nakon 40 minuta razgovora, saznali smo da su promijenili HTTP biblioteku i da su se promijenila njena zadana vremena. To je dovelo do promjene ponašanja u prometu na API serveru, što je dovelo do situacije koja je izazvala trku unutar brokera i on je počeo rušiti.
Bez dubokog praćenja općenito je nemoguće otvoriti ovo. Ako organizacija i dalje ima problem “bunara”, kada svi bacaju novac jedni na druge, to može živjeti godinama. Jednostavno restartujete server jer je nemoguće riješiti problem. Kada nadgledate, pratite, pratite sve događaje koje imate i koristite monitoring kao testiranje - napišite kod i odmah naznačite kako ga pratiti, takođe u obliku koda (infrastrukturu već imamo kao kod), sve postaje jasno kako na dlanu. Čak i ovako složeni problemi se lako prate.
Prikupite sve informacije o tome što se događa s artefaktom u svakoj fazi procesa isporuke - ne u proizvodnji.
Učitajte monitoring u CI i neke osnovne stvari će već biti vidljive tamo. Kasnije ćete ih vidjeti u Testu, PredProd-u i testiranju opterećenja. Prikupljajte informacije u svim fazama, ne samo metriku, statistiku, već i zapisnike: kako se aplikacija pojavila, anomalije - prikupite sve.
Inače će to biti teško shvatiti. Već sam rekao da je DevOps složeniji. Da biste se nosili s ovom složenošću, morate imati normalnu analitiku.
Pitanja za samokontrolu
Je li vaše praćenje i evidentiranje razvojni alat za vas? Kada pišete kod, da li vaši programeri, uključujući i vas, razmišljaju o tome kako ga nadgledati?
Da li čujete o problemima od kupaca? Razumijete li klijenta bolje iz praćenja i evidentiranja? Razumijete li sistem bolje iz praćenja i evidentiranja? Da li menjate sistem samo zato što ste videli da trend u sistemu raste i razumete da će za još 3 nedelje sve umreti?
Kada imate ove tri komponente, možete razmišljati o tome kakvu infrastrukturnu platformu imate u svojoj kompaniji.
Infrastrukturna platforma
Poenta nije u tome da se radi o skupu različitih alata koje svaka kompanija ima.
Smisao infrastrukturne platforme je da svi timovi koriste ove alate i zajedno ih razvijaju.
Jasno je da postoje odvojeni timovi koji su odgovorni za razvoj pojedinačnih delova infrastrukturne platforme. Ali u isto vrijeme, svaki inženjer snosi odgovornost za razvoj, performanse i promociju infrastrukturne platforme. Na unutrašnjem nivou to postaje uobičajeno oruđe.
Svi timovi razvijaju infrastrukturnu platformu i tretiraju je pažljivo kao sopstveni IDE. U svom IDE-u instalirate različite dodatke da sve bude lijepo i brzo i konfigurirate prečice. Kada otvorite Sublime, Atom ili Visual Studio Code, hrle greške u kodu i shvatite da je nemoguće raditi uopće, odmah se osjećate tužno i trčite da popravite svoj IDE.
Tretirajte svoju infrastrukturnu platformu na isti način. Ako shvatite da nešto nije u redu s tim, ostavite zahtjev ako ne možete sami popraviti. Ako postoji nešto jednostavno, uredite sami, pošaljite pull request, momci će to razmotriti i dodati. Ovo je malo drugačiji pristup inženjerskim alatima u glavi programera.
Infrastrukturna platforma osigurava prijenos artefakta od razvoja do klijenta uz kontinuirano poboljšanje kvaliteta. IP je programiran skupom priča koje se dešavaju kodu u produkciji. Tokom godina razvoja, mnogo je ovih priča, neke od njih su jedinstvene i odnose se samo na vas - ne mogu se pronaći na Google-u.
U ovom trenutku, infrastrukturna platforma postaje vaša konkurentska prednost, jer ima nešto ugrađeno u sebe što nije u alatu konkurenta. Što je vaš IP dublji, veća je vaša konkurentska prednost u smislu vremena do stupanja na tržište. Pojavljuje se ovdje problem sa zaključavanjem dobavljača: Možete uzeti tuđu platformu, ali koristeći tuđe iskustvo nećete shvatiti koliko vam je ona relevantna. Da, ne može svaka kompanija izgraditi platformu poput Amazona. Ovo je teška linija u kojoj je iskustvo kompanije relevantno za njenu poziciju na tržištu i tu ne možete koristiti zaključavanje dobavljača. O ovome je takođe važno razmisliti.
Shema
Ovo je osnovni dijagram infrastrukturne platforme koji će vam pomoći da postavite sve prakse i procese u DevOps kompaniji.
Pogledajmo od čega se sastoji.
Sistem orkestracije resursa, koji pruža CPU, memoriju, disk aplikacijama i drugim uslugama. Povrh ovoga - usluge niskog nivoa: praćenje, evidentiranje, CI/CD Engine, skladištenje artefakata, infrastruktura kao sistemski kod.
Usluge višeg nivoa: baza podataka kao usluga, redovi kao usluga, balans opterećenja kao usluga, promjena veličine slike kao usluga, fabrika velikih podataka kao usluga. Povrh ovoga - cjevovod koji isporučuje stalno modificirani kod vašem klijentu.
Primate informacije o tome kako vaš softver radi za klijenta, mijenjate ga, ponovo dajete ovaj kod, primate informacije - i tako stalno razvijate i infrastrukturnu platformu i svoj softver.
Na dijagramu, cjevovod isporuke se sastoji od više faza. Ali ovo je shematski dijagram koji je dat kao primjer - nema potrebe da ga ponavljate jedan po jedan. Faze stupaju u interakciju sa uslugama kao da su usluge—svaka kockica platforme nosi svoju priču: kako se dodeljuju resursi, kako se aplikacija pokreće, radi sa resursima, nadgleda se i menja.
Važno je shvatiti da svaki dio platforme nosi priču, i zapitajte se koju priču nosi ova cigla, možda bi je trebalo baciti i zamijeniti servisom treće strane. Na primjer, da li je moguće instalirati Okmeter umjesto cigle? Možda su momci već razvili ovu stručnost mnogo više od nas. Ali možda i ne – možda imamo jedinstvenu ekspertizu, moramo instalirati Prometheus i dalje ga razvijati.
Kreiranje platforme
Ovo je složen komunikacijski proces. Kada imate osnovne prakse, započinjete komunikaciju između različitih inženjera i stručnjaka koji razvijaju zahtjeve i standarde, te ih stalno mijenjaju u različite alate i pristupe. Kultura koju imamo u DevOps-u je ovdje važna.
Sa kulturom je sve vrlo jednostavno - radi se o saradnji i komunikaciji, odnosno želja da se međusobno radi na zajedničkom polju, želja da se zajedno rukuje jednim instrumentom. Ovdje nema raketne nauke - sve je vrlo jednostavno, banalno. Na primjer, svi živimo u ulazu i održavamo ga čistim - takav je nivo kulture.
Šta imaš?
Opet, pitanja koja možete sebi postaviti.
Je li infrastrukturna platforma namijenjena? Ko je odgovoran za njen razvoj? Razumijete li konkurentske prednosti vaše infrastrukturne platforme?
Morate stalno sebi postavljati ova pitanja. Ako se nešto može prenijeti na usluge treće strane, to treba prenijeti; ako usluga treće strane počne blokirati vaše kretanje, onda morate izgraditi sistem u sebi.
Dakle, DevOps...
... ovo je složen sistem, mora imati:
- Digitalni proizvod.
- Poslovni moduli koji razvijaju ovaj digitalni proizvod.
- Proizvodni timovi koji pišu kod.
- Praksa kontinuirane isporuke.
- Platforme kao usluga.
- Infrastruktura kao usluga.
- Infrastruktura kao kod.
- Odvojene prakse za održavanje pouzdanosti, ugrađene u DevOps.
- Praksa povratnih informacija koja sve to opisuje.
Možete koristiti ovaj dijagram, naglašavajući u njemu ono što već imate u svojoj kompaniji u nekom obliku: da li je razvijeno ili još treba da se razvije.
Biće gotovo za par nedelja . kao dio RIT++. Dođite na konferenciju, gdje ćete pronaći mnogo cool izvještaja o kontinuiranoj isporuci, infrastrukturi kao kodu i DevOps transformaciji. , posljednji rok za cijenu je 20. maj
izvor: www.habr.com