Mis on DevOps

DevOpsi määratlemine on väga keeruline, mistõttu tuleb iga kord arutelu uuesti alustada. Ainuüksi 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), ja me räägime lihtsalt DevOpsist ning ma jagan oma kogemust.

Mõtlesin kaua, kuidas teha minu jutustus kasulikuks, seetõttu tuleb siia palju küsimusi — need, mida ma endalt küsida, ja need, mida ma meie ettevõtte klientidelt küsin. Neile küsimustele vastates muutub arusaamine paremaks. Räägin, miks DevOps on vajalik minu vaatenurgast, mis see on, taas minu positsiooni põhjal, ja kuidas mõista, kas liigute DevOpsi suunas, samuti minu vaatenurgast. Viimane punkt tuleb küsimuste kaudu. Neile vastates suudate mõista, kas teie ettevõte liigub DevOpsi suunas või on midagi valesti.

Ühel hetkel jalutasin ma ühinemiste ja omandamiste lainetel. Alguses töötasin ma väikeses idufirmas Qik, mille hiljem ostis pisut suurem ettevõte Skype, mille omakorda ostis veelgi suurem ettevõte Microsoft. Sel hetkel sain ma aru, kuidas DevOpsi mõisted erinevates suurustes ettevõtetes transformeeruvad. Pärast seda hakkas mind huvitama DevOps’i vaatamine turuperspektiivist ning koos kolleegidega asutasime ettevõtte Express 42. Juba 6 aastat oleme me selles ettevõttes turule suunatud tegevust arendamas.

Lisaks olen ma üks DevOps Moscow kogukonna korraldajatest ja 2017. aasta DevOps Days’i korraldaja, kuid 2018. aastal ei korraldanud ma üritust. Express 42 töötab paljude ettevõtetega. Me arendame seal DevOps’i, jälgime, kuidas see toimub, teeme järeldusi, analüüsime, jagame oma järeldusi kõigiga, õpetame inimesi DevOps’i praktikates. Ühesõnaga, kasvatame igas mõttes kogemusi ja ekspertiisi.

Miks DevOps?

Esimene küsimus, mis kummitab kõiki ja alati – miks? Paljud arvavad, et DevOps on lihtsalt automatiseerimine või sarnane asi, mis on juba igas ettevõttes olemas.

— Meil oli pidev integreerimine — see tähendab, et DevOps oli juba olemas ja miks on kogu see jama vajalik? Seal välismaal lõbustavad ennast, aga meil segavad töötamist!

9 aasta jooksul, mil kogukond ja metoodika on arenenud, on juba selgeks saanud, et need ei ole pelgalt turunduslikud sädelused, aga ikkagi ei ole veel selge, miks see vajalik on. Nagu igal toolil ja protsessil, on DevOps-il konkreetsed eesmärgid, mida ta lõpuks lahendab.

See kõik on seotud sellega, et maailm muutub. See liigub eemale ettevõtte lähenemisviisist, kus firmad liiguvad otse unistuste poole, nagu ütles meie Peterburi klassik, punktist A punkti B kindla strateegia kaudu, milline struktuur on selle jaoks ehitatud.

Põhimõtteliselt peaks IT kõik olema üles ehitatud selle lähenemisviisi ümber. Siin kasutatakse IT-d eelkõige protsesside automatiseerimiseks.

Automatiseerimine ei muutu sageli, sest kui ettevõte sõidab juba välja töötatud rajal — mis seal muuta? Töötab — ära puutu. Praegu maailmas lähenemised muutuvad, ja see, mida nimetatakse Agile'iks, ütleb, et lõpp-punkt B ei ole kohe näha.

Kui ettevõte turul tegutseb ja klientidega töötab, uurib ta pidevalt turgu ja muudab oma lõpp-punkti B. Mida sagedamini ettevõte oma suunda muudab, seda edukam on ta lõppkokkuvõttes, sest ta valib rohkem turunišše.

Strateegiat demonstreerib huvitav ettevõte, 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ärel Koreasse tehasesse, mis toodab kaupa.

Selle toote ostis ettevõte Unilever 1 miljardi dollari eest. Praegu konkureerib see Gillette'iga ja on kaotanud sellelt märkimisväärse osa tarbijatest Ameerika turul. One Box Shave ütleb:

— 4 teraga? Kas sa tõsiselt? Miks teil seda vaja on — see ei paranda kuidagi raseerimise kvaliteeti. Eriline kreem, lõhnav ained ja kvaliteetne raseerija kahe teraga lahendavad palju rohkem küsimusi kui need rumalad 4 teraga Gillette'id! Peagi jõuame 10 ni?

Nii maailm muutub. Unilever teatab, et neil on uus IT-süsteem, mis seda võimaldab. Lõppkokkuvõttes näeb see välja nagu kontseptsioon. Turuletoomise aeg, millest on rääkinud juba mitmed.

Turuletoomise mõte ei ole selles, kui tihti me deploy'ime. Sageli võib deploy'ida, kuid see tähendab, et väljaandmise tsüklid on pikad. Kui kolme kuu väljaandmise tsüklid üksteise peale panna, nihutades neid nädalaks, tundub, et ettevõte nagu deploy'b kord nädalas. Ent ideest lõpliku teostuseni kulub 3 kuud.

Turuletoomine tähendab ideest lõpliku teostuseni kulumise aja minimeerimist.

Sellisel juhul suhtleb turuga tarkvara. Näiteks One Box Shave'il suhtleb kliendiga nende veebisait. Neil pole müügiinimesi - lihtsalt sait, kus külastaja klõpsab ja jätab soovid. Seega tuleb saidil pidevalt midagi uut avaldada, et seda vastavalt soovidele värskendada. Näiteks Lõuna-Koreas peetakse habet teistmoodi kui Venemaal, ja neile meeldib, et aroomiks pole männi lõhn, vaid näiteks porgandi vanilje.

Kuna on vajalik kiiresti muuta veebisaidi sisu, tarkvara arendus on muutunud. Tarkvara kaudu peame mõistma, mida klient soovib. Varem saime seda teada kaude, näiteks äri juhtimise kaudu. Siis kavandasime, seadsime nõuded IT-süsteemi ja kõik oli suurepärane. Praegu on olukord teine - tarkvara kavandavad kõik, kes on protsessis kaasatud, sealhulgas insenerid, kuna nad saavad tehniliste spetsifikatsioonide kaudu aru, kuidas turg töötab, ja jagavad oma teadmisi äri poolega.

Näiteks ettevõttes Qik saime ootamatult teada, et inimestele meeldib väga laadida kontaktloendeid serverisse, ja nad andsid meile rakenduse. Alguses me sellele ei mõelnud. Klassikalises ettevõttes oleks kõik arvanud, et see on viga, kuna spetsifikatsioonis ei olnud öeldud, et see peaks hästi töötama, ja seda oli üldse poolikult teostatud, oleks funktsiooni välja lülitatud ja öeldud: "See ei ole kellelegi vajalik, peamine on see, et põhifunktsionaalsus töötab". Kuid tehnoloogiaettevõte näeb selles võimalust ja hakkab tarkvara vastavalt muutma.

1968. aastal kujundas ettevaatlik noormees Melvin Conway järgmise idee.

Organisatsioon, mis loob süsteemi, on piiratud disainiga, mis kopeerib selle organisatsiooni suhtluse struktuuri.

Kuna süsteemide tootmiseks, mis on erinevat tüüpi, peab ettevõttel olema ka erinevat tüüpi suhtlusstruktuur. Kui teie suhtlusstruktuur on pealtnäha hierarhiline, siis see ei võimalda teil luua süsteeme, mis suudavad tagada väga kõrge Time-to-market taseme.

Lugege Conway seadusest saab linkide kaudu. See on oluline DevOpsi kultuuri või filosoofia mõistmiseks, kuna ainus, mis DevOpsis põhjalikult muutub, on just suhtlus struktuur meeskondade vahel..

Protsessi vaatenurgast toimusid enne DevOps'i kõik etapid: analüüs, arendamine, testimine, kasutusele võtmine, järjestikku.
DevOps'i juhul toimuvad kõik need protsessid paralleelselt.

Time-to-market võib toimuda ainult nii. Inimestele, kes on töötanud vana protsessi juures, näib see mõnevõrra ulmeline ja üldiselt mitte just eriti meeldiv.

Miks on DevOps vajalik?

Digitaalsete toodete arendamiseks. Kui teie ettevõttes pole digitaalset toodet, pole DevOps vajalik - see on väga oluline.

DevOps ületab traditsioonilise tarkvaraarenduse piirangud.. Kõik protsessid toimuvad selles samas ajas.

Soolise keerukus suureneb. Kui DevOps'i evangelistid räägivad, et see teeb tarkvarade loomise lihtsamaks, on see vale.

DevOps teeb kõik vaid keerulisemaks.

Konverentsil Avalduskeskkonnas sai vaadata, kuidas Docker-konteinerit käivitada – see on peaaegu võimatu ülesanne. Keerukus muutub äärmuslikuks, peate samal ajal mitme palliga jongleerima.

DevOps muudab täielikult protsessi ja organisatsiooni ettevõttes – täpsemalt, ei muuda DevOps, vaid digitaalne toode. Et jõuda DevOps'i, tuleb selle protsessi täielikult muuta.

Küsimused spetsialistile

Aga kuidas teil? Küsimused, mida saate endalt küsida, töötades ettevõttes ja arenedes spetsialistina.

Kas teie ettevõttel on digitaalsete toodete loomise strateegia? Kui on - juba hästi. See tähendab, et teie ettevõte liigub DevOps'i suunas.

Kas teie ettevõte juba loob digitaalset toodet? See tähendab, et saate astuda veel ühe sammu kõrgemale, tegeleda huvitavate asjadega – DevOpsi vaates jälle. Just sellest vaatenurgast ma räägin.

Kas teie ettevõte on üks digitaalsete toodete turuliidreid? Spotify, Yandex, Uber – ettevõtted, mis hetkel asuvad tehnoloogia tipptaseme kõrval.

Esitage endale need küsimused ja kui kõik vastused on negatiivsed, siis võib-olla ei tasu teil DevOpsiga selles ettevõttes tegeleda. Kui aga DevOps teema tõeliselt huvitab, võib-olla... tuleks teil minna teise ettevõttesse? Kui teie ettevõte soovib liikuda DevOpsi suunas, kuid te vastasite kõikidele küsimustele "Ei", siis meenutab see kaunist ninasarvikut, kes kunagi ei muutu.

Organiseerimine

Kuna ma olen juba öelnud, et Conway seaduse järgi muutub ettevõttes organisatsioon. Alustan sellest, mis takistab DevOpsi sisemist juurdumist ettevõttes just organisatsiooni vaatenurgast.

Probleem „kolledžidest“

Inglise sõna „Silo“ on siin tõlgitud vene keelde kui „kolledž“. Selle probleemi mõte seisneb selles, et tiimide vahel pole teabevahetust.. Iga meeskond süveneb oma ekspertiisi, samas luues ühist kaarti, mille järgi orienteeruda.

See meenutab inimest, kes just saabus Moskvasse ja ei oska veel metroo kaartil orienteeruda. Moskvalased tunnevad oma piirkonda tavaliselt väga hästi, kuid Moskvasse orienteeruvad nad metroo kaardi järgi. Kui sa jõuad Moskvasse esmakordselt, pole seda oskust ja oled täiesti desorienteeritud.

DevOps pakub võimalust seda desorientatsiooni hetke ületada ning kõigil osakondadel koos luua ühine suhtlemiskaart.

Sellele takistavad kaks tegurit.

Tulemuseks on ettevõtte juhtimissüsteem. See on üles ehitatud eraldi hierarhiliste 'kaevudena'. Näiteks on teatud KPI-d ettevõtetes, mis toetavad seda süsteemi. Teiselt poolt takistavad seda inimeste mõtlemine, kellel on raske oma ekspertiisi piire ületada ja süsteemi üldiselt orienteeruda. See on lihtsalt ebamugav. Kujutage ette, et olete Bangkokis lennujaamas — seal ei orienteeru kiiresti. DevOpsis on samuti keeruline orienteeruda, seetõttu ütlevad inimesed, et on vaja leida juht, et sinna jõuda.

Kuid kõige olulisem on see, et «kaevude» probleem insenerile, kes on DevOps'i vaimu sisse elanud, lugenud Fowlerit ja palju teisi raamatuid, väljendub selles, et «kaevud» ei võimalda teha «ilmselgeid» asju.Me koguneme sageli pärast DevOps Moscow't, räägime omavahel ja inimesed kurdavad:

— Me tahtsime lihtsalt CI käivitada, aga selgus, et juhtkonnale see ei sobi.

See toimub just seetõttu, et CI ja Continuous Delivery process asuvad paljude teadmiste piiril. Lihtsalt kaevude probleemi ületamata organisatsioonilisel tasandil ei saa edasi liikuda, ükskõik mida te ka ei teeks ja kui kurb see ka ei oleks.

Iga protsessis osaleja ettevõttes: tagasisuunajate ja esitusnõustajate arendajad, testimine, DBA, haldamine, võrk, kaevandab oma suunas, kuid üldist kaarti ei oma keegi peale juhtkonna, kes neid kuidagi vaatab ja juhib meetodiga «jaga ja valitse».

Inimesed võitlevad mingite tähiste või lippude nimel, igaüks kaevandab oma ekspertteadmisi.

Kokkuvõttes, kui ülesanne on kõik see koos siduda ja luua ühine töövoog, ning tähed ja lipud enam ei häiri, tekib küsimus – mida siis üldse teha? Peame kuidagi kokku leppima, aga kuidas seda teha, meid koolis ei õpetatud. Oleme juba koolist harjunud: kaheksas klass - ohhoo! - võrreldes seitsmenda klassiga! Siin on sama moodi.

Kas teie ettevõttes on samuti?

Selle kontrollimiseks võib endalt esitada järgmised küsimused.

Kas meeskonnad kasutavad ühiseid tööriistu, kas nad panustavad nende ühiste tööriistade muutmisse?

Kui tihti meeskonnad ümber moodustatakse – kas spetsialistid ühest meeskonnast liiguvad teise meeskonda? Just DevOps keskkonnas saab sellest norm, sest mõnikord ei saa inimene lihtsalt aru, millega tegeleb teine teadmisvaldkond. Ta liigub teise osakonda, töötab seal paar nädalat, et luua endale orienteerumiskaart ja suhtlemine selle osakonnaga.

Kas on võimalik luua muudatuskomitee ja midagi muuta? Või on selleks vajalik kõrgeima juhtkonna tugev käsi ja korraldus? Hiljuti kirjutasin Facebookis, kuidas üks vähe tuntud pank korralduste kaudu tööriistu rakendab: kirjutatakse korraldus, aasta rakendatakse, vaadatakse, mis juhtub. See on muidugi pikk ja kurb protsess.

Kui oluline on juhtide jaoks saada isiklikke saavutusi, arvestamata ettevõtte saavutusi?

Kui vastate endale nendele küsimustele, siis on selgem, kas teil on ettevõttes selline probleem.

Infrastruktuur kui kood

Pärast seda, kui see probleem on lahendatud, on esimene oluline praktika, milleta DevOps'is edasi liikumine on keeruline — see on infrastruktuur kui kood.

Kõige sagedamini mõistetakse infrastruktuuri kui koodi nii:

— Automatiseerime kõik bash'is, määritame end skriptidega, et adminni töö oleks vähem käsitsi!

Aga see pole nii.

Infrastruktuur kui kood tähendab, et IT-süsteemi, millega töötate, kirjeldatakse koodina, et pidevalt mõista selle seisundit.

Koostöös teiste meeskondadega loote kaardi koodivormingus, mis on kõigile arusaadav ja mille järgi saab orienteeruda ja navigeerida. Pole oluline, millest see on tehtud — Chef, Ansible, Salt, või kasutatakse YAML-faile Kubernetes'is — ei ole vahet.

Konverentsil rääkis kolleeg 2GIS-ist, kuidas nad lõid oma sisemise lahenduse Kubernetes'i jaoks, mis kirjeldab üksikute süsteemide ülesehitust. 500 süsteemi kirjeldamiseks vajasid nad eraldi tööriista, mis selle kirjelduse genereerib. Kui see kirjeldus on olemas, saavad kõik üksteisega võrrelda, jälgida muudatusi ning mõista, kuidas seda muuta ja täiustada, mida puudu on.

Kokkuleppel, eraldi bash-skriptid ei anna tavaliselt seda arusaamist. Ühes ettevõttes, kus ma töötasin, oli isegi nimeks "write only"-skript – kui skript on kirjutatud, siis ei ole seda enam võimalik lugeda. Arvan, et see on teilegi tuttav.

Infrastruktuur koodina – see on kood, mis kirjeldab infrastruktuuri tegelikku seisundit. Selle koodiga töötab ühiselt mitmeid toote-, infrastruktuuri- ja teenindusmeeskondi ning mis kõige tähtsam, kõik nad peavad aru saama, kuidas see kood üldse töötab.

Kood järgib parimaid praktikaid koodiga töötamisel.: koostööarendamine, koodikontroll, XP-programmeerimine, testimine, pull-requestid, CI koodiinfrastruktuuride jaoks — see kõik on kasulik ja kasutatav.

Kood muutub kõigi inseneride ühise keelena.

Infrastruktuuri muutmine koodis ei võta palju aega.. Jah, ka infrastruktuurikoodis võib olla tehnilist võlga. Tüüpiliselt seisavad meeskonnad silmitsi sellega umbes poolteise aasta pärast seda, kui nad on hakanud rakendama 'infrastruktuuri kui koodi' hulgana skripte või isegi Ansible'i, mida nad kirjutavad nagu spagetikood ja lisavad sinna veel bash-skripte!

Oluline: kui te pole seda veel proovinud, pidage meeles, et Ansible ei ole bash! Kõigepealt lugege hoolikalt dokumentatsiooni, uurige, mida selle kohta üldse kirjutatakse.

Infrastruktuur kui kood tähendab infrastruktuurikoodi jagamist eraldi kihtideks.

Meie ettevõttes määratleme kolm põhikihti, mis on väga arusaadavad ja lihtsad, kuid neid võib olla rohkem. Saate vaadata oma infrastruktuuri koodi ja öelda, kas teil on see tingimus või mitte. Kui ühtegi kihti ei määratleta, tuleb leida aega ja teha natuke refaktoreerimist.


Põhikih — see on nagu operatsioonisüsteemi seadistamine, varukoopiad ja muud madalamal tasemel asjad, näiteks kuidas Kubernetes baasvälja määrata.

Teenuste tase — need on teenused, mida te arendajale pakute: logimine teenusena, monitooring teenusena, andmebaas teenusena, koormuse tasandaja teenusena, järjekord teenusena, pidev tarnimine teenusena — hulk teenuseid, mida eri meeskonnad saavad arendusele pakkuda. Kõik need tuleb teie konfiguratsiooni haldussüsteemis eraldi moodulitena kirjeldada.

Kiht, kus rakendused luuakse ja kirjeldatakse, kuidas need kahel eelpool nimetatud kihil välja on arendatud.

Kontrollküsimused

Kas teie ettevõttel on ühine infrastruktuurihoidla? Kas te haldate infrastruktuuri tehnilist võlga? Kas te rakendate arenduspraktikaid infrastruktuuri hoidlas? Kas teie infrastruktuur on kihiti jagatud? Võite viidata Base-service-APP skeemile. Kui keeruline on muudatusi teha?

Kui olete kokku puutunud olukorraga, kus muudatuste tegemine võttis poolteist päeva, siis tähendab see, et teil on tekkida saanud tehniline võlg, mille kallal on vaja töötada. Teatud on, et olete komistanud infrastruktuurikoodi tehnilise võla kuristikku. Mäletan palju selliseid juhtumeid, kus mingite CCTL muutmine nõudis poolte infrastruktuuri koodi ümberkirjutamist, kuna loovus ja soov kõik automatiseerida viisid selleni, et kõik on ummistunud, kõik juhtmed on eemaldatud ja see vajab refaktooringut.

Jätkuv tarnimine

Käime läbi deebetkrediidiga. Esiteks antakse ülevaade infrastruktuurist, mis võib olla üsna põhiline. Pole tingimata vajalik kõike üksikasjalikult kirjeldada, kuid mingist põhikirjelduse olemasolu on vajalik, et saaksite sellega töötada. Vastasel juhul ei ole selge, mille peal edasi pidevat tarnimist teha. Kõik need praktikad käivad käsikäes, kui jõuate DevOpsini, kuid alustamiseks peab mõistma, mis teil on ja kuidas sellega hallata. See on just praktikaks infrastruktuuri kui koodi.

Pärast seda, kui on arusaadav, mis teil on ja kuidas sellega hallata, hakkate välja mõtlema, kuidas arendaja koodi võimalikult kiiresti tootmisse saata. Ma mõtlen koos arendajaga – peame meeles probleemi, et „kaevud” ei ole sellised, et eraldi inimesed seda välja mõtleksid, vaid kogu meeskonna koostöös.

Kui me Vaneja Jevtuhovičiga nägime esimest raamatut Jez Hambula ja autorite rühma «Continuous Delivery», mis käidi välja 2009. aastal, mõeldi kaua, kuidas tõlkida selle pealkiri eesti keelde. Soovisime tõlkida kui "Alati toimetama", aga kahjuks tõlgiti kui "Jätkuv tarnimine". Tundub, et meie pealkirjas on midagi venekeelset, millega on seotud kindel tahe.

Alati toimetama — see tähendab

Kood, mis asub tootehoidlas, võib alati minna tootmisse. See võib olla ka mitte välja viidud, kuid on alati selleks valmis. Seetõttu kirjutate alati koodi teatud seletamatu ärevustunde saatel. See tunne tekib sageli, kui tõstate infrastruktuurikoodi. See teatud ärevus peaks olema kohal — see kutsub esile mõtteprotsesse, mis aitavad kirjutada koodi veidi teistsuguselt. See peaks olema fikseeritud arendusreeglites.

Alati toimetamiseks on vajalik artefakti formaat, mis läbib infrastruktuuriplatvormi. Kui te viskate erineva formaadi "elutoas aitavaid" jääke infrastruktuursele platvormile, siis see muutub teie jaoks mitteühtseks, seda on keeruline hooldada ja tekib tehnilise võla probleem. Artefakti vorm tuleb ühtlustada — see on ka kollektiivne ülesanne: tuleb kõik koos kokku tulla, mõtiskleda ja välja mõelda see formaat.

Artefakti täiustatakse pidevalt ning see muutub tootmiskeskkonna järgi, kui see liigub tarnimise torustiku kaudu. 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üsteemihaldur, kes teeb väljalaskmist, siis DevOps-protsessis toimub see pidevalt: seal on teda katsetega keerutatud, siin on ta visatud Kubernetes-klastrisse, mis on enam-vähem sarnane tootmisele, ja siis järsku käivitatakse koormustestimine.

See on midagi sarnast Pac-Man mänguga — artefakt läbib teatud loo. Oluline on jälgida, kas kood tõesti järgib lugu ja kas see on seotud teie tootmisega. Toote lood saab integreerida pideva kohaletoimetamise protsessi: varem juhtus midagi häda, nüüd programmeerime selle stsenaariumi lihtsalt süsteemi. Iga kord, kui kood seda stsenaariumi läbib, ei puutu te selle probleemiga enam kokku järgmine kord. Te saate sellest teada palju kiiremini, kui see jõuab teie kliendini.

Erinevad juurutamisstrateegiad. Näiteks kasutate AB-testimist või kanarode juurutamisi, et eri klientidel koodi erinevalt "katsetada", teades, kuidas kood töötab, ja seda palju varem, kui see jõuab 100 miljoni kasutajani.

"Pidev kohaletoimetamine" näeb välja nii.

Tootmisprotsess Dev, CI, Test, PreProd, Prod — see ei ole eraldi keskkond, vaid etapid või jaamad, mille kaudu teie artefakt liigub.

Kui teil on infrastruktuuri kood, mis on kirja pandud Base Service APP-ina, siis see aitab mitte unustada kõiki stsenaariume., ja salvestada need ka koodi kujul selle objekti jaoks, edendada objekti ja muuta seda protsessi käigus.

Enesehinnanguks küsimused

Kas funktsiooni kirjeldamisest kuni tootmisseviimiseni kulub 95% juhtudest vähem kui nädal? Kas objekti kvaliteet paraneb igas etapis toimeprotsessis? Kas sellel on ajalugu, mille kaudu see läbib? Kas kasutate erinevaid rakendamisstrateegiaid?

Kui kõik vastused on jah, siis olete te uskumatu! Kirjutage vastused kommentaaridesse - mul oleks rõõm).

Tagasiside

See on kõige keerulisem praktika kõigist. DevOpsConf'i konverentsil rääkis kolleeg Infobipist sellest ja segas end veidi sõnades, sest see on tõepoolest väga keeruline praktika, mis käsitleb seda, et tuleb jälgida tõeliselt kõike!

Näiteks, kaua aega tagasi, kui töötasin Qik'is ja me mõistsime, et tuleb jälgida tõeliselt kõike. Me tegime seda ja meie Zabbix'is oli 150 000 objekti, mida jälgiti pidevalt. See oli hirmutav, tehniline direktor keerutas sõrme oma lasku:

— Kutsikad, miks te serverit niimoodi mõttetult piinate?

Aga siis juhtus juhus, mis näitas, et see on tõeliselt äge strateegia.

Üks teenus hakkas pidevalt kokku kukkuma. Alguses see ei kukkunud, huvitav on see, et sinna ei kirjutatud uut koodi, kuna see oli põhiline broker, kus praktiliselt ei olnud ärifunktsionaalsust — see lihtsalt edastas sõnumeid erinevate teenuste vahel. Teenus ei olnud muutunud 4 kuu jooksul ja äkki hakkas see kukkuma veaga «Segmentation fault».

Olimme šokis, avasime meie Zabbix'i grafi ja selgus, et poolteist nädalat tagasi olid API-teenuse päringute käitumine tugevalt muutunud, mis kasutab seda brokereid. Edasi vaatasime, et teatud tüüpi sõnumite saatmise sagedus oli muutunud. Hiljem sai selgeks, et need on android-klientide päringud. Küsisime:

— Poisid, mis teiega poolteist nädalat tagasi juhtus?

Vastas kuuldi huvitavat lugu sellest, kuidas nad kasutajaliidest uuendasid. Raske on kohe öelda, et nad muutsid HTTP-raamatukogu. Androidi klientidele on see nagu seepi vahetada vannitoas – nad lihtsalt ei mäleta seda. Lõpuks, pärast 40 minutit vestlust, selgus, et nad tõepoolest vahetasid HTTP-raamatukogu ja sellel muutusid vaikeseaded. See tõi kaasa muudatused API serveri liikluse käitumises, mis omakorda viis olukorrani, mis põhjustas võistluse brokera sees, mille tõttu ta hakkas kokku kukkuma.

Ilma süvamonitorimiseta on seda üldse võimatu avastada.. Kui organisatsioonis on veel probleem „kaevude” osas, kus kõik liigutavad vastutust üksteisele, võib see kesta aastaid. Sa lihtsalt taaskäivitad serveri, sest probleemi lahendamine on võimatu. Kui sa jälgid, monitoorid ja jälgid kõiki sündmusi, mis sul on, ning kasutad monitooringut testimise viisina – kirjutad koodi ja kohe näitad, kuidas seda monitoorida, samuti koodina (meil on juba infrastruktuur koodina), siis kõik saab selgeks nagu peopesa peal. Ieven sellised keerulised probleemid on kergesti jälgitavad.

Koguge kogu teavet selle kohta, mis toimub artefaktiga iga etapi jooksul tarneprotsessis — mitte tootmisel.

Laadige jälgimine CI-sse, seal saate juba näha mõned põhiasjad. Edasi näete neid nii Testis, PredProd-s kui ka koormustestimisel. Koguge teavet kõigil etappidel, mitte ainult mõõdikute, statistika, vaid ka logide osas: kuidas rakendus välja lasti, anomaaliad — koguge kõik.

Vastasel juhul on keeruline aru saada. Olen juba öelnud, et DevOps on suurem keerukus. Selle keerukusega toimetulemiseks on vajalik omada head analüütikat..

Enesekontrolli küsimused

Kas teie jälgimine ja logimine on teie jaoks arendustööriist? Kas teie arendajad, sealhulgas teie ise, mõtlevad koodi kirjutades sellele, kuidas seda jälgida?

Kas saate probleemidest teada klientidelt? Kas mõistate klienti paremini jälgimise ja logimise kaudu? Kas mõistate süsteemi paremini jälgimise ja logimise kaudu? Kas muudate süsteemi lihtsalt seetõttu, et näete, et süsteemi trend kasvab ja mõistate, et veel 3 nädalat ja kõik kukub kokku?

Kui teil on need kolm komponenti, võite mõelda, milline infrastruktuuri platvorm teil on ettevõttes.

Infrastruktuuri platvorm

Mõte ei ole selles, et see on hulk lahusolevaid tööriistu, mis on igas ettevõttes olemas.

Infrastruktuuri platvormi mõte on see, et kõik meeskonnad kasutavad neid tööriistu ja arendavad neid koos.

Selge on, et on eraldi meeskonnad, kes vastutavad infrastruktuuri platvormi eraldi osade arendamise eest. Kuid vastutus arendamise, töökindluse ja infrastruktuuri platvormi edendamise eest lasub igal inseneril. Sisemiselt muutub see üldiseks tööriistaks.

Kõik meeskonnad arendavad infrastruktuuri platvormi, käitudes selle suhtes hoolikalt nagu omaenda IDE-de vastu.. Oma IDE-s seadistate erinevaid pluginaid, et kõik oleks ilus ja kiire, kohandate otseteid. Kui avate Sublime'i, Atomi või Visual Studio Code'i, sadavad teile koodivead ja te saate aru, et on täiesti võimatu töötada, tunnete kohe kurbust ja jooksete oma IDE-d parandama.

Suhtuge oma infrastruktuuri platvormi sama tõsiselt. Kui te mõistate, 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 — arendajad vaatavad selle üle ja lisavad. See on erinev lähenemine arendaja tööriistadele.

Infrastruktuuri platvorm tagab artefakti ülekande arendusest kliendini, pideva kvaliteedi parandamisega.. Infrastruktuuri platvormil on programmeeritud hulk lugusid, mis juhtuvad koodiga tootmises. Aastate jooksul on nendest lugudest saanud väga palju, osa neist on unikaalsed ja seotud ainult teiega — neid ei ole võimalik Google'ist leida.

Sel hetkel muutub infrastruktuuri platvorm teie konkurentsieeliseks, sest selles on sisse kodeeritud midagi, mida konkurendi tööriistadel ei ole. Mida sügavam on teie infrastruktuuri platvorm, seda suurem on teie konkurentsieelis Time-to-market osas. Siin kerkib esile vendor lock probleem.: saate endale võtta kellegi teise platvormi, kuid kasutades kellegi teise kogemust, ei saa te aru, kui asjakohane see teie jaoks on. Jah, mitte iga ettevõte ei saa üles ehitada Amazoni tüüpi platvormi. See on keeruline piiriülene asi, kus ettevõtte kogemus on seotud selle turupositsiooniga, ja sinna ei tohi lubada vendor lock'i. Sellele on samuti oluline mõelda.

Skeem

See on infrastruktuuri platvormi põhiskeem, mis aitab teil seadistada kõik praktikas ja protsessides DevOps ettevõttes.

Vaatame, millest see koosneb.

Ressursside orkestreerimise süsteem, mis pakub rakendustele ja teistele teenustele CPU-d, mälu, kettaruumi. Selle peal on madala taseme teenused: jälgimine, logimine, CI/CD mootor, artefaktide ladustamine, infrastruktuur kui kood.

Kõrgema taseme teenused: andmebaas kui teenus, järjekorrad 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..

Te saate teavet selle kohta, kuidas teie tarkvara kliendil töötab, muudate, uuesti tarnite selle koodi, saate teavet — ning nii arendate pidevalt nii infrastruktuuri platvormi kui ka teie tarkvara.

Kujundusel koosneb kohaletoimetamise torustik mitmest etapist. Kuid see on põhimõtteline skeem, mis on toodud näitena — ei pea seda täpselt kordama. Etapid suhtlevad teenustega nagu teenustega — iga platvormi ehitis kannab oma ajalugu: kuidas ressursse eraldatakse, kuidas rakendus käivitub, töötab ressurssidega, jälgitakse, muudetakse.

Oluline on mõista, et iga platvormi osa kannab ajalugu, ja küsida endalt — millist ajalugu kannab see element, võib-olla tasub see välja vahetada ja asendada kolmanda osapoole teenusega. Näiteks, kas võiksime selle kivi asemel kasutada Okmeter'i? Võib-olla on nad juba selle ekspertiisi palju paremini üles ehitanud kui meie. Aga võib-olla mitte — võib-olla on meil ainulaadne ekspertiis, peame kasutama Prometheuse ja seda edasi arendama.

Platvormi loomine

See on keeruline kommunikatsiooniprotsess. Kui teil on põhipraktikad paigas, alustate suhtlemist erinevate inseneride ja spetsialistidega, kes töötavad välja nõudmisi ja стандарte ning muudavad neid pidevalt vastavalt erinevatele tööriistadele ja lähenemisviisidele. Siin on oluline kultuur, mis on DevOps-is.

Kultuuriga on kõik väga lihtne — see on koostöö ja suhtlemine, see tähendab soov töötada ühiselt, jagada sama tööriista. Siin ei ole midagi keerulist — kõik on väga lihtne ja tavaline. Näiteks elame kõik trepikojas ja hoiame selle puhtana — see on kultuuri tase.

Ja kuidas on teil?

Jälle küsimused, mida võite endalt küsida.

Kas infrastruktuuri platvorm on eraldatud? Kes vastutab selle arengu eest? Kas te mõistate oma infrastruktuuri platvormi konkurentsieeliseid?

Nendele küsimustele tuleb pidevalt vastuseid otsida. Kui midagi saab välisteenustele üle anda — tuleks seda teha, ja kui väline teenus hakkab teie edasiviimist takistama, tuleb süsteem endas üles ehitada.

Nii et DevOps…

… see on keeruline süsteem, kus peavad olema:

• Digitaalne toode.
• Ärise mudeleid, mis arendavad seda digitaalset toodet.
• Tootemeeskonnad, kes kirjutavad koodi.
• Jätkuva tarne praktikad.
• Platvormid teenusena.
• Infrastruktuur teenusena.
• Infrastruktuur kui kood.
• Eramugavad praktikad, mis toetavad usaldusväärsust ja on DevOpsisse integreeritud.
• Tagasiside praktika, mis kirjeldab seda kõike.

Seda skeemi saab kasutada, värvides selle sisse, mis teil juba ettevõttes mingil kujul olemas on: see on arenenud või vajab veel arendamist.

Juba paar nädalat hiljem toimub DevOpsConf 2019. osana RIT++. Tulge konverentsile, kus ootavad teid paljud lahedad ettekanded jätkuva tarnimise, infrastruktuuri kui koodi ja DevOps-i transformatsiooni kohta. Broneerige piletid, viimase hindade tähtaeg on 20. mai.

Allikas: habr.com