Stanje DevOps-a u Rusiji 2020

Kako razumjeti stanje nečega?

Možete se osloniti na svoje mišljenje, formirano iz različitih izvora informacija, na primjer, publikacija na web stranicama ili iskustva. Možete pitati kolege, poznanike. Druga mogućnost je pogledati teme konferencija: programski odbor su aktivni predstavnici industrije, tako da im vjerujemo u odabiru relevantnih tema. Posebno područje su istraživanja i izvješća. Ali postoji problem. U svijetu se svake godine provode istraživanja o stanju DevOpsa, izvješća objavljuju strane tvrtke, a o ruskom DevOpsu gotovo da i nema informacija.

Ali došao je dan kada je takvo istraživanje provedeno, a danas ćemo govoriti o rezultatima. Stanje DevOps-a u Rusiji zajedno su proučavale tvrtke "Ekspres 42"A"Ontico". Express 42 pomaže tehnološkim tvrtkama u implementaciji i razvoju DevOps praksi i alata i bio je jedan od prvih koji je govorio o DevOpsu u Rusiji. Autori studije, Igor Kurochkin i Vitaly Khabarov, angažirani su u analizi i savjetovanju u Expressu 42, a imaju tehničko iskustvo iz rada i iskustvo u različitim tvrtkama. Tijekom 8 godina kolege su promatrali desetke tvrtki i projekata - od startupa do poduzeća - s različitim problemima, kao i različitom kulturnom i inženjerskom zrelošću.

Igor i Vitalij su u svom izvješću objasnili koji su problemi nastajali tijekom procesa istraživanja, kako su ih rješavali, kao i kako se u principu provode DevOps istraživanja te zašto je Express 42 odlučio provesti svoje. Možete vidjeti njihov izvještaj здесь.

DevOps istraživanje

Razgovor je započeo Igor Kuročkin.

Redovito pitamo publiku na DevOps konferencijama: "Jeste li pročitali izvješće o stanju DevOpsa za ovu godinu?" Rijetki dižu ruku, a naše je istraživanje pokazalo da ih proučava samo trećina. Ako nikada niste vidjeli takva izvješća, recimo odmah da su sva vrlo slična. Najčešće se pojavljuju fraze poput: "U usporedbi s prošlom godinom ..."

Ovdje imamo prvi problem, a nakon njega još dva:

1. Za prošlu godinu nemamo podataka. Stanje DevOps-a u Rusiji nikoga ne zanima;
2. Metodologija. Nije jasno kako testirati hipoteze, kako graditi pitanja, kako analizirati, uspoređivati ​​rezultate, pronalaziti veze;
3. Terminologija. Sva izvješća su na engleskom, prijevod je obavezan, zajednički okvir za DevOps još nije izmišljen i svatko izmišlja svoj.

Pogledajmo kako su analize DevOps stanja rađene diljem svijeta.

Povijest

DevOps istraživanje provodi se od 2011. godine. Puppet, developer sustava za upravljanje konfiguracijom, prvi ih je proveo. U to je vrijeme bio jedan od glavnih alata za opisivanje infrastrukture u obliku koda. Do 2013. te su studije bile jednostavno zatvorene ankete i bez javnih izvješća.

Godine 2013. pojavila se IT Revolution, izdavač svih važnijih knjiga o DevOpsu. Zajedno s Puppetom pripremili su prvu publikaciju State of DevOps u kojoj su se prvi put pojavila 4 ključna metrika. Sljedeće se godine uključila ThoughtWorks, konzultantska tvrtka poznata po svojim redovitim tehnološkim radarima o industrijskim praksama i alatima. A 2015. je dodan dio s metodologijom i postalo je jasno kako rade analizu.

Godine 2016. autori studije, nakon što su stvorili vlastitu tvrtku DORA (DevOps Research and Assessment), objavili su godišnje izvješće. Sljedeće godine DORA i Puppet objavili su posljednju zajedničku reportažu.

A onda je počelo nešto zanimljivo:

Godine 2018. tvrtke su se razdvojile i objavljena su dva neovisna izvješća: jedno od Puppet-a, drugo od DORA-e zajedno s Googleom. DORA je nastavila koristiti svoju metodologiju s ključnim metrikama, profilima izvedbe i inženjerskim praksama koje utječu na ključne metrike i izvedbu cijele tvrtke. I Puppet je ponudio vlastiti pristup s opisom procesa i evolucije DevOps-a. No priča nije zaživjela, 2019. Puppet je napustio ovu metodologiju i objavio novu verziju izvješća, u kojima su navedene ključne prakse i kako one utječu na DevOps s njihove točke gledišta. Zatim se dogodio još jedan događaj: Google je kupio DORA-u i zajedno su objavili još jedno izvješće. Možda ste ga vidjeli.

Ove godine stvari su se zakomplicirale. Poznato je da je Puppet pokrenuo vlastitu anketu. Napravili su to tjedan dana ranije od nas, a već je završilo. Sudjelovali smo u tome i pogledali koje ih teme zanimaju. Sada Puppet radi analizu i priprema se za objavu izvješća.

No još uvijek nema priopćenja DORE i Googlea. U svibnju, kada je anketa inače počela, stigla je informacija da je Nicole Forsgren, jedna od osnivačica DORE, prešla u drugu tvrtku. Stoga smo pretpostavili da istraživanja i izvješća DORE ove godine neće biti.

Kako stoje stvari u Rusiji?

Nismo proveli DevOps istraživanje. Govorili smo na konferencijama, prepričavali tuđa saznanja, a Raiffeisenbank je prevela "State of DevOps" za 2019. (njihovu objavu možete pronaći na Habréu), veliko im hvala. I to je sve.

Stoga smo proveli vlastito istraživanje u Rusiji koristeći metodologiju i nalaze DORA-e. Koristili smo izvješće kolega iz Raiffeisenbank za naše istraživanje, uključujući i sinkronizaciju terminologije i prijevoda. A pitanja relevantna za industriju preuzeta su iz izvješća DORA-e i ovogodišnjeg upitnika Puppet.

Proces istraživanja

Izvještaj je samo završni dio. Cijeli proces istraživanja sastoji se od četiri glavna koraka:

Tijekom pripremne faze intervjuirali smo stručnjake iz industrije i pripremili popis hipoteza. Na temelju njih sastavljena su pitanja i pokrenuta anketa za cijeli kolovoz. Zatim smo analizirali i pripremili samo izvješće. Za DORA-u ovaj proces traje 6 mjeseci. Upoznali smo se u roku od 3 mjeseca, a sada shvaćamo da smo jedva imali dovoljno vremena: tek provođenjem analize shvatit ćete koja pitanja trebate postaviti.

Sudionici

Sve strane reportaže počinju portretom sudionika, a većina ih nije iz Rusije. Postotak ruskih ispitanika varira od 5 do 1% iz godine u godinu, što ne dopušta bilo kakve zaključke.

Karta iz izvješća Accelerate State of DevOps 2019:

U našem istraživanju uspjeli smo intervjuirati 889 ljudi – to je dosta (DORA godišnje u svojim izvješćima anketira oko tisuću ljudi) i tu smo postigli cilj:

Istina, nisu svi naši sudionici stigli do kraja: postotak dovršenosti pokazao se nešto manjim od polovice. Ali i to je bilo dovoljno za dobivanje reprezentativnog uzorka i analizu. DORA u svojim izvješćima ne objavljuje postotke popunjenosti, tako da ovdje nema usporedbe.

Industrije i položaji

Naši ispitanici predstavljaju desetak industrija. Pola radi u informatici. Slijede financijske usluge, trgovina, telekomunikacije i dr. Među pozicijama su stručnjaci (programer, tester, operativni inženjer) i upravljačko osoblje (voditelji timova, grupa, područja, direktori):

Svaki drugi radi za srednje veliko poduzeće. Svaka treća osoba radi u velikim tvrtkama. Većina radi u timovima do 9 ljudi. Zasebno smo pitali o glavnim aktivnostima, a većina je nekako povezana s radom, a oko 40% bavi se razvojem:

Tako smo prikupili informacije za usporedbu i analizu predstavnika različitih industrija, tvrtki, timova. O analizi će reći moj kolega Vitaly Khabarov.

Analiza i usporedba

Vitaly Khabarov: Veliko hvala svim sudionicima koji su ispunili našu anketu, ispunili upitnike i dali nam podatke za daljnju analizu i testiranje naših hipoteza. A zahvaljujući našim klijentima i kupcima, imamo bogato iskustvo koje nam je pomoglo identificirati probleme koji zabrinjavaju industriju i formulirati hipoteze koje smo testirali u našem istraživanju.

Nažalost, ne možete samo uzeti popis pitanja s jedne strane i podataka s druge strane, nekako ih usporediti, reći: "Da, sve tako funkcionira, bili smo u pravu" i razići se. Ne, potrebna nam je metodologija i statističke metode kako bismo bili sigurni da ne griješimo i da su naši zaključci pouzdani. Tada možemo graditi svoj daljnji rad na temelju ovih podataka:

Ključne metrike

Za osnovu smo uzeli DORA metodologiju koju su detaljno opisali u knjizi “Accelerate State of DevOps”. Provjerili smo jesu li ključne metrike prikladne za rusko tržište, mogu li se koristiti na isti način kao što DORA koristi za odgovor na pitanje: "Kako industrija u Rusiji odgovara inozemnoj industriji?"

Ključne metrike:

1. Učestalost postavljanja. Koliko se često nova verzija aplikacije postavlja u produkcijsko okruženje (planirane promjene, isključujući hitne popravke i odgovor na incident)?
2. Vrijeme isporuke. Koje je prosječno vrijeme između izvršenja promjene (pisanje funkcionalnosti kao koda) i implementacije promjene u proizvodno okruženje?
3. Vrijeme oporavka. Koliko u prosjeku traje vraćanje aplikacije u proizvodno okruženje nakon incidenta, degradacije usluge ili otkrivanja pogreške koja utječe na korisnike aplikacije?
4. Neuspješne promjene. Koliki postotak implementacija u produkcijskom okruženju dovodi do degradacije aplikacije ili incidenata i zahtijeva popravak (vraćanje promjena, razvoj hitnog popravka ili zakrpe)?

DORA je u svom istraživanju pronašla vezu između ovih metrika i organizacijske uspješnosti. Također ga testiramo u našoj studiji.

Ali kako biste bili sigurni da četiri ključne metrike mogu utjecati na nešto, morate razumjeti - jesu li one nekako povezane jedna s drugom? DORA je odgovorila potvrdno uz jednu napomenu: odnos između neuspješnih promjena (Change Failure Rate) i tri druge metrike nešto je slabiji. Imamo otprilike istu sliku. Ako vrijeme isporuke, učestalost postavljanja i vrijeme oporavka međusobno koreliraju (tu smo korelaciju ustanovili kroz Pearsonovu korelaciju i kroz Chaddockovu ljestvicu), tada ne postoji tako jaka korelacija s neuspješnim promjenama.

U principu, većina ispitanika sklona je odgovoru da ima relativno mali broj incidenata u proizvodnji. Iako ćemo kasnije vidjeti da još uvijek postoji značajna razlika među skupinama ispitanika u pogledu neuspješnih promjena, ovu metriku još ne možemo koristiti za ovu podjelu.

To pripisujemo činjenici da (kako se pokazalo tijekom analize i komunikacije s nekim od naših kupaca) postoji mala razlika u percepciji onoga što se smatra incidentom. Ako smo uspjeli vratiti performanse naše usluge tijekom tehničkog prozora, može li se to smatrati incidentom? Vjerojatno ne, jer sve smo sredili, super nam je. Možemo li smatrati incidentom ako smo morali ponovno pokrenuti svoju aplikaciju 10 puta u uobičajenom, nama poznatom načinu rada? Čini se da nije. Stoga ostaje otvoreno pitanje odnosa neuspješnih promjena s drugim metrikama. Dodatno ćemo ga doraditi.

Ono što je ovdje važno jest da smo pronašli značajnu korelaciju između vremena isporuke, vremena oporavka i učestalosti implementacije. Stoga smo uzeli ove tri metrike kako bismo dodatno podijelili ispitanike u skupine na temelju produktivnosti.

Koliko visjeti u gramima?

Koristili smo hijerarhijsku klaster analizu:

• Ispitanike raspodjeljujemo u n-dimenzionalnom prostoru, gdje su koordinata svakog ispitanika njihovi odgovori na pitanja.
• Svaki ispitanik je proglašen malim klasterom.
• Spojimo dva grozda najbliža jedan drugome u jedan veći grozd.
• Pronalazimo sljedeći par klastera i spajamo ih u veći klaster.

Na ovaj način grupiramo sve naše ispitanike u onoliki broj klastera koji nam je potreban. Koristeći dendrogram (stablo veza između klastera) vidimo udaljenost između dva susjedna klastera. Sve što nam preostaje je postaviti određenu granicu udaljenosti između tih klastera i reći: “Ove dvije skupine se prilično razlikuju jedna od druge jer je udaljenost između njih gigantska.”

Ali tu postoji skriveni problem: nemamo ograničenja u broju klastera - možemo dobiti 2, 3, 4, 10 klastera. I prva ideja je bila - zašto ne podijeliti sve naše ispitanike u 4 grupe, kao što to radi DORA. No, ustanovili smo da razlike između tih skupina postaju beznačajne, te ne možemo biti sigurni pripada li ispitanik doista svojoj skupini, a ne susjednoj. Rusko tržište još ne možemo podijeliti u četiri skupine. Stoga smo se zaustavili na tri profila između kojih postoji statistički značajna razlika:

Zatim smo odredili profil prema klasterima: uzeli smo medijan za svaku metriku za svaku skupinu i sastavili tablicu profila izvedbe. Zapravo, dobili smo profile uspješnosti prosječnog sudionika u svakoj grupi. Identificirali smo tri profila učinkovitosti: niska, srednja, visoka:

Ovdje smo potvrdili našu hipotezu da su 4 ključne metrike prikladne za određivanje profila izvedbe i da rade i na zapadnom i na ruskom tržištu. Postoji razlika između skupina i ona je statistički značajna. Naglašavam da postoji značajna razlika između profila performansi u metrici neuspješnih promjena u prosjeku, iako nismo inicijalno dijelili ispitanike po tom parametru.

Onda se postavlja pitanje: kako sve to iskoristiti?

Kako koristiti

Ako uzmemo bilo koji tim, 4 ključne metrike i primijenimo ih na tablicu, tada u 85% slučajeva nećemo dobiti potpunu utakmicu - ovo je samo prosječni sudionik, a ne ono što je u stvarnosti. Svi smo (i svaki tim) malo drugačiji.

Provjerili smo: uzeli smo naše ispitanike i profil izvedbe DORA, te pogledali koliko ispitanika odgovara ovom ili onom profilu. Otkrili smo da samo 16% ispitanika sigurno spada u neki od profila. Svi ostali su raštrkani negdje između:

To znači da profil učinkovitosti ima ograničen opseg. Da biste razumjeli gdje ste u prvoj aproksimaciji, možete upotrijebiti ovu tablicu: "Oh, čini se da smo bliže srednjem ili visokom!" Ako razumijete kamo dalje, ovo bi moglo biti dovoljno. Ali ako je vaš cilj konstantno, kontinuirano usavršavanje i želite točnije znati gdje se razvijati i što raditi, tada su potrebna dodatna sredstva. Nazvali smo ih kalkulatorima:

• DORA kalkulator
• Calculator Express 42* (u razvoju)
• Vaš vlastiti razvoj (možete izraditi vlastiti interni kalkulator).

Za što su oni potrebni? Razumjeti:

• Zadovoljava li tim unutar naše organizacije naše standarde?
• Ako ne, možemo li pomoći, ubrzati u okviru stručnosti koju naša tvrtka ima?
• Ako je tako, možemo li još bolje?

Također ih možete koristiti za prikupljanje statistike unutar tvrtke:

• Koje timove imamo?
• Podijelite timove na profile;
• Vidite: Oh, ove naredbe imaju lošu izvedbu (ne izvlače se ni malo), ali ove su super: postavljaju se svaki dan, bez pogrešaka, imaju vrijeme čekanja manje od sat vremena.

A onda možete saznati da unutar naše tvrtke postoji potrebna stručnost i alati za one timove koji još nisu na visini.

Ili, ako shvatite da se unutar tvrtke osjećate odlično, bolji ste od mnogih, onda možete gledati malo šire. Ovo je samo ruska industrija: možemo li dobiti potrebnu stručnost u ruskoj industriji kako bismo se ubrzali? Ovdje će vam pomoći kalkulator Express 42 (u razvoju je). Ako ste prerasli rusko tržište, pogledajte DORA kalkulator i na svjetsko tržište.

Fino. A ako ste u Elit grupi na DORA kalkulatoru, što trebate učiniti? Nema tu dobrog rješenja. Najvjerojatnije ste na čelu industrije, a daljnje ubrzanje i pouzdanost mogući su kroz interno istraživanje i razvoj i trošenjem više resursa.

Prijeđimo na ono najslađe – usporedbu.

usporedba

U početku smo htjeli usporediti rusku industriju sa zapadnom industrijom. Ako direktno uspoređujemo, vidimo da imamo manje profila, i oni su malo više međusobno izmiješani, granice su malo nejasnije:

Naši Elitni izvođači skriveni su među Visokim izvođačima, ali oni su tu - to su elita, jednorozi koji su dosegli značajne visine. U Rusiji razlika između profila Elite i High profila još nije dovoljno značajna. Smatramo da će se u budućnosti to razdvajanje dogoditi zbog porasta inženjerske kulture, kvalitete implementacije inženjerskih praksi i stručnosti unutar tvrtki.

Ako prijeđemo na izravnu usporedbu unutar ruske industrije, možemo vidjeti da su timovi visokog profila bolji u svim aspektima. Također smo potvrdili našu hipotezu da postoji odnos između ovih metrika i organizacijske uspješnosti: mnogo je vjerojatnije da će istaknuti timovi ne samo postići ciljeve, već ih i premašiti.
Postanimo timovi visokog profila i nemojmo stati na tome:

Ali ova je godina posebna i odlučili smo provjeriti kako je tvrtkama u pandemiji: Timovi visokog profila rade puno bolje i osjećaju se bolje od prosjeka industrije:

• 1,5-2 puta veća vjerojatnost da će objaviti nove proizvode,
• 2 puta veća vjerojatnost poboljšanja pouzdanosti i/ili performansi aplikacijske infrastrukture.

Odnosno, kompetencije koje su već imali pomogle su im u bržem razvoju, lansiranju novih proizvoda, modificiranju postojećih proizvoda, osvajanju novih tržišta i novih korisnika:

Što je još pomoglo našim timovima?

Inženjerske prakse

Reći ću vam o značajnim nalazima za svaku praksu koju smo testirali. Možda je još nešto pomoglo timovima, ali govorimo o DevOpsu. I unutar DevOpsa vidimo razliku među timovima različitih profila.

Platforma kao usluga

Nismo pronašli značajan odnos između starosti platforme i profila tima: Platforme su se pojavile otprilike u isto vrijeme i za Nisko i za Visoke timove. Ali za potonje, platforma u prosjeku pruža više usluga i više programskih sučelja za kontrolu putem programskog koda. A vjerojatnije je da će platformski timovi pomoći svojim programerima i timovima da koriste platformu, češće rješavaju svoje probleme i incidente povezane s platformom te educiraju druge timove.

Infrastruktura kao šifra

Ovdje je sve prilično standardno. Pronašli smo vezu između automatizacije rada infrastrukturnog koda i količine informacija pohranjenih unutar infrastrukturnog repozitorija. Naredbe visokog profila pohranjuju više informacija u repozitorije: ovo je konfiguracija infrastrukture, CI/CD cjevovod, postavke okruženja i parametri izgradnje. Oni češće pohranjuju te informacije, bolje rade s infrastrukturnim kodom i automatiziraju više procesa i zadataka za rad s infrastrukturnim kodom.

Zanimljivo, nismo vidjeli značajnu razliku u infrastrukturnim testovima. To pripisujem činjenici da visoko profilirani timovi općenito imaju više automatizacije testiranja. Možda im ne treba posebno odvlačiti pažnju infrastrukturnim testovima, nego onim testovima kojima provjeravaju aplikacije i zahvaljujući njima već vide što su i gdje pokvarili.

Integracija i isporuka

Najdosadniji odjeljak, jer smo potvrdili: što više automatizacije imate, što bolje radite s kodom, vjerojatnije je da ćete dobiti bolje rezultate.

arhitektura

Htjeli smo vidjeti kako mikroservisi utječu na performanse. Istina, nemaju, budući da korištenje mikroservisa nije povezano s povećanjem pokazatelja uspješnosti. Mikroservisi se koriste i za naredbe visokog profila i za naredbe niskog profila.

Ali ono što je značajno jest da za High-teamove prijelaz na mikroservisnu arhitekturu omogućuje da samostalno razvijaju i uvode svoje usluge. Ako arhitektura omogućuje razvojnim programerima da djeluju autonomno, bez čekanja na nekoga van tima, onda je to ključna kompetencija za povećanje brzine. U ovom slučaju pomažu mikroservisi. I samo njihova implementacija ne igra veliku ulogu.

Kako smo sve to otkrili?

Imali smo ambiciozan plan da u potpunosti ponovimo DORA metodologiju, ali nedostajali su nam resursi. Ako DORA ima dosta sponzora i njihovo istraživanje traje pola godine, mi smo svoje istraživanje napravili u kratkom roku. Htjeli smo izgraditi DevOps model kao što to radi DORA i to ćemo činiti u budućnosti. Do sada smo se ograničili na toplinske karte:

Promatrali smo distribuciju inženjerskih praksi po timovima u svakom profilu i otkrili da će timovi visokog profila u prosjeku vjerojatnije koristiti inženjerske prakse. Više o svemu tome možete pročitati u našem izvješće.

Za promjenu, prijeđimo sa složenih statistika na jednostavne.

Što smo još otkrili?

Alat

Primjećujemo da većinu naredbi koristi OS iz obitelji Linux. Ali Windows je još uvijek u trendu - najmanje četvrtina naših ispitanika primijetila je korištenje jedne ili druge njegove verzije. Čini se da tržište ima tu potrebu. Stoga možete razviti te kompetencije i održati prezentacije na konferencijama.

Među orkestratorima, nije tajna ni za koga, prednjači Kubernetes (52%). Sljedeći na redu orkestrator je Docker Swarm (oko 12%). Najpopularniji CI sustavi su Jenkins i GitLab. Najpopularniji sustav za upravljanje konfiguracijom je Ansible, a slijedi ga naš voljeni Shell.

Amazon je trenutno vodeći pružatelj hostinga u oblaku. Udio ruskih oblaka postupno raste. Sljedeće godine bit će zanimljivo vidjeti kako će se osjećati ruski pružatelji oblaka, hoće li se njihov tržišni udio povećati. Jesu, mogu se koristiti, i to je dobro:

Predajem riječ Igoru koji će dati još malo statistike.

Širenje praksi

Igor Kurochkin: Zasebno smo zamolili ispitanike da navedu kako su razmatrane inženjerske prakse raspoređene u tvrtki. Većina tvrtki ima mješoviti pristup koji se sastoji od različitih skupova obrazaca, a pilot projekti su vrlo popularni. Također smo vidjeli malu razliku između profila. Predstavnici visokog profila češće koriste obrazac "Inicijativa odozdo", kada mali timovi stručnjaka mijenjaju radne procese, alate i dijele uspješne razvoje s drugim timovima. U Mediumu, ovo je inicijativa od vrha prema dolje koja dotiče cijelu tvrtku kroz stvaranje zajednica i centara izvrsnosti:

Agile i DevOps

Pitanje veze između Agile i DevOps često se raspravlja u industriji. Ovo pitanje je također postavljeno u State of Agile Report za 2019/2020, pa smo odlučili usporediti kako su Agile i DevOps aktivnosti povezane u tvrtkama. Otkrili smo da je DevOps bez Agilea rijedak. Za polovicu ispitanika, širenje Agile-a počelo je puno ranije, a oko 20% primijetilo je istovremeni početak, a jedan od znakova Low profilea bit će odsutnost Agile i DevOps praksi:

Topologije naredbi

Krajem prošle godine knjTimske topologije“, koji predlaže okvir za opisivanje naredbenih topologija. Postalo nam je zanimljivo je li to primjenjivo na ruske tvrtke. I postavili smo pitanje: "Koje uzorke nalazite?".

Infrastrukturni timovi uočeni su kod polovine ispitanika, kao i zasebni timovi za razvoj, testiranje i rad. Odvojeni DevOps timovi zabilježili su 45%, među kojima su predstavnici Higha češći. Slijede višefunkcionalni timovi, koji su također češći na High. Odvojene SRE naredbe pojavljuju se u High, Medium profilima i rijetko se vide u Low profilu:

Omjer DevQaOps

Ovo pitanje vidjeli smo na FaceBooku od voditelja Skyeng platformskog tima - zanimao ga je omjer programera, testera i administratora u tvrtkama. Pitali smo to i pogledali odgovore na temelju profila: Predstavnici visokog profila imaju manje inženjera za testiranje i operacije za svakog programera:

Planovi za 2021 godinu

U planovima za iduću godinu ispitanici su istaknuli sljedeće aktivnosti:

Ovdje možete vidjeti presjek s konferencijom DevOps Live 2020. Pažljivo smo pregledali program:

• Infrastruktura kao proizvod
• DevOps transformacija
• Distribucija DevOps praksi
• DevSecOps
• Klubovi slučajeva i rasprave

Ali vrijeme naše prezentacije nije dovoljno da pokrijemo sve teme. Ostalo iza scene:

• Platforma kao usluga i kao proizvod;
• Infrastruktura kao kod, okruženja i oblaci;
• Kontinuirana integracija i isporuka;
• Arhitektura;
• DevSecOps obrasci;
• Platforma i međufunkcionalni timovi.

Prijavi Naš je pozamašan, ima 50 stranica i možete ga detaljnije pogledati.

Sažimanje

Nadamo se da će vas naše istraživanje i izvješće potaknuti da eksperimentirate s novim pristupima razvoju, testiranju i radu, kao i da će vam pomoći da se orijentišete, usporedite se s drugima u studiji i identificirate područja u kojima možete poboljšati svoje pristupe .

Rezultati prve studije o stanju DevOps-a u Rusiji:

• Ključne metrike. Utvrdili smo da su ključne metrike (vrijeme isporuke, učestalost implementacije, vrijeme oporavka i neuspjele promjene) prikladne za analizu učinkovitosti procesa razvoja, testiranja i operacija.
• Profili Visoki, Srednji, Niski. Na temelju prikupljenih podataka moguće je razlikovati statistički različite skupine Visoka, Srednja, Niska s karakterističnim značajkama u pogledu metrike, praksi, procesa i alata. Predstavnici visokog profila pokazuju bolje rezultate od niskog. Veća je vjerojatnost da će postići i premašiti svoje ciljeve.
• Pokazatelji, pandemija i planovi za 2021. Poseban pokazatelj ove godine je kako su se tvrtke nosile s pandemijom. Visoki predstavnici su prošli bolje, iskusili su povećani angažman korisnika, a glavni razlozi uspjeha bili su učinkoviti razvojni procesi i jaka inženjerska kultura.
• DevOps prakse, alati i njihov razvoj. Glavni planovi tvrtki za iduću godinu uključuju razvoj DevOps praksi i alata, uvođenje DevSecOps praksi te promjene u organizacijskoj strukturi. A učinkovita implementacija i razvoj DevOps praksi provodi se uz pomoć pilot projekata, formiranja zajednica i centara izvrsnosti, inicijativa na višim i nižim razinama tvrtke.

Voljeli bismo čuti vaše povratne informacije, priče, povratne informacije. Zahvaljujemo svima koji su sudjelovali u istraživanju i veselimo se vašem sudjelovanju sljedeće godine.

Izvor: www.habr.com