Di van demên dawî de reklamên bi vî rengî li Înternetê diherikin. Digel meaşê xweş, meriv nikare şerm bike ku di hundurê viraştene çolê de hatî nivîsandin. Di destpêkê de tê texmîn kirin ku "DevOps" û "endezyar" dikarin bi rengekî bi yek peyvê bi hev ve werin zeliqandin, û dûv re navnîşek hewcedariyên rasthatî heye, ku hin ji wan bi eşkere ji valahiya sysadmin têne kopî kirin.
Di vê postê de ez dixwazim piçekî biaxivim ka em çawa gihîştin vê xala jiyanê, DevOps bi rastî çi ye û niha bi wê re çi bikin.
Valahiyên weha dikarin bi her awayê gengaz bêne mehkûm kirin, lê rastiyek dimîne: gelek ji wan hene, û bi vî rengî bazar di vê gavê de dixebite. Me konferansek devops pêk anî û bi eşkereyî ragihand: - ne ji bo endezyarên DevOps." Ev dê ji gelekan re xerîb û hov xuya bike: çima kesên ku bûyerek bi tevahî bazirganî dikin li dijî sûkê derdikevin. Niha em ê her tiştî rave bikin.
Li ser çand û pêvajoyan
Ka em bi vê rastiyê dest pê bikin ku DevOps ne dîsîplînek endezyariyê ye. Hemî bi vê yekê dest pê kir ku dabeşkirina rola dîrokî ya ku ji bo kalîteya hilberan kar nake. Gava ku bernameçêker tenê bername dikin, lê naxwazin di derbarê ceribandinê de tiştek bibihîzin, nermalava bi xeletiyan tije dibe. Gava ku rêvebir eleqedar nakin ka nermalava çawa û çima tê nivîsandin, piştgirî vediguhere dojehê.
Mînakî, danasîna cûdahiya di navbera rêveberek pergalê û nêzîkatiyek SRE ya rêveberiya karûbarê de . Di hundurê de lêkolînên balkêş hatine kirin - Eşkere ye ku pêşdebirên çêtirîn bi rengekî rê didin ku guheztinên nû di hilberînê de ji demjimêrek carekê zûtir bicîh bikin. Ew bi destên xwe ji% 10 zêdetir ceribandinê dikin (ev dikare ji ). Çawa vê yekê dikin? Yek ji sernavên raporê dibêje "Biser bikeve an bimire". Ji bo nîqaşek berfireh a van statîstîkan di çarçoweya ceribandinê de, hûn dikarin serî li sernivîsa Baruch Sadogursky bidin. li konferansa me ya din, Heisenbug.
“Dema ku di navbera hevalan de lihevkirin çênebe,
Tişt dê ji wan re baş neçe,
Û tiştek jê dernakeve, tenê ezab.
Demek berê Swan, Kerfek û Pîkek..."
Ma hûn difikirin ku kîjan beşek ji bernamenûsên malperê bi rastî şert û mercên ku sepanên wan di hilberînê de têne bikar anîn fam dike? Çend ji wan dê biçin cem rêvebiran û hewl bidin ku fêhm bikin ka dê çi bibe heke databas têk bibe? Û kîjan ji wan dê biçe cem testkaran û ji wan bipirse ku wan fêrî nivîsandina testan bikin? Û her weha cerdevanên ewlehiyê, rêveberên hilberê, û komek mirovên din jî hene.
Fikra giştî ya DevOps ev e ku di navbera rol û beşan de hevkariyê biafirîne. Berî her tiştî, ev ne ji hêla hin nermalava bi aqilane ve hatî mîheng kirin, lê ji hêla pratîka ragihandinê ve tê bidestxistin. DevOps li ser çand, pratîk, rêbaz û pêvajoyan e. Taybetmendiyek endezyariyê tune ku bikaribe bersiva van pirsan bide.
Goreke xirab
Wê demê dîsîplîna "endazyariya devops" ji ku derket? Versiyonek me heye! Ramanên DevOps baş bûn - ewqas baş bûn ku ew bûn qurbaniyên serkeftina xwe. Hin peyker û bazirganên mirovan, yên ku atmosfera wan heye, dest pê kirin ku li dora vê mijarê tev bigerin.
Bifikirin: duh we li Khimki shawarma çêdikir, û îro hûn jixwe zilamek mezin, peywirdarek payebilind in. Pêvajoyek tevahî lêgerîn û hilbijartina berendaman heye, her tişt ne hêsan e, divê hûn fêm bikin. Em bêjin serokê beşê dibêje: di X de pisporekî peyda bikin. Pêdivî ye Linux? Welê, ev bê guman endezyarek Linux-ê ye, heke hûn DevOps dixwazin, wê hingê endezyarek DevOps. Valahî ne tenê ji sernavekê pêk tê, di heman demê de divê hin nivîs jî têkevin hundur. Rêya herî hêsan ev e ku meriv bi xeyala xwe ve girêdayî komek peyvên sereke ji Google-ê bike. DevOps ji du peyvan pêk tê - "Dev" û "Ops", ku tê vê wateyê ku em hewce ne ku peyvên sereke yên ku bi pêşdebir û rêvebiran re têkildar in tev li yek pileyê bixin. Bi vî rengî valahiyên di derbarê jêhatîbûna 42 zimanên bernamekirinê û 20 sal karanîna Kubernetes û Swarm de bi hevdemî xuya dibin. Diyagrama xebatê.
Bi vî rengî wêneya bêwate û bêmerhemet a hin serpêhatiyek "devops" di hişê mirovan de cîh girtiye, ku dê her kesî mîheng bike ku li Jenkins bicîh bike, û bextewarî dê were. Oh, heke her tişt ew qas hêsan bûya. "Û bi vî rengî hûn dikarin rêvebirên pergalê jî bişopînin," HR difikire, "ew peyvek modê ye, peyvên sereke yek in, divê ew li ber xwe bidin."
Daxwaz pêşkêşiyê diafirîne, û van hemî valahiyên çopê bi hejmareke dîn a rêveberên pergalê ve hatine dagirtin ku fêm kirine: hûn dikarin her tiştî wekî berê bikin, lê bi navê xwe "devops" çend caran bêtir bistînin. Mîna ku we serverên bi navgîniya SSH-ê yek bi yek bi destan mîheng kirin, hûn ê mîhengkirina wan bidomînin, lê naha ev tê guman kirin ku pratîkek devops e. Ev celebek diyardeyek tevlihev e, ku hinekî jî bi kêmnirxandina rêveberên klasîk û hîpertansiyonê li dora DevOps ve girêdayî ye, lê bi gelemperî, çi qewimî, qewimî.
Ji ber vê yekê dabîn û daxwaziya me heye. Derdoreke xerab a ku xwe dixwe. Ya ku em li dijî wê şer dikin ev e (tevî çêkirina konferansa DevOops).
Bê guman, ji xeynî rêvebirên pergalê ku navê xwe dane "devops", beşdarên din jî hene - mînakî, SRE-yên profesyonel an pêşdebirên Binesaziyê-as-Code.
Mirov li DevOps çi dikin (bi rastî)
Ji ber vê yekê hûn dixwazin di fêrbûn û pêkanîna pratîkên DevOps de pêş de bibin. Lê meriv çawa vê yekê bike, li kîjan alî binêre? Eşkere ye, divê hûn ne kor bi keywordên populer ve girêdayî bin.
Ger karek hebe divê kes bike. Me berê jî dît ku ev ne "endazyarên devops" in, wê demê kî ne? Rasttir xuya dike ku meriv vê yekê ne li gorî mewziyan, lê di warê qadên taybetî yên xebatê de formule bike.
Pêşîn, hûn dikarin dilê DevOps-pêvajo û çandê çareser bikin. Çand karsaziyek hêdî û dijwar e, û her çend ew bi kevneşopî berpirsiyariya rêveberan e jî, ji bernamenûs bigire heya rêveberan her kes bi vî rengî tevlê dibe. Çend meh berê Tim Lister :
"Çand ji hêla nirxên bingehîn ên rêxistinê ve tê destnîşankirin. Bi gelemperî mirov vê yekê ferq nakin, lê ji ber ku em bi salan di şêwirdariyê de xebitîn, em fêrî vê yekê bûne. Hûn dikevin pargîdaniyek û bi rastî di nav çend hûrdeman de hûn dest pê dikin ku çi diqewime hîs bikin. Em ji vê re dibêjin "tehm". Carinan ev bîhn bi rastî xweş e. Carinan dibe sedema gêjbûnê. (...) Heta ku nirx û baweriyên li pişt kiryarên taybetî neyên fêmkirin, hûn nikarin çandekê biguherînin. Çavdêrîkirina tevger hêsan e, lê lêgerîna baweriyan dijwar e. DevOps tenê mînakek hêja ye ku tişt çawa her ku diçe tevlihevtir dibin."
Helbet beşek teknîkî ya mijarê jî heye. Ger koda weya nû di mehekê de were ceribandin, lê tenê salek şûnda were berdan, û ji hêla laşî ve ne gengaz e ku hûn hemî bilez bikin, dibe ku hûn bi pratîkên baş re nejîn. Pratîkên baş bi amûrên baş têne piştgirî kirin. Mînakî, bi ramana Binesaziya-wek-Code, hûn dikarin ji AWS CloudFormation û Terraform heya Chef-Ansible-Puppet tiştek bikar bînin. Pêdivî ye ku hûn van hemîyan zanibin û karibin bikin, û ev jixwe dîsîplînek endezyariyê ye. Girîng e ku sedem bi encamê re tevlihev nebe: pêşî hûn li gorî prensîbên SRE dixebitin û tenê hingê van prensîban di forma hin çareseriyên teknîkî yên taybetî de bicîh dikin. Di heman demê de, SRE metodolojîyek pir berfireh e ku ji we re nabêje meriv çawa Jenkins saz dike, lê li ser pênc prensîbên bingehîn:
- Têkiliya di navbera rol û beşan de çêtir kirin
- Qebûlkirina xeletiyan wekî beşek bingehîn a xebatê
- Guhertinên gav bi gav têne çêkirin
- Bikaranîna amûr û otomasyona din
- Pîvandina her tiştê ku dikare were pîvandin
Ev ne tenê çend gotinan e, lê taybetmendiyek e . Mînakî, li ser riya pejirandina xeletiyan, hûn ê hewce bikin ku xetereyan fam bikin, hebûna û nebûna karûbaran bi karanîna tiştek mîna SLI bipîvin () û SLO (), fêrî nivîsandina postmorteman bibin û nivîsandina wan netirsin.
Di dîsîplîna SRE de, karanîna amûran tenê beşek serfiraziyê ye, her çend yek girîng be. Pêdivî ye ku em bi berdewamî teknîkî pêş bixin, li cîhanê binihêrin ka çi diqewime û çawa dikare di xebata me de were sepandin.
Wekî din, çareseriyên Cloud Native naha pir populer bûne. Wekî ku îro ji hêla Weqfa Cloud Native Computing ve hatî destnîşan kirin, teknolojiyên Cloud Native rê dide rêxistinan ku di hawîrdorên dînamîkî yên îroyîn de, wekî ewrên gelemperî, taybet, û hybrid, serîlêdanên berbiçav pêşve bibin û bimeşînin. Nimûne konteynir, tevnên karûbar, mîkroxizmet, binesaziya neguhêrbar, û API-yên ragihandinê hene. Hemî van teknîkan dihêle ku pergalên ku bi hev ve girêdayî ne elastîk, birêkûpêk û pir berçav bimînin. Otomasyona baş dihêle endezyaran bi gelemperî û bi encamên pêşbînîkirî guheztinên mezin çêbikin bêyî ku ew bikin kar. Hemî ev ji hêla stûnek amûrên naskirî yên wekî Docker û Kubernetes ve têne piştgirî kirin.
Ev pênaseya tevlihev û berfireh ji ber wê yekê ye ku dever jî têra xwe tevlihev e. Ji aliyekî ve, tê nîqaşkirin ku divê guhertinên nû li vê pergalê pir hêsan werin zêdekirin. Ji hêla din ve, meriv fêr bibe ka meriv çawa meriv cûreyek jîngehek konteyneran biafirîne ku tê de karûbarên bi hevûdu ve girêdayî li ser binesaziyek nermalava diyarkirî dijîn û li wir bi karanîna CI/CD-ya domdar têne radest kirin, û li dora van hemî pratîkên DevOps ava bikin - ev hemî bêtir hewce dike. ji yek kûçik dixwe.
Bi van hemûyan re çi bikin
Her kes van pirsgirêkan bi awayê xwe çareser dike: Mînakî, hûn dikarin valahiyên normal biweşînin da ku çembera xirab bişkînin. Hûn dikarin fêm bikin ka peyvên wekî DevOps û Cloud Native tê çi wateyê û wan rast û bi xal bikar bînin. Hûn dikarin di DevOps de pêşve bibin û bi mînaka xwe nêzîkatiyên rast destnîşan bikin.
Em konferansekê dikin , ku fersendek peyda dike ku em li ser tiştên ku me tenê li ser axifîn kûr bigerin. Ji bo vê yekê çend komên rapor hene:
- Pêvajo û çand;
- Endezyariya pêbaweriya malperê;
- Cloud Native;
Meriv çawa hilbijêre ku biçin? Li vir xalek nazik heye. Ji aliyekî ve, DevOps di derbarê danûstendinê de ye, û em bi rastî dixwazin ku hûn ji blokên cûda beşdarî pêşkêşiyan bibin. Ji hêla din ve, heke hûn rêveberek pêşkeftinê ne ku hatî konferansê da ku li ser yek peywirek taybetî hûr bibe, wê hingê kes we sînordar nake - eşkere, ev ê bibe astengek li ser pêvajo û çandê. Ji bîr nekin ku piştî konferansê dê tomarên we hebin (piştî dagirtina forma bersivdayînê), ji ber vê yekê hûn her gav dikarin paşê pêşandanên kêmtir girîng temaşe bikin.
Eşkere ye ku di konferansê de bixwe hûn nekarin bi yekcarî li ser sê rêkan biçin, ji ber vê yekê em bernameyê bi vî rengî organîze dikin ku her carê mijar ji bo her çêjekê hebe.
Tiştê ku dimîne ev e ku hûn fêm bikin ka hûn endezyarek DevOps in çi bikin! Pêşîn, hewl bidin ku hûn diyar bikin ku hûn bi rastî çi dikin. Bi gelemperî ew dixwazin vê peyvê bibêjin:
- Pêşdebirên ku li ser binesaziyê dixebitin. Komên raporên li ser SRE û Cloud Native ji bo we herî maqûl in.
- Rêveberên pergalê. Li vir tevlihevtir e. DevOops ne li ser rêveberiya pergalê ye. Xweşbextane, li ser mijara rêveberiya pergalê gelek konferans, pirtûk, gotar, vîdyoy û hwd. Ji hêla din ve, heke hûn dixwazin xwe di warê têgihîştina çand û pêvajoyan de, fêrbûna teknolojiyên ewr û hûrguliyên jiyanê bi Cloud Native re pêşve bibin, wê hingê em hez dikin ku we bibînin! Li ser vê yekê bifikirin: hûn rêveberiyê dikin, û paşê hûn ê çi bikin? Ji bo ku hûn ji nişka ve xwe di rewşek ne xweş de nebînin, divê hûn nuha fêr bibin.
Vebijarkek din jî heye: hûn îdia dikin ku hûn in bi taybetî endezyarek DevOps û tiştekî din, çi tê wê wateyê. Wê hingê divê em we bêhêvî bikin, DevOops ne konferansek ji bo endezyarên DevOps e!
Slide ji li Munîhê
DevOops 2020 Moskowê dê di 29-30 Avrêlê de li Moskowê were li dar xistin, bilêt jixwe berdest in .
Wekî din, hûn dikarin heta 8ê Sibatê. Ji kerema xwe bala xwe bidin ku dema ku formê dagirtin, divê hûn temaşevanên armanc hilbijêrin ku dê herî zêde ji rapora we sûd werbigirin (di nav lîsteyê de surprîzek heye).
Source: www.habr.com