Opredelitev DevOps je zelo zapletena, zato je treba vsakokrat znova sprožiti razpravo o tem. Na Habré je tisoč objav na to temo. Ampak, če to berete, potem zagotovo veste, kaj je DevOps. Ker jaz ne. Živjo, moje ime je Aleksander Titov (@), in samo pogovorili se bomo o DevOpsu in delil bom svoje izkušnje.
Dolg časa sem razmišljal, kako narediti svoj govor koristen, zato bo tukaj veliko vprašanj - tistih, ki si jih postavljam sam, in tistih, ki jih postavljam strankam naše podjetja. Z odgovarjanjem na ta vprašanja postane razumevanje boljše. Povedal bom, zakaj je DevOps potreben z mojega stališča, kaj to sploh je, znova z moje pozicije, in kako razumeti, ali se premikate proti DevOpsu, spet z mojega stališča. Zadnja točka bo skozi vprašanja. Z odgovarjanjem nanje sam sebi boste lahko ugotovili, ali vaša podjetja napredujejo proti DevOpsu ali se srečujejo s težavami.
Nekaj časa sem se gibal po valovih združitev in prevzemov. Najprej sem delal v majhnem start-upu Qik, nato ga je kupila nekoliko večja podjetja Skype, ki ga je nato kupila še nekoliko večja podjetja Microsoft. V tem trenutku sem dobil vpogled v to, kako se predstava o DevOpsu preoblikuje v različnih podjetjih z različno velikostjo. Po tem me je zanimalo gledati na DevOps z vidika trga, zato smo s sodelavci ustanovili podjetje Ekspress 42. Že 6 let se na njem premikamo po valovih trga.
Poleg vsega sem eden od organizatorjev skupnosti DevOps Moscow in organizator DevOps -Days 2017, toda leta 2018 nisem organiziral. Ekspress 42 dela z mnogimi podjetji. Spodbujamo tam DevOps, opazujemo, kako to poteka, potegnemo zaključke, analiziramo, povemo svoje ugotovitve vsem, učimo ljudi DevOps praks. Na kratko, na vse možne načine krepimo izkušnje in strokovno znanje na tem področju.
Zakaj DevOps
Prvo vprašanje, ki mučijo vse in vedno - zakaj? Mnogi menijo, da je DevOps preprosto avtomatizacija ali kaj podobnega, kar je že bilo v vsakem podjetju.
- Imeli smo Continuous Integration - to pomeni, da je DevOps že bil prisoten, in zakaj potrebujejo vse te neumnosti? Tam na Zahodu se zabavajo, nam pa delajo ovire pri delu!
Za 9 let razvoja skupnosti in metodologije je že postalo jasno, da to niso le marketinške bleščečnosti, a vendarle še vedno ni povsem jasno, zakaj je to potrebno. Kot pri vsakem orodju in procesu, ima DevOps konkretne cilje, ki jih na koncu doseže.
Vse to je povezano s tem, da se svet spreminja. Odvija se od pristopa enterprise, kjer podjetja gredo takoj proti sanjam, kot je pela našega svetnika iz Sankt Peterburga, iz točke A v točko B po določeni strategiji, zgrajeni za to posebni strukturi.
Načeloma bi moralo biti v IT vse zgrajeno pod tem pristopom. Tukaj se IT uporablja izključno za avtomatizacijo procesov.
Avtomatizacija se ne spreminja pogosto, ker ko podjetje teče po ustaljeni poti - kaj tu spremeniti? Dela - ne dotikaj se. Zdaj se svetovi pristopi spreminjajo, in tisti, ki se imenuje Agile, pravi, da končne točke B takoj ne vidi.
Ko podjetje hodi po trgu, dela s stranko - nenehno raziskuje trg in spreminja končno točko B. Pri čemer, bolj pogosto kot podjetje spremeni svojo smer, večja je na koncu uspešnost, ker izbere več tržnih niš.
Strategijo prikazuje zanimivo podjetje, o katerem sem se nedavno naučil. One Box Shave - storitev dostave britv in britvenih pripomočkov na naročnino v škatli. Umejo prilagoditi svojo 'škatlo' različnim strankam. S tem se ukvarja določen program, ki nato pošlje naročilo na korejsko tovarno, ki proizvaja izdelek.
Ta izdelek je kupila družba Unilever za 1 milijardo dolarjev. Zdaj se konkurenčno bori z Gillette in mu je odvzela pomemben delež potrošnikov na ameriškem trgu. One Box Shave pravijo:
— 4 rezila? Resno? Zakaj to potrebujete - to nikakor ne izboljša kakovosti britja. Posebej izbrana krema, dišava in kakovostna britva z dvema reziloma rešujejo veliko več vprašanj kot ta neumna 4 rezila Gillette! Tako bomo kmalu pri desetih?
Tako se svet spreminja. Unilever trdi, da imajo odličen IT sistem, ki to omogoča. Na koncu to izgleda kot koncept Time-to-market, o katerem že ni govorila samo ena oseba.
Smisel 'Time-to-market' ni v tem, kako pogosto izvajamo uvedbe. Pogosto lahko uvedemo, vendar so lahko cikli izdaj dolgi. Če tri mesečne cikle izdaj zložimo drug na drugega in jih premikamo za teden, podjetje deluje, kot da se uvedba dogaja enkrat na teden. Od ideje do končne realizacije minejo 3 mesece.
'Time-to-market' se nanaša na minimizacijo časa od ideje do končne realizacije.
V tem primeru programska oprema sodeluje s trgom. Tako kot pri One Box Shave spletna stran komunicira s strankami. Nimajo prodajalcev — samo spletna stran, kjer obiskovalec klikne in pusti želje. Zato je na spletni strani treba stalno postavljati nekaj novega, ga posodabljati v skladu z željami. Na primer, v Južni Koreji se britje ne izvaja tako kot v Rusiji, in tam ljudje raje vonjajo po drugih vonjih, kot je, recimo, vanilija z korenčkom.
Ker je potrebno hitro spreminjati vsebino spletne strani, se razvoj programske opreme močno spreminja. Preko programske opreme moramo ugotoviti, kaj želi stranka. Pred tem smo to ugotavljali preko nekaterih posrednih poti, na primer, preko poslovnega menedžmenta. Nato smo projektirali in v IT-sistem vključili zahteve, kar je bilo super. Zdaj je vse drugače - programska oprema se projektira s strani vseh, ki so vključeni v proces, vključno z inženirji, ki preko tehničnih specifikacij ugotovijo, kako deluje trg, in svoje vpoglede delijo s poslovanjem.
Na primer, v podjetju Qik smo nenadoma ugotovili, da ljudem zelo ustreza nalagati kontaktne sezname na strežnik, in dodali so nam aplikacijo. Sprva tega nismo razmišljali. V klasičnem podjetju bi vsi rekli, da je to napaka, ker v specifikaciji ni zapisano, da mora delovati dobro, in bi dejansko to funkcionalnost izključili, ter rekli: 'To ni nikomur potrebno, najpomembnejše je, da osnovna funkcionalnost deluje.' Tehnološko podjetje pa v tem vidi priložnost in začne prilagajati programsko opremo temu.
Leta 1968 je predvidevalni fant Melvin Conway oblikoval naslednjo idejo.
Organizacija, ki ustvarja sistem, je omejena z oblikovanjem, ki kopira strukturo komunikacije v tej organizaciji.
Če želite podrobneje, morate za ustvarjanje sistemov druge vrste poleg tega imeti tudi komunikacijsko strukturo znotraj podjetja druge vrste. Če imate hierarhično komunikacijsko strukturo, vam to ne bo omogočilo ustvariti sistemov, ki lahko dosežejo zelo visoko stopnjo Time-to-market.
Preberi je možno . Pomembno je za razumevanje kulture ali filozofije DevOps, ker edina stvar, ki se v DevOps bistveno spreminja, je prav komunikacijska struktura med ekipami..
Z vidika procesa so do DevOps vse faze: analiza, razvoj, testiranje, delovanje potekale linearno.
V DevOps pa vse te procese potekajo hkrati.
Time-to-market se lahko tako doseže. Za ljudi, ki so delali v starem procesu, to izgleda nekoliko nepredstavljivo, in sploh ne.
Zakaj torej DevOps?
Za razvoj digitalnih izdelkov. Če v vaši družbi ni digitalnega izdelka, DevOps ni potreben – to je zelo pomembno.
DevOps premaguje hitrostne omejitve zaporednega postopka razvoja programske opreme.. V njem vsi procesi potekajo hkrati.
Povečuje se kompleksnost. Ko DevOps evangelisti govorijo, da bo z njim lažje izdati programsko opremo – to je neumnost.
S DevOps bo vse le še bolj zapleteno.
Na konferenci ste lahko na stojnici Avita videli, kaj pomeni razporediti Docker kontejner – nerealna naloga. Kompleksnost postaja nepredstavljiva, treba je žonglirati z več obroči hkrati.
DevOps popolnoma spreminja proces in organizacijo v podjetju – natančneje, ne menja DevOps, ampak digitalni izdelek. Da pridete do DevOps, morate ta proces popolnoma spremeniti.
Vprašanja za strokovnjaka
Kaj pa vi? Vprašanja, ki si jih lahko postavite, ko delate v podjetju in se razvijate kot strokovnjak.
Imate strategijo za ustvarjanje digitalnega izdelka? Če jo imate – že dobro. To pomeni, da vaše podjetje napreduje proti DevOps.
Ali vaše podjetje že ustvarja digitalni izdelek? To pomeni, da se lahko dvignete še na eno stopnjo višje, ukvarjate se z bolj zanimivimi zadevami – prav tako z vidika DevOps. O tem govorim samo z te perspektive.
Ali je vaše podjetje eden vodilnih na trgu v niši z digitalnim izdelkom? Spotify, Yandex, Uber — podjetja, ki so trenutno na vrhuncu tehnološkega napredka.
Postavite si ta vprašanja, in če so vsi odgovori negativni, morda res ni smiselno ukvarjati se z DevOps v tem podjetju. Če pa vas tema DevOps resnično zanima, morda,... bi se morali preseliti v drugo podjetje? Če vaše podjetje želi preiti na DevOps, a ste na vsa vprašanja odgovorili "Ne", potem spominja na lepega nosoroga, ki se nikoli ne bo spremenil.
Organizacija
Kot sem že povedal, po zakonu Conwaya se organizacija v podjetju spreminja. Začel bom s tistim, kar ovira DevOps, da pronica v notranjost podjetja, prav z vidika organizacije.
Težava "silosov"
Angleška beseda "Silo" je tukaj prevedena v slovenščino kot "kolodvor". Pomen te težave je v tem, da med ekipami ni izmenjave informacij.. Vsaka ekipa izkopava svojo ekspertizo globoko, pri tem pa ne gradi skupne karte, po kateri bi se lahko orientirali.
Nekako spominja na osebo, ki je ravnokar prispela v Moskvo in še ne zna brati zemljevida metroja. Moskviči običajno odlično poznajo svojo četrt, po celi Moskvi pa se orientirajo po zemljevidu metroja. Ko prvič prideš v Moskvo, ti ta veščina še manjka in si preprosto dezorientiran.
DevOps ponuja, da preidete čez ta trenutek dezorientacije in da skupaj z vsemi oddelki zgradite skupno karto interakcije.
To ovira dva dejavnika.
Posledica korporativnega sistema upravljanja. Ta sistem je zgrajen iz ločenih hierarhičnih "silosov". Na primer, obstajajo določeni KPI-ji v podjetjih, ki podpirajo ta sistem. Po drugi strani pa so ovira misli osebe, ki ji je težko prestopiti meje svoje ekspertize in se orientirati v celotnem sistemu. To preprosto ni udobno. Predstavljajte si, da ste prišli na letališče v Bangkoku — tam se hitro ne znajdete. V DevOpsu je tudi težko orientirati se, zato ljudje pravijo, da je treba najti vodnika, da se tja pride.
Ampak najpomembnejše je, da se težava "silosov" za inženirja, ki je sprejel duh DevOps, prebral Fowlerja in kup drugih knjig, izraža v tem, da "silosni" ne dovoljujejo izvajanja "očitnih" stvari.. Pogosto se zberemo po DevOps Moscow, se pogovarjamo med seboj in ljudje se pritožujejo:
— Želeli smo samo zagnati CI, a je prišlo do tega, da to vodstvu ni potrebno.
To se dogaja prav zaradi tega, CI in postopek nenehnega dostavljanja se nahajajo na meji mnogih ekspertiz. Preprosto ne morete napredovati, ne da bi premagali problem "vodnjakov" na organizacijski ravni, ne glede na to, kaj počnete in kako žalostno to je.
Vsak udeleženec procesa v podjetju: razvijalci backend-a in frontend-a, testiranje, DBA, obratovanje, mreža, koplje v svojo smer, skupne karte pa nima nihče, razen vodje, ki nekako nadzira in upravlja s metodo "deli in vladaj".
Ljudje se borijo za neke zvezde ali zastavice, vsak koplje svojo ekspertizo.
Na koncu, ko se pojavi naloga, da vse to združimo in zgradimo skupni pipeline, in za zvezde in zastavice ni več potrebe za boj, se pojavi vprašanje — kaj pa zdaj? Moramo se nekako dogovoriti, a kako to storiti, nas v šoli nihče ni učil. Še v šoli smo bili naučeni: osmi razred — oho! — v primerjavi s sedmim razredom! Tudi tu je enako.
Je tudi v vašem podjetju tako?
Da to preverite, si lahko postavite naslednja vprašanja.
Ali ekipe uporabljajo skupna orodja, prispevajo k spremembam teh skupnih orodij?
Kako pogosto se ekipe preoblikujejo — eni strokovnjaki iz ene ekipe prehajajo v drugo ekipo? Prav v DevOps okolju to postaja normalno, ker včasih oseba preprosto ne more razumeti, s čim se ukvarja druga področje ekspertize. Prehaja v drugi oddelek, tam dela dva tedna, da si ustvari orientacijsko karto in odnose s tem oddelkom.
Ali je mogoče ustanoviti odbor za spremembe in kaj spremeniti? Ali pa za to potrebujete močno roko najvišjega vodstva in ukaz? Nedavno sem napisal na Facebooku, kako ena malo znana banka uvaja orodja preko ukazov: napisali so ukaz, ga uvajamo eno leto, gledamo, kaj se dogaja. To je seveda dolgo in žalostno.
Kako pomembno je za menedžerje, da dobijo osebne dosežke ne glede na dosežke podjetja?
Če si na ta vprašanja odgovorite sami, bo jasneje, ali imate v podjetju takšno težavo.
Infrastruktura kot koda
Ko končanju teh težav je prva pomembna praksa, brez katere je težko napredovati v DevOps, infrastruktura kot koda.
Najpogosteje se infrastruktura kot koda razume kot:
— Poglejmo, da vse avtomatiziramo z bashom, se obložimo s skripti, da bo skrbnikom manj ročnega dela!
Toda to ni tako.
Infrastruktura kot koda pomeni, da IT-sistem, s katerim delate, opisujete v obliki kode, da nenehno razumete njeno stanje.
Skupaj z drugimi ekipami ustvarjate zemljevid v obliki kode, ki je vsem razumljiv in po katerem se lahko orientirate. Ni važno, na čem je to narejeno — Chef, Ansible, Salt ali se uporabljajo YAML-datoteke v Kubernetesu — to ni pomembno.
Na konferenci je kolega iz 2GIS-a pripovedoval, kako so naredili svoj notranji pripomoček za Kubernetes, ki opisuje strukturo posameznih sistemov. Da bi opisali 500 sistemov, so potrebovali poseben pripomoček, ki ta opis generira. Ko je ta opis na voljo, si vsak lahko izmenjuje informacije, spremlja spremembe, kako jih lahko spremeni in izboljša, česa manjka.
Se strinjate, da posamezni bash skripti običajno ne ponujajo tega razumevanja. V eni od podjetij, kjer sem delal, so celo imeli naziv „write only“ skript - ko je skript napisan, ga ne morete več prebrati. Mislim, da vam to tudi zveni znano.
Infrastruktura kot koda je koda, ki opisuje trenutno stanje infrastrukture. S to kodo skupaj delajo številne produktne, infrastrukturne in servisne ekipe, in kar je najpomembnejše, vse morajo razumeti, kako ta koda sploh deluje.
Koda se vzdržuje v skladu z najboljšimi praksami dela s kodo: skupno razvijanje, pregledovanje kode, XP-programiranje, testiranje, pull requesti, CI za infrastrukturo kode — to je vse dobro in uporabno.
Koda postane skupni jezik za vse inženirje.
Sprememba infrastrukture v kodi ne vzame veliko časa. Da, v infrastrukturni kodi je lahko tudi tehnični dolg. Običajno se ekipe s tem srečajo približno pol leta po tem, ko so začele implementirati „infrastrukturo kot kodo“ v obliki kupčka skriptov ali celo Ansible-a, ki ga pišejo kot testenine, in še bash skripti se vržejo v peč!
Pomembno: če še niste poskusili te reči, zapomnite si, da Ansible ni bash! Pozorno preberite dokumentacijo, preglejte, kaj o tem pravijo.
Infrastruktura kot koda - to je razdelitev infrastrukturne kode na ločene plasti.
V naši družbi izpostavljamo 3 osnovne plasti, ki so zelo jasne in preproste, a jih je lahko več. Lahko si ogledate svojo infrastrukturno kodo in si rečete, ali imate to stanje ali ne. Če se nobene plasti ne izločajo, je treba vzeti čas in malo refaktorizirati.
Osnovna plast — to je, kako se nastavi OS, varnostne kopije in druge nizkonivojske stvari, kot je na osnovnem nivoju razporeditev Kubernetes.
Plast storitev — to so storitve, ki jih nudite razvijalcu: beleženje kot storitev, nadzor kot storitev, podatkovna baza kot storitev, balansirnik kot storitev, vrstica kot storitev, neprekinjena dostava kot storitev - množica storitev, ki jih lahko ločene ekipe nudijo razvoju. Vse to je treba opisati z ločenimi moduli v vašem sistemu upravljanja konfiguracije.
Plast, kjer se izdelujejo aplikacije in opisuje, kako se bodo razvijale nad dvema prejšnjima plastema.
Kontrolna vprašanja
Ali imate v podjetju skupni infrastrukturni repozitorij? Ali spremljate tehnični dolg v infrastrukturi? Ali uporabljate prakse razvoja v infrastrukturnem repozitoriju? Ali je vaša infrastruktura razdeljena na plasti? Lahko se sklicujete na shemo Base-service-APP. Kako težko je uvesti spremembo?
Če ste se srečali s tem, da je vnos sprememb trajal dan in pol, to pomeni, da ste pridobili tehnični dolg in ga je treba razrešiti. Naleteli ste na pasti tehničnega dolga v infrastrukturni kodi. Spomnim se mnogih takšnih zgodb, ko je bilo potrebno, da se spremeni kakšen CCTL, prepisati polovico infrastrukturne kode, ker je ustvarjalnost in želja po automatizaciji privedla do tega, da je vse postalo zmedeno, vse ročice so bile odstranjene in je potrebno refaktorizirati.
Neprekinjena dostava
Povzamemo debit s kreditom. Najprej se pojavi opis infrastrukture, ki je lahko precej osnovni. Ni nujno, da vse podrobno opisujemo, a vsaj osnovni opis je potreben, da lahko z njim delate. Drugače ni jasno, na čem naj se nadalje izvaja neprekinjena dostava. Vse te prakse se hkrati razvijajo, ko pridete do DevOps, vendar je treba začeti z razumevanjem tega, kar imate, in kako to upravljati. To je praksa infrastrukture kot koda.
Ko enkrat razumete, kaj imate in kako to upravljati, začnete razmišljati, kako naj programersko kodo čim hitreje pošljete v produkcijo. Mislim, da to vključuje sodelovanje z razvijalcem — spomnimo se na problem „vodnjakov“, torej to ne smislijo posamezniki, temveč ekipa.
Ko smo z Ivanom Jevtuhovičem videli prvo knjigo Jezza Hamblea in skupine avtorjev „Continuous Delivery“, ki je izšla leta 2009, smo dolgo razmišljali, kako prevesti njen naslov v slovenščino. Hoteli smo prevesti kot „Nenehno dostavljati“, a smo jo, na žalost, preveli kot „Neprekinjena dostava“. Mislim, da naš naslov vsebuje nekaj pravoslavnega, z energijo.
Nenehno dostavljati pomeni
Koda, ki leži v produkcijskem repozitoriju, je vedno pripravljena za prenos v produkcijo. Morda je ne bo poslana, a je vedno pripravljena na to. Posledično vedno pišete kodo s težko razložljivim občutkom določene zaskrbljenosti v predelu trtice. To občutje zaskrbljenosti se pogosto pojavi, ko izdajate infrastrukturno kodo. To občutje zaskrbljenosti bi moralo biti prisotno — sproži miselne procese, ki omogočajo, da pišete kodo nekoliko drugače. To bi moralo biti zapisano v pravilih znotraj razvoja.
Da bi lahko nenehno dostavljali, je potreben format artefakta, ki gre skozi infrastrukturno platformo. Če na infrastrukturno platformo mečete različne formate „odpadkov življenja“, ta postane neusklajena, težko jo je vzdrževati, kar povzroči težave s tehničnim dolgom. Format artefakta je treba uskladiti — to je prav tako kolektivna naloga: moramo se skupaj zbrati, zbrati misli in ustvariti ta format.
Artifact se neprekidno poboljšava i menja prema produkcionom okruženju dok prolazi kroz isporučivački pipeline. Kada artifact prolazi kroz pipeline, stalno se suočava sa neugodnim stvarima koje liče na one s kojima se susreće artifact koji postavljate u produkciju. Ako se u klasičnom razvoju time bavi sistem administrator koji sprovodi izdavanje, u DevOps procesu to se dešava stalno: ovde ga testiraju na razne načine, tu se ubacuje u Kubernetes klaster koji je na neki način sličan proizvodnji, a tu iznenada pokreću opterećenje.
To podseća na igru Pac-Man—artifact prolazi kroz neku priču. Važno je da se kontroliše da li kod zapravo prolazi kroz priču i da li je nekako povezana s vašom produkcijom. Priče o proizvodnji se mogu uključiti u proces Kontinuirane Isporuke: nekada je bilo tako kada nešto nije funkcionisalo; hajde da sada jednostavno programiramo ovaj scenario u sistem. Svaki put kod će prolaziti kroz ovaj scenario, i neće se više suočiti s tim problemom. Saznaćete za njega mnogo pre nego što se pojavi kod vašeg klijenta.
Različite strategije postavljanja. Na primer, koristite A/B testiranje ili kanarinske postavke da biste različito 'testirali' kod na različitim klijentima, dobijali informacije o tome kako kod funkcioniše, i to mnogo pre nego što se postavi na 100 miliona korisnika.
Kontinuirana isporuka izgleda ovako.
Proces isporuke Dev, CI, Test, PreProd, Prod—nije to odvojeno okruženje, to su stagevi ili stanice s nepaličnim iznosima kroz koje prolazi vaš artifact.
Ako imate infrastrukturni kod koji je opisan kao Base Service APP, on pomaže da se ne zaborave svi scenariji, i da se oni takođe zabeleže kao kod za ovaj artifact, da se promotri artifact i menja tokom kretanja.
Pitanja za samoprovjeru
Da li vreme od opisa funkcije do postavljanja u produkciju u 95% slučajeva traje manje od nedelju dana? Da li se kvalitet artifacta povećava na svakoj etapi pipeline-a? Da li postoji priča kroz koju prolazi? Da li koristite različite strategije postavljanja?
Ako su svi odgovori da, onda ste neverovatno sjajni! Napišite odgovore u komentarima - biću srećan).
Povratna informacija
To je najteža praksa od svih. Na DevOpsConf konferenciji, kolega iz Infobipa, objašnjavajući je, pomalo se zabavljao u rečima, jer je zaista veoma složena praksa o tome šta sve treba pratiti!
Na primer, davno, kada sam radio u Qiku i shvatili smo da treba pratiti sve. Učinili smo to i u Zabbixu je bilo 150.000 stavki koje se stalno prate. Bilo je to zastrašujuće, tehnički direktor je vrtio prstom pored slepoočnice:
— Momci, zašto mučite server nejasnim stvarima?
Ali, kasnije se dogodila situacija koja je pokazala da je to zaista veoma dobra strategija.
Jedan od servisa je počeo da pada. U početku nije padao, što je zanimljivo, kod nije bio dodat, jer je to bio osnovni broker koji je praktično imao minimalnu poslovnu funkcionalnost — samo je prenosio poruke između pojedinih servisa. Servis se nije menjao četiri meseca, i odjednom je počeo da pada sa greškom „Segmentation fault“.
Bili smo u šoku, otvorili smo naše grafikon u Zabbixu i otkrili da je, izgleda, pre nedelju i po dana ozbiljno promenjeno ponašanje zahteva u API servisu koji koristi ovaj broker. Zatim smo pogledali i primetili da se učestalost slanja određene vrste poruka promenila. Otkrili smo da su to android klijenti. Pitali smo:
— Momci, šta se desilo pre nedelju i po dana?
U odgovoru smo čuli zanimljivu priču o tome da su redizajnirali UI. Teško da bi neko odmah rekao da su promenili HTTP biblioteku. Za android klijente to je kao promeniti sapun u kupatilu — jednostavno se ne sećaju. Na kraju, nakon 40 minuta razgovora, saznali smo da su ipak promenili HTTP biblioteku i da su njeni podrazumevani tajmingi promenjeni. To je dovelo do promene ponašanja saobraćaja na API serveru, što je prouzrokovalo situaciju koja je uzrokovala trku unutar brokera, i on je počeo da pada.
Bez dubokog monitoringa, to je uopšte nemoguće otkriti.Če pa v organizaciji obstaja problem "bunarjev", kjer si vsak meče krivdo drug na drugega, lahko to traja leta. Preprosto znova zagnate strežnik, ker težave ni mogoče rešiti. Ko spremljate, sledite, beležite vse dogodke, ki jih imate, in uporabljate spremljanje kot testiranje - pišete kodo in takoj navedete, kako jo spremljati, tudi v obliki kode (že imamo infrastrukturo kot kodo), vse postane jasno kot na dlani. Tudi tako zapletene težave se enostavno spremljajo.
Zberite vse informacije o tem, kaj se dogaja z artefaktom v vsaki fazi dobavnega procesa - ne v produkciji.
Naložite spremljanje na CI, in tam bodo že vidne nekatere osnovne stvari. Kasneje jih boste videli tako v Testu kot v PredProdukciji in v obremenitvenem testiranju. Zberite informacije v vseh fazah, ne le metrike in statistiko, temveč tudi dnevniške podatke: kako je bila aplikacija uvedena, anomalije - zberite vse.
V nasprotnem primeru bo težko razjasniti. Že sem rekel, da je DevOps večja kompleksnost. Da bi se spoprijeli s to kompleksnostjo, morate imeti normalno analitiko..
Vprašanja za samocontroliranje.
Je vaše spremljanje in beleženje razvojno orodje za vas? Ali vaši razvijalci, vi vključno, ko pišejo kodo, razmišljajo o tem, kako jo spremljati?
Ali izveste o težavah od strank? Ali bolje razumete stranko iz spremljanja in beleženja? Ali bolje razumete sistem iz spremljanja in beleženja? Ali spremenite sistem samo zato, ker ste opazili, da trend v sistemu narašča in razumete, da bo čez tri tedne vse propadlo?
Ko imate te tri komponente, lahko razmislite o tem, kakšna je vaša infrastrukturna platforma v podjetju.
Infrastrukturna platforma.
Smisel ni v tem, da gre za skupek razpršenih orodij, ki jih ima vsako podjetje.
Smisel infrastrukturne platforme je v tem, da vse ekipe uporabljajo ta orodja in jih skupaj razvijajo.
Jasno je, da so tu ločene ekipe, ki so odgovorne za razvoj posameznih delov infrastrukturne platforme. Vendar pa je odgovornost za razvoj, delovanje, napredek infrastrukturne platforme na vsakem inženirju. Na notranji ravni postane to splošno orodje..
Vse ekipe razvijajo infrastrukturno platformo, do nje pristopajo skrbno, kot do lastnega IDE.. V svojem IDE namestite različne vtičnike, da je vse lepo in hitro, nastavljate bližnjice. Ko odprete Sublime, Atom ali Visual Studio Code, se tam pojavijo napake v kodi in razumete, da je delo sploh nemogoče, takoj postanete žalostni in odhitite popraviti svoj IDE.
Tako ravnajte tudi z vašo infrastrukturno platformo. Če razumete, da nekaj ni v redu, oddajte zahtevo, če ne morete popraviti sami. Če gre za kaj preprostega - popravite sami, pošljite pull request - fantje bodo pregledali in dodali. To je nekoliko drugačen pristop k inženirskemu orodju v mislih razvijalca.
Infrastrukturna platforma zagotavlja prenos artefakta od razvoja do stranke s stalnim izboljšanjem kakovosti.. V IP je programiran niz zgodb, ki se zgodijo s kodo v produkciji. Po letih razvoja postane teh zgodb zelo veliko, del njih je edinstven in se nanaša samo na vas - ni jih mogoče najti na Googlu.
V tem trenutku infrastrukturna platforma postane vaša konkurenčna prednost., ker je v njej zakodirano tisto, česar ni v orodju konkurence. Tem globlja je vaša IP, večja je vaša konkurenčna prednost v smislu Time-to-market. Tu se pojavi problem vendor lock.: lahko si vzamete tujo platformo, vendar s tujo izkušnjo ne boste razumeli, kako relevantna je za vas. Da, ni vsako podjetje sposobno zgraditi platforme, kot je Amazon. To je zapleten rob, kjer je izkušnja podjetja relevantna glede na njegovo mesto na trgu, in spuščati tja vendor lock ne sme. O tem je prav tako pomembno razmisliti.
Scheme
To je osnovna shema infrastrukturne platforme, ki vam bo pomagala urediti vse prakse in procese v DevOps podjetju.
Poglejmo, iz česa sestavlja.
Sistem orkestracije virov, ki zagotavlja CPU, pomnilnik, disk aplikacijam in drugim storitvam. Nad tem - nizke ravni storitve:monitoring, beleženje, CI/CD Engine, shrambe artefaktov, infrastruktura kot koda sistemov.
Storitve višje ravni.: podatkovna baza kot storitev, čakalne vrste kot storitev, Load Balance kot storitev, preurejanje slik kot storitev, Big Data tovarna kot storitev. Čez to — cevi, ki neprekinjeno dostavljajo spremenjen kodo vašemu uporabniku.
Prejmete informacije o tem, kako vaše programsko opremo deluje pri uporabniku, spremenite, ponovno dostavite to kodo, pridobite informacije — in tako nenehno razvijate tako infrastrukturo platforme kot tudi vašo programsko opremo.
Na diagramu je dostavna cev sestavljena iz mnogih stopenj. To je načelni diagram, ki je prikazan kot primer — ni potrebno, da ga ponavljate do potankosti. Stopenje komunicirajo s storitvami kot storitve — vsak del platforme nosi svojo zgodbo: kako se dodelijo viri, kako se aplikacija zažene, dela z viri, se spremlja, spreminja.
Pomembno je razumeti, da vsak del platforme nosi svojo zgodbo, in se spraševati — katero zgodbo nosi ta del, morda bi ga bilo smiselno odstraniti in zamenjati z zunanjimi storitvami. Na primer, ali je mogoče namesto tega dela postaviti Okmeter? Morda so fantje to ekspertizo že razvili veliko bolj kot mi. A morda tudi ne — morda imamo edinstveno ekspertizo, potrebujemo da postavimo Prometheus in to razvijamo naprej.
Ustvarjanje platforme
To je zapleten komunikacijski proces. Ko imate osnovne prakse, začnete komunikacijo med različnimi inženirji in strokovnjaki, ki razvijejo zahteve in standarde ter jih nenehno prilagajajo različnim orodjem in pristopom. Tu je pomembna kultura, ki obstaja v DevOps.
S kulturo je zadeva zelo preprosta — to je sodelovanje in komunikacija, torej želja delati v skupnem prostoru med seboj, želja, da skupaj upravljamo z enim orodjem. Tu ni nobene raketne znanosti — vse je zelo preprosto, banalno. Na primer, vsi živimo v večstanovanjski hiši in skrbimo za njeno čistost — takšen je nivo kulture.
Kaj pa vi?
Spet vprašanja, ki si jih lahko postavite.
Ali je infrastruktura platforma ločena? Kdo odgovarja za njeno razvoj? Ali razumete konkurenčne prednosti svoje infrastrukture platforme?
Te vprašanja si je treba neprestano postavljati. Če je mogoče kaj prenesti na zunanje storitve, to storite; če zunanja storitev začne blokirati vaše delovanje, je treba zgraditi sistem znotraj sebe.
Torej, DevOps…
… to je zapleten sistem, v katerem morajo biti:
- Digitalni izdelek.
- Poslovni moduli, ki razvijajo ta digitalni izdelek.
- Produktne ekipe, ki pišejo kodo.
- Prakse neprekinjenega dobavljanja.
- Platforme kot storitev.
- Infrastruktura kot storitev.
- Infrastruktura kot koda.
- Ločene prakse ohranjanja zanesljivosti, vpete znotraj DevOps-a.
- Praktika povratnih informacij, ki to vse opisuje.
To shemo lahko uporabite, obarvate tisto, kar že imate v podjetju v neki obliki: to se je razvilo ali pa ga je še treba razviti.
Že čez nekaj tednov bo potekalo . v okviru RIT++. Pridružite se konferenci, kjer vas čakajo številna odlična predavanja o neprekinjenem dobavljanju, infrastrukturi kot kodi in DevOps transformaciji. , zadnji rok za cene 20. maja
Izvor: habr.com
