🥇Infrastructure as Code: jak překonat problémy s pomocí XP

Ahoj, Habre! Dříve jsem si stěžoval na život v paradigmatu Infrastruktura jako kód a nic nenabízel jako řešení vzniklé situace. Dnes se vracím, abych pověděl, jaké přístupy a praktiky mohou pomoci uniknout z propasti beznaděje a nasměrovat situaci správným směrem.

V předchozím článku Infrastruktura jako kód: první seznámení Sdílel jsem své dojmy z této oblasti, snažil jsem se přemýšlet o současné situaci v oboru a dokonce jsem naznačil, že standardní, všem vývojářům známé praktiky mohou pomoci. Mohlo se zdát, že tam bylo mnoho stížností na život, ale nebylo tam žádné návrhy, jak situaci vyřešit.

Kdo jsme, kde jsme a jaké máme problémy

Momentálně jsme v týmu SRE Onboarding, který se skládá ze šesti programátorů a tří infrastrukturálních inženýrů. Všichni se snažíme psát Infrastrukturu jako kód (IaC). Děláme to, protože umíme psát kód a v minulosti jsme byli vývojáři na úrovni "nadprůměrně".

Máme několik výhod: určité zázemí, znalosti praktik, schopnost psát kód, touhu učit se novému.
A máme i slabou stránku, neboli mínus: nedostatek znalostí o infrastrukturním základu.

Technologický stack, který používáme v našem IaC.

Terraform pro vytváření zdrojů.
Packer pro sestavení obrazů. To jsou obrazy Windows a CentOS 7.
Jsonnet pro mocné sestavení v drone.io, a také pro generování packer json a našich terraform modulů.
Azure.
Ansible při přípravě obrazů.
Python pro pomocné služby, a také skripty pro provisioning.
A to vše v VSCode s pluginy sdílenými mezi členy týmu.

Závěr z mé předchozího článku byl takový: snažil jsem se vštípit (především sobě) optimismus, chtěl jsem říct, že budeme zkoušet známé nám přístupy a praktiky, abychom se vyrovnali s obtížemi a komplikacemi, které v této sféře existují.

Momentálně čelíme takovým problémům IaC:

Nedokonalost nástrojů a prostředků pro vývoj kódu.
Pomalé nasazení. Infrastruktura je část reálného světa a ten může být pomalý.
Nedostatek přístupů a praktik.
Jsme nováčci a mnoho nevíme.

Extrémní programování (XP) spěchá na pomoc.

Všichni vývojáři dobře znají extrémní programování (XP) a praktiky, které za ním stojí. Mnozí z nás pracovali s tímto přístupem a byl úspěšný. Proč tedy nevyužít principy a praktiky, které tam byly zavedeny, abychom překonali překážky infrastruktury? Rozhodli jsme se aplikovat tento přístup a podívat se, co z toho vzejde.

Ověření použitelnosti přístupu XP ve vaší oblastiPřináším popis prostředí, pro které je XP dobře přizpůsobené, a jak se to vztahuje k nám:

1. Dynamicky se měnící požadavky na software. Měli jsme jasno v konečném cíli. Ale detaily mohou být variabilní. Sami rozhodujeme, kam se máme posunout, takže se požadavky občas mění (většinou od nás samotných). Pokud vezmeme tým SRE, který sám dělá automatizaci a sám omezuje požadavky a rozsah práce, platí tento bod dobře.

2. Rizika způsobená pevně časovými projekty používajícími novou technologii. Můžeme čelit rizikům při používání nějakých nám neznámých věcí. A to je 100 % náš případ. Celý náš projekt spočívá v používání technologií, které jsme do konce neznali. To je obecně stálý problém, protože v oblasti infrastruktury neustále přibývá mnoho nových technologií.

3,4. Malý, spolu umístěný rozšířený vývojový tým. Technologii, kterou používáte, umožňuje automatizované jednotkové a funkční testy. Tyto dva body nám úplně nesedí. Zaprvé, nejsme zajedno umístěný tým, zadruhé máme devět lidí, což může být považováno za velký tým. I když podle některých definic „velkého“ týmu je to hodně — 14+ lidí.

Podívejme se na některé praktiky z XP a to, 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 správně, zda kráčíme tím správným směrem. V XP existuje božská schéma: cyklus zpětné vazby v čase. Zajímavé je, že čím níže jsme, tím rychleji můžeme získat O/S, abychom odpověděli na potřebné otázky.

Je to docela zajímavé téma k diskusi, protože v naší IT industriji je možné rychle získat O/S. Představte si, jak bolestně složité je dělat nějaký projekt po dobu šest měsíců a teprve potom zjistit, že na začátku byla položena chyba. To se stává jak při návrhu, tak při jakémkoliv budování složitých systémů.

V našem případě nám IaC pomáhá s zpětnou vazbou. Okamžitě provedu malou úpravu v výše uvedeném schématu: plán vydání nemáme v měsíčních cyklech, ale probíhá několikrát denně. K tomuto cyklu OS se vážou některé praktiky, které podrobněji prozkoumáme.

Je důležité: zpětná vazba může být řešením pro všechny výše uvedené problémy. Ve spojení s praktikami XP může vytáhnout z propasti zoufalství.

Jak se dostat z propasti zoufalství: tři praktiky

Testy

Testy se zmiňují dvakrát v cyklu zpětné vazby XP. Není to bez důvodu. Jsou extrémně důležité pro celou techniku extrémního programování.

Předpokládá se, že máš Unit a Acceptance tests. Jedny ti dávají zpětnou vazbu za pár minut, druhé za několik dní, proto jsou psány déle a spouštěny méně často.

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

Jak je toto schéma použitelné v našem projektu IaC? Vlastně… nijak.

Unit testů, přestože by jich mělo být opravdu hodně, nemůže být opravdu moc. Buď testují něco velmi nepřímo. V podstatě lze říci, že je vůbec nepíšeme. Ale máme několik využití pro takové testy, které se nám přece jen podařilo udělat:
1. Testování kódu na jsonnet. To je například náš build pipeline 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 startu zdroje. Skripty jsou na Python, a proto je možné psát testy i pro ně.
Potenciálně je možná kontrola konfigurace v testech, ale my to tak neděláme. Je tu také možnost nastavení kontroly pravidel konfigurace zdrojů přes tflint. Nicméně, pro terraform jsou tam příliš základní kontroly, ale mnoho kontrolních scénářů je napsáno pro AWS. A my jsme na Azure, takže to opět nefunguje.
Komponentní integrační testy: záleží na tom, jak je klasifikuješ a kam je zařadíš. Ale v zásadě fungují.
Takto vypadají integrační testy.

To je příklad při buildování obrazů v Drone CI. Abychom se k nim dostali, musíme čekat 30 minut, než se vytvoří image Packer, pak dalších 15 minut čekat, než projdou. Ale jsou tu!
Algoritmus kontroly obrazů
1. Nejprve musí Packer úplně připravit obraz.
2. Vedle testu je terrafom s lokálním stavem, pomocí kterého tento obraz nasazujeme.
3. Při nasazování se používá malý modul, který leží vedle, aby bylo jednodušší pracovat s obrázkem.
4. Jakmile je z obrazu nasazena VM, lze začít s kontrolami. Kontroly se provádějí především na stroji. Zkoumá se, jak fungovaly skripty při spuštění, jak fungují démoni. K tomu se přes ssh nebo winrm přihlásíme na právě spuštěný stroj a zkontrolujeme stav konfigurace nebo zda se služby spustily.
Podobná situace je s integračními testy a moduly pro terraform. Zde je stručná tabulka, která vysvětluje vlastnosti takových testů.

Zpětná vazba na pipeline je kolem 40 minut. Všechno probíhá velmi pomalu. Lze to použít pro regresi, ale pro nový vývoj je to naprosto nerealistické. Pokud se na to člověk opravdu pečlivě připraví, připraví running, skripty, lze to zkrátit na 10 minut. Ale to stále nejsou Unit testy, které vykonají 100 kusů za 5 sekund.

Nedostatek Unit testů při sestavování obrazů nebo modulů terraformu nutí přesouvat práci na samostatné služby, které lze jednoduše zavolat přes REST, nebo na Python skripty.

Například jsme potřebovali zajistit, aby se při spuštění virtuálního stroje registroval v službě ScaleFT, a při zničení virtuálky se smazal.

Jelikož ScaleFT u nás funguje jako služba, musíme s ním pracovat přes API. Bylo napsáno obal, které lze zavolat a říct: „Zajdi a smaž to a to“. Uchovává všechny potřebné nastavení a přístupy.

Na to už můžeme psát normální testy, protože to nijak neodlišuje od běžného softwaru: mockuje se nějaké API, ty to zavoláš, a díváme se, co se děje.

Výsledky testů: Unit testování, které by mělo trvat OS minutu, to nesplňuje. A vyšší typy testování na pyramidě dávají efekt, ale pokrývají pouze část problémů.

Párové programování

Testy jsou samozřejmě dobré. Můžeme napsat hodně, mohou mít různé formáty. Budou fungovat na svých úrovních a poskytovat nám zpětnou vazbu. Ale problém s špatnými unit testy, které poskytují nejrychlejší OS, přetrvává. Přesto si stále přejeme rychlou OS, na které se snadno a příjemně pracuje. Nemluvě o kvalitě konečného řešení. Naštěstí existují techniky, které nám umožňují poskytnout ještě rychlejší zpětnou vazbu než modulové testy. To je cílem párového programování.

Při psaní kódu chceme získat zpětnou vazbu o jeho kvalitě co nejdříve. Ano, můžete napsat všechno ve feature větvi (aby nikomu nic neporušilo), vytvořit pull request na GitHubu, přidělit ho někomu, jehož názor má váhu, a čekat na odpověď.

Ale čekání může trvat dlouho. Lidé jsou všichni zaneprázdněni, a odpověď, i když přijde, nemusí být vždy nejkvalitnější. Představme si, že odpověď přišla okamžitě, recenzent okamžitě porozuměl celému záměru, ale odpověď přichází stále se zpožděním, dodatečně. A člověk by chtěl dříve. Tady je párové programování cíleno – aby se reagovalo ihned, v průběhu psaní.

Dále uvádím styly párového programování a jejich použitelnost při práci na IaC:

1. Klasický, Zkušený + zkušený, změna podle časovače. Dvě role – driver a navigator. Dva lidé. Pracují na stejném kódu a mění se v rolích po určitém předem určeném časovém úseku.

Podívejme se na slučitelnost našich problémů se stylem:

Problém: nedokonalost nástrojů, prostředků pro vývoj kódu.
Negativní vliv: delší doba vývoje, zpomalujeme, narušujeme tempo / rytmus práce.
Jak bojujeme: používáme jiné nástroje, společné IDE a také se učíme zkratky.
Problém: pomalé nasazení.
Negativní vliv: prodlužuje čas potřebný k vytvoření funkční části kódu. Nudíme se při čekání, ruce automaticky sahají po něčem jiném, zatímco čekáme.
Jak bojujeme: nezvládli jsme to.
Problém: nedostatek přístupů a praktik.
Negativní vliv: neexistuje znalost, jak dělat dobře a jak špatně. Zpomalí to získání zpětné vazby.
Jak bojujeme: vzájemné sdílení názorů a praktik v párové práci téměř řeší problém.

Hlavním problémem při použití tohoto stylu v IaC je nerovnoměrné tempo práce. V tradičním vývoji softwaru je pohyb velmi rovnoměrný. Můžeš strávit pět minut a napsat N. Strávit 10 minut a napsat 2N, 15 minut – 3N. Tady můžeš strávit pět minut a napsat N, a pak strávit dalších 30 minut a napsat jednu desetinou N. Tady nic nevíš, máš zmatek a stagnaci. Vysvětlování zabere čas a odvádí pozornost od samotného programování.

Závěr: v čisté podobě nám to nevyhovuje.

2. Ping-pong. Tento přístup předpokládá, že jeden účastník napíše test, zatímco druhý ho implementuje. S ohledem na to, že s unit testy je to složité, a je nutné psát dlouhé integrační testy, veškerá lehkost ping-pongu mizí.

Mohu říci, že jsme zkoušeli oddělení povinností při návrhu scénáře testu a implementaci kódu pro něj. Jeden účastník vymýšlel scénář, v této části práce byl zodpovědný, on měl poslední slovo. Druhý byl zodpovědný za implementaci. To fungovalo dobře. Kvalita scénáře se takovým přístupem zvyšuje.

Závěr: bohužel, tempo práce neumožňuje používat ping-pong jako praktiku párového programování v IaC.

3. Strong Style. Složitá praxe. Myšlenka je, že jeden účastník se stává direktivním navigátorem, zatímco druhý přebírá roli výkonného řidiče. Přitom veškerá rozhodovací práva patří pouze navigatorovi. Řidič pouze zapisuje a slovy může ovlivnit, co se děje. Role se nemění dlouhou dobu.

Dobře se hodí pro výuku, ale vyžaduje silné soft skills. Na tom jsme se zasekli. Technika byla složitá. A vůbec to není jen o infrastruktuře.

Závěr: potenciálně může být použito, nevzdáváme se pokusů.

4. Mobbing, swarming a všechny známé, ale zde nezmíněné styly nezkoumáme, protože jsme je nezkoušeli a nemůžeme o tom říct nic v kontextu naší práce.

Obecné shrnutí používání párového programování:

Máme nerovnoměrné tempo práce, které narušuje.

Narážíme na nedostatečně dobré soft skills. A odborná oblast nepomáhá překonat tyto naše nedostatky.

Dlouhé testy a problémy s nástroji činí párový vývoj obtížným.

5. I přesto byly i úspěchy. Vymysleli jsme vlastní metodu "Sjednocení – rozdělení." Stručně popíšu, jak to funguje.

Máme stálé partnery na několik dní (méně než týden). Děláme spolu jeden úkol. Někdy spolu sedíme: jeden píše, druhý se dívá, jak pracuje tým podpory. Potom se na nějakou dobu rozdělujeme, každý dělá nějaké nezávislé věci, potom se zase sejdeme, velmi rychle se synchronizujeme, děláme něco spolu a znovu se rozdělujeme.

Plánování a komunikace

Poslední blok praktik, jak řešit problémy OS, se týká organizace práce se samotnými úkoly. Zde patří i výměna zkušeností, která je mimo párovou práci. Pojďme se podívat na tři praktiky:

1. Úkoly prostřednictvím cílového stromu. Celkovou správu projektu jsme organizovali prostřednictvím stromu, který nekonečně směřuje do budoucnosti. Technicky je správa prováděna v Miro. Existuje jeden úkol – to je mezilehlý cíl. Od něj se odvíjejí buď menší cíle, nebo skupiny úkolů. Od nich pak už samotné úkoly. Všechny úkoly jsou vytvářeny a spravovány na této tabuli.

Tato schéma také poskytuje zpětnou vazbu, která probíhá jednou denně, když se synchronizujeme na schůzkách. Přítomnost společného plánu před všemi, přitom strukturovaného a zcela otevřeného, umožňuje každému být informován o tom, co se děje a jak daleko jsme pokročili v postupu.

Výhody vizuálního vnímání úkolů:

Příčinnost. Každý úkol vede k nějakému globálnímu cíli. Úkoly jsou seskupeny podle menších cílů. Doména infrastruktury je sama o sobě poměrně technická. Ne vždy je hned jasné, jaký konkrétní vliv na podnikání má například vytvoření raněho manuálu pro migraci na jiný nginx. Přítomnost cílové karty vedle toho to činí srozumitelnější.

Příčinnost – důležitá vlastnost úkolů. Přímo odpovídá na otázku: "Dělám to správně?"
Paralelnost. Je nás devět a není fyzicky možné, aby se všichni zaměřovali na jeden úkol. Úkolů z jedné oblasti také nemusí být vždy dost. Práci tedy nutně paralelizujeme mezi menší pracovní skupiny. Tyto skupiny nějakou dobu pracují na svém úkolu a mohou být posíleny někým dalším. Z této pracovní skupiny občas někteří lidé odcházejí. Někdo jde na dovolenou, někdo dělá prezentaci na konferenci DevOps conf, někdo píše článek na Habr. Vědět, které cíle a úkoly mohou být prováděny paralelně, se stává velmi důležité.

2. Rotující vedoucí ranních schůzek. Na stand-upech vznikl takový problém – lidé dělají mnoho úkolů paralelně. Někdy jsou úkoly slabě propojené a není jasno, kdo co dělá. A názor dalšího člena týmu je velmi důležitý. To je dodatečná informace, která může změnit průběh řešení úkolu. Samozřejmě, obvykle s tebou ve dvojici někdo je, ale konzultace a rady jsou vždy užitečné.

Abychom tuto situaci zlepšili, zavedli jsme techniku “Rotující vedoucí stand-upu”. Nyní se rotují podle určitého seznamu a to má svůj efekt. Když se dostaneš na řadu, jsi nucen se ponořit a pochopit, co se děje, abys dobře vedl scrum meeting.

3. Interní demo. Pomoc při řešení úkolu z párového programování, vizualizace na stromě úkolů a pomoc na ranních scrum meetingech – to je dobré, ale ne dokonalé. Ve dvou jste omezeni pouze svými znalostmi. Strom úkolů pomáhá globálně pochopit, kdo a co dělá. A vedoucí a kolegové na ranní schůzce se nevnoří hluboko do tvých problémů. Určitě mohou něco přehlédnout.

Řešení bylo nalezeno ve vzájemném ukazování hotových prací a následné diskusi o nich. Scházíme se jednou týdně na hodinu a ukazujeme detaily řešení úkolů, které jsme dělali za poslední týden.

Během prezentace je třeba odhalit detaily úkolu a určitě ukázat jeho fungování.

Prezentaci lze provádět podle check-listu.1. Vložte do kontextu. Odkud úkol pochází, proč to vůbec bylo potřeba?

2. Jak se úkol řešil předtím? Například bylo potřeba masivní klikání myší, nebo bylo zcela nemožné něco udělat.

3. Jak to zlepšujeme. Například: "Podívejte, teď existuje skript, tady je readme."

4. Ukažte, jak to funguje. Ideálně proveďte nějaký uživatelský scénář. Chci X, dělám Y, vidím Z (nebo Z). Například nasazuji NGINX, testuji URL, dostávám 200 OK. Pokud je akce dlouhá, připravte ji předem, abyste ji mohli ukázat. Ideálně hodinu před prezentací se už ničím nestresujte, pokud je to křehké.

5. Vysvětlete, jak úspěšně byla vyřešena problémová otázka, jaké potíže zůstaly, co ještě není dokončeno, jaké možné vylepšení je do budoucna. Například, teď je to CLI, pak bude plná automatizace v CI.

Ideálně by měl každý řečník stihnout 5-10 minut. Pokud je váš příspěvek předem důležitý a zabere více času, dohodněte se na tom předem v kanálu sre-takeover.

Po živé části určitě probíhá diskuze v treads. Zde se objeví ta potřebná zpětná vazba ohledně vašich úkolů.

Na závěr se provádí dotazník k určení užitečnosti konání. Toto už je zpětná vazba k podstatě vystoupení a důležitosti úkolu.

Dlouhé závěry a co dál

Může se zdát, že tón článku je poněkud pesimistický. Není tomu tak. Dva základní úrovně získávání zpětné vazby, a to testy a párové programování, fungují. Ne úplně tak, jak je tomu v tradičním vývoji, ale pozitivní efekt z toho je.

Testy, v jejich současné podobě, poskytují pouze částečné pokrytí kódu. Mnoho konfiguračních funkcí zůstává netestovaných. Jejich vliv na přímou činnost při psaní kódu je nízký. Přesto existuje efekt z integračních testů, a to právě ony umožňují provádět refaktoring bez obav. To je velký úspěch. Také s přesunem zaměření na vývoj ve vysokoúrovňových jazycích (u nás python, go) problém mizí. A na "svařování" je mnoho kontrol a není to potřeba, stačí obecní integrace.

Práce v páru více závisí na konkrétních lidech. Existuje faktor úkolu a naše soft skills. S někým to jde velmi dobře, s někým hůř. Určitě z toho plyne prospěch. Je jasné, že i při nedostatečném dodržování pravidel párové práce má samotný fakt společného plnění úkolů pozitivní vliv na kvalitu výsledku. Osobně se mi v páru pracuje snáze a příjemněji.

Vyšší úrovně vlivu na OS – plánování a práce s úkoly rozhodně přinášejí efekty: kvalitní výměnu znalostí a zlepšení kvality vývoje.