Infrastruktura jako kód: jak překonat problémy pomocí XP

Dobrý den, Habr! Dříve jsem si stěžoval na život v Infrastruktuře jako na kódové paradigma a nenabízel nic k řešení současné situace. Dnes jsem zpět, abych vám řekl, jaké přístupy a postupy vám pomohou uniknout z propasti zoufalství 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 se reflektovat současnou situaci v této oblasti a dokonce jsem naznačil, že by mohly pomoci standardní postupy známé všem vývojářům. Mohlo by se zdát, že stížností na život bylo hodně, ale návrhy na východisko ze současné situace nebyly.

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

V současné době jsme v týmu Sre Onboarding Team, který se skládá ze šesti programátorů a tří inženýrů infrastruktury. Všichni se snažíme psát infrastrukturu jako kód (IaC). Děláme to proto, že v podstatě víme, jak psát kód, a máme historii „nadprůměrných“ vývojářů.

• Máme sadu výhod: určité zázemí, znalost postupů, schopnost psát kód, chuť učit se nové věci.
• A je tu ochabující část, což je také mínus: nedostatek znalostí o hardwaru infrastruktury.

Zásobník technologií, který používáme v našem IaC.

• Terraform pro vytváření zdrojů.
• Packer pro skládání obrázků. Jedná se o obrázky Windows, CentOS 7.
• Jsonnet k vytvoření výkonné sestavy v drone.io a také ke generování packer json a našich terraform modulů.
• Azure.
• Možné při přípravě obrázků.
• Python pro pomocné služby a prováděcí skripty.
• A to vše ve VSCode s pluginy sdílenými mezi členy týmu.

Závěr z mého poslední článek byl takový: Snažil jsem se vštípit (především v sobě) optimismus, chtěl jsem říci, že vyzkoušíme nám známé přístupy a postupy, abychom se vypořádali s obtížemi a složitostmi, které v této oblasti existují.

V současné době se potýkáme s následujícími problémy IaC:

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

Extreme Programming (XP) na záchranu

Všichni vývojáři znají Extreme Programming (XP) a praktiky, které za ním stojí. Mnoho z nás s tímto přístupem pracovalo a byl úspěšný. Proč tedy nevyužít tam stanovených zásad a postupů k překonání problémů v oblasti infrastruktury? Rozhodli jsme se použít tento přístup a uvidíme, co se stane.

Kontrola použitelnosti přístupu XP ve vašem odvětvíZde je popis prostředí, pro které se XP dobře hodí, a jak s námi souvisí:

1. Dynamicky se měnící požadavky na software. Bylo nám jasné, jaký je konečný cíl. Ale detaily se mohou lišit. Sami rozhodujeme, kam potřebujeme taxi, takže požadavky se pravidelně mění (hlavně my sami). Pokud vezmeme tým SRE, který dělá automatizaci sám a sám omezuje požadavky a rozsah práce, pak tento bod dobře sedí.

2. Rizika způsobená projekty na pevný čas využívající nové technologie. Při používání některých věcí, které neznáme, se můžeme setkat s riziky. A to je 100% náš případ. Celý náš projekt byl založen na technologiích, se kterými jsme nebyli plně obeznámeni. Obecně je to neustálý problém, protože... V sektoru infrastruktury se neustále objevuje mnoho nových technologií.

3,4. Malý, společně umístěný rozšířený vývojový tým. Automatizovaná technologie, kterou používáte, umožňuje jednotkové a funkční testy. Tyto dva body nám úplně nevyhovují. Za prvé nejsme sehraný tým a za druhé je nás devět, což se dá považovat za velký tým. I když podle některých definic „velkého“ týmu je hodně 14+ lidí.

Podívejme se na některé XP praktiky a na to, jak ovlivňují rychlost a kvalitu zpětné vazby.

Princip zpětné vazby XP

V mém chápání je zpětná vazba odpovědí na otázku, dělám správnou věc, jdeme tam? XP má na to božské schéma: časovou zpětnovazební smyčku. Zajímavostí je, že čím jsme níže, tím rychleji jsme schopni přimět OS k zodpovězení potřebných otázek.

To je docela zajímavé téma k diskuzi, že v naší IT branži je možné rychle sehnat OS. Představte si, jak bolestivé je dělat projekt šest měsíců a teprve pak zjistit, že hned na začátku byla chyba. To se děje při navrhování a při jakékoli konstrukci složitých systémů.

V našem případě IaC nám pomáhá zpětná vazba. Okamžitě provedu malou úpravu výše uvedeného diagramu: plán vydání nemá měsíční cyklus, ale vyskytuje se několikrát denně. S tímto cyklem OS jsou spojeny některé postupy, na které se podíváme podrobněji.

Důležité: zpětná vazba může být řešením všech výše uvedených problémů. V kombinaci s XP praktikami vás může vytáhnout z propasti zoufalství.

Jak se vytáhnout z propasti zoufalství: tři praktiky

Testy

Testy jsou ve zpětnovazební smyčce XP zmíněny dvakrát. Není to jen tak. Jsou nesmírně důležité pro celou techniku ​​extrémního programování.

Předpokládá se, že máte testy Unit a Acceptance. Některé vám poskytnou zpětnou vazbu za pár minut, jiné za pár dní, takže jejich psaní trvá déle a jsou méně často kontrolovány.

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

Jak se tento rámec vztahuje na nás v projektu IaC? Vlastně... vůbec ne.

• Unit testů, přestože by jich mělo být hodně, nemůže být příliš mnoho. Nebo něco velmi nepřímo testují. Vlastně se dá říct, že je vůbec nepíšeme. Zde je ale několik aplikací pro takové testy, které jsme mohli udělat:
  1. Testování kódu jsonnet. To je například naše potrubí montáže dronů, které je poměrně komplikované. Kód jsonnet je dobře pokryt testy.
     Používáme toto Rámec testování jednotek pro Jsonnet.
  2. Testuje skripty, které se spouštějí při spuštění prostředku. Skripty jsou psány v Pythonu, a proto na nich lze psát testy.
• Potenciálně je možné zkontrolovat konfiguraci v testech, ale my to neděláme. Je také možné nakonfigurovat kontrolu pravidel konfigurace zdrojů pomocí tflint. Nicméně kontroly tam jsou prostě příliš základní pro terraform, ale mnoho testovacích skriptů je napsáno pro AWS. A jsme na Azure, takže to zase neplatí.
• Testy integrace komponent: záleží na tom, jak je klasifikujete a kam je umístíte. Ale v podstatě fungují.

  Takto vypadají integrační testy.

  
  
  Toto je příklad při vytváření obrázků v Drone CI. Abyste se k nim dostali, musíte počkat 30 minut, než se vytvoří obrázek Packer, a pak počkat dalších 15 minut, než projdou. Ale existují!

  Algoritmus ověření obrazu

  1. Packer musí obraz nejprve kompletně připravit.
  2. Vedle testu je terraform s místním stavem, který používáme k nasazení tohoto obrázku.
  3. Při rozkládání slouží malý modul ležící poblíž, aby se s obrázkem snadněji pracovalo.
  4. Jakmile je virtuální počítač nasazen z bitové kopie, mohou začít kontroly. Kontroly se v zásadě provádějí autem. Kontroluje, jak fungovaly skripty při spuštění a jak fungují démoni. Chcete-li to provést, přes ssh nebo winrm se přihlásíme do nově spuštěného počítače a zkontrolujeme stav konfigurace nebo zda jsou služby spuštěny.

• Podobná situace je s integračními testy v modulech pro terraform. Zde je krátká tabulka vysvětlující vlastnosti takových testů.

  
  
  Zpětná vazba na potrubí je asi 40 minut. Vše se děje velmi dlouho. Může být použit pro regresi, ale pro nový vývoj je to obecně nereálné. Pokud jste na to velmi, velmi připraveni, připravte si běžící skripty, pak to můžete zkrátit na 10 minut. Pořád to ale nejsou Unit testy, které udělají 5 kusů za 100 sekund.

Absence Unit testů při sestavování obrázků nebo terraform modulů vybízí k přesunu práce na samostatné služby, které lze jednoduše spouštět přes REST, nebo na skripty Pythonu.

Potřebovali jsme například zajistit, aby se virtuální stroj po spuštění sám zaregistroval do služby MěřítkoFTa když byl virtuální stroj zničen, smazal se sám.

Jelikož máme ScaleFT jako službu, jsme nuceni s ní pracovat přes API. Byl tam napsaný obal, který jste mohli vytáhnout a říct: "Jdi dovnitř a smaž to a to." Ukládá všechna potřebná nastavení a přístupy.

Na to už můžeme napsat normální testy, protože se to neliší od běžného softwaru: nějaký druh apiha se vysmívá, vytáhnete to a uvidíte, co se stane.

Výsledky testů: Unit testing, který by měl dát OS za minutu, to nedává. A typy testování výše v pyramidě jsou účinné, ale pokrývají pouze část problémů.

Párové programování

Testy jsou samozřejmě dobré. Můžete jich napsat spoustu, mohou být různého typu. Budou pracovat na své úrovni a poskytnou nám zpětnou vazbu. Ale problém se špatnými Unit testy, které dávají nejrychlejší OS, zůstává. Zároveň stále chci rychlý OS, se kterým se snadno a příjemně pracuje. O kvalitě výsledného řešení nemluvě. Naštěstí existují techniky, které mohou poskytnout ještě rychlejší zpětnou vazbu než unit testy. Jedná se o párové programování.

Při psaní kódu chcete co nejrychleji získat zpětnou vazbu o jeho kvalitě. Ano, vše si můžete napsat do feature větve (aby se nikomu nic nezlomilo), udělat pull request v Githubu, přiřadit to někomu, jehož názor má váhu, a čekat na odpověď.

Ale můžete čekat dlouho. Všichni lidé jsou zaneprázdněni a odpověď, i když existuje, nemusí být nejvyšší kvality. Předpokládejme, že odpověď přišla okamžitě, recenzent okamžitě pochopil celou myšlenku, ale odpověď stále přichází pozdě, poté. Kéž by to bylo dříve. Na to je zaměřeno párové programování – hned, v době psaní tohoto článku.

Níže jsou uvedeny párové programovací styly a jejich použitelnost při práci na IaC:

1. Klasika, Zkušený+Zkušený, posun podle časovače. Dvě role – řidič a navigátor. Dva lidé. Pracují na stejném kódu a po určité předem stanovené době si vymění role.

Podívejme se na kompatibilitu našich problémů se stylem:

• Problém: nedokonalost nástrojů a nástrojů pro vývoj kódu.
  Negativní dopad: trvá déle, než se vyvíjí, zpomalujeme, ztrácí se 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í dopad: zvyšuje čas potřebný k vytvoření funkční části kódu. Při čekání se nudíme, natahujeme ruce, abychom během čekání udělali něco jiného.
  Jak bojujeme: nepřekonali jsme to.
• Problém: nedostatek přístupů a postupů.
  Negativní dopad: neexistují žádné znalosti o tom, jak to dělat dobře a jak to dělat špatně. Prodlužuje příjem zpětné vazby.
  Jak bojujeme: vzájemná výměna názorů a praktik v párové práci téměř řeší problém.

Hlavním problémem používání tohoto stylu v IaC je nerovnoměrné tempo práce. V tradičním vývoji softwaru máte velmi jednotný pohyb. Můžete strávit pět minut a napsat N. Strávit 10 minut a napsat 2N, 15 minut - 3N. Tady můžete strávit pět minut a napsat N, a pak strávit dalších 30 minut a napsat desetinu N. Tady nic nevíš, jsi zaseknutý, hlupáku. Vyšetřování vyžaduje čas a odvádí pozornost od samotného programování.

Závěr: v čisté formě pro nás není vhodný.

2. Ping-pong. Tento přístup vyžaduje, aby jedna osoba napsala test a druhá provedla jeho implementaci. Vezmeme-li v úvahu skutečnost, že u Unit testů je vše komplikované a musíte napsat integrační test, jehož programování trvá dlouho, veškerá snadnost ping-pongu zmizí.

Mohu říci, že jsme se pokusili oddělit odpovědnosti za návrh testovacího skriptu a implementaci kódu pro něj. Jeden účastník přišel se scénářem, v této části práce byl zodpovědný, měl poslední slovo. A druhý byl zodpovědný za realizaci. Dopadlo to dobře. Kvalita scénáře se tímto přístupem zvyšuje.

Závěr: bohužel, tempo práce neumožňuje použití ping-pongu jako párové programovací praxe v IaC.

3. Silný styl. Obtížná praxe. Myšlenka je taková, že jeden účastník se stane navigátorem direktivy a druhý převezme roli řidiče provádění. V tomto případě má právo rozhodovat výhradně navigátor. Ovladač pouze tiskne a může ovlivnit, co se děje se slovem. Role se dlouho nemění.

Dobré pro učení, ale vyžaduje silné měkké dovednosti. Tady jsme zaváhali. Technika byla obtížná. A nejde ani tak o infrastrukturu.

Závěr: potenciálně se dá použít, nevzdáváme se pokusů.

4. Mobbing, swarming a všechny známé, ale neuvedené styly Neuvažujeme o tom, protože Nezkoušeli jsme to a v kontextu naší práce se o tom mluvit nedá.

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

• Máme nerovnoměrné tempo práce, což je matoucí.
• Narazili jsme na nedostatečně dobré měkké dovednosti. A předmětná oblast nepomáhá tyto naše nedostatky překonat.
• Dlouhé testy a problémy s nástroji ztěžují párový vývoj.

5. Navzdory tomu byly úspěchy. Přišli jsme s vlastní metodou „Konvergence – Divergence“. Stručně popíšu, jak to funguje.

Máme stálé partnery na pár dní (necelý týden). Děláme spolu jeden úkol. Chvíli spolu sedíme: jeden píše, druhý sedí a sleduje podpůrný tým. Pak se na nějakou dobu rozejdeme, každý dělá nějaké nezávislé věci, pak se zase sejdeme, velmi rychle se synchronizujeme, něco spolu uděláme a zase se rozejdeme.

Plánování a komunikace

Posledním blokem praktik, jejichž prostřednictvím se řeší problémy OS, je organizace práce se samotnými úkoly. Patří sem i výměna zkušeností mimo párovou práci. Podívejme se na tři praktiky:

1. Cíle prostřednictvím stromu cílů. Celkové řízení projektu jsme zorganizovali prostřednictvím stromu, který jde nekonečně do budoucnosti. Technicky se sledování děje v Miru. Je tu jeden úkol – je to přechodný cíl. Od toho jdou buď menší cíle, nebo skupiny úkolů. Od nich vycházejí samotné úkoly. Všechny úkoly jsou vytvářeny a udržovány na této nástěnce.

Toto schéma také poskytuje zpětnou vazbu, která se objevuje jednou denně, když se synchronizujeme na shromážděních. Mít před všemi společný plán, ale strukturovaný a zcela otevřený, umožňuje každému uvědomit si, co se děje a jak daleko jsme pokročili.

Výhody vizuálního vidění úkolů:

• Kauzalita. Každý úkol vede k nějakému globálnímu cíli. Úkoly jsou seskupeny do menších cílů. Samotná doména infrastruktury je poměrně technická. Není vždy hned jasné, jaký konkrétní dopad má na podnikání například napsání runbooku o migraci na jiný nginx. Mít cílovou kartu poblíž, je to jasnější.
  
  Kauzalita je důležitou vlastností problémů. Přímo odpovídá na otázku: "Dělám správnou věc?"
• Rovnoběžnost. Je nás devět a je prostě fyzicky nemožné vrhnout všechny na jeden úkol. Úkoly z jedné oblasti také nemusí vždy stačit. Jsme nuceni paralelizovat práci mezi malými pracovními skupinami. Skupiny přitom na svém úkolu nějakou dobu sedí, mohou být posíleny někým dalším. Někdy lidé z této pracovní skupiny odpadnou. Někdo jede na dovolenou, někdo dělá reportáž pro DevOps conf, někdo píše článek o Habrovi. Vědět, jaké cíle a úkoly lze dělat paralelně, se stává velmi důležitým.

2. Náhradní přednášející ranních porad. U stand-upů máme tento problém – lidé dělají mnoho úkolů paralelně. Někdy jsou úkoly volně propojené a není jasné, kdo co dělá. A názor dalšího člena týmu je velmi důležitý. Jedná se o doplňující informace, které mohou změnit průběh řešení problému. Samozřejmě, většinou je s vámi někdo, ale rady a tipy se vždy hodí.

Ke zlepšení této situace jsme použili techniku ​​„Changing the Leading Stand-Up“. Nyní se točí podle určitého seznamu a to má svůj efekt. Když jste na řadě, jste nuceni se ponořit a pochopit, co se děje, abyste mohli vést dobrý Scrum setkání.

3. Interní demo. Pomoc při řešení problému z párového programování, vizualizace na stromě problémů a pomoc na ranních scrum meetingech jsou dobré, ale ne ideální. Jako pár jste omezeni pouze svými znalostmi. Strom úloh pomáhá globálně pochopit, kdo co dělá. A moderátor a kolegové na ranní poradě se neponoří hluboko do vašich problémů. Určitě jim může něco uniknout.

Řešením bylo vzájemně si předvést vykonanou práci a následně o ní diskutovat. Scházíme se jednou týdně na hodinu a ukazujeme si detaily řešení úkolů, které jsme za poslední týden udělali.

Při ukázce je nutné odhalit detaily úkolu a určitě předvést jeho fungování.

Hlášení lze provést pomocí kontrolního seznamu.1. Vstupte do kontextu. Kde se úkol vzal, proč byl vůbec nutný?

2. Jak byl problém vyřešen dříve? Vyžadovalo se například masivní klikání myší nebo nebylo možné dělat vůbec nic.

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

4. Ukažte, jak to funguje. Je vhodné přímo implementovat nějaký uživatelský scénář. Chci X, dělám Y, vidím Y (nebo Z). Například nasadím NGINX, vykouřím url a dostanu 200 OK. Pokud je akce dlouhá, připravte si ji předem, abyste ji mohli ukázat později. Hodinu před ukázkou je vhodné ji příliš nerozbíjet, pokud je křehká.

5. Vysvětlete, jak úspěšně byl problém vyřešen, jaké potíže přetrvávají, co není dokončeno, jaká zlepšení jsou možná v budoucnu. Například nyní CLI, pak bude plná automatizace v CI.

Je vhodné, aby každý reproduktor dodržel 5-10 minut. Pokud je váš projev zjevně důležitý a bude trvat déle, koordinujte to předem v kanálu sre-takeover.

Po prezenční části vždy následuje diskuze ve vláknu. Zde se objevuje zpětná vazba, kterou potřebujeme k našim úkolům.

V důsledku toho se provádí průzkum, který má určit užitečnost toho, co se děje. Jde o zpětnou vazbu o podstatě projevu a důležitosti úkolu.

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

Může se zdát, že vyznění článku je poněkud pesimistické. To je špatně. Fungují dvě nižší úrovně zpětné vazby, a to testy a párové programování. Není to tak dokonalé jako v tradičním vývoji, ale má to pozitivní efekt.

Testy ve své současné podobě poskytují pouze částečné pokrytí kódem. Mnoho konfiguračních funkcí skončí nevyzkoušeno. Jejich vliv na vlastní práci při psaní kódu je nízký. Existuje však efekt integračních testů a umožňují vám nebojácně provádět refaktoringy. To je velký úspěch. Také s přesunem zaměření na vývoj v jazycích na vysoké úrovni (máme python, go) problém zmizí. A nepotřebujete mnoho kontrol pro „lepidlo“, stačí obecná kontrola integrace.

Práce ve dvojicích závisí spíše na konkrétních lidech. Je tu faktor úkolu a naše měkké dovednosti. S některými lidmi to jde velmi dobře, s jinými hůře. Z toho určitě plynou výhody. Je zřejmé, že i když nejsou dostatečně dodržována pravidla párové práce, samotná skutečnost společného plnění úkolů má pozitivní vliv na kvalitu výsledku. Osobně považuji práci ve dvojici za jednodušší a příjemnější.

Vyšší úrovně ovlivňování OS - plánování a práce s úkoly precizně přináší efekty: kvalitní výměnu znalostí a zlepšení kvality vývoje.

Krátké závěry v jednom řádku

• Personalisté pracují v IaC, ale s menší efektivitou.
• Posílit to, co funguje.
• Vymyslete si vlastní kompenzační mechanismy a postupy.

Zdroj: www.habr.com