Infrastruktura kao kod: kako prevazići probleme koristeći XP

Zdravo, Habr! Prethodno sam se žalio na život u Infrastrukturi kao paradigmu koda i nisam nudio ništa za rješavanje trenutne situacije. Danas se vraćam da vam kažem koji će vam pristupi i prakse pomoći da pobjegnete iz ponora očaja i usmjerite situaciju u pravom smjeru.

U prethodnom članku "Infrastruktura kao kod: prvo upoznavanje" Izneo sam svoje utiske o ovoj oblasti, pokušao da razmislim o trenutnoj situaciji u ovoj oblasti, pa čak i sugerisao da bi standardne prakse poznate svim programerima mogle da pomognu. Možda se čini da je bilo mnogo pritužbi na život, ali nije bilo prijedloga za izlaz iz trenutne situacije.

Ko smo, gdje smo i kakve probleme imamo

Trenutno smo u Sre onboarding timu koji se sastoji od šest programera i tri infrastrukturna inženjera. Svi pokušavamo napisati infrastrukturu kao kod (IaC). To radimo zato što u osnovi znamo kako pisati kod i imamo istoriju da smo bili "nadprosječni" programeri.

• Imamo niz prednosti: određenu pozadinu, poznavanje prakse, sposobnost pisanja koda, želju za učenjem novih stvari.
• A tu je i jedan opušteni dio, koji je također minus: nedostatak znanja o infrastrukturnom hardveru.

Tehnološki stog koji koristimo u našem IaC-u.

• Terraform za kreiranje resursa.
• Paker za sastavljanje slika. Ovo su Windows, CentOS 7 slike.
• Jsonnet da napravi moćnu izgradnju drone.io, kao i da generiše packer json i naše terraform module.
• Azure.
• Ansible prilikom pripreme slika.
• Python za pomoćne usluge i skripte za obezbjeđivanje.
• I sve to u VSCodeu s dodacima koje dijele članovi tima.

Zaključak iz mog zadnji članak je bilo ovako: Pokušao sam da (prije svega sebi) ulijem optimizam, htio sam reći da ćemo isprobati nama poznate pristupe i prakse kako bismo se izborili sa poteškoćama i složenostima koje postoje u ovoj oblasti.

Trenutno se borimo sa sljedećim problemima IaC-a:

• Nesavršenost alata i sredstava za razvoj koda.
• Sporo raspoređivanje. Infrastruktura je dio stvarnog svijeta i može biti spora.
• Nedostatak pristupa i praksi.
• Novi smo i ne znamo mnogo.

Ekstremno programiranje (XP) u pomoć

Svi programeri su upoznati sa ekstremnim programiranjem (XP) i praksama koje stoje iza toga. Mnogi od nas su radili s ovim pristupom, i bio je uspješan. Pa zašto ne iskoristiti principe i prakse koje su tamo postavljene za prevazilaženje infrastrukturnih izazova? Odlučili smo da uzmemo ovaj pristup i vidimo šta će se desiti.

Provjera primjenjivosti XP pristupa u vašoj industrijiEvo opisa okruženja za koje je XP dobro prikladan i kako se ono odnosi na nas:

1. Dinamički promjenjivi softverski zahtjevi. Bilo nam je jasno šta je krajnji cilj. Ali detalji mogu varirati. Mi sami odlučujemo gdje trebamo taksirati, tako da se zahtjevi periodično mijenjaju (uglavnom sami). Ako uzmemo SRE tim, koji sam radi automatizaciju, a sam ograničava zahtjeve i obim posla, onda se ova tačka dobro uklapa.

2. Rizici uzrokovani projektima na određeno vrijeme koji koriste novu tehnologiju. Možemo naići na rizike kada koristimo neke nama nepoznate stvari. I ovo je 100% naš slučaj. Cijeli naš projekt bio je korištenje tehnologija koje nismo u potpunosti poznavali. Generalno, ovo je stalni problem, jer... U sektoru infrastrukture stalno se pojavljuju mnoge nove tehnologije.

3,4. Mali prošireni razvojni tim koji se nalazi zajedno. Automatska tehnologija koju koristite omogućava jedinične i funkcionalne testove. Ove dvije tačke nam baš ne odgovaraju. Prvo, nismo uigrana ekipa, a drugo, ima nas devetoro, što se može smatrati velikim timom. Mada, prema nekim definicijama “velikog” tima, puno je 14+ ljudi.

Pogledajmo neke XP prakse i kako one utiču na brzinu i kvalitet povratnih informacija.

Princip XP povratne sprege

Po mom shvatanju, povratna informacija je odgovor na pitanje, da li radim pravu stvar, idemo li tamo? XP ima božansku šemu za ovo: vremensku povratnu petlju. Zanimljivo je da što smo niži, brže smo u mogućnosti da natjeramo OS da odgovori na potrebna pitanja.

Ovo je prilično interesantna tema za diskusiju, da je u našoj IT industriji moguće brzo dobiti OS. Zamislite koliko je bolno raditi projekat šest mjeseci i tek onda saznati da je greška na samom početku. To se dešava u projektovanju i u bilo kojoj konstrukciji složenih sistema.

U našem slučaju IaC-a, povratne informacije nam pomažu. Odmah ću napraviti malu prilagodbu gornjeg dijagrama: plan izdanja nema mjesečni ciklus, već se javlja nekoliko puta dnevno. Postoje neke prakse vezane za ovaj ciklus OS-a koje ćemo detaljnije razmotriti.

Važno: povratne informacije mogu biti rješenje za sve gore navedene probleme. U kombinaciji sa XP praksama, može vas izvući iz ponora očaja.

Kako se izvući iz ponora očaja: tri prakse

Testovi

Testovi se spominju dva puta u XP povratnoj sprezi. Nije samo tako. Oni su izuzetno važni za cjelokupnu tehniku ​​ekstremnog programiranja.

Pretpostavlja se da imate jedinične i testove prihvatanja. Neki vam daju povratnu informaciju za nekoliko minuta, drugi za nekoliko dana, tako da im je potrebno više vremena za pisanje i rjeđe se recenziraju.

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

Kako se ovaj okvir primjenjuje na nas u IaC projektu? Zapravo... nikako.

• Jediničnih testova, uprkos činjenici da bi ih trebalo biti puno, ne može biti previše. Ili testiraju nešto vrlo indirektno. Zapravo, možemo reći da ih uopće ne pišemo. Ali evo nekoliko aplikacija za takve testove koje smo uspjeli napraviti:
  1. Testiranje jsonnet koda. Ovo je, na primjer, naš cjevovod za montažu dronova, koji je prilično kompliciran. Jsonnet kod je dobro pokriven testovima.
     Koristimo ovo Okvir za testiranje jedinica za Jsonnet.
  2. Testovi za skripte koje se izvršavaju kada se resurs pokrene. Skripte su napisane u Pythonu, pa se na njima mogu pisati testovi.
• Potencijalno je moguće provjeriti konfiguraciju u testovima, ali mi to ne radimo. Također je moguće konfigurirati pravila konfiguracije provjere resursa putem tflint. Međutim, tamo su provjere jednostavno previše osnovne za terraform, ali mnoge testne skripte su napisane za AWS. A mi smo na Azureu, tako da ovo opet ne vrijedi.
• Testovi integracije komponenti: zavisi od toga kako ih klasifikujete i gde ih stavljate. Ali u osnovi rade.

  Ovako izgledaju integracijski testovi.

  
  
  Ovo je primjer kada se prave slike u Drone CI. Da biste došli do njih, morate čekati 30 minuta da se formira Packer slika, a zatim pričekati još 15 minuta da prođu. Ali oni postoje!

  Algoritam za provjeru slike

  1. Packer prvo mora u potpunosti pripremiti sliku.
  2. Pored testa nalazi se terraform sa lokalnim stanjem, koji koristimo za postavljanje ove slike.
  3. Prilikom rasklapanja koristi se mali modul koji leži u blizini kako bi se olakšao rad sa slikom.
  4. Kada se VM implementira sa slike, provjere mogu početi. Uglavnom, provjere se obavljaju automobilom. Provjerava kako su skripte radile pri pokretanju i kako rade demoni. Da bismo to učinili, preko ssh-a ili winrm-a ​​se prijavljujemo na novopodignutu mašinu i provjeravamo status konfiguracije ili da li su servisi pokrenuti.

• Slična je situacija i sa integracijskim testovima u modulima za terraform. Evo kratke tabele koja objašnjava karakteristike takvih testova.

  
  
  Povratna informacija o cevovodu je oko 40 minuta. Sve se dešava jako dugo. Može se koristiti za regresiju, ali za novi razvoj je općenito nerealno. Ako ste vrlo, vrlo spremni za ovo, pripremite skripte za pokretanje, onda to možete smanjiti na 10 minuta. Ali ovo još uvijek nisu jedinični testovi, koji rade 5 komada za 100 sekundi.

Odsustvo testova jedinica prilikom sastavljanja slika ili terraform modula potiče prebacivanje posla na odvojene servise koji se jednostavno mogu pokrenuti preko REST-a ili na Python skripte.

Na primjer, morali smo osigurati da se virtuelna mašina registruje u servisu kada se pokrene ScaleFT, a kada je virtuelna mašina uništena, sama se izbrisala.

Pošto imamo ScaleFT kao servis, primorani smo da radimo sa njim preko API-ja. Tu je bio napisan omot koji možete povući i reći: „Uđi ​​i izbriši to i to“. Pohranjuje sva potrebna podešavanja i pristupe.

Za ovo već možemo pisati normalne testove, pošto se ne razlikuje od običnog softvera: neka vrsta apihe se ismeva, povučeš je i vidiš šta će se desiti.

Rezultati testova: Jedinično testiranje, koje bi OS trebalo dati za minut, ne daje. A vrste testiranja koje se nalaze više u piramidi su efikasne, ali pokrivaju samo dio problema.

Programiranje u paru

Testovi su, naravno, dobri. Možete ih napisati puno, mogu biti različitih vrsta. Oni će raditi na svom nivou i dati nam povratne informacije. Ali problem sa lošim Unit testovima, koji daju najbrži OS, ostaje. U isto vrijeme, i dalje želim brzi OS sa kojim je lako i ugodno raditi. O kvaliteti dobivenog rješenja da i ne govorimo. Na sreću, postoje tehnike koje mogu pružiti još bržu povratnu informaciju od jediničnih testova. Ovo je programiranje u paru.

Kada pišete kod, želite da dobijete povratne informacije o njegovom kvalitetu što je brže moguće. Da, možete sve napisati u granu funkcija (kako ne biste ništa pokvarili ni za koga), napraviti pull request u Githubu, dodijeliti ga nekome čije mišljenje ima težinu i čekati odgovor.

Ali možete čekati dugo. Svi su ljudi zauzeti, a odgovor, čak i ako ga ima, možda neće biti najvišeg kvaliteta. Pretpostavimo da je odgovor stigao odmah, recenzent je odmah shvatio cijelu ideju, ali odgovor ipak dolazi kasno, nakon činjenice. Voleo bih da je ranije. To je ono čemu je programiranje u paru usmjereno – odmah, u trenutku pisanja.

Ispod su stilovi programiranja u paru i njihova primjenjivost u radu na IaC-u:

1. Classic, Experienced+Experienced, pomicanje po tajmeru. Dvije uloge – vozač i navigator. Dvoje ljudi. Oni rade na istom kodu i mijenjaju uloge nakon određenog unaprijed određenog vremenskog perioda.

Razmotrimo kompatibilnost naših problema sa stilom:

• Problem: nesavršenost alata i alata za razvoj koda.
  Negativan uticaj: potrebno je duže da se razvije, usporavamo, tempo/ritam rada se gubi.
  Kako se borimo: koristimo različite alate, zajednički IDE i učimo prečice.
• Problem: Spora implementacija.
  Negativan uticaj: povećava vreme potrebno za kreiranje radnog dela koda. Dosadno nam je dok čekamo, ruke nam se pružaju da uradimo nešto drugo dok čekamo.
  Kako se borimo: nismo to savladali.
• Problem: nedostatak pristupa i praksi.
  Negativan uticaj: nema znanja kako to učiniti dobro, a kako loše. Produžuje prijem povratnih informacija.
  Kako se borimo: međusobna razmjena mišljenja i prakse u radu u paru gotovo rješava problem.

Glavni problem korištenja ovog stila u IaC-u je neujednačen tempo rada. U tradicionalnom razvoju softvera, imate vrlo ujednačen pokret. Možete provesti pet minuta i napisati N. Potrošite 10 minuta i napišite 2N, 15 minuta - 3N. Ovdje možete provesti pet minuta i napisati N, a onda potrošiti još 30 minuta i napisati deseti dio N. Ovdje ne znate ništa, zaglavili ste, glupi. Istraga oduzima vrijeme i odvlači pažnju od samog programiranja.

Zaključak: u svom čistom obliku nije prikladan za nas.

2. Ping-pong. Ovaj pristup uključuje jednu osobu koja piše test, a drugu radi implementaciju za njega. Uzimajući u obzir činjenicu da je sa jediničnim testovima sve komplikovano i da morate napisati integracijski test za koji je potrebno mnogo vremena za programiranje, sva lakoća ping-ponga nestaje.

Mogu reći da smo pokušali da odvojimo odgovornosti za dizajniranje test skripte i implementaciju koda za nju. Jedan učesnik je osmislio scenario, u ovom dijelu posla on je bio odgovoran, on je imao posljednju riječ. A drugi je bio odgovoran za implementaciju. Dobro je ispalo. Kvalitet skripte ovim pristupom se povećava.

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

3.Strong Style. Teška praksa. Ideja je da jedan učesnik postane navigator direktive, a drugi preuzme ulogu pokretača izvršenja. U ovom slučaju, pravo na donošenje odluka ima isključivo navigator. Vozač samo štampa i može uticati na ono što se dešava jednom rečju. Uloge se dugo ne mijenjaju.

Dobro za učenje, ali zahtijeva jake meke vještine. Tu smo posustali. Tehnika je bila teška. I ne radi se čak ni o infrastrukturi.

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

4. Mobing, rojenje i svi poznati ali nenavedeni stilovi Mi to ne smatramo, jer Nismo probali i nemoguće je o tome govoriti u kontekstu našeg rada.

Opći rezultati korištenja programiranja u paru:

• Imamo neujednačen tempo rada, što je zbunjujuće.
• Naišli smo na nedovoljno dobre soft skills. I predmetna oblast ne pomaže u prevazilaženju ovih naših nedostataka.
• Dugi testovi i problemi s alatima otežavaju upareni razvoj.

5. Uprkos tome, bilo je uspjeha. Osmislili smo sopstvenu metodu „Konvergencija – Divergencija“. Ukratko ću opisati kako to funkcionira.

Imamo stalne partnere na nekoliko dana (manje od nedelju dana). Zajedno radimo jedan zadatak. Neko vrijeme sjedimo zajedno: jedan piše, drugi sjedi i gleda tim za podršku. Onda se raziđemo neko vrijeme, svako radi neke samostalne stvari, onda se opet okupimo, sinhronizujemo se vrlo brzo, uradimo nešto zajedno i onda se opet raziđemo.

Planiranje i komunikacija

Posljednji blok praksi kroz koji se rješavaju OS problemi je organizacija rada sa samim zadacima. Ovo također uključuje razmjenu iskustava koja je izvan rada u paru. Pogledajmo tri prakse:

1. Ciljevi kroz stablo ciljeva. Organizirali smo cjelokupno upravljanje projektom kroz drvo koje ide beskonačno u budućnost. Tehnički, praćenje se vrši u Miru. Postoji jedan zadatak - to je srednji cilj. Od toga idu ili manji ciljevi ili grupe zadataka. Sami zadaci dolaze od njih. Svi zadaci se kreiraju i održavaju na ovoj ploči.

Ova šema također pruža povratne informacije, koje se dešavaju jednom dnevno kada se sinhronizujemo na mitinzima. Imati zajednički plan pred svima, ali strukturiran i potpuno otvoren, omogućava svima da budu svjesni šta se dešava i koliko smo napredovali.

Prednosti vizuelne vizije zadataka:

• Uzročnost. Svaki zadatak vodi do nekog globalnog cilja. Zadaci su grupirani u manje ciljeve. Sama oblast infrastrukture je prilično tehnička. Nije uvijek odmah jasno kakav specifični uticaj, na primjer, pisanje runbooka o prelasku na drugi nginx ima na poslovanje. Kada je ciljna karta u blizini, postaje jasnije.
  
  Uzročnost je važno svojstvo problema. On direktno odgovara na pitanje: „Da li radim pravu stvar?“
• Paralelizam. Ima nas devetoro i jednostavno je fizički nemoguće baciti sve na jedan zadatak. Ni zadaci iz jedne oblasti možda neće uvijek biti dovoljni. Primorani smo da paraleliziramo rad između malih radnih grupa. Istovremeno, grupe sjede na svom zadatku neko vrijeme, mogu biti pojačane nekim drugim. Ponekad ljudi ispadnu iz ove radne grupe. Neko ide na odmor, neko pravi izveštaj za DevOps conf, neko piše članak na Habru. Znati koji ciljevi i zadaci se mogu raditi paralelno postaje veoma važno.

2. Zamjena prezentatora jutarnjih sastanaka. Kod stand-up-a imamo ovaj problem - ljudi rade mnoge zadatke paralelno. Ponekad su zadaci labavo povezani i nema razumijevanja ko šta radi. I mišljenje drugog člana tima je veoma važno. Ovo su dodatne informacije koje mogu promijeniti tok rješavanja problema. Naravno, obično je neko sa vama, ali savjeti i savjeti su uvijek korisni.

Da bismo poboljšali ovu situaciju, koristili smo tehniku ​​“Promjena vodećeg stand-up-a”. Sada se rotiraju prema određenoj listi i to ima svoj učinak. Kada dođete na red, primorani ste da zaronite i shvatite šta se dešava kako biste održali dobar Scrum sastanak.

3. Interni demo. Pomoć u rješavanju problema iz programiranja u paru, vizualizacija na drvetu problema i pomoć na scrum sastancima ujutro su dobri, ali nisu idealni. Kao par, ograničeni ste samo svojim znanjem. Stablo zadataka pomaže da se globalno shvati ko šta radi. A voditelj i kolege na jutarnjem sastanku neće ulaziti duboko u vaše probleme. Sigurno bi im nešto moglo nedostajati.

Rješenje je pronađeno u demonstriranju obavljenog posla jedni drugima, a zatim u raspravi o tome. Sastajemo se jednom sedmično na sat vremena i pokazujemo detalje o rješenjima zadataka koje smo radili u protekloj sedmici.

Tokom demonstracije potrebno je otkriti detalje zadatka i obavezno demonstrirati njegovo djelovanje.

Izvještaj se može provesti korištenjem kontrolne liste.1. Uđite u kontekst. Odakle zadatak, zašto je uopšte bio potreban?

2. Kako je problem ranije bio riješen? Na primjer, bilo je potrebno masivno klikanje mišem ili je bilo nemoguće učiniti bilo šta.

3. Kako ga poboljšavamo. Na primjer: "Vidi, sada postoji scriptosik, evo readme."

4. Pokažite kako to funkcionira. Preporučljivo je direktno implementirati neki korisnički scenario. Želim X, radim Y, vidim Y (ili Z). Na primjer, implementiram NGINX, zapušim url i dobijem 200 OK. Ako je radnja duga, pripremite je unaprijed kako biste je mogli prikazati kasnije. Preporučljivo je da ga ne lomite previše sat vremena prije demo, ako je lomljiv.

5. Objasnite koliko je uspješno riješen problem, koje su poteškoće ostale, šta nije završeno, koja su poboljšanja moguća u budućnosti. Na primjer, sada CLI, onda će biti potpuna automatizacija u CI.

Preporučljivo je da svaki govornik zadrži 5-10 minuta. Ako je vaš govor očigledno važan i da će trajati duže, koordinirajte to unaprijed na kanalu za preuzimanje.

Nakon dijela licem u lice uvijek se vodi rasprava u temi. Ovdje se pojavljuje povratna informacija koja nam je potrebna o našim zadacima.

Kao rezultat toga, provodi se anketa kako bi se utvrdila korisnost onoga što se dešava. Ovo je povratna informacija o suštini govora i važnosti zadatka.

Dugi zaključci i šta dalje

Možda se čini da je ton članka pomalo pesimističan. Ovo je pogrešno. Dva niža nivoa povratnih informacija, odnosno testovi i programiranje u paru, rade. Nije tako savršeno kao u tradicionalnom razvoju, ali ima pozitivan učinak.

Testovi, u svom trenutnom obliku, pružaju samo djelomičnu pokrivenost koda. Mnoge konfiguracijske funkcije ostaju neprovjerene. Njihov uticaj na stvarni rad pri pisanju koda je mali. Međutim, postoji učinak od integracijskih testova i oni vam omogućavaju da neustrašivo provodite refaktoring. Ovo je veliko postignuće. Također, s pomjeranjem fokusa na razvoj u jezicima visokog nivoa (imamo python, go), problem nestaje. I ne treba vam puno provjera za "ljepak"; dovoljna je opća provjera integracije.

Rad u paru više zavisi od konkretnih ljudi. Tu je faktor zadataka i naše soft skills. Kod nekih ljudi to ide jako dobro, kod drugih lošije. Od ovoga svakako ima koristi. Jasno je da čak i ako se pravila rada u paru ne poštuju dovoljno, sama činjenica zajedničkog izvođenja zadataka pozitivno utiče na kvalitetu rezultata. Lično, rad u paru mi je lakši i ugodniji.

Načini višeg nivoa uticaja na OS - precizno planiranje i rad sa zadacima proizvode efekte: kvalitetnu razmenu znanja i bolji kvalitet razvoja.

Kratki zaključci u jednom redu

• HR praktičari rade u IaC-u, ali sa manjom efikasnošću.
• Ojačajte ono što radi.
• Osmislite svoje kompenzacijske mehanizme i prakse.

izvor: www.habr.com