Përcaktimi i DevOps është shumë i komplikuar, prandaj çdo herë duhet të nisim një diskutim të ri rreth kësaj teme. Vetëm në Habr ka mijëra publikime mbi këtë temë. Por nëse jeni duke e lexuar këtë, me siguri e dini se çfarë është DevOps. Sepse unë - nuk e di. Përshëndetje, unë quhem Aleksandër Titov (@), dhe ne do të flasim thjesht për DevOps dhe do të ndaj përvojën time.
Kam menduar për një kohë të gjatë se si ta bëj tregimin tim të dobishëm, prandaj këtu do të ketë shumë pyetje - ato që vetë i bëj dhe ato që iu bëj klientëve të kompanisë sonë. Duke iu përgjigjur këtyre pyetjeve, kuptimi bëhet më i qartë. Do të flas për pse është e nevojshme DevOps nga këndvështrimi im, çfarë është kjo, përsëri, nga pozita ime, dhe si ta kuptoni nëse po lëvizni drejt DevOps, përsëri nga këndvështrimi im. Pika e fundit do të jetë përmes pyetjeve. Duke iu përgjigjur atyre vetë, do të jeni në gjendje të kuptoni nëse kompanitë tuaja po shkojnë drejt DevOps apo ka ndonjë problem.
Një herë, unë shëtita në valët e bashkimeve dhe blerjeve. Fillimisht punova në një startup të vogël, Qik, pastaj e bleu një kompani pak më e madhe, Skype, e cila më vonë u bleu nga një kompani akoma më e madhe, Microsoft. Në atë moment, pata një vizion se si transformohet perceptimi për DevOps në kompani të ndryshme në madhësi. Pas kësaj, më interesoi të shikoj DevOps nga këndvështrimi i tregut, dhe së bashku me kolegët, organizuam kompaninë Ekspress 42. Tani jemi 6 vjet në këtë rrugë në valët e tregut.
Përveç kësaj, unë jam një nga organizatorët e komunitetit DevOps Moscow dhe organizator i DevOps Days 2017, por në 2018 nuk e organizova. Ekspress 42 punon me shumë kompani. Ne zhvillojmë DevOps aty, shohim si ndodh, nxjerrim përfundime, analizojmë, ndajmë përfundimet tona me të gjithë, dhe i mësojmë njerëzit në praktikat DevOps. Në përgjithësi, po rrisim përvojën dhe ekspertizën në këtë drejtim.
Pse DevOps
Pyetja e parë që ndjek të gjithë dhe gjithmonë është – pse? Shumë mendojnë se DevOps është thjesht automatizim ose ndonjë gjë e ngjashme që tashmë ka qenë në çdo kompani.
— Ne kemi pasur Continuous Integration — do të thotë që tashmë ka qenë DevOps, dhe përse është e nevojshme gjithë kjo? Aty jashtë argëtohen, ndërsa ne na pengojnë të punojmë!
Pas 9 vjetësh të zhvillimit të komunitetit dhe metodologjisë, tashmë është e qartë se këto nuk janë thjesht shkëlqime marketingu, por akoma nuk e kuptojmë plotësisht përse është i nevojshëm. Sikurse çdo mjet dhe proces, DevOps ka objektiva të caktuara që ai në fund zgjidh.
E gjithë kjo lidhet me faktin se bota po ndryshon. Po largohet nga qasja enterprise, kur kompanitë lëvizin direkt drejt ëndrrës, siç këndonte klasiku ynë nga Shën Peterburgu, nga pika A në pikën B sipas një strategjie të caktuar, me një strukturë të ndërtuar për këtë.
Në principe, në IT gjithçka duhet të ndërt exposedt mbi këtë qasje. Këtu IT përdoret ekskluzivisht për automatizimin e proceseve.
Automatizimi nuk ndryshon shpesh, sepse kur një kompani është duke ecur në shtegun e përshkruar — çfarë do të ndryshosh? Funksionon — mos e prek. Tani në botë qasjet po ndryshojnë, dhe ajo që quhet Agile tregon se pika përfundimtare B nuk është e dukshme menjëherë.
Kur kompanit shkon në treg, punon me klientin — ajo vazhdimisht hulumton tregun dhe ndryshon pikën përfundimtare B. Sa më shpesh të ndryshojë drejtimin e saj, aq më e suksesshme bëhet, sepse zgjat më shumë niša tregu.
Strategjinë e tregon një kompani interesante, për të cilën mësova së fundmi. One Box Shave — një shërbim që ofron dërgesë të razorëve dhe pajisjeve për rruajtje në çështje abonimi brenda një kuti. Ata dinë të personalizojnë "kutinë" e tyre për klientë të ndryshëm. Këtë e bën një software i caktuar që pastaj dërgon porosinë në fabrikën koreane që prodhon mallin.
Ky produkt u ble nga kompania Unilever për 1 miliard dollarë. Tani ai konkurron me Gillette dhe ka marrë një pjesë të konsiderueshme të konsumatorëve në tregun amerikan. One Box Shave thotë:
— 4 lamë? A seriozisht? Pse ju nevoitet kjo — kjo asnjëherë nuk përmirëson cilësinë e rruajtjes. Një krem i përzgjedhur, një aromë dhe një razor cilësor me dy lama zgjidhin shumë më tepër çështje sesa këto katër lama të dëmshme Gillette! Kështu do të arrijmë deri në 10?
Kështu po ndryshon bota. Unilever deklaron se kanë një sistem IT të shkëlqyer që e bën këtë të mundur. Në fund, kjo duket si një koncept Koha për treg, për të cilin kanë folur tashmë shumë njerëz.
Kuptimi i kohës për treg nuk është se sa shpesh ne bëjmë depolimin. Mund të bëhet depolim shpesh, por ciklet e lëshimit do të jenë të gjata. Nëse ciklet e lëshimit prej tre muajsh vendosen njërën mbi tjetrën, duke i shtyrë për një javë, duket se kompania po depolon çdo javë. Por ideja deri te realizimi përfundimtar zgjat 3 muaj.
Koha për treg është për minimizimin e kohës nga ideja deri te realizimi përfundimtar.
Në këtë rast, softueri ndërvepron me tregun. Kështu, One Box Shave ka ndërveprime me klientin përmes faqes së tyre. Ata nuk kanë shitës - thjesht një faqe, ku vizitori klikoni dhe lë preferencat e tij. Prandaj, faqja duhet të publikojë vazhdimisht diçka të re, për t'u përditësuar në përputhje me dëshirat. Për shembull, në Kore, nuk depilojnë si në Rusi, dhe ata preferojnë aromën e vaniljes me karotë nga ajo e pishës.
Me sa duhet të ndërrojmë shpejt përmbajtjen e faqeve, zhvillimi i softuerit ka ndryshuar ndjeshëm. Me anë të softuerit, ne duhet të kuptojmë se çfarë dëshiron klienti. Më parë, ne e mësuam këtë përmes disa rrugëve alternative, për shembull, përmes menaxhimit të biznesit. Pastaj e projektuan, përcaktuan kërkesat në sistemin IT, dhe gjithçka ishte në rregull. Tani është ndryshe – softueri projektit zhvillohet nga të gjithë që janë të përfshirë në proces, përfshirë inxhinierët, sepse ata mësojnë përmes specifikimeve teknike se si funksionon tregu dhe gjithashtu ndajnë me biznesin njohuritë e tyre.
Për shembull, në kompaninë Qik, ne papritmas mësuam se njerëzit e duan shumë të ngarkojnë lista kontakti në server, dhe ata na sollën një aplikacion. Fillimisht ne nuk e kishim menduar këtë. Në një kompani tradicionale, të gjithë do të kishin menduar se ishte një problem, pasi në specifikim nuk ishte shkruar që kjo duhej të funksiononte mirë dhe ishte realizuar më shumë në mënyrë të improvizuar, do ta kishin ndaluar atë veçori dhe do thoshin: "Kjo nuk është e nevojshme për askënd, e rëndësishme është që funksionaliteti kryesor funksionon". Një kompani teknologjike në këtë e sheh si mundësi dhe fillon të ndryshojë softuerin në përputhje me këtë.
Në vitin 1968, djali i mençur Melvin Conway formuloi këtë ide.
Organizata që krijon një sistem është e kufizuar nga dizajni që kopjon strukturën e komunikimit në këtë organizatë.
Më në detaje, për të prodhuar sisteme të një lloji tjetër, duhet gjithashtu të kemi një strukturë komunikimi brenda kompanisë që është e ndryshme. Nëse keni një strukturë komunikimi të nivelit të lartë hierarkik, kjo nuk do t'ju lejojë të krijoni sisteme që mund të sigurojnë një përqindje shumë të lartë të shpejtësisë së sjelljes në treg.
Lexoni mund të . Ai është i rëndësishëm për të kuptuar kulturën ose filozofinë DevOps, pasi e vetmja gjë që ndryshon themelore në DevOps është saktësisht struktura e komunikimit midis ekipeve..
Nga perspektiva e procesit, para DevOps, të gjitha fazat: analiza, zhvillimi, testimi, operimi, kalonin në mënyrë lineare.
Në rastin e DevOps, të gjithë këto procese shkojnë njëkohësisht.
Shpejtësia e sjelljes në treg mund të realizohet vetëm kështu. Për njerëzit që kanë punuar në procesin e vjetër, kjo duket disi kozmike dhe në përgjithësi jo shumë e mirë.
Pse është e nevojshme DevOps?
Për zhvillimin e produkteve digjitale. Nëse kompania juaj nuk ka një produkt digjital, DevOps nuk është e nevojshme - kjo është shumë e rëndësishme.
DevOps kalon kufijtë e shpejtësisë së një skeme tradicionale të prodhimit të softuerit. Në të gjitha proceset ndodhin në një kohë.
Përfundon duke u bërë më e komplikuar. Kur evangjelistët e DevOps-it thonë se me të do t'ju bëhet më e lehtë të lëshoni softuer - kjo është nonsense.
Me DevOps gjithçka do të jetë më e ndërlikuar.
Në konferencë, në stendën e Avito, mund të shihni se çfarë do të thotë të vendosësh një kontejner Docker - një detyrë e pamundur. Kompleksiteti bëhet ekstreme, duhet të jongloni me shumë topa në të njëjtën kohë.
DevOps ndryshon plotësisht procesin dhe organizatën në kompani — saktësisht, ndryshon jo DevOps, por produktin digjital. Për të arritur në DevOps, duhet ta ndryshoni plotësisht këtë proces.
Pyetje për specialistin
Çfarë ndodh me ju? Pyetje që mund t'i bëni vetes, kur punoni në kompani dhe përfitoni si specialist.
A keni një strategji për krijimin e produktit digjital? Nëse po - kjo është mirë. Kjo do të thotë se kompania juaj po ecën drejt DevOps.
A po krijon kompania juaj një produkt digjital? Kjo do të thotë se mund të ngjiteni edhe një shkallë më lart, duke u angazhuar në aktivitete më interesante - nga këndvështrimi i DevOps, përsëri. Po e them vetëm nga ky këndvështrim.
A është kompania juaj një nga liderët e tregut në nişën e produkteve digjitale? Spotify, Yandex, Uber - kompani që janë në kulmin e përparimit teknologjik tani.
Bëni këto pyetje për veten dhe nëse të gjitha përgjigjet janë negative, ndoshta nuk duhet të angazhoheni me DevOps në këtë kompani. Nëse tema e DevOps është vërtet interesante për ju, ndoshta... duhet të kaloni në një kompani tjetër? Nëse kompania juaj dëshiron të shkojë në DevOps, por ju përgjigjët me "Jo" për të gjitha pyetjet, atëherë ajo i ngjan atij rinocerosi të mrekullueshëm që kurrë nuk do të ndryshojë.
Organizata
Siç kam thënë tashmë, sipas ligjit të Conway-t, organizata e kompanisë ndryshon. Do të filloj me pengesat që i ndalojnë DevOps-it të depërtojë brenda kompanisë, pikërisht nga këndvështrimi i organizatës.
Problemi i "tubave"
Fjala angleze "Silo" është përkthyer këtu në rusisht si "kolodec". Kuptimi i këtij problemi është se nuk ka shkëmbim informacioni midis ekipeve.. Çdo ekip thellon ekspertizën e tij, duke mos ndërtuar një mapë të përgjithshme për orientim.
Kjo të ngjan disi me një njeri që sapo ka mb arrive në Moskë dhe ende nuk di të orientojë në hartën e metrosë. Moskvi i njohin zakonisht mirë lagjen e tyre, ndërsa në të gjithë Moskën orientohen sipas hartës së metrosë. Kur arrin në Moskë për herë të parë, nuk e ke këtë aftësi dhe thjesht je i zhgënjyer.
DevOps ofron mundësinë për të kaluar këtë moment të zhgënjimit dhe që të gjitha njësite të ndërtojnë së bashku një hartë të përbashkët të bashkëpunimit.
Kjo pengohet nga dy faktorë.
Pasojat e sistemit korporativ të menaxhimit. Ai është ndërtuar në «pushta» të veçanta hierarkike. Për shembull, ka KPI të caktuara në kompani që e mbështesin këtë sistem. Nga ana tjetër, pengon truri i njeriut, i cili ka vështirësi të dalë jashtë ekspertizës së tij dhe të orientohet në gjithë sistemin. Thjesht nuk është komod. Imagjinoni se si do të ndiheshit në aeroportin e Bangokut – nuk është e lehtë të orientohesh shpejt. Edhe në DevOps është e vështirë të orientohesh, prandaj njerëzit thonë se duhet të gjejmë një udhëheqës për të arritur atje.
Porosia më e rëndësishme është se problemin e "pusave" për inxhinierin që ka marrë frymë nga fryma DevOps, ka lexuar Fowler dhe shumë libra të tjerë, shprehet në atë që "pusat" nuk lejojnë të bëhen gjëra "të dukshme". Ne shpesh mblidhemi pas DevOps Moscow, bisedojmë me njëri-tjetrin dhe njerëzit ankohen:
— Ne thjesht donim të nisnim CI, por rezultoi se menaxhmenti nuk e kishte për synim.
Kjo ndodh pikërisht për shkak se CI dhe procesi i Continuous Delivery është në kufirin e shumë ekspertizave. Thjesht, duke mos e tejkaluar problemin e "pusave" në nivelin organizativ, nuk do të arrijmë të avancojmë më tej, pavarësisht se çfarë bëni dhe sa e trishtë që është.
Çdo pjesëmarrës në proces në kompani: zhvilluesit e backend-it dhe frontend-it, testimi, DBA, operimi, rrjeti, po çajnë në anën e tyre, dhe askush nuk ka një hartë të përbashkët, përveç menaxherit, i cili i sheh dhe i menaxhon me metodën "ndaje dhe sundo".
Njerëzit luftojnë për disa yje apo flamuj, secili çan ekspertizën e tij.
Si në fund, kur shfaqet detyra për të lidhur gjithçka së bashku dhe për të ndërtuar një pipeline të përbashkët, dhe për yjet dhe flamujt nuk ka më nevojë të luftohet, shfaqet pyetja - çfarë duhet të bëjmë në fakt? Duhet të arrijmë një marrëveshje, por si ta bëjmë këtë, askush nuk na mësoi në shkollë. Jemi mësuar që që në shkollë: klasa e tetë - oho! - në krahasim me klasën e shtatë! Këtu është njësoj.
A është kështu edhe në kompaninë tuaj?
Për ta verifikuar këtë, mund të bëni këto pyetje për vete.
A e përdorin ekipet mjetet e përbashkëta, a kontribuojnë në ndryshimet e këtyre mjeteve të përbashkëta?
Sa shpesh riformohen ekipet - specialistë nga një ekip kalojnë në një ekip tjetër? Veçanërisht në mjedisin DevOps, kjo bëhet normale, sepse ndonjëherë një person thjesht nuk mund të kuptojë se çfarë po bën një zonë tjetër ekspertize. Ai kalon në departamentin tjetër, punon aty për dy javë, për të krijuar një hartë orientimi dhe bashkëpunimi me këtë departament.
A mund të krijohet një komitet për ndryshime dhe të bëhen disa ndryshime? A është e nevojshme që një dorë e fortë nga drejtuesit më të lartë të jetë e angazhuar për këtë dhe një urdhër? Kohët e fundit kam shkruar në Facebook se si një bankë e panjohur, përmes urdhërave, po implementon metoda: kanë shkruar një urdhër, e zbatojnë për një vit, dhe shohin se çfarë ndodh. Sigurisht, kjo është e gjatë dhe e trishtueshme.
Sa e rëndësishme është për menaxherët të marrin arritje personale pa marr parasysh arritjet e kompanisë?
Nëse i jepni përgjigje këtyre pyetjeve për vete, do të kuptoni nëse keni një problem të tillë në kompani.
Infrastruktura si kod
Pas zgjidhjes së këtij problemi, praktika e parë e rëndësishme, e cila e bën të vështirë avancimin më tej në DevOps, është infrastruktura si kod.
Shpesh infrastruktura si kod kuptohet kështu:
— Le të automatizojmë gjithçka me bash, të mbulohemi me skripta, që administratoret të kenë më pak punë manuale!
Por, ajo nuk është kështu.
Infrastruktura si kod nënkupton se sistemi IT me të cilin punoni e përshkruani në formë kodi, për ta kuptuar vazhdimisht gjendjen e tij.
Së bashku me ekipet e tjera, krijoni një hartë të formatuar si kod, që është e kuptueshme për të gjithë dhe mbi të cilën mund të orientoheni dhe navigoni. Nuk ka rëndësi se çfarë përdoret për këtë — Chef, Ansible, Salt, ose përdorimi i skedarëve YAML në Kubernetes — nuk bën diferencë.
Në konferencë, një koleg nga 2GIS tregoi se si ata krijuan një mjet të brendshëm për Kubernetes, i cili përshkruan funksionimin e sistemeve të veçanta. Për të përshkruar 500 sisteme, ata patën nevojë për një mjet të veçantë që gjeneron këtë përshkrim. Kur ka këtë përshkrim, secili mund të krahasohet me të tjerët, të monitorojë ndryshimet, si mund ta ndryshojë dhe përmirësojë, çfarë mungon.
Më tregoni, scriptet e veçanta bashkë zakonisht nuk ofrojnë këtë kuptim. Në një nga kompanitë ku kam punuar, kishte madje një emër "shkrim vetëm" - kur skripti është shkruar, por nuk mund të lexohet më. Mendoj se kjo është e njohur edhe për ju.
Infrastruktura si kod është kod që përshkruan gjendjen aktuale të infrastrukturës. Për këtë kod punojnë së bashku shumë ekipe produkti, infrastrukture dhe shërbimesh, dhe, më e rëndësishmja, të gjitha ato duhet të kuptojnë si funksionon ky kod.
Kodi shoqërohet sipas praktikave më të mira të zhvillimit të kodit: zhvillim i përbashkët, rishikim i kodit, programimi XP, testimi, kërkesat për bashkëngjitje, CI për infrastrukturat e kodit — të gjitha këto janë të mira dhe mund të përdoren.
Kodi bëhet një gjuhë e zakonshme për të gjithë inxhinierët.
Ndryshimi i infrastrukturës në kod nuk zë shumë kohë. Po, në infrastrukturën e kodit mund të ketë borxhe teknike. Zakonisht, ekipet përballen me to rreth një vit e gjysmë pas fillimit të zbatimit të «infrastrukturës si kod» në formën e një grumbulli skriptesh ose madje Ansible, të cilat i shkruajnë si kod spageti, dhe kështu i hedhin edhe skripte bash në zjarre!
E rëndësishme: nëse nuk e keni provuar këtë gjë, mbani mend se Ansible nuk është bash! Lexoni me kujdes dokumentacionin, studiohuni për atë që flitet për të.
Infrastruktura si kod është ndarjen e kodit të infrastrukturës në shtresa të veçanta.
Në kompaninë tonë, ne kemi identifikuar 3 nivele bazike që janë shumë të qarta dhe të thjeshta, por mund të ketë edhe më shumë. Ju mund të shqyrtoni kodin tuaj të infrastrukturës dhe të thoni nëse keni këtë kusht apo jo. Nëse nuk ka nivele të identifikuara, është e nevojshme të dedikoni kohë dhe të rregulloni pak.
Niveli bazik — është si konfigurimi i OS-së, backup-et dhe gjëra të tjera të nivelit të ulët, për shembull, si vendoset Kubernetes në nivelin bazik.
Niveli i shërbimeve — janë shërbimet që ju ofroni zhvilluesve: logimi si shërbim, monitorimi si shërbim, baza e të dhënave si shërbim, balancuesi si shërbim, radhitja si shërbim, Continuous Delivery si shërbim — një mori shërbimesh që ekipet e ndara mund të ofrojnë për zhvillimin. Të gjitha këto duhen përshkruar si module të veçanta në sistemin tuaj të menaxhimit të konfiguracionit.
Niveli ku krijohen aplikacionet dhe përshkruhet si do të zhvillohen mbi dy nivelet e mëparshme.
Pyetje kontrolli
A keni një depozitë të përbashkët infrastrukturore në kompaninë tuaj? A e kontrolloni borxhin teknik në infrastrukturë? A përdorni praktikat e zhvillimit në depozitën infrastrukturore? A është infrastruktura juaj e segmentuar në shtresa? Mund të kontrolloni me diagramin Base-service-APP. Sa e vështirë është të bësh një ndryshim?
Nëse keni hasur në situata ku për të bërë ndryshime ka marrë një deri në një ditë e gjysmë, kjo do të thotë se keni krijuar borxh teknik dhe duhet të punoni me të. Ju sapo keni hasur në pengesat e borxhit teknik në kodin e infrastrukturës. Kujtoj shumë histori, kur për të ndryshuar një CCTL, duhej të rishkruaje gjysmën e kodit të infrastrukturës, sepse krijimtaria dhe dëshira për të automatizuar gjithçka çoi në situata ku gjithçka është ngatërruar, janë hequr të gjitha butonat, dhe duhet të rifillosh.
Dorëzim i vazhdueshëm
Kemi një përmbledhje të debitit me kreditin. Fillimisht paraqitet një përshkrim i infrastrukturës, i cili mund të jetë mjaft bazik. Nuk është e nevojshme ta përshkruani gjithçka në detaje, por një përshkrim themelor është i domosdoshëm që të punoni me këtë. Në të kundërt, nuk është e qartë se mbi çfarë duhet të bëni vazhdimin e përhershëm. Të gjitha këto praktika zbatohen në mënyrë të njëkohshme kur arrini në DevOps, por duhet të filloni me kuptimin e asaj që keni dhe si ta menaxhoni atë. Kjo është pikërisht praktika e infrastrukturës si kod.
Pasi kuptoni atë që keni dhe si ta menaxhoni, filloni të mendoni si ta dërgoni kodin e zhvilluesit sa më shpejt në prodhim. Kam parasysh së bashku me zhvilluesin — mos haroni problemin e «pusëve», që do të thotë se nuk janë individë të veçantë që e mendojnë këtë, por ekipi.
Kur ne Vanja Evtukhovich pamë librin e parë Jez Hembla dhe grupin e autorëve «Continuous Delivery», e cila doli në vitin 2009, menduam për një kohë të gjatë se si ta përkthenim titullin e saj në shqip. Donim ta përkthenim si "Dërgesa e vazhdueshme", por, fatkeqësisht, e përkthyer si "Dërgesa e pandërprerë". Më duket se titulli ynë ka diçka shqiptare, me forcë.
Dërgesa e vazhdueshme do të thotë
Kodet që ndodhen në depozitën e produktit mund të nxirren gjithmonë në prodhim. Ai mund të mos nxirret, por gjithmonë është gati për këtë. Prandaj, gjithmonë shkruani kodin me një ndjenjë të vështirë për t'u shpjeguar të një shqetësimi në pjesën e poshtme të shpinës. Kjo ndjenjë shqetësimi shpesh shfaqet kur nxjerrni kodin e infrastrukturës. Kjo ndjenjë shqetësimi duhet të jetë e pranishme – ajo aktivizon proceset mendore që lejojnë të shkruani kodin pak ndryshe. Kjo duhet të dokumentohet në rregullat brenda zhvillimit.
Për të dërguar vazhdimisht, nevojitet një format artefakti që kalon nëpër platformën infrastrukturore. Nëse po dërgoni "mbeturina" të formateve të ndryshme mbi platformën infrastrukturore, ajo bëhet e paunifikuar, është e vështirë për ta mbajtur, krijohet problemi i borxhit teknik. Formati i artefaktit duhet të rregullohet - kjo është gjithashtu një detyrë kolektive: duhet të mblidhemi të gjithë së bashku, të përdorim mendjen dhe të krijojmë këtë format.
Artefakti përmirësohet dhe ndryshon vazhdimisht sipas mjedisit të prodhimit gjatë kalimit nëpër pipeline të dorëzimit. Kur artefakti lëviz përmes pipeline-it, ai përballet vazhdimisht me disa gjëra të pakëndshme për të, të cilat i ngjasojnë atyre me të cilat përballet artefakti që po e publikoni në prodhim. Në zhvillimin tradicional, një administrator sistemi merret me publikimin, ndërsa në procesin DevOps kjo ndodh vazhdimisht: këtu e rrotullojnë me disa teste, këtu e hedhin në Kubernetes cluster që ngjason më shumë me prodhimin, këtu papritur fillojnë testimin e ngarkesës.
Kjo i ngjan një loje Pac-Man — artefakti kalon nëpër një histori. Është e rëndësishme të kontrolloni nëse kodi kalon nëpër këtë histori dhe nëse ajo ndërlidhet me prodhimin tuaj. Historia me prodhimin mund të përfshihet brenda procesit të Continuous Delivery: ndodhte kështu, kur diçka dështoi, tani le të programojmë thjesht këtë skenar brenda sistemit. Çdo herë kodi do të kalojë këtë skenar gjithashtu, dhe nuk do të përballeni me këtë problem tjetër herë. Do të informoheni për të shumë më herët, para se të dalë te klienti juaj.
Strategji të ndryshme të deploy-eve. Për shembull, ju përdorni AB-testimin ose deploy-të kanarinë, për të provuar në mënyra të ndryshme kodin te klientë të ndryshëm, për të marrë informacion mbi se si punon kodi, dhe shumë më herët se sa do të nxitohet për 100 milion përdorues.
«Të dorëzosh vazhdimisht» duket kështu.
Processi i dorëzimit Dev, CI, Test, PreProd, Prod — nuk është një ambient i veçantë, janë faza ose stacione me shuma të pathyeshme për të cilat kalon artefakti juaj.
Nëse keni kodin infrastruktural të përshkruar si Base Service APP, ai ndihmon të mos harroni gjithë skenarët, dhe të regjistrohen gjithashtu në formën e kodit për këtë artefakt, të promovoni artefaktin dhe ta ndryshoni gjatë rrugës.
Pyetje për vetëvlerësim
A është koha nga përshkrimi i veçorisë deri te lansimi në prodhim në 95% të rasteve më pak se një javë? A rritet cilësia e artefaktit në çdo hap të pipeline? A ka një histori për të cilën ai kalon? A përdorni strategji të ndryshme për ndërrimin?
Nëse të gjitha përgjigjet janë po, atëherë ju jeni me të vërtetë të shkëlqyer! Shkruani përgjigjet në komente - do të isha i lumtur).
Feedback
Kjo është prakika më e vështirë nga të gjitha. Në konferencën DevOpsConf, një koleg nga Infobip, duke folur për të, u ngatërrua pak në fjalë, sepse kjo është me të vërtetë një praktikë shumë e vështirë për atë që duhet të monitoroni gjithçka!
Për shembull, shumë kohë më parë, kur punoja në Qik dhe kuptuam se duhet të monitoronim gjithçka. Ne e bëmë këtë, dhe në Zabbix kishim 150,000 items që monitoroheshin vazhdimisht. Kjo ishte e frikshme, dhe drejtori teknik po përkëdhelte gishti në tempull:
— Djem, përse po e ngacmoni serverin me gjëra të paqartë?
Por pastaj ndodhi një rast që tregoi se kjo është me të vërtetë një strategji shumë e shkëlqyer.
Një nga shërbimet filloi të bjerë vazhdimisht. Në fillim nuk kishte rënë, që është interesante, pasi nuk ishte shkruar kod atje, sepse ishte një broker bazë, në të cilin praktikisht nuk kishte funksionalitete biznesi - ai thjesht transmetonte mesazhe midis shërbimeve të ndryshme. Shërbimi nuk ishte ndryshuar për 4 muaj, dhe papritmas filloi të binte me gabimin "Segmentation fault".
Ishim të shokuar, hapëm grafikun tonë në Zabbix, dhe zbuluam se, realisht, sjellja e kërkesave në shërbimin API që përdor këtë broker kishte ndryshuar ndjeshëm një javë e gjysmë më parë. Pastaj ne pamë se frekuenca e dërgimit të një lloji të caktuar mesazhesh kishte ndryshuar. Më pas zbuluam se ishin klientët android. Pyetëm:
— Djem, çfarë ndodhi me ju një javë e gjysmë më parë?
Në përgjigje, dëgjuam një histori interesante në lidhje me ri-dizajnimin e UI. Është e vështirë të thuhet menjëherë se ata e kanë ndryshuar bibliotekën HTTP. Për klientët Android, kjo është si të ndërroni sapunin në banjë — ata thjesht nuk e mbajnë mend. Pas 40 minutash bisedë, ne zbuluam se ata në të vërtetë kanë ndryshuar bibliotekën HTTP, dhe koha e saj e paracaktuar ishte ndryshuar. Kjo shkaktoi një ndryshim në sjelljen e trafikut në serverin API, çka rezultoi në një situatë që shkaktoi një garë brenda brokerit, dhe ai filloi të bjerë.
Pa monitorim të thellë, kjo është krejtësisht e pamundur të zbulohet.. Nëse organizata ka gjithashtu një problem me "puset", kur secili e kalon përgjegjësinë te tjetri, kjo mund të vazhdojë për vite. Thjesht e rivendosni serverin, sepse është e pamundur të zgjidhni problemin. Kur monitoroni, ndjekni, regjistroni të gjitha ngjarjet që keni, dhe përdorni monitorimin si testim — shkruani kodin dhe menjëherë e shëni se si ta monitoroni atë, gjithashtu në formën e kodit (ne tashmë kemi infrastruktura si kod), gjithçka bëhet e qartë si në pëllëmbë. Madje, problemet kaq të komplikuara ndjekin lehtësisht.
Mblidhni të gjitha informacionet në lidhje me atë që ndodh me artefaktin në çdo fazë të procesit të furnizimit - jo në produksion.
Ngarkoni monitorimin në CI, dhe atje do të shihni disa gjëra bazike. Më pas do t'i shihni edhe në Test, edhe në PredProd, dhe në testimin e ngarkesës. Mblidhni informacion në të gjitha fazat, përfshirë jo vetëm metrikat, statistikat, por edhe logjet: si u publikua aplikacioni, anomali - mblidhni gjithçka.
Në të kundërt, do të jetë e vështirë të kuptoni. Kam thënë më parë se DevOps është një kompleksitet më i madh. Për të përballuar këtë kompleksitet, duhet të keni një analitikë të mirë..
Pyetje për vetëkontroll.
A është monitorimi dhe logimi juaj një mjet zhvillimi për ju? A mendojnë zhvilluesit tuaj, dhe gjithashtu ju, gjatë shkrimit të kodit, se si ta monitorojnë atë?
A e merrni vesh për problemet nga klientët? A e kuptoni më mirë klientin nga monitorimi dhe logimi? A e kuptoni më mirë sistemin nga monitorimi dhe logimi? A e ndryshoni sistemin thjesht sepse keni parë që trendi në sistem po rritet dhe e kuptoni se pas 3 javësh do të dështojë?
Kur ju keni këto tre komponente, mund të mendoni për platformën infrastrukturore që keni në kompaninë tuaj.
Platforma Infrastruktuore
Kuptimi nuk është se është një grup mjetesh të ndara, që çdo kompani i ka.
Kuptimi i platformës infrastrukturore është se të gjitha ekipet e përdorin këto mjete dhe i zhvillojnë ato së bashku.
Natyrisht, ka ekipe të veçanta që janë përgjegjëse për zhvillimin e pjesëve të veçanta të platformës infrastrukturore. Por përgjegjësia për zhvillimin, funksionimin dhe promovimin e platformës infrastrukturore është e gjithë inxhinierëve. Në nivelin e brendshëm, kjo bëhet një mjet i përbashkët.
Të gjitha ekipet zhvillojnë platformën infrastrukturore dhe i qasen asaj me kujdes si një IDE të vetin.. Në IDE-në tuaj vendosni plugins të ndryshme për të gjitha të duken bukur dhe të shpejta, konfiguroni çelësa të nxehtë. Kur hapni Sublime, Atom ose Visual Studio Code, keni shumë gabime në kod dhe kuptoni se është e pamundur të punoni, ndiheni menjëherë të trishtuar dhe shkoni të riparoni IDE-në tuaj.
Trajtojini ndryshe lidhjen tuaj me platformën infrastrukturore. Nëse e kuptoni se diçka nuk shkon me të, dërgoni një kërkesë nëse nuk mund ta rregulloni vetë. Por nëse është diçka e thjeshtë, atëherë rregulloni vetë, dërgoni një pull request - ekipi i shqyrton dhe miraton. Ky është një qasje krejt tjetër ndaj mjetit inxhinierik në mendjen e zhvilluesit.
Platforma infrastrukturore siguron transferimin e artefaktit nga zhvillimi te klienti me një përmirësim të vazhdueshëm të cilësisë.. Në IP ka një grup historish të programuar që ndodhin me kodin në prodhim. Gjatë viteve të zhvillimit, këto histori bëhen shumë, një pjesë e tyre janë unike dhe i përkasin vetëm juve - nuk mund të gjenden në internet.
Në këtë moment, platforma infrastrukturore bëhet avantazhi juaj konkurrues,, sepse përmban atë që nuk e ka mjeti i konkurrentit. Sa më e thellë të jetë IP-ja juaj, aq më shumë avantazh konkurrues keni në aspektin e Time-to-market. Këtu paraqitet problemi i bllokimit nga shitësi: ju mund të merrni një platformë të huaj, por duke përdorur përvojën e dikujt tjetër, nuk do të kuptoni se sa e rëndësishme është ajo për ju. Po, nuk çdo kompani mund të ndërtojë një platformë si Amazon. Kjo është njënuancë e komplikuar, ku përvoja e një kompanie është e rëndësishme për pozitën e saj në treg, dhe nuk duhet lejuar vendor lock. Kjo është gjithashtu e rëndësishme për t'u menduar.
Skema
Kjo është një skemë bazë e platformës infrastrukturore, e cila do t'ju ndihmojë të vendosni të gjitha praktikat dhe proceset në një kompani DevOps.
Le të shohim se nga çfarë përbëhet.
Sistemi i orkestrimit të burimeve, i cili ofron CPU, memorie, dhe disk për aplikacionet dhe shërbime të tjera. Më sipër kësaj - shërbimet e nivelit të ulët: monitorimi, logimi, CI/CD Engine, depoja e artefakteve, infrastruktura si kod e sistemeve.
Shërbimet e nivelit më të lartë: baza e të dhënave si shërbim, radhë si shërbim, Load Balance si shërbim, resizing imazhesh si shërbim, Big Data fabrikë si shërbim. Më sipër kësaj - pipeline, i cili dërgon kodin e modifikuar vazhdimisht tek klienti juaj.
Merrni informacione mbi mënyrën se si funksionon softueri juaj te klienti, ndihmoni, ripakoni këtë kod, merrni informacione - dhe kështu vazhdoni për të zhvilluar përherë platformën infrastrukturore dhe softuerin tuaj.
Në diagramin e delivery pipeline përbëhet nga shumë faza. Por kjo është një skemë themelore, e dhënë si shembull - nuk është e nevojshme ta përsëritni saktësisht. Faza ndërveprojnë me shërbimet, si shërbime - çdo element i platformës ka historinë e vet: si alokohen burimet, si aktivizohet aplikacioni, punon me burimet, monitorohet dhe ndryshohet.
Është e rëndësishme të kuptohet se çdo pjesë e platformës ka një histori, dhe të pyesim veten - çfarë historie ka ky element, ndoshta duhet ta hedhim atë dhe të zëvendësojmë me një shërbim të jashtëm. Për shembull, mund të vendosim Okmeter në vend të këtij elementi? Ndoshta, ata e kanë zhvilluar këtë ekspertizë shumë më tepër se ne. Por ndoshta jo - ndoshta ne kemi një ekspertizë unike, na nevojitet të vendosim Prometheus dhe ta zhvillojmë më tej.
Krijimi i platformës
Ky është një proces kompleks komunikimi. Kur keni praktikat themelore, filloni komunikimin mes inxhinierëve dhe specialistëve të ndryshëm, të cilët zhvillojnë kërkesat dhe standardet dhe i ndryshojnë ato vazhdimisht bashkë me mjetet dhe qasjet e ndryshme. Kultura këtu është e rëndësishme për DevOps.
Me kulturën është shumë e thjeshtë — është bashkëpunim dhe komunikim, domethënë dëshira për të punuar së bashku në një fushë të përbashkët, dëshira për të zotëruar një mjet së bashku. Nuk ka asgjë të komplikuar — gjithçka është shumë e thjeshtë, banale. Për shembull, ne të gjithë jetojmë në një hyrje dhe mbajmë pastërtinë e saj — ky është niveli i kulturës.
Dhe ju?
Përseri pyetje që mund t'i bëni vetes.
A është ndarë platforma infrastrukturore? Kush përgjigjet për zhvillimin e saj? A e kuptoni avantazhet konkurruese të platformës suaj infrastrukturore?
Këto pyetje duhet t'i bëni vazhdimisht vetes. Nëse diçka mund të sillet në shërbime të jashtme — duhet ta sillni, nëse një shërbim i jashtëm fillon të bllokojë lëvizjen tuaj, atëherë duhet të ndërtoni një sistem brenda vetes.
Pra, DevOps…
… është një sistem kompleks, ku duhet të ketë:
- Një produkt digjital.
- Modulet e biznesit që zhvillojnë këtë produkt digjital.
- Ekipet e produkteve që shkruajnë kod.
- Praktikat e Continuous Delivery.
- Platforma si shërbim.
- Infrastruktura si shërbim.
- Infrastruktura si kod.
- Praktikat individuale të ruajtjes së besueshmërisë, të integruara brenda DevOps.
- Praktika e reagimit që përshkruan të gjithë këtë.
Mund ta përdorni këtë skemë, duke theksuar atë që tashmë keni në kompaninë tuaj në një formë: kjo është zhvilluar ose ka nevojë të zhvillohet.
Vetëm pas disa javësh do të mbahet . si pjesë e RIT++. Ejani në konferencë, ku ju presin shumë prezantime të shkëlqyera mbi Continuous Delivery, infrastrukturen si kod dhe transformimin DevOps. , afati i fundit i çmimeve është 20 maj
Burimi: habr.com
