Ŝtato de DevOps en Rusio 2020

Kiel kompreni la staton de io?

Vi povas fidi vian opinion, formitan el diversaj fontoj de informoj, ekzemple, publikaĵoj en retejoj aŭ sperto. Vi povas demandi kolegojn, konatojn. Alia eblo estas rigardi la temojn de la konferencoj: la programa komitato estas aktivaj reprezentantoj de la industrio, do ni fidas ilin en elekto de koncernaj temoj. Aparta areo estas esplorado kaj raportoj. Sed estas problemo. Esplorado pri la stato de DevOps estas farita ĉiujare en la mondo, raportoj estas publikigitaj de eksterlandaj kompanioj, kaj preskaŭ ne ekzistas informoj pri rusa DevOps.

Sed venis la tago, kiam tia studo estis farita, kaj hodiaŭ ni parolos pri la rezultoj. La stato de DevOps en Rusio estis studita kune de la kompanioj "Ekspreso 42"Kaj"Ontiko". Express 42 helpas teknologiajn kompaniojn efektivigi kaj evoluigi DevOps-praktikojn kaj ilojn kaj estis unu el la unuaj se temas pri paroli pri DevOps en Rusio. La aŭtoroj de la studo, Igor Kurochkin kaj Vitaly Khabarov, okupiĝas pri analizo kaj konsultado ĉe Express 42, dum ili havas teknikan fonon de operacio kaj sperto en malsamaj kompanioj. Dum 8 jaroj, kolegoj rigardis dekojn da kompanioj kaj projektoj - de noventreprenoj ĝis entreprenoj - kun malsamaj problemoj, same kiel malsama kultura kaj inĝenieristiko matureco.

En ilia raporto, Igor kaj Vitaly rakontis, kiaj problemoj estis en la procezo de esplorado, kiel ili solvis ilin, same kiel kiel DevOps-esplorado estas farita principe kaj kial Express 42 decidis fari sian propran. Ilia raporto estas rigardebla tie.

Esplorado pri DevOps

La konversacion komencis Igor Kuroĉkin.

Ni regule demandas la spektantaron ĉe DevOps-konferencoj, "Ĉu vi legis la DevOps-statustan raporton por ĉi tiu jaro?" Malmultaj levas la manojn, kaj nia studo montris, ke nur triono studas ilin. Se vi neniam vidis tiajn raportojn, ni tuj diru, ke ili ĉiuj estas tre similaj. Plej ofte estas frazoj kiel: "Kompare kun la pasinta jaro..."

Jen ni havas la unuan problemon, kaj post ĝi du pli:

1. Ni ne havas datumojn pri la pasinta jaro. La stato de DevOps en Rusio interesas neniun;
2. Metodologio. Ne estas klare kiel testi hipotezojn, kiel konstrui demandojn, kiel analizi, kompari rezultojn, trovi ligojn;
3. Terminologio. Ĉiuj raportoj estas en la angla, tradukado estas postulata, komuna DevOps-kadro ankoraŭ ne estis inventita kaj ĉiu elpensas sian propran.

Ni rigardu kiel DevOps-ŝtataj analizoj estis faritaj tra la mondo.

Historia Fono

DevOps-esplorado estis farita ekde 2011. Puppet, programisto de agordaj administradsistemoj, estis la unua se temas pri konduki ilin. Tiutempe, ĝi estis unu el la ĉefaj iloj por priskribi la infrastrukturon en formo de kodo. Ĝis 2013, tiuj studoj estis simple fermitaj enketoj kaj neniuj publikaj raportoj.

En 2013 aperis IT Revolution, la eldonisto de ĉiuj gravaj libroj pri DevOps. Kune kun Puppet, ili preparis la unuan publikaĵon State of DevOps, kie 4 ŝlosilaj metrikoj aperis unuafoje. La sekvan jaron, ThoughtWorks, konsilanta firmao konata pro siaj regulaj teknologiaj radaroj pri industriopraktikoj kaj iloj, engaĝiĝis. Kaj en 2015, sekcio kun metodiko estis aldonita, kaj evidentiĝis kiel ili faras la analizon.

En 2016, la aŭtoroj de la studo, kreinte sian propran kompanion DORA (DevOps Research and Assessment), publikigis jaran raporton. La sekvan jaron, DORA kaj Pupeto publikigis sian lastan komunan raporton.

Kaj tiam io interesa komenciĝis:

En 2018, la kompanioj disiĝis kaj du sendependaj raportoj estis publikigitaj: unu de Puppet, la dua de DORA kune kun Guglo. DORA daŭre utiligis sian metodaron kun ŝlosilaj metrikoj, agado-profiloj kaj inĝenieraj praktikoj, kiuj influas ŝlosilajn metrikojn kaj tutkompanian agadon. Kaj Puppet proponis sian propran aliron kun priskribo de la procezo kaj la evoluo de DevOps. Sed la rakonto ne enradikiĝis, en 2019 Puppet forlasis ĉi tiun metodaron kaj publikigis novan version de la raportoj, kiuj listigis la ŝlosilajn praktikojn kaj kiel ili influas DevOps de sia vidpunkto. Tiam okazis alia evento: Guglo aĉetis DORA, kaj kune ili publikigis alian raporton. Vi eble vidis lin.

Ĉi-jare, aferoj komplikiĝis. Oni scias, ke Puppet lanĉis sian propran enketon. Ili faris ĝin unu semajnon pli frue ol ni, kaj ĝi jam finiĝis. Ni partoprenis ĝin kaj rigardis pri kiuj temoj ili interesiĝas. Nun Puppet faras sian analizon kaj prepariĝas por publikigi la raporton.

Sed ankoraŭ ne estas anonco de DORA kaj Guglo. En majo, kiam la enketo kutime komenciĝis, venis informo ke Nicole Forsgren, unu el la fondintoj de DORA, translokiĝis al alia firmao. Tial ni supozis, ke ĉi-jare ne estos esploro kaj raporto de DORA.

Kiel fartas la aferoj en Rusio?

Ni ne faris esplorojn pri DevOps. Ni parolis en konferencoj, rerakontante la trovojn de aliaj homoj, kaj Raiffeisenbank tradukis "Stato de DevOps" por 2019 (vi povas trovi ilian anoncon ĉe Habré), multe dankon al ili. Kaj estas ĉio.

Tial ni faris nian propran esploradon en Rusio uzante metodologiojn kaj rezultojn de DORA. Ni uzis la raporton de kolegoj de Raiffeisenbank por nia esplorado, inkluzive por sinkronigado de terminologio kaj tradukado. Kaj industrie rilataj demandoj estis prenitaj el DORA-raportoj kaj la ĉi-jara Puppet-enketilo.

Esplorprocezo

La raporto estas nur la fina parto. La tuta esplorprocezo konsistas el kvar ĉefaj ŝtupoj:

Dum la preparfazo, ni intervjuis industriajn spertulojn kaj preparis liston de hipotezoj. Sur ilia bazo estis kompilitaj demandoj kaj estis lanĉita enketo por la tuta aŭgusto. Poste ni analizis kaj preparis la raporton mem. Por DORA, ĉi tiu procezo daŭras 6 monatojn. Ni renkontiĝis ene de 3 monatoj, kaj nun ni komprenas, ke ni apenaŭ havis sufiĉe da tempo: nur per la analizo vi komprenas, kiajn demandojn vi devas demandi.

partoprenantoj

Ĉiuj eksterlandaj raportoj komenciĝas per portreto de la partoprenantoj, kaj la plej multaj el ili ne estas el Rusio. La procento de rusaj respondantoj fluktuas inter 5 kaj 1% de jaro al jaro, kaj tio ne ebligas konkludi.

Mapo de la raporto Akceli Ŝtaton de DevOps 2019:

En nia studo, ni sukcesis intervjui 889 homojn - tio estas sufiĉe multe (DORA sondas ĉirkaŭ mil homojn ĉiujare en ĝiaj raportoj) kaj ĉi tie ni atingis la celon:

Vere, ne ĉiuj niaj partoprenantoj atingis la finon: la procento de kompletigo montriĝis iomete malpli ol duono. Sed eĉ ĉi tio sufiĉis por akiri reprezentan specimenon kaj fari analizon. DORA ne malkaŝas plenigajn procentojn en siaj raportoj, do ne estas komparo ĉi tie.

Industrioj kaj pozicioj

Niaj respondantoj reprezentas dekduon da industrioj. Duona laboro en informa teknologio. Sekvas financaj servoj, komerco, telekomunikadoj kaj aliaj. Inter la pozicioj estas specialistoj (programisto, elprovilo, operacia inĝeniero) kaj administrada personaro (ĉefoj de teamoj, grupoj, areoj, direktoroj):

Unu el du laboras por mezgranda firmao. Ĉiu tria persono laboras en grandaj kompanioj. Plej multaj laboras en teamoj de ĝis 9 homoj. Aparte, ni demandis pri la ĉefaj agadoj, kaj la plimulto iel rilatas al la operacio, kaj ĉirkaŭ 40% okupiĝas pri disvolviĝo:

Do ni kolektis informojn por komparo kaj analizo de reprezentantoj de malsamaj industrioj, kompanioj, teamoj. Pri la analizo rakontos mia kolego Vitalij Ĥabarov.

Analizo kaj komparo

Vitaly Khabarov: Koran dankon al ĉiuj partoprenantoj, kiuj kompletigis nian enketon, plenigis demandarojn kaj provizis al ni datumojn por plia analizo kaj testado de niaj hipotezoj. Kaj danke al niaj klientoj kaj klientoj, ni havas abundon da sperto, kiu helpis identigi industriajn zorgojn kaj formuli la hipotezojn, kiujn ni provis en nia esplorado.

Bedaŭrinde, vi ne povas simple preni liston de demandoj unuflanke kaj datumojn aliflanke, iel kompari ilin, diri: "Jes, ĉio funkcias tiel, ni pravis" kaj disvastigi. Ne, metodiko kaj statistikaj metodoj necesas por certigi, ke ni ne eraras kaj niaj konkludoj estas fidindaj. Tiam ni povas konstrui nian pluan laboron surbaze de ĉi tiuj datumoj:

Ŝlosilaj Metrikoj

Ni prenis la DORA-metodaron kiel bazon, kiun ili priskribis detale en la libro "Akceli Ŝtaton de DevOps". Ni kontrolis ĉu la ŝlosilaj mezuroj taŭgas por la rusa merkato, ĉu ili povas esti uzataj same kiel DORA uzas por respondi la demandon: "Kiel la industrio en Rusio respondas al la eksterlanda industrio?"

Ŝlosilaj mezuroj:

1. Ofteco de deplojo. Kiom ofte estas nova versio de la aplikaĵo deplojita al la produktadmedio (planitaj ŝanĝoj, ekskludante varmigojn kaj okazaĵrespondon)?
2. Livera tempo. Kio estas la averaĝa tempo inter farado de ŝanĝo (skribado de funkcieco kiel kodo) kaj deplojado de la ŝanĝo al la produktadmedio?
3. Tempo de reakiro. Kiom da tempo necesas averaĝe por restarigi aplikaĵon al produktadmedio post okazaĵo, servo-malboniĝo aŭ malkovro de cimo, kiu influas aplikaĵuzantojn?
4. Malsukcesaj ŝanĝoj. Kia procento de deplojoj en la produktadmedio kondukas al aplikaĵa degenero aŭ incidentoj kaj postulas solvadon (malfunkciigo de ŝanĝoj, disvolviĝo de varmigo aŭ flikaĵo)?

DORA en sia esplorado trovis ligon inter ĉi tiuj metrikoj kaj organiza agado. Ni ankaŭ testas ĝin en nia studo.

Sed por certigi, ke la kvar ŝlosilaj mezuroj povas influi ion, vi devas kompreni - ĉu ili estas iel rilataj unu al la alia? DORA respondis jese kun unu averto: la rilato inter malsukcesaj ŝanĝoj (Ŝanĝi Malsukceso-Indico) kaj tri aliaj metrikoj estas iomete pli malforta. Ni ricevis proksimume la saman bildon. Se livera tempo, deploja frekvenco kaj reakiro tempo korelacias unu kun la alia (ni establis ĉi tiun korelacion per la Pearson-korelacio kaj per la Chaddock-skalo), tiam ne ekzistas tia forta korelacio kun malsukcesaj ŝanĝoj.

Principe, la plej multaj el la respondantoj emas respondi, ke ili havas sufiĉe malgrandan nombron da okazaĵoj en produktado. Kvankam ni vidos poste, ke ankoraŭ ekzistas grava diferenco inter la grupoj de respondantoj laŭ malsukcesaj ŝanĝoj, ni ankoraŭ ne povas uzi ĉi tiun metrikon por ĉi tiu divido.

Ni atribuas ĉi tion al la fakto, ke (kiel ĝi rezultis dum la analizo kaj komunikado kun iuj el niaj klientoj) estas eta diferenco en la percepto de tio, kio estas konsiderata incidento. Se ni sukcesis restarigi la agadon de nia servo dum la teknika fenestro, ĉu tio povas esti konsiderata incidento? Verŝajne ne, ĉar ni riparis ĉion, ni estas bonegaj. Ĉu ni povas konsideri ĝin incidento se ni devus reruligi nian aplikaĵon 10 fojojn en normala, konata reĝimo por ni? Ŝajnas ne. Tial, la demando pri la rilato de malsukcesaj ŝanĝoj kun aliaj metrikoj restas malfermita. Ni rafinos ĝin plu.

Grava ĉi tie estas, ke ni trovis gravan korelacion inter livertempoj, reakiro kaj ofteco de deplojo. Sekve, ni prenis ĉi tiujn tri metrikojn por plu dividi la respondantojn en agadgrupojn.

Kiom pezi en gramoj?

Ni uzis hierarkian grupan analizon:

• Ni distribuas respondantojn sur n-dimensia spaco, kie la koordinato de ĉiu respondanto estas iliaj respondoj al demandoj.
• Ĉiu respondanto estas deklarita malgranda areto.
• Ni kombinas la du aretojn plej proksimajn unu al la alia en unu pli grandan areton.
• Ni trovas la sekvan paron de aretoj kaj kombinas ilin en pli grandan areton.

Jen kiel ni grupigas ĉiujn niajn respondintojn en la nombron da aretoj, kiujn ni bezonas. Helpe de dendrogramo (arbo de ligoj inter aretoj), ni vidas la distancon inter du najbaraj aretoj. Restas al ni nur fiksi certan distancolimon inter tiuj ĉi aretoj kaj diri: "Ĉi tiuj du grupoj estas sufiĉe distingeblaj unu de la alia ĉar la distanco inter ili estas giganta."

Sed estas kaŝita problemo ĉi tie: ni ne havas limigojn pri la nombro da aretoj - ni povas akiri 2, 3, 4, 10 aretojn. Kaj la unua ideo estis - kial ne dividi ĉiujn niajn respondintojn en 4 grupojn, kiel faras DORA. Sed ni trovis, ke la diferencoj inter tiuj ĉi grupoj fariĝas sensignifaj, kaj ni ne povas esti certaj, ke la respondanto vere apartenas al sia grupo, kaj ne al la najbara. Ni ankoraŭ ne povas dividi la rusan merkaton en kvar grupojn. Tial ni decidiĝis pri tri profiloj inter kiuj estas statistike signifa diferenco:

Poste, ni determinis la profilon per aretoj: ni prenis la medianon por ĉiu metriko por ĉiu grupo kaj kompilis tabelon de agado-profiloj. Fakte, ni ricevis la agadprofilojn de la averaĝa partoprenanto en ĉiu grupo. Ni identigis tri efikecprofilojn: Malalta, Meza, Alta:

Ĉi tie ni konfirmis nian hipotezon, ke 4-ŝlosilaj metrikoj taŭgas por determini la rendimentan profilon, kaj ili funkcias ambaŭ en la okcidenta kaj rusa merkato. Estas diferenco inter la grupoj kaj ĝi estas statistike signifa. Mi emfazas, ke estas grava diferenco inter la agado-profiloj laŭ la metriko de malsukcesaj ŝanĝoj laŭ la mezumo, kvankam ni komence ne dividis la respondantojn per ĉi tiu parametro.

Tiam ekestas la demando: kiel uzi ĉion ĉi?

Kiel uzi

Se ni prenas iun teamon, 4 ŝlosilajn metrikojn kaj aplikas ĝin al la tabelo, tiam en 85% de kazoj ni ne ricevos kompletan matĉon - ĉi tio estas nur averaĝa partoprenanto, kaj ne kio estas en la realeco. Ni ĉiuj (kaj ĉiu teamo) estas iomete malsamaj.

Ni kontrolis: ni prenis niajn respondintojn kaj la profilon de DORA-agado, kaj rigardis kiom da respondantoj taŭgas ĉi tiun aŭ alian profilon. Ni trovis, ke nur 16% de la respondintoj certe falis en unu el la profiloj. Ĉiuj ceteraj estas disigitaj ie intere:

Ĉi tio signifas, ke la efikecprofilo havas limigitan amplekson. Por kompreni kie vi estas en la unua proksimuma proksimumado, vi povas uzi ĉi tiun tabelon: "Ho, ŝajnas, ke ni estas pli proksimaj al Meza aŭ Alta!" Se vi komprenas kien iri poste, tio eble sufiĉos. Sed se via celo estas konstanta, kontinua plibonigo, kaj vi volas scii pli precize kie disvolvi kaj kion fari, tiam necesas pliaj financoj. Ni nomis ilin kalkuliloj:

• DORA kalkulilo
• Kalkulilo Express 42* (evolua)
• Propra evoluo (vi povas krei vian propran internan kalkulilon).

Por kio ili estas bezonataj? Kompreni:

• Ĉu la teamo ene de nia organizo estas laŭ niaj normoj?
• Se ne, ĉu ni povas helpi ĝin, akceli ĝin kadre de la kompetenteco, kiun nia kompanio havas?
• Se jes, ĉu ni povas fari eĉ pli bone?

Vi ankaŭ povas uzi ilin por kolekti statistikojn ene de la kompanio:

• Kiajn teamojn ni havas?
• Dividu teamojn en profilojn;
• Vidu: Ho, ĉi tiuj komandoj estas malfortaj (ili ne eltiras iomete), sed ĉi tiuj estas bonegaj: ili deplojas ĉiutage, sen eraroj, ili havas plumbotempon de malpli ol horo.

Kaj tiam vi povas ekscii, ke ene de nia kompanio ekzistas la necesaj kompetentecoj kaj iloj por tiuj teamoj, kiuj ankoraŭ ne estas alĝustigitaj.

Aŭ, se vi komprenas, ke vi sentas vin bonege ene de la kompanio, vi estas pli bona ol multaj, tiam vi povas aspekti iom pli larĝa. Ĉi tio estas nur la rusa industrio: ĉu ni povas akiri la necesan kompetentecon en la rusa industrio por akceli nin? La kalkulilo Express 42 helpos ĉi tie (ĝi estas evoluinta). Se vi superis la rusan merkaton, tiam rigardu DORA kalkulilo kaj al la monda merkato.

Bone. Kaj se vi estas en la Elit-grupo sur la DORA-kalkulilo, kion vi faru? Ne estas bona solvo ĉi tie. Vi plej verŝajne estas ĉe la avangardo de la industrio, kaj plia akcelo kaj fidindeco eblas per interna R&D kaj elspezado de pli da rimedoj.

Ni transiru al la plej dolĉa - komparo.

Komparo

Ni komence volis kompari rusan industrion kun okcidenta industrio. Se ni komparas rekte, ni vidas, ke ni havas malpli da profiloj, kaj ili estas iom pli miksitaj unu kun la alia, la randoj estas iom pli malklaraj:

Niaj Elitaj artistoj estas kaŝitaj inter la Altuloj, sed ili estas tie - ĉi tiuj estas la elitaj, unikornoj, kiuj atingis signifajn altecojn. En Rusio, la diferenco inter la Elita profilo kaj la Alta profilo ankoraŭ ne estas sufiĉe grava. Ni pensas, ke estonte ĉi tiu disiĝo okazos pro pliiĝo de inĝenieristiko, la kvalito de efektivigo de inĝenieraj praktikoj kaj kompetenteco ene de kompanioj.

Se ni transiras al rekta komparo ene de la rusa industrio, ni povas vidi, ke la altprofilaj teamoj estas pli bonaj en ĉiuj aspektoj. Ni ankaŭ konfirmis nian hipotezon, ke ekzistas rilato inter ĉi tiuj metrikoj kaj organiza rendimento: Altprofilaj teamoj estas multe pli verŝajne ne nur atingi celojn, sed ankaŭ superi ilin.
Ni iĝu altprofilaj teamoj kaj ne ĉesu tie:

Sed ĉi tiu jaro estas speciala, kaj ni decidis kontroli kiel kompanioj fartas en pandemio: altprofilaj teamoj fartas multe pli bone kaj sentas sin pli bone ol la industria averaĝo:

• 1,5-2 fojojn pli verŝajne liberigi novajn produktojn,
• 2 fojojn pli verŝajne plibonigi la fidindecon kaj/aŭ agadon de la aplika infrastrukturo.

Tio estas, la kompetentecoj, kiujn ili jam havis, helpis ilin disvolvi pli rapide, lanĉi novajn produktojn, modifi ekzistantajn produktojn, tiel konkerante novajn merkatojn kaj novajn uzantojn:

Kio alia helpis niajn teamojn?

Inĝenieristikaj praktikoj

Mi rakontos al vi pri la signifaj trovoj por ĉiu praktiko, kiun ni provis. Eble io alia helpis la teamojn, sed ni parolas pri DevOps. Kaj ene de DevOps, ni vidas diferencon inter teamoj de malsamaj profiloj.

Platformo kiel Servo

Ni ne trovis signifan rilaton inter platforma aĝo kaj teamprofilo: Platformoj aperis proksimume samtempe por kaj Malalt-teamoj kaj Alt-teamoj. Sed por ĉi-lasta, la platformo disponigas, averaĝe, pli da servoj kaj pli da programaj interfacoj por kontrolo per programkodo. Kaj platformaj teamoj pli ofte helpas siajn programistojn kaj teamojn uzi la platformon, solvi siajn problemojn kaj platform-rilatajn incidentojn pli ofte kaj eduki aliajn teamojn.

Infrastrukturo kiel kodo

Ĉio estas sufiĉe norma ĉi tie. Ni trovis rilaton inter aŭtomatigado de la laboro de la infrastruktura kodo kaj kiom da informoj estas stokitaj ene de la infrastruktura deponejo. La Altprofilaj komandoj stokas pli da informoj en la deponejoj: ĉi tio estas la infrastruktura agordo, CI / KD-dukto, medio-agordoj kaj konstruaj parametroj. Ili konservas ĉi tiujn informojn pli ofte, funkcias pli bone kun infrastruktura kodo kaj aŭtomatigas pli da procezoj kaj taskoj por labori kun infrastruktura kodo.

Interese, ni ne vidis gravan diferencon en infrastrukturaj testoj. Mi atribuas tion al la fakto, ke altprofilaj teamoj ĝenerale havas pli da testaŭtomatigo. Eble ili ne devas distri ilin aparte per infrastrukturaj provoj, sed prefere tiuj testoj, per kiuj ili kontrolas aplikaĵojn, kaj danke al ili ili jam vidas kion kaj kie ili rompis.

Integriĝo kaj livero

La plej enuiga sekcio, ĉar ni konfirmis, ke ju pli da aŭtomatigo vi havas, des pli bone vi laboras kun la kodo, des pli verŝajne vi ricevos pli bonajn rezultojn.

arkitekturo

Ni volis vidi kiel mikroservoj influas rendimenton. Vere, ili ne faras, ĉar la uzo de mikroservoj ne rilatas al pliigo de rendimentaj indikiloj. Mikroservoj estas uzataj por Altprofilaj komandoj kaj Malaltprofilaj komandoj.

Sed kio estas signifa estas, ke por Altaj teamoj, la transiro al mikroserva arkitekturo permesas al ili sendepende disvolvi siajn servojn kaj disvolvi. Se la arkitekturo permesas al programistoj agi aŭtonome, sen atendi iun eksteran al la teamo, tiam ĉi tio estas ŝlosila kompetenteco por pliigi rapidecon. En ĉi tiu kazo, mikroservoj helpas. Kaj nur ilia efektivigo ne ludas grandan rolon.

Kiel ni malkovris ĉion ĉi?

Ni havis ambician planon plene reprodukti la DORA-metodaron, sed mankis la rimedoj. Se DORA uzas multe da sponsorado kaj ilia esplorado daŭras duonjaron, ni faris nian esploron en mallonga tempo. Ni volis konstrui DevOps-modelon kiel DORA faras, kaj ni faros tion estonte. Ĝis nun ni limigis nin al varmigaj mapoj:

Ni rigardis la distribuadon de inĝenieraj praktikoj tra teamoj en ĉiu profilo kaj trovis, ke Altaj profilaj teamoj, averaĝe, pli verŝajne uzis inĝenierajn praktikojn. Vi povas legi pli pri ĉio ĉi en nia raporto.

Por ŝanĝi, ni ŝanĝu de kompleksaj statistikoj al simplaj.

Kion alian ni malkovris?

Iloj

Ni observas, ke la plej multaj el la komandoj estas uzataj de la OS de la familio Linukso. Sed Vindozo daŭre estas en tendenco - almenaŭ kvarono de niaj respondantoj rimarkis la uzadon de unu aŭ alia el ĝiaj versioj. Ŝajnas, ke la merkato havas ĉi tiun bezonon. Tial vi povas disvolvi ĉi tiujn kompetentecojn kaj fari prezentojn ĉe konferencoj.

Inter la orkestroj, ĝi ne estas sekreto por neniu, Kubernetes estas en la antaŭeco (52%). La sekva en linio orkestranto estas Docker Swarm (proksimume 12%). La plej popularaj CI-sistemoj estas Jenkins kaj GitLab. La plej populara agorda administradsistemo estas Ansible, sekvata de nia kara Ŝelo.

Amazon estas nuntempe la ĉefa provizanto pri nuba gastigado. La parto de rusaj nuboj iom post iom pliiĝas. Venontjare estos interese vidi kiel sentos rusaj nubaj provizantoj, ĉu ilia merkatparto pliiĝos. Ili estas, ili povas esti uzataj, kaj tio estas bona:

Mi pasas la parolon al Igor, kiu donos pliajn statistikojn.

Disvastigo de praktikoj

Igor Kurochkin: Aparte, ni petis respondantojn indiki kiel la konsiderataj inĝenieraj praktikoj estas distribuitaj en la kompanio. En plej multaj kompanioj, ekzistas miksita aliro, konsistanta el malsama aro de ŝablonoj, kaj pilotprojektoj estas tre popularaj. Ni ankaŭ vidis etan diferencon inter la profiloj. Reprezentantoj de la Alta profilo pli ofte uzas la ŝablonon "Iniciato de malsupre", kiam malgrandaj teamoj de specialistoj ŝanĝas laborprocezojn, ilojn kaj dividas sukcesajn praktikojn kun aliaj teamoj. Ĉe Medium, ĉi tio estas desupra iniciato, kiu influas la tutan kompanion per la kreado de komunumoj kaj centroj de plejboneco:

Agile kaj DevOps

La demando pri la rilato inter Agile kaj DevOps ofte estas diskutata en la industrio. Ĉi tiu problemo ankaŭ estas levita en la Raporto pri Ŝtato de Agile por 2019/2020, do ni decidis kompari kiel Agile kaj DevOps-agadoj estas konektitaj en kompanioj. Ni trovis, ke DevOps sen Agile estas malofta. Por duono de la respondantoj, la disvastiĝo de Agile komenciĝis multe pli frue, kaj ĉirkaŭ 20% observis la samtempan komencon, kaj unu el la signoj de Malalta profilo estos la foresto de Agile kaj DevOps-praktikoj:

Komandaj topologioj

Fine de la pasinta jaro, la libro "Teamaj topologioj”, kiu proponas kadron por priskribi komandtopologiojn. Fariĝis interese al ni ĉu ĝi aplikeblas al rusaj kompanioj. Kaj ni demandis la demandon: "Kiujn ŝablonojn vi trovas?".

Infrastrukturaj teamoj estas observitaj en duono de la respondantoj, same kiel apartaj teamoj por evoluo, testado kaj operacio. Apartaj DevOps-teamoj notis 45%, inter kiuj reprezentantoj de High estas pli oftaj. Poste venas transfunkciaj teamoj, kiuj ankaŭ estas pli oftaj ĉe High. Apartaj SRE-komandoj aperas en la Alta, Meza profiloj kaj malofte vidiĝas en la Malalta profilo:

DevQaOps-proporcio

Ni vidis ĉi tiun demandon sur FaceBook de la teamgvidanto de la Skyeng platformteamo - li interesiĝis pri la proporcio de programistoj, testistoj kaj administrantoj en kompanioj. Ni demandis ĝin kaj rigardis la respondojn bazitajn sur profiloj: Altprofilaj reprezentantoj havas malpli da testaj kaj operaciaj inĝenieroj por ĉiu programisto:

Planoj por 2021

En la planoj por la venonta jaro, la respondantoj notis la sekvajn agadojn:

Ĉi tie vi povas vidi la intersekciĝon kun la konferenco DevOps Live 2020. Ni zorge reviziis la programon:

• Infrastrukturo kiel produkto
• DevOps transformo
• Distribuado de DevOps-praktikoj
• DevSecOps
• Kazaj kluboj kaj diskutoj

Sed la tempo de nia prezentado ne sufiĉas por kovri ĉiujn temojn. Malantaŭ la scenoj:

• Platformo kiel servo kaj kiel produkto;
• Infrastrukturo kiel kodo, medioj kaj nuboj;
• Kontinua Integriĝo kaj Livero;
• Arkitekturo;
• DevSecOps ŝablonoj;
• Platformaj kaj transfunkciaj teamoj.

Raporto ni ricevis grandan, 50 paĝojn, kaj vi povas vidi ĝin pli detale.

Supre

Ni esperas, ke nia esplorado kaj raporto inspiros vin eksperimenti kun novaj aliroj al disvolviĝo, testado kaj operacioj, kaj ankaŭ helpos vin navigi, kompari vin kun aliaj partoprenantoj en la studo kaj identigi areojn kie vi povas plibonigi viajn proprajn alirojn.

Rezultoj de la unua studo pri la stato de DevOps en Rusio:

• Ŝlosilaj metrikoj. Ni trovis, ke ŝlosilaj metrikoj (livera tempo, deploja frekvenco, reakiro-tempo kaj ŝanĝaj malsukcesoj) taŭgas por analizi la efikecon de evoluado, testado kaj operaciaj procezoj.
• Profiloj Alta, Meza, Malalta. Surbaze de la kolektitaj datumoj, ni povas distingi statistike malsamajn grupojn de Alta, Meza, Malalta kun karakterizaj trajtoj laŭ metrikoj, praktikoj, procezoj kaj iloj. Reprezentantoj de la Alta profilo montras pli bonajn rezultojn ol Malalta. Ili pli verŝajne atingos kaj superos siajn celojn.
• Indikiloj, pandemio kaj planoj por 2021. Speciala indikilo ĉi-jare estas kiel kompanioj traktis la pandemion. La Altaj reprezentantoj fartis pli bone, spertis pliigitan engaĝiĝon de uzantoj, kaj la ĉefkialoj de sukceso estis efikaj evoluprocezoj kaj forta inĝenieristikkulturo.
• DevOps-praktikoj, iloj kaj ilia evoluo. La ĉefaj planoj de kompanioj por la venonta jaro inkluzivas la disvolviĝon de DevOps-praktikoj kaj iloj, la enkonduko de DevSecOps-praktikoj kaj ŝanĝoj en la organiza strukturo. Kaj la efika efektivigo kaj evoluo de DevOps-praktikoj estas efektivigitaj kun la helpo de pilotprojektoj, la formado de komunumoj kaj centroj de ekscelenco, iniciatoj ĉe la supraj kaj malsuperaj niveloj de la kompanio.

Ni ŝatus aŭdi viajn komentojn, rakontojn, komentojn. Ni dankas ĉiujn kiuj partoprenis en la studo kaj antaŭĝojas vian partoprenon venontjare.

fonto: www.habr.com