Close

DevOps: Prolomení bariéry mezi vývojem a provozem

Co znamená DevOps?

DevOps nám přináší konkurenční výhodu

„Koncepce DevOps nám umožnila vydávat často nové verze, čímž jsme získali náskok v rychlosti uvádění produktů na trh. Nyní můžeme vydávat verze produktů denně, zatímco dříve jednou za 6 měsíců, a vynucené opravy můžeme našim zákazníkům rozesílat v rozmezí několika hodin.“

— Hamesh Chawla, technický viceprezident společnosti Zephyr

DevOps je sada postupů, která automatizuje procesy mezi vývojem softwaru a týmy IT, aby mohly tyto týmy sestavovat, testovat a vydávat software rychleji a spolehlivěji. Koncepce DevOps je založena na vybudování kultury spolupráce mezi týmy, které v minulosti pracovaly v relativní izolaci. Mezi očekávané výhody patří vyšší důvěra, rychlejší vydávání verzí softwaru, schopnost rychle řešit kritické chyby a lepší řízení neplánované práce.

Výraz DevOps je ve společnosti Atlassian druhou nejznámější složeninou hned po slově Brangelina (Brad Pitt a Angelina Jolie) a představuje spojení toho nejlepšího z vývoje softwaru (dev) a IT provozu (ops). Ale stejně jako u našich vtipů je třeba ještě dodat nějaké vysvětlení. 

Ve své podstatě je DevOps kultura, hnutí a filozofie.

Jde o pevný stisk ruky mezi vývojem a provozem, který zdůrazňuje změnu v myšlení, lepší spolupráci a těsnější integraci. Spojuje agilitu, kontinuální dodávání, automatizaci a mnoho dalšího, a tím pomáhá vývojářským a provozním týmům zvýšit jejich efektivitu, urychlit inovace a poskytovat firmám a zákazníkům kvalitnější služby.

Historie DevOps

Hnutí DevOps se začalo formovat zhruba mezi lety 2007 a 2008, kdy komunity IT provozu a vývoje softwaru začaly nahlas mluvit o tom, v čem vidí hlavní příčiny selhávání v tomto odvětví.

Přístup DevOps se zformuloval jako protiváha k tradičnímu modelu vývoje softwaru, který předpokládal, že tvůrci kódu jsou organizačně a funkčně nezávislí na těch, kdo provádějí nasazení a podporu tohoto kódu.

Vývojáři a provozní IT odborníci měli odlišné (často protichůdné) cíle, byli v jiných odděleních s jiným vedením, měli jiné klíčové ukazatele výkonu, podle kterých byla posuzována jejich práce, a často sídlili v jiných patrech nebo přímo v jiných budovách. Výsledkem byly izolované týmy soustředěné pouze na práci „na vlastním písečku“, dlouhé přesčasy, nekvalitní vydané verze a nespokojení zákazníci.

Z toho vyrostlo přesvědčení, že by vše mohlo fungovat lépe. Tyto dvě komunity se sešly a začaly spolu hovořit – přičemž hlavními motory konverzace byli lidé jako Patrick Dubois, Gene Kim a John Willis.

To, co vzniklo na online fórech a místních setkáních, je nyní hlavním současným tématem diskuzí týkajících se softwaru, což může být i důvod, který vás sem přivádí. Vy a váš tým pociťujete těžkosti v důsledku izolace týmů a nefunkčních komunikačních kanálů v rámci společnosti.

Využíváte metodologie agile k plánování a vývoji, ale stále bojujete s tím, abyste kód dokončili bez zbytečného dramatu. Již jste o DevOps a jeho magickém účinku na týmy něco slyšeli a rádi byste využili „něco z této zázračné strategie“.

Špatnou zprávou je, že DevOps není magický lék na všechny problémy a transformace to nestane přes noc. Dobrou zprávou je, že není nutné čekat, až se nejvyšší management odhodlá k rozsáhlé iniciativě shora. S pochopením základních hodnot DevOps se váš tým může vydat na cestu DevOps ihned prostřednictvím malých, postupných změn. Podívejme se podrobně na každou z těchto výhod.

Infrastruktura jako kód nám umožnila sestavovat 10x více buildů, aniž bychom náš tým posílili o další osoby. – Michael Knight, specialista vytváření buildů ve společnosti Atlassian

Jaký bude přínos pro vás?

Spolupráce a důvěra

Kultura je v DevOps nejdůležitějším faktorem. Základem každého vysoce výkonného týmu DevOps je budování kultury společné odpovědnosti, transparentnosti a rychlejší zpětné vazby.

Týmy, které pracují izolovaně, nezapadají do koncepce „systémového myšlení“ DevOps. „Systémové myšlení“ spočívá v tom, že si uvědomíme nejen to, jak naše činnost ovlivňuje tým, ale také všechny ostatní týmy podílející se na procesu vydání produktu. Nedostatečný přehled a rozdělení úkolů vede k nedostatku plánování závislostí, špatně nastaveným prioritám, svalování viny na druhé a postoji typu „to není náš problém“. Výsledkem je nižší tempo práce a nedostatečná kvalita. DevOps znamená změnu v myšlení – spočívá v holistickém pohledu na proces vývoje a v odstranění překážek mezi vývojem a provozem.

Rychlejší vydávání verzí a chytřejší pracovní postupy

Rychlost je vším. Týmy, které praktikují koncepci DevOps, vydávají nové verze častěji a s vyšší kvalitou a stabilitou.

Nedostatek automatizovaných testovacích a kontrolních cyklů blokuje vydávání nových produkčních verzí a dlouhé časy odezvy na incidenty ničí pružnost a sebedůvěru týmu. Různorodost nástrojů a procesů zvyšuje provozní výdaje, vede k přecházení od úkolu k úkolu a zpomaluje tempo práce. Automatizací a použitím standardizovaných nástrojů a procesů mohou týmy zvýšit svou produktivitu a dosáhnout častějších vydání nových verzí produktů s menším počtem problémů.

Zkraťte dobu vyřešení problému

Tým, který má rychlou zpětnou vazbu, má otevřenou rychlou cestu k úspěchu.Plná transparentnost a hladká komunikace bez zbytečných překážek umožňují týmům DevOps minimalizovat prostoje a řešit požadavky rychleji než kdy dříve.

Pokud nejsou kritické požadavky řešeny rychle, projeví se to negativně na spokojenosti zákazníků. Při nedostatku otevřené komunikace mohou klíčové požadavky a problémy „uvíznou“ na půli cesty mezi týmy, což pak u týmů vede ke zvýšenému napětí a frustraci. Otevřená komunikace pomáhá vývojovým a provozním týmům dodat k požadavkům všechny podstatné připomínky, řešit incidenty a vydávat nové verze rychleji.

Lepší řízení neplánované práce

S neplánovanou prací se setkává každý tým a tato skutečnost má vliv na jeho produktivitu. Prostřednictvím zavedených procesů a jasných priorit mohou vývojářské a provozní týmy lépe řídit neplánovanou práci a současně se soustředit na plánovanou práci.

Přenášení neplánované práce s vysokou prioritou mezi různými týmy a systémy je neefektivní a samozřejmě odvádí pozornost od aktuální činnosti. S vyšší viditelností a proaktivní retrospektivou však týmy mohou neplánované práce lépe předvídat a sdílet mezi sebou.

Kultura

Pokud bychom měli charakterizovat kulturu DevOps jedním slovem, byla by to „spolupráce“. Kdybychom to mohli rozvést o trochu více, mluvili bychom o „spolupráci mezi různými funkcemi/rolemi“. (Ale nebudeme se tu snažit o zbytečně stručnou definici.)

Veškeré nástroje a automatizace využívané ve světě jsou zbytečné, pokud je nedoprovází skutečná snaha o spolupráci ze strany IT vývojářů a provozních pracovníků. DevOps neřeší problémy s nástroji. Zabývá se problémy na straně lidského faktoru. Je nepravděpodobné, že jednoho dne vyjdete ze své kanceláře, rozhlédnete se a zjistíte, že najednou týmy ve vaší společnosti žijí kulturou DevOps. Můžete však dělat pár jednoduchých věcí, abyste podpořili její rozvoj.

Přístup DevOps je podobný agile, ale zahrnuje i provoz. Vytváření projektově nebo produktově orientovaných týmů nahrazujících týmy zformované pro jednotlivé funkce je krok správným směrem. Začleňte vývoj, kontrolu kvality, správu produktů, design provoz a jakékoli další dovednosti, které daný projekt vyžaduje. Ve společnosti Atlassian do našich produktových týmů zapojujeme i marketing.

Jen málo věcí dokáže podpořit spolupráci tak jako sdílení společného cíle a nutnost dosáhnout ho společnými silami. V některých společnostech je náhlý přechod na projektově orientované týmy příliš radikálním krokem. Lze postupovat i po menších krocích. Vývojové týmy mohou (a měly by) přizvat vhodné členy provozního týmu na plánování sprintů, denní standup porady a ukázky sprintů. Provozní týmy mohou pozvat klíčové vývojáře. Takto budou mít týmy přirozeně přehled o projektech, námětech a problémech ostatních. Čas strávený nasloucháním druhým a vzájemným sdílením zkušeností se bohatě vrátí ve formě efektivnější správy verzí a řešení mimořádných událostí.

A když už jsme u toho, mimořádné události jsou skutečným testem kultury DevOps. Dokážou vývojáři, provozní pracovníci a zákaznická podpora rychle a efektivně spolupracovat na problému a vyřešit jej jako tým? Předpokládá každý od počátku, že jeho kolegové učinili nejlepší možná rozhodnutí na základě jim dostupných informací a zdrojů? Přináší následná analýza incidentu spíše opravy procesů, místo aby se zvrhávala v pátrání po viníkovi? Pokud je odpověď Ano, je to dobrým ukazatelem, že váš tým vnitřně funguje s kulturou DevOps.

Nejúspěšnější společnosti využívají principy DevOps napříč všemi odděleními a na všech úrovních organizační struktury. Mají otevřené komunikační kanály a pravidelně spolu hovoří. Zajišťují tak, aby byly cíle všech zúčastněných v souladu, a v případě potřeby provádějí nutné úpravy. Předpokládá se, že spokojenost zákazníků nese stejnou odpovědnost správa produktů i vývojový tým. Chápou, že DevOps není úkolem jednoho týmu. Je to úkol pro všechny.

Automation

Investice do automatizace eliminuje repetitivní manuální práci, přináší opakovatelné procesy a vytváří spolehlivé systémy.

Automatizace buildů, testování, nasazení a zřizování jsou obvyklými počátečními body u týmů, které toto dosud nezavedly. Jaký může být lepší důvod ke spolupráci vývojářů, testerů a provozních pracovníků než vytváření systémů, které budou užitečné pro všechny?

Týmy začínající s automatizací obvykle nejdříve přistoupí ke kontinuálnímu dodávání: praxe, kdy každá změna kódu nejprve prochází automatickými testy, často usnadněnými použitím cloudové infrastruktury, následně se vytvoří balíček úspěšných buildů a to je předáno do produkce s použitím automatického nasazení. Jak asi tušíte, zavedení kontinuálního dodávání není rychlý ani snadný proces, návratnost investic však stojí za to.

Proč? Počítače provádějí testy důsledněji a přesněji než lidé. Tyto testy zachycují chyby a nedostatky v zabezpečení dříve, čímž umožňují vývojářům je snadněji opravit. A automatizovaná nasazení upozorňují IT a provozní pracovníky na přesun mezi prostředími na serveru, aby se předešlo překvapením při vydání nové verze.

Dalším významným příspěvkem DevOps je myšlenka „konfigurace jako kódu“. Vývojáři se snaží vytvářet modulární a rozšiřitelné aplikace, protože jsou spolehlivější a snadněji udržovatelné. Stejné uvažování lze ale rozšířit i na hostující infrastrukturu. Nezáleží ani na tom, zda jde o cloud nebo o síť společnosti.

Je pravdou, že systémy se stále mění. Můžeme však vytvořit fasádu neměnnosti použitím kódu pro zřizování, takže opětovné zřízení postiženého serveru bude rychlejší než jeho oprava, nemluvě o tom, že bude i spolehlivější. Také se sníží riziko. Jak vývoj i provoz mohou prostřednictvím tohoto kódu pro zřizování integrovat nové jazyky nebo technologie a vzájemně sdílet aktualizace. Problémy s kompatibilitou se pak projeví ihned a ne až na půli cesty procesu vydání nové verze.

„Konfigurace jako kód“ a „trvalé dodávání“ nejsou jedinými typy automatizace ve sféře DevOps, ale stojí za zvláštní zmínku, protože pomáhají prolomit bariéru mezi vývojem a provozem. A pokud DevOps používá automatizovaná nasazení k odesílání důkladně testovaného kódu do identicky zřízených prostředí, nemusíte řešit záležitosti typu „Ale tady u mě to funguje“.

Štíhlá metodika

Když slyšíme o šetření v kontextu softwaru, obvykle si představíme eliminaci aktivit s nízkou hodnotou a rychlý postup – spěch a agilitu. Pro přístup DevOps jsou ještě relevantnější koncepce neustálého zlepšování a vyrovnání se s chybami.

Myšlení DevOps vidí všude příležitosti k neustálému zlepšování. Některé jsou zřejmé, například pravidelné retrospektivní analýzy, které pomáhají zlepšovat týmové procesy. Jiné jsou méně nápadné, jako A/B testování různých přístupů k zaškolování nových uživatelů produktu.

Díky vývoji agile se myšlenka neustálého zlepšování stala součástí mainstreamu. První týmy, které přešly na metodiku agile, prokázaly, že jednoduchý produkt v rukách zákazníka dnes je cennější než dokonalý produkt u zákazníka za šest měsíců. Pokud je produkt trvale vylepšován, zákazníci se neodvrátí.

A představte si, že ať děláte, co děláte, občas se něco nepovede. Je tedy dobré připravit tým na to, aby se z neúspěchu oklepal a poučil, místo aby se hroutili. V Atlassian vlastně věříme, že pokud jednou za čas neuděláte nějakou chybu, jedete příliš na jistotu a vaše nasazení může mít mezery.

Našim týmům dáváme velké, smělé a odvážné cíle a zajišťujeme, aby měly autonomii a zdroje pro jejich splnění. Najímáme inteligentní, ambiciózní lidi a víme, že i oni někdy selžou.

V přístupu DevOps není selhání či chyba něčím, co je nutné trestat. Týmy předpokládají, že se všechno může v někdy pokazit, proto se při vývoji soustředí na rychlé zjištění a nápravu chyby a zotavení. (Jako příklad si přečtěte o nástroji Chaos Monkey od Nexflix.) Následné šetření se soustřeďuje na to, kde procesy selhaly a jak procesy posílit – nikoli na hledání konkrétního člena týmu, který napsal řádek kódu s chybou. Proč? Trvalé vylepšování a chyby jdou ruku v ruce.

Koncepce DevOps se vyvinula tak, že vývoj má na starost více provozních činností – přesně takto pracuje společnost Chef. Už není možné úkoly házet přes zeď. Naši analytici odpovídají za kontrolu kvality, psaní a spouštění vlastních testů, aby software doručili k zákazníkům. — Julian Dunn, produktový manažer ve společnosti Chef

Měření

Bez konkrétních dat není snadné dokázat, že vaše úsilí o trvalé zlepšování skutečně něco zlepšuje. Naštěstí existuje spousta nástrojů a technologií pro měření výkonnosti, například kolik času uživatelé stráví používáním vašeho produktu, zda určitý příspěvek blogu generoval nějaké prodeje nebo jak často se v protokolech objevují kritické výstrahy.

Ačkoli můžete změřit prakticky cokoli, neznamená to, že musíte (nebo byste měli) měřit úplně všechno. Vezměte si poučení z principů vývoje agile a začněte se základními parametry:

  • Jak dlouho trval přechod od vývoje k nasazení? 
  • Jak často dochází k opakovaným chybám nebo selháním?
  • Jak dlouho trvá zotavení po selhání systému?
  • Kolik lidí používá váš produkt právě teď?
  • Kolik uživatelů jste získali nebo ztratili minulý týden?

Pokud máme pevné základy, je snadnější zavést mnohem sofistikovanější metriky ohledně využití funkcí, cesty zákazníka a smluv SLA. Získané informace vám přijdou vhod, když přijde čas na plánování a specifikace dalších významných kroků.

Tato zajímavá data pomohou vašemu týmu při rozhodování, ale jsou ještě účinnější, když jsou sdílena s ostatními týmy – zejména týmy v jiných odděleních. Váš marketingový tým si například přeje úžasné nové funkce, které by se dobře prodávaly. Ale vy zatím vidíte docela vysokou nespokojenost u existujících zákazníků, protože v produktu jsou některé funkce technicky nedotažené. Data o uživatelích, kterými podpoříte předložený plán dalšího vývoje produktu (i když to bude znamenat méně nových funkcí a více oprav), pomohou dosáhnout konsensu a přesvědčit všechny zúčastněné strany, že právě tohle je správný směr dalšího vývoje.

DevOps není úkolem jediného člověka. Je to úkol pro všechny. – Christophe Capel, hlavní produktový manažer, Jira Service Desk

Sdílení

Dlouhotrvající pnutí mezi vývojářskými a provozními týmy je do značné míry způsobeno nedostatkem společné práce. Věříme, že sdílení odpovědnosti a úspěchu může spojení obou rozdělených stran významně napomoct. Vývojáři mohou okamžitě získat dobré jméno tím, že pomohou provozním týmům s jednou z největších potíží jejich práce: nošením pageru. Velikost koncepce DevOps spočívá v myšlence, že stejní lidé, kteří sestavují aplikaci, by se měli podílet na jejím dodání a uvádění do provozu.

To neznamená pouze zaměstnat vývojáře a očekávat, že budou zároveň vynikajícími provozními pracovníky. Pracovníci ve vývoji i provozu se musí v jednotlivých fázích životního cyklu aplikace vzájemně doplňovat.

Týmy využívající DevOps mají často rotující roli, proto vývojáři řeší požadavky zachycené koncovými uživateli a současně řeší problémy ve výrobě. Tato osoba reaguje na naléhavé požadavky nahlášené zákazníky, v případě potřeby vytváří opravy a prochází závady, které do backlogu nahlásili zákazníci. „Vývojář na podpoře“ se dozví hodně věcí o používání aplikace v reálném světě. A díky vysoké dostupnosti pro provozní tým si vývojářský tým buduje důvěru a vzájemný respekt.

Spolupráce při překonávání neočekávaných těžkostí znamená, že o to sladší bude dosažený úspěch. Až uvidíte, jak tým vývojářů v den vydání nové verze přinese na setkání s provozním týmem dortíky a chlebíčky, vězte, že se kultura DevOps ve vaší společnosti skutečně uchytila.

Pozitivní zpětná vazba od kolegů nás motivuje, obdobně jako finanční ohodnocení nebo kariérní ambice. Veřejné ocenění spolupracovníka, který odhalil závažnou chybu, než se dostala ven, má velký význam. Pokud má vaše oddělení zvláštní rozpočtovou kapitolu pro oceňování mimořádných výkonů zaměstnanců, nenechávejte ji nevyužitou!

Jste připraveni se vydat na cestu DevOps?

Vydejte se na cestu