🥇Infrastructure as Code: hogyan küzdjünk meg a problémákkal XP segítségével

Helló, Habr! Korábban panaszkodtam az Infrastructure as Code paradigmájában való életre, és semmit sem javasoltam a kialakult helyzet megoldására. Ma visszatértem, hogy meséljek arról, hogy milyen megközelítések és gyakorlatok segíthetnek kiszabadulni a kétségbeesés mélységeiből, és a helyes irányba terelni a helyzetet.

Az előző cikkben «Infrastructure as Code: Első találkozás» megpróbáltam megosztani a benyomásaimat erről a területről, gondolkodtam a jelenlegi helyzetről, és még azt is feltételeztem, hogy a standard, minden fejlesztő által ismert gyakorlatok segíthetnek. Úgy tűnhetett, hogy sok panaszt fogalmaztam meg, de nem kínáltam megoldásokat a kialakult helyzetre.

Kik vagyunk, hol vagyunk és mik a problémáink

Jelenleg az SRE Onboarding Team tagjai vagyunk, amely hat programozóból és három infrastrukturális mérnökből áll. Mindannyian próbálunk Infrastructure as Code (IaC) megoldásokat írni. Ezt azért tesszük, mert az alapvető kódírásban jártasak vagyunk és a háttérünk fejlesztők szintjén 'átlag feletti'.

Van egy csomó előnyünk: bizonyos háttér, a gyakorlatok ismerete, a kódírási képesség és a vágy az új tanulására.
És van egy gyengébb rész is, ez a hátrány: az infrastruktúra anyagról való tudás hiánya.

Az általunk használt technológiai stack az IaC terén.

Terraform az erőforrások létrehozásához.
Packer a képek építéséhez. Ezek Windows és CentOS 7 képek.
Jsonnet a hatékony buildhez a drone.io-n, valamint a packer json és Terraform modulok generálásához.
Azure.
Ansible a képek elkészítésekor.
Python segédszolgáltatásokhoz és a provisionálási szkriptekhez.
És mindez a VSCode-ban zajlik, a csapattagok által megosztott pluginekkel.

A korábbi cikkemből az a következtetés született: próbáltam optimizmust önteni (elsősorban magamba), és azt akartam mondani, hogy ismerjük a megközelítéseket és gyakorlatokat, amelyek segítségével küzdeni fogunk a nehézségekkel és kihívásokkal, amelyek ezen a területen vannak.

Jelenleg ezekkel a IaC problémákkal küzdünk:

Az eszközök és a kódfejlesztés eszközeinek hiányosságai.
Lassú telepítés. Az infrastruktúra a valóság része, és ez nem mindig gyors.
Hiányzó megközelítések és gyakorlatok.
Újak vagyunk, és sok mindent nem tudunk.

A szélsőséges programozás (XP) siet a segítségünkre

Minden fejlesztő számára jól ismert az extrém programozás (XP) és azok a gyakorlatok, amelyek mögötte állnak. Sokan közülünk dolgoztunk már ezzel a megközelítéssel, és az sikeres volt. Miért ne használnánk a benne rejló elveket és gyakorlatokat, hogy leküzdjük a infrastruktúra nehézségeit? Úgy döntöttünk, alkalmazzuk ezt a megközelítést, és megnézzük, hová vezet.

Az XP megközelítés alkalmazhatóságának ellenőrzése a ti területetekenA következőkben bemutatok egy olyan környezetet, amely jól illeszkedik az XP-hez, és hogy ez hogyan viszonyul hozzánk:

1. Dinamikusan változó szoftverigények. Tudtuk, mi a végső cél. De a részletek változhatnak. Mi magunk döntjük el, hová kell kanyarodnunk, ezért az igények időnként megváltoznak (főként mi magunk által). Ha az SRE csoportra nézünk, aki maga végzi az automatizálást és maga is korlátozza az igényeket és a munka terjedelmét, akkor ez a pont jól illeszkedik.

2. Kockázatok a fix időkeretes projekteknél új technológiák alkalmazása miatt. Kockázatok merülhetnek fel, ha ismeretlen dolgokat használunk. És ez 100%-ban a mi esetünk. Az egész projektünk olyan technológiák használata, amelyekkel nem voltunk teljesen tisztában. Ez folyamatos probléma, mivel az infrastruktúrában állandóan új technológiák jelennek meg.

3,4. Kis, együtt elhelyezett kiterjesztett fejlesztőcsapat. Az általad használt technológia lehetővé teszi az automatizált egység- és funkcionális teszteket. Ezek a pontok nem teljesen ránk vonatkoznak. Először is, nem vagyunk ko-lokált csapat, másodszor, kilenc főből állunk, ami nagy csapatnak számíthat. Míg egyes meghatározások szerint a "nagy" csapat 14+ fő.

Vizsgáljunk meg néhány XP-ből származó gyakorlatot és azt, hogy ezek hogyan befolyásolják a visszajelzés gyorsaságát és minőségét.

Az XP visszajelzési ciklusának elve

Az én megértésem szerint a visszajelzés az a válasz, amely arra kérdésre érkezik, hogy jól csinálom-e, arra megyünk-e? Az XP-nek van erre egy isteni diagramja: az időbeli visszajelzési ciklus. Az érdekesség abban rejlik, hogy minél alacsonyabban vagyunk, annál gyorsabban tudunk operatív szolgáltatást kapni, hogy válaszoljunk a szükséges kérdésekre.

Ez egy elég érdekes téma, hogy az IT iparban gyorsan lehet operatív szolgáltatást kapni. Képzeld el, mennyire fájdalmas lehet egy projektet fél évig csinálni, és csak akkor rájönni, hogy az elején hibát vétettünk. Ez előfordulhat a tervezés során és bármilyen bonyolult rendszer felépítése során.

Az IaC esetében a visszajelzés segít nekünk. Azonnal végeztem egy apró módosítást a fenti sémában: a kiadási terv nem havi ciklus, hanem naponta többször valósul meg. Ehhez a ciklushoz kötődnek bizonyos gyakorlatok, amelyeket részletesebben megvizsgálunk.

Fontos: a visszajelzés megoldást nyújthat az összes fent említett problémára. Az XP gyakorlatokkal együtt képes kihúzni a kétségbeesés mélységéből.

Hogyan mentsd meg magad a kétségbeesés mélységéből: három gyakorlat

Tesztelés

A tesztek kétszer kerülnek említésre az XP visszajelzési ciklusában. Ez nem véletlen. Rendkívül fontosak az extrém programozás összes technikájához.

Feltételezzük, hogy rendelkezésedre áll Unit és Acceptance teszt. Az egyik néhány perc alatt visszajelzést ad, a másik napokig tart, mert hosszabban írják és ritkábban futtatják.

Van egy klasszikus tesztelési piramis, amely azt mutatja, hogy bizonyos tesztjeinkből többnek kell lennie.

Hogyan alkalmazható ez a séma a mi IaC projektünkre? Valójában… sehogy.

Unit tesztből, habár soknak kell lennie, nem lehet túl sok. Vagy nagyon közvetve tesztelnek valamit. Valójában elmondható, hogy szinte egyáltalán nem írunk ilyen teszteket. De van néhány alkalmazás, amit mégis sikerült létrehoznunk:
1. Kód tesztelése jsonnet-ben. Ez például a drónban lévő összeszerelési folyamatunk, amely elég bonyolult. A jsonnet kód jól tesztelhető.
  Ezt használjuk Unit testing framework for Jsonnet.
2. Tesztelés a források indításakor végrehajtott szkriptekre. Python szkriptek, így ezeken a teszteken is lehet dolgozni.
Potenciálisan lehetséges a konfiguráció vizsgálata a tesztekben, de mi ezt nem csináljuk. Van lehetőség a források konfigurálási szabályainak ellenőrzésére is a tflint. Azonban a Terraform esetében túl alapvető ellenőrzéseket kínál, viszont sok ellenőrzési forgatókönyv készült az AWS-hez. Mi az Azure-on vagyunk, így ez újból nem alkalmazható.
Komponens integrációs tesztek: ezek attól függnek, hogyan kategorizálod őket és hová sorolod. De alapvetően működnek.
Így néznek ki az integrációs tesztek.

Ez egy példa a képek összeszerelésére a Drone CI-ban. Ahhoz, hogy elérjük őket, 30 percet kell várni, amíg a Packer kép összeáll, majd további 15 percet, amíg lefutnak. De ott vannak!
A képek ellenőrzési algoritmus
1. Először a Packernek teljesen el kell készítenie a képet.
2. A teszt mellett van egy terrafom helyi állapotával, amelyet e képet telepítjük.
3. A telepítés során egy kis modult használunk, amely a közelben található, hogy könnyebb legyen dolgozni a képpel.
4. Amikor a VM a képből telepítve van, elkezdhetjük a vizsgálatokat. Főként a gépen végezzük a teszteket. Ellenőrizzük, hogyan működtek a szkriptek a betöltéskor, és hogyan működnek a démonok. Ehhez ssh vagy winrm segítségével belépünk az éppen létrehozott gépre, és ellenőrizzük a konfiguráció állapotát, illetve hogy a szolgáltatások elindultak-e.
Hasonló a helyzet az integrációs tesztekkel és a terrafom modulokkal. Íme egy rövid táblázat, amely magyarázza ezen tesztek sajátosságait.

A visszajelzés a pipeline-on körülbelül 40 perc. Minden nagyon lassan történik. Lehet regresszióra használni, de új fejlesztéshez teljesen lehetetlen. Ha nagyon-nagyon készülünk rá, előkészítjük a futást, a szkripteket, akkor akár 10 percre is le lehet rövidíteni. De ez még mindig nem olyan, mint a Unit-tesztelés, ami 5 másodperc alatt fut le 100 példányban.

A Unit-tesztelés hiánya a képek vagy a terrafom modulok összegyűjtésekor arra késztet minket, hogy a munkát különböző szolgáltatásokra bízzuk, amelyeket egyszerűen meghívhatunk REST-en keresztül, vagy Python-szkriptekre.

Például úgy kellett megoldanunk, hogy a virtuális gép indításakor regisztrálja magát a ScaleFT, és amikor a virtuális gép megsemmisül, akkor törölje magát.

Mivel a ScaleFT szolgáltatásként működik, kénytelenek vagyunk az API-ján keresztül dolgozni. Itt írtak egy burkoló réteget, amelyet meghívhatunk, és mondhatjuk: "Menj és törölj valamit". Minden szükséges beállítást és hozzáférést tárol.

Erre már tudunk normális teszteket írni, mivel ez semmiben sem különbözik a megszokott szoftvertől: egy API-t szimulálunk, meghívod, és nézzük, mi történik.

A tesztek összegzése: A Unit-tesztelés, amelynek egy perc alatt kellene teljesítenie, nem nyújt eredményt. A piramis magasabb szintjei viszont hatást gyakorolnak, de csak részben oldják meg a problémákat.

Páros programozás

A tesztelés természetesen jó dolog. Sokféle tesztet lehet írni, és ezek különböző szinten fognak működni, visszajelzést adva nekünk. Azonban a rossz unit-tesztek problémája, amelyek a leggyorsabb operációs rendszert eredményezik, továbbra is fennáll. Még mindig vágyunk egy gyors operációs rendszerre, amivel könnyű és kellemes dolgozni. Nem is beszélve a megoldás minőségéről. Szerencsére vannak technikák, amelyek lehetővé teszik, hogy még gyorsabb visszajelzést kapjunk, mint a moduláris tesztek. Ez a páros programozás.

A kód írásakor minél gyorsabban szeretnénk visszajelzést kapni annak minőségéről. Igen, mindent meg lehet írni egy feature ágban (hogy senkinek se okozzon kárt), létrehozni egy pull requestet a GitHubon, kijelölni valakit, akinek a véleménye fontos, és várni a válaszra.

De várni hosszú ideig lehet. Az emberek mind elfoglaltak, és a válasz, még ha meg is érkezik, nem biztos, hogy a legjobb minőségű. Tegyük fel, hogy a válasz azonnal megérkezett, a véleményező azonnal megértette az elképzelést, de a válasz így is késlekedik, utólag érkezik. Pedig korábban szeretnénk. A páros programozás éppen ezért van – hogy azonnal, az írás pillanatában kapjunk visszajelzést.

Az alábbiakban bemutatom a páros programozás stílusait és azok alkalmazhatóságát az IaC terén:

1. Klasszikus, tapasztalt + tapasztalt, időzített váltás. Két szerep – driver és navigator. Két ember. Együtt dolgoznak egy kódon, és előre meghatározott időintervallumonként váltanak szerepet.

Tekintsük át a problémáink és a stílus összeférhetőségét:

Probléma: eszközök, a kód fejlesztéséhez szükséges eszközök tökéletlensége.
Negatív hatás: hosszabb fejlesztési idő, lelassulunk, megzavarodik a munka üteme/ritmusa.
Hogyan küzdünk ellene: más eszközöket alkalmazunk, közös IDE-t, és tanuljuk a billentyűparancsokat.
Probléma: lassú telepítés.
Negatív hatás: megnöveli az időt, amíg egy működő kód részletet létrehozunk. Unatkozunk a várakozás alatt, és kezünk hajlik arra, hogy valami másba kezdjünk, miközben várunk.
Hogyan küzdünk ellene: még nem győztük le.
Probléma: a megközelítések és gyakorlatok hiánya.
Negatív hatás: nincs tudás arról, hogyan kell jól, és hogyan rosszul csinálni. Megnöveli a visszajelzés megszerzésének idejét.
Hogyan küzdünk ellene: a vélemények és gyakorlatok kölcsönös cseréje a páros munkában szinte megoldja a problémát.

A fő probléma az IaC ezen stílusának alkalmazásában az egyenlőtlen munkatempóra vezethető vissza. A hagyományos szoftverfejlesztés során a mozgás nagyon egyenletes. El tudsz tölteni öt percet és írni egy N-t. Töltesz tíz percet és írsz 2N-t, 15 percet – 3N-t. Itt viszont eltölthetsz öt percet és írhatsz egy N-t, majd további 30 percet, és írhatsz egy tizedet az N-ből. Itt semmit sem tudsz, megakadsz, elakadsz. A rendezés időt vesz igénybe és eltérít a tényleges programozástól.

Következtetés: tiszta formájában nem megfelelő számunkra.

2. Ping-pong. Ez a megközelítés azt jelenti, hogy az egyik résztvevő tesztet ír, a másik pedig megvalósítja azt. Figyelembe véve, hogy a Unit-tesztekkel minden komplikált, és hosszú időt igényel egy integrált teszt írása, a ping-pong egyszerűsége eltűnik.

Elmondhatom, hogy próbálkoztunk a tesztforgatókönyv tervezésének és a hozzá tartozó kód megvalósításának feladatainak szétosztásával. Az egyik résztvevő elképzelte a forgatókönyvet, ebben a munkarészben ő volt a felelős, az utolsó szó az övé volt. A másik a megvalósításért volt felelős. Ez jól működött. Az ilyen megközelítéssel a forgatókönyv minősége javult.

Következtetés: sajnos a munkatempó nem teszi lehetővé a ping-pong alkalmazását, mint a páros programozási gyakorlatot az IaC-ben.

3. Strong Style. Bonyolult gyakorlat.A lényeg, hogy az egyik résztvevő irányító navigátorként működik, míg a másik végrehajtó meghajtó szerepét tölti be. A döntések joga kizárólag a navigátoré. A meghajtó csak gépel és szavakkal befolyásolhatja a folyamatot. A szerepek hosszú ideig nem változnak.

Jól alkalmas a tanulásra, de erős soft skill-eket igényel. Itt akadtunk el. A technika nehezen haladt. Ennek nem is az infrastruktúra volt az oka.

Következtetés: potenciálisan alkalmazható, nem hagyjuk abba a próbálkozást.

4. Mobbing, swarming és minden ismert, de itt nem felsorolt stílus. nem vizsgáljuk, mert nem próbáltuk ki, és nem tudunk erről beszélni a mi munkánk kontextusában.

Általános eredmények a páros programozás használatáról:

Egyenlőtlen munkatempót tapasztalunk, ami zavaró.

A nem elég jó soft skill-ekbe ütköztünk. Az adott terület nem segíti elő ezeknek a hiányosságoknak a leküzdését.

Hosszú tesztek, eszközproblémák teszik a páros fejlesztést nehézkessé.

5. Ennek ellenére voltak sikereink is. Kitaláltunk egy saját "Összeolvadás – szétválás" módszert. Röviden bemutatom, hogyan működik.

Van néhány állandó partnerünk néhány napra (kevesebb mint egy hétre). Egy feladatot közösen végzünk el. Szóval egy ideig együtt ültünk: az egyik ír, a másik figyeli, mint egy támogató csapat. Aztán elválunk egy időre, mindenki független dolgokat csinál, majd újra összeülünk, nagyon gyorsan szinkronizálódunk, közösen csinálunk valamit, és ismét elválunk.

Tervezés és kommunikáció

Az utolsó blokk gyakorlatai, amelyek megoldják az operációs rendszerek problémáit – a feladatokkal való munka szervezése. Ide tartozik a párban végzett munkán kívüli tapasztalatcsere is. Három gyakorlatot fogunk megvizsgálni:

1. Feladatok célfa szerint. A projekt átfogó irányítását egy fával szerveztük, amely végtelenül a jövőbe nyúlik. Technikailag az irányítás Miro-ban történik. Van egy feladat – ez egy közbenső cél. Ebből kisebb célok, vagy feladatcsoporák indulnak. Azoktól már maguk a feladatok. Minden feladat ezen a táblán jön létre és van nyilvántartva.

Ez a rendszer is visszajelzést ad, amely naponta egyszer történik, amikor a találkozókon szinkronizálódunk. Az, hogy mindenki előtt van egy közös, struktúrált és teljesen nyilvános terv, lehetővé teszi, hogy mindenki tisztában legyen az eseményekkel és azzal, mennyit haladtunk előre.

A feladatok vizuális áttekintésének előnyei:

Ok-okozati összefüggés. Minden feladat valamilyen globális célhoz vezet. A feladatok kisebb célok szerint csoportosulnak. Az infrastruktúra területe önmagában meglehetősen technikai. Nem mindig világos, hogy például a migrációs kézikönyv elkészítése, amely egy másik nginx-hez kapcsolódik, milyen konkrét hatással van az üzletre. A célkártya mellett azonban ez érthetőbbé válik.

Az ok-okozati összefüggés – fontos jellemzője a feladatoknak. Közvetlenül válaszol arra a kérdésre: "Jót csinálok?"
Párhuzamosság. Kilencen vagyunk, és fizikailag lehetetlen, hogy egyszerre egy feladatra összpontosítsunk. Az egy területről származó feladatokból sem mindig elegendő. Kényszerülünk arra, hogy a munkát apró munkacsoportok között párhuzamosan osszuk meg. Ezek a csoportok egy ideig a saját feladatukra fókuszálnak, őket erősítheti valaki más is. Néha a munkacsoportból emberek esnek ki. Valaki szabadságra megy, valaki előadást készít a DevOps konferenciára, valaki cikket ír a Habr-ra. Fontos tudni, hogy mely célok és feladatok végezhetők el párhuzamosan.

2. Váltakozó vezetők a reggeli megbeszéléseken. A stand-up-ok során egy probléma merült fel – sok feladatot párhuzamosan végeznek az emberek. Néha a feladatok gyengén kapcsolódnak egymáshoz, és nincs tisztában senki, hogy ki mit csinál. Egy csapattag véleménye nagyon fontos. Ez egy plusz információ, amely megváltoztathatja a feladat megoldásának menetét. Persze, általában van valaki, akivel együtt vagy, de a konzultáció és az útmutatás mindig nem árt.

A helyzet javítása érdekében alkalmaztuk a "Stand-up vezető váltás" technikát. Most egy meghatározott lista szerint rotálódnak, és ennek megvan a hatása. Amikor elérkezik a te időd, kénytelen vagy elmélyedni és megérteni, mi történik, hogy jól vezesd a scrum megbeszélést.

3. Belső demó. A párban programozásból származó segítség, a feladatok fában való vizualizálása és a reggeli scrum megbeszélések során nyújtott segítség jó, de nem tökéletes. Párban csak a saját tudásodra vagy korlátozva. A feladatfá segít globálisan megérteni, ki mit csinál. A vezető és a kollégák a reggeli találkozón nem mélyednek el a problémáidban. Már biztosan valamit ki fognak hagyni.

A megoldás az volt, hogy bemutattuk egymásnak a kész munkákat, majd ezt követően megvitattuk azokat. Hetente egyszer összegyűlünk egy órára, és bemutatjuk az utolsó hétben végzett feladatok részleteit.

A bemutató során fontos, hogy részletezd a feladatot, és mindenképp mutasd be annak működését.

Az előadást lehet check-list alapján lebonyolítani.1. Helyezd kontextusba. Honnan származott a feladat, miért volt erre szükség?

2. Hogyan oldották meg a feladatot eddig? Például szükséges volt a tömeges kattintás, vagy egyáltalán lehetetlen volt valamit megvalósítani.

3. Hogyan javítjuk ezt. Például: "Nézzétek, most van egy kis szkriptnyi, itt a README."

4. Mutassa be, hogyan működik. Lehetőleg közvetlenül végezzen el egy felhasználói forgatókönyvet. Azt szeretném, hogy X legyen, csinálok Y-t, látom Z-t (vagy Y-t). Például telepítek NGINX-et, megnézem az URL-t, kapok 200 OK-t. Ha az akció hosszú, készítse elő előre, hogy később meg tudja mutatni. Lehetőleg egy órával a bemutató előtt ne bontsa meg, ha törékeny.

5. Magyarázza el, mennyire sikeresen oldódott meg a probléma, milyen nehézségek maradtak, mi nem készült el, milyen fejlesztések lehetségesek a jövőben. Például jelenleg CLI, később pedig teljes automatizálás a CI-n.

Lehetőleg minden előadónak 5-10 percet kell betartania. Ha az előadása eleve fontos, és több időt vesz igénybe, előre egyeztesse ezt az sre-takeover csatornában.

A személyes rész után kötelező a diskurzus a szálban. Itt jelenik meg a szükséges visszajelzés a feladatainkról.

A végén egy felmérést végeznek a történtek hasznosságának megállapítására. Ez visszajelzés a bemutató lényegéről és a feladat fontosságáról.

Hosszú következtetések és mi a következő lépés

Úgy tűnhet, hogy a cikk hangulata némileg pesszimista. Ez nem így van. Két alsó szintű visszajelzési forma, név szerint a tesztek és a páros programozás működik. Nem teljesen olyan, mint a hagyományos fejlesztésben, de van pozitív hatása.

A tesztek jelenlegi formájukban csak részleges kódlefedettséget adnak. Sok konfigurációs funkció tesztelés nélkül marad. Ezek közvetlen hatása a kódírásra alacsony. Az integrációs tesztek azonban hatásosak, és éppen ezek teszik lehetővé a kockázatmentes refaktorálást. Ez nagy eredmény. Továbbá a fókusz áthelyezésével a magas szintű nyelvek (nálunk python, go) problémája elmúlik. A „ragasztó”-hoz kevés ellenőrzés szükséges, elegendő az általános integráció.

A páros munka egyre inkább az adott emberektől függ. Van egy feladati tényező és a soft skills-ünk. Valakivel nagyon jól sikerül, másokkal kevésbé. Ennek biztosan van haszna. Nyilvánvaló, hogy még a páros munka szabályainak elégtelen betartása esetén is a közös feladatvégzés ténye pozitívan befolyásolja az eredmény minőségét. Személy szerint nekem párosan sokkal könnyebb és kellemesebb dolgozni.

A magasabb szintű módszerek a rendszer operációinak befolyásolására – a feladatok tervezése és kezelése – biztosan hatásosak: a tudás minőségi cseréje és a fejlesztés minőségének javítása.