Na lanskoletni o teoriji kaosa in glavnih principih inženiringa kaosa ter pojasnil, kako deluje idealna DevOps organizacija prihodnosti.
Pripravili smo besedilno različico poročila.
Dobro jutro!
DevOpsDays v Moskvi že drugo leto zapored, drugič sem na tem odru, mnogi od vas ste v tej sobi drugič. Kaj to pomeni? To pomeni, da gibanje DevOps v Rusiji raste, se množi, in kar je najpomembneje, to pomeni, da je prišel čas, da govorimo o tem, kaj je DevOps v letu 2018.
Dvignite roke, kdo misli, da je DevOps poklic že leta 2018? Obstajajo taki. Ali so v sobi kakšni inženirji DevOps, katerih opis delovnega mesta piše »Inženir DevOps«? Ali so v sobi kakšni upravitelji DevOps? Tega ni. DevOps arhitekti? Tudi št. Ne dovolj. Je res res, da nihče ne pravi, da je inženir DevOps?
Torej večina od vas misli, da je to anti-vzorec? Da tak poklic ne bi smel obstajati? Lahko si mislimo, kar hočemo, a medtem ko mi razmišljamo, se industrija slovesno premika naprej ob zvoku DevOps trobente.
Kdo je že slišal za novo temo, imenovano DevDevOps? To je nova tehnika, ki omogoča učinkovito sodelovanje med razvijalci in devops. In ne tako novo. Sodeč po Twitterju so se o tem začeli pogovarjati že pred 4 leti. In do zdaj zanimanje za to narašča in raste, torej obstaja problem. Problem je treba rešiti.
Smo ustvarjalni ljudje, ne le počivamo. Pravimo: DevOps ni dovolj obsežna beseda, manjka ji še najrazličnejših, zanimivih elementov. In gremo v naše tajne laboratorije in začnemo proizvajati zanimive mutacije: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Logika je železna, kajne? Naš sistem dostave ne deluje, naši sistemi so nestabilni in naši uporabniki so nezadovoljni, nimamo časa za pravočasno uvedbo programske opreme, ne ustrezamo proračunu. Kako bomo vse to rešili? Izmislili bomo novo besedo! Končalo se bo z "Ops" in težava je rešena.
Zato ta pristop imenujem - "Ops, in problem je rešen."
Vse to pade v ozadje, če se spomnimo, zakaj smo se vsega tega domislili. Celotno zadevo DevOps smo si zamislili, da bi bila dobava programske opreme in naše lastno delo v tem procesu čim bolj neovirana, neboleča, učinkovita in, kar je najpomembneje, prijetna.
DevOps je zrasel iz bolečine. In utrujeni smo od trpljenja. In da bi se vse to zgodilo, se zanašamo na zimzelene prakse: učinkovito sodelovanje, pretočne prakse in, kar je najpomembneje, sistemsko razmišljanje, saj brez tega noben DevOps ne deluje.
Kakšen je sistem?
In če smo že pri sistemskem razmišljanju, se spomnimo, kaj je sistem.
Če ste revolucionarni heker, potem je za vas sistem očitno zlo. To je oblak, ki visi nad vami in vas sili v stvari, ki jih ne želite.
Z vidika sistemskega razmišljanja je sistem celota, sestavljena iz delov. V tem smislu je vsak od nas sistem. Organizacije, v katerih delamo, so sistemi. In to, kar ti in jaz gradiva, se imenuje sistem.
Vse to je del enega velikega družbeno-tehnološkega sistema. In samo če razumemo, kako ta družbeno-tehnološki sistem deluje skupaj, šele takrat bomo lahko v tej zadevi nekaj resnično optimizirali.
Z vidika sistemskega razmišljanja ima sistem različne zanimive lastnosti. Prvič, sestavljen je iz delov, kar pomeni, da je njegovo obnašanje odvisno od obnašanja delov. Poleg tega so vsi njeni deli medsebojno odvisni. Izkazalo se je, da več ko ima sistem delov, težje je razumeti ali predvideti njegovo vedenje.
Z vedenjskega vidika je zanimivo še eno dejstvo. Sistem zmore nekaj, česar ne zmore noben njegov posamezni del.
Kot je rekel dr. Russell Ackoff (eden od utemeljiteljev sistemskega razmišljanja), je to precej enostavno dokazati z miselnim eksperimentom. Na primer, kdo v sobi zna napisati kodo? Rokov je veliko in to je normalno, saj je to ena glavnih zahtev našega poklica. Ali znate pisati, vendar lahko vaše roke pišejo kodo ločeno od vas? So ljudje, ki bodo rekli: "Niso moje roke tiste, ki pišejo kodo, to so moji možgani, ki pišejo kodo." Ali lahko vaši možgani pišejo kodo ločeno od vas? No, verjetno ne.
Možgani so neverjeten stroj, ne vemo niti 10 %, kako tam delujejo, vendar ne morejo delovati ločeno od sistema, ki je naše telo. In to je lahko dokazati: odprite lobanjo, izvlecite možgane, postavite jih pred računalnik, naj poskusi napisati nekaj preprostega. "Hello, world" v Pythonu, na primer.
Če lahko sistem naredi nekaj, česar ne more noben njegov del posebej, potem to pomeni, da njegovo vedenje ni določeno z vedenjem njegovih delov. S čim se potem določa? Določa ga interakcija med temi deli. In v skladu s tem, več ko je delov, bolj zapletene kot so interakcije, težje je razumeti in napovedati obnašanje sistema. In to dela takšen sistem kaotičen, saj lahko vsaka, še tako nepomembna, nevidna sprememba v kateremkoli delu sistema privede do popolnoma nepredvidljivih rezultatov.
To občutljivost na začetne pogoje je prvi odkril in proučeval ameriški meteorolog Ed Lorenz. Kasneje so ga poimenovali »učinek metulja« in pripeljal do razvoja gibanja znanstvene misli, imenovanega »teorija kaosa«. Ta teorija je postala ena glavnih sprememb paradigme v znanosti 20. stoletja.
Teorija kaosa
Ljudje, ki preučujejo kaos, se imenujejo kaosologi.
Pravzaprav je bil razlog za to poročilo ta, da sem pri delu s kompleksnimi porazdeljenimi sistemi in velikimi mednarodnimi organizacijami na neki točki spoznal, da se tako počutim. Sem kaoolog. To je v bistvu pameten način povedati: "Ne razumem, kaj se tukaj dogaja, in ne vem, kaj naj storim glede tega."
Mislim, da se tudi mnogi med vami pogosto počutite tako, torej ste tudi kaosologi. Vabim vas v ceh kaozologov. Sistemi, ki jih bomo vi in jaz, dragi kolegi kaozologi, preučevali, se imenujejo "kompleksni prilagodljivi sistemi".
Kaj je prilagodljivost? Prilagodljivost pomeni, da se individualno in kolektivno vedenje delov v takem prilagodljivem sistemu spreminja in samoorganizira ter se odziva na dogodke ali verige mikrodogodkov v sistemu. To pomeni, da se sistem s samoorganizacijo prilagaja spremembam. In ta sposobnost samoorganiziranja temelji na prostovoljnem, popolnoma decentraliziranem sodelovanju prostih avtonomnih agentov.
Druga zanimiva lastnost takih sistemov je, da so prosto prilagodljivi. Kar bi nas kot kaoologe inženirje nedvomno moralo zanimati. Torej, če rečemo, da je obnašanje kompleksnega sistema določeno z medsebojnim delovanjem njegovih delov, kaj naj nas potem zanima? Interakcija.
Zanimivi sta še dve ugotovitvi.
Prvič, razumemo, da kompleksnega sistema ni mogoče poenostaviti s poenostavitvijo njegovih delov. Drugič, edini način za poenostavitev kompleksnega sistema je poenostavitev interakcij med njegovimi deli.
Kako komuniciramo? Ti in jaz sva del velikega informacijskega sistema, imenovanega človeška družba. Interakcija poteka preko skupnega jezika, če ga imamo, če ga najdemo.
Toda jezik sam je kompleksen prilagodljiv sistem. Zato moramo za učinkovitejšo in preprostejšo interakcijo ustvariti neke vrste protokole. Se pravi neko zaporedje simbolov in dejanj, zaradi katerih bo izmenjava informacij med nami preprostejša, predvidljivejša, bolj razumljiva.
Hočem reči, da je v vsem mogoče zaslediti trende k kompleksnosti, k prilagodljivosti, k decentralizaciji, k kaosu. In v sistemih, ki jih gradiva ti in jaz, in v tistih sistemih, katerih del sva.
In da ne bomo neutemeljeni, poglejmo, kako se spreminjajo sistemi, ki jih ustvarjamo.
Čakal si na to besedo, razumem. Smo na konferenci DevOps, danes bo ta beseda slišana približno sto tisočkrat in potem bomo ponoči sanjali o njej.
Mikrostoritve so prva arhitektura programske opreme, ki se je pojavila kot reakcija na prakse DevOps, ki je zasnovana tako, da naredi naše sisteme bolj prilagodljive, bolj razširljive in zagotavlja neprekinjeno dostavo. Kako ji to uspe? Z zmanjševanjem obsega storitev, zmanjševanjem obsega problemov, ki jih te storitve obdelujejo, skrajšanjem dobavnih rokov. To pomeni, da zmanjšamo in poenostavimo dele sistema, povečamo njihovo število, zato se kompleksnost interakcij med temi deli vedno poveča, to pomeni, da se pojavijo novi problemi, ki jih moramo rešiti.
Mikrostoritev ni konec, mikrostoritve so nasploh že včeraj, saj prihaja Serverless. Vsi strežniki so zgoreli, brez strežnikov, brez operacijskih sistemov, samo čista izvršljiva koda. Konfiguracije so ločene, stanja so ločena, vse je nadzorovano z dogodki. Lepota, čistoča, tišina, brez dogodkov, nič se ne dogaja, popoln red.
Kje je kompleksnost? Težava je seveda v interakcijah. Koliko lahko ena funkcija naredi sama? Kako deluje z drugimi funkcijami? Čakalne vrste sporočil, baze podatkov, balanserji. Kako poustvariti nek dogodek, ko je prišlo do napake? Veliko vprašanj in malo odgovorov.
Mikrostoritve in brez strežnika mi, geek hipsterji, imenujemo Cloud Native. Vse se vrti okoli oblaka. Toda oblak je tudi sam po sebi omejen v svoji razširljivosti. Navajeni smo o tem razmišljati kot o porazdeljenem sistemu. Kje pravzaprav živijo strežniki ponudnikov oblakov? V podatkovnih centrih. To pomeni, da imamo tukaj nekakšen centraliziran, zelo omejen, porazdeljen model.
Danes razumemo, da internet stvari niso več le velike besede, da nas že po skromnih napovedih v naslednjih petih do desetih letih čakajo milijarde naprav, povezanih v internet. Ogromno koristnih in neuporabnih podatkov, ki se bodo zlili v oblak in naložili iz oblaka.
Oblak ne bo trajal, zato vse pogosteje govorimo o nečem, kar se imenuje robno računalništvo. Ali pa mi je všeč tudi čudovita definicija "računalništva v megli". Zavito je v mistiko romantike in skrivnostnosti.
Računalništvo v megli. Bistvo je, da so oblaki centralizirane kepe vode, pare, ledu in kamenja. In megla so kapljice vode, ki so razpršene okoli nas v ozračju.
V paradigmi megle večino dela opravijo te kapljice povsem avtonomno ali v sodelovanju z drugimi kapljicami. In na oblak se obrnejo šele takrat, ko jih zares močno pritisne.
Se pravi spet decentralizacija, avtonomija in seveda mnogi že razumete, kam vse to pelje, saj ne morete govoriti o decentralizaciji, ne da bi omenili blockchain.
Obstajajo tisti, ki verjamejo, to so tisti, ki so investirali v kriptovalute. So takšni, ki verjamejo, a se bojijo, kot jaz na primer. In obstajajo tisti, ki ne verjamejo. Tukaj lahko obravnavate drugače. Obstaja tehnologija, nova neznana zadeva, obstajajo težave. Kot vsaka nova tehnologija postavlja več vprašanj kot daje odgovorov.
Pomp okrog blockchaina je razumljiv. Če pustimo zlato mrzlico na stran, ima sama tehnologija izjemne obljube za svetlejšo prihodnost: več svobode, več avtonomije, porazdeljeno globalno zaupanje. Česa si ne želite?
V skladu s tem vedno več inženirjev po vsem svetu začenja razvijati decentralizirane aplikacije. In to je moč, ki je ni mogoče zavreči preprosto z besedami: "Ah, blockchain je le slabo implementirana porazdeljena zbirka podatkov." Ali kot radi rečejo skeptiki: "Za blockchain ni pravih aplikacij." Če pomislite, so pred 150 leti enako govorili o elektriki. In v nečem so imeli celo prav, kajti to, kar elektrika omogoča danes, v 19. stoletju nikakor ni bilo mogoče.
Mimogrede, kdo ve, kakšen logotip je na zaslonu? To je Hyperledger. Gre za projekt, ki se razvija pod okriljem The Linux Foundation in vključuje nabor tehnologij blockchain. To je resnično moč naše odprtokodne skupnosti.
Inženiring kaosa
Torej sistem, ki ga razvijamo, postaja vedno bolj zapleten, vedno bolj kaotičen in vedno bolj prilagodljiv. Netflix so pionirji sistemov mikrostoritev. Bili so med prvimi, ki so to razumeli, razvili so nabor orodij, ki so jih poimenovali Simian Army, med katerimi je najbolj znano . Opredelil je, kaj je postalo znano kot .
Mimogrede, v procesu dela na poročilu smo to besedilo celo prevedli v ruščino, zato pojdite na , brati, komentirati, grajati.
Na kratko, načela inženiringa kaosa pravijo naslednje. Kompleksni porazdeljeni sistemi so sami po sebi nepredvidljivi in imajo napake. Napake so neizogibne, kar pomeni, da moramo te napake sprejeti in delati s temi sistemi na povsem drugačen način.
Sami moramo poskušati vnesti te napake v naše proizvodne sisteme, da bi preizkusili svoje sisteme glede te iste prilagodljivosti, prav te sposobnosti samoorganizacije, preživetja.
In to spremeni vse. Ne samo, kako lansiramo sisteme v proizvodnjo, ampak tudi, kako jih razvijamo, kako jih testiramo. Ni procesa stabilizacije ali zamrznitve kode, nasprotno, poteka stalen proces destabilizacije. Poskušamo ubiti sistem in zagotoviti, da bo še naprej preživel.
Protokoli porazdeljene sistemske integracije
Zato se morajo naši sistemi nekako spremeniti. Da bi postali bolj stabilni, potrebujejo nekaj novih protokolov za interakcijo med svojimi deli. Da se ti deli dogovorijo in pridejo do neke vrste samoorganizacije. In pojavijo se različna nova orodja, novi protokoli, ki jih imenujem "protokoli za interakcijo porazdeljenih sistemov."
O čem govorim? Prvič, projekt . Nekateri poskušajo ustvariti splošen protokol porazdeljenega sledenja, ki je popolnoma nepogrešljivo orodje za odpravljanje napak v kompleksnih porazdeljenih sistemih.
Nadalje - . Pravimo, da ne moremo predvideti, kaj se bo zgodilo s sistemom, se pravi, da moramo povečati njegovo opazljivost, opazljivost. Opentracing spada v družino orodij, ki našim sistemom omogočajo opazovanje. Vendar potrebujemo opazljivost, da ugotovimo, ali se sistem obnaša, kot pričakujemo, ali ne. Kako definiramo pričakovano vedenje? Z definiranjem neke vrste politike, nekega sklopa pravil. Projekt Open Policy Agent si prizadeva definirati ta sklop pravil v širokem spektru, od dostopa do dodeljevanja virov.
Kot smo rekli, naši sistemi vedno bolj temeljijo na dogodkih. Brez strežnika je odličen primer sistemov, ki jih vodijo dogodki. Da lahko prenašamo dogodke med sistemi in jim sledimo, potrebujemo nek skupni jezik, nek skupni protokol, kako govorimo o dogodkih, kako jih prenašamo drug drugemu. Tako se imenuje projekt .
Nenehen tok sprememb, ki preplavlja naše sisteme in jih nenehno destabilizira, je neprekinjen tok programskih artefaktov. Da lahko vzdržujemo ta stalen tok sprememb, potrebujemo nekakšen skupni protokol, prek katerega se lahko pogovarjamo o tem, kaj je artefakt programske opreme, kako se testira, kakšno preverjanje je prestal. Tako se imenuje projekt . To je skupni metapodatkovni protokol za artefakte programske opreme.
In končno, če želimo, da so naši sistemi popolnoma neodvisni, prilagodljivi in samoorganizirani, jim moramo dati pravico do samoidentifikacije. Projekt imenovan Točno to počne. Tudi to je projekt pod okriljem Cloud Native Computing Foundation.
Vsi ti projekti so mladi, vsi potrebujejo našo ljubezen, naše potrjevanje. To je vse odprtokodno, naše testiranje, naša implementacija. Kažejo nam, kam gre tehnologija.
Vendar pri DevOps nikoli ni šlo predvsem za tehnologijo, vedno je šlo za sodelovanje med ljudmi. In v skladu s tem, če želimo, da se sistemi, ki jih razvijamo, spremenijo, se moramo spremeniti tudi mi sami. Pravzaprav se tako ali tako spreminjamo, nimamo veliko izbire.
Obstaja čudovito Britanska pisateljica Rachel Botsman, v kateri piše o evoluciji zaupanja skozi človeško zgodovino. Pravi, da je bilo sprva v primitivnih družbah zaupanje lokalno, se pravi, da smo zaupali samo tistim, ki jih osebno poznamo.
Potem je bilo zelo dolgo obdobje – temen čas, ko je bilo zaupanje centralizirano, ko smo začeli zaupati ljudem, ki jih ne poznamo na podlagi dejstva, da pripadamo isti javni oziroma državni instituciji.
In to je tisto, kar vidimo v našem sodobnem svetu: zaupanje postaja vse bolj porazdeljeno in decentralizirano, temelji pa na svobodi pretoka informacij, na dostopnosti informacij.
Če dobro pomislite, prav to dostopnost, ki omogoča to zaupanje, je tisto, kar vi in jaz izvajamo. To pomeni, da se morata spremeniti način našega sodelovanja in način, na katerega to počnemo, saj stare centralizirane, hierarhične IT organizacije ne delujejo več. Začnejo odmirati.
Osnove organizacije DevOps
Idealna organizacija DevOps prihodnosti je decentraliziran, prilagodljiv sistem, sestavljen iz avtonomnih ekip, od katerih vsako sestavljajo avtonomni posamezniki. Te ekipe so razpršene po vsem svetu in učinkovito sodelujejo med seboj z uporabo asinhrone komunikacije in zelo preglednih komunikacijskih protokolov. Zelo lepo, kajne? Zelo lepa prihodnost.
Seveda nič od tega ni mogoče brez kulturnih sprememb. Imeti moramo transformacijsko vodstvo, osebno odgovornost, notranjo motivacijo.
To je osnova organizacij DevOps: informacijska transparentnost, asinhrone komunikacije, transformacijsko vodenje, decentralizacija.
Izgorel
Sistemi, katerih del smo in jih gradimo, so vse bolj kaotični in ljudje se s to mislijo težko spopadamo, težko se odrečemo iluziji nadzora. Poskušamo jih še naprej nadzorovati, kar pogosto vodi v izgorelost. To govorim iz lastnih izkušenj, tudi sam sem se opekel, onemogočili so me tudi nepredvideni izpadi v proizvodnji.
Izgorelost se pojavi, ko poskušamo nadzorovati nekaj, kar je samo po sebi neobvladljivo. Ko pregorimo, vse izgubi smisel, saj izgubimo željo po nečem novem, se postavimo v obrambo in začnemo braniti tisto, kar imamo.
Inženirski poklic, kot se pogosto rad spomnim, je predvsem kreativen poklic. Če izgubimo željo, da bi nekaj ustvarili, potem se spremenimo v pepel, spremenimo v pepel. Ljudje izgorevajo, izgorevajo cele organizacije.
Po mojem mnenju je samo sprejemanje ustvarjalne moči kaosa, samo gradnja sodelovanja po njegovih načelih tisto, kar nam bo pomagalo, da ne bomo izgubili dobrega v našem poklicu.
To je tisto, kar vam želim: ljubiti svoje delo, ljubiti to, kar počnemo. Ta svet se hrani z informacijami, mi imamo čast, da jih hranimo. Zato preučujmo kaos, bodimo kaosologi, prinašajmo vrednost, ustvarjajmo nekaj novega, no, težave so, kot smo že ugotovili, neizogibne in ko se pojavijo, preprosto rečemo »Ups!« In problem je rešen.
Kaj drugega kot Chaos Monkey?
Pravzaprav so vsi ti instrumenti tako mladi. Isti Netflix je zase izdelal orodja. Zgradite svoja orodja. Preberite načela inženiringa kaosa in živite v skladu s temi načeli, namesto da poskušate najti druga orodja, ki jih je nekdo že zgradil.
Poskusite razumeti, kako se vaši sistemi kvarijo, in jih začnite razbijati ter preverite, kako vzdržijo. To je na prvem mestu. In lahko iščete orodja. Projekti so najrazličnejši.
Nisem dobro razumel trenutka, ko ste rekli, da sistema ni mogoče poenostaviti s poenostavitvijo komponent in ste takoj prešli na mikrostoritve, ki sistem poenostavljajo s poenostavitvijo samih komponent in zapletanjem interakcij. To sta v bistvu dva dela, ki si nasprotujeta.
Tako je, mikrostoritve so nasploh zelo kontroverzna tema. Pravzaprav poenostavitev delov poveča prilagodljivost. Kaj ponujajo mikrostoritve? Dajejo nam prilagodljivost in hitrost, zagotovo pa nam ne dajejo preprostosti. Povečujejo težavnost.
Torej v filozofiji DevOps mikrostoritve niso tako dobra stvar?
Vsako dobro ima tudi hrbtno stran. Prednost je v tem, da poveča fleksibilnost, kar nam omogoča hitrejše izvajanje sprememb, vendar poveča kompleksnost in s tem krhkost celotnega sistema.
Kljub temu, na čem je večji poudarek: na poenostavitvi interakcije ali na poenostavitvi delov?
Poudarek je seveda na poenostavitvi interakcij, kajti če gledamo na to z vidika našega dela z vami, potem moramo biti najprej pozorni na poenostavitev interakcij in ne na poenostavitev dela. vsakega od nas posebej. Kajti poenostaviti delo pomeni spremeniti se v robote. Pri nas v McDonald'su deluje normalno, ko imaš navodila: tukaj daš burger, tukaj ga poliješ z omako. Pri našem ustvarjalnem delu to nikakor ne deluje.
Je res, da vse, kar ste rekli, živi v svetu brez konkurence in je kaos tam tako prijazen in v tem kaosu ni nobenih nasprotij, nihče noče nikogar pojesti ali ubiti? Kako naj se obneseta konkurenca in DevOps?
No, odvisno o kakšni konkurenci govorimo. Gre za konkurenco na delovnem mestu ali konkurenco med podjetji?
O konkurenci storitev, ki obstaja, ker storitve niso več podjetij. Ustvarjamo nov tip informacijskega okolja in nobeno okolje ne more živeti brez konkurence. Povsod je konkurenca.
Isti Netflix, jih jemljemo za vzor. Zakaj so se tega domislili? Ker so morali biti konkurenčni. Ravno ta prilagodljivost in hitrost gibanja je zelo konkurenčna zahteva, vnaša kaos v naše sisteme. Se pravi, kaos ni nekaj, kar zavestno počnemo, ker si to želimo, je nekaj, kar se zgodi, ker svet to zahteva. Samo prilagoditi se moramo. In kaos je ravno posledica konkurence.
Ali to pomeni, da je kaos tako rekoč odsotnost ciljev? Ali tiste cilje, ki jih nočemo videti? Smo v hiši in ne razumemo ciljev drugih. Tekmovalnost je pravzaprav posledica tega, da imamo jasne cilje in vemo, kje bomo v vsakem naslednjem trenutku prišli. Z mojega vidika je to bistvo DevOps.
Tudi pogled na vprašanje. Mislim, da imamo vsi isti cilj: preživeti in to narediti
največje veselje. In konkurenčni cilj katere koli organizacije je enak. Preživetje se pogosto zgodi s tekmovanjem, glede tega ne morete storiti ničesar.
Letošnja konferenca bo 7. decembra v Tehnopolisu. Prijave na poročila sprejemamo do 11. novembra. nas, če želite govoriti.
Registracija za udeležence je odprta, vstopnice stanejo 7000 rubljev. Pridruži se nam!
Vir: www.habr.com