Bazuar në një diskutim bisede
Kohët e fundit, betejat e vërteta janë ndezur mbi përkufizimin e DevOps dhe SRE.
Përkundër faktit se në shumë mënyra diskutimet mbi këtë temë tashmë më kanë vënë dhëmbët në buzë, duke përfshirë edhe mua, vendosa ta sjell pikëpamjen time mbi këtë temë në gjykatën e komunitetit Habra. Per te interesuarit mirepresim ne cat. Dhe le të fillojë gjithçka përsëri!
parahistorinë
Pra, në kohët e lashta, një ekip zhvilluesish softuerësh dhe administratorësh të serverëve jetonin veçmas. I pari shkroi me sukses kodin, i dyti, duke përdorur fjalë të ndryshme të ngrohta, të dashura drejtuar të parit, vendosi serverët, duke ardhur periodikisht te zhvilluesit dhe duke marrë si përgjigje një "gjithçka funksionon në makinën time". Biznesi po priste softuerin, gjithçka ishte boshe, prishej periodikisht, të gjithë ishin nervozë. Sidomos ai që pagoi gjithë këtë rrëmujë. Epoka e lavdishme e llambave. Epo, ju tashmë e dini se nga vjen DevOps.
Lindja e praktikave DevOps
Pastaj erdhën djem seriozë dhe thanë - kjo nuk është një industri, nuk mund të punosh kështu. Dhe ata sollën modele të ciklit jetësor. Këtu, për shembull, është modeli V.
Pra, çfarë shohim? Një biznes vjen me një koncept, arkitektët projektojnë zgjidhje, zhvilluesit shkruajnë kodin dhe më pas ai dështon. Dikush e teston disi produktin, dikush disi ia dorëzon përdoruesit përfundimtar dhe diku në daljen e këtij modeli të mrekullueshëm ulet një klient i vetmuar biznesi duke pritur motin e premtuar buzë detit. Ne arritëm në përfundimin se kemi nevojë për metoda që do të na lejojnë të vendosim këtë proces. Dhe vendosëm të krijonim praktika që do t'i zbatonin ato.
Një digresion lirik mbi temën se çfarë është praktika
Me praktikë nënkuptoj një kombinim të teknologjisë dhe disiplinës. Një shembull është praktika e përshkrimit të infrastrukturës duke përdorur kodin terraform. Disiplina është se si të përshkruani infrastrukturën me kod, ajo është në kokën e zhvilluesit dhe teknologjia është vetë terraforma.
Dhe ata vendosën t'i quanin praktika DevOps - mendoj se ata kishin për qëllim nga Zhvillimi në Operacione. Ne dolëm me gjëra të ndryshme të zgjuara - praktika CI/CD, praktika të bazuara në parimin IaC, mijëra prej tyre. Dhe largohemi, zhvilluesit shkruajnë kodin, inxhinierët DevOps transformojnë përshkrimin e sistemit në formën e kodit në sisteme funksionale (po, kodi është, për fat të keq, vetëm një përshkrim, por jo mishërimi i sistemit), shpërndarja vazhdon, e kështu me radhë. Administratorët e djeshëm, pasi kishin zotëruar praktika të reja, u rikualifikuan me krenari si inxhinierë DevOps dhe gjithçka shkoi prej andej. Dhe erdhi mbrëmje, dhe erdhi mëngjesi... më falni, jo nga atje.
Nuk është gjithçka mirë përsëri, falë Zotit
Sapo gjithçka u qetësua dhe "metodologë" të ndryshëm dinakë filluan të shkruanin libra të trashë mbi praktikat e DevOps, mosmarrëveshjet u ndezën në heshtje se kush ishte inxhinieri famëkeq DevOps dhe se DevOps është një kulturë prodhimi, pakënaqësia u ngrit përsëri. Papritur doli që shpërndarja e softuerit është një detyrë absolutisht jo e parëndësishme. Çdo infrastrukturë zhvillimi ka pirgun e vet, diku duhet ta montoni, diku duhet të vendosni mjedisin, këtu keni nevojë për Tomcat, këtu keni nevojë për një mënyrë dinake dhe të ndërlikuar për ta nisur atë - në përgjithësi, koka juaj po përplaset. Dhe problemi, çuditërisht, doli të ishte kryesisht në organizimin e proceseve - ky funksion shpërndarjeje, si një pengesë, filloi të bllokojë proceset. Përveç kësaj, askush nuk i anuloi Operacionet. Nuk është e dukshme në modelin V, por ende është i gjithë cikli i jetës në të djathtë. Si rezultat, është e nevojshme që disi të ruhet infrastruktura, të monitorohet monitorimi, të zgjidhen incidentet dhe gjithashtu të merret me dorëzimin. Ato. uluni me një këmbë si në zhvillim ashtu edhe në funksionim - dhe papritmas doli të ishte Zhvillimi dhe Operacionet. Dhe më pas ishte zhurma e përgjithshme për mikroshërbimet. Dhe me ta, zhvillimi nga makinat lokale filloi të lëvizte në re - përpiquni të korrigjoni diçka në nivel lokal, nëse ka dhjetëra e qindra mikroshërbime, atëherë shpërndarja e vazhdueshme bëhet një mjet mbijetese. Për një "kompani të vogël modeste" ishte në rregull, por prapë? Po Google?
SRE nga Google
Google erdhi, hëngri kaktusët më të mëdhenj dhe vendosi - ne nuk kemi nevojë për këtë, ne kemi nevojë për besueshmëri. Dhe besueshmëria duhet të menaxhohet. Dhe vendosa që ne kemi nevojë për specialistë që do të menaxhojnë besueshmërinë. I thirra inxhinierë SR dhe u thashë, kjo është për ju, bëjeni mirë si zakonisht. Këtu është SLI, këtu është SLO, këtu është monitorimi. Dhe ai futi hundën në operacion. Dhe ai e quajti "DevOps të besueshëm" SRE. Gjithçka duket të jetë mirë, por ka një hak të ndyrë që Google mund të përballojë - për pozicionin e inxhinierëve SR, punësoni njerëz që ishin zhvillues të kualifikuar dhe gjithashtu bënin pak detyra shtëpie dhe kuptonin funksionimin e sistemeve të punës. Për më tepër, vetë Google ka probleme me punësimin e njerëzve të tillë - kryesisht sepse këtu konkurron me veten - është e nevojshme t'i përshkruhet dikujt logjika e biznesit. Dorëzimi u caktua për lëshimin e inxhinierëve, SR - inxhinierët menaxhojnë besueshmërinë (natyrisht, jo drejtpërdrejt, por duke ndikuar në infrastrukturë, duke ndryshuar arkitekturën, duke ndjekur ndryshimet dhe treguesit, duke u marrë me incidente). E bukur, mundesh . Por, çka nëse nuk jeni Google, por besueshmëria është ende një shqetësim?
Zhvillimi i ideve të DevOps
Pikërisht atëherë mbërriti Docker, i cili u rrit nga lxc, dhe më pas sisteme të ndryshme orkestrimi si Docker Swarm dhe Kubernetes, dhe inxhinierët e DevOps nxorrën - unifikimi i praktikave thjeshtoi shpërndarjen. Ai e thjeshtoi atë në një masë të tillë sa u bë e mundur që të transferohej edhe ofrimi te zhvilluesit - çfarë është deployment.yaml. Kontejnerizimi e zgjidh problemin. Dhe pjekuria e sistemeve CI/CD është tashmë në nivelin e shkrimit të një skedari dhe ne ikim - zhvilluesit mund ta trajtojnë vetë. Dhe pastaj fillojmë të flasim se si mund të bëjmë SRE-në tonë, me... ose të paktën me dikë.
SRE nuk është në Google
Epo, ok, dërguam dërgesën, duket se mund të nxjerrim frymë, të kthehemi në ditët e mira të vjetra, kur administratorët shikonin ngarkesën e procesorit, akordonin sistemet dhe pinin në heshtje diçka të pakuptueshme nga kriklla në paqe dhe qetësi... Ndalo. Kjo nuk është arsyeja pse ne filluam gjithçka (që është për të ardhur keq!). Papritmas rezulton se në qasjen e Google mund të adoptojmë lehtësisht praktika të shkëlqyera - nuk është ngarkesa e procesorit që është e rëndësishme dhe jo sa shpesh i ndryshojmë disqet atje, ose optimizojmë koston në cloud, por metrikat e biznesit janë të njëjtat famëkeqe SLx. Dhe askush nuk e ka hequr menaxhimin e infrastrukturës prej tyre, dhe ata duhet të zgjidhin incidentet, të jenë në detyrë periodikisht, dhe në përgjithësi të qëndrojnë në krye të proceseve të biznesit. Dhe djema, filloni të programoni pak nga pak në një nivel të mirë, Google tashmë ju pret.
Për të përmbledhur. Papritur, por tashmë jeni lodhur duke lexuar dhe mezi prisni të pështyni dhe t'i shkruani autorit në një koment për artikullin. DevOps si një praktikë shpërndarjeje ka qenë gjithmonë dhe do të jetë. Dhe nuk po shkon askund. SRE si një grup praktikash operacionale e bën këtë ofrim shumë të suksesshëm.
Burimi: www.habr.com