De definysje fan DevOps is heul kompleks, dus wy moatte de diskusje deroer elke kear opnij begjinne. D'r binne tûzen publikaasjes oer dit ûnderwerp allinich op Habré. Mar as jo dit lêze, wite jo wierskynlik wat DevOps is. Want ik bin it net. Goeie myn namme is Alexander Titov (@), en wy sille gewoan oer DevOps prate en ik sil myn ûnderfining diele.
Ik haw al in lange tiid tocht oer hoe't ik myn ferhaal nuttich meitsje kin, dus d'r sille hjir in protte fragen wêze - dyjingen dy't ik mysels freegje en dyjingen dy't ik de kliïnten fan ús bedriuw freegje. Troch dizze fragen te beantwurdzjen wurdt it begryp better. Ik sil jo fertelle wêrom DevOps nedich is út myn eachpunt, wat it is, wer, út myn eachpunt, en hoe te begripen dat jo wer nei DevOps gean út myn eachpunt. It lêste punt sil wêze fia fragen. Troch se foar josels te beantwurdzjen, kinne jo begripe oft jo bedriuw nei DevOps giet of dat d'r op ien of oare manier problemen binne.
Op in stuit ried ik de weagen fan fúzjes en oernames. Earst wurke ik foar in lyts startup neamd Qik, doe waard it kocht troch in wat grutter bedriuw neamd Skype, dat doe kocht waard troch in wat grutter bedriuw neamd Microsoft. Op dat stuit begon ik te sjen hoe't it idee fan DevOps transformearre yn bedriuwen fan ferskate grutte. Dêrnei waard ik ynteressearre yn it besjen fan DevOps út in merk eachpunt, en myn kollega's en ik stiften it bedriuw Express 42. Foar 6 jier no hawwe wy bewege lâns de weagen fan 'e merk.
Ik bin ûnder oare ien fan 'e organisatoaren fan' e DevOps Moskou-mienskip en de organisator fan DevOps-Days 2017, mar ik haw 2018 net organisearre. Express 42 wurket mei in protte bedriuwen. Wy groeie DevOps dêr, sjogge hoe't it bart, lûke konklúzjes, analysearje, fertelle elkenien ús konklúzjes, en traine minsken yn DevOps-praktiken. Yn 't algemien dogge wy ús bêst om ús ûnderfining en ekspertize yn dit ferbân te fergrutsjen.
Wêrom DevOps
De earste fraach dy't elkenien spoeket en altyd is - wêrom? In protte minsken tinke dat DevOps gewoan automatisearring is as in ferlykber ding dat elk bedriuw al hie.
- Wy hiene trochgeande yntegraasje - dit betsjut dat wy al DevOps hiene, en wêrom is al dit spul nedich? Se hawwe wille yn it bûtenlân, mar se stopje ús om te wurkjen!
Oer 9 jier ûntwikkeling fan 'e mienskip en metodyk is it al dúdlik wurden dat dit noch altyd gjin marketingglitter is, mar it is noch net hielendal dúdlik wêrom't it nedich is. Lykas elk ark en proses, hat DevOps spesifike doelen dy't it úteinlik berikt.
Dit alles komt troch it feit dat de wrâld feroaret. Hy giet fuort fan de ûndernimmingsbenadering, as bedriuwen streekrjocht nei in dream gean, sa’t ús Sint-Petersburchske klassiker song, fan punt A nei punt B neffens in bepaalde strategy, mei dêrfoar in bepaalde struktuer boud.
Yn prinsipe moat alles yn IT neffens dizze oanpak boud wurde. Hjir wurdt IT eksklusyf brûkt om prosessen te automatisearjen.
Automatisearring feroaret net faak, want wannear't in bedriuw ûnder in goed tûke rut giet, wat is der dan te feroarjen? It wurket - net oanreitsje it. No feroarje oanpak yn 'e wrâld, en de iene neamd Agile suggerearret dat einpunt B net direkt sichtber is.
As in bedriuw troch de merk giet, wurket mei in klant, ûndersiket it konstant de merk en feroaret it einpunt B. Boppedat feroaret it faker it bedriuw syn rjochting, hoe suksesfolle it op it lêst is, om't it mear merk kiest niches.
De strategy wurdt oantoand troch in nijsgjirrich bedriuw dat ik koartlyn leard oer. One Box Shave is in tsjinstferliening foar abonneminten foar skearapparaten en skeeraccessoires yn in doaze. Se witte hoe't se har "doaze" kinne oanpasse foar ferskate kliïnten. Dit wurdt dien troch in bepaalde software, dy't dan de bestelling stjoert nei it Koreaanske fabryk dat it produkt produsearret.
Dit produkt waard kocht troch Unilever foar $ 1 miljard. It konkurrearret no mei Gillette en hat in signifikant oandiel fan konsuminten yn 'e Amerikaanske merk ôfnommen. One Box Shave sizze:
- 4 blêden? Binne jo serieus? Wêrom hawwe jo dit nedich - it ferbetteret de kwaliteit fan 'e scheerbeurt net. In spesjaal selektearre crème, geur en in heechweardich skeermes mei twa blêden losse folle mear problemen op as dy domme 4 Gillette blêden! Sille wy gau nei 10 komme?
Dit is hoe't de wrâld feroaret. Unilever beweare dat se in koel IT-systeem hawwe wêrmei jo dit kinne dwaan. Uteinlik liket it in konsept Tiid-to-merk, dêr't nimmen al oer praat hat.
It punt fan Time-to-market is net hoe faak wy ynsette. Jo kinne faak ynsette, mar de frijlittingssyklusen sille lang wêze. As trije-moanne release cycles wurde boppe op elkoar, ferskowing se troch in wike, docht bliken dat it bedriuw liket te ynsette ien kear yn 'e wike. En fan it idee oant de definitive ymplemintaasje duorret it 3 moannen.
Time-to-market giet oer it minimalisearjen fan de tiid fan idee oant definitive ymplemintaasje.
Yn dit gefal, software ynteraksje mei de merk. Dit is hoe't de One Box Shave-webside ynteraksje mei de klant. Se hawwe gjin ferkeapers - gewoan in webside wêr't besikers klikke en winsken litte. Dêrtroch moat hieltyd wat nijs op 'e side pleatst wurde en neffens winsken bywurke wurde. Bygelyks, yn Súd-Korea skearje se oars as yn Ruslân, en se hâlde fan de geur net fan pine, mar bygelyks fan woartels en vanille.
Om't it needsaaklik is om de ynhâld fan 'e side fluch te feroarjen, feroaret softwareûntwikkeling sterk. Troch software moatte wy útfine wat de klant wol. Earder learden wy dit troch guon rotondes, bygelyks fia bedriuwsbehear. Doe hawwe wy it ûntworpen, de easken yn it IT-systeem setten, en alles wie cool. No is it oars - software is ûntwurpen troch elkenien dy't belutsen is by it proses, ynklusyf yngenieurs, om't se troch technyske spesifikaasjes leare hoe't de merk wurket en ek har ynsjoch diele mei it bedriuw.
Bygelyks, by Qik learden wy ynienen dat minsken echt leuk wiene om kontaktlisten op te laden nei de server, en se levere ús in applikaasje. Yn it earstoan ha wy der net oer neitocht. Yn in klassyk bedriuw soe elkenien besletten hawwe dat dit in brek wie, om't de spec net sei dat it geweldich soe wurkje en oer it algemien op 'e knibbel ymplementearre waard, soene se de funksje útskeakele hawwe en sein: "Nimmen hat dit nedich, it wichtichste is dat de haadfunksje wurket.” . En it technologybedriuw sjocht dit as in kâns en begjint de software yn oerienstimming mei dit te feroarjen.
Yn 1968 formulearre in fisioenêre keardel, Melvin Conway, it folgjende idee.
De organisaasje dy't it systeem skept wurdt beheind troch in ûntwerp dat de kommunikaasjestruktuer fan dy organisaasje replikearret.
Yn mear detail, om systemen fan in oar type te produsearjen, moatte jo ek in kommunikaasjestruktuer hawwe binnen in bedriuw fan in oar type. As jo kommunikaasjestruktuer top-hierarchysk is, dan sil dit jo net tastean om systemen te meitsjen dy't in heul hege Time-to-Market-yndikator kinne leverje.
Lês kin . It is wichtich foar it begripen fan 'e DevOps-kultuer as filosofy om't it iennichste ding dat fûneminteel feroaret yn DevOps is de struktuer fan kommunikaasje tusken teams.
Ut in proses eachpunt, foardat DevOps, alle stadia: analytics, ûntwikkeling, testen, operaasje, wiene lineêr.
Yn it gefal fan DevOps komme al dizze prosessen tagelyk foar.
Time-to-market is de ienige manier wêrop it kin wurde dien. Foar minsken dy't wurken yn it âlde proses, dit sjocht der wat kosmysk, en oer it algemien sa-sa.
Dus wêrom hawwe jo DevOps nedich?
Foar digitale produktûntwikkeling. As jo bedriuw gjin digitaal produkt hat, is DevOps net nedich - it is heul wichtich.
DevOps oerwint de snelheidsbeheiningen fan sekwinsjele softwareproduksje. Dêryn komme alle prosessen tagelyk foar.
Swierrichheid nimt ta. As DevOps-evangelisten jo fertelle dat it jo makliker meitsje sil om software frij te litten, is dit ûnsin.
Mei DevOps sille dingen allinich yngewikkelder wurde.
Op de konferinsje op 'e Avito-stand koene jo sjen hoe't it wie om in Docker-kontener yn te setten - in unrealistyske taak. De kompleksiteit wurdt ferbean; jo moatte tagelyk mei in protte ballen jongleren.
DevOps feroaret it proses en de organisaasje yn it bedriuw folslein - krekter, it is net DevOps dy't feroaret, mar it digitale produkt. Om nei DevOps te kommen, moatte jo dit proses noch folslein feroarje.
Fragen foar in spesjalist
Wat hasto? Fragen dy't jo sels stelle kinne as jo yn in bedriuw wurkje en jo ûntwikkelje as spesjalist.
Hawwe jo in strategy foar it meitsjen fan in digitaal produkt? As der is, is dat al goed. Dit betsjut dat jo bedriuw nei DevOps giet.
Meitsje jo bedriuw al in digitaal produkt? Dit betsjut dat jo in oar nivo heger kinne komme en dingen ynteressanter kinne dwaan - wer út in DevOps-perspektyf. Ik praat allinich út dit eachpunt.
Is jo bedriuw ien fan 'e merklieders yn' e niche fan digitale produkten? Spotify, Yandex, Uber binne bedriuwen dy't no op it hichtepunt binne fan technologyske foarútgong.
Stel josels dizze fragen, en as alle antwurden nee binne, dan moatte jo miskien gjin DevOps dwaan by dit bedriuw. As it ûnderwerp fan DevOps jo echt ynteressant is, miskien ... jo moatte ferhúzje nei in oar bedriuw? As jo bedriuw yn DevOps wol, mar jo antwurde "Nee" op alle fragen, dan is it as dy prachtige neushoorn dy't noait sil feroarje.
organisaasje
Lykas ik sei, neffens Conway's Law feroaret de organisaasje fan in bedriuw. Ik sil begjinne mei wat foarkomt dat DevOps yn it bedriuw penetrearret út it organisatoarysk eachpunt.
It probleem fan "putten"
It Ingelske wurd "Silo" wurdt hjir yn it Russysk oerset as "goed". It punt fan dit probleem is dat der is gjin útwikseling fan ynformaasje tusken teams. Elk team graaft djip yn har ekspertize, sûnder in mienskiplike kaart te bouwen om te navigearjen.
Op ien of oare manier docht dit my tinken oan in persoan dy't krekt yn Moskou is oankaam en noch net wit hoe't jo de metrokaart moatte navigearje. Muscovites kenne har gebiet normaal goed, en yn Moskou kinne se navigearje mei de metrokaart. As jo komme nei Moskou foar de earste kear, do hast net dizze feardigens, en do bist gewoan disoriented.
DevOps suggerearret dat jo troch dit momint fan disorientaasje komme en alle ôfdielingen gearwurkje om in mienskiplike ynteraksjekaart te bouwen.
Twa faktoaren hindere dit.
Konsekwinsje fan it bedriuwsbehearsysteem. It is boud yn aparte hiërargyske "putten". Bygelyks binne d'r bepaalde KPI's yn bedriuwen dy't dit systeem stypje. Oan 'e oare kant komme de harsens fan in persoan dy't it dreech fynt om de grinzen fan har ekspertize te gean en troch it heule systeem te navigearjen yn' e wei. It is gewoan ûngemaklik. Stel jo foar dat jo op it fleanfjild fan Bangkok binne - jo sille jo wei net fluch fine. DevOps is ek lestich om te navigearjen, en dêrom sizze minsken dat jo in hantlieding moatte fine om dêr te kommen.
Mar it wichtichste ding is dat it probleem fan "putten" foar in yngenieur dy't trochjûn is mei de geast fan DevOps, hat lêzen Fowler en in bosk oare boeken, wurdt útdrukt yn it feit dat "putten" litte jo net "dúdlike" dingen dwaan. Wy komme faak byinoar nei DevOps Moskou, prate mei elkoar, en minsken kleie:
- Wy woenen gewoan CI lansearje, mar it die bliken dat it management it net nedich hie.
Dit bart krekt omdat CI и Trochrinnende levering proses steane op 'e grins fan in protte eksamens. Simpelwei sûnder it probleem fan "putten" op organisatoarysk nivo te oerwinnen, kinne jo net foarút gean, wat jo ek dogge en hoe tryst it ek is.
Elke dielnimmer oan it proses yn it bedriuw: backend- en frontend-ûntwikkelders, testen, DBA, operaasje, netwurk, graven yn har eigen rjochting, en gjinien hat in mienskiplike kaart útsein de manager, dy't se op ien of oare manier kontrolearret en beheart se mei de "divide" en feroverje” metoade.
Minsken stride foar guon stjerren of flaggen, elkenien gravt har ekspertize.
As gefolch, as de taak ûntstiet om dit alles te ferbinen en in mienskiplike pipeline te bouwen, en it is net langer nedich om te fjochtsjen foar stjerren en flaggen, dan komt de fraach - wat te dwaan dochs? Wy moatte op ien of oare manier ta in oerienkomst komme, mar gjinien hat ús leard hoe dit te dwaan op skoalle. Wy hawwe leard sûnt skoalle: achtste klasse - wow! - ferlike mei sânde klasse! It is hjir itselde.
Is it itselde yn jo bedriuw?
Om dit te kontrolearjen, kinne jo josels de folgjende fragen stelle.
Brûke teams mienskiplike ark en drage by oan feroaringen oan dy mienskiplike ark?
Hoe faak reorganisearje teams - guon spesjalisten fan it iene team ferhúzje nei in oar team? It is yn in DevOps-omjouwing dat dit normaal wurdt, om't soms in persoan gewoan net kin begripe wat in oar gebiet fan saakkundigens docht. Hy ferhuzet nei in oare ôfdieling, wurket dêr twa wiken om foar himsels in kaart te meitsjen fan oriïntaasje en ynteraksje mei dizze ôfdieling.
Is it mooglik om in feroaringskommisje te foarmjen en dingen te feroarjen? Of fereasket it de sterke hân fan it heechste bestjoer en rjochting? Ik skreau koartlyn op Facebook hoe't ien lyts bekende bank ark ymplementearret troch oarders: wy skriuwe in bestelling, wy implementearje it foar in jier, en sjoch wat der bart. Dit is fansels lang en tryst.
Hoe wichtich is it foar managers om persoanlike prestaasjes te ûntfangen sûnder de prestaasjes fan it bedriuw te beskôgjen?
As jo dizze fragen foar josels beäntwurdzje, wurdt dúdliker oft jo sa'n probleem hawwe yn jo bedriuw.
Ynfrastruktuer as koade
Nei't dit probleem trochjûn is, is de earste wichtige praktyk, sûnder dat it dreech is om fierder te gean yn DevOps ynfrastruktuer as koade.
Meastentiids wurdt ynfrastruktuer as koade as folget waarnommen:
- Litte wy alles yn bash automatisearje, ússels bedekke mei skripts sadat admins minder hânwurk hawwe!
Mar dat is net wier.
Ynfrastruktuer as koade betsjut dat jo it IT-systeem wêrmei jo wurkje yn 'e foarm fan koade beskriuwe om de steat konstant te begripen.
Tegearre mei oare teams meitsje jo in kaart yn 'e foarm fan in koade dy't elkenien ferstean kin en kin navigearje en navigearje. It makket net út wêrop it wurdt dien - Chef, Ansible, Salt, of YAML-bestannen yn Kubernetes brûke - d'r is gjin ferskil.
Op 'e konferinsje fertelde in kollega fan 2GIS hoe't se har eigen ynterne ding foar Kubernetes makken, dy't de struktuer fan yndividuele systemen beskriuwt. Om 500 systemen te beskriuwen, hiene se in apart ark nedich dat dizze beskriuwing genereart. As d'r dizze beskriuwing is, kin elkenien mei elkoar kontrolearje, wizigingen kontrolearje, hoe't jo it feroarje en ferbetterje, wat mist.
It iens, yndividuele bash-skripts jouwe normaal dit begryp net. Yn ien fan 'e bedriuwen wêr't ik wurke, wie d'r sels in namme foar "skriuw allinich" skript - as it skript skreaun is, mar it is net mear mooglik om it te lêzen. Ik tink dat dit jo ek bekend is.
Ynfrastruktuer as koade is koade dy't de hjoeddeistige steat fan 'e ynfrastruktuer beskriuwt. In protte produkt-, ynfrastruktuer- en tsjinstteams wurkje gear oan dizze koade, en it wichtichste, se moatte allegear begripe hoe't dizze koade eins wurket.
De koade wurdt ûnderhâlden neffens bêste koadepraktiken: mienskiplike ûntwikkeling, koade review, XP-programmearring, testen, pull fersiken, CI foar koade ynfrastruktuer - dit alles is geskikt en kin brûkt wurde.
Koade wurdt in mienskiplike taal foar alle yngenieurs.
It feroarjen fan ynfrastruktuer yn koade nimt net folle tiid. Ja, ynfrastruktuerkoade kin ek technyske skuld hawwe. Gewoanlik tsjinkomme teams it in jier en in heal nei't se begûnen te ymplementearjen "ynfrastruktuer as koade" yn 'e foarm fan in boskje skripts of sels Ansible, dy't se skriuwe as spaghetti-koade, en se smite ek bash-skripts yn' e miks!
wichtich: As jo dit spul noch net besocht hawwe, tink dan dat Ansible is net bash! Lês de dokumintaasje soarchfâldich, bestudearje wat se deroer skriuwe.
Ynfrastruktuer as koade is de skieding fan ynfrastruktuerkoade yn aparte lagen.
Yn ús bedriuw ûnderskiede wy 3 basislagen, dy't heul dúdlik en ienfâldich binne, mar d'r kinne mear fan wêze. Jo kinne nei jo ynfrastruktuerkoade sjen en fertelle oft jo dizze betingst hawwe of net. As gjin lagen wurde markearre, dan moatte jo nimme wat tiid en refactor in bytsje.
basis laach - dit is hoe't it OS, backups en oare dingen op leech nivo binne konfigureare, bygelyks hoe't Kubernetes wurdt ynset op it basisnivo.
Service nivo - dit binne de tsjinsten dy't jo leverje oan 'e ûntwikkelder: logging as in tsjinst, tafersjoch as in tsjinst, databank as in tsjinst, balancer as in tsjinst, wachtrige as in tsjinst, Continuous Delivery as a Service - in boskje tsjinsten dy't yndividuele teams kin leverje oan ûntwikkeling. Dit alles moat wurde beskreaun yn aparte modules yn jo konfiguraasjebehearsysteem.
De laach dêr't applikaasjes wurde makke en beskriuwt hoe't se sille unfold boppe op 'e foarige twa lagen.
Kontrolearje fragen
Hat jo bedriuw in mienskiplike ynfrastruktuer repository? Beheare jo technyske skulden yn jo ynfrastruktuer? Brûke jo ûntwikkelingspraktiken yn in ynfrastruktuer repository? Is jo ynfrastruktuer yn lagen yndield? Jo kinne it Base-service-APP-diagram kontrolearje. Hoe dreech is it om in feroaring te meitsjen?
As jo ûnderfûn hawwe dat it oardel dei duorre om feroaringen oan te bringen, betsjut dit dat jo technyske skuld hawwe en der mei wurkje moatte. Jo stroffele krekt op in technyske skuldrake yn jo ynfrastruktuerkoade. Ik herinner my in protte fan sokke ferhalen as jo, om wat CCTL te feroarjen, de helte fan 'e ynfrastruktuerkoade moatte oerskriuwe, om't kreativiteit en de winsk om alles te automatisearjen liede ta it feit dat alles oeral korrodearre is, alle hânfetten binne fuorthelle, en it is nedich om te refactor.
Trochrinnende levering
Litte wy debet fergelykje mei kredyt. Earst komt in beskriuwing fan 'e ynfrastruktuer, dy't frijwat basis kin wêze. Jo hoege net alles yn detail te beskriuwen, mar wat basisbeskriuwing is nedich, sadat jo dermei kinne wurkje. Oars is it net dúdlik wat te dwaan mei trochgeande levering neist. Al dizze praktiken ûntjaan tagelyk as jo by DevOps komme, mar it begjint mei it begripen fan wat jo hawwe en hoe't jo it kinne beheare. Dit is krekt de praktyk fan ynfrastruktuer as koade.
Sadree't it dúdlik wurdt dat jo it hawwe en hoe't jo it beheare, begjinne jo út te finen hoe't jo de ûntwikkelderskoade sa gau mooglik nei produksje kinne stjoere. Ik bedoel tegearre mei de ûntwikkelder - wy ûnthâlde oer it probleem fan "putten", dat is, it binne gjin yndividuele minsken dy't dit komme, mar in team.
As wy binne mei Vanya Evtukhovich seach it earste boek Jez Humble en groepen skriuwers "Kontinue levering", dy't yn 2009 útbrocht is, hawwe wy lang neitocht oer hoe't se de titel oersette yn it Russysk. Se woenen it oersette as "Ferstanlik leverje", mar, spitigernôch, waard it oerset as "Durch levering". It liket my ta dat der wat Russysk yn ús namme sit, mei druk.
Hieltyd leverjende middels
Koade dy't yn 'e produktrepository is kin altyd wurde downloade nei produksje. Hy kin net deflearre wurde, mar hy is der altyd klear foar. Dêrtroch skriuwe jo altyd koade mei in dreech te ferklearjen gefoel fan wat eangst ûnder jo sturtbonke. It ferskynt faak as jo ynfrastruktuerkoade útrolje. Dit gefoel fan wat eangst moat oanwêzich wêze - it triggert harsensprosessen wêrtroch jo koade in bytsje oars kinne skriuwe. Dit moat fêstlein wurde yn de regels binnen de ûntwikkeling.
Om konsekwint te leverjen, hawwe jo in artefaktformaat nedich dat oer in ynfrastruktuerplatfoarm rint. As jo "libbensôffal" fan ferskate formaten oer in ynfrastruktuerplatfoarm smite, dan wurdt it ferienige, it is lestich om te ûnderhâlden, en it probleem fan technyske skuld ûntstiet. It formaat fan it artefakt moat ôfstimd wurde - dit is ek in kollektive taak: wy moatte allegear byinoar komme, ús harsens ritsje en mei dit formaat komme.
It artefakt wurdt kontinu ferbettere en feroaret oan 'e produksjeomjouwing as it troch de leveringspipeline beweecht. As in artefakt lâns de pipeline beweecht, komt it konstant wat dingen tsjin dy't der ûngemaklik foar binne, dy't fergelykber binne mei wat it artefakt dat jo yn produksje sette, tsjinkomt. As dit yn 'e klassike ûntwikkeling dien wurdt troch in systeembehearder dy't de útrol docht, dan bart dat yn it DevOps-proses altyd: hjir testen se it mei guon tests, hjir smieten se it yn in Kubernetes-kluster, dat is min of mear gelyk nei produksje, doe begon se ynienen load testen.
Dit docht wat tinken oan it Pac-Man-spiel - it artefakt giet troch in soarte fan ferhaal. Tagelyk is it wichtich om te kontrolearjen oft de koade eins troch it ferhaal giet en oft it op ien of oare manier relatearre is oan jo produksje. Ferhalen út produksje kinne wurde sleept yn it Continuous Delivery-proses: it wie sa doe't der wat foel, no litte wy dit senario gewoan yn it systeem programmearje. Elke kear sil de koade ek troch dit senario gean, en jo sille dit probleem de folgjende kear net tsjinkomme. Jo sille it folle earder witte as it jo klant berikt.
Ferskillende ynsetstrategyen. Jo brûke bygelyks AB-testen of kanaryske ynset om de koade oars op ferskate kliïnten te testen, ynformaasje te krijen oer hoe't de koade wurket, en folle earder as wannear't it wurdt útrôle nei 100 miljoen brûkers.
"Konsekwint leverje" sjocht der sa út.
It leveringsproses Dev, CI, Test, PreProd, Prod is gjin aparte omjouwing, dit binne stadia of stasjons mei brânfeilige sommen dêr't jo artefakt troch giet.
As jo ynfrastruktuerkoade hawwe dy't wurdt beskreaun as Base Service APP, dan helpt it ferjit net alle skripts, en skriuw se op as koade foar dit artefakt, artefakt befoarderje en feroarje it as jo gean.
Sels-testfragen
De tiid fan funksjebeskriuwing oant frijlitting yn produksje is yn 95% fan 'e gefallen minder dan in wike? Ferbettert de kwaliteit fan it artefakt yn elke faze fan 'e pipeline? Is der in ferhaal dat it trochgiet? Brûke jo ferskate ynsetstrategyen?
As alle antwurden ja binne, dan binne jo ongelooflijk cool! Skriuw jo antwurden yn 'e kommentaren - ik sil bliid wêze).
Обратная связь
Dit is de dreechste praktyk fan allegear. Op de DevOpsConf-konferinsje wie in kollega fan Infobip, dy't der oer praat, in bytsje yn 'e war yn syn wurden, om't dit echt in heul komplekse praktyk is oer it feit dat jo alles kontrolearje moatte!
Bygelyks, in lange tiid lyn, doe't ik wurke by Qik en wy realisearre dat wy moatte tafersjoch op alles. Wy hawwe dit dien, en wy hawwe no 150 items yn Zabbix, dy't konstant wurde kontrolearre. It wie eng, de technysk direkteur draaide syn finger nei syn timpel:
- Jonges, wêrom ferkrêfte jo de tsjinner mei wat ûndúdliks?
Mar doe barde der in ynsidint dat liet sjen dat dit echt in heul coole strategy is.
Ien fan 'e tsjinsten begon konstant te crashen. Yn it earstoan crashte it net, wat nijsgjirrich is, de koade waard dêr net tafoege, om't it in basismakelaar wie, dy't praktysk gjin saaklike funksjonaliteit hie - it stjoerde gewoan berjochten tusken yndividuele tsjinsten. De tsjinst feroare net foar 4 moannen, en ynienen begon it te crashen mei de flater "Segmentaasjefout".
Wy wiene skrokken, iepene ús charts yn Zabbix, en it die bliken dat in wike en in heal lyn it gedrach fan oanfragen yn 'e API-tsjinst dy't dizze broker brûkt, sterk feroare. Dêrnei seagen wy dat de frekwinsje fan it ferstjoeren fan in bepaald type berjocht feroare wie. Letter fûnen wy út dat dit Android-kliïnten wiene. Wy fregen:
- Jonges, wat is der oardel wike lyn mei jim bard?
As antwurd hearden wy in nijsgjirrich ferhaal oer hoe't se de UI hienen opnij ûntworpen. It is net wierskynlik dat immen daliks sil sizze dat se de HTTP-bibleteek hawwe feroare. Foar Android-kliïnten is it as sjippe feroarje yn 'e badkeamer - se ûnthâlde it gewoan net. As gefolch, nei 40 minuten fan petear, fûnen wy út dat se de HTTP-bibleteek feroare hiene, en de standerttimingen wiene feroare. Dit late ta dat it ferkearsgedrach op 'e API-tsjinner feroare, wat late ta in situaasje dy't in race yn' e makelder feroarsake, en it begon te crashen.
Sûnder djippe tafersjoch is it oer it algemien ûnmooglik om dit te iepenjen. As de organisaasje noch it probleem hat fan “putten”, as elkenien jild nei elkoar smyt, kin dat jierren libje. Jo gewoan opnij starte de tsjinner omdat it is ûnmooglik om te lossen it probleem. As jo alle eveneminten dy't jo hawwe kontrolearje, folgje, folgje, en monitoaring brûke as testen - skriuw koade en jouwe fuortendaliks oan hoe't jo it kontrolearje, ek yn 'e foarm fan koade (wy hawwe de ynfrastruktuer al as koade), wurdt alles dúdlik hoe't op palm. Sels sokke komplekse problemen binne maklik te folgjen.
Sammelje alle ynformaasje oer wat der bart mei it artefakt yn elke faze fan it leveringsproses - net yn produksje.
Upload de tafersjoch nei CI, en guon basis dingen sille dêr al sichtber wêze. Letter sille jo se sjen yn Test, PredProd, en load testen. Sammelje ynformaasje yn alle stadia, net allinich metriken, statistiken, mar ek logs: hoe't de applikaasje útrûn, anomalies - sammelje alles.
Oars sil it dreech wêze om it út te finen. Ik sei al dat DevOps komplekser is. Om mei dizze kompleksiteit om te gaan, moatte jo normale analytiken hawwe.
Fragen foar selskontrôle
Is jo tafersjoch en logging it ûntwikkelingsark foar jo? By it skriuwen fan koade, tinke jo ûntwikkelders, ynklusyf jo, oer hoe't se it kontrolearje kinne?
Harkje jo oer problemen fan klanten? Begripe jo de klant better fan tafersjoch en logging? Begripe jo it systeem better fan tafersjoch en logging? Feroarje jo it systeem gewoan om't jo seagen dat de trend yn it systeem groeit en jo begripe dat yn in oare 3 wiken alles sil stjerre?
As jo ienris dizze trije komponinten hawwe, kinne jo tinke oer hokker soarte ynfrastruktuerplatfoarm jo hawwe yn jo bedriuw.
Ynfrastruktuer platfoarm
It punt is net dat it in set fan ferskate ark is dat elk bedriuw hat.
It punt fan in ynfrastruktuerplatfoarm is dat alle teams dizze ark brûke en se tegearre ûntwikkelje.
It is dúdlik dat d'r aparte teams binne dy't ferantwurdlik binne foar de ûntwikkeling fan yndividuele stikken fan it ynfrastruktuerplatfoarm. Mar tagelyk draacht elke yngenieur ferantwurdlikens foar de ûntwikkeling, prestaasjes en promoasje fan it ynfrastruktuerplatfoarm. Op yntern nivo wurdt it in mienskiplik ark.
Alle teams ûntwikkelje it ynfrastruktuerplatfoarm en behannelje it mei soarch as har eigen IDE. Yn jo IDE ynstallearje jo ferskate plugins om alles moai en fluch te meitsjen, en fluchtoetsen ynstelle. As jo Sublime, Atom of Visual Studio Code iepenje, streame koadefouten yn en jo realisearje dat it hielendal ûnmooglik is om te wurkjen, jo fiele jo daliks tryst en jo rinne om jo IDE te reparearjen.
Behannelje jo ynfrastruktuerplatfoarm op deselde manier. As jo begripe dat der wat mis mei it, lit in fersyk as jo kinne net reparearje it sels. As d'r wat ienfâldich is, bewurkje it sels, stjoer in pull-fersyk, de jonges sille it beskôgje en it tafoegje. Dit is in wat oare oanpak foar yngenieur-ark yn 'e holle fan' e ûntwikkelders.
It ynfrastruktuerplatfoarm soarget foar de oerdracht fan it artefakt fan ûntwikkeling nei de klant mei trochgeande ferbettering fan kwaliteit. De IP is programmearre mei in set fan ferhalen dy't barre mei de koade yn produksje. Yn 'e rin fan' e jierren fan ûntwikkeling binne d'r in protte fan dizze ferhalen, guon fan har binne unyk en relatearje allinich oan jo - se kinne net Google wurde.
Op dit punt wurdt it ynfrastruktuerplatfoarm jo konkurrinsjefoardiel, om't it wat ynboud hat dat net yn it ark fan 'e konkurrint is. Hoe djipper jo IP, hoe grutter jo konkurrinsjefoardiel yn termen fan Time-to-market. Ferskynt hjir ferkeaper slot probleem: Jo kinne nimme in oar syn platfoarm, mar mei help fan in oar syn ûnderfining, do silst net begripe hoe relevant it is foar dy. Ja, net elk bedriuw kin in platfoarm bouwe lykas Amazon. Dit is in dreech line dêr't it bedriuw syn ûnderfining is relevant foar syn posysje yn 'e merk, en do kinst net brûke in vendor slot dêr. Dit is ek wichtich om nei te tinken.
De regeling
Dit is in basisdiagram fan in ynfrastruktuerplatfoarm dat jo sil helpe jo alle praktiken en prosessen yn in DevOps-bedriuw yn te stellen.
Litte wy sjen wêr't it út bestiet.
Resource orkestraasje systeem, dy't CPU, ûnthâld, skiif leveret oan applikaasjes en oare tsjinsten. Boppe-op dit - leech nivo tsjinsten: monitoring, logging, CI / CD Engine, artefakt opslach, ynfrastruktuer as systeem koade.
Heger nivo tsjinsten: databank as in tsjinst, wachtrijen as in tsjinst, Load Balance as in tsjinst, ôfbylding feroarje as in tsjinst, Big Data fabryk as in tsjinst. Boppe-op dit - pipeline dy't konstant feroare koade leveret oan jo klant.
Jo ûntfange ynformaasje oer hoe't jo software wurket foar de klant, feroarje it, leverje dizze koade opnij, ûntfange ynformaasje - en sa ûntwikkelje jo konstant sawol it ynfrastruktuerplatfoarm as jo software.
Yn it diagram bestiet de leveringpipeline út in protte stadia. Mar dit is in skematysk diagram dat wurdt jûn as foarbyld - it is net nedich om it ien foar ien te werheljen. Stappen ynteraksje mei tsjinsten as wiene se tsjinsten - elke bakstien fan it platfoarm draacht in eigen ferhaal: hoe't boarnen wurde tawiisd, hoe't de applikaasje wurdt lansearre, wurket mei boarnen, wurdt kontrolearre en feroaret.
It is wichtich om te begripen dat elk diel fan it platfoarm in ferhaal draacht, en josels ôffreegje hokker ferhaal dizze bakstien draacht, miskien moat it wurde smiten en ferfongen troch in tsjinst fan tredden. Bygelyks, is it mooglik om te ynstallearjen Okmeter ynstee fan in bakstien? Miskien hawwe de jonges dizze ekspertize al folle mear ûntwikkele as wy. Mar miskien net - miskien hawwe wy unike saakkundigens, wy moatte Prometheus ynstallearje en it fierder ûntwikkelje.
Skepping fan it platfoarm
Dit is in kompleks kommunikaasjeproses. As jo basispraktiken hawwe, begjinne jo kommunikaasje tusken ferskate yngenieurs en spesjalisten dy't easken en noarmen ûntwikkelje, en feroarje se konstant nei ferskate ark en oanpak. De kultuer dy't wy hawwe yn DevOps is hjir wichtich.
Mei kultuer is alles heul ienfâldich - it giet om gearwurking en kommunikaasje, dat is de winsk om op in mienskiplik mêd mei inoar te wurkjen, de winsk om ien ynstrumint tegearre te hanthavenjen. D'r is hjir gjin raketwittenskip - alles is heul ienfâldich, banaal. Bygelyks, wy wenje allegear yn 'e yngong en hâlde it skjin - sa'n nivo fan kultuer.
Wat hasto?
Nochris, fragen kinne jo sels stelle.
Is it ynfrastruktuerplatfoarm wijd? Wa is ferantwurdlik foar syn ûntwikkeling? Begripe jo de konkurrinsjefoardielen fan jo ynfrastruktuerplatfoarm?
Jo moatte josels dizze fragen konstant stelle. As iets kin wurde oerdroegen oan tsjinsten fan tredden, moat it oerdroegen wurde; as in tsjinst fan tredden jo beweging begjint te blokkearjen, dan moatte jo in systeem yn josels bouwe.
Dus, DevOps...
... dit is in kompleks systeem, it moat hawwe:
- Digitaal produkt.
- Bedriuwsmodules dy't dit digitale produkt ûntwikkelje.
- Produkt teams dy't skriuwe koade.
- Praktyken foar trochgeande levering.
- Platfoarms as in tsjinst.
- Ynfrastruktuer as in tsjinst.
- Ynfrastruktuer as koade.
- Aparte praktiken foar it behâld fan betrouberens, ynboud yn DevOps.
- In feedbackpraktyk dy't it allegear beskriuwt.
Jo kinne dit diagram brûke, dêryn markearje wat jo al yn jo bedriuw hawwe yn ien of oare foarm: hat it ûntwikkele of noch ûntwikkele wurde moat.
It giet oer in pear wike oer . as ûnderdiel fan RIT++. Kom nei de konferinsje, wêr't jo in protte koele rapporten sille fine oer trochgeande levering, ynfrastruktuer as koade en DevOps-transformaasje. , lêste priisdeadline is 20 maaie
Boarne: www.habr.com