Innviði sem kóða: hvernig á að sigrast á vandamálum með XP

Halló, Habr! Áður kvartaði ég yfir lífinu í innviðum sem kóða fyrirmynd og bauð ekki neitt til að leysa núverandi ástand. Í dag kem ég aftur til að segja þér hvaða aðferðir og venjur munu hjálpa þér að flýja úr hyldýpi örvæntingar og stýra ástandinu í rétta átt.

Í fyrri greininni "Infrastrúktúr sem kóða: fyrstu kynni" Ég deildi tilfinningum mínum af þessu svæði, reyndi að velta fyrir mér núverandi ástandi á þessu svæði og lagði jafnvel til að staðlaðar venjur sem allir þróunaraðilar þekkja gætu hjálpað. Það gæti virst sem mikið væri kvartað yfir lífinu en engar tillögur komu fram um leið út úr núverandi ástandi.

Hver við erum, hvar við erum og hvaða vandamál við höfum

Við erum sem stendur í Sre Onboarding Team, sem samanstendur af sex forriturum og þremur innviðaverkfræðingum. Við erum öll að reyna að skrifa Infrastructure sem kóða (IaC). Við gerum þetta vegna þess að við vitum í grundvallaratriðum hvernig á að skrifa kóða og höfum sögu um að vera „yfir meðaltal“ verktaki.

• Við höfum ýmsa kosti: ákveðinn bakgrunn, þekkingu á starfsháttum, hæfni til að skrifa kóða, löngun til að læra nýja hluti.
• Og það er lafandi hluti, sem er líka mínus: skortur á þekkingu á innviðabúnaði.

Tæknistaflan sem við notum í IaC okkar.

• Terraform til að búa til auðlindir.
• Pakkari til að setja saman myndir. Þetta eru Windows, CentOS 7 myndir.
• Jsonnet til að búa til öfluga byggingu í drone.io, sem og til að búa til pakkara json og terraform einingar okkar.
• Azure.
• Hægt að undirbúa myndir.
• Python fyrir aukaþjónustu og úthlutunarforskriftir.
• Og allt þetta í VSCode með viðbætur sem deilt er á milli liðsmanna.

Niðurstaða frá mínu síðustu grein var svona: Ég reyndi að innræta (fyrst af öllu) bjartsýni, ég vildi meina að við munum reyna þær aðferðir og vinnubrögð sem við þekktum til að takast á við þá erfiðleika og margbreytileika sem eru á þessu sviði.

Við glímum nú við eftirfarandi IaC vandamál:

• Ófullkomleiki tækja og leiða til að þróa kóða.
• Hæg dreifing. Innviðir eru hluti af hinum raunverulega heimi og það getur verið hægt.
• Skortur á aðferðum og vinnubrögðum.
• Við erum ný og vitum ekki mikið.

Extreme forritun (XP) til bjargar

Allir forritarar þekkja Extreme Programming (XP) og vinnubrögðin sem standa að baki henni. Mörg okkar hafa unnið með þessa nálgun og það hefur gengið vel. Svo hvers vegna ekki að nota þær reglur og venjur sem þar eru settar fram til að sigrast á innviðaáskorunum? Við ákváðum að taka þessa aðferð og sjá hvað gerist.

Athugaðu notagildi XP nálgunarinnar fyrir iðnaðinn þinnHér er lýsing á umhverfinu sem XP hentar vel og hvernig það tengist okkur:

1. Kröfur um breytilegar hugbúnaður. Okkur var ljóst hvert lokamarkmiðið var. En smáatriðin geta verið mismunandi. Við ákveðum sjálf hvert við þurfum að leigubíla, svo kröfurnar breytast reglulega (aðallega af okkur sjálfum). Ef við tökum SRE teymið, sem sér um sjálfvirknivæðinguna, og takmarkar sjálft kröfur og umfang vinnunnar, þá passar þetta atriði vel.

2. Áhætta af völdum fastatímaverkefna þar sem ný tækni er notuð. Við gætum lent í áhættu þegar við notum suma hluti sem okkur eru óþekktir. Og þetta er 100% okkar mál. Allt verkefnið okkar var notkun tækni sem við vorum ekki fullkunnug. Almennt séð er þetta stöðugt vandamál vegna þess að... Það eru mörg ný tækni að koma fram í innviðageiranum allan tímann.

3,4. Lítið, samsett aukið þróunarteymi. Sjálfvirka tæknin sem þú notar gerir kleift að prófa einingar og virkni. Þessir tveir punktar henta okkur ekki alveg. Í fyrsta lagi erum við ekki samstillt lið og í öðru lagi erum við níu sem má telja stórt lið. Þó, samkvæmt sumum skilgreiningum á „stóru“ liði, þá er margt 14+ manns.

Við skulum skoða nokkrar XP venjur og hvernig þær hafa áhrif á hraða og gæði endurgjöf.

XP Feedback Loop Principle

Í mínum skilningi er endurgjöf svarið við spurningunni, er ég að gera rétt, erum við að fara þangað? XP er með guðdómlegt kerfi fyrir þetta: A Time feedback Loop. Það áhugaverða er að því lægra sem við erum, því hraðar getum við fengið stýrikerfið til að svara nauðsynlegum spurningum.

Þetta er frekar áhugavert umræðuefni, að í upplýsingatæknigeiranum okkar er hægt að fá stýrikerfi fljótt. Ímyndaðu þér hversu sársaukafullt það er að vinna verkefni í sex mánuði og komast þá fyrst að því að það var mistök strax í upphafi. Þetta gerist í hönnun og í hvers kyns byggingu flókinna kerfa.

Í tilfelli okkar um IaC hjálpar endurgjöf okkur. Ég mun strax gera smá lagfæringu á skýringarmyndinni hér að ofan: útgáfuáætlunin hefur ekki mánaðarlega lotu heldur gerist nokkrum sinnum á dag. Það eru nokkrar venjur tengdar þessari stýrikerfislotu sem við munum skoða nánar.

Mikilvægt: endurgjöf getur verið lausn á öllum vandamálunum sem lýst er hér að ofan. Ásamt XP-æfingum getur það dregið þig upp úr hyldýpi örvæntingar.

Hvernig á að draga þig upp úr hyldýpi örvæntingar: þrjár æfingar

Próf

Próf eru nefnd tvisvar í XP endurgjöf lykkju. Það er ekki bara þannig. Þau eru afar mikilvæg fyrir alla Extreme-forritunartæknina.

Gert er ráð fyrir að þú hafir eininga- og samþykkispróf. Sumir gefa þér álit á nokkrum mínútum, aðrir á nokkrum dögum, þannig að þau taka lengri tíma að skrifa og eru skoðuð sjaldnar.

Það er til klassískur prófunarpýramídi, sem sýnir að það ættu að vera fleiri próf.

Hvernig á þessi rammi við um okkur í IaC verkefni? Reyndar... alls ekki.

• Einingapróf, þrátt fyrir að þau ættu að vera mörg, geta ekki verið of mörg. Eða þeir eru að prófa eitthvað mjög óbeint. Reyndar getum við sagt að við skrifum þær alls ekki. En hér eru nokkrar umsóknir um slík próf sem við gátum gert:
  1. Er að prófa jsonnet kóða. Þetta er til dæmis drónasamsetningarleiðslan okkar, sem er frekar flókin. Jsonnet kóðann er vel þakinn af prófum.
     Við notum þetta Einingaprófunarrammi fyrir Jsonnet.
  2. Próf fyrir forskriftir sem eru keyrðar þegar tilfangið byrjar. Forskriftir eru skrifaðar í Python og því er hægt að skrifa próf á þau.
• Það er hugsanlega hægt að athuga stillingarnar í prófunum, en við gerum það ekki. Það er líka hægt að stilla stillingarreglur eftirlitsaðfanga í gegnum tflint. Hins vegar eru athuganir þar einfaldlega of grunnar fyrir terraform, en mörg prófforskriftir eru skrifaðar fyrir AWS. Og við erum á Azure, svo þetta á ekki við.
• Samþættingarpróf íhluta: það fer eftir því hvernig þú flokkar þau og hvar þú setur þau. En þeir virka í grundvallaratriðum.

  Svona líta samþættingarpróf út.

  
  
  Þetta er dæmi þegar þú byggir myndir í Drone CI. Til að ná til þeirra þarftu að bíða í 30 mínútur þar til Packer myndin myndast og bíða síðan í 15 mínútur í viðbót þar til þau fara framhjá. En þeir eru til!

  Myndastaðfestingaralgrím

  1. Packer verður fyrst að undirbúa myndina alveg.
  2. Við hliðina á prófinu er terraform með staðbundnu ríki, sem við notum til að dreifa þessari mynd.
  3. Við uppbrot er lítil eining sem liggur nálægt til að auðvelda vinnu með myndina.
  4. Þegar VM hefur verið dreift frá myndinni geta athuganir hafist. Í grundvallaratriðum fer eftirlit fram með bíl. Það athugar hvernig forskriftirnar virkuðu við ræsingu og hvernig púkarnir virka. Til að gera þetta, í gegnum ssh eða winrm, skráum við okkur inn á nýlega upphækkuðu vélina og athugum stillingarstöðuna eða hvort þjónustan sé uppi.

• Svipað er uppi á teningnum með samþættingarpróf í einingum fyrir terraform. Hér er stutt tafla sem útskýrir eiginleika slíkra prófa.

  
  
  Endurgjöf um leiðsluna er um 40 mínútur. Allt gerist í mjög langan tíma. Það er hægt að nota fyrir afturför, en fyrir nýja þróun er það almennt óraunhæft. Ef þú ert mjög, mjög tilbúinn fyrir þetta, undirbúið keyrsluforskriftir, þá geturðu dregið það niður í 10 mínútur. En þetta eru samt ekki einingapróf, sem gera 5 stykki á 100 sekúndum.

Skortur á einingaprófum við að setja saman myndir eða terraform einingar hvetur til að færa vinnuna yfir í aðskilda þjónustu sem einfaldlega er hægt að keyra með REST, eða yfir í Python forskriftir.

Til dæmis þurftum við að ganga úr skugga um að þegar sýndarvélin fer í gang skráir hún sig í þjónustuna ScaleFT, og þegar sýndarvélin var eytt eyddi hún sjálfri sér.

Þar sem við erum með ScaleFT sem þjónustu neyðumst við til að vinna með hana í gegnum API. Það var umbúðir skrifaðar þar sem þú gætir dregið og sagt: "Farðu inn og eyddu hinu og þessu." Það geymir allar nauðsynlegar stillingar og aðgang.

Við getum nú þegar skrifað venjuleg próf fyrir þetta, þar sem það er ekkert frábrugðið venjulegum hugbúnaði: einhvers konar apiha er spottaður, þú togar í það og sérð hvað gerist.

Niðurstöður prófana: Einingaprófun, sem ætti að gefa stýrikerfinu eftir eina mínútu, gefur það ekki. Og tegundir prófa ofar í pýramídanum eru árangursríkar, en ná aðeins yfir hluta vandamálanna.

Para forritun

Próf eru auðvitað góð. Þú getur skrifað mikið af þeim, þau geta verið af mismunandi gerðum. Þeir munu vinna á sínum stigum og gefa okkur endurgjöf. En vandamálið við slæmar einingapróf, sem gefa hraðasta stýrikerfið, er enn eftir. Á sama tíma vil ég enn hraðvirkt stýrikerfi sem er auðvelt og notalegt að vinna með. Svo ekki sé minnst á gæði lausnarinnar sem fæst. Sem betur fer eru til aðferðir sem geta veitt enn hraðari endurgjöf en einingapróf. Þetta er paraforritun.

Þegar þú skrifar kóða viltu fá endurgjöf um gæði hans eins fljótt og auðið er. Já, þú getur skrifað allt í eiginleikagrein (til þess að brjóta ekki neitt fyrir neinn), lagt fram dráttarbeiðni í Github, úthlutað henni til einhvers sem hefur álit sitt vægi og beðið eftir svari.

En þú getur beðið lengi. Fólk er allt upptekið og svarið, jafnvel þótt það sé eitt, er kannski ekki í hæsta gæðaflokki. Segjum sem svo að svarið hafi komið strax, gagnrýnandinn skildi alla hugmyndina samstundis, en svarið kemur samt seint, eftir á. Ég vildi að það væri fyrr. Þetta er það sem paraforritun miðar að - strax, þegar þetta er skrifað.

Hér að neðan eru forritunarstíll para og notagildi þeirra í vinnu við IaC:

1. Klassískt, reyndur+reyndur, skipt eftir tímamæli. Tvö hlutverk - bílstjóri og stýrimaður. Tvær manneskjur. Þeir vinna á sama kóða og skipta um hlutverk eftir ákveðinn fyrirfram ákveðinn tíma.

Við skulum íhuga samhæfni vandamála okkar við stíl:

• Vandamál: ófullkomleiki tækja og tóla fyrir kóðaþróun.
  Neikvæð áhrif: það tekur lengri tíma að þróast, við hægjum á okkur, hraðinn/takturinn í vinnunni glatast.
  Hvernig við berjumst: við notum önnur verkfæri, sameiginlega IDE og lærum líka flýtileiðir.
• Vandamál: Hæg dreifing.
  Neikvæð áhrif: eykur tímann sem það tekur að búa til vinnukóða. Okkur leiðist á meðan við bíðum, hendurnar teygja okkur út til að gera eitthvað annað á meðan við bíðum.
  Hvernig við berjumst: við sigruðum það ekki.
• Vandamál: skortur á aðferðum og vinnubrögðum.
  Neikvæð áhrif: það er engin þekking á því hvernig á að gera það vel og hvernig á að gera það illa. Lengir móttöku endurgjöf.
  Hvernig við berjumst: gagnkvæm skoðanaskipti og venjur í paravinnu leysir nánast vandamálið.

Helsta vandamálið við að nota þennan stíl í IaC er ójafn vinnuhraði. Í hefðbundinni hugbúnaðarþróun hefur þú mjög einsleita hreyfingu. Þú getur eytt fimm mínútum og skrifað N. Eyddu 10 mínútum og skrifaðu 2N, 15 mínútur - 3N. Hér geturðu eytt fimm mínútum og skrifað N, og eytt síðan 30 mínútum í viðbót og skrifað tíunda af N. Hér veistu ekki neitt, þú ert fastur, heimskur. Rannsóknin tekur tíma og dregur athyglina frá sjálfri forrituninni.

Ályktun: í sinni hreinu mynd hentar það okkur ekki.

2. Borðtennis. Þessi nálgun felur í sér að einn skrifar prófið og annar gerir útfærslu fyrir það. Að teknu tilliti til þeirrar staðreyndar að allt er flókið með Unit tests, og þú þarft að skrifa samþættingarpróf sem tekur langan tíma að forrita, hverfur öll auðveldið við borðtennis.

Ég get sagt að við reyndum að aðskilja ábyrgð á því að hanna prófunarforskrift og innleiða kóða fyrir það. Einn þátttakandi kom með handritið, í þessum hluta verksins sem hann bar ábyrgð á átti hann síðasta orðið. Og hinn bar ábyrgð á framkvæmdinni. Það tókst vel. Gæði handritsins með þessari nálgun aukast.

Ályktun: því miður, vinnuhraði leyfir ekki notkun borðtennis sem paraforritunaræfingar í IaC.

3.Strong Style. Erfið æfing. Hugmyndin er sú að annar þátttakandinn verði leiðbeinandi og hinn taki hlutverk aftökubílstjóra. Í þessu tilviki hvílir rétturinn til að taka ákvarðanir eingöngu á siglingastjóranum. Ökumaðurinn prentar aðeins út og getur haft áhrif á það sem er að gerast með orði. Hlutverkin breytast ekki í langan tíma.

Gott til að læra, en krefst sterkrar mjúkrar færni. Þetta er þar sem við töpuðum. Tæknin var erfið. Og það snýst ekki einu sinni um innviði.

Ályktun: það er hugsanlega hægt að nota það, við erum ekki að gefast upp á að reyna.

4. Mobbing, swarming og allir þekktir en ekki skráðir stílar Við teljum það ekki, vegna þess Við höfum ekki reynt það og það er ómögulegt að tala um það í samhengi við vinnu okkar.

Almennar niðurstöður um notkun paraforritunar:

• Við erum með ójafnan vinnuhraða, sem er ruglingslegt.
• Við lentum í ófullnægjandi mjúkfærni. Og málefnasviðið hjálpar ekki til við að vinna bug á þessum göllum okkar.
• Langar prófanir og vandamál með verkfæri gera pöruð þróun erfið.

5. Þrátt fyrir þetta var árangur. Við komum með okkar eigin aðferð „Convergence - Divergence“. Ég mun lýsa stuttlega hvernig það virkar.

Við erum með fasta samstarfsaðila í nokkra daga (minna en viku). Við gerum eitt verkefni saman. Við sitjum saman um stund: annar skrifar, hinn situr og fylgist með stuðningsteyminu. Svo dreifumst við í einhvern tíma, hver gerir einhverja sjálfstæða hluti, svo komum við saman aftur, samstillumst mjög hratt, gerum eitthvað saman og tvístruðumst aftur.

Skipulag og samskipti

Síðasti aðferðaflokkurinn sem stýrikerfisvandamál eru leyst með er skipulag vinnu við verkefnin sjálf. Þetta felur einnig í sér reynsluskipti sem eru utan paravinnu. Við skulum skoða þrjár aðferðir:

1. Markmið í gegnum markatréð. Við skipulögðum heildarstjórnun verkefnisins í gegnum tré sem fer endalaust inn í framtíðina. Tæknilega séð fer rakningin fram í Miro. Það er eitt verkefni - það er millimarkmið. Þaðan fara ýmist smærri markmið eða verkefnahópar. Verkefnin sjálf koma frá þeim. Öll verkefni eru búin til og viðhaldið á þessu borði.

Þetta kerfi veitir einnig endurgjöf, sem á sér stað einu sinni á dag þegar við samstillum á mótum. Að hafa sameiginlega áætlun fyrir framan alla, en skipulögð og algjörlega opin, gerir öllum kleift að vera meðvitaðir um hvað er að gerast og hversu langt við erum komin.

Kostir sjónrænnar sýn á verkefni:

• Orsakasamband. Hvert verkefni leiðir að einhverju heimsmarkmiði. Verkefnum er flokkað í smærri markmið. Innviðasvæðið sjálft er nokkuð tæknilegt. Það er ekki alltaf strax ljóst hvaða sérstök áhrif, til dæmis að skrifa runbook um flutning til annars nginx, hefur á fyrirtækið. Að hafa markspjaldið nálægt gerir það skýrara.
  
  Orsakasamband er mikilvægur eiginleiki vandamála. Það svarar beint spurningunni: "Er ég að gera rétt?"
• Hliðstæður. Við erum níu og það er einfaldlega líkamlega ómögulegt að henda öllum í eitt verkefni. Verkefni frá einu svæði eru kannski ekki alltaf nóg heldur. Við neyðumst til að samsíða vinnu milli lítilla vinnuhópa. Jafnframt sitja hóparnir að verkefni sínu í nokkurn tíma, þeir geta fengið styrkingu frá öðrum. Stundum falla menn frá þessum starfshópi. Einhver fer í frí, einhver gerir skýrslu fyrir DevOps conf, einhver skrifar grein á Habr. Að vita hvaða markmið og verkefni er hægt að vinna samhliða verður mjög mikilvægt.

2. Afleysingarkynnendur morgunfunda. Í uppistandi erum við með þetta vandamál - fólk sinnir mörgum verkum samhliða. Stundum eru verkefni lauslega tengd og það er enginn skilningur á því hver er að gera hvað. Og álit annars liðsmanns er mjög mikilvægt. Þetta eru viðbótarupplýsingar sem geta breytt ferlinu við að leysa vandamálið. Auðvitað er venjulega einhver með þér, en ráð og ábendingar eru alltaf gagnlegar.

Til að bæta þetta ástand notuðum við tæknina „Að breyta leiðandi uppistandi“. Nú er þeim snúið eftir ákveðnum lista og það hefur sín áhrif. Þegar röðin kemur að þér neyðist þú til að kafa inn og skilja hvað er að gerast til að halda góðan Scrum fund.

3. Innri kynning. Hjálp við að leysa vandamál frá paraforritun, sjónmynd á vandamálatrénu og aðstoð á scrum fundum á morgnana er góð, en ekki tilvalin. Sem par takmarkast þið aðeins af þekkingu ykkar. Verkefnatréð hjálpar til við að skilja á heimsvísu hver er að gera hvað. Og kynnirinn og samstarfsmenn á morgunfundinum munu ekki kafa djúpt í vandamál þín. Þeir gætu vissulega misst af einhverju.

Lausnin var fundin í því að sýna hver öðrum vinnuna sem unnin voru og ræða það síðan. Við hittumst einu sinni í viku í klukkutíma og sýnum upplýsingar um lausnir á verkefnum sem við höfum unnið undanfarna viku.

Á meðan á sýningunni stendur er nauðsynlegt að sýna upplýsingar um verkefnið og vera viss um að sýna fram á virkni þess.

Skýrsluna er hægt að framkvæma með því að nota gátlista.1. Settu inn í samhengi. Hvaðan kom verkefnið, hvers vegna var það jafnvel nauðsynlegt?

2. Hvernig var vandamálið leyst áður? Til dæmis var nauðsynlegt að smella með músinni, eða það var ómögulegt að gera neitt.

3. Hvernig við bætum það. Til dæmis: "Sjáðu, nú er scriptosik, hér er readme."

4. Sýndu hvernig það virkar. Það er ráðlegt að innleiða einhverja notendaatburðarás beint. Ég vil X, ég geri Y, ég sé Y (eða Z). Til dæmis set ég inn NGINX, reyki slóðina og fæ 200 OK. Ef aðgerðin er löng skaltu undirbúa hana fyrirfram svo þú getir sýnt hana síðar. Það er ráðlegt að brjóta það ekki of mikið klukkutíma fyrir kynninguna, ef það er viðkvæmt.

5. Útskýrðu hversu farsællega tókst að leysa vandamálið, hvaða erfiðleikar eru eftir, hvað er ekki lokið, hvaða úrbætur eru mögulegar í framtíðinni. Til dæmis, núna CLI, þá verður full sjálfvirkni í CI.

Það er ráðlegt fyrir hvern hátalara að halda því í 5-10 mínútur. Ef ræðan þín er augljóslega mikilvæg og mun taka lengri tíma skaltu samþykkja það fyrirfram í sre-yfirtökurásinni.

Eftir augliti til auglitis er alltaf umræða í þræðinum. Hér birtist endurgjöfin sem við þurfum á verkefnum okkar.

Í kjölfarið er gerð könnun til að kanna gagnsemi þess sem er að gerast. Þetta er endurgjöf um kjarna ræðunnar og mikilvægi verkefnisins.

Langar ályktanir og hvað er næst

Það kann að virðast sem tónninn í greininni sé nokkuð svartsýnn. Þetta er rangt. Tvö lægri stig endurgjöf, þ.e. próf og paraforritun, vinna. Ekki eins fullkomið og í hefðbundinni þróun, en það eru jákvæð áhrif af því.

Próf, í núverandi mynd, veita aðeins hluta kóðaþekju. Margar stillingaraðgerðir enda óprófaðar. Áhrif þeirra á raunverulega vinnu við ritun kóða eru lítil. Hins vegar eru áhrif frá samþættingarprófum og þau gera þér kleift að framkvæma endurstillingar óttalaust. Þetta er frábær árangur. Einnig, með breytingu á fókus á þróun í tungumálum á háu stigi (við höfum python, farðu), vandamálið hverfur. Og þú þarft ekki mikið af eftirliti fyrir „límið“; almenn samþættingarathugun er nóg.

Að vinna í pörum fer meira eftir ákveðnu fólki. Það er verkefnisþátturinn og mjúk færni okkar. Hjá sumum gengur þetta mjög vel, hjá öðrum gengur það verr. Það eru svo sannarlega kostir við þetta. Ljóst er að jafnvel þótt reglum paravinnu sé ekki fylgt nægilega vel hefur það sjálft að vinna verkefni saman jákvæð áhrif á gæði niðurstöðunnar. Persónulega finnst mér að vinna í pörum auðveldara og skemmtilegra.

Leiðir á hærra stigi til að hafa áhrif á stýrikerfið - að skipuleggja og vinna með verkefni hafa nákvæmlega áhrif: hágæða þekkingarskipti og bætt þróunargæði.

Stuttar ályktanir í einni línu

• HR sérfræðingar vinna í IaC, en með minni skilvirkni.
• Styrkja það sem virkar.
• Komdu með þína eigin uppbótaraðferðir og venjur.

Heimild: www.habr.com