Je těžké pochopit hlavní bod, když mluvíme o DevOps? Shromáždili jsme pro vás živé analogie, nápadné formulace a rady odborníků, které pomohou i laikům dostat se k věci. Bonusem jsou nakonec vlastní DevOps zaměstnanců Red Hatu.
Termín DevOps vznikl před 10 lety a přešel z twitterového hashtagu na silné kulturní hnutí ve světě IT, skutečnou filozofii, která povzbuzuje vývojáře, aby dělali věci rychleji, experimentovali a iterovali vpřed. DevOps se stalo neodmyslitelně spjato s konceptem digitální transformace. Ale jak se to s IT terminologií často stává, za posledních deset let si DevOps o sobě osvojilo mnoho definic, interpretací a mylných představ.
Proto můžete často slýchat otázky o DevOps jako, je to stejné jako agile? Nebo je to nějaká speciální metodika? Nebo je to jen další synonymum pro slovo „spolupráce“?
DevOps zahrnuje mnoho různých konceptů (nepřetržité doručování, nepřetržitá integrace, automatizace atd.), takže destilování toho, co je důležité, může být náročné, zvláště když jste pro toto téma nadšení. Tato dovednost je však velmi užitečná, bez ohledu na to, zda se snažíte sdělit své nápady svým nadřízeným nebo o své práci jednoduše říct někomu z rodiny nebo přátel. Ponechme proto prozatím terminologické nuance DevOps a zaměř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 jeho hodnota jasná čtenářům s jakoukoli úrovní technických znalostí. Na základě výsledků těchto rozhovorů jsme vybrali nejpůsobivější analogie a nejpůsobivější formulace, které vám pomohou vytvořit váš příběh o DevOps.
1. DevOps je kulturní hnutí
„DevOps je kulturní hnutí, ve kterém obě strany (vývojáři softwaru a specialisté na provoz IT systémů) uznávají, že software nepřináší skutečné výhody, dokud ho někdo nezačne používat: zákazníci, klienti, zaměstnanci, není to podstatné,“ říká Eveline Oehrlich, vedoucí výzkumu. analytik z DevOps Institute. "Obě tyto strany proto společně zajišťují rychlé a vysoce kvalitní dodávky softwaru."
2. DevOps je o posílení postavení vývojářů.
„DevOps umožňuje vývojářům vlastnit aplikace, spouštět je a řídit doručování od začátku do konce.“
„Obvykle se o DevOps mluví jako o způsobu, jak urychlit dodávání aplikací do výroby vytvořením a implementací automatizovaných procesů,“ říká Jai Schniepp, ředitel platforem DevOps v pojišťovací společnosti Liberty Mutual. "Ale pro mě je to mnohem zásadnější věc." DevOps umožňuje vývojářům vlastnit aplikace nebo konkrétní části softwaru, spouštět je a spravovat jejich poskytování od začátku do konce. DevOps eliminuje zmatky v odpovědnosti a vede každého, kdo se podílí na vytváření automatizované infrastruktury řízené vývojáři.“
3. DevOps je o spolupráci při vytváření a dodávání aplikací.
„Jednoduše řečeno, DevOps je přístup k výrobě a dodávání softwaru, kde všichni spolupracují,“ říká Gur Staf, prezident a vedoucí automatizace digitálního podnikání ve společnosti BMC.
4. DevOps je potrubí
"Montáž dopravníku je možná pouze tehdy, pokud do sebe všechny díly pasují."
„DevOps bych přirovnal k montážní lince automobilů,“ pokračuje Gur Staff. – Cílem je navrhnout a vyrobit všechny díly předem tak, aby je bylo možné sestavit bez individuálního seřizování. Montáž dopravníku je možná pouze tehdy, pokud do sebe všechny díly pasují. Ti, kdo navrhují a staví motor, musí zvážit, jak jej namontovat na karoserii nebo rám. Kdo vyrábí brzdy, musí myslet na kola a tak dále. Totéž by mělo platit se softwarem.
Vývojář vytvářející obchodní logiku nebo uživatelské rozhraní musí přemýšlet o databázi, která uchovává informace o zákaznících, o bezpečnostních opatřeních na ochranu uživatelských dat a o tom, jak to vše bude fungovat, až služba začne sloužit velkému, možná dokonce mnohamilionovému publiku uživatelů. ."
„Největší překážkou, kterou je třeba překonat, je přimět lidi, aby spolupracovali a přemýšleli o částech práce, kterou dělají ostatní, než aby se soustředili pouze na své vlastní úkoly. Pokud to dokážete, máte skvělou šanci na digitální transformaci,“ dodává Gur Staff.
5. DevOps je správná kombinace lidí, procesů a automatizace
Jayne Groll, výkonná ředitelka DevOps Institute, nabídla skvělou analogii pro vysvětlení DevOps. Podle jejích slov „DevOps je jako recept se třemi hlavními kategoriemi složek: lidé, proces a automatizace. Většinu těchto složek lze převzít z jiných oblastí a zdrojů: Lean, Agile, SRE, CI/CD, ITIL, leadership, kultura, nástroje. Tajemství DevOps, stejně jako každého dobrého receptu, spočívá v tom, jak získat správné proporce a namíchat tyto ingredience, abyste zvýšili rychlost a efektivitu vytváření a vydávání aplikací.“
6. DevOps je, když programátoři pracují jako tým Formule 1
"Závod není plánován od začátku do konce, ale naopak od cíle do začátku."
„Když mluvím o tom, co očekávat od iniciativy DevOps, myslím si jako příklad závodní tým NASCAR nebo Formule 1,“ říká Chris Short, senior manažer marketingu cloudových platforem ve společnosti Red Hat a vydavatel zpravodaje DevOps'ish. – Vedoucí takového týmu má jediný cíl: zaujmout na konci závodu co nejvyšší místo s přihlédnutím ke zdrojům, které má tým k dispozici, a výzvám, které na něj číhaly. Závod je v tomto případě plánován nikoli od startu do cíle, ale naopak od cíle do startu. Nejprve se stanoví ambiciózní cíl a poté se určí způsoby, jak jej dosáhnout. Poté jsou rozděleny na dílčí úkoly a delegovány na členy týmu.“
„Tým celý týden před závodem zdokonaluje zastávku v boxech. Dělá silový trénink a kardio, aby zůstal ve formě na vyčerpávající závodní den. Cvičí společnou práci při řešení jakýchkoli problémů, které mohou nastat během závodu. Stejně tak by vývojový tým měl trénovat dovednost častého vydávání nových verzí. Pokud máte takové schopnosti a dobře fungující bezpečnostní systém, dochází také častěji k náběhu nových verzí do výroby. V tomto pohledu na svět znamená zvýšená rychlost zvýšenou bezpečnost,“ říká Short.
„Nejde o to dělat ‚správnou věc‘,“ dodává Short, „jde o to odstranit co nejvíce věcí, které stojí v cestě kýženému výsledku. Spolupracujte a přizpůsobte 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 zlepšení kvality, abyste minimalizovali jejich dopad na pokrok směrem k vašemu cíli. To nás čeká ve světě DevOps.“
Jak škálovat DevOps: 10 tipů od odborníků
Je to tak, že DevOps a hromadné DevOps jsou úplně jiné věci. Prozradíme vám, jak překonat bariéry na cestě z prvního do druhého.
Pro mnoho organizací začíná cesta k DevOps snadno a příjemně. Vznikají malé zapálené týmy, staré procesy se nahrazují novými a první úspěchy na sebe nenechají dlouho čekat.
Bohužel, je to jen falešný pozlátko, iluze pokroku, říká Ben Grinnell, výkonný ředitel a vedoucí digitálního poradenství v poradenské společnosti North Highland. Včasná vítězství jsou jistě povzbudivá, ale nepomohou dosáhnout konečného cíle, kterým je široké přijetí DevOps v celé organizaci.
Je snadné vidět, že výsledkem je kultura rozdělení mezi „my“ a „oni“.
„Organizace často zahajují tyto průkopnické projekty v domnění, že připraví cestu pro mainstreamové DevOps, aniž by zvažovaly, zda ostatní budou schopni nebo ochotni jít touto cestou,“ vysvětluje Ben Grinnell. – Týmy pro realizaci takových projektů se obvykle rekrutují ze sebevědomých „Varjagů“, kteří již něco podobného dělali jinde, ale jsou ve vaší organizaci noví. Zároveň jsou povzbuzováni k porušování a ničení pravidel, která zůstávají závazná pro všechny ostatní. Je snadné vidět, že výsledkem je kultura „my“ a „oni“, která brání přenosu znalostí a dovedností.
„A tento kulturní problém je jen jedním z důvodů, proč je obtížné škálovat DevOps. Týmy DevOps čelí zvýšeným technickým výzvám, které jsou typické pro rychle se rozvíjející IT společnosti,“ řekl Steve Newman, zakladatel a předseda představenstva Scalyr.
„V moderním světě se služby mění, jakmile je potřeba. Je skvělé neustále implementovat a implementovat nové funkce, ale koordinace tohoto procesu a eliminace vzniklých problémů je skutečným bolehlavem, dodává Steve Newman. – Ve velmi rychle rostoucích organizacích se inženýři v mezifunkčních týmech snaží udržet přehled o změnách a kaskádových efektech, které vytváří na úrovni závislosti. Navíc inženýři nejsou šťastní, když jsou o tuto příležitost připraveni, a v důsledku toho je pro ně obtížnější pochopit podstatu problémů, které se objevují.“
Jak překonat tyto výše popsané výzvy a přejít k masovému přijetí DevOps ve velké organizaci? Odborníci nabádají k trpělivosti, i když je vaším konečným cílem urychlit cyklus vývoje softwaru a obchodní procesy.
1. Pamatujte, že změna kultury vyžaduje čas.
Jayne Groll, výkonný ředitel, DevOps Institute: „Podle mého názoru by expanze DevOps měla být stejně postupná a iterativní jako agilní vývoj (a stejně tak by se měla dotýkat kultury). Agile a DevOps kladou důraz na malé týmy. Ale jak tyto týmy rostou co do počtu a integrace, končíme s tím, že stále více lidí přijímá nové způsoby práce a v důsledku toho dochází k masivní kulturní transformaci.“
2. Věnujte dostatek času plánování a výběru platformy
Eran Kinsbruner, vedoucí technický evangelista ve společnosti Perfecto: „Aby škálování fungovalo, musí se týmy DevOps nejprve naučit kombinovat tradiční procesy, nástroje a dovednosti a poté pomalu pěstovat a stabilizovat každou jednotlivou fázi DevOps. Všechno to začíná pečlivým plánováním uživatelských příběhů a hodnotových toků, následovaným psaním softwaru a řízením verzí pomocí vývoje založeného na kmenu nebo jiných přístupů, které se nejlépe hodí pro větvení a slučování kódu.“
„Poté přichází fáze integrace a testování, kde je již vyžadována škálovatelná platforma pro automatizaci. Zde je důležité, aby si týmy DevOps vybraly správnou platformu, která odpovídá úrovni jejich dovedností a konečným cílům projektu.
Další fází je nasazení do produkce, které by mělo být plně automatizováno pomocí nástrojů pro orchestraci a kontejnerů. Je důležité mít virtualizovaná prostředí ve všech fázích DevOps (produkční simulátor, QA prostředí a skutečné produkční prostředí) a vždy používat pouze nejnovější data pro testy pro získání relevantních závěrů. Analytics musí být chytrá a schopná zpracovávat velká data s rychlou a použitelnou zpětnou vazbou.“
3. Vyjměte vinu z odpovědnosti.
Gordon Haff, evangelista RedHat: „Vytvoření systému a atmosféry, která umožňuje a podporuje experimentování, umožňuje to, co je známé jako úspěšná selhání v agilním vývoji softwaru. To neznamená, že za neúspěchy není odpovědný nikdo jiný. Ve skutečnosti je určení toho, kdo je odpovědný, ještě snazší, protože „být zodpovědný“ již neznamená „způsobit nehodu“. To znamená, že podstata odpovědnosti se kvalitativně mění. Čtyři faktory se stávají kritickými: rozsah narušení, přístupy, výrobní procesy a pobídky.“ (Více o těchto faktorech si můžete přečíst v článku Gordona Huffa „DevOps lekce: 4 aspekty zdravých experimentů.)
4. Vyčistěte cestu vpřed
Ben Grinnell, výkonný ředitel a vedoucí digitálního oddělení poradenské společnosti North Highland: „Abychom dosáhli rozsahu, doporučuji spustit program „čištění cest“ společně s průkopnickými projekty. Cílem tohoto programu je vyčistit odpadky, které po sobě zanechávají průkopníci DevOps, jako jsou zastaralá pravidla a podobné věci, aby cesta vpřed zůstala volná.“
„Dejte lidem organizační podporu a dynamiku prostřednictvím komunikace, která jde daleko za průkopnickou skupinu tím, že široce oslavujete úspěchy nových způsobů práce. Trénujte lidi, kteří jsou zapojeni do další vlny projektů DevOps a jsou nervózní z prvního použití DevOps. A pamatujte, že tito lidé jsou velmi odlišní od průkopníků.“
5. Demokratizujte nástroje
Steve Newman, zakladatel a předseda Scalyr: „Nástroje by neměly být lidem skryty a měly by být relativně snadno naučitelné pro každého, kdo je ochoten tomu věnovat čas. Pokud je možnost dotazovat se na protokoly omezena na tři osoby „certifikované“ pro používání nástroje, budete mít vždy k dispozici maximálně tři osoby, které problém vyřeší, a to i v případě, že máte velmi rozsáhlé výpočetní prostředí. Jinými slovy, existuje zde úzké hrdlo, které může vést k vážným (obchodním) důsledkům.“
6. Vytvořte ideální podmínky pro týmovou práci
Tom Clark, šéf Common Platform v ITV: "Můžeš dělat cokoli, ale ne všechno najednou." Stanovte si tedy velké cíle, začněte v malých a posouvejte se vpřed v rychlých iteracích. Postupem času si vytvoříte reputaci, že věci dotahujete, takže ostatní budou chtít používat vaše metody také. A nebojte se vybudovat vysoce efektivní tým. Místo toho poskytněte lidem ideální pracovní podmínky a efektivita bude následovat.“
7. Nezapomeňte na desky Conway's Law a Kanban
Logan Daigle, ředitel doručování softwaru a strategie DevOps ve společnosti CollabNetVersionOne: "Je důležité pochopit důsledky Conwayova zákona." V mé volné parafrázi tento zákon říká, že produkty, které vytváříme, a procesy, které k tomu používáme, včetně DevOps, jsou strukturovány stejným způsobem jako naše organizace.“
„Pokud je v organizaci mnoho sil a řízení při plánování, sestavování a vydávání softwaru mnohokrát změní majitele, efekt škálování bude nulový nebo krátkodobý. Pokud organizace vybuduje mezifunkční týmy kolem produktů, které jsou financovány s tržním zaměřením, pak se šance na úspěch dramaticky zvýší.“
„Dalším důležitým aspektem škálování je zobrazení veškeré nedokončené práce (WIP, workinprogress) na tabulích Kanban. Když má organizace místo, kde mohou lidé tyto věci vidět, velmi to podporuje spolupráci, což má pozitivní dopad na škálování.“
8. Hledejte staré jizvy
Manuel Pais, konzultant DevOps a spoluautor Team Topologies: „Převzít postupy DevOps nad rámec samotného Dev a Ops a pokusit se je aplikovat na další funkce je stěží optimální přístup. To jistě bude mít určitý dopad (například automatizací ručního ovládání), ale mnohem více lze dosáhnout, pokud začneme pochopením procesů dodání a zpětné vazby.“
„Pokud v IT systému organizace existují staré jizvy – postupy a mechanismy řízení, které byly implementovány v důsledku minulých incidentů, ale ztratily svou relevanci (kvůli změnám v produktech, technologiích nebo procesech) – pak je určitě potřeba odstranit. nebo vyhlazení, spíše než automatizace neefektivních nebo zbytečných procesů.“
9. Nemnožte možnosti DevOps
Anthony Edwards, provozní ředitel společnosti Eggplant: „DevOps je velmi vágní pojem, takže každý tým skončí se svou vlastní verzí DevOps. A není nic horšího, když má organizace najednou 20 druhů DevOps, které spolu moc nevycházejí. Je nemožné, aby každý ze tří vývojových týmů měl své vlastní speciální rozhraní mezi vývojem a správou produktu. Produkty by také neměly mít svá vlastní jedinečná očekávání ohledně zpracování zpětné vazby při přenosu do výrobního simulátoru. Jinak nikdy nebudete moci škálovat DevOps.“
10. Kázejte o obchodní hodnotě DevOps
Steve Newman, zakladatel a předseda Scalyr: „Pracujte na rozpoznání hodnoty DevOps. Učte se a klidně mluvte o výhodách toho, co děláte. DevOps je neuvěřitelná úspora času a peněz (jen pomyslete: méně prostojů, kratší průměrná doba do obnovy) a týmy DevOps musí neúnavně zdůrazňovat (a kázat) důležitost těchto iniciativ pro obchodní úspěch. Tímto způsobem můžete rozšířit okruh přívrženců a zvýšit vliv DevOps v organizaci.“
BONUS
Na Naše vlastní DevOps dorazí 13. září – ano, Red Hat jako výrobce softwaru má své vlastní DevOps týmy a postupy.
Náš inženýr Mark Birger, který vyvíjí služby interní automatizace pro další skupiny v celé organizaci, bude vyprávět svůj vlastní příběh v čisté ruštině – jak tým Red Hat DevOps migroval aplikace z virtuálních prostředí Hat Virtualization spravovaných Ansible na plnohodnotný kontejnerový formát na platforma OpenShift.
Ale to není vše:
Jakmile organizace přesunou pracovní zátěž do kontejnerů, tradiční metody monitorování aplikací nemusí fungovat. Ve druhém povídání vysvětlíme naši motivaci změnit způsob logování a ukážeme pokračování cesty, která nás vedla k moderním metodám těžby a monitorování.
Zdroj: www.habr.com