Anton Weiss, osnivač i direktor Otomato Softwarea, jedan od inicijatora i instruktora prve DevOps certifikacije u Izraelu, govorio je na prošlogodišnjoj o teoriji kaosa i glavnim principima inženjeringa kaosa, a objasnio je i kako funkcionira idealna DevOps organizacija budućnosti.
Pripremili smo tekstualnu verziju izvješća.
Dobro jutro
DevOpsDays u Moskvi drugu godinu zaredom, ovo mi je drugi put na ovoj pozornici, mnogi od vas su u ovoj prostoriji po drugi put. Što to znači? To znači da DevOps pokret u Rusiji raste, umnožava se, i što je najvažnije, to znači da je došlo vrijeme za razgovor o tome što je DevOps u 2018.
Dignite ruke tko misli da je DevOps profesija već 2018.? Ima i takvih. Ima li u prostoriji DevOps inženjera čiji opis posla kaže "DevOps inženjer"? Ima li DevOps upravitelja u sobi? Takvog nema. DevOps arhitekti? Također br. Nedovoljno. Je li stvarno istina da nitko ne kaže da je DevOps inženjer?
Dakle, većina vas misli da je ovo anti-uzorak? Da takvo zanimanje ne bi smjelo postojati? Možemo misliti što god hoćemo, ali dok mi razmišljamo, industrija svečano korača naprijed uz zvuk DevOps trube.
Tko je čuo za novu temu pod nazivom DevDevOps? Ovo je nova tehnika koja omogućuje učinkovitu suradnju između programera i devopsa. I ne tako nova. Sudeći po Twitteru, o tome su već počeli pričati prije 4 godine. I do sada interes za to raste i raste, odnosno postoji problem. Problem treba riješiti.
Mi smo kreativni ljudi, nismo samo mirni. Mi kažemo: DevOps nije dovoljno sveobuhvatna riječ; još uvijek joj nedostaje svakakvih različitih, zanimljivih elemenata. I mi odlazimo u naše tajne laboratorije i počinjemo proizvoditi zanimljive mutacije: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Logika je čelična, zar ne? Naš sustav isporuke nije funkcionalan, naši sustavi su nestabilni i naši korisnici su nezadovoljni, nemamo vremena za uvođenje softvera na vrijeme, ne uklapamo se u budžet. Kako ćemo sve to riješiti? Smislit ćemo novu riječ! Završit će s "Ops" i problem je riješen.
Stoga ovaj pristup nazivam - "Ops, i problem je riješen."
Sve to pada u drugi plan ako se podsjetimo zašto smo sve ovo smislili. Smislili smo cijelu ovu DevOps stvar kako bismo isporuku softvera i naš vlastiti rad u ovom procesu učinili što neometanijim, bezbolnijim, učinkovitijim i, što je najvažnije, ugodnijim.
DevOps je izrastao iz boli. I umorni smo od patnje. A kako bi se sve to dogodilo, oslanjamo se na uvijek poznate prakse: učinkovitu suradnju, prakse protoka i što je najvažnije, sistemsko razmišljanje, jer bez toga nijedan DevOps ne funkcionira.
Što je sustav?
A ako smo već kod sistemskog razmišljanja, podsjetimo se što je sustav.
Ako ste revolucionarni haker, onda je za vas sustav očito zlo. To je oblak koji visi nad vama i tjera vas da činite stvari koje ne želite.
Sa stajališta sistemskog razmišljanja, sustav je cjelina koja se sastoji od dijelova. U tom smislu svatko od nas je sustav. Organizacije u kojima radimo su sustavi. A ono što ti i ja gradimo zove se sustav.
Sve je to dio jednog velikog socio-tehnološkog sustava. I samo ako shvatimo kako ovaj socio-tehnološki sustav funkcionira zajedno, tek tada ćemo moći nešto uistinu optimizirati po ovom pitanju.
Iz perspektive sistemskog razmišljanja, sustav ima različita zanimljiva svojstva. Prvo, sastoji se od dijelova, što znači da njegovo ponašanje ovisi o ponašanju dijelova. Štoviše, svi njegovi dijelovi također su međusobno ovisni. Ispada da što više dijelova sustav ima, to je teže razumjeti ili predvidjeti njegovo ponašanje.
Sa stajališta ponašanja postoji još jedna zanimljiva činjenica. Sustav može učiniti nešto što niti jedan njegov pojedinačni dio ne može.
Kao što je rekao dr. Russell Ackoff (jedan od utemeljitelja sistemskog razmišljanja), to je prilično lako dokazati misaonim eksperimentom. Na primjer, tko u prostoriji zna napisati kod? Puno je ruku i to je normalno jer je to jedan od glavnih uvjeta naše profesije. Znate li pisati, ali mogu li vaše ruke pisati kod odvojeno od vas? Ima ljudi koji će reći: "Nisu moje ruke te koje pišu šifru, moj mozak je taj koji piše šifru." Može li vaš mozak pisati kod odvojeno od vas? Pa, vjerojatno ne.
Mozak je nevjerojatan stroj, ne znamo ni 10% kako radi, ali ne može funkcionirati odvojeno od sustava koji je naše tijelo. A to je lako dokazati: otvorite lubanju, izvadite mozak, stavite ga pred računalo, neka pokuša napisati nešto jednostavno. "Hello, world" u Pythonu, na primjer.
Ako sustav može učiniti nešto što niti jedan njegov dio zasebno ne može, onda to znači da njegovo ponašanje nije određeno ponašanjem njegovih dijelova. Čime se onda određuje? Određen je međudjelovanjem između tih dijelova. I sukladno tome, što je više dijelova, što su interakcije složenije, to je teže razumjeti i predvidjeti ponašanje sustava. A to takav sustav čini kaotičnim, jer svaka, pa i najbeznačajnija, nevidljiva promjena u bilo kojem dijelu sustava može dovesti do potpuno nepredvidivih rezultata.
Ovu osjetljivost na početne uvjete prvi je otkrio i proučavao američki meteorolog Ed Lorenz. Kasnije je to nazvano "efekt leptira" i dovelo je do razvoja pokreta znanstvene misli nazvanog "teorija kaosa". Ova je teorija postala jedna od glavnih promjena paradigme u znanosti 20. stoljeća.
Teorija kaosa
Ljudi koji proučavaju kaos sebe nazivaju kaoolozima.
Zapravo, razlog za ovo izvješće bio je taj što sam, radeći sa složenim distribuiranim sustavima i velikim međunarodnim organizacijama, u jednom trenutku shvatio da se tako osjećam. Ja sam kaozolog. Ovo je u biti pametan način da se kaže: "Ne razumijem što se ovdje događa i ne znam što učiniti u vezi s tim."
Mislim da se i mnogi od vas često tako osjećaju, pa ste i vi kaoolozi. Pozivam vas u ceh kaoologa. Sustavi koje ćemo vi i ja, dragi kolege kaoolozi, proučavati nazivamo "kompleksnim adaptivnim sustavima".
Što je prilagodljivost? Prilagodljivost znači da se individualno i kolektivno ponašanje dijelova u takvom adaptivnom sustavu mijenja i samoorganizira, reagirajući na događaje ili nizove mikrodogađaja u sustavu. Odnosno, sustav se samoorganizacijom prilagođava promjenama. A ta se sposobnost samoorganiziranja temelji na dobrovoljnoj, potpuno decentraliziranoj suradnji slobodnih autonomnih agenata.
Još jedno zanimljivo svojstvo takvih sustava je da su slobodno skalabilni. Ono što bi nas kao kaoologe-inženjere nedvojbeno trebalo zanimati. Dakle, ako kažemo da je ponašanje složenog sustava određeno međudjelovanjem njegovih dijelova, što bi nas onda trebalo zanimati? Interakcija.
Postoje još dva zanimljiva saznanja.
Prvo, razumijemo da se složeni sustav ne može pojednostaviti pojednostavljivanjem njegovih dijelova. Drugo, jedini način da se pojednostavi složeni sustav je pojednostavljivanje interakcija između njegovih dijelova.
Kako komuniciramo? Vi i ja smo svi dijelovi velikog informacijskog sustava koji se zove ljudsko društvo. Mi komuniciramo kroz zajednički jezik, ako ga imamo, ako ga nađemo.
Ali sam jezik složen je adaptivni sustav. Sukladno tome, kako bi interakcija bila učinkovitija i jednostavnija, moramo stvoriti neku vrstu protokola. Odnosno, neki niz simbola i radnji koji će razmjenu informacija među nama učiniti jednostavnijom, predvidljivijom, razumljivijom.
Želim reći da se u svemu mogu pratiti trendovi prema kompleksnosti, prema prilagodljivosti, prema decentralizaciji, prema kaosu. I u sustavima koje gradimo ti i ja, i u sustavima čiji smo dio.
I da ne budemo neutemeljeni, pogledajmo kako se mijenjaju sustavi koje stvaramo.
Čekali ste ovu riječ, razumijem. Nalazimo se na DevOps konferenciji, danas će se ova riječ čuti sto tisuća puta, a onda ćemo je noću sanjati.
Mikroservisi su prva softverska arhitektura koja se pojavila kao reakcija na DevOps praksu, koja je osmišljena da naše sustave učini fleksibilnijima, skalabilnijima i osigura kontinuiranu isporuku. Kako joj to uspijeva? Smanjenjem obima usluga, smanjenjem obima problema koje te usluge obrađuju, smanjenjem vremena isporuke. Odnosno, smanjujemo i pojednostavljujemo dijelove sustava, povećavamo njihov broj, a sukladno tome neizmjerno raste složenost interakcija između tih dijelova, odnosno pojavljuju se novi problemi koje moramo riješiti.
Mikroservisi nisu kraj, mikroservisi su, generalno, već jučer, jer dolazi Serverless. Svi poslužitelji su izgorjeli, nema poslužitelja, nema operativnih sustava, samo čisti izvršni kod. Konfiguracije su odvojene, stanja su odvojena, sve kontroliraju događaji. Ljepota, čistoća, tišina, nema događanja, ništa se ne događa, potpuni red.
Gdje je složenost? Poteškoća je, naravno, u interakcijama. Koliko jedna funkcija može učiniti sama? Kako je u interakciji s drugim funkcijama? Redovi poruka, baze podataka, balanseri. Kako rekreirati neki događaj kada se dogodio kvar? Puno pitanja, a malo odgovora.
Mikroservisi i Serverless su ono što mi geek hipsteri zovemo Cloud Native. Sve je u oblaku. Ali oblak je također inherentno ograničen u svojoj skalabilnosti. Navikli smo o tome razmišljati kao o distribuiranom sustavu. Zapravo, gdje žive poslužitelji pružatelja usluga oblaka? U podatkovnim centrima. Odnosno, ovdje imamo neku vrstu centraliziranog, vrlo ograničenog, distribuiranog modela.
Danas shvaćamo da internet stvari više nisu samo velike riječi da nas čak i prema skromnim predviđanjima u sljedećih pet do deset godina čekaju milijarde uređaja spojenih na internet. Ogromna količina korisnih i beskorisnih podataka koji će se spojiti u oblak i prenijeti iz oblaka.
Oblak neće trajati, pa sve više govorimo o nečemu što se zove rubno računalstvo. Ili mi se također sviđa prekrasna definicija "računalstva u magli". Obavijen je mistikom romantizma i tajanstvenosti.
Računanje u magli. Poanta je da su oblaci centralizirane nakupine vode, pare, leda i kamenja. A magla su kapljice vode koje su oko nas raspršene u atmosferi.
U paradigmi magle većinu posla te kapljice obavljaju potpuno samostalno ili u suradnji s drugim kapljicama. I okreću se oblaku samo kad su stvarno jako pritisnuti.
Odnosno, opet decentralizacija, autonomija i, naravno, mnogi od vas već razumiju kamo sve to vodi, jer ne možete govoriti o decentralizaciji, a da ne spomenete blockchain.
Ima onih koji vjeruju, to su oni koji su uložili u kriptovalute. Ima onih koji vjeruju ali se boje, kao ja na primjer. A ima i onih koji ne vjeruju. Ovdje možete tretirati drugačije. Postoji tehnologija, nova nepoznata materija, postoje problemi. Kao i svaka nova tehnologija, postavlja više pitanja nego što daje odgovora.
Pompa oko blockchaina je razumljiva. Zlatna groznica na stranu, sama tehnologija ima izvanredna obećanja za svjetliju budućnost: više slobode, više autonomije, distribuirano globalno povjerenje. Što ne željeti?
Sukladno tome, sve više inženjera diljem svijeta počinje razvijati decentralizirane aplikacije. A to je moć koja se ne može odbaciti jednostavnim riječima: "Ahh, blockchain je samo loše implementirana distribuirana baza podataka." Ili kako skeptici vole reći: "Nema pravih aplikacija za blockchain." Ako bolje razmislite, prije 150 godina isto su govorili o struji. Čak su na neki način bili i u pravu, jer ono što električna energija omogućuje danas nije bilo moguće u 19. stoljeću.
Usput, tko zna kakav je logo na ekranu? Ovo je Hyperledger. Riječ je o projektu koji se razvija pod pokroviteljstvom The Linux Foundation i uključuje skup blockchain tehnologija. To je doista snaga naše zajednice otvorenog koda.
Inženjering kaosa
Dakle, sustav koji razvijamo postaje sve složeniji, sve kaotičniji i sve prilagodljiviji. Netflix su pioniri mikroservisnih sustava. Oni su bili među prvima koji su to shvatili, razvili su set alata koje su nazvali Simian Army, od kojih je najpoznatiji bio . Definirao je ono što je postalo poznato kao .
Usput, u procesu rada na izvješću, čak smo preveli ovaj tekst na ruski, pa idite na , čitati, komentirati, grditi.
Ukratko, principi inženjeringa kaosa govore sljedeće. Složeni distribuirani sustavi su sami po sebi nepredvidivi i inherentno bugljivi. Pogreške su neizbježne, što znači da te pogreške moramo prihvatiti i raditi s tim sustavima na potpuno drugačiji način.
Mi sami moramo pokušati uvesti te pogreške u naše proizvodne sustave kako bismo testirali naše sustave na tu istu prilagodljivost, upravo tu sposobnost samoorganizacije, za preživljavanje.
I to mijenja sve. Ne samo kako pokrećemo sustave u proizvodnji, već i kako ih razvijamo, kako ih testiramo. Ne postoji proces stabilizacije ili zamrzavanja koda, naprotiv, postoji stalni proces destabilizacije. Pokušavamo ubiti sustav i osigurati mu da nastavi preživljavati.
Protokoli za integraciju distribuiranog sustava
Sukladno tome, to zahtijeva da se naši sustavi nekako promijene. Kako bi postali stabilniji, potrebni su im neki novi protokoli za interakciju između njihovih dijelova. Da se ti dijelovi dogovore i dođu do nekakve samoorganizacije. I pojavljuju se sve vrste novih alata, novi protokoli, koje ja zovem "protokoli za interakciju distribuiranih sustava."
O čemu ja pričam? Prvo, projekt . Neki pokušavaju stvoriti opći protokol za distribuirano praćenje, koji je apsolutno nezamjenjiv alat za otklanjanje pogrešaka u složenim distribuiranim sustavima.
dalje - . Kažemo da ne možemo predvidjeti što će se dogoditi sa sustavom, odnosno trebamo povećati njegovu uočljivost, uočljivost. Opentracing pripada obitelji alata koji našim sustavima daju vidljivost. Ali potrebna nam je sposobnost promatranja kako bismo utvrdili ponaša li se sustav onako kako očekujemo ili ne. Kako definiramo očekivano ponašanje? Definiranjem nekakve politike, nekog skupa pravila. Projekt Open Policy Agent radi na definiranju ovog skupa pravila u rasponu od pristupa do dodjele resursa.
Kao što smo rekli, naši su sustavi sve više vođeni događajima. Bez poslužitelja izvrstan je primjer sustava vođenih događajima. Da bismo mogli prenositi događaje između sustava i pratiti ih, potreban nam je neki zajednički jezik, neki zajednički protokol za to kako govorimo o događajima, kako ih prenosimo jedni drugima. Tako se zove projekt .
Stalni tok promjena koji zapljuskuje naše sustave, stalno ih destabilizirajući, kontinuirani je tok softverskih artefakata. Kako bismo održali ovaj stalni tijek promjena, trebamo neku vrstu zajedničkog protokola kroz koji možemo razgovarati o tome što je softverski artefakt, kako se testira, kakvu je provjeru prošao. Tako se zove projekt . To jest, uobičajeni protokol metapodataka za softverske artefakte.
I konačno, ako želimo da naši sustavi budu potpuno neovisni, prilagodljivi i samoorganizirani, moramo im dati pravo na samoidentifikaciju. Projekt tzv To je upravo ono što on radi. Ovo je također projekt pod pokroviteljstvom Cloud Native Computing Foundation.
Svi su ti projekti mladi, svi trebaju našu ljubav, našu potvrdu. Ovo je sve otvorenog koda, naše testiranje, naša implementacija. Oni nam pokazuju kamo tehnologija ide.
Ali DevOps se nikada nije primarno bavio tehnologijom, uvijek se odnosio na suradnju među ljudima. I, sukladno tome, ako želimo da se sustavi koje razvijamo promijene, onda se i mi sami moramo promijeniti. Zapravo, ionako se mijenjamo; nemamo puno izbora.
Postoji prekrasan Britanska spisateljica Rachel Botsman, u kojoj piše o evoluciji povjerenja kroz ljudsku povijest. Ona kaže da je u početku, u primitivnim društvima, povjerenje bilo lokalno, odnosno da smo vjerovali samo onima koje osobno poznajemo.
Zatim je bilo jedno jako dugo razdoblje – mračno vrijeme kada je povjerenje bilo centralizirano, kada smo počeli vjerovati ljudima koje ne poznajemo na temelju činjenice da pripadamo istoj javnoj ili državnoj instituciji.
I to je ono što vidimo u našem modernom svijetu: povjerenje postaje sve više distribuirano i decentralizirano, a temelji se na slobodi protoka informacija, na dostupnosti informacija.
Ako razmislite o tome, upravo ta pristupačnost, koja čini ovo povjerenje mogućim, je ono što vi i ja implementiramo. To znači da se i način na koji surađujemo i način na koji to radimo moraju promijeniti, jer stare centralizirane, hijerarhijske IT organizacije više ne funkcioniraju. Počinju odumirati.
DevOps organizacijske osnove
Idealna DevOps organizacija budućnosti je decentralizirani, prilagodljivi sustav sastavljen od autonomnih timova, od kojih se svaki sastoji od autonomnih pojedinaca. Ti su timovi raštrkani po cijelom svijetu, učinkovito surađuju jedni s drugima koristeći asinkronu komunikaciju, koristeći vrlo transparentne komunikacijske protokole. Vrlo lijepo, zar ne? Vrlo lijepa budućnost.
Naravno, ništa od ovoga nije moguće bez kulturne promjene. Moramo imati transformacijsko vodstvo, osobnu odgovornost, unutarnju motivaciju.
Ovo je osnova DevOps organizacija: transparentnost informacija, asinkrone komunikacije, transformacijsko vodstvo, decentralizacija.
Izgorjeti
Sustavi kojih smo dio i koje gradimo sve su kaotičniji, a nama ljudima je teško nositi se s tom mišlju, teško se odreći iluzije kontrole. Pokušavamo ih i dalje kontrolirati, a to često dovodi do izgaranja. To govorim iz vlastitog iskustva, opekao sam se i ja, onemogućili su me i nepredviđeni kvarovi u proizvodnji.
Sagorijevanje se javlja kada pokušavamo kontrolirati nešto što je samo po sebi nekontrolirano. Kad pregorimo, sve gubi smisao jer gubimo želju za nečim novim, postajemo defanzivni i počinjemo braniti ono što imamo.
Inženjersko zanimanje, kako se često volim podsjetiti, prije svega je kreativno zanimanje. Ako izgubimo želju da nešto stvaramo, onda se pretvaramo u pepeo, pretvaramo u pepeo. Ljudi izgaraju, cijele organizacije izgaraju.
Po mom mišljenju, samo prihvaćanje kreativne snage kaosa, samo izgradnja suradnje po njegovim principima je ono što će nam pomoći da ne izgubimo ono što je dobro u našoj struci.
To je ono što vam želim: da volite svoj posao, da volite ono što radimo. Ovaj svijet se hrani informacijama, nama je čast hraniti ih. Zato proučavajmo kaos, budimo kaoolozi, donosimo vrijednost, stvarajmo nešto novo, pa problemi su, kako smo već saznali, neizbježni, a kada se pojave, jednostavno ćemo reći “Ops!” I problem je riješen.
Što osim Chaos Monkey?
Zapravo, svi su ti instrumenti tako mladi. Isti je Netflix napravio alate za sebe. Izradite vlastite alate. Pročitajte načela inženjeringa kaosa i živite u skladu s tim načelima umjesto da pokušavate pronaći druge alate koje je netko drugi već napravio.
Pokušajte razumjeti kako se vaši sustavi kvare i počnite ih razgrađivati i vidite kako se drže. Ovo je prvo. I možete tražiti alate. Ima svakakvih projekata.
Nisam baš razumio trenutak kada ste rekli da se sustav ne može pojednostaviti pojednostavljivanjem njegovih komponenti i odmah prešli na mikroservise koji pojednostavljuju sustav pojednostavljivanjem samih komponenti i kompliciranjem interakcija. To su u biti dva dijela koja su u suprotnosti.
Tako je, mikroservisi su općenito vrlo kontroverzna tema. Zapravo, pojednostavljivanje dijelova povećava fleksibilnost. Što pružaju mikrousluge? Daju nam fleksibilnost i brzinu, ali nam sigurno ne daju jednostavnost. Oni povećavaju poteškoće.
Dakle, u DevOps filozofiji, mikroservisi nisu tako dobra stvar?
Svako dobro ima naličje. Prednost je u tome što povećava fleksibilnost, omogućujući nam da brže unosimo promjene, ali povećava složenost, a time i krhkost cijelog sustava.
Ipak, na čemu je veći naglasak: na pojednostavljenju interakcije ili na pojednostavljenju dijelova?
Naglasak je, naravno, na pojednostavljenju interakcija, jer ako ovo gledamo sa stajališta našeg rada s vama, onda prije svega moramo obratiti pažnju na pojednostavljenje interakcija, a ne na pojednostavljenje rada svakog od nas posebno. Jer pojednostaviti rad znači pretvoriti se u robote. Kod nas u McDonald'su to radi normalno kad imate upute: ovdje stavite burger, ovdje ga prelijete umakom. To u našem kreativnom radu nikako ne funkcionira.
Je li istina da sve što ste rekli živi u svijetu bez konkurencije, a kaos je tamo tako ljubazan, iu tom kaosu nema proturječja, nitko nikoga ne želi jesti ili ubiti? Kako bi se trebala ponašati konkurencija i DevOps?
Pa ovisi o kakvoj konkurenciji je riječ. Radi li se o konkurenciji na radnom mjestu ili konkurenciji između tvrtki?
O konkurenciji usluga koja postoji jer usluge nisu nekoliko tvrtki. Stvaramo novi tip informacijskog okruženja, a bilo koje okruženje ne može živjeti bez konkurencije. Konkurencija je posvuda.
Isti Netflix, njih uzimamo za uzor. Zašto su ovo smislili? Jer su trebali biti konkurentni. Upravo je ta fleksibilnost i brzina kretanja vrlo natjecateljski zahtjev; ona unosi kaos u naše sustave. Odnosno, kaos nije nešto što svjesno radimo jer to želimo, to je nešto što se događa jer svijet to zahtijeva. Samo se moramo prilagoditi. A kaos, to je upravo rezultat natjecanja.
Znači li to da je kaos nedostatak ciljeva? Ili oni golovi koje ne želimo vidjeti? U kući smo i ne razumijemo ciljeve drugih. Konkurencija je, naime, posljedica toga što imamo jasne ciljeve i znamo gdje ćemo stići u svakom sljedećem trenutku. To je, s moje točke gledišta, bit DevOps-a.
Također pogledajte pitanje. Mislim da svi imamo isti cilj: preživjeti i to učiniti
najveće zadovoljstvo. A natjecateljski cilj svake organizacije je isti. Opstanak se često događa kroz natjecanje, tu se ne može ništa učiniti.
Ovogodišnja konferencija održat će se 7. prosinca u Technopolisu. Prijave za izvješća primamo do 11. studenog. nas ako želite govoriti.
Registracija za sudionike je otvorena, ulaznice koštaju 7000 rubalja. Pridruži nam se!
Izvor: www.habr.com