DevOps-en definizioa oso konplexua da, beraz, horri buruzko eztabaida berriro hasi behar dugu aldiro. Mila argitalpen daude gai honi buruz Habré-ri buruz bakarrik. Baina hau irakurtzen ari bazara, ziurrenik badakizu zer den DevOps. Ez naizelako. Kaixo nire izena da Alexander Titov (@), eta DevOps-i buruz hitz egingo dugu eta nire esperientzia partekatuko dut.
Aspalditik nabil nire istorioa erabilgarria nola egin pentsatzen, beraz, galdera asko egongo dira hemen - neure buruari egiten dizkiodanak eta gure konpainiako bezeroei egiten dizkiedanak. Galdera hauei erantzunez, ulermena hobetzen da. Esango dizut zergatik behar den DevOps nire ikuspuntutik, zer den, berriro ere, nire ikuspuntutik, eta nola ulertu berriro DevOps aldera zoazela nire ikuspuntutik. Azken puntua galderen bidez izango da. Zeure kabuz erantzunez, zure enpresa DevOps-era jotzen ari den edo nolabait arazoak dauden uler dezakezu.
Garai batean fusioen eta erosketen olatuetan ibiltzen nintzen. Lehenik eta behin, Qik izeneko startup txiki batean lan egin nuen, gero Skype izeneko enpresa apur bat handiagoak erosi zuen, eta gero Microsoft izeneko enpresa apur bat handiagoak erosi zuen. Momentu horretan, DevOps-en ideia tamaina ezberdinetako enpresetan nola eraldatzen ari zen ikusten hasi nintzen. Horren ostean, DevOps merkatuaren ikuspuntutik begiratzeko interesa piztu zitzaidan, eta nire lankideek eta biok Express 42 enpresa sortu genuen. 6 urte daramatzagu merkatuaren olatuetan zehar mugitzen.
Besteak beste, DevOps Moskuko komunitateko antolatzaileetako bat naiz eta DevOps-Days 2017-en antolatzaileetako bat naiz, baina ez nuen 2018a antolatu. Express 42 konpainia askorekin lan egiten du. Bertan DevOps hazten dugu, nola gertatzen den ikusten dugu, ondorioak ateratzen ditugu, gure ondorioak aztertzen, guztiei kontatzen dizkiegu eta jendea DevOps praktiketan trebatzen dugu. Oro har, gure onena egiten ari gara zentzu honetan gure esperientzia eta espezializazioa areagotzeko.
Zergatik DevOps
Guztiontzat eta beti dabilen lehen galdera hau da: zergatik? Jende askok uste du DevOps automatizazioa besterik ez dela edo enpresa guztiek lehendik zuten antzeko gauza bat dela.
— Etengabeko integrazioa genuen; horrek esan nahi du dagoeneko DevOps geneukala, eta zergatik behar da gauza guzti hau? Atzerrian ondo pasatzen ari dira, baina lan egitea galarazten digute!
Komunitatearen eta metodologiaren garapenaren 9 urtetan zehar, dagoeneko argi geratu da hori ez dela purpurina merkaturatzea, baina oraindik ez dago guztiz argi zergatik den beharrezkoa. Edozein tresna eta prozesu bezala, DevOps-ek helburu zehatzak ditu azkenean lortzen dituena.
Hori guztia mundua aldatzen ari delako. Enpresa-ikuspegitik urruntzen da, konpainiak amets batera zuzen doazenean, gure San Petersburgoko klasikoak kantatzen zuen bezala, A puntutik B puntura estrategia jakin baten arabera, horretarako eraikitako egitura jakin batekin.
Printzipioz, informatikako guztia ikuspegi honen arabera eraiki behar da. Hemen IT prozesuak automatizatzeko soilik erabiltzen da.
Automatizazioa ez da askotan aldatzen, izan ere, enpresa batek ondo zapaldutako bidetik doanean, zer dago aldatzeko? Funtzionatzen du - ez ukitu. Orain munduan planteamenduak aldatzen ari dira, eta Agile izenekoak iradokitzen du B amaiera puntua ez dela berehala ikusten.
Enpresa bat merkatutik pasatzen denean, bezero batekin lan egiten duenean, merkatua etengabe arakatzen du eta B amaierako puntua aldatzen du. Gainera, zenbat eta maizago aldatzen duen konpainiak bere norabidea, orduan eta arrakasta handiagoa du azkenean, merkatu gehiago aukeratzen duelako. nitxoak.
Duela gutxi ezagutu dudan enpresa interesgarri batek erakusten du estrategia. One Box Shave kaxa batean bizarrak eta bizarra egiteko osagarriak bidaltzeko harpidetza zerbitzua da. Badakite euren "kutxa" pertsonalizatzen bezero ezberdinetarako. Hau software jakin batek egiten du, eta gero eskaera Koreako fabrikara bidaltzen du salgaiak ekoizten dituena.
Produktu hau Unilever-ek erosi zuen 1 milioi dolarren truke. Gaur egun, Gilletterekin lehiatzen da eta kontsumitzaileen parte garrantzitsua kendu die Amerikako merkatuan. One Box Shave esan:
- 4 pala? Serio al zaude? Zergatik behar duzu hau - ez du bizarraren kalitatea hobetzen. Bereziki hautatutako krema, usain eta bi xafladun kalitate handiko bizar batek Gillette 4 xafla ergel horiek baino askoz arazo gehiago konpontzen dituzte! Laster iritsiko al gara 10era?
Horrela aldatzen da mundua. Unilever-ek dio hori egiteko aukera ematen dizun IT sistema polita dutela. Azkenean kontzeptu bat dirudi Merkaturatzeko denbora, inork jadanik hitz egin ez duena.
Merkaturako Denboraren puntua ez da zenbat maiztasunez zabaltzen dugun. Askotan zabaldu dezakezu, baina kaleratze-zikloak luzeak izango dira. Hiru hilabeteko kaleratze-zikloak elkarri gainjartzen bazaizkio, astebetez aldatuz, badirudi konpainia astean behin zabaltzen ari dela. Eta ideiatik behin betiko inplementaziora arte 3 hilabete behar dira.
Merkaturatzeko denbora ideiatik azken inplementaziora arteko denbora gutxitzea da.
Kasu honetan, softwareak merkatuarekin elkarreragiten du. Honela One Box Shave webguneak bezeroarekin elkarreragiten du. Ez dute saltzailerik, bisitariek egin klik eta nahiak uzten dituzten webgune bat besterik ez. Horren arabera, zerbait berria etengabe argitaratu behar da webgunean eta nahien arabera eguneratu. Adibidez, Hego Korean Errusian baino modu ezberdinean bizarra egiten dute, eta ez dute pinuaren usaina gustatzen, baizik eta, adibidez, azenarioaren eta bainilaren usaina.
Gunearen edukia azkar aldatzea beharrezkoa denez, softwarearen garapena asko aldatzen da. Softwarearen bidez bezeroak zer nahi duen jakin behar dugu. Aurretik, bide borobil batzuen bidez ikasi genuen hori, adibidez, enpresa kudeaketaren bidez. Gero diseinatu genuen, eskakizunak sistema informatikoan jarri eta dena polita izan zen. Orain ezberdina da: softwarea prozesuan parte hartzen duten guztiek diseinatu dute, ingeniariek barne, zehaztapen teknikoen bidez merkatuak nola funtzionatzen duen ikasten dutelako eta negozioarekin beren ikuspegiak ere partekatzen dituztelako.
Esaterako, Qik-en bat-batean jakin genuen jendeari asko gustatzen zitzaiola kontaktuen zerrendak zerbitzarira kargatzea, eta aplikazio bat hornitu ziguten. Hasieran ez genuen horretan pentsatu. Enpresa klasiko batean, denek erabakiko lukete hau akats bat zela, zehaztapenak ez zuenez ondo funtzionatu behar zuenik esaten eta, oro har, belaunean inplementatzen zenez, funtzioa desaktibatu egingo zuten eta esan zuten: "Inork ez du hau behar, garrantzitsuena funtzionalitate nagusiak funtzionatzen duela da.” . Eta teknologia konpainiak aukera bat bezala ikusten du eta horren arabera softwarea aldatzen hasten da.
1968an, tipo ikusgarri batek, Melvin Conwayk, honako ideia hau formulatu zuen.
Sistema sortzen duen erakundea erakunde horren komunikazio egitura errepikatzen duen diseinu batek mugatzen du.
Xehetasun gehiagorekin, beste mota bateko sistemak ekoizteko, beste mota bateko enpresa baten barruan komunikazio-egitura bat ere izan behar duzu. Zure komunikazio-egitura goi-hierarkikoa bada, horrek ez dizu aukera emango Merkaturako Denboraren adierazle oso altua eman dezaketen sistemak sortzeko.
Irakurri ko ahal . Garrantzitsua da DevOps kultura edo filosofia ulertzeko DevOps-en funtsean aldatzen den gauza bakarra taldeen arteko komunikazioaren egitura da.
Prozesuaren ikuspuntutik, DevOps-en aurretik, fase guztiak linealak ziren: analitika, garapena, probak, funtzionamendua.
DevOps-en kasuan, prozesu hauek guztiak aldi berean gertatzen dira.
Merkaturatzeko denbora da egiteko modu bakarra. Prozesu zaharrean lan egin zuten pertsonentzat, itxura kosmikoa dirudi, eta, oro har, halaxe da.
Beraz, zergatik behar duzu DevOps?
Produktu digitala garatzeko. Zure enpresak ez badu produktu digitalik, DevOps ez da beharrezkoa - oso garrantzitsua da.
DevOps-ek software sekuentzialaren ekoizpenaren abiadura mugak gainditzen ditu. Bertan prozesu guztiak aldi berean gertatzen dira.
Zailtasuna handitzen da. DevOps ebanjelariek softwarea kaleratzea erraztuko dizula esaten dizutenean, zentzugabekeria da.
DevOps-ekin, gauzak konplikatuko dira.
Avitoko standeko hitzaldian, Docker edukiontzi bat zabaltzea nolakoa zen ikusi ahal izan zen, ez-errealista den zeregina. Konplexutasuna debekatu egiten da; aldi berean pilota asko egin behar dituzu malabarismoa.
DevOps-ek erabat aldatzen ditu enpresako prozesua eta antolaketa — zehatzago esanda, ez da DevOps aldatzen dena, produktu digitala baizik. DevOps-era etortzeko, oraindik prozesu hau guztiz aldatu behar duzu.
Espezialistentzako galderak
Zer daukazu? Enpresa batean lanean eta espezialista gisa garatzen ari zaren bitartean zeure buruari egin ditzakezun galderak.
Produktu digital bat sortzeko estrategiarik ba al duzu? Bada, hori dagoeneko ona da. Horrek esan nahi du zure enpresa DevOps aldera doala.
Zure enpresa dagoeneko produktu digital bat sortzen ari al da? Horrek esan nahi du beste maila bat gorago igo dezakezula eta gauzak era interesgarriagoan egin ditzakezula, berriro ere DevOps-en ikuspuntutik. Ikuspegi honetatik baino ez naiz hitz egiten.
Zure enpresa produktu digitalen nitxoan merkatuko liderretako bat al da? Spotify, Yandex, Uber orain aurrerapen teknologikoaren gailurrean dauden enpresak dira.
Egin galdera hauek zeure buruari, eta erantzun guztiak ezezkoak badira, agian ez zenuke DevOps egin behar enpresa honetan. DevOps-en gaia benetan interesgarria bada, agian... beste enpresa batera joan beharko zenuke? Zure enpresak DevOps-en sartu nahi badu, baina galdera guztiei "Ez" erantzun diezu, inoiz aldatuko ez den errinozero eder hori bezalakoa da.
Erakundea
Esan bezala, Conwayren Legearen arabera, enpresa baten antolaketa aldatzen da. Antolakuntzaren ikuspuntutik DevOps enpresa barruan sartzea eragozten duenarekin hasiko naiz.
"Putzuen" arazoa
Ingelesezko "Silo" hitza hemen errusierara "ondo" bezala itzultzen da. Arazo honen kontua hori da ez dago taldeen arteko informazio-trukerik. Talde bakoitzak bere espezializazioan sakontzen du, nabigatzeko mapa komun bat eraiki gabe.
Nolabait, horrek Moskura iritsi berri den eta oraindik metroaren mapan nola nabigatu ez dakien pertsona bat ekartzen dit gogora. Moskutarrek normalean oso ondo ezagutzen dute euren eremua, eta Mosku osoan zehar nabiga dezakete metroko mapa erabiliz. Moskura lehen aldiz etortzen zarenean, ez duzu trebetasun hori, eta desorientatuta zaude.
DevOps-ek iradokitzen du desorientazio une hori gainditzea eta sail guztiak elkarrekin lan egitea elkarrekintza-mapa komun bat eraikitzeko.
Bi faktorek hori oztopatzen dute.
Kudeaketa sistema korporatiboaren ondorioa. “Putzu” hierarkiko bereizietan eraikia dago. Esaterako, sistema hau onartzen duten enpresetan KPI batzuk daude. Bestalde, bere espezializazioaren mugak gainditzea eta sistema osoan nabigatzea zaila egiten zaion pertsona baten garunak oztopatzen du. Deserosoa besterik ez da. Imajinatu Bangkok-eko aireportuan zaudela, ez duzula azkar aurkituko. DevOps ere zaila da nabigatzea, eta horregatik jendeak dio bertara joateko gida bat aurkitu behar duzula.
Baina garrantzitsuena da DevOps-en izpirituan barneratuta dagoen ingeniari baten "putzuen" arazoa, Fowler eta beste liburu mordoa irakurri dituena, horrela adierazten dela. "putzuek" ez dizute uzten "ageriko" gauzarik egiten. Askotan elkartzen gara DevOps Moskuren ondoren, elkarrekin hitz egiten dugu eta jendea kexatzen gara:
— CI abian jartzea besterik ez genuen nahi, baina ondorioztatu zen zuzendaritzak ez zuela behar.
Hori gertatzen da hain zuzen ere CI и Etengabeko entrega-prozesua azterketa askoren mugan daude. Besterik gabe, antolakuntza mailan “putzuen” arazoa gainditu gabe, ezin izango duzu aurrera egin, zer egin eta zein tristea izan.
Enpresako prozesuan parte-hartzaile bakoitzak: backend eta frontend garatzaileak, probak, DBA, eragiketa, sarea, bere norabidean zulatzen du, eta inork ez du mapa komun bat kudeatzaileak izan ezik, zeinak nolabait monitorizatu eta kudeatzen dituen “banatu” erabiliz. eta konkistatu” metodoa.
Jendea izar edo bandera batzuengatik borrokatzen ari da, bakoitzak bere espezializazioa zulatzen ari da.
Ondorioz, hori guztia elkarrekin lotu eta hodi komun bat eraikitzeko zeregina sortzen denean, eta jada izarren eta banderen alde borrokatu beharrik ez dagoenean, galdera sortzen da: zer egin hala ere? Akordio batera iritsi behar dugu nolabait, baina inork ez digu eskolan hori nola egin irakatsi. Eskolatik irakatsi digute: zortzigarren maila - ba! - zazpigarren mailarekin alderatuta! Hemen berdin da.
Berdin al da zure enpresan?
Hori egiaztatzeko, galdera hauek egin diezazkiokezu zeure buruari.
Taldeek tresna komunak erabiltzen al dituzte eta tresna komun horien aldaketetan laguntzen dute?
Zenbat aldiz berrantolatzen dira taldeak: talde bateko espezialista batzuk beste talde batera mugitzen dira? DevOps ingurunean hori normal bihurtzen da, batzuetan pertsona batek ezin duelako ulertu beste aditu-eremu batek zer egiten duen. Beste sail batera joaten da, bertan bi astez lan egiten du sail honekin orientazio eta interakzio mapa bat egiteko.
Posible al da aldaketa batzorde bat osatzea eta gauzak aldatzea? Edo zuzendaritza eta zuzendaritza gorenen esku sendoa eskatzen du? Duela gutxi Facebook-en idatzi nuen nola ezezagun den banku bat eskabideen bidez tresnak ezartzen ari diren: eskaera bat idazten dugu, urtebetez ezartzen dugu eta ea zer gertatzen den. Hau, noski, luzea eta tristea da.
Zein garrantzitsua da zuzendariek lorpen pertsonalak jasotzea enpresaren lorpenak kontuan hartu gabe?
Galdera hauek zuk zeuk erantzuten badituzu, argiago geratuko da zure enpresan horrelako arazoren bat duzun ala ez.
Azpiegitura kode gisa
Arazo hau gainditu ondoren, lehen praktika garrantzitsua da, eta hori gabe zaila da DevOps-en aurrera egitea azpiegitura kode gisa.
Gehienetan, azpiegitura kode gisa hautematen da:
— Automatizatu dezagun dena bash-en, estali gaitezen scriptekin administratzaileek eskuzko lan gutxiago izan dezaten!
Baina hori ez da egia.
Azpiegitura kode gisa lan egiten duzun sistema informatikoa kode moduan deskribatzen duzula esan nahi du bere egoera etengabe ulertzeko.
Beste talde batzuekin batera, mapa bat sortzen duzu kode moduan, denek ulertu eta nabigatu eta nabigatu ahal izateko. Berdin du zertan egiten den - Chef, Ansible, Salt edo Kubernetes-en YAML fitxategiak erabiltzea - ez dago alderik.
Konferentzian, 2GIS-eko lankide batek kontatu zuen nola egin zuten Kubernetes-en barneko gauza, sistema indibidualen egitura deskribatzen duena. 500 sistema deskribatzeko, deskribapen hori sortzen duen tresna bereizi bat behar zuten. Deskribapen hau dagoenean, denek elkarren artean egiaztatu dezakete, aldaketak kontrolatu, nola aldatu eta hobetu, zer falta den.
Ados, bash script indibidualek normalean ez dute ulermen hori ematen. Lan egin nuen enpresetako batean, "idatzi soilik" gidoiaren izena ere bazegoen, gidoia idazten denean, baina jada ezin da irakurri. Uste dut hau ere ezaguna zaizula.
Azpiegitura kodea den bezala azpiegituraren egungo egoera deskribatzen duen kodea. Produktu, azpiegitura eta zerbitzu talde askok elkarrekin lan egiten dute kode honetan, eta, batez ere, guztiek ulertu behar dute kode honek benetan nola funtzionatzen duen.
Kodea kode-praktika onenen arabera mantentzen da: garapen bateratua, kodea berrikustea, XP-programazioa, probak, tira-eskaerak, kode azpiegituretarako CI - hau guztia egokia da eta erabil daiteke.
Kodea hizkuntza arrunta bihurtzen da ingeniari guztientzat.
Kodearen azpiegitura aldatzeak ez du denbora asko behar. Bai, azpiegitura kodeak ere izan dezake zor teknikoa. Normalean taldeek urte eta erdira topo egiten dute "azpiegitura kode gisa" inplementatzen hasi zirenetik script sorta edo are Ansible moduan, spaghetti kodea bezala idazten dutena, eta bash script-ak ere botatzen dituzte nahasketara!
Garrantzitsua da: Oraindik gauza hauek probatu ez badituzu, gogoratu Ansible ez da bash! Irakurri arretaz dokumentazioa, aztertu zer idazten duten horri buruz.
Azpiegitura kodea gisa azpiegitura kodea geruza bereizietan banatzea da.
Gure enpresan, oinarrizko 3 geruza bereizten ditugu, oso argiak eta sinpleak, baina gehiago egon daitezke. Zure azpiegitura-kodea begiratu eta egoera hori duzun ala ez esan dezakezu. Geruzarik nabarmentzen ez bada, denbora pixka bat hartu eta apur bat birfakturatu behar duzu.
oinarrizko geruza - horrela konfiguratzen dira OS, babeskopiak eta behe-mailako beste gauza batzuk, adibidez, Kubernetes oinarrizko mailan nola zabaltzen den.
Zerbitzu maila - Hauek dira garatzaileari eskaintzen dizkiozun zerbitzuak: saioa zerbitzu gisa, jarraipena zerbitzu gisa, datu-basea zerbitzu gisa, orekatzailea zerbitzu gisa, ilara zerbitzu gisa, Etengabeko entrega zerbitzu gisa - banakako taldeek dituzten zerbitzu mordoa garapenari eman diezaioke. Hau guztia modulu bereizietan deskribatu behar da zure konfigurazioa kudeatzeko sisteman.
Aplikazioak egiten diren geruza eta aurreko bi geruzen gainean nola zabalduko diren deskribatzen du.
Kontrol-galderak
Zure enpresak ba al du azpiegitura biltegi komun bat? Zor teknikoa kudeatzen al duzu zure azpiegituretan? Garapen-praktikak erabiltzen al dituzu azpiegitura-biltegi batean? Zure azpiegitura geruzatan zatituta al dago? Base-service-APP diagrama egiaztatu dezakezu. Zein zaila da aldaketa bat egitea?
Aldaketak egiteko egun eta erdi behar izan dela ikusi baduzu, horrek esan nahi du zor teknikoa duzula eta horrekin lan egin behar duzula. Zure azpiegitura kodean zor tekniko bat topatu duzu. Halako istorio asko gogoratzen ditut, CCTL batzuk aldatzeko, azpiegitura-kodearen erdia berridatzi behar zenean, sormenak eta dena automatizatzeko gogoak ekarri baitzuen dena nonahi korrodituta egotea, helduleku guztiak kenduta, eta beharrezkoa da birfaktorea.
Etengabeko entrega
Konpara dezagun zordunketa kredituarekin. Lehenik eta behin azpiegituraren deskribapena dator, nahiko oinarrizkoa izan daitekeena. Ez duzu guztia zehatz-mehatz deskribatu beharrik, baina oinarrizko deskribapen batzuk behar dira horrekin lan egin ahal izateko. Bestela, ez dago argi zer egin hurrengo entrega jarraituarekin. Praktika hauek guztiak aldi berean garatzen dira DevOps-era iristen zarenean, baina zer duzun eta nola kudeatu ulertzen hasten da. Hau da, hain zuzen, azpiegitura kode gisa praktika.
Behin argi geratzen zaizula eta nola kudeatu, garatzaile-kodea ekoizpenera ahalik eta azkarren nola bidali asmatzen hasten zara. Garatzailearekin batera esan nahi dut - "putzuen" arazoa gogoratzen dugu, hau da, ez dira pertsona indibidualak sortzen, talde bat baizik.
Gurekin gaudenean Vania Evtukhovich lehen liburua ikusi zuen Jez Umila eta egile-taldeak "Etengabeko entrega", 2009an kaleratu zena, denbora luzez pentsatu genuen bere izenburua errusierara nola itzuli. “Etengabe entregatu” bezala itzuli nahi izan zuten, baina, tamalez, “Etengabeko entrega” bezala itzuli zen. Gure izenean errusiar zerbait dagoela iruditzen zait, presioarekin.
Etengabe bitartekoak ematea
Produktuaren biltegian dagoen kodea beti deskargatu daiteke ekoizpenera. Agian ez da deflatuta egongo, baina beti dago horretarako prest. Ondorioz, beti idazten duzu kodea azaltzeko zaila den antsietate-sentsazio batekin isilpean. Askotan agertzen da azpiegitura kodea zabaltzen duzunean. Antsietate sentsazio hori egon beharko litzateke: kodea apur bat ezberdinean idazteko aukera ematen duten garuneko prozesuak abiarazten ditu. Hori garapenaren barruko arauetan jaso behar da.
Etengabe entregatzeko, azpiegitura plataforma batean exekutatzen den artefaktu formatua behar duzu. Azpiegitura-plataforma batean formatu ezberdinetako "bizi-hondakinak" botatzen badituzu, bateratu egiten da, mantentzea zaila da eta zor teknikoaren arazoa sortzen da. Artefaktuaren formatua lerrokatu egin behar da - hau ere zeregin kolektiboa da: denok elkartu, burmuina kiskaldu eta formatu hau asmatu behar dugu.
Artifaktua etengabe hobetzen da eta ekoizpen-ingurunera egokitzeko aldatzen da entrega-hodietan zehar mugitzen den heinean. Artefaktu bat kanalizazioan zehar mugitzen denean, etengabe topatzen ditu gauza deseroso batzuk, produkzioan jartzen duzun artefaktuak aurkitzen dituenaren antzekoak. Garapen klasikoan inplementazioa egiten duen sistema-administratzaile batek egiten badu, DevOps prozesuan hau gertatzen da denbora guztian: hemen proba batzuekin probatu dute, hemen Kubernetes kluster batera bota dute, gutxi gorabehera antzekoa dena. produkziora, eta, bat-batean, karga probak hasi ziren.
Honek zertxobait gogorarazten du Pac-Man jokoa - artefaktuak istorioren bat igarotzen du. Aldi berean, garrantzitsua da kontrolatzea kodea benetan istoriotik pasatzen den eta nolabait zure ekoizpenarekin erlazionatuta dagoen. Ekoizpeneko istorioak Etengabeko Entrega prozesura eraman daitezke: horrela izan zen zerbait erori zenean, orain programatu dezagun agertoki hau sistema barruan. Kodeak ere eszenatoki hau igaroko du bakoitzean, eta hurrengoan ez duzu arazo honekin topatuko. Zure bezeroari heldu baino askoz lehenago ikasiko duzu horri buruz.
Inplementazio estrategia desberdinak. Adibidez, AB probak edo canary inplementazioak erabiltzen dituzu kodea bezero ezberdinetan probatzeko, kodearen funtzionamenduari buruzko informazioa lortzeko eta 100 milioi erabiltzaileri zabaltzen denean baino askoz lehenago.
"Etengabe entregatu" itxura hau du.
Entrega-prozesua Dev, CI, Test, PreProd, Prod ez da ingurune bereizia, zure artefaktua igarotzen duten suaren aurkako batuketak dituzten etapak edo estazioak dira.
Oinarrizko Zerbitzuaren APP gisa deskribatzen den azpiegitura kodea baduzu, laguntzen du ez ahaztu gidoi guztiak, eta idatzi artefaktu honen kode gisa, artefaktua sustatu eta aldatu ahala.
Autotest galderak
Ezaugarrien deskribapenetik produkziora atera arte kasuen % 95ean aste bat baino gutxiago da? Artefaktuaren kalitatea hobetzen al da hodiaren fase bakoitzean? Ba al dago pasatzen duen istoriorik? Inplementazio estrategia desberdinak erabiltzen dituzu?
Erantzun guztiak baiezkoa badira, oso polita zara! Idatzi zure erantzunak iruzkinetan - pozik egongo naiz).
iritzia
Hau da praktikarik zailena. DevOpsConf konferentzian, Infobipeko lankide bat, horri buruz hitz egiten, apur bat nahastuta zegoen bere hitzetan, hau benetan oso praktika konplexua baita dena kontrolatu behar duzulako!
Esaterako, aspaldi, Qik-en lan egiten nuen eta konturatu ginen dena kontrolatu behar genuela. Hori egin genuen, eta orain 150 elementu ditugu Zabbixen, etengabe kontrolatzen direnak. Beldurra zen, zuzendari teknikoak hatza bihurritu zuen tenpluan:
- Mutilak, zergatik bortxatzen duzu zerbitzaria argi ez den zerbaitekin?
Baina orduan gertakari bat gertatu zen, hau benetan estrategia polita dela erakutsi zuena.
Zerbitzuetako bat etengabe huts egiten hasi zen. Hasieran, ez zen huts egin, eta hori interesgarria da, kodea ez zen bertan gehitu, oinarrizko broker bat zelako, ia negozio-funtzionalitaterik ez zuena - zerbitzu indibidualen artean mezuak bidaltzen zituen. Zerbitzua ez zen aldatu 4 hilabetez, eta bat-batean huts egiten hasi zen "Segmentazio akatsa" errorearekin.
Harrituta geratu ginen, gure zerrendak ireki genituen Zabbixen, eta ondorioztatu zen duela aste eta erdi, broker honek erabiltzen duen API zerbitzuko eskaeren portaera asko aldatu zela. Jarraian, mezu mota jakin bat bidaltzeko maiztasuna aldatu zela ikusi genuen. Geroago jakin genuen hauek Android bezeroak zirela. Galdetu genuen:
— Mutilak, zer gertatu zitzaizuen duela aste eta erdi?
Horren harira, istorio interesgarri bat entzun genuen UI-a birdiseinatu zutenari buruz. Nekez esango du inork berehala HTTP liburutegia aldatu duela. Android bezeroentzat, bainugelan xaboia aldatzea bezalakoa da; ez dira gogoratzen. Ondorioz, 40 minutuko elkarrizketaren ondoren, jakin genuen HTTP liburutegia aldatu zutela, eta ordutegi lehenetsiak aldatu zirela. Horrek API zerbitzariaren trafikoaren portaera aldatu zuen, eta horrek broker barruan lasterketa bat eragin zuen egoera bat eragin zuen eta huts egiten hasi zen.
Jarraipen sakonik gabe, oro har, ezinezkoa da hau irekitzea. Antolakuntzak “putzuen” arazoa badu oraindik, denek elkarri dirua botatzen diotenean, hau urtez bizi daiteke. Zerbitzaria berrabiarazi besterik ez duzu, arazoa konpontzea ezinezkoa delako. Dauzkazun gertaera guztien jarraipena, jarraipena, jarraipena egiten duzunean eta monitorizazioa proba gisa erabiltzen dituzunean - idatzi kodea eta berehala nola monitorizatu behar den adierazi, baita kode moduan ere (dagoeneko azpiegitura kode gisa daukagu), dena argi geratzen da nola. ahurrean. Arazo konplexu horiek ere erraz jarraitzen dira.
Bildu entrega-prozesuaren fase bakoitzean artefaktuarekin gertatzen denari buruzko informazio guztia, ez ekoizpenean.
Kargatu monitorizazioa CIra, eta oinarrizko gauza batzuk dagoeneko ikusgai egongo dira bertan. Geroago Test, PredProd eta karga proban ikusiko dituzu. Bildu informazioa fase guztietan, neurketak, estatistikak ez ezik, erregistroak ere: aplikazioa nola zabaldu zen, anomaliak - bildu dena.
Bestela zaila izango da hura asmatzea. Dagoeneko esan dut DevOps konplexuagoa dela. Konplexutasun horri aurre egiteko, analisi normalak izan behar dituzu.
Autokontrolerako galderak
Zure jarraipena eta erregistroa garatzeko tresna al da zuretzat? Kodea idaztean, zure garatzaileek, zu barne, pentsatzen al dute nola kontrolatu?
Bezeroen arazoen berri al duzu? Bezeroa hobeto ulertzen al duzu monitorizaziotik eta erregistrotik? Sistema hobeto ulertzen al duzu monitorizaziotik eta erregistrotik? Sistema aldatzen al duzu sistemaren joera hazten ari dela ikusi duzulako eta beste 3 aste barru dena hilko dela ulertzen duzulako?
Hiru osagai hauek dituzunean, zure enpresan zer azpiegitura-plataforma duzun pentsa dezakezu.
Azpiegitura plataforma
Kontua ez da enpresa bakoitzak dituen tresna ezberdinen multzoa denik.
Azpiegitura plataforma baten helburua da talde guztiek tresna hauek erabiltzea eta elkarrekin garatzea.
Argi dago azpiegitura plataformako pieza indibidualen garapenaz arduratzen diren talde bereiziak daudela. Baina, aldi berean, ingeniari bakoitzak azpiegitura plataformaren garapenaren, errendimenduaren eta sustapenaren erantzukizuna du. Barne mailan ohiko tresna bihurtzen da.
Talde guztiek azpiegitura plataforma garatzen dute eta arreta handiz tratatzen dute beren IDE gisa. Zure IDEan plugin desberdinak instalatzen dituzu dena polita eta azkarra izan dadin, eta laster-teklak konfiguratzen dituzu. Sublime, Atom edo Visual Studio Code irekitzean, kode-erroreak agertzen dira bertan eta lan egitea ezinezkoa dela konturatzen zara, berehala triste sentitzen zara eta zure IDEa konpontzera korrika egiten duzu.
Tratatu zure azpiegitura plataforma modu berean. Zerbait gaizki dagoela ulertzen baduzu, utzi eskaera bat zuk zeuk konpondu ezin baduzu. Zerbait sinplea bada, edita ezazu zuk zeuk, bidali pull request bat, mutilek kontuan hartuko dute eta gehituko dute. Hau garatzailearen buruan ingeniaritza tresnen ikuspegi apur bat desberdina da.
Azpiegitura plataformak artefaktua garapenetik bezerora transferitzea bermatzen du kalitatearen etengabeko hobekuntzarekin. IP produkzioan kodeari gertatzen zaizkion istorio multzo batekin programatzen da. Garapen urteetan zehar, istorio horietako asko daude, horietako batzuk bakarrak dira eta zurekin soilik erlazionatzen dira; ezin dira Googlen bilatu.
Une honetan, azpiegitura plataforma zure abantaila lehiakorra bihurtzen da, lehiakidearen tresnan ez dagoen zerbait barneratua duelako. Zenbat eta IP sakonagoa izan, orduan eta abantaila lehiakorra handiagoa izango duzu merkaturatzeko denborari dagokionez. Hemen agertzen da saltzaileen blokeo arazoa: Beste norbaiten plataforma har dezakezu, baina beste norbaiten esperientzia erabiliz, ez duzu ulertuko zein garrantzitsua den zuretzat. Bai, enpresa guztiek ezin dute Amazon bezalako plataforma bat eraiki. Lerro zaila da, non konpainiaren esperientzia merkatuan duen posizioarekin garrantzitsua den eta ezin duzu hor saltzaileen blokeorik erabili. Hau ere garrantzitsua da hausnartzea.
Eskema
DevOps enpresa bateko praktika eta prozesu guztiak konfiguratzen lagunduko dizun azpiegitura plataforma baten oinarrizko diagrama da.
Ikus dezagun zertan datzan.
Baliabideak orkestratzeko sistema, CPU, memoria, diskoa aplikazioei eta beste zerbitzu batzuei eskaintzen diena. Honen gainean - maila baxuko zerbitzuak: monitorizazioa, erregistroa, CI/CD Engine, artefaktuen biltegiratzea, azpiegitura sistema-kode gisa.
Goi-mailako zerbitzuak: datu-basea zerbitzu gisa, ilarak zerbitzu gisa, Load Balance zerbitzu gisa, irudien tamaina aldatzea zerbitzu gisa, Big Data fabrika zerbitzu gisa. Honen gainean - etengabe aldatutako kodea zure bezeroari bidaltzen dion kanalizazioa.
Zure softwareak bezeroarentzat funtzionatzen duenari buruzko informazioa jasotzen duzu, aldatu, kode hau berriro hornitu, informazioa jasotzen duzu eta, beraz, etengabe garatzen dituzu bai azpiegitura-plataforma bai zure softwarea.
Diagraman, entrega-hodiak etapa asko ditu. Baina adibide gisa ematen den diagrama eskematiko bat da, ez dago banan-banan errepikatu beharrik. Faseek zerbitzuekin elkarreragiten dute zerbitzuak balira bezala: plataformako adreilu bakoitzak bere istorioa darama: baliabideak nola esleitzen diren, aplikazioa nola abiarazten den, baliabideekin funtzionatzen duen, kontrolatzen den eta aldatzen den.
Garrantzitsua da ulertzea plataformaren atal bakoitzak istorio bat daramala, eta galdetu zeure buruari zein istorio daraman adreilu honek, agian bota egin beharko litzateke eta hirugarrenen zerbitzu batekin ordezkatu beharko litzateke. Adibidez, posible al da adreilu baten ordez Okmeter instalatzea? Agian mutilek guk baino askoz gehiago garatu dute esperientzia hori. Baina agian ez - agian esperientzia berezia dugu, Prometheus instalatu eta gehiago garatu behar dugu.
Plataformaren sorrera
Komunikazio prozesu konplexua da. Oinarrizko praktikak dituzunean, eskakizunak eta estandarrak garatzen dituzten ingeniari eta espezialista ezberdinen arteko komunikazioa hasten zara, eta etengabe aldatzen dituzu tresna eta ikuspegi ezberdinetara. DevOps-en dugun kultura garrantzitsua da hemen.
Kulturarekin dena oso erraza da - elkarlana eta komunikazioa da, hau da, elkarren artean eremu komun batean lan egiteko gogoa, instrumentu bat elkarrekin maneiatzeko gogoa. Hemen ez dago suziri zientziarik - dena oso sinplea da, hutsala. Esaterako, denok bizi gara sarreran eta garbi mantentzen dugu –halako kultura maila–.
Zer daukazu?
Berriz ere, zeure buruari egin ditzakezun galderak.
Azpiegitura plataforma dedikatua al da? Nor da bere garapenaren arduraduna? Ulertzen al dituzu zure azpiegitura plataformaren abantaila lehiakorrak?
Galdera hauek etengabe egin behar dizkiozu zeure buruari. Zerbait hirugarrenen zerbitzuetara transferitu badaiteke, transferitu egin beharko litzateke; hirugarrenen zerbitzu bat zure mugimendua blokeatzen hasten bada, orduan zure baitan sistema bat eraiki behar duzu.
Beraz, DevOps...
... sistema konplexua da, izan behar du:
- Produktu digitala.
- Produktu digital hau garatzen duten negozio moduluak.
- Kodea idazten duten produktu-taldeak.
- Etengabeko entrega-praktikak.
- Plataformak zerbitzu gisa.
- Azpiegitura zerbitzu gisa.
- Azpiegitura kode gisa.
- Fidagarritasuna mantentzeko praktika bereiziak, DevOps-en barneratuak.
- Hori guztia deskribatzen duen feedback praktika.
Diagrama hau erabil dezakezu, bertan zure enpresan duzuna nolabait nabarmenduz: garatu al da edo oraindik garatu behar da.
Pare bat aste barru amaituko da . RIT++-ren parte gisa. Zatoz hitzaldira, non etengabeko entregari, azpiegiturari kode gisa eta DevOps eraldaketari buruzko txosten eder asko aurkituko dituzu. , azken prezioaren azken eguna maiatzaren 20a da
Iturria: www.habr.com