Në frymën e diskutimit në chat
Së fundmi, po ndezin luftëra të vërteta rreth definicionit të konceptit të DevOps dhe SRE.
Megjithëse shumë nga diskutimet mbi këtë temë e kanë humbur freskinë, përfshirë edhe për mua, vendosa t'ia paraqes komunitetit të Habrës pikëpamjen time mbi këtë temë. Ata që janë të interesuar, janë të mirëpritur të ndjekin poshtë. Dhe le të fillojë gjithçka përsëri!
Historia e mëparshme
Pra, në ditët e vjetra, ekzistonte një ekip i veçantë i zhvilluesve të softuerit dhe administratorëve të serverëve. Të parët shkruanin kod me sukses, ndërsa të dytët, pasi përdornin fjalë të ngrohta dhe të dashura për të parët, konfiguronte serverët, duke shkuar nganjëherë te zhvilluesit dhe duke marrë si përgjigje një "në makinën time punon gjithçka". Biznesi priste softuerin, gjithçka ishte në pritje, herë-herë prishej, të gjithë ishin të nervozuar. Sidomos ai që paguante për këtë kaos. Një epokë e mrekullueshme e zakonshme. Epo, ju e dini se nga vjen DevOps.
Lindja e praktikave DevOps
Pastaj erdhën disa burra të rëndësishëm dhe thanë - kjo nuk është një industrinë, kështu nuk mund të punohet. Dhe sollën modelet e ciklit të jetës. Ja, për shembull, modeli V.
Pra, çfarë shohim? Biznesi vjen me një koncept, arkitektët projektojnë zgjidhje, zhvilluesit shkruajnë kod, më pas - dështim. Disa si ndonjëherë testojnë produktin, disa si ndonjëherë e dorëzojnë atë te përdoruesi përfundimtar dhe diku në fund të këtij modeli mrekullibërës qëndron një biznes-prapambetje dhe pret që premtimi të realizohet. Arritën në përfundimin - janë të nevojshme metoda që do të lejojnë që ky proces të funksionojë. Dhe vendosën të krijojnë praktika që do t'i realizonin ato.
Një tërheqje lirike për atë se çfarë është praktika
Praktikën e kuptoj si lidhjen midis teknologjisë dhe disiplinës. Një shembull - praktika e përshkrimit të infrastrukturës me kod në terraform. Disiplina është ajo se si të përshkruajmë infrastrukturën me kod, ajo është në mendjen e zhvilluesit, ndërsa teknologjia është vetë terraform.
Dhe vendosën t'i quajnë praktikat DevOps - mendoj se do të thoshin nga Zhvillimi në Operacione. Shkruan ide të ndryshme komplekse - praktikat CI/CD, praktikat që bazohen në parimin IaC, mijëra të tilla. Dhe e gjithë kjo filloi: zhvilluesit shkruajnë kod, inxhinierët DevOps transformojnë përshkrimin e sistemit në formë kodi në sisteme funksionale (po, kodi është në fakt vetëm një përshkrim, por asnjë mënyrë nuk është një realizim i sistemit), dërgimi rrotullohet, dhe kështu me radhë. Administratoret e djeshme, të cilët zotëruan praktikat e reja, me krenari u rikualifikuan si inxhinierë DevOps, dhe e gjithë kjo filloi. Dhe ishte mbrëmje, dhe ishte mëngjes... më falni, jo nga aty.
Të gjithë përsëri nuk është ashtu si duhet.
Pasi gjithçka u qetësua, dhe metodologët e ndryshëm të zgjuar filluan të shkruanin libra të trashë mbi praktikat DevOps, filluan të ndiznin debate se kush është në fakt i famshmi inxhinier DevOps dhe çfarë është DevOps - një kulturë prodhimi, përsëri ndjeu mospajtim. Papritur u zbulua se shpërndarja e softuerit është një detyrë krejtësisht jo triviale. Çdo infrastrukture zhvillimi ka një stek të vetin; ndoshta duhet të projektohet, ndoshta duhet të ngrihet një ambient, aty nevojitet tomcat, këtu nevojitet një mënyrë e caktuar e nisjes - në përgjithësi, koka ka filluar të dhembë. Dhe çudia, problemi fillestar ishte në organizimin e proceseve - kjo funksion shpërndarjeje, si një grykë shisheje, filloi të bllokonte proceset. Gjithashtu, operimi (Operations) nuk është anuluar. Ai nuk duket në modelin V, dhe atje është gjithë cikli i jetës për të djathtën. Në fund, duhet të mirëmbani infrastrukturën, të shikoni në monitorim, të zgjidhni incidente, dhe për më tepër, të angazhoheni me shpërndarjen. Kjo do të thotë të jesh një këmbë në zhvillim dhe një këmbë në operim - dhe kështu lindi ky Development & Operations. Dhe këtu erdhi gjithashtu një bujë e madhe për mikroshërbimet. Dhe me ta, zhvillimi nga makinat lokale filloi të kalonte në cloud - provo të debugosh diçka lokalisht, nëse ka dhjetra dhe qindra mikroshërbime, këtu shpërndarja e përhershme bëhet një mjet mbijetese. Për një "kompani të vogël modeste" akoma është diku, por në fund të fundit? Dhe Google?
SRE nga Google
Erdhi Google, hëngri kaktusët më të mëdhenj dhe vendosi - ne nuk kemi nevojë për diçka si kjo, na nevojitet besueshmëri. Dhe për t'u menaxhuar besueshmëria. Ai vendosi - na duhen specialistë që do të menaxhojnë besueshmërinë. I emërtoi ata inxhinierë SR dhe u tha, ja ku jeni, bëni, si zakonisht, mirë. Ja ku keni SLI, ja ku keni SLO, ja ku keni monitorim. Dhe iu tregua operacioneve. Ai e quajti DevOps-in e tij të 'besueshëm' SRE. Duket se gjithçka është mirë, por ka një hile të papastër që Google mund të lejojë - në pozitat e inxhinierëve SR punëson njerëz që kishin aftësi si zhvillues dhe gjithashtu dijnë pak rreth funksionimit të sistemeve në punë. Ndërsa për të punësuar këta njerëz, edhe Google ka probleme - kryesisht sepse ai konkurron vetë me veten - dikush duhet të përshkruajë logjikën e biznesit. Dërgimin e ka vendosur te inxhinierët e lëshimit, inxhinierët SR 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 incidentet). Bukur, mund . Çfarë duhet të bëni, nëse nuk jeni Google, por besueshmëria gjithsesi ju shqetëson?
Zhvillimi i ideve DevOps
Këtu sapo është arritur Docker, i rritur nga lxc, dhe më pas sisteme të ndryshme orkestrimi si Docker Swarm dhe Kubernetes, dhe inxhinierët DevOps u lehtësuan - unifikimi i praktikave e thjeshtoi dërgimin. E thjeshtoi deri në atë pikë sa bëri të mundur edhe t'i dorëzohet zhvilluesve - çfarë është atje deployment.yaml. Kontejnerizimi e zgjidh problemin. Po ashtu, pjekuria e sistemeve CI/CD tashmë është në nivelin që shkruan një skedë dhe gjithçka fillon - zhvilluesit vetë do të merren me këtë. Dhe këtu fillojmë të flasim se si ta bëjmë SRE-në tonë, me... qoftë me dikë.
SRE jo në Google
Mirë, e dorëzuam dërgesën, duket se mund të marrim frymë thellë, të kthehemi në kohët e vjetra kur administratorët monitoronin ngarkesën e procesorëve, optimizonin sistemet dhe qetësisht pinin diçka të pazakontë nga gota në heshtje dhe paqe... Prit. Ne nuk e bëmë gjithë këtë për këtë (e kishim dëshirë!). Papritmas del se në qasjen e Google mund të mirremi me praktikat e shkëlqyera - nuk është ngarkesa e procesorëve ajo që ka rëndësi, as sa shpesh i ndryshojmë diskët, ose sa optimizojmë koston aty në cloud, por metrikat e biznesit - të gjitha ato të njohura SLx. Dhe menaxhimi i infrastrukturës mbetet, duhet të zgjidhim incidentet, të jemi në gatishmëri herë pas here dhe në përgjithësi të jemi në temën e proceseve të biznesit. Djem, filloni të programoni pak në një nivel të mirë, Google ju pret.
Për të përmbledhur. Papritmas, por ju tashmë jeni lodhur duke lexuar dhe nuk keni durim të shkruani një koment për autorin e artikullit. DevOps si praktikë e dërgesës, ka qenë, është dhe do të jetë. Dhe nuk do të zhduket. SRE si një grup praktikash të eksploatimit e bën këtë dërgesë të suksesshme.
Burimi: habr.com
