Jednou jsme jednomu zákazníkovi dodali systém elektronické správy dokumentů. A pak k dalšímu objektu. A ještě jeden. A na čtvrtém a na pátém. Nechali jsme se tak unést, že jsme dosáhli 10 rozmístěných objektů. Ukázalo se to mocně... zvláště když jsme se dostali k provedení změn. V rámci dodávky do výrobního okruhu si 5 scénářů testovacího systému nakonec vyžádalo 10 hodin a 6-7 zaměstnanců. Takové náklady nás donutily provádět dodávky co nejméně. Po třech letech fungování jsme to nevydrželi a rozhodli se projekt okořenit špetkou DevOps.
Nyní probíhá veškeré testování za 3 hodiny a účastní se ho 3 lidé: inženýr a dva testeři. Vylepšení jsou jasně vyjádřena v číslech a vedou ke snížení tolik oblíbeného TTM. Podle našich zkušeností existuje mnohem více zákazníků, kteří mohou těžit z DevOps, než těch, kteří o něm vůbec vědí. Proto, abychom DevOps přiblížili lidem, vyvinuli jsme jednoduchý konstruktor, o kterém si povíme podrobněji v tomto příspěvku.
Nyní vám to povíme podrobněji. Jedna energetická společnost zavádí systém správy technických dokumentů v 10 velkých zařízeních. Není snadné procházet projekty tohoto rozsahu bez DevOps, protože velký podíl ruční práce práci značně zdržuje a také snižuje kvalitu – veškerá ruční práce je plná chyb. Na druhou stranu existují projekty, kde je pouze jedna instalace, ale vše musí fungovat automaticky, neustále a bez poruch – například stejné systémy toku dokumentů ve velkých monolitických organizacích. V opačném případě někdo provede nastavení ručně, zapomene na návod k nasazení – a ve výsledku se ve výrobě nastavení ztratí a vše se zhroutí.
Obvykle pracujeme se zákazníkem prostřednictvím smlouvy a v tomto případě se naše zájmy mírně rozcházejí. Zákazník se na projekt dívá přísně v rámci rozpočtu a technických specifikací. Může být obtížné vysvětlit mu výhody různých postupů DevOps, které nejsou zahrnuty v technických specifikacích. Co když má zájem o rychlá vydání s přidanou obchodní hodnotou nebo o vybudování automatizačního potrubí?
Bohužel, při práci s předem schválenými náklady se tento zájem vždy nenajde. V naší praxi se vyskytl případ, kdy jsme museli vyzvednout vývoj bezohledného a nedbalého dodavatele. Bylo to hrozné: neexistovaly žádné aktuální zdrojové kódy, kódová základna stejného systému byla na různých instalacích odlišná, dokumentace částečně chyběla a částečně měla hroznou kvalitu. Zákazník samozřejmě neměl kontrolu nad zdrojovým kódem, sestavou, vydáními atd.
Zatím ne každý o DevOps ví, ale jakmile se bavíme o jeho výhodách, o skutečné úspoře zdrojů, všem zákazníkům se rozzáří oči. Počet požadavků, které zahrnují DevOps, se tedy postupem času zvyšuje. Abychom mohli se zákazníky snadno mluvit stejným jazykem, musíme rychle propojit obchodní problémy a postupy DevOps, které pomohou vybudovat vhodný vývojový kanál.
Takže na jedné straně máme řadu problémů, na druhé máme znalosti, postupy a nástroje DevOps. Proč se o zkušenost nepodělit se všemi?
Vytvoření konstruktoru DevOps
Agile má svůj vlastní manifest. ITIL má svou vlastní metodiku. DevOps má méně štěstí – zatím nezískalo šablony a standardy. Ačkoli určit vyspělost společností na základě posouzení jejich vývoje a provozních postupů.
Naštěstí v roce 2014 známá společnost Gartner a analyzoval klíčové postupy DevOps a vztahy mezi nimi. Na základě toho jsem vydal infografiku:
Vzali jsme to jako základ našeho . Každá ze čtyř oblastí má sadu nástrojů – shromáždili jsme je do databáze, identifikovali ty nejoblíbenější, identifikovali integrační body a vhodné optimalizační mechanismy. Celkem to vyšlo 36 praktik a 115 nástrojů, z nichž čtvrtinu tvoří open source nebo svobodný software. Dále budeme hovořit o tom, čeho jsme v jednotlivých oblastech dosáhli, a jako příklad o tom, jak to bylo implementováno v projektu vytvoření správy technických dokumentů, se kterým jsme příspěvek začínali.
Procesy
V notoricky známém projektu EDMS byl systém správy technické dokumentace nasazen podle stejného schématu u každého z 10 objektů. Instalace zahrnuje 4 servery: databázový server, aplikační server, fulltextovou indexaci a správu obsahu. V instalaci fungují v rámci jednoho uzlu a jsou umístěny v datovém centru na zařízeních. Všechny objekty se mírně liší v infrastruktuře, ale to nenarušuje globální interakci.
Nejprve jsme podle postupů DevOps lokálně zautomatizovali infrastrukturu, poté jsme dodávku přivedli na testovací okruh a poté na produkt zákazníka. Každý proces byl vypracován krok za krokem. Nastavení prostředí je pevně dané v systému zdrojového kódu, přičemž se bere v úvahu, která distribuční sada je sestavena pro automatickou aktualizaci. V případě změn konfigurace musí inženýři jednoduše provést příslušné změny v systému správy verzí – a pak proběhne automatická aktualizace bez problémů.
Díky tomuto přístupu se značně zjednodušil proces testování. Dříve měl projekt testery, kteří nedělali nic jiného, než ručně aktualizovali stojany. Teď jen přijdou, vidí, že vše funguje a dělají užitečnější věci. Každá aktualizace je testována automaticky – od povrchové úrovně až po automatizaci obchodního scénáře. Výsledky jsou zveřejněny jako samostatné zprávy v TestRail.
Kultura
Nepřetržité experimentování je nejlépe vysvětleno na příkladu návrhu testu. Testování systému, který ještě neexistuje, je kreativní práce. Při psaní testovacího plánu musíte pochopit, jak správně testovat a podle kterých větví se řídit. A také najít rovnováhu mezi časem a rozpočtem, abyste určili optimální počet kontrol. Je důležité zvolit přesně potřebné testy, promyslet, jak bude uživatel se systémem komunikovat, vzít v úvahu prostředí a možné vnější faktory. Bez neustálého experimentování se to neobejde.
Nyní o kultuře interakce. Dříve existovaly dvě protichůdné strany – inženýři a vývojáři. Vývojáři řekli: „Je nám jedno, jak to bude spuštěno. Jste inženýři, jste chytří, ujistěte se, že to funguje bez poruch.". Inženýři odpověděli: "Vy vývojáři jste příliš nedbalí." Buďme opatrnější a vaše vydání budeme hrát méně často. Protože pokaždé, když nám dáte děravý kód, není nám jasné, jak interagovat.“. Toto je problém kulturní interakce, který je z pohledu DevOps strukturován odlišně. Zde jsou inženýři i vývojáři součástí jednoho týmu, který je zaměřen na neustále se měnící, ale zároveň spolehlivý software.
Ve stejném týmu jsou specialisté odhodláni si navzájem pomáhat. Jak to bylo předtím? Například se připravovaly nějaké tlusté pokyny k nasazení, asi 50 stránek. Technik si to přečetl, něčemu nerozuměl, nadával a ve tři hodiny ráno požádal vývojáře, aby se vyjádřil. Vývojář to komentoval a také nadával – nakonec se nikdo neradoval. Navíc samozřejmě došlo k několika chybám, protože si nemůžete zapamatovat vše v pokynech. A nyní inženýr společně s vývojářem píše skript pro automatizované nasazení infrastruktury aplikačního softwaru. A mluví spolu prakticky stejným jazykem.
lidé
Velikost týmu je dána rozsahem aktualizace. Tým je rekrutován během tvorby dodávky, zahrnuje zájemce z obecného projektového týmu. Poté je sepsán plán aktualizace s osobami odpovědnými za každou fázi a tým podává zprávy o postupu. Všichni členové týmu jsou zaměnitelní. V rámci týmu máme i záložního vývojáře, který se ale téměř nikdy nemusí připojovat.
Technologie
V technologickém diagramu je zvýrazněno několik bodů, ale pod nimi je spousta technologií – s jejich popisy byste mohli vydat celou knihu. Vyzdvihneme tedy to nejzajímavější.
Infrastruktura jako kód
Nyní tento koncept pravděpodobně nikoho nepřekvapí, ale dříve popisy infrastruktur zůstávaly velmi žádoucí. , testovací prostředí byla jedinečná, byla opečovávaná a opečovávaná, byly z nich odfukovány prachové částice.
V dnešní době se nikdo nebojí experimentovat. Existují základní obrazy virtuálních strojů, existují připravené scénáře pro nasazení prostředí. Všechny šablony a skripty jsou uloženy v systému správy verzí a jsou okamžitě aktualizovány. Dříve, když bylo nutné doručit balík na stojan, objevila se konfigurační mezera. Nyní stačí přidat řádek do zdrojového kódu.
Kromě infrastrukturních skriptů a kanálů se pro dokumentaci používá také přístup Documentation as a Code. Díky tomu je snadné do projektu zapojit nové lidi, uvést je do systému na základě funkcí popsaných například v plánu testování a také znovu použít testovací případy.
Průběžné dodávky a sledování
o DevOps jsme hovořili o tom, jak jsme vybírali nástroje pro implementaci kontinuálního doručování a monitorování. Často není potřeba nic přepisovat – stačí použít dříve napsané skripty, správně vybudovat integraci mezi komponentami a vytvořit společnou konzoli pro správu. A všechny procesy lze spustit pomocí jednoho tlačítka nebo plánu.
V angličtině existují různé pojmy, Continuous Delivery a Continuous Deployment. Oba lze přeložit jako „nepřetržité dodávky“, ale ve skutečnosti je mezi nimi nepatrný rozdíl. V našem projektu pro tok technických dokumentů distribuované energetické společnosti se spíše používá Dodávka - kdy instalace pro výrobu probíhá na příkaz. V Deployment proběhne instalace automaticky. Kontinuální doručování v tomto projektu se obecně stalo centrální část DevOps.
Obecně platí, že sběrem určitých parametrů můžete jasně pochopit, proč jsou postupy DevOps užitečné. A předejte to managementu, který opravdu miluje čísla. Celkový počet spuštění, doba provádění fází skriptu, podíl úspěšných spuštění – to vše přímo ovlivňuje oblíbenou dobu uvedení na trh každého, tedy dobu od odevzdání do systému správy verzí po vydání verze na produkční prostředí. Díky implementaci potřebných nástrojů dostávají inženýři cenné ukazatele poštou a projektový manažer je vidí na palubní desce. Takto můžete okamžitě vyhodnotit přínosy nových nástrojů. A můžete je vyzkoušet na vaší infrastruktuře pomocí návrháře DevOps.
Kdo bude potřebovat naše ?
Nepředstírejme: pro začátek se nám stal užitečným. Jak jsme již řekli, se zákazníkem je potřeba mluvit stejným jazykem a s pomocí designéra DevOps dokážeme rychle načrtnout základ takové konverzace. Obchodní specialisté budou moci sami posoudit, co potřebují, a rozvíjet se tak rychleji. Snažili jsme se, aby byl návrhář co nejpodrobnější, přidali jsme spoustu popisů, aby každý uživatel pochopil, co si vybírá.
Formát návrháře umožňuje zohlednit stávající vývoj společnosti v oblasti stavebních procesů a automatizace. Není třeba vše bourat a přestavovat, pokud si můžete vybrat pouze řešení, která se dobře integrují se stávajícími procesy a která mohou jednoduše vyplnit mezery.
Možná se váš vývoj již posunul na vyšší úroveň a náš nástroj se vám bude zdát příliš „kapitánský“. Ale považujeme to za užitečné pro sebe a doufáme, že to bude užitečné pro některé ze čtenářů. Připomínáme projektantovi - pokud něco, diagram obdržíte ihned po zadání počátečních dat. Budeme vděční za vaši zpětnou vazbu a doplnění.
Zdroj: www.habr.com