„DevOps“ apibrėžimas yra labai sudėtingas, todėl kiekvieną kartą turime pradėti diskusiją apie tai iš naujo. Vien Habré šia tema yra tūkstantis publikacijų. Bet jei skaitote tai, tikriausiai žinote, kas yra „DevOps“. Nes aš nesu. Labas mano vardas yra Aleksandras Titovas (@), pakalbėsime tik apie „DevOps“, o aš pasidalinsiu savo patirtimi.
Ilgai galvojau, kaip savo istoriją paversti naudinga, todėl čia kils daug klausimų – tų, kuriuos užduodu sau ir mūsų įmonės klientams. Atsakius į šiuos klausimus supratimas tampa geresnis. Aš jums pasakysiu, kodėl mano požiūriu reikalingas DevOps, kas tai yra, vėlgi, mano požiūriu ir kaip suprasti, kad mano požiūriu vėl judate link DevOps. Paskutinis taškas bus per klausimus. Atsakydami į juos patys galite suprasti, ar jūsų įmonė juda DevOps link, ar yra kokių nors problemų.
Vienu metu važiavau susijungimų ir įsigijimų bangomis. Iš pradžių dirbau nedideliame startuolyje pavadinimu „Qik“, vėliau jį nusipirko šiek tiek didesnė įmonė „Skype“, kurią vėliau įsigijo šiek tiek didesnė įmonė „Microsoft“. Tuo metu aš pradėjau matyti, kaip DevOps idėja transformuojasi skirtingo dydžio įmonėse. Po to susidomėjau pažvelgti į DevOps iš rinkos pusės ir su kolegomis įkūrėme įmonę Express 42. Jau 6 metus judame rinkos bangomis.
Be kita ko, esu vienas iš „DevOps Moscow“ bendruomenės organizatorių ir „DevOps-Days 2017“ organizatorių, tačiau 2018-ųjų neorganizavau. „Express 42“ veikia su daugeliu įmonių. Ten auginame DevOps, stebime, kaip tai vyksta, darome išvadas, analizuojame, sakome visiems savo išvadas ir mokome žmones DevOps praktikos. Apskritai, mes darome viską, kad padidintume savo patirtį ir kompetenciją šioje srityje.
Kodėl DevOps
Pirmas klausimas, kuris kankina visus ir visada – kodėl? Daugelis žmonių mano, kad „DevOps“ yra tik automatika ar panašus dalykas, kurį jau turėjo kiekviena įmonė.
— Turėjome nuolatinį integravimą – tai reiškia, kad jau turėjome „DevOps“ ir kam viso to reikia? Jie linksminasi užsienyje, bet mums trukdo dirbti!
Per 9 bendruomenės ir metodikos kūrimo metus jau tapo aišku, kad tai vis dar nėra rinkodaros blizgučiai, tačiau vis dar nėra iki galo aišku, kam to reikia. Kaip ir bet kuris įrankis ir procesas, „DevOps“ turi konkrečius tikslus, kuriuos galiausiai pasiekia.
Visa tai lemia tai, kad pasaulis keičiasi. Jis nutolsta nuo įmonės požiūrio, kai įmonės juda tiesiai svajonės link, kaip dainavo mūsų Sankt Peterburgo klasika, iš taško A į tašką B pagal tam tikrą strategiją, su tam tikra struktūra.
Iš esmės viskas IT srityje turėtų būti kuriama pagal šį požiūrį. Čia IT naudojamos išskirtinai procesams automatizuoti.
Automatika keičiasi nedažnai, nes įmonei nuėjus į išmintą vėžę, ką čia keisti? Veikia – nelieskite. Dabar požiūriai pasaulyje keičiasi, o vadinamasis „Agile“ rodo, kad galutinis taškas B nėra matomas iš karto.
Kai įmonė eina per rinką, dirba su klientu, ji nuolat tyrinėja rinką ir keičia galutinį tašką B. Be to, kuo dažniau įmonė keičia savo kryptį, tuo jai galiausiai sekasi, nes renkasi daugiau rinkos. nišos.
Strategiją demonstruoja įdomi įmonė, apie kurią neseniai sužinojau. „One Box Shave“ – tai prenumeratos barzdaskučių ir skutimosi reikmenų pristatymo dėžutėje paslauga. Jie žino, kaip pritaikyti savo „dėžutę“ skirtingiems klientams. Tai atlieka tam tikra programinė įranga, kuri vėliau siunčia užsakymą Korėjos gamyklai, kuri gamina produktą.
Šį produktą „Unilever“ įsigijo už 1 mlrd. Dabar ji konkuruoja su „Gillette“ ir atėmė didelę vartotojų dalį Amerikos rinkoje. One Box Shave sako:
- 4 peiliukai? Ar tu rimtai? Kam to reikia – skutimosi kokybės tai nepagerina. Specialiai parinktas kremas, kvapas ir kokybiškas skustuvas su dviem peiliukais išsprendžia daug daugiau problemų nei tie kvaili 4 Gillette peiliukai! Ar greitai sulauksime 10?
Taip keičiasi pasaulis. „Unilever“ teigia, kad jie turi puikią IT sistemą, leidžiančią tai padaryti. Galų gale tai atrodo kaip koncepcija Laikas patekti į rinką, apie kurią dar niekas nekalbėjo.
„Time-to-market“ esmė nėra tai, kaip dažnai diegiame. Dažnai galite įdiegti, tačiau išleidimo ciklai bus ilgi. Jei trijų mėnesių išleidimo ciklai dedami vienas ant kito, perkeliant juos savaite, paaiškėja, kad įmonė diegia kartą per savaitę. O nuo idėjos iki galutinio įgyvendinimo praeina 3 mėnesiai.
Laikas patekti į rinką – tai laiko nuo idėjos iki galutinio įgyvendinimo sutrumpinimas.
Šiuo atveju programinė įranga sąveikauja su rinka. Taip One Box Shave svetainė sąveikauja su klientu. Juose nėra pardavėjų – tik svetainė, kurioje lankytojai spustelėja ir palieka pageidavimus. Atitinkamai, kažkas naujo turi būti nuolat skelbiama svetainėje ir atnaujinama pagal pageidavimus. Pavyzdžiui, Pietų Korėjoje skutasi kitaip nei Rusijoje, o joms patinka ne pušų, o, pavyzdžiui, morkų ir vanilės kvapas.
Kadangi reikia greitai keisti svetainės turinį, programinės įrangos kūrimas labai keičiasi. Per programinę įrangą turime išsiaiškinti, ko nori klientas. Anksčiau mes to išmokome naudodamiesi kai kuriais aplinkiniais būdais, pavyzdžiui, per verslo valdymą. Tada suprojektavome, sudėjome reikalavimus į IT sistemą ir viskas buvo šaunu. Dabar viskas kitaip – programinę įrangą kuria visi, kurie dalyvauja procese, įskaitant inžinierius, nes per technines specifikacijas jie sužino, kaip veikia rinka, ir dalijasi savo įžvalgomis su verslu.
Pavyzdžiui, „Qik“ staiga sužinojome, kad žmonėms labai patiko į serverį įkelti kontaktų sąrašus, ir jie mums pateikė programą. Iš pradžių apie tai negalvojome. Klasikinėje įmonėje visi būtų nusprendę, kad tai klaida, nes specifikacijoje nebuvo nurodyta, kad ji turėtų puikiai veikti ir paprastai buvo įdiegta ant kelio, jie būtų išjungę funkciją ir pasakę: „Niekam to nereikia, svarbiausia, kad veiktų pagrindinis funkcionalumas.“ . O technologijų įmonė mato tai kaip galimybę ir pagal tai pradeda keisti programinę įrangą.
1968 m. vizionierius Melvinas Conway'us suformulavo tokią idėją.
Sistemą kurianti organizacija yra suvaržyta dizaino, atkartojančio tos organizacijos komunikacijos struktūrą.
Išsamiau, norėdami gaminti kitokio tipo sistemas, turite turėti ir komunikacijos struktūrą kito tipo įmonėje. Jei jūsų komunikacijos struktūra yra aukščiausia hierarchinė, tai neleis jums sukurti sistemų, kurios galėtų užtikrinti labai aukštą laiko iki rinkos rodiklį.
Skaityti vienas gali . Tai svarbu norint suprasti DevOps kultūrą ar filosofiją, nes Vienintelis dalykas, kuris iš esmės keičiasi „DevOps“, yra komunikacijos tarp komandų struktūra.
Proceso požiūriu, prieš DevOps visi etapai: analizė, kūrimas, testavimas, veikimas buvo linijiniai.
DevOps atveju visi šie procesai vyksta vienu metu.
Laikas patekti į rinką yra vienintelis būdas tai padaryti. Žmonėms, kurie dirbo senajame procese, tai atrodo šiek tiek kosmiškai ir apskritai taip.
Taigi kodėl jums reikia „DevOps“?
Skaitmeninio produkto kūrimui. Jei jūsų įmonė neturi skaitmeninio produkto, DevOps nereikia – tai labai svarbu.
„DevOps“ įveikia nuoseklios programinės įrangos gamybos greičio apribojimus. Joje visi procesai vyksta vienu metu.
Sunkumas didėja. Kai „DevOps“ evangelistai jums sako, kad jums bus lengviau išleisti programinę įrangą, tai yra nesąmonė.
Naudojant „DevOps“, viskas tik sudėtingės.
Konferencijoje „Avito“ stende galėjote pamatyti, ką reiškia „Docker“ konteinerio dislokavimas – nereali užduotis. Sudėtingumas tampa pernelyg didelis; jūs turite žongliruoti daug kamuoliukų vienu metu.
„DevOps“ visiškai pakeičia procesą ir organizaciją įmonėje — tiksliau, keičiasi ne DevOps, o skaitmeninis produktas. Norėdami patekti į „DevOps“, vis tiek turite visiškai pakeisti šį procesą.
Klausimai specialistui
Ką tu turi? Klausimai, kuriuos galite užduoti sau dirbdami įmonėje ir tobulėdami kaip specialistas.
Ar turite skaitmeninio produkto kūrimo strategiją? Jei yra, tai jau gerai. Tai reiškia, kad jūsų įmonė juda link „DevOps“.
Ar jūsų įmonė jau kuria skaitmeninį produktą? Tai reiškia, kad galite pakilti dar vienu lygiu ir daryti dalykus įdomiau – vėlgi DevOps požiūriu. Aš kalbu tik šiuo požiūriu.
Ar jūsų įmonė yra viena iš rinkos lyderių skaitmeninių produktų nišoje? „Spotify“, „Yandex“, „Uber“ yra įmonės, kurios šiuo metu yra technologijų pažangos viršūnėje.
Užduokite sau šiuos klausimus ir, jei visi atsakymai yra neigiami, galbūt neturėtumėte daryti „DevOps“ šioje įmonėje. Jei DevOps tema tikrai jus domina, gal... vertėtų pereiti į kitą įmonę? Jei jūsų įmonė nori patekti į „DevOps“, bet į visus klausimus atsakėte „Ne“, tai yra kaip tas gražuolis raganosis, kuris niekada nepasikeis.
Organizacija
Kaip sakiau, pagal Conway dėsnį keičiasi įmonės organizacija. Pradėsiu nuo to, kas trukdo „DevOps“ prasiskverbti į įmonės vidų organizaciniu požiūriu.
„Šulinių“ problema
Angliškas žodis „Silo“ čia išverstas į rusų kalbą kaip „gerai“. Šios problemos esmė ta tarp komandų nesikeičiama informacija. Kiekviena komanda gilinasi į savo žinias, nekurdama bendro navigacijos žemėlapio.
Tam tikra prasme tai man primena žmogų, kuris ką tik atvyko į Maskvą ir dar nemoka naršyti metro žemėlapyje. Maskviečiai paprastai puikiai žino savo vietovę, o visoje Maskvoje gali naršyti naudodamiesi metro žemėlapiu. Kai pirmą kartą atvykstate į Maskvą, jūs neturite šio įgūdžio ir esate tiesiog dezorientuotas.
„DevOps“ siūlo įveikti šį dezorientacijos momentą ir visiems skyriams dirbti kartu, kad sukurtų bendrą sąveikos žemėlapį.
Tam trukdo du veiksniai.
Įmonės valdymo sistemos pasekmė. Jis pastatytas atskiruose hierarchiniuose „šuliniuose“. Pavyzdžiui, įmonėse, kurios palaiko šią sistemą, yra tam tikri KPI. Kita vertus, žmogaus, kuriam sunku peržengti savo kompetencijos ribas ir naršyti visoje sistemoje, smegenys trukdo. Tiesiog nepatogu. Įsivaizduokite, kad esate Bankoko oro uoste – greitai nesusirasite. „DevOps“ taip pat sunku naršyti, todėl žmonės sako, kad norint ten patekti, reikia rasti vadovą.
Tačiau svarbiausia yra tai, kad DevOps dvasios persmelkto, Fowler ir dar krūvą kitų knygų perskaitėm inžinieriaus „šulinių“ problema išreiškiama tuo, kad „šuliniai“ neleidžia daryti „akivaizdžių“ dalykų. Mes dažnai susirenkame po „DevOps Moscow“, kalbamės ir žmonės skundžiasi:
– Tiesiog norėjome paleisti CI, bet paaiškėjo, kad vadovybei to nereikia.
Taip atsitinka būtent todėl CI и Nuolatinis pristatymo procesas yra ant daugelio tyrimų ribos. Tiesiog neįveikę „šulinių“ problemos organizaciniame lygmenyje, negalėsite judėti į priekį, kad ir ką darytumėte ir kad ir kaip būtų liūdna.
Kiekvienas proceso dalyvis įmonėje: backend ir frontend kūrėjai, testavimas, DBA, eksploatavimas, tinklas, kasiasi savo kryptimi, ir niekas neturi bendro žemėlapio, išskyrus vadybininką, kuris kažkaip juos stebi ir valdo naudodamas „padalinti“. ir užkariauti“ metodą.
Žmonės kovoja dėl kokių nors žvaigždžių ar vėliavų, visi kasa savo kompetenciją.
Dėl to, kai iškyla užduotis visa tai sujungti ir nutiesti bendrą vamzdyną, o dėl žvaigždžių ir vėliavų kovoti nebereikia, kyla klausimas – ką vis dėlto daryti? Reikia kažkaip susitarti, bet niekas mokykloje mūsų nemokė, kaip tai daryti. Mus mokė nuo mokyklos laikų: aštunta klasė – oho! - palyginti su septinta klase! Čia tas pats.
Ar jūsų įmonėje taip yra?
Norėdami tai patikrinti, galite užduoti sau šiuos klausimus.
Ar komandos naudoja bendrus įrankius ir prisideda prie tų bendrų įrankių pakeitimų?
Kaip dažnai komandos persitvarko – kai kurie specialistai iš vienos komandos pereina į kitą komandą? DevOps aplinkoje tai tampa įprasta, nes kartais žmogus tiesiog negali suprasti, ką daro kita kompetencijos sritis. Jis persikelia į kitą skyrių, dirba ten dvi savaites, kad sukurtų orientacijos ir bendravimo su šiuo skyriumi žemėlapį.
Ar įmanoma suformuoti pokyčių komitetą ir pakeisti dalykus? O gal tam reikia tvirtos aukščiausios vadovybės ir krypties rankos? Neseniai feisbuke rašiau, kaip vienas mažai žinomas bankas per pavedimus diegia įrankius: parašome užsakymą, įgyvendiname metus, o kas bus. Tai, žinoma, ilga ir liūdna.
Kiek svarbu vadovams gauti asmeninius pasiekimus neatsižvelgiant į įmonės pasiekimus?
Jei į šiuos klausimus atsakysite sau, taps aiškiau, ar turite tokią problemą savo įmonėje.
Infrastruktūra kaip kodas
Išsprendus šią problemą, įvyksta pirmoji svarbi praktika, be kurios sunku tobulėti naudojant „DevOps“. infrastruktūra kaip kodas.
Dažniausiai infrastruktūra kaip kodas suvokiama taip:
— Automatizuosime viską bash, apsisaugokime scenarijais, kad administratoriams būtų mažiau rankinio darbo!
Bet tai netiesa.
Infrastruktūra kaip kodas reiškia, kad IT sistemą, su kuria dirbate, aprašote kodo forma, kad nuolat suprastumėte jos būseną.
Kartu su kitomis komandomis sukuriate žemėlapį kodo pavidalu, kurį visi gali suprasti ir naršyti bei naršyti. Nesvarbu, su kuo tai daroma – „Chef“, „Ansible“, „Salt“ ar naudojant YAML failus „Kubernetes“ – nėra jokio skirtumo.
Konferencijoje kolega iš 2GIS papasakojo, kaip Kubernetes sukūrė savo vidinį dalyką, kuriame aprašoma atskirų sistemų struktūra. Norint aprašyti 500 sistemų, jiems reikėjo atskiro įrankio, kuris generuoja šį aprašymą. Kai yra šis aprašymas, visi gali tarpusavyje pasitikrinti, stebėti pokyčius, kaip tai pakeisti ir tobulinti, ko trūksta.
Sutikite, atskiri bash scenarijai paprastai nesuteikia tokio supratimo. Vienoje iš įmonių, kurioje dirbau, buvo net „rašyti tik“ scenarijaus pavadinimas – kai scenarijus parašytas, bet jo perskaityti nebeįmanoma. Manau, tai ir tau pažįstama.
Infrastruktūra tokia, kokia yra kodas kodas, apibūdinantis esamą infrastruktūros būklę. Daugelis produktų, infrastruktūros ir paslaugų komandų dirba kartu su šiuo kodu, ir, svarbiausia, jos visos turi suprasti, kaip šis kodas iš tikrųjų veikia.
Kodas tvarkomas pagal geriausią kodo praktiką: bendras kūrimas, kodo peržiūra, XP programavimas, testavimas, ištraukimo užklausos, CI kodų infrastruktūrai – visa tai tinka ir galima naudoti.
Kodas tampa bendra kalba visiems inžinieriams.
Infrastruktūros keitimas kode neužima daug laiko. Taip, infrastruktūros kodas taip pat gali turėti techninių skolų. Paprastai komandos su tuo susiduria praėjus pusantrų metų po to, kai pradėjo diegti „infrastruktūrą kaip kodą“ daugybės scenarijų ar net Ansible pavidalu, kuriuos rašo kaip spagečių kodą, taip pat į mišinį įmeta bash scenarijus!
Svarbu,: Jei dar neišbandėte šios medžiagos, prisiminkite tai Ansible nėra baisus! Atidžiai perskaitykite dokumentus, išstudijuokite, ką jie apie tai rašo.
Infrastruktūra kaip kodas yra infrastruktūros kodo atskyrimas į atskirus sluoksnius.
Mūsų įmonėje išskiriame 3 pagrindinius sluoksnius, kurie yra labai aiškūs ir paprasti, tačiau jų gali būti ir daugiau. Galite peržiūrėti savo infrastruktūros kodą ir pasakyti, ar turite šią sąlygą, ar ne. Jei sluoksniai nėra paryškinti, reikia skirti šiek tiek laiko ir šiek tiek pertvarkyti.
bazinis sluoksnis - taip sukonfigūruojama OS, atsarginės kopijos ir kiti žemo lygio dalykai, pavyzdžiui, kaip „Kubernetes“ yra įdiegtas pagrindiniame lygyje.
Aptarnavimo lygis - tai paslaugos, kurias teikiate kūrėjui: registravimas kaip paslauga, stebėjimas kaip paslauga, duomenų bazė kaip paslauga, balansavimo priemonė kaip paslauga, eilė kaip paslauga, nuolatinis pristatymas kaip paslauga - daugybė paslaugų, kurias teikia atskiros komandos. gali suteikti vystymuisi. Visa tai turi būti aprašyta atskiruose jūsų konfigūracijos valdymo sistemos moduliuose.
Sluoksnis, kuriame atliekamos programos ir aprašoma, kaip jie išsiskleis ant ankstesnių dviejų sluoksnių.
Kontroliniai klausimai
Ar jūsų įmonė turi bendrą infrastruktūros saugyklą? Ar tvarkote technines skolas savo infrastruktūroje? Ar infrastruktūros saugykloje naudojate kūrimo praktiką? Ar jūsų infrastruktūra suskirstyta į sluoksnius? Galite patikrinti Base-service-APP diagramą. Kaip sunku pakeisti?
Jei patyrėte, kad pakeitimams atlikti prireikė pusantros paros, tai reiškia, kad turite techninių skolų ir turite su ja dirbti. Savo infrastruktūros kodekse ką tik aptikote techninį skolų grėblį. Prisimenu daug tokių istorijų, kai norint pakeisti kokius nors CCTL reikia perrašyti pusę infrastruktūros kodo, nes kūrybiškumas ir noras viską automatizuoti privedė prie to, kad visur viskas aprūdyta, nuimtos visos rankenos, būtina refaktorizuoti.
Nepertraukiamas pristatymas
Palyginkime debetą su kreditu. Pirmiausia aprašoma infrastruktūra, kuri gali būti gana paprasta. Nereikia visko išsamiai apibūdinti, tačiau būtinas pagrindinis aprašymas, kad galėtumėte su juo dirbti. Priešingu atveju neaišku, ką toliau daryti su nuolatiniu pristatymu. Visos šios praktikos atsiskleidžia vienu metu, kai ateinate į „DevOps“, tačiau viskas prasideda nuo supratimo, ką turite ir kaip tai valdyti. Būtent tokia yra infrastruktūros kaip kodo praktika.
Kai tampa aišku, kad jį turite ir kaip jį valdyti, pradedate sugalvoti, kaip kuo greičiau išsiųsti kūrėjo kodą į gamybą. Turiu omenyje kartu su kūrėju - mes prisimename apie „šulinių“ problemą, tai yra, tai sugalvoja ne pavieniai žmonės, o komanda.
Kai esame su Vania Evtukhovich pamačiau pirmąją knygą Jez Humble ir autorių grupės "Nuolatinis pristatymas", kuris buvo išleistas 2009 m., ilgai galvojome, kaip išversti jo pavadinimą į rusų kalbą. Jie norėjo jį išversti kaip „nuolat pristatyti“, bet, deja, jis buvo išverstas kaip „Nuolatinis pristatymas“. Man atrodo, kad mūsų pavadinime yra kažkas rusiško, su spaudimu.
Nuolat pristatomos priemonės
Produkto saugykloje esantį kodą visada galima atsisiųsti į gamybą. Jis gali ir nenusileisti, bet visada tam pasiruošęs. Atitinkamai, jūs visada rašote kodą su sunkiai paaiškinamu nerimo jausmu po uodegos kaulu. Jis dažnai pasirodo, kai išleidžiate infrastruktūros kodą. Šis tam tikro nerimo jausmas turėtų būti – jis suaktyvina smegenų procesus, leidžiančius kodą parašyti kiek kitaip. Tai turėtų būti įrašyta plėtros taisyklėse.
Norint nuosekliai teikti, reikia artefakto formato, kuris veikia infrastruktūros platformoje. Jei per infrastruktūros platformą mesti įvairių formatų „gyvybės atliekas“, ji tampa vieninga, ją sunku išlaikyti, atsiranda techninių skolų problema. Reikia suderinti artefakto formatą – tai taip pat kolektyvinė užduotis: mes visi turime susiburti, papurtyti smegenis ir sugalvoti šį formatą.
Artefaktas nuolat tobulinamas ir keičiamas, kad atitiktų gamybos aplinką, kai jis juda tiekimo vamzdynu. Kai artefaktas juda vamzdynu, jis nuolat susiduria su tam tikrais nepatogiais dalykais, panašiais į tai, su kuo susiduria artefaktas, kurį įdėjote į gamybą. Jei klasikiniame kūrime tai atlieka sistemos administratorius, kuris atlieka diegimą, tai „DevOps“ procese taip nutinka nuolat: čia jie išbandė su kai kuriais testais, čia jie įmetė į „Kubernetes“ klasterį, kuris yra daugmaž panašus. į gamybą, tada staiga jie pradėjo apkrovos testavimą.
Tai šiek tiek primena Pac-Man žaidimą – artefaktas pergyvena tam tikrą istoriją. Tuo pačiu metu svarbu kontroliuoti, ar kodas iš tikrųjų eina per istoriją ir ar jis kaip nors susijęs su jūsų produkcija. Istorijos iš gamybos gali būti įtrauktos į Continuous Delivery procesą: buvo taip, kai kažkas nukrito, dabar tiesiog užprogramuokime šį scenarijų sistemos viduje. Kiekvieną kartą, kai kodas taip pat bus vykdomas pagal šį scenarijų, ir kitą kartą su šia problema nesusidursite. Sužinosite apie tai daug anksčiau, nei pasieks jūsų klientą.
Įvairios diegimo strategijos. Pavyzdžiui, naudojate AB testavimą arba kanalų diegimą, norėdami skirtingai išbandyti kodą skirtinguose klientuose, gauti informacijos apie tai, kaip kodas veikia, ir daug anksčiau nei tada, kai jis išleidžiamas 100 milijonų vartotojų.
„Nuoseklus pristatymas“ atrodo taip.
Pristatymo procesas Dev, CI, Test, PreProd, Prod nėra atskira aplinka, tai yra etapai arba stotys su ugniai atspariomis sumomis, per kurias praeina jūsų artefaktas.
Jei turite infrastruktūros kodą, kuris apibūdinamas kaip „Base Service APP“, tai padeda nepamirškite visų scenarijųir užsirašykite juos kaip šio artefakto kodą, reklamuoti artefaktą ir pakeiskite jį eidami.
Savęs patikrinimo klausimai
Laikas nuo funkcijos aprašymo iki išleidimo į gamybą 95% atvejų yra trumpesnis nei savaitė? Ar artefakto kokybė gerėja kiekviename dujotiekio etape? Ar yra kokia nors istorija, kurią tai išgyvena? Ar naudojate skirtingas diegimo strategijas?
Jei visi atsakymai yra taip, vadinasi, esate nepaprastai šaunus! Rašykite savo atsakymus komentaruose - džiaugsiuosi).
Susisiekite su Mumis
Tai pati sunkiausia praktika. DevOpsConf konferencijoje kolega iš Infobip, kalbėdamas apie tai, kiek sutriko savo žodžiuose, nes tai tikrai labai sudėtinga praktika apie tai, kad reikia viską stebėti!
Pavyzdžiui, labai seniai, kai dirbau „Qik“ ir supratome, kad reikia viską stebėti. Mes tai padarėme ir dabar „Zabbix“ turime 150 000 prekių, kurios yra nuolat stebimos. Buvo baisu, techninis direktorius susuko pirštą į smilkinį:
- Vaikinai, kodėl prievartaujate serverį su kažkuo neaišku?
Bet tada įvyko incidentas, kuris parodė, kad tai tikrai labai šauni strategija.
Viena iš servisų pradėjo nuolatos strigti. Iš pradžių jis nesugriuvo, kas įdomu, kodas ten nebuvo pridėtas, nes tai buvo pagrindinis brokeris, kuris praktiškai neturėjo verslo funkcionalumo – tiesiog siuntė žinutes tarp atskirų tarnybų. Paslauga nepasikeitė 4 mėnesius ir staiga ji pradėjo strigti su klaida „Segmentacijos gedimas“.
Buvome šokiruoti, atidarėme savo diagramas „Zabbix“ ir paaiškėjo, kad prieš pusantros savaitės užklausų elgesys API tarnyboje, kurią naudoja šis brokeris, labai pasikeitė. Tada pamatėme, kad pasikeitė tam tikro tipo pranešimų siuntimo dažnis. Vėliau sužinojome, kad tai buvo „Android“ klientai. Mes klausėme:
– Vaikinai, kas jums nutiko prieš pusantros savaitės?
Atsakydami išgirdome įdomią istoriją apie tai, kaip jie pertvarkė vartotojo sąsają. Mažai tikėtina, kad kas nors iš karto pasakys, kad pakeitė HTTP biblioteką. „Android“ klientams tai tarsi muilo keitimas vonioje – jie tiesiog neprisimena. Dėl to po 40 minučių pokalbio sužinojome, kad jie pakeitė HTTP biblioteką, o jos numatytieji laikai pasikeitė. Dėl to API serverio srauto elgsena pasikeitė, o tai sukėlė situaciją, dėl kurios brokeryje kilo lenktynės ir jis pradėjo strigti.
Be gilaus stebėjimo paprastai neįmanoma to atidaryti. Jei organizacija vis dar turi „šulinių“ problemą, kai visi meta pinigus vieni kitiems, tai gali gyvuoti metų metus. Jūs tiesiog paleidžiate serverį iš naujo, nes problemos išspręsti neįmanoma. Kai stebite, sekate, sekate visus turimus įvykius ir naudojate stebėjimą kaip testavimą - parašykite kodą ir iš karto nurodykite, kaip jį stebėti, taip pat kodo pavidalu (mes jau turime infrastruktūrą kaip kodą), viskas tampa aišku, kaip ant delno. Net tokios sudėtingos problemos lengvai atsekamos.
Surinkite visą informaciją apie tai, kas nutinka artefaktui kiekviename pristatymo proceso etape – ne gamyboje.
Įkelk stebėjimą į CI, ten jau bus matomi kai kurie pagrindiniai dalykai. Vėliau juos pamatysite „Test“, „PredProd“ ir apkrovos bandymuose. Rinkti informaciją visais etapais, ne tik metriką, statistiką, bet ir žurnalus: kaip aplikacija pasirodė, anomalijas – surinkite viską.
Priešingu atveju bus sunku tai išsiaiškinti. Jau sakiau, kad „DevOps“ yra sudėtingesnis. Norėdami susidoroti su šiuo sudėtingumu, turite turėti įprastą analizę.
Klausimai savikontrolei
Ar jūsų stebėjimas ir registravimas yra kūrimo įrankis? Ar rašydami kodą jūsų kūrėjai, įskaitant jus, galvoja, kaip jį stebėti?
Ar girdite apie klientų problemas? Ar geriau suprantate klientą iš stebėjimo ir registravimo? Ar geriau suprantate sistemą iš stebėjimo ir registravimo? Ar keičiate sistemą vien todėl, kad pamatėte, kad sistemos tendencija auga ir suprantate, kad dar po 3 savaičių viskas mirs?
Kai turėsite šiuos tris komponentus, galėsite pagalvoti, kokią infrastruktūros platformą turite savo įmonėje.
Infrastruktūros platforma
Esmė ne ta, kad tai yra skirtingų įrankių rinkinys, kurį turi kiekviena įmonė.
Infrastruktūros platformos esmė ta, kad visos komandos naudoja šiuos įrankius ir kuria kartu.
Akivaizdu, kad yra atskiros komandos, atsakingos už atskirų infrastruktūros platformos dalių kūrimą. Tačiau tuo pat metu kiekvienas inžinierius yra atsakingas už infrastruktūros platformos kūrimą, veikimą ir reklamą. Vidiniame lygmenyje tai tampa įprastu įrankiu.
Visos komandos kuria infrastruktūros platformą ir rūpestingai traktuoja ją kaip savo IDE. Savo IDE įdiegiate skirtingus papildinius, kad viskas būtų gražu ir greita, ir sukonfigūruojate sparčiuosius klavišus. Atsidarius „Sublime“, „Atom“ ar „Visual Studio Code“, pasipila kodo klaidos ir supranti, kad dirbti iš viso neįmanoma, iškart nuliūdi ir bėgate taisyti savo IDE.
Taip pat elkitės su savo infrastruktūros platforma. Jei suprantate, kad kažkas negerai, palikite užklausą, jei negalite patys to ištaisyti. Jei yra kažkas paprasto, suredaguokite patys, atsiųskite užklausą, vaikinai tai apsvarstys ir pridės. Tai šiek tiek kitoks požiūris į inžinerinius įrankius kūrėjo galvoje.
Infrastruktūros platforma užtikrina artefakto perdavimą iš kūrimo klientui nuolat gerinant kokybę. IP yra užprogramuotas su istorijų rinkiniu, kuris nutinka gamybiniam kodui. Per ilgus kūrimo metus šių istorijų yra daug, kai kurios iš jų yra unikalios ir susijusios tik su jumis – jų negalima ieškoti „Google“.
Šiuo metu infrastruktūros platforma tampa jūsų konkurenciniu pranašumu, nes jame yra kažkas, ko nėra konkurento įrankyje. Kuo gilesnis jūsų IP, tuo didesnis jūsų konkurencinis pranašumas pateikimo į rinką požiūriu. Pasirodo čia pardavėjo užrakto problema: Galite naudoti kažkieno platformą, bet pasinaudoję kažkieno patirtimi nesuprasite, kaip tai aktualu jums. Taip, ne kiekviena įmonė gali sukurti tokią platformą kaip „Amazon“. Tai sudėtinga linija, kurioje įmonės patirtis yra susijusi su jos padėtimi rinkoje, ir jūs negalite ten naudoti pardavėjo užrakto. Apie tai taip pat svarbu pagalvoti.
Schema
Tai pagrindinė infrastruktūros platformos schema, kuri padės nustatyti visas praktikas ir procesus „DevOps“ įmonėje.
Pažiūrėkime, iš ko jis susideda.
Išteklių orkestravimo sistema, kuri teikia procesorių, atmintį, diską programoms ir kitoms paslaugoms. Be to - žemo lygio paslaugas: stebėjimas, registravimas, CI/CD variklis, artefaktų saugykla, infrastruktūra kaip sistemos kodas.
Aukštesnio lygio paslaugos: duomenų bazė kaip paslauga, eilės kaip paslauga, Load Balance kaip paslauga, vaizdo dydžio keitimas kaip paslauga, Big Data gamykla kaip paslauga. Be to - vamzdynas, kuris jūsų klientui pateikia nuolat keičiamą kodą.
Jūs gaunate informaciją apie tai, kaip jūsų programinė įranga veikia klientui, ją pakeičiate, vėl pateikiate šį kodą, gaunate informaciją – taip nuolat kuriate tiek infrastruktūros platformą, tiek savo programinę įrangą.
Diagramoje tiekimo vamzdynas susideda iš daugelio etapų. Bet tai yra schema, pateikta kaip pavyzdys - nereikia kartoti po vieną. Etapai sąveikauja su paslaugomis taip, lyg tai būtų paslaugos – kiekviena platformos dalis turi savo istoriją: kaip paskirstomi ištekliai, kaip paleidžiama programa, dirba su ištekliais, stebima ir keičiasi.
Svarbu suprasti, kad kiekviena platformos dalis neša istoriją, ir paklauskite savęs, kokią istoriją neša ši plyta, galbūt ją reikėtų išmesti ir pakeisti trečiosios šalies paslauga. Pavyzdžiui, ar galima vietoj plytos sumontuoti Okmeter? Galbūt vaikinai jau išplėtojo šią patirtį daug labiau nei mes. Bet gal ir ne – galbūt turime unikalių žinių, turime įdiegti „Prometheus“ ir jį toliau plėtoti.
Platformos sukūrimas
Tai sudėtingas komunikacijos procesas. Kai turite pagrindinę praktiką, pradedate bendrauti tarp skirtingų inžinierių ir specialistų, kurie kuria reikalavimus ir standartus, ir nuolat keičia juos į skirtingus įrankius ir metodus. Čia svarbi kultūra, kurią turime „DevOps“.
Su kultūra viskas labai paprasta - tai apie bendradarbiavimą ir bendravimą, tai yra noras dirbti vieni su kitais bendroje srityje, noras kartu valdyti vieną instrumentą. Jokio raketų mokslo čia nėra – viskas labai paprasta, banalu. Pavyzdžiui, mes visi gyvename įėjime ir laikome švarą – toks kultūros lygis.
Ką tu turi?
Vėlgi, klausimai, kuriuos galite užduoti sau.
Ar infrastruktūros platforma skirta? Kas atsakingas už jo plėtrą? Ar suprantate savo infrastruktūros platformos konkurencinius pranašumus?
Turite nuolat sau užduoti šiuos klausimus. Jei ką nors galima perkelti į trečiųjų šalių paslaugas, tai turėtų būti perkelta; jei trečiosios šalies paslauga pradeda blokuoti jūsų judėjimą, turite sukurti sistemą savyje.
Taigi, „DevOps“...
... tai sudėtinga sistema, joje turi būti:
- Skaitmeninis produktas.
- Verslo moduliai, kuriantys šį skaitmeninį produktą.
- Produktų komandos, kurios rašo kodą.
- Nuolatinio pristatymo praktika.
- Platformos kaip paslauga.
- Infrastruktūra kaip paslauga.
- Infrastruktūra kaip kodas.
- Atskiros praktikos patikimumui palaikyti, integruotos į „DevOps“.
- Visa tai apibūdinanti grįžtamojo ryšio praktika.
Galite naudoti šią diagramą, pabrėždami joje tai, ką jau turite savo įmonėje tam tikra forma: ar ji sukurta ar dar turi būti tobulinama.
Po poros savaičių baigsis . kaip RIT++ dalis. Ateikite į konferenciją, kurioje rasite daug puikių pranešimų apie nuolatinį pristatymą, infrastruktūrą kaip kodą ir „DevOps“ transformaciją. , paskutinis kainos terminas yra gegužės 20 d
Šaltinis: www.habr.com