Kaixo, Habr! Aurretik, Azpiegituraren bizitza kode paradigma gisa salatu nuen eta ez nuen ezer eskaini egungo egoera konpontzeko. Gaur itzuli naiz kontatzeko zein planteamendu eta praktikak etsipenaren amildegitik ihes egiten lagunduko dizuten eta egoera bide onetik bideratzen.
Aurreko artikulu batean Arlo honi buruzko nire inpresioak partekatu nituen, arlo honetako egungo egoerari buruz hausnartzen saiatu nintzen, eta garatzaile guztiek ezagutzen dituzten praktika estandarrak lagun zitezkeela ere iradoki nuen. Badirudi bizitzaren inguruan kexa asko egon zirela, baina ez zegoen egungo egoeratik ateratzeko proposamenik.
Nor garen, non gauden eta zer arazo ditugun
Une honetan Sre Onboarding Team-ean gaude, sei programatzailek eta hiru azpiegitura ingeniarik osatzen dutena. Guztiok saiatzen ari gara Azpiegitura kode gisa (IaC) idazten. Hau egiten dugu, funtsean, kodea idazten dakigulako eta garatzaile "batez bestekoaren gainetik" izatearen historia dugulako.
- Abantaila batzuk ditugu: formazio jakin bat, praktiken ezagutza, kodea idazteko gaitasuna, gauza berriak ikasteko gogoa.
- Eta atal bat dago, eta hori ere negatiboa da: azpiegituren hardwareari buruzko ezagutza falta.
Gure IaC-n erabiltzen dugun teknologia pila.
- Baliabideak sortzeko Terraform.
- Irudiak muntatzeko paketatzailea. Hauek Windows, CentOS 7 irudiak dira.
- Jsonnet drone.io-n eraikuntza indartsu bat egiteko, baita packer json eta gure terraform moduluak sortzeko ere.
- Azure.
- Ansible irudiak prestatzerakoan.
- Python zerbitzu osagarrietarako eta hornikuntzarako scriptetarako.
- Eta hori guztia VSCode-n taldekideen artean partekatutako pluginekin.
Nire ondorioa honelakoa zen: saiatu nintzen (lehenik nire baitan) baikortasuna pizten, esan nahi nuen ezagutzen ditugun planteamendu eta praktikak probatuko ditugula arlo honetan dauden zailtasun eta konplexuei aurre egiteko.
Une honetan IaC arazo hauekin ari gara borrokan:
- Kodea garatzeko tresnen eta bitartekoen inperfekzioa.
- Inplementazio motela. Azpiegitura mundu errealaren parte da, eta motela izan daiteke.
- Planteamendu eta praktika falta.
- Berriak gara eta ez dakigu gauza handirik.
Muturreko programazioa (XP) erreskaterako
Garatzaile guztiek ezagutzen dituzte Muturreko Programazioa (XP) eta horren atzean dauden praktikak. Gutako askok lan egin dugu ikuspegi honekin, eta arrakastatsua izan da. Beraz, zergatik ez erabili bertan ezarritako printzipioak eta praktikak azpiegituren erronkak gainditzeko? Planteamendu hori hartzea erabaki genuen eta ea zer gertatzen den.
XP ikuspegiaren aplikagarritasuna zure industriarako egiaztatzeaHona hemen XP egokia den ingurunearen deskribapena eta gurekin nola erlazionatzen den:
1. Softwarearen eskakizunak dinamikoki aldatzea. Argi genuen zein zen azken helburua. Baina xehetasunak alda daitezke. Guk geuk erabakitzen dugu taxia nora joan behar dugun, beraz, eskakizunak aldian-aldian aldatzen dira (guk bakarrik). Automatizazioa bera egiten duen SRE taldea hartzen badugu eta berak mugatzen dituen baldintzak eta lan-esparrua, orduan puntu hau ondo egokitzen da.
2. Teknologia berriak erabiliz denbora finkoko proiektuek eragindako arriskuak. Guretzat ezezagunak diren gauza batzuk erabiltzean arriskuak aurki ditzakegu. Eta hau da %100ean gure kasua. Gure proiektu osoa guztiz ezagutzen ez genituen teknologien erabilera izan zen. Oro har, etengabeko arazoa da, izan ere... Azpiegituren sektorean teknologia berri asko sortzen ari dira etengabe.
3,4. Garapen talde hedatu txikia eta batera kokatua. Erabiltzen ari zaren teknologia automatizatuak proba unitarioak eta funtzionalak egiteko aukera ematen du. Bi puntu hauek ez zaizkigu guztiz egokitzen. Lehenik eta behin, ez gara talde koordinatu bat, eta bigarrenik, bederatzi gara, talde handitzat har daitezkeenak. Nahiz eta, talde "handi" baten definizio batzuen arabera, asko 14 pertsona baino gehiago izan.
Ikus ditzagun XP praktika batzuk eta nola eragiten duten feedbackaren abiaduran eta kalitatean.
XP Feedback Loop printzipioa
Nire ustez, feedbacka galderaren erantzuna da, ondo egiten ari al naiz, hara goaz? XP-k jainkozko eskema bat du horretarako: denbora-feedback begizta. Interesgarria da zenbat eta baxuago egon, orduan eta azkarrago lortuko dugula OSak beharrezko galderei erantzuteko.
Eztabaidarako gai nahiko interesgarria da, gure IT industrian posible dela sistema eragile bat azkar lortzea. Imajinatu zein mingarria den sei hilabetez proiektu bat egitea eta orduan bakarrik jakitea hasieran akats bat egon zela. Hau diseinuan eta sistema konplexuen edozein eraikuntzan gertatzen da.
Gure IaC-ren kasuan, feedbackak laguntzen gaitu. Berehala doikuntza txiki bat egingo dut goiko diagraman: kaleratze planak ez du hileko ziklorik, baina egunean hainbat aldiz gertatzen da. Xehetasun gehiagorekin aztertuko ditugun OS ziklo honi lotutako praktika batzuk daude.
Garrantzitsua: iritzia goian adierazitako arazo guztien konponbidea izan daiteke. XP praktikekin konbinatuta, etsipenaren amildegitik atera zaitezke.
Nola atera zeure burua etsipenaren amildegitik: hiru praktika
probak
Probak bi aldiz aipatzen dira XP feedback-en begiztan. Ez da horrela bakarrik. Oso garrantzitsuak dira Extreme Programming teknika osorako.
Unitate eta Onarpen probak dituzula suposatzen da. Batzuek minutu gutxitan ematen dizute iritzia, beste batzuk egun gutxitan, beraz, denbora gehiago behar dute idazteko eta gutxiagotan berrikusten dira.
Proba-piramide klasiko bat dago, proba gehiago egon beharko liratekeela erakusten duena.
Nola aplikatzen zaigu esparru hau IaC proiektu batean? Egia esan... batere ez.
- Unitate-probak, asko izan behar diren arren, ezin dira gehiegi izan. Edo zerbait oso zeharka probatzen ari dira. Izan ere, esan dezakegu ez ditugula batere idazten. Baina hona hemen egin ahal izan ditugun probak egiteko aplikazio batzuk:
- jsonnet kodea probatzen. Hau da, adibidez, gure droneak muntatzeko kanalizazioa, nahiko konplikatua. jsonnet kodea probak ondo estaltzen du.
Hau erabiltzen dugu . - Baliabidea abiaraztean exekutatzen diren scripten probak. Scriptak Python-en idazten dira, eta, beraz, probak idatz daitezke horietan.
- jsonnet kodea probatzen. Hau da, adibidez, gure droneak muntatzeko kanalizazioa, nahiko konplikatua. jsonnet kodea probak ondo estaltzen du.
- Probetan konfigurazioa egiaztatzea posible da, baina ez dugu hori egiten. Baliabideen konfigurazio-arauak egiaztatzeko ere konfiguratzeko aukera dago . Hala ere, egiaztapenak oinarrizkoegiak dira terraformarako, baina proba-script asko AWSrako idatzita daude. Eta Azure-n gaude, beraz, berriro hau ez da aplikatzen.
- Osagaien integrazio-probak: nola sailkatzen dituzun eta non jartzen dituzun araberakoa da. Baina funtsean funtzionatzen dute.
Hau da integrazio-probak nolakoak diren.
Hau adibide bat da Drone CI-n irudiak eraikitzean. Beraietara iristeko, 30 minutu itxaron behar dituzu Packer irudia eratu arte, eta gero beste 15 minutu itxaron behar dituzu pasa daitezen. Baina existitzen dira!Irudiak egiaztatzeko algoritmoa
- Packer-ek irudia guztiz prestatu behar du lehenik.
- Testaren ondoan egoera lokala duen terraforma bat dago, irudi hau zabaltzeko erabiltzen duguna.
- Zabaltzean, ondoan dagoen modulu txiki bat erabiltzen da irudiarekin lan egitea errazteko.
- Behin VM iruditik zabalduta, egiaztapenak has daitezke. Funtsean, kontrolak autoz egiten dira. Abiaraztean scriptek nola funtzionatu zuten eta deabruek nola funtzionatzen duten egiaztatzen du. Horretarako, ssh edo winrm bidez sortu berri den makinan saioa hasi eta konfigurazio egoera edo zerbitzuak martxan dauden egiaztatzen dugu.
- Egoera antzekoa da terraform moduluetako integrazio probekin. Hona hemen proba horien ezaugarriak azaltzen dituen taula labur bat.
Hodiari buruzko iritzia 40 minutu ingurukoa da. Oso denbora luzez gertatzen da dena. Erregresiorako erabil daiteke, baina garapen berrietarako, oro har, ez da errealista. Horretarako oso-oso prestatuta bazaude, prestatu exekutatzen ari diren gidoiak, orduan 10 minutura murriztu dezakezu. Baina hauek oraindik ez dira unitateko probak, 5 segundotan 100 pieza egiten dituztenak.
Irudiak edo terraform moduluak muntatzean Unitate-probarik ez izateak lana REST bidez exekutatu daitezkeen zerbitzu bereizietara edo Python scriptetara aldatzea bultzatzen du.
Adibidez, ziurtatu behar genuen makina birtuala abiarazten denean bere burua zerbitzuan erregistratzen duela , eta makina birtuala suntsitu zenean, bere burua ezabatu zuen.
ScaleFT zerbitzu gisa dugunez, APIaren bidez berarekin lan egitera behartuta gaude. Han idatzita zegoen bilgarri bat atera eta esan dezakezuna: "Sartu eta ezabatu hau eta bestea". Beharrezko ezarpen eta sarbide guztiak gordetzen ditu.
Honetarako proba normalak idatz ditzakegu dagoeneko, ez baita software arruntaren desberdina: apiha motaren bat burlatzen da, tira egiten duzu eta ea zer gertatzen den.
Proben emaitzak: unitateko probak, sistema eragilea minutu batean eman behar duena, ez du ematen. Piramidean goragoko proba motak eraginkorrak dira, baina arazoen zati bat bakarrik estaltzen dute.
Bikoteka programazioa
Probak, noski, onak dira. Horietako asko idatz ditzakezu, mota ezberdinetakoak izan daitezke. Euren mailan lan egingo dute eta iritzia emango digute. Baina OS azkarrena ematen duten Unitate-proba txarren arazoa jarraitzen du. Aldi berean, lan egiteko erraza eta atsegina den sistema eragile azkarra nahi dut. Zer esanik ez, lortutako soluzioaren kalitatea. Zorionez, unitate-probak baino are feedback azkarragoa eman dezaketen teknikak daude. Hau bikoteen programazioa da.
Kodea idaztean, bere kalitateari buruzko iritzia jaso nahi duzu ahalik eta azkarren. Bai, dena idatz dezakezu ezaugarrien adar batean (inori ezer hautsi ez dezan), Github-en pull-eskaera bat egin, iritziak pisua duen norbaiti esleitu eta erantzuna itxaron.
Baina denbora luzez itxaron dezakezu. Jende guztia lanpetuta dago, eta erantzuna, bat egon arren, baliteke kalitate gorenekoa ez izatea. Demagun erantzuna berehala iritsi zela, berrikusleak berehala ulertu zuen ideia osoa, baina erantzuna berandu datorrela ere, gertatu ondoren. Nahiago nuke lehenago izan. Horra zuzenduta dago bikoteen programazioa β berehala, idazteko unean.
Jarraian, bikoteen programazio estiloak eta IaC lantzeko duten aplikagarritasuna daude:
1. Klasikoa, Esperientziatua + Esperientziatua, aldatu tenporizadorearen arabera. Bi rol: gidaria eta nabigatzailea. Bi pertsona. Kode berean lan egiten dute eta aldez aurretik zehaztutako denbora-tarte jakin baten ondoren rolak aldatzen dituzte.
Kontuan izan dezagun gure arazoen bateragarritasuna estiloarekin:
- Arazoa: kodea garatzeko tresnen eta tresnen inperfekzioa.
Eragin negatiboa: denbora gehiago behar da garatzeko, moteldu egiten dugu, lan erritmoa/erritmoa galtzen da.
Nola borrokatzen dugun: beste tresna bat erabiltzen dugu, IDE arrunt bat eta lasterbideak ere ikasten ditugu. - Arazoa: hedapen motela.
Eragin negatiboa: laneko kode bat sortzeko behar den denbora handitzen du. Itxarotean aspertzen gara, eskuak itxaroten dugun bitartean beste zerbait egiteko heltzen gara.
Nola borrokatzen dugun: ez dugu gainditu. - Arazoa: planteamendu eta praktika falta.
Eragin negatiboa: ez dago ondo nola egin eta gaizki nola egin jakiteko. Iritzia jasotzea luzatzen du.
Nola borrokatzen garen: bikote-lanean iritzi eta praktiken elkar-trukeak ia konpontzen du arazoa.
IaC-n estilo hau erabiltzearen arazo nagusia lan-erritmo irregularra da. Softwarearen garapen tradizionalean, mugimendu oso uniformea ββduzu. Bost minutu pasa ditzakezu eta N idatzi. Pasa 10 minutu eta idatzi 2N, 15 minutu - 3N. Hemen bost minutu eman eta N idatzi dezakezu, eta gero beste 30 minutu pasa eta N-ren hamarren bat idatzi. Hemen ez dakizu ezer, trabatuta zaude, ergela. Ikerketak denbora behar du eta programaziotik aldentzen du.
Ondorioa: bere forma hutsean ez zaigu egokia.
2. Ping-pong. Ikuspegi honek pertsona batek proba idazten du eta beste batek inplementazioa egiten du. Kontuan izanda Unitate-testekin dena konplikatua dela, eta programatzeko denbora luzea behar duen integrazio-proba idatzi behar duzula, ping-pong-en erraztasun guztiak desagertu egiten dira.
Esan dezaket proba-script bat diseinatzeko eta horren kodea inplementatzeko ardurak bereizten saiatu garela. Parte-hartzaile batek asmatu zuen gidoia, lanaren zati honetan bera arduratu zen, azken hitza zuen. Eta bestea gauzatzeaz arduratu zen. Ondo atera zen. Ikuspegi honekin gidoiaren kalitatea handitzen da.
Ondorioa: ai, lan-erritmoak ez du onartzen IaC-n ping-pong-a binaka programatzeko praktika gisa erabiltzea.
3.Estilo sendoa. . Ideia da parte-hartzaile bat zuzentarau-nabigatzaile bilakatzea eta bigarrenak exekuzio-gidariaren rola hartzen duela. Kasu honetan, erabakiak hartzeko eskubidea nabigatzaileari dagokio soilik. Gidariak bakarrik inprimatzen du eta hitz batekin gertatzen dena eragin dezake. Rolak ez dira denbora luzez aldatzen.
Ikasteko ona, baina trebetasun bigunak behar ditu. Hau da, non faltsutu ginen. Teknika zaila zen. Eta ez da azpiegituraz ere.
Ondorioa: baliagarri izan daiteke, ez diogu saiatzeari uzten.
4. Mobbing-a, swarming eta estilo ezagunak baina zerrendatu gabekoak Ez dugu kontuan hartzen, zeren Ez gara probatu eta ezinezkoa da gure lanaren testuinguruan horretaz hitz egitea.
Bikoteen programazioa erabiltzearen emaitza orokorrak:
- Lan erritmo irregularra dugu, eta hori nahasgarria da.
- Gaitasun bigun nahiko onak topatu genituen. Eta gaiak ez du laguntzen gure gabezia horiek gainditzen.
- Proba luzeek eta tresnen arazoek binakako garapena zailtzen dute.
5. Hala ere, arrakastak izan ziren. Gure metodo propioa sortu genuen "Konbergentzia - Dibergentzia". Nola funtzionatzen duen laburki deskribatuko dut.
Bazkide finkoak ditugu egun batzuetarako (aste bat baino gutxiago). Zeregin bat elkarrekin egiten dugu. Elkarrekin esertzen gara pixka bat: batek idazten du, besteak eseri eta laguntza taldeari begira. Gero denbora batez sakabanatzen gara, bakoitzak gauza independente batzuk egiten ditu, gero berriro elkartzen gara, oso azkar sinkronizatzen gara, elkarrekin zerbait egin eta berriro sakabanatzen gara.
Plangintza eta komunikazioa
OS arazoak konpontzen diren azken praktiken blokea lanaren antolakuntza da zereginekin beraiekin. Bikote lanetik kanpo dagoen esperientzia-trukea ere barne hartzen du horrek. Ikus ditzagun hiru praktika:
1. Helburuen zuhaitzaren bidez helburuak. Etorkizunera amaigabean doan zuhaitz baten bidez antolatu genuen proiektuaren kudeaketa orokorra. Teknikoki, jarraipena Miro-n egiten da. Zeregin bat dago: tarteko helburua da. Bertatik helburu txikiagoak edo ataza-taldeak ateratzen dira. Zereginak beraietatik datoz. Zeregin guztiak taula honetan sortu eta mantentzen dira.
Eskema honek feedbacka ere ematen du, rallyetan sinkronizatzen dugunean egunean behin gertatzen dena. Plan komun bat denon aurrean, baina egituratua eta guztiz irekia izateak, denek gertatzen ari denaz eta noraino egin dugun jakitun izatea ahalbidetzen du.
Zereginen ikusmenaren abantailak:
- Kausalitatea. Zeregin bakoitzak helburu global batera eramaten du. Zereginak helburu txikiagoetan biltzen dira. Azpiegituren domeinua bera nahiko teknikoa da. Ez dago beti berehala argi zein eragin zehatza duen, adibidez, beste nginx batera migratzeko runbook bat idazteak negozioan duen. Helburu-txartela gertu izateak argiago uzten du.
Kausalitatea arazoen propietate garrantzitsu bat da. Zuzenean erantzuten dio galderari: "Gauza zuzena egiten ari al naiz?" - Paralelismoa. Bederatzi gara, eta fisikoki ezinezkoa da denak zeregin batera botatzea. Arlo bateko zereginak ere ez dira beti nahikoak izango. Lan talde txikien arteko lana paralelizatzera behartuta gaude. Aldi berean, taldeak beren zereginean esertzen dira denbora batez, beste norbaitek indartu ditzake. Batzuetan jendea lantalde honetatik aldentzen da. Norbait oporretara doa, norbaitek txosten bat egiten du DevOps konf-erako, norbaitek Habr-i buruzko artikulu bat idazten du. Paraleloan zein helburu eta zeregin egin daitezkeen jakitea oso garrantzitsua da.
2. Goizeko bileren ordezko aurkezleak. Stand-upetan arazo hau dugu: jendeak lan asko egiten ditu paraleloan. Batzuetan, zereginak oso lotuta daude eta ez dago ulertzen nork zer egiten duen. Eta beste taldekide baten iritzia oso garrantzitsua da. Hau arazoa konpontzeko bidea alda dezakeen informazio gehigarria da. Noski, normalean norbait egon ohi da zurekin, baina aholkuak eta aholkuak beti dira lagungarriak.
Egoera hau hobetzeko, βLeading the Leading Stand-Upβ teknika erabili dugu. Orain zerrenda jakin baten arabera biratzen dira, eta horrek badu bere eragina. Zure txanda denean, murgiltzera eta gertatzen ari dena ulertzera behartuta zaude Scrum bilera on bat egiteko.
3. Barne demoa. Bikoteen programaziotik arazo bat konpontzen laguntzea, arazoen zuhaitz batean bistaratzea eta goizean scrum bileretan laguntzea onak dira, baina ez aproposa. Bikote gisa, zure ezagutzak bakarrik mugatuta zaude. Zereginen zuhaitzak mundu osoan zer egiten ari den ulertzen laguntzen du. Eta goizeko bileran aurkezleak eta lankideak ez dira zure arazoetan sakonduko. Zalantzarik gabe, zerbait galduko dute.
Irtenbidea elkarri egindako lana erakustean eta gero eztabaidatzean aurkitu zen. Astean behin ordubetez elkartzen gara eta azken astean egin ditugun lanen konponbideen xehetasunak erakusten ditugu.
Erakustaldian zehar, zereginaren xehetasunak agerian utzi behar dira eta ziurtatu funtzionamendua frogatzea.
Txostena kontrol-zerrenda baten bidez egin daiteke.1. Sartu testuinguruan. Nondik sortu zen zeregina, zergatik zen beharrezkoa?
2. Nola konpondu zen arazoa aurretik? Adibidez, saguaren klik masiboa behar zen, edo ezinezkoa zen ezer egin.
3. Nola hobetzen dugun. Adibidez: "Begira, orain scriptosik dago, hona hemen readme".
4. Erakutsi nola funtzionatzen duen. Gomendagarria da erabiltzaileen eszenatoki batzuk zuzenean ezartzea. X nahi dut, Y egiten dut, Y ikusten dut (edo Z). Adibidez, NGINX inplementatzen dut, url-a erretzen dut eta 200 OK lortzen dut. Ekintza luzea bada, prestatu aldez aurretik, gero erakutsi ahal izateko. Demoa baino ordubete lehenago gehiegi ez haustea komeni da, hauskorra bada.
5. Azaldu zein arrakastaz konpondu den arazoa, zer zailtasun geratzen diren, zer ez den osatu, zer hobekuntza posible diren etorkizunean. Adibidez, orain CLI, gero automatizazio osoa egongo da CIn.
Bozgorailu bakoitzak 5-10 minututan mantentzea komeni da. Zure hitzaldia, jakina, garrantzitsua bada eta luzeagoa izango bada, koordinatu hau aldez aurretik sre-takeover kanalean.
Aurrez aurre egin ondoren beti dago eztabaida bat harian. Hor agertzen da gure zereginetan behar dugun iritzia.
Ondorioz, inkesta bat egiten da gertatzen ari denaren erabilgarritasuna zehazteko. Hau diskurtsoaren funtsa eta zereginaren garrantziari buruzko iritzia da.
Ondorio luzeak eta hurrengoa
Badirudi artikuluaren tonua ezkorra samarra dela. Hau gaizki dago. Bi feedback-maila baxuago, hots, probak eta bikoteen programazioa, funtzionatzen dute. Ez garapen tradizionalean bezain perfektua, baina eragin positiboa dago.
Testek, gaur egungo forman, kode estaldura partziala baino ez dute ematen. Konfigurazio-funtzio asko probatu gabe geratzen dira. Kodea idaztean benetako lanean duten eragina txikia da. Hala ere, integrazio proben eragina dago, eta beldurrik gabe birfaktorizazioak egiteko aukera ematen dute. Lorpen handia da hau. Gainera, goi-mailako lengoaietan garapenerako arreta aldatzearekin (python dugu, joan), arazoa desagertu egiten da. Eta ez duzu egiaztapen asko behar "kola"rako; nahikoa da integrazio-kontrol orokorra.
Bikoteka lan egitea pertsona zehatz batzuen araberakoa da. Zereginaren faktorea eta gure gaitasun bigunak daude. Batzuekin oso ondo funtzionatzen du, beste batzuekin okerrago. Zalantzarik gabe, honetatik onurak daude. Argi dago bikote-lanaren arauak behar bezala betetzen ez badira ere, zereginak elkarrekin egiteak berak eragin positiboa duela emaitzaren kalitatean. Pertsonalki, binaka lan egitea errazagoa eta atseginagoa iruditzen zait.
OSan eragiteko goi-mailako moduek - zereginak planifikatzeak eta lan egiteak ondorioak sortzen dituzte: kalitate handiko ezagutza-trukea eta garapenaren kalitatea hobetzea.
Ondorio laburrak lerro batean
- HR profesionalek IaCn lan egiten dute, baina eraginkortasun gutxiagorekin.
- Funtzionatzen duena indartu.
- Sortu zure konpentsazio-mekanismoak eta praktikak.
Iturria: www.habr.com