Měřitelnost přínosů implementace metodologie DevOps
V minulých dílech našeho seriálu o DevOps jsme se věnovali roli DevOps v digitální transformaci: co si pod tímto pojmem představit, a jaké jsou klíčové body tohoto systému práce. Popsali jsme také jak DevOps úspěšně zavést uvnitř technologické organizace a neselhat při tom. Nyní, ve třetím a závěrečném dílu, se budeme věnovat neméně důležitému tématu, a to odpovědi na otázku, které bude čelit každý zaměstnanec technologicky zodpovědný za vývoj a doručení aplikace. Ta otázka velmi zjednodušeně zní: „Kolik to bude stát, co z toho budeme mít a kdo to nakonec zaplatí?“ Ke každému hodnocenému aspektu uvedeme pro lepší představu i krátký příklad z praxe.
1. Čas
Nikde jinde, než právě při vývoji a doručování aplikací nehraje tato jednotka tak důležitou roli jako zde. Vývoj softwaru je velmi drahá záležitost, a předpokládané náklady lze poměrně jednoduše přenést na časovou osu. Přímá úměra je velice jednoduchá: Čím více času při vývoji softwaru strávíme, tím více peněz musíme vydat. Částečným řešením může být automatizace, ale pouze pokud je v týmu dostatek zkušených specialistů, kteří ji umí aplikovat.
Naprosto zásadní je mít správně nastavený rozpočet vůči velikosti týmu, který se bude v projektu angažovat. Projektové vedení, analytici, vývojáři a testeři dokážou doslova „konzumovat“ časové jednotky po celých týdnech a žádný rozpočet není bez nezbytného plánování ve skutečnosti tak velký, aby nedokázal nakonec velice rychle dojít.
K vývoji aplikací se nyní nejčastěji používá některý z agilních přístupů. Cílem DevOps je zajistit dostatečnou podporu agilním vývojovým týmům, přesto však není nezbytně nutné, aby byly jejich součástí. Bezpochyby nejrozšířenější agilní metodikou používanou na vývoj aplikací je Scrum.
V ideálním světě lze vytvořit backlog na konkrétní úkony, a dopředu si rezervovat čas DevOps specialisty. Tedy konkrétně a pouze jen jeho „Dev“ část, kterou lze plánovat. Bohužel v tom reálném musí DevOps, (tentokrát spíše ta „Ops“ část) reagovat ihned a nelze čekat na další sprint s opravou kritické části nasazení. Plánování se tím nutně stane složitějším.
Naší prioritou je eliminovat plýtvání, přinést dostatečnou kvalitu tam, kde je vyžadována a také budovat a zvyšovat celkovou zkušenost týmu. Právě proto je velmi často lépe aplikovatelná Lean Kanban metodologie.
Příklad:
Před adopcí DevOps nebylo u našeho zákazníka možné paralelizovat sestavování aplikačního kódu. Sestavení monolitické aplikace trvalo přes 60 minut. Vývojáři nemohli vytvářet nové vývojové větve, a požadavek na vyřízení zabral i týden. Změnové požadavky na aplikaci byly plánovány měsíčně a release probíhal každý kvartál.
V případě operativních zásahů nefunkčnosti nasazení, bylo nutné kontaktovat externí tým, který sice reagoval následující den, ale problém vyřešil většinou až za několik dalších pracovního dní.
Díky metodologii DevOps bylo možné implementovat novou mikroservisní architekturu. Vývojáři si nyní mohou sami vytvářet vývojové větve. Jejich aplikační kód je testován v reálném čase ihned po odevzdání. Změnové požadavky jsou plánovány každé dva týdny a release je možné uskutečnit prakticky kdykoliv. Provozní chyby jsou eliminovány ten samý den, kdy jsou reportovány. Celkově potřebovala nová majoritní verze aplikace na cestě před zákazníka pouze 35 % času v porovnání s tou předchozí.
Kvalita
Jakákoliv další jednotka, kterou si stanovíme má víceméně opět dopad na čas, který je potřeba věnovat nápravě chyb, ať aplikačních, nebo UX. Kvalita je ale jedna z nejlépe hodnotitelných metrik, kterou můžeme sledovat. Zároveň se čísla velmi dobře sledují na grafech, které je nutné předložit jako důkaz správně provedené digitální transformace.
Každá společnost by měla udržovat seznam reportovaných chyb aplikace včetně jejich závažnosti s tím, že ty nejzávažnější bude opravovat jako první. Právě počty aktivních vs. vyřízených chyb v tomto seznamu se dají velmi dobře srovnat se stavem před zavedením DevOps. Na reportování chyb lze použít kterýkoliv trackovací nástroj typu Jira, Trac, YouTrack nebo CI/CD platformy Azure DevOps, Github, které také nabízí určité, byť drobně omezené, možnosti.
Kvalita se netýká pouze komplexního řešení hotového produktu, ale i jeho částí. Konkrétně služeb, ze kterých je postavena. Díky statické analýze můžeme měřit kvalitu kódu i bezpečnost. Mezi nejznámější nástroje patří SonarQube, který zvládne hravě obojí. Další služby jsou jFrom, Deepsource, Codacy, Qodana a mnoho dalších. Výstupem jsou grafy, které ukáží, jak dobře na tom daný produkt aktuálně je, včetně trendu, kterým se kvalita ubírá.
Standardně je možné tyto testy kvality a bezpečnosti implementovat jako jeden z podmíněných kroků při sestavování aplikačního kódu. Pokud odevzdávaný kód nesplní definovaná pravidla a limity, je automaticky zamítnut. Jinými slovy, není připuštěn k integraci a dalším testům, dokud ho vývojáři neopraví.
Příklad:
Díky DevOps, automatizaci a integraci statické analýzy ve vybrané společnosti vzrostla velmi zásadně kvalita produktu. Na základě nižšího počtu hlášených chyb došlo ke zlepšení kvality o více než 65 %. Většina chyb byla nalezena a včas odstraněna díky automatizovanému testování, definovaným pravidlům na kvalitu kódu i bezpečnostním testům.
3. Flexibilita
Jak lze měřit schopnost umět se přizpůsobit neustále se měnícím podmínkám na trhu a potřebám zákazníků? Zejména v dnešním dynamickém podnikatelském prostředí, kde flexibilita při vývoji softwaru velmi často znamená udržení konkurenceschopnosti, je tato schopnost zásadní? DevOps podporuje agilitu a umožňuje zapracování průběžné zpětné vazby zákazníků. Zrychlení iterace vývojových cyklů a časté nasazování aktualizací softwaru jsou jen některé ukazatele, které lze bez větších potíží zveřejnit.
Příklad:
Nové procesy umožnily rychlejší reagování na změnu trhu: změnové požadavky jsou zpracovávány podle reportu společnosti často až 18x rychleji. Toho bylo možné dosáhnout díky automatizaci některých kroků při integraci, opět včetně testování. Odevzdaný kód je po splnění podmínek automatický začleněn do hlavní vývojové větve.
Takto velké zrychlení vývoje by nebylo myslitelné bez podpory paralelního vývoje a infrastrukturních závislostí. Díky dynamicky škálovatelnému prostředí je vždy dostatek výkonu pro vývoj a testy bez velkého dopadu na celkovou cenu. Když výkon není potřeba, jsou prostředky infrastruktury uvolněny na nezbytné minimum.
Flexibilitě napomáhá i moderní technologický stack a orchestrace aplikačních modulů. Pomocí dockerizace je velmi jednoduché izolovat jednotlivé verze aplikace, škálovat i doručovat a to bezvýpadkově. Kontejnerizace umožňuje i snadný „rollback“ (vrácení na předchozí verzi), pokud si to situace žádá. To, co dříve trvalo hodiny a dny, je možné aplikovat do několika málo vteřin.
4. Náklady
Téměř s jistotou nenarazíte na žádného vlastníka produktu, který by podepsal vývojovému týmu tzv. „blank cheque“. Stejně tak nevím ani o úspěšném projektu, kde byl termín dodání definován stylem „Až to bude, tak to bude“.
Náklady musí být známy a vyčísleny a vždy se musí hledat úspora tak, aby byl výsledný produkt ziskový. Jedním z mnoha řešení je automatizace procesů testování a doručení softwaru. Dalším řešením je dynamická infrastruktura typu „Pay as you go“, kdy jdou náklady pouze na infrastrukturu, která je aktivně používaná. Zároveň je vhodné zvolit architekturu, která umožňuje dynamické škálování infrastruktury.
Optimalizovat lze i ve vývojovém týmu, nebo požadovaných službách. Je vždy nutné mít interní vývojový tým, který (pokud chcete dostatečnou senioritu), je velmi drahý. Některé jeho části lze samozřejmě i outsourcovat.
Příklad:
Díky digitální transformaci společnosti a změny architektury bylo možné snížit náklady na infrastrukturu o 67 %! Snížily se také celkové náklady na vývoj a zrychlilo se celkové dodání. Úspory se dotkly také potřebných lidských zdrojů, opět díky automatizaci, není potřebný tak velký lidský výkon.
Závěrem
I když se může zdát, že je vše zalité sluncem na rozkvetlé zahradě plné růží, je nutné si uvědomit i rizika spojená s digitální transformací, o kterých jsme se bavili v předchozích dílech. Pokud je transformace prováděna neodborně, populární metodou „pokus-omyl“, může tento pokus vyjít velmi draho bez valného výsledku, nebo s výraznou ztrátou.
V případě, že je transformace naplánována dobře, je možné ji provést „bezvýpadkově“, kontinuálně a v přesně vymezeném časovém horizontu bez zásahu koncových klientů, a o ty jde dodavatelům softwaru samozřejmě především.
Díky měřitelnosti jednotlivých aspektů implementace DevOps procesů je jasně prokazatelné, jaký je přínos zavedením metodologie ve společnosti. Zároveň dokážou tyto metriky odhalit slabá místa, na která se lze více zaměřit při dalším rozvoji.
 |
Vojtěch Kijenský Autor článku je nadšenec pro DevOps a cloudovou architekturu, pracuje ve společnosti Cleverlance Enterprise Solutions na pozici Head of DevOps. Pomáhá klientům s vybudováním kvalifikovaného profesionálního týmu DevOps a nastavením kultury spolupráce. |
