{"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\/et\/blog\/administrirovanie\/chto-takoe-devops","title":{"rendered":"Mis on DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

DevOpsi m\u00e4\u00e4ratlemine on v\u00e4ga keeruline, mist\u00f5ttu tuleb iga kord arutelu uuesti alustada. Ainu\u00fcksi Habras on sellel teemal tuhat avaldust. Aga kui te seda loete, siis teate kindlasti, mis on DevOps. Sest mina ei tea. Tere, mina olen Aleksandr Titov (@osminog<\/a><\/noindex><\/b>), ja me r\u00e4\u00e4gime lihtsalt DevOpsist ning ma jagan oma kogemust.<\/p>\n

\"Mis
\n
\nM\u00f5tlesin kaua, kuidas teha minu jutustus kasulikuks, seet\u00f5ttu tuleb siia palju k\u00fcsimusi \u2014 need, mida ma endalt k\u00fcsida, ja need, mida ma meie ettev\u00f5tte klientidelt k\u00fcsin. Neile k\u00fcsimustele vastates muutub arusaamine paremaks. R\u00e4\u00e4gin, miks DevOps on vajalik minu vaatenurgast, mis see on, taas minu positsiooni p\u00f5hjal, ja kuidas m\u00f5ista, kas liigute DevOpsi suunas, samuti minu vaatenurgast. Viimane punkt tuleb k\u00fcsimuste kaudu. Neile vastates suudate m\u00f5ista, kas teie ettev\u00f5te liigub DevOpsi suunas v\u00f5i on midagi valesti.
\n<\/a><\/noindex>
\n

\r\n \"Vaata\r\n
<\/div>\r\n <\/div><\/center>
\n\u00dchel hetkel jalutasin ma \u00fchinemiste ja omandamiste lainetel. Alguses t\u00f6\u00f6tasin ma v\u00e4ikeses idufirmas Qik, mille hiljem ostis pisut suurem ettev\u00f5te Skype, mille omakorda ostis veelgi suurem ettev\u00f5te Microsoft. Sel hetkel sain ma aru, kuidas DevOpsi m\u00f5isted erinevates suurustes ettev\u00f5tetes transformeeruvad. P\u00e4rast seda hakkas mind huvitama DevOps\u2019i vaatamine turuperspektiivist ning koos kolleegidega asutasime ettev\u00f5tte Express 42. Juba 6 aastat oleme me selles ettev\u00f5ttes turule suunatud tegevust arendamas.<\/p>\n

Lisaks olen ma \u00fcks DevOps Moscow kogukonna korraldajatest ja 2017. aasta DevOps Days\u2019i korraldaja, kuid 2018. aastal ei korraldanud ma \u00fcritust. Express 42 t\u00f6\u00f6tab paljude ettev\u00f5tetega. Me arendame seal DevOps\u2019i, j\u00e4lgime, kuidas see toimub, teeme j\u00e4reldusi, anal\u00fc\u00fcsime, jagame oma j\u00e4reldusi k\u00f5igiga, \u00f5petame inimesi DevOps\u2019i praktikates. \u00dches\u00f5naga, kasvatame igas m\u00f5ttes kogemusi ja ekspertiisi.<\/p>\n

Miks DevOps?<\/h2>\n

\nEsimene k\u00fcsimus, mis kummitab k\u00f5iki ja alati \u2013 miks? Paljud arvavad, et DevOps on lihtsalt automatiseerimine v\u00f5i sarnane asi, mis on juba igas ettev\u00f5ttes olemas.<\/p>\n

\u2014 Meil oli pidev integreerimine \u2014 see t\u00e4hendab, et DevOps oli juba olemas ja miks on kogu see jama vajalik? Seal v\u00e4lismaal l\u00f5bustavad ennast, aga meil segavad t\u00f6\u00f6tamist!<\/i><\/p>\n

9 aasta jooksul, mil kogukond ja metoodika on arenenud, on juba selgeks saanud, et need ei ole pelgalt turunduslikud s\u00e4delused, aga ikkagi ei ole veel selge, miks see vajalik on. Nagu igal toolil ja protsessil, on DevOps-il konkreetsed eesm\u00e4rgid, mida ta l\u00f5puks lahendab.<\/p>\n

See k\u00f5ik on seotud sellega, et maailm muutub. See liigub eemale ettev\u00f5tte l\u00e4henemisviisist, kus firmad liiguvad otse unistuste poole, nagu \u00fctles meie Peterburi klassik, punktist A punkti B kindla strateegia kaudu, milline struktuur on selle jaoks ehitatud. <\/p>\n

\"Mis
\n<\/p>\n

P\u00f5him\u00f5tteliselt peaks IT k\u00f5ik olema \u00fcles ehitatud selle l\u00e4henemisviisi \u00fcmber. Siin kasutatakse IT-d eelk\u00f5ige protsesside automatiseerimiseks.<\/p><\/blockquote>\n

\nAutomatiseerimine ei muutu sageli, sest kui ettev\u00f5te s\u00f5idab juba v\u00e4lja t\u00f6\u00f6tatud rajal \u2014 mis seal muuta? T\u00f6\u00f6tab \u2014 \u00e4ra puutu. Praegu maailmas l\u00e4henemised muutuvad, ja see, mida nimetatakse Agile'iks, \u00fctleb, et l\u00f5pp-punkt B ei ole kohe n\u00e4ha.<\/p>\n

\"Mis
\n
\nKui ettev\u00f5te turul tegutseb ja klientidega t\u00f6\u00f6tab, uurib ta pidevalt turgu ja muudab oma l\u00f5pp-punkti B. Mida sagedamini ettev\u00f5te oma suunda muudab, seda edukam on ta l\u00f5ppkokkuv\u00f5ttes, sest ta valib rohkem turuni\u0161\u0161e.<\/p>\n

Strateegiat demonstreerib huvitav ettev\u00f5te, millest ma hiljuti kuulsin. One Box Shave on tellimusteenus, mis pakub raseerimisvahendite ja -tarvikute kojutoomist kastis. Neil on oskus kohandada oma \"kasti\" erinevate klientide jaoks. Sellega tegeleb kindel tarkvara, mis saadab tellimuse seej\u00e4rel Koreasse tehasesse, mis toodab kaupa.<\/p>\n

Selle toote ostis ettev\u00f5te Unilever 1 miljardi dollari eest. Praegu konkureerib see Gillette'iga ja on kaotanud sellelt m\u00e4rkimisv\u00e4\u00e4rse osa tarbijatest Ameerika turul. One Box Shave \u00fctleb:<\/p>\n

\u2014 4 teraga? Kas sa t\u00f5siselt? Miks teil seda vaja on \u2014 see ei paranda kuidagi raseerimise kvaliteeti. Eriline kreem, l\u00f5hnav ained ja kvaliteetne raseerija kahe teraga lahendavad palju rohkem k\u00fcsimusi kui need rumalad 4 teraga Gillette'id! Peagi j\u00f5uame 10 ni?<\/i><\/p>\n

Nii maailm muutub. Unilever teatab, et neil on uus IT-s\u00fcsteem, mis seda v\u00f5imaldab. L\u00f5ppkokkuv\u00f5ttes n\u00e4eb see v\u00e4lja nagu kontseptsioon. Turuletoomise aeg<\/b>, millest on r\u00e4\u00e4kinud juba mitmed.<\/p>\n

\"Mis
\n
\nTuruletoomise m\u00f5te ei ole selles, kui tihti me deploy'ime. Sageli v\u00f5ib deploy'ida, kuid see t\u00e4hendab, et v\u00e4ljaandmise ts\u00fcklid on pikad. Kui kolme kuu v\u00e4ljaandmise ts\u00fcklid \u00fcksteise peale panna, nihutades neid n\u00e4dalaks, tundub, et ettev\u00f5te nagu deploy'b kord n\u00e4dalas. Ent ideest l\u00f5pliku teostuseni kulub 3 kuud.<\/p>\n

Turuletoomine t\u00e4hendab ideest l\u00f5pliku teostuseni kulumise aja minimeerimist.<\/p><\/blockquote>\n

\nSellisel juhul suhtleb turuga tarkvara. N\u00e4iteks One Box Shave'il suhtleb kliendiga nende veebisait. Neil pole m\u00fc\u00fcgiinimesi - lihtsalt sait, kus k\u00fclastaja kl\u00f5psab ja j\u00e4tab soovid. Seega tuleb saidil pidevalt midagi uut avaldada, et seda vastavalt soovidele v\u00e4rskendada. N\u00e4iteks L\u00f5una-Koreas peetakse habet teistmoodi kui Venemaal, ja neile meeldib, et aroomiks pole m\u00e4nni l\u00f5hn, vaid n\u00e4iteks porgandi vanilje.<\/p>\n

Kuna on vajalik kiiresti muuta veebisaidi sisu, tarkvara arendus on muutunud. Tarkvara kaudu peame m\u00f5istma, mida klient soovib. Varem saime seda teada kaude, n\u00e4iteks \u00e4ri juhtimise kaudu. Siis kavandasime, seadsime n\u00f5uded IT-s\u00fcsteemi ja k\u00f5ik oli suurep\u00e4rane. Praegu on olukord teine - tarkvara kavandavad k\u00f5ik, kes on protsessis kaasatud, sealhulgas insenerid, kuna nad saavad tehniliste spetsifikatsioonide kaudu aru, kuidas turg t\u00f6\u00f6tab, ja jagavad oma teadmisi \u00e4ri poolega.<\/p>\n

N\u00e4iteks ettev\u00f5ttes Qik saime ootamatult teada, et inimestele meeldib v\u00e4ga laadida kontaktloendeid serverisse, ja nad andsid meile rakenduse. Alguses me sellele ei m\u00f5elnud. Klassikalises ettev\u00f5ttes oleks k\u00f5ik arvanud, et see on viga, kuna spetsifikatsioonis ei olnud \u00f6eldud, et see peaks h\u00e4sti t\u00f6\u00f6tama, ja seda oli \u00fcldse poolikult teostatud, oleks funktsiooni v\u00e4lja l\u00fclitatud ja \u00f6eldud: \"See ei ole kellelegi vajalik, peamine on see, et p\u00f5hifunktsionaalsus t\u00f6\u00f6tab\". Kuid tehnoloogiaettev\u00f5te n\u00e4eb selles v\u00f5imalust ja hakkab tarkvara vastavalt muutma.<\/p>\n

\"Mis
\n
\n1968. aastal kujundas ettevaatlik noormees Melvin Conway j\u00e4rgmise idee.<\/p>\n

Organisatsioon, mis loob s\u00fcsteemi, on piiratud disainiga, mis kopeerib selle organisatsiooni suhtluse struktuuri.<\/p><\/blockquote>\n

\nKuna s\u00fcsteemide tootmiseks, mis on erinevat t\u00fc\u00fcpi, peab ettev\u00f5ttel olema ka erinevat t\u00fc\u00fcpi suhtlusstruktuur. Kui teie suhtlusstruktuur on pealtn\u00e4ha hierarhiline, siis see ei v\u00f5imalda teil luua s\u00fcsteeme, mis suudavad tagada v\u00e4ga k\u00f5rge Time-to-market taseme.<\/p>\n

Lugege Conway seadusest<\/a><\/noindex> saab linkide kaudu<\/a><\/noindex>. See on oluline DevOpsi kultuuri v\u00f5i filosoofia m\u00f5istmiseks, kuna ainus, mis DevOpsis p\u00f5hjalikult muutub, on just suhtlus struktuur meeskondade vahel.<\/b>.<\/p>\n

Protsessi vaatenurgast toimusid enne DevOps'i k\u00f5ik etapid: anal\u00fc\u00fcs, arendamine, testimine, kasutusele v\u00f5tmine, j\u00e4rjestikku.\"Mis
\nDevOps'i juhul toimuvad k\u00f5ik need protsessid paralleelselt.<\/p>\n

\"Mis
\n
\nTime-to-market v\u00f5ib toimuda ainult nii. Inimestele, kes on t\u00f6\u00f6tanud vana protsessi juures, n\u00e4ib see m\u00f5nev\u00f5rra ulmeline ja \u00fcldiselt mitte just eriti meeldiv.<\/p>\n

Miks on DevOps vajalik?<\/h3>\n

\nDigitaalsete toodete arendamiseks<\/b>. Kui teie ettev\u00f5ttes pole digitaalset toodet, pole DevOps vajalik - see on v\u00e4ga oluline.<\/p>\n

DevOps \u00fcletab traditsioonilise tarkvaraarenduse piirangud.<\/b>. K\u00f5ik protsessid toimuvad selles samas ajas.<\/p>\n

Soolise keerukus suureneb.<\/b> Kui DevOps'i evangelistid r\u00e4\u00e4givad, et see teeb tarkvarade loomise lihtsamaks, on see vale.<\/p>\n

DevOps teeb k\u00f5ik vaid keerulisemaks.<\/p><\/blockquote>\n

\nKonverentsil Avalduskeskkonnas sai vaadata, kuidas Docker-konteinerit k\u00e4ivitada \u2013 see on peaaegu v\u00f5imatu \u00fclesanne. Keerukus muutub \u00e4\u00e4rmuslikuks, peate samal ajal mitme palliga jongleerima.<\/p>\n

DevOps muudab t\u00e4ielikult protsessi ja organisatsiooni ettev\u00f5ttes<\/b>\u00a0\u2013 t\u00e4psemalt, ei muuda DevOps, vaid digitaalne toode. Et j\u00f5uda DevOps'i, tuleb selle protsessi t\u00e4ielikult muuta.<\/p>\n

K\u00fcsimused spetsialistile<\/h3>\n

\nAga kuidas teil? K\u00fcsimused, mida saate endalt k\u00fcsida, t\u00f6\u00f6tades ettev\u00f5ttes ja arenedes spetsialistina.<\/p>\n

Kas teie ettev\u00f5ttel on digitaalsete toodete loomise strateegia?<\/b> Kui on - juba h\u00e4sti. See t\u00e4hendab, et teie ettev\u00f5te liigub DevOps'i suunas.<\/p>\n

Kas teie ettev\u00f5te juba loob digitaalset toodet?<\/b> See t\u00e4hendab, et saate astuda veel \u00fche sammu k\u00f5rgemale, tegeleda huvitavate asjadega \u2013 DevOpsi vaates j\u00e4lle. Just sellest vaatenurgast ma r\u00e4\u00e4gin.<\/p>\n

Kas teie ettev\u00f5te on \u00fcks digitaalsete toodete turuliidreid?<\/b> Spotify, Yandex, Uber \u2013 ettev\u00f5tted, mis hetkel asuvad tehnoloogia tipptaseme k\u00f5rval.<\/p>\n

Esitage endale need k\u00fcsimused ja kui k\u00f5ik vastused on negatiivsed, siis v\u00f5ib-olla ei tasu teil DevOpsiga selles ettev\u00f5ttes tegeleda. Kui aga DevOps teema t\u00f5eliselt huvitab, v\u00f5ib-olla... tuleks teil minna teise ettev\u00f5ttesse? Kui teie ettev\u00f5te soovib liikuda DevOpsi suunas, kuid te vastasite k\u00f5ikidele k\u00fcsimustele \"Ei\", siis meenutab see kaunist ninasarvikut, kes kunagi ei muutu.<\/p>\n

\"Mis
\n<\/p>\n

Organiseerimine<\/h2>\n

\nKuna ma olen juba \u00f6elnud, et Conway seaduse j\u00e4rgi muutub ettev\u00f5ttes organisatsioon. Alustan sellest, mis takistab DevOpsi sisemist juurdumist ettev\u00f5ttes just organisatsiooni vaatenurgast.<\/p>\n

Probleem \u201ekolled\u017eidest\u201c<\/h3>\n

\nInglise s\u00f5na \u201eSilo\u201c on siin t\u00f5lgitud vene keelde kui \u201ekolled\u017e\u201c. Selle probleemi m\u00f5te seisneb selles, et tiimide vahel pole teabevahetust.<\/b>. Iga meeskond s\u00fcveneb oma ekspertiisi, samas luues \u00fchist kaarti, mille j\u00e4rgi orienteeruda.<\/p>\n

See meenutab inimest, kes just saabus Moskvasse ja ei oska veel metroo kaartil orienteeruda. Moskvalased tunnevad oma piirkonda tavaliselt v\u00e4ga h\u00e4sti, kuid Moskvasse orienteeruvad nad metroo kaardi j\u00e4rgi. Kui sa j\u00f5uad Moskvasse esmakordselt, pole seda oskust ja oled t\u00e4iesti desorienteeritud.<\/p>\n

DevOps pakub v\u00f5imalust seda desorientatsiooni hetke \u00fcletada ning k\u00f5igil osakondadel koos luua \u00fchine suhtlemiskaart.<\/p><\/blockquote>\n

\nSellele takistavad kaks tegurit.<\/p>\n

Tulemuseks on ettev\u00f5tte juhtimiss\u00fcsteem.<\/b> See on \u00fcles ehitatud eraldi hierarhiliste 'kaevudena'. N\u00e4iteks on teatud KPI-d ettev\u00f5tetes, mis toetavad seda s\u00fcsteemi. Teiselt poolt takistavad seda inimeste m\u00f5tlemine, kellel on raske oma ekspertiisi piire \u00fcletada ja s\u00fcsteemi \u00fcldiselt orienteeruda. See on lihtsalt ebamugav. Kujutage ette, et olete Bangkokis lennujaamas \u2014 seal ei orienteeru kiiresti. DevOpsis on samuti keeruline orienteeruda, seet\u00f5ttu \u00fctlevad inimesed, et on vaja leida juht, et sinna j\u00f5uda.<\/p>\n

Kuid k\u00f5ige olulisem on see, et \u00abkaevude\u00bb probleem insenerile, kes on DevOps'i vaimu sisse elanud, lugenud Fowlerit ja palju teisi raamatuid, v\u00e4ljendub selles, et \u00abkaevud\u00bb ei v\u00f5imalda teha \u00abilmselgeid\u00bb asju.<\/b>Me koguneme sageli p\u00e4rast DevOps Moscow't, r\u00e4\u00e4gime omavahel ja inimesed kurdavad:<\/p>\n

\u2014 Me tahtsime lihtsalt CI k\u00e4ivitada, aga selgus, et juhtkonnale see ei sobi.<\/i><\/p>\n

See toimub just seet\u00f5ttu, et\u00a0CI <\/b>ja\u00a0Continuous Delivery process<\/b> asuvad paljude teadmiste piiril. Lihtsalt kaevude probleemi \u00fcletamata organisatsioonilisel tasandil ei saa edasi liikuda, \u00fcksk\u00f5ik mida te ka ei teeks ja kui kurb see ka ei oleks.<\/p>\n

\"Mis
\n
\nIga protsessis osaleja ettev\u00f5ttes: tagasisuunajate ja esitusn\u00f5ustajate arendajad, testimine, DBA, haldamine, v\u00f5rk, kaevandab oma suunas, kuid \u00fcldist kaarti ei oma keegi peale juhtkonna, kes neid kuidagi vaatab ja juhib meetodiga \u00abjaga ja valitse\u00bb.<\/p>\n

Inimesed v\u00f5itlevad mingite t\u00e4histe v\u00f5i lippude nimel, iga\u00fcks kaevandab oma ekspertteadmisi.<\/p><\/blockquote>\n

\nKokkuv\u00f5ttes, kui \u00fclesanne on k\u00f5ik see koos siduda ja luua \u00fchine t\u00f6\u00f6voog, ning t\u00e4hed ja lipud enam ei h\u00e4iri, tekib k\u00fcsimus \u2013 mida siis \u00fcldse teha? Peame kuidagi kokku leppima, aga kuidas seda teha, meid koolis ei \u00f5petatud. Oleme juba koolist harjunud: kaheksas klass - ohhoo! - v\u00f5rreldes seitsmenda klassiga! Siin on sama moodi.<\/p>\n

Kas teie ettev\u00f5ttes on samuti?<\/h3>\n

\nSelle kontrollimiseks v\u00f5ib endalt esitada j\u00e4rgmised k\u00fcsimused.<\/p>\n

Kas meeskonnad kasutavad \u00fchiseid t\u00f6\u00f6riistu, kas nad panustavad nende \u00fchiste t\u00f6\u00f6riistade muutmisse?<\/p>\n

\u041d\u0430\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0447\u0430\u0441\u0442\u043e \u043a\u043e\u043c\u0430\u043d\u0434\u044b \u043f\u0435\u0440\u0435\u0444\u043e\u0440\u043c\u0438\u0440\u0443\u044e\u0442\u0441\u044f\u00a0\u2014 \u043e\u0434\u043d\u0438 \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0441\u0442\u044b \u0438\u0437\u00a0\u043e\u0434\u043d\u043e\u0439 \u043a\u043e\u043c\u0430\u043d\u0434\u044b \u043f\u0435\u0440\u0435\u0445\u043e\u0434\u044f\u0442 \u0432\u00a0\u0434\u0440\u0443\u0433\u0443\u044e \u043a\u043e\u043c\u0430\u043d\u0434\u0443?<\/b> \u0418\u043c\u0435\u043d\u043d\u043e \u0432\u00a0DevOps-\u0441\u0440\u0435\u0434\u0435 \u044d\u0442\u043e \u0441\u0442\u0430\u043d\u043e\u0432\u0438\u0442\u0441\u044f \u043d\u043e\u0440\u043c\u0430\u043b\u044c\u043d\u044b\u043c, \u043f\u043e\u0442\u043e\u043c\u0443 \u0447\u0442\u043e \u0438\u043d\u043e\u0433\u0434\u0430 \u0447\u0435\u043b\u043e\u0432\u0435\u043a \u043f\u0440\u043e\u0441\u0442\u043e \u043d\u0435\u00a0\u043c\u043e\u0436\u0435\u0442 \u043f\u043e\u043d\u044f\u0442\u044c, \u0447\u0435\u043c \u0437\u0430\u043d\u0438\u043c\u0430\u0435\u0442\u0441\u044f \u0434\u0440\u0443\u0433\u0430\u044f \u0437\u043e\u043d\u0430 \u044d\u043a\u0441\u043f\u0435\u0440\u0442\u0438\u0437\u044b. \u041e\u043d\u00a0\u043f\u0435\u0440\u0435\u0445\u043e\u0434\u0438\u0442 \u0432\u00a0\u0434\u0440\u0443\u0433\u043e\u0439 \u043e\u0442\u0434\u0435\u043b, \u0434\u0432\u0435 \u043d\u0435\u0434\u0435\u043b\u044c\u043a\u0438 \u0442\u0430\u043c \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442, \u0447\u0442\u043e\u0431\u044b \u0441\u043e\u0437\u0434\u0430\u0442\u044c \u0434\u043b\u044f \u0441\u0435\u0431\u044f \u043a\u0430\u0440\u0442\u0443 \u043e\u0440\u0438\u0435\u043d\u0442\u0430\u0446\u0438\u0438 \u0438\u00a0\u0432\u0437\u0430\u0438\u043c\u043e\u0434\u0435\u0439\u0441\u0442\u0432\u0438\u044f \u0441\u00a0\u044d\u0442\u0438\u043c \u043e\u0442\u0434\u0435\u043b\u043e\u043c.<\/p>\n

Kas on v\u00f5imalik luua muudatuskomitee ja midagi muuta? <\/b>V\u00f5i on selleks vajalik k\u00f5rgeima juhtkonna tugev k\u00e4si ja korraldus? Hiljuti kirjutasin Facebookis, kuidas \u00fcks v\u00e4he tuntud pank korralduste kaudu t\u00f6\u00f6riistu rakendab: kirjutatakse korraldus, aasta rakendatakse, vaadatakse, mis juhtub. See on muidugi pikk ja kurb protsess.<\/p>\n

Kui oluline on juhtide jaoks saada isiklikke saavutusi, arvestamata ettev\u00f5tte saavutusi? <\/b><\/p>\n

Kui vastate endale nendele k\u00fcsimustele, siis on selgem, kas teil on ettev\u00f5ttes selline probleem.<\/p>\n

Infrastruktuur kui kood<\/h2>\n

\nP\u00e4rast seda, kui see probleem on lahendatud, on esimene oluline praktika, milleta DevOps'is edasi liikumine on keeruline \u2014 see on infrastruktuur kui kood<\/b>. <\/p>\n

K\u00f5ige sagedamini m\u00f5istetakse infrastruktuuri kui koodi nii:<\/p>\n

\u2014 Automatiseerime k\u00f5ik bash'is, m\u00e4\u00e4ritame end skriptidega, et adminni t\u00f6\u00f6 oleks v\u00e4hem k\u00e4sitsi!<\/i><\/p>\n

Aga see pole nii.<\/p>\n

Infrastruktuur kui kood t\u00e4hendab, et IT-s\u00fcsteemi, millega t\u00f6\u00f6tate, kirjeldatakse koodina, et pidevalt m\u00f5ista selle seisundit.<\/p><\/blockquote>\n

\nKoost\u00f6\u00f6s teiste meeskondadega loote kaardi koodivormingus, mis on k\u00f5igile arusaadav ja mille j\u00e4rgi saab orienteeruda ja navigeerida. Pole oluline, millest see on tehtud \u2014 Chef, Ansible, Salt, v\u00f5i kasutatakse YAML-faile Kubernetes'is \u2014 ei ole vahet.<\/p>\n

Konverentsil r\u00e4\u00e4kis kolleeg 2GIS-ist, kuidas nad l\u00f5id oma sisemise lahenduse Kubernetes'i jaoks, mis kirjeldab \u00fcksikute s\u00fcsteemide \u00fclesehitust. 500 s\u00fcsteemi kirjeldamiseks vajasid nad eraldi t\u00f6\u00f6riista, mis selle kirjelduse genereerib. Kui see kirjeldus on olemas, saavad k\u00f5ik \u00fcksteisega v\u00f5rrelda, j\u00e4lgida muudatusi ning m\u00f5ista, kuidas seda muuta ja t\u00e4iustada, mida puudu on. <\/p>\n

Kokkuleppel, eraldi bash-skriptid ei anna tavaliselt seda arusaamist. \u00dches ettev\u00f5ttes, kus ma t\u00f6\u00f6tasin, oli isegi nimeks \"write only\"-skript \u2013 kui skript on kirjutatud, siis ei ole seda enam v\u00f5imalik lugeda. Arvan, et see on teilegi tuttav.<\/p>\n

Infrastruktuur koodina \u2013 see on kood, mis kirjeldab infrastruktuuri tegelikku seisundit<\/b>. Selle koodiga t\u00f6\u00f6tab \u00fchiselt mitmeid toote-, infrastruktuuri- ja teenindusmeeskondi ning mis k\u00f5ige t\u00e4htsam, k\u00f5ik nad peavad aru saama, kuidas see kood \u00fcldse t\u00f6\u00f6tab.<\/p>\n

Kood j\u00e4rgib parimaid praktikaid koodiga t\u00f6\u00f6tamisel.<\/b>: koost\u00f6\u00f6arendamine, koodikontroll, XP-programmeerimine, testimine, pull-requestid, CI koodiinfrastruktuuride jaoks \u2014 see k\u00f5ik on kasulik ja kasutatav.<\/p>\n

Kood muutub k\u00f5igi inseneride \u00fchise keelena.<\/p><\/blockquote>\n

\nInfrastruktuuri muutmine koodis ei v\u00f5ta palju aega.<\/b>. Jah, ka infrastruktuurikoodis v\u00f5ib olla tehnilist v\u00f5lga. T\u00fc\u00fcpiliselt seisavad meeskonnad silmitsi sellega umbes poolteise aasta p\u00e4rast seda, kui nad on hakanud rakendama 'infrastruktuuri kui koodi' hulgana skripte v\u00f5i isegi Ansible'i, mida nad kirjutavad nagu spagetikood ja lisavad sinna veel bash-skripte! <\/p>\n

Oluline<\/b>: kui te pole seda veel proovinud, pidage meeles, et Ansible ei ole bash<\/b>! K\u00f5igepealt lugege hoolikalt dokumentatsiooni, uurige, mida selle kohta \u00fcldse kirjutatakse.<\/p>\n

Infrastruktuur kui kood t\u00e4hendab infrastruktuurikoodi jagamist eraldi kihtideks.<\/p><\/blockquote>\n

\nMeie ettev\u00f5ttes m\u00e4\u00e4ratleme kolm p\u00f5hikihti, mis on v\u00e4ga arusaadavad ja lihtsad, kuid neid v\u00f5ib olla rohkem. Saate vaadata oma infrastruktuuri koodi ja \u00f6elda, kas teil on see tingimus v\u00f5i mitte. Kui \u00fchtegi kihti ei m\u00e4\u00e4ratleta, tuleb leida aega ja teha natuke refaktoreerimist.
\n\"Mis
\n
\nP\u00f5hikih<\/b>\u00a0\u2014 see on nagu operatsioonis\u00fcsteemi seadistamine, varukoopiad ja muud madalamal tasemel asjad, n\u00e4iteks kuidas Kubernetes baasv\u00e4lja m\u00e4\u00e4rata.<\/p>\n

Teenuste tase<\/b>\u00a0\u2014 need on teenused, mida te arendajale pakute: logimine teenusena, monitooring teenusena, andmebaas teenusena, koormuse tasandaja teenusena, j\u00e4rjekord teenusena, pidev tarnimine teenusena \u2014 hulk teenuseid, mida eri meeskonnad saavad arendusele pakkuda. K\u00f5ik need tuleb teie konfiguratsiooni halduss\u00fcsteemis eraldi moodulitena kirjeldada.<\/p>\n

Kiht, kus rakendused luuakse<\/b> ja kirjeldatakse, kuidas need kahel eelpool nimetatud kihil v\u00e4lja on arendatud.<\/p>\n

Kontrollk\u00fcsimused<\/h3>\n

\nKas teie ettev\u00f5ttel on \u00fchine infrastruktuurihoidla? Kas te haldate infrastruktuuri tehnilist v\u00f5lga? Kas te rakendate arenduspraktikaid infrastruktuuri hoidlas? Kas teie infrastruktuur on kihiti jagatud? V\u00f5ite viidata Base-service-APP skeemile. Kui keeruline on muudatusi teha? <\/p>\n

Kui olete kokku puutunud olukorraga, kus muudatuste tegemine v\u00f5ttis poolteist p\u00e4eva, siis t\u00e4hendab see, et teil on tekkida saanud tehniline v\u00f5lg, mille kallal on vaja t\u00f6\u00f6tada. Teatud on, et olete komistanud infrastruktuurikoodi tehnilise v\u00f5la kuristikku. M\u00e4letan palju selliseid juhtumeid, kus mingite CCTL muutmine n\u00f5udis poolte infrastruktuuri koodi \u00fcmberkirjutamist, kuna loovus ja soov k\u00f5ik automatiseerida viisid selleni, et k\u00f5ik on ummistunud, k\u00f5ik juhtmed on eemaldatud ja see vajab refaktooringut.<\/p>\n

J\u00e4tkuv tarnimine<\/h2>\n

\nK\u00e4ime l\u00e4bi deebetkrediidiga. Esiteks antakse \u00fclevaade infrastruktuurist, mis v\u00f5ib olla \u00fcsna p\u00f5hiline. Pole tingimata vajalik k\u00f5ike \u00fcksikasjalikult kirjeldada, kuid mingist p\u00f5hikirjelduse olemasolu on vajalik, et saaksite sellega t\u00f6\u00f6tada. Vastasel juhul ei ole selge, mille peal edasi pidevat tarnimist teha. K\u00f5ik need praktikad k\u00e4ivad k\u00e4sik\u00e4es, kui j\u00f5uate DevOpsini, kuid alustamiseks peab m\u00f5istma, mis teil on ja kuidas sellega hallata. See on just praktikaks infrastruktuuri kui koodi.<\/p>\n

P\u00e4rast seda, kui on arusaadav, mis teil on ja kuidas sellega hallata, hakkate v\u00e4lja m\u00f5tlema, kuidas arendaja koodi v\u00f5imalikult kiiresti tootmisse saata. Ma m\u00f5tlen koos arendajaga \u2013 peame meeles probleemi, et \u201ekaevud\u201d ei ole sellised, et eraldi inimesed seda v\u00e4lja m\u00f5tleksid, vaid kogu meeskonna koost\u00f6\u00f6s.<\/p>\n

Kui me\u00a0Vaneja Jevtuhovi\u010diga<\/b> n\u00e4gime esimest raamatut Jez Hambula<\/b> ja autorite r\u00fchma \u00abContinuous Delivery\u00bb<\/b>, mis k\u00e4idi v\u00e4lja 2009. aastal, m\u00f5eldi kaua, kuidas t\u00f5lkida selle pealkiri eesti keelde. Soovisime t\u00f5lkida kui \"Alati toimetama\", aga kahjuks t\u00f5lgiti kui \"J\u00e4tkuv tarnimine\". Tundub, et meie pealkirjas on midagi venekeelset, millega on seotud kindel tahe.<\/p>\n

Alati toimetama \u2014 see t\u00e4hendab<\/h3>\n

\nKood, mis asub tootehoidlas, v\u00f5ib alati minna tootmisse<\/b>. See v\u00f5ib olla ka mitte v\u00e4lja viidud, kuid on alati selleks valmis. Seet\u00f5ttu kirjutate alati koodi teatud seletamatu \u00e4revustunde saatel. See tunne tekib sageli, kui t\u00f5state infrastruktuurikoodi. See teatud \u00e4revus peaks olema kohal \u2014 see kutsub esile m\u00f5tteprotsesse, mis aitavad kirjutada koodi veidi teistsuguselt. See peaks olema fikseeritud arendusreeglites.<\/p>\n

Alati toimetamiseks on vajalik artefakti formaat, mis l\u00e4bib infrastruktuuriplatvormi. <\/b>Kui te viskate erineva formaadi \"elutoas aitavaid\" j\u00e4\u00e4ke infrastruktuursele platvormile, siis see muutub teie jaoks mitte\u00fchtseks, seda on keeruline hooldada ja tekib tehnilise v\u00f5la probleem. Artefakti vorm tuleb \u00fchtlustada \u2014 see on ka kollektiivne \u00fclesanne: tuleb k\u00f5ik koos kokku tulla, m\u00f5tiskleda ja v\u00e4lja m\u00f5elda see formaat.<\/p>\n

Artefakti t\u00e4iustatakse pidevalt ning see muutub tootmiskeskkonna j\u00e4rgi, kui see liigub tarnimise torustiku kaudu. <\/b>Kui artefakt liigub torustikus, siis ta pidevalt kohtub mingite ebamugavate asjadega, mis sarnanevad sellele, millega seisab silmitsi artefakt, mille te tootmisse viite. Kui klassikalises arenduses tegeleb sellega s\u00fcsteemihaldur, kes teeb v\u00e4ljalaskmist, siis DevOps-protsessis toimub see pidevalt: seal on teda katsetega keerutatud, siin on ta visatud Kubernetes-klastrisse, mis on enam-v\u00e4hem sarnane tootmisele, ja siis j\u00e4rsku k\u00e4ivitatakse koormustestimine.<\/p>\n

See on midagi sarnast Pac-Man m\u00e4nguga \u2014 artefakt l\u00e4bib teatud loo. Oluline on j\u00e4lgida, kas kood t\u00f5esti j\u00e4rgib lugu ja kas see on seotud teie tootmisega. Toote lood saab integreerida pideva kohaletoimetamise protsessi: varem juhtus midagi h\u00e4da, n\u00fc\u00fcd programmeerime selle stsenaariumi lihtsalt s\u00fcsteemi. Iga kord, kui kood seda stsenaariumi l\u00e4bib, ei puutu te selle probleemiga enam kokku j\u00e4rgmine kord. Te saate sellest teada palju kiiremini, kui see j\u00f5uab teie kliendini.<\/p>\n

Erinevad juurutamisstrateegiad. <\/b>N\u00e4iteks kasutate AB-testimist v\u00f5i kanarode juurutamisi, et eri klientidel koodi erinevalt \"katsetada\", teades, kuidas kood t\u00f6\u00f6tab, ja seda palju varem, kui see j\u00f5uab 100 miljoni kasutajani.<\/p>\n

\"Pidev kohaletoimetamine\" n\u00e4eb v\u00e4lja nii.<\/p>\n

\"Mis
\n<\/p>\n

Tootmisprotsess Dev, CI, Test, PreProd, Prod \u2014 see ei ole eraldi keskkond, vaid etapid v\u00f5i jaamad, mille kaudu teie artefakt liigub.<\/p><\/blockquote>\n

\nKui teil on infrastruktuuri kood, mis on kirja pandud Base Service APP-ina, siis see aitab mitte unustada k\u00f5iki stsenaariume.<\/b>, ja\u00a0salvestada need\u00a0ka\u00a0koodi kujul selle objekti jaoks, edendada objekti<\/b> ja\u00a0muuta seda\u00a0protsessi k\u00e4igus.<\/p>\n

Enesehinnanguks k\u00fcsimused<\/h3>\n

\nKas funktsiooni kirjeldamisest kuni tootmisseviimiseni kulub 95% juhtudest v\u00e4hem kui n\u00e4dal? Kas objekti kvaliteet paraneb igas etapis toimeprotsessis? Kas sellel on ajalugu, mille kaudu see l\u00e4bib? Kas kasutate erinevaid rakendamisstrateegiaid?<\/p>\n

Kui k\u00f5ik vastused on jah, siis olete te uskumatu! Kirjutage vastused kommentaaridesse - mul oleks r\u00f5\u00f5m).<\/p>\n

Tagasiside<\/h3>\n

\nSee on k\u00f5ige keerulisem praktika k\u00f5igist. DevOpsConf'i konverentsil r\u00e4\u00e4kis kolleeg Infobipist sellest ja segas end veidi s\u00f5nades, sest see on t\u00f5epoolest v\u00e4ga keeruline praktika, mis k\u00e4sitleb seda, et tuleb j\u00e4lgida t\u00f5eliselt k\u00f5ike!<\/p>\n

\"Mis
\n
\nN\u00e4iteks, kaua aega tagasi, kui t\u00f6\u00f6tasin Qik'is ja me m\u00f5istsime, et tuleb j\u00e4lgida t\u00f5eliselt k\u00f5ike. Me tegime seda ja meie Zabbix'is oli 150 000\u00a0objekti, mida j\u00e4lgiti pidevalt. See oli hirmutav, tehniline direktor keerutas s\u00f5rme oma lasku:<\/p>\n

\u2014\u00a0Kutsikad, miks te\u00a0serverit niimoodi m\u00f5ttetult piinate?<\/i><\/p>\n

Aga siis juhtus juhus, mis n\u00e4itas, et see on t\u00f5eliselt \u00e4ge strateegia.<\/p>\n

\u00dcks teenus hakkas pidevalt kokku kukkuma. Alguses see ei kukkunud, huvitav on see, et sinna ei kirjutatud uut koodi, kuna see oli p\u00f5hiline broker, kus praktiliselt ei olnud \u00e4rifunktsionaalsust \u2014 see lihtsalt edastas s\u00f5numeid erinevate teenuste vahel. Teenus ei olnud muutunud 4 kuu jooksul ja \u00e4kki hakkas see kukkuma veaga \u00abSegmentation fault\u00bb.<\/p>\n

Olimme \u0161okis, avasime meie Zabbix'i grafi ja selgus, et poolteist n\u00e4dalat tagasi olid API-teenuse p\u00e4ringute k\u00e4itumine tugevalt muutunud, mis kasutab seda brokereid. Edasi vaatasime, et teatud t\u00fc\u00fcpi s\u00f5numite saatmise sagedus oli muutunud. Hiljem sai selgeks, et need on android-klientide p\u00e4ringud. K\u00fcsisime:<\/p>\n

\u2014 Poisid, mis teiega poolteist n\u00e4dalat tagasi juhtus?<\/i><\/p>\n

Vastas kuuldi huvitavat lugu sellest, kuidas nad kasutajaliidest uuendasid. Raske on kohe \u00f6elda, et nad muutsid HTTP-raamatukogu. Androidi klientidele on see nagu seepi vahetada vannitoas \u2013 nad lihtsalt ei m\u00e4leta seda. L\u00f5puks, p\u00e4rast 40 minutit vestlust, selgus, et nad t\u00f5epoolest vahetasid HTTP-raamatukogu ja sellel muutusid vaikeseaded. See t\u00f5i kaasa muudatused API serveri liikluse k\u00e4itumises, mis omakorda viis olukorrani, mis p\u00f5hjustas v\u00f5istluse brokera sees, mille t\u00f5ttu ta hakkas kokku kukkuma.<\/p>\n

Ilma s\u00fcvamonitorimiseta on seda \u00fcldse v\u00f5imatu avastada.<\/b>. Kui organisatsioonis on veel probleem \u201ekaevude\u201d osas, kus k\u00f5ik liigutavad vastutust \u00fcksteisele, v\u00f5ib see kesta aastaid. Sa lihtsalt taask\u00e4ivitad serveri, sest probleemi lahendamine on v\u00f5imatu. Kui sa j\u00e4lgid, monitoorid ja j\u00e4lgid k\u00f5iki s\u00fcndmusi, mis sul on, ning kasutad monitooringut testimise viisina \u2013 kirjutad koodi ja kohe n\u00e4itad, kuidas seda monitoorida, samuti koodina (meil on juba infrastruktuur koodina), siis k\u00f5ik saab selgeks nagu peopesa peal. Ieven sellised keerulised probleemid on kergesti j\u00e4lgitavad.<\/p>\n

\"Mis
\n<\/p>\n

Koguge kogu teavet selle kohta, mis toimub artefaktiga iga etapi jooksul tarneprotsessis \u2014 mitte tootmisel.<\/p><\/blockquote>\n

\nLaadige j\u00e4lgimine CI-sse, seal saate juba n\u00e4ha m\u00f5ned p\u00f5hiasjad. Edasi n\u00e4ete neid nii Testis, PredProd-s kui ka koormustestimisel. Koguge teavet k\u00f5igil etappidel, mitte ainult m\u00f5\u00f5dikute, statistika, vaid ka logide osas: kuidas rakendus v\u00e4lja lasti, anomaaliad \u2014 koguge k\u00f5ik. <\/p>\n

Vastasel juhul on keeruline aru saada. Olen juba \u00f6elnud, et DevOps on suurem keerukus. Selle keerukusega toimetulemiseks on vajalik omada head anal\u00fc\u00fctikat.<\/b>.<\/p>\n

Enesekontrolli k\u00fcsimused<\/h3>\n

\nKas teie j\u00e4lgimine ja logimine on teie jaoks arendust\u00f6\u00f6riist?<\/b> Kas teie arendajad, sealhulgas teie ise, m\u00f5tlevad koodi kirjutades sellele, kuidas seda j\u00e4lgida?<\/p>\n

Kas saate probleemidest teada klientidelt? Kas m\u00f5istate klienti paremini j\u00e4lgimise ja logimise kaudu?<\/b> Kas m\u00f5istate s\u00fcsteemi paremini j\u00e4lgimise ja logimise kaudu?<\/b> Kas muudate s\u00fcsteemi lihtsalt seet\u00f5ttu, et n\u00e4ete, et s\u00fcsteemi trend kasvab ja m\u00f5istate, et veel 3 n\u00e4dalat ja k\u00f5ik kukub kokku? <\/p>\n

Kui teil on need kolm komponenti, v\u00f5ite m\u00f5elda, milline infrastruktuuri platvorm teil on ettev\u00f5ttes.<\/p>\n

Infrastruktuuri platvorm <\/h2>\n

\nM\u00f5te ei ole selles, et see on hulk lahusolevaid t\u00f6\u00f6riistu, mis on igas ettev\u00f5ttes olemas.<\/p>\n

Infrastruktuuri platvormi m\u00f5te on see, et k\u00f5ik meeskonnad kasutavad neid t\u00f6\u00f6riistu ja arendavad neid koos.<\/p><\/blockquote>\n

\nSelge on, et on eraldi meeskonnad, kes vastutavad infrastruktuuri platvormi eraldi osade arendamise eest. Kuid vastutus arendamise, t\u00f6\u00f6kindluse ja infrastruktuuri platvormi edendamise eest lasub igal inseneril. Sisemiselt muutub see \u00fcldiseks t\u00f6\u00f6riistaks<\/b>. <\/p>\n

K\u00f5ik meeskonnad arendavad infrastruktuuri platvormi, k\u00e4itudes selle suhtes hoolikalt nagu omaenda IDE-de vastu.<\/b>. Oma IDE-s seadistate erinevaid pluginaid, et k\u00f5ik oleks ilus ja kiire, kohandate otseteid. Kui avate Sublime'i, Atomi v\u00f5i Visual Studio Code'i, sadavad teile koodivead ja te saate aru, et on t\u00e4iesti v\u00f5imatu t\u00f6\u00f6tada, tunnete kohe kurbust ja jooksete oma IDE-d parandama.<\/p>\n

Suhtuge oma infrastruktuuri platvormi sama t\u00f5siselt. Kui te m\u00f5istate, et midagi on valesti, siis esitage taotlus, kui te ei suuda seda ise parandada. Kui probleem on aga lihtne, parandage see ise ja saatke pull request \u2014 arendajad vaatavad selle \u00fcle ja lisavad. See on erinev l\u00e4henemine arendaja t\u00f6\u00f6riistadele.<\/p>\n

Infrastruktuuri platvorm tagab artefakti \u00fclekande arendusest kliendini, pideva kvaliteedi parandamisega.<\/b>. Infrastruktuuri platvormil on programmeeritud hulk lugusid, mis juhtuvad koodiga tootmises. Aastate jooksul on nendest lugudest saanud v\u00e4ga palju, osa neist on unikaalsed ja seotud ainult teiega \u2014 neid ei ole v\u00f5imalik Google'ist leida. <\/p>\n

Sel hetkel muutub infrastruktuuri platvorm teie konkurentsieeliseks<\/b>, sest selles on sisse kodeeritud midagi, mida konkurendi t\u00f6\u00f6riistadel ei ole. Mida s\u00fcgavam on teie infrastruktuuri platvorm, seda suurem on teie konkurentsieelis Time-to-market osas. Siin kerkib esile vendor lock probleem.<\/b>: saate endale v\u00f5tta kellegi teise platvormi, kuid kasutades kellegi teise kogemust, ei saa te aru, kui asjakohane see teie jaoks on. Jah, mitte iga ettev\u00f5te ei saa \u00fcles ehitada Amazoni t\u00fc\u00fcpi platvormi. See on keeruline piiri\u00fclene asi, kus ettev\u00f5tte kogemus on seotud selle turupositsiooniga, ja sinna ei tohi lubada vendor lock'i. Sellele on samuti oluline m\u00f5elda.<\/p>\n

Skeem<\/h3>\n

\nSee on infrastruktuuri platvormi p\u00f5hiskeem, mis aitab teil seadistada k\u00f5ik praktikas ja protsessides DevOps ettev\u00f5ttes.<\/p>\n

\"Mis
\n
\nVaatame, millest see koosneb.<\/p>\n

Ressursside orkestreerimise s\u00fcsteem<\/b>, mis pakub rakendustele ja teistele teenustele CPU-d, m\u00e4lu, kettaruumi. Selle peal on madala taseme teenused<\/b>: j\u00e4lgimine, logimine, CI\/CD mootor, artefaktide ladustamine, infrastruktuur kui kood.<\/p>\n

K\u00f5rgema taseme teenused<\/b>: andmebaas kui teenus, j\u00e4rjekorrad kui teenus, Load Balance kui teenus, piltide suuruse muutmine kui teenus, Big Data tehas kui teenus. Selle peal on torujuhe, mis edastab pidevalt muudetud koodi teie kliendile.<\/b>.<\/p>\n

Te saate teavet selle kohta, kuidas teie tarkvara kliendil t\u00f6\u00f6tab, muudate, uuesti tarnite selle koodi, saate teavet \u2014 ning nii arendate pidevalt nii infrastruktuuri platvormi kui ka teie tarkvara.<\/p>\n

Kujundusel koosneb kohaletoimetamise torustik mitmest etapist. Kuid see on p\u00f5him\u00f5tteline skeem, mis on toodud n\u00e4itena \u2014 ei pea seda t\u00e4pselt kordama. Etapid suhtlevad teenustega nagu teenustega \u2014 iga platvormi ehitis kannab oma ajalugu: kuidas ressursse eraldatakse, kuidas rakendus k\u00e4ivitub, t\u00f6\u00f6tab ressurssidega, j\u00e4lgitakse, muudetakse.<\/p>\n

Oluline on m\u00f5ista, et iga platvormi osa kannab ajalugu, ja k\u00fcsida endalt \u2014 millist ajalugu kannab see element, v\u00f5ib-olla tasub see v\u00e4lja vahetada ja asendada kolmanda osapoole teenusega. N\u00e4iteks, kas v\u00f5iksime selle kivi asemel kasutada Okmeter'i? V\u00f5ib-olla on nad juba selle ekspertiisi palju paremini \u00fcles ehitanud kui meie. Aga v\u00f5ib-olla mitte \u2014 v\u00f5ib-olla on meil ainulaadne ekspertiis, peame kasutama Prometheuse ja seda edasi arendama.<\/p>\n

Platvormi loomine<\/h3>\n

\nSee on keeruline kommunikatsiooniprotsess. Kui teil on p\u00f5hipraktikad paigas, alustate suhtlemist erinevate inseneride ja spetsialistidega, kes t\u00f6\u00f6tavad v\u00e4lja n\u00f5udmisi ja \u0441\u0442\u0430\u043d\u0434\u0430\u0440te ning muudavad neid pidevalt vastavalt erinevatele t\u00f6\u00f6riistadele ja l\u00e4henemisviisidele. Siin on oluline kultuur, mis on DevOps-is.<\/p>\n

\"Mis
\nKultuuriga on k\u00f5ik v\u00e4ga lihtne \u2014 see on koost\u00f6\u00f6 ja suhtlemine<\/b>, see t\u00e4hendab soov t\u00f6\u00f6tada \u00fchiselt, jagada sama t\u00f6\u00f6riista. Siin ei ole midagi keerulist \u2014 k\u00f5ik on v\u00e4ga lihtne ja tavaline. N\u00e4iteks elame k\u00f5ik trepikojas ja hoiame selle puhtana \u2014 see on kultuuri tase.<\/p>\n

Ja kuidas on teil?<\/h3>\n

\nJ\u00e4lle k\u00fcsimused, mida v\u00f5ite endalt k\u00fcsida.<\/p>\n

Kas infrastruktuuri platvorm on eraldatud? Kes vastutab selle arengu eest? Kas te m\u00f5istate oma infrastruktuuri platvormi konkurentsieeliseid?<\/p>\n

Nendele k\u00fcsimustele tuleb pidevalt vastuseid otsida. Kui midagi saab v\u00e4listeenustele \u00fcle anda \u2014 tuleks seda teha, ja kui v\u00e4line teenus hakkab teie edasiviimist takistama, tuleb s\u00fcsteem endas \u00fcles ehitada.<\/p>\n

\u0418\u0442\u0430\u043a, DevOps…<\/h2>\n

\n\u2026 see on keeruline s\u00fcsteem, kus peavad olema:<\/p>\n