Në bazë të diskutimeve në bisedë
Në kohët e fundit po shpërthejnë vërtet luftëra për të përcaktuar konceptin e DevOps dhe SRE.
Pavarësisht se debati mbi këtë temë tashmë është bërë i njohur, përfshirë dhe mua, vendosa ta paraqes për komunitetin Habr dhe perspektivën time mbi këtë temë. Të gjithë ata që janë të interesuar, janë të mirëpritur të vazhdojnë poshtë. Dhe le të fillojë gjithçka nga e para!
Pas historia
Pra, në kohët e vjetra, ekzistonte një ekip i veçantë i zhvilluesve të softuerit dhe administruesve të serverëve. Të parët shkruanin kod, të dytët, duke përdorur fjalë të ngrohta dhe të dashura për të parët, konfiguroni serverët, duke ardhur herë pas here te zhvilluesit dhe duke marrë si përgjigje një 'në makinën time gjithçka funksionon'. Biznesi prisnin softuerin, gjithçka ndalonte për shkak të problemeve, të gjithë ishin të shqetësuar. Sidomos ai, që paguante për gjithë këtë kaos. Një epokë e lavdishme e ngrohtë. Po, ju e dini se nga vjen DevOps.
Lindja e praktikave DevOps
Pastaj erdhën disa ‘djem të mençur’ dhe thanë - kjo nuk është industri, nuk mund të punoni kështu. Dhe sollën modele të ciklit të jetës. Ja, për shembull, modeli V.
Pra, çfarë shohim ne? Biznesi vjen me një koncept, arkitektët projektuan zgjidhje, zhvilluesit shkruajnë kod, më pas - kaos. Disa siç do ta testojnë produktin, disa siç do ta dërgojnë atij përdoruesi përfundimtar dhe diku në daljen e këtij modeli magjik, ulur një klient biznesi që pret nga deti cilësinë e premtuar. Arritën në përfundimin se nevojiten metoda që do të mundësonin rregullimin e këtij procesi. Dhe vendosën të krijonin praktika që do t’i zbatonin ato.
Një hapje lirike mbi çfarë është një praktikë
Praktikë unë kuptoj lidhjen e teknologjisë dhe disiplinës. Një shembull - praktika e përshkrimit të infrastrukturës me kod në terraform. Disiplina është se si të përshkruash infrastrukturën me kod, ajo është në mendjen e zhvilluesit, ndërsa teknologjia është terraform vetë.
Dhe ata vendosën t’i quajnë këto praktika DevOps - mendoj se kanë pasur parasysh nga Development to Operations. Të ndryshme gjëra të komplikuara u shpikën - praktikat CI/CD, praktikat që bazohet në parimin IaC, mijëra prej tyre. Dhe filloi, zhvilluesit shkruajnë kod, inxhinierët DevOps transformojnë përshkrimin e sistemit në formë kodi në sisteme funksionale (po, kodi është për fat të keq, vetëm një përshkrim, por aspak një implementim të sistemit), dërgimi është në qarkullim, dhe e kështu me radhë. Administratoret e djeshëm, pas mësimit të praktikave të reja, me krenari iu nënshtruan transformimit në inxhinierë DevOps, dhe kështu filloi. Dhe ishte mbrëmje, dhe ishte mëngjes… më falni, e kam marrur nga një tjetër vend.
Gjithçka sërish nuk është siç duhet
Pasi gjithçka u qetësua, dhe disa ‘metodologë’ filluan të shkruajnë libra të trashë mbi praktikat DevOps, debate të heshtura filluan se kush ishte përfundimisht inxhinieri i famshëm DevOps dhe se çfarë është DevOps - një kulturë prodhimi, një pakënaqësi e re lindi. Papritmas u zbulua se dërgimi i softuerit është një detyrë krejt normale. Çdo infrastrukturë zhvillimi kishte stek të sajin, ndonjëherë duhej të mblidhet, ndonjëherë të rrjedhë mjedisi, duhet tomcat këtu, duhet një mënyrë e duke kaluar procesin - shkurt, krejt makth. Dhe problemi, siç është për çudi, u zbulua se fillimisht ishte në organizimin e proceseve - kjo funksion dërgimi, si grykë shishe, filloi të bllokonte proceset. Po ashtu operacioni (Operations) nuk u anashkalua. Ajo nuk shihet në modelin V, por aty ndodhet gjithë cikli i jetës së djathtë. Në përfundim, duhet të mbështesim infrastrukturën, të shikojmë monitorimin, të trajtojmë incidentet dhe gjithashtu të merremi me dërgimin. Pra, duhet të jemi një këmbë në zhvillim dhe një këmbë në operacion - dhe papritmas rezultoi një Development & Operations. Dhe pastaj, hype masiv mbi mikroshërbimet erdhi. Po ashtu dhe zhvillimi nga makinat lokale filloi të kalonte në cloud - provo të debatosh diçka në mënyrë lokale, nëse ka dhjetëra dhe qindra mikroshërbime, dërgimi i vazhdueshëm bëhet një mjet mbijetese. Për një 'kompanie të vogël dhe të modeste' nuk ka gjë, por pse po ashtu? E Google?
SRE nga Google
Erdhi Google, hëngri kaktusët më të mëdhenj dhe vendosi - ne nuk e duam këtë, na nevojitet besueshmëri. Dhe besueshmërinë duhet ta menaxhojmë. Ai vendosi - na duhen specialistë që do të menaxhojnë besueshmërinë. I quajti inxhinierë SR dhe tha, ja, bëni çfarë do, si zakonisht, mirë. Ja, SLI juaj, ja SLO juaj, ja monitorimi juaj. Dhe e shtyu në operacione. Dhe e quajti DevOps-in e tij të 'besueshëm' SRE. Duket e gjitha mirë, por ka një hile të ndyrë që Google mund ta lejojë - që në pozitat e inxhinierëve SR të punësojë njerëz me kualifikime zhvilluesish dhe për më tepër, që të dinin edhe pak rreth funksionimit të sistemeve të punës. Madje, Google ka probleme me rekrutimin e këtyre njerëzve - kryesisht sepse ai vetë konkurron me veten - duhet që dikush të përshkruajë logjikën e biznesit. Dërgesën e la në duar të inxhinierëve të lëshimit, inxhinierët SR menaxhojnë besueshmërinë (sigurisht, jo drejtpërdrejt, por duke ndikuar në infrastrukturë, duke ndryshuar arkitekturën, duke ndjekur ndryshimet dhe treguesit, dhe duke u marrë me incidentet). Bukur, mund . Çfarë duhet të bëni, nëse nuk jeni Google, por besueshmëria ju shqetëson ndonjëherë?
Zhvillimi i ideve DevOps
Këtu sapo erdhi Docker, i rritur nga lxc, dhe më pas edhe sisteme të ndryshme orkestrimi si Docker Swarm dhe Kubernetes, dhe inxhinierët DevOps shpëtuan - unifikimi i praktikave e thjeshtoi dërgimin. E thjeshtoi deri në atë pikë sa u bë e mundur që dërgimin t'ua kalonin zhvillueseve - çfarë ka aty deployment.yaml. Konteinerizimi e zgjidh problemin. Po ashtu, pjekuria e sistemeve CI/CD është tashmë në një nivel ku shkruan një skedar dhe gjithçka fillon - zhvilluesit mund të vetë-përballen. Dhe këtu fillojmë të flasim se si të bëjmë SRE-në tonë, me... madje me dikë.
SRE nuk është në Google
Mirë, por dorëzimin e kemi dorëzuar, duket se mund të marrim frymë, të kthehemi në kohët e vjetra të mira kur adminët ndiqnin ngarkesën e procesorëve, rregullonin sistemet dhe në heshtje pinin nga filxhanët diçka të paqartë në qetësi dhe qetësi… Ndalo. Ne nuk e bëmë këtë për këtë (sa keq!). Papritur del se me qasjen e Google, ne mund të marrim praktikat e shkëlqyera — nuk është ngarkesa e procesorëve ajo që ka rëndësi, dhe as sa shpesh i ndryshojmë disqet, apo atje në re se sa optimizojmë koston, por metrikat e biznesit — të njëjtat SLx të njohura. Dhe menaxhimi i infrastrukturës nuk është hequr nga ato, ne duhet të menaxhojmë incidentet, dhe të jemi të pranishëm në postë periodikisht, dhe në përgjithësi të jemi në temën e proceseve të biznesit. Djem, filloni tashmë të programoni në një nivel të mirë, Google po ju pret.
Përmbledhtas. Papritur, por ju tashmë jeni lodhur të lexoni dhe ju mezi prisni të shkruani autorit në komentet e artikullit. DevOps si praktika e dorëzimit, ka qenë, është dhe do të jetë. Dhe nuk do të shpëtojë askund. SRE si një grup praktikash operacionale e bën këtë dorëzim të suksesshëm.
Burimi: habr.com
