Infrastruktura kot koda: kako premagati težave z uporabo XP

Pozdravljeni, Habr! Prej sem se pritoževal nad življenjem v paradigmi infrastrukture kot kode in nisem ponudil ničesar za rešitev trenutne situacije. Danes se vračam, da vam povem, kateri pristopi in prakse vam bodo pomagali pobegniti iz brezna obupa in usmeriti situacijo v pravo smer.

V prejšnjem članku "Infrastruktura kot koda: prvo spoznavanje" Delil sem svoje vtise o tem področju, poskušal razmisliti o trenutnem stanju na tem področju in celo predlagal, da bi lahko pomagale standardne prakse, ki jih poznajo vsi razvijalci. Morda se zdi, da je bilo veliko pritožb nad življenjem, vendar ni bilo predlogov za izhod iz trenutne situacije.

Kdo smo, kje smo in kakšne težave imamo

Trenutno smo v ekipi Sre Onboarding Team, ki jo sestavlja šest programerjev in trije infrastrukturni inženirji. Vsi poskušamo napisati infrastrukturo kot kodo (IaC). To počnemo, ker v bistvu znamo pisati kodo in imamo zgodovino »nadpovprečnih« razvijalcev.

• Imamo vrsto prednosti: določeno ozadje, poznavanje praks, sposobnost pisanja kode, željo po učenju novih stvari.
• In tu je še en del, ki je tudi minus: pomanjkanje znanja o infrastrukturni strojni opremi.

Tehnološki sklop, ki ga uporabljamo v našem IAC.

• Terraform za ustvarjanje virov.
• Packer za sestavljanje slik. To so slike sistema Windows, CentOS 7.
• Jsonnet za izdelavo zmogljive zgradbe v drone.io, pa tudi za generiranje pakerja json in naših terraform modulov.
• Azure.
• Možno pri pripravi slik.
• Python za pomožne storitve in skripte za zagotavljanje.
• In vse to v VSCode z vtičniki, ki si jih delijo člani ekipe.

Sklep iz mojega zadnji članek je bilo takole: poskušal sem vliti (najprej v sebi) optimizem, želel sem povedati, da bomo poskusili z nam znanimi pristopi in praksami, da bi se soočili s težavami in kompleksnostmi, ki obstajajo na tem področju.

Trenutno se spopadamo z naslednjimi težavami IAC:

• Nepopolnost orodij in sredstev za razvoj kode.
• Počasno uvajanje. Infrastruktura je del resničnega sveta in je lahko počasna.
• Pomanjkanje pristopov in praks.
• Smo novi in ​​ne vemo veliko.

Ekstremno programiranje (XP) na pomoč

Vsi razvijalci poznajo ekstremno programiranje (XP) in prakse, ki stojijo za njim. Mnogi od nas smo delali s tem pristopom in bil je uspešen. Zakaj torej ne bi uporabili tam določenih načel in praks za premagovanje infrastrukturnih izzivov? Odločili smo se za ta pristop in videli, kaj se zgodi.

Preverjanje uporabnosti pristopa XP v vaši industrijiTukaj je opis okolja, za katerega je XP zelo primeren, in kako je povezan z nami:

1. Dinamično spreminjanje programskih zahtev. Jasno nam je bilo, kaj je končni cilj. Toda podrobnosti se lahko razlikujejo. Sami se odločamo, kje bomo vozili taksi, zato se zahteve občasno spreminjajo (predvsem sami). Če vzamemo ekipo SRE, ki sama dela avtomatizacijo in sama omejuje zahteve in obseg dela, potem ta točka dobro ustreza.

2. Tveganja, ki jih povzročajo projekti z določenim časom, ki uporabljajo novo tehnologijo. Pri uporabi nekaterih nam neznanih stvari lahko naletimo na tveganje. In to je 100% naš primer. Naš celoten projekt je bil uporaba tehnologij, ki jih nismo povsem poznali. Na splošno je to stalni problem, saj... V infrastrukturnem sektorju se ves čas pojavlja veliko novih tehnologij.

3,4. Majhna razširjena razvojna ekipa, ki se nahaja na istem mestu. Avtomatizirana tehnologija, ki jo uporabljate, omogoča enotne in funkcionalne teste. Ti dve točki nam ne ustrezata povsem. Prvič, nismo usklajena ekipa, drugič, devet nas je, kar lahko štejemo za veliko ekipo. Čeprav je po nekaterih definicijah »velike« ekipe veliko 14+ ljudi.

Oglejmo si nekaj praks XP in kako vplivajo na hitrost in kakovost povratnih informacij.

Načelo povratne zanke XP

Po mojem mnenju je povratna informacija odgovor na vprašanje, ali delam pravo stvar, ali gremo tja? XP ima za to božansko shemo: časovno povratno zanko. Zanimivo je, da nižje ko smo, hitreje lahko OS pripravimo do odgovorov na potrebna vprašanja.

To je precej zanimiva tema za razpravo, da je v naši IT industriji mogoče hitro dobiti OS. Predstavljajte si, kako boleče je delati projekt šest mesecev in šele nato ugotoviti, da je bila napaka že na samem začetku. To se dogaja pri načrtovanju in pri gradnji kompleksnih sistemov.

V našem primeru IAC nam povratne informacije pomagajo. Takoj bom naredil majhno prilagoditev zgornjega diagrama: načrt izdaje nima mesečnega cikla, ampak se pojavi večkrat na dan. Obstaja nekaj praks, povezanih s tem ciklom OS, ki si jih bomo podrobneje ogledali.

Pomembno: povratne informacije so lahko rešitev za vse zgoraj navedene težave. V kombinaciji s praksami XP vas lahko potegne iz brezna obupa.

Kako se potegniti iz brezna obupa: tri prakse

Testi

Testi so dvakrat omenjeni v povratni zanki XP. Ni kar tako. So izjemno pomembni za celotno tehniko ekstremnega programiranja.

Predvideva se, da imate test enote in sprejemljivost. Nekateri vam povratne informacije posredujejo v nekaj minutah, drugi v nekaj dneh, zato njihovo pisanje traja dlje in so redkeje pregledani.

Obstaja klasična piramida testiranja, ki kaže, da mora biti testov več.

Kako se ta okvir uporablja za nas v projektu IAC? Pravzaprav ... sploh ne.

• Unit testov, kljub temu, da bi jih moralo biti veliko, ne more biti preveč. Ali pa nekaj zelo posredno testirajo. Pravzaprav lahko rečemo, da jih sploh ne pišemo. Toda tukaj je nekaj aplikacij za takšne teste, ki smo jih lahko opravili:
  1. Testiranje kode jsonnet. To je na primer naš cevovod za montažo dronov, ki je precej zapleten. Koda jsonnet je dobro pokrita s testi.
     Uporabljamo to Ogrodje za testiranje enot za Jsonnet.
  2. Preizkusi za skripte, ki se izvajajo ob zagonu vira. Skripte so napisane v Pythonu, zato je na njih mogoče pisati teste.
• Potencialno je možno preveriti konfiguracijo v testih, vendar tega ne počnemo. Prav tako je mogoče konfigurirati pravila konfiguracije preverjanja virov prek tflint. Vendar so tamkajšnja preverjanja preprosto preveč osnovna za terraform, vendar je veliko testnih skriptov napisanih za AWS. In mi smo na Azure, tako da to spet ne velja.
• Preizkusi integracije komponent: odvisno je od tega, kako jih razvrstite in kam jih postavite. Ampak v bistvu delujejo.

  Tako izgledajo integracijski testi.

  
  
  To je primer gradnje slik v Drone CI. Če jih želite doseči, morate počakati 30 minut, da se oblikuje slika Packer, nato pa počakati še 15 minut, da minejo. Vendar obstajajo!

  Algoritem za preverjanje slike

  1. Packer mora najprej popolnoma pripraviti sliko.
  2. Poleg testa je teraforma z lokalnim stanjem, ki jo uporabimo za razporeditev te slike.
  3. Pri razgrnitvi se za lažje delo s sliko uporablja majhen modul, ki leži v bližini.
  4. Ko je VM razporejen iz slike, se lahko začnejo preverjanja. V osnovi se pregledi izvajajo z avtomobilom. Preveri, kako so skripti delovali ob zagonu in kako delujejo demoni. Da bi to naredili, se prek ssh ali winrm prijavimo v novo dvignjeno napravo in preverimo stanje konfiguracije ali ali so storitve vzpostavljene.

• Podobno je z integracijskimi testi v modulih za terraform. Tukaj je kratka tabela, ki pojasnjuje značilnosti takih testov.

  
  
  Povratne informacije o cevovodu so približno 40 minut. Vse se dogaja zelo dolgo. Lahko se uporablja za regresijo, za nov razvoj pa je na splošno nerealno. Če ste na to zelo, zelo pripravljeni, pripravite tekoče skripte, potem lahko skrajšate na 10 minut. Ampak to še vedno niso Unit testi, ki naredijo 5 kosov v 100 sekundah.

Odsotnost testov enot pri sestavljanju slik ali modulov terraform spodbuja preusmeritev dela na ločene storitve, ki jih je mogoče preprosto izvajati prek REST, ali na skripte Python.

Na primer, morali smo zagotoviti, da se virtualni stroj ob zagonu sam registrira v storitvi ScaleFT, in ko je bil virtualni stroj uničen, se je izbrisal sam.

Ker imamo ScaleFT kot storitev, smo prisiljeni delati z njo prek API-ja. Tam je bil napisan ovoj, ki ga lahko potegneš in rečeš: "Pojdi noter in izbriši to in to." Shranjuje vse potrebne nastavitve in dostope.

Za to že lahko napišemo običajne teste, saj se ne razlikuje od navadne programske opreme: nekakšna apiha se posmehuje, jo potegneš in vidiš, kaj se zgodi.

Rezultati testov: Testiranje enote, ki bi moralo dati OS v minuti, ga ne da. In vrste testiranja višje v piramidi so učinkovite, vendar pokrivajo le del težav.

Programiranje v paru

Testi so seveda dobri. Lahko jih napišete veliko, lahko so različnih vrst. Delali bodo na svojih ravneh in nam posredovali povratne informacije. A problem s slabimi Unit testi, ki dajejo najhitrejši OS, ostaja. Hkrati pa si še vedno želim hiter OS, s katerim je enostavno in prijetno delati. Da ne omenjam kakovosti nastale rešitve. Na srečo obstajajo tehnike, ki lahko zagotovijo še hitrejše povratne informacije kot testi enot. To je programiranje v paru.

Ko pišete kodo, želite čim hitreje dobiti povratne informacije o njeni kakovosti. Da, vse lahko napišeš v vejo funkcij (da ne bi komu kaj pokvaril), narediš zahtevo za vleko v Githubu, jo dodeliš nekomu, čigar mnenje ima težo, in počakaš na odgovor.

Lahko pa čakaš dolgo. Ljudje so vsi zaposleni in odgovor, tudi če ga je, morda ni najbolj kakovosten. Recimo, da je odgovor prišel takoj, recenzent je v trenutku razumel celotno idejo, vendar odgovor kljub temu pride pozno. Želim si, da bi bilo prej. Temu je namenjeno programiranje v parih – takoj, v času pisanja.

Spodaj so slogi parov programiranja in njihova uporabnost pri delu na IaC:

1. Klasično, Izkušeni+Izkušeni, prestavljanje s časovnikom. Dve vlogi – voznik in navigator. Dva človeka. Delajo na isti kodi in po določenem vnaprej določenem času zamenjajo vloge.

Razmislimo o združljivosti naših težav s slogom:

• Problem: nepopolnost orodij in orodij za razvoj kode.
  Negativni vpliv: razvija se dlje, upočasnimo se, tempo/ritem dela se izgubi.
  Kako se borimo: uporabljamo drugačna orodja, skupni IDE in se tudi učimo bližnjic.
• Težava: Počasno uvajanje.
  Negativni učinek: podaljša čas, ki je potreben za ustvarjanje delujoče kode. Med čakanjem se dolgočasimo, med čakanjem se nam segajo roke, da počnemo kaj drugega.
  Kako se borimo: nismo ga premagali.
• Problem: pomanjkanje pristopov in praks.
  Negativni vpliv: ni znanja o tem, kako narediti dobro in kako slabo. Podaljša prejem povratnih informacij.
  Kako se kregamo: medsebojna izmenjava mnenj in praks pri delu v paru skoraj reši problem.

Glavna težava pri uporabi tega sloga v IaC je neenakomeren tempo dela. Pri tradicionalnem razvoju programske opreme imate zelo enotno gibanje. Lahko porabite pet minut in napišete N. Porabite 10 minut in napišite 2N, 15 minut - 3N. Tukaj lahko porabiš pet minut in napišeš N, nato pa porabiš še 30 minut in napišeš desetinko N. Tukaj ne veš ničesar, obtičal si, neumen. Preiskava zahteva čas in odvrne pozornost od samega programiranja.

Zaključek: v čisti obliki za nas ni primeren.

2. Ping-pong. Ta pristop vključuje, da ena oseba napiše test, druga pa izvaja njegovo izvedbo. Ob upoštevanju dejstva, da je pri testih enot vse zapleteno in morate napisati integracijski test, ki traja dolgo za programiranje, vsa lahkotnost ping-ponga izgine.

Lahko rečem, da smo poskušali ločiti odgovornosti za oblikovanje testnega skripta in implementacijo kode zanj. En udeleženec se je domislil scenarija, v tem delu dela je bil odgovoren, imel je zadnjo besedo. In drugi je bil odgovoren za izvedbo. Dobro se je izšlo. Kakovost scenarija s tem pristopom se poveča.

Zaključek: žal, tempo dela ne dovoljuje uporabe ping-ponga kot prakse programiranja v parih v IaC.

3. Močan slog. Težka praksa. Ideja je, da en udeleženec postane navigator smernic, drugi pa prevzame vlogo izvajalca. V tem primeru ima pravico do odločanja izključno navigator. Voznik samo tiska in lahko z besedo vpliva na dogajanje. Vloge se dolgo ne menjajo.

Dobro za učenje, vendar zahteva močne mehke veščine. Tukaj smo omahovali. Tehnika je bila težka. In sploh ne gre za infrastrukturo.

Zaključek: potencialno se lahko uporablja, ne odnehamo poskušati.

4. Mobbing, swarming in vsi znani, a ne našteti stili Ne upoštevamo, ker Tega nismo poskusili in o tem v okviru našega dela ni mogoče govoriti.

Splošni rezultati uporabe programiranja v parih:

• Imamo neenakomeren tempo dela, kar nas moti.
• Naleteli smo na premalo dobre mehke veščine. In predmetno področje ne pomaga premagati teh naših pomanjkljivosti.
• Dolgi testi in težave z orodji otežujejo razvoj v paru.

5. Kljub temu so bili uspehi. Prišli smo do lastne metode »Konvergenca - Divergenca«. Na kratko bom opisal, kako deluje.

Imamo stalne partnerje za nekaj dni (manj kot teden dni). Skupaj opravimo eno nalogo. Nekaj ​​časa sedimo skupaj: eden piše, drugi sedi in opazuje ekipo za podporo. Potem se za nekaj časa razidemo, vsak počne neke samostojne stvari, potem se spet zberemo, se zelo hitro sinhroniziramo, nekaj naredimo skupaj in se spet razidemo.

Načrtovanje in komuniciranje

Zadnji sklop praks, s katerimi se rešujejo težave OS, je organizacija dela s samimi nalogami. To vključuje tudi izmenjavo izkušenj, ki je izven dela v paru. Poglejmo tri prakse:

1. Cilji skozi drevo ciljev. Celotno vodenje projekta smo organizirali skozi drevo, ki sega neskončno v prihodnost. Tehnično se sledenje izvaja v Miru. Obstaja ena naloga - to je vmesni cilj. Iz njega gredo bodisi manjši cilji bodisi skupine nalog. Naloge same izhajajo iz njih. Vse naloge so ustvarjene in vzdrževane na tej plošči.

Ta shema omogoča tudi povratne informacije, ki se pojavljajo enkrat dnevno, ko se sinhroniziramo na shodih. Imeti skupen načrt pred vsemi, vendar strukturiran in popolnoma odprt, omogoča vsem, da se zavedajo, kaj se dogaja in kako daleč smo napredovali.

Prednosti vizualnega videnja nalog:

• Vzročnost. Vsaka naloga vodi do nekega globalnega cilja. Naloge so združene v manjše cilje. Sama infrastrukturna domena je precej tehnična. Ni vedno takoj jasno, kakšen poseben vpliv ima na primer pisanje runbooka o selitvi na drug nginx na podjetje. Če imate ciljno kartico v bližini, je bolj jasno.
  
  Vzročnost je pomembna lastnost problemov. Neposredno odgovarja na vprašanje: "Ali delam pravo stvar?"
• Paralelizem. Devet nas je in enostavno je fizično nemogoče vse vreči k eni nalogi. Tudi naloge z enega področja morda niso vedno dovolj. Prisiljeni smo paralelizirati delo med majhnimi delovnimi skupinami. Skupine ob tem nekaj časa sedijo na svoji nalogi, lahko jih okrepi še kdo. Včasih ljudje odpadejo iz te delovne skupine. Nekdo gre na dopust, nekdo naredi poročilo za DevOps conf, nekdo napiše članek na Habru. Vedeti, katere cilje in naloge je mogoče izvajati vzporedno, postane zelo pomembno.

2. Nadomestni voditelji jutranjih srečanj. Pri stand-upih imamo ta problem – ljudje opravljajo veliko nalog vzporedno. Včasih so naloge ohlapno povezane in ni razumevanja, kdo kaj dela. In mnenje drugega člana ekipe je zelo pomembno. To je dodatna informacija, ki lahko spremeni potek reševanja problema. Seveda je običajno nekdo s teboj, a nasveti in nasveti so vedno koristni.

Da bi izboljšali to situacijo, smo uporabili tehniko »Spreminjanje vodilnega položaja«. Zdaj se menjajo po določenem seznamu in to ima svoj učinek. Ko ste na vrsti, ste prisiljeni poglobiti se in razumeti, kaj se dogaja, da lahko vodite dober sestanek Scrum.

3. Interni demo. Pomoč pri reševanju problema iz programiranja v paru, vizualizacija na problemskem drevesu in pomoč na scrum srečanjih zjutraj so dobri, vendar niso idealni. Kot par ste omejeni le s svojim znanjem. Drevo opravil pomaga globalno razumeti, kdo kaj dela. In voditelj in sodelavci na jutranjem sestanku se ne bodo poglobili v vaše težave. Zagotovo lahko kaj zamudijo.

Rešitev so našli v tem, da so drug drugemu prikazali opravljeno delo in se o tem pogovarjali. Srečujemo se enkrat tedensko za eno uro in pokažemo podrobnosti rešitev nalog, ki smo jih opravili v preteklem tednu.

Med demonstracijo je treba razkriti podrobnosti naloge in obvezno prikazati njeno delovanje.

Poročilo je mogoče izvesti s kontrolnim seznamom.1. Vstopite v kontekst. Od kod naloga, zakaj je bila sploh potrebna?

2. Kako je bil problem rešen prej? Zahtevano je bilo na primer veliko klikanje z miško ali pa je bilo nemogoče storiti karkoli.

3. Kako ga izboljšamo. Na primer: "Glej, zdaj je scriptosik, tukaj je readme."

4. Pokažite, kako deluje. Priporočljivo je neposredno implementirati nek uporabniški scenarij. Želim X, naredim Y, vidim Y (ali Z). Na primer, uvedem NGINX, pokadim url in dobim 200 OK. Če je akcija dolga, jo pripravite vnaprej, da jo boste lahko prikazali pozneje. Priporočljivo je, da ga ne zlomite preveč eno uro pred predstavitvijo, če je krhek.

5. Pojasnite, kako uspešno je bil problem rešen, katere težave ostajajo, kaj še ni dokončano, kakšne izboljšave so možne v prihodnosti. Na primer, zdaj CLI, potem bo popolna avtomatizacija v CI.

Priporočljivo je, da vsak govornik traja 5-10 minut. Če je vaš govor očitno pomemben in bo trajal dlje, to vnaprej uskladite v kanalu sre-takeover.

Po delu iz oči v oči vedno sledi razprava v temi. Tu se pojavijo povratne informacije, ki jih potrebujemo za naše naloge.

Posledično se izvede raziskava, da se ugotovi koristnost dogajanja. To je povratna informacija o bistvu govora in pomembnosti naloge.

Dolgi zaključki in kaj sledi

Morda se zdi, da je ton članka nekoliko pesimističen. To je narobe. Delujeta dve nižji ravni povratnih informacij, in sicer testi in programiranje v parih. Ni tako popoln kot v tradicionalnem razvoju, vendar je pozitiven učinek.

Testi v svoji trenutni obliki zagotavljajo le delno pokritost kode. Veliko konfiguracijskih funkcij na koncu ostane nepreizkušenih. Njihov vpliv na dejansko delo pri pisanju kode je majhen. Vendar pa obstaja učinek integracijskih testov in vam omogočajo, da brez strahu izvajate preoblikovanje. To je velik dosežek. Tudi s preusmeritvijo fokusa na razvoj v jezikih na visoki ravni (imamo python, go), težava izgine. In ne potrebujete veliko preverjanj za "lepilo", dovolj je splošno preverjanje integracije.

Delo v paru je bolj odvisno od konkretnih ljudi. Obstajata dejavnik naloge in naše mehke veščine. Pri nekaterih ljudeh gre zelo dobro, pri drugih slabše. Od tega so vsekakor koristi. Jasno je, da tudi če pravila dela v parih niso dovolj upoštevana, že samo skupno opravljanje nalog pozitivno vpliva na kakovost rezultata. Osebno se mi zdi delo v paru lažje in prijetnejše.

Višji nivojski načini vplivanja na OS - načrtovanje in delo z nalogami natančno proizvajajo učinke: kakovostna izmenjava znanja in izboljšana kakovost razvoja.

Kratki zaključki v eni vrstici

• Kadroviki delajo v IAC, vendar manj učinkovito.
• Okrepite tisto, kar deluje.
• Izmislite si svoje kompenzacijske mehanizme in prakse.

Vir: www.habr.com