Ahoj Habr! Predtým som sa sťažoval na život v Infraštruktúre ako na kódovú paradigmu a neponúkol som nič na riešenie súčasnej situácie. Dnes som späť, aby som vám povedal, aké prístupy a postupy vám pomôžu uniknúť z priepasti zúfalstva a nasmerovať situáciu správnym smerom.
V predchádzajúcom článku Podelil som sa o svoje dojmy z tejto oblasti, snažil som sa zamyslieť nad aktuálnou situáciou v tejto oblasti a dokonca som naznačil, že by mohli pomôcť štandardné postupy známe všetkým vývojárom. Mohlo by sa zdať, že sťažností na život bolo veľa, no chýbali návrhy na východisko zo súčasnej situácie.
Kto sme, kde sme a aké máme problémy
Momentálne sme v tíme Sre Onboarding Team, ktorý pozostáva zo šiestich programátorov a troch inžinierov infraštruktúry. Všetci sa snažíme napísať infraštruktúru ako kód (IaC). Robíme to preto, lebo v podstate vieme, ako písať kód a máme históriu „nadpriemerných“ vývojárov.
- Máme súbor výhod: určité zázemie, znalosť postupov, schopnosť písať kód, chuť učiť sa nové veci.
- A je tu klesajúca časť, ktorá je tiež mínus: nedostatok vedomostí o hardvéri infraštruktúry.
Technologický balík, ktorý používame v našom IaC.
- Terraform na vytváranie zdrojov.
- Packer na skladanie obrázkov. Toto sú obrázky Windows, CentOS 7.
- Jsonnet na vytvorenie výkonnej zostavy v drone.io, ako aj na generovanie packer json a našich terraform modulov.
- Azure.
- Povolené pri príprave obrázkov.
- Python pre pomocné služby a skripty na poskytovanie.
- A to všetko vo VSCode s pluginmi zdieľanými medzi členmi tímu.
Záver z môjho bol takýto: Snažil som sa vniesť (predovšetkým do seba) optimizmus, chcel som povedať, že skúsime nám známe prístupy a praktiky, aby sme sa vysporiadali s ťažkosťami a zložitosťami, ktoré v tejto oblasti existujú.
Momentálne zápasíme s nasledujúcimi problémami IaC:
- Nedokonalosť nástrojov a prostriedkov na vývoj kódu.
- Pomalé nasadenie. Infraštruktúra je súčasťou skutočného sveta a môže byť pomalá.
- Nedostatok prístupov a praktík.
- Sme noví a veľa toho nevieme.
Extreme Programming (XP) na záchranu
Všetci vývojári poznajú extrémne programovanie (XP) a praktiky, ktoré za ním stoja. Mnohí z nás s týmto prístupom pracovali a bol úspešný. Prečo teda nevyužiť tam stanovené princípy a postupy na prekonanie problémov v oblasti infraštruktúry? Rozhodli sme sa použiť tento prístup a uvidíme, čo sa stane.
Kontrola použiteľnosti prístupu XP vo vašom odvetvíTu je popis prostredia, pre ktoré je XP vhodný, a ako s nami súvisí:
1. Dynamicky sa meniace softvérové požiadavky. Bolo nám jasné, aký je konečný cieľ. Ale detaily sa môžu líšiť. Sami rozhodujeme o tom, kde potrebujeme taxík, takže požiadavky sa pravidelne menia (hlavne sami). Ak si zoberieme tím SRE, ktorý robí samotnú automatizáciu a sám obmedzuje požiadavky a rozsah práce, tak tento bod sedí dobre.
2. Riziká spôsobené projektmi na pevný čas s použitím novej technológie. Pri používaní niektorých pre nás neznámych vecí sa môžeme stretnúť s rizikami. A toto je 100% náš prípad. Celý náš projekt spočíval v použití technológií, s ktorými sme neboli úplne oboznámení. Vo všeobecnosti je to neustály problém, pretože... V sektore infraštruktúry sa neustále objavuje množstvo nových technológií.
3,4. Malý, spoločne umiestnený rozšírený vývojový tím. Automatizovaná technológia, ktorú používate, umožňuje jednotkové a funkčné testy. Tieto dva body nám celkom nesedia. Po prvé nie sme zohratý tím a po druhé je nás deväť, čo sa dá považovať za veľký tím. Aj keď podľa niektorých definícií „veľkého“ tímu je veľa 14+ ľudí.
Pozrime sa na niektoré postupy XP a ako ovplyvňujú rýchlosť a kvalitu spätnej väzby.
Princíp spätnej väzby XP
V mojom ponímaní je spätná väzba odpoveďou na otázku, či robím správnu vec, ideme tam? XP má na to božskú schému: slučku časovej spätnej väzby. Zaujímavosťou je, že čím sme nižšie, tým rýchlejšie dokážeme prinútiť OS odpovedať na potrebné otázky.
Toto je dosť zaujímavá téma na diskusiu, že v našom IT priemysle je možné rýchlo získať OS. Predstavte si, aké bolestivé je robiť projekt šesť mesiacov a až potom zistiť, že hneď na začiatku bola chyba. To sa deje pri navrhovaní a pri akejkoľvek konštrukcii zložitých systémov.
V našom prípade IaC nám pomáha spätná väzba. Okamžite vykonám malú úpravu vyššie uvedeného diagramu: plán vydania nemá mesačný cyklus, ale vyskytuje sa niekoľkokrát denne. S týmto cyklom operačného systému sú spojené niektoré postupy, na ktoré sa pozrieme podrobnejšie.
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 XP praktikami vás môže vytiahnuť z priepasti zúfalstva.
Ako sa dostať z priepasti zúfalstva: tri praktiky
skúšky
Testy sa spomínajú dvakrát v slučke spätnej väzby XP. Nie je to len tak. Sú mimoriadne dôležité pre celú techniku extrémneho programovania.
Predpokladá sa, že máte testy Unit a Acceptance. Niektoré vám dajú spätnú väzbu za pár minút, iné za pár dní, takže ich písanie trvá dlhšie a sú menej často kontrolované.
Existuje klasická testovacia pyramída, ktorá ukazuje, že testov by malo byť viac.
Ako sa tento rámec vzťahuje na nás v projekte IaC? Vlastne... vôbec nie.
- Unit testov, napriek tomu, že by ich malo byť veľa, nemôže byť príliš veľa. Alebo niečo veľmi nepriamo testujú. V podstate sa dá povedať, že ich vôbec nepíšeme. Ale tu je niekoľko aplikácií pre takéto testy, ktoré sme mohli urobiť:
- Testovanie kódu jsonnet. Ide napríklad o naše potrubie na montáž dronov, ktoré je dosť komplikované. Kód jsonnet je dobre pokrytý testami.
Používame toto . - Testuje skripty, ktoré sa spustia pri spustení prostriedku. Skripty sú napísané v Pythone, a preto sa na nich dajú písať testy.
- Testovanie kódu jsonnet. Ide napríklad o naše potrubie na montáž dronov, ktoré je dosť komplikované. Kód jsonnet je dobre pokrytý testami.
- Potenciálne je možné skontrolovať konfiguráciu v testoch, ale my to nerobíme. Je tiež možné nakonfigurovať kontrolu pravidiel konfigurácie zdrojov cez . Kontroly sú však jednoducho príliš základné pre Terraform, ale veľa testovacích skriptov je napísaných pre AWS. A sme na Azure, takže toto opäť neplatí.
- Testy integrácie komponentov: záleží na tom, ako ich klasifikujete a kam ich umiestnite. Ale v podstate fungujú.
Takto vyzerajú integračné testy.
Toto je príklad pri vytváraní obrázkov v Drone CI. Aby ste sa k nim dostali, musíte počkať 30 minút, kým sa vytvorí obrázok Packer, a potom počkať ďalších 15 minút, kým prejdú. Ale existujú!Algoritmus overenia obrázkov
- Packer musí najprv úplne pripraviť obrázok.
- Vedľa testu je terraform s lokálnym stavom, ktorý používame na nasadenie tohto obrázku.
- Pri rozkladaní sa na uľahčenie práce s obrázkom používa malý modul ležiaci v blízkosti.
- Po nasadení virtuálneho počítača z obrazu sa môžu začať kontroly. Kontroly sa v zásade vykonávajú autom. Kontroluje, ako skripty fungovali pri spustení a ako fungujú démoni. Aby sme to urobili, cez ssh alebo winrm sa prihlásime do novovytvoreného počítača a skontrolujeme stav konfigurácie alebo či sú služby zapnuté.
- Podobne je to aj s integračnými testami v moduloch pre terraform. Tu je krátka tabuľka vysvetľujúca vlastnosti takýchto testov.
Spätná väzba na potrubí je približne 40 minút. Všetko sa deje veľmi dlho. Dá sa použiť na regresiu, ale pre nový vývoj je to vo všeobecnosti nereálne. Ak ste na to veľmi, veľmi pripravení, pripravte si spustené skripty, potom to môžete skrátiť na 10 minút. Ale stále to nie sú Unit testy, ktoré spravia 5 kusov za 100 sekúnd.
Absencia Unit testov pri zostavovaní obrázkov alebo terraform modulov podporuje presun práce na samostatné služby, ktoré možno jednoducho spustiť cez REST, alebo na skripty Pythonu.
Potrebovali sme sa napríklad uistiť, že keď sa virtuálny stroj spustí, sám sa zaregistruje v službe a keď bol virtuálny stroj zničený, vymazal sa sám.
Keďže máme ScaleFT ako službu, sme nútení s ňou pracovať cez API. Bol tam napísaný obal, ktorý ste mohli vytiahnuť a povedať: „Choď dnu a vymaž toto a tamto“. Ukladá všetky potrebné nastavenia a prístupy.
Na to už môžeme napísať normálne testy, keďže sa to nijako nelíši od bežného softvéru: nejaký druh apiha sa vysmieva, vytiahnete ho a uvidíte, čo sa stane.
Výsledky testov: Unit testing, ktorý by mal dať OS za minútu, to nedáva. A typy testovania vyššie v pyramíde sú účinné, ale pokrývajú len časť problémov.
Párové programovanie
Testy sú samozrejme dobré. Môžete ich napísať veľa, môžu byť rôzneho typu. Budú pracovať na svojich úrovniach a poskytnú nám spätnú väzbu. Ale problém so zlými testami jednotiek, ktoré poskytujú najrýchlejší OS, zostáva. Zároveň stále chcem rýchly OS, s ktorým sa ľahko a príjemne pracuje. Nehovoriac o kvalite výsledného riešenia. Našťastie existujú techniky, ktoré dokážu poskytnúť ešte rýchlejšiu spätnú väzbu ako jednotkové testy. Toto je párové programovanie.
Pri písaní kódu chcete čo najrýchlejšie získať spätnú väzbu o jeho kvalite. Áno, všetko si môžete napísať do feature branche (aby ste nikomu nič nepokazili), spraviť pull request v Githube, priradiť to niekomu, koho názor má váhu a čakať na odpoveď.
Môžete však čakať dlho. Všetci ľudia sú zaneprázdnení a odpoveď, aj keď existuje, nemusí byť práve najkvalitnejšia. Predpokladajme, že odpoveď prišla okamžite, recenzent okamžite pochopil celú myšlienku, ale odpoveď stále prichádza neskoro, potom. Bodaj by to bolo skôr. Na to je zamerané párové programovanie – hneď, v čase písania.
Nižšie sú uvedené párové programovacie štýly a ich použiteľnosť pri práci na IaC:
1. Klasický, Skúsený+Skúsený, posun podľa časovača. Dve úlohy – vodič a navigátor. Dvaja ľudia. Pracujú na rovnakom kóde a po určitom vopred určenom čase si vymenia úlohy.
Uvažujme o kompatibilite našich problémov so štýlom:
- Problém: nedokonalosť nástrojov a nástrojov na vývoj kódu.
Negatívny dopad: dlhšie sa rozvíja, spomaľujeme, stráca sa tempo/rytmus práce.
Ako bojujeme: používame iné nástroje, spoločné IDE a tiež sa učíme skratky. - Problém: Pomalé nasadenie.
Negatívny vplyv: zvyšuje čas potrebný na vytvorenie pracovného kódu. Počas čakania sa nudíme, ruky sa naťahujú, aby sme počas čakania urobili niečo iné.
Ako bojujeme: neprekonali sme to. - Problém: nedostatok prístupov a praktík.
Negatívny vplyv: neexistujú žiadne znalosti o tom, ako to urobiť dobre a ako to urobiť zle. Predlžuje príjem spätnej väzby.
Ako bojujeme: vzájomná výmena názorov a praktík v párovej práci takmer rieši problém.
Hlavným problémom používania tohto štýlu v IaC je nerovnomerné tempo práce. Pri tradičnom vývoji softvéru máte veľmi jednotný pohyb. Môžete stráviť päť minút a napísať N. Stráviť 10 minút a napísať 2N, 15 minút - 3N. Tu môžete 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č neviete, ste zaseknutý, hlúpy. Vyšetrovanie si vyžaduje čas a odvádza pozornosť od samotného programovania.
Záver: vo svojej čistej forme nie je pre nás vhodný.
2. Ping-pong. Tento prístup spočíva v tom, že jedna osoba napíše test a druhá vykoná jeho implementáciu. Ak vezmeme do úvahy skutočnosť, že s Unit testami je všetko komplikované a musíte napísať integračný test, ktorého programovanie trvá dlho, všetka ľahkosť ping-pongu zmizne.
Môžem povedať, že sme sa pokúsili oddeliť zodpovednosti za návrh testovacieho skriptu a implementáciu kódu preň. Jeden účastník vymyslel scenár, v tejto časti práce bol zodpovedný, mal posledné slovo. A druhý bol zodpovedný za realizáciu. Dobre to dopadlo. Kvalita scenára sa týmto prístupom zvyšuje.
Záver: žiaľ, tempo práce neumožňuje použitie ping-pongu ako párového programovania v IaC.
3. Silný štýl. . Ide o to, že jeden účastník sa stane navigátorom direktív a druhý prevezme úlohu vodiča vykonávania. V tomto prípade má právo rozhodovať výlučne navigátor. Vodič iba tlačí a môže slovom ovplyvniť, čo sa deje. Úlohy sa dlho nemenia.
Dobré na učenie, ale vyžaduje silné mäkké zručnosti. Tu sme zaváhali. Technika bola náročná. A nejde ani tak o infraštruktúru.
Záver: potenciálne sa to dá použiť, nevzdávame pokusy.
4. Mobbing, rojenie a všetky známe, ale neuvedené štýly Neberieme do úvahy, pretože Neskúšali sme to a nedá sa o tom v kontexte našej práce hovoriť.
Všeobecné výsledky používania párového programovania:
- Máme nerovnomerné tempo práce, čo je mätúce.
- Narazili sme na nedostatočne dobré mäkké zručnosti. A predmetná oblasť nepomáha prekonať tieto naše nedostatky.
- Dlhé testy a problémy s nástrojmi sťažujú párový vývoj.
5. Napriek tomu boli úspechy. Prišli sme s vlastnou metódou „Konvergencia – Divergencia“. Stručne opíšem, ako to funguje.
Máme stálych partnerov na pár dní (menej ako týždeň). Robíme spolu jednu úlohu. Chvíľu spolu sedíme: jeden píše, druhý sedí a sleduje tím podpory. Potom sa na nejaký čas rozídeme, každý robí nejaké nezávislé veci, potom sa opäť spojíme, veľmi rýchlo sa zosynchronizujeme, urobíme niečo spolu a potom sa zase rozídeme.
Plánovanie a komunikácia
Posledným blokom praktík, prostredníctvom ktorých sa riešia problémy OS, je organizácia práce so samotnými úlohami. Patrí sem aj výmena skúseností, ktorá je mimo párovej práce. Pozrime sa na tri praktiky:
1. Ciele cez strom cieľov. Celkové riadenie projektu sme zorganizovali prostredníctvom stromu, ktorý ide do nekonečna do budúcnosti. Technicky sa sledovanie robí v Miro. Je tu jedna úloha – je to prechodný cieľ. Z toho vychádzajú buď menšie ciele, alebo skupiny úloh. Samotné úlohy pochádzajú z nich. Všetky úlohy sa vytvárajú a udržiavajú na tejto nástenke.
Táto schéma tiež poskytuje spätnú väzbu, ktorá sa vyskytuje raz denne, keď sa synchronizujeme na mítingoch. Mať pred všetkými spoločný plán, ale štruktúrovaný a úplne otvorený, umožňuje každému uvedomiť si, čo sa deje a ako ďaleko sme pokročili.
Výhody vizuálneho videnia úloh:
- Kauzalita. Každá úloha vedie k nejakému globálnemu cieľu. Úlohy sú zoskupené do menších cieľov. Samotná doména infraštruktúry je dosť technická. Nie je vždy hneď jasné, aký konkrétny vplyv má na podnikanie napríklad napísanie runbooku o migrácii na iný nginx. Ak máte cieľovú kartu v blízkosti, je to jasnejšie.
Kauzalita je dôležitou vlastnosťou problémov. Priamo odpovedá na otázku: "Robím správnu vec?" - Paralelizmus. Je nás deväť a je jednoducho fyzicky nemožné vrhnúť všetkých na jednu úlohu. Ani úlohy z jednej oblasti nemusia vždy stačiť. Sme nútení paralelizovať prácu medzi malými pracovnými skupinami. Skupiny si zároveň nejaký čas sadnú na svoju úlohu, môže ich posilniť niekto iný. Niekedy ľudia odpadávajú z tejto pracovnej skupiny. Niekto ide na dovolenku, niekto robí reportáž pre DevOps conf, niekto napíše článok o Habrovi. Vedieť, aké ciele a úlohy je možné vykonávať paralelne, sa stáva veľmi dôležitým.
2. Náhradné moderátorky ranných stretnutí. Pri stand-upoch máme tento problém – ľudia robia veľa úloh paralelne. Niekedy sú úlohy voľne prepojené a nie je jasné, kto čo robí. A názor ďalšieho člena tímu je veľmi dôležitý. Ide o dodatočné informácie, ktoré môžu zmeniť priebeh riešenia problému. Samozrejme, zvyčajne je s vami niekto, ale rady a tipy sú vždy užitočné.
Na zlepšenie tejto situácie sme použili techniku „Changing the Leading Stand-Up“. Teraz sa otáčajú podľa určitého zoznamu a to má svoj účinok. Keď ste na rade, musíte sa ponoriť a pochopiť, čo sa deje, aby ste mohli viesť dobrý Scrum stretnutie.
3. Interné demo. Pomoc pri riešení problému z párového programovania, vizualizácia na strome problémov a pomoc na ranných stretnutiach scrumu sú dobré, ale nie ideálne. Ako pár ste limitovaní len svojimi vedomosťami. Strom úloh pomáha globálne pochopiť, kto čo robí. A moderátor a kolegovia na rannom stretnutí sa neponoria hlboko do vašich problémov. Určite im môže niečo uniknúť.
Riešenie sa našlo vo vzájomnej demonštrácii vykonanej práce a následnej diskusii. Stretávame sa raz týždenne na hodinu a ukazujeme si podrobnosti o riešeniach úloh, ktoré sme robili za posledný týždeň.
Počas predvádzania je potrebné odhaliť detaily úlohy a určite predviesť jej fungovanie.
Správa môže byť vykonaná pomocou kontrolného zoznamu.1. Vstúpte do kontextu. Odkiaľ táto úloha pochádza, prečo bola vôbec potrebná?
2. Ako sa problém riešil predtým? Vyžadovalo sa napríklad masívne klikanie myšou, alebo sa nedalo robiť vôbec nič.
3. Ako to zlepšujeme. Napríklad: „Pozri, teraz je tu scriptosik, tu je readme.“
4. Ukážte, ako to funguje. Odporúča sa priamo implementovať nejaký užívateľský scenár. Chcem X, robím Y, vidím Y (alebo Z). Napríklad nasadím NGINX, vyfajčím url a dostanem 200 OK. Ak je akcia dlhá, pripravte si ju vopred, aby ste ju mohli ukázať neskôr. Hodinu pred ukážkou je vhodné ho príliš nerozbíjať, ak je krehký.
5. Vysvetlite, ako úspešne bol problém vyriešený, aké ťažkosti pretrvávajú, čo nie je dokončené, aké zlepšenia sú možné v budúcnosti. Napríklad teraz CLI, potom bude plná automatizácia v CI.
Pre každého rečníka je vhodné dodržať 5-10 minút. Ak je váš prejav zjavne dôležitý a bude trvať dlhšie, koordinujte to vopred na kanáli opätovného prevzatia.
Po osobnej časti vždy nasleduje diskusia vo vlákne. Tu sa objavuje spätná väzba, ktorú potrebujeme na naše úlohy.
V dôsledku toho sa vykonáva prieskum na určenie užitočnosti toho, čo sa deje. Ide o spätnú väzbu o podstate prejavu a dôležitosti úlohy.
Dlhé závery a čo ďalej
Môže sa zdať, že vyznenie článku je trochu pesimistické. Toto je nesprávne. Fungujú dve nižšie úrovne spätnej väzby, a to testy a párové programovanie. Nie je to také dokonalé ako pri tradičnom vývoji, ale má to pozitívny efekt.
Testy vo svojej súčasnej podobe poskytujú len čiastočné pokrytie kódu. Mnohé konfiguračné funkcie sú nevyskúšané. Ich vplyv na skutočnú prácu pri písaní kódu je nízky. Existuje však vplyv integračných testov a umožňujú vám bez obáv vykonávať refaktoringy. To je veľký úspech. Tiež s posunom zamerania na vývoj v jazykoch na vysokej úrovni (máme python, go) problém zmizne. A nepotrebujete veľa kontrol na „lepidlo“, stačí všeobecná kontrola integrácie.
Práca vo dvojici závisí skôr od konkrétnych ľudí. Je tu faktor úlohy a naše mäkké zručnosti. Niekomu to ide veľmi dobre, niekomu horšie. Z toho určite plynú výhody. Je zrejmé, že aj keď nie sú dostatočne dodržané pravidlá párovej práce, samotná skutočnosť spoločného plnenia úloh má pozitívny vplyv na kvalitu výsledku. Osobne považujem prácu vo dvojici za jednoduchšiu a príjemnejšiu.
Spôsoby ovplyvňovania OS na vyššej úrovni - precízne plánovanie a práca s úlohami prináša efekty: kvalitnú výmenu poznatkov a zlepšenie kvality vývoja.
Krátke závery v jednom riadku
- Personalisti pracujú v IaC, ale s menšou efektivitou.
- Posilnite to, čo funguje.
- Vymyslite si vlastné kompenzačné mechanizmy a postupy.
Zdroj: hab.com