Ačkoliv tento článek popisuje naše cíle v rámci změny na DevOps kulturu, tak je především vyjádřením velkého díku mnoha chytrým lidem v KB. Bez nich by naše cesta za DevOps nebyla možná. Jsem opravdu rád, že s vámi, lidi, mohu spolupracovat a těším se, jak budeme dál společně tvořit náš IT svět: přívětivější, zábavnější, rychlejší a odolnější – vše ve prospěch našich klientů.

 

Komerční banka obsluhuje přibližně 1,6 milionu retailových a velkou spoustu korporátních klientů. V roce 2016 byla typickou velkou dámou s těžkopádnými IT procesy, kde obchodní a IT části fungovaly zcela odděleně. Kdo chtěl něco nového naprogramovat, musel si nechat vytvořit projekt a veškeré změny podrobit složitému plánování. Pak přišel CEO Honza Juchelka a spustil agilní transformaci. A tehdy to všechno začalo …

 

Mé jméno je Jindřich Kubát. V KB pracuji dva roky jako šéf vývoje a zároveň jsem lídrem naší DevOps transformace. V tomto článku bych rád popsal naši dosavadní cestu, cíle a úspěchy, jichž jsme dosáhli.

 

DEVOPS

Děláme DevOps. Nikoliv BizDevOps, ani DevSecOps nebo jakoukoliv jinou kombinaci těchto zkratek. K DevOps přistupujeme tak, jako by zahrnoval všechny úseky: Business, Securitu, Architekturu, QA, Operations apod. DevOps je zkratka, která vyjadřuje naši kulturu lepší spolupráce a sdílených cílů.

 

Naše DevOps cíle

Cíle jsou důležité. Každý by se jimi měl řídit a každý by si měl průběžně kontrolovat, zda jeho každodenní práce skutečně směřuje k dosažení stanovených cílů. Na cestě k naplnění vize není radno podceňovat význam cílů. Bez stanovených cílů sice každý děláme svou práci tak, jak umíme nejlépe, ale jednoho dne můžeme přijít na to, že někteří z nás ve skutečnosti pracují proti sobě, protože sledují rozdílné cíle.  I z tohoto důvodu velké firmy tak často fungují neefektivně. Protože je zkrátka velice obtížné koordinovat cíle pro všechny. Proto mám osobně tak rád S.M.A.R.T. cíle , které používám jako osobní cíle pro své manažery. Ze stejného důvodu jsem fanda OKR, které se v KB uplatňují na firemní úrovni.

Pro měření naší implementace na DevOps kulturu jsme zvolili cíle podle DORA. Posláním mého DevOps transformačního týmu je nejen popsat jednotlivé cíle, ale zároveň vysvětlovat, proč jsou důležité. A zde jsme hned narazili na první problémy, protože různé útvary uvnitř firmy mají kolikrát různé cíle. Také jsme museli průběžně vysvětlovat, které činnosti k naplnění cílů směřují a které nikoliv.

 

Lead time for changes

Tento cíl jsme pojali jako End-2-End lead time to changes, přestože je složitější ho měřit. Vyjadřuje naši schopnost rychle dosáhnout business změny či opravy chyby v období od zadání do produkce. Pro naplnění cíle jsme museli výrazně optimalizovat vlastní Software Delivery Life Cycle (SDLC), a to by nebylo možné bez nativního cloudového prostředí. Naštěstí jsme již měli svůj interní cloud postavený na technologiích OpenStack a Kubernetes. První zásadní změnou bylo kompletní přepracování SDLC pro nové aplikace. Tam, kde jsme byli zvyklí používat 10 až 15 různých prostředí pro každou aplikaci, jsme je nahradili pouhými čtyřmi pevně danými prostředími: DEV -> QA -> STAGE -> PROD! Zde je nutné podotknout, že počty prostředí jsou spojené i se způsobem, jakým týmy používají verzovací systém zdrojového kódu (gitflow). Aplikace dříve vyžadovaly celou řadu prostředí: k vývoji, testování, akceptacím, výkonovým testům, zaškolování apod. Jejich velice nákladná údržba pak měla za následek častou nedostupnost neprodukčních prostředí a vysokou variabilitu různých prostředí, která jsme mapovali na sebe. Vývojáři museli používat záslepky (mocking) namísto fungujících živých integrací. To už však pro nové aplikace neplatí! Prvním prostředím, v němž může vývojový tým testovat stabilitu, API vazby a vůbec funkčnost aplikace, je QA. Následující STAGE je pak superstabilní předprodukční prostředí, kde může kdokoliv testovat cokoliv, tj. provádět zátěžové (stress) testy, testovat obnovu po pádu (disaster recovery), penetrační testy, integrační testy a další a další druhy testů. Vývojový tým garantuje, že jejich aplikace funguje v minimálním režimu 5/8 (5 dní, 8 hod. denně). Naší ambicí je být schopni uvolňovat verze do prostředí PROD průběžně, téměř denně.

Náš stanovený cíl: Do Q4/2025 zkrátit E2E lead time for changes ze 100 na 20 dní.

Komentář k cíli: Lead time měříme od vložení nápadu do JIRA po dodávku a nasazení do produkce. Měření se provádí zpětně pro všechny nápady dotažené po dodávku.

 

Jindřich Kubát, Head of Development CoE

Deployment frequency

Donedávna jsme vydávali tři velké verze ročně – ano, tři! Všechny firemní procesy jako vzdělávání na pobočkách, vývoj, testování a release kampaně se točily kolem vydání velké integrační verze. Během nasazení se vydávalo nějakých 15 hlavních aplikací (monolitů) a případné související aplikace. Před několika roky jsme provedli analýzu na čtyři nasazení ročně. Skončilo to neúspěchem. Spousta lidí žádnou změnu nechtěla a mnoho lidí se tenkrát vyslovilo pro omezení na dvě verze ročně (čím méně změn, tím méně problémů). Hodně lidí si nepochybně muselo myslet, že jsem blázen, když jsem přišel s tím, že budeme nasazovat každý měsíc modelem release train. Trvalo to sice skoro rok, ale dokázali jsme to! Za přispění mnoha lidí jsme již dokázali vydat několik menších verzí v roce 2021. Tento cíl bychom nezvládli bez úsilí vloženého do automatizace testování, stabilizace neprodukčního prostředí či přenesení E2E zodpovědnosti za aplikaci v non-prod na vývojové týmy. Je potřeba zdůraznit, že release trains jsou určené pouze pro stávající velké monolitické aplikace. Pro nové aplikace máme připravený nový SDLC a s ním spojenou ambici vydávat změny na vyžádání (ideálně denně).

 

Náš stanovený cíl: Do roku 2025 zvýšit průměrný počet nasazení z osmi za rok a tým na 120 za rok.

Komentář k cíli: Na nasazení nahlížíme jako na cokoliv, co může ovlivnit produkční stabilitu. Veškeré změny musí procházet přes CI/CD pipeline: vývoj nových business změn, opravy chyb, změny v datech, změny konfigurace. Všechny tyto změny znamenají růst počtu nasazení a každé nasazení musí být řádně kategorizováno.

 

Mean time to recovery

Dostupnost aplikace významným způsobem závisí na hodnotách Mean Time To Failure (MTTF) a Mean Time to Recovery (MTTR). Dříve jsme investovali množství prostředků do navyšování hodnoty MTTF. Úsek Operations nesl zodpovědnost za vydávání verzí, jejich údržbu, řešení problémů, management mimořádných událostí apod. Tím ovšem vznikla zeď mezi vývojem a operations. Nyní se zaměřujeme spíše na autonomii týmů, automatizaci vydávání aplikací (deployment automation) a následnou (post-mortem) analýzu. Zlepšili jsme spolupráci při řešení problémů. Tím jsme zlepšili dostupnost aplikací v produkci a co je ještě důležitější, dostupnost aplikací v neprodukčním prostředí, což má zásadní význam pro zrychlení dodávek a zvýšení produktivity.

Vedle toho také investujeme do naší Observability. Namísto parametrů CPU, MEM, I/O waits a dalších HW metrik sledujeme aplikační metriky podle Google Golden Metrics (Errors, Latency, Total traffic, Saturation). Obecně jsme ve sledování aplikačních metrik a propojování na HW a Business metriky zatím na začátku, ale týmy už doceňují význam monitoringu pro jejich práci i skutečnost, že bez kvalitního monitoringu jsme slepí.

Náš stanovený cíl: Do roku 2025 zkrátit MTTR ze sedmi na jednu hodinu.

Komentář k cíli: Měříme dobu, která uplyne mezi nasazením dvou různých funkcí a případnými opravami chyb. Pokud je potřeba vydat opravu, existoval problém, který opravu vyžadoval.

 

Change Failure Rate

Míra produktivity v IT závisí mimo jiné na tom, jak rychle přijdeme na to, že jsme udělali chybu. Pokud na chybu přijdeme až v produkci, je to pozdě a obvykle je to také drahé. Musíme ihned přerušit stávající práci a začít se věnovat řešení dané chyby. Proto jsme začali automatizovat nasazování pomocí CI/CD pipelines a provádět testy během fáze nasazování. Nástroje CI/CD, například Jenkins v kombinaci s dalšími jako třeba Sonarcube, nám pomohly zavést automatizaci testování a nasazení. Pro nový SDLC to byla (a stále je) nezbytná investice. Pro mnoho aplikací jsou nyní automatické testy nedílnou součástí dodávky. Není možné je vydat bez provedení automatického testu. Je to tedy již nedílná součást našeho nového způsobu práce.

Náš stanovený cíl: Do roku 2025 navýšit podíl aplikací, pro něž platí četnost chyb Change Failure Rate 10 % a méně, z 67 % na 95 %.

Komentář k cíli: Výpočet vychází z celkového počtu vydaných verzí, počtu verzí s novými funkcemi a počtu verzí s opravami chyb.

 

Doslov

Je jasné, že jsem nezmínil spoustu další práce, která k dosahování hlavních cílů přispívá, jako je řízení (governance) DevOps, měření postupu v DevOps, spolupráce s dalšími IT útvary či s obchodní částí. Základní vizí pro nás zůstává spolehlivá dodávka udržitelných produktů, nikoliv projektů. Jediným způsobem, jak dlouhodobě dosahovat produkční dostupnosti při krátké době uvádění produktů (time to market), je uplatňování LEAN postupů a teorie omezení (Theory of Constraints) a průběžná práce na vylepšování a na schopnosti rychle se měnit a rychle odhalovat chyby.

Někdy není snadné vidět výsledky práce, které se dennodenně věnujeme. Proto je občas potřeba ohlédnout se zpět na všechny dosažené úspěchy. Ještě jednou díky všem!