DevOps: Shrnutí současného stavu, mýty a problémy
Co přinesl DevOps v současné době? Nahradí či vytlačí ostatní standardy a metodiky pro řízení IT, jako je CobIT či ITIL? „Nedojede“ DevOps na nedostatečnou bezpečnost? Co můžeme čekat do budoucna? Bude DevOps někdy standardizován? Jaké jsou s DevOps často spojované mýty a problémy?
DevOps ITIL DevSecOps State of DevOps
Část VII.
V předposledním dílu celého seriálu si představíme současný stav transformace na DevOps, dopady na řízení firem, časté mýty a typické problémy, se kterými se při implementaci nejčastěji potkáváme.
Současný stav DevOps aneb dosažené výsledky
Zde si stručně shrneme dosavadní výsledky včetně dopadu na business firem.
Co přináší DevOps nového vůči tradičním metodám řízení IT?
Jednoduchá otázka, ale složitá odpověď. Na tu jsme se snažili odpovědět již v předchozích dílech tohoto seriálu. Pokud bychom měli shrnout ty největší rozdíly, ale zároveň i výzvy:
- jednoznačná orientace na zákazníka (value),
- zkracování dob realizace (současně se snižováním nákladů a zajištěním vyšší kvality),
- důraz na inovace a automatizaci (robotizaci),
- nasazení nových modelů businessu, financí a zajišťování podpory IT,
- uplatnění nových typů rolí, procesů, organizačních struktur a stylů řízení,
- uplatnění nových typů alokací lidských zdrojů a procesních/ projektových/produktových přístupů,
- nasazení nových typů podpůrných softwarových nástrojů,
- změna některých zažitých návyků při řízení IT (IaC, CI, CD, CT, CS, pets/snowflakes vs. cattle, cloud, neměnná infrastruktura atd.),
- změna kultury (od sil k spolupráci, komunikaci a sdílení) a další lidské „soft“ i „hard“ dovednosti,
- uplatnění agilních, interaktivních a iterativních přístupů jak ve vývoji, tak i v provozu,
- využití posledních technických a technologických řešení a inovací – cloud, kontejnery, IaaS, SDN,
- nové výzvy, zranitelnosti, ale i metody v oblasti informační bezpečnosti.
Ten seznam samozřejmě není konečný.
Jaký dopad má fakticky transformace na DevOps?
DevOps znamená určitou transformaci firmy v šesti oblastech:
- vytváří zpětnovazební smyčky v pracovním prostředí v oblasti vývoje i provozu; klíčová je komunikace a sdílení znalostí,
- považuje všechny systémy a infrastrukturu za kód (IaC) a zachází s nimi stejně jako se softwarem,
- posouvá kulturu doposud čistě technicky fungující organizace směrem vůči totální dodávce a zkušenosti uživatele (value stream mapping, customer experience) se silným zapojením útvarů businessu,
- zajišťuje daleko rychlejší kadenci rozmisťování softwaru do produkčního prostředí a redukuje změny v dodávkách,
- mění kulturu firmy, organizační a kompetenční struktury a styl práce včetně celkové governance,
- napomáhá digitální transformaci celé firmy a v dlouhodobém kontextu umožňuje přežití na trhu.
Mýty u DevOps
DevOps je stejně jako celá řada dalších nejlepších praktik předmětem častých mýtů. Protože DevOps není nijak standardizován či normalizován jako v případě dalších metodik a standardů (ITIL, CobIT atd.), je tato problematika daleko více ohrožující a může mít velmi významné dopady na rozhodování managementu a v konečném důsledku na úspěch nasazení DevOps ve firmě.
V každém případě je potřeba tyto mýty identifikovat a vysvětlovat zaměstnancům i managementu. Asi nejúčinnějšími nástroji v téhle problematice jsou návštěvy konferencí DevOps či ITSM, školení pro zaměstnance, sebevzdělávání formou studia materiálů na internetu a knížek kolem DevOps (viz poslední díl tohoto seriálu).
Typické problémy a výzvy při implementaci
Kromě mýtů si ještě proberme typické problémy, se kterými se v DevOps potkáváme. Některé z nich mohou plynout z mýtů popsaných v předchozím textu, jiné jsou prostě přirozenou věcí, kterou DevOps jakožto instrument měnící kulturu, procesy, governance a podpůrné nástroje nevyhnutelně přináší. Tím se dostáváme k největší výzvě DevOps – jak to udělat, aby se to povedlo? Toto jsme již částečně probírali v dílu IV. (DSM 2/2019) v rámci implementace, zde to však proberme z pohledu celkové governance.
Stakeholder management (aneb správa zúčastněných stran)
Tohle je velmi důležitá stránka věci. DevOps je multidisciplinární a multitýmová disciplína, která vyžaduje spolupráci, komunikaci a sdílení společného cíle. Pokud budou KPI u jednotlivých osob či celých týmů DevOps stanovena odlišně či budou tito lidé/týmy placeni z různých rozpočtů nebo bude odlišně zajišťována a řízena správa lidských zdrojů (resource management), pak celý koncept DevOps nebude korektně fungovat. Typickými skupinami v tomto kontextu jsou vývojáři, provoz, testeři, zástupci za bezpečnost a za business potažmo za zákazníky.
Důležitou úlohu hraje nejvyšší vedení, a to jak IT, tak i businessu. Nemáme-li jejich podporu, vše je dopředu rovnou ztraceno. Nezapomínejme, že právě seniorní management by měl činit klíčová rozhodnutí, zajistit dostatečný rozpočet a schválit program či jednotlivé projekty realizované v rámci transformace na DevOps.
Vlastnictví, nejasné odpovědnosti
U velkých firem se hodně často potkáváme s určitým alibismem a překryvem či naopak nedostatkem kompetencí a hlavně nejasnou či nestanovenou odpovědností. Opačným problémem také bývá „všelidové“ vlastnictví, tedy situace, kdy při nějakém selhání obviníte celou firmu, Dev i Ops a jakékoli poučení z toho jde zpravidla do ztracena (viz [5]). Co zde určitě potřebujete, je jasné vlastnictví (leader pro DevOps na úrovni minimálně člena boardu, nestačí úroveň CIO), osobní angažovanost jak na straně manažerů, tak i řadových pracovníků. Další „spolehlivou“ cestou do pekel je externí implementace DevOps třetí stranou – to prostě v principu nemůže fungovat (pokud tedy nehodláte outsourcovat celé IT včetně businessu).
Realistické cíle
Velkou výzvou při aplikaci DevOps je nastavení realistických cílů (rozsah, očekávané výstupy a přínosy, finanční prostředky, čas). Častým problémem jsou totálně podstřelené časové a finanční odhady transformace na DevOps. Zde si prosím uvědomme, že se jedná spíše o cestu (journey) než o jednorázovou aktivitu či projekt. DevOps je o změně fungování IT, kultury organizace, stylu práce, a proto vyžaduje u velké firmy spíše několik let k získání zralosti. DevOps značí primárně kulturní změnu a změnu pracovního stylu. Čím větší organizace je, tím déle to bude trvat, protože to vyžaduje vysvětlování, školení a řešení otevřených bodů. Někdy to obnáší i obměnu personálu (ale i části managementu) podle známého hesla „starého psa novým kouskům nenaučíš“.
Nejasné řídící DevOps a organizační struktury
DevOps s sebou často přináší nutnost změnit jak styl řízení (přechod od liniového/procesního/projektového řízení na autonomní týmy a produktové řízení), tak i organizační a kompetenční struktury (např. squads – viz DSM 2/2019). Adekvátně se také mění požadavky na členy týmů i jejich manažery (nebo spíše leadery). Změnu poměrně dobře vystihuje Tab. 2.
Nevhodný výběr lidí
Jako u všech zlepšovacích iniciativ úspěch transformace na DevOps spočívá ve výběru vhodných leaderů (úmyslně nepíši manažerů), ale i členů jednotlivých týmů. O nutnosti se s některými zaměstnanci rozloučit už jsme psali. V každém případě u členů jednotlivých týmů potřebujeme diskutovat o změně jejich profilu (T-shape – viz díl IV., DSM 2/2019), u leaderů je zase nutné určité vůdcovství (Leadership). Direktivní a autoritativní liniový manažer je pro DevOps nepoužitelný.
Interpretace DevOps a agilních metodik jako něco, co nemá jasná pravidla
Agilní metodiky a přístupy se někdy (určitě neprávem) pojímají jako „chaos“, neexistují pevná pravidla, odpovědnosti, nedělá se dokumentace atd. Není to ale úplně pravda. Např. pokud chcete automatizovat některé procesní činnosti v rámci DevOps, musíte pravidla stanovit daleko rigidněji než třeba podle ITIL.
DevOps jako iniciativa IT
Někdy bereme start a rozvoj DevOps spíše pouze jako potřebu útvaru IT, aniž bychom reflektovali reálné potřeby businessu. Takto lze dosáhnout pouze dílčích úspěchů, např. můžeme úspěšně vybudovat agilní SW vývoj, ale nikoli celý rozsah DevOps. Způsobem, jak toho nejlépe docílit, je sdílení společných hodnot a cílů. Toho nejlépe dosáhneme díky společnému (business a IT) plánování a alokaci zdrojů, společné strategii a v neposlední řadě ve společně nastaveném financování.
Bezpečnost a governance
Poměrně často se vyskytujícím problémem je přehlížení bezpečnosti a chybějící nebo nedostatečná governance nad řízením lidí a dodávkami v rámci DevOps. Ačkoli má být DevOps rychlý a agilní, neznamená to běh bez pravidel, ale naopak více pravidel, která jsou ovšem stále více a více vynucována na úrovni podpůrných nástrojů (automatizace).
Nedostatečné testování /špatná kvalita kódu
Testování je oblast, která na jednu stranu velmi značně zrychluje release vyvinutého softwaru (za předpokladu automatizace testů), ale na druhou stranu vytváří celou řadu výzev, jak pokrýt všechny typy testů, kde vzít zkušené a levné testery, jak pokrýt oblasti, které nejdou automatizovat, atd. Řešením je zapojit vývojáře více do testování a nasadit nástroje, které umožní hlídat kvalitu vyvíjeného softwaru, upozorňovat na „škodlivý“ nebo nebezpečný kód a k samotnému vývoji používat příslušné agilní metodiky, jako je např. Test Driven Development/TDD. V oblasti vývoje se pak doporučuje organizovat procedury, jak optimalizovat kód a zvyšovat jeho kvalitu (continuous refactoring, peer review apod.).
Nedostatečná nebo chybějící dokumentace
Toto je téměř klasické téma. Většinový přístup k agilním metodikám je takový, že se podle agilního Manifesta dokumentace prostě nevytvářejí, nebo jen okrajově. Časté je to v případech startupů, kde doposud platilo, že si to prostě lidé pamatují, takže dokumentace není zapotřebí. V momentě, kdy ale startup začíná růst a nabírat nové zaměstnance, se toto stává velkou brzdou. Je to podobné téma jako testování. Naopak u firem typu Enterprise, které doposud aplikovaly nejlepší praktiky à la ITIL (s vytvářením rozsáhlé a často i zbytečné dokumentace), se zase objevuje obrácený postup, že s nasazením agilních metod (a DevOps) se od dokumentace kompletně upouští (často i v oblastech, kde je to nutné, např. Enterprise Architektura). Zradou je, že se neaktuálnost dokumentace zpravidla projeví se zpožděním několik měsíců až let. Řešením je definovat postupy a odpovědnosti, omezit tvorbu dokumentace na nejmenší možnou míru a alespoň částečně automatizovat její vytváření.
Integrace DevOps a ITIL /změna stylu řízení
Další velmi častou výzvou jsou tzv. hybridní týmy (ITIL V3 a DevOps), které fungují odlišným způsobem pro tzv. Bi-Modální IT2 či vícerychlostní správu aplikací (pace-layered application management). Ta první část funguje postaru podle ITIL V2/3 a ta druhá podle DevOps, resp. spíše její vývojová a testovací část podle agilních přístupů a část Operations podle ITIL. Tedy zkoušíme něco jako „kočkopsa“ – snaha zachovat tradiční separované Dev a Ops organizační sila a přitom se pokoušet je řídit agilně. Tady se dá získat pár bodů v oblasti rychlejšího vývoje a automatizovaného testování, možná i rychlejšího vývoje kódu, ale nikoli u provozu. Vzhledem k faktu, že se tyto týmy/skupiny potkávají nad sdílenou infrastrukturou a velmi často i používají stejný podpůrný nástroj, je častou výzvou obě alternativy skloubit [2]. Moje vlastní zkušenost s použitím hybridních přístupů je spíše negativní; většinou to nefunguje.
Podniková architektura a standardizace
Dalším potenciálním problémem je chybějící podniková architektura (Enterprise Architecture/EA), konkrétně v kontextu budování nativních aplikací pro cloud (cloud native applications), znovu využívání částí kódu (Microservices) a určité standardizace, kterou DevOps určitě přináší. Všechny tyto věci vyžadují dost vysokou zralost, čehož nejde bez EA adekvátně dosáhnout.
Vzdělávání, školení na DevOps
Důležitou součástí transformace firem na DevOps je vzdělávání zaměstnanců. Řešíme tak mnohdy chybějící expertízu, přehledové znalosti v oblasti CI/CD (T-shape), nedostatečné zkušenosti a znalosti, ale také budování systému zajišťujícího motivaci zaměstnanců viz [1].
Kulturní aspekty
Toto je aspekt, který je snad nejvíce ignorován (specificky na úrovni nejvyššího managementu) a zanedbáván; aspekt, kde se asi dělá nejvyšší počet chyb a kvůli kterému celá řada pokusů o zvládnuté DevOps buďto úplně selže, nebo nepřináší plné výsledky. Některé poradenské firmy (viz [2]) vypichují důležitost řešení kultury ve firmách, ITIL 4 na toto téma zavádí novou praktiku zvanou Organizational Change Management. Velmi častým problémem v kontextu kultury organizace je prostě neochota se změnit. Potkáváme se s tím ve všech větších a historicky déle existujících organizacích – „resistance to change“ je prostě typická forma obrany před čímkoli novým, neznámým. Toto specificky platí pro provoz IT.
Komunikace a spolupráce
Hodně důležitou a ožehavou věcí je komunikace – alfa-omega úspěchu DevOps (viz Box 2). Týká se to spolupráce týmů a organizačních jednotek, lokalit, zemí či kontinentů, používání referenčního jazyka (zpravidla angličtina), kulturních a národních rozdílů, používání společného podpůrného nástroje (chat, Skype, Webex), formy a frekvence komunikace, ochoty dávat a reagovat na zpětnou vazbu a dalších faktorů.
Podpůrné nástroje pro DevOps
A konečně posledním (nikoli však významem) bodem je úloha podpůrných SW nástrojů, na které se „implementace DevOps“ někdy zvrhne. Vy tyto nástroje určitě potřebujete, o tom není pochyb, ale není to ten nejdůležitější faktor – tím hlavním jsou určitě lidé (viz [3]). U nástrojů se soustřeďte na automatizaci (včetně integrací), uživatelskou přívětivost, žádnou customizaci, zjednodušování procesů a eliminaci duplicitních nástrojů.
Automatizace pro automatizaci
Někdy máme tendenci hledat automatizovaná řešení i pro případy, které provádíme v jednotkách aktivit za rok. To není efektivní – vždy zvažujme náklady vs. reálné přínosy. Nesnažte se automatizovat aktivity, které provádíte zřídkakdy. Dávejme si pozor na „automatizovaná sila“ – uspořádání podpůrných softwarových nástrojů, které zná jen dodavatel, popř. úzký okruh vašich expertů.
Závěr
V posledním, osmém díle si všechny předchozí díly shrneme, uvedeme si další zdroje a literaturu a celý seriál zakončíme závěrečnými doporučeními.
Poznámky pod čarou:
- Dodávejte často.
- Termín společnosti Gartner rozdělující aplikační portfolio na mód 1 (systems of records) a mód 2 (systems of innovations).
- Např. podporující chat a instant messaging.
Použité zdroje:
[ 1 ] Periodická tabulka nástrojů DevOps, XebiaLabs, dostupné online na https://xebialabs.com/periodic-table-of-devops-tools/
[ 2 ] Axelos, dostupné z https://www.axelos.com/news/blogs/february-2017/bi-modal-two-speed-it-chaos-with-agile-projects či https://www.axelos.com/news/blogs/june-2016/integrating-devops-into-the-itil-orthodoxy
[ 3 ] The secrets of DevOps success, Gartner, dostupné z https://www.gartner.com/smarterwithgartner/the-secret-to-devops-success/
[ 4 ] Forrester, 2018: The Year Of Enterprise DevOps, dostupné z https://go.forrester.com/blogs/2018-the-year-of-enterprise-devops/
[ 5 ] Dev vs. Ops: The State of Accountability, dostupné z https://devops.com/wp-content/uploads/2019/04/dev-vs-ops-state-of-accountability-pdf-original.original.pdf
