Azkenaldian, horrelako iragarkiak Internetez gainezka egin dute. Soldata atsegina izan arren, ezin da lotsatzen utzi heresia basatia idatzita dagoelako barruan. Hasieran suposatzen da "DevOps" eta "ingeniaria" nolabait hitz batean itsatsi daitezkeela, eta, ondoren, ausazko eskakizunen zerrenda dago, horietako batzuk sistemaren administratzaile hutsetik argi eta garbi kopiatzen direla.
Post honetan pixka bat hitz egin nahiko nuke nola iritsi garen bizitzaren puntu honetara, zer den benetan DevOps eta zer egin orain.
Halako lanpostu hutsak modu guztietan gaitzetsi daitezke, baina kontua da: asko dira, eta horrela funtzionatzen du merkatuak une honetan. Devops konferentzia bat egin genuen eta argi eta garbi adierazi genuen: " - Ez DevOps ingeniarientzat." Askori arraroa eta basatia irudituko zaio hori: zergatik ekitaldi guztiz komertziala egiten ari den jendea merkatuaren aurka doa. Orain dena azalduko dugu.
Kultura eta prozesuei buruz
Has gaitezen DevOps ez dela ingeniaritza diziplina bat. Dena hasi zen historikoki ezarritako rolen banaketak ez duela balio produktuen kalitaterako. Programatzaileek soilik programatzen dutenean, baina probei buruz ezer entzun nahi ez dutenean, softwarea akatsez josita dago. Administratzaileei ez zaien axola nola edo zergatik idazten den softwarea, laguntza infernu bihurtzen da.
Adibidez, sistema-administratzaile baten eta zerbitzuen kudeaketarako SRE ikuspegiaren arteko aldea deskribatzea . Ikerketa interesgarriak egin dira barruan - Argi dago garatzaile onenek, nolabait, ekoizpenean aldaketa berriak orduko behin baino azkarrago zabaltzea lortzen dutela. Eskuekin ez dute proba % 10 baino gehiago (hortik ikus daiteke ). Nola egiten dute hau? "Excel edo hil" dio txostenaren goiburuetako batek. Estatistika hauen azterketaren testuinguruan eztabaidatzeko, Baruch Sadogurskyren hitzaldira jo dezakezu. gure beste hitzaldian, Heisenbug.
«Bideen artean akordiorik ez dagoenean,
Gauzak ez zaizkie ondo aterako,
Eta ez da ezer aterako, oinazea baizik.
Bazen behin Zisne bat, Txarramarroa eta Pikea..."
Zure ustez, web-programatzaileen zein partek ulertzen ditu haien aplikazioak ekoizpenean erabiltzen diren baldintzak? Horietako zenbat administratzaileengana joango dira eta datu-basea huts egiten bada zer gertatuko den asmatzen saiatuko dira? Eta haietako zein joango da probatzaileengana eta eskatuko die probak zuzen idazten irakasteko? Eta segurtasun zaindariak, produktuen kudeatzaileak eta beste pertsona mordoa ere badaude.
DevOps-en ideia orokorra rolen eta sailen arteko lankidetza sortzea da. Lehenik eta behin, hori ez da modu egokian konfiguratutako software batzuekin lortzen, komunikazioaren praktikarekin baizik. DevOps kultura, praktika, metodologia eta prozesuei buruzkoa da. Ez dago galdera hauei erantzun diezaiekeen ingeniaritza espezialitaterik.
Zirkulu ikusgarria
Nondik sortu zen orduan “devops engineering” diziplina? Bertsio bat dugu! DevOps ideiak onak ziren, hain onak non euren arrakastaren biktima bihurtu ziren. Beren giro propioa duten erreklutatzaile eta giza trafikatzaile itzaltsu batzuk hasi ziren gai honen inguruan bueltaka.
Imajinatu: atzo shawarma egiten ari zinen Khimkin, eta gaur jada gizon handia zara, senior erreklutatzailea. Hautagaiak bilatzeko eta hautatzeko prozesu oso bat dago, dena ez da erraza, ulertu behar duzu. Demagun departamentu bateko buruak esaten duela: bilatu X-en espezialista. X-ri "ingeniari" hitza esleitzen diogu, eta amaitu dugu. Linux behar duzu? Beno, hau da, zalantzarik gabe, Linux ingeniaria, DevOps nahi baduzu, orduan DevOps ingeniaria. Lanpostua titulu batez ez ezik, testuren bat ere sartu behar da barruan. Modurik errazena Google-ren gako-hitz multzo bat sartzea da, zure irudimenaren arabera. DevOps-ek bi hitzek osatzen dute: "Dev" eta "Ops", hau da, garatzaileei eta administratzaileei lotutako gako-hitzak bildu behar ditugula pila batean. Honela agertzen dira hutsik dauden 42 programazio-lengoaietan eta Kubernetes eta Swarm aldi berean erabiltzen dituzten 20 urteko gaitasunari buruz. Lan-diagrama.
Horrela errotu da jendearen buruan "devops" superheroi jakin baten irudi zentzugabe eta errukigabea, Jenkinsera hedatzeko denak konfiguratuko dituena, eta zoriona etorriko da. Ai, dena hain sinplea balitz. "Eta horrela ere sistema-administratzaileak ehizatu ditzakezu", uste du HR-k, "modan dagoen hitza da, gako-hitzak berdinak dira, amua hartu beharko lukete".
Eskariak eskaintza sortzen du, eta zabor hutsune horiek guztiak konturatu ziren sistema-administratzaile kopuru zoro batekin bete dira: dena egin dezakezu lehen bezala, baina hainbat aldiz gehiago lortu zure burua "devops" deituz. SSH bidez zerbitzariak eskuz banan-banan konfiguratu dituzun bezala, konfiguratzen jarraituko duzu, baina orain hau ustez devops praktika bat da. Fenomeno konplexua da hau, neurri batean administratzaile klasikoen gutxiestearekin eta DevOps-en inguruko hypearekin lotuta dagoena, baina, oro har, gertatu zena gertatu zen.
Beraz, eskaintza eta eskaria ditugu. Bere burua elikatzen duen gurpil zoroa. Horren aurka borrokatzen ari gara (DevOops konferentzia sortuz barne).
Jakina, beren burua "devops" izena aldatu duten sistema-administratzaileez gain, badira beste parte-hartzaile batzuk - adibidez, SRE profesionalak edo Infrastructure-as-Code garatzaileak.
Jendeak DevOps-en egiten duena (benetan)
Beraz, DevOps praktikak ikasten eta aplikatzen aurrera egin nahi duzu. Baina nola egin hau, zein norabidetara begiratu? Jakina, ez zenuke itsu-itsuan gako-hitz ezagunetan fidatu behar.
Lana badago, norbaitek egin beharko luke. Dagoeneko jakin dugu hauek ez direla "devops ingeniariak", orduan nor dira? Zuzenagoa dirudi hori ez postuen arabera formulatzea, lan arlo zehatzen arabera baizik.
Lehenik eta behin, DevOps-en muina jo dezakezu: prozesuak eta kultura. Kultura negozio motela eta zaila da, eta tradizionalki kudeatzaileen ardura bada ere, denek parte hartzen dute era batera edo bestera, programatzaileetatik hasi eta administratzaileetaraino. Duela hilabete pare bat Tim Lister :
“Kultura erakundearen oinarrizko balioek zehazten dute. Normalean jendea ez da horretaz ohartzen, baina urte askoan aholkularitzan lan eginda, ohartzera ohituta gaude. Enpresa batean sartzen zara eta literalki minutu gutxiren buruan gertatzen ari dena sentitzen hasten zara. Horri "zaporea" deitzen diogu. Batzuetan usain hau oso ona da. Batzuetan goragalea eragiten du. (...) Ezin duzu kultura bat aldatu ekintza zehatzen atzean dauden balioak eta sinesmenak ulertu arte. Jokabidea behatzeko erraza da, baina sinesmenak bilatzea zaila da. DevOps gauzak gero eta konplexuagoak direnaren adibide bikaina da.
Gaiaren zati tekniko bat ere badago, noski. Zure kode berria hilabete batean probatzen bada, baina urtebete beranduago kaleratzen bada, eta fisikoki ezinezkoa bada guztia bizkortzea, baliteke praktika onak beteko ez izatea. Praktika onak tresna onek onartzen dituzte. Adibidez, Infrastructure-as-Code ideia kontuan hartuta, AWS CloudFormation eta Terraform-etik Chef-Ansible-Puppet-era edozer erabil dezakezu. Hori guztia ezagutu eta egiteko gai izan behar duzu, eta hori dagoeneko nahiko ingeniaritza diziplina da. Garrantzitsua da kausa eta efektua ez nahastea: lehenik eta behin SREren printzipioen arabera lan egiten duzu eta, ondoren, printzipio horiek soluzio tekniko zehatz batzuen moduan ezartzen dituzu. Aldi berean, SRE metodologia oso integrala da, eta ez dizu esaten Jenkins nola konfiguratu, baina oinarrizko bost printzipiori buruz:
- Rolen eta sailen arteko komunikazioa hobetu
- Akatsak lanaren osagai gisa onartzea
- Aldaketak pixkanaka eginez
- Tresneria eta beste automatizazio batzuk erabiltzea
- Neurtu daitekeen guztia neurtzea
Hau ez da adierazpen multzo bat bakarrik, zehatz bat baizik . Adibidez, akatsak onartzeko bidean, arriskuak ulertu beharko dituzu, zerbitzuen erabilgarritasuna eta erabilgarritasuna neurtu beharko duzu SLI bezalako zerbait erabiliz () eta SLO (), postmortems idazten ikasi eta idaztea beldurgarria izan ez dadin.
SRE diziplinan, tresnen erabilera arrakastaren zati bat baino ez da, nahiz eta garrantzitsua izan. Teknikoki etengabe garatu behar dugu, munduan zer gertatzen den eta gure lanean nola aplika daitekeen aztertu.
Era berean, Cloud Native irtenbideak oso ezagunak bihurtu dira. Cloud Native Computing Foundation-ek gaur egun definitzen duen moduan, Cloud Native teknologiek erakundeei aplikazio eskalagarriak garatzeko eta exekutatzeko aukera ematen diete egungo ingurune dinamikoetan, hala nola hodei publiko, pribatu eta hibridoetan. Adibideak edukiontziak, zerbitzu-sareak, mikrozerbitzuak, azpiegitura aldaezinak eta API deklaratzaileak dira. Teknika horiei guztiei esker, akoplatutako sistemak elastikoak, kudeagarriak eta oso behagarriak izaten jarraitzen dute. Automatizazio onak aukera ematen die ingeniariek aldaketa handiak egin ditzakete maiz eta aurreikus daitezkeen emaitzekin, lanik egin gabe. Hori guztia, Docker eta Kubernetes bezalako tresna ezagunen pila batek onartzen du.
Definizio nahiko korapilatsu eta zabal hau eremua ere nahiko konplexua delako da. Alde batetik, sistema honi aldaketa berriak gehitu behar zaizkiola esaten da. Bestetik, asmatzea nola sortu edukiontzidun ingurune moduko bat, zeinetan akoplatutako zerbitzuak softwareak definitutako azpiegitura batean bizi diren eta bertan ematen diren etengabeko CI/CD erabiliz, eta DevOps praktikak eraikitzea honen guztiaren inguruan - honek guztiak gehiago eskatzen du. batek baino txakurra jan.
Zer egin honekin guztiarekin
Bakoitzak bere erara konpontzen ditu arazo hauek: adibidez, hutsik gabeko lanpostu arruntak argitara ditzakezu gurpil zoroa hausteko. DevOps eta Cloud Native bezalako hitzek zer esan nahi duten jakin dezakezu eta behar bezala erabil ditzakezu. DevOps-en garatu dezakezu eta zure adibidearen bidez planteamendu egokiak erakutsi.
Konferentzia bat egiten ari gara , hitz egin berri ditugun gauzetan sakontzeko aukera ematen duena. Horretarako hainbat txosten talde daude:
- Prozesuak eta kultura;
- Gunearen fidagarritasunaren ingeniaritza;
- Hodei Natiboa;
Nola aukeratu nora joan? Puntu sotil bat dago hemen. Alde batetik, DevOps interakzioari buruzkoa da, eta benetan nahi dugu bloke ezberdinetako aurkezpenetara joatea. Bestalde, kongresura ataza zehatz batean kontzentratzeko etorri den garapen-kudeatzailea bazara, inork ez zaitu mugatzen; jakina, prozesuei eta kulturari buruzko blokeo bat izango da. Ez ahaztu hitzaldiaren ondoren grabazioak izango dituzula (erantzunak egiteko formularioa bete ondoren), gerora beti ikusi ahal izateko garrantzi gutxiagoko aurkezpenak.
Jakina denez, jardunaldian bertan ezin zara aldi berean hiru bidetan ibili, beraz, egitaraua antolatzen dugu, ordu-tarte bakoitzak gustu guztietarako gaiak izan ditzan.
DevOps ingeniaria bazara zer egin behar den ulertzea besterik ez da geratzen! Lehenik eta behin, saiatu benetan zer egiten duzun zehazten. Normalean hitz honi deitzea gustatzen zaie:
- Azpiegituretan lan egiten duten garatzaileak. SRE eta Cloud Nativeri buruzko txosten-taldeak dira egokienak zuretzat.
- Sistema administratzaileak. Hemen konplikatuagoa da. DevOops ez da sistemaren administrazioari buruz. Zorionez, sistemaren administrazioaren gaiari buruzko hitzaldi, liburu, artikulu, bideo eta abar bikain asko daude Interneten. Bestalde, kultura eta prozesuak ulertzeko, hodeiko teknologiak eta Cloud Native-rekin bizitzaren xehetasunak ezagutzeko interesa baduzu, orduan ikustea gustatuko litzaiguke! Pentsa hau: administrazioa egiten ari zara, eta orduan zer egingo duzu? Zure burua bat-batean egoera desatsegin batean aurkitzea ekiditeko, orain ikasi beharko zenuke.
Bada beste aukera bat: jarraitzen duzu eta zarela aldarrikatzen jarraitzen duzu zehazki, DevOps ingeniari bat eta kito, horrek esan nahi duena. Orduan huts egin behar zaitugu, DevOops ez da DevOps ingeniarientzako hitzaldi bat!
Irristatu Munichen
DevOops 2020 Mosku apirilaren 29tik 30era ospatuko da Moskun, sarrerak dagoeneko eskuragarri daude .
Bestela, dezakezu otsailaren 8ra arte. Kontuan izan inprimakia betetzerakoan, zure txostenari etekin handiena aterako dion xede-publikoa hautatu behar duzula (ezusteko bat dago zerrenda barruan lurperatuta).
Iturria: www.habr.com