Rychlý jako DevOps

Jak přitáhnout vývojáře blíž k provozu? Jak zrychlit nasazování změn? Jak lépe provázat systémy a procesy? Jak být pružný jako „ty fintechy“?

 

Fintech firmy se předhánějí v nových službách, inovacích a objevech, které by mohly usnadnit uživatelům život a jako vedlejší efekt trochu pobourat zažité finanční instituce. Banky také inovují, ale pomaleji. Když už změnu v bankovním systému někdo naprogramuje, jak ji dostat k uživatelům? Stovky nezdarů naučily banky být maximálně opatrné s uváděním nových změn. Ve velkých institucích se změny plánují do čtvrtletních release-cyklů, v těch modernějších se povede nasazovat změny třeba i každý měsíc.

Nezřídka se ukazuje, že cesta Design-Vývoj-Testování-Release-Podpora je tak zdlouhavá, že se původní myšlenka v průběhu doby mění vlivem všech dobře míněných nápadů. Nakonec může dojít i k situaci, kdy sice výsledná změna „funguje“, ale jaksi jinak než chtěl klient. Pěkně to ilustruje již klasický obrázek různých očekávání účastníků projektu „houpačka“:

Dalším úskalím je předání produktu z fáze vývoje do produkce. Zpravidla to totiž mají na starost různé týmy, a ty si o produktu, jeho nasazení a správě nemusí myslet to samé.

 

Co je to DevOps

Tyto otázky se snaží řešit koncept DevOps (Development + Operations). Pojem se objevil již v r.2009. Základní myšlenka DevOps vychází z co nejužšího provázání týmů vývoje a provozu, nasazení automatizace všude kde to lze vč. testování a nasazení do produkce, využití agilního přístupu, zakomponování security kontrol, přechod do cloudu atd.

Jádrem je provázání, ideálně přímo spojení týmů vývojářů s provozáky v jeden DevOps tým. Namísto dlouho plánovaných hromadných změn se nasazují drobnější změny častěji, klidně i několikrát denně. Ideálně průběžně, každá změna hned do produkce, tzv. Continuous Delivery.

Velká změna sice mohla projít stovkami testů, ty přesto nemohou vyloučit, že se v praxi neobjeví nečekaná chyba. Dopad takové nepovedené velké změny může být dalekosáhlý. V ČR nedávno jedna velká banka po releasu velké změny měla několikadenní problémy s Internetovým bankovnictvím a kartami. Proti tomu průběžné nasazování drobnějších změn udržuje nebezpečí výskytu chyby v akceptovatelné rovině. Ano, také se může chyba objevit, ale nastavení rychlé zpětné vazby umožňuje předat informaci rychle vývojářům. Programátoři pak snáz chybu objeví a opraví, protože si jsou lépe vědomi co, kde a kdo konkrétně v kódu měnil při této poslední změně.

Pomalost a nedostatek komunikace je jádrem problému, který pěkně ilustruje Damon Edwards ve své přednášce, video zde. Prapříčinou je tradiční oddělování fází Plánu (=designu) – Vývoje – Nasazení změny a Provozu. Tyto činnosti tradičně vykonávají různé týmy a nezřídka také v různých „svých“ prostředích. Existují tak oddělená tzv.sila.

„The biggest advantage is the insight that we work in a system. We have to optimize for the whole system   and not just for the silo. By optimizing for the whole, we are improving for the business, not just for IT.“   Patrick Debois (zdroj), Patrikův blog http://www.jedi.be/blog/

Řešením problému je tedy spojení těchto týmů, ale nejen to. DevOps koncept je velmi široký a schová se pod něj kde co. Proto také neexistuje žádný DevOps Manifest, na rozdíl např. od Agilního manifestu. Ve světě i v ČR existují banky, které hrdě tvrdí, že využívají agilního přístupu při vývoji, ale potom se nestydí naprogramované změny z agilních sprintů nasazovat s několikaměsíčním zpožděním.

 

Jak se stát DevOps

Každá změna v nabídce finančních institucí musí být naprogramována. Do toho lze počítat i nastavení parametrů v již existujících programech. Pro rychlost a správnost provedení dané změny je nutné, aby se každý požadavek bez jakýchkoli zbytečných zdržení dostal co nejdříve k programátorům. Stejně jako fintech i banky musejí bourat staré struktury, vytvářet pružné týmy a zapojovat programátory do debat o změnách hned v počátečních fázích úvah. Je čas vpustit do zasedaček ty podivné chlapíky v tričkách a v sandálech…

Pro analytiky to nese požadavek změny kvalifikace směrem k IT, po programátorech je naopak vyžadováno, aby nejen rozuměli businessu, ale byli schopni s ním mluvit bez tradičních prostředníků (analytiků). Programátor se zároveň ale stává provozákem, takže změnu si nejen vyrobí a nasadí, ale musí o chod systému v produkci také dlouhodobě pečovat. Je jasné, že tento koncept podporuje přirozenou opatrnost a větší svědomitost při nasazování změn. Není totiž na koho problém přehodit.  V DevOps není místo na tlusté specifikace jako zadání pro programátory. V praxi se mnohokrát ukázalo, že je nikdo nečte a navíc jejich trvalá synchronizace s aktuálním stavem je neskutečná a zbytečná práce. DevOps není chaos. I zde lze využívat řadu nástrojů, které práci na změnách všem usnadní a udržují celý proces změn trvale transparentní.

O mixování týmů a významu oběda pěkně mluví Cornelia Davis na DevOps Enterprise Summit 2017 (video).

 

Banky, které jedou na DevOps

Banky se svou tradičně pomalejší schopností zavádět jakékoli změny kolem DevOps stále spíše přešlapují. Mimo banky je koncept DevOps hromadně přijímán a podporován vč. takových gigantů jako IBM. Situaci v bankách nepomáhá ani regulace, která stále ještě rigidně vyžaduje oddělení provozu a vývoje. Požadavky regulátora reflektují také interní a externí auditoři, kteří zatím v ČR konceptu DevOps nejsou příliš nakloněni.

 

CapitalOne

Americká banka Capital One začala pracovat na přechodu k DevOps již v r.2015. Zárodkem byl první agilní tým. Prvotním impulzem byla snaha nahradit všechny ruční kroky při tvorbě a nasazování změn plně automatickým procesem. Automatizaci stavěli na produktu Hygieia. I CapitalOne přesouvá svou infrastrukturu do cloudu Amazon Web Services (AWS), dlohodobý cíl 100% v cloudu chtějí splnit do konce r.2018. Právě CapitalOne take mluví o tom, že sebelepší automatizace a semknuté týmy nevyloučí možnost chyb. Klienti ale jsou schopni chyby akceptovat, pokud jsou dostatečně rychle opravené. Běžně se pohybují mezi 50-100 commity denně. Gnani Dathathreya, ředitelka Enterprise architecture mluví o možné chybě jako součásti řešení v rámci Continuous Delivery, resp. Continuos Chaos (zdroj).

 

Rabobank

Rabobank se potýkala s problémem pomalého nasazování změn a častými výpadky, způsobenými chybou v nasazované změně. Z nabídek na trhu se rozhodli použít řešení pro Application Release Automation „XL Deploy“ firmy XebiaLabs. Podle prohlášení Rabobank, dříve potřebovali i 4 týdny na nastavení infrastruktury pro požadované změny. Nyní je to otázka hodin. Výsledek: v novém prostředí se daří eliminovat 99% chyb, které se dříve vyskytovaly při releasu nových verzí (zdroj).

 

Nordea

Nordea ve spolupráci s DevOps týmem Accenture přešla do DevOps módu při implementaci nového core-bankingu. Z jejich prohlášení je zřejmé, že změny v technologiích – migrace na novou platformu, byly ten snadnější krok. Mnohem obtížnější bylo definovat a upravit procesy. Nejkomplikovanější bylo změnit chování zaměstnanců. (zdroj a zde).

 

Allianz

Pojišťovací gigant Allianz se rozhodl přejít na DevOps. Pod heslem „digital by default“ nešlo jen o o spojování týmů do DevOps, ale o celkovou digitální transformaci s cílem poskytovat klientům personalizované služby na míru na základě dostupných dat. V rámci digitalizaci Alianz přešla na cloudové služby pod Amazon Web Services (AWS). Ve spolupráci s partnerem Contino celý proces implementace změn maximálně automazovali vč. buildů, testování, bezpečnosti, compliance a monitoringu. Výsledek: změny jsou nasazovány do produkce během 30min, vč. automatického buidu, testování a vlastního nasazení. Jednodušší „microservices“ mohou být dodány do produkce do 1 hodiny! (zdroj)

 

Barclays

I pro Barclays byl „time-to-market“ hlavním důvodem pro přechod na DevOps. Nasadili řešení Red Hat OpenShift Container Platform v rámci Platform-as-a-Service. A vyhráli RedHat Innovation Award 2017 (zdroj).

„Particularly with automation, when you show a colleague how they can stand up a test environment in just a few steps, you don’t need metrics—you can see on their face how happy they are with what the technology can do.“  Stephen Fletcher, DevOps Lead Engineer, Baclays

 

 

Budoucnost 2018

  1. Všichni jsou DevOps. Agilní nestačí. Máme i DevSecOps….
  2. BizDevOps – DevOps přerůstá do celé firmy, rychlejším reakcím na straně vývoje se musejí přizpůsovat také business útvary. Všichni jsou DevOps, byť někde se mluví o BizDevOps
  3. Failure as a service / Chaos engineering – stejně jako Fintech, i systémy bank mohou vykazovat chyby, pokud je budou banky schopny rychle najít a opravit a k tomu, stejně jako Fintech, budou nabízet pružně a rychlé nové služby

(zdroj)

 

Co na to české banky? Která stíhá nasazovat změny denně? Není někde spíše používán po nasazení změny koncept „Ops!“…?

Napsat komentář

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *