Infrastruktúra mint kód: hogyan lehet leküzdeni a problémákat XP használatával

Szia Habr! Korábban panaszkodtam az infrastruktúra életére, mint kódparadigmára, és nem kínáltam semmit a jelenlegi helyzet megoldására. Ma visszatérek, hogy elmondjam, milyen megközelítések és gyakorlatok segítenek kiszabadulni a kétségbeesés szakadékából, és a helyes irányba terelni a helyzetet.

Egy korábbi cikkben "Infrastruktúra mint kód: első ismerkedés" Megosztottam benyomásaimat erről a területről, próbáltam reflektálni a jelenlegi helyzetre ezen a területen, sőt felvetettem, hogy a minden fejlesztő által ismert szabványos gyakorlat segíthet. Úgy tűnhet, hogy sok panasz érkezett az életre, de nem voltak javaslatok a jelenlegi helyzetből való kiutat illetően.

Kik vagyunk, hol vagyunk és milyen problémáink vannak

Jelenleg a Sre Onboarding Team tagja vagyunk, amely hat programozóból és három infrastrukturális mérnökből áll. Mindannyian megpróbáljuk az infrastruktúrát kódként (IaC) írni. Ezt azért tesszük, mert alapvetően tudjuk, hogyan kell kódot írni, és „átlagon felüli” fejlesztők vagyunk.

• Van egy sor előnyünk: bizonyos háttér, gyakorlatok ismerete, kódírási képesség, új dolgok elsajátítására való vágy.
• És van egy megereszkedett rész, ami szintén mínusz: az infrastrukturális hardverekkel kapcsolatos ismeretek hiánya.

Az IaC-ben használt technológiai halom.

• Terraform erőforrások létrehozásához.
• Csomagoló a képek összeállításához. Ezek Windows, CentOS 7 képek.
• Jsonnet a drone.io hatékony építéséhez, valamint a packer json és a terraform modulok generálásához.
• Égszínkék.
• Képkészítéskor használható.
• Python a kiegészítő szolgáltatásokhoz és a szkriptek kiépítéséhez.
• És mindez a VSCode-ban, a csapattagok között megosztott bővítményekkel.

Következtetés az enyémből utolsó cikk így volt: próbáltam (elsősorban magamban) optimizmust kelteni, azt akartam mondani, hogy kipróbáljuk az általunk ismert megközelítéseket, gyakorlatokat, hogy kezeljük az ezen a területen fennálló nehézségeket és bonyolultságokat.

Jelenleg a következő IaC problémákkal küzdünk:

• A kódfejlesztéshez szükséges eszközök és eszközök tökéletlenségei.
• Lassú telepítés. Az infrastruktúra a való világ része, és lassú is lehet.
• Megközelítések és gyakorlatok hiánya.
• Újak vagyunk és nem sokat tudunk.

Extrém programozás (XP) a megmentésre

Minden fejlesztő ismeri az extrém programozást (XP) és a mögötte rejlő gyakorlatokat. Sokan dolgoztunk ezzel a megközelítéssel, és ez sikeres volt. Akkor miért ne használja az ott lefektetett elveket és gyakorlatokat az infrastrukturális kihívások leküzdésére? Úgy döntöttünk, hogy ezt a megközelítést alkalmazzuk, és meglátjuk, mi történik.

Az XP megközelítés alkalmazhatóságának ellenőrzése az Ön iparágábanÍme egy leírás arról a környezetről, amelyre az XP kiválóan alkalmas, és hogyan kapcsolódik hozzánk:

1. Dinamikusan változó szoftverkövetelmények. Egyértelmű volt számunkra, hogy mi a végcél. De a részletek változhatnak. Mi magunk döntjük el, hogy hol kell taxizni, így a követelmények időszakosan változnak (főleg magunktól). Ha vesszük az SRE csapatát, amely maga végzi az automatizálást, és maga korlátozza a követelményeket és a munkakört, akkor ez a pont jól illeszkedik.

2. Új technológiát alkalmazó, fix idejű projektek által okozott kockázatok. Kockázatokba ütközhetünk, ha számunkra ismeretlen dolgokat használunk. És ez 100%-ban a mi esetünk. Az egész projektünk olyan technológiák alkalmazása volt, amelyeket nem ismertünk teljesen. Általában ez állandó probléma, mert... Az infrastrukturális szektorban folyamatosan sok új technológia jelenik meg.

3,4. Kicsi, közös helyen található kiterjesztett fejlesztőcsapat. Az Ön által használt automatizált technológia lehetővé teszi az egység- és funkcionális teszteket. Ez a két pont nem igazán illik hozzánk. Egyrészt nem vagyunk egy összehangolt csapat, másrészt kilencen vagyunk, ami egy nagy csapatnak tekinthető. Bár a „nagy” csapat egyes definíciói szerint sok a 14+ ember.

Nézzünk meg néhány XP gyakorlatot, és azt, hogy ezek hogyan befolyásolják a visszacsatolás sebességét és minőségét.

XP visszacsatolási hurok elve

Értelmezésem szerint a visszajelzés a válasz arra a kérdésre, hogy jól csinálom-e, oda megyünk? Az XP-nek erre van egy isteni sémája: egy időbeli visszacsatolási hurok. Az az érdekes, hogy minél alacsonyabban vagyunk, annál gyorsabban tudjuk elérni, hogy az operációs rendszer válaszoljon a szükséges kérdésekre.

Ez egy elég érdekes téma a megbeszéléshez, hogy a mi IT iparágunkban lehetőség van gyorsan operációs rendszert szerezni. Képzeld el, milyen fájdalmas hat hónapig csinálni egy projektet, és csak azután derül ki, hogy hiba történt a legelején. Ez megtörténik a tervezésnél és az összetett rendszerek bármilyen felépítésénél.

Az IaC esetében a visszajelzés segít nekünk. Azonnal kiigazítok a fenti diagramon: a kiadási tervnek nincs havi ciklusa, de naponta többször előfordul. Ehhez az operációs rendszer ciklushoz néhány gyakorlat kapcsolódik, amelyeket részletesebben megvizsgálunk.

Fontos: a visszajelzések megoldást jelenthetnek az összes fent említett problémára. XP gyakorlatokkal kombinálva kirángathat a kétségbeesés szakadékából.

Hogyan húzd ki magad a kétségbeesés mélységéből: három gyakorlat

Tesztek

A tesztek kétszer szerepelnek az XP visszacsatolási hurokban. Nem csak úgy. Rendkívül fontosak az egész extrém programozási technika szempontjából.

Feltételezhető, hogy rendelkezik egység- és átvételi tesztekkel. Egyesek néhány perc alatt, mások néhány napon belül visszajelzést adnak, így hosszabb ideig tart a megírásuk, és ritkábban tekintik át őket.

Létezik egy klasszikus tesztelési piramis, ami azt mutatja, hogy több tesztnek kellene lennie.

Hogyan vonatkozik ez a keretrendszer ránk egy IaC projektben? Valójában... egyáltalán nem.

• Az egységtesztek, annak ellenére, hogy soknak kell lenniük, nem lehet túl sok. Vagy nagyon közvetetten tesztelnek valamit. Valójában azt mondhatjuk, hogy egyáltalán nem írjuk őket. De itt van néhány alkalmazás az ilyen tesztekhez, amelyeket el tudtunk végezni:
  1. Jsonnet kód tesztelése. Ez például a mi drón összeszerelő csővezetékünk, ami meglehetősen bonyolult. A jsonnet kódot jól lefedik a tesztek.
     Ezt használjuk Egységtesztelési keretrendszer a Jsonnethez.
  2. Az erőforrás indításakor végrehajtott parancsfájlok tesztelése. A szkriptek Pythonban vannak írva, ezért tesztek írhatók rájuk.
• Potenciálisan lehetséges a konfiguráció ellenőrzése tesztekben, de ezt nem tesszük meg. Az erőforrás-konfigurációs szabályok ellenőrzése ezen keresztül is konfigurálható tflint. Az ottani ellenőrzések azonban egyszerűen túl egyszerűek a terraformhoz, de sok tesztszkriptet AWS-hez írnak. És az Azure-on vagyunk, így ez megint nem vonatkozik.
• Komponensintegrációs tesztek: attól függ, hogyan osztályozod és hova helyezed el. De alapvetően működnek.

  Így néznek ki az integrációs tesztek.

  
  
  Ez egy példa a Drone CI-ben történő képek készítésére. Ahhoz, hogy elérje őket, 30 percet kell várnia a Packer kép megjelenésére, majd várnia kell további 15 percet, amíg elhaladnak. De léteznek!

  Képellenőrző algoritmus

  1. A csomagolónak először teljesen elő kell készítenie a képet.
  2. A teszt mellett van egy helyi állapotú terraform, amelyet a kép telepítéséhez használunk.
  3. Kibontáskor egy közelben fekvő kis modult használnak, ami megkönnyíti a képpel való munkát.
  4. Miután a virtuális gépet a lemezképből telepítette, megkezdődhet az ellenőrzés. Az ellenőrzéseket alapvetően autóval végzik. Ellenőrzi, hogyan működtek a szkriptek az indításkor, és hogyan működnek a démonok. Ehhez ssh-n vagy winrm-en keresztül bejelentkezünk az újonnan felvett gépre és ellenőrizzük a konfiguráció állapotát, vagy hogy a szolgáltatások működnek-e.

• Hasonló a helyzet a terraform modulok integrációs tesztjeivel is. Íme egy rövid táblázat, amely elmagyarázza az ilyen tesztek jellemzőit.

  
  
  A csővezetékkel kapcsolatos visszajelzés körülbelül 40 perc. Minden nagyon sokáig megtörténik. Használható regresszióra, de új fejlesztéseknél általában irreális. Ha erre nagyon-nagyon felkészült, készítsen elő futó szkripteket, akkor lecsökkentheti 10 percre. De ezek még mindig nem Unit tesztek, amelyek 5 másodperc alatt csinálnak 100 darabot.

Az egységtesztek hiánya a képek vagy a terraform modulok összeállításakor arra ösztönzi a munkát, hogy különálló szolgáltatásokra helyezzék át a munkát, amelyek egyszerűen REST-en keresztül futtathatók, vagy Python-szkriptekre.

Például meg kellett győződnünk arról, hogy amikor a virtuális gép elindul, regisztrálja magát a szolgáltatásban ScaleFT, és amikor a virtuális gép megsemmisült, törölte magát.

Mivel a ScaleFT szolgáltatásunk van, kénytelenek vagyunk az API-n keresztül dolgozni vele. Oda volt írva egy borító, amit kihúzva azt mondhatta: "Menj be, és töröld ki ezt-azt." Minden szükséges beállítást és hozzáférést tárol.

Erre már tudunk normális teszteket írni, hiszen semmiben sem különbözik a hétköznapi szoftverektől: kigúnyolnak valami apihát, meghúzod, és meglátod, mi lesz.

A tesztek eredményei: Az egységtesztelés, amelynek egy percen belül meg kell adnia az operációs rendszert, nem adja meg. A piramisban magasabban lévő tesztelések pedig hatékonyak, de csak a problémák egy részét fedik le.

Páros programozás

A tesztek természetesen jók. Rengeteget lehet írni belőlük, különböző típusúak lehetnek. A saját szintjükön fognak dolgozni, és visszajelzést adnak nekünk. De továbbra is fennáll a probléma a rossz egységtesztekkel, amelyek a leggyorsabb operációs rendszert adják. Ugyanakkor továbbra is egy gyors operációs rendszert szeretnék, amivel könnyű és kellemes dolgozni. Nem beszélve a kapott megoldás minőségéről. Szerencsére vannak olyan technikák, amelyek még az egységteszteknél is gyorsabb visszajelzést tudnak adni. Ez páros programozás.

A kód írásakor a lehető leggyorsabban szeretne visszajelzést kapni a minőségéről. Igen, mindent beírhat egy funkció ágba (hogy ne törjön el senkinek semmit), lekérést küldhet a Githubban, hozzárendelheti valakihez, akinek a véleményének súlya van, és várni a választ.

De sokáig lehet várni. Az emberek mind elfoglaltak, és a válasz, még ha van is, nem biztos, hogy a legjobb minőségű. Tegyük fel, hogy a válasz azonnal megérkezett, a lektor azonnal megértette az egész ötletet, de a válasz még mindig későn, utólag érkezik. Bárcsak korábban lenne. Erre irányul a páros programozás – rögtön, az írás pillanatában.

Az alábbiakban bemutatjuk a páros programozási stílusokat és azok alkalmazhatóságát az IaC-n végzett munkában:

1. Klasszikus, tapasztalt+tapasztalt, váltás időzítő szerint. Két szerep – sofőr és navigátor. Két ember. Ugyanazon a kódon dolgoznak, és egy bizonyos előre meghatározott idő elteltével szerepet cserélnek.

Nézzük meg problémáink stílussal való összeegyeztethetőségét:

• Probléma: a kódfejlesztéshez szükséges eszközök és eszközök tökéletlensége.
  Negatív hatás: tovább tart a fejlődés, lelassulunk, elvész a munkatempó/ritmus.
  Hogyan küzdünk: más eszközöket, közös IDE-t használunk, és megtanuljuk a parancsikonokat is.
• Probléma: Lassú telepítés.
  Negatív hatás: megnöveli a működő kódrészlet létrehozásához szükséges időt. Várakozás közben unatkozunk, a kezünk kinyújtja a várakozást, hogy mást csináljunk.
  Hogyan küzdünk: nem győztük le.
• Probléma: megközelítések és gyakorlatok hiánya.
  Negatív hatás: nincs tudás arról, hogyan kell jól és hogyan kell rosszul csinálni. Meghosszabbítja a visszajelzések fogadását.
  Hogyan küzdünk: a vélemény- és gyakorlatok kölcsönös cseréje páros munkában szinte megoldja a problémát.

Ennek a stílusnak az IaC-ben való használatának fő problémája az egyenetlen munkatempó. A hagyományos szoftverfejlesztésben nagyon egységes a mozgás. Öt percet tölthet és írhat N. Töltsön el 10 percet, és írjon 2N, 15 perc - 3N. Itt tölthetsz öt percet és írhatsz N-t, aztán még 30 percet és írhatsz egy tizedet N-ből. Itt nem tudsz semmit, elakadtál, hülye. A vizsgálat időt vesz igénybe, és elvonja a figyelmet magáról a programozásról.

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

2. Ping-pong. Ez a megközelítés azt jelenti, hogy egy személy megírja a tesztet, egy másik pedig elvégzi a megvalósítást. Figyelembe véve azt a tényt, hogy az egységteszteknél minden bonyolult, és olyan integrációs tesztet kell írni, aminek programozása sok időt vesz igénybe, a pingpongozás minden könnyedsége megszűnik.

Elmondhatom, hogy megpróbáltuk szétválasztani a felelősséget a tesztszkript tervezése és a kód implementálása során. Az egyik résztvevő kitalálta a forgatókönyvet, ebben a munkarészben ő volt a felelős, övé volt az utolsó szó. A másik pedig a megvalósításért volt felelős. Jól sikerült. Ezzel a megközelítéssel javul a szkript minősége.

Következtetés: sajnos a munkatempó nem teszi lehetővé a ping-pong használatát páros programozási gyakorlatként az IaC-ben.

3. Erős stílus. Nehéz gyakorlat. Az ötlet az, hogy az egyik résztvevő lesz a direktíva navigátora, a másik pedig a végrehajtó szerepét tölti be. Ebben az esetben a döntési jog kizárólag a navigátort illeti meg. Az illesztőprogram csak nyomtat, és egy szóval tudja befolyásolni, hogy mi történik. A szerepek sokáig nem változnak.

Jó a tanuláshoz, de erős soft készségeket igényel. Itt akadoztunk. A technika nehéz volt. És még csak nem is az infrastruktúráról van szó.

Következtetés: potenciálisan használható, nem adjuk fel a próbálkozást.

4. Mobbing, rajzás és minden ismert, de fel nem sorolt ​​stílus Nem vesszük figyelembe, mert Nem próbáltuk ki, és lehetetlen a munkánk keretében beszélni róla.

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

• Egyenetlen a munkatempónk, ami zavaró.
• Nem elég jó soft skillekbe ütköztünk. A témakör pedig nem segít leküzdeni ezeket a hiányosságainkat.
• A hosszú tesztek és az eszközökkel kapcsolatos problémák megnehezítik a páros fejlesztést.

5. Ennek ellenére voltak sikerek. Kidolgoztuk a saját módszerünket „Konvergencia - Divergencia”. Röviden leírom, hogyan működik.

Néhány napig (kevesebb, mint egy hétig) állandó partnereink vannak. Egy feladatot végzünk együtt. Egy kicsit együtt ülünk: az egyik ír, a másik ül és nézi a támogató csapatot. Aztán szétszéledünk egy ideig, mindegyik önálló dolgot csinál, aztán újra összejövünk, nagyon gyorsan szinkronizálunk, csinálunk valamit együtt, és újra szétszóródunk.

Tervezés és kommunikáció

A gyakorlatok utolsó blokkja, amelyen keresztül az operációs rendszer problémáit megoldják, a munka megszervezése magukkal a feladatokkal. Ez magában foglalja a páros munkán kívüli tapasztalatcserét is. Nézzünk három gyakorlatot:

1. Célok a célfán keresztül. A projekt átfogó irányítását egy olyan fán keresztül szerveztük meg, amely végtelenül a jövőbe nyúlik. Technikailag a nyomkövetés Miróban történik. Egy feladat van – ez egy köztes cél. Ebből indulnak ki vagy kisebb célok, vagy feladatcsoportok. Maguk a feladatok tőlük származnak. Minden feladat létrehozása és karbantartása ezen a fórumon történik.

Ez a séma visszajelzést is ad, ami naponta egyszer fordul elő, amikor gyűléseken szinkronizálunk. A közös terv mindenki előtt, de strukturált és teljesen nyitott, lehetővé teszi, hogy mindenki tisztában legyen azzal, mi történik, és mennyit haladtunk előre.

A feladatok vizuális látásmódjának előnyei:

• Kauzalitás. Minden feladat valamilyen globális célhoz vezet. A feladatok kisebb célokba vannak csoportosítva. Maga az infrastruktúra-tartomány meglehetősen technikai jellegű. Nem mindig világos, hogy milyen konkrét hatással van az üzletre például egy runbook írása egy másik nginx-re való átállásról. Ha a célkártya a közelben van, akkor ez világosabbá válik.
  
  Az ok-okozati összefüggés a problémák fontos tulajdonsága. Közvetlenül válaszol a kérdésre: „Jól cselekszem?”
• Párhuzamosság. Kilencen vagyunk, és egyszerűen fizikailag lehetetlen mindenkit egy feladatra rábírni. Az egy területről származó feladatok sem mindig elegendőek. Kénytelenek vagyunk párhuzamosítani a munkát a kis munkacsoportok között. Ugyanakkor a csoportok egy ideig a feladatukon ülnek, valaki mással megerősítheti őket. Néha az emberek kiesnek ebből a munkacsoportból. Valaki nyaralni megy, valaki riportot készít a DevOps konf-ra, valaki cikket ír a Habrról. Nagyon fontossá válik, hogy tudjuk, milyen célokat és feladatokat lehet párhuzamosan elvégezni.

2. A délelőtti értekezletek előadóinak helyettesítése. A stand-upoknál ez a probléma – az emberek sok feladatot végeznek párhuzamosan. Néha a feladatok lazán kapcsolódnak egymáshoz, és nem értik, ki mit csinál. És nagyon fontos egy másik csapattag véleménye. Ez további információ, amely megváltoztathatja a probléma megoldásának menetét. Természetesen általában van veled valaki, de a tanácsok és tippek mindig hasznosak.

A helyzet javítására a „Changing the Leading Stand-Up” technikát alkalmaztuk. Most egy bizonyos lista szerint forgatják őket, és ennek megvan a hatása. Amikor Önre kerül a sor, kénytelen belemerülni, és megérteni, mi történik, hogy egy jó Scrum-találkozót lehessen lebonyolítani.

3. Belső bemutató. A páros programozásból, a problémafán való vizualizációból és a reggeli scrum értekezleteken nyújtott segítség a probléma megoldásában jó, de nem ideális. Párként csak a tudásotok szab határt. A feladatfa segít globálisan megérteni, hogy ki mit csinál. A délelőtti megbeszélés előadója és kollégái pedig nem fognak mélyen belemerülni a problémáidba. Biztosan kihagynak valamit.

A megoldást az elvégzett munka egymásnak bemutatásában, majd megbeszélésében találták meg. Hetente egyszer találkozunk egy órára, és bemutatjuk az elmúlt héten elvégzett feladatok megoldásainak részleteit.

A bemutató során fel kell tárni a feladat részleteit, és mindenképpen be kell mutatni a működését.

A jelentést egy ellenőrző lista segítségével lehet elkészíteni.1. Lépjen be a kontextusba. Honnan jött a feladat, miért volt egyáltalán szükség rá?

2. Hogyan oldották meg korábban a problémát? Például hatalmas egérkattintásra volt szükség, vagy egyáltalán nem lehetett semmit csinálni.

3. Hogyan javítjuk. Például: "Nézd, most van scriptosik, itt a readme."

4. Mutassa be, hogyan működik. Célszerű néhány felhasználói forgatókönyvet közvetlenül megvalósítani. X-et akarok, Y-t akarok, Y-t (vagy Z-t) látok. Például telepítem az NGINX-et, kifüstölöm az url-t, és 200 OK-t kapok. Ha a művelet hosszú, készítse elő előre, hogy később meg tudja mutatni. Javasoljuk, hogy egy órával a demó előtt ne törje meg túlságosan, ha törékeny.

5. Ismertesse, milyen sikeresen oldották meg a problémát, milyen nehézségek maradtak még, mi az, ami nem fejeződött be, milyen fejlesztések lehetségesek a jövőben. Például most CLI, akkor teljes automatizálás lesz a CI-ben.

Minden egyes hangszórónak ajánlatos 5-10 percig tartani. Ha a beszéde nyilvánvalóan fontos és tovább tart, ezt előre egyeztetje az sre-takeover csatornán.

A személyes rész után mindig van vita a szálban. Itt jelennek meg azok a visszajelzések, amelyekre szükségünk van a feladatainkkal kapcsolatban.

Ennek eredményeként felmérést végeznek a történések hasznosságának megállapítására. Ez visszajelzés a beszéd lényegéről és a feladat fontosságáról.

Hosszú következtetések és mi következik

Úgy tűnhet, hogy a cikk hangvétele kissé pesszimista. Ez rossz. A visszacsatolás két alacsonyabb szintje, nevezetesen a tesztek és a páros programozás működik. Nem olyan tökéletes, mint a hagyományos fejlesztésben, de van ennek pozitív hatása.

A tesztek jelenlegi formájukban csak részleges kódlefedettséget biztosítanak. Sok konfigurációs funkciót nem tesztelnek. Befolyásuk a tényleges munkára a kódírás során csekély. Az integrációs teszteknek azonban van hatása, és lehetővé teszik, hogy félelem nélkül hajtsanak végre refaktorálásokat. Ez nagy eredmény. Továbbá, ha a hangsúly a magas szintű nyelvek fejlesztésére helyeződik (van python, go), a probléma megszűnik. És nincs szükség sok ellenőrzésre a „ragasztóhoz”, elég egy általános integrációs ellenőrzés.

A párban végzett munka inkább konkrét személyektől függ. Ott van a feladatfaktor és a soft skilljeink. Van, akinek ez nagyon jól sikerül, másoknál rosszabbul. Ennek mindenképpen vannak előnyei. Nyilvánvaló, hogy ha a páros munka szabályait nem is tartják be kellőképpen, a közös feladatok elvégzésének ténye pozitív hatással van az eredmény minőségére. Személy szerint könnyebbnek és élvezetesebbnek találom a párban való munkát.

Az operációs rendszer befolyásolásának magasabb szintű módjai - a feladatok pontos tervezése és munkavégzése hatásokat eredményez: magas színvonalú tudáscsere és jobb fejlesztési minőség.

Rövid következtetések egy sorban

• A HR-szakemberek az IaC-ben dolgoznak, de kisebb hatékonysággal.
• Erősítsd meg azt, ami működik.
• Találja ki saját kompenzációs mechanizmusait és gyakorlatait.

Forrás: will.com