DevOps-en egoera Errusian 2020

Nola ulertu zerbaiten egoera?

Zure iritzian oinarritu zaitezke, hainbat informazio iturritatik eratua, adibidez, webguneetako argitalpenak edo esperientzia. Lankideei, ezagunei galdetu diezaiekezu. Jardunaldietako gaiak aztertzea da beste aukera bat: programa-batzordea industriako ordezkari aktiboak dira, beraz, haiengan konfiantza dugu gai garrantzitsuak aukeratzerakoan. Alor bereizi bat ikerketa eta txostenak dira. Baina arazo bat dago. DevOps-en egoerari buruzko ikerketak urtero egiten dira munduan, txostenak atzerriko enpresek argitaratzen dituzte eta ez dago ia informaziorik Errusiako DevOps-i buruz.

Baina heldu da halako azterketa bat egiteko eguna, eta gaur emaitzei buruz hitz egingo dugu. Errusiako DevOps-en egoera enpresek elkarrekin aztertu zuten "Adierazi 42"Eta"Ontiko". Express 42-k teknologia-enpresei DevOps praktikak eta tresnak ezartzen eta garatzen laguntzen die eta Errusian DevOps-i buruz hitz egiten lehenetariko bat izan zen. Ikerketaren egileak, Igor Kurochkin eta Vitaly Khabarov, analisian eta aholkularitzan aritzen dira Express 42-n, eta enpresa ezberdinetako operaziotik eta esperientzia teknikoa dute. 8 urtez, lankideek arazo desberdinak dituzten dozenaka enpresa eta proiektu aztertu dituzte —startupetatik hasi eta enpresetara—, baita kultura eta ingeniaritza heldutasun ezberdina ere.

Euren txostenean, Igor eta Vitalyk ikerketa prozesuan zer arazo zeuden, nola konpondu zituzten, baita DevOps ikerketa printzipioz nola egiten den eta Express 42-k zergatik erabaki zuen berea egitea ere. Haien txostena ikus daiteke Hemen.

DevOps Ikerketa

Igor Kurochkinek hasi zuen solasaldia.

DevOps kongresuetan ikusleei aldizka galdetzen diegu: "Irakurri al duzu aurtengo DevOps egoera txostena?" Gutxik altxatzen dute eskua, eta gure ikerketak erakutsi du hirugarren batek bakarrik aztertzen dituela. Horrelako erreportajeak inoiz ikusi ez badituzu, esan berehala denak oso antzekoak direla. Gehienetan honelako esaldiak daude: "Iazkoarekin alderatuta..."

Hemen dugu lehen arazoa, eta ondoren beste bi:

1. Ez dugu iazko daturik. Errusiako DevOps-en egoerak ez du inorentzat interesik;
2. Metodologia. Ez dago argi nola frogatu hipotesiak, nola eraiki galderak, nola aztertu, emaitzak alderatu, loturak aurkitu;
3. Terminologia. Txosten guztiak ingelesez daude, itzulpena beharrezkoa da, DevOps esparru komun bat oraindik ez da asmatu eta bakoitzak berea egiten du.

Ikus dezagun nola egin diren DevOps egoeraren analisiak munduan zehar.

Informazio historiko

DevOps ikerketa 2011tik aurrera egiten da. Puppet, konfigurazioa kudeatzeko sistemen garatzailea, izan zen haiek egiten lehena. Garai hartan, azpiegitura kode moduan deskribatzeko tresna nagusietako bat zen. 2013ra arte, azterketa horiek inkesta itxiak besterik ez ziren eta txosten publikorik ez.

2013an, IT Revolution agertu zen, DevOps-i buruzko liburu nagusi guztien argitaratzailea. Puppet-ekin batera, DevOps-en lehen argitalpena prestatu zuten, non 4 neurketa gako agertu ziren lehen aldiz. Hurrengo urtean, ThoughtWorks, industriako praktika eta tresnei buruzko ohiko radar teknologikoengatik ezaguna den aholkularitza-enpresa, parte hartu zuen. Eta 2015ean, metodologiarekin atal bat gehitu zen, eta argi geratu zen nola egiten duten azterketa.

2016an, ikerketaren egileek, DORA (DevOps Research and Assessment) enpresa propioa sortuta, urteko txostena argitaratu zuten. Hurrengo urtean, DORA eta Puppet-ek euren azken txosten bateratua kaleratu zuten.

Eta orduan zerbait interesgarria hasi zen:

2018an, konpainiak banandu egin ziren eta bi txosten independente kaleratu ziren: Puppet-en bat, DORAren bigarrena Googlerekin batera. DORAk bere metodologia aprobetxatzen jarraitu du neurri gakoekin, errendimendu-profilekin eta ingeniaritza-praktikekin, funtsezko metriketan eta enpresa osoaren errendimenduan eragina dutenak. Eta Puppet-ek bere ikuspegia eskaini zuen DevOps-en prozesuaren eta bilakaeraren deskribapenarekin. Baina istorioa ez zen errotu, 2019an Puppet-ek metodologia hau alde batera utzi zuen eta txostenen bertsio berri bat kaleratu zuen, funtsezko praktikak eta DevOps beren ikuspuntutik nola eragiten duten zerrendatu zuena. Orduan beste gertaera bat gertatu zen: Googlek DORA erosi zuen, eta elkarrekin beste txosten bat kaleratu zuten. Baliteke hura ikusi izana.

Aurten, gauzak zaildu egin dira. Puppet-ek bere inkesta propioa martxan jarri duela ezaguna da. Gu baino astebete lehenago egin zuten, eta dagoeneko amaitu da. Bertan parte hartu dugu eta zein gai interesatzen zaizkien aztertu dugu. Orain Puppet bere azterketa egiten eta txostena argitaratzeko prestatzen ari da.

Baina oraindik ez dago DORA eta Google-ren iragarpenik. Maiatzean, inkesta normalean hasi zenean, Nicole Forsgren, DORAren sortzaileetako bat, beste enpresa batera joan zela jakinarazi zuen. Hori dela eta, aurten DORAren ikerketa eta txostenik ez zela egongo suposatu genuen.

Nola daude gauzak Errusian?

Ez dugu DevOps ikerketarik egin. Jardunaldietan hitz egin genuen, besteen aurkikuntzak berriro kontatzen, eta Raiffeisenbankek 2019rako "DevOps-aren egoera" itzuli zuen (Habren aurki dezakezu haien iragarkia), mila esker. Eta dena da.

Hori dela eta, gure ikerketa egin genuen Errusian DORA metodologia eta aurkikuntzak erabiliz. Gure ikerketarako Raiffeisenbankeko lankideen txostena erabili dugu, terminologia eta itzulpena sinkronizatzeko barne. Eta industriari dagozkion galderak DORA txostenetatik eta aurtengo Puppet galdetegitik atera ziren.

Ikerketa prozesua

Txostena azken zatia baino ez da. Ikerketa prozesu osoak lau urrats nagusi ditu:

Prestaketa fasean, industriako adituak elkarrizketatu eta hipotesi zerrenda bat prestatu genuen. Horien arabera, galderak bildu eta abuztu osorako inkesta bat jarri zen martxan. Ondoren, txostena bera aztertu eta prestatu genuen. DORArentzat, prozesu honek 6 hilabete behar ditu. 3 hilabeteren buruan elkartu ginen, eta orain ulertzen dugu apenas izan genuela denbora: analisia eginez bakarrik ulertzen duzu zer galdera egin behar dituzun.

Parte-hartzaile

Atzerriko erreportaje guztiak parte-hartzaileen erretratu batekin hasten dira, eta gehienak ez dira Errusiakoak. Errusiako inkestatuen ehunekoa % 5 eta 1 artean aldatzen da urtetik urtera, eta horrek ez du inolako ondoriorik ateratzen uzten.

Acelerate State of DevOps 2019 txostenaren mapa:

Gure azterketan, 889 pertsona elkarrizketatzea lortu dugu - hau dezente da (DORAk urtero mila pertsona inguru galdetzen ditu bere txostenetan) eta hemen helburua lortu dugu:

Egia da, gure parte-hartzaile guztiak ez ziren amaierara iritsi: osatzeko portzentajea erdia baino apur bat gutxiago izan zen. Baina hori ere nahikoa izan zen lagin adierazgarri bat lortzeko eta analisi bat egiteko. DORAk ez du betetze-ehunekorik azaltzen bere txostenetan, beraz, ez dago konparaziorik hemen.

Industriak eta postuak

Gure inkestatuek dozena bat industria ordezkatzen dituzte. Informazioaren teknologietan lan erdia. Horren atzetik datoz finantza zerbitzuak, merkataritza, telekomunikazioak eta beste. Lanpostuen artean espezialistak (garatzailea, probatzailea, operazio ingeniaria) eta zuzendaritzako langileak (talde, talde, arlo, zuzendariak) daude:

Bitik batek enpresa ertain baterako egiten du lan. Hirugarren pertsona bakoitzak enpresa handietan egiten du lan. Gehienak 9 laguneko taldeetan lan egiten dute. Bereiz, jarduera nagusiei buruz galdetu genuen, eta gehienak eragiketarekin lotuta daude nolabait, eta %40 inguru garapenean aritzen dira:

Beraz, industria, enpresa, talde ezberdinetako ordezkariak alderatzeko eta aztertzeko informazioa bildu genuen. Vitaly Khabarov nire lankideak analisiaren berri emango du.

Analisia eta konparazioa

Vitaly Khabarov: Mila esker gure inkesta bete, galdetegiak bete eta gure hipotesiak gehiago aztertzeko eta probatzeko datuak eman dizkiguten parte-hartzaile guztiei. Eta gure bezeroei eta bezeroei esker, industriaren kezkak identifikatzen eta gure ikerketan probatu ditugun hipotesiak formulatzen lagundu duen esperientzia ugari dugu.

Zoritxarrez, ezin da alde batetik galdera zerrenda bat eta bestetik datuak hartu, nolabait konparatu, esan: “Bai, dena horrela funtzionatzen du, arrazoi genuen” eta sakabanatu. Ez, metodologia eta metodo estatistikoak behar ditugu oker ez gaudela eta gure ondorioak fidagarriak direla ziurtatzeko. Ondoren, gure lan gehiago eraiki dezakegu datu hauetan oinarrituta:

Funtsezko neurketak

DORA metodologia hartu genuen oinarri, "Accelerate State of DevOps" liburuan zehatz deskribatu zutena. Funtsezko neurriak Errusiako merkaturako egokiak diren egiaztatu dugu, DORAk galderari erantzuteko erabiltzen duen moduan erabil daitezkeen: "Nola dagokio Errusiako industria atzerriko industriarekin?"

Funtsezko neurriak:

1. Hedapen maiztasuna. Zenbat aldiz zabaltzen da aplikazioaren bertsio berri bat produkzio-ingurunean (aurreikusitako aldaketak, konponketak eta gertakarien erantzuna kenduta)?
2. Entregatzeko epea. Zein da aldaketa bat egin arte (funtzionalitatea kode gisa idaztea) eta aldaketa produkzio-ingurunean zabaltzen den artean?
3. Berreskuratzeko denbora. Zenbat denbora behar da, batez beste, aplikazio bat produkzio-ingurune batera berrezartzeko, aplikazioen erabiltzaileei eragiten dien gorabeheraren, zerbitzuaren degradazio baten edo akatsen bat aurkitu ondoren?
4. Aldaketa arrakastatsuak. Ekoizpen-ingurunean inplementazioen zein ehunekotan aplikazioak hondatzea edo gorabeherak eragiten ditu eta konponketa eskatzen du (aldaketak atzera egitea, konponketa edo adabaki bat garatzea)?

DORAk bere ikerketan metrika horien eta erakundearen errendimenduaren arteko lotura aurkitu du. Gure azterketan ere probatzen dugu.

Baina lau neurketa gakoek zerbaitetan eragin dezaketela ziurtatzeko, ulertu behar duzu: nolabait erlazionatuta al daude elkarren artean? DORAk baietz erantzun zuen ohar batekin: arrakastarik gabeko aldaketen (Aldaketa hutsegite-tasa) eta beste hiru neurgailuen arteko erlazioa apur bat ahulagoa da. Irudi berdina lortu dugu. Entrega-denbora, inplementazio-maiztasuna eta berreskuratze-denbora elkarren artean erlazionatzen badira (korelazio hori Pearson-en korrelazioaren bidez eta Chaddock-en eskalaren bidez ezarri genuen), orduan ez dago korrelazio handirik arrakastarik gabeko aldaketekin.

Printzipioz, inkestatu gehienek produkzioan gorabehera kopuru txiki samarra dutela erantzun ohi dute. Aurrerago ikusiko dugun arren, inkestatu taldeen artean desberdintasun nabarmena dagoela arrakastarik gabeko aldaketei dagokienez, oraindik ezin dugu metrika hori erabili zatiketa honetarako.

Horixe egozten dugu (gure bezero batzuekin analisian eta komunikazioan ikusi den bezala) gertakaritzat hartzen denaren pertzepzioan alde txiki bat dagoela. Leiho teknikoan zehar gure zerbitzuaren errendimendua berreskuratzea lortu bagenu, gertakaritzat har al daiteke hori? Seguruenik ez, dena konpondu dugulako, bikainak gara. Gertakaritzat har al dezakegu gure aplikazioa 10 aldiz berritu behar izan bagenu modu normal eta ezagun batean? Ezetz dirudi. Hori dela eta, arrakastarik gabeko aldaketek beste metrika batzuekin duten erlazioaren auzia zabalik dago. Gehiago findu egingo dugu.

Garrantzitsua da hemen entrega denboraren, berreskuratze denboraren eta inplementazioaren maiztasunaren arteko korrelazio nabarmena aurkitu dugula. Hori dela eta, hiru neurri hauek hartu ditugu inkestatuak errendimendu taldeetan gehiago banatzeko.

Zenbat gramoetan zintzilikatu?

Kluster analisi hierarkikoa erabili dugu:

• Inkestatuak n dimentsioko espazio batean banatzen ditugu, non inkestatu bakoitzaren koordenatua galderen erantzunak diren.
• Inkestatu bakoitza kluster txikitzat hartzen da.
• Elkarrengandik hurbilen dauden bi multzoak multzo handiago batean konbinatzen ditugu.
• Hurrengo kluster parea aurkituko dugu eta multzo handiago batean konbinatzen ditugu.

Horrela taldekatzen ditugu inkestatu guztiak behar ditugun kluster kopuruan. Dendrograma baten laguntzaz (klusterren arteko konexioen zuhaitza), ondoko bi multzoen arteko distantzia ikusiko dugu. Bakarrik geratzen zaigu multzo horien artean distantzia muga jakin bat jartzea eta esatea: «Bi talde hauek elkarrengandik nahiko bereizten dira, haien arteko distantzia erraldoia delako».

Baina ezkutuko arazo bat dago hemen: ez dugu kluster kopuruan murrizketarik - 2, 3, 4, 10 kluster lor ditzakegu. Eta lehenengo ideia izan zen: zergatik ez gure inkestatu guztiak 4 taldetan banatu, DORAk egiten duen moduan. Baina ikusi dugu talde horien arteko ezberdintasunak hutsalak bihurtzen direla, eta ezin dugu ziurtatu inkestatua benetan bere taldekoa denik, eta ez aldamenekoa denik. Oraindik ezin dugu Errusiako merkatua lau taldetan banatu. Hori dela eta, hiru profiletan finkatu gara eta horien artean estatistikoki esanguratsua den aldea dago:

Jarraian, profila klusterren arabera zehaztu dugu: talde bakoitzeko metrika bakoitzaren mediana hartu eta errendimendu-profilen taula bat osatu dugu. Izan ere, talde bakoitzeko batez besteko parte-hartzailearen errendimendu profilak lortu ditugu. Hiru eraginkortasun-profil identifikatu ditugu: Baxua, Ertaina, Altua:

Hemen gure hipotesia berretsi genuen 4 neurketa gako egokiak direla errendimendu-profila zehazteko, eta bai Mendebaldeko eta Errusiako merkatuan funtzionatzen dutela. Aldea dago taldeen artean eta estatistikoki esanguratsua da. Azpimarratzen dut errendimendu-profilen artean alde nabarmena dagoela batez bestekoaren arabera arrakastarik gabeko aldaketen metrikaren arabera, nahiz eta hasieran inkestatuak parametro honen arabera zatitu ez genituen.

Orduan, galdera sortzen da: nola erabili hau guztia?

Nola erabili

Talderen bat, 4 neurketa giltzarri hartzen baditugu eta taulan aplikatzen baditugu, kasuen % 85ean ez dugu partida osoa lortuko - hau batez besteko parte-hartzailea da, eta ez errealitatean dagoena. Denak gara (eta talde guztiak) zertxobait desberdinak.

Egiaztatu dugu: gure inkestatuak eta DORAren errendimendu-profila hartu ditugu, eta inkestatu zenbateraino egokitzen diren begiratu dugu. Inkestatuen % 16 baino ez zela behin betiko sartzen ikusi dugu profiletako batean. Gainerako guztiak tartean sakabanatuta daude:

Horrek esan nahi du eraginkortasun-profilak esparru mugatua duela. Lehenengo hurbilpenean non zauden ulertzeko, taula hau erabil dezakezu: "Oh, badirudi Ertaina edo Handia hurbilago gaudela!" Hurrengo nora joan ulertzen baduzu, nahikoa izan daiteke. Baina zure helburua etengabeko hobekuntza bada, eta zehatzago jakin nahi baduzu non garatu eta zer egin, orduan funts gehigarriak behar dira. Kalkulagailu deitzen genien:

• DORA kalkulagailua
• Calculator Express 42* (garapenean)
• Garapen propioa (zure barne kalkulagailua sor dezakezu).

Zertarako behar dira? Ulertu:

• Gure erakundeko taldeak gure estandarrak betetzen ditu?
• Hala ez bada, lagundu al dezakegu, bizkortu gure enpresak duen esperientziaren esparruan?
• Hala bada, are hobeto egin al dezakegu?

Enpresa barruan estatistikak biltzeko ere erabil ditzakezu:

• Zein talde ditugu?
• Taldeak profiletan banatu;
• Ikusi: Oh, komando hauek errendimendu gutxikoak dira (ez dira pixka bat ateratzen), baina politak dira: egunero zabaltzen dira, akatsik gabe, ordubete baino gutxiagoko epea dute.

Eta orduan jakin dezakezu gure enpresaren barruan oraindik parean ez dauden talde horientzako beharrezko espezializazioa eta tresnak daudela.

Edo, konpainiaren barruan ondo sentitzen zarela ulertzen baduzu, asko baino hobea zara, orduan pixka bat zabalago begiratu dezakezu. Hau Errusiako industria besterik ez da: lor al dezakegu Errusiako industrian beharrezko esperientzia geure burua bizkortzeko? Express 42 kalkulagailuak lagunduko dizu hemen (garapenean dago). Errusiako merkatua gainditu baduzu, begiratu DORA kalkulagailua eta munduko merkatura.

Ederki. Eta DORA kalkulagailuan Elit taldean bazaude, zer egin beharko zenuke? Hemen ez dago irtenbide onik. Ziurrenik industriaren abangoardian zaude, eta azelerazio eta fidagarritasun gehiago posible da barneko I+G bidez eta baliabide gehiago gastatuz.

Goazen gozoenera - alderaketa.

konparazio

Hasieran Errusiako industria Mendebaldeko industriarekin alderatu nahi genuen. Zuzenean alderatzen badugu, ikusten dugu profil gutxiago ditugula, eta pixka bat gehiago nahasten direla elkarren artean, ertzak apur bat lausoagoak dira:

Gure elite-joleak goi-jartzaileen artean ezkutatuta daude, baina hor daude - hauek dira altuera esanguratsuak lortu dituzten eliteak, unikornioak. Errusian, Elite profilaren eta Goi profilaren arteko aldea ez da oraindik nahikoa nabarmena. Uste dugu etorkizunean bereizketa hori gertatuko dela ingeniaritza-kulturaren, ingeniaritza-praktiken ezarpenaren kalitatearen eta enpresen barneko espezializazioaren ondorioz.

Errusiako industriaren barnean konparazio zuzen batera pasatzen bagara, goi mailako taldeak hobeak direla ikus dezakegu alderdi guztietan. Neurri horien eta erakundearen errendimenduaren artean erlazio bat dagoela dioen gure hipotesia ere baieztatu dugu: profil handiko taldeek askoz ere litekeena da helburuak lortzeko ez ezik, gainditzea ere.
Bihur gaitezen goi mailako talde eta ez geldi gaitezen:

Baina aurtengoa berezia da, eta enpresek pandemia batean nola dauden egiaztatzea erabaki dugu: goi mailako taldeak askoz hobeto ari dira eta industriako batez bestekoa baino hobeto sentitzen dira:

• 1,5-2 aldiz produktu berriak kaleratzeko aukera gehiago,
• 2 aldiz litekeena da aplikazioen azpiegituraren fidagarritasuna eta/edo errendimendua hobetzeko.

Hau da, lehendik zeuzkaten gaitasunek azkarrago garatzen, produktu berriak abian jartzen, lehendik zeuden produktuak aldatzen lagundu zien, eta horrela merkatu berriak eta erabiltzaile berriak konkistatuz:

Zer gehiago lagundu die gure taldeei?

Ingeniaritza praktikak

Probatu dugun praktika bakoitzerako aurkikuntza esanguratsuen berri emango dizut. Beharbada, beste zerbaitek lagundu zien taldeei, baina DevOps-i buruz ari gara. Eta DevOps-en barruan, aldea ikusten dugu profil ezberdinetako taldeen artean.

Plataforma Zerbitzu gisa

Ez dugu erlazio esanguratsurik aurkitu plataformaren adinaren eta taldearen profilaren artean: Plataformak gutxi gorabehera aldi berean agertu ziren bai Behe-taldeentzat bai Goi-taldeentzat. Baina azken horretarako, plataformak, batez beste, zerbitzu gehiago eta programazio-interfaze gehiago eskaintzen ditu programa-kodearen bidez kontrolatzeko. Eta plataforma-taldeek litekeena da beren garatzaileei eta taldeei plataforma erabiltzen laguntzea, arazoak eta plataformarekin lotutako gorabeherak maizago konpontzea eta beste talde batzuk heztea.

Azpiegitura kode gisa

Hemen dena nahiko estandarra da. Azpiegitura kodearen lanaren automatizazioaren eta azpiegitura biltegiaren barruan zenbat informazio gordetzen den erlazio bat aurkitu dugu. Profil handiko komandoek informazio gehiago gordetzen dute biltegietan: hau da azpiegituraren konfigurazioa, CI / CD kanalizazioa, ingurunearen ezarpenak eta eraikitzeko parametroak. Informazio hori maizago gordetzen dute, hobeto lan egiten dute azpiegitura-kodearekin eta prozesu eta zeregin gehiago automatizatzen dituzte azpiegitura-kodearekin lan egiteko.

Interesgarria da azpiegitura probetan ez genuen alde handirik ikusi. Hau goi mailako taldeek orokorrean test automatizazio gehiago izateari egozten diot. Beharbada, ez dira azpiegitura probek bereizita distraitu behar, baizik eta aplikazioak egiaztatzen dituzten proba horiek, eta horiei esker dagoeneko ikusten dute zer eta non hautsi duten.

Integrazioa eta Entrega

Atal aspergarriena, izan ere, zenbat eta automatizazio gehiago izan, orduan eta hobeto lan egin kodearekin, orduan eta emaitza hobeak lortzeko probabilitate handiagoa izango duzula.

arkitektura

Mikrozerbitzuek errendimenduan nola eragiten duten ikusi nahi genuen. Egia esan, ez dute, mikrozerbitzuen erabilera ez baitago lotzen errendimendu-adierazleen gehikuntzarekin. Mikrozerbitzuak profil altuko komandoetarako eta profil baxuko komandoetarako erabiltzen dira.

Baina esanguratsua da Goi-taldeentzat, mikrozerbitzuen arkitekturarako trantsizioak beren zerbitzuak modu independentean garatu eta zabaltzea ahalbidetzen duela. Arkitekturak garatzaileei modu autonomoan jardutea ahalbidetzen badie, taldetik kanpoko norbaiten zain egon gabe, abiadura handitzeko funtsezko konpetentzia da hori. Kasu honetan, mikrozerbitzuek laguntzen dute. Eta haien ezarpenak ez du zeregin handirik jokatzen.

Nola deskubritu genuen hori guztia?

DORA metodologia guztiz errepikatzeko asmo handiko plan bat genuen, baina baliabiderik ez genuen. DORAk babesa asko erabiltzen badu eta haien ikerketak urte erdia behar badu, denbora gutxian egin dugu gure ikerketa. DORAk egiten duen bezala DevOps eredu bat eraiki nahi genuen, eta hori egingo dugu etorkizunean. Orain arte mapak berotzera mugatu gara:

Profil bakoitzeko taldeen artean ingeniaritza-praktiken banaketa aztertu genuen eta ikusi genuen goi mailako taldeek, batez beste, ingeniaritza praktikak erabiltzeko aukera gehiago zutela. Guzti honi buruz gehiago irakur dezakezu gure txostena.

Aldaketa baterako, pasa gaitezen estatistika konplexuetatik sinpleetara.

Zer gehiago aurkitu dugu?

Tresnak

Komando gehienak Linux familiako OSak erabiltzen dituela ikusten dugu. Baina Windows-ek joeran jarraitzen du - gure inkestatuen laurdenak gutxienez bere bertsioren bat edo beste erabiltzea adierazi du. Badirudi merkatuak behar hori duela. Hori dela eta, gaitasun horiek garatu eta hitzaldietan aurkezpenak egin ditzakezu.

Orkestratzaileen artean, ez da inorentzat sekretua, Kubernetes da lidergoan (%52). Hurrengo orkestratzailea Docker Swarm da (% 12 inguru). CI sistema ezagunenak Jenkins eta GitLab dira. Konfigurazioa kudeatzeko sistemarik ezagunena Ansible da, gure Shell maitea.

Amazon da gaur egun hodeiko ostalaritza hornitzaile nagusia. Errusiako hodeien kuota pixkanaka handitzen ari da. Datorren urtean interesgarria izango da Errusiako hodei hornitzaileak nola sentituko diren ikustea, haien merkatu kuota handituko den ala ez. Dira, erabil daitezke, eta hori ona da:

Igorri pasatzen diot hitza, eta honek estatistika gehiago emango ditu.

Praktiken zabalkundea

Igor Kurochkin: Bereiz, inkestatuei eskatu genien adieraztea nola banatzen diren kontuan hartutako ingeniaritza praktikak enpresan. Enpresa gehienetan, ikuspegi mistoa dago, eredu multzo ezberdinez osatua, eta proiektu pilotuak oso ezagunak dira. Profilen artean ere alde txiki bat ikusi dugu. Goi-mailako ordezkariek maizago erabiltzen dute "Ekimena behetik" eredua, espezialisten talde txikiek lan-prozesuak, tresnak aldatzen dituztenean eta praktika arrakastatsuak beste talde batzuekin partekatzen dituztenean. Medium-en, goitik beherako ekimena da, eta enpresa osoari eragiten dio komunitate eta bikaintasun zentroen sorreraren bidez:

Agile eta DevOps

Agile eta DevOps-en arteko loturaren auzia askotan eztabaidatzen da industrian. Gai hau 2019/2020rako Agilearen Egoera Txostenean ere planteatzen da, beraz, Agile eta DevOps jarduerak enpresetan nola konektatzen diren alderatzea erabaki dugu. Agilerik gabeko DevOps arraroa dela ikusi dugu. Inkestatuen erdiarentzat, Agilearen hedapena askoz lehenago hasi zen, eta %20 inguruk aldibereko hasiera ikusi zuten, eta profil baxuaren seinaleetako bat Agile eta DevOps praktikarik ez izatea izango da:

Agindu-topologiak

Iazko amaieran, liburuaTaldeko topologiak”, komandoen topologiak deskribatzeko marko bat proposatzen duena. Interesgarria egin zitzaigun Errusiar enpresentzat aplikagarria den ala ez. Eta galdera egin genion: “Zer eredu aurkitzen dituzu?”.

Inkestatuen erdian azpiegitura taldeak ikusten dira, baita garapen, proba eta funtzionamendurako talde bereiziak ere. DevOps talde bereiziek %45 adierazi zuten, eta horien artean High-eko ordezkariak ohikoagoak dira. Jarraian, funtzio gurutzatuko taldeak datoz, eta hauek ere ohikoagoak dira High-en. SRE komando bereiziak Goi eta Ertain profiletan agertzen dira eta oso gutxitan ikusten dira Behe ​​profilean:

DevQaOps ratioa

Galdera hau FaceBook-en ikusi genuen Skyeng plataformako taldeko liderrak - enpresetako garatzaileen, probatzaileen eta administratzaileen ratioa interesatzen zitzaion. Galdetu eta profiletan oinarritutako erantzunak aztertu ditugu: goi mailako ordezkariek proba eta operazio ingeniari gutxiago dituzte garatzaile bakoitzeko:

2021 urteko planak

Datorren urteko planetan, inkestatuek honako jarduera hauek adierazi dituzte:

Hemen DevOps Live 2020 konferentziarekiko elkargunea ikus dezakezu. Arretaz aztertu dugu programa:

• Azpiegitura produktu gisa
• DevOps eraldaketa
• DevOps praktiken banaketa
• DevSecOps
• Kasu-klubak eta eztabaidak

Baina gure aurkezpenaren denbora ez da nahikoa gai guztiak lantzeko. Eszena atzean utzita:

• Plataforma zerbitzu eta produktu gisa;
• Azpiegitura kode, ingurune eta hodei gisa;
• Etengabeko Integrazioa eta Entrega;
• Arkitektura;
• DevSecOps ereduak;
• Plataforma eta funtzio anitzeko taldeak.

txosten bolumen handikoa lortu dugu, 50 orrialdekoa, eta zehatzago ikus dezakezue.

Laburbilduz

Espero dugu gure ikerketak eta txostenak garapenerako, probak eta eragiketetarako ikuspegi berriekin esperimentatzera bultzatuko zaitugula, baita nabigatzen laguntzea, azterketako beste parte-hartzaileekin konparatzen eta zure planteamenduak hobetu ditzakezun arloak identifikatzen ere.

Errusiako DevOps-en egoeraren lehen azterketaren emaitzak:

• Funtsezko neurriak. Funtsezko neurketak (entrega-denbora, inplementazio-maiztasuna, berreskuratze-denbora eta aldaketa-hutsegiteak) garapen-, proba- eta eragiketa-prozesuen eraginkortasuna aztertzeko egokiak direla ikusi dugu.
• Profilak altua, ertaina, baxua. Bildutako datuetan oinarrituta, estatistikoki Altua, Ertaina, Baxua talde desberdinak bereiz ditzakegu metrika, praktika, prozesu eta tresnei dagokienez ezaugarri bereizgarriak dituztenak. High profileko ordezkariek Low baino emaitza hobeak erakusten dituzte. Beren helburuak lortzeko eta gainditzeko aukera gehiago dute.
• Adierazleak, pandemia eta 2021erako planak. Aurten adierazle berezi bat enpresek pandemiari nola aurre egin dioten da. Goi-ordezkariek hobeto ibili ziren, erabiltzaileen parte-hartze handiagoa izan zuten eta arrakastaren arrazoi nagusiak garapen prozesu eraginkorrak eta ingeniaritza kultura sendoa izan ziren.
• DevOps praktikak, tresnak eta haien garapena. Datorren urterako enpresen plan nagusien artean DevOps praktiken eta tresnen garapena, DevSecOps praktiken sarrera eta antolaketa-egituraren aldaketak daude. Eta DevOps praktiken ezarpen eta garapen eraginkorra proiektu pilotuen, komunitateen eta konpetentzia zentroen eraketa, enpresaren goiko eta beheko mailetako ekimenen laguntzarekin egiten da.

Zure iritziak, istorioak, iritziak entzutea gustatuko litzaiguke. Eskerrak ematen dizkiegu azterketan parte hartu duten guztiei eta datorren urtean zuen parte hartzea espero dugu.

Iturria: www.habr.com