{"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":"

DevOps'i m\u00e4\u00e4ratlemine on v\u00e4ga keeruline, mist\u00f5ttu tuleb seda igal korral uuesti arutada. Ainult Habr'ist leiate tuhandeid selle teema avaldusi. Kuid kui te seda loete, siis teate kindlasti, mis on DevOps. Sest mina - ei tea. Tere, minu nimi on Aleksandr Titov (@osminog<\/a><\/noindex><\/b>), ja me r\u00e4\u00e4gime lihtsalt DevOps'ist ja jagan oma kogemusi.<\/p>\n

\"Mis
\n
\nOlin pikka aega m\u00f5elnud, kuidas muuta oma jutt kasulikuks, seega on siin palju k\u00fcsimusi - neid, mida ma endale esitan, ja neid, mida esitan meie ettev\u00f5tte klientidele. Neile k\u00fcsimustele vastates saavad arusaamad selgemaks. R\u00e4\u00e4gin, miks on DevOps vajalik minu vaatenurgast, mis see on, j\u00e4lle minu positsioonist, ja kuidas m\u00f5ista, kas teie ettev\u00f5te liigub taas DevOps'i suunas minu vaatenurgast. Viimane punkt tuleb k\u00fcsimuste kaudu. Vastates neile endale, saate aru, kas teie ettev\u00f5te liigub DevOps'i suunas v\u00f5i on milleski probleeme.
\n<\/a><\/noindex>
\n

\r\n \"M\u00e4ngi\r\n
<\/div>\r\n <\/div><\/center>
\nMingil ajal navigeerisin \u00fchinemiste ja omandamiste lainetel. Esiteks t\u00f6\u00f6tasin v\u00e4ikeses idufirmas Qik, mille seej\u00e4rel ostis veidi suurem ettev\u00f5te Skype, mille seej\u00e4rel ostis veelgi suurem ettev\u00f5te Microsoft. Selle hetke jooksul sain aimu, kuidas DevOps'i arusaam erineva suurusega ettev\u00f5tetes muutub. P\u00e4rast seda tekkis mul huvi DevOps'i turu poole vaatamine ja koos kolleegidega korraldasime ettev\u00f5tte Ekspress 42. Oleme juba 6 aastat sellel turul lainetel liikunud.<\/p>\n

Lisaks olen \u00fcks DevOps Moscow kogukonna korraldajatest ja 2017. aasta DevOps Days'i korraldaja, kuid 2018. aastal ei korraldanud ma. Ekspress 42 teeb koost\u00f6\u00f6d paljude ettev\u00f5tetega. Arendame seal DevOps'i, vaatame, kuidas see toimub, teeme j\u00e4reldusi, anal\u00fc\u00fcsime, jagame oma j\u00e4reldusi k\u00f5igile, koolitame inimesi DevOps'i praktikate osas. \u00dches\u00f5naga, kasvame selles osas kogemusi ja ekspertiisi.<\/p>\n

Miks DevOps<\/h2>\n

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

- Meil oli pidev integratsioon - see t\u00e4hendab, et DevOps oli juba olemas, miks on siis kogu see jama vajalik? Seal v\u00e4lismaal l\u00f5butsetakse, aga meile takistatakse t\u00f6\u00f6d!<\/i><\/p>\n

9 aasta jooksul arendatud kogukonna ja metoodika k\u00e4igus on selgeks saanud, et see ei ole pelgalt turunduspettus, kuid siiani ei ole t\u00e4ielikult selge, miks see vajalik on. Nagu igal v\u00f5tmel ja protsessil, on DevOps-il konkreetsed eesm\u00e4rgid, mida ta l\u00f5puks saavutab.<\/p>\n

See k\u00f5ik on seotud sellega, et maailm muutub. See liigub eemale ettev\u00f5tte l\u00e4henemisest, kus ettev\u00f5tted liiguvad otse unistuste suunas, nagu laulis meie peterburilik klassik, punktist A punkti B kindla strateegia kaudu, mille jaoks on loodud m\u00e4\u00e4ratud struktuur. <\/p>\n

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

P\u00f5him\u00f5tteliselt peaks IT k\u00f5ike seda l\u00e4henemist j\u00e4rgima. Siin kasutatakse IT-d ainult protsesside automatiseerimiseks.<\/p><\/blockquote>\n

\nAutomatiseerimine ei muutu sageli, kuna kui ettev\u00f5te liigub kindlat rada pidi \u2014 mis seal siis muuta? Kui see t\u00f6\u00f6tab, \u00e4ra puutu. Praegu maailmas l\u00e4henemised muutuvad, ja see, mida nimetatakse Agile'iks, \u00fctleb, et l\u00f5pp-punkti B ei ole kohe n\u00e4htav.<\/p>\n

\"Mis
\n
\nKui ettev\u00f5te liigub turul, suhtleb klientidega \u2014 ta uurib pidevalt turgu ja muudab l\u00f5pp-punkti B. Mida tihedamalt ettev\u00f5te oma suunda muudab, seda rohkem see l\u00f5puks \u00f5nnestub, kuna ta valib rohkem turuni\u0161\u0161e.<\/p>\n

Strateegiat demonstreerib huvitav ettev\u00f5te, millest ma hiljuti kuulsin. One Box Shave \u2014 tellimuste j\u00e4rgi raseerimisvahendite ja -tarvikute kohaldamise teenus. Nad oskavad kohandada oma \"karpi\" erinevatele klientidele. Sellega tegeleb kindel tarkvara, mis saadab seej\u00e4rel tellimuse Korea tehasesse, kus toodet valmistatakse.<\/p>\n

Selle toote ostis ettev\u00f5te Unilever 1 miljardi dollari eest. N\u00fc\u00fcd konkurseerib see Gillette'iga ja on v\u00f5tnud USA turul sellelt olulise osa tarbijatest. One Box Shave \u00fctleb:<\/p>\n

\u2014 4 tera? Oled t\u00f5siselt? Miks sul seda vaja on \u2014 see ei paranda kvaliteeti raseerimise. Spetsiaalselt valitud kreem, l\u00f5hnaine ja kvaliteetne raseerija kahe teraga lahendavad palju rohkem probleeme kui need rumalad 4 tera Gillette'il! Varsti j\u00f5uame 10 tera juurde?<\/i><\/p>\n

Nii muutub maailm. Unilever teatab, et neil on lahe IT-s\u00fcsteem, mis v\u00f5imaldab seda teha. L\u00f5puks n\u00e4eb see v\u00e4lja nagu kontseptsioon Time-to-market<\/b>, millest on juba r\u00e4\u00e4kinud, kes iganes.<\/p>\n

\"Mis
\n
\nTime-to-market m\u00f5te ei seisne selles, kui sageli me v\u00e4lja anname. Sageli v\u00f5ib v\u00e4lja anda, kuid sel juhul on v\u00e4ljaandets\u00fcklid pikad. Kui kolme kuu v\u00e4ljaandets\u00fcklid \u00fcksteise peale asetada, nihutades n\u00e4dalakese, tundub nagu ettev\u00f5te v\u00e4ljastab kord n\u00e4dalas. Ent idee ja l\u00f5pliku teostamise vahele j\u00e4\u00e4b 3 kuud.<\/p>\n

Time-to-market t\u00e4hendab aega, mis kulub ideest l\u00f5pliku teostamiseni.<\/p><\/blockquote>\n

\nSelles juhul suhtleb turuga tarkvara. Nii nagu One Box Shave'i puhul suhtleb kliendiga veebisait. Neil pole m\u00fc\u00fcjaid - lihtsalt veebisait, kus k\u00fclastaja kl\u00f5psab ja j\u00e4tab oma soovid. Seet\u00f5ttu tuleb veebisaidil pidevalt midagi uut avaldada, et see vastaks soovidele. N\u00e4iteks L\u00f5una-Koreas habetakse teisiti kui Venemaal, ja neile meeldib ei ole m\u00e4nni, vaid n\u00e4iteks porgandi vanilli l\u00f5hn.<\/p>\n

Kuna tuleb kiiresti muuta veebisaidi sisu, muutub tarkvara arendus oluliselt. Tarkvara kaudu peame teada saama, mida klient soovib. Varem saime me seda teada ringteed pidi, n\u00e4iteks \u00e4rijuhtimise kaudu. Siis projekteerisime, panime n\u00f5uded IT-s\u00fcsteemi ja k\u00f5ik oli suurep\u00e4rane. Praegu on see aga teisiti - tarkvara projekteerivad k\u00f5ik, kes on protsessis kaasatud, sealhulgas insenerid, sest nad saavad tehniliste omaduste kaudu teada, kuidas turg t\u00f6\u00f6tab, ja jagavad \u00e4riga oma teadmisi.<\/p>\n

N\u00e4iteks ettev\u00f5ttes Qik saime \u00e4kki teada, et inimestele meeldib v\u00e4ga kontaktloendeid serverisse \u00fcles laadida, ja nad andsid meile rakenduse. Me ei olnud algselt selle peale m\u00f5elnud. Kliendiga tegelevas ettev\u00f5ttes oleks k\u00f5ik arvanud, et see on viga, kuna spetsiifikas ei olnud kirjutatud, et see peab h\u00e4sti t\u00f6\u00f6tama, ja see oli \u00fcldiselt teostatud kiirustades, oleks funktsioon v\u00e4lja l\u00fclitatud ja \u00f6eldud: \u201eSee pole kellelegi vajalik, peamine on, et peamine funktsionaalsus t\u00f6\u00f6tab\u201c. Ahnates tehnoloogiaettev\u00f5tte n\u00e4eb sellises olukorras v\u00f5imalust ja hakkab tarkvara vastavalt sellele muutma.<\/p>\n

\"Mis
\n
\n1968. aastal s\u00f5nastas ettevaatlik mees Melvin Conway j\u00e4rgmise idee.<\/p>\n

Organisatsioon, mis loob s\u00fcsteemi, on piiratud selle disainiga, mis kopeerib kommunikatsioonistruktuuri selles organisatsioonis.<\/p><\/blockquote>\n

\nKui r\u00e4\u00e4kida l\u00e4hemalt, et toota teist t\u00fc\u00fcpi s\u00fcsteeme, peab olema ka ettev\u00f5ttes teistsugune suhtlemisstruktuur. Kui teie suhtlemisstruktuur on pealiskaudne ja hierarhiline, ei v\u00f5imalda see teil luua s\u00fcsteeme, mis suudavad tagada v\u00e4ga k\u00f5rge Time-to-market.<\/p>\n

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

Protsessi vaatenurgast on kogu DevOpsi eelnevad etapid: anal\u00fc\u00fcs, arendus, testimine, kasutuselev\u00f5tt, toimunud lineaarselt.\"Mis
\nDevOpsi puhul toimuvad k\u00f5ik need protsessid samal ajal.<\/p>\n

\"Mis
\n
\nTime-to-market saab t\u00e4idetud ainult nii. Inimestele, kes on t\u00f6\u00f6tanud vanas protsessis, tundub see natuke ulmelisena ja \u00fcldiselt mitte just meeldivana.<\/p>\n

Aga miks on vaja DevOpsi?<\/h3>\n

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

DevOps \u00fcletab tarkvaratootmise j\u00e4rjestikuste meetodite kiiruspiiranguid<\/b>. K\u00f5ik protsessid toimuvad samal ajal.<\/p>\n

Suurenev keerukus.<\/b> Kui DevOpsi evangelistid r\u00e4\u00e4givad, et sellega on teil lihtsam tarkvara v\u00e4lja anda \u2013 see on jama.<\/p>\n

DevOpsiga muutub k\u00f5ik ainult keerulisemaks.<\/p><\/blockquote>\n

\nKonverentsil v\u00f5is Avito stendil n\u00e4ha, mis on Docker-konteineri \u00fcles seadmine \u2013 uskumatu \u00fclesanne. Keerukus muutub \u00fcletamatuks, tuleb samal ajal peksta mitut palli.<\/p>\n

DevOps muudab t\u00e4ielikult protsessi ja korralduse ettev\u00f5ttes<\/b>\u00a0\u2013 t\u00e4psemalt mitte DevOps, vaid digitaalne toode. Et j\u00f5uda DevOpsini, tuleb see protsess t\u00e4ielikult muuta.<\/p>\n

K\u00fcsimused spetsialistile<\/h3>\n

\nAga mis teil on? K\u00fcsimused, mida saate endale esitada, t\u00f6\u00f6tades ettev\u00f5ttes ja enesearendades spetsialistina.<\/p>\n

Kas teil on digitaalsete toodete loomise strateegia?<\/b> Kui on \u2013 juba hea. See t\u00e4hendab, et teie ettev\u00f5te liigub DevOpsi suunas.<\/p>\n

Kas teie ettev\u00f5te juba loob digitaalset toodet?<\/b> See t\u00e4hendab, et saate t\u00f5usta veel \u00fchele astmele k\u00f5rgemale, tegutseda huvitavamate asjade kallal \u2013 DevOpi vaatenurgast. R\u00e4\u00e4gin ainult sellest vaatenurgast.<\/p>\n

Kas teie ettev\u00f5te on \u00fcks turuliidritest digitaalsete toodete ni\u0161is?<\/b> Spotify, Yandex, Uber \u2014 ettev\u00f5tted, mis on praegu tehnoloogilise edusamme tipus.<\/p>\n

K\u00fcsi endalt neid k\u00fcsimusi, ja kui k\u00f5ik vastused on eitavad, siis v\u00f5ib-olla ei tasu sul DevOpsiga selle ettev\u00f5tte juures tegeleda. Kui aga sind DevOps t\u00f5eliselt huvitab, v\u00f5ib-olla\u2026 peaksid sa minema teise ettev\u00f5ttesse? Kui sinu ettev\u00f5te soovib minna DevOpsi suunas, aga oled k\u00f5igile k\u00fcsimustele vastanud \u201eEi\u201d, siis sarnaneb see toreda ninasarvikuga, kes ei muutu kunagi.<\/p>\n

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

Organisatsioon<\/h2>\n

\nNagu ma juba \u00fctlesin, muutub ettev\u00f5ttes organisatsioon Conwy seaduse kohaselt. Alustan sellest, mis takistab DevOpsi tungimist ettev\u00f5tte sisemusse just organisatsiooni seisukohalt.<\/p>\n

\u201eSilo\u201d probleem<\/h3>\n

\nInglise s\u00f5na \u201eSilo\u201d on siin t\u00f5lgitud vene keelde kui \u201e\u043a\u043e\u043b\u043e\u0434\u0435\u0446\u201d. Probleemi m\u00f5te on selles, et meeskondade vahel ei toimu teabe vahetust<\/b>. Iga meeskond kaevab oma ekspertiseerimist s\u00fcgavale, ehitamata samas \u00fchist kaarti, mille j\u00e4rgi orienteeruda.<\/p>\n

See meenutab inimest, kes just saabus Moskvasse ja ei oska veel metrookaardi j\u00e4rgi orienteeruda. Moskvast p\u00e4rit inimesed tunnevad oma piirkonda tavaliselt h\u00e4sti, aga kogu Moskva piires orienteeruvad nad metrookaardi j\u00e4rgi. Kui sa tuled Moskvasse esmakordselt, puudub see oskus ning sa oled lihtsalt segaduses.<\/p>\n

DevOps kutsub \u00fcles minema l\u00e4bi selle segaduse hetke ning koostama k\u00f5igil osakondadel koos \u00fchise suhtlemiskaardi.<\/p><\/blockquote>\n

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

Korporatiivse juhtimiss\u00fcsteemi tagaj\u00e4rg.<\/b> See on \u00fcles ehitatud eraldi hierarhiliste \u201esiloide\u201d peale. N\u00e4iteks on ettev\u00f5tetes teatud KPI-d, mis seda s\u00fcsteemi toetavad. Teiselt poolt takistavad inimese m\u00f5tted, kellel on keeruline v\u00e4lja astuda oma ekspertiseerimisest ja orienteeruda kogu s\u00fcsteemis. See on lihtsalt ebamugav. Kujutage ette, et olete sattunud Bangkokis asuvasse lennujaama \u2014 seal ei orienteeru kiiresti.<\/p>\n

DevOpsis on samuti keeruline orienteeruda, ja seet\u00f5ttu \u00fctlevad inimesed, et on vaja leida giid, et sinna p\u00e4\u00e4seda. Kuid k\u00f5ige olulisem on see, et \u201esiloide\u201d probleem insenerile, kes on m\u00f5istnud DevOpsi vaimu, lugenud Fowlerit ja palju teisi raamatuid, v\u00e4ljendub selles, et<\/b>\u201esiloid\u201d ei luba teha \u201eilmseid\u201d asju. Me koguneme sageli p\u00e4rast DevOps Moskvast, suhtleme omavahel ning inimesed kurdavad:<\/p>\n

\u2014 Me lihtsalt tahtsime CI-d k\u00e4ivitada, aga juhtkonnale ei ole see vajalik.<\/i><\/p>\n

See juhtub just seet\u00f5ttu, et\u00a0CI <\/b>ja\u00a0Continuous Delivery protsess<\/b> asuvad paljude ekspertide piiril. Lihtsalt, kui ei suudeta probleem 'kaevudest' organisatsiooni tasandil \u00fcletada, ei \u00f5nnestu edasi liikuda, \u00fcksk\u00f5ik mida teete ja kui kurb see ka pole.<\/p>\n

\"Mis
\n
\nIga protsessi osaline ettev\u00f5ttes: tagaplaneerijad ja esiplaneerijad, testimine, DBA, tegevus, v\u00f5rk, kaevavad oma suunas, kuid \u00fchtegi \u00fcldkaarti pole kellelgi, v\u00e4lja arvatud juht, kes neid kuidagi j\u00e4lgib ja haldab meetodiga 'jaga ja vali'.<\/p>\n

Inimesed v\u00f5itlevad mingite t\u00e4hede v\u00f5i lippude p\u00e4rast, iga\u00fchel on oma ekspertiza.<\/p><\/blockquote>\n

\nL\u00f5puks, kui tekib \u00fclesanne k\u00f5ik see kokku tuua ja ehitada \u00fcldine torujuhe, ning t\u00e4hete ja lippude p\u00e4rast enam ei pea v\u00f5itlema, tekib k\u00fcsimus - mida n\u00fc\u00fcd teha? Kuidas leppida kokku, aga seda ei \u00f5petanud meile koolis. Oleme juba koolist harjunud: kaheksas klass - ohhoo! - v\u00f5rreldes seitsmenda klassiga! Siin on sama.<\/p>\n

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

\nSeda kontrollimiseks v\u00f5ite esitada endale j\u00e4rgmised k\u00fcsimused.<\/p>\n

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

Kui tihti tuumikud \u00fcmber formeeruvad - \u00fched spetsialistid l\u00e4hevad \u00fchest tiimist teise?<\/b> Just DevOps keskkonnas saab see normiks, kuna m\u00f5nikord ei saa inimene lihtsalt aru, millega teises spetsialiseerumisvaldkonnas tegeletakse. Ta liigub teise osakonda, t\u00f6\u00f6tab seal kaks n\u00e4dalat, et luua endale orientatsiooni- ja suhtlemiskaart selle osakonnaga.<\/p>\n

Kas on v\u00f5imalik luua muudatuste komitee ja midagi muuta? <\/b>V\u00f5i on selleks vaja tugevat k\u00e4tt k\u00f5rgeimast juhtkonnast ja korraldust? Hiljuti kirjutasin Facebookis, kuidas \u00fcks v\u00e4hetuntud pank l\u00e4bi korralduste t\u00f6\u00f6riistu rakendab: kirjutasime korralduse, rakendame aasta, vaatame, mis juhtub. See on loomulikult pikk ja kurb.<\/p>\n

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

Kui te neile k\u00fcsimustele vastate, on parem arusaamine sellest, 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, ilma milleta on keeruline DevOpsis edasi liikuda, infrastruktuur kui kood<\/b>. <\/p>\n

Kuna infrastruktuuri kui koodi m\u00f5istetakse sageli j\u00e4rgmiselt:<\/p>\n

\u2014 Automaatige k\u00f5ik bash'is, katke end skriptidega, et administraatoritel oleks v\u00e4hem k\u00e4sitsi t\u00f6\u00f6d!<\/i><\/p>\n

Kuid see ei ole t\u00f5si.<\/p>\n

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

\nKoos teiste meeskondadega loote koodi kujul kaardi, mis on k\u00f5igile arusaadav ja mille kaudu saab orienteeruda ja navigeerida. Pole vahet, kas see on tehtud Chef'i, Ansible'i, Salt'i abil v\u00f5i kasutatakse YAML-faile Kubernetes'is \u2014 vahet pole.<\/p>\n

Konverentsil r\u00e4\u00e4kis kolleeg 2GIS-st, kuidas nad l\u00f5id oma sisemise t\u00f6\u00f6riista 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, kuidas seda muuta ja t\u00e4iustada, millest puudu j\u00e4\u00e4b. <\/p>\n

Olge n\u00f5us, eraldi bash-skriptid ei anna tavaliselt seda arusaamist. \u00dches ettev\u00f5ttes, kus ma t\u00f6\u00f6tasin, oli isegi nimetus \"write only\"-skript \u2014 kui skript on kirjutatud, siis ei saa seda enam lugeda. Ma arvan, et see on teile samuti tuttav.<\/p>\n

Infrastruktuur kui kood on kood, mis kirjeldab infrastruktuuri tegelikku seisundit<\/b>. Selle koodi kallal t\u00f6\u00f6tab koos hulk toote-, infrastruktuuri- ja teenuste meeskondi ning k\u00f5ige t\u00e4htsam on, et k\u00f5ik nad peavad m\u00f5istma, kuidas see kood \u00fcldse t\u00f6\u00f6tab.<\/p>\n

Kood on dokumenteeritud parimate koodit\u00f6\u00f6tluspraktikate j\u00e4rgselt<\/b>: koost\u00f6\u00f6 arendus, koodivaatlus, XP-programmeerimine, testimine, pull-requestid, CI infrastruktuuri koodi jaoks \u2014 see k\u00f5ik on hea ja seda saab kasutada.<\/p>\n

Koodist saab k\u00f5ikide inseneride \u00fchine keel.<\/p><\/blockquote>\n

\nInfrastruktuuri muutmine koodis ei v\u00f5ta palju aega<\/b>. Jah, infrastruktuuri koodis v\u00f5ib samuti olla tehniline v\u00f5lg. Tavaliselt kohtavad meeskonnad seda umbes poolteise aasta p\u00e4rast, kui nad on hakanud rakendama \"infrastruktuuri kui kood\" kujul hunnik skripte v\u00f5i isegi Ansible'i, mille nad kirjutavad nagu spagetikood, ja lisavad sinna veel bash-skripte. <\/p>\n

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

Infrastruktuur kui kood on infrastruktuurikoodi jagamine eraldi kihtideks.<\/p><\/blockquote>\n

\nMeie ettev\u00f5ttes eristame kolme p\u00f5hikihti, mis on h\u00e4sti arusaadavad ja lihtsad, kuid neid v\u00f5ib olla rohkem. Saate vaadata oma infrastruktuurikoodi ja \u00f6elda, kas teil on see tingimus v\u00f5i mitte. Kui kihte ei ole eristatav, siis tuleb leida aega ja natuke refaktoreerida.
\n\"Mis
\n
\nP\u00f5hikiht<\/b>\u00a0on see, kuidas konfigureeritakse OS, varukoopiad ja muud madala taseme asjad, n\u00e4iteks kuidas Kubernetes p\u00f5hitootena \u00fcles seada.<\/p>\n

Teenuste tase<\/b>\u00a0on need teenused, mida te arendajale pakute: logimise teenus, j\u00e4lgimise teenus, andmebaasi teenus, tasakaalustamisteenus, j\u00e4rjekorra teenus, pidev kohaletoimetamine teenus \u2014 hulga teenuseid, mida erinevad meeskonnad saavad arendusele pakkuda. K\u00f5ik need teenused tuleb teie konfiguratsioonihalduss\u00fcsteemis eraldi moodulitena kirjeldada.<\/p>\n

Kiht, kus rakendusi luuakse<\/b> ja kirjeldatakse, kuidas neid kahte eelmist kihti toetatakse.<\/p>\n

Kontrollk\u00fcsimused<\/h3>\n

\nKas teie ettev\u00f5ttes on \u00fchine infrastruktuuri hoidla? Kas te j\u00e4lgite tehnilist v\u00f5lga infrastruktuuris? Kas kasutate arendustavasid infrastruktuuri hoidlas? Kas teie infrastruktuur on jagatud kihtideks? V\u00f5ite viidata skeemile Base-service-APP. Kui keeruline on muudatusi teha? <\/p>\n

Kui olete kokku puutunud olukordadega, kus muudatuste tegemine v\u00f5ttis poolteist p\u00e4eva, t\u00e4hendab see, et teil on tekkinud tehniline v\u00f5lg ja sellega tuleb tegeleda. Olete kokku puutunud tehnilise v\u00f5la takistustega infrastruktuurikoodis. M\u00e4letan palju selliseid lugusid, kus m\u00f5ne CCTL muutmiseks tuli \u00fcmber kirjutada pool infrastruktuurikoodist, sest loovus ja soov k\u00f5ik automatiseerida viisid selleni, et k\u00f5ik oli ummistunud, k\u00f5ik nupud olid eemaldatud ja vajalik on refaktoreerida.<\/p>\n

Pidev kohaletoimetamine<\/h2>\n

\nKokkuv\u00f5tteks v\u00f5rdleme deebet- ja krediite. Esiteks esitatakse infrastruktuuri kirjeldus, mis v\u00f5ib olla \u00fcsna p\u00f5hiline. Pole vajalik k\u00f5ike detailselt kirjeldada, kuid mingit p\u00f5hilist kirjeldust on vaja, et saaksite sellega t\u00f6\u00f6tada. Vastasel juhul ei ole selge, mille peal edasi pidevat tarnet teha. K\u00f5ik need praktikad k\u00e4ivituvad samal ajal, kui j\u00f5uate DevOps'i, kuid alustada tuleb sellest, et m\u00f5ista, mis teil on, ja kuidas sellega juhtida. See on infrastruktuuri nagu koodi praktika.<\/p>\n

P\u00e4rast seda, kui on aru saadud, mis teil on ja kuidas sellega juhtida, hakkate v\u00e4lja m\u00f5tlema, kuidas arendaja koodi v\u00f5imalikult kiiresti tootmisse saata. Ma m\u00f5tlen koos arendajaga \u2013 peame meeles, et probleem on \u201ekaevudes\u201d, st mitte eraldi inimesed seda v\u00e4lja m\u00f5tlema, vaid meeskonnana.<\/p>\n

Kui me\u00a0Vanja Evtuhooviga<\/b> n\u00e4gime esimest raamatut Jez H\u00e4mblalt<\/b> ja autorite grupilt \u201eContinuous Delivery\u201d<\/b>, mis ilmus 2009. aastal, m\u00f5tlesime kaua, kuidas t\u00f5lkida selle pealkirja vene keelde. Tahtsime t\u00f5lkida kui \u201ePidev tarnimine\u201d, kuid kahjuks t\u00f5lkisime selle kui \u201ePidev kohaletoimetamine\u201d. Mulle tundub, et meie pealkirjas on midagi sellist vene moodi, j\u00f5uliselt.<\/p>\n

Pidev kohaletoimetamine \u2013 see t\u00e4hendab<\/h3>\n

\nKood, mis asub toote andmehoidlas, on alati valmis tootmisse minema.<\/b>See v\u00f5ib mitte minna, kuid on alati selleks valmis. Seega kirjutate alati koodi koos seletamatult \u00e4revustunde, misilmast allpool. See tunne tekib sageli, kui v\u00e4ljastate infrastruktuuri koodi. See \u00e4revustunne peab olema olemas \u2013 see tekitab m\u00f5tlemisprotsesse, mis v\u00f5imaldavad koodi kirjutada veidi teistsuguselt. See peaks olema fikseeritud arenduseeskirjades.<\/p>\n

Pideva kohaletoimetamiseks on vajalik artefakti formaat, mis l\u00e4bib infrastruktuuri platvormi. <\/b>Kui viskate infrastruktuuri platvormile erineva formaadiga \u201eeluea j\u00e4\u00e4tmeid\u201d, siis muutub see teistmoodi \u00fchtsustuks, seda on raske hooldada ning tekib tehnilise v\u00f5la probleem. Artefakti formaat tuleb \u00fchtlustada \u2013 see on samuti kollektiivne \u00fclesanne: tuleb koos kokku tulla, ajusid raputada ja v\u00e4lja m\u00f5elda see formaat.<\/p>\n

Aeg continually improves and adapts to the production environment during its passage through the delivery pipeline. <\/b>When the artifact moves through the pipeline, it constantly encounters certain inconvenient issues similar to those faced by the artifact you deploy to production. In traditional development, this would be managed by a sysadmin deploying it, but in the DevOps process, this happens constantly: sometimes it's tested, other times it's thrown into a Kubernetes cluster that resembles production more or less, and suddenly load testing is initiated.<\/p>\n

This somewhat resembles the game Pac-Man \u2014 the artifact goes through a certain story. It is important to monitor whether the code is truly progressing through the story and whether it is somehow related to your production. Stories from production can be integrated into the Continuous Delivery process: it used to be that something failed, so let's program this scenario into the system. Each time the code will go through this scenario as well, preventing you from encountering that issue again next time. You will be informed about it long before it reaches your client.<\/p>\n

Different deployment strategies. <\/b>For example, you use AB testing or canary deployments to explore the code differently across various clients, gathering information on how the code operates before it is released to 100 million users.<\/p>\n

\"Constant delivery\" looks like this.<\/p>\n

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

The delivery process Dev, CI, Test, PreProd, Prod \u2014 is not a separate environment; it consists of stages or stations with unburnable sums through which your artifact passes.<\/p><\/blockquote>\n

\nIf you have infrastructure code described as Base Service APP, it helps not to forget all scenarios<\/b>, and write them down in code form for this artifact, to promote the artifact<\/b> and modify it along the way.<\/p>\n

Self-check questions<\/h3>\n

\nIs the time from feature description to production rollout less than a week in 95% of cases? Is the quality of the artifact improving at each stage of the pipeline? Is there a story through which it progresses? Are you using different deployment strategies?<\/p>\n

If all the answers are yes, then you are incredibly awesome! Please write your answers in the comments \u2014 I would be glad to see them).<\/p>\n

Feedback<\/h3>\n

\nSee on k\u00f5ige keerulisem praktik, mis olemas on. DevOpsConf konverentsil r\u00e4\u00e4kis Infobipi kolleeg sellest ja ta segas veidi s\u00f5nu, sest see on t\u00f5esti v\u00e4ga keeruline praktika, mis k\u00e4sitleb seda, et tuleb j\u00e4lgida absoluutselt k\u00f5ike!<\/p>\n

\"Mis
\n
\nN\u00e4iteks, kunagi ammu, kui ma t\u00f6\u00f6tasin Qikis ja me m\u00f5istsime, et tuleb j\u00e4lgida k\u00f5ike. Me tegime seda ja Zabbixis oli meil 150 000 elemente, mida pidevalt j\u00e4lgiti. See oli kohutav, tehniline direktor keerutas oma pead:<\/p>\n

\u2014 Poisid, miks te serverit segaduses hoidma peate?<\/i><\/p>\n

Aga hiljem juhtus olukord, mis n\u00e4itas, et see on t\u00f5eliselt suurep\u00e4rane strateegia.<\/p>\n

\u00dcks teenus hakkas pidevalt kokku kukkuma. Alguses see ei kukkunud, mis on huvitav, sinna koodi ei lisatud, sest see oli p\u00f5hiline broker, milles praktiliselt ei olnud \u00e4rifunktsioone - see edastas lihtsalt s\u00f5numeid erinevate teenuste vahel. Teenus ei muutunud 4 kuud ja \u00e4kki hakkas see kukkuma veaga \"Segmentation fault.\"<\/p>\n

Olime \u0161okis, avasime oma graafikud Zabbixis ja selgus, et poolteist n\u00e4dalat tagasi muutus API-teenuse p\u00e4ringute k\u00e4itumine oluliselt. Edasi vaatasime, et teatud t\u00fc\u00fcpi s\u00f5numite saatmise sagedus muutus. Hiljem selgitasime v\u00e4lja, et nende Android-kliendid. K\u00fcsisime:<\/p>\n

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

Vastuseks kuulsime huvitavat lugu sellest, et nad uuendasid kasutajaliidest. Vaevalt keegi kohe \u00fctleb, et nad vahetasid HTTP-raamatukogu. Android-kliendi jaoks on see nagu seep vannitoas - nad lihtsalt ei m\u00e4leta seda. L\u00f5puks, 40-minutilise vestluse j\u00e4rel, saime teada, et nad vahetasid HTTP-raamatukogu ja sellel muutusid vaikimisi ajad. See t\u00f5i kaasa olukorra, et API serveri liikluse k\u00e4itumine muutus, mis p\u00f5hjustas lahingu brokeris ja see hakkas kukkuma.<\/p>\n

Ilma s\u00fcgava j\u00e4lgimiseta ei oleks seda \u00fcldse v\u00f5imalik avastada.<\/b>. Kui organisatsioonis on aga veel probleem \"kaevudega\", kus iga\u00fcks viskab s\u00fc\u00fc teise kaela, v\u00f5ib see kesta aastaid. Sa lihtsalt taask\u00e4ivitat server, kuna probleemi on v\u00f5imatu lahendada. Kui sa j\u00e4lgid ja j\u00e4lgite k\u00f5iki s\u00fcndmusi, mis sul on, ning kasutad j\u00e4lgimist nagu testimist \u2014 kirjutad koodi ja kohe n\u00e4itad, kuidas seda j\u00e4lgida, samuti koodi kujul (meil on juba infrastruktuur kui kood), siis on k\u00f5ik selge nagu peopesa. Ieven keerulised probleemid on kergesti j\u00e4lgitavad.<\/p>\n

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

Kogu teave selle kohta, mis toimub artefaktil iga etapi jooksul tarnimisprotsessis, tuleks koguda \u2014 mitte tootmisprotsessis.<\/p><\/blockquote>\n

\nJ\u00e4lgimine tuleb laadida CI-sse, ja seal on juba n\u00e4ha teatud p\u00f5hiasju. Edasi n\u00e4ed neid nii Testis, PredProd'is kui ka koormustestimises. Kogu teavet tuleb koguda k\u00f5igil etappidel, ja mitte ainult m\u00f5\u00f5dikud ja statistika, vaid ka logid: kuidas rakendus t\u00f6\u00f6le l\u00e4ks, anomaaliad \u2014 kogu teave koguge. <\/p>\n

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

K\u00fcsimused iseseisvaks kontrolliks.<\/h3>\n

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

Kas te kuulete probleemidest klientidelt? Kas m\u00f5istate klienti paremini j\u00e4lgimise ja logimise kaudu?<\/b> Kas te m\u00f5istate s\u00fcsteemi paremini j\u00e4lgimise ja logimise kaudu?<\/b> Kas te muudate s\u00fcsteemi lihtsalt selle p\u00e4rast, et n\u00e4ete s\u00fcsteemis t\u00f5usu ja m\u00f5istate, et veel 3 n\u00e4dala p\u00e4rast l\u00e4heb k\u00f5ik p\u00f5hja? <\/p>\n

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

Infrastruktuuri platvorm. <\/h2>\n

\nM\u00f5te ei ole selles, et see on iga ettev\u00f5tte laialivalguvate t\u00f6\u00f6riistade kogum.<\/p>\n

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

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

K\u00e4skude meeskond arendab infrastruktuuri platvormi, kohtleb seda hoolikalt nagu enda IDE-d<\/b>. Oma IDE-s installite erinevad pistikprogrammid, et k\u00f5ik oleks ilus ja kiiresti, seadistate otseteed. Kui avate Sublime, Atomi v\u00f5i Visual Studio Code'i, tulevad koodih\u00e4ired ja te m\u00f5istate, et on v\u00f5imatu t\u00f6\u00f6tada, te tunnete end kohe kurvalt ja jooksed oma IDE-d parandama.<\/p>\n

Koheldakse t\u00e4pselt samamoodi teie infrastruktuuri platvormi. Kui te m\u00f5istate, et midagi on valesti, esitage taotlus, kui te ei suuda seda ise parandada. Kui aga midagi lihtsat \u2014 parandage ise, saatke pull request \u2014 poisid vaatavad, lisavad. See on veidi erinev l\u00e4henemine insenerit\u00f6\u00f6riistadele arendaja peas.<\/p>\n

Infrastruktuuri platvorm tagab artefakti \u00fclekande arendajalt kliendile pideva kvaliteedi t\u00f5usuga<\/b>. IP-s on programmeeritud ajaloode kogum, mis juhtub koodiga tootmises. Aastate jooksul tekib neid lugematul hulgal, osa neist on unikaalsed ja kuuluvad ainult teile \u2014 neid ei ole v\u00f5imalik Google'ist leida. <\/p>\n

Sellest hetkest alates muutub infrastruktuuri platvorm teie konkurentsieeliseks<\/b>, sest see sisaldab seda, mida konkurendi t\u00f6\u00f6riistas ei ole. Mida s\u00fcgavam on teie IP, seda suurem on teie konkurentsieelis ajakohasus. Tekib vendor lock<\/b>: v\u00f5ite kasutada kellegi teise platvormi, kuid kasutades kellegi teise kogemust, ei saa te aru, kui relevantne see teile on. Jah, mitte iga ettev\u00f5te ei suuda ehitada Amazonit\u00fc\u00fcpi platvormi. See on keeruline piir, kus ettev\u00f5tte kogemus on seotud selle positsiooniga turul, ja vendor lock'i ei saa sinna lasta. Sellest on samuti oluline m\u00f5elda.<\/p>\n

Schema<\/h3>\n

\nSee on p\u00f5hiline skeem infrastruktuuri platvormist, mis aitab teil k\u00f5ik praktika ja protsessid DevOps-ettev\u00f5ttes paika saada.<\/p>\n

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

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

K\u00f5rge taseme teenused<\/b>: andmebaas teenusena, j\u00e4rjekorrad teenusena, Load Balance teenusena, piltide suurendamine teenusena, Suured Andmed tehasena teenusena. Selle peal\u00a0\u2014 pipeline, mis varustab pidevalt muudetud koodi teie kliendile<\/b>.<\/p>\n

Te saite teavet selle kohta, kuidas teie tarkvara t\u00f6\u00f6tab kliendi juures, muute, uuesti varustate selle koodiga, saite teavet - ja nii arendate pidevalt nii infrastruktuuriplatvormi kui ka oma tarkvara.<\/p>\n

Tarnepipeline koosneb paljusid etappidest. Kuid see on p\u00f5him\u00f5tteline skeem, mis on esitatud n\u00e4itena - ei pea seda t\u00e4pselt kordama. Etapid suhtlevad teenustega nagu teenustega - iga plokk platvormil kannab oma lugu: kuidas eraldatakse ressursse, kuidas rakendus k\u00e4ivitatakse, t\u00f6\u00f6tab ressurssidega, j\u00e4lgitakse, muudetakse.<\/p>\n

Oluline on m\u00f5ista, et iga platvormi osa kannab lugu, ja k\u00fcsida endalt - millist lugu see plokk kannab, v\u00f5ib-olla on m\u00f5istlik see k\u00f5rvaldada ja asendada kolmanda osapoole teenusega. N\u00e4iteks, kas saame selle ploki asendada Okmeteriga? V\u00f5ib-olla on nad juba arendanud seda ekspertiisi palju rohkem kui meie. Aga v\u00f5ib-olla ei ole - v\u00f5ib-olla on meil ainulaadne ekspertiis, mida meil on vaja arendada Prometheusega.<\/p>\n

Platvormi loomine<\/h3>\n

\nSee on keeruline suhtlemisprotsess. Kui teil on p\u00f5hipraktikad, alustate suhtlemist erinevate inseneride ja spetsialistide vahel, kes t\u00f6\u00f6tavad v\u00e4lja n\u00f5uded ja standardid ning muudavad neid pidevalt erinevate t\u00f6\u00f6riistade ja l\u00e4henemiste jaoks. Siin on oluline kultuur, mis on DevOpsis.<\/p>\n

\"Mis
\nKultuuriga on k\u00f5ik v\u00e4ga lihtne - see on koost\u00f6\u00f6 ja suhtlemine<\/b>, see t\u00e4hendab soovi t\u00f6\u00f6tada koos \u00fchisv\u00e4ljal, soovi omada sama t\u00f6\u00f6riista koos. Siin ei ole mingit rocket science - k\u00f5ik on v\u00e4ga lihtne, banaalne. N\u00e4iteks, me k\u00f5ik elame samas trepikojas ja hoidame selle puhtust - selline kultuuritase.<\/p>\n

Aga mis teiega on?<\/h3>\n

\nTaaskord k\u00fcsimused, mida saate endalt k\u00fcsida.<\/p>\n

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

Need to constantly ask yourself these questions. If something can be moved to external services, it should be done; if an external service starts blocking your progress, you need to build a system internally.<\/p>\n

Nii et, DevOps...<\/h2>\n

\n\u2026 it\u2019s a complex system that must include:<\/p>\n