Danasîna DevOps pir tevlihev e, ji ber vê yekê divê em her carê nîqaşa li ser wê ji nû ve dest pê bikin. Tenê li ser Habré li ser vê mijarê hezar belavok hene. Lê heke hûn vê dixwînin, hûn belkî dizanin DevOps çi ye. Ji ber ku ez ne. Merheba navê min Alexander Titov (@), û em ê tenê li ser DevOps biaxivin û ez ê ezmûna xwe parve bikim.
Ez demek dirêj difikirîm ka meriv çawa çîroka xwe kêrhatî dike, ji ber vê yekê dê li vir gelek pirs hebin - yên ku ez ji xwe dipirsim û yên ku ez ji xerîdarên pargîdaniya me dipirsim. Bi bersivdana van pirsan, têgihiştin çêtir dibe. Ez ê ji we re vebêjim ka çima DevOps ji nihêrîna min hewce ye, ew dîsa ji nêrîna min çi ye, û meriv çawa fêm dike ku hûn ji nihêrîna min dîsa ber bi DevOps ve diçin. Xala dawî dê bi rêya pirsan be. Bi bersiva wan ji bo xwe, hûn dikarin fêm bikin ka pargîdaniya we ber bi DevOps ve diçe an jî bi rengek pirsgirêk hene.
Demekê ez li ser pêlên yekbûn û desteserkirinê siwar bûm. Pêşî, ez ji bo destpêkek piçûk a bi navê Qik xebitîm, piştre ew ji hêla pargîdaniyek piçûktir a bi navê Skype ve hate kirîn, ku dûv re ji hêla pargîdaniyek piçûktir a bi navê Microsoft ve hate kirîn. Wê gavê, min dest pê kir ku bibînim ka ramana DevOps çawa di pargîdaniyên mezinahiyên cihêreng de vediguhere. Piştî wê, ez eleqedar bûm ku bi nêrîna bazarê li DevOps mêze bikim, û min û hevkarên xwe pargîdaniya Express 42 ava kir. Ev 6 sal in em li ser pêlên bazarê dimeşin.
Di nav tiştên din de, ez yek ji organîzatorên civata DevOps Moskowê û organîzatorê DevOps-Days 2017 me, lê min 2018 organîze nekir. Express 42 bi gelek pargîdaniyan re dixebite. Em li wir DevOps mezin dikin, temaşe dikin ka ew çawa diqewime, encaman derdixin, analîz dikin, encamên xwe ji her kesî re vedibêjin, û mirovan di pratîkên DevOps de perwerde dikin. Bi giştî em bi hemû hêza xwe hewl didin ku di vî warî de ezmûn û pisporiya xwe zêde bikin.
Çima DevOps
Pirsa yekem ku her kes dikişîne û her dem ev e - çima? Pir kes difikirin ku DevOps tenê otomasyon an tiştek mîna ku her pargîdanî berê hebû ye.
- Me Yekbûnek Berdewam hebû - ev tê vê wateyê ku me berê DevOps hebû, û çima ev hemî tişt hewce ne? Li derve kêfa xwe dikin, lê me ji kar dihêlin!
Zêdetirî 9 sal pêşkeftina civak û metodolojiyê, jixwe diyar bû ku ev hîn jî ne birûskek kirrûbirrê ye, lê hîn jî bi tevahî ne diyar e ka çima hewce ye. Mîna her amûr û pêvajoyek, DevOps armancên taybetî hene ku ew di dawiyê de digihîje.
Ev hemû ji ber wê yekê ye ku cîhan diguhere. Ew ji nêzîkatiya pargîdaniyê dûr dikeve, dema ku pargîdan rasterast ber bi xewnekê ve diçin, wekî ku klasîka me ya St.
Di prensîbê de, divê her tişt di IT-ê de li gorî vê nêzîkbûnê were çêkirin. Li vir IT bi taybetî ji bo otomatîkkirina pêvajoyên tê bikar anîn.
Otomasyon pir caran nayê guheztin, ji ber ku dema ku pargîdaniyek berbi şikestinek baş ve diçe, çi heye ku were guheztin? Ew dixebite - dest nede. Naha nêzîkatiyên li cîhanê diguhezin, û ya bi navê Agile pêşniyar dike ku xala dawiya B tavilê nayê dîtin.
Gava ku pargîdaniyek di sûkê re derbas dibe, bi xerîdar re dixebite, ew bi berdewamî li bazarê digere û xala dawiya B diguhezîne. Wekî din, her ku pir caran pargîdanî rêça xwe diguhezîne, ew di dawiyê de ew qas serfiraztir e, ji ber ku ew bêtir bazarê hildibijêre. niches.
Stratejî ji hêla pargîdaniyek balkêş ve ku ez vê dawiyê fêr bûm ve hatî destnîşan kirin. One Box Shave karûbarek radestkirina abonetiyê ye ji bo razber û aksesûarên tirşkirinê yên di qutikê de. Ew dizanin ka meriv çawa "qutiya" xwe ji bo xerîdarên cihêreng xweş bike. Ev ji hêla hin nermalavê ve tête kirin, ku dûv re fermanê dişîne kargeha Koreyî ya ku hilberê çêdike.
Ev berhem ji aliyê Unilever ve bi 1 milyar dolarî hatiye kirîn. Naha ew bi Gillette re pêşbaziyê dike û di sûka Amerîkî de beşek girîng ji xerîdaran derxistiye. Yek Box Shave dibêje:
- 4 berik? Tu cidî yî? Çima hûn vê yekê hewce ne - ew kalîteya şûştinê çêtir nake. Krem, bîhnxweşek taybetî bijartî û çîpek jêhatî ya bi du lûleyan ji wan 4 tîrên Gillette yên ehmeq pir zêdetir pirsgirêkan çareser dike! Ma em ê di demek nêzîk de bigihîjin 10?
Bi vî awayî dinya diguhere. Unilever îdîa dike ku wan pergalek IT-ya xweş heye ku destûrê dide we ku hûn wiya bikin. Di dawiyê de ew wekî têgehek xuya dike Dem-bazarê, ku jixwe kesî behsa wê nekiriye.
Xala Dem-bazarê ne ew e ku em çend caran bi cih dikin. Hûn dikarin pir caran bicîh bikin, lê çerxên berdanê dê dirêj bin. Ger çerxên serbestberdana sê-mehî li ser hev werin danîn, wan bi hefteyekê veguhezînin, derdikeve holê ku pargîdanî dixuye ku heftê carekê dişoxilîne. Û ji ramanê heta pêkanîna dawîn 3 meh derbas dibe.
Dem-to-bazar li ser kêmkirina dema ji ramanê heya pêkanîna dawîn e.
Di vê rewşê de, nermalavê bi bazarê re têkilî dike. Bi vî rengî malpera One Box Shave bi xerîdar re têkilî dike. Firoşkarên wan nînin - tenê malperek ku mêvan lê bikirtînin û xwestekên xwe bihêlin. Li gorî vê yekê, pêdivî ye ku tiştek nû bi domdarî li ser malperê were şandin û li gorî xwestekan were nûve kirin. Mînakî, li Koreya Başûr ew ji ya Rûsyayê cûdatir dişoxilînin, û ew ji bêhnê ne ji çamê, lê, mînakî, ji gêzer û vanilla hez dikin.
Ji ber ku pêdivî ye ku meriv zû naveroka malperê biguhezîne, pêşkeftina nermalavê pir diguhere. Bi navgîniya nermalavê divê em fêr bibin ka xerîdar çi dixwaze. Berê, em vê yekê bi hin awayên dorpêçê fêr bûn, mînakî, bi rêveberiya karsaziyê. Dûv re me ew sêwirand, hewcedariyên pergala IT-ê danîn, û her tişt xweş bû. Naha ew cûda ye - nermalava ji hêla her kesê ku beşdarî pêvajoyê ye, tevî endezyaran, tê sêwirandin, ji ber ku bi taybetmendiyên teknîkî ew fêr dibin ka bazar çawa dixebite û di heman demê de têgihiştinên xwe bi karsaziyê re jî parve dikin.
Mînakî, li Qik em ji nişkê ve fêr bûn ku mirov bi rastî ji barkirina navnîşên pêwendiyê li serverê hez dikin, û wan serîlêdanek ji me re peyda kirin. Destpêkê em li ser nefikirîn. Di pargîdaniyek klasîk de, dê her kesî biryar da ku ev xeletiyek e, ji ber ku taybetmendiyê negot ku divê ew pir baş bixebite û bi gelemperî li ser çokê hate bicîh kirin, wan ê taybetmendiyê qut bikira û got: "Ne hewcedarê vê yekê ye, ya herî girîng ev e ku fonksiyona sereke dixebite. Û şîrketa teknolojiyê vê yekê wekî firsendekê dibîne û li gorî vê dest bi guhertina nermalavê dike.
Di sala 1968 de, zilamek dîtbar, Melvin Conway, ramana jêrîn formule kir.
Rêxistina ku pergalê diafirîne ji hêla sêwiranek ku strukturên ragihandinê yên wê rêxistinê dubare dike ve tê asteng kirin.
Bi hûrgulî, ji bo ku hûn pergalên celebek cûda hilberînin, divê hûn di nav pargîdaniyek celebek cûda de jî avahiyek ragihandinê hebe. Ger avahiya weya ragihandinê top-hiyerarşîk e, wê hingê ev ê nehêle hûn pergalên ku dikarin nîşanek Dem-to-Marketê pir bilind peyda bikin biafirînin.
Xwendin dikare . Ji bo têgihîştina çand an felsefeya DevOps girîng e ji ber ku tenê tiştê ku bi bingehîn di DevOps de diguhezîne avahiya danûstendina di navbera tîmê de ye.
Ji hêla pêvajoyê ve, berî DevOps, hemî qonax: analîtîk, pêşkeftin, ceribandin, xebitandin, rêzik bûn.
Di doza DevOps de, ev hemî pêvajo bi hevdemî diqewimin.
Dem-bazarê yekane awayê ku dikare were kirin e. Ji bo mirovên ku di pêvajoya kevin de xebitîn, ev hinekî kozmîk xuya dike, û bi gelemperî wusa ye.
Ji ber vê yekê çima hûn hewceyê DevOps in?
Ji bo pêşveçûna hilberê dîjîtal. Ger pargîdaniya we hilberek dîjîtal tune, DevOps ne hewce ye - ew pir girîng e.
DevOps tixûbên leza hilberîna nermalava rêzdar derbas dike. Di wê de hemû pêvajo bi hev re diqewimin.
Zehmetî zêde dibe. Gava ku mizgînvanên DevOps ji we re dibêjin ku ew ê ji we re hêsantir bike ku hûn nermalavê berdin, ev bêaqil e.
Bi DevOps re, tişt dê tenê tevlihevtir bibin.
Di konferansa li standa Avito de, hûn dikarin bibînin ka sazkirina konteynerek Docker çawa ye - karekî nerealîst. Tevlihevî qedexe dibe; pêdivî ye ku hûn di heman demê de gelek topan bişopînin.
DevOps bi tevahî pêvajo û rêxistina di pargîdaniyê de diguhezîne - Bi rastî, ew ne DevOps e ku diguhezîne, lê hilbera dîjîtal e. Ji bo ku hûn werin DevOps, hûn hîn jî hewce ne ku vê pêvajoyê bi tevahî biguherînin.
Pirs ji bo pispor
Çi heye? Pirsên ku hûn dikarin ji xwe bipirsin dema ku di pargîdaniyek de dixebitin û wekî pispor pêşve diçin.
Ji bo afirandina hilberek dîjîtal stratejiyek we heye? Ger hebe, ew jixwe baş e. Ev tê vê wateyê ku pargîdaniya we ber bi DevOps ve diçe.
Ma pargîdaniya we jixwe hilberek dîjîtal diafirîne? Ev tê vê wateyê ku hûn dikarin astek din rakin û tiştan balkêştir bikin - dîsa ji nêrînek DevOps. Ez tenê ji vî alî ve dibêjim.
Pargîdaniya we yek ji serokên bazarê ye di warê hilberê dîjîtal de? Spotify, Yandex, Uber pargîdaniyên ku niha di lûtkeya pêşkeftina teknolojîk de ne.
Van pirsan ji xwe bipirsin, û heke hemî bersiv na bin, wê hingê dibe ku hûn li vê pargîdaniyê DevOps nekin. Ger mijara DevOps bi rastî ji we re balkêş be, dibe ku ... hûn biçin pargîdaniyek din? Ger pargîdaniya we bixwaze biçe nav DevOps, lê we bersiva hemî pirsan "Na" da, wê hingê ew mîna wî rinocerosê xweşik e ku dê çu carî neguheze.
rêxistina
Wekî ku min got, li gorî Qanûna Conway, rêxistina pargîdaniyek diguhere. Ez ê bi tiştê ku pêşî lê nagire ku DevOps ji hêla rêxistinî ve di hundurê pargîdaniyê de derbas bibe dest pê bikim.
Pirsgirêka "kaniyan"
Peyva Îngilîzî "Silo" li vir bi rûsî wekî "baş" tê wergerandin. Xala vê pirsgirêkê ew e di navbera tîman de pevguhertina agahiyan tune. Her tîm di pisporiya xwe de kûr dikole, bêyî ku nexşeyek hevpar ava bike ku rêve bibe.
Di hin awayan de ev kesek tê bîra min ku nû hatiye Moskowê û hîn nizane ku meriv çawa nexşeya metroyê rêve bibe. Muscovites bi gelemperî devera xwe pir baş dizanin, û li seranserê Moskowê ew dikarin bi karanîna nexşeya metroyê rêve bibin. Gava ku hûn cara yekem têne Moskowê, hûn ne xwediyê vê jêhatîbûnê ne, û hûn tenê bêaqil in.
DevOps pêşniyar dike ku di vê kêliya bêaqiliyê de derbas bibin û hemî beşan bi hev re bixebitin da ku nexşeyek danûstendinek hevpar ava bikin.
Du faktor vê yekê asteng dikin.
Encama pergala rêveberiya pargîdaniyê. Ew di "kaniyên" yên hiyerarşîk ên cihê de hatiye avakirin. Mînakî, di pargîdaniyên ku vê pergalê piştgirî dikin de hin KPI hene. Ji aliyê din ve, mejiyê kesekî ku zehmetiyê dikişîne derveyî sînorên pisporiya xwe û rê li tevahiya pergalê digire, rê li ber digire. Tenê nerehet e. Bifikirin ku hûn li balafirgeha Bangkok in - hûn ê zû riya xwe nebînin. Rêvekirina DevOps di heman demê de dijwar e, û ji ber vê yekê mirov dibêjin ku hûn hewce ne ku rêbernameyek bibînin da ku biçin wir.
Lê ya herî girîng ev e ku pirsgirêka "kaniyan" ji bo endezyarek ku bi ruhê DevOps ve girêdayî ye, Fowler û komek pirtûkên din xwendiye, di vê rastiyê de tête diyar kirin. "kanî" nahêlin hûn tiştên "eşkere" bikin. Em gelek caran piştî DevOps Moskowê li hev dicivin, bi hev re dipeyivin, û mirov gilî dikin:
- Me tenê dixwest ku CI-yê bidin destpêkirin, lê derket holê ku rêveberî ne hewce ye.
Ev bi rastî ji ber ku dibe CI и Pêvajoya Delivery Continuous li ser sînorê gelek muayeneyan in. Bi tenê bêyî ku di asta rêxistinî de pirsgirêka "kaniyan" derbas bike, hûn ê nikaribin pêşde biçin, hûn çi bikin û çi qas xemgîn be jî.
Her beşdarek di pêvajoyê de di pargîdaniyê de: pêşdebirên paşîn û pêşîn, ceribandin, DBA, operasyon, torê, di rêça xwe de dikole, û ji xeynî rêveberê ku bi rengekî wan dişopîne û wan bi karanîna "parçebûnê" bi rê ve dibe, nexşeyek hevpar tune. û bi ser bikeve” rêbaza.
Mirov ji bo hin stêrkan an alayan şer dikin, her kes pisporiya xwe dikole.
Di encamê de, dema ku peywira girêdana van hemûyan bi hev re û avakirina boriyek hevbeş were pêş, û êdî ne hewce ye ku ji bo stêrk û alayan şer bikin, ev pirs derdikeve holê - gelo çi bikin? Pêdivî ye ku em bi rengekî li hev bikin, lê tu kes me fêrî vê yekê li dibistanê nekir. Em ji dibistanê hîn bûne: pola heştan - wey! - li gorî pola heftan! Li vir jî wisa ye.
Ma di pargîdaniya we de heman tişt e?
Ji bo kontrolkirina vê, hûn dikarin pirsên jêrîn ji xwe bipirsin.
Ma tîm amûrên hevpar bikar tînin û beşdarî guhertinên wan amûrên hevpar dibin?
Tîm çend caran ji nû ve organîze dikin - hin pispor ji tîmek diçin tîmek din? Ew di hawîrdorek DevOps de ye ku ev normal dibe, ji ber ku carinan kesek bi hêsanî nikare fêm bike ka qada din a pisporiyê çi dike. Ew diçe nav dezgehek din, du hefte li wir dixebite ku ji xwe re nexşeyek rêgez û danûstendina bi vê beşê re çêbike.
Gelo pêkan e ku komîteyeke guherînê bê avakirin û tiştan biguherînin? An jî ew pêdivî bi destê bihêz a rêveberî û rêberiya herî bilind heye? Min herî dawî li ser Facebookê nivîsî ku bankek hindik-naskirî çawa bi fermanan amûran pêk tîne: em fermanekê dinivîsin, em salekê bicîh dikin, û bibînin ka çi dibe. Ev, bê guman, dirêj û xemgîn e.
Ji bo rêveberan çiqas girîng e ku destkeftiyên kesane bistînin bêyî ku destkeftiyên pargîdaniyê bifikirin?
Ger hûn ji bo xwe bersiva van pirsan bidin, dê zelaltir bibe ka we di pargîdaniya we de pirsgirêkek wusa heye.
Binesaziya wekî kodê
Piştî ku ev pirsgirêk derbas bû, yekem pratîka girîng, bêyî ku dijwar e ku di DevOps-ê de pêşdetir biçe, ev e binesaziya wek kod.
Bi gelemperî, binesaziya wekî kodê wekî jêrîn tê fêm kirin:
- Werin em her tiştî di bash de otomat bikin, xwe bi senaryoyan veşêrin da ku rêvebiran kêm karê destan bin!
Lê ev ne rast e.
Binesaziya wekî kod tê vê wateyê ku hûn pergala IT-ya ku hûn pê re dixebitin di forma kodê de diyar dikin da ku hûn bi domdarî rewşa wê fam bikin.
Bi tîmên din re, hûn nexşeyek di forma kodê de diafirînin ku her kes dikare fêm bike û dikare rêve bike û rêve bibe. Ne girîng e ku ew li ser çi hatî kirin - Chef, Ansible, Salt, an karanîna pelên YAML li Kubernetes - cûdahî tune.
Di konferansê de, hevkarek ji 2GIS re got ku wan çawa tiştê xweya hundurîn ji bo Kubernetes çêkir, ku strukturên pergalên kesane vedibêje. Ji bo danasîna 500 pergalan, ji wan re amûrek cûda hewce bû ku vê ravekirinê çêbike. Dema ku ev danasîn hebe, her kes dikare bi hevûdu re kontrol bike, guheztinan bişopîne, meriv wê çawa biguhezîne û baştir bike, çi winda ye.
Bipejirînim, nivîsarên bash yên kesane bi gelemperî vê têgihiştinê peyda nakin. Li yek ji pargîdaniyên ku ez lê dixebitim, navek ji bo senaryoyê "tenê binivîse" jî hebû - dema ku senaryo tê nivîsandin, lê êdî xwendina wê ne gengaz e. Ez difikirim ku ev ji we re jî nas e.
Binesaziya wekî kodê ye koda ku rewşa heyî ya binesaziyê diyar dike. Gelek hilber, binesaz û tîmên karûbarê li ser vê kodê bi hev re dixebitin, û ya herî girîng, ew hemî hewce ne ku fêm bikin ka ev kod bi rastî çawa dixebite.
Kod li gorî pratîkên kodê yên çêtirîn têne parastin: Pêşkeftina hevbeş, vekolîna kodê, bernamekirina XP, ceribandin, daxwazên kişandinê, CI ji bo binesaziyên kodê - ev hemî guncan e û dikare were bikar anîn.
Kod ji bo hemî endezyaran dibe zimanek hevpar.
Guhertina binesaziya kodê pir dem nagire. Erê, koda binesaziyê dikare deynê teknîkî jî hebe. Bi gelemperî tîm salek û nîv piştî ku wan dest bi pêkanîna "binesaziyê wekî kod" di forma komek nivîsan an jî Ansible de, ku ew wekî koda spaghetti dinivîsin, rûbirû dibin, û ew jî nivîsên bash di nav tevliheviyê de diavêjin!
giring: Ger we hîn ev tişt neceribandiye, bîr bînin Ansible ne bash e! Belgeyên bi baldarî bixwînin, bixwînin ku ew li ser wê çi dinivîsin.
Binesaziya wekî kod veqetandina koda binesaziyê li qatên cihê ye.
Di pargîdaniya me de, em 3 qatên bingehîn, ku pir zelal û sade ne, ji hev vediqetînin, lê dibe ku ji wan zêdetir hebin. Hûn dikarin li koda binesaziya xwe binêrin û bibêjin ka we ev rewş heye an na. Ger tu qat neyên ronî kirin, wê hingê hûn hewce ne ku hinekî dem bavêjin û piçek nûve bikin.
tebeqeya bingehîn - Bi vî rengî OS, paşvekêşan û tiştên din ên nizm têne mîheng kirin, mînakî, Kubernetes çawa di asta bingehîn de tête bicîh kirin.
Asta xizmetê - ev karûbarên ku hûn ji pêşdebir re peyda dikin: têketin wekî karûbar, çavdêrîkirin wekî karûbar, databas wekî karûbar, hevseng wekî karûbar, dorê wekî karûbar, Radestkirina Berdewam wekî karûbar - komek karûbarên ku tîmên kesane dikare pêşveçûnê pêşkêşî bike. Pêdivî ye ku ev hemî di modulên cihêreng de di pergala rêveberiya weya vesazkirinê de were vegotin.
Tebeqeya ku serîlêdan lê têne çêkirin û diyar dike ka ew ê çawa li ser her du qatên berê derbikevin.
Pirsên kontrolê
Ma pargîdaniya we depoyek binesaziya hevpar heye? Ma hûn di binesaziya xwe de deynê teknîkî birêve dibin? Ma hûn pratîkên pêşkeftinê di depoyek binesaziyê de bikar tînin? Ma binesaziya we di qatan de tê perçe kirin? Hûn dikarin diyagrama Base-service-APP kontrol bikin. Çiqas zehmet e ku guhertinek çêbikin?
Ger we ezmûn kir ku ji bo guherandinan rojek û nîv girt, ev tê vê wateyê ku we deynek teknîkî heye û pêdivî ye ku hûn pê re bixebitin. Hûn tenê di koda binesaziya xwe de li ser rakêşek deynek teknîkî ketin. Gelek çîrokên weha têne bîra min gava ku, ji bo ku hûn hin CCTL biguhezînin, hûn hewce ne ku nîvê koda binesaziyê ji nû ve binivîsin, ji ber ku afirîner û xwesteka otomatîkkirina her tiştî rê li ber vê yekê vekir ku her tişt li her deverê gemarî ye, hemî destok hatine rakirin, û pêdivî ye ku ji nû ve were çêkirin.
Delivery Berdewam
Ka em debîtê bi krediyê re bidin ber hev. Pêşî şiroveyek binesaziyê tê, ku dikare pir bingehîn be. Ne hewce ye ku hûn her tiştî bi hûrgulî rave bikin, lê hin ravekirina bingehîn hewce ye ku hûn pê re bixebitin. Wekî din, ne diyar e ku dê bi radestkirina domdar re çi bike. Dema ku hûn werin DevOps van pratîkan bi hevdemî vedibin, lê ew bi têgihiştina tiştê ku we heye û meriv wê çawa birêve dibe dest pê dike. Ev bi rastî pratîka binesaziyê wekî kod e.
Gava ku eşkere dibe ku we ew heye û meriv wê çawa birêve dibe, hûn dest pê dikin ka meriv çawa koda pêşdebiran bi lez û bez bişîne hilberînê. Yanî ez bi pêşdebir re bi hev re - em pirsgirêka "kaniyan" bi bîr tînin, ango, ne mirovên ferdî ne ku vê yekê derdixin, lê tîmek.
Dema ku em bi hev re ne Vanya Evtukhovîç pirtûka yekem dît Jez Humble û komên nivîskaran "Radestkirina Berdewam", ku di sala 2009-an de derket, em demek dirêj fikirîn ka meriv çawa sernavê wê wergerîne rûsî. Wan dixwest ku wê wergerînin wekî "Constantly radest", lê, mixabin, ew wekî "Radestkirina Berdewam" hate wergerandin. Bi dîtina min tiştekî rûsî di navê me de heye, bi zextan.
Berdewam pêşkêşkirina wateyan
Koda ku di depoya hilberê de ye her gav dikare ji bo hilberînê were dakêşandin. Dibe ku ew neteqandin, lê ew her gav ji bo wê amade ye. Li gorî vê yekê, hûn her gav kodê bi hestek dijwar a ravekirina hin fikaran di binê dûvê xwe de dinivîsin. Dema ku hûn koda binesaziyê derdixin pir caran xuya dibe. Divê ev hesta hin fikaran hebe - ew pêvajoyên mêjî dide destpêkirin ku dihêle hûn kodê hinekî cûda binivîsin. Divê ev di qaîdeyên di nav pêşveçûnê de bêne tomar kirin.
Ji bo ku hûn bi domdarî radest bikin, hûn hewceyê formatek hunerî ya ku li ser platformek binesaziyê derbas dibe. Ger hûn "bermayiyên jiyanê" yên formên cihêreng li ser platformek binesaziyê bavêjin, wê hingê ew yek dibe, domandina wê dijwar e, û pirsgirêka deynê teknîkî derdikeve holê. Pêdivî ye ku forma hunerê were hevrêz kirin - ev jî peywirek kolektîf e: pêdivî ye ku em hemî li hev bicivin, mêjiyê xwe bişewitînin û bi vê formatê rabin.
Dema ku ew di nav lûleya radestkirinê de dimeşe, huner bi domdarî tê baştir kirin û li gorî hawîrdora hilberînê tê guhertin. Dema ku hunerek li ser boriyê dimeşe, ew bi berdewamî ji bo wê bi hin tiştên nerehet re rû bi rû dimîne, yên ku dişibihe tiştên ku hûn di hilberînê de dihêlin. Ger di pêşkeftina klasîk de ev yek ji hêla rêveberek pergalê ve ku pêvekê dike pêk tê, wê hingê di pêvajoya DevOps de ev her dem diqewime: li vir wan ew bi hin ceribandinan ceriband, li vir ew avêtin nav komek Kubernetes, ku kêm-zêde dişibihe. ji bo hilberînê, paşê ji nişkê ve wan dest bi ceribandina barkirinê kirin.
Ev hinekî tîne bîra lîstika Pac-Man - huner di nav cûreyek çîrokê de derbas dibe. Di heman demê de, girîng e ku hûn kontrol bikin ka kod bi rastî di çîrokê de derbas dibe û gelo ew bi rengek bi hilberîna we re têkildar e. Çîrokên ji hilberînê dikarin werin kişandin nav Pêvajoya Radestkirina Berdewam: gava ku tiştek ket wusa bû, naha em tenê vê senaryoyê di hundurê pergalê de bername bikin. Her carê ku kod dê vê senaryoyê jî derbas bike, û hûn ê carek din bi vê pirsgirêkê re rûbirû nebin. Hûn ê li ser wê pir zûtir fêr bibin ku ew digihîje muwekîlê we.
Stratejiyên dabeşkirina cihêreng. Mînakî, hûn ceribandina AB-ê an bicîhkirina kanariyê bikar tînin da ku kodê bi rengek cûda li ser xerîdarên cûda ceribînin, agahdarî li ser ka kod çawa dixebite, û pir zûtir ji dema ku ew ji 100 mîlyon bikarhêneran re tê şandin.
"Bi domdarî radest bikin" bi vî rengî xuya dike.
Pêvajoya radestkirinê Dev, CI, Test, PreProd, Prod ne hawîrdorek veqetandî ye, ev qonax an qereqolên bi dravê agirgir in ku hunera we tê de derbas dibe.
Ger koda binesaziya we heye ku wekî APP Karûbarê Bingehê tê binav kirin wê hingê ew dibe alîkar hemû senaryoyan ji bîr nekin, û wan wekî koda vê hunerê binivîsin, artifact pêşve bibin û gava ku hûn diçin wê biguherînin.
Pirsên xwe-ceribandinê
Dem ji danasîna taybetmendiyê heya berdana hilberînê di 95% bûyeran de ji hefteyek kêmtir e? Ma di her qonaxa boriyê de kalîteya hunerê baştir dibe? Çîrokek ku tê de derbas dibe heye? Ma hûn stratejiyên cihêreng bicîhkirinê bikar tînin?
Ger hemî bersiv erê bin, wê hingê hûn pir xweş in! Bersivên xwe di şîroveyan de binivîsin - ez ê kêfxweş bim).
Bikin
Ev ji hemûyan pratîka herî dijwar e. Di konferansa DevOpsConf de, hevkarek ji Infobip, ku li ser wê diaxivî, di gotinên xwe de hinekî tevlihev bû, ji ber ku ev bi rastî pratîkek pir tevlihev e di derbarê vê yekê de ku hûn hewce ne ku her tiştî bişopînin!
Mînakî, demek dirêj berê, dema ku ez li Qik dixebitim û me fêm kir ku pêdivî ye ku em her tiştî bişopînin. Me ev kir, û niha 150 tiştên me li Zabbix hene, ku bi berdewamî têne şopandin. Ew tirs bû, derhênerê teknîkî tiliya xwe li perestgeha xwe zivirî:
- Gelî hevalno, hûn çima bi tiştekî nezelal tecawizê serverê dikin?
Lê paşê bûyerek qewimî ku nîşan da ku ev bi rastî stratejiyek pir xweş e.
Yek ji karûbaran bi berdewamî dest pê kir. Di destpêkê de, ew têk neçû, ya ku balkêş e, kod li wir nehat zêdekirin, ji ber ku ew brokerek bingehîn bû, ku di pratîkê de fonksiyonek karsaziyê tune bû - ew tenê di navbera karûbarên kesane de peyam şand. Karûbar 4 mehan neguherî, û ji nişkê ve ew bi xeletiya "qesûra dabeşkirinê" dest pê kir.
Em şok bûn, nexşeyên xwe li Zabbix vekirin, û derket holê ku hefteyek û nîv berê, tevgera daxwazên di karûbarê API-ê de ku ev broker bikar tîne pir guherî. Dûv re me dît ku frekansa şandina celebek peyamek guherî. Dûv re me fêhm kir ku ev xerîdarên android bûn. Me pirsî:
- Gelî hevalno, hefteyek û nîv berê çi hat serê we?
Di bersivê de, me çîrokek balkêş bihîst ku wan çawa UI ji nû ve dîzayn kir. Ne mimkûn e ku kes tavilê bêje ku wan pirtûkxaneya HTTP guhertiye. Ji bo xerîdarên Android-ê, ew mîna guheztina sabûnê di serşokê de ye - ew tenê ji bîr nakin. Di encamê de, piştî 40 hûrdeman axaftinê, me fêr kir ku wan pirtûkxaneya HTTP guhertiye, û demên wê yên xwerû hatine guhertin. Ev bû sedema guheztina tevgera seyrûsefera li ser servera API-yê, ku bû sedema rewşek ku di hundurê brokerê de bû sedema pêşbaziyek, û ew dest pê kir.
Bê çavdêriya kûr bi gelemperî vekirina vê yekê ne gengaz e. Ger rêxistin hîna pirsgirêka "kaniyan" hebe, dema ku her kes pereyan davêje hev, ev dikare bi salan bijî. Hûn bi tenê serverê ji nû ve bidin destpêkirin ji ber ku ne gengaz e ku pirsgirêk çareser bibe. Gava ku hûn hemî bûyerên ku we hene dişopînin, dişopînin, dişopînin, û çavdêriyê wekî ceribandinê bikar tînin - kodê binivîsin û tavilê destnîşan bikin ka meriv çawa çavdêriya wê dike, di heman demê de di forma kodê de (jixwe binesaziya me wekî kod heye), her tişt eşkere dibe ku çawa li ser palmê. Pirsgirêkên weha tevlihev jî bi hêsanî têne şopandin.
Hemî agahdarî li ser tiştên ku di her qonaxa pêvajoya radestkirinê de diqewime de - ne di hilberînê de, berhev bikin.
Çavdêriyê li CI barkirin, û hin tiştên bingehîn dê jixwe li wir xuya bibin. Dûv re hûn ê wan di Test, PredProd, û ceribandina barkirinê de bibînin. Di hemî qonaxan de agahdarî berhev bikin, ne tenê metrîk, statîstîk, lê di heman demê de têketin: ka serîlêdan çawa derket, anomalî - her tiştî berhev bikin.
Wekî din ew ê dijwar be ku meriv wê fêm bike. Min berê jî got ku DevOps tevlihevtir e. Ji bo ku hûn bi vê tevliheviyê re mijûl bibin, hûn hewce ne ku analîzek normal hebe.
Pirsên ji bo xwe-kontrolê
Ma çavdêrîkirin û tomarkirina we ji bo we amûra pêşkeftinê ye? Dema ku kodê dinivîsin, pêşdebirên we, tevî we, difikirin ka meriv çawa wê çavdêrî bike?
Ma hûn li ser pirsgirêkan ji xerîdaran dibihîzin? Ma hûn xerîdar ji şopandin û têketinê çêtir fam dikin? Ma hûn pergalê ji şopandin û têketinê çêtir fam dikin? Ma hûn pergalê tenê diguherînin ji ber ku we dît ku meyla di pergalê de mezin dibe û hûn fêm dikin ku di 3 hefteyên din de dê her tişt bimire?
Gava ku we van sê hêmanan hebe, hûn dikarin bifikirin ka hûn di pargîdaniya we de çi celeb platformek binesaziyê heye.
Platforma binesaziyê
Mesele ne ew e ku ew komek amûrên cihêreng ên ku her pargîdanî hene.
Mebesta platformek binesaziyê ew e ku hemî tîm van amûran bikar bînin û bi hev re pêş bixin.
Eşkere ye ku tîmên cihê hene ku ji pêşkeftina perçeyên kesane yên platforma binesaziyê berpirsiyar in. Lê di heman demê de, her endezyar berpirsiyariya pêşkeftin, performans û pêşvebirina platforma binesaziyê digire. Di asta navxweyî de ew dibe amûrek hevpar.
Hemî tîm platforma binesaziyê pêşve dixin û wê bi baldarî wekî IDE-ya xwe derman dikin. Di IDE-ya xwe de hûn pêvekên cihêreng saz dikin da ku her tiştî xweş û bilez bikin, û bişkojkên germî mîheng bikin. Dema ku hûn Sublime, Atom an Visual Studio Code vedikin, xeletiyên kodê diherikin û hûn pê dihesin ku ne gengaz e ku meriv bi tevahî bixebite, hûn tavilê xemgîn dibin û hûn direvin ku IDE-ya xwe rast bikin.
Bi heman rengî platforma binesaziya xwe derman bikin. Ger hûn fêm bikin ku tiştek di wê de heye, heke hûn nikaribin wê bi xwe rast bikin daxwazek bihêlin. Ger tiştek hêsan hebe, wê bi xwe biguherînin, daxwazek kişandinê bişînin, dê xort wê bifikirin û lê zêde bikin. Ev di serê pêşdebiran de ji amûrên endezyariyê re nêzîkatiyek hinekî cûda ye.
Platforma binesaziyê veguheztina hunerê ji pêşkeftinê ji xerîdar re bi başkirina domdar a kalîteyê re misoger dike. IP bi komek çîrokên ku di hilberînê de bi kodê re diqewimin bernamekirî ye. Di salên pêşkeftinê de, gelek ji van çîrokan hene, hin ji wan yekta ne û tenê bi we re têkildar in - ew nikarin werin Google kirin.
Di vê nuqteyê de, platforma binesaziyê dibe berjewendiya weya pêşbaziyê, ji ber ku tiştek di nav xwe de çêkiriye ku ne di amûra hevrikê de ye. IP-ya we ya kûrtir, di warê Demjimêr-bazarê de berjewendiya weya pêşbaziyê mezintir dibe. Li vir xuya dike pirsgirêka lock vendor: Hûn dikarin platforma kesek din bigirin, lê ezmûna kesek din bikar bînin, hûn ê fam nekin ka ew çiqas bi we re têkildar e. Erê, ne her pargîdanî dikare platformek mîna Amazon ava bike. Ev xetek dijwar e ku ezmûna pargîdaniyê bi pozîsyona wê ya li sûkê re têkildar e, û hûn nekarin li wir qeflek firoşkar bikar bînin. Ev jî girîng e ku li ser bifikirin.
Scheme
Ev diagramek bingehîn a platformek binesaziyê ye ku dê ji we re bibe alîkar ku hûn hemî pratîk û pêvajoyên di pargîdaniyek DevOps de saz bikin.
Ka em binêrin ka ew ji çi pêk tê.
Sîstema orkestrasyona çavkaniyê, ku CPU, bîranîn, dîsk ji serîlêdan û karûbarên din re peyda dike. Li ser vê - xizmetên asta nizm: şopandin, têketin, motora CI/CD, hilanîna hunerê, binesaziya wekî koda pergalê.
Xizmetên asta bilind: databas wekî karûbar, rêzên wekî karûbar, Balansa barkirinê wekî karûbar, mezinbûna wêneyê wekî karûbar, kargeha Daneyên Mezin wekî karûbar. Li ser vê - lûleya ku koda ku bi domdarî hatî guheztin ji muwekîlê we re peyda dike.
Hûn agahdarî distînin ka nermalava we ji bo xerîdar çawa dixebite, wê diguhezînin, vê kodê dîsa peyda dikin, agahdarî distînin - û ji ber vê yekê hûn hem platforma binesaziyê û hem jî nermalava xwe bi domdarî pêşdixin.
Di diagramê de, lûleya radestkirinê ji gelek qonaxan pêk tê. Lê ev diagramek şematîkî ye ku wekî mînak tê dayîn - ne hewce ye ku yek bi yek dubare bike. Qonax bi karûbaran re mîna ku ew karûbar in re têkilî daynin - her kulmek platformê çîroka xwe hildigire: çavkanî çawa têne veqetandin, serîlêdan çawa tê destpêkirin, bi çavkaniyan re dixebite, tê şopandin û diguhezîne.
Girîng e ku meriv fam bike ku her perçeyek platformê çîrokek hildigire, û ji xwe bipirsin ka ev kerpîç çi çîrok hildigire, dibe ku ew were avêtin û bi karûbarek sêyemîn-sêyem were guheztin. Mînakî, ma gengaz e ku li şûna kerpîçek Okmeter were saz kirin? Dibe ku xortan berê vê pisporiyê ji me pirtir pêş xistine. Lê dibe ku ne - dibe ku pisporiya me ya bêhempa hebe, pêdivî ye ku em Prometheus saz bikin û wê bêtir pêşve bibin.
Afirandina platformê
Ev pêvajoyek pêwendiya tevlihev e. Gava ku hûn pratîkên bingehîn hebin, hûn di navbera endezyar û pisporên cihêreng ên ku hewcedarî û standardan pêşdixin de dest bi danûstandinê dikin, û bi domdarî wan diguhezînin amûr û nêzîkatiyên cihê. Çanda ku me di DevOps de heye li vir girîng e.
Bi çandê re her tişt pir hêsan e - ew li ser hevkarî û danûstandinê ye, ango xwestina ku di qadeke hevpar de bi hev re bixebitin, xwestina ku bi hev re amûrekê bi dest bixin. Li vir zanistiya rokêtê tune - her tişt pir hêsan, banal e. Mînakî, em hemî di dergehê de dijîn û wê paqij diparêzin - astek weha çand.
Çi heye?
Dîsa, pirsên ku hûn dikarin ji xwe bipirsin.
Ma platforma binesaziyê veqetandî ye? Kî ji pêşveçûna wê berpirsiyar e? Ma hûn feydeyên pêşbaziyê yên platforma binesaziya xwe fam dikin?
Pêdivî ye ku hûn bi berdewamî van pirsan ji xwe bipirsin. Ger tiştek dikare ji karûbarên sêyemîn re were veguheztin, divê ew were veguheztin; heke karûbarek sêyemîn dest bi astengkirina tevgera we bike, wê hingê hûn hewce ne ku di hundurê xwe de pergalek ava bikin.
Ji ber vê yekê, DevOps ...
... ev pergalek tevlihev e, divê ev hebe:
- Hilbera dîjîtal.
- Modulên karsaziyê ku vê hilbera dîjîtal pêşve dibin.
- Tîmên hilberê ku kodê dinivîsin.
- Pratîkên Delivery Continuous.
- Platformên wekî xizmetê.
- Binesaziya wekî xizmetê.
- Binesaziya wekî kodê.
- Pratîkên veqetandî yên ji bo domandina pêbaweriyê, ku di DevOps de hatine çêkirin.
- Pratîkek bertekek ku her tiştî vedibêje.
Hûn dikarin vê diagramê bikar bînin, tê de tiştê ku we berê di pargîdaniya xwe de bi rengekî heye ronî bike: ew pêşkeftî ye an hîn jî pêdivî ye ku were pêşve xistin.
Dê di nav du hefteyan de biqede . wekî beşek ji RIT ++. Werin konferansê, ku hûn ê di derheqê radestkirina domdar, binesaziya wekî kod û veguherîna DevOps de gelek raporên xweş bibînin. , dema dawî ya bihayê 20ê Gulanê ye
Source: www.habr.com