Zakladatel a ředitel „Otomato Software“, jeden z iniciátorů a instruktorů první DevOps certifikace v Izraeli, Anton Weiss, hovořil na loňském o teorii chaosu a hlavních principech chaosového inženýrství, a vysvětlil, jak funguje ideální DevOps organizace budoucnosti.
Připravili jsme textovou verzi přednášky.
Dobré ráno!
DevOpsDays v Moskvě již druhý rok po sobě, já jsem podruhé na tomto pódiu, mnozí z vás jsou podruhé v této místnosti. Co to znamená? To znamená, že hnutí DevOps v Rusku roste, množí se, a co je nejdůležitější, je čas mluvit o tom, co znamená DevOps v roce 2018.
Zvedněte ruce ti, kdo si myslí, že v roce 2018 je DevOps už profesí? Jsou takoví. Jsou v sále DevOps inženýři, kteří mají ve své náplni práce napsáno „DevOps inženýr“? Jsou v sále DevOps manažeři? Takoví nejsou. DevOps architekti? Taky ne. Je jich málo. Opravu nikdo nemá napsáno, že je DevOps inženýr?
To znamená, že většina z vás si myslí, že je to antipattern? Že taková profese by neměla existovat? Myslet si můžeme cokoliv, a zatímco přemýšlíme, průmysl hrdě postupuje vpřed pod zvuky DevOps trubky.
Kdo slyšel o nové tématu, které se nazývá DevDevOps? Je to taková nová metodika, která umožňuje efektivní spolupráci mezi vývojáři a devopsy. A není to ani tak nová. Pokud se podíváte na Twitter, už před 4 lety se o tom začalo mluvit. A stále roste zájem o tuto problematiku, tedy problém existuje. Je třeba problém vyřešit.
Jsme kreativní lidé, tak snadno se neuklidníme. Říkáme: DevOps je nedostatečně komplexní slovo, chybí v něm ještě různé zajímavé prvky. A jdeme do svých tajných laboratoří a začínáme vytvářet zajímavé mutace: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Logika je jasná, že? Naše doručovací systém není funkční, naše systémy jsou nestabilní a uživatelé jsou nespokojení, nestíháme vydávat software včas, nesplňujeme rozpočet. Jak to všechno budeme řešit? Vymyslíme nové slovo! Bude končit na „Ops“ a problém je vyřešen.
Tak tento přístup nazývám — „Ops a problém je vyřešen“.
Všechno to ustupuje do pozadí, pokud si připomínáme, proč jsme to všechno vymysleli. Vymysleli jsme celý tento DevOps, abychom co nejvíce usnadnili dodávku softwaru a naši práci v tomto procesu, aby byla co nejméně bolestivá, efektivní a co nejvíce příjemná.
DevOps vyrostl z bolesti. A už nás unavuje trpět. Abychom toho dosáhli, zakládáme se na večnozelených praktikách: efektivní spolupráce, praktiky toku a především systémové myšlení, protože bez něj žádný DevOps nefunguje.
Co je to systém?
A pokud už mluvíme o systémovém myšlení, připomeňme si, co to vlastně systém je.
Pokud jste hacker-revolucionář, pak je pro vás systém jednoznačné zlo. Je to mračno, které se nad vámi vznáší a nutí vás dělat to, co dělat nechcete.
Z pohledu systémového myšlení je systém nějakým celkem, které se skládá z částí. V tomto smyslu jsme každý z nás systém. Organizace, v nichž pracujeme, jsou systémy. A to, co spolu budujeme, se také nazývá systém.
Všechno to je součástí jednoho velkého socio-technologického systému. A pouze pokud pochopíme, jak tento socio-technologický systém funguje dohromady, pak budeme schopni v této oblasti skutečně něco optimalizovat.
Z pohledu systémového myšlení má systém různá zajímavá vlastnosti. Za prvé, skládá se z částí, což znamená, že jeho chování závisí na chování částí. Při tom jsou všechny jeho části také vzájemně závislé. Výsledkem je, že čím víc má systém částí, tím obtížnější je pochopit nebo předpovědět jeho chování.
Z pohledu chování existuje ještě jedna zajímavá skutečnost. Systém může dělat něco, co žádná z jeho jednotlivých částí dělat nemůže.
Jak říkal doktor Russell Ackoff (jeden z zakladatelů systémového myšlení), to lze snadno dokázat pomocí myšlenkového experimentu. Například, kdo v sále umí psát kód? Mnoho rukou, a to je normální, protože to je jedno z hlavních požadavků na naši profesi. Umíte psát, ale vaše ruce odděleně od vás mohou psát kód? Existují lidé, kteří by řekli: „Ne moje ruce píší kód, můj mozek píše kód.“ A může mozek psát kód odděleně od vás? No, pravděpodobně ne.
Mozek je úžasný stroj, o jehož fungování nevíme ani 10 %, ale nemůže fungovat odděleně od systému, kterým je náš organismus. A to se dá snadno dokázat: otevřete si lebku, vyjměte mozek, položte ho před počítač a ať se pokusí napsat něco jednoduchého. Například „Hello, world“ v Pythonu.
Pokud systém dokáže udělat něco, co žádná z jeho částí samostatně udělat nemůže, znamená to, že jeho chování není určeno chováním jeho částí. Co ho tedy určuje? Určuje ho interakce mezi těmito částmi. A podle toho, čím více částí, tím složitější interakce, tím složitější je pochopit a předpovědět chování systému. A to dělá takový systém chaotickým, protože jakákoliv, i ta nejnepatrnější a neviditelná změna v jakékoliv části systému může vést k naprosto nepředvídatelným výsledkům.
Tato citlivost na výchozí podmínky byla poprvé objevena a zkoumána americkým meteorologem Edem Lorenzem. Později byla nazvána „efekt motýlích křídel“ a vedla k rozvoji takového směru vědeckého myšlení, který se nazývá „teorie chaosu“. Tato teorie se stala jedním z hlavních posunů paradigmat v vědě 20. století.
Teorie chaosu
Lidé, kteří se zabývají studiem chaosu, se nazývají chaosologové.
Skutečnou příčinou této přednášky bylo to, že při práci se složitými distribuovanými systémy a velkými mezinárodními organizacemi jsem v určitém okamžiku pochopil, že přesně tohle jsem já. Jsem chaosolog. Je to vlastně rafinovaný způsob, jak říct: „Nerozumím tomu, co se zde děje, a nevím, co s tím dělat.“
Myslím, že mnoho z vás se také často cítí takto, takže také jste chaosologové. Zveme vás do cechu chaosologů. Systémy, které budeme studovat, milí kolegové chaosologové, se nazývají „složené adaptivní systémy“.
Co je to adaptabilita? Adaptabilita znamená, že individuální a kolektivní chování částí v takové adaptivní soustavě se mění a samoorganizuje v reakci na události nebo řetězce mikro-událostí v systému. Jinými slovy, systém se přizpůsobuje změnám prostřednictvím samoorganizace. A tato schopnost samoorganizace je založena na dobrovolné, zcela decentralizované spolupráci svobodných autonomních agentů.
Dalším zajímavým rysem těchto systémů je, že jsou svobodně škálovatelné. Což by nás, jakožto inženýry chaosu, mělo bezpochyby zajímat. Řekli jsme-li, že chování složitého systému je určováno interakcí jeho částí, co by nás mělo zajímat? Interakce.
Existují ještě dvě zajímavé závěry.
Za prvé chápeme, že složitý systém nelze zjednodušit prostým zjednodušením jeho částí. Za druhé jediným způsobem, jak zjednodušit složitý systém, je zjednodušit interakce mezi jeho částmi.
Jak interagujeme? Všichni jsme součástí velkého informačního systému, který se nazývá lidská společnost. Interagujeme pomocí společného jazyka, pokud ho máme, pokud ho nacházíme.
Ale jazyk sám o sobě je složitý adaptivní systém. Proto, abychom mohli interagovat efektivněji a jednodušeji, je nezbytné vytvoření určitých protokolů. Jinými slovy, určité posloupnosti symbolů a činů, které učiní výměnu informací mezi námi jednodušší, předvídatelnější a srozumitelnější.
Chci říci, že tendence ke komplexnosti, adaptabilitě, decentralizaci a chaotičnosti se projevují ve všem. Jak v těch systémech, které budujeme, tak v těch systémech, jejichž součástí jsme.
Abychom nebyli bez argumentů, podívejme se, jak se mění ty systémy, které vytváříme.
Čekali jste na toto slovo, rozumím. Jsme na DevOps konferenci, dnes to slovo zazní asi sto tisíckrát a pak se nám zdá v noci.
Mikroslužby jsou první architekturou softwaru, která se objevila jako reakce na praktiky DevOps a má za cíl učinit naše systémy flexibilnějšími, škálovatelnějšími a zajistit nepřetržitou dodávku. Jak to dělá? Zkrácením objemu služeb, zúžením hranic problémů, které tyto služby zpracovávají, a zkrácením doby dodání. To znamená, že zmenšujeme a zjednodušujeme části systému, zvyšujeme jejich počet, a tím se nevyhnutelně zvyšuje složitost interakcí mezi těmito částmi, což znamená, že vznikají nové problémy, které musíme řešit.
Mikroslužby ještě nejsou konec; mikroslužby jsou v podstatě už včerejším dnem, protože přichází Serverless. Všechny servery shořely, nejsou servery, nejsou operační systémy, jen čistý vykonávací kód. Konfigurace samostatně, stavy samostatně, vše je řízeno událostmi. Krása, čistota, ticho, žádné události, nic se neděje, úplný pořádek.
Kde je složitost? Složitost, jak je jasné, spočívá v interakcích. Kolik toho může jedna funkce udělat sama? Jak interaguje s ostatními funkcemi? Zprávové fronty, databáze, vyvažovače zátěže. Jak znovu vytvořit nějakou událost, když dojde k chybě? Spousta otázek a málo odpovědí.
Mikroslužby a Serverless jsou všechno, co my, počítačoví hípsteři, nazýváme Cloud Native. To všechno se točí kolem cloudu. Ale cloud je v podstatě také omezeně škálovatelný. Jsme zvyklí myslet na něj jako na distribuovaný systém. Ve skutečnosti, kde žijí servery cloudových poskytovatelů? V datových centrech. Máme tedy určitou centralizovanou, velmi omezenou, distribuovanou model.
Dnes chápeme, že internet věcí už není jenom prázdné slovo; podle skromných předpovědí nás v příštích pěti až deseti letech čekají miliardy zařízení připojených k internetu. Obrovské množství užitečných i zbytečných dat, která budou stahována do cloudu a vypouštěna z cloudu.
Cloud nevydrží, proto stále častěji mluvíme o tom, čemu se říká „okrajové výpočty“. Nebo mě také zaujalo nádherné určení „fog computing“. Je to zahaleno mystikou romantismu a tajemství.
Záhadné výpočetní praktiky. Jde o to, že oblaka jsou centralizované shluky vody, páry, ledu nebo kamenů. A mlha je soubor kapek vody, které jsou rozptýleny kolem nás v atmosféře.
V mlhavé paradigmatice většina práce probíhá tímto kapkovým způsobem zcela autonomně nebo ve spolupráci s ostatními kapkami. Obracejí se na oblak pouze tehdy, když to opravdu tlačí.
Opět tedy decentralizace, autonomnost a samozřejmě mnozí z vás již chápou, kam to směřuje, protože nelze hovořit o decentralizaci a nezmínit blockchain.
Jsou ti, kteří věří, což jsou ti, kdo investovali do kryptoměn. Jsou ti, kteří věří, ale bojí se, jako já například. A jsou ti, kteří nevěří. Můžete na to mít různé názory. Existuje technologie, nové nepochopitelné věci a existují problémy. Jako každá nová technologie vyvolává více otázek, než poskytuje odpovědí.
Hype kolem blockchainu je pochopitelný. I když odložíte zlatou horečku stranou, samotná technologie nabízí úžasné sliby světlé budoucnosti: více svobody, více autonomie, globální distribuované důvěry. Co tu není k chtění?
Následně více a více inženýrů po celém světě začíná vyvíjet decentralizované aplikace. A to je síla, kterou nelze ignorovat, jen říci: „Ach, blockchain je jen špatně implementovaná distribuovaná databáze.“ Nebo jak rádi říkají skeptici: „Neexistují žádné skutečné aplikace pro blockchain.“ Když o tom přemýšlíte, před 150 lety říkali to samé o elektřině. A dokonce měli pravdu, protože to, co elektřina dnes umožňuje, bylo v 19. století úplně nerealizovatelné.
Mimochodem, kdo ví, co je to logo na obrazovce? To je Hyperledger. Je to projekt, který se vyvíjí pod záštitou The Linux Foundation a zahrnuje sadu blockchainových technologií. To je opravdu síla naší komunity otevřeného zdroje.
Chaosové inženýrství
Takže systém, který vyvíjíme, se stává stále složitějším, stále chaotičtějším a stále adaptivnějším. Netflix je průkopníkem mikroslužeb. Byli jedni z prvních, kdo to pochopili, vyvinuli sadu nástrojů, které nazvali Simian Army, nejznámější z nich je . Stanovil to, co se stalo známým jako .
Mimochodem, během práce na prezentaci jsme dokonce přeložili tento text do ruštiny, takže se podívejte na , čtěte, komentujte, kritizujte.
Stručně řečeno, principy chaosového inženýrství říkají následující. Složené distribuované systémy jsou svými podstatami nepředvídatelné a v nich se v zásadě vyskytují chyby. Chyby jsou nevyhnutelné, což znamená, že musíme tyto chyby přijmout a pracovat s těmito systémy zcela jiným způsobem.
Musíme se sami pokoušet vložit tyto chyby do našich produkčních systémů, abychom testovali naše systémy na tuto adaptabilitu, na tuto schopnost k seorganizaci, k přežití.
A to mění vše. Nejen to, jak uvedeme systém do produkce, ale i jak je vyvíjíme, jak je testujeme. Neexistuje žádný proces stabilizace, zamrznutí kódu, naopak, existuje neustálý proces destabilizace. Snažíme se zabít systém a vidět, že stále přežívá.
Protokoly pro integraci distribuovaných systémů
V souladu s tím to vyžaduje, aby se naše systémy také nějakým způsobem změnily. Aby se staly odolnějšími, potřebují určité nové protokoly pro interakci mezi svými částmi. Aby tyto části mohly komunikovat a dosáhnout jisté seorganizace. A vznikají různé nové nástroje, nové protokoly, které nazývám „protokoly interakce distribuovaných systémů“.
O čem mluvím? Za prvé, projekt . Jakási snaha vytvořit společný protokol pro distribuované sledování, který je naprosto nezbytným nástrojem pro ladění složených distribuovaných systémů.
Dále je zde . Říkáme, že nemůžeme předvídat, co se se systémem stane, takže je nezbytné zvýšit jeho observabilitu. Opentracing patří do rodiny nástrojů, které poskytují observabilitu našich systémů. Ale observabilita je nám potřebná k tomu, abychom určili, zda se systém chová tak, jak od něj očekáváme, nebo ne. Jak zjistit očekávané chování? Určením nějaké politiky, nějaké sady pravidel. Projekt Open Policy Agent se zabývá definicí této sady pravidel v širokém spektru: od přístupů po umístění zdrojů.
Jak jsme již řekli, naše systémy jsou čím dál tím více řízeny událostmi. Serverless je skvělý příklad systémů řízených událostmi. Abychom mohli předávat události mezi systémy a sledovat je, potřebujeme společný jazyk, jakýsi společný protokol pro to, jak o událostech komunikujeme a jak si je předáváme. To se zabývá projekt s názvem .
Nepřetržitý proud změn, který ovlivňuje naše systémy a neustále je destabilizuje, je nepřetržitý proud softwarových artefaktů. Abychom mohli udržovat tento trvalý proud změn, potřebujeme společný protokol, pomocí kterého můžeme mluvit o tom, co je softwarový artefakt, jak byl ověřen a jakou verifikaci prošel. To se zabývá projekt s názvem . To znamená společný protokol metadat softwarových artefaktů.
A nakonec, pokud chceme, aby naše systémy byly zcela autonomní, adaptivní a samostatně organizované, musíme jim dát právo na self-identifikaci. Projekt s názvem se tímto právě zabývá. Je to také projekt pod záštitou Cloud Native Computing Foundation.
Všechny tyto projekty jsou mladé, potřebují naši lásku, naše ověření. Vše je otevřený kód, naše testování, naše implementace. Ukazují nám, kterým směrem se technologie ubírá.
Ale DevOps nikdy nebyl především o technologii, vždy byl především o spolupráci mezi lidmi. A pokud chceme, aby se systémy, které vyvíjíme, změnily, musíme se změnit my sami. Ve skutečnosti se už měníme, nemáme příliš na výběr.
Existuje skvělá britské autorky Rachael Botsman, ve které píše o evoluci důvěry v průběhu lidské historie. Říká, že původně, v primitivních společnostech, byla důvěra lokální, tj. důvěřovali jsme pouze těm, které známe osobně.
Následovalo velmi dlouhé období – temné časy, kdy byla důvěra centralizovaná, kdy jsme začali důvěřovat lidem, které neznáme, na základě toho, že patříme ke stejnému společenskému nebo státnímu institutu.
A co vidíme v našem moderním světě: důvěra se stává čím dál více rozptýlenou a decentralizovanou, zakládá se na svobodě informačních proudů a dostupnosti informací.
Pokud se zamyslíme, tak tuto dostupnost, která dává důvěře smysl, my sami realizujeme. To znamená, že se musí měnit i náš způsob spolupráce a to, jak to děláme, protože centralizované hierarchické IT organizace starého typu přestávají fungovat. Začínají zanikat.
Základy DevOps organizací
Ideální DevOps organizace budoucnosti je decentralizovaný, adaptivní systém složený z autonomních týmů, z nichž každý se skládá z autonomních jednotlivců. Tyto týmy jsou rozptýleny po celém světě a efektivně spolupracují pomocí asynchronní komunikace a vysoce transparentních protokolů výměny informací. Je to krásné, že? Velmi krásná budoucnost.
Samozřejmě, to vše není možné bez kulturních změn. Musíme mít transformační vedení, osobní odpovědnost a vnitřní motivaci.
To je základ DevOps organizací: transparentnost informací, asynchronní komunikace, transformační vedení, decentralizace.
Vyhoření
Systémy, jejichž součástí jsme, a ty, které budujeme, jsou čím dál tím chaotičtější, a my, lidé, máme těžké s touto myšlenkou se vyrovnat, těžké se vzdát iluze kontroly. Snažíme se je nadále kontrolovat, a to často vede k vyhoření. Mluvím to z vlastní zkušenosti, také jsem se spálil, také jsem obětí nečekaných poruch v produkci.
Vyhoření nastává, když se snažíme kontrolovat to, co kontrolovatelné v podstatě není. Když vyhoříme, všechno ztrácí smysl, protože ztrácíme chuť dělat něco nového, zaujmeme defensivní postoj a začínáme chránit to, co máme.
Inženýrská profese, jak si často rád připomínám, je především kreativní profesí. Pokud ztratíme touhu něco vytvářet, měníme se v popel, měníme se v saze. Vyhoří lidé, vyhoří celé organizace.
Podle mého názoru, jedině přijetí tvořivé síly chaosu, pouze budování spolupráce na jeho principech - to je to, co nám pomůže neztratit to dobré, co máme v našem oboru.
To vám také přeji: milovat svou práci, milovat to, co děláme. Tento svět se živí informacemi, máme tu čest ho živit. Takže pojďme studovat chaos, buďme chaosology, přinášejme hodnotu, vytvářejme něco nového, a potíže, jak jsme již zjistili, jsou nevyhnutelné, a když se objeví, řekneme jednoduše „Ops!“, a problém je vyřešen.
Co kromě Chaos Monkey?
Ve skutečnosti jsou všechny tyto nástroje velmi mladé. Například Netflix vytvářel nástroje pro sebe. Vytvářejte nástroje pro sebe. Čtěte principy chaosového inženýrství a dodržujte tyto principy, místo abyste hledali jiné nástroje, které již vytvořil někdo jiný.
Snažte se pochopit, jak se vaše systémy rozpadávají, a začněte je rozpadat a pozorujte, jak odolávají nárazům. To je v první řadě. Nástroje si můžete vyhledat. Existuje spousta projektů.
Nerozuměl jsem úplně tomu okamžiku, kdy jste říkali, že systém nelze zjednodušit zjednodušením jeho komponentů, a ihned jste přešli k mikroservisům, které právě zjednodušují systém zjednodušením samotných komponentů a ztěžují interakce. To jsou v podstatě dvě části, které si navzájem odporují.
Zcela správně, mikroservisy jsou velmi kontroverzní téma. Ve skutečnosti zjednodušení částí zvyšuje flexibilitu. Co nám mikroservisy dávají? Dávají nám flexibilitu a rychlost, ale rozhodně nám nedávají jednodušší řešení. Zvyšují složitost.
Takže v filozofii DevOps mikroservisy nejsou takovým požehnáním?
Každé požehnání má svou odvrácenou stránku. Je tu požehnání: zvyšuje flexibilitu, dává nám možnost provádět změny rychleji, ale zvyšuje složitost a tím pádem křehkost celého systému.
Na co je tedy větší důraz: na zjednodušení interakcí, nebo na zjednodušení částí?
Důraz je bezpochyby kladen na zjednodušení interakce, protože pokud se na to podíváme z pohledu toho, jak pracujeme, měli bychom se primárně soustředit na zjednodušení interakcí, a ne na zjednodušení práce každého z nás jednotlivě. Protože zjednodušení práce znamená přetvoření nás v roboty. Ve McDonald's to funguje, protože máte předepsáno: sem dej burger, sem nalij omáčku. To v naší kreativní práci vůbec nefunguje.
Je pravda, že vše, co jste řekli, žije v světě bez konkurence, a chaos tam je tak laskavý, že v něm nejsou žádné rozpory, nikdo nikoho nechce sníst, zabít? Jak by měly spolu žít konkurence a DevOps?
To záleží na tom, o jaké konkurenci mluvíme. O konkurenci na pracovišti nebo o konkurenci mezi společnostmi?
O konkurenci služeb, které existují, protože služby nejsou pouze několik firem. Vytváříme nový typ informačního prostředí, a jakékoli prostředí nemůže žít bez konkurence. Konkurence je všude.
Pokud vezmeme Netflix jako příklad. Proč to vymysleli? Protože potřebovali být konkurenceschopní. Tato flexibilita a rychlost pohybu představují právě to konkurenční požadavek, který vnáší chaotičnost do našich systémů. Chaos tedy není něco, co děláme vědomě, protože to chceme, ale je to něco, co vzniká jako důsledek potřeb světa. Musíme se jednoduše přizpůsobit. A chaos je právě výsledkem konkurence.
To znamená, že chaos je absence cílů jakoby? Nebo cíle, které nechceme vidět? Jsme v domečku a nechápeme cíle ostatních. Konkurence, ve skutečnosti, se děje díky tomu, že máme jasné cíle a víme, kam přijdeme v každém následujícím okamžiku. V tom vidím já podstatu DevOps.
To je další pohled na věc. Myslím, že naše cíle jsou společné: přežít a dělat to s
největší radostí. A konkurenceschopný cíl jakékoli organizace je stejný. Přežití se často odehrává v konkurenčním boji, to se nedá nic dělat.
Tento rok se konference uskuteční 7. prosince v „Technopolis“. Přihlášky na prezentace přijímáme do 11. listopadu. nám, pokud chcete vystoupit.
Registrace pro účastníky je otevřená, vstupenka stojí 7000 rublů. Připojte se!
Zdroj: habr.com
