Je těžké pochopit podstatu věci, když mluvíte o DevOps? Shromáždili jsme pro vás jasné analogie, úderné formulace a rady od odborníků, které pomohou pochopit podstatu i těm, kteří nejsou specialisty. Na závěr bonus – vlastní DevOps zaměstnanců Red Hat.
Termín DevOps vznikl před 10 lety a prošel cestou od hashtagů na Twitteru k mocnému kulturnímu hnutí v IT, skutečné filozofii, která podporuje vývojáře k rychlejšímu dosahování výsledků, experimentování a postupu vpřed metodou iterací. DevOps se stal neoddělitelně spojen s pojmem digitální transformace. Ale jak už to často v IT terminologii bývá, za deset let si DevOps získal množství definic, výkladů a omylů.
Proto se o DevOps často lze slyšet otázky jako, je to to samé jako agilní? Nebo je to nějaká zvláštní metodologie? Anebo je to prostě další synonymum pro slovo „spolupráce“?
DevOps zahrnuje spoustu různých konceptů (nepřetržitá dodávka, nepřetržitá integrace, automatizace atd.), takže je obtížné vyčíslit to hlavní, zvlášť pokud vám na tématu záleží. Nicméně, tato dovednost je velmi užitečná, ať už se snažíte sdělit své myšlenky nadřízeným nebo jen vyprávíte o své práci někomu blízkému. Proto nyní odložme terminologické nuance DevOps a soustřeďme se na celkový obraz.
Co je DevOps: 6 definic a analogií
Požádali jsme odborníky, aby co nejjednodušeji a nejstručněji vysvětlili podstatu DevOps, aby byla její hodnota srozumitelná čtenářům s jakoukoliv technickou přípravou. Na základě těchto rozhovorů jsme vybrali nejjasnější analogie a úderné formulace, které vám pomohou vyprávět svůj příběh o DevOps.
1. DevOps – to je kulturní hnutí
„DevOps je kulturní hnutí, v rámci kterého obě strany (vývojáři softwaru a specialisté na IT systémy) uznávají, že software nepřináší skutečné výhody, dokud ho nezačne někdo používat: zákazníci, klienti, zaměstnanci, na tom nezáleží,“ říká Eveline Oehrlich, senior analytik výzkumného institutu DevOps. „Proto obě strany společně zajišťují rychlou a kvalitní dodávku softwaru.“
2. DevOps – to je něco, co dává moc vývojářům
«DevOps dává vývojářům pravomoc vlastnit aplikace, jejich nasazení a řízení dodávky od začátku až do konce»
«Obvykle se o DevOps mluví jako o způsobu, jak urychlit dodávku aplikací do produkce díky budování a zavádění automatizovaných procesů, – říká Jai Schniepp, ředitel pro DevOps platformy v pojišťovací společnosti Liberty Mutual. – Pro mě je to však něco mnohem fundamentálnějšího. DevOps dává vývojářům pravomoc vlastnit aplikace nebo určité části softwaru, jejich nasazení a řízení dodávky od začátku až do konce. DevOps odstraňuje zmatek v odpovědnosti a vede všechny účastníky procesu k vytvoření automatizované a vývojářem řízené infrastruktury.»
3. DevOps je spolupráce při vytváření a dodávce aplikací
«Jednoduše řečeno, DevOps je přístup k výrobě a dodávce softwaru, kdy všichni pracují společně,» uvádí Gur Staf, prezident a vedoucí divize automatizace digitálního podnikání ve společnosti BMC.
4. DevOps je výrobní linka
«Výroba na lince je možná pouze tehdy, když všechny části do sebe zapadají.»
«Srovnal bych DevOps s montážní linkou automobilů, – pokračuje Gur Staf. – Myšlenkou je navrhnout a vyrobit všechny díly tak, aby je bylo možné bez individuální úpravy sestavit. Výroba na lince je možná pouze tehdy, když všechny části do sebe zapadají. Ti, kdo navrhují a vyrábějí motor, musí zvážit, jak ho připevnit k tělu nebo rámu. Ti, kdo vyrábějí brzdy, musí myslet na kola, a tak dále. Stejně tak by to mělo fungovat i se softwarem.»
Vývojář, který vytváří obchodní logiku nebo uživatelské rozhraní, by měl zvážit databázi, která uchovává informace o zákaznících, prostředky zabezpečení na ochranu uživatelských dat, a také to, jak to vše bude fungovat, když služba začne obsluhovat velké, možná i mnohamilionové publikum uživatelů.»
„Udělat to, aby lidé spolupracovali a přemýšleli o těch částech práce, které vykonávají ostatní, a ne soustředili se výhradně na své vlastní úkoly – to je největší překážka, kterou je třeba překonat. Pokud se to podaří, máte skvělé šance na digitální transformaci,“ dodává Gur Staf.
5. DevOps je správná kombinace lidí, procesů a automatizace.
Jane Groll, výkonná ředitelka Institutu DevOps, navrhla skvělou analogii k vysvětlení DevOps. Podle ní je „DevOps jako recept na vaření, ve kterém jsou tři hlavní kategorie ingrediencí: lidé, procesy a automatizace. Většinu těchto ingrediencí lze čerpat z jiných oblastí a zdrojů: Lean, Agile, SRE, CI/CD, ITIL, vedení, kultura, nástroje. Tajemství DevOps, stejně jako jakéhokoli dobrého receptu, spočívá v tom, jak správně skloubit poměry a smíchat tyto ingredience, aby se zvýšila rychlost a výkonnost práce při vytváření a vydávání aplikací.“
6. DevOps je, když programátoři pracují jako tým formule 1.
„Závod se plánuje nikoli od startu k cíli, ale naopak, od cíle ke startu.“
„Když mluvím o tom, co očekávat od iniciativy DevOps, dávám příklad závodnímu týmu NASCAR nebo formule 1,“ říká Chris Short, hlavní marketingový manažer cloudových platforem Red Hat a vydavatel newsletteru DevOps’ish. „Cílem vedoucího takového týmu je dosáhnout co nejlepšího umístění na závodě vzhledem k dostupným zdrojům a výzvám, které tým čelil. Závod se plánuje nikoli od startu k cíli, ale naopak, od cíle ke startu. Nejprve se stanoví ambiciózní cíl a poté se určí cesty k jeho dosažení. Následně se rozdělí na úkoly a delegují členům týmu.“
„Celý týden před závodem tým zdokonaluje pitstop. Zaměřuje se na silové a kardio tréninky, aby byl ve formě v náročný závodní den. Procvičuje společné akce při řešení jakýchkoli problémů, které mohou během závodu nastat. Podobně by se týmy vývojářů měly vytrénovat ve schopnostech častého vydávání nových verzí. S těmito dovednostmi a propracovaným bezpečnostním systémem probíhá nasazení nových verzí do produkce častěji. V rámci této filozofie znamená růst rychlostí také růst bezpečnosti,“ říká Short.
„Není to o tom dělat ‚správné věci‘,“ dodává Short, „ale o tom odstranit co nejvíce překážek, které stojí v cestě k žádoucímu výsledku. Spolupracujte a přizpůsobujte se na základě zpětné vazby, kterou dostáváte v reálném čase. Buďte připraveni na anomálie a pracujte na zvyšování kvality, abyste minimalizovali jejich vliv na cestu k cíli. Přesně to nás čeká ve světě DevOps.“
Jak škálovat DevOps: 10 rad od expertů
Jednoduchý DevOps a masový DevOps jsou zcela odlišné věci. Povědíme vám, jak překonat překážky na cestě od prvního k druhému.
Pro mnohé organizace začíná cesta k DevOps snadno a příjemně. Vytvářejí se malé nadšené týmy, staré procesy jsou nahrazovány novými a první úspěchy na sebe nenechají dlouho čekat.
Bohužel, je to jen falešný lesk, iluze pokroku, jak říká Ben Grinnell, výkonný ředitel a vedoucí digitálních technologií konzultační firmy North Highland. Ranné vítězství samozřejmě povzbuzuje, ale nepomáhá dosáhnout konečného cíle, a to masového využívání DevOps v organizaci.
Je snadné vidět, že jako výsledek se formuje kultura rozdělení na ‚my‘ a ‚oni‘.
„Často organizace spouštějí projekty-pionýry s přesvědčením, že otevřou cestu k rozsáhlému DevOps, aniž by uvažovaly, zda to ostatní chtějí a mohou následovat,“ vysvětluje Ben Grinnell. „Týmy pro realizaci takových projektů bývají obvykle složeny z přehnaně sebevědomých 'vikingů', kteří už něco podobného dělali jinde, ale jsou v vaší organizaci nováčky. Povzbuzují se, aby porušovali a ničili pravidla, která zůstávají závazná pro všechny ostatní. Je snadné vidět, že výsledkem je kultura rozdělení na 'my' a 'oni', která brání předávání znalostí a dovedností.“
„A tento kulturní problém je jen jedním z důvodů, proč je DevOps obtížné škálovat. Týmy DevOps čelí rostoucím technickým obtížím charakteristickým pro rychle se rozvíjející firmy, které vsadily na IT technologie,“ říká Steve Newman, zakladatel a předseda představenstva společnosti Scalyr.
„V moderním světě se služby mění okamžitě, jakmile je to potřeba. Neustále uvádět do provozu a implementovat nové funkce je sice skvělé, ale koordinovat tento proces a odstraňovat vzniklé problémy – to je skutečný hlavolam,“ dodává Steve Newman. „Ve velmi rychle rostoucích organizacích se inženýři v rámci cross-funkčních týmů snaží udržet si možnost sledovat změny a kaskádové účinky, které tyto změny přinášejí na úrovni závislostí. Navíc inženýry rozhodně netěší, když jsou o tuto možnost ochuzeni a tím pádem jim přestává být jasné podstata vznikajících problémů.“
Jak překonat uvedené potíže a přejít k masovému využívání DevOps ve velké organizaci? Odborníci vyzývají, abyste měli trpělivost, i když vaším konečným cílem je urychlit cyklus vývoje softwaru a obchodní procesy.
1. Nezapomeňte, že změny v kultuře vyžadují čas
Jayne Groll, výkonná ředitelka Institutu DevOps: Podle mého názoru by zavádění DevOps mělo být stejně postupné a iterativní jako agile vývoj (a také by mělo do značné míry ovlivnit kulturu). V Agile a DevOps se klade důraz na malé týmy. Ale s růstem počtu a integrací těchto týmů se setkáváme s čím dál více lidmi, kteří aplikují nové pracovní metody, což následně vede k rozsáhlé kulturní transformaci.
2. Vyhraďte dostatek času na plánování a výběr platformy
Eran Kinsbruner, hlavní technický evangelista společnosti Perfecto: Aby bylo škálování úspěšné, musí se týmy DevOps zprvu naučit kombinovat tradiční procesy, nástroje a dovednosti, a poté pomalu rozvíjet každou jednotlivou fázi DevOps a stabilizovat ji. Všechno začíná důkladným plánováním uživatelských příběhů a toků vytváření hodnoty, po čemž následuje fáze psaní softwaru a správy verzí s použitím trunk-based development nebo jiných přístupů, které jsou nejvhodnější pro větvení a slučování kódu.
Následuje fáze integrace a testování, kdy už je třeba škálovatelná platforma pro automatizaci. A zde je pro týmy DevOps důležité zvolit správnou platformu, která by odpovídala jejich úrovni dovedností a konečným cílům projektu.
Další fází je nasazení do prostředí produkce, které musí být plně automatizováno s využitím orchestrace a kontejnerových nástrojů. Je také důležité mít virtualizovaná prostředí ve všech fázích DevOps (simulátor produkčního prostředí, prostředí kontroly kvality a opravdu produkční prostředí) a vždy používat pro testování pouze nejnovější data, aby bylo možné získávat aktuální závěry. Analytika by měla být inteligentní a schopná zpracovávat velká data s rychlou a užitečnou zpětnou vazbou.
3. Odpovědnost zbavte chuti viny
Gordon Haff, evangelista RedHat: Vytvoření systému a atmosféry, která umožňuje a podporuje experimenty, umožňuje dosáhnout takzvaných úspěšných selhání v agile vývoji softwaru. Neznamená to, že za selhání nikdo neodpovídá. Ve skutečnosti je pro určení odpovědného subjektu ještě snadnější, protože «být odpovědný» nyní neznamená «stát se viníkem havárie». Tedy podstata odpovědnosti se kvalitativně mění. Přitom jsou extrémně důležité čtyři faktory: rozsah selhání, přístupy, výrobní procesy a pobídky. (Více o těchto faktorech si můžete přečíst v článku Gordona Haffa „DevOps lessons: 4 aspects of healthy experiments“.)
4. Uvolněte cestu vpřed
Ben Grinnell, managing director a vedoucí digitálních technologií v poradenské firmě North Highland: „Abychom dosáhli rozšíření, doporučuji spustit program 'uvolňování cesty' společně s projekty průkopníků. Cílem tohoto programu je odstraňovat nepořádek, který zůstává za průkopníky DevOps, jako jsou zastaralé pravidla a další podobné věci, aby cesta vpřed zůstala volná.“
„Dejte lidem organizační podporu a podnítíte to prostřednictvím komunikace, která daleko přesahuje skupinu průkopníků, široce oslavujete úspěchy nových pracovních metod. Školte lidi, kteří se zapojují do další vlny projektů DevOps a bojí se, protože DevOps používají poprvé. A pamatujte, že tito lidé se výrazně liší od průkopníků.“
5. Zpřístupněte nástroje pro všechny
Steve Newman, zakladatel a předseda představenstva firmy Scalyr: „Nástroje by neměly být lidem skryty, a měly by být relativně snadné k osvojení pro kohokoliv, kdo je ochoten tomu věnovat čas. Pokud mají možnost požadovat logy jen tři lidé 'certifikovaní' pro práci s nějakým nástrojem, vždy budete mít maximálně tři lidi schopné se vypořádat s příslušným problémem, i když máte velmi velké výpočetní prostředí. Jinými slovy, zde vzniká úzké hrdlo, které může mít vážné (pro podnikání) důsledky.“
6. Vytvořte ideální podmínky pro práci týmu
Tom Clark, vedoucí divize Common Platform ve společnosti ITV: „Můžete dělat cokoliv, ale ne všechno najednou. Proto si stanovte velké cíle, začněte s malými kroky a postupujte vpřed rychlými iteracemi. V průběhu času si vybudujete reputaci týmu, kterému se daří, a ostatní budou chtít také využívat vaše metody. A neusilujte o vybudování vysoce efektivního týmu. Místo toho zajistěte lidem ideální pracovní podmínky a efektivita přijde sama.“
7. Nezapomínejte na Conwayův zákon a kanbanové tabule
Logan Daigle, ředitel pro dodávku softwaru a strategii DevOps společnosti CollabNetVersionOne: „Je důležité si uvědomit důsledky Conwayova zákona. Ve své volné interpretaci říká, že produkty, které vytváříme, a procesy, které používáme, včetně DevOps, jsou uspořádány stejně, jako je uspořádána naše organizace.“
„Pokud je v organizaci vysoká míra rozdělenosti a řízení se při plánování, vytváření a vydávání softwaru mnohokrát mění z rukou do rukou, efekt od škálování bude nulový nebo krátkodobý. Pokud však organizace vytvoří křížově funkční týmy okolo produktů, které jsou financovány s ohledem na trh, šance na úspěch se radikálně zvyšují.“
„Dalším důležitým aspektem škálování je zobrazování všech prací, které jsou v procesu provádění (WIP, work in progress), na kanbanových tabulích. Když se v organizaci objeví místo, kde lidé mohou vidět takové věci, výrazně to podněcuje spolupráci, což má pozitivní vliv na škálování.“
8. Hledejte staré jizvy
Manuel Pais, konzultant pro DevOps a spoluautor knihy „Team Topologies“: „Vytahování praktik DevOps za hranice samotného Dev a Ops a pokus o jejich aplikaci na jiné funkce rozhodně nelze považovat za optimální přístup. To jistě přinese určitý efekt (například tím, že zautomatizujete ruční řízení), ale můžete dosáhnout mnohem více, pokud začnete s porozuměním procesům dodávky a zpětné vazby.“
Pokud má IT systém organizace staré jizvy – postupy a mechanismy řízení, které byly zavedeny v důsledku minulých incidentů, ale ztratily svůj význam (kvůli změně produktů, technologií nebo procesů), je třeba je bezpochyby odstranit nebo vyhladit, a nikoli automatizovat neefektivní nebo nepotřebné procesy.
9. Nezvětšujte varianty DevOps
Antony Edwards, ředitel výroby společnosti Eggplant: „DevOps je velmi vágní termín, a proto má každý tým svou vlastní variantu DevOps. A není nic horšího, než když se v organizaci objeví hned 20 různých variant DevOps, které spolu příliš dobře nesouzní. Není možné, aby každé ze tří vývojových týmů mělo svůj vlastní, specifický rozhraní mezi vývojem a řízením produktu. Stejně tak není možné, aby produkty měly svá, jedinečná očekávání ohledně zpracování zpětné vazby při přenosu do simulátoru výrobního prostředí. Jinak se vám nikdy nepodaří škálovat DevOps.
10. Hlavně propagujte hodnotu DevOps pro byznys
Steve Newman, zakladatel a předseda představenstva firmy Scalyr: „Pracujte na uznání hodnoty DevOps. Naučte se a nebojte se hovořit o výhodách toho, co děláte. DevOps neuvěřitelně šetří čas a peníze (stačí si pomyslet: méně prostoje, kratší průměrná doba obnovy), a týmy DevOps by měly neúnavně zdůrazňovat (a propagovat) význam těchto iniciativ pro úspěch podnikání. Tím můžete rozšířit okruh příznivců a posílit vliv DevOps v organizaci.
BONUS
Na 13. září dorazí náš vlastní DevOps – ano, Red Hat, jako výrobce softwaru, má své vlastní DevOps týmy a praktiky.
Náš inženýr Mark Birger, který se zabývá vývojem služeb vnitřní automatizace pro další týmy v celé organizaci, vám v čisté češtině poví svůj příběh – jak DevOps tým Red Hat migroval aplikace z virtuálních prostředí Hat Virtualization, spravovaných Ansible, do plnohodnotného kontejnerového formátu na platformě OpenShift.
Ale to není všechno:
Poté, co organizace převedly pracovní zátěže do kontejnerů, tradiční metody monitorování aplikací nemusí fungovat. V druhé zprávě vysvětlíme naši motivaci ke změně způsobu zaznamenávání a ukážeme pokračování cesty, která nás dovedla k moderním metodám vedení záznamů a monitorování.
Zdroj: habr.com
