🥇Infrastructure as Code: kako prevazići probleme pomoću XP

Živjo, Habr! Prej sem se pritoževal nad življenjem v paradigmi infrastruktura kot koda in nisem ponujal rešitev za nastalo situacijo. Danes sem se vrnil, da povem, kateri pristopi in prakse nam bodo pomagali pobegniti iz brezna obupa in preusmeriti situacijo v pravo smer.

V prejšnjem članku »Infrastruktura kot koda: prvo srečanje« Delil sem svoje vtise o tem področju, poskušal razmišljati o trenutni situaciji na tem področju in celo domneval, da bi standardne, znane vsem razvijalcem prakse, lahko pomagale. Morda se je zdelo, da je bilo tam veliko pritožb nad življenjem, a ni bilo predlogov za izhod iz nastale situacije.

Kdo smo, kje smo in katere težave imamo

Trenutno smo v Sre Onboarding Team, ki ga sestavlja šest programerjev in trije infrastrukturni inženirji. Vsi se trudimo pisati infrastrukturo kot kodo (IaC). To delamo, ker v splošnem znamo pisati kodo in v preteklosti smo bili razvijalci na ravni »nad povprečjem«.

Imamo nekaj prednosti: določeno ozadje, znanje praks, sposobnost pisanja kode, željo po učenju novega.
In imamo tudi šibko točko, ki je slabost: pomanjkanje znanja o osnovah infrastrukture.

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

Terraform za ustvarjanje virov.
Packer za sestavljanje slik. To so Windows in CentOS 7 slike.
Jsonnet, da ustvarimo močno sestavo v drone.io, ter za generiranje packer json in naših Terraform modulov.
Azure.
Ansible pri pripravi slik.
Python za pomočnike ter skripte za provisioning.
In vse to v VSCode s vtičniki, ki jih delimo med člani ekipe.

Izvlek iz moje prejšnje objave je bil takšen: poskušal sem vsaditi (predvsem v sebe) optimizem, želel sem povedati, da bomo poskusili znane pristope in prakse, da bi se borili proti težavam in izzivom, ki jih imamo na tem področju.

Trenutno se borimo s takšnimi težavami IaC:

Nepopolnost orodij in sredstev za razvoj kode.
Počasna uvedba. Infrastruktura je del resničnega sveta, ki lahko ni hiter.
Pomanjkanje pristopov in praks.
Smo novinci in veliko ne vemo.

Ekstremno programiranje (XP) priskoči na pomoč

Vsem razvityam dobré známo extrémní programování (XP) a ty praktiky, které za ním stojí. Mnozí z nás pracovaly podle takového přístupu a byl úspěšný. Proč tedy nevyužít principy a praktiky, které tam byly uloženy, k překonání potíží infrastruktury? Rozhodli jsme se tento přístup aplikovat a zjistit, co z toho vzejde.

Kontrola použitelnosti přístupu XP ve vaší oblastiUvedu popis prostředí, pro které je XP vhodné, a jak to souvisí s námi:

1. Dynamicky se měnící požadavky na software. Bylo nám jasné, jaký je konečný cíl. Detaily však mohou kolísat. Rozhodujeme sami, kam potřebujeme směřovat, proto se požadavky periodicky mění (většinou naším vlastním rozhodnutím). Pokud vezmeme tým SRE, který sám provádí automatizaci a sám určuje požadavky a rozsah práce, pak tento bod se velmi dobře hodí.

2. Rizika způsobená časově fixovanými projekty s použitím nové technologie. Můžeme čelit rizikům při použití něčeho, co nám není známé. A to je náš 100% případ. Celý náš projekt spočívá v používání technologií, se kterými jsme nebyli zcela obeznámeni. To je obecně trvalý problém, protože v oblasti infrastruktury neustále vzniká mnoho nových technologií.

3,4. Malý, spolu umístěný rozšířený vývojový tým. Technologie, kterou používáte, umožňuje automatizované jednotkové a funkční testy. Tyto dva body nám zcela nevyhovují. Zaprvé, nejsme kolokovaný tým, a zadruhé, máme devět lidí, což může být považováno za velký tým. Nicméně podle některých definic je "velký" tým, když je nás 14 nebo více.

Podívejme se na některé praktiky z XP a jak ovlivňují rychlost a kvalitu zpětné vazby.

Princip zpětné vazby v XP

Podle mého názoru je zpětná vazba odpovědí na otázku, zda dělám vše správně, zda směřujeme tam, kam chceme? V XP je na to úžasný diagram: časový cyklus zpětné vazby. Intrikující je, že čím níže se nacházíme, tím rychleji máme možnost získat OS a odpovědět na potřebné otázky.

To je poměrně zajímavé téma k diskusi, že v IT průmyslu je možné rychle získat OS. Představte si, jak bolestivé je pracovat na nějakém projektu půl roku a až poté zjistit, že na samém začátku byla uložena chyba. To se děje jak při projektování, tak i při jakémkoli budování složitých systémů.

V našem případě nám IaC pomáhá zpětná vazba. Hned provedu drobnou úpravu ve výše uvedeném schématu: vydávací plán není měsíční cyklus, ale probíhá několikrát za den. K tomuto cyklu jsou připojeny některé praktiky, které si podrobněji probereme.

Důležité: zpětná vazba může být řešením všech výše uvedených problémů. V kombinaci s praktikami XP může vytáhnout z propasti zoufalství.

Jak se vytáhnout z propasti zoufalství: tři praktiky

Testovi

Testy jsou v cyklu zpětné vazby XP zmíněny dvakrát. Není to náhodou. Jsou extrémně důležité pro celou techniku extrémního programování.

Předpokládá se, že máš Unit a Acceptance testy. Jedny ti dávají zpětnou vazbu během několika minut, druhé během několika dnů, proto se píší déle a spouštějí se méně často.

Existuje klasická pyramida testování, která ukazuje, že by mělo být více některých testů.

Jak je tento schéma aplikovatelné na nás v projektu IaC? Ve skutečnosti… nijak.

Unit testů, i když jich musí být hodně, nemůže být příliš mnoho. Buď testují velmi nepřímo něco. Skutečně lze říct, že je vůbec nepíšeme. Ale existuje několik aplikací pro takové testy, které jsme přece jen dokázali udělat:
1. Testování kódu na jsonnet. Například náš pipeline pro sestavení v drone, který je dost složitý. Kód na jsonnet je dobře pokryt testy.
  Používáme tento Unit testing framework for Jsonnet.
2. Testy na skripty, které se vykonávají při spuštění zdroje. Skripty jsou v Pythonu, a znamená to, že testy na ně lze psát.
Potenciálně je možná kontrola konfigurace v testech, ale takhle to neděláme. Ještě je možnost nastavení kontroly pravidel konfigurování zdrojů přes tflint. Nicméně, pro terraform tam jsou příliš základní kontroly, ale mnoho kontrolních scénářů bylo napsáno pro AWS. A my jsme na Azure, takže to opět nevyhovuje.
Komponentní integrační testy: tady záleží na tom, jak je klasifikuješ a kam je rozkládáš. Ale v zásadě fungují.
Takto vypadají integrační testy.

To je příklad při sestavení obrazů v Drone CI. Aby se k nim dostali, musí se čekat 30 minut, než se sestaví image Packer, pak ještě 15 minut, než projdou. Ale jsou!
Algoritmus kontroly obrazů
1. Nejprve musí Packer úplně připravit obraz.
2. Поблизу находится терраформ с локальным состоянием, с помощью которого мы разворачиваем этот образ.
3. При разворачивании используется небольшой модуль, расположенный рядом, чтобы упростить работу с образом.
4. Когда из образа развернута виртуальная машина, можно приступать к проверкам. В основном, проверки проводятся на машине. Мы проверяем, как исполнились скрипты при запуске, и как работают демоны. Для этого через ssh или winrm мы подключаемся к только что запущенной машине и проверяем состояние конфигурации или работоспособность сервисов.
Похожая ситуация с интеграционными тестами в модулях для терраформа. Вот краткая таблица, объясняющая особенности таких тестов.

Обратная связь на пайплайне составляет около 40 минут. Все происходит очень медленно. Можно использовать для регресса, но для новой разработки это вообще нереально. Если очень-очень подготовиться, подготовить запуск и скрипты, то можно сократить до 10 минут. Но это всё равно не Соответствующие тесты, которые проходят за 5 секунд по 100 штук.

Отсутствие Соответствующих тестов при сборке образов или модулей терраформа заставляет перекидывать работу на отдельные сервисы, которые можно просто вызвать через REST, или на Python-скрипты.

Например, нам нужно было сделать так, чтобы при запуске виртуальной машины она регистрировала себя в сервисе ScaleFT, а при уничтожении виртуальной машины удаляла себя.

Поскольку ScaleFT у нас как сервис, мы вынлены работать с ним через API. Там была написана обертка, которую можно вызвать и сказать: «Зайди и удали то-то, то-то». Она хранит все необходимые настройки и доступы.

На это уже можем писать нормальные тесты, так как это никак не отличается от обычного программного обеспечения: мокается какая-то API, ты вызываешь, и смотрим, что происходит.

Итоги по тестам: Соответствующее тестирование, которое должно давать ОС за минуту, не дает его. А более высокие виды тестирования дают эффект, но покрывают лишь часть проблем.

Парное программирование

Testi so, seveda, koristni. Lahko jih napišemo veliko, lahko so različnih vrst. Delovali bodo v svojih nivojih in nam dajali povratne informacije. Vendar pa problem slabih enotnih testov, ki dajo najhitrejši operacijski sistem, ostaja. Kljub temu še vedno hrepenimo po hitrem operacijskem sistemu, s katerim je enostavno in prijetno delati. O kakovosti rešitve, ki jo dobimo, niti ne govorimo. Na srečo obstajajo tehnike, ki omogočajo še hitrejše povratne informacije kot enotni testi. To je para programiranje.

Pri pisanju kode si želimo čimprej dobiti povratne informacije o njeni kakovosti. Da, vse lahko napišemo v funkcijski veji (da ne bi ničesar pokvarili nikomur), naredimo pull request na GitHubu, določimo nekoga, čije mnenje šteje, in čakamo na odgovor.

Ampak čakati je lahko dolgo. Ljudje so vsi zaposleni, odgovor, tudi če pride, morda ne bo najkakovostnejši. Predpostavimo, da je odgovor prišel takoj, recenzent je takoj razumel celotno zamisel, a odgovor še vedno pride z zamudo, post factum. Želimo si hitreje. Tu je para programiranje osredotočeno na to - da takoj, ob pisanju.

Nato predstavljam sloge para programiranja in njihovo uporabnost pri delu z IaC:

1. Klasičen, izkušen + izkušen, sprememba glede na časovnik. Dve vlogi – voznik in navigator. Dva človeka. Delata nad enim in istim kodeksom in zamenjata vloge preko vnaprej določenega časovnega obdobja.

Oglejmo si združljivost naših težav s stilom:

Težava: nepopolnost orodij in sredstev za razvoj kode.
Negativen vpliv: daljši razvoj, upočasnimo se, ritmi dela se izkrivlja.
Kako se borimo: uporabljamo drugačno orodje, skupni IDE in še učimo bližnjice.
Težava: počasno uvajanje.
Negativen vpliv: podaljšuje čas za ustvarjanje delujočega koda. Med čakanjem se dolgočasimo, roke se stegujejo, da bi se ukvarjali s čim drugim, medtem ko čakamo.
Kako se borimo: nismo premagali.
Težava: pomanjkanje pristopov in praks.
Negativen vpliv: ni znanja, kako narediti dobro in kako slabo. Podaljšuje pridobivanje povratnih informacij.
Kako se borimo: medsebojno izmenjujemo mnenja in prakse v parnem delu skoraj rešuje problem.

Glavna težava pri uporabi tega sloga v IaC je neenakomeren tempo dela. Pri tradicionalnem razvoju programske opreme imaš zelo ravno gibanje. Lahko porabiš pet minut in napišeš N. Porabiš 10 minut in napišeš 2N, 15 minut – 3N. Tu pa lahko porabiš pet minut in napišeš N, nato pa še 30 minut in napišeš deseti del N. Tu nič ne veš, nastane zastoja, zmeda. Razumevanje vzame čas in odvrne od samega programiranja.

Izvleček: v čisti obliki nam ne ustreza.

2. Ping-pong. Ta pristop predvideva, da en sodelujoči piše test, drugi pa izvede implementacijo. Glede na to, da je z enotnimi testi vse zapleteno, in je treba dolgo pisati integracijski test, vsa preprostost ping-ponga izgine.

Lahko povem, da smo poskusili razdelitev nalog pri oblikovanju scenarija testa in implementaciji kode zanj. En sodelujoči je oblikoval scenarij, v tem delu dela je bil odgovoren, on je imel zadnjo besedo. Drugi je bil odgovoren za implementacijo. Izšlo je dobro. Kakovost scenarija se pri takšnem pristopu povečuje.

Izvleček: žal tempo dela ne omogoča uporabe ping-ponga kot prakse parnega programiranja v IaC.

3. Strong Style. Zahteven praksa. Ideja je, da en sodelujoči postane usmerjevalnik, drugi pa prevzame vlogo izvajalca. Pri tem ima pravico odločanja izključno usmerjevalnik. Izvajalec samo tipka in lahko z besedo vpliva na dogajanje. Vloge se dolgo ne spreminjajo.

Dobro se prilega za učenje, vendar zahteva močne mehke veščine. Tu smo se zataknili. Tehnika je bila težavna. In problem ni le v infrastrukturi.

Izvleček: potencialno se lahko uporablja, ne obupamo nad poskusi.

4. Mobbing, swarming in vse znane, vendar tu nepomenovane sloge ne obravnavamo, saj jih nismo preizkusili in o njih ne moremo govoriti v kontekstu našega dela.

Skupni zaključki o uporabi parnega programiranja:

Imamo neenakomeren tempo dela, ki moti.

Ustavili smo se pri nezadostnih mehkih veščinah. In predmetna področja ne spodbujajo premagovanja teh naših pomanjkljivosti.

Dolgi testi, težave z orodji naredijo parno razvijanje zmedeno.

5. Kljub temu so bili tudi uspehi. Izumili smo lastno metodo 'Srečanje – razhajanje'. Na kratko bom opisal, kako deluje.

Imamo stalne partnerje za nekaj dni (manj kot teden). Skupaj opravljamo eno nalogo. Nekaj časa sedimo skupaj: eden piše, drugi sedi in spremlja, kot podpora ekipi. Nato se na trenutek razhajamo, vsak dela svoje neodvisne stvari, potem se ponovno srečamo, zelo hitro uskladimo, delamo nekaj skupaj in se spet razhajamo.

Načrtovanje in komunikacija

Zadnji blok praks, preko katerih rešujemo težave OS, je organizacija dela z nalogami. Sem spada tudi izmenjava izkušenj, ki je zunaj parnega dela. Poglejmo tri prakse:

1. Naloge preko drevesa ciljev. Skupno vodenje projekta smo organizirali preko drevesa, ki neskončno odhaja v prihodnost. Tehnično se vodi v Miro. Obstaja ena naloga – to je vmesni cilj. Od nje izhajajo bodisi manjši cilji bodisi skupine nalog. Od teh se že oblikujejo same naloge. Vse naloge se ustvarjajo in vodijo na tej plošči.

Ta shema prav tako daje povratne informacije, ki se dogajajo enkrat na dan, ko se usklajujemo na sestankih. Ob وجود skupnega načrta, ki je strukturiran in povsem odprt, omogoča vsakemu, da je seznanjen, kaj se dogaja in kako daleč smo napredovali.

Prednosti vizualizacije nalog:

Povezanost. Vsaka naloga vodi do neke globalne cilja. Naloge se grupirajo po manjših ciljih. Območje infrastrukture je samo po sebi precej tehnično. Ni vedno takoj jasno, kakšen specifičen vpliv na posel ima, na primer, pisanje navodil za migracijo na drug nginx. Prisutnost cilja ob strani to naredi bolj razumljivo.

Povezanost je pomembna lastnost nalog. Neposredno odgovarja na vprašanje: 'Ali delam pravo stvar?'
Paralelnost. Nas devet ljudi, i nije fizički moguće da se svi bacaju na jedan zadatak. Zadatak iz jedne oblasti takođe ne mora uvek biti dovoljan. Primorani smo da paralelizujemo rad između manjih radnih grupa. U tom trenutku, grupe neko vreme rade na svom zadatku, mogu ih pojačati još nekim. Iz te radne grupe ponekad odlaze ljudi. Neko ide na odmor, neko pravi izlaganje za konferenciju DevOps conf, neko piše članak za Habr. Značajno je znati koje ciljeve i zadatke može raditi paralelno.

2. Smene vođa jutarnjih sastanaka. Na stand-upovima je nastao problem – ljudi paralelno rade mnogo zadataka. Ponekad su zadaci slabo povezani i nema razumevanja ko šta radi. A mišljenje još jednog člana tima je veoma važno. To je dodatna informacija koja može promeniti tok rešenja zadatka. Naravno, obično imaš nekoga pored sebe, ali konsultacije i sugestije nikada nisu suvišne.

Da bismo poboljšali ovu situaciju, primenili smo tehniku "Smena vođe stand-upa". Sada se rotiraju prema utvrđenom spisku, i to daje efekat. Kada dođe tvoj red, moraš se uroniti i razumeti šta se dešava kako bi dobro vodio scrum sastanak.

3. Interno demo. Pomoć u rešavanju zadatka putem parnog programiranja, vizualizacija na stablu zadataka i pomoć na scrum sastancima ujutro – dobro je, ali nije savršeno. U paru si ograničen samo na svoja znanja. Stablo zadataka pomaže globalno razumeti ko i šta radi. A vođa i kolege na jutarnjem sastanku ne uranjaju duboko u tvoje probleme. Sigurno mogu nešto i propustiti.

Rešenje je pronađeno u demonstraciji urađenih radova jedni drugima i kasnijem razgovoru o njima. Okupljamo se jednom nedeljno na sat vremena i pokazujemo detalje rešenja po zadacima koje smo radili tokom poslednje nedelje.

Tokom demonstracije treba otkriti detalje zadatka i obavezno pokazati njegov rad.

Izlaganje se može voditi prema check-listi.1. Uvedite u kontekst. Odakle potiče zadatak, zašto je to uopšte bilo potrebno?

2. Kako se zadatak rešavao do sada? Na primer, zahtevalo se masovno klikanje mišem, ili je uopšte bilo nemoguće nešto uraditi.

3. Kako to poboljšavamo. Na primer: "Pogledajte, sada imamo mali skript, evo readme-a."

4. Pokažite, kako to deluje. Zaželeno je direktno izvesti neki korisnički scenario. Hoću X, radim Y, vidim Z. Na primer, deployujem NGINX, pregledam URL, dobijam 200 OK. Ako akcija traje duže, pripremite unapred kako biste kasnije pokazali. Idealno je ne prekidati pre demo minimalno sat vremena unapred, ukoliko je osetljivo.

5. Objasnite koliko je uspešno rešeno pitanje, koji problemi su ostali, šta nije završeno, kakve su moguće buduće nadogradnje. Na primer, trenutno je CLI, ali će kasnije biti puna automatizacija u CI.

Poželjno je da svaki govornik stane u 5-10 minuta. Ako je vaše izlaganje naročito važno i oduzeće više vremena, unapred to dogovorite u SRE-takeover kanalu.

Nakon fizičkog dela obavezno sledi diskusija u thread-u. Tu se pojavljuje potrebna povratna informacija o našim zadacima.

Na kraju se sprovodi anketa da bi se utvrdila korisnost događaja. Ovo već predstavlja povratnu informaciju o suštini izlaganja i važnosti zadatka.

Dugoročne posledice i šta dalje

Može delovati da je ton članka pomalo pesimističan. To nije tačno. Dva osnovna nivoa dobijanja povratne informacije, a to su testovi i parno programiranje, funkcionišu. Ne baš savršeno kao u tradicionalnom razvoju, ali pozitivni efekti su prisutni.

Testovi, u trenutnom obliku, pružaju samo delimično pokriće koda. Mnoge konfiguracione funkcije ostaju neproverene. Njihov uticaj na neposredno pisanje koda je mali. Ipak, efekat integracionih testova postoji, i oni omogućavaju bez straha provođenje refaktorizacija. To je veliko dostignuće. Takođe, sa premestanjem fokusa na razvoj u visoko-nivou jezicima (kod nas python, go) problem se povlači. A za 'lepak' ima puno provera i nije potrebno, dovoljno je opšte integracione.

Rad u paru više zavisi od konkretnih ljudi. Tu je faktor zadatka i naše softverske veštine. Sa nekim ide jako dobro, sa nekim slabije. Korist od toga je očigledna. Jasno je da čak i uz nedovoljno poštovanje pravila parnog rada, sama činjenica zajedničkog izvršavanja zadataka pozitivno utiče na kvalitet rezultata. Meni lično u paru ide lakše i prijatnije.

Viši nivo načina uticaja na OS – planiranje i rad sa zadacima svakako daju efekat: kvalitetna razmena znanja i poboljšanje kvaliteta razvoja.