Hallo, Habr! Earder klage ik oer it libben yn 'e Ynfrastruktuer as koadeparadigma en joech neat oan om de hjoeddeistige situaasje op te lossen. Hjoed bin ik werom om jo te fertellen hokker oanpak en praktiken jo sille helpe te ûntkommen út 'e ôfgrûn fan wanhoop en de situaasje yn' e goede rjochting te stjoeren.
Yn it foarige artikel Ik dielde myn yndrukken fan dit gebiet, besocht te reflektearjen oer de hjoeddeistige situaasje yn dit gebiet, en suggerearre sels dat standertpraktiken dy't bekend binne foar alle ûntwikkelders kinne helpe. It soe lykje dat der in soad klachten wiene oer it libben, mar der wiene gjin útstellen foar in útwei út de hjoeddeiske situaasje.
Wa't wy binne, wêr't wy binne en hokker problemen wy hawwe
Wy binne op it stuit yn it Sre Onboarding Team, dat bestiet út seis programmeurs en trije ynfrastruktuer yngenieurs. Wy besykje allegear ynfrastruktuer te skriuwen as koade (IaC). Wy dogge dit om't wy yn prinsipe witte hoe't wy koade skriuwe en in skiednis hawwe fan "boppegemiddelde" ûntwikkelders.
- Wy hawwe in set fan foardielen: in bepaalde eftergrûn, kennis fan praktiken, de mooglikheid om koade te skriuwen, in winsk om nije dingen te learen.
- En d'r is in sakke diel, dat is ek in minus: gebrek oan kennis oer ynfrastruktuer hardware.
De technologystack dy't wy brûke yn ús IaC.
- Terraform foar it meitsjen fan boarnen.
- Packer foar it gearstallen fan ôfbyldings. Dit binne Windows, CentOS 7-ôfbyldings.
- Jsonnet om in krêftige build te meitsjen yn drone.io, en ek om packer json en ús terraform-modules te generearjen.
- Azure.
- Unsible by it tarieden fan ôfbyldings.
- Python foar helptsjinsten en foarsjenningsskripts.
- En dit alles yn VSCode mei plugins dield tusken teamleden.
Konklúzje út myn wie sa: ik besocht (alearst by mysels) optimisme by te bringen, ik woe sizze dat wy de oan ús bekende oanpakken en praktiken besykje sille om te gean mei de swierrichheden en kompleksiteiten dy't op dit mêd bestean.
Wy wrakselje op it stuit mei de folgjende IaC-problemen:
- Unfolsleinens fan ark en middels foar koadeûntwikkeling.
- Stadige ynset. Ynfrastruktuer is diel fan 'e echte wrâld, en it kin stadich wêze.
- Gebrek oan oanpakken en praktiken.
- Wy binne nij en witte net folle.
Extreme Programming (XP) oan 'e rêding
Alle ûntwikkelders binne bekend mei Extreme Programming (XP) en de praktiken dy't der efter steane. In protte fan ús hawwe wurke mei dizze oanpak, en it is suksesfol. Dus wêrom net de dêr fêstleine prinsipes en praktiken brûke om ynfrastruktuerútdagings te oerwinnen? Wy besletten om dizze oanpak te nimmen en te sjen wat der bart.
Kontrolearje de tapasberens fan 'e XP-oanpak foar jo yndustryHjir is in beskriuwing fan 'e omjouwing wêrfoar XP goed geskikt is, en hoe't it mei ús ferhâldt:
1. Dynamysk feroarjende software easken. It wie ús dúdlik wat it eindoel wie. Mar de details kinne ferskille. Wy sels beslute wêr't wy moatte taksy, dus de easken feroarje periodyk (benammen troch ússels). As wy it SRE-team nimme, dat de automatisearring sels docht, en sels de easken en wurkomfang beheint, dan past dit punt goed.
2. Risiko's feroarsake troch fêste tiid projekten mei help fan nije technology. Wy kinne risiko's tsjinkomme by it brûken fan guon foar ús ûnbekende dingen. En dit is 100% ús gefal. Us hiele projekt wie it gebrûk fan technologyen dêr't wy net folslein mei wiene. Yn 't algemien is dit in konstant probleem, om't ... D'r binne hieltyd in protte nije technologyen dy't yn 'e ynfrastruktuersektor opkomme.
3,4. Lyts, tegearre lizzend útwreide ûntwikkelingsteam. De automatisearre technology dy't jo brûke lit ienheid- en funksjonele tests ta. Dizze twa punten passe ús net hielendal. As earste binne wy gjin koördinearre ploech, en twad binne wy njoggen, dy't as in grut team beskôge wurde kinne. Hoewol, neffens guon definysjes fan in "grut" team, is in protte 14+ minsken.
Litte wy nei guon XP-praktiken sjen en hoe't se de snelheid en kwaliteit fan feedback beynfloedzje.
XP Feedback Loop Prinsipe
Yn myn begryp is feedback it antwurd op de fraach, doch ik it goede ding, geane wy dêr hinne? XP hat in godlik skema foar dit: in tiid feedback loop. It nijsgjirrige is dat hoe leger wy binne, hoe rapper wy it OS kinne krije om de nedige fragen te beantwurdzjen.
Dit is in nochal nijsgjirrich ûnderwerp foar diskusje, dat it yn ús IT-sektor mooglik is om fluch in OS te krijen. Stel jo foar hoe pynlik it is om in projekt foar seis moanne te dwaan en pas dan út te finen dat der in flater wie oan it begjin. Dit bart yn ûntwerp en yn elke konstruksje fan komplekse systemen.
Yn ús gefal fan IaC helpt feedback ús. Ik sil fuortendaliks in lytse oanpassing meitsje oan it boppesteande diagram: it releaseplan hat gjin moanlikse syklus, mar komt ferskate kearen deis foar. D'r binne guon praktiken bûn oan dizze OS-syklus dy't wy yn mear detail sille besjen.
Wichtich: feedback kin in oplossing wêze foar alle boppesteande problemen. Tegearre mei XP-praktiken kin it jo út 'e ôfgrûn fan wanhoop lûke.
Hoe kinne jo josels út 'e ôfgrûn fan wanhoop lûke: trije praktiken
Tests
Tests wurde twa kear neamd yn 'e XP-feedback-loop. It is net samar sa. Se binne ekstreem wichtich foar de hiele Extreme Programming technyk.
Der wurdt oannommen dat jo ienheid- en akseptaasjetests hawwe. Guon jouwe jo yn in pear minuten feedback, oaren yn in pear dagen, sadat se langer duorje om te skriuwen en wurde minder faak besjoen.
D'r is in klassike testpiramide, dy't sjen lit dat d'r mear tests moatte wêze.
Hoe jildt dit ramt foar ús yn in IaC-projekt? Eins... hielendal net.
- Ienheidstests, nettsjinsteande it feit dat d'r in protte moatte wêze, kinne net te folle wêze. Of se testen wat heul yndirekt. Eins kinne wy sizze dat wy se hielendal net skriuwe. Mar hjir binne in pear applikaasjes foar sokke tests dy't wy koenen dwaan:
- Jsonnet-koade testen. Dit is bygelyks ús drone-assemblagepipeline, dy't frij yngewikkeld is. De jsonnet-koade wurdt goed bedutsen troch tests.
Wy brûke dit . - Tests foar skripts dy't wurde útfierd as de boarne begjint. Skripten wurde skreaun yn Python, en dêrom kinne der tests op skreaun wurde.
- Jsonnet-koade testen. Dit is bygelyks ús drone-assemblagepipeline, dy't frij yngewikkeld is. De jsonnet-koade wurdt goed bedutsen troch tests.
- It is mooglik mooglik om de konfiguraasje te kontrolearjen yn tests, mar dat dogge wy net. It is ek mooglik om te konfigurearjen kontrôle resource konfiguraasje regels fia . De kontrôles dêr binne lykwols gewoan te basis foar terraform, mar in protte testskripts binne skreaun foar AWS. En wy binne op Azure, dus dit jildt wer net.
- Yntegraasjetests foar komponinten: it hinget ôf fan hoe't jo se klassifisearje en wêr't jo se pleatse. Mar se wurkje yn prinsipe.
Dit is hoe't yntegraasjetests der útsjen.
Dit is in foarbyld by it bouwen fan bylden yn Drone CI. Om se te berikken, moatte jo 30 minuten wachtsje foar de Packer-ôfbylding om te foarmjen, wachtsje dan noch 15 minuten foar't se passe. Mar se besteane!Ofbylding ferifikaasje algoritme
- Packer moat earst de ôfbylding folslein tariede.
- Njonken de test is d'r in terraform mei in lokale steat, dy't wy brûke om dizze ôfbylding yn te setten.
- By it útfolden wurdt in lytse module dy't tichtby leit brûkt om it makliker te meitsjen mei it byld te wurkjen.
- Sadree't de VM is ynset fanút de ôfbylding, kinne kontrôles begjinne. Yn prinsipe wurde kontrôles útfierd mei de auto. It kontrolearret hoe't de skripts wurken by it opstarten en hoe't de daemons wurkje. Om dit te dwaan, fia ssh of winrm ynlogge wy yn 'e nij ferhege masine en kontrolearje de konfiguraasjestatus of oft de tsjinsten op binne.
- De situaasje is fergelykber mei yntegraasjetests yn modules foar terraform. Hjir is in koarte tabel mei útlis oer de funksjes fan sokke tests.
Feedback oer de pipeline is sawat 40 minuten. Alles bart foar in hiel lange tiid. It kin brûkt wurde foar regression, mar foar nije ûntwikkeling is it oer it algemien ûnrealistysk. As jo hier heul, heul taret binne, tariede rinnende skripts, dan kinne jo it ferminderje nei 10 minuten. Mar dit binne noch gjin Unit-tests, dy't 5 stikken yn 100 sekonden dogge.
It ûntbrekken fan ienheidstests by it gearstallen fan ôfbyldings of terraform-modules stimulearret it ferpleatsen fan it wurk nei aparte tsjinsten dy't gewoan fia REST kinne wurde útfierd, of nei Python-skripts.
Wy moasten bygelyks derfoar soargje dat as de firtuele masine begjint, it himsels registrearret yn 'e tsjinst , en doe't de firtuele masine waard ferneatige, it wiske himsels.
Sûnt wy hawwe ScaleFT as tsjinst, binne wy twongen om te wurkjen mei it fia de API. D'r stie in wrapper skreaun dat jo koenen lûke en sizze: "Gean deryn en wiskje dit en dat." It bewarret alle nedige ynstellingen en tagongen.
Wy kinne hjir al normale tests foar skriuwe, om't it net oars is fan gewoane software: in soarte fan apiha wurdt bespot, jo lûke it, en sjoch wat der bart.
Resultaten fan 'e tests: Unittesten, dy't it OS yn in minút moatte jaan, jout it net. En soarten testen heger yn 'e piramide binne effektyf, mar dekke mar in part fan' e problemen.
Pair programmearring
Tests binne, fansels, goed. Jo kinne in protte fan har skriuwe, se kinne fan ferskate soarten wêze. Se sille wurkje op har nivo en jou ús feedback. Mar it probleem mei minne Unit-tests, dy't de rapste OS jouwe, bliuwt. Tagelyk wol ik noch in fluch OS dat maklik en noflik is om mei te wurkjen. Net te ferjitten de kwaliteit fan de resultearjende oplossing. Gelokkich binne d'r techniken dy't noch rapper feedback kinne leverje as ienheidstests. Dit is pear programmearring.
By it skriuwen fan koade wolle jo sa rap mooglik feedback krije oer de kwaliteit. Ja, jo kinne alles skriuwe yn in funksje-tûke (om neat foar elkenien te brekken), in pull-fersyk yn Github meitsje, it tawize oan ien waans miening gewicht hat, en wachtsje op in antwurd.
Mar jo kinne lang wachtsje. Minsken binne allegear drok, en it antwurd, sels as d'r ien is, kin net fan 'e heechste kwaliteit wêze. Stel dat it antwurd daliks kaam, de resinsint begriep daliks it hiele idee, mar it antwurd komt noch let, nei it feit. Ik woe dat it earder wie. Dit is wêrop pair-programmearring rjochte is - direkt, op it momint fan skriuwen.
Hjirûnder binne de pear programmearring stilen en harren tapasberens by it wurkjen oan IaC:
1. Klassyk, Belibbe + Belibbe, ferskowe troch timer. Twa rollen - bestjoerder en navigator. Twa minsken. Se wurkje op deselde koade en wikselje rollen nei in bepaalde foarbepaalde tiid.
Litte wy de kompatibiliteit fan ús problemen mei styl beskôgje:
- Probleem: ûnfolsleinens fan ark en ark foar koadeûntwikkeling.
Negative ynfloed: it duorret langer om te ûntwikkeljen, wy fertrage, it tempo / ritme fan wurk giet ferlern.
Hoe't wy fjochtsje: wy brûke in oar ark, in mienskiplike IDE en learje ek fluchtoetsen. - Probleem: Stadige ynset.
Negatyf ynfloed: fergruttet de tiid dy't it nimt om in wurkjend stik koade te meitsjen. Wy ferfele ús wylst wy wachtsje, ús hannen stekke út om wat oars te dwaan wylst wy wachtsje.
Hoe't wy fjochtsje: wy hawwe it net oerwûn. - Probleem: gebrek oan oanpakken en praktiken.
Negative ynfloed: d'r is gjin kennis fan hoe't it goed en hoe't jo it min dwaan moatte. Fergruttet de ûntfangst fan feedback.
Hoe't wy fjochtsje: ûnderlinge útwikseling fan mieningen en praktiken yn pearwurk lost it probleem hast op.
It wichtichste probleem mei it brûken fan dizze styl yn IaC is it ûngelikense tempo fan wurk. Yn tradisjonele softwareûntwikkeling hawwe jo in heul unifoarme beweging. Jo kinne besteegje fiif minuten en skriuwe N. Besteegje 10 minuten en skriuw 2N, 15 minuten - 3N. Hjir kinne jo fiif minuten trochbringe en N skriuwe, en dan noch 30 minuten trochbringe en in tsiende fan N skriuwe. Hjir wite jo neat, jo sitte fêst, dom. It ûndersyk duorret tiid en leit ôf fan it programmearjen sels.
Konklúzje: yn syn suvere foarm is it net geskikt foar ús.
2. Ping-pong. Dizze oanpak giet it om dat ien persoan de test skriuwt en in oar de ymplemintaasje dêrfoar docht. Rekken hâldend mei it feit dat alles is yngewikkeld mei Unit tests, en jo moatte skriuwe in yntegraasje test dat duorret in lange tiid om te programmearjen, al it gemak fan ping-pong giet fuort.
Ik kin sizze dat wy besochten de ferantwurdlikheden te skieden foar it ûntwerpen fan in testskript en it útfieren fan koade foar it. Ien dielnimmer kaam mei it skript, yn dit diel fan it wurk wie hy ferantwurdlik, hy hie it lêste wurd. En de oare wie ferantwurdlik foar de útfiering. It slagge goed. De kwaliteit fan it skript mei dizze oanpak nimt ta.
Konklúzje: helaas, it wurktempo lit it gebrûk fan ping-pong net ta as in pear programmearringpraktyk yn IaC.
3.Sterke Styl. . It idee is dat ien dielnimmer wurdt de rjochtline navigator, en de twadde nimt de rol fan de útfiering bestjoerder. Yn dit gefal leit it rjocht om besluten te nimmen allinich by de navigator. De sjauffeur print allinnich en kin mei in wurd beynfloedzje wat der bart. De rollen feroarje foar in lange tiid net.
Goed foar learen, mar fereasket sterke sêfte feardigens. Dit is wêr't wy wankele. De technyk wie dreech. En it giet net iens oer ynfrastruktuer.
Konklúzje: it kin mooglik brûkt wurde, wy jouwe it besykjen net op.
4. Mobbing, swarming en alle bekende, mar net neamd stilen Wy beskôgje it net, om't Wy hawwe it net besocht en it is ûnmooglik om der oer te praten yn 'e kontekst fan ús wurk.
Algemiene resultaten oer it brûken fan pear programmearring:
- Wy hawwe in ûngelyk tempo fan wurk, dat is betiizjend.
- Wy rûnen net genôch goede sêfte feardichheden oan. En it fakgebiet helpt net om dizze tekoarten fan ús te oerwinnen.
- Lange testen en problemen mei ark meitsje keppele ûntwikkeling lestich.
5. Nettsjinsteande dit wiene der suksessen. Wy kamen mei ús eigen metoade "Konverginsje - Diverginsje". Ik sil koart beskriuwe hoe't it wurket.
Wy hawwe permaninte partners foar in pear dagen (minder dan in wike). Wy dogge ien taak tegearre. Wy sitte efkes byinoar: de iene skriuwt, de oare sit en sjocht nei it stipeteam. Dan fersprieden wy in skoft, elk docht wat selsstannige dingen, dan komme wy wer byinoar, syngronisearje hiel fluch, dogge wat tegearre en fersprieden wer.
Planning en kommunikaasje
It lêste blok fan praktiken wêrmei OS-problemen wurde oplost is de organisaasje fan wurk mei de taken sels. Dit omfettet ek de útwikseling fan ûnderfining dy't bûten pearwurk leit. Litte wy nei trije praktiken sjen:
1. Doelen troch de doelbeam. Wy organisearje it algemiene behear fan it projekt troch in beam dy't einleaze de takomst yn giet. Technysk wurdt it folgjen dien yn Miro. D'r is ien taak - it is in tuskendoel. Fanôf gean of lytsere doelen as groepen fan taken. De taken sels komme fan harren. Alle taken wurde makke en ûnderhâlden op dit boerd.
Dit skema ek jout feedback, dat bart ien kear deis as wy syngronisearje op rallyen. In mienskiplik plan foar elkenien hawwe, mar strukturearre en folslein iepen, lit elkenien bewust wêze fan wat der bart en hoe fier wy foarútgien binne.
Foardielen fan fisuele fisy fan taken:
- Kausaliteit. Elke taak liedt ta in globaal doel. Taken wurde groepearre yn lytsere doelen. It ynfrastruktuerdomein sels is frij technysk. It is net altyd direkt dúdlik hokker spesifike ynfloed, bygelyks, it skriuwen fan in runbook oer migrearjen nei in oare nginx hat op it bedriuw. It hawwen fan de doelkaart tichtby makket it dúdliker.
Kausaliteit is in wichtige eigenskip fan problemen. It beantwurdet direkt de fraach: "Doch ik it goede ding?" - Parallelisme. D'r binne njoggen fan ús, en it is gewoan fysyk ûnmooglik om elkenien op ien taak te goaien. Taken út ien gebiet kinne ek net altyd genôch wêze. Wy binne twongen om wurk te parallelisearjen tusken lytse wurkgroepen. Tagelyk sitte de groepen in skoft op har taak, se kinne fersterke wurde troch in oar. Soms falle minsken ôf fan dizze wurkgroep. Immen giet op fakânsje, immen makket in rapport foar de DevOps conf, immen skriuwt in artikel oer Habr. Wittende hokker doelen en taken kinne wurde dien parallel wurdt hiel wichtich.
2. Ferfanging presintatoaren fan moarnsgearkomsten. By stand-ups hawwe wy dit probleem - minsken dogge in protte taken parallel. Soms binne taken los ferbûn en is der gjin begryp fan wa't wat docht. En de miening fan in oar teamlid is tige wichtich. Dit is ekstra ynformaasje dy't de rin fan it oplossen fan it probleem kin feroarje. Fansels is der meastentiids ien by dy, mar advys en tips binne altyd nuttich.
Om dizze situaasje te ferbetterjen, brûkten wy de technyk "De liedende stand-up feroarje". No wurde se rotearre neffens in bepaalde list, en dit hat syn effekt. As it jo beurt is, wurde jo twongen om yn te dûken en te begripen wat der bart om in goede Scrum-gearkomste út te fieren.
3. Ynterne demo. Help by it oplossen fan in probleem út pear programmearring, fisualisaasje op de probleem beam en help by scrum gearkomsten yn 'e moarntiid binne goed, mar net ideaal. As pear binne jo allinich beheind troch jo kennis. De taakbeam helpt om wrâldwiid te begripen wa't wat docht. En de presintator en kollega's op 'e moarnsgearkomste sille net djip yn jo problemen dûke. Se kinne grif wat misse.
De oplossing waard fûn yn it demonstrearjen fan it wurk oan elkoar en dêrnei te besprekken. Wy treffe ien kear yn 'e wike in oere lang en litte details sjen fan oplossings foar taken dy't wy de ôfrûne wike dien hawwe.
Tidens de demonstraasje is it nedich om de details fan 'e taak te iepenbierjen en der wis fan te wêzen dat it wurket.
It rapport kin útfierd wurde mei in checklist.1. Fier yn kontekst. Wêr kaam de taak wei, wêrom wie it sels nedich?
2. Hoe wie it probleem earder oplost? Bygelyks, massive mûsklikken wie ferplichte, of it wie ûnmooglik om alles te dwaan.
3. Hoe't wy it ferbetterje. Bygelyks: "Sjoch, no is d'r scriptosik, hjir is de readme."
4. Lit sjen hoe't it wurket. It is oan te rieden om guon brûkerssenario direkt út te fieren. Ik wol X, ik doch Y, ik sjoch Y (of Z). Bygelyks, ik ynsette NGINX, smoke de url, en krije 200 OK. As de aksje lang is, meitsje it dan foarôf tariede, sadat jo it letter sjen kinne. It is oan te rieden om it net te folle in oere foar de demo te brekken, as it kwetsber is.
5. Ferklearje hoe suksesfol it probleem oplost is, hokker swierrichheden bliuwe, wat net foltôge is, hokker ferbetteringen mooglik binne yn 'e takomst. Bygelyks, no CLI, dan sil d'r folsleine automatisearring wêze yn CI.
It is oan te rieden foar elke sprekker om it 5-10 minuten te hâlden. As jo taspraak is fansels wichtich en sil langer duorje, koördinearje dit foarôf yn de sre-oername kanaal.
Nei it face-to-face diel is der altyd in diskusje yn de tried. Dit is wêr't de feedback dy't wy nedich binne oer ús taken ferskynt.
Dêrtroch wurdt in enkête hâlden om it nut fan wat der bart te bepalen. Dit is feedback oer de essinsje fan 'e taspraak en it belang fan' e taak.
Lange konklúzjes en wat is folgjende
It kin lykje dat de toan fan it artikel is wat pessimistysk. Dit is ferkeard. Twa legere nivo's fan feedback, nammentlik tests en pear programmearring, wurkje. Net sa perfekt as yn tradisjonele ûntwikkeling, mar der is in posityf effekt fan.
Tests, yn har hjoeddeistige foarm, jouwe mar in part koadedekking. In protte konfiguraasjefunksjes einigje net te testen. Harren ynfloed op it eigentlike wurk by it skriuwen fan koade is leech. D'r is lykwols in effekt fan yntegraasjetests, en se kinne jo sûnder eangst refactorings útfiere. Dit is in grutte prestaasje. Ek mei de ferskowing fan fokus nei ûntwikkeling yn talen op heech nivo (wy hawwe python, gean), giet it probleem fuort. En jo hawwe net in protte kontrôles nedich foar de "lym"; in algemiene yntegraasjekontrôle is genôch.
Wurkje yn pearen hinget mear ôf fan spesifike minsken. D'r is de taakfaktor en ús sêfte feardigens. By guon komt it hiel goed, by oaren komt it minder. D'r binne perfoarst foardielen fan dit. It is dúdlik dat sels as de regels fan pear wurken net genôch wurde observearre, it feit fan it útfieren fan taken tegearre hat in posityf effekt op de kwaliteit fan it resultaat. Persoanlik fyn ik it wurkjen yn pearen makliker en nofliker.
Manieren op heger nivo om it OS te beynfloedzjen - plannen en wurkje mei taken presys effekten produsearje: kennisútwikseling fan hege kwaliteit en ferbettere ûntwikkelingskwaliteit.
Koarte konklúzjes yn ien rigel
- HR-beoefeners wurkje yn IaC, mar mei minder effisjinsje.
- Fersterkje wat wurket.
- Kom mei jo eigen kompensearjende meganismen en praktiken.
Boarne: www.habr.com