🥇Infrastruktura kao kod: kako riješiti probleme uz pomoć XP

Pozdrav, Habr! Prije sam se žalio na život unutar paradigme Infrastructure as Code i nisam nudio rješenja za postojeću situaciju. Danas se vraćam kako bih pričao o pristupima i praksama koje će pomoći da se izvučete iz ponora očaja i preokrenete situaciju u pravom smjeru.

U prethodnom članku «Infrastructure as Code: prvo upoznavanje» podijelio sam svoje utiske o ovom području, pokušavao razmišljati o trenutnoj situaciji u ovoj oblasti i čak pretpostavio da standardne, svima poznate prakse programera mogu pomoći. Moglo se činiti da je bilo mnogo žalbi na život, ali nije bilo prijedloga za izlazak iz postojeće situacije.

Tko smo, gdje smo i koji su naši problemi

Trenutno se nalazimo u SRE Onboarding timu, koji se sastoji od šest programera i tri inženjera infrastrukture. Svi pokušavamo pisati Infrastructure as Code (IaC). Radimo to jer u suštini znamo pisati kod i u anamnezi smo programeri „iznad prosjeka”.

Imamo set prednosti: određeno iskustvo, poznavanje praksi, sposobnost pisanja koda i želju za učenjem novog.
A imamo i slabiju stranu, koju možete smatrati manom: nedostatak znanja o osnovama infrastrukture.

Tehnološki skupovi koje koristimo u našem IaC.

Terraform za kreiranje resursa.
Packer za izradu slika. To su Windows i CentOS 7 slike.
Jsonnet za moćno graditi u drone.io, a također za generiranje packer json i naših Terraform modula.
Azure.
Ansible prilikom pripreme slika.
Python za pomoćne servise, kao i za provisioning skripte.
I sve to u VSCode s dodacima koje dijelimo među članovima tima.

Zaključak mog prošlog članka bio je sljedeći: pokušavao sam usaditi (prije svega u sebe) optimizam, htio sam reći da ćemo isprobati pristupe i prakse koje poznajemo kako bismo se borili s teškoćama i izazovima koji postoje u ovoj oblasti.

Trenutačno se suočavamo s takvim problemima u IaC:

Nedostatak savršenstva alata, razvojnih sredstava.
Sporo implementiranje. Infrastruktura je dio stvarnog svijeta, a on može biti spor.
Nedostatak pristupa i praksi.
Mi smo novi i ne znamo mnogo.

Ekstremno programiranje (XP) dolazi u pomoć.

Svima developerima dobro je poznato ekstremno programiranje (XP) i prakse koje su iza njega. Mnogi od nas su radili prema ovom pristupu, a on se pokazao uspješnim. Pa zašto ne bismo iskoristili principe i prakse koje su tamo postavljene da bismo se nosili s izazovima infrastrukture? Odlučili smo primijeniti ovaj pristup i vidjeti što će iz njega proizaći.

Provjera primjenjivosti pristupa XP-u u vašem područjuDonosim opis okruženja za koje je XP dobro prilagođen i kako se to odnosi na nas:

1. Dinamički se mijenjajući softverski zahtjevi. Bilo nam je jasno koja je konačna svrha. No, u detaljima se može varirati. Mi sami odlučujemo kamo trebamo skrenuti, stoga se zahtjevi povremeno mijenjaju (najčešće od strane nas samih). Ako uzmemo tim SRE-a koji samo radi automatizaciju i sam ograničava zahtjeve i opseg rada, onda se ova stavka dobro uklapa.

2. Rizici nastali fiksnim vremenom projekata koristeći nove tehnologije. Mogu se pojaviti rizici kada koristimo nešto što nam nije poznato. I to je 100% naš slučaj. Ceo naš projekt temelji se na tehnologijama s kojima nismo u potpunosti bili upoznati. Uistinu, to je stalni problem, jer u području infrastrukture neprekidno se pojavljuje mnoštvo novih tehnologija.

3,4. Mala, ko-locirana proširena razvojna ekipa. Tehnologija koju koristite omogućuje automatske jedinicne i funkcionalne testove. Ove dvije stavke potpuno nam ne odgovaraju. Prvo, nismo ko-locirani tim, a drugo, nas je devet, što se može smatrati velikim timom. Iako prema nekim definicijama „velikog“ tima, mnogo je 14+ osoba.

Razmotrit ćemo neke prakse iz XP-a i kako one utječu na brzinu i kvalitetu povratnih informacija.

Princip ciklusa povratne informacije u XP-u

U mom razumijevanju povratna informacija je odgovor na pitanje, radim li ispravno, idemo li u pravom smjeru? U XP-u postoji božanska shema u tom pogledu: vremenski ciklus povratne informacije. Zanimljivost leži u tome što što smo niže, to brže možemo dobiti OS kako bismo odgovorili na potrebna pitanja.

To je prilično zanimljiva tema za raspravu, da u našoj IT industriji možemo brzo dobiti OS. Zamislite koliko je teško raditi na nekom projektu šest mjeseci i tek tada saznati da je na samom početku došlo do greške. To se događa i u projektiranju i u bilo kojem konstrukciji složenih sustava.

U našem slučaju IaC nam pomaže povratna informacija. Odmah ću unijeti malu ispravku u gornju shemu: plan izlaska nema mjesečni ciklus, već se odvija nekoliko puta dnevno. Tim ciklusom OS su vezane neke prakse koje ćemo detaljnije razmotriti.

Važno: povratna informacija može postati rješenje za sve gore navedene probleme. U kombinaciji s XP praksama, može nas izvući iz ponora očaja.

Kako se izvuci iz ponora očaja: tri prakse

Testovi

Testovi se spominju dvaput u ciklusu povratne informacije XP. To nije slučajno. Oni su iznimno važni za cijelu tehniku ekstremnog programiranja.

Pretpostavlja se da imaš Unit i Acceptance testove. Jedni ti daju povratne informacije za nekoliko minuta, a drugi za nekoliko dana, pa ih duže pišemo, dok se rjeđe provode.

Postoji klasična piramida testiranja koja pokazuje da bi trebalo biti više određenih testova.

Kako je ova shema primjenjiva na naš projekt IaC? U stvari... nikako.

Iako bi trebalo biti jako puno unit testova, ne može ih biti previše. Ili testiraju nešto vrlo indirektno. U suštini, možemo reći da ih uopće ne pišemo. No, postoje neka primjenjiva područja gdje smo ih ipak uspjeli napraviti:
1. Testiranje koda na jsonnet. To je, na primjer, naš build pipeline u droneu, koji je prilično složen. Kod na jsonnetu dobro je prekriven testovima.
  Koristimo ovaj Unit testing framework for Jsonnet.
2. Testovi za skripte koje se izvršavaju prilikom pokretanja resursa. Skripte su na Pythonu, a samim time možemo pisati i testove na njima.
Potencijalno je moguća provjera konfiguracije u testovima, ali mi to ne radimo. Također postoji mogućnost postavljanja provjere pravila konfiguriranja resursa kroz tflint. Međutim, za Terraform su tamo pregledi previše osnovni, ali mnogo provjera napisanih za AWS. A mi smo na Azureu, tako da to opet ne odgovara.
Komponentni integracijski testovi: ovdje ovisi kako ih klasificiraš i gdje ih smještaš. No oni u suštini funkcionišu.
Ovako izgledaju integracijski testovi.

To je primjer prilikom izrade slika u Drone CI. Da bi do njih došli, potrebno je čekati 30 minuta dok se Packer slika ne izgradi, a zatim još 15 minuta dok prođu. Ali postoje!
Algoritam provjere slika
1. Prvo Packer mora potpuno pripremiti sliku.
2. Pored testa postoji Terraform s lokalnim stanjem kojim raspodjeljujemo ovu sliku.
3. Prilikom raspodjele koristi se mali modul koji se nalazi blizu kako bi rad sa slikom bio jednostavniji.
4. Kada je iz slike raspoređena VM, može se početi s provjerama. Uglavnom, provjere se vrše na stroju. Provjerava se kako su skripte radile prilikom pokretanja, kako rade demoni. Za to preko ssh ili winrm ulazimo na upravo podignutu mašinu i provjeravamo stanje konfiguracije ili da li su servisi podigli.
Slična situacija je s integracijskim testovima i u modulima za Terraform. Evo kratke tablice koja objašnjava osobitosti takvih testova.

Povratne informacije na pipelineu traje oko 40 minuta. Sve traje jako dugo. Može se koristiti za regresiju, ali za novi razvoj to je jednostavno nemoguće. Ako se zaista temeljito pripremite, pripremite running, skripte, tada se to može smanjiti na 10 minuta. No, to još uvijek nisu Unit testovi koji traju 5 sekundi za 100 komada.

Nedostatak Unit testova prilikom izrade slika ili modula Terraforma tjera nas da prebacimo rad na odvojene servise koje se jednostavno može dohvatiti putem REST-a, ili na Python skripte.

Na primjer, morali smo napraviti da se prilikom pokretanja virtualne mašine registrira u servisu ScaleFT, a prilikom uništavanja virtualnog stroja da se ukloni.

Budući da je ScaleFT naš servis, prisiljeni smo raditi s njim preko API-ja. Tamo je napisana omotač koja se može dohvatiti i reći: 'Uđi i ukloni ovo, ono'. Ona čuva sve potrebne postavke i pristupe.

Na to već možemo pisati normalne testove, budući da se nimalo ne razlikuje od običnog softvera: mockaš neki API, ti ga dohvaćaš, i gledamo što se događa.

Ishodi testova: Unit testiranje, koje bi trebalo dati OS-u u minuti, ne daje to. A viši tipovi testiranja u piramidi daju učinak, ali pokrivaju samo dio problema.

Parno programiranje

Testovi su, naravno, dobri. Mogu se pisati u velikim količinama i mogu imati različite oblike. Radit će na svojim razinama i pružati nam povratne informacije. No, problem s lošim Unit testovima, koji donose najbrži OS, ostaje. I dalje želimo brzi OS, s njim je lako i ugodno raditi. Ne govorim o kvaliteti rješenja koje dobivamo. Na sreću, postoje tehnike koje omogućuju brži feedback od modula. To je parno programiranje.

Kada pišemo kod, želimo što brže dobiti povratne informacije o njegovoj kvaliteti. Da, možemo sve napisati u feature grani (da ne bismo nikome uništili nešto), napraviti pull request na GitHubu, odrediti nekoga čije mišljenje ima težinu i čekati odgovor.

Ali čekanje može potrajati. Svi su ljudi zauzeti, a odgovor, čak i ako stigne, možda neće biti od najviše kvalitete. Pretpostavimo da je odgovor stigao odmah, recenzent je odmah shvatio cijeli koncept, ali odgovor i dalje dolazi s odgodom, postfaktom. A želimo ranije. Zato je parno programiranje usmjereno na to – da odmah, u trenutku pisanja.

Dalje predstavljam stilove parnog programiranja i njihovu primjenu u radu na IaC:

1. Klasično, Iskusan + Iskusan, promjena po tajmeru. Dvije uloge – vozač i navigator. Dvojica ljudi. Rade na istom kodu i mijenjaju uloge nakon unaprijed određenog vremenskog razdoblja.

Pogledajmo usklađenost naših problema sa stilom:

Problem: nesavršenstvo alata, sredstava za razvoj koda.
Negativan utjecaj: duže vrijeme razvoja, usporavamo se, gubimo tempo/ritam rada.
Kako se borimo: primjenjujemo različite alate, zajednički IDE i učimo prečace.
Problem: sporo implementiranje.
Negativan utjecaj: produžava vrijeme potrebno za stvaranje radnog dijela koda. Dosadno nam je dok čekamo, ruke su nam željne baviti se nečim drugim dok čekamo.
Kako se borimo: nismo pobijedili.
Problem: nedostatak pristupa i praksi.
Negativan utjecaj: nema znanja o tome kako raditi dobro, a kako loše. Produžava dobivanje povratnih informacija.
Kako se borimo: međusobna razmjena mišljenja i praksi u parnom radu gotovo rješava problem.

Glavna problematika primjene ovog stila u IaC je neravnomjeran tempo rada. U tradicionalnom razvoju softvera, napredak je prilično ujednačen. Možeš potrošiti pet minuta i napisati N. Potroši deset minuta i napiši 2N, petnaest minuta – 3N. Ovdje, međutim, možeš potrošiti pet minuta i napisati N, a zatim potrošiti još 30 minuta i napisati jednu desetinu od N. Ovdje ništa ne znaš, dođeš do zastoja, zaglavljen si. Rješavanje problema oduzima vrijeme i odvlači te od samog programiranja.

Zaključak: u čistom obliku nam ne odgovara.

2. Ping-pong. Ovaj pristup podrazumijeva da jedan sudionik piše test, a drugi radi njegovu implementaciju. S obzirom na to da je s Unit testovima sve komplicirano, i trebaš napisati dugotrajan integracijski test, cijela lakoća ping-ponga nestaje.

Mogu reći da smo pokušali podijeliti odgovornosti po pitanju dizajniranja scenarija testa i implementacije koda. Jedan sudionik smišljao je scenarij, u ovom dijelu posla bio je odgovoran i imao je zadnju riječ. A drugi je bio odgovoran za implementaciju. To se ispostavilo kao dobro. Kvaliteta scenarija prema ovom pristupu se povećava.

Zaključak: nažalost, tempo rada ne dopušta korištenje ping-ponga kao prakse parnog programiranja u IaC.

3. Strong Style. Kompleksna praksa. Ideja je da jedan sudionik postane direktivan navigator, a drugi preuzima ulogu izvršnog vozača. Pri tom su odluke isključivo na navigatoru. Vozač samo kuca i može riječima utjecati na tijek događaja. Uloge se ne mijenjaju dugo vremena.

Dobar je za obuku, ali zahtijeva snažne softverske vještine. Tu smo se i zaglavili. Tehnika je bila teška. I tu se ne radi čak ni o infrastrukturi.

Zaključak: potencijalno se može primijeniti, ne odustajemo od pokušaja.

4. Mobbing, swarming i svi poznati, ali ovdje ne navedeni stilovi ne razmatramo, jer nismo isprobali i ne možemo o tome govoriti u kontekstu našeg rada.

Opći rezultati o korištenju parnog programiranja:

Imamo neujednačen tempo rada, koji ometa.

Uočili smo nedostatak dobrih softverskih vještina. A predmetna oblast ne pomaže u prevladavanju tih naših nedostataka.

Dugi testovi, problemi s alatima čine parni razvoj zamrznutim.

5. Ipak, bilo je i uspjeha. Izmislili smo vlastitu metodu 'Sjedinjavanje – razdvajanje'. Kratko ću opisati kako ona funkcionira.

Imamo stalne partnere na nekoliko dana (manje od tjedan dana). Radimo na jednom zadatku zajedno. Neko vrijeme sjedimo zajedno: jedan piše, drugi sjedi i promatra, kao tim podrške. Nakon toga se razdvajamo na neko vrijeme, svatko radi nešto neovisno, a onda se opet okupljamo, vrlo brzo se sinkroniziramo, radimo nešto zajedno i opet se razdvajamo.

Planiranje i komunikacija

Posljednji blok praksi, kroz koje se rješavaju problemi operativnog sustava, odnosi se na organizaciju rada s samim zadacima. Ovo također uključuje razmjenu iskustava koja se odvijaju izvan uparene suradnje. Razmotrit ćemo tri prakse:

1. Zadatci prema stablu ciljeva. Opće upravljanje projektom organizirali smo kroz stablo koje beskonačno ide u budućnost. Tehnički se vođenje obavlja u Miro-u. Postoji jedan zadatak – on je međucilj. Od njega se razvijaju ili manje ciljeve ili grupe zadataka. Od njih onda nastaju sami zadaci. Svi zadaci se stvaraju i vode na ovoj ploči.

Ovaj sustav također pruža povratne informacije, koje se javljaju jednom dnevno, kada se sinkroniziramo na sastancima. Postojanje zajedničkog plana, koji je strukturiran i potpuno otvoren, omogućuje svakome da bude u tijeku s onim što se događa i koliko smo napredovali.

Prednosti vizualnog prikaza zadataka:

Uzročnost. Svaki zadatak vodi ka nekom globalnom cilju. Zadatci su grupirani prema manjim ciljevima. Dominantna infrastruktura sama po sebi prilično je tehnička. Nije uvijek odmah jasno kakav konkretan utjecaj na poslovanje ima, na primjer, pisanje priručnika za migraciju na drugi nginx. Postojanje ciljne kartice pored ovoga čini to jasnijim.

Uzročnost – važno svojstvo zadataka. Ona izravno odgovara na pitanje: 'Radim li točno to?'
Paralelnost. Nas je devetoro, i fizički nije moguće napadati jednu zadatak sa svih strana. Zadatka iz iste oblasti također ne mora biti dovoljno. Prisiljeni smo paralelizirati rad između malih radnih grupa. U tom procesu grupe određeno vrijeme rade na svom zadatku, a mogu ih ojačati dodatnim članovima. Od ove radne grupe ponekad se odvajaju ljudi. Neki idu na odmor, neki pripremaju izlaganje za konferenciju DevOps conf, neki pišu članak za Habr. Važno je znati koje se ciljeve i zadatke može raditi paralelno.

2. Smjene voditelja jutarnjih sastanaka. Na standupovima se javila ovakva problema - puno zadataka ljudu rade paralelno. Ponekad su zadaci slabo povezani i nema razumijevanja tko što radi. A mišljenje još jednog člana tima je vrlo važno. To je dodatna informacija koja može promijeniti tok rješavanja zadatka. Naravno, obično si u paru s nekim, ali savjeti i konzultacije nikad ne škode.

Kako bismo poboljšali ovu situaciju, primijenili smo tehniku "Rotacija voditelja standupa". Sada se rotiraju po unaprijed dogovorenom popisu, i to ima svoj učinak. Kada dođeš do svoje smjene, prisiljen si se uroniti i razumjeti što se događa, kako bi dobro vodio scrum sastanak.

3. Interna demonstracija. Pomoć u rješavanju zadataka kroz parno programiranje, vizualizacija na stablu zadataka i pomoć na scrum sastancima ujutro - to je dobro, ali ne savršeno. U paru si ograničen samo svojim znanjem. Stablo zadataka pomaže globalno razumjeti tko i što radi. A voditelj i kolege na jutarnjem sastanku ne ulaze duboko u tvoje probleme. Zasigurno mogu nešto i propustiti.

Rješenje je pronađeno u međusobnom demonstriranju urađenog i naknadnoj raspravi o tome. Okupljamo se jednom tjedno na sat vremena i pokazujemo detalje rješenja za zadatke koje smo obavili tijekom proteklog tjedna.

Tijekom demonstracije potrebno je otkriti detalje zadatka i obavezno pokazati njegov rad.

Izlaganje se može voditi prema kontrolnom popisu.1. Uvedite u kontekst. Odakle zadatak dolazi, zašto je to uopće bilo potrebno?

2. Kako je zadatak rješavan do sada? Na primjer, bilo je potrebno masovno klikanje mišem, ili je bilo potpuno nemoguće nešto učiniti.

3. Kako to poboljšavamo. Na primjer: "Pogledajte, sada imamo skripticu, evo readme-a."

4. Prikažite kako to funkcionira. Preporučljivo je provesti neki scenarij korisnika. Želim X, radim Y, vidim Z (ili Y). Na primjer, deployam NGINX, provjeravam url, dobijem 200 OK. Ako je radnja dugotrajna, pripremite u naprijed, kako biste to mogli pokazati. Preporučljivo je da sat vremena prije demoa ne proradite ako je krhko.

5. Objasnite koliko je dobro riješeno pitanje, koje su preostale poteškoće, što nije završeno, koja poboljšanja su moguća u budućnosti. Na primjer, sada je cli, a kasnije će biti potpuna automatizacija u CI.

Preporučljivo je da svaki govornik stane u 5-10 minuta. Ako je vaš govor unaprijed važan i traje duže, unaprijed se dogovorite o tome u kanalu sre-takeover.

Nakon uživo dijela obavezno ide rasprava u threadu. Tu se pojavljuje potrebna povratna informacija o svojim zadacima.

Na kraju se provodi anketa za utvrđivanje korisnosti onoga što se događa. To je već povratna informacija o samom govoru i važnosti zadatka.

Dugi zaključci i što dalje

Može se činiti da je ton članka pomalo pesimističan. Nije tako. Dva niska nivoa dobivanja povratne informacije, a to su testovi i parno programiranje, funkcioniraju. Ne tako savršeno kao u tradicionalnom razvoju, ali postoji pozitivan učinak od toga.

Testovi, u svom trenutnom obliku, osiguravaju samo djelomično pokriće koda. Mnoge funkcije konfiguracije ostaju netestirane. Njihov utjecaj na neposredan rad prilikom pisanja koda je nizak. Međutim, učinak integracijskih testova postoji, i upravo oni omogućuju nesmetano provođenje refaktoringa. To je veliki uspjeh. Također, s prebacivanjem fokusa na razvoj na višim razinama jezika (kod nas python, go) problem se gubi. A za 'ljepilo' je potrebna puno provjera, to je dovoljno opće integracije.

Rad u paru više zavisi od konkretnih ljudi. Postoji faktor zadatka i naše softverske vještine. S nekima ide jako dobro, s nekima lošije. Korist od toga sigurno postoji. Jasno je da čak i pri nedovoljnog poštivanja pravila rada u paru, sam čin zajedničkog obavljanja zadataka pozitivno utječe na kvalitetu rezultata. Osobno mi je rad u paru lakši i ugodniji.

Viši načini utjecaja na OS – planiranje i rad sa zadacima definitivno donose efekte: kvalitetnu razmjenu znanja i poboljšanje kvalitete razvoja.