Anton Weiss, zakladatel a ředitel Otomato Software, jeden z iniciátorů a instruktorů první certifikace DevOps v Izraeli, vystoupil na loňském o teorii chaosu a hlavních principech chaosového inženýrství a také vysvětlil, jak funguje ideální organizace DevOps budoucnosti.
Připravili jsme textovou verzi zprávy.
Dobré ráno!
DevOpsDays v Moskvě již druhým rokem, na této scéně jsem podruhé, mnozí z vás jsou v této místnosti již podruhé. Co to znamená? To znamená, že hnutí DevOps v Rusku roste, množí se, a co je nejdůležitější, znamená to, že nastal čas mluvit o tom, co je DevOps v roce 2018.
Zvedněte ruce, kdo si myslí, že DevOps je už v roce 2018 povolání? Existují takové. Jsou v místnosti nějací inženýři DevOps, jejichž popis práce říká „DevOps Engineer“? Jsou v místnosti nějací správci DevOps? Žádný takový neexistuje. Architekti DevOps? Také ne. Nedostatek. Je opravdu pravda, že nikdo neříká, že je inženýrem DevOps?
Takže většina z vás si myslí, že je to anti-vzorec? Že by taková profese neměla existovat? Můžeme si myslet, co chceme, ale zatímco přemýšlíme, průmysl se slavnostně posouvá vpřed za zvuku trubky DevOps.
Kdo slyšel o novém tématu s názvem DevDevOps? Jedná se o novou techniku, která umožňuje efektivní spolupráci mezi vývojáři a vývojáři. A ne tak nový. Soudě podle Twitteru se o tom začalo mluvit už před 4 lety. A doteď zájem o to roste a roste, to znamená, že je tu problém. Problém je potřeba vyřešit.
Jsme kreativní lidé, nejenže odpočíváme. Říkáme: DevOps není dostatečně obsáhlé slovo, stále mu chybí nejrůznější, zajímavé prvky. A jdeme do našich tajných laboratoří a začínáme vyrábět zajímavé mutace: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Logika je železná, že? Náš doručovací systém není funkční, naše systémy jsou nestabilní a naši uživatelé jsou nespokojení, nestíháme zavádět software včas, nevejdeme se do rozpočtu. Jak to všechno vyřešíme? Vymyslíme nové slovo! Skončí to "Ops" a problém je vyřešen.
Takže tomu říkám přístup - "Ops, a problém je vyřešen."
To vše ustoupí do pozadí, pokud si připomeneme, proč jsme na to všechno přišli. Vymysleli jsme celou tuto věc DevOps, abychom zajistili dodávání softwaru a naši vlastní práci v tomto procesu tak, aby bylo co nejvíce bezproblémové, bezbolestné, efektivní a hlavně příjemné.
DevOps vyrostl z bolesti. A jsme unaveni utrpením. A aby k tomu všemu došlo, spoléháme na evergreen praktiky: efektivní spolupráci, flow praktiky a hlavně systémové myšlení, protože bez toho žádné DevOps nefunguje.
co je to systém?
A když už mluvíme o systémovém myšlení, připomeňme si, co je to systém.
Pokud jste revoluční hacker, pak je pro vás systém jednoznačně zlý. Je to mrak, který nad vámi visí a nutí vás dělat věci, které nechcete.
Z hlediska systémového myšlení je systém celkem, který se skládá z částí. V tomto smyslu je každý z nás systém. Organizace, ve kterých pracujeme, jsou systémy. A to, co vy a já budujeme, se nazývá systém.
To vše je součástí jednoho velkého sociotechnologického systému. A pouze pokud pochopíme, jak tento sociotechnologický systém funguje společně, teprve potom budeme schopni v této věci skutečně něco optimalizovat.
Z pohledu systémového myšlení má systém různé zajímavé vlastnosti. Za prvé se skládá z částí, což znamená, že její chování závisí na chování částí. Navíc jsou všechny jeho části také vzájemně závislé. Ukazuje se, že čím více částí systém má, tím obtížnější je pochopit nebo předvídat jeho chování.
Z hlediska chování je zajímavý ještě jeden fakt. Systém umí něco, co žádná z jeho jednotlivých částí neumí.
Jak řekl Dr. Russell Ackoff (jeden ze zakladatelů systémového myšlení), lze to docela snadno dokázat myšlenkovým experimentem. Kdo v místnosti například umí psát kód? Je tam hodně rukou, a to je normální, protože to je jeden z hlavních požadavků na naši profesi. Umíte psát, ale umí vaše ruce psát kód odděleně od vás? Jsou lidé, kteří řeknou: "Kód nepíšou moje ruce, ale můj mozek." Dokáže váš mozek psát kód odděleně od vás? No to asi ne.
Mozek je úžasný stroj, ani nevíme z 10%, jak tam funguje, ale nemůže fungovat odděleně od systému, kterým je naše tělo. A to se dá snadno dokázat: otevřete lebku, vyndejte mozek, dejte ho před počítač, ať zkusí napsat něco jednoduchého. Například „Hello, world“ v Pythonu.
Pokud systém dokáže něco, co žádná z jeho částí nedokáže samostatně, pak to znamená, že jeho chování není určeno chováním jeho částí. Podle čeho se to tedy určuje? Je určena interakcí mezi těmito částmi. A podle toho, čím více částí, čím složitější jsou interakce, tím obtížnější je pochopit a předvídat chování systému. A to dělá takový systém chaotickým, protože jakákoli, i sebenepatrnější, neviditelná změna v jakékoli části systému může vést ke zcela nepředvídatelným výsledkům.
Tuto citlivost na počáteční podmínky poprvé objevil a studoval americký meteorolog Ed Lorenz. Následně byl nazýván „motýlím efektem“ a vedl k rozvoji hnutí vědeckého myšlení zvaného „teorie chaosu“. Tato teorie se stala jednou z hlavních změn paradigmatu ve vědě 20. století.
Teorie chaosu
Lidé, kteří studují chaos, si říkají chaosologové.
Vlastně důvodem této zprávy bylo to, že při práci se složitými distribuovanými systémy a velkými mezinárodními organizacemi jsem si v určitém okamžiku uvědomil, že to je ten, na koho se cítím. Jsem chaosolog. Je to v podstatě chytrý způsob, jak říct: „Nerozumím tomu, co se tady děje, a nevím, co s tím dělat.
Myslím, že mnozí z vás to také často cítí, takže jste také chaosologové. Zvu vás do cechu chaosologů. Systémy, které vy a já, drazí kolegové chaosologové, budeme studovat, se nazývají „komplexní adaptivní systémy“.
Co je přizpůsobivost? Adaptabilita znamená, že individuální a kolektivní chování částí v takovém adaptivním systému se mění a samoorganizuje, reaguje na události nebo řetězce mikroudálostí v systému. To znamená, že systém se přizpůsobuje změnám prostřednictvím sebeorganizace. A tato schopnost sebeorganizace je založena na dobrovolné, zcela decentralizované spolupráci svobodných autonomních agentů.
Další zajímavou vlastností takových systémů je, že jsou volně škálovatelné. Co by nás jako chaosology-inženýry mělo bezpochyby zajímat. Pokud jsme tedy řekli, že chování složitého systému je dáno interakcí jeho částí, tak co by nás mělo zajímat? Interakce.
Zajímavá jsou ještě dvě zjištění.
Za prvé, chápeme, že složitý systém nelze zjednodušit zjednodušením jeho částí. Za druhé, jediný způsob, jak zjednodušit složitý systém, je zjednodušit interakce mezi jeho částmi.
Jak spolu interagujeme? Vy i já jsme všichni součástí velkého informačního systému zvaného lidská společnost. Komunikujeme prostřednictvím společného jazyka, pokud jej máme, pokud jej najdeme.
Ale jazyk sám o sobě je složitý adaptivní systém. V souladu s tím, abychom mohli efektivněji a jednodušeji komunikovat, musíme vytvořit nějaký druh protokolů. Tedy nějakou posloupnost symbolů a akcí, díky kterým bude výměna informací mezi námi jednodušší, předvídatelnější, srozumitelnější.
Chci říci, že ve všem lze vysledovat trendy ke komplexitě, k přizpůsobivosti, k decentralizaci, k chaosu. A v systémech, které vy a já budujeme, a v těch systémech, kterých jsme součástí.
A abychom nebyli neopodstatnění, podívejme se, jak se mění systémy, které vytváříme.
Na tohle slovo jsi čekal, rozumím. Jsme na konferenci DevOps, dnes toto slovo zazní asi stotisíckrát a pak se nám o něm bude v noci zdát.
Mikroslužby jsou první softwarovou architekturou, která se objevila jako reakce na postupy DevOps, která je navržena tak, aby naše systémy byly flexibilnější, škálovatelnější a zajistily nepřetržité poskytování. Jak to dělá? Snížením objemu služeb, snížením rozsahu problémů, které tyto služby zpracovávají, zkrácením dodacích lhůt. To znamená, že redukujeme a zjednodušujeme části systému, zvyšujeme jejich počet a podle toho neustále roste složitost interakcí mezi těmito částmi, to znamená, že vznikají nové problémy, které musíme řešit.
Mikroslužby nekončí, mikroslužby jsou obecně již včera, protože přichází Serverless. Všechny servery shořely, žádné servery, žádné operační systémy, jen čistý spustitelný kód. Konfigurace jsou oddělené, stavy jsou oddělené, vše je řízeno událostmi. Krása, čistota, ticho, žádné akce, nic se neděje, naprostý pořádek.
Kde je ta složitost? Potíž je samozřejmě v interakcích. Kolik může jedna funkce dělat sama o sobě? Jak interaguje s dalšími funkcemi? Fronty zpráv, databáze, balancery. Jak znovu vytvořit nějakou událost, když došlo k selhání? Mnoho otázek a málo odpovědí.
Microservices a Serverless jsou to, co my geekští hipsteři nazýváme Cloud Native. Všechno je to o cloudu. Ale cloud je také ze své podstaty omezený ve své škálovatelnosti. Jsme zvyklí o něm uvažovat jako o distribuovaném systému. Kde vlastně servery poskytovatelů cloudu žijí? V datových centrech. To znamená, že zde máme jakýsi centralizovaný, velmi omezený, distribuovaný model.
Dnes už chápeme, že internet věcí už nejsou jen velká slova, že i 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 sloučena do cloudu a nahrána z cloudu.
Cloud nevydrží, a tak stále častěji mluvíme o něčem, čemu se říká edge computing. Nebo se mi také líbí nádherná definice „fog computingu“. Je zahalena mystikou romantismu a tajemna.
Fog computing. Jde o to, že mraky jsou centralizované shluky vody, páry, ledu a kamenů. A mlha jsou kapky vody, které jsou rozptýleny kolem nás v atmosféře.
V paradigmatu mlhy většinu práce vykonávají tyto kapky zcela autonomně nebo ve spolupráci s jinými kapkami. A do cloudu se obrátí pouze tehdy, když je opravdu tlačí.
Tedy opět decentralizace, autonomie a samozřejmě mnozí z vás již chápou, kam to všechno směřuje, protože o decentralizaci nelze mluvit, aniž bychom nezmínili blockchain.
Jsou tací, kteří věří, to jsou ti, kteří investovali do kryptoměny. Jsou tací, kteří věří, ale bojí se, jako například já. A jsou i tací, kteří nevěří. Zde můžete zacházet jinak. Je tu technologie, nová neznámá záležitost, jsou tu problémy. Jako každá nová technologie vyvolává více otázek, než odpovídá.
Hype kolem blockchainu je pochopitelný. Pomineme-li zlatou horečku, samotná technologie skrývá pozoruhodné sliby pro lepší budoucnost: více svobody, více autonomie, distribuovaná globální důvěra. Co nechtít?
V souladu s tím stále více inženýrů po celém světě začíná vyvíjet decentralizované aplikace. A to je síla, kterou nelze odbýt pouhým prohlášením: „Ach, blockchain je jen špatně implementovaná distribuovaná databáze.“ Nebo jak skeptici rádi říkají: „Pro blockchain neexistují žádné skutečné aplikace.“ Když se nad tím zamyslíte, před 150 lety říkali totéž o elektřině. A dokonce měli v něčem pravdu, protože to, co dnes umožňuje elektřina, nebylo v 19. století možné.
Mimochodem, kdo ví, jaké logo je na obrazovce? Toto je Hyperledger. Jedná se o projekt, který je vyvíjen pod záštitou The Linux Foundation a zahrnuje sadu blockchainových technologií. To je skutečně síla naší open source komunity.
Chaos Engineering
Systém, který vyvíjíme, se tedy stává stále složitějším, stále chaotičtějším a stále více přizpůsobivým. Netflix je průkopníkem mikroservisních systémů. Byli mezi prvními, kdo to pochopili, vyvinuli sadu nástrojů, které nazvali Simian Army, z nichž nejznámější byl . Definoval to, co se stalo známým jako .
Mimochodem, v procesu práce na zprávě jsme dokonce přeložili tento text do ruštiny, takže přejděte na , číst, komentovat, nadávat.
Stručně řečeno, principy chaosového inženýrství říkají následující. Komplexní distribuované systémy jsou ze své podstaty nepředvídatelné a ze své podstaty zabugované. Chyby jsou nevyhnutelné, což znamená, že musíme tyto chyby přijmout a pracovat s těmito systémy zcela jiným způsobem.
My sami se musíme pokusit zavést tyto chyby do našich produkčních systémů, abychom otestovali naše systémy na stejnou přizpůsobivost, právě tuto schopnost sebeorganizace, pro přežití.
A to vše mění. Nejen, jak zavádíme systémy do výroby, ale také jak je vyvíjíme, jak je testujeme. Nedochází k žádnému procesu stabilizace nebo zmrazení kódu, naopak dochází k neustálému procesu destabilizace. Snažíme se zabít systém a uvidíme, jak přežije.
Protokoly distribuované systémové integrace
V souladu s tím to vyžaduje, aby se naše systémy nějak změnily. Aby se staly stabilnějšími, potřebují nějaké nové protokoly pro interakci mezi jejich částmi. Aby se tyto části mohly dohodnout a dojít k nějaké samoorganizaci. A vznikají nejrůznější nové nástroje, nové protokoly, kterým říkám „protokoly pro interakci distribuovaných systémů“.
O čem to mluvím? Za prvé, projekt . Někteří se pokoušejí vytvořit obecný distribuovaný sledovací protokol, který je naprosto nepostradatelným nástrojem pro ladění složitých distribuovaných systémů.
Dále - . Říkáme, že nemůžeme předvídat, co se se systémem stane, to znamená, že potřebujeme zvýšit jeho pozorovatelnost, pozorovatelnost. Opentracing patří do rodiny nástrojů, které umožňují sledovatelnost našich systémů. Ale potřebujeme pozorovatelnost, abychom mohli určit, zda se systém chová tak, jak očekáváme, nebo ne. Jak definujeme očekávané chování? Definováním nějaké politiky, nějakého souboru pravidel. Projekt Open Policy Agent pracuje na definování této sady pravidel napříč spektrem od přístupu po alokaci zdrojů.
Jak jsme řekli, naše systémy jsou stále více řízeny událostmi. Serverless je skvělým příkladem systémů řízených událostmi. Abychom mohli přenášet události mezi systémy a sledovat je, potřebujeme nějaký společný jazyk, nějaký společný protokol, jak o událostech mluvíme, jak si je přenášíme. Tomu se říká projekt .
Neustálý proud změn, který zaplavuje naše systémy a neustále je destabilizuje, je nepřetržitý proud softwarových artefaktů. Abychom udrželi tento neustálý tok změn, potřebujeme nějaký společný protokol, pomocí kterého můžeme mluvit o tom, co je softwarový artefakt, jak se testuje, jakým ověřením prošel. Tomu se říká projekt . Tedy běžný protokol metadat pro softwarové artefakty.
A konečně, pokud chceme, aby naše systémy byly zcela nezávislé, adaptivní a samoorganizované, musíme jim dát právo na sebeidentifikaci. Projekt s názvem To je přesně to, co dělá. I toto je projekt pod záštitou Cloud Native Computing Foundation.
Všechny tyto projekty jsou mladé, všechny potřebují naši lásku, naše potvrzení. To vše je open source, naše testování, naše implementace. Ukazují nám, kam technologie míří.
DevOps ale nikdy nebylo primárně o technologiích, vždy šlo o spolupráci mezi lidmi. A pokud tedy chceme, aby se systémy, které vyvíjíme, změnily, musíme se změnit i my sami. Ve skutečnosti se stejně měníme; nemáme moc na výběr.
Existuje úžasné Britská spisovatelka Rachel Botsman, ve které píše o vývoji důvěry v historii lidstva. Říká, že zpočátku v primitivních společnostech byla důvěra místní, to znamená, že jsme věřili pouze těm, které osobně známe.
Pak nastalo velmi dlouhé období – doba temna, kdy se centralizovala důvěra, kdy jsme začali věřit lidem, které neznáme na základě toho, že patříme do stejné veřejné nebo státní instituce.
A to je to, co vidíme v našem moderním světě: důvěra se stále více distribuuje a decentralizuje a je založena na svobodě informačních toků, na dostupnosti informací.
Pokud se nad tím zamyslíte, právě tato dostupnost, která tuto důvěru umožňuje, je to, co vy i já implementujeme. To znamená, že se musí změnit způsob, jakým spolupracujeme, i způsob, jakým to děláme, protože staré centralizované, hierarchické IT organizace již nefungují. Začínají odumírat.
Základy organizace DevOps
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ě mezi sebou spolupracují pomocí asynchronní komunikace, využívající vysoce transparentní komunikační protokoly. Velmi krásné, že? Moc krásná budoucnost.
Nic z toho samozřejmě není možné bez kulturních změn. Musíme mít transformační vedení, osobní zodpovědnost, vnitřní motivaci.
To je základ organizací DevOps: informační transparentnost, asynchronní komunikace, transformační vedení, decentralizace.
Vyhořet
Systémy, kterých jsme součástí, a ty, které budujeme, jsou stále více chaotické a pro nás lidi je těžké se s touto myšlenkou vyrovnat, je těžké vzdát se iluze kontroly. Snažíme se je nadále ovládat a často to vede k vyhoření. Říkám to z vlastní zkušenosti, také jsem se spálil, znemožnily mě i nepředvídané poruchy ve výrobě.
K vyhoření dochází, když se snažíme ovládat něco, co je ze své podstaty nekontrolovatelné. Když vyhoříme, všechno ztrácí smysl, protože ztrácíme chuť dělat něco nového, dostáváme se do defenzívy a začínáme bránit to, co máme.
Inženýrská profese, jak často rád připomínám, je především kreativní profese. Ztratíme-li chuť něco tvořit, pak se proměníme v popel, proměníme se v popel. Lidé vyhoří, vyhoří celé organizace.
Podle mého názoru jedině přijetí tvůrčí síly chaosu, teprve budování spolupráce podle jeho principů je to, co nám pomůže neztratit to, co je v naší profesi dobré.
To je to, co vám přeji: milovat svou práci, milovat to, co děláme. Tento svět se živí informacemi, máme tu čest ho krmit. Takže studujme chaos, buďme chaosologové, přinášejme hodnotu, tvořme něco nového, no, problémy, jak jsme již zjistili, jsou nevyhnutelné, a když se objeví, řekneme prostě „Ops!“ A problém je vyřešen.
Co jiného než Chaos Monkey?
Ve skutečnosti jsou všechny tyto nástroje tak mladé. Stejný Netflix vytvořil nástroje pro sebe. Sestavte si vlastní nástroje. Přečtěte si principy chaosového inženýrství a dodržujte tyto principy, spíše než se pokoušejte najít jiné nástroje, které již vytvořil někdo jiný.
Pokuste se pochopit, jak se vaše systémy porouchají, začněte je bourat a uvidíte, jak vydrží. To je na prvním místě. A můžete hledat nástroje. Existují všechny druhy projektů.
Moc jsem nepochopil ten moment, kdy jste řekl, že systém nelze zjednodušit zjednodušením jeho komponent, a hned jste přešel k mikroslužbám, které zjednodušují systém tím, že zjednodušují samotné komponenty a komplikují interakce. Jde v podstatě o dvě části, které si odporují.
Je to tak, mikroslužby jsou obecně velmi kontroverzní téma. Ve skutečnosti zjednodušení dílů zvyšuje flexibilitu. Co mikroslužby poskytují? Poskytují nám flexibilitu a rychlost, ale rozhodně nám nedávají jednoduchost. Zvyšují obtížnost.
Takže ve filozofii DevOps nejsou mikroslužby tak dobrá věc?
Každé dobro má odvrácenou stranu. Výhodou je, že zvyšuje flexibilitu, umožňuje nám provádět změny rychleji, ale zvyšuje složitost a tím i křehkost celého systému.
Přesto, na co je kladen větší důraz: na zjednodušení interakce nebo na zjednodušení částí?
Důraz je samozřejmě kladen na zjednodušení interakcí, protože pokud se na to podíváme z pohledu toho, jak s vámi pracujeme, pak je v první řadě potřeba dbát na zjednodušení interakcí, a ne na zjednodušení práce každého z nás zvlášť. Protože zjednodušit práci znamená proměnit se v roboty. Tady v McDonaldu to funguje normálně, když máte návod: tu dáte burger, tu nalijete omáčku. To v naší kreativní práci vůbec nefunguje.
Je pravda, že všechno, co jsi řekl, žije ve světě bez konkurence a chaos tam je tak laskavý a v tomto chaosu nejsou žádné rozpory, nikdo nechce nikoho jíst ani zabít? Jak by na tom měla být konkurence a DevOps?
No, záleží na tom, o jaké soutěži se bavíme. Jde o konkurenci na pracovišti nebo konkurenci mezi firmami?
O konkurenci služeb, které existují, protože služby nejsou několika společnostmi. Vytváříme nový typ informačního prostředí a žádné prostředí nemůže žít bez konkurence. Všude je konkurence.
To samé Netflix, bereme je jako vzor. Proč s tím přišli? Protože potřebovali být konkurenceschopní. Tato flexibilita a rychlost pohybu je právě tím velmi konkurenčním požadavkem, vnáší do našich systémů chaos. To znamená, že chaos není něco, co vědomě děláme, protože to chceme, je to něco, co se děje, protože si to svět žádá. Musíme se prostě přizpůsobit. A chaos, to je přesně výsledek soutěže.
Znamená to, že chaos je absence cílů, jak to bylo? Nebo ty cíle, které nechceme vidět? Jsme v domě a nerozumíme cílům ostatních. Konkurence je ve skutečnosti dána tím, že máme jasné cíle a víme, kde v každém dalším okamžiku skončíme. To je z mého pohledu podstata DevOps.
Také pohled na otázku. Myslím, že všichni máme stejný cíl: přežít a udělat to s
největší radost. A konkurenční cíl každé organizace je stejný. K přežití často dochází díky konkurenci, s tím se nedá nic dělat.
Letošní konference se uskuteční 7. prosince v Technopolis. Přihlášky na reportáže přijímáme do 11. listopadu. nás, pokud byste chtěli mluvit.
Registrace pro účastníky je otevřena, vstupenky stojí 7000 XNUMX rublů. Připoj se k nám!
Zdroj: www.habr.com