Infrastruktura kao kod: kako prevladati probleme koristeći XP

Pozdrav, Habr! Prije sam se žalio na život u Infrastrukturi kao paradigmi koda i nisam nudio ništa za rješenje trenutne situacije. Danas sam se vratio 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 šifra: prvo upoznavanje" Podijelio sam svoje dojmove o ovom području, pokušao razmisliti o trenutnoj situaciji u ovom području i čak sugerirao da bi standardne prakse poznate svim programerima mogle pomoći. Moglo bi se činiti da je bilo puno pritužbi na život, ali nije bilo prijedloga za izlaz iz trenutne situacije.

Tko smo, gdje smo i kakvih problema imamo

Trenutno smo u Sre Onboarding Teamu koji se sastoji od šest programera i tri infrastrukturna inženjera. Svi pokušavamo napisati infrastrukturu kao kod (IaC). To radimo jer u osnovi znamo kako napisati kod i imamo povijest "iznadprosječnih" programera.

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

Tehnološki skup koji koristimo u našem IAC-u.

• Terraform za stvaranje resursa.
• Paker za sastavljanje slika. Ovo su Windows, CentOS 7 slike.
• Jsonnet za izradu snažne nadogradnje u drone.io, kao i za generiranje pakera json i naših terraform modula.
• Azurno.
• Anable prilikom pripreme slika.
• Python za pomoćne usluge i skripte za pružanje usluga.
• I sve to u VSCodeu s dodacima koji dijele članovi tima.

Zaključak iz mog posljednji članak bila je ovakva: pokušao sam uliti (prije svega u sebe) optimizam, htio sam reći da ćemo isprobati nama poznate pristupe i prakse kako bismo se nosili s poteškoćama i kompleksnostima koje postoje na ovom području.

Trenutno se borimo sa sljedećim IaC problemima:

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

Ekstremno programiranje (XP) u pomoć

Svi programeri upoznati su s Extreme Programming (XP) i praksama koje stoje iza njega. Mnogi od nas radili su s ovim pristupom i bio je uspješan. Dakle, zašto ne upotrijebiti tamo postavljena načela i prakse za prevladavanje infrastrukturnih izazova? Odlučili smo primijeniti ovaj pristup i vidjeti što će se dogoditi.

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

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

2. Rizici uzrokovani projektima s fiksnim vremenom koji koriste novu tehnologiju. Možemo se suočiti s rizicima kada koristimo neke stvari koje su nam nepoznate. I ovo je 100% naš slučaj. Cijeli naš projekt bio je korištenje tehnologija s kojima nismo bili u potpunosti upoznati. Općenito, to je stalni problem, jer... Mnogo je novih tehnologija koje se stalno pojavljuju u sektoru infrastrukture.

3,4. Mali prošireni razvojni tim koji se nalazi zajedno. Automatizirana tehnologija koju koristite omogućuje jedinične i funkcionalne testove. Ove nam dvije točke baš i ne odgovaraju. Prvo, nismo uigran tim, a drugo, ima nas devet, što se može smatrati velikom ekipom. Iako, prema nekim definicijama “velikog” tima puno je 14+ ljudi.

Pogledajmo neke XP prakse i kako one utječu na brzinu i kvalitetu povratnih informacija.

XP princip povratne veze

Po mom razumijevanju, povratna informacija je odgovor na pitanje, radim li pravu stvar, idemo li tamo? XP za to ima božansku shemu: vremensku povratnu petlju. Zanimljivo je da što smo niži, to brže možemo natjerati OS da odgovori na potrebna pitanja.

Ovo je prilično zanimljiva tema za raspravu, da je u našoj IT industriji moguće brzo dobiti OS. Zamislite koliko je bolno raditi projekt šest mjeseci i tek onda saznati da je došlo do greške na samom početku. To se događa u dizajnu iu svakoj konstrukciji složenih sustava.

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 pojavljuje nekoliko puta dnevno. Postoje neke prakse povezane s ovim OS ciklusom koje ćemo detaljnije razmotriti.

Važno: povratne informacije mogu biti rješenje za sve gore navedene probleme. U kombinaciji s 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 petlji. Nije to samo tako. Oni su iznimno važni za cjelokupnu tehniku ​​ekstremnog programiranja.

Pretpostavlja se da imate jedinične i prihvatljive testove. Neki vam daju povratne informacije za nekoliko minuta, drugi za nekoliko dana, pa im je potrebno dulje da se napišu i rjeđe se pregledavaju.

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

Kako se ovaj okvir odnosi na nas u IaC projektu? Zapravo... nimalo.

• Jediničnih testova, unatoč činjenici da bi ih trebalo biti puno, ne može biti previše. Ili testiraju nešto vrlo neizravno. 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. To je, na primjer, naš cjevovod za montažu drona, koji je dosta kompliciran. Jsonnet kod je dobro pokriven testovima.
     Koristimo ovo Okvir za jedinično testiranje 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 provjeru pravila konfiguracije resursa putem tflint. Međutim, tamošnje provjere jednostavno su previše osnovne za terraform, ali mnoge testne skripte napisane su za AWS. A mi smo na Azureu, pa ovo opet ne vrijedi.
• Testovi integracije komponenti: ovisi o tome kako ih klasificirate i gdje ih stavljate. Ali u osnovi rade.

  Ovako izgledaju integracijski testovi.

  
  
  Ovo je primjer izrade slika u Drone CI. Da biste došli do njih, morate pričekati 30 minuta da se formira Packer slika, 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. Pokraj testa nalazi se teraforma s lokalnim stanjem, koju 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. Nakon što se VM implementira sa slike, provjere mogu započeti. Uglavnom se kontrole obavljaju automobilom. Provjerava kako su skripte radile pri pokretanju i kako rade demoni. Da bismo to učinili, putem ssh-a ili winrm-a ​​prijavljujemo se na novo podignuti stroj i provjeravamo status konfiguracije ili jesu li usluge pokrenute.

• Slična je situacija i s integracijskim testovima u modulima za terraform. Ovdje je kratka tablica koja objašnjava značajke takvih testova.

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

Odsutnost jediničnih testova prilikom sastavljanja slika ili terraform modula potiče prebacivanje posla na zasebne usluge koje se jednostavno mogu pokrenuti putem REST-a ili na Python skripte.

Na primjer, morali smo osigurati da se virtualni stroj registrira u servisu kada se pokrene ScaleFT, a kada je virtualni stroj uništen, izbrisao se sam.

Budući da imamo ScaleFT kao uslugu, prisiljeni smo raditi s njim putem API-ja. Tamo je bio napisan omot koji ste mogli povući i reći: "Uđi i izbriši to i to." Pohranjuje sve potrebne postavke i pristupe.

Za to već možemo napisati normalne testove, jer se ne razlikuje od običnog softvera: ismijava se neka vrsta apihe, povučete je i vidite što se događa.

Rezultati testova: Jedinično testiranje, koje bi trebalo dati OS za minutu, ne daje ga. I vrste testiranja više u piramidi su učinkovite, ali pokrivaju samo dio problema.

Programiranje u parovima

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

Kada pišete kod, želite dobiti povratnu informaciju o njegovoj kvaliteti što je brže moguće. Da, možete sve napisati u granu značajki (da nikome ništa ne slomite), napraviti pull request u Githubu, dodijeliti ga nekome čije mišljenje ima težinu i čekati odgovor.

Ali možete čekati dugo. Ljudi su svi zauzeti, a odgovor, čak i ako ga ima, možda nije najkvalitetniji. Pretpostavimo da je odgovor stigao odmah, recenzent je odmah shvatio cijelu ideju, ali odgovor ipak dolazi kasno, nakon činjenice. Volio bih da je bilo ranije. To je ono čemu je cilj programiranje u parovima – odmah, u trenutku pisanja.

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

1. Classic, Experienced+Experienced, pomak po mjeraču vremena. Dvije uloge – vozač i navigator. Dvoje ljudi. Rade na istom kodu i mijenjaju uloge nakon određenog unaprijed određenog vremenskog razdoblja.

Razmotrimo kompatibilnost naših problema sa stilom:

• Problem: nesavršenost alata i alata za razvoj koda.
  Negativan učinak: potrebno je više vremena za razvoj, usporavamo, tempo/ritam rada se gubi.
  Kako se borimo: koristimo različite alate, zajednički IDE i također učimo prečace.
• Problem: Spora implementacija.
  Negativan učinak: povećava vrijeme potrebno za stvaranje radnog dijela koda. Dosađujemo se dok čekamo, ruke nam se pružaju da radimo nešto drugo dok čekamo.
  Kako se borimo: nismo to prevladali.
• Problem: nedostatak pristupa i prakse.
  Negativan učinak: nema znanja o tome kako to učiniti dobro, a kako loše. Produžuje primanje povratnih informacija.
  Kako se borimo: međusobna razmjena mišljenja i prakse u radu u paru gotovo da rješava problem.

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

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

2. Stoni tenis. Ovaj pristup uključuje jednu osobu koja piše test, a druga provodi njegovu implementaciju. Uzimajući u obzir činjenicu da je sve komplicirano s Unit testovima i da morate napisati integracijski test koji se dugo programira, sva lakoća ping-ponga nestaje.

Mogu reći da smo pokušali razdvojiti odgovornosti za dizajniranje testne skripte i implementacije koda za nju. Jedan je sudionik osmislio scenarij, u ovom dijelu posla on je bio odgovoran, imao je zadnju riječ. A drugi je bio odgovoran za provedbu. Dobro je ispalo. Kvaliteta skripte ovim pristupom se povećava.

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

3. Snažan stil. Teška praksa. Ideja je da jedan sudionik postane navigator direktiva, a drugi preuzima ulogu vozača izvršenja. U ovom slučaju, pravo donošenja odluka pripada isključivo navigatoru. Vozač samo ispisuje i može utjecati na ono što se događa riječju. Uloge se dugo ne mijenjaju.

Dobar za učenje, ali zahtijeva jake meke vještine. Ovdje smo posustali. Tehnika je bila teška. A nije čak ni riječ o infrastrukturi.

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

4. Mobbing, swarming i svi poznati ali ne navedeni stilovi Ne razmatramo, jer Mi to nismo probali i nemoguće je o tome govoriti u kontekstu našeg posla.

Opći rezultati korištenja programiranja u paru:

• Imamo neujednačen tempo rada, što je zbunjujuće.
• Naletjeli smo na nedovoljno dobre meke vještine. A predmetno područje ne pomaže u prevladavanju ovih naših nedostataka.
• Dugi testovi i problemi s alatima otežavaju razvoj u paru.

5. Unatoč tome, bilo je uspjeha. Smislili smo vlastitu metodu "Konvergencija - Divergencija". Ukratko ću opisati kako to radi.

Imamo stalne partnere na nekoliko dana (manje od tjedan dana). Zajedno radimo jedan zadatak. Sjedimo zajedno neko vrijeme: jedan piše, drugi sjedi i gleda podršku. Onda se neko vrijeme raziđemo, svatko radi neke samostalne stvari, onda se opet skupimo, vrlo brzo se uskladimo, radimo nešto zajedno i onda se opet raziđemo.

Planiranje i komunikacija

Posljednji blok praksi kroz koje se rješavaju problemi OS-a je organizacija rada sa samim zadacima. To uključuje i razmjenu iskustava koja je izvan rada u paru. Pogledajmo tri prakse:

1. Ciljevi kroz stablo ciljeva. Cjelokupno upravljanje projektom organizirali smo kroz stablo koje ide beskrajno u budućnost. Tehnički, praćenje se obavlja u Miru. Postoji jedan zadatak - to je međucilj. Iz njega idu ili manji ciljevi ili skupine zadataka. Sami zadaci dolaze od njih. Svi se zadaci stvaraju i održavaju na ovoj ploči.

Ova shema također daje povratnu informaciju, koja se događa jednom dnevno kada se sinkroniziramo na skupovima. Imati zajednički plan pred svima, ali strukturiran i potpuno otvoren, omogućuje svima da budu svjesni što se događa i koliko smo napredovali.

Prednosti vizualnog prikaza zadataka:

• Uzročnost. Svaki zadatak vodi nekom globalnom cilju. Zadaci su grupirani u manje ciljeve. Sama infrastrukturna domena prilično je tehnička. Nije uvijek odmah jasno kakav konkretan utjecaj, na primjer, pisanje runbooka o prelasku na drugi nginx ima na poslovanje. Ako imate ciljnu karticu u blizini, to postaje jasnije.
  
  Uzročnost je važno svojstvo problema. Izravno odgovara na pitanje: "Radim li pravu stvar?"
• Paralelizam. Ima nas devet i jednostavno je fizički nemoguće sve baciti na jedan zadatak. Ni zadaci iz jednog područja možda nisu uvijek dovoljni. Prisiljeni smo paralelizirati rad između malih radnih grupa. U isto vrijeme, grupe neko vrijeme rade na svom zadatku, mogu biti pojačane nekim drugim. Ponekad ljudi odustanu od ove radne skupine. Netko ode na godišnji odmor, netko napravi izvještaj za DevOps conf, netko napiše članak na Habru. Vrlo je važno znati koji se ciljevi i zadaci mogu raditi paralelno.

2. Zamjena voditelja jutarnjih sastanaka. Na stand-upu imamo taj problem - ljudi rade mnogo zadataka paralelno. Ponekad su zadaci labavo povezani i nema razumijevanja tko što radi. I mišljenje drugog člana tima je vrlo važno. To su dodatne informacije koje mogu promijeniti tijek rješavanja problema. Naravno, obično je netko s vama, ali savjeti i savjeti uvijek su korisni.

Kako bismo poboljšali ovu situaciju, upotrijebili smo tehniku ​​"Promjena vodećeg stand-upa". Sad se izmjenjuju po određenoj listi i to ima svoje. Kada dođete na red, prisiljeni ste zaroniti i razumjeti što se događa kako biste vodili dobar Scrum sastanak.

3. Interni demo. Pomoć u rješavanju problema iz programiranja u paru, vizualizacija na stablu problema i pomoć na scrum sastancima ujutro su dobri, ali nisu idealni. Kao par, ograničeni ste samo svojim znanjem. Stablo zadataka pomaže globalno razumjeti tko što radi. A voditelj i kolege na jutarnjem sastanku neće duboko zaroniti u vaše probleme. Sigurno bi mogli nešto propustiti.

Rješenje je nađeno u međusobnom demonstriranju obavljenog posla i razgovoru o tome. Sastajemo se jednom tjedno na sat vremena i prikazujemo detalje rješenja zadataka koje smo napravili prošli tjedan.

Tijekom demonstracije potrebno je otkriti detalje zadatka i svakako demonstrirati njegov rad.

Izvješće se može napraviti pomoću popisa za provjeru.1. Uđite u kontekst. Odakle zadatak, zašto je uopće bio potreban?

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

3. Kako ga poboljšavamo. Na primjer: "Pogledajte, sada je tu scriptosik, ovdje je readme."

4. Pokažite kako to radi. Preporučljivo je izravno implementirati neki korisnički scenarij. Želim X, radim Y, vidim Y (ili Z). Na primjer, implementiram NGINX, popušim url i dobijem 200 OK. Ako je akcija duga, pripremite je unaprijed kako biste je kasnije mogli prikazati. Preporučljivo je ne lomiti ga previše sat vremena prije demonstracije, ako je lomljiv.

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

Preporučljivo je da svaki govornik traje 5-10 minuta. Ako je vaš govor očito važan i trajat će duže, koordinirajte to unaprijed u sre-takeover kanalu.

Nakon dijela licem u lice uvijek postoji rasprava u temi. Ovdje se pojavljuju povratne informacije koje su nam potrebne za naše zadatke.

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

Dugi zaključci i što dalje

Može se činiti da je ton članka pomalo pesimističan. To je pogrešno. Dvije niže razine povratne informacije, odnosno testovi i programiranje u paru, rade. Nije tako savršeno kao u tradicionalnom razvoju, ali postoji pozitivan učinak od toga.

Testovi, u svom trenutnom obliku, pružaju samo djelomičnu pokrivenost kodom. Mnoge konfiguracijske funkcije na kraju ostanu neprovjerene. Njihov utjecaj na stvarni rad pri pisanju koda je nizak. Međutim, postoji učinak integracijskih testova i oni vam omogućuju neustrašivo provođenje refaktoriranja. Ovo je veliko postignuće. Također, s pomakom fokusa na razvoj na jezicima visoke razine (imamo python, kreni), problem nestaje. I ne trebate puno provjera za "ljepilo"; dovoljna je opća provjera integracije.

Rad u paru više ovisi o konkretnim osobama. Tu je faktor zadatka i naše meke vještine. Kod nekih ljudi to ide jako dobro, kod drugih lošije. Od toga svakako ima koristi. Jasno je da čak i ako se pravila rada u paru ne poštuju dovoljno, sama činjenica zajedničkog obavljanja zadataka pozitivno utječe na kvalitetu rezultata. Osobno mi je rad u paru lakši i ugodniji.

Načini više razine utjecaja na OS - planiranje i rad sa zadacima precizno proizvode učinke: kvalitetna razmjena znanja i poboljšana kvaliteta razvoja.

Kratki zaključci u jednom retku

• HR praktičari rade u IAC-u, ali s manjom učinkovitošću.
• Ojačajte ono što djeluje.
• Osmislite vlastite kompenzacijske mehanizme i prakse.

Izvor: www.habr.com