{"id":33725,"date":"2019-10-31T21:54:21","date_gmt":"2019-10-31T18:54:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/chto-takoe-devops\/"},"modified":"2019-10-31T21:54:21","modified_gmt":"2019-10-31T18:54:21","slug":"chto-takoe-devops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/chto-takoe-devops","title":{"rendered":"\u0427\u0442\u043e \u0442\u0430\u043a\u043e\u0435 DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Opredelitev DevOps je zelo zapletena, zato je treba vsakokrat znova spro\u017eiti razpravo o tem. Na Habr\u00e9 je tiso\u010d objav na to temo. Ampak, \u010de to berete, potem zagotovo veste, kaj je DevOps. Ker jaz ne. \u017divjo, moje ime je Aleksander Titov (@osminog<\/a><\/noindex><\/b>), in samo pogovorili se bomo o DevOpsu in delil bom svoje izku\u0161nje.<\/p>\n

\"\u0427\u0442\u043e
\n
\nDolg \u010dasa sem razmi\u0161ljal, kako narediti svoj govor koristen, zato bo tukaj veliko vpra\u0161anj - tistih, ki si jih postavljam sam, in tistih, ki jih postavljam strankam na\u0161e podjetja. Z odgovarjanjem na ta vpra\u0161anja postane razumevanje bolj\u0161e. Povedal bom, zakaj je DevOps potreben z mojega stali\u0161\u010da, kaj to sploh je, znova z moje pozicije, in kako razumeti, ali se premikate proti DevOpsu, spet z mojega stali\u0161\u010da. Zadnja to\u010dka bo skozi vpra\u0161anja. Z odgovarjanjem nanje sam sebi boste lahko ugotovili, ali va\u0161a podjetja napredujejo proti DevOpsu ali se sre\u010dujejo s te\u017eavami.
\n<\/a><\/noindex>
\n

\r\n \"Predvajaj\r\n
<\/div>\r\n <\/div><\/center>
\nNekaj \u010dasa sem se gibal po valovih zdru\u017eitev in prevzemov. Najprej sem delal v majhnem start-upu Qik, nato ga je kupila nekoliko ve\u010dja podjetja Skype, ki ga je nato kupila \u0161e nekoliko ve\u010dja podjetja Microsoft. V tem trenutku sem dobil vpogled v to, kako se predstava o DevOpsu preoblikuje v razli\u010dnih podjetjih z razli\u010dno velikostjo. Po tem me je zanimalo gledati na DevOps z vidika trga, zato smo s sodelavci ustanovili podjetje Ekspress 42. \u017de 6 let se na njem premikamo po valovih trga.<\/p>\n

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\u010dke, analiziramo, povemo svoje ugotovitve vsem, u\u010dimo ljudi DevOps praks. Na kratko, na vse mo\u017ene na\u010dine krepimo izku\u0161nje in strokovno znanje na tem podro\u010dju.<\/p>\n

Zakaj DevOps<\/h2>\n

\nPrvo vpra\u0161anje, ki mu\u010dijo vse in vedno - zakaj? Mnogi menijo, da je DevOps preprosto avtomatizacija ali kaj podobnega, kar je \u017ee bilo v vsakem podjetju.<\/p>\n

- Imeli smo Continuous Integration - to pomeni, da je DevOps \u017ee bil prisoten, in zakaj potrebujejo vse te neumnosti? Tam na Zahodu se zabavajo, nam pa delajo ovire pri delu!<\/i><\/p>\n

Za 9 let razvoja skupnosti in metodologije je \u017ee postalo jasno, da to niso le marketin\u0161ke ble\u0161\u010de\u010dnosti, a vendarle \u0161e vedno ni povsem jasno, zakaj je to potrebno. Kot pri vsakem orodju in procesu, ima DevOps konkretne cilje, ki jih na koncu dose\u017ee.<\/p>\n

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\u0161ega svetnika iz Sankt Peterburga, iz to\u010dke A v to\u010dko B po dolo\u010deni strategiji, zgrajeni za to posebni strukturi. <\/p>\n

\"\u0427\u0442\u043e
\n<\/p>\n

Na\u010deloma bi moralo biti v IT vse zgrajeno pod tem pristopom. Tukaj se IT uporablja izklju\u010dno za avtomatizacijo procesov.<\/p><\/blockquote>\n

\nAvtomatizacija se ne spreminja pogosto, ker ko podjetje te\u010de po ustaljeni poti - kaj tu spremeniti? Dela - ne dotikaj se. Zdaj se svetovi pristopi spreminjajo, in tisti, ki se imenuje Agile, pravi, da kon\u010dne to\u010dke B takoj ne vidi.<\/p>\n

\"\u0427\u0442\u043e
\n
\nKo podjetje hodi po trgu, dela s stranko - nenehno raziskuje trg in spreminja kon\u010dno to\u010dko B. Pri \u010demer, bolj pogosto kot podjetje spremeni svojo smer, ve\u010dja je na koncu uspe\u0161nost, ker izbere ve\u010d tr\u017enih ni\u0161.<\/p>\n

Strategijo prikazuje zanimivo podjetje, o katerem sem se nedavno nau\u010dil. One Box Shave - storitev dostave britv in britvenih pripomo\u010dkov na naro\u010dnino v \u0161katli. Umejo prilagoditi svojo '\u0161katlo' razli\u010dnim strankam. S tem se ukvarja dolo\u010den program, ki nato po\u0161lje naro\u010dilo na korejsko tovarno, ki proizvaja izdelek.<\/p>\n

Ta izdelek je kupila dru\u017eba Unilever za 1 milijardo dolarjev. Zdaj se konkuren\u010dno bori z Gillette in mu je odvzela pomemben dele\u017e potro\u0161nikov na ameri\u0161kem trgu. One Box Shave pravijo:<\/p>\n

\u2014 4 rezila? Resno? Zakaj to potrebujete - to nikakor ne izbolj\u0161a kakovosti britja. Posebej izbrana krema, di\u0161ava in kakovostna britva z dvema reziloma re\u0161ujejo veliko ve\u010d vpra\u0161anj kot ta neumna 4 rezila Gillette! Tako bomo kmalu pri desetih?<\/i><\/p>\n

Tako se svet spreminja. Unilever trdi, da imajo odli\u010den IT sistem, ki to omogo\u010da. Na koncu to izgleda kot koncept Time-to-market<\/b>, o katerem \u017ee ni govorila samo ena oseba.<\/p>\n

\"\u0427\u0442\u043e
\n
\nSmisel 'Time-to-market' ni v tem, kako pogosto izvajamo uvedbe. Pogosto lahko uvedemo, vendar so lahko cikli izdaj dolgi. \u010ce tri mese\u010dne cikle izdaj zlo\u017eimo drug na drugega in jih premikamo za teden, podjetje deluje, kot da se uvedba dogaja enkrat na teden. Od ideje do kon\u010dne realizacije minejo 3 mesece.<\/p>\n

'Time-to-market' se nana\u0161a na minimizacijo \u010dasa od ideje do kon\u010dne realizacije.<\/p><\/blockquote>\n

\nV tem primeru programska oprema sodeluje s trgom. Tako kot pri One Box Shave spletna stran komunicira s strankami. Nimajo prodajalcev \u2014 samo spletna stran, kjer obiskovalec klikne in pusti \u017eelje. Zato je na spletni strani treba stalno postavljati nekaj novega, ga posodabljati v skladu z \u017eeljami. Na primer, v Ju\u017eni Koreji se britje ne izvaja tako kot v Rusiji, in tam ljudje raje vonjajo po drugih vonjih, kot je, recimo, vanilija z koren\u010dkom.<\/p>\n

Ker je potrebno hitro spreminjati vsebino spletne strani, se razvoj programske opreme mo\u010dno spreminja. Preko programske opreme moramo ugotoviti, kaj \u017eeli stranka. Pred tem smo to ugotavljali preko nekaterih posrednih poti, na primer, preko poslovnega mened\u017ementa. Nato smo projektirali in v IT-sistem vklju\u010dili zahteve, kar je bilo super. Zdaj je vse druga\u010de - programska oprema se projektira s strani vseh, ki so vklju\u010deni v proces, vklju\u010dno z in\u017eenirji, ki preko tehni\u010dnih specifikacij ugotovijo, kako deluje trg, in svoje vpoglede delijo s poslovanjem.<\/p>\n

Na primer, v podjetju Qik smo nenadoma ugotovili, da ljudem zelo ustreza nalagati kontaktne sezname na stre\u017enik, in dodali so nam aplikacijo. Sprva tega nismo razmi\u0161ljali. V klasi\u010dnem podjetju bi vsi rekli, da je to napaka, ker v specifikaciji ni zapisano, da mora delovati dobro, in bi dejansko to funkcionalnost izklju\u010dili, ter rekli: 'To ni nikomur potrebno, najpomembnej\u0161e je, da osnovna funkcionalnost deluje.' Tehnolo\u0161ko podjetje pa v tem vidi prilo\u017enost in za\u010dne prilagajati programsko opremo temu.<\/p>\n

\"\u0427\u0442\u043e
\n
\nLeta 1968 je predvidevalni fant Melvin Conway oblikoval naslednjo idejo.<\/p>\n

Organizacija, ki ustvarja sistem, je omejena z oblikovanjem, ki kopira strukturo komunikacije v tej organizaciji.<\/p><\/blockquote>\n

\n\u010ce \u017eelite podrobneje, morate za ustvarjanje sistemov druge vrste poleg tega imeti tudi komunikacijsko strukturo znotraj podjetja druge vrste. \u010ce imate hierarhi\u010dno komunikacijsko strukturo, vam to ne bo omogo\u010dilo ustvariti sistemov, ki lahko dose\u017eejo zelo visoko stopnjo Time-to-market.<\/p>\n

Preberi o Leyni zakon<\/a><\/noindex> je mo\u017eno po povezavah<\/a><\/noindex>. Pomembno je za razumevanje kulture ali filozofije DevOps, ker edina stvar, ki se v DevOps bistveno spreminja, je prav komunikacijska struktura med ekipami.<\/b>.<\/p>\n

Z vidika procesa so do DevOps vse faze: analiza, razvoj, testiranje, delovanje potekale linearno.\"\u0427\u0442\u043e
\nV DevOps pa vse te procese potekajo hkrati.<\/p>\n

\"\u0427\u0442\u043e
\n
\nTime-to-market se lahko tako dose\u017ee. Za ljudi, ki so delali v starem procesu, to izgleda nekoliko nepredstavljivo, in sploh ne.<\/p>\n

Zakaj torej DevOps?<\/h3>\n

\nZa razvoj digitalnih izdelkov<\/b>. \u010ce v va\u0161i dru\u017ebi ni digitalnega izdelka, DevOps ni potreben \u2013 to je zelo pomembno.<\/p>\n

DevOps premaguje hitrostne omejitve zaporednega postopka razvoja programske opreme.<\/b>. V njem vsi procesi potekajo hkrati.<\/p>\n

Pove\u010duje se kompleksnost.<\/b> Ko DevOps evangelisti govorijo, da bo z njim la\u017eje izdati programsko opremo \u2013 to je neumnost.<\/p>\n

S DevOps bo vse le \u0161e bolj zapleteno.<\/p><\/blockquote>\n

\nNa konferenci ste lahko na stojnici Avita videli, kaj pomeni razporediti Docker kontejner \u2013 nerealna naloga. Kompleksnost postaja nepredstavljiva, treba je \u017eonglirati z ve\u010d obro\u010di hkrati.<\/p>\n

DevOps popolnoma spreminja proces in organizacijo v podjetju<\/b>\u00a0\u2013 natan\u010dneje, ne menja DevOps, ampak digitalni izdelek. Da pridete do DevOps, morate ta proces popolnoma spremeniti.<\/p>\n

Vpra\u0161anja za strokovnjaka<\/h3>\n

\nKaj pa vi? Vpra\u0161anja, ki si jih lahko postavite, ko delate v podjetju in se razvijate kot strokovnjak.<\/p>\n

Imate strategijo za ustvarjanje digitalnega izdelka?<\/b> \u010ce jo imate \u2013 \u017ee dobro. To pomeni, da va\u0161e podjetje napreduje proti DevOps.<\/p>\n

Ali va\u0161e podjetje \u017ee ustvarja digitalni izdelek?<\/b> To pomeni, da se lahko dvignete \u0161e na eno stopnjo vi\u0161je, ukvarjate se z bolj zanimivimi zadevami \u2013 prav tako z vidika DevOps. O tem govorim samo z te perspektive.<\/p>\n

Ali je va\u0161e podjetje eden vodilnih na trgu v ni\u0161i z digitalnim izdelkom?<\/b> Spotify, Yandex, Uber \u2014 podjetja, ki so trenutno na vrhuncu tehnolo\u0161kega napredka.<\/p>\n

Postavite si ta vpra\u0161anja, in \u010de so vsi odgovori negativni, morda res ni smiselno ukvarjati se z DevOps v tem podjetju. \u010ce pa vas tema DevOps resni\u010dno zanima, morda,... bi se morali preseliti v drugo podjetje? \u010ce va\u0161e podjetje \u017eeli preiti na DevOps, a ste na vsa vpra\u0161anja odgovorili \"Ne\", potem spominja na lepega nosoroga, ki se nikoli ne bo spremenil.<\/p>\n

\"\u0427\u0442\u043e
\n<\/p>\n

Organizacija<\/h2>\n

\nKot sem \u017ee povedal, po zakonu Conwaya se organizacija v podjetju spreminja. Za\u010del bom s tistim, kar ovira DevOps, da pronica v notranjost podjetja, prav z vidika organizacije.<\/p>\n

Te\u017eava \"silosov\"<\/h3>\n

\nAngle\u0161ka beseda \"Silo\" je tukaj prevedena v sloven\u0161\u010dino kot \"kolodvor\". Pomen te te\u017eave je v tem, da med ekipami ni izmenjave informacij.<\/b>. Vsaka ekipa izkopava svojo ekspertizo globoko, pri tem pa ne gradi skupne karte, po kateri bi se lahko orientirali.<\/p>\n

Nekako spominja na osebo, ki je ravnokar prispela v Moskvo in \u0161e ne zna brati zemljevida metroja. Moskvi\u010di obi\u010dajno odli\u010dno poznajo svojo \u010detrt, po celi Moskvi pa se orientirajo po zemljevidu metroja. Ko prvi\u010d pride\u0161 v Moskvo, ti ta ve\u0161\u010dina \u0161e manjka in si preprosto dezorientiran.<\/p>\n

DevOps ponuja, da preidete \u010dez ta trenutek dezorientacije in da skupaj z vsemi oddelki zgradite skupno karto interakcije.<\/p><\/blockquote>\n

\nTo ovira dva dejavnika.<\/p>\n

Posledica korporativnega sistema upravljanja.<\/b> Ta sistem je zgrajen iz lo\u010denih hierarhi\u010dnih \"silosov\". Na primer, obstajajo dolo\u010deni KPI-ji v podjetjih, ki podpirajo ta sistem. Po drugi strani pa so ovira misli osebe, ki ji je te\u017eko prestopiti meje svoje ekspertize in se orientirati v celotnem sistemu. To preprosto ni udobno. Predstavljajte si, da ste pri\u0161li na letali\u0161\u010de v Bangkoku \u2014 tam se hitro ne znajdete. V DevOpsu je tudi te\u017eko orientirati se, zato ljudje pravijo, da je treba najti vodnika, da se tja pride.<\/p>\n

Ampak najpomembnej\u0161e je, da se te\u017eava \"silosov\" za in\u017eenirja, ki je sprejel duh DevOps, prebral Fowlerja in kup drugih knjig, izra\u017ea v tem, da \"silosni\" ne dovoljujejo izvajanja \"o\u010ditnih\" stvari.<\/b>. Pogosto se zberemo po DevOps Moscow, se pogovarjamo med seboj in ljudje se prito\u017eujejo:<\/p>\n

\u2014 \u017deleli smo samo zagnati CI, a je pri\u0161lo do tega, da to vodstvu ni potrebno.<\/i><\/p>\n

To se dogaja prav zaradi tega,\u00a0CI <\/b>in\u00a0postopek nenehnega dostavljanja<\/b> 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\u010dnete in kako \u017ealostno to je.<\/p>\n

\"\u0427\u0442\u043e
\n
\nVsak udele\u017eenec procesa v podjetju: razvijalci backend-a in frontend-a, testiranje, DBA, obratovanje, mre\u017ea, koplje v svojo smer, skupne karte pa nima nih\u010de, razen vodje, ki nekako nadzira in upravlja s metodo \"deli in vladaj\".<\/p>\n

Ljudje se borijo za neke zvezde ali zastavice, vsak koplje svojo ekspertizo.<\/p><\/blockquote>\n

\nNa koncu, ko se pojavi naloga, da vse to zdru\u017eimo in zgradimo skupni pipeline, in za zvezde in zastavice ni ve\u010d potrebe za boj, se pojavi vpra\u0161anje \u2014 kaj pa zdaj? Moramo se nekako dogovoriti, a kako to storiti, nas v \u0161oli nih\u010de ni u\u010dil. \u0160e v \u0161oli smo bili nau\u010deni: osmi razred \u2014 oho! \u2014 v primerjavi s sedmim razredom! Tudi tu je enako.<\/p>\n

Je tudi v va\u0161em podjetju tako?<\/h3>\n

\nDa to preverite, si lahko postavite naslednja vpra\u0161anja.<\/p>\n

Ali ekipe uporabljajo skupna orodja, prispevajo k spremembam teh skupnih orodij?<\/p>\n

Kako pogosto se ekipe prevladujejo \u2013 eni strokovnjaki iz ene ekipe prehajajo v drugo ekipo?<\/b> V DevOps okolju to postaja norma, saj v\u010dasih oseba preprosto ne more razumeti, s \u010dim se ukvarja druga podro\u010dje strokovnjaka. Prelazi v drug oddelek, tam dela dva tedna, da si ustvari orientacijsko karto in vzpostavi interakcijo s tem oddelkom.<\/p>\n

Ali je mogo\u010de ustanoviti odbor za spremembe in kaj spremeniti? <\/b>Ali pa za to potrebujete mo\u010dno roko najvi\u0161jega 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 \u017ealostno.<\/p>\n

Kako pomembno je za mened\u017eerje, da dobijo osebne dose\u017eke ne glede na dose\u017eke podjetja? <\/b><\/p>\n

\u010ce si na ta vpra\u0161anja odgovorite sami, bo jasneje, ali imate v podjetju tak\u0161no te\u017eavo.<\/p>\n

Infrastruktura kot koda<\/h2>\n

\nKo kon\u010danju teh te\u017eav je prva pomembna praksa, brez katere je te\u017eko napredovati v DevOps, infrastruktura kot koda<\/b>. <\/p>\n

Najpogosteje se infrastruktura kot koda razume kot:<\/p>\n

\u2014 Poglejmo, da vse avtomatiziramo z bashom, se oblo\u017eimo s skripti, da bo skrbnikom manj ro\u010dnega dela!<\/i><\/p>\n

Toda to ni tako.<\/p>\n

Infrastruktura kot koda pomeni, da IT-sistem, s katerim delate, opisujete v obliki kode, da nenehno razumete njeno stanje.<\/p><\/blockquote>\n

\nSkupaj z drugimi ekipami ustvarjate zemljevid v obliki kode, ki je vsem razumljiv in po katerem se lahko orientirate. Ni va\u017eno, na \u010dem je to narejeno \u2014 Chef, Ansible, Salt ali se uporabljajo YAML-datoteke v Kubernetesu \u2014 to ni pomembno.<\/p>\n

Na konferenci je kolega iz 2GIS-a pripovedoval, kako so naredili svoj notranji pripomo\u010dek za Kubernetes, ki opisuje strukturo posameznih sistemov. Da bi opisali 500 sistemov, so potrebovali poseben pripomo\u010dek, ki ta opis generira. Ko je ta opis na voljo, si vsak lahko izmenjuje informacije, spremlja spremembe, kako jih lahko spremeni in izbolj\u0161a, \u010desa manjka. <\/p>\n

Se strinjate, da posamezni bash skripti obi\u010dajno ne ponujajo tega razumevanja. V eni od podjetij, kjer sem delal, so celo imeli naziv \u201ewrite only\u201c skript - ko je skript napisan, ga ne morete ve\u010d prebrati. Mislim, da vam to tudi zveni znano.<\/p>\n

Infrastruktura kot koda je koda, ki opisuje trenutno stanje infrastrukture<\/b>. S to kodo skupaj delajo \u0161tevilne produktne, infrastrukturne in servisne ekipe, in kar je najpomembnej\u0161e, vse morajo razumeti, kako ta koda sploh deluje.<\/p>\n

Koda se vzdr\u017euje v skladu z najbolj\u0161imi praksami dela s kodo<\/b>: skupno razvijanje, pregledovanje kode, XP-programiranje, testiranje, pull requesti, CI za infrastrukturo kode \u2014 to je vse dobro in uporabno.<\/p>\n

Koda postane skupni jezik za vse in\u017eenirje.<\/p><\/blockquote>\n

\nSprememba infrastrukture v kodi ne vzame veliko \u010dasa<\/b>. Da, v infrastrukturni kodi je lahko tudi tehni\u010dni dolg. Obi\u010dajno se ekipe s tem sre\u010dajo pribli\u017eno pol leta po tem, ko so za\u010dele implementirati \u201einfrastrukturo kot kodo\u201c v obliki kup\u010dka skriptov ali celo Ansible-a, ki ga pi\u0161ejo kot testenine, in \u0161e bash skripti se vr\u017eejo v pe\u010d! <\/p>\n

Pomembno<\/b>: \u010de \u0161e niste poskusili te re\u010di, zapomnite si, da Ansible ni bash<\/b>! Pozorno preberite dokumentacijo, preglejte, kaj o tem pravijo.<\/p>\n

Infrastruktura kot koda - to je razdelitev infrastrukturne kode na lo\u010dene plasti.<\/p><\/blockquote>\n

\nV na\u0161i dru\u017ebi izpostavljamo 3 osnovne plasti, ki so zelo jasne in preproste, a jih je lahko ve\u010d. Lahko si ogledate svojo infrastrukturno kodo in si re\u010dete, ali imate to stanje ali ne. \u010ce se nobene plasti ne izlo\u010dajo, je treba vzeti \u010das in malo refaktorizirati.
\n\"\u0427\u0442\u043e
\n
\nOsnovna plast<\/b>\u00a0\u2014 to je, kako se nastavi OS, varnostne kopije in druge nizkonivojske stvari, kot je na osnovnem nivoju razporeditev Kubernetes.<\/p>\n

Plast storitev<\/b>\u00a0\u2014 to so storitve, ki jih nudite razvijalcu: bele\u017eenje kot storitev, nadzor kot storitev, podatkovna baza kot storitev, balansirnik kot storitev, vrstica kot storitev, neprekinjena dostava kot storitev - mno\u017eica storitev, ki jih lahko lo\u010dene ekipe nudijo razvoju. Vse to je treba opisati z lo\u010denimi moduli v va\u0161em sistemu upravljanja konfiguracije.<\/p>\n

Plast, kjer se izdelujejo aplikacije<\/b> in opisuje, kako se bodo razvijale nad dvema prej\u0161njima plastema.<\/p>\n

Kontrolna vpra\u0161anja<\/h3>\n

\nAli imate v podjetju skupni infrastrukturni repozitorij? Ali spremljate tehni\u010dni dolg v infrastrukturi? Ali uporabljate prakse razvoja v infrastrukturnem repozitoriju? Ali je va\u0161a infrastruktura razdeljena na plasti? Lahko se sklicujete na shemo Base-service-APP. Kako te\u017eko je uvesti spremembo? <\/p>\n

\u010ce ste se sre\u010dali s tem, da je vnos sprememb trajal dan in pol, to pomeni, da ste pridobili tehni\u010dni dolg in ga je treba razre\u0161iti. Naleteli ste na pasti tehni\u010dnega dolga v infrastrukturni kodi. Spomnim se mnogih tak\u0161nih zgodb, ko je bilo potrebno, da se spremeni kak\u0161en CCTL, prepisati polovico infrastrukturne kode, ker je ustvarjalnost in \u017eelja po automatizaciji privedla do tega, da je vse postalo zmedeno, vse ro\u010dice so bile odstranjene in je potrebno refaktorizirati.<\/p>\n

Neprekinjena dostava<\/h2>\n

\nPovzamemo 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\u010de ni jasno, na \u010dem naj se nadalje izvaja neprekinjena dostava. Vse te prakse se hkrati razvijajo, ko pridete do DevOps, vendar je treba za\u010deti z razumevanjem tega, kar imate, in kako to upravljati. To je praksa infrastrukture kot koda.<\/p>\n

Ko enkrat razumete, kaj imate in kako to upravljati, za\u010dnete razmi\u0161ljati, kako naj programersko kodo \u010dim hitreje po\u0161ljete v produkcijo. Mislim, da to vklju\u010duje sodelovanje z razvijalcem \u2014 spomnimo se na problem \u201evodnjakov\u201c, torej to ne smislijo posamezniki, temve\u010d ekipa.<\/p>\n

Ko smo\u00a0z Ivanom Jevtuhovi\u010dem<\/b> videli prvo knjigo Jezza Hamblea<\/b> in skupine avtorjev \u201eContinuous Delivery\u201c<\/b>, ki je iz\u0161la leta 2009, smo dolgo razmi\u0161ljali, kako prevesti njen naslov v sloven\u0161\u010dino. Hoteli smo prevesti kot \u201eNenehno dostavljati\u201c, a smo jo, na \u017ealost, preveli kot \u201eNeprekinjena dostava\u201c. Mislim, da na\u0161 naslov vsebuje nekaj pravoslavnega, z energijo.<\/p>\n

Nenehno dostavljati pomeni<\/h3>\n

\nKoda, ki le\u017ei v produkcijskem repozitoriju, je vedno pripravljena za prenos v produkcijo<\/b>. Morda je ne bo poslana, a je vedno pripravljena na to. Posledi\u010dno vedno pi\u0161ete kodo s te\u017eko razlo\u017eljivim ob\u010dutkom dolo\u010dene zaskrbljenosti v predelu trtice. To ob\u010dutje zaskrbljenosti se pogosto pojavi, ko izdajate infrastrukturno kodo. To ob\u010dutje zaskrbljenosti bi moralo biti prisotno \u2014 spro\u017ei miselne procese, ki omogo\u010dajo, da pi\u0161ete kodo nekoliko druga\u010de. To bi moralo biti zapisano v pravilih znotraj razvoja.<\/p>\n

Da bi lahko nenehno dostavljali, je potreben format artefakta, ki gre skozi infrastrukturno platformo. <\/b>\u010ce na infrastrukturno platformo me\u010dete razli\u010dne formate \u201eodpadkov \u017eivljenja\u201c, ta postane neusklajena, te\u017eko jo je vzdr\u017eevati, kar povzro\u010di te\u017eave s tehni\u010dnim dolgom. Format artefakta je treba uskladiti \u2014 to je prav tako kolektivna naloga: moramo se skupaj zbrati, zbrati misli in ustvariti ta format.<\/p>\n

Artifact se neprekidno pobolj\u0161ava i menja prema produkcionom okru\u017eenju dok prolazi kroz isporu\u010diva\u010dki pipeline. <\/b>Kada artifact prolazi kroz pipeline, stalno se suo\u010dava sa neugodnim stvarima koje li\u010de na one s kojima se susre\u0107e artifact koji postavljate u produkciju. Ako se u klasi\u010dnom razvoju time bavi sistem administrator koji sprovodi izdavanje, u DevOps procesu to se de\u0161ava stalno: ovde ga testiraju na razne na\u010dine, tu se ubacuje u Kubernetes klaster koji je na neki na\u010din sli\u010dan proizvodnji, a tu iznenada pokre\u0107u optere\u0107enje.<\/p>\n

To podse\u0107a na igru Pac-Man\u2014artifact prolazi kroz neku pri\u010du. Va\u017eno je da se kontroli\u0161e da li kod zapravo prolazi kroz pri\u010du i da li je nekako povezana s va\u0161om produkcijom. Pri\u010de o proizvodnji se mogu uklju\u010diti u proces Kontinuirane Isporuke: nekada je bilo tako kada ne\u0161to nije funkcionisalo; hajde da sada jednostavno programiramo ovaj scenario u sistem. Svaki put kod \u0107e prolaziti kroz ovaj scenario, i ne\u0107e se vi\u0161e suo\u010diti s tim problemom. Sazna\u0107ete za njega mnogo pre nego \u0161to se pojavi kod va\u0161eg klijenta.<\/p>\n

Razli\u010dite strategije postavljanja. <\/b>Na primer, koristite A\/B testiranje ili kanarinske postavke da biste razli\u010dito 'testirali' kod na razli\u010ditim klijentima, dobijali informacije o tome kako kod funkcioni\u0161e, i to mnogo pre nego \u0161to se postavi na 100 miliona korisnika.<\/p>\n

Kontinuirana isporuka izgleda ovako.<\/p>\n

\"\u0427\u0442\u043e
\n<\/p>\n

Proces isporuke Dev, CI, Test, PreProd, Prod\u2014nije to odvojeno okru\u017eenje, to su stagevi ili stanice s nepali\u010dnim iznosima kroz koje prolazi va\u0161 artifact.<\/p><\/blockquote>\n

\nAko imate infrastrukturni kod koji je opisan kao Base Service APP, on poma\u017ee da se ne zaborave svi scenariji<\/b>, i da se oni tako\u0111e zabele\u017ee kao kod za ovaj artifact, da se promotri artifact<\/b> i menja tokom kretanja.<\/p>\n

Pitanja za samoprovjeru<\/h3>\n

\nDa li vreme od opisa funkcije do postavljanja u produkciju u 95% slu\u010dajeva traje manje od nedelju dana? Da li se kvalitet artifacta pove\u0107ava na svakoj etapi pipeline-a? Da li postoji pri\u010da kroz koju prolazi? Da li koristite razli\u010dite strategije postavljanja?<\/p>\n

Ako su svi odgovori da, onda ste neverovatno sjajni! Napi\u0161ite odgovore u komentarima - bi\u0107u sre\u0107an).<\/p>\n

Povratna informacija<\/h3>\n

\nTo je najte\u017ea praksa od svih. Na DevOpsConf konferenciji, kolega iz Infobipa, obja\u0161njavaju\u0107i je, pomalo se zabavljao u re\u010dima, jer je zaista veoma slo\u017eena praksa o tome \u0161ta sve treba pratiti!<\/p>\n

\"\u0427\u0442\u043e
\n
\nNa primer, davno, kada sam radio u Qiku i shvatili smo da treba pratiti sve. U\u010dinili smo to i u Zabbixu je bilo 150.000 stavki koje se stalno prate. Bilo je to zastra\u0161uju\u0107e, tehni\u010dki direktor je vrtio prstom pored slepoo\u010dnice:<\/p>\n

\u2014 Momci, za\u0161to mu\u010dite server nejasnim stvarima?<\/i><\/p>\n

Ali, kasnije se dogodila situacija koja je pokazala da je to zaista veoma dobra strategija.<\/p>\n

Jedan od servisa je po\u010deo da pada. U po\u010detku nije padao, \u0161to je zanimljivo, kod nije bio dodat, jer je to bio osnovni broker koji je prakti\u010dno imao minimalnu poslovnu funkcionalnost \u2014 samo je prenosio poruke izme\u0111u pojedinih servisa. Servis se nije menjao \u010detiri meseca, i odjednom je po\u010deo da pada sa gre\u0161kom \u201eSegmentation fault\u201c.<\/p>\n

Bili smo u \u0161oku, otvorili smo na\u0161e grafikon u Zabbixu i otkrili da je, izgleda, pre nedelju i po dana ozbiljno promenjeno pona\u0161anje zahteva u API servisu koji koristi ovaj broker. Zatim smo pogledali i primetili da se u\u010destalost slanja odre\u0111ene vrste poruka promenila. Otkrili smo da su to android klijenti. Pitali smo:<\/p>\n

\u2014 Momci, \u0161ta se desilo pre nedelju i po dana?<\/i><\/p>\n

U odgovoru smo \u010duli zanimljivu pri\u010du o tome da su redizajnirali UI. Te\u0161ko da bi neko odmah rekao da su promenili HTTP biblioteku. Za android klijente to je kao promeniti sapun u kupatilu \u2014 jednostavno se ne se\u0107aju. 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\u0161anja saobra\u0107aja na API serveru, \u0161to je prouzrokovalo situaciju koja je uzrokovala trku unutar brokera, i on je po\u010deo da pada.<\/p>\n

Bez dubokog monitoringa, to je uop\u0161te nemogu\u0107e otkriti.<\/b>\u010ce pa v organizaciji obstaja problem \"bunarjev\", kjer si vsak me\u010de krivdo drug na drugega, lahko to traja leta. Preprosto znova zagnate stre\u017enik, ker te\u017eave ni mogo\u010de re\u0161iti. Ko spremljate, sledite, bele\u017eite vse dogodke, ki jih imate, in uporabljate spremljanje kot testiranje - pi\u0161ete kodo in takoj navedete, kako jo spremljati, tudi v obliki kode (\u017ee imamo infrastrukturo kot kodo), vse postane jasno kot na dlani. Tudi tako zapletene te\u017eave se enostavno spremljajo.<\/p>\n

\"\u0427\u0442\u043e
\n<\/p>\n

Zberite vse informacije o tem, kaj se dogaja z artefaktom v vsaki fazi dobavnega procesa - ne v produkciji.<\/p><\/blockquote>\n

\nNalo\u017eite spremljanje na CI, in tam bodo \u017ee 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\u010d tudi dnevni\u0161ke podatke: kako je bila aplikacija uvedena, anomalije - zberite vse. <\/p>\n

V nasprotnem primeru bo te\u017eko razjasniti. \u017de sem rekel, da je DevOps ve\u010dja kompleksnost. Da bi se spoprijeli s to kompleksnostjo, morate imeti normalno analitiko.<\/b>.<\/p>\n

Vpra\u0161anja za samocontroliranje.<\/h3>\n

\nJe va\u0161e spremljanje in bele\u017eenje razvojno orodje za vas?<\/b> Ali va\u0161i razvijalci, vi vklju\u010dno, ko pi\u0161ejo kodo, razmi\u0161ljajo o tem, kako jo spremljati?<\/p>\n

Ali izveste o te\u017eavah od strank? Ali bolje razumete stranko iz spremljanja in bele\u017eenja?<\/b> Ali bolje razumete sistem iz spremljanja in bele\u017eenja?<\/b> Ali spremenite sistem samo zato, ker ste opazili, da trend v sistemu nara\u0161\u010da in razumete, da bo \u010dez tri tedne vse propadlo? <\/p>\n

Ko imate te tri komponente, lahko razmislite o tem, kak\u0161na je va\u0161a infrastrukturna platforma v podjetju.<\/p>\n

Infrastrukturna platforma. <\/h2>\n

\nSmisel ni v tem, da gre za skupek razpr\u0161enih orodij, ki jih ima vsako podjetje.<\/p>\n

Smisel infrastrukturne platforme je v tem, da vse ekipe uporabljajo ta orodja in jih skupaj razvijajo.<\/p><\/blockquote>\n

\nJasno je, da so tu lo\u010dene ekipe, ki so odgovorne za razvoj posameznih delov infrastrukturne platforme. Vendar pa je odgovornost za razvoj, delovanje, napredek infrastrukturne platforme na vsakem in\u017eenirju. Na notranji ravni postane to splo\u0161no orodje.<\/b>. <\/p>\n

Vse ekipe razvijajo infrastrukturno platformo, do nje pristopajo skrbno, kot do lastnega IDE.<\/b>. V svojem IDE namestite razli\u010dne vti\u010dnike, da je vse lepo in hitro, nastavljate bli\u017enjice. Ko odprete Sublime, Atom ali Visual Studio Code, se tam pojavijo napake v kodi in razumete, da je delo sploh nemogo\u010de, takoj postanete \u017ealostni in odhitite popraviti svoj IDE.<\/p>\n

Tako ravnajte tudi z va\u0161o infrastrukturno platformo. \u010ce razumete, da nekaj ni v redu, oddajte zahtevo, \u010de ne morete popraviti sami. \u010ce gre za kaj preprostega - popravite sami, po\u0161ljite pull request - fantje bodo pregledali in dodali. To je nekoliko druga\u010den pristop k in\u017eenirskemu orodju v mislih razvijalca.<\/p>\n

Infrastrukturna platforma zagotavlja prenos artefakta od razvoja do stranke s stalnim izbolj\u0161anjem kakovosti.<\/b>. 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\u0161a samo na vas - ni jih mogo\u010de najti na Googlu. <\/p>\n

V tem trenutku infrastrukturna platforma postane va\u0161a konkuren\u010dna prednost.<\/b>, ker je v njej zakodirano tisto, \u010desar ni v orodju konkurence. Tem globlja je va\u0161a IP, ve\u010dja je va\u0161a konkuren\u010dna prednost v smislu Time-to-market. Tu se pojavi problem vendor lock.<\/b>: lahko si vzamete tujo platformo, vendar s tujo izku\u0161njo 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\u0161nja podjetja relevantna glede na njegovo mesto na trgu, in spu\u0161\u010dati tja vendor lock ne sme. O tem je prav tako pomembno razmisliti.<\/p>\n

Scheme<\/h3>\n

\nTo je osnovna shema infrastrukturne platforme, ki vam bo pomagala urediti vse prakse in procese v DevOps podjetju.<\/p>\n

\"\u0427\u0442\u043e
\n
\nPoglejmo, iz \u010desa sestavlja.<\/p>\n

Sistem orkestracije virov<\/b>, ki zagotavlja CPU, pomnilnik, disk aplikacijam in drugim storitvam. Nad tem - nizke ravni storitve:<\/b>monitoring, bele\u017eenje, CI\/CD Engine, shrambe artefaktov, infrastruktura kot koda sistemov.<\/p>\n

Storitve vi\u0161je ravni.<\/b>: podatkovna baza kot storitev, \u010dakalne vrste kot storitev, Load Balance kot storitev, preurejanje slik kot storitev, Big Data tovarna kot storitev. \u010cez to \u2014 cevi, ki neprekinjeno dostavljajo spremenjen kodo va\u0161emu uporabniku<\/b>.<\/p>\n

Prejmete informacije o tem, kako va\u0161e programsko opremo deluje pri uporabniku, spremenite, ponovno dostavite to kodo, pridobite informacije \u2014 in tako nenehno razvijate tako infrastrukturo platforme kot tudi va\u0161o programsko opremo.<\/p>\n

Na diagramu je dostavna cev sestavljena iz mnogih stopenj. To je na\u010delni diagram, ki je prikazan kot primer \u2014 ni potrebno, da ga ponavljate do potankosti. Stopenje komunicirajo s storitvami kot storitve \u2014 vsak del platforme nosi svojo zgodbo: kako se dodelijo viri, kako se aplikacija za\u017eene, dela z viri, se spremlja, spreminja.<\/p>\n

Pomembno je razumeti, da vsak del platforme nosi svojo zgodbo, in se spra\u0161evati \u2014 katero zgodbo nosi ta del, morda bi ga bilo smiselno odstraniti in zamenjati z zunanjimi storitvami. Na primer, ali je mogo\u010de namesto tega dela postaviti Okmeter? Morda so fantje to ekspertizo \u017ee razvili veliko bolj kot mi. A morda tudi ne \u2014 morda imamo edinstveno ekspertizo, potrebujemo da postavimo Prometheus in to razvijamo naprej.<\/p>\n

Ustvarjanje platforme<\/h3>\n

\nTo je zapleten komunikacijski proces. Ko imate osnovne prakse, za\u010dnete komunikacijo med razli\u010dnimi in\u017eenirji in strokovnjaki, ki razvijejo zahteve in standarde ter jih nenehno prilagajajo razli\u010dnim orodjem in pristopom. Tu je pomembna kultura, ki obstaja v DevOps.<\/p>\n

\"\u0427\u0442\u043e
\nS kulturo je zadeva zelo preprosta \u2014 to je sodelovanje in komunikacija<\/b>, torej \u017eelja delati v skupnem prostoru med seboj, \u017eelja, da skupaj upravljamo z enim orodjem. Tu ni nobene raketne znanosti \u2014 vse je zelo preprosto, banalno. Na primer, vsi \u017eivimo v ve\u010dstanovanjski hi\u0161i in skrbimo za njeno \u010distost \u2014 tak\u0161en je nivo kulture.<\/p>\n

Kaj pa vi?<\/h3>\n

\nSpet vpra\u0161anja, ki si jih lahko postavite.<\/p>\n

Ali je infrastruktura platforma lo\u010dena? Kdo odgovarja za njeno razvoj? Ali razumete konkuren\u010dne prednosti svoje infrastrukture platforme?<\/p>\n

Te vpra\u0161anja si je treba neprestano postavljati. \u010ce je mogo\u010de kaj prenesti na zunanje storitve, to storite; \u010de zunanja storitev za\u010dne blokirati va\u0161e delovanje, je treba zgraditi sistem znotraj sebe.<\/p>\n

Torej, DevOps\u2026<\/h2>\n

\n\u2026 to je zapleten sistem, v katerem morajo biti:<\/p>\n