Heya nuha, ev hema hema pozîsyona herî biha ya li sûkê ye. Kêşeya li dora endezyarên "DevOps" ji hemî sînorên xeyalî wêdetir e, û bi endezyarên DevOps-ê yên payebilind re jî xirabtir e.
Ez wekî serokê beşa entegrasyon û otomasyonê dixebitim, dekodkirina Englishngilîzî texmîn dikim - Rêvebirê DevOps. Ne mimkûn e ku transkrîpta Îngilîzî çalakiyên me yên rojane nîşan bide, lê guhertoya rûsî di vê rewşê de rasttir e. Ji ber cewherê çalakiya min, xwezayî ye ku ez hewce bikim ku bi endamên pêşerojê yên tîmê xwe re hevpeyivîn bikim, û di sala borî de, nêzîkî 50 kes ji min re derbas bûne, û heman hejmar li pêş-ekranê bi karmendên min re hatine qut kirin.
Em hîn jî li hevkaran digerin, ji ber ku li pişt etîketa DevOps qateyek pir mezin a endezyarên cihêreng veşartiye.
Her tiştê ku li jêr hatî nivîsandin nerîna min a kesane ye, ne hewce ye ku hûn pê razî bibin, lê ez qebûl dikim ku ew ê hinekî reng li helwesta we ya mijarê zêde bike. Digel ku xetera ji destketinê heye jî, ez nêrîna xwe diweşînim ji ber ku ez bawer dikim ku cîhek wê heye.
Pargîdanî xwedan têgihiştinên cihêreng in ku endezyarên DevOps kî ne û, ji bo ku zû çavkaniyek peyda bikin, ew vê etîketê li her kesî daliqînin. Rewş pir xerîb e, ji ber ku pargîdan amade ne ku berdêlên nerealîst bidin van kesan, di pir rewşan de, ji bo wan rêveberek amûrek werdigirin.
Ji ber vê yekê endezyarên DevOps kî ne?
Ka em bi dîroka xuyangiya wê dest pê bikin - Operasyonên Pêşveçûnê wekî gavek din a berbi xweşbînkirina danûstendinê di tîmên piçûk de xuya bû da ku leza hilberîna hilberê zêde bike, wekî encamek çaverê. Fikir ew bû ku tîmê pêşkeftinê bi zanîna prosedurek û nêzîkatiyên di rêvebirina hawîrdora hilberê de xurt bikin. Bi gotinek din, pêşdebir divê fam bike û bizanibe ku hilbera wî di hin mercan de çawa dixebite, divê fam bike ka meriv çawa hilbera xwe bi cih dike, kîjan taybetmendiyên hawîrdorê dikare were sererast kirin da ku performansê baştir bike. Ji ber vê yekê, ji bo demekê, pêşdebiran bi nêzîkatiyek DevOps xuya bûn. Pêşdebirên DevOps ji bo hêsankirina çalakiyên xwe û performansa hawîrdora hilberînê skrîptên çêkirin û pakkirinê nivîsandin. Lêbelê, tevliheviya mîmariya çareseriyê û bandora hevdu ya hêmanên binesaziyê bi demê re dest pê kir ku performansa hawîrdoran xirab bike; bi her dubarekirinê re, têgihîştinek kûrtir a hin hêmanan hewce bû, ku ji ber zêdebûna hilberîneriya pêşdebir kêm dike. lêçûnên têgihiştina pêkhateyan û pergalên birêkûpêk ji bo karek taybetî. . Lêçûna xwe ya pêşdebir mezin bû, lêçûna hilberê digel wê, hewcedariyên ji bo pêşdebirên nû yên di tîmê de bi tundî rabûn, ji ber ku wan jî hewce bû ku berpirsiyariyên pêşveçûna "stêrk" bigire û, bi xwezayî, "stêrk" kêm bûn. û kêm peyda dibe. Di heman demê de hêjayî gotinê ye ku, li gorî ezmûna min, hindik pêşdebiran bi taybetmendiya hilberandina pakêtê ji hêla kernelê pergala xebitandinê, qaîdeyên rêça pakêtê, û aliyên ewlehiya mêvandar ve eleqedar dibin. Pêngava mentiqî kişandina rêveberek ku bi vê yekê nas e û peywirên wekhev jê re destnîşan kir, ku, bi saya ezmûna wî, gengaz kir ku meriv heman nîşanan bi lêçûnek kêmtir li gorî lêçûna pêşkeftinek "stêrk" bi dest bixe. Rêvebirên weha di tîmekê de hatin bi cih kirin û peywira wî ya sereke birêvebirina hawîrdorên ceribandin û hilberînê bû, li gorî rêgezên tîmek taybetî, bi çavkaniyên ku ji vê tîmê taybetî re hatine veqetandin. Bi vî rengî, bi rastî, DevOps di hişê piran de xuya bû.
Qismî an bi tevahî, bi demê re, van rêveberên pergalê dest pê kirin ku hewcedariyên vê tîmê taybetî di warê pêşkeftinê de fam bikin, ka meriv çawa jiyanê ji pêşdebir û ceribandinan re hêsantir dike, meriv çawa nûvekirinek derdixe û neçar dimîne ku şevekê li nivîsgehê bimîne. roja Îniyê, rastkirina çewtiyên bicihkirinê. Dem derbas bû, û naha "stêrk" rêveberên pergalê bûn ku fêm kirin ka pêşdebiran çi dixwazin. Ji bo kêmkirina bandorê, karûbarên rêveberiyê dest pê kir; her kes rêbazên kevn û pêbawer ên veqetandina asta OS-ê bi bîr anî, ku ev gengaz kir ku hewcedariyên ji bo ewlehiyê, rêveberiya beşa torê, û veavakirina mêvandar wekî amûrek kêm bike. tevahî û, wekî encamek, hewcedariyên ji bo "stêrkên" nû kêm bike.
Tiştek "ecêb" xuya bû - docker. Çima ecêb? Erê, tenê ji ber ku afirandina îzolasyonê li chroot an girtîgehek, û her weha OpenVZ, hewceyê zanîna OS-yê ne-tewre bû, berevajî vê, karûbar dihêle hûn bi tenê jîngehek serîlêdanê ya veqetandî li ser mêvandarek diyar bi her tiştê ku di hundur û dest de hewce dike biafirînin. dîsa li ser lingên pêşkeftinê, û rêvebirê pergalê tenê dikare bi yek mêvandar re rêve bibe, ewlekarî û hebûna wê ya bilind misoger bike - sadebûnek mentiqî. Lê pêşkeftin namîne û pergal dîsa her ku diçe tevlihevtir dibin, her ku diçe bêtir pêkhate hene, yek host êdî hewcedariyên pergalê nabîne û pêdivî bi avakirina koman heye, em dîsa vedigerin ser rêvebirên pergalê ku dikarin van sîsteman ava bikin.
Demjimêr piştî dewreyê, pergalên cihêreng xuya dikin ku pêşkeftin û / an rêveberiyê hêsan dikin, pergalên orkestrasyonê xuya dikin, ku heya ku hûn hewce ne ku ji pêvajoya standard dûr bikevin, karanîna wan hêsan in. Mîmariya Microservice jî bi mebesta hêsankirina her tiştê ku li jor hatî destnîşan kirin xuya bû - têkiliyên hindiktir, birêvebirina hêsantir. Di ezmûna xwe de, min mîmariyek mîkro-xizmetê bi tevahî nedît, ez ê bibêjim ji sedî 50 heya 50 - 50 ji mîkroservîsan, qutiyên reş, ketin hundur, pêvajoyek derketin, 50 yên din monolîtek perçebûyî ne, karûbar nikarin ji yên din cuda bixebitin. pêkhateyên. Hemî vê yekê dîsa li ser asta zanîna hem pêşdebiran û hem jî rêvebiran sînordar kirin.
Di asta zanîna pispor a çavkaniyek taybetî de "swing"ên bi vî rengî heya roja îro berdewam dikin. Lê em hinekî dûr dikevin, gelek xalên hêjayî balkişandinê hene.
Endezyarê Avakirinê / Endezyarê berdanê
Endezyarên pir pispor ên ku wekî navgînek standardkirina nermalava pêvajo û serbestberdanê derketine holê. Di pêvajoya danasîna Agile ya berbelav de, wusa dixuye ku ew ji daxwazê rawestiyane, lê ev ji dozê dûr e. Ev pisporî wekî navgînek standardkirina kombûn û radestkirina nermalavê li ser pîvanek pîşesaziyê xuya bû, ango. bikaranîna teknîkên standard ji bo hemû berhemên şîrketa. Bi hatina DevOps re, pêşdebiran bi qismî fonksiyonên xwe winda kirin, ji ber ku ew pêşdebiran bûn ku dest bi amadekirina hilberê ji bo radestkirinê kirin, û ji ber guhertina binesaziyê û nêzîkatiya radestkirina bi lez û bez bêyî guhdana kalîteyê, bi demê re ew zivirîn rawestana guhertinan, ji ber ku pabendbûna bi standardên kalîteyê bi neçarî radestkirinê hêdî dike. Ji ber vê yekê, hêdî hêdî, beşek ji fonksiyonên endezyarên Build / Release koçî milên rêveberên pergalê kirin.
Ops pir cûda ne
Em bi pêş ve diçin û dîsa hebûna cûrbecûr berpirsiyariyan û nebûna personelên jêhatî me ber bi pisporiya hişk ve dikişîne, mîna kivarkên piştî baranê, Operasyonên cihêreng xuya dikin:
- TechOps - rêveberên pergala enikey an jî Endezyarê HelpDesk
- LiveOps - Rêvebirên pergalê di serî de ji hawîrdorên hilberînê berpirsiyar in
- CloudOps - rêveberên pergalê yên pispor di ewrên gelemperî de Azure, AWS, GCP, hwd.
- PlatOps / InfraOps / SysOps - rêveberên pergala binesaziyê.
- NetOps - rêveberên torê
- SecOps - rêveberên pergalê yên pispor di ewlehiya agahdariyê de - Lihevhatina PCI, lihevhatina CIS, patching, hwd.
DevOps (di teoriyê de) kesek e ku ji hemî pêvajoyên çerxa pêşkeftinê ji destê yekem fam dike - pêşkeftin, ceribandin, mîmariya hilberê fam dike, dikare xetereyên ewlehiyê binirxîne, bi nêzîkatî û amûrên otomasyonê re, bi kêmanî di asta bilind de nas e. asta, ji bilî vê, di heman demê de pêş- û piştî-pêvajoyê jî fêm dike.Piştgiriya berdana hilberê. Kesek ku karibe wekî parêzvanek hem ji bo Operasyon û hem jî Pêşkeftinê tevbigere, ku rê dide hevkariyek xweş di navbera van her du stûnan de. Pêvajoyên xebata plansaziyê ji hêla tîmê ve û birêvebirina hêviyên xerîdar ve fêm dike.
Ji bo pêkanîna vî rengî kar û berpirsiyarî, pêdivî ye ku ev kes xwedan amûr be ku ne tenê pêvajoyên pêşkeftin û ceribandinê, lê di heman demê de rêveberiya binesaziya hilberê, û her weha plansaziya çavkaniyê jî birêve bibe. DevOps di vê têgihiştinê de ne di IT-ê de, ne di R&D-ê de, ne jî di PMO-yê de ne pêkan e; pêdivî ye ku ew di van hemî deveran de xwedî bandor be - rêveberê teknîkî yê pargîdanî, Karmendê Teknîkî yê sereke.
Ma ev di pargîdaniya we de rast e? - Ez guman dikim. Di pir rewşan de, ev IT an R&D e.
Nebûna dirav û şiyana bandorkirina bi kêmî ve yek ji van sê warên çalakiyê dê giraniya pirsgirêkan ber bi cîhê ku ev guhertin hêsantir têne sepandin veguhezîne, wek mînak serîlêdana sînorkirinên teknîkî yên li ser berdanan di girêdana bi koda "pîs" de li gorî statîk. sîstemên analîzer. Ango, dema ku PMO ji bo serbestberdana fonksiyonê muhletek hişk destnîşan dike, R&D nikare di nav van muhletan de encamek kalîteya bilind derxîne û wê bi qasî ku ji destê wî tê hildiberîne, refaktorkirinê ji bo paşê dihêle, DevOpsên têkildar bi IT-ê ve bi rêyên teknîkî berdanê asteng dike. . Nebûna desthilatdariyê ji bo guheztina rewşê, di mijara karmendên berpirsiyar de, dibe sedema xuyangkirina berpirsiyariya hîper-berpirsiyarî ya ku ew nikaribin bandor bikin, nemaze heke van karmend xeletiyan fam bikin û bibînin, û çawa wan rast bikin - "Xwezî nezanî ye". û di encamê de şewitî û windakirina van karmendan.
Bazara çavkaniya DevOps
Ka em li çend valahiyên ji bo pozîsyonên DevOps ji pargîdaniyên cihêreng binêrin.
Em amade ne ku bi we re hevdîtinê bikin eger hûn:
- Hûn xwediyê Zabbix in û dizanin Prometheus çi ye;
- Iptables;
- Xwendekarê doktoraya BASH;
- Profesor Ansible;
- Linux Guru;
- Dizanin ka meriv çawa xeletkirinê bikar tîne û bi pêşdebiran re pirsgirêkên serîlêdanê bibîne (php/java/python);
- Routing we hîsterîk nake;
- Bala xwe bidin ewlehiya pergalê;
- Piştgiriya "tişt û her tiştî", û her weha bi serfirazî vê "tişt û her tiştî" sererast bikin;
- Hûn dizanin ka meriv çawa pergalê bi vî rengî mîheng bike ku herî zêde ji hindiktirînê derkeve;
- Beriya razanê li ser Postgres û MySQL-ê dubarekirinê saz bikin;
- Sazkirin û sererastkirina CI/CD ji we re wekî taştê/xwarin/şev pêwîst e.
- Bi AWS re xwedî ezmûn in;
- Amade ne ku bi pargîdaniyê re pêşve bibin;
Ji ber vê yekê
- ji 1 heta 6 - rêveberê pergalê
- 7 - rêveberiya torê ya piçûk, ku di heman demê de di nav rêvebirê pergalê de, asta navîn de jî tê de ye
- 8 - ewlehiyek piçûk, ku ji bo rêveberek pergala asta navîn mecbûrî ye
- 9-11 - Rêvebirê Sîstema Navîn
- 12 - Li gorî peywirên hatine peywirdarkirin, an Rêvebirê Pergala Navîn an Endezyarê Avakirinê
- 13 - Virtualîzasyon - Rêvebirê Pergala Navîn, an jî bi navê CloudOps, zanîna pêşkeftî ya karûbarên malperek mêvandar a taybetî, ji bo karanîna bikêrhatî ya fonan û kêmkirina barê lênihêrînê.
Bi kurtî vê valatiyê, em dikarin bibêjin ku Rêvebirê Pergala Navîn/Pilind ji bo xortan bes e.
Bi awayê, divê hûn rêveberên li ser Linux/Windows bi tundî dabeş nekin. Bê guman, ez fêm dikim ku xizmet û pergalên van her du cîhan ji hev cihê ne, lê bingeha hemîyan yek e û her rêveberek xwerû hem bi yekî û hem jî bi yê din re nas dike, û heke ew ne nas be jî, dê ne zehmet be ku rêvebirek jêhatî pê re nas bike.
Ka em cîhek din a vala bifikirin:
- Ezmûna di avakirina pergalên barkirina bilind de;
- Zanîna bêkêmasî ya Linux OS, nermalava pergalê ya gelemperî û stacka malperê (Nginx, PHP / Python, HAProxy, MySQL / PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Ezmûna pergalên virtualîzasyonê (KVM, VMWare, LXC / Docker);
- Zehmetiya zimanên nivîsandinê;
- Fêmkirina prensîbên xebitandinê yên torên protokola torê;
- Têgihîştina prensîbên avakirina pergalên xelet-tolerant;
- Serxwebûn û destpêşxerî;
Ka em lê binêrin:
- 1 – Rêvebirê Sîstema Bilind
- 2 - Li gorî wateya ku di vê stikê de tête danîn - Rêvebirê Pergala Navîn / Mezin
- 3 - Tecrûbeya xebatê, di nav de, dibe ku were vê wateyê - "Kube hilneda, lê makîneyên virtual afirandin û rêvebirin, yek mêvandarek Docker hebû, gihîştina konteyneran peyda nebû" - Rêvebirê Sîstema Navîn
- 4 - Rêvebirê Sîstema Junior - erê, rêveberek ku nizane çawa nivîsarên xweseriya bingehîn binivîsîne, bêyî ku ziman hebe, ne rêveberek - enikey.
- 5 - Rêvebirê Sîstema Navîn
- 6 – Rêvebirê Sîstema Bilind
Bi kurtasî - Rêvebirê Pergala Navîn / Mezin
Yeka din:
- Tecrubeya Devops;
- Ezmûna karanîna yek an çend hilberan ji bo afirandina pêvajoyên CI / CD. Gitlab CI dê avantaj be;
- Bi konteyneran û virtualîzasyonê re dixebitin; Ger we docker bikar anî, baş e, lê heke we k8s bikar anî, baş e!
- Ezmûna xebatê di tîmek agile de;
- Zanîna her zimanekî bernamesaziyê;
Ka em bibînin:
- 1 - Hmm... Mebesta xortan çi ye? =) Bi îhtîmaleke mezin ew bi xwe nizanin li pişt wê çi veşartî ye
- 2 - Endezyarê avahîsaziyê
- 3 - Rêvebirê Sîstema Navîn
- 4 - Zehmetiya nerm, em ê heya niha wê nehesibînin, her çend Agile tiştek din e ku bi rengek hêsan tê şîrove kirin.
- 5 - Pir devkî - dibe ku zimanek nivîsandinê be an jî yê berhevkirî be. Ez meraq dikim gelo nivîsandina bi Pascal û Basic li dibistanê dê li gorî wan be? =)
Di heman demê de ez dixwazim di derbarê xala 3-ê de notek bihêlim da ku têgihîştina ka çima ev xal ji hêla rêvebirê pergalê ve hatî vegirtin xurt bikim. Kubernetes tenê orkestrasyonek e, amûrek ku fermanên rasterast li ajokarên torê û mêvandarên virtualîzasyon/îzolekirinê di nav çend fermanan de dipêçe û dihêle hûn bi wan re danûstendinê razber bikin, ew hemî. Mînakî, em "çarçoveya avakirina" Make bigirin, ku, bi awayê, ez çarçoveyek nabînim. Erê, ez di derbarê moda kişandina Make li her deverê de dizanim, li cîhê ku ew hewce ye û ne hewce ye - Mînakî, bi giranî Maven di Make de pêça?
Di bingeh de, Make tenê pêçek li ser şêlê ye, mîna k8s, berhevok, girêdan û fermanên hawîrdora berhevkirinê hêsan dike.
Carekê, min bi zilamek ku k8s di xebata xwe de li ser OpenStack-ê bikar anî re hevpeyivîn kir, û wî got ka wî çawa karûbar li ser wê bi cih kiriye, lêbelê, gava ku min li ser OpenStack pirsî, derket holê ku ew ji hêla pergalê ve hatî rêve kirin, û her weha ji hêla pergalê ve hatî bilind kirin. rêveberan. Ma hûn bi rastî difikirin ku kesê ku OpenStack saz kiriye, bêyî ku ew li pişt xwe kîjan platformê bikar tîne, nekare k8 bikar bîne? =)
Ev serlêder bi rastî ne DevOps e, lê Rêvebirek Pergalê ye û, rasttir, Rêvebirek Kubernetes e.
Ka em careke din kurt bikin - Rêvebirê Pergala Navîn / Mezin dê ji wan re bes be.
Çiqas bi gram
Rêjeya mûçeyên pêşniyarkirî yên ji bo valahiyên diyarkirî 90k-200k e
Naha ez dixwazim di navbera xelatên diravî yên Rêvebirên Pergalê û Endezyarên DevOps de paralelek bikişînim.
Di prensîbê de, ji bo hêsankirina tiştan, hûn dikarin notan li ser bingeha ezmûna xebatê belav bikin, her çend ev ê ne rast be, lê ji bo mebestên gotarê ew ê bes be.
Tecrubeyek:
- heta 3 salan - Junior
- heta 6 salî - Navîn
- zêdetir ji 6 - Senior
Malpera lêgerîna karmendan pêşkêşî dike:
Rêvebirên Sîstemê:
- Junior - 2 sal - 50k rub.
- Navîn - 5 sal - 70 hezar rûb.
- Mezin - 11 sal - 100 hezar rûb.
Endezyarên DevOps:
- Junior - 2 sal - 100k rub.
- Navîn - 3 sal - 160k rûb.
- Mezin - 6 sal - 220 hezar rûb.
Li gorî ezmûna "DevOps", ezmûnek hate bikar anîn ku bi kêmanî bi rengek bandor li SDLC kir.
Ji jor tê xuyang kirin ku di rastiyê de pargîdanî ne hewceyê DevOps-ê ne, û her weha ew dikarin bi kirêkirina Rêvebirek bi kêmî ve ji sedî 50 ji lêçûnên destpêkê yên plansazkirî xilas bikin; ji bilî vê, ew dikarin berpirsiyariyên kesê ku lê digerin zelaltir diyar bikin. û hewcedariyê zûtir tije bikin. Di heman demê de divê em ji bîr nekin ku dabeşkirina zelal a berpirsiyariyan dihêle ku em hewcedariyên karmendan kêm bikin, û her weha di tîmê de atmosferek xweştir biafirînin, ji ber nebûna hevgirtinê. Piraniya valahiyan tijî karûbar û etîketên DevOps in, lê ew ne li gorî hewcedariyên rastîn ên Endezyarek DevOps-ê ne, tenê daxwazên rêveberek amûrê ne.
Pêvajoya perwerdekirina endezyarên DevOps di heman demê de tenê bi komek karên taybetî, karûbaran ve sînorkirî ye, û têgihiştinek giştî ya pêvajoyê û girêdanên wan peyda nake. Bê guman baş e ku gava mirovek bikaribe AWS EKS-ê bi karanîna Terraform-ê, digel kêleka Fluentd-ê ya di vê komê de û stûna AWS ELK-ê ji bo pergala têketinê di nav 10 hûrdeman de bicîh bike, tenê yek fermanek di konsolê de bikar bîne, lê heke ew fam neke. prensîba hilberandina têketinên xwe û ji bo çi ew hewce ne, heke hûn nizanin ka meriv çawa metrîkan li ser wan berhev dike û xerabûna karûbarê bişopîne, wê hingê ew ê dîsa jî heman enikey be ku dizane meriv hin karûbaran çawa bikar tîne.
Lêbelê, daxwazî peyda dike, û em ji bo pozîsyona DevOps bazarek pir germbûyî dibînin, ku hewcedarî bi rola rastîn re nagunce, lê tenê rê dide rêvebirên pergalê ku bêtir qezenc bikin.
Îcar ew kî ne? DevOps an rêveberên pergalê yên çavbirçî? =)
Çawa berdewamkirina jiyanê?
Kardêr pêdivî ye ku hewcedariyên rasttir formule bikin û tam li yên ku hewce ne bigerin, û li dora etîketan nexin. Hûn nizanin DevOps çi dikin - hûn di wê rewşê de ne hewce ne.
Karker - Fêr bibin. Bi domdarî zanîna xwe baştir bikin, li wêneya giştî ya pêvajoyan binihêrin û riya armanca xwe bişopînin. Hûn dikarin bibin yê ku hûn dixwazin, hûn tenê biceribînin.
Source: www.habr.com