Përkufizimi i DevOps është shumë kompleks, kështu që ne duhet të fillojmë diskutimin rreth tij nga e para çdo herë. Ka një mijë botime për këtë temë vetëm në Habré. Por nëse po e lexoni këtë, me siguri e dini se çfarë është DevOps. Sepse nuk jam. Pershendetje, emri im eshte Alexander Titov (@), dhe ne do të flasim vetëm për DevOps dhe unë do të ndaj përvojën time.
Unë kam menduar për një kohë të gjatë se si ta bëj të dobishme historinë time, kështu që këtu 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, të kuptuarit bëhet më i mirë. Unë do t'ju tregoj pse DevOps është i nevojshëm nga këndvështrimi im, çfarë është, përsëri, nga këndvështrimi im dhe si ta kuptoni që po lëvizni përsëri drejt DevOps nga këndvështrimi im. Pika e fundit do të jetë përmes pyetjeve. Duke iu përgjigjur atyre vetë, mund të kuptoni nëse kompania juaj po shkon drejt DevOps ose nëse ka probleme në një farë mënyre.
Dikur isha duke hipur në valët e bashkimeve dhe blerjeve. Fillimisht, punova për një startup të vogël të quajtur Qik, më pas u ble nga një kompani pak më e madhe e quajtur Skype, e cila më pas u ble nga një kompani pak më e madhe e quajtur Microsoft. Në atë moment, fillova të shoh se si po transformohej ideja e DevOps në kompani të madhësive të ndryshme. Pas kësaj, u interesova të shikoja DevOps nga këndvështrimi i tregut dhe unë dhe kolegët e mi themeluam kompaninë Express 42. Prej 6 vitesh ne lëvizim përgjatë valëve të tregut.
Ndër të tjera, unë jam një nga organizatorët e komunitetit DevOps Moscow dhe organizatori i DevOps-Days 2017, por nuk e kam organizuar 2018. Express 42 punon me shumë kompani. Ne rritim DevOps atje, shikojmë se si ndodh, nxjerrim përfundime, analizojmë, u tregojmë të gjithëve përfundimet tona dhe trajnojmë njerëzit në praktikat e DevOps. Në përgjithësi, ne po bëjmë çmos për të rritur përvojën dhe ekspertizën tonë në këtë drejtim.
Pse DevOps
Pyetja e parë që i përndjek të gjithë dhe gjithmonë është - pse? Shumë njerëz mendojnë se DevOps është thjesht automatizimi ose një gjë e ngjashme që çdo kompani e kishte tashmë.
— Ne kishim Integrim të vazhdueshëm - kjo do të thotë se ne kishim tashmë DevOps, dhe pse nevojiten të gjitha këto gjëra? Jashtë po argëtohen, por po na pengojnë të punojmë!
Gjatë 9 viteve të zhvillimit të komunitetit dhe metodologjisë, tashmë është bërë e qartë se ky nuk është shkëlqim marketingu, por ende nuk është plotësisht e qartë pse nevojitet. Ashtu si çdo mjet dhe proces, DevOps ka qëllime specifike që i arrin përfundimisht.
E gjithë kjo është për shkak të faktit se bota po ndryshon. Ai largohet nga qasja e sipërmarrjes, kur kompanitë shkojnë drejt e drejt një ëndrre, siç këndonte klasikja jonë e Shën Petersburgut, nga pika A në pikën B sipas një strategjie të caktuar, me një strukturë të caktuar të ndërtuar për këtë.
Në parim, gjithçka në IT duhet të ndërtohet sipas kësaj qasjeje. Këtu IT përdoret ekskluzivisht për të automatizuar proceset.
Automatizimi nuk ndryshon shpesh, sepse kur një kompani bie në një rrëmujë të shkelur mirë, çfarë ka për të ndryshuar? Ajo funksionon - mos e prekni. Tani qasjet në botë po ndryshojnë, dhe ajo e quajtur Agile sugjeron që pika fundore B nuk është menjëherë e dukshme.
Kur një kompani kalon në treg, punon me një klient, ajo vazhdimisht eksploron tregun dhe ndryshon pikën përfundimtare B. Për më tepër, sa më shpesh kompania të ndryshojë drejtimin e saj, aq më e suksesshme është në fund, sepse zgjedh më shumë treg. kamare.
Strategjia është demonstruar nga një kompani interesante për të cilën kam mësuar kohët e fundit. One Box Shave është një shërbim shpërndarjeje abonimi për brisqe dhe aksesorë rruajtjeje në një kuti. Ata dinë të personalizojnë "kutinë" e tyre për klientë të ndryshëm. Kjo bëhet nga një softuer i caktuar, i cili më pas dërgon porosinë në fabrikën koreane që prodhon mallrat.
Ky produkt u ble nga Unilever për 1 miliard dollarë. Tani ajo konkurron me Gillette dhe ka marrë një pjesë të konsiderueshme të konsumatorëve në tregun amerikan. One Box Shave thotë:
- 4 tehe? Jeni seriozisht? Pse keni nevojë për këtë - nuk përmirëson cilësinë e rruajtjes. Një krem, aromë e zgjedhur posaçërisht dhe një brisk me cilësi të lartë me dy tehe zgjidhin shumë më tepër probleme sesa ato budallenj 4 tehe Gillette! A do të arrijmë në 10 së shpejti?
Kështu ndryshon bota. Unilever pretendon se ata kanë një sistem të lezetshëm IT që ju lejon ta bëni këtë. Në fund duket si një koncept Koha për në treg, për të cilën askush nuk ka folur tashmë.
Pika e Kohës së Tregut nuk është se sa shpesh vendosemi. Shpesh mund të vendosni, por ciklet e lëshimit do të jenë të gjata. Nëse ciklet e lëshimit tre mujor mbivendosen mbi njëri-tjetrin, duke i zhvendosur ato me një javë, rezulton se kompania duket se po vendoset një herë në javë. Dhe nga ideja deri në zbatimin përfundimtar duhen 3 muaj.
Koha në treg ka të bëjë me minimizimin e kohës nga ideja deri në zbatimin përfundimtar.
Në këtë rast, softueri ndërvepron me tregun. Kështu ndërvepron faqja e internetit One Box Shave me klientin. Ata nuk kanë shitës - vetëm një faqe interneti ku vizitorët klikojnë dhe lënë dëshirat. Prandaj, diçka e re duhet të postohet vazhdimisht në faqe dhe të përditësohet në përputhje me dëshirat. Për shembull, në Korenë e Jugut ata rruhen ndryshe nga Rusia, dhe u pëlqen aroma jo e pishës, por, për shembull, e karotave dhe vaniljes.
Meqenëse është e nevojshme të ndryshoni shpejt përmbajtjen e faqes, zhvillimi i softuerit ndryshon shumë. Përmes softuerit duhet të zbulojmë se çfarë dëshiron klienti. Më parë, ne e mësuam këtë përmes disa mënyrave rrethrrotulluese, për shembull, përmes menaxhimit të biznesit. Pastaj e projektuam, vendosëm kërkesat në sistemin e TI-së dhe gjithçka ishte e mirë. Tani është ndryshe - softueri është projektuar nga të gjithë ata që janë të përfshirë në proces, duke përfshirë inxhinierët, sepse përmes specifikimeve teknike ata mësojnë se si funksionon tregu dhe gjithashtu ndajnë njohuritë e tyre me biznesin.
Për shembull, në Qik papritmas mësuam se njerëzve u pëlqente shumë të ngarkonin listat e kontakteve në server dhe ata na furnizuan me një aplikacion. Fillimisht nuk e menduam. Në një kompani klasike, të gjithë do të kishin vendosur që ky ishte një gabim, pasi specifikimi nuk thoshte që duhet të funksiononte mirë dhe përgjithësisht zbatohej në gju, ata do ta kishin fikur funksionin dhe do të thoshin: "Askush nuk ka nevojë për këtë, gjëja më e rëndësishme është që funksionaliteti kryesor të funksionojë.” . Dhe kompania e teknologjisë e sheh këtë si një mundësi dhe fillon të ndryshojë softuerin në përputhje me këtë.
Në vitin 1968, një djalë vizionar, Melvin Conway, formuloi idenë e mëposhtme.
Organizata që krijon sistemin është e kufizuar nga një dizajn që përsërit strukturën e komunikimit të asaj organizate.
Më në detaje, për të prodhuar sisteme të një lloji tjetër, duhet të keni edhe një strukturë komunikimi brenda një kompanie të një lloji tjetër. Nëse struktura juaj e komunikimit është hierarkike e lartë, atëherë kjo nuk do t'ju lejojë të krijoni sisteme që mund të ofrojnë një tregues shumë të lartë të Kohës së Tregut.
Lexoni një mund të . Është e rëndësishme për të kuptuar kulturën ose filozofinë e DevOps sepse e vetmja gjë që ndryshon rrënjësisht në DevOps është struktura e komunikimit midis ekipeve.
Nga pikëpamja e procesit, përpara DevOps, të gjitha fazat: analitika, zhvillimi, testimi, funksionimi, ishin lineare.
Në rastin e DevOps, të gjitha këto procese ndodhin njëkohësisht.
Koha për në treg është e vetmja mënyrë që mund të bëhet. Për njerëzit që kanë punuar në procesin e vjetër, kjo duket disi kozmike, dhe përgjithësisht kështu.
Pra, pse keni nevojë për DevOps?
Për zhvillimin e produkteve dixhitale. Nëse kompania juaj nuk ka një produkt dixhital, DevOps nuk nevojitet - është shumë e rëndësishme.
DevOps kapërcen kufizimet e shpejtësisë së prodhimit të njëpasnjëshëm të softuerit. Në të të gjitha proceset ndodhin njëkohësisht.
Vështirësia rritet. Kur ungjilltarët e DevOps ju thonë se do ta bëjë më të lehtë për ju lëshimin e softuerit, kjo është e pakuptimtë.
Me DevOps, gjërat do të bëhen më të ndërlikuara.
Në konferencën në stendën Avito, ju mund të shihni se si ishte vendosja e një kontejneri Docker - një detyrë joreale. Kompleksiteti bëhet pengues; ju duhet të mashtroni me shumë topa në të njëjtën kohë.
DevOps ndryshon plotësisht procesin dhe organizimin në kompani — më saktë, nuk është DevOps që ndryshon, por produkti dixhital. Për të ardhur në DevOps, duhet të ndryshoni plotësisht këtë proces.
Pyetje për një specialist
Cfare ke? Pyetje që mund t'i bëni vetes gjatë punës në një kompani dhe zhvillimit si specialist.
A keni një strategji për krijimin e një produkti dixhital? Nëse ka, kjo tashmë është mirë. Kjo do të thotë që kompania juaj po shkon drejt DevOps.
A po krijon kompania juaj tashmë një produkt dixhital? Kjo do të thotë që ju mund të ngriheni një nivel tjetër më lart dhe t'i bëni gjërat më interesante - përsëri nga një këndvështrim DevOps. Unë po flas vetëm nga ky këndvështrim.
A është kompania juaj një nga liderët e tregut në tregun e produkteve dixhitale? Spotify, Yandex, Uber janë kompani që janë në kulmin e përparimit teknologjik tani.
Bëjini vetes këto pyetje dhe nëse të gjitha përgjigjet janë jo, atëherë ndoshta nuk duhet të bëni DevOps në këtë kompani. Nëse tema e DevOps është vërtet interesante për ju, ndoshta... duhet të transferoheni në një kompani tjetër? Nëse kompania juaj dëshiron të hyjë në DevOps, por ju i jeni përgjigjur "Jo" të gjitha pyetjeve, atëherë është si ai rinoceronti i bukur që nuk do të ndryshojë kurrë.
Organizatë
Siç thashë, sipas ligjit të Conway, organizimi i një kompanie ndryshon. Do të filloj me atë që pengon DevOps të depërtojë brenda kompanisë nga pikëpamja organizative.
Problemi i "puseve"
Fjala angleze "Silo" përkthehet këtu në Rusisht si "pus". Thelbi i këtij problemi është se nuk ka shkëmbim informacioni ndërmjet ekipeve. Çdo ekip gërmon thellë në ekspertizën e tij, pa ndërtuar një hartë të përbashkët për të lundruar.
Në një farë mënyre kjo më kujton një person që sapo ka mbërritur në Moskë dhe nuk di ende se si të lundrojë në hartën e metrosë. Moskovitët zakonisht e njohin shumë mirë zonën e tyre, dhe në të gjithë Moskën ata mund të lundrojnë duke përdorur hartën e metrosë. Kur vini për herë të parë në Moskë, nuk e keni këtë aftësi dhe thjesht jeni të çorientuar.
DevOps sugjeron të kaloni këtë moment çorientimi dhe të gjitha departamentet të punojnë së bashku për të ndërtuar një hartë të përbashkët ndërveprimi.
Dy faktorë e pengojnë këtë.
Pasoja e sistemit të menaxhimit të korporatës. Është ndërtuar në “puse” të veçanta hierarkike. Për shembull, ka disa KPI në kompani që mbështesin këtë sistem. Nga ana tjetër, truri i një personi që e ka të vështirë të shkojë përtej kufijve të ekspertizës së tij dhe të lundrojë në të gjithë sistemin, pengohet. Është thjesht e pakëndshme. Imagjinoni që jeni në aeroportin e Bangkok - nuk do ta gjeni shpejt rrugën tuaj. DevOps është gjithashtu i vështirë për t'u naviguar, dhe kjo është arsyeja pse njerëzit thonë se duhet të gjesh një udhëzues për të arritur atje.
Por gjëja më e rëndësishme është se problemi i "puseve" për një inxhinier që është i mbushur me frymën e DevOps, ka lexuar Fowler dhe një mori librash të tjerë, shprehet në faktin se “pusetat” nuk të lejojnë të bësh gjëra “të dukshme”.. Ne shpesh mblidhemi pas DevOps Moscow, flasim me njëri-tjetrin dhe njerëzit ankohen:
— Ne thjesht donim të nisnim CI, por doli që menaxhmentit nuk i duhej.
Kjo ndodh pikërisht sepse CI и Procesi i dërgimit të vazhdueshëm janë në kufirin e shumë ekzaminimeve. Thjesht pa kapërcyer problemin e “puseve” në nivel organizativ, nuk do të mund të ecni përpara, pavarësisht se çfarë bëni dhe sado trishtuese të jetë.
Secili pjesëmarrës në procesin në kompani: zhvilluesit e backend dhe frontend, testimi, DBA, operacioni, rrjeti, gërmon në drejtimin e tyre dhe askush nuk ka një hartë të përbashkët përveç menaxherit, i cili disi i monitoron dhe i menaxhon duke përdorur "ndarjen dhe pushto” metodë.
Njerëzit po luftojnë për disa yje apo flamuj, të gjithë po gërmojnë ekspertizën e tyre.
Si rezultat, kur lind detyra për të lidhur të gjitha këto së bashku dhe për të ndërtuar një tubacion të përbashkët, dhe nuk ka më nevojë të luftoni për yje dhe flamuj, lind pyetja - çfarë të bëni gjithsesi? Ne duhet të arrijmë një marrëveshje disi, por askush nuk na mësoi se si ta bëjmë këtë në shkollë. Ne kemi mësuar që në shkollë: klasën e tetë - wow! - krahasuar me klasën e shtatë! Është e njëjta gjë këtu.
A është e njëjta gjë në kompaninë tuaj?
Për ta kontrolluar këtë, mund t'i bëni vetes pyetjet e mëposhtme.
A përdorin ekipet mjete të zakonshme dhe a kontribuojnë në ndryshimet në ato mjete të zakonshme?
Sa shpesh riorganizohen ekipet - disa specialistë nga një ekip kalojnë në një ekip tjetër? Është në një mjedis DevOps që kjo bëhet normale, sepse ndonjëherë një person thjesht nuk mund të kuptojë se çfarë po bën një fushë tjetër e ekspertizës. Ai kalon në një departament tjetër, punon atje për dy javë për të krijuar për vete një hartë orientimi dhe ndërveprimi me këtë departament.
A është e mundur të formohet një komitet ndryshimi dhe të ndryshohen gjërat? Apo kërkon dorën e fortë të menaxhimit dhe drejtimit më të lartë? Kohët e fundit kam shkruar në Facebook se si një bankë pak e njohur po zbaton mjete përmes porosive: ne shkruajmë një urdhër, e zbatojmë atë për një vit dhe shohim se çfarë ndodh. Kjo, natyrisht, është e gjatë dhe e trishtueshme.
Sa e rëndësishme është që menaxherët të marrin arritje personale pa marrë parasysh arritjet e kompanisë?
Nëse i përgjigjeni vetë këtyre pyetjeve, do të bëhet më e qartë nëse keni një problem të tillë në kompaninë tuaj.
Infrastruktura si kod
Pas kalimit të këtij problemi, praktika e parë e rëndësishme, pa të cilën është e vështirë të përparosh më tej në DevOps, është infrastruktura si kod.
Më shpesh, infrastruktura si kod perceptohet si më poshtë:
— Le të automatizojmë gjithçka në bash, të mbulohemi me skripta që administratorët të kenë më pak punë manuale!
Por kjo nuk është e vërtetë.
Infrastruktura si kod do të thotë që ju përshkruani sistemin e IT me të cilin punoni në formën e kodit në mënyrë që të kuptoni vazhdimisht gjendjen e tij.
Së bashku me ekipet e tjera, ju krijoni një hartë në formën e kodit që të gjithë mund ta kuptojnë dhe mund të lundrojnë dhe lundrojnë. Nuk ka rëndësi se në çfarë është bërë - Chef, Ansible, Salt ose duke përdorur skedarë YAML në Kubernetes - nuk ka asnjë ndryshim.
Në konferencë, një koleg nga 2GIS tregoi se si ata krijuan gjënë e tyre të brendshme për Kubernetes, i cili përshkruan strukturën e sistemeve individuale. Për të përshkruar 500 sisteme, atyre u duhej një mjet i veçantë që gjeneron këtë përshkrim. Kur ekziston ky përshkrim, të gjithë mund të kontrollojnë me njëri-tjetrin, të monitorojnë ndryshimet, si ta ndryshojnë dhe përmirësojnë atë, çfarë mungon.
Pajtohem, skriptet individuale bash zakonisht nuk e ofrojnë këtë kuptim. Në një nga kompanitë ku punoja, kishte edhe një emër për skenarin "vetëm shkruaj" - kur shkruhet skenari, por nuk është më e mundur ta lexosh atë. Unë mendoj se kjo është e njohur edhe për ju.
Infrastruktura siç është kodi kodi që përshkruan gjendjen aktuale të infrastrukturës. Shumë ekipe produktesh, infrastrukturës dhe shërbimesh punojnë së bashku në këtë kod, dhe më e rëndësishmja, të gjithë duhet të kuptojnë se si funksionon në të vërtetë ky kod.
Kodi mbahet sipas praktikave më të mira të kodit: zhvillimi i përbashkët, rishikimi i kodit, programimi XP, testimi, kërkesat për tërheqje, CI për infrastrukturën e kodit - e gjithë kjo është e përshtatshme dhe mund të përdoret.
Kodi bëhet një gjuhë e përbashkët për të gjithë inxhinierët.
Ndryshimi i infrastrukturës në kod nuk kërkon shumë kohë. Po, kodi i infrastrukturës mund të ketë edhe borxh teknik. Zakonisht ekipet e hasin një vit e gjysmë pasi filluan të zbatonin "infrastrukturën si kod" në formën e një tufe skriptash apo edhe Ansible, të cilat i shkruajnë si kod spageti, dhe gjithashtu hedhin skriptet bash në përzierje!
Është e rëndësishme: Nëse nuk i keni provuar ende këto gjëra, mbani mend këtë Ansible nuk është bash! Lexoni me kujdes dokumentacionin, studioni se çfarë shkruajnë për të.
Infrastruktura si kod është ndarja e kodit të infrastrukturës në shtresa të veçanta.
Në kompaninë tonë dallojmë 3 shtresa bazë, të cilat janë shumë të qarta dhe të thjeshta, por mund të ketë më shumë. Mund të shikoni kodin tuaj të infrastrukturës dhe të tregoni nëse e keni këtë gjendje apo jo. Nëse asnjë shtresë nuk është theksuar, atëherë duhet të kaloni pak kohë dhe të rifaktoni pak.
shtresa bazë - kështu konfigurohen OS, kopjet rezervë dhe gjëra të tjera të nivelit të ulët, për shembull, si vendoset Kubernetes në nivelin bazë.
Niveli i shërbimit - këto janë shërbimet që i ofroni zhvilluesit: regjistrimi si shërbim, monitorimi si shërbim, baza e të dhënave si shërbim, balancuesi si shërbim, radha si shërbim, Dorëzimi i vazhdueshëm si shërbim - një mori shërbimesh që ekipet individuale mund të sigurojë zhvillimin. E gjithë kjo duhet të përshkruhet në module të veçanta në sistemin tuaj të menaxhimit të konfigurimit.
Shtresa ku bëhen aplikimet dhe përshkruan se si ato do të shpalosen në krye të dy shtresave të mëparshme.
Pyetjet e kontrollit
A ka kompania juaj një depo të përbashkët të infrastrukturës? A po menaxhoni borxhin teknik në infrastrukturën tuaj? A përdorni praktikat e zhvillimit në një depo infrastrukture? A është infrastruktura juaj e ndarë në shtresa? Mund të kontrolloni diagramin Bazë-shërbim-APP. Sa e vështirë është të bësh një ndryshim?
Nëse keni përjetuar se ju është dashur një ditë e gjysmë për të bërë ndryshime, kjo do të thotë se keni borxh teknik dhe duhet të punoni me të. Sapo keni ngecur në një grabujë teknike të borxhit në kodin tuaj të infrastrukturës. Më kujtohen shumë histori të tilla kur, për të ndryshuar disa CCTL, duhet të rishkruash gjysmën e kodit të infrastrukturës, sepse kreativiteti dhe dëshira për të automatizuar gjithçka çuan në faktin se gjithçka është gërryer kudo, të gjitha dorezat janë hequr dhe është e nevojshme të rifaktorohet.
Dorëzimi i vazhdueshëm
Le të krahasojmë debitin me kredinë. Së pari vjen një përshkrim i infrastrukturës, i cili mund të jetë mjaft bazë. Nuk është e nevojshme të përshkruani gjithçka në detaje, por kërkohet një përshkrim bazë që të mund të punoni me të. Përndryshe, nuk është e qartë se çfarë të bëhet më pas me shpërndarjen e vazhdueshme. Të gjitha këto praktika shpalosen njëkohësisht kur vini në DevOps, por fillon me të kuptuarit se çfarë keni dhe si ta menaxhoni atë. Kjo është pikërisht praktika e infrastrukturës si kod.
Pasi të bëhet e qartë se e keni atë dhe si ta menaxhoni atë, filloni të kuptoni se si ta dërgoni kodin e zhvilluesit në prodhim sa më shpejt që të jetë e mundur. Dua të them së bashku me zhvilluesin - ne kujtojmë problemin e "puseve", domethënë, nuk janë njerëz individualë që dalin me këtë, por një ekip.
Kur jemi me Vanya Evtukhovich pa librin e parë Jez Humble dhe grupe autorësh "Dorëzimi i vazhdueshëm", i cili u publikua në 2009, menduam për një kohë të gjatë se si ta përkthenim titullin e tij në Rusisht. Ata donin ta përkthenin si "Dorëzo vazhdimisht", por, për fat të keq, u përkthye si "Dorëzim i vazhdueshëm". Më duket se ka diçka ruse në emrin tonë, me presion.
Shpërndarja e vazhdueshme e mjeteve
Kodi që është në depon e produktit mund të shkarkohet gjithmonë në prodhim. Ai mund të mos jetë i shfryrë, por ai është gjithmonë gati për të. Prandaj, ju gjithmonë shkruani kod me një ndjenjë të vështirë për t'u shpjeguar të njëfarë ankthi nën bishtin tuaj. Shpesh shfaqet kur nxjerr kodin e infrastrukturës. Kjo ndjenjë e njëfarë ankthi duhet të jetë e pranishme - ajo shkakton procese të trurit që ju lejojnë të shkruani kodin pak më ndryshe. Kjo duhet të regjistrohet në rregullat brenda zhvillimit.
Për të ofruar vazhdimisht, ju nevojitet një format artifakti që kalon nëpër një platformë infrastrukturore. Nëse hidhni “humbje jete” të formateve të ndryshme në një platformë infrastrukturore, atëherë ajo bëhet e unifikuar, është e vështirë të mirëmbahet dhe lind problemi i borxhit teknik. Formati i artefaktit duhet të përafrohet - kjo është gjithashtu një detyrë kolektive: ne të gjithë duhet të mblidhemi, të shushurisim trurin tonë dhe të dalim me këtë format.
Artifakti përmirësohet vazhdimisht dhe ndryshon për t'iu përshtatur mjedisit të prodhimit ndërsa lëviz nëpër tubacionin e dorëzimit. Kur një objekt lëviz përgjatë tubacionit, ai vazhdimisht ndeshet me disa gjëra të papërshtatshme për të, të cilat janë të ngjashme me atë që has artefakti që ju vendosni në prodhim. Nëse në zhvillimin klasik kjo bëhet nga një administrator i sistemit që bën paraqitjen, atëherë në procesin DevOps kjo ndodh gjatë gjithë kohës: këtu e testuan me disa teste, këtu e hodhën në një grup Kubernetes, i cili është pak a shumë i ngjashëm. në prodhim, pastaj papritmas filluan testimin e ngarkesës.
Kjo të kujton disi lojën Pac-Man - artifakti kalon nëpër një lloj historie. Në të njëjtën kohë, është e rëndësishme të kontrolloni nëse kodi në të vërtetë kalon nëpër histori dhe nëse ai është disi i lidhur me prodhimin tuaj. Historitë nga prodhimi mund të tërhiqen në procesin e dorëzimit të vazhdueshëm: ishte kështu kur diçka ra, tani le ta programojmë këtë skenar brenda sistemit. Çdo herë që kodi do të kalojë edhe në këtë skenar dhe nuk do ta hasni këtë problem herën tjetër. Ju do të mësoni për të shumë më herët sesa të arrijë klienti juaj.
Strategji të ndryshme vendosjeje. Për shembull, ju përdorni testimin AB ose vendosjet e kanarisë për të testuar kodin në mënyra të ndryshme në klientë të ndryshëm, për të marrë informacione se si funksionon kodi dhe shumë më herët se kur ai është shpërndarë në 100 milionë përdorues.
"Dorëzo në mënyrë të vazhdueshme" duket kështu.
Procesi i dorëzimit Dev, CI, Test, PreProd, Prod nuk është një mjedis i veçantë, këto janë faza ose stacione me shuma të papërshkueshme nga zjarri nëpër të cilat kalon objekti juaj.
Nëse keni kodin e infrastrukturës që përshkruhet si APP i Shërbimit Bazë, atëherë ju ndihmon mos harroni të gjitha skenarët, dhe shkruajini ato si kod për këtë objekt, promovojnë artefakt dhe ndryshoni atë ndërsa shkoni.
Pyetje për vetë-testim
Koha nga përshkrimi i veçorive deri në daljen në prodhim në 95% të rasteve është më pak se një javë? A përmirësohet cilësia e objektit në çdo fazë të tubacionit? A ka ndonjë histori që kalon? A përdorni strategji të ndryshme vendosjeje?
Nëse të gjitha përgjigjet janë po, atëherë ju jeni jashtëzakonisht të lezetshëm! Shkruani përgjigjet tuaja në komente - do të jem i lumtur).
reagim
Kjo është praktika më e vështirë nga të gjitha. Në konferencën DevOpsConf, një koleg nga Infobip, duke folur për këtë, ishte pak i hutuar në fjalët e tij, sepse kjo është me të vërtetë një praktikë shumë komplekse për faktin që ju duhet të monitoroni gjithçka!
Për shembull, shumë kohë më parë, kur punoja në Qik dhe kuptuam se duhej të monitoronim gjithçka. Ne e bëmë këtë dhe tani kemi 150 artikuj në Zabbix, të cilët monitorohen vazhdimisht. Ishte e frikshme, drejtori teknik ktheu gishtin në tëmth:
- Djema, pse po përdhunoni serverin me diçka të paqartë?
Por më pas ndodhi një incident që tregoi se kjo është vërtet një strategji shumë e lezetshme.
Një nga shërbimet filloi të rrëzohej vazhdimisht. Fillimisht, ai nuk u rrëzua, gjë që është interesante, kodi nuk u shtua atje, sepse ishte një ndërmjetës bazë, i cili praktikisht nuk kishte asnjë funksionalitet biznesi - thjesht dërgonte mesazhe midis shërbimeve individuale. Shërbimi nuk ndryshoi për 4 muaj dhe papritmas filloi të rrëzohej me gabimin "Segmentation fault".
Ne u tronditëm, hapëm grafikët tanë në Zabbix dhe doli që një javë e gjysmë më parë, sjellja e kërkesave në shërbimin API që përdor ky ndërmjetës ndryshoi shumë. Më pas pamë se frekuenca e dërgimit të një lloji të caktuar mesazhi kishte ndryshuar. Më vonë zbuluam se këta ishin klientë android. Ne pyetëm:
- Djema, çfarë ndodhi me ju një javë e gjysmë më parë?
Si përgjigje, ne dëgjuam një histori interesante se si ata kishin ridizajnuar UI. Nuk ka gjasa që dikush të thotë menjëherë se ka ndryshuar bibliotekën HTTP. Për klientët Android, është si të ndërroni sapun në banjë - thjesht nuk e mbajnë mend. Si rezultat, pas 40 minutash bisedë, zbuluam se ata kishin ndryshuar bibliotekën HTTP dhe oraret e saj të paracaktuara kishin ndryshuar. Kjo çoi në ndryshimin e sjelljes së trafikut në serverin API, gjë që çoi në një situatë që shkaktoi një garë brenda ndërmjetësit dhe ai filloi të rrëzohej.
Pa monitorim të thellë është përgjithësisht e pamundur ta hapësh këtë. Nëse organizata ka ende problemin e “puseve”, kur të gjithë hedhin para njëri-tjetrit, kjo mund të jetojë me vite. Ju thjesht rinisni serverin sepse është e pamundur të zgjidhet problemi. Kur monitoroni, gjurmoni, gjurmoni të gjitha ngjarjet që keni dhe përdorni monitorimin si testim - shkruani kodin dhe tregoni menjëherë se si ta monitoroni atë, gjithashtu në formën e kodit (ne tashmë kemi infrastrukturën si kod), gjithçka bëhet e qartë se si në pëllëmbë. Edhe probleme të tilla komplekse gjurmohen lehtësisht.
Mblidhni të gjithë informacionin rreth asaj që ndodh me objektin në çdo fazë të procesit të dorëzimit - jo në prodhim.
Ngarkoni monitorimin në CI dhe disa gjëra themelore tashmë do të jenë të dukshme atje. Më vonë do t'i shihni ato në Test, PredProd dhe testimin e ngarkesës. Mblidhni informacione në të gjitha fazat, jo vetëm metrikat, statistikat, por edhe regjistrat: si doli aplikacioni, anomalitë - mblidhni gjithçka.
Përndryshe do të jetë e vështirë për ta kuptuar atë. Unë tashmë thashë që DevOps është më kompleks. Për të përballuar këtë kompleksitet, duhet të keni analiza normale.
Pyetje për vetëkontroll
A është monitorimi dhe regjistrimi juaj mjeti i zhvillimit për ju? Kur shkruani kodin, a mendojnë zhvilluesit tuaj, përfshirë ju, se si ta monitorojnë atë?
A keni dëgjuar për probleme nga klientët? A e kuptoni më mirë klientin nga monitorimi dhe regjistrimi? A e kuptoni më mirë sistemin nga monitorimi dhe regjistrimi? E ndryshoni sistemin thjesht sepse patë që trendi në sistem po rritet dhe e kuptoni që në 3 javë të tjera gjithçka do të vdesë?
Pasi të keni këto tre komponentë, mund të mendoni se çfarë lloj platforme infrastrukturore keni në kompaninë tuaj.
Platforma e infrastrukturës
Çështja nuk është se është një grup mjetesh të ndryshme që ka çdo kompani.
Qëllimi i një platforme infrastrukturore është që të gjitha ekipet t'i përdorin këto mjete dhe t'i zhvillojnë ato së bashku.
Është e qartë se ka ekipe të veçanta që janë përgjegjëse për zhvillimin e pjesëve individuale të platformës së infrastrukturës. Por në të njëjtën kohë, çdo inxhinier mban përgjegjësi për zhvillimin, performancën dhe promovimin e platformës së infrastrukturës. Në një nivel të brendshëm ai bëhet një mjet i zakonshëm.
Të gjitha ekipet zhvillojnë platformën e infrastrukturës dhe e trajtojnë atë me kujdes si IDE-në e tyre. Në IDE-në tuaj ju instaloni shtojca të ndryshme për ta bërë gjithçka të bukur dhe të shpejtë, dhe të konfiguroni çelësat kryesorë. Kur hap Sublime, Atom ose Visual Studio Code, gabimet e kodit po vërshojnë dhe e kupton se është e pamundur të punosh fare, ndihesh menjëherë i trishtuar dhe vrapon të rregullosh IDE-në tënde.
Trajtoni platformën tuaj të infrastrukturës në të njëjtën mënyrë. Nëse e kuptoni se ka diçka që nuk shkon me të, lini një kërkesë nëse nuk mund ta rregulloni vetë. Nëse ka diçka të thjeshtë, modifikojeni vetë, dërgoni një kërkesë për tërheqje, djemtë do ta marrin në konsideratë dhe do ta shtojnë. Kjo është një qasje paksa e ndryshme për mjetet inxhinierike në kokën e zhvilluesit.
Platforma e infrastrukturës siguron transferimin e artefaktit nga zhvillimi tek klienti me përmirësim të vazhdueshëm në cilësi. IP është programuar me një sërë historish që ndodhin me kodin në prodhim. Gjatë viteve të zhvillimit, ka shumë nga këto histori, disa prej tyre janë unike dhe lidhen vetëm me ju - ato nuk mund të kërkohen në Google.
Në këtë pikë, platforma e infrastrukturës bëhet avantazhi juaj konkurrues, sepse ka diçka të integruar që nuk është në mjetin e konkurrentit. Sa më e thellë IP-ja juaj, aq më i madh është avantazhi juaj konkurrues për sa i përket Kohës së Tregut. Shfaqet këtu problem me bllokimin e shitësit: Ju mund të merrni platformën e dikujt tjetër, por duke përdorur përvojën e dikujt tjetër, nuk do ta kuptoni se sa e rëndësishme është për ju. Po, jo çdo kompani mund të ndërtojë një platformë si Amazon. Kjo është një linjë e vështirë ku përvoja e kompanisë është e rëndësishme për pozicionin e saj në treg dhe nuk mund të përdorni një bllokues shitësi atje. Kjo është gjithashtu e rëndësishme për të menduar.
skemë
Ky është një diagram bazë i një platforme infrastrukturore që 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, disk në aplikacione dhe shërbime të tjera. Në krye të kësaj - shërbime të nivelit të ulët: monitorimi, prerjet, motori CI/CD, ruajtja e objekteve, infrastruktura si kod sistemi.
Shërbime të nivelit të lartë: baza e të dhënave si shërbim, radhët si shërbim, Load Balance si shërbim, ndryshimi i madhësisë së imazhit si shërbim, Fabrika e të dhënave të mëdha si shërbim. Në krye të kësaj - tubacion që i jep klientit tuaj kod të modifikuar vazhdimisht.
Ju merrni informacione se si funksionon softueri juaj për klientin, e ndryshoni atë, jepni përsëri këtë kod, merrni informacion - dhe kështu ju zhvilloni vazhdimisht platformën e infrastrukturës dhe softuerin tuaj.
Në diagram, tubacioni i dorëzimit përbëhet nga shumë faza. Por ky është një diagram skematik që jepet si shembull - nuk ka nevojë të përsëritet një nga një. Fazat ndërveprojnë me shërbimet sikur të ishin shërbime - çdo tullë e platformës mbart historinë e vet: si shpërndahen burimet, si lëshohet aplikacioni, funksionon me burimet, monitorohet dhe ndryshon.
Është e rëndësishme të kuptoni se çdo pjesë e platformës mbart një histori dhe pyesni veten se çfarë historie mbart kjo tullë, ndoshta duhet të hidhet dhe të zëvendësohet me një shërbim të palës së tretë. Për shembull, a është e mundur të instaloni Okmeter në vend të një tullë? Ndoshta djemtë e kanë zhvilluar tashmë këtë ekspertizë shumë më tepër se ne. Por ndoshta jo - ndoshta ne kemi ekspertizë unike, duhet ta instalojmë Prometheus dhe ta zhvillojmë më tej.
Krijimi i platformës
Ky është një proces kompleks komunikimi. Kur keni praktika bazë, filloni komunikimin midis inxhinierëve dhe specialistëve të ndryshëm që zhvillojnë kërkesa dhe standarde dhe vazhdimisht i ndryshoni ato në mjete dhe qasje të ndryshme. Kultura që kemi në DevOps është e rëndësishme këtu.
Me kulturë gjithçka është shumë e thjeshtë - ka të bëjë me bashkëpunimin dhe komunikimin, pra dëshira për të punuar në një fushë të përbashkët me njëri-tjetrin, dëshira për të përdorur së bashku një instrument. Këtu nuk ka shkencë raketore - gjithçka është shumë e thjeshtë, banale. Për shembull, ne të gjithë jetojmë në hyrje dhe e mbajmë atë të pastër - një nivel i tillë kulture.
Cfare ke?
Përsëri, pyetjet që mund t'i bëni vetes.
A është e dedikuar platforma e infrastrukturës? Kush është përgjegjës për zhvillimin e tij? A i kuptoni avantazhet konkurruese të platformës suaj të infrastrukturës?
Ju duhet t'i bëni vazhdimisht vetes këto pyetje. Nëse diçka mund të transferohet në shërbime të palëve të treta, ajo duhet të transferohet; nëse një shërbim i palës së tretë fillon të bllokojë lëvizjen tuaj, atëherë ju duhet të ndërtoni një sistem brenda vetes.
Pra, DevOps...
... ky është një sistem kompleks, ai duhet të ketë:
- Produkt dixhital.
- Modulet e biznesit që zhvillojnë këtë produkt dixhital.
- Ekipet e produkteve që shkruajnë kodin.
- Praktikat e shpërndarjes së vazhdueshme.
- Platformat si shërbim.
- Infrastruktura si shërbim.
- Infrastruktura si kod.
- Praktika të veçanta për ruajtjen e besueshmërisë, të integruara në DevOps.
- Një praktikë reagimi që i përshkruan të gjitha.
Ju mund ta përdorni këtë diagram, duke theksuar në të atë që tashmë keni në kompaninë tuaj në një formë: a është zhvilluar ose ende duhet të zhvillohet.
Do të përfundojë brenda dy javësh . si pjesë e RIT++. Ejani në konferencë, ku do të gjeni shumë raporte interesante në lidhje me shpërndarjen e vazhdueshme, infrastrukturën si kod dhe transformimin e DevOps. , afati i fundit i çmimit është 20 maji
Burimi: www.habr.com