Anton Weiss, osnivač i direktor Otomato Software-a, jednog od inicijatora i instruktora prve DevOps certifikacije u Izraelu, govorio je na prošlogodišnjem o teoriji haosa i glavnim principima haos inženjeringa, a takođe je objasnio kako funkcioniše idealna DevOps organizacija budućnosti.
Pripremili smo tekstualnu verziju izvještaja.
Dobro jutro
DevOpsDays u Moskvi drugu godinu zaredom, ovo mi je drugi put na ovoj bini, mnogi od vas su u ovoj prostoriji po drugi put. Šta to znači? To znači da DevOps pokret u Rusiji raste, množi se, i što je najvažnije, to znači da je došlo vrijeme da se priča o tome šta je DevOps u 2018.
Dignite ruke koji misle da je DevOps već profesija u 2018. godini? Ima takvih. Ima li DevOps inženjera u prostoriji čiji opis posla kaže „DevOps inženjer“? Ima li DevOps menadžera u prostoriji? Ne postoji takav. DevOps arhitekte? Također ne. Nije dovoljno. Da li je zaista tačno da niko ne kaže da je DevOps inženjer?
Dakle, većina vas misli da je ovo anti-obrazac? Da takva profesija ne bi trebalo da postoji? Možemo misliti šta god želimo, ali dok razmišljamo, industrija se svečano kreće naprijed uz zvuk DevOps trube.
Ko je čuo za novu temu pod nazivom DevDevOps? Ovo je nova tehnika koja omogućava efikasnu saradnju između programera i devopsa. I nije tako novo. Sudeći po Twitteru, o tome su već počeli da pričaju pre 4 godine. I do sada interesovanje za to raste i raste, odnosno postoji problem. Problem treba riješiti.
Mi smo kreativni ljudi, ne opuštamo se samo mirni. Kažemo: DevOps nije dovoljno sveobuhvatna riječ; još uvijek mu nedostaju svakakvi različiti, zanimljivi elementi. I idemo u naše tajne laboratorije i počinjemo proizvoditi zanimljive mutacije: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Logika je gvozdena, zar ne? Naš sistem isporuke nije funkcionalan, naši sistemi su nestabilni i naši korisnici su nezadovoljni, nemamo vremena da uvedemo softver na vrijeme, ne uklapamo se u budžet. Kako ćemo sve ovo riješiti? Smislićemo novu reč! Završiće se sa "Ops" i problem je rešen.
Zato ja zovem ovaj pristup - "Ups, i problem je riješen."
Sve ovo odlazi u drugi plan ako se podsjetimo zašto smo sve ovo smislili. Smislili smo cijelu ovu DevOps stvar kako bismo isporuku softvera i vlastiti rad u ovom procesu učinili što nesmetanim, bezbolnijim, efikasnijim i što je najvažnije, ugodnijim.
DevOps je izrastao iz bola. I umorni smo od patnje. A da bi se sve ovo dogodilo, oslanjamo se na evergreen prakse: efikasnu saradnju, prakse protoka, i što je najvažnije, sistemsko razmišljanje, jer bez toga nijedan DevOps ne funkcioniše.
Šta je sistem?
A ako već govorimo o sistemskom razmišljanju, podsjetimo se šta je sistem.
Ako ste revolucionarni haker, onda je za vas sistem očigledno zao. To je oblak koji se nadvija nad vama i tjera vas da radite stvari koje ne želite.
Sa stanovišta sistemskog mišljenja, sistem je cjelina koja se sastoji od dijelova. U tom smislu, svako od nas je sistem. Organizacije u kojima radimo su sistemi. A ono što ti i ja gradimo zove se sistem.
Sve je to dio jednog velikog društveno-tehnološkog sistema. I samo ako shvatimo kako ovaj društveno-tehnološki sistem funkcioniše zajedno, tek tada ćemo moći zaista da optimizujemo nešto po ovom pitanju.
Iz perspektive sistemskog razmišljanja, sistem ima razna zanimljiva svojstva. Prvo, sastoji se od delova, što znači da njegovo ponašanje zavisi od ponašanja delova. Štaviše, svi njegovi dijelovi su također međusobno zavisni. Ispostavilo se da što više dijelova sistem ima, to je teže razumjeti ili predvidjeti njegovo ponašanje.
Sa bihevioralne tačke gledišta, postoji još jedna zanimljiva činjenica. Sistem može učiniti nešto što nijedan njegov pojedinačni dio ne može učiniti.
Kao što je dr. Russell Ackoff (jedan od osnivača sistemskog razmišljanja) rekao, ovo je prilično lako dokazati misaonim eksperimentom. Na primjer, ko u prostoriji zna pisati kod? Ima puno ruku i to je normalno, jer je to jedan od osnovnih uslova za našu profesiju. Znate li pisati, ali mogu li vaše ruke pisati kod odvojeno od vas? Ima ljudi koji će reći: "Ne pišu moje ruke, moj mozak piše kod." Može li vaš mozak pisati kod odvojeno od vas? Pa, vjerovatno ne.
Mozak je nevjerovatna mašina, ne znamo ni 10% kako tu funkcionira, ali ne može funkcionirati odvojeno od sistema koji je naše tijelo. A ovo je lako dokazati: otvori lobanju, izvadi mozak, stavi ga pred kompjuter, pusti ga da napiše nešto jednostavno. "Halo, world" u Pythonu, na primjer.
Ako sistem može učiniti nešto što nijedan njegov dio ne može učiniti zasebno, to znači da njegovo ponašanje nije određeno ponašanjem njegovih dijelova. Čime se onda određuje? Određuje se interakcijom između ovih dijelova. I shodno tome, što je više dijelova, što su interakcije složenije, to je teže razumjeti i predvidjeti ponašanje sistema. I to takav sistem čini haotičnim, jer svaka, čak i najbeznačajnija, nevidljiva promjena u bilo kojem dijelu sistema 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 „efekat leptira“ i dovelo je do razvoja pokreta naučne misli pod nazivom „teorija haosa“. Ova teorija je postala jedna od glavnih promena paradigme u nauci 20. veka.
Teorija haosa
Ljudi koji proučavaju haos sebe nazivaju haoolozima.
Zapravo, razlog za ovaj izvještaj je bio taj što sam, radeći sa složenim distribuiranim sistemima i velikim međunarodnim organizacijama, u jednom trenutku shvatio da se tako osjećam. Ja sam haosolog. Ovo je u osnovi pametan način da se kaže: "Ne razumijem šta se ovdje dešava i ne znam šta da radim u vezi s tim."
Mislim da se i mnogi od vas često tako osjećaju, pa ste i vi haoolozi. Pozivam vas u ceh haozologa. Sistemi koje ćemo vi i ja, dragi kolege haosolozi, proučavati zovu se „složeni adaptivni sistemi“.
Šta je prilagodljivost? Prilagodljivost znači da se individualno i kolektivno ponašanje dijelova u takvom adaptivnom sistemu mijenja i samoorganizira, reagirajući na događaje ili lance mikro-događaja u sistemu. Odnosno, sistem se prilagođava promjenama kroz samoorganizaciju. A ta sposobnost samoorganiziranja zasniva se na dobrovoljnoj, potpuno decentraliziranoj saradnji slobodnih autonomnih agenata.
Još jedno zanimljivo svojstvo takvih sistema je da su slobodno skalabilni. Ono što bi nas, kao haosologe-inženjere, nesumnjivo trebalo da zanima. Dakle, ako bismo rekli da je ponašanje složenog sistema određeno interakcijom njegovih dijelova, šta bi nas onda zanimalo? Interakcija.
Postoje još dva zanimljiva nalaza.
Prvo, razumijemo da se složeni sistem ne može pojednostaviti pojednostavljivanjem njegovih dijelova. Drugo, jedini način da se pojednostavi složen sistem je pojednostavljivanje interakcija između njegovih dijelova.
Kako komuniciramo? Vi i ja smo svi dijelovi velikog informacionog sistema zvanog ljudsko društvo. Mi komuniciramo putem zajedničkog jezika, ako ga imamo, ako ga nađemo.
Ali sam jezik je složen sistem prilagođavanja. U skladu s tim, da bismo djelovali efikasnije i jednostavnije, moramo kreirati neku vrstu protokola. Odnosno, neki niz simbola i radnji koji će razmjenu informacija među nama učiniti jednostavnijom, predvidljivijom, razumljivijom.
Želim da kažem da se u svemu mogu pratiti trendovi ka složenosti, prema prilagodljivosti, ka decentralizaciji, ka haosu. I u sistemima koje ti i ja gradimo, iu onim sistemima čiji smo dio.
I da ne budemo neosnovani, pogledajmo kako se mijenjaju sistemi koje stvaramo.
Čekao si ovu reč, razumem. Nalazimo se na DevOps konferenciji, danas će se ova riječ čuti oko sto hiljada puta, a onda ćemo je sanjati noću.
Mikroservise su prva softverska arhitektura koja se pojavila kao reakcija na DevOps prakse, a koja je dizajnirana da naše sisteme učini fleksibilnijim, skalabilnijim i osigura kontinuiranu isporuku. Kako ona to radi? Smanjenjem obima usluga, smanjenjem obima problema koje ove usluge obrađuju, smanjenjem vremena isporuke. Odnosno, smanjujemo i pojednostavljujemo dijelove sistema, povećavamo njihov broj, pa se shodno tome stalno povećava složenost interakcija između ovih dijelova, odnosno nastaju novi problemi koje moramo rješavati.
Mikroservisima nije kraj, mikroservise su, generalno, već juče, jer dolazi bez servera. Svi serveri su izgorjeli, nema servera, nema operativnih sistema, samo čisti izvršni kod. Konfiguracije su odvojene, stanja su odvojena, sve je pod kontrolom događaja. Lepota, čistoća, tišina, nema dešavanja, ništa se ne dešava, potpuni red.
Gdje je složenost? Teš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 ponovo kreirati neki događaj kada je došlo do kvara? Mnogo pitanja a malo odgovora.
Mikrousluge i bez servera su ono što mi štreberski hipsteri nazivamo Cloud Native. Sve je u oblaku. Ali oblak je također inherentno ograničen u svojoj skalabilnosti. Navikli smo da o njemu razmišljamo kao o distribuiranom sistemu. Zapravo, gdje žive serveri cloud provajdera? U data centrima. To jest, 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 narednih pet do deset godina čekaju milijarde uređaja povezanih na internet. Ogromna količina korisnih i beskorisnih podataka koji će biti spojeni u oblak i postavljeni iz oblaka.
Oblak neće trajati, tako da sve više govorimo o nečemu što se zove rubno računanje. Ili mi se također sviđa divna definicija “računanja magle”. Omotano je misticizmom romantizma i misterije.
Računanje magle. Poenta je da su oblaci centralizovane nakupine vode, pare, leda i kamenja. A magla su kapljice vode koje su rasute oko nas u atmosferi.
U paradigmi magle, većinu posla obavljaju ove kapljice potpuno autonomno ili u suradnji s drugim kapljicama. I okreću se oblaku tek kada su stvarno pritisnuti.
Odnosno, opet decentralizacija, autonomija i, naravno, mnogi od vas već shvaćaju kuda sve to vodi, jer ne možete govoriti o decentralizaciji bez spominjanja blockchaina.
Ima onih koji vjeruju, to su oni koji su investirali u kriptovalute. Ima onih koji vjeruju, ali se boje, kao ja, na primjer. A ima i onih koji ne veruju. Ovdje možete tretirati drugačije. Postoji tehnologija, nova nepoznata stvar, postoje problemi. Kao i svaka nova tehnologija, postavlja više pitanja nego što daje odgovore.
Hiper oko blockchaina je razumljiv. Ako ostavimo na stranu zlatnu groznicu, sama tehnologija ima izvanredna obećanja za svjetliju budućnost: više slobode, više autonomije, distribuirano globalno povjerenje. Šta ne želite?
Shodno tome, sve više inženjera širom 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 da kažu: "Ne postoje prave aplikacije za blockchain." Ako razmislite o tome, prije 150 godina rekli su isto o struji. I čak su na neki način bili u pravu, jer ono što danas omogućava električna energija nije bilo moguće u 19. vijeku.
Usput, ko zna kakav je logo na ekranu? Ovo je Hyperledger. Ovo je projekat koji se razvija pod pokroviteljstvom The Linux Foundation i uključuje skup blockchain tehnologija. Ovo je zaista snaga naše zajednice otvorenog koda.
Chaos Engineering
Dakle, sistem koji razvijamo postaje sve složeniji, sve haotičniji i sve prilagodljiviji. Netflix je pionir mikroservisnih sistema. Oni su među prvima to shvatili, razvili su skup alata koje su nazvali Simian Army, od kojih je najpoznatiji bio . Definisao je ono što je postalo poznato kao .
Inače, u procesu rada na izvještaju, čak smo i preveli ovaj tekst na ruski, pa idite na , čitaj, komentiraj, grdi.
Ukratko, principi inženjeringa haosa kažu sljedeće. Složeni distribuirani sistemi su inherentno nepredvidivi i inherentno greši. Greške su neizbježne, što znači da moramo prihvatiti te greške i raditi sa ovim sistemima na potpuno drugačiji način.
Mi sami moramo pokušati da uvedemo ove greške u naše proizvodne sisteme kako bismo testirali naše sisteme na tu istu prilagodljivost, upravo tu sposobnost samoorganizacije, za opstanak.
I to sve mijenja. Ne samo kako pokrećemo sisteme u proizvodnju, već i kako ih razvijamo, kako ih testiramo. Ne postoji proces stabilizacije ili zamrzavanja koda, naprotiv, postoji stalan proces destabilizacije. Pokušavamo da ubijemo sistem i vidimo da on nastavi da preživi.
Protokoli za integraciju distribuiranog sistema
U skladu s tim, ovo zahtijeva da se naši sistemi nekako promijene. Da bi postali stabilniji, potrebni su im neki novi protokoli za interakciju između njihovih dijelova. Pa da se ovi dijelovi dogovore i dođu do neke vrste samoorganizacije. I pojavljuju se sve vrste novih alata, novih protokola, koje ja nazivam „protokoli za interakciju distribuiranih sistema“.
o cemu pricam? Prvo, projekat . Neki pokušavaju stvoriti opći distribuirani protokol za praćenje, koji je apsolutno nezamjenjiv alat za otklanjanje grešaka u složenim distribuiranim sistemima.
Dalje - . Kažemo da ne možemo da predvidimo šta će se desiti sa sistemom, odnosno da moramo povećati njegovu uočljivost, uočljivost. Opentracing pripada porodici alata koji daju vidljivost našim sistemima. Ali potrebna nam je opservabilnost da bismo utvrdili da li se sistem ponaša onako kako očekujemo ili ne. Kako definišemo očekivano ponašanje? Definiranjem neke vrste politike, nekog skupa pravila. Projekat Open Policy Agent radi na definisanju ovog skupa pravila kroz spektar u rasponu od pristupa do alokacije resursa.
Kao što smo rekli, naši sistemi su sve više vođeni događajima. Serverless je odličan primjer sistema vođenih događajima. Da bismo prenosili događaje između sistema i pratili ih, potreban nam je neki zajednički jezik, neki zajednički protokol kako pričamo o događajima, kako ih prenosimo jedni drugima. Tako se zove projekat .
Stalni tok promjena koji zapljuskuje naše sisteme, neprestano ih destabilizirajući, neprekidan je tok softverskih artefakata. Da bismo održali ovaj stalni tok promjena, potreban nam je nekakav zajednički protokol kroz koji možemo razgovarati o tome šta je softverski artefakt, kako se testira, koju verifikaciju je prošao. Tako se zove projekat . To jest, uobičajeni protokol metapodataka za softverske artefakte.
I konačno, ako želimo da naši sistemi budu potpuno nezavisni, prilagodljivi i samoorganizirani, moramo im dati pravo na samoidentifikaciju. Projekat je pozvan To je upravo ono što on radi. Ovo je također projekat pod pokroviteljstvom Cloud Native Computing Foundation.
Svi ovi projekti su mladi, svi trebaju našu ljubav, našu potvrdu. Ovo je sve otvorenog koda, naše testiranje, naša implementacija. Oni nam pokazuju kuda tehnologija ide.
Ali DevOps se nikada nije prvenstveno bavio tehnologijom, oduvijek je bio saradnja među ljudima. I, shodno tome, ako želimo da se sistemi koje razvijamo mijenjaju, onda se i mi sami moramo promijeniti. U stvari, ionako se mijenjamo; nemamo mnogo izbora.
Postoji divan Britanska spisateljica Rachel Botsman, u kojoj piše o evoluciji povjerenja kroz ljudsku historiju. Ona kaže da je u početku, u primitivnim društvima, povjerenje bilo lokalno, odnosno vjerovali smo samo onima koje smo lično poznavali.
Zatim je bio jedan veoma dug period – mračno vrijeme kada je povjerenje bilo centralizirano, kada smo počeli vjerovati ljudima koje ne poznajemo na osnovu činjenice da pripadamo istoj javnoj ili državnoj instituciji.
A to je ono što vidimo u našem modernom svijetu: povjerenje postaje sve više distribuirano i decentralizirano, a zasniva se na slobodi protoka informacija, na dostupnosti informacija.
Ako razmislite o tome, upravo ova 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 sarađujemo i način na koji to radimo moraju promijeniti, jer stare centralizirane, hijerarhijske IT organizacije više ne rade. Počinju da umiru.
Osnove organizacije DevOps
Idealna DevOps organizacija budućnosti je decentralizovan, prilagodljiv sistem sastavljen od autonomnih timova, od kojih se svaki sastoji od autonomnih pojedinaca. Ovi timovi su raštrkani širom svijeta, efikasno sarađujući jedni s drugima koristeći asinhronu komunikaciju, koristeći visoko transparentne komunikacijske protokole. Veoma lepo, zar ne? Veoma lepa budućnost.
Naravno, ništa od ovoga nije moguće bez kulturoloških promjena. Moramo imati transformacijsko vodstvo, ličnu odgovornost, unutrašnju motivaciju.
To je osnova DevOps organizacija: transparentnost informacija, asinhrone komunikacije, transformacijsko vodstvo, decentralizacija.
Izgaranje
Sistemi čiji smo dio i oni koje gradimo sve su haotičniji, a nama ljudima je teško nositi se s tom mišlju, teško je odustati od iluzije kontrole. Trudimo se da ih i dalje kontrolišemo, a to često dovodi do sagorevanja. Ovo govorim iz vlastitog iskustva, i ja sam se opekao, također sam bio onemogućen nepredviđenim propustima u proizvodnji.
Izgaranje se javlja kada pokušavamo kontrolisati nešto što je inherentno nekontrolirano. Kada izgorimo, sve gubi smisao jer gubimo želju da radimo nešto novo, postajemo defanzivni i počinjemo braniti ono što imamo.
Inženjerska profesija je, kako se često volim podsjetiti, prije svega kreativna profesija. Ako izgubimo želju da nešto stvorimo, onda se pretvaramo u pepeo, pretvaramo se u pepeo. Ljudi izgaraju, cijele organizacije izgaraju.
Po mom mišljenju, samo prihvatanje kreativne snage haosa, samo izgradnja saradnje po njegovim principima je ono što će nam pomoći da ne izgubimo ono što je dobro u našoj profesiji.
Ovo vam želim: da volite svoj posao, da volite ono što radimo. Ovaj svijet se hrani informacijama, mi imamo čast da ih hranimo. Pa hajde da proučavamo haos, budimo haoolozi, donosimo vrednost, stvaramo nešto novo, pa problemi su, kao što smo već saznali, neizbežni, a kada se pojave, jednostavno ćemo reći „Ops!“ I problem je rešen.
Šta drugo nego haos majmun?
Zapravo, svi ovi instrumenti su tako mladi. Isti Netflix je napravio alate za sebe. Izgradite vlastite alate. Pročitajte principe inženjeringa haosa i živite u skladu s tim principima umjesto da pokušavate pronaći druge alate koje je neko drugi već napravio.
Pokušajte razumjeti kako se vaši sistemi kvare i počnite ih razbijati i vidjeti kako se oni drže. Ovo je prvo. I možete potražiti alate. Postoje razni projekti.
Nisam baš shvatio trenutak kada ste rekli da se sistem ne može pojednostaviti pojednostavljivanjem njegovih komponenti i odmah prešli na mikroservise, koji pojednostavljuju sistem pojednostavljivanjem samih komponenti i komplikovanjem interakcija. To su u suštini dva dijela koja su u suprotnosti jedan s drugim.
Tako je, mikroservise su generalno vrlo kontroverzna tema. U stvari, pojednostavljivanje dijelova povećava fleksibilnost. Šta mikroservise pružaju? Daju nam fleksibilnost i brzinu, ali nam sigurno ne daju jednostavnost. Oni povećavaju težinu.
Dakle, u filozofiji DevOpsa, mikroservis nije tako dobra stvar?
Svako dobro ima i obrnutu stranu. Prednost je u tome što povećava fleksibilnost, omogućavajući nam da brže vršimo promjene, ali povećava složenost i stoga krhkost cijelog sistema.
Ipak, na čemu je veći naglasak: na pojednostavljenju interakcije ili na pojednostavljivanju dijelova?
Naglasak je, naravno, na pojednostavljenju interakcija, jer ako ovo posmatramo sa stanovišta načina na koji radimo s vama, onda, prije svega, trebamo obratiti pažnju na pojednostavljivanje interakcija, a ne na pojednostavljivanje rada svakog od nas posebno. Jer pojednostavljivanje rada znači pretvaranje u robote. Ovdje u McDonald'su radi normalno kada imate uputstva: ovdje stavljate pljeskavicu, ovdje sipate sos. Ovo uopšte ne funkcioniše u našem kreativnom radu.
Da li je tačno da sve što ste rekli živi u svetu bez konkurencije, a haos je tako ljubazan, i da u ovom haosu nema kontradiktornosti, niko nikoga ne želi da jede ili ubije? Kako bi trebalo da prođu konkurencija i DevOps?
Pa zavisi o kakvoj konkurenciji je reč. Da li je riječ o konkurenciji na radnom mjestu ili konkurenciji između kompanija?
O konkurenciji usluga koje postoje jer usluge nisu više kompanija. Stvaramo novu vrstu informatičkog okruženja i nijedno okruženje ne može živjeti bez konkurencije. Konkurencija je svuda.
Isti Netflix, uzimamo ih kao uzor. Zašto su smislili ovo? Zato što su morali biti konkurentni. Ova fleksibilnost i brzina kretanja je upravo vrlo konkurentni zahtjev; ona unosi haos u naše sisteme. Odnosno, haos nije nešto što svjesno radimo zato što to želimo, to je nešto što se dešava jer svijet to zahtijeva. Samo se moramo prilagoditi. A haos, to je upravo rezultat konkurencije.
Da li to znači da je haos odsustvo ciljeva, takoreći? Ili oni ciljevi koje ne želimo da vidimo? Mi smo u kući i ne razumijemo ciljeve drugih. Konkurencija je, naime, zbog činjenice da imamo jasne ciljeve i da znamo gdje ćemo završiti u svakom narednom trenutku. Ovo je, sa moje tačke gledišta, suština DevOps-a.
Također pogledajte pitanje. Mislim da svi imamo isti cilj: da preživimo i uradimo to
najveće zadovoljstvo. A konkurentski cilj svake organizacije je isti. Opstanak se često dešava kroz takmičenje, tu ne možete ništa učiniti.
Ovogodišnja konferencija održat će se 7. decembra u Technopolisu. Prijave za izvještaje primamo do 11. novembra. nas ako želite da govorite.
Registracija učesnika je otvorena, ulaznice koštaju 7000 rubalja. Pridruži nam se!
izvor: www.habr.com