Përcaktimi i DevOps është shumë i ndërlikuar, dhe për këtë arsye ne duhet ta fillojmë diskutimin mbi këtë temë çdo herë nga fillimi. Vetëm në Habr ka mijëra publikime mbi këtë çështje. 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, emri im është Aleksandër Titov (@), dhe ne thjesht do të flasim për DevOps dhe unë do të ndaj përvojën time.
Kam menduar gjatë se si ta bëj tregimin tim të dobishëm, prandaj do të ketë shumë pyetje – ato që i bëj vetes dhe ato që u bëj klientëve të kompanisë sonë. Duke iu përgjigjur këtyre pyetjeve, kuptimi bëhet më i qartë. Do të flas përse është e nevojshme DevOps nga këndvështrimi im, çfarë është kjo, sërish nga pozita ime, dhe si të 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 vetes, do të mundeni të kuptoni nëse kompania juaj po lëviz drejt DevOps apo ka ndonjë problem.
Një periudhë, kam ndjekur dallgët e shkërmoqjes dhe blerjeve. Fillimisht punova në një startup të vogël Qik, pastaj e bleu një kompani pak më të madhe Skype, e cila më pas u ble nga një kompani edhe më e madhe Microsoft. Në këtë moment, më u bë e qartë si transformohet përceptimi i DevOps në kompani të ndryshme sipas madhësisë. Pas kësaj, u bëra i interesuar për DevOps nga pikëpamja e tregut, dhe me kolegët e mi organizuam kompaninë Ekspress 42. Tani e katër vjet ne lëvizim nëpër dallgët e tregut.
Përveç të gjitha, unë jam një nga organizatorët e komunitetit DevOps Moscow dhe organizator i DevOps -Days 2017, por në 2018 nuk kam organizuar. Ekspress 42 punon me shumë kompani. Ne zhvillojmë atje DevOps, shikojmë si ndodh kjo, nxjerrim përfundime, analizojmë, tregojmë përfundimet tona të gjithë, dhe fuqizojmë njerëzit me praktikat DevOps. Në përgjithësi, ne po rrisim përvojën dhe ekspertizën në këtë drejtim.
Pse DevOps
Pyetja e parë që ndjek të gjithë është – pse? Shumë konsiderojnë se DevOps është thjesht automatizim ose një gjë e ngjashme që tashmë ka qenë në çdo kompani.
- Kishim Continuous Integration – do të thotë se më parë kishte DevOps, dhe përse na nevojitet e gjithë kjo? Aty jashtë argëtohen, ndërsa ne pengohemi nga puna!
Pas 9 vjetësh zhvillimi të komunitetit dhe metodologjisë, tashmë është e qartë se nuk janë thjesht shkëlqimet marketinguese, por akoma nuk është plotësisht e qartë pse është e nevojshme. Si çdo mjet dhe proces, DevOps ka objektiva të caktuara që në fund zgjidh.
E gjithë kjo është e lidhur me faktin se bota po ndryshon. Ajo po largohet nga qasja enterprise, ku kompanitë shkojnë menjëherë drejt ëndrrës, siç këndonte klasiku ynë nga Peterburg, nga pika A në pikën B sipas një strategjie të caktuar, me një strukturë të ndërtuar për këtë.
Në parim, gjithçka në IT duhet të jetë ndërtuar sipas këtij qasjeje. Këtu IT përdoret ekskluzivisht për automatizimin e proceseve.
Automatizimi nuk ndryshon shpesh, sepse kur një kompani po lëviz në një rrugë të njohur - çfarë ka për të ndryshuar? Funksionon - mos e prek. Tani në botë qasjet po ndryshojnë, dhe ajo që quhet Agile flet për faktin se pika e fundit B nuk është menjëherë e dukshme.
Kur një kompani ecën nëpër treg, punon me klientë - ajo vazhdimisht eksploron tregun dhe ndryshon pikën e fundit B. Dhe për sa më shpesh kompani të ndryshojë drejtimin e saj, aq më e suksesshme është në fund, sepse zgjedh më shumë segmente tregu.
Një strategji interesante e tregon një kompani që mora vesh rishtazi. One Box Shave - një shërbim për dorëzimin e razorave dhe pajisjeve për kujdesin e trupit me abone në një kuti. Ata dinë të personalizojnë "kutinë" e tyre për klientë të ndryshëm. Kjo merret me një softuer të caktuar, i cili më pas dërgon porosinë në një fabrikë 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 blades? A jeni serioz? Pse ju nevojitet kjo - nuk përmirëson cilësinë e rruajtjes. Një krem i veçantë, një aromë dhe një razor cilësor me dy blades zgjidhin shumë më tepër se këto katër blades budallaqe të Gillette! Kështu do të arrijmë së shpejti 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 Time-to-market, për të cilin tashmë ka folur kushdo.
Konteksti i Time-to-market nuk qëndron në frekuencën e publikimeve tona. Mund të publikojmë shpesh, por ciklet e lançimeve mund të jenë të gjata. Nëse ciklet e lançimeve me tre muaj mbivendosen, duke u shtyrë për një javë, ndodhemi në një situatë ku kompania duket se po publikon një herë në javë. Por, koha nga ideja deri në realizimin final merr 3 muaj.
Time-to-market është për minimizimin e kohës nga ideja deri në realizimin përfundimtar.
Në këtë rast, softi ndërvepron me tregun. Kështu, One Box Shave ka një faqe interneti për ndërveprimin me klientët. Ata nuk kanë shitës — thjesht një faqe, ku vizitori klikoni dhe lë dëshira. Prandaj, faqja duhet të nxjerrë vazhdimisht përmbajtje të re, për të përditësuar në përputhje me dëshirat e klientëve. Për shembull, në Korenë e Jugut, njerëzit nuk rruhen njëlloj si në Rusi, dhe ata preferojnë që aroma e sapunit të mos jetë ajo e pishave, por, për shembull, e karotave me vanilje.
Duke qenë se nevojitet të ndryshojmë shpejt përmbajtjen e faqes, zhvillimi i softit ndryshon ndjeshëm. Nëpërmjet softit, ne duhet të kuptojmë se çfarë dëshiron klienti. Më parë, e merrnim këtë informacion përmes rrugëve alternative, për shembull, përmes menaxhimit të biznesit. Pastaj projektinim, vendosnim kërkesat në sistemin IT dhe gjithçka shkonin mirë. Tani është ndryshe — softi projektizohet nga të gjithë ata që janë të përfshirë në proces, përfshirë inxhinierët, sepse ata kuptojnë përmes specifikave teknike se si funksionon tregu dhe gjithashtu ndajnë me biznesin njohuritë e tyre.
Për shembull, në kompaninë Qik, papritur mësuam se njerëzit e pëlqejnë të ngarkojnë lista kontaktesh në server, dhe ata na ofruan një aplikacion. Fillimisht, ne nuk ishim menduar për këtë. Në një kompani klasike, të gjithë do të kishin vendosur se është një bug, sepse në spesifikimet nuk është shkruar se kjo duhet të funksionojë mirë, dhe në përgjithësi e kishim implementuar me shpejtësi, do ta kishin çaktivizuar këtë veçori dhe do të thoshin: 'Kjo nuk është e nevojshme për askënd, më e rëndësishme është se funksionaliteti kryesor punon.' Por, një kompani teknologjike e sheh këtë si një mundësi dhe fillon të ndryshojë softin në përputhje me këtë.
Në vitin 1968, një djalë i mençur Melvin Conway formulojë idenë e mëposhtme.
Organizata që krijon një sistem është e kufizuar nga dizajni, i cili kopjon strukturën e komunikimit në këtë organizatë.
Nëse flasim më hollësisht, për të prodhuar sisteme të tjera, ju nevojitet gjithashtu një strukturë komunikimi brenda kompanisë që është e ndryshme. Nëse keni një strukturë komunikimi të lartë hierarkike, kjo nuk do t'ju lejojë të krijoni sisteme që mund të ofrojnë një nivel shumë të lartë të Time-to-market.
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 bazikisht në DevOps është struktura e komunikimit midis ekipeve.
Nga pikëpamja e procesit, deri në DevOps të gjitha fazat: analiza, zhvillimi, testimi, operimi, kanë kaluar në mënyrë lineare.
Në rastin e DevOps, të gjithë këto procese ndodhin njëkohësisht.
Time-to-market mund të përmbushët vetëm kështu. Për njerëzit që kanë punuar në procesin e vjetër, kjo duket disi ndryshe, dhe në përgjithësi jo e lehtë.
Pra, përse nevojitet DevOps?
Për zhvillimin e produkteve digjitale. Nëse në kompaninë tuaj nuk ka një produkt digjital, DevOps nuk është i nevojshëm - kjo është shumë e rëndësishme.
DevOps kalon kufijtë e shpejtësisë së një skeme prodhimi lineare të softuerit. Në të, të gjitha proceset ndodhin njëkohësisht.
Rritet kompleksiteti. Kur evangelistët e DevOps flasin se me të do t'ju bëhet më e lehtë të publikoni softuer - kjo është një marrëzi.
Me DevOps, gjithçka do të jetë më e komplikuar.
Në konferencë, në stendën e Avito, mund të shihni se çfarë do të thotë të dezdeployosh një kontejner Docker - një detyrë e pamundshme. Kompleksiteti bëhet jashtëzakonisht i lartë, duhet të luani me shumë tops njëkohësisht.
DevOps ndryshon plotësisht procesin dhe organizatën në kompani në fakt, nuk e ndryshon DevOps, por produkti digjital. Për të arritur në DevOps, duhet të ndryshoni plotësisht këtë proces.
Pyetje për specialistin
Dhe çfarë për ju? Pyetje që mund t'i bëni vetes, duke punuar në kompani dhe duke u zhvilluar si specialist.
A keni strategji për krijimin e një produkti digjital? Nëse po - është mirë. Kjo do të thotë se kompanisë tuaj 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, të angazhoheni në aktivitete më interesante - nga pikëpamja e DevOps përsëri. Unë flas 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 tanimë.
Beni vetë këto pyetje dhe nëse të gjitha përgjigjet janë negative, ndoshta nuk duhet të angazhoheni me DevOps në këtë kompani. Megjithatë, nëse tema e DevOps është me të vërtetë interesante për ju, ndoshta… duhet të kaloni në një kompani tjetër? Nëse kompania juaj dëshiron të hyjë në DevOps, por ju përgjithsisht keni përgjigjur "Jo", atëherë ajo i ngjan këtij rhinoceros-i të shkëlqyer që kurrë nuk do të ndryshojë.
Organizata
Siç e thashë, sipas ligjit të Conway-t, organizimi në kompani ndryshon. Filloj me atë që pengon DevOps të hyjë brenda kompanisë pikërisht nga këndvështrimi i organizatës.
Problemi i "kolonave"
Fjala angleze "Silo" është përkthyer këtu në rusisht si "kolonë". Kuptimi i këtij problemi është se nuk ka shkëmbim informacioni midis ekipeve.Çdo ekip thellon ekspertizën e vet, duke mos ndërtuar një hartë të përbashkët, në të cilën mund të orientohesh.
Kjo i ngjan një njeriu që sapo ka mbërritur në Moskë dhe ende nuk di të orientoheshe sipas hartës së metrosë. Moskvat zakonisht e dinë mirë rajonin 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 humbur.
DevOps ofron të kalosh këtë moment të dezinformimit dhe të ndërtosh së bashku një hartë të përbashkët të bashkëpunimit nga të gjitha nën-njësitë.
Dy faktorë pengojnë këtë.
Pasojat e sistemit korporativ të menaxhimit. Ai është ndërtuar me "kolona" hierarkike të veçanta. Për shembull, ka KPI të caktuara në kompani që e mbështesin këtë sistem. Nga ana tjetër, pengon edhe truri i njeriut, i cili ka vështirësi të dalë jashtë ekspertizës së tij dhe të orientohet në tërë sistemin. Kjo është thjesht e pakëndshme. Imagjinoni se keni shkuar në aeroportin e Bangkokut — atje nuk orientohesh lehtësisht. Po ashtu është e vështirë të orientohesh në DevOps, ndaj njerëzit thonë se duhet të gjesh një udhërrëfyes për të hyrë atje.
Por gjëja më e rëndësishme është se problemi i "kolonave" për inxhinierin që ka përqafuar shpirtin e DevOps-it, ka lexuar Fowler-in dhe një sërë librash të tjerë, shprehet në këtë mënyrë "kolonat" nuk lejojnë të bëhen gjëra "të dukshme". Ne shpesh mblidhemi pas DevOps Moscow, flasim me njëri-tjetrin dhe njerëzit ankojnë:
— Ne dojahtëm vetëm të nisim CI, por rezultoi që menaxhmenti nuk e do atë.
Kjo ndodh pikërisht për shkak se CI dhe Procesi i Dërgesës së Përhershme janë në kufirin e shumë ekspertizave. Thjesht, duke mos e kaluar problemin e "pushtimin" në nivelin organizativ, nuk do të mund të përparoni më tej, pavarësisht se çfarë bëni dhe sa të trishtueshëm është kjo.
Çdo pjesëmarrës në proces në kompani: zhvilluesit e backend dhe frontend, testimi, DBA, operimi, rrjeti, punon në drejtimin e tij, ndërsa askush nuk ka një hartë të përbashkët, përveç menaxherit, i cili i vë re dhe menaxhon me metodën "ndaje dhe sundo".
Njerëzit luftojnë për disa yje ose flamuj, secili punon në ekspertizën e tij.
Si rezultat, kur shfaqet detyra për t'i lidhur të gjitha këto së bashku dhe për të ndërtuar një pipeline të përbashkët, dhe e tëra për yjet dhe flamujt tashmë nuk ka nevojë për luftë, lind pyetja - çfarë të bëjmë gjithsesi? Duhet të arrijmë një marrëveshje, por si ta bëjmë këtë, askush në shkollë nuk na mësoi. Edhe nga shkolla, ne jemi mësuar: klasa e tetë - oh! - në krahasim me klasën e shtatë! Këtu është e njëjta gjë.
A është ndryshe në kompaninë tuaj?
Për ta verifikuar këtë, mund të bëni këto pyetje për veten.
A përdorin ekipet mjete të përbashkëta, a kontribuojnë në ndryshimet e këtyre mjeteve të përbashkëta?
Sa shpesh ekipet riformohen - specialistët nga një ekip kalojnë në një ekip tjetër? Pika kyçe në ambientin DevOps, kjo bëhet normale, sepse ndonjëherë një person thjesht nuk mund të kuptojë se çfarë bën një zonë tjetër ekspertize. Ai kalon në departamentin tjetër, punon një ose dy javë atje për të krijuar një hartë orientimi dhe bashkëpunimi me atë departament.
A është e mundur të krijohet një komitet për ndryshime dhe të bëhet ndonjë ndryshim? Apo për këtë kërkohet një dorë e fortë e udhëheqjes më të lartë dhe një urdhër? Së fundmi kam shkruar në Facebook, si një bankë e panjohur, përmes urdhëresave implementon mjete: shkruan një urdhër, një vit e implementojmë, shohim çfarë ndodh. Kjo, sigurisht, ë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 ju përgjigjeni këtyre pyetjeve, do të kuptoni më mirë nëse keni një problem të tillë në kompani.
Infrastruktura si kod
Pas këtij problemi, praktika e parë e rëndësishme, pa të cilën është e vështirë të avancosh më tej në DevOps, është infrastruktura si kod.
Shpesh infrastruktura si kod perceptohet si:
- Le të automatizojmë gjithçka me bash, të mbushim me skripte, në mënyrë që adminët të kenë më pak punë manuale!
Por kjo nuk është ashtu.
Infrastruktura si kod nënkupton që sistemin IT me të cilin punoni, e përshkruani në formë kodi, për të kuptuar vazhdimisht gjendjen e tij.
Në bashkëpunim me ekipet e tjera, krijoni një hartë në formë kodi, e cila është e qartë për të gjithë dhe në të cilën mund të orientoheni, të navigoni. Nuk ka rëndësi se me çfarë është bërë - Chef, Ansible, Salt, ose nëse përdoren skedarët YAML në Kubernetes - nuk ka ndryshim.
Në konferencë, një koleg nga 2GIS tregoi se si ata krijuan mjetin e tyre të brendshëm për Kubernetes, i cili përshkruan strukturën e sistemeve të veçanta. Për të përshkruar 500 sisteme, ata kishin nevojë për një mjet të veçantë që e gjeneron këtë përshkrim. Kur ka këtë përshkrim, secili mund të kontrollojë njëri-tjetrin, të monitorojë ndryshimet, si mund të ndryshohet dhe përmirësohet, çfarë mungon.
Pranojeni, skriptet e veçanta bash zakonisht nuk ofrojnë këtë kuptim. Në një nga kompanitë ku kam punuar, kishte madje një emër "write only"-skript - kur skripti shkruhet, por që leximi i tij bëhet i pamundur. Mendoj se kjo është e njohur për ju gjithashtu.
Infrastruktura si kod është kodi që përshkruan gjendjen aktuale të infrastrukturës. Ky kod punon në mënyrë bashkëpunuese nga shumë ekipe produktesh, infrastrukture dhe shërbimi, dhe, më e rëndësishmja, të gjitha duhet të kuptojnë se si funksionon ky kod.
Kodi shoqërohet sipas praktikave më të mira të punës me kodin: zhvillimi i përbashkët, rivlerësimi i kodit, XP-programim, testimi, kërkesat për tërheqje, CI për infrastrukturat e kodit - të gjitha këto janë të dobishme dhe mund të përdoren.
Kodi bëhet një gjuhë e përbashkët për të gjithë inxhinierët.
Ndryshimi i infrastrukturës në kod nuk merr shumë kohë. Po, në kodin e infrastrukturës gjithashtu mund të ketë borxhe teknike. Zakonisht ekipet përballen me to rreth një vit e gjysmë pasi filluan të implementojnë "infrastrukturen si kod" në formën e një grumbulli skriptesh ose madje Ansible, të cilin e shkruajnë si kod spaghetti, dhe për më tepër hedhin skripte bash në të!
Ëhtë e rëndësishme: nëse nuk e keni provuar akoma këtë, mbani mend se Ansible - nuk është bash! Lexoni me kujdes dokumentacionin, studioni se çfarë shkruhet në lidhje me këtë.
Infrastruktura si kod është ndarja e kodit Infrastrukturor në shtresa të veçanta.
Ne në kompaninë tonë dallojmë 3 shtresa bazë, të cilat janë shumë të qarta dhe të thjeshta, por mund të ketë më shumë. Mund të shqyrtoni kodin tuaj infrastrukturore dhe të thoni, a keni këtë kusht apo jo. Nëse nuk ka asnjë shtresë të ndarë, atëherë duhet të gjeni kohë dhe të refaktoroni pak.
Shtresa e bazës është si të konfigurohet OS, backup-et dhe gjëra të tjera me nivel të ulët, për shembull, si të veproni Kubernetes në nivelin themelor.
Niveli i shërbimeve është ato shërbime që ju ofroni zhvilluesit: logim si shërbim, monitorim si shërbim, bazë të dhënash si shërbim, balancues si shërbim, radhë si shërbim, Continuous Delivery si shërbim - një mori shërbimesh që ekipet e veçanta mund të ofrojnë për zhvillimin. Të gjitha këto nevojitet të përshkruhen si module të veçanta në sistemin tuaj të menaxhimit të konfigurimeve.
Shtresa, ku bëhen aplikacionet dhe përshkruhet se si do të implementohen mbi dy shtresat e mëparshme.
Pyetje kontrolluese
A keni në kompaninë tuaj një depozitë infrastrukurale të përgjithshme? A kontrolloni borxhin teknik në infrastrukturë? A përdorni praktikat e zhvillimit në depozitën infrastrukurale? A është infrastruktura juaj e ndarë në shtresa? Mund të kontrolloni me diagramin Base-service-APP. Sa e vështirë është të bëni një ndryshim?
Nëse keni pasur përvojën se ndryshimi ka zgjatur një ditë e gjysmë, do të thotë se ju keni përdorur borxhin teknik dhe me të duhet punuar. Ju sapo keni hasur pengesat e borxhit teknik në kodin infrastruktural. Unë e mbaj mend shumë storie të tilla, kur për të ndryshuar ndonjë CCTL, duhet të riprogramoni gjysmën e kodit infrastruktural, sepse krijimtarinë dhe dëshirën për të automatizuar gjithçka e kanë çuar në atë që është bllokuar çdo gjë, të gjitha duart janë larguar, dhe duhet refaktoruara.
Dharja e vazhdueshme
Do të bëjmë një trajtim të debiti dhe krediti. Fillimisht prezantohet përshkrimi i infrastrukturës, i cili mund të jetë mjaft bazik. Nuk është e nevojshme të përshkruani gjithçka në detaje, por ndonjë përshkrim bazik kërkohet që të mund të punoni me të. Ndryshe, nuk kuptohet mbi çfarë do të bëni më tej për shpërndarjen e vazhdueshme. Të gjitha këto praktika zhvillohen në të njëjtën kohë kur kaloni në DevOps, por duhet të filloni nga kuptimi i asaj që keni dhe si ta menaxhoni atë. Kjo është pika e praktikes 'infrastrukturë si kod'.
Pas asaj që keni kuptuar se çfarë keni, si ta menaxhoni atë, filloni të mendoni se si ta dërgoni kodin e zhvilluesit sa më shpejt në prodhim. Kam parasysh së bashku me zhvilluesit - kujtojmë problemin e 'pushtimeve', dmth nuk janë njerëz të veçantë që e mendojnë këtë, por ekip.
Kur ne me Vanya Evtuhoichin pashë librin e parë të Jez Hambles dhe grupit të autorëve ‘Continuous Delivery’, i cili doli në vitin 2009, menduam gjatë për si ta përkthejmë titullin e tij në gjuhën ruse. Donim ta përkthenim si ‘Përcjellje të vazhdueshme’, por, për fat të keq, e përkthyem si ‘Dërgesë e vazhdueshme’. Më duket se në titullin tonë ka diçka ruse, me forcë.
Të dërgosh vazhdimisht do të thotë
Kodi, që ndodhet në depo produkti, gjithmonë mund të dërgohet në prodhim. Ai mund të mos dërgohet, por gjithmonë është gati për këtë. Prandaj, ju gjithmonë shkruani kod me një ndjenjë të vështirë për të shpjeguar e shqetësim nën kockën e pasme. Kjo ndjenjë shqetësimi duhet të jetë e pranishme - ajo shkakton procese mendore që lejojnë të shkruani kod ndryshe. Kjo duhet të regjistrohet në rregullat brenda zhvillimit.
Për të dërguar vazhdimisht, kërkohet një format arti që kalon nëpër platformën infrastrukturore. Nëse ju hedhin ‘mbeturina’ me formate të ndryshme nëpër platformën infrastrukturore, atëherë ajo bëhet jo e unifikuar, bëhet e vështirë për t'u mbajtur, lind problemi i borxhit teknik. Formati i artefaktit duhet të rregullohet - kjo është gjithashtu një detyrë kolektive: duhet të mblidhemi të gjithë bashkë, të këshillohemi dhe të imagjinojmë këtë format.
Artefakti vazhdon të përmirësohet dhe ndryshojë sipas mjedisit të prodhimit gjatë kalimit përmes pipeline-it të dorëzimit. Kur artefakti lëviz përmes pipeline-it, ai përballet vazhdimisht me disa gjëra që janë të pakëndshme për të, të cilat i ngjajnë asaj që ndodh me artefaktin që e publikoni në prodhim. Në zhvillimin klasik, këtë e bën administrator sistemi që realizon përditësimin, ndërsa në procesin DevOps, kjo ndodh vazhdimisht: këtu ai kalon nëpër disa teste, aty – hidhet në klasterin Kubernetes, i cili është më shumë-më pak si prodhimi, dhe aty papritur fillon testimi me ngarkesë.
Kjo ndonjëherë i ngjan lojës Pacman – artefakti kalon një histori. Aty është e rëndësishme të kontrolloni nëse kodi realisht kalon historinë dhe nëse ajo lidhet me prodhimin tuaj. Historitë nga prodhimi mund të përfshihen brenda procesit të Continuous Delivery: ndodhi kështu, kur diçka dështoi, tani le të programojmë këtë skenar brenda sistemit. Çdo herë kodi do të kalojë këtë skenar gjithashtu, dhe ju nuk do të përballeni sërish me këtë problem. Do ta mësoni për të shumë më herët se sa të dalë te klienti juaj.
Strategjitë e ndryshme të publikimit. Për shembull, ju përdorni testimin AB ose publikime kanarie, për të "exploruar" ndryshe kodin te klientë të ndryshëm, duke e marrë informacionin se si funksionon kodi, dhe shumë më përpara se të publikohet për 100 milion përdorues.
"Dorëzimi i vazhdueshëm" duket kështu.
Procesi i dorëzimit Dev, CI, Test, PreProd, Prod – ato nuk janë mjedise të ndara, janë faza ose stacione me vlera të papërfshira, përmes të cilave kalon artefakti juaj.
Nëse keni një kod infrastrukture i cili përshkruhet si Base Service APP, atëherë ai ndihmon të mos harrosh të gjitha skenarët, dhe t’i regjistrosh ata gjithashtu në formën e kodit për këtë artefakt, të promovosh artefaktin dhe ta ndryshosh atë gjatë rrugës.
Pyetje për vetëkontroll
A është koha nga përshkrimi i veçorisë deri në publikimin në prodhim më e vogël se një javë në 95% të rasteve? A rritet cilësia e artefaktit në çdo fazë të pipeline-it? A ka një histori për të kaluar? A përdorni strategji të ndryshme të publikimit?
Nëse të gjitha përgjigjet janë po, atëherë ju jeni me të vërtetë të mrekullueshëm! Shkruani përgjigjet në komentet – do të isha i gëzuar).
Kthimi i informacionit
Kjo është praktika 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 është vërtet një praktikë shumë e komplikuar në lidhje me atë që duhet të monitorosh gjithçka!
Për shembull, një kohë të gjatë më parë, kur punoja në Qik dhe ne kuptuam se duhej të monitoronim gjithçka. E bëmë këtë, dhe në Zabbix kishim 150,000 item-e që monitoroheshin vazhdimisht. Ishte frikshme, drejtoresha teknike po na shikonte me dyshim:
— Djem, pse po e përdorni serverin pa kuptim?
Por pastaj ndodhi një rast që tregoi se kjo është vërtet një strategji shumë e shkëlqyer.
Një nga shërbimet filloi të binte vazhdimisht. Në fillim, ai nuk binte, çuditërisht, atje nuk ishin bërë ndryshime të kodit, sepse ishte një broker bazë, i cili në thelb nuk kishte funksionalitet biznesi — ai thjesht transmetonte mesazhe midis shërbimeve. Shërbimi nuk kishte ndryshuar për 4 muaj dhe papritmas filloi të binte me një gabim "Segmentation fault".
Ishim të tronditur, hapëm grafikët tanë në Zabbix dhe zbuluam se, në fakt, katërmbëdhjetë ditë më parë kishte ndryshuar ndjeshëm sjellja e kërkesave në API-shërbimin që shfrytëzonte këtë broker. Më pas, shikuam se pati ndryshime në frekuencën e dërgimit të një tipi të caktuar mesazhesh. Pas kësaj, zbuluam se ishin klientët android. Ne pyetëm:
— Djem, çfarë ndodhi katërmbëdhjetë ditë më parë?
Në përgjigje dëgjuam një histori interesante rreth faktit se ata e kishin riprojektuar UI-në. Është e pamundur që dikush të thotë menjëherë se kanë ndryshuar bibliotekën HTTP. Për klientët android, ky është një ndryshim si të ndryshosh sapun në banjë — ata thjesht nuk e mbajnë mend. Në fund, pas 40 minutash bisedë, zbuluam se ata përfundimisht kishin ndryshuar bibliotekën HTTP dhe ajo kishte ndryshuar parametrat e saj default. Kjo çoi në ndryshimin e sjelljes së trafik të API serverit, gjë që krijoi një garë brenda brokerit dhe ai filloi të binte.
Pa një monitorim të thellë, kjo do të ishte e pamundur të zbulohej.. Nëse organizata ka një tjetër problem "pushtimesh", kur çdo person e kalon përgjegjësinë te tjetri, kjo mund të zgjasë gjatë. Ju thjesht e restartoni serverin, sepse është e pamundur të zgjidhet problemi. Kur monitoroni, ndjekni, trackoni të gjitha ngjarjet që keni, dhe përdorni monitorimin si testim — shkruani kod dhe menjëherë specifikoni si ta monitoroni, gjithashtu në formë kodi (ne tashmë kemi infrastrukturë si kod), gjithçka bëhet e qartë si në pëllëmbë. Edhe problemet kaq të komplikuara ndjekin lehtësisht.
Mblidhni të gjitha informacionet mbi atë që ndodh me artefaktin në çdo fazë të procesit të dërgimit — jo në prodhim.
Ngarkoni monitorimin në CI, dhe atje do të shihen disa gjëra të bazueshme. Më pas do t'i shihni edhe në Test, në PredProd, dhe në testimin e ngarkesës. Mblidhni informacionin në të gjitha fazat, përfshirë jo vetëm metrikat, statistikën, por edhe logjet: si u lëshua 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, nevojitet një analitikë e mirë..
Pyetje për vetëkontroll.
A është monitorimi dhe logimi juaj një mjet zhvillimi për ju? A mendojnë zhvilluesit tuaj, dhe ju gjithashtu, kur shkruajnë kod, se si ta monitorojnë atë?
A e merrni vesh për problemet nga klientët? A e kuptoni klientin më mirë nga monitorimi dhe logimi? A e kuptoni sistemin më mirë nga monitorimi dhe logimi? A e ndryshoni sistemin thjesht sepse keni parë se trendi në sistem rritet dhe kuptoni se pas 3 javësh do të dështojë?
Kur keni këto tre komponentë, mund të mendoni për platformën infrastrukturale që keni në kompaninë tuaj.
Platforma infrastrukturore.
Kuptimi nuk është se kjo është një grup veglash të ndara, që ka çdo kompani.
Kuptimi i platformës infrastrukturore është që të gjitha ekipet të përdorin këto vegla dhe t'i zhvillojnë ato së bashku.
E qartë, ka ekipe të veçanta që mbajnë përgjegjësinë 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 çdo inxhinieri. Në nivelin e brendshëm, kjo bëhet një mjet i përgjithshëm.
Të gjitha ekipet zhvillojnë platformën infrastrukturore, e trajtojnë atë me kujdes si IDE-në e tyre. Në IDE-në tuaj vendosni plugina të ndryshme për t'i bërë gjërat të duken bukur dhe të shpejta, konfiguroni çelësat e nxehtë. Kur hapni Sublime, Atom ose Visual Studio Code, aty shihni shumë gabime kodi dhe kuptoni se është krejt e pamundur të punoni, menjëherë bëheni të trishtuar dhe vraponi për të rregulluar IDE-në tuaj.
Trajtojeni platformën tuaj infrastrukturore në të njëjtën mënyrë. Nëse kuptoni se diçka nuk shkon me të, bëni një kërkesë, nëse nuk mund ta rregulloni vetë. Nëse është diçka e thjeshtë, rregulloni atë vetë, dërgoni pull request – djemtë shqyrtojnë, e shtojnë. Kjo është një qasje disi e ndryshme për mjetet inxhinierike në mendjen e zhvilluesit.
Platforma infrastrukturore siguron kalimin e artefaktit nga zhvillimi te klienti me një rritje të vazhdueshme të cilësisë. Në IP ka një set historish të programuar që ndodhin me kodin në prodhim. Me kalimin e viteve të zhvillimit, këto histori bëhen shumë, disa prej tyre janë unike dhe i përkasin vetëm juve – nuk mund t'i gjejmë në Google.
Në këtë moment, platforma infrastrukturore bëhet avantazhi juaj konkurrues, sepse aty ka atë që nuk ka mjeti i konkurrencës. Sa më thellë të jetë IP juaj, aq më shumë avantazh konkurrues keni në lidhje me kohën për treg. Këtu paraqitet problemi i bllokimit nga shitësi: mund të merrni një platformë të huaj, por duke përdorur përvojën e huaj, nuk do të kuptoni se sa i përshtatshëm është për ju. Po, nuk çdo kompani mund të ndërtojë një platformë si Amazon. Kjo është një kufi i ndërlikuar, ku përvoja e kompanisë është relevante për pozitën e saj në treg, dhe nuk duhet lejuar bllokimi vendor. Është gjithashtu e rëndësishme të mendoni për këtë.
Skema
Ky është një skemë e bazës së platformës infrastrukturore, që do t'ju ndihmojë të organizoni të gjitha praktikat dhe proceset në një kompani DevOps.
Le të shohim se çfarë përbëhet.
Sistemi i orkestrimit të burimeve, që ofron CPU, memorie, disk për aplikacionet dhe shërbime të tjera. Në sipërfaqe të saj – shërbime të nivelit të ulët: monitorimi, regjistrimi, CI/CD Engine, depoja e artefakteve, infrastruktura si kod sistemet.
Shërbime të nivelit më të lartë: baza e të dhënave si shërbim, radhitje si shërbim, Load Balance si shërbim, rResize i imazheve si shërbim, Big Data fabrika si shërbim. Më sipër është pipeline që shpërndan kodin e modifikuar vazhdimisht tek klienti tuaj.
Ju merrni informacion mbi mënyrën se si softueri juaj funksionon tek klienti, e ndryshoni, e shkarkoni sërish këtë kod, merrni informacion – dhe kështu zhvilloni vazhdimisht si platformën infrastrukturore ashtu edhe softuerin tuaj.
Në diagramin delivery pipeline përbëhet nga shumë faza. Por kjo është një skemë themelore, e cila është e paraqitur për shembull – nuk duhet ta përsërisni njësoj. Faza ndërveprojnë me shërbimet, si shërbime – çdo bllok i platformës ka historinë e tij: si ndahen burimet, si aplikacioni nis, punon me burimet, monitorohet, ndryshohet.
Është e rëndësishme të kuptoni se çdo pjesë e platformës ka një histori dhe duhet të pyesni veten – çfarë historie ka ky bllok, ndoshta ia vlen ta heqim dhe ta zëvendësojmë me një shërbim të jashtëm. Për shembull, a mund të vendosim Okmeter në vend të këtij blloku? Ndoshta ata kanë zhvilluar këtë ekspertizë më shumë se ne. Por ndoshta jo – ndoshta ne kemi ekspertizë unike, dhe duhet të vendosim Prometheus dhe ta zhvillojmë atë më tej.
Krijimi i platformës
Ky është një proces kompleks komunikimi. Kur keni praktikat bazë, filloni komunikimin midis inxhinierëve dhe specialistëve të ndryshëm, të cilët zhvillojnë kërkesat dhe standardet dhe vazhdimisht i modifikojnë ato për mjete dhe qasje të ndryshme. Këtu kultura, që ekziston në DevOps, është e rëndësishme.
Me kulturën gjithçka është shumë e thjeshtë – është bashkëpunimi dhe komunikimi, dmth dëshira për të punuar në një fushë të përbashkët me njëri-tjetrin, dëshira për të zotëruar një mjet së bashku. Nuk ka asgjë shkencë raketash – gjithçka është shumë e thjeshtë, banale. Për shembull, ne të gjithë jetojmë në një pallat dhe ruajmë pastërtinë e tij – një nivel i tillë kulture.
Dhe për ju?
Sërish pyetje që mund t'i bëni vetes.
A është ndarë platforma infrastrukturore? Kush është përgjegjës 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 ka diçka që mund të transferohet në shërbime të jashtme, duhet ta transferoni; nëse një shërbim i jashtëm fillon të bllokojë aktivitetin tuaj, atëherë duhet të ndërtoni një sistem brenda vetes.
Pra, DevOps...
... është një sistem kompleks, që duhet të ketë:
- Një produkt digjital.
- Modulet e biznesit që zhvillojnë këtë produkt digjital.
- Ekipet produkt që shkruajnë kod.
- Praktikat e Continuous Delivery.
- Platformat si shërbim.
- Infrastruktura si shërbim.
- Infrastruktura si kod.
- Praktika të veçanta për mbajtjen e qëndrueshmërisë, të integruara brenda DevOps.
- Praktika e kthimit të informacionit që përshkruan gjithçka këtë.
Mund ta përdorni këtë skemë, duke e dekoruar atë me atë që keni tashmë në kompani në një formë të caktuar: është zhvilluar ose duhet ende të zhvillohet.
Vetëm pas pak javësh do të zhvillohet . si pjesë e RIT++. Ejani në konferencë, ku ju pret shumë prezantime të shkëlqyera për dorëzimin e vazhdueshëm, infrastrukturën si kod dhe transformimin DevOps. , afati i fundit për çmimet është më 20 maj.
Burimi: habr.com
