Definicija DevOpsa je vrlo složena, tako da svaki put moramo iznova započeti raspravu o tome. Samo na Habréu postoji tisuću objava na ovu temu. Ali ako ovo čitate, vjerojatno znate što je DevOps. Jer ja nisam. Pozdrav moje ime je Aleksandar Titov (@), a razgovarat ćemo samo o DevOpsu i podijelit ću svoje iskustvo.
Dugo sam razmišljao kako svoju priču učiniti korisnom, pa će ovdje biti puno pitanja – onih koja postavljam sebi i onih koja postavljam klijentima naše tvrtke. Odgovaranjem na ova pitanja, razumijevanje postaje bolje. Reći ću vam zašto je DevOps potreban s moje točke gledišta, što je to, opet, s moje točke gledišta, i kako razumjeti da se ponovno krećete prema DevOps-u s moje točke gledišta. Posljednja točka bit će niz pitanja. Ako sami odgovorite na njih, možete shvatiti ide li vaša tvrtka prema DevOps-u ili postoje problemi na neki način.
Jedno sam vrijeme jahao na valovima spajanja i akvizicija. Prvo sam radio za mali startup koji se zove Qik, zatim ga je kupila malo veća kompanija koja se zove Skype, koju je zatim kupila malo veća kompanija koja se zove Microsoft. U tom sam trenutku počeo uviđati kako se ideja o DevOpsu transformira u tvrtkama različitih veličina. Nakon toga sam se zainteresirao za sagledavanje DevOpsa s tržišne strane te smo s kolegama osnovali tvrtku Express 42. Već 6 godina koračamo na valovima tržišta.
Između ostalog, jedan sam od organizatora DevOps Moscow zajednice i organizator DevOps-Days 2017, ali nisam organizirao 2018. Express 42 surađuje s mnogim tvrtkama. Tamo razvijamo DevOps, gledamo kako se to događa, donosimo zaključke, analiziramo, svima govorimo svoje zaključke i obučavamo ljude DevOps praksi. Općenito, dajemo sve od sebe da povećamo svoje iskustvo i stručnost u tom pogledu.
Zašto DevOps
Prvo pitanje koje svakoga i uvijek muči je – zašto? Mnogi misle da je DevOps samo automatizacija ili slična stvar koju je svaka tvrtka već imala.
— Imali smo kontinuiranu integraciju - to znači da smo već imali DevOps, a zašto su sve te stvari potrebne? U inozemstvu se zabavljaju, a nama brane rad!
Kroz 9 godina razvoja zajednice i metodologije već je postalo jasno da to još uvijek nije marketinški blještavilo, ali još uvijek nije posve jasno zašto je to potrebno. Kao i svaki alat i proces, DevOps ima specifične ciljeve koje u konačnici postiže.
Sve je to zbog činjenice da se svijet mijenja. Odmiče se od poduzetničkog pristupa, kada se tvrtke kreću ravno prema snu, kako je pjevao naš sanktpeterburški klasik, od točke A do točke B prema određenoj strategiji, s određenom strukturom izgrađenom za to.
U principu, sve u IT-u treba biti izgrađeno prema ovom pristupu. Ovdje se IT koristi isključivo za automatizaciju procesa.
Automatizacija se ne mijenja često, jer kada tvrtka krene niz dobro utabanu kolotečinu, što se ima promijeniti? Djeluje - ne diraj ga. Sada se pristupi u svijetu mijenjaju, a onaj nazvan Agile sugerira da krajnja točka B nije odmah vidljiva.
Kada tvrtka prolazi kroz tržište, radi s klijentom, stalno istražuje tržište i mijenja krajnju točku B. Štoviše, što tvrtka češće mijenja svoj smjer, to je na kraju uspješnija, jer bira više tržišta niše.
Strategiju demonstrira jedna zanimljiva tvrtka za koju sam nedavno saznao. One Box Shave je pretplatnička usluga dostave brijača i pribora za brijanje u kutiji. Oni znaju prilagoditi svoju “kutiju” različitim klijentima. To radi određeni softver koji zatim šalje narudžbu korejskoj tvornici koja proizvodi robu.
Ovaj proizvod je kupio Unilever za milijardu dolara. Sada se natječe s Gilletteom i uzeo je značajan udio potrošača na američkom tržištu. One Box Shave kaže:
— 4 oštrice? Jesi li ozbiljan? Zašto vam ovo treba - ne poboljšava kvalitetu brijanja. Posebno odabrana krema, miris i kvalitetna britvica s dvije oštrice rješavaju puno više problema od one glupe 4 Gillette oštrice! Hoćemo li uskoro doći do 10?
Ovako se svijet mijenja. Unilever tvrdi da ima cool IT sustav koji vam to omogućuje. Na kraju izgleda kao koncept Vrijeme za izlazak na tržište, o čemu već nitko nije govorio.
Poanta Time-to-marketa nije koliko često implementiramo. Često možete implementirati, ali ciklusi izdavanja bit će dugi. Ako se tromjesečni ciklusi izdavanja nadovežu jedan na drugi, pomičući ih za tjedan dana, ispada da se čini da tvrtka implementira jednom tjedno. A od ideje do konačne provedbe potrebno je 3 mjeseca.
Time-to-market je smanjenje vremena od ideje do konačne implementacije.
U ovom slučaju softver je u interakciji s tržištem. Ovo je način na koji web stranica One Box Shave komunicira s klijentom. Nemaju prodavače - samo web stranicu na koju posjetitelji klikaju i ostavljaju želje. Sukladno tome, na stranici se stalno mora postavljati nešto novo i ažurirati u skladu sa željama. Recimo, u Južnoj Koreji briju drugačije nego u Rusiji, a ne vole miris borovice, već, primjerice, mrkve i vanilije.
Budući da je potrebno brzo mijenjati sadržaj stranice, razvoj softvera se uvelike mijenja. Kroz softver moramo saznati što klijent želi. Prethodno smo to učili nekim zaobilaznim putevima, na primjer, kroz poslovno vođenje. Zatim smo to dizajnirali, postavili zahtjeve u IT sustav i sve je bilo cool. 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 funkcionira tržište i također dijele svoje uvide s tvrtkom.
Na primjer, u Qiku smo iznenada saznali da se ljudima jako sviđa učitavanje popisa kontakata na poslužitelj, pa su nam dali aplikaciju. U početku nismo razmišljali o tome. U klasičnoj tvrtki, svi bi zaključili da je to greška, budući da specifikacija nije rekla da bi trebala raditi odlično i općenito je implementirana na koljenu, isključili bi značajku i rekli: "Ovo nikome ne treba, najvažnije je da glavna funkcionalnost radi.” . I tehnološka tvrtka to vidi kao priliku i počinje mijenjati softver u skladu s tim.
Godine 1968., vizionar, Melvin Conway, formulirao je sljedeću ideju.
Organizacija koja stvara sustav ograničena je dizajnom koji replicira komunikacijsku strukturu te organizacije.
Detaljnije, da biste proizvodili sustave drugačijeg tipa, morate imati i komunikacijsku strukturu unutar poduzeća drugog tipa. Ako je vaša komunikacijska struktura visokohijerarhijska, tada vam to neće omogućiti stvaranje sustava koji mogu pružiti vrlo visok pokazatelj vremena za izlazak na tržište.
Čitati može se . Važno je za razumijevanje DevOps kulture ili filozofije jer jedino što se bitno mijenja u DevOpsu je struktura komunikacije između timova.
Sa stajališta procesa, prije DevOps-a, sve faze: analitika, razvoj, testiranje, rad, bile su linearne.
U slučaju DevOpsa, svi se ti procesi odvijaju istovremeno.
Vrijeme za izlazak na tržište jedini je način na koji se to može učiniti. Za ljude koji su radili po starom procesu, ovo izgleda nekako kozmički, i općenito tako-tako.
Dakle, zašto vam je potreban DevOps?
Za razvoj digitalnih proizvoda. Ako vaša tvrtka nema digitalni proizvod, DevOps nije potreban – vrlo je važan.
DevOps nadilazi ograničenja brzine sekvencijalne proizvodnje softvera. U njemu se svi procesi odvijaju istovremeno.
Poteškoće se povećavaju. Kada vam DevOps evangelisti kažu da će vam olakšati izdavanje softvera, to je besmislica.
S DevOpsom stvari će se samo zakomplicirati.
Na konferenciji na Avito štandu moglo se vidjeti kako je to bilo postaviti Docker kontejner – nerealan zadatak. Teškoća postaje previsoka; morate žonglirati s mnogo lopti u isto vrijeme.
DevOps potpuno mijenja proces i organizaciju u tvrtki — točnije, ne mijenja se DevOps, nego digitalni proizvod. Da biste došli do DevOps-a, morate potpuno promijeniti ovaj proces.
Pitanja za stručnjaka
Što imaš? Pitanja koja si možete postaviti dok radite u tvrtki i razvijate se kao stručnjak.
Imate li strategiju za stvaranje digitalnog proizvoda? Ako postoji, to je već dobro. To znači da se vaša tvrtka kreće prema DevOps-u.
Stvara li vaša tvrtka već digitalni proizvod? To znači da se možete popeti za još jednu višu razinu i raditi stvari zanimljivije – opet s DevOps točke gledišta. Govorim samo s ove točke gledišta.
Je li vaša tvrtka jedan od tržišnih lidera u niši digitalnih proizvoda? Spotify, Yandex, Uber su tvrtke koje su sada na vrhuncu tehnološkog napretka.
Postavite si ova pitanja i ako su svi odgovori ne, onda možda ne biste trebali raditi DevOps u ovoj tvrtki. Ako vam je tema DevOpsa stvarno zanimljiva, možda... biste trebali prijeći u drugu tvrtku? Ako vaša tvrtka želi ići u DevOps, ali ste na sva pitanja odgovorili "Ne", onda je to poput onog prekrasnog nosoroga koji se nikada neće promijeniti.
Organizacija
Kao što sam rekao, prema Conwayevom zakonu mijenja se organizacija poduzeća. Počet ću s onim što sprječava DevOps da prodre unutar tvrtke s organizacijske točke gledišta.
Problem "bunara"
Engleska riječ "Silo" ovdje je prevedena na ruski kao "bunar". Poanta ovog problema je u tome nema razmjene informacija između timova. Svaki tim kopa duboko u svoju stručnost, bez izgradnje zajedničke karte za navigaciju.
Na neki način ovo me podsjeća na osobu koja je tek stigla u Moskvu i još se ne zna snalaziti po karti metroa. Moskovljani obično vrlo dobro poznaju svoje područje i mogu se kretati diljem Moskve pomoću karte metroa. Kad prvi put dođete u Moskvu, nemate tu vještinu i jednostavno ste dezorijentirani.
DevOps predlaže da prebrodite ovaj trenutak dezorijentiranosti i da svi odjeli rade zajedno na izgradnji zajedničke karte interakcije.
Dva faktora to ometaju.
Posljedica korporativnog sustava upravljanja. Izgrađen je u zasebnim hijerarhijskim "bunarima". Na primjer, postoje određeni KPI-ovi u tvrtkama koje podržavaju ovaj sustav. S druge strane, smeta mozak osobe kojoj je teško izaći izvan granica svoje stručnosti i snaći se u cijelom sustavu. Jednostavno je neugodno. Zamislite da ste u zračnoj luci Bangkok - nećete se brzo snaći. DevOps je također težak za navigaciju i zato ljudi kažu da trebate pronaći vodiča kako biste tamo stigli.
Ali najvažnije je da se problem “bunara” za inženjera koji je prožet duhom DevOpsa, pročitao Fowlera i hrpu drugih knjiga, izražava u činjenici da "bunari" vam ne dopuštaju da radite "očite" stvari. Često se nađemo nakon DevOps Moscow, razgovaramo jedni s drugima, a ljudi se žale:
— Samo smo htjeli pokrenuti CI, ali pokazalo se da to menadžmentu nije potrebno.
To se događa upravo zato CI и Kontinuirani proces isporuke su na granici mnogih ispitivanja. Jednostavno, bez prevladavanja problema "bunara" na organizacijskoj razini, nećete moći ići naprijed, što god radili i koliko god to bilo tužno.
Svaki sudionik procesa u poduzeću: backend i frontend developeri, testiranje, DBA, operacija, mreža, kopaju u svom smjeru, a nitko nema zajedničku mapu osim menadžera koji ih na neki način prati i njima upravlja koristeći “divide i osvoji” metoda.
Ljudi se bore za neke zvjezdice ili zastavice, svatko kopa svoju stručnost.
Kao rezultat toga, kada se pojavi zadatak sve to spojiti i izgraditi zajednički cjevovod, te se više ne treba boriti za zvjezdice i zastave, postavlja se pitanje - što uopće učiniti? Treba se nekako dogovoriti, ali nitko nas u školi nije naučio kako se to radi. Od škole su nas učili: osmi razred - wow! - u usporedbi sa sedmim razredom! I ovdje je isto.
Je li tako i u vašoj tvrtki?
Kako biste to provjerili, možete si postaviti sljedeća pitanja.
Koriste li timovi zajedničke alate i doprinose li promjenama tih zajedničkih alata?
Koliko se često timovi reorganiziraju - 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 što drugo područje stručnosti radi. Prelazi u drugi odjel, radi tamo dva tjedna kako bi napravio za sebe mapu orijentacije i interakcije s tim odjelom.
Je li moguće formirati odbor za promjene i promijeniti stvari? Ili je za to potrebna čvrsta ruka najviše uprave i usmjeravanja? Nedavno sam na Facebooku napisao kako jedna malo poznata banka implementira alate preko naloga: napišemo nalog, implementiramo ga godinu dana i vidite što će biti. Ovo je, naravno, dugo i tužno.
Koliko je važno da menadžeri primaju osobna postignuća bez obzira na postignuća tvrtke?
Ako sami sebi odgovorite na ova pitanja, bit će vam jasnije imate li takav problem u svojoj tvrtki.
Infrastruktura kao šifra
Nakon što se ovaj problem riješi, prva važna praksa bez koje je teško napredovati u DevOps-u je infrastruktura kao kod.
Najčešće se infrastruktura kao kod percipira na sljedeći način:
— Automatizirajmo sve u bashu, pokrijmo se skriptama da admini imaju manje ručnog rada!
Ali to nije istina.
Infrastruktura kao kod znači da IT sustav s kojim radite opisujete u obliku koda kako biste stalno razumjeli njegovo stanje.
Zajedno s drugim timovima izrađujete kartu u obliku koda koji svatko može razumjeti i koji može navigirati i kretati se. Nije važno na čemu se radi - Chef, Ansible, Salt ili korištenje YAML datoteka u Kubernetesu - nema razlike.
Na konferenciji je kolega iz 2GIS-a ispričao kako su za Kubernetes napravili svoju internu stvar koja opisuje strukturu pojedinih sustava. Kako bi opisali 500 sustava, trebao im je poseban alat koji generira ovaj opis. Kada postoji ovaj opis, svi se mogu međusobno provjeravati, pratiti promjene, kako to promijeniti i poboljšati, što nedostaje.
Slažem se, pojedinačne bash skripte obično ne pružaju ovo razumijevanje. U jednoj od tvrtki u kojoj sam radio čak je postojao naziv za “write only” skriptu - kada je skripta napisana, ali se više ne može čitati. Mislim da je i vama ovo poznato.
Infrastruktura kao kod šifra koja 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 najboljim praksama kodiranja: zajednički razvoj, pregled koda, XP-programiranje, testiranje, zahtjevi za povlačenjem, CI za infrastrukture koda - 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, kod infrastrukture također može imati tehnički dug. Obično se timovi susreću s tim godinu i pol dana nakon što su počeli implementirati “infrastrukturu kao kod” u obliku hrpe skripti ili čak Ansiblea, koje pišu kao špageti kod, a također ubacuju i bash skripte!
To je važno: Ako još niste probali ove stvari, zapamtite to Ansible nije bash! Pažljivo pročitajte dokumentaciju, proučite što o tome pišu.
Infrastruktura kao kod je odvajanje infrastrukturnog koda u zasebne slojeve.
U našoj tvrtki razlikujemo 3 osnovna sloja, koji su vrlo jasni i jednostavni, no može ih biti i više. Možete pogledati svoj kod infrastrukture i reći imate li ovo stanje ili ne. Ako nijedan sloj nije istaknut, tada trebate odvojiti malo vremena i malo refaktorirati.
Temeljni sloj - ovako se konfiguriraju OS, sigurnosne kopije i druge stvari niske razine, na primjer, kako se Kubernetes postavlja na osnovnoj razini.
Razina usluge - ovo su usluge koje pružate developeru: logging kao usluga, monitoring kao usluga, baza podataka kao usluga, balancer kao usluga, queue kao usluga, Continuous Delivery kao usluga - hrpa usluga koje pojedini timovi može pružiti razvoju. Sve to treba opisati u zasebnim modulima u vašem sustavu upravljanja konfiguracijom.
Sloj na kojem se izrađuju aplikacije i opisuje kako će se razviti na prethodna dva sloja.
Kontrolna pitanja
Ima li vaša tvrtka zajednički repozitorij infrastrukture? Upravljate li 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 vam je za izmjene trebalo dan i pol, to znači da imate tehnički dug i da morate s njim raditi. Upravo ste naišli na tehnički dug u svom kodu infrastrukture. Sjećam se puno takvih priča kada je za promjenu nekog CCTL-a potrebno prepisati pola infrastrukturnog koda, jer je kreativnost i želja da se sve automatizira dovela do toga da je sve posvuda korodiralo, sve ručke su uklonjene, a potrebno je refaktorirati.
Kontinuirana isporuka
Usporedimo zaduženje s kreditom. Prvo dolazi opis infrastrukture, koja može biti prilično osnovna. Ne morate sve detaljno opisivati, ali neki osnovni opis je potreban da biste mogli raditi s njim. Inače, nije jasno što dalje s kontinuiranom isporukom. Sve ove prakse odvijaju se istovremeno kada dođete u DevOps, ali počinje razumijevanjem onoga što imate i kako time upravljati. To je upravo praksa infrastrukture kao koda.
Jednom kada postane jasno da ga imate i kako njime upravljati, počinjete smišljati kako programerski kod poslati u proizvodnju što je brže moguće. Mislim zajedno s programerom - sjećamo se problema "bušotina", to jest, to ne smisle pojedinačni ljudi, već tim.
Kad smo sa Vanja Evtuhovič vidio prvu knjigu Jez Humble i grupe autora "Kontinuirana isporuka", koji je objavljen 2009., dugo smo razmišljali o tome kako prevesti njegov naslov na ruski. Htjeli su to prevesti kao “Stalno isporučivati”, ali je, nažalost, prevedeno kao “Kontinuirana isporuka”. Čini mi se da ima nešto rusko u našem imenu, s pritiskom.
Stalno isporučuju sredstva
Kod koji se nalazi u repozitoriju proizvoda uvijek se može preuzeti u proizvodnju. Možda nije ispuhan, ali je uvijek spreman za to. Sukladno tome, kod uvijek pišete s teško objašnjivim osjećajem neke tjeskobe pod trticom. Često se pojavljuje kada uvedete infrastrukturni kod. Taj osjećaj tjeskobe trebao bi biti prisutan - on pokreće moždane procese koji vam omogućuju pisanje koda 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 po infrastrukturnoj platformi bacite “životni otpad” različitih formata, on postaje unificiran, teško ga je održavati i javlja se problem tehničkog duga. Format artefakta treba uskladiti - to je također zajednički zadatak: trebamo se svi skupiti, promućkati i smisliti ovaj format.
Artefakt se neprestano 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 nailazi na neke stvari koje su mu nezgodne, a koje su slične onome na što nailazi artefakt koji ste stavili u proizvodnju. Ako u klasičnom razvoju to radi sistemski administrator koji radi rollout, onda se u DevOps procesu to stalno događa: ovdje su ga testirali nekim testovima, ovdje su ga bacili u Kubernetes klaster, koji je više-manje sličan u proizvodnju, onda su iznenada započeli testiranje opterećenja.
Ovo pomalo podsjeća na igru Pac-Man - artefakt prolazi kroz neku vrstu priče. Pritom je važno kontrolirati prolazi li kod doista kroz priču i je li na neki način povezan s vašom produkcijom. Priče iz proizvodnje mogu se uvući u proces kontinuirane isporuke: bilo je ovako kad je nešto palo, sada samo programirajmo ovaj scenarij unutar sustava. Svaki put će kod također proći kroz ovaj scenarij i sljedeći put se nećete susresti s ovim problemom. Saznat ćete za to puno prije nego što stigne do vašeg klijenta.
Različite strategije implementacije. Na primjer, koristite AB testiranje ili implementaciju Canary programa kako biste različito testirali kod na različitim klijentima, dobili informacije o tome kako kod funkcionira i to mnogo ranije nego kada se uvede za 100 milijuna korisnika.
“Dosljedno isporučivati” izgleda ovako.
Proces isporuke Dev, CI, Test, PreProd, Prod nije zasebno okruženje, to su faze ili stanice s protupožarnim iznosima kroz koje prolazi vaš artefakt.
Ako imate infrastrukturni kod koji je opisan kao Base Service APP, onda pomaže ne zaboravi sve skripte, i zapišite ih kao kod za ovaj artefakt, promovirati artefakt i mijenjajte ga u hodu.
Pitanja za samotestiranje
Vrijeme od opisa značajke do puštanja u proizvodnju u 95% slučajeva je manje od tjedan dana? Poboljšava li se kvaliteta artefakta u svakoj fazi cjevovoda? Postoji li priča kroz koju to prolazi? Koristite li različite strategije implementacije?
Ako su svi odgovori potvrdni, onda ste nevjerojatno cool! Napišite svoje odgovore u komentarima - bit će mi drago).
Povratna veza
Ovo je najteža praksa od svih. Na DevOpsConf konferenciji, kolega iz Infobipa, govoreći o tome, malo se zbunio u riječima, jer ovo je stvarno vrlo kompleksna praksa o tome da treba sve pratiti!
Na primjer, davno, dok sam radio u Qiku i shvatili smo da moramo sve pratiti. Učinili smo to i sada imamo 150 stavki u Zabbixu, koje se stalno prate. Bilo je strašno, tehnički direktor je vrtio prstom na sljepoočnici:
- Ljudi, zašto silujete server s nečim nejasnim?
Ali onda se dogodio incident koji je pokazao da je ovo stvarno jako cool strategija.
Jedna od usluga počela se stalno rušiti. U početku se nije srušio, što je zanimljivo, kod tamo nije dodan, jer je to bio osnovni broker, koji praktički nije imao nikakvu poslovnu funkcionalnost - jednostavno je slao poruke između pojedinih servisa. Usluga se nije mijenjala 4 mjeseca i odjednom se počela rušiti s pogreškom "Segmentation fault".
Bili smo šokirani, otvorili smo naše grafikone u Zabbixu i pokazalo se da se prije tjedan i pol dana ponašanje zahtjeva u API servisu koji ovaj broker koristi jako promijenilo. Zatim smo vidjeli da se promijenila učestalost slanja određene vrste poruka. Kasnije smo saznali da se radi o android klijentima. Pitali smo:
— Ljudi, što vam se dogodilo prije tjedan i pol?
Kao odgovor čuli smo zanimljivu priču o tome kako su redizajnirali korisničko sučelje. Malo je vjerojatno da će netko odmah reći da je promijenio HTTP biblioteku. Za Android klijente, to je kao mijenjanje sapuna u kupaonici - jednostavno se ne sjećaju. Kao rezultat toga, nakon 40 minuta razgovora, saznali smo da su promijenili HTTP biblioteku i da su se promijenila zadana vremena. To je dovelo do promjene ponašanja prometa na API poslužitelju, što je dovelo do situacije koja je izazvala utrku unutar brokera i počeo se rušiti.
Bez dubokog praćenja općenito je nemoguće ovo otvoriti. Ako organizacija i dalje ima problem "bunara", kada se svi bacaju novcem jedni na druge, to može trajati godinama. Jednostavno restartujete poslužitelj jer je nemoguće riješiti problem. Kada nadzireš, pratiš, pratiš sve događaje koje imaš, a praćenje koristiš kao testiranje - napišeš kod i odmah naznačiš kako to pratiti, također u obliku koda (već imamo infrastrukturu kao kod), sve postaje jasno kako na dlanu. Čak i tako složene probleme lako je pratiti.
Prikupite sve informacije o tome što se događa s artefaktom u svakoj fazi procesa isporuke - ne u proizvodnji.
Uploadajte monitoring u CI, i tamo će već biti vidljive neke osnovne stvari. Kasnije ćete ih vidjeti u Testu, PredProdu i testiranju opterećenja. Prikupite informacije u svim fazama, ne samo metrike, statistike, već i zapisnike: kako je aplikacija pokrenuta, 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 bilježenje razvojni alat za vas? Kada pišete kod, razmišljaju li vaši programeri, uključujući i vas, kako ga nadzirati?
Čujete li o problemima od kupaca? Razumijete li klijenta bolje iz praćenja i zapisivanja? Razumijete li sustav bolje iz praćenja i zapisivanja? Mijenjate li sustav samo zato što ste vidjeli da trend u sustavu raste i shvaćate da će za još 3 tjedna sve umrijeti?
Nakon što imate ove tri komponente, možete razmišljati o tome kakvu infrastrukturnu platformu imate u svojoj tvrtki.
Infrastrukturna platforma
Nije stvar u tome da je to skup različitih alata koje ima svaka tvrtka.
Smisao infrastrukturne platforme je da svi timovi koriste te alate i razvijaju ih zajedno.
Jasno je da postoje zasebni timovi koji su odgovorni za razvoj pojedinih dijelova infrastrukturne platforme. Ali u isto vrijeme, svaki inženjer snosi odgovornost za razvoj, izvedbu i promociju infrastrukturne platforme. Na internoj razini postaje uobičajeni alat.
Svi timovi razvijaju infrastrukturnu platformu i pažljivo je tretiraju kao vlastiti IDE. U svom IDE-u instalirate različite dodatke kako bi sve bilo lijepo i brzo te konfigurirate prečace. Kad otvorite Sublime, Atom ili Visual Studio Code, greške u kodu pljušte i shvatite da je to uopće nemoguće raditi, odmah se rastužite i trčite popravljati svoj IDE.
Tretirajte svoju infrastrukturnu platformu na isti način. Ako shvatite da nešto nije u redu s tim, ostavite zahtjev ako to ne možete sami popraviti. Ako postoji nešto jednostavno, uredite to sami, pošaljite pull request, dečki ć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 stalno poboljšanje kvalitete. IP je programiran skupom priča koje se događaju kodu u proizvodnji. Tijekom godina razvoja, takvih je priča puno, neke su jedinstvene i odnose se samo na vas - ne mogu se guglati.
U ovom trenutku infrastrukturna platforma postaje vaša konkurentska prednost, jer ima nešto ugrađeno u sebe čega nema u alatu natjecatelja. Što je vaš IP dublji, to je veća vaša konkurentska prednost u smislu vremena izlaska na tržište. Pojavljuje se ovdje problem zaključavanja dobavljača: Možete preuzeti tuđu platformu, ali koristeći tuđe iskustvo nećete shvatiti koliko vam je relevantna. Da, ne može svaka tvrtka izgraditi platformu poput Amazona. Ovo je teška linija u kojoj je iskustvo tvrtke relevantno za njen položaj na tržištu i tu ne možete koristiti zaključavanje dobavljača. O tome je također važno razmisliti.
Shema
Ovo je osnovni dijagram infrastrukturne platforme koji će vam pomoći da postavite sve prakse i procese u DevOps tvrtki.
Pogledajmo od čega se sastoji.
Sustav orkestracije resursa, koji pruža CPU, memoriju, disk aplikacijama i drugim uslugama. Na vrhu ovoga - usluge niske razine: praćenje, bilježenje, CI/CD Engine, pohrana artefakata, infrastruktura kao kod sustava.
Usluge više razine: baza podataka kao usluga, redovi čekanja kao usluga, Balans opterećenja kao usluga, promjena veličine slike kao usluga, Big Data tvornica kao usluga. Na vrhu ovoga - cjevovod koji isporučuje stalno modificirani kod vašem klijentu.
Primate informacije o tome kako vaš softver radi za klijenta, mijenjate ga, ponovno dostavljate ovaj kod, primate informacije - i tako neprestano razvijate i infrastrukturnu platformu i svoj softver.
U dijagramu se cjevovod isporuke sastoji od mnogo faza. Ali ovo je shematski dijagram koji je dan kao primjer - nema potrebe ponavljati ga jedan po jedan. Faze su u interakciji s uslugama kao da su usluge — svaka cigla platforme nosi svoju priču: kako se resursi dodjeljuju, kako se aplikacija pokreće, radi s resursima, nadzire se i mijenja.
Važno je shvatiti da svaki dio platforme nosi priču i zapitajte se kakvu priču nosi ova cigla, možda bi je trebalo baciti i zamijeniti uslugom treće strane. Na primjer, je li moguće instalirati Okmeter umjesto cigle? Možda su dečki već razvili tu stručnost puno više od nas. Ali možda ne - možda imamo jedinstvenu stručnost, moramo instalirati Prometheus i dalje ga razvijati.
Izrada 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 i stalno ih mijenjaju različitim alatima i pristupima. Ovdje je važna kultura koju imamo u DevOps-u.
S kulturom je sve vrlo jednostavno - radi se o suradnji i komunikaciji, odnosno želju za zajedničkim radom na zajedničkom polju, želju za zajedničkim rukovanjem jednim instrumentom. Nema tu nikakve raketne znanosti – sve je vrlo jednostavno, banalno. Recimo, svi živimo u ulazu i držimo ga čistim – takva razina kulture.
Što imaš?
Opet, pitanja koja si možete postaviti.
Je li infrastrukturna platforma namjenska? Tko je odgovoran za njegov razvoj? Razumijete li konkurentske prednosti svoje infrastrukturne platforme?
Trebate si stalno postavljati ova pitanja. Ako se nešto može prenijeti na usluge trećih strana, treba se prenijeti; ako vam servis trećih strana počne blokirati kretanje, onda trebate izgraditi sustav u sebi.
Dakle, DevOps...
... ovo je složen sustav, 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 šifra.
- Odvojene prakse za održavanje pouzdanosti, ugrađene u DevOps.
- Praksa povratne informacije koja sve to opisuje.
Možete koristiti ovaj dijagram, ističući u njemu ono što već imate u svojoj tvrtki u nekom obliku: je li se razvilo ili se tek treba razvijati.
Bit će gotovo za nekoliko tjedana . u sklopu RIT++. Dođite na konferenciju gdje ćete pronaći mnogo cool izvješća o kontinuiranoj isporuci, infrastrukturi kao kodu i DevOps transformaciji. , zadnji rok cijena je 20. svibnja
Izvor: www.habr.com