Die definisie van DevOps is baie kompleks, so ons moet elke keer weer die bespreking daaroor begin. Daar is 'n duisend publikasies oor hierdie onderwerp op Habré alleen. Maar as jy dit lees, weet jy waarskynlik wat DevOps is. Want ek is nie. hallo my naam is Alexander Titov (@), en ons sal net oor DevOps praat en ek sal my ervaring deel.
Ek het lank gedink oor hoe om my storie bruikbaar te maak, so daar sal baie vrae hier wees - dié wat ek myself vra en dié wat ek aan ons maatskappy se kliënte vra. Deur hierdie vrae te beantwoord, word begrip beter. Ek sal jou vertel hoekom DevOps nodig is uit my oogpunt, wat dit weer is uit my oogpunt, en hoe om te verstaan dat jy weer na DevOps beweeg vanuit my oogpunt. Die laaste punt sal deur vrae wees. Deur dit self te beantwoord, kan jy verstaan of jou maatskappy na DevOps beweeg en of daar op een of ander manier probleme is.
Op 'n tyd het ek die golwe van samesmeltings en verkrygings gery. Eers het ek vir 'n klein beginonderneming genaamd Qik gewerk, toe is dit gekoop deur 'n effens groter maatskappy genaamd Skype, wat toe deur 'n effens groter maatskappy genaamd Microsoft gekoop is. Op daardie oomblik het ek begin sien hoe die idee van DevOps in verskillende grootte maatskappye verander. Daarna het ek begin belangstel om na DevOps vanuit 'n markoogpunt te kyk, en ek en my kollegas het die maatskappy Express 42 gestig. Ons beweeg nou al 6 jaar met die golwe van die mark.
Ek is onder meer een van die organiseerders van die DevOps Moskou-gemeenskap en die organiseerder van DevOps-Days 2017, maar ek het nie 2018 georganiseer nie. Express 42 werk met baie maatskappye. Ons kweek DevOps daar, kyk hoe dit gebeur, maak gevolgtrekkings, ontleed, vertel almal ons gevolgtrekkings en lei mense op in DevOps-praktyke. Oor die algemeen doen ons ons bes om ons ervaring en kundigheid in hierdie verband te vergroot.
Hoekom DevOps
Die eerste vraag wat by almal spook en altyd is – hoekom? Baie mense dink dat DevOps net outomatisering of 'n soortgelyke ding is wat elke maatskappy reeds gehad het.
— Ons het deurlopende integrasie gehad - dit beteken dat ons reeds DevOps gehad het, en hoekom is al hierdie goed nodig? Hulle het pret in die buiteland, maar hulle keer ons om te werk!
Oor 9 jaar se ontwikkeling van die gemeenskap en metodologie het dit reeds duidelik geword dat dit steeds nie bemarkingsglitter is nie, maar dit is steeds nie heeltemal duidelik hoekom dit nodig is nie. Soos enige instrument en proses, het DevOps spesifieke doelwitte wat dit uiteindelik bereik.
Dit alles is te wyte aan die feit dat die wêreld besig is om te verander. Hy beweeg weg van die ondernemingsbenadering, wanneer maatskappye reguit na 'n droom beweeg, soos ons St. Petersburg klassieke gesing het, van punt A na punt B volgens 'n sekere strategie, met 'n sekere struktuur hiervoor gebou.
In beginsel moet alles in IT volgens hierdie benadering gebou word. Hier word IT uitsluitlik gebruik om prosesse te outomatiseer.
Outomatisering verander nie gereeld nie, want wanneer 'n maatskappy in 'n getrapte groef val, wat is daar om te verander? Dit werk – moenie daaraan raak nie. Nou is benaderings in die wêreld besig om te verander, en die een wat Agile genoem word, stel voor dat eindpunt B nie onmiddellik sigbaar is nie.
Wanneer 'n maatskappy deur die mark gaan, met 'n kliënt werk, verken dit voortdurend die mark en verander die eindpunt B. Bowendien, hoe meer gereeld die maatskappy sy rigting verander, hoe meer suksesvol is dit op die ou end, want dit kies meer mark nisse.
Die strategie word gedemonstreer deur 'n interessante maatskappy waaroor ek onlangs geleer het. One Box Shave is 'n intekenafleweringsdiens vir skeermesse en skeerbykomstighede in 'n boks. Hulle weet hoe om hul "boks" vir verskillende kliënte aan te pas. Dit word gedoen deur 'n sekere sagteware, wat dan die bestelling na die Koreaanse fabriek stuur wat die produk vervaardig.
Hierdie produk is deur Unilever vir $1 miljard gekoop. Dit ding nou met Gillette mee en het 'n aansienlike deel van verbruikers in die Amerikaanse mark weggeneem. One Box Shave sê:
— 4 lemme? Is jy ernstig? Hoekom het jy dit nodig - dit verbeter nie die kwaliteit van die skeer nie. 'n Spesiaal geselekteerde room, geur en 'n hoë-gehalte skeermes met twee lemme los baie meer probleme op as daardie dom 4 Gillette lemme! Gaan ons binnekort by 10 uitkom?
Dit is hoe die wêreld verander. Unilever beweer dat hulle 'n koel IT-stelsel het wat jou toelaat om dit te doen. Op die ou end lyk dit na 'n konsep Tyd om te bemark, waaroor niemand al gepraat het nie.
Die punt van Tyd-tot-mark is nie hoe gereeld ons ontplooi nie. Jy kan dikwels ontplooi, maar die vrystellingsiklusse sal lank wees. As vrystellingsiklusse van drie maande op mekaar geplaas word en dit met 'n week verskuif, blyk dit dat die maatskappy blykbaar een keer per week ontplooi. En van die idee tot die finale implementering neem dit 3 maande.
Tyd-tot-mark gaan oor die minimalisering van die tyd vanaf idee tot finale implementering.
In hierdie geval is sagteware in wisselwerking met die mark. Dit is hoe die One Box Shave-webwerf met die kliënt in wisselwerking tree. Hulle het nie verkoopsmense nie – net 'n webwerf waar besoekers klik en wense los. Gevolglik moet iets nuuts voortdurend op die webwerf geplaas word en volgens wense opgedateer word. Byvoorbeeld, in Suid-Korea skeer hulle anders as in Rusland, en hulle hou nie van die geur van denne nie, maar byvoorbeeld van wortels en vanielje.
Aangesien dit nodig is om die inhoud van die webwerf vinnig te verander, verander sagteware-ontwikkeling baie. Deur middel van sagteware moet ons uitvind wat die kliënt wil hê. Voorheen het ons dit geleer deur 'n paar rondweg maniere, byvoorbeeld deur besigheidsbestuur. Toe het ons dit ontwerp, die vereistes in die IT-stelsel geplaas, en alles was cool. Nou is dit anders – sagteware word ontwerp deur almal wat by die proses betrokke is, insluitend ingenieurs, want deur tegniese spesifikasies leer hulle hoe die mark werk en deel ook hul insigte met die onderneming.
Byvoorbeeld, by Qik het ons skielik geleer dat mense baie daarvan hou om kontaklyste na die bediener op te laai, en hulle het ons van 'n toepassing voorsien. Aanvanklik het ons nie daaraan gedink nie. In 'n klassieke maatskappy sou almal besluit het dat dit 'n fout is, aangesien die spesifikasie nie gesê het dat dit goed moet werk nie en oor die algemeen op die knie geïmplementeer is, sou hulle die funksie afgeskakel het en gesê het: "Niemand het dit nodig nie, die belangrikste ding is dat die hooffunksie werk.” . En die tegnologiemaatskappy sien dit as 'n geleentheid en begin die sagteware hiervolgens verander.
In 1968 het 'n visioenêre ou, Melvin Conway, die volgende idee geformuleer.
Die organisasie wat die stelsel skep, word beperk deur 'n ontwerp wat daardie organisasie se kommunikasiestruktuur herhaal.
In meer besonderhede, om stelsels van 'n ander tipe te produseer, moet jy ook 'n kommunikasiestruktuur binne 'n maatskappy van 'n ander tipe hê. As jou kommunikasiestruktuur top-hiërargies is, sal dit jou nie toelaat om stelsels te skep wat 'n baie hoë tyd-tot-mark-aanwyser kan verskaf nie.
Lees kan 'n mens . Dit is belangrik om die DevOps-kultuur of -filosofie te verstaan, want die enigste ding wat fundamenteel verander in DevOps is die struktuur van kommunikasie tussen spanne.
Vanuit 'n proses-oogpunt, voor DevOps, was alle stadiums: analise, ontwikkeling, toetsing, werking, lineêr.
In die geval van DevOps vind al hierdie prosesse gelyktydig plaas.
Tyd-tot-mark is die enigste manier waarop dit gedoen kan word. Vir mense wat in die ou proses gewerk het, lyk dit ietwat kosmies, en oor die algemeen so-so.
So hoekom het jy DevOps nodig?
Vir digitale produkontwikkeling. As jou maatskappy nie 'n digitale produk het nie, is DevOps nie nodig nie - dit is baie belangrik.
DevOps oorkom die spoedbeperkings van opeenvolgende sagtewareproduksie. Daarin vind alle prosesse gelyktydig plaas.
Moeilikheid neem toe. Wanneer DevOps-evangeliste vir jou sê dat dit dit vir jou makliker sal maak om sagteware vry te stel, is dit onsin.
Met DevOps sal dinge net meer ingewikkeld raak.
By die konferensie by die Avito-stalletjie kon jy sien hoe dit was om 'n Docker-houer te ontplooi - 'n onrealistiese taak. Die kompleksiteit raak onbetaalbaar; jy moet met baie balle op dieselfde tyd jongleren.
DevOps verander die proses en organisasie in die maatskappy heeltemal — meer presies, dit is nie DevOps wat verander nie, maar die digitale produk. Om na DevOps te kom, moet jy steeds hierdie proses heeltemal verander.
Vrae vir 'n spesialis
Wat het jy? Vrae wat jy jouself kan vra terwyl jy in 'n maatskappy werk en as 'n spesialis ontwikkel.
Het jy 'n strategie om 'n digitale produk te skep? As daar is, is dit reeds goed. Dit beteken dat u onderneming na DevOps beweeg.
Skep jou onderneming reeds 'n digitale produk? Dit beteken dat jy op 'n ander vlak kan beweeg en dinge interessanter kan doen - weereens vanuit 'n DevOps-oogpunt. Ek praat net vanuit hierdie oogpunt.
Is jou maatskappy een van die markleiers in die digitale produk nis? Spotify, Yandex, Uber is maatskappye wat nou op die hoogtepunt van tegnologiese vooruitgang is.
Vra jouself hierdie vrae, en as al die antwoorde nee is, moet jy dalk nie DevOps by hierdie maatskappy doen nie. As die onderwerp van DevOps vir jou regtig interessant is, moet jy dalk na 'n ander maatskappy skuif? As jou maatskappy in DevOps wil gaan, maar jy het “Nee” op al die vrae geantwoord, dan is dit soos daardie pragtige renoster wat nooit sal verander nie.
Organisasie
Soos ek gesê het, volgens Conway se wet verander die organisasie van 'n maatskappy. Ek sal begin met wat verhoed dat DevOps vanuit die organisatoriese oogpunt binne die maatskappy binnedring.
Die probleem van "putte"
Die Engelse woord "Silo" word hier in Russies vertaal as "goed". Die punt van hierdie probleem is dat daar is geen uitruil van inligting tussen spanne nie. Elke span delf diep in sy kundigheid, sonder om 'n gemeenskaplike kaart te bou om te navigeer.
Op sekere maniere laat dit my dink aan 'n persoon wat pas in Moskou aangekom het en nog nie weet hoe om die metrokaart te navigeer nie. Moskoviete ken gewoonlik hul gebied baie goed, en regdeur Moskou kan hulle met behulp van die metrokaart navigeer. Wanneer jy vir die eerste keer na Moskou kom, het jy nie hierdie vaardigheid nie, en jy is net gedisoriënteerd.
DevOps stel voor om deur hierdie oomblik van disoriëntasie te kom en dat alle departemente saamwerk om 'n gemeenskaplike interaksiekaart te bou.
Twee faktore verhinder dit.
Gevolg van die korporatiewe bestuurstelsel. Dit is in aparte hiërargiese "putte" gebou. Daar is byvoorbeeld sekere KPI's in maatskappye wat hierdie stelsel ondersteun. Aan die ander kant staan die brein van 'n persoon wat dit moeilik vind om oor die grense van hul kundigheid te gaan en die hele stelsel te navigeer in die pad. Dis net ongemaklik. Stel jou voor dat jy by Bangkok-lughawe is - jy sal nie vinnig jou weg vind nie. DevOps is ook moeilik om te navigeer, en dit is hoekom mense sê jy moet 'n gids vind om daar te kom.
Maar die belangrikste ding is dat die probleem van "putte" vir 'n ingenieur wat deurdrenk is van die gees van DevOps, Fowler en 'n klomp ander boeke gelees het, uitgedruk word in die feit dat "putte" laat jou nie toe om "vanselfsprekende" dinge te doen nie. Ons kom gereeld na DevOps Moskou bymekaar, praat met mekaar en mense kla:
- Ons wou net CI bekendstel, maar dit het geblyk dat die bestuur dit nie nodig het nie.
Dit gebeur juis omdat CI и Deurlopende afleweringsproses is op die grens van baie eksamens. Bloot sonder om die probleem van “putte” op organisatoriese vlak te oorkom, sal jy nie vorentoe kan beweeg nie, maak nie saak wat jy doen en hoe hartseer dit ook al is nie.
Elke deelnemer aan die proses in die maatskappy: backend- en frontend-ontwikkelaars, toetsing, DBA, bedryf, netwerk, grawe in hul eie rigting, en niemand het 'n gemeenskaplike kaart nie, behalwe die bestuurder, wat hulle op een of ander manier monitor en bestuur met behulp van die "divide en oorwin” metode.
Mense veg vir 'n paar sterre of vlae, almal grawe hul kundigheid.
As gevolg hiervan, wanneer die taak opduik om dit alles met mekaar te verbind en 'n gemeenskaplike pyplyn te bou, en daar is nie meer nodig om vir sterre en vlae te veg nie, ontstaan die vraag - wat om in elk geval te doen? Ons moet op een of ander manier tot 'n vergelyk kom, maar niemand het ons op skool geleer hoe om dit te doen nie. Ons is van skool af geleer: graad agt - sjoe! - in vergelyking met graad sewe! Dit is dieselfde hier.
Is dit dieselfde in jou maatskappy?
Om dit na te gaan, kan jy jouself die volgende vrae vra.
Gebruik spanne algemene gereedskap en dra hulle by tot veranderinge aan daardie algemene gereedskap?
Hoe gereeld herorganiseer spanne - sommige spesialiste van een span skuif na 'n ander span? Dit is in 'n DevOps-omgewing dat dit normaal word, want soms kan 'n persoon eenvoudig nie verstaan wat 'n ander gebied van kundigheid doen nie. Hy skuif na 'n ander departement, werk vir twee weke daar om vir homself 'n kaart van oriëntasie en interaksie met hierdie departement te skep.
Is dit moontlik om 'n veranderingskomitee te stig en dinge te verander? Of vereis dit die sterk hand van die hoogste bestuur en rigting? Ek het onlangs op Facebook geskryf hoe een onbekende bank gereedskap deur bestellings implementeer: ons skryf 'n bevel, ons implementeer dit vir 'n jaar, en kyk wat gebeur. Dit is natuurlik lank en hartseer.
Hoe belangrik is dit vir bestuurders om persoonlike prestasies te ontvang sonder om die maatskappy se prestasies in ag te neem?
As jy hierdie vrae vir jouself beantwoord, sal dit duideliker word of jy so 'n probleem in jou maatskappy het.
Infrastruktuur as kode
Nadat hierdie probleem geslaag is, is die eerste belangrike praktyk, waarsonder dit moeilik is om verder in DevOps te vorder infrastruktuur as kode.
Meestal word infrastruktuur as kode soos volg waargeneem:
— Kom ons outomatiseer alles in bash, bedek onsself met skrifte sodat admins minder handwerk het!
Maar dis nie waar nie.
Infrastruktuur as kode beteken dat jy die IT-stelsel waarmee jy werk in die vorm van kode beskryf om voortdurend die toestand daarvan te verstaan.
Saam met ander spanne skep jy 'n kaart in die vorm van kode wat almal kan verstaan en kan navigeer en navigeer. Dit maak nie saak waarop dit gedoen word nie – Chef, Ansible, Salt, of die gebruik van YAML-lêers in Kubernetes nie – daar is geen verskil nie.
Op die konferensie het 'n kollega van 2GIS vertel hoe hulle hul eie interne ding vir Kubernetes gemaak het, wat die struktuur van individuele stelsels beskryf. Om 500 stelsels te beskryf, het hulle 'n aparte hulpmiddel nodig gehad wat hierdie beskrywing genereer. Wanneer daar hierdie beskrywing is, kan almal met mekaar kyk, veranderinge monitor, hoe om dit te verander en te verbeter, wat ontbreek.
Stem saam, individuele bash-skrifte verskaf gewoonlik nie hierdie begrip nie. In een van die maatskappye waar ek gewerk het, was daar selfs 'n naam vir “slegs skryf” skrif – wanneer die skrif geskryf is, maar dit nie meer moontlik is om dit te lees nie. Ek dink dit is ook aan jou bekend.
Infrastruktuur soos kode is kode wat die huidige stand van die infrastruktuur beskryf. Baie produk-, infrastruktuur- en diensspanne werk saam aan hierdie kode, en die belangrikste is dat hulle almal moet verstaan hoe hierdie kode werklik werk.
Die kode word gehandhaaf volgens beste kodepraktyke: gesamentlike ontwikkeling, kodehersiening, XP-programmering, toetsing, trekversoeke, CI vir kode-infrastruktuur - dit alles is geskik en kan gebruik word.
Kode word 'n algemene taal vir alle ingenieurs.
Die verandering van infrastruktuur in kode neem nie veel tyd nie. Ja, infrastruktuurkode kan ook tegniese skuld hê. Gewoonlik kom spanne dit teë 'n jaar en 'n half nadat hulle "infrastruktuur as kode" begin implementeer het in die vorm van 'n klomp skrifte of selfs Ansible, wat hulle soos spaghetti-kode skryf, en hulle gooi ook bash-skripte in die mengsel!
Dit is belangrik om: As jy nog nie hierdie goed probeer het nie, onthou dit Ansible is nie bash nie! Lees die dokumentasie aandagtig deur, bestudeer wat hulle daaroor skryf.
Infrastruktuur as kode is die skeiding van infrastruktuurkode in aparte lae.
In ons maatskappy onderskei ons 3 basiese lae, wat baie duidelik en eenvoudig is, maar daar kan meer van hulle wees. Jy kan na jou infrastruktuurkode kyk en sê of jy hierdie toestand het of nie. As geen lae uitgelig is nie, moet u 'n bietjie tyd neem en 'n bietjie herfaktor.
basislaag - dit is hoe die bedryfstelsel, rugsteun en ander lae-vlak dinge opgestel word, byvoorbeeld hoe Kubernetes op die basiese vlak ontplooi word.
Diensvlak - dit is die dienste wat jy aan die ontwikkelaar verskaf: aanteken as 'n diens, monitering as 'n diens, databasis as 'n diens, balanseerder as 'n diens, tou as 'n diens, Deurlopende aflewering as 'n diens - 'n klomp dienste wat individuele spanne aan ontwikkeling kan verskaf. Dit moet alles in afsonderlike modules in jou konfigurasiebestuurstelsel beskryf word.
Die laag waar toepassings gemaak word en beskryf hoe hulle bo-op die vorige twee lae sal ontvou.
Beheer vrae
Het u onderneming 'n gemeenskaplike infrastruktuurbewaarplek? Bestuur jy tegniese skuld in jou infrastruktuur? Gebruik jy ontwikkelingspraktyke in 'n infrastruktuurbewaarplek? Is jou infrastruktuur in lae gesny? Jy kan die Base-service-APP-diagram nagaan. Hoe moeilik is dit om 'n verandering te maak?
As jy ervaar het dat dit 'n dag en 'n half geneem het om veranderinge aan te bring, beteken dit dat jy tegniese skuld het en daarmee moet werk. Jy het sopas afgekom op 'n tegniese skuldhark in jou infrastruktuurkode. Ek onthou baie sulke stories wanneer jy, om 'n sekere CCTL te verander, die helfte van die infrastruktuurkode moet herskryf, want kreatiwiteit en die begeerte om alles te outomatiseer het daartoe gelei dat alles oral gekorrodeer is, al die handvatsels verwyder is, en dit is nodig om te herfaktor.
Deurlopende aflewering
Kom ons vergelyk debiet met krediet. Eerstens kom 'n beskrywing van die infrastruktuur, wat redelik basies kan wees. Jy hoef nie alles in detail te beskryf nie, maar 'n basiese beskrywing word vereis sodat jy daarmee kan werk. Andersins is dit nie duidelik wat om volgende met deurlopende aflewering te doen nie. Al hierdie praktyke ontvou gelyktydig wanneer jy by DevOps kom, maar dit begin met om te verstaan wat jy het en hoe om dit te bestuur. Dit is juis die praktyk van infrastruktuur as kode.
Sodra dit duidelik word dat jy dit het en hoe om dit te bestuur, begin jy uitvind hoe om die ontwikkelaarkode so vinnig as moontlik na produksie te stuur. Ek bedoel saam met die ontwikkelaar - ons onthou van die probleem van "putte", dit wil sê, dit is nie individuele mense wat hiermee vorendag kom nie, maar 'n span.
Wanneer ons saam is Vanya Evtukhovich die eerste boek gesien Jez Humble en groepe skrywers "Deurlopende aflewering", wat in 2009 vrygestel is, het ons lank gedink oor hoe om sy titel in Russies te vertaal. Hulle wou dit vertaal as “Deurlopende aflewering”, maar dit is ongelukkig vertaal as “Deurlopende aflewering”. Dit lyk vir my of daar iets Russies in ons naam is, met druk.
Voortdurend lewering beteken
Kode wat in die produkbewaarplek is, kan altyd na produksie afgelaai word. Hy is dalk nie afgeblaas nie, maar hy is altyd gereed daarvoor. Gevolglik skryf jy altyd kode met 'n moeilik verklaarbare gevoel van een of ander angs onder jou stertbeen. Dit verskyn dikwels wanneer jy infrastruktuurkode uitrol. Hierdie gevoel van 'n mate van angs moet teenwoordig wees - dit veroorsaak breinprosesse wat jou toelaat om kode 'n bietjie anders te skryf. Dit moet in die reëls binne die ontwikkeling aangeteken word.
Om konsekwent te lewer, benodig jy 'n artefakformaat wat oor 'n infrastruktuurplatform loop. As jy "lewensafval" van verskillende formate oor 'n infrastruktuurplatform gooi, dan word dit verenig, dit is moeilik om te onderhou, en die probleem van tegniese skuld ontstaan. Die formaat van die artefak moet in lyn gebring word - dit is ook 'n kollektiewe taak: ons moet almal bymekaar kom, ons brein ritsel en met hierdie formaat vorendag kom.
Die artefak word voortdurend verbeter en verander om by die produksie-omgewing te pas soos dit deur die afleweringspyplyn beweeg. Wanneer 'n artefak langs die pyplyn beweeg, kom dit voortdurend 'n paar ongerieflike dinge teë vir hom, wat soortgelyk is aan wat die artefak wat jy in produksie plaas, teëkom. As dit in klassieke ontwikkeling gedoen word deur 'n stelseladministrateur wat die ontplooiing doen, dan gebeur dit in die DevOps-proses heeltyd: hier het hulle dit met 'n paar toetse getoets, hier het hulle dit in 'n Kubernetes-kluster gegooi, wat min of meer soortgelyk is na produksie, toe begin hulle skielik laai toets .
Dit herinner ietwat aan die Pac-Man-speletjie - die artefak gaan deur 'n soort storie. Terselfdertyd is dit belangrik om te beheer of die kode werklik deur die storie gaan en of dit op een of ander manier verband hou met jou produksie. Verhale van produksie kan in die Deurlopende afleweringsproses ingesleep word: dit was so toe iets geval het, laat ons nou net hierdie scenario binne die stelsel programmeer. Elke keer sal die kode ook deur hierdie scenario gaan, en jy sal nie volgende keer hierdie probleem teëkom nie. Jy sal baie vroeër daaroor leer as wat dit jou kliënt bereik.
Verskillende ontplooiingstrategieë. Byvoorbeeld, jy gebruik AB-toetsing of kanarie-ontplooiings om die kode anders op verskillende kliënte te toets, inligting te kry oor hoe die kode werk, en baie vroeër as wanneer dit na 100 miljoen gebruikers uitgerol word.
"Lewer deurlopend" lyk so.
Die afleweringsproses Dev, CI, Test, PreProd, Prod is nie 'n aparte omgewing nie, dit is stadiums of stasies met vuurvaste somme waardeur jou artefak gaan.
As jy infrastruktuurkode het wat as Base Service APP beskryf word, help dit moenie al die skrifte vergeet nie, en skryf dit neer as kode vir hierdie artefak, artefak bevorder en verander dit soos jy gaan.
Self-toets vrae
Is die tyd vanaf kenmerkbeskrywing tot vrystelling in produksie in 95% van die gevalle minder as 'n week? Verbeter die kwaliteit van die artefak in elke stadium van die pyplyn? Is daar 'n storie wat dit deurgaan? Gebruik jy verskillende ontplooiingstrategieë?
As al die antwoorde ja is, dan is jy ongelooflik cool! Skryf jou antwoorde in die kommentaar - ek sal bly wees).
terugvoer
Dit is die moeilikste praktyk van almal. By die DevOpsConf-konferensie was 'n kollega van Infobip, wat daaroor gepraat het, 'n bietjie verward in sy woorde, want dit is regtig 'n baie komplekse praktyk oor die feit dat jy alles moet monitor!
Byvoorbeeld, lank gelede, toe ek by Qik gewerk het en ons besef het dat ons alles moet monitor. Ons het dit gedoen, en ons het nou 150 000 items in Zabbix, wat voortdurend gemonitor word. Dit was skrikwekkend, die tegniese direkteur het sy vinger na sy slaap gedraai:
- Ouens, hoekom verkrag julle die bediener met iets wat onduidelik is?
Maar toe gebeur 'n voorval wat wys dat dit regtig 'n baie cool strategie is.
Een van die dienste het voortdurend begin ineenstort. Aanvanklik het dit nie neergestort nie, wat interessant is, die kode is nie daar bygevoeg nie, want dit was 'n basiese makelaar wat feitlik geen besigheidsfunksionaliteit gehad het nie - dit het bloot boodskappe tussen individuele dienste gestuur. Die diens het vir 4 maande nie verander nie, en skielik het dit begin ineenstort met die "Segmentasiefout"-fout.
Ons was geskok, het ons kaarte in Zabbix oopgemaak, en dit het geblyk dat 'n week en 'n half gelede die gedrag van versoeke in die API-diens wat hierdie makelaar gebruik, baie verander het. Vervolgens het ons gesien dat die frekwensie van die stuur van 'n sekere tipe boodskap verander het. Later het ons uitgevind dat dit Android-kliënte was. Ons het gevra:
— Ouens, wat het 'n week en 'n half gelede met julle gebeur?
In reaksie hierop het ons 'n interessante storie gehoor oor hoe hulle die UI herontwerp het. Dit is onwaarskynlik dat iemand dadelik sal sê dat hulle die HTTP-biblioteek verander het. Vir Android-kliënte is dit soos om seep in die badkamer te verander - hulle onthou net nie. Gevolglik het ons na 40 minute se gesprek uitgevind dat hulle die HTTP-biblioteek verander het, en dat die verstektydsberekeninge daarvan verander het. Dit het daartoe gelei dat die verkeersgedrag op die API-bediener verander het, wat gelei het tot 'n situasie wat 'n wedloop binne die makelaar veroorsaak het, en dit het begin ineenstort.
Sonder diep monitering is dit oor die algemeen onmoontlik om dit oop te maak. As die organisasie steeds die probleem van “putte” het, wanneer almal geld na mekaar gooi, kan dit vir jare voortleef. Jy herbegin eenvoudig die bediener omdat dit onmoontlik is om die probleem op te los. Wanneer jy al die gebeure wat jy het monitor, dop, dop en monitering as toets gebruik - skryf kode en dui dadelik aan hoe om dit te monitor, ook in die vorm van kode (ons het reeds die infrastruktuur as kode), word alles duidelik hoe op die palm. Selfs sulke komplekse probleme word maklik opgespoor.
Versamel alle inligting oor wat met die artefak gebeur in elke stadium van die afleweringsproses - nie in produksie nie.
Laai die monitering op na CI, en 'n paar basiese dinge sal reeds daar sigbaar wees. Later sal jy hulle sien in toets, PredProd, en laai toets. Versamel inligting in alle stadiums, nie net metrieke, statistieke nie, maar ook logs: hoe die toepassing uitgerol het, afwykings - versamel alles.
Anders sal dit moeilik wees om dit uit te vind. Ek het reeds gesê dat DevOps meer kompleks is. Om hierdie kompleksiteit die hoof te bied, moet u normale analise hê.
Vrae vir selfbeheersing
Is jou monitering en aanteken van die ontwikkelingsinstrument vir jou? Wanneer u kode skryf, dink u ontwikkelaars, insluitend u, oor hoe om dit te monitor?
Hoor jy van probleme van kliënte? Verstaan jy die kliënt beter uit monitering en aanteken? Verstaan jy die stelsel beter van monitering en aanteken? Verander jy die stelsel bloot omdat jy gesien het dat die tendens in die stelsel groei en jy verstaan dat alles oor nog 3 weke sal sterf?
Sodra jy hierdie drie komponente het, kan jy dink oor watter soort infrastruktuurplatform jy in jou onderneming het.
Infrastruktuur platform
Die punt is nie dat dit 'n stel uiteenlopende instrumente is wat elke maatskappy het nie.
Die punt van 'n infrastruktuurplatform is dat alle spanne hierdie instrumente gebruik en saam ontwikkel.
Dit is duidelik dat daar afsonderlike spanne is wat verantwoordelik is vir die ontwikkeling van individuele stukke van die infrastruktuurplatform. Maar terselfdertyd dra elke ingenieur verantwoordelikheid vir die ontwikkeling, prestasie en bevordering van die infrastruktuurplatform. Op 'n interne vlak word dit 'n algemene instrument.
Alle spanne ontwikkel die infrastruktuurplatform en hanteer dit versigtig as hul eie IO. In jou IDE installeer jy verskillende plugins om alles mooi en vinnig te maak, en stel snelsleutels in. Wanneer jy Sublime, Atom of Visual Studio Code oopmaak, stroom kodefoute in en jy besef dat dit onmoontlik is om glad nie te werk nie, jy voel dadelik hartseer en jy hardloop om jou IDE reg te maak.
Behandel jou infrastruktuurplatform op dieselfde manier. As jy verstaan dat daar iets fout daarmee is, los 'n versoek as jy dit nie self kan regmaak nie. As daar iets eenvoudig is, redigeer dit self, stuur 'n trekversoek, die ouens sal dit oorweeg en dit byvoeg. Dit is 'n effens ander benadering tot ingenieursinstrumente in die ontwikkelaar se kop.
Die infrastruktuurplatform verseker die oordrag van die artefak van ontwikkeling na die kliënt met voortdurende verbetering in kwaliteit. Die IP is geprogrammeer met 'n stel stories wat gebeur met die kode in produksie. Oor die jare van ontwikkeling is daar baie van hierdie stories, sommige van hulle is uniek en hou net met jou verband – hulle kan nie gegoogle word nie.
Op hierdie stadium word die infrastruktuurplatform jou mededingende voordeel, want dit het iets ingebou wat nie in die mededinger se instrument is nie. Hoe dieper jou IP, hoe groter is jou mededingende voordeel in terme van Tyd-tot-mark. Verskyn hier verkoperslot probleem: Jy kan iemand anders se platform neem, maar deur iemand anders se ervaring te gebruik, sal jy nie verstaan hoe relevant dit vir jou is nie. Ja, nie elke maatskappy kan 'n platform soos Amazon bou nie. Dit is 'n moeilike lyn waar die maatskappy se ervaring relevant is tot sy posisie in die mark, en jy kan nie 'n verkoperslot daar gebruik nie. Dit is ook belangrik om oor na te dink.
Die skema
Dit is 'n basiese diagram van 'n infrastruktuurplatform wat jou sal help om al die praktyke en prosesse in 'n DevOps-maatskappy op te stel.
Kom ons kyk waaruit dit bestaan.
Hulpbronorkestrasiestelsel, wat SVE, geheue, skyf aan toepassings en ander dienste verskaf. Boonop - lae vlak dienste: monitering, aanteken, CI/CD-enjin, artefakberging, infrastruktuur as stelselkode.
Hoër vlak dienste: databasis as 'n diens, toue as 'n diens, Load Balance as 'n diens, beeldgrootte as 'n diens, Big Data fabriek as 'n diens. Boonop - pyplyn wat voortdurend gewysigde kode aan jou kliënt lewer.
Jy ontvang inligting oor hoe jou sagteware vir die kliënt werk, verander dit, verskaf hierdie kode weer, ontvang inligting – en so ontwikkel jy voortdurend beide die infrastruktuurplatform en jou sagteware.
In die diagram bestaan die afleweringspyplyn uit baie stadiums. Maar dit is 'n skematiese diagram wat as voorbeeld gegee word - dit hoef nie een vir een te herhaal nie. Stadiums werk in wisselwerking met dienste asof dit dienste is - elke baksteen van die platform dra sy eie storie: hoe hulpbronne toegewys word, hoe die toepassing bekendgestel word, met hulpbronne werk, gemonitor word en verander.
Dit is belangrik om te verstaan dat elke deel van die platform 'n storie dra, en vra jouself af watter storie dra hierdie baksteen, miskien moet dit weggegooi word en vervang word met 'n derdeparty-diens. Is dit byvoorbeeld moontlik om Okmeter in plaas van 'n baksteen te installeer? Miskien het die ouens hierdie kundigheid al baie meer ontwikkel as wat ons het. Maar miskien nie – miskien het ons unieke kundigheid, ons moet Prometheus installeer en verder ontwikkel.
Skep van die platform
Dit is 'n komplekse kommunikasieproses. Wanneer jy basiese praktyke het, begin jy kommunikasie tussen verskillende ingenieurs en spesialiste wat vereistes en standaarde ontwikkel, en verander dit voortdurend na verskillende instrumente en benaderings. Die kultuur wat ons in DevOps het, is hier belangrik.
Met kultuur is alles baie eenvoudig - dit gaan oor samewerking en kommunikasie, dit wil sê die begeerte om in 'n gemeenskaplike veld met mekaar te werk, die begeerte om een instrument saam te swaai. Hier is geen vuurpylwetenskap nie – alles is baie eenvoudig, banaal. Ons woon byvoorbeeld almal in die ingang en hou dit skoon – so ’n vlak van kultuur.
Wat het jy?
Weereens, vrae wat jy jouself kan vra.
Is die infrastruktuurplatform toegewy? Wie is verantwoordelik vir die ontwikkeling daarvan? Verstaan jy die mededingende voordele van jou infrastruktuurplatform?
Jy moet jouself voortdurend hierdie vrae vra. As iets na derdepartydienste oorgedra kan word, moet dit oorgedra word; as 'n derdepartydiens jou beweging begin blokkeer, moet jy 'n stelsel binne jouself bou.
So, DevOps...
... dit is 'n komplekse stelsel, dit moet hê:
- Digitale produk.
- Besigheidsmodules wat hierdie digitale produk ontwikkel.
- Produkspanne wat kode skryf.
- Deurlopende afleweringspraktyke.
- Platforms as 'n diens.
- Infrastruktuur as 'n diens.
- Infrastruktuur as kode.
- Afsonderlike praktyke vir die handhawing van betroubaarheid, ingebou in DevOps.
- 'n Terugvoerpraktyk wat dit alles beskryf.
Jy kan hierdie diagram gebruik en daarin uitlig wat jy reeds in jou maatskappy het in een of ander vorm: het dit ontwikkel of nog ontwikkel moet word.
Dit sal oor 'n paar weke verby wees . as deel van RIT++. Kom na die konferensie, waar jy baie koel verslae sal vind oor deurlopende aflewering, infrastruktuur as kode en DevOps-transformasie. , laaste pryssperdatum is 20 Mei
Bron: will.com