🥇Infrastructure as Code: ako prekonať problémy s pomocou XP

Ahoj, Habr! Predtým som sa sťažoval na život v paradigme Infrastructure as code a nič som nenavrhoval na vyriešenie situácie. Dnes som sa vrátil, aby som povedal, aké prístupy a praktiky pomôžu uniknúť z hlbín beznádeje a nasmerovať situáciu správnym smerom.

V predchádzajúcom článku „Infrastructure as code: prvé zoznámenie“ Zdieľal som svoje dojmy z tejto oblasti, snažil som sa zamyslieť nad aktuálnou situáciou a dokonca som naznačil, že štandardné, všetkým známé praktiky vývojárov môžu pomôcť. Môže sa zdať, že tam bolo veľa sťažností na život, ale neboli tam žiadne návrhy, ako sa z tejto situácie dostať.

Kto sme, kde sme a aké máme problémy

Momentálne sme v Sre Onboarding Tíme, ktorý pozostáva z šiestich programátorov a troch infraštruktúrnych inžinierov. Všetci sa snažíme písať Infrastructure as code (IaC). Robíme to, pretože vo všeobecnosti vieme písať kód a v anamnéze sme vývojári na úrovni „nadpriemerní“.

Máme niekoľko výhod: určitý background, znalosť praktík, schopnosť písať kód, túžbu učiť sa nové veci.
A máme aj slabú stránku, a to nedostatok znalostí v oblasti infraštruktúry.

Technologický stack, ktorý používame v našom IaC.

Terraform na vytváranie zdrojov.
Packer na zostavovanie imidžov. To sú imidže Windows a CentOS 7.
Jsonnet na silnú zostavu v drone.io, ako aj na generovanie packer json a našich terraform modulov.
Azure.
Ansible pri príprave imidžov.
Python na pomocné služby, ako aj na provisioning skripty.
A to všetko vo VSCode s pluginmi zdieľanými medzi členmi tímu.

Môj záver bol taký: snažil som sa vnuknúť (predovšetkým sebe) optimizmus, chcel som povedať, že budeme skúšať známe prístupy a praktiky na boj s ťažkosťami a problémami, ktoré existujú v tejto oblasti. predchádzajúceho článku Teraz bojujeme s takými problémami IaC:

Nedokonalosť nástrojov a prostriedkov na vývoj kódu.

Pomalé nasadzovanie. Infraštruktúra je časťou reálneho sveta a ten môže byť pomalý.
Nedostatok prístupov a praktík.
Sme nováčikovia a veľa toho nevieme.
Extrémne programovanie (XP) prichádza na pomoc.

Extrémne programovanie (XP) prichádza na pomoc.

Všetkým vývojárom je dobre známe extrémne programovanie (XP) a zásady, ktoré za ním stoja. Mnohí z nás pracovali podľa takéhoto prístupu a boli s ním úspešní. Tak prečo nevyužiť princípy a praktiky, ktoré tam sú, na prekonanie ťažkostí infraštruktúry? Rozhodli sme sa aplikovať tento prístup a pozrieť sa, čo z toho vznikne.

Overenie aplikovateľnosti prístupu XP vo vašej oblastiUvádzam popis prostredia, pre ktoré je XP dobre vhodné, a ako to súvisí s nami:

1. Dynamicky sa meniacie softvérové požiadavky. Bolo nám jasné, aký je konečný cieľ. Ale v detailoch môžeme variabilne upravovať. My sami rozhodujeme, ktorým smerom sa máme vydať, preto sa požiadavky periodicky menia (väčšinou z našich vlastných dôvodov). Ak vezmeme tím SRE, ktorý sám vykonáva automatizáciu a zároveň obmedzuje požiadavky a rozsah prác, potom tento bod nám vyhovuje.

2. Riziká spôsobené fixným časom projektov s novou technológiou. Môžu sa nám objaviť riziká pri používaní neznámych technológií. A to je 100% náš prípad. celý náš projekt sa zakladá na technológiách, s ktorými sme neboli úplne oboznámení. V skutočnosti je to neustály problém, pretože v oblasti infraštruktúry sa neustále objavujú mnohé nové technológie.

3,4. Malý, spolu umiestnený rozšírený vývojový tím. Technológia, ktorú používate, umožňuje automatizované jednotkové a funkčné testy. Tieto dva body nám úplne nevyhovujú. Po prvé, nie sme ko-lokovaný tím, po druhé, má nás deväť, čo môže byť považované za veľký tím. Aj keď, podľa niektorých definícií „veľkého“ tímu, množstvo znamená 14+ ľudí.

Zvážime niektoré praktiky z XP a to, ako ovplyvňujú rýchlosť a kvalitu spätnej väzby.

Princíp cyklu spätnej väzby v XP

Podľa môjho chápania je spätná väzba odpoveďou na otázku, či robím správne, či ideme tým správnym smerom? V XP je na to božská schéma: cyklus spätnej väzby v čase. Zaujímavosťou je, že čím nižšie sa nachádzame, tým rýchlejšie môžeme získať OS, aby sme odpovedali na potrebné otázky.

Toto je pomerne zaujímavá téma na diskusiu, že v našej IT oblasti je možné rýchlo získať OS. Predstavte si, aké bolestivé môže byť pracovať na nejakom projekte pol roka a až potom zistiť, že na začiatku bola zakorenená chyba. To sa stáva ako pri projektovaní, tak aj pri akomkoľvek budovaní zložitých systémov.

V našom prípade nám IaC pomáha spätná väzba. Okamžite uvádzam malé opravy do vyššie uvedenej schémy: vydanie plánu nemáme mesačný cyklus, ale prebieha niekoľkokrát denne. K tomuto cyklu sú viazané niektoré praktiky, ktoré si podrobnejšie preberieme.

Dôležité: spätná väzba môže byť riešením všetkých vyššie uvedených problémov. V kombinácii s praktikami XP môže vytiahnuť z hlbokej beznádeje.

Ako sa dostať z hlbokej beznádeje: tri praktiky

Testy

Testy sú v cykle spätnej väzby XP zmienené dvakrát. Nie je to len tak. Sú extrémne dôležité pre celú techniku extrémneho programovania.

Predpokladá sa, že máte jednotkové a akceptačné testy. Jedny vám poskytujú spätnú väzbu za niekoľko minút, druhé za niekoľko dní, pretože sa píšu dlhšie a spúšťajú sa menej často.

Existuje klasická pyramída testovania, ktorá ukazuje, že nejakých testov by malo byť viac.

Ako je táto schéma uplatniteľná v našom projekte IaC? V skutočnosti… nijako.

Jednotkových testov, aj keď ich má byť veľmi veľa, nemôže byť veľmi veľa. Alebo testujú veľmi nepriamo niečo. V podstate môžeme povedať, že ich vlastne vôbec nepíšeme. Ale tu je niekoľko využití takýchto testov, ktoré sme predsa len dokázali spraviť:
1. Testovanie kódu na jsonnet. To je napríklad náš pipeline na zostavenie v drone, ktorý je dosť zložitý. Kód na jsonnet je dobre pokrytý testami.
  Používame tento Unit testing framework for Jsonnet.
2. Testy na skripty, ktoré sa vykonávajú pri spustení zdroja. Skripty sú na Pythone, takže aj testy na ne je možné písať.
Potenciálne je možná kontrola konfigurácie v testoch, ale my to tak nerobíme. Ešte existuje možnosť nastaviť kontrolu pravidiel konfigurácie zdrojov cez tflint. Avšak, pre terraform sú tam príliš základné kontroly, no pre AWS je napísaných veľa kontrolných scénarov. A my sme na Azure, takže to znovu nevyhovuje.
Komponentné integračné testy: tu závisí od toho, ako ich klasifikujete a kam ich zaradíte. Ale v princípe fungujú.
Takto vyzerajú integračné testy.

Toto je príklad pri zostavovaní obrazov v Drone CI. Aby sme sa k nim dostali, musíme čakať 30 minút, kým sa zmontuje imidž Packer, a potom ďalších 15 minút, kým prejdú. Ale sú tu!
Algoritmus kontroly obrazov
1. Najprv musí Packer úplne pripraviť obraz.
2. Vedľa testu je terrafフォーム s lokálnym stavom, pomocou ktorého rozbaľujeme tento obraz.
3. Pri rozbaľovaní sa používa malý modul umiestnený vedľa, aby sa s obrazom dalo ľahšie pracovať.
4. Keď je z obrazu rozbalená VM, môžeme začať kontroly. Hlavne sa kontroly vykonávajú na stroji. Overuje sa, ako fungovali skripty pri štarte, ako pracujú démoni. Na tento účel sa cez ssh alebo winrm prihlásime na práve spustený stroj a skontrolujeme stav konfigurácie alebo či sa služby spustili.
Podobná situácia je s integračnými testami a modulmi pre terraform. Tu je krátka tabuľka, ktorá vysvetľuje špecifiká takýchto testov.

Spätná väzba na pipeline je okolo 40 minút. Všetko prebieha veľmi pomaly. Môže sa použiť pre regresiu, ale pre novú vývoj je to úplne nerealizovateľné. Ak sa na to naozaj pripraviť, pripraviť running, skripty, môže sa to skrátiť na 10 minút. Ale aj tak to nie sú Unit testy, ktoré sa dajú spustiť 100 za 5 sekúnd.

Nedostatok Unit testov pri zostavovaní obrazov alebo modulov terraformu núti prenášať prácu na samostatné služby, ktoré sa dajú jednoducho zavolať cez REST, alebo na Python skripty.

Napríklad, potrebovali sme to tak, aby pri štarte virtuálneho stroja sa zaregistroval v službe ScaleFT, a pri zničení virtuálky sa odstránil.

Keďže ScaleFT máme ako službu, sme nútení s ním pracovať cez API. Napísali sme obálku, ktorú sa dá zavolať a povedať: „Pridaj sa a odstráň to a to“. Uchováva všetky potrebné nastavenia a prístupy.

Na toto už môžeme písať normálne testy, pretože to sa nijako nelíši od bežného softvéru: mockne sa nejaké API, zavoláš ho a sleduješ, čo sa deje.

Závery z testov: Unit testovanie, ktoré by malo byť poskytované OS za minútu, ho neposkytuje. A vyššie úrovne testovania v pyramíde dávajú výsledok, ale pokrývajú len časť problémov.

Párové programovanie

Testy sú určite dobré. Môže ich byť veľa rôznych typov. Budú fungovať na svojich úrovniach a poskytovať nám spätnú väzbu. Problém však zostáva s nekvalitnými Unit testami, ktoré zabezpečujú najrýchlejší OS. Zároveň však túžime po rýchlom OS, s ktorým je ľahké a príjemné pracovať. Nehovoriac o kvalite vyriešeného problému. Našťastie existujú techniky, ktoré dokážu poskytnúť ešte rýchlejšiu spätnú väzbu ako modulové testy. To je párové programovanie.

Pri písaní kódu túžime získať spätnú väzbu o jeho kvalite čo najrýchlejšie. Áno, všetko sa dá napísať vo funkčnej vetve (aby sme nikomu nič neporušili), spraviť pull request na GitHube, priradiť ho niekomu, koho názor má váhu, a čakať na odpoveď.

Ale čakať sa môže dlho. Ľudia sú zaneprázdnení a odpoveď, aj keď príde, môže byť nie vždy kvalitná. Predpokladajme, že odpoveď prišla okamžite, recenzent okamžite pochopil celú myšlienku, no odpoveď aj tak prichádza so oneskorením, spätne. A chceme ju skôr. Tu práve párové programovanie mieri na to – aby sme hneď, v momente písania, dostali spätnú väzbu.

Ďalej uvádzam štýly párového programovania a ich použiteľnosť pri práci na IaC:

1. Klasický, Skúsený + skúsený, zmena podľa časovača. Dve úlohy – driver a navigator. Dvaja ľudia. Pracujú na jednom kóde a menia si úlohy po určitom predtým dohodnutom čase.

Zvážime zlučiteľnosť našich problémov so štýlom:

Problém: nedokonalosť nástrojov, prostriedkov na vývoj kódu.
Negatívny vplyv: dlhšie vyvíjanie, spomaľujeme sa, stráca sa tempo/rytmus práce.
Ako bojujeme: používame iné nástroje, spoločné IDE a učíme skratky.
Problém: pomalé nasadenie.
Negatívny vplyv: zvyšuje čas na vytvorenie funkčného kódu. Nudí nás to počas čakania, ruky sa natiahnu robiť niečo iné, kým čakáme.
Ako bojujeme: to sme nezvládli.
Problém: nedostatok prístupov a praktik.
Negatívny vplyv: nie je vedomosť, ako to robiť dobre a ako zle. Predlžuje získanie spätnej väzby.
Ako bojujeme: vzájomná výmena názorov a praktík pri párovom programovaní takmer vyrieši problém.

Hlavným problémom pri uplatňovaní tohto štýlu v IaC je nerovnomerné tempo práce. V tradičnom vývoji softvéru máš veľmi vyrovnaný postup. Môžeš stráviť päť minút a napísať N. Môžeš stráviť 10 minút a napísať 2N, 15 minút – 3N. Tu však môžeš stráviť päť minút a napísať N, a potom stráviť ďalších 30 minút a napísať desatinu N. Tu nič nevieš, máš zátku, stagnáciu. Pre pochopenie to trvá čas a odvádza to od samotného programovania.

Záver: v čistom zmysle nám to nevyhovuje.

2. Ping-pong. Tento prístup predpokladá, že jeden účastník píše test a druhý robí jeho implementáciu. Vzhľadom na to, že s unit testami je to zložité, a musíme písať dlhý integračný test, celá ľahkosť ping-pongu sa vytráca.

Môžem povedať, že sme skúšali rozdelenie povinností pri návrhu testovacieho scenára a implementácii kódu pod ním. Jeden účastník navrhoval scenár, v tejto časti práce bol zodpovedný, mal posledné slovo. A druhý bol zodpovedný za implementáciu. Vyšlo to dobre. Kvalita scenára sa pri takomto prístupe zvyšuje.

Záver: žiaľ, tempo práce neumožňuje používať ping-pong ako praktiku párového programovania v IaC.

3. Strong Style. Zložitá prax.. Myšlienka spočíva v tom, že jeden účastník sa stáva directive navigátorom, zatiaľ čo druhý preberá úlohu vykonávacieho vodiča. Právo rozhodovania zostáva výlučne na navigátorovi. Vodič iba píše a slovom môže ovplyvniť prebiehajúce veci. Úlohy sa nemenia dlhú dobu.

Dobre sa hodí na školenie, ale vyžaduje silné soft skills. Na tom sme sa zasekli. Technika prebiehala ťažko. A tu nejde ani tak o infraštruktúru.

Záver: potenciálne môže byť aplikovaná, nevzdávame sa pokusov.

4. Mobbing, swarming a všetky známe, ale tu nevypísané štýly nerozvažujeme, pretože sme ich neskúšali a nemôžeme o tom hovoriť v kontexte našej práce.

Hlavné zhrnutia o používaní párového programovania:

Máme nepravidelné tempo práce, ktoré nás zneisťuje.

Narazili sme na nedostatočne dobré soft skills. A odborná oblasť nepomáha prekonať tieto nedostatky.

Dlhé testy, problémy s nástrojmi robia párový vývoj ťažkopádnym.

5. Napriek tomu sme mali úspechy. Vymysleli sme vlastnú metódu „Zlučovanie - rozdeľovanie“. Stručne opíšem, ako to funguje.

Máme stálych partnerov na niekoľko dní (menej ako týždeň). Robíme spolu jednu úlohu. Niekedy sedíme spolu: jeden píše, druhý sedí a sleduje, ako pracuje podpora. Potom sa na nejaký čas rozdelíme, každý robí nejaké nezávislé veci, potom sa opäť spoja, veľmi rýchlo sa synchronizujeme, robíme niečo spolu a opäť sa rozdelíme.

Plánovanie a komunikácia

Posledný blok praktík, prostredníctvom ktorých sa riešia problémy OS, sa týka organizácie prác so samotnými úlohami. Sem patrí aj výmena skúseností, ktorá prebieha mimo partnerskej práce. Pozrime sa na tri praktiky:

1. Úlohy prostredníctvom cieľového stromu. Celkové riadenie projektu sme zorganizovali prostredníctvom stromu, ktorý nekonečne smeruje do budúcnosti. Technicky sa riadenie vykonáva v Miro. Existuje jedna úloha – tá je medzicíľom. Odtiaľ vychádzajú buď menšie ciele, alebo skupiny úloh. Od nich už nasledujú samotné úlohy. Všetky úlohy sú vytvorené a vedené na tejto nástenke.

Táto schéma tiež poskytuje spätnú väzbu, ktorá prebieha raz denne, keď sa synchronizujeme na stretnutiach. Mať pred všetkými spoločný plán, ktorý je pritom štruktúrovaný a úplne otvorený, umožňuje každému byť informovaným o tom, čo sa deje a ako ďaleko sme pokročili.

Výhody vizuálneho vnímania úloh:

Príčinnosť. Každá úloha vedie k nejakej globálnej cieľovej. Úlohy sa skupinujú podľa menších cieľov. Doména infraštruktúry je sama o sebe dosť technická. Niekedy nie je hneď jasné, aký konkrétny dopad na biznis má, napríklad, písanie príručky o migrácii na iný nginx. Mať vedľa cieľovú kartu to urobí jasnejším.

Príčinnosť je dôležitou vlastnosťou úloh. Priamo odpovedá na otázku: „Robím to správne?“
Paralelita. Sme deväť, a nie je fyzicky možné, aby sa všetci sústredili na jednu úlohu. Niekedy nestačí ani úloh z jednej oblasti. Pracujeme nútene na paralelných úlohách v malých pracovných skupinách. Tieto skupiny sa určitý čas zaoberajú svojou úlohou a môžu byť posilnené niekým iným. Od tejto pracovnej skupiny občas niekto odíde. Niekto ide na dovolenku, niekto pripravuje prezentáciu na konferenciu DevOps conf, niekto píše článok na Habr. Vedieť, aké ciele a úlohy môžu byť vykonávané paralelne, sa stáva veľmi dôležité.

2. Zmeny vedúcich ranných stretnutí. Na stand-upoch vznikol taký problém – veľa úloh sa robí paralelne. Niekedy sú úlohy slabo prepojené a nie je jasné, kto čo robí. A názor ďalšieho člena tímu je veľmi dôležitý. Je to dodatočná informácia, ktorá môže zmeniť priebeh riešenia úlohy. Samozrejme, zvyčajne je s tebou vo dvojici niekto, ale konzultácie a rady sú vždy vítané.

Aby sme zlepšili túto situáciu, zaviedli sme techniku „zmena vedúceho stand-upu“. Teraz sa rotujú podľa určitého zoznamu a to má svoj efekt. Keď príde tvoja rada, musíš sa ponoriť do toho, čo sa deje, aby si dobre viedol scrummit.

3. Interné demo. Pomoc pri riešení úloh párovým programovaním, vizualizácia na strome úloh a pomoc na scrummitoch ráno – to je dobré, ale nie ideálne. V páre ste obmedzení iba svojimi znalosťami. Stroma úloh pomáha globálne pochopiť, kto a čo robí. A vedúci a kolegovia na rannej porade sa nebudú hlboko zaoberať tvojimi problémami. Určite môžu niečo aj prehliadnuť.

Riešenie bolo nájdené v demonštrácii vykonaných prác navzájom a následnej diskusii o nich. Zbierame sa raz za týždeň na hodinu a ukazujeme detaily riešení úloh, ktoré sme robili za posledný týždeň.

V procese demonštrácie je potrebné odhaliť detaily úlohy a určite ju predviesť v akcii.

Prezentáciu je možné viesť podľa kontrolného zoznamu.1. Vložte do kontextu. Odkiaľ úloha vznikla, prečo to vlastne bolo potrebné?

2. Ako sa úloha riešila predtým? Napríklad, bolo potrebné masové kliknutie myšou, alebo bolo vôbec nemožné niečo urobiť.

3. Ako to zlepšujeme. Napríklad: „Pozrite, teraz je tu skriptik, tu je readme.“

4. Ukážte, ako to funguje. Odporúčame priamo vykonať nejaký používateľský scenár. Chcem X, robím Y, vidím Z (alebo iné). Napríklad, nasadzujem NGINX, kontrolujem URL, dostávam 200 OK. Ak je akcia dlhá, pripravte to vopred, aby ste to mohli ukázať. Odporúčame už hodinu pred demo nepokazovať, ak je to krehké.

5. Vysvetlite, akým spôsobom bola problém vyriešený, aké prekážky zostali, čo nie je dokončené, aké vylepšenia sú možné v budúcnosti. Napríklad, teraz je to cli, neskôr bude úplná automatizácia v CI.

Odporúčame, aby sa každý spíker zmestil do 5-10 minút. Ak je váš príspevok evidentne dôležitý a zaberie viac času, dohodnite to vopred v kanáli sre-takeover.

Po prezentácii nasleduje diskusia v threde. Tu sa objavuje spätná väzba na naše úlohy.

Na konci sa vykoná prieskum na zistenie užitočnosti prebiehajúceho. To už je spätná väzba na podstatu prezentácie a dôležitosť úlohy.

Dlhé závery a čo ďalej

Môže sa zdať, že tón článku je trochu pesimistický. Nie je to tak. Dva nižšie úrovne získavania spätnej väzby, konkrétne testy a párové programovanie, fungujú. Nie tak dokonale ako v tradičnom vývoji, ale pozitívny efekt z toho je.

Testy, v aktuálnej podobe, poskytujú len čiastočné pokrytie kódu. Mnoho konfigurácií ostáva netestovaných. Ich vplyv na bezprostrednú prácu pri písaní kódu je nízky. Avšak efekt z integračných testov existuje, a práve tie umožňujú bez obáv robiť refaktoringy. To je veľký úspech. S presunom zamerania na vývoj v high-level jazykoch (u nás python, go) problém zmizne. A na "lepidlo" je mnoho kontrol a nie sú potrebné, stačí všeobecná integrácia.

Práca v páre sa viac závisí od konkrétnych ľudí. Existuje faktor úlohy a naše softvérové zručnosti. S niekým to ide veľmi dobre, s niekým horšie. Určite z toho vyplýva nejaký prínos. Jasné je, že aj pri nedostatočnom dodržiavaní pravidiel párovej práce má samotná skutočnosť spolupráce pozitívny vplyv na kvalitu výsledku. Osobne sa mi robí v páre jednoduchšie a príjemnejšie.

Vyššie úrovne vplyvu na OS – plánovanie a práca s úlohami určite prinášajú efekty: kvalitná výmena vedomostí a zlepšenie kvality vývoja.