Stále je spousta organizací, které nasazují manuálně, automatizace je velmi sporadická, CI/CD a principy DevOps hudbou budoucnosti.
Všichni to známe, máme-li být v našem podnikání úspěšní, musíme vyvíjet a poskytovat nové aplikace, a to rychleji, kvalitněji a levněji než kdykoli dříve. Vypadá to jednoduše, máme velké množství technologií, které nám to mají usnadnit. Ať už mluvíme o moderních platformách založených na Kubernetes jako je Red Hat OpenShift, softwarovových řešeních poskytovaných formou služby (SaaS) ve veřejném cloudu, pokročilých integračních nástrojích, datovém streamingu nebo v neposlední řadě i technologiích kolem strojového učení, všechny tyto technologie nám mohou pomoci, ale i velmi uškodit. Na jedné straně přináší dosud nevídané možnosti mnohem jednoduššího vývoje a provozu aplikací, na straně druhé velmi zvyšují komplexitu prostředí a kladou vysoké nároky na znalosti jak vývojářů, tak i správců jednotlivých systémů.
Na první pohled se toto celé může zdát jako problém, který je snadno řešitelný a uměle vyvolaný. Správnou adopci technologií a metodik k jejich použití přeci zajistíme tím, že implementujeme DevOps, projekty budeme řídit agilně a aplikace napíšeme podle posledních trendů a nasadíme je pomocí vyladěných CI/CD postupů. Vypadá to jako ideální a snadná cesta, opak je ale pravdou. Pokud se podíváme trochu do historie, tak CI/CD principy tu s námi jsou více než 10 let, mikroslužby více než 15 let a Manifest agilního vývoje softwaru byl sepsán před více než 20 lety. Neměli by tedy být již dávno adoptované, sloužící jako základní stavební kameny IT a používané jako ověřené způsoby vývoje a provozu aplikací?
Ne všude se tomu tak děje. Stále je spousta organizací, které nasazují manuálně, automatizace je velmi sporadická, CI/CD a principy DevOps hudbou budoucnosti. Kde nám tedy vznikl problém? Máme velmi pokročilé technologie, máme znalosti metodik a velmi často máme i týmy, které jsou motivované a touží všechny tyto trendy aplikovat. A tady se dostáváme k jádru problému – žádná z těchto změn nemůže být iniciována a úspěšně realizována čistě jako záležitost IT samotného. Technologie a metodiky jsou pouze nástrojem, které nám mají usnadnit cestu k cíli – k aplikacím a službám, které naši zákazníci rádi využívají a které jim každý den pomáhají zvládat jejich úkoly, vzdělávají je, či jim jen pomáhají se odreagovat od problémů všedních dní.
Proč tedy v této oblasti, která je pro nás velmi často klíčová selháváme i přes to, že máme technologie, metodiky a často i týmy motivované situaci změnit? Na tuto otázku není jednoduchá odpověď a u každé firmy či projektu může být ten důvod jiný. Zkusme se na to tedy podívat obráceně, co zapříčinilo, že některé firmy a projekty fungují lépe a blíží se cíli, kterého chceme dosáhnout – IT, které je schopno efektivně spravovat stávající aplikace a zároveň rychle reagovat na nové požadavky a ty bez vytváření technologického dluhu integrovat se stávajícími systémy. Co jsou tedy hlavní důvody?
Ze zkušenosti, co na trhu vídáme, jsou tyto důvody celkem fádní. Zejména se jedná o nevhodné nastolení nebo ignorování společných cílů, nedostatečnou podporu spolupráce a komunikace nejen mezi jednotlivými členy IT týmů, ale i vlastníky produktů, obchodním oddělením, marketingem a zákazníky. Jako velmi zajímavý můžeme použít příklad automatizace, což je jedna z významných oblastí, kde Red Hat působí a kde máme bohaté zkušenosti. Náš přístup k automatizaci není jen psaní playbooků a rolí pro automatizační platformu Ansible, ale celá problematika je mnohem širší. Celkem brzy jsme zjistili, že když dáme našim zákazníkům pouze technologii a obecné metodologie, tak často tápou a zbytečně prochází slepými uličkami. Proto jsme jako firma založená na meritokracii a sdílení, vyvinuli tzv. Automation Adoption Journey, tedy program, který – jak název napovídá, usnadňuje zákazníkům cestu k adopci automatizace jako celku. Celý tento program je postaven na propojování jednotlivých týmů a budování společného přístupu k automatizaci napříč celou firmou, který se nakonec sbíhá v IT procesech, které se mohou obejít i bez klasických ticketovacích systémů a ručních zásahů do infrastruktury. Jednotlivé týmy jsou během tohoto procesu propojovány a podporovány ve společném budování automatizačních skriptů a postupů od konfigurace sítě, správy operačních systémů, aplikací až po pokročilá témata jako jsou Chaos Monkeys, event-driven automatizace či self healing a automatické generovaní playbooků za pomocí Red Hat Insights.
Podobný program nabízíme i v oblasti kontejnerizace a modernizace aplikací. Zároveň je velmi důležité, že tady primárně nedodáváme řešení na klíč, ale naši konzultanti slouží jako katalyzátor akcelerující tato témata. Důležité jsou zejména počáteční fáze, kde si klademe velké množství složitých otázek a snažíme se nejen definovat vizi, jak má daná organizace fungovat ve výhledu let, ale zároveň hledáme i aktuální problémy, které se snažíme pojmenovat a definovat z nich tzv. “minimal viable product”. Tedy určit produkt s nejmenší možnou funkcionalitou, který je však plně použitelný a umožňuje rychle získat zpětnou vazbu od zákazníků pro další vývoj, a pomocí jeho rozvoje akcelerovat změnu vedoucí k lepšímu propojení a efektivnějšímu fungování nejen IT částí firem.
Inspirací pro tyto programy jsou nejen naše zkušenosti z interních projektů, v rámci kterých jsme podobné problémy úspěšně řešili, ale vycházíme i ze zkušeností našich zákazníků a celého ekosystému našich partnerů, ať už mluvíme o menších projektech či přípravě plně spravovaných řešení, které jsou součástí největších veřejných cloudů. Dobrou zprávou pro všechny agilní organizace je, že veškeré nástroje a metodiky, které používáme, jsou vyvíjeny jako open source a jsou volně dostupné na stránkách Open Practice Library (https://openpracticelibrary.com/).
David Bečvařík
Autor je Country Manager pro Českou republiku a Slovensko ve společnosti Red Hat
