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 opcija je da pogledate teme konferencija: programski odbor su aktivni predstavnici industrije, tako da im vjerujemo u odabiru relevantnih tema. Posebno područje su istraživanja i izvještaji. Ali postoji problem. Istraživanja o stanju DevOps-a u svijetu se sprovode godišnje, izvještaje objavljuju strane kompanije, a o ruskom DevOps-u gotovo da i nema informacija.
Ali došao je dan kada je takva studija sprovedena, a danas ćemo govoriti o rezultatima. Kompanije su zajedno proučavale stanje DevOps-a u Rusiji ""I"". Express 42 pomaže tehnološkim kompanijama da implementiraju i razvijaju DevOps prakse i alate i bio je jedan od prvih koji je govorio o DevOps-u u Rusiji. Autori studije, Igor Kuročkin i Vitalij Habarov, bave se analizom i konsaltingom u Express 42, dok imaju tehničku pozadinu iz poslovanja i iskustvo u različitim kompanijama. Tokom 8 godina, kolege su pregledale desetine kompanija i projekata - od startupa do preduzeća - sa različitim problemima, kao i različitom kulturnom i inženjerskom zrelošću.
Igor i Vitalij su u svom izveštaju ispričali koji su problemi bili u procesu istraživanja, kako su ih rešili, kao i kako se u principu sprovodi DevOps istraživanje i zašto je Express 42 odlučio da sprovede svoje. Njihov izvještaj se može pogledati .
DevOps Research
Razgovor je započeo Igor Kuročkin.
Redovno pitamo publiku na DevOps konferencijama: „Da li ste pročitali izvještaj o statusu DevOps-a za ovu godinu?“ Malo njih diže ruke, a naše istraživanje je pokazalo da ih je proučavala tek trećina. Ako nikada niste vidjeli takve izvještaje, recimo odmah da su svi vrlo slični. Najčešće postoje fraze poput: "U poređenju sa prošlom godinom..."
Ovdje imamo prvi problem, a nakon njega još dva:
- Nemamo podataka za prošlu godinu. Stanje DevOps-a u Rusiji nikoga ne zanima;
- Metodologija. Nije jasno kako testirati hipoteze, kako graditi pitanja, kako analizirati, upoređivati rezultate, pronaći veze;
- Terminologija. Svi izvještaji su na engleskom, prijevod je obavezan, zajednički DevOps okvir još nije izmišljen i svako dolazi sa svojim.
Pogledajmo kako su DevOps analize stanja rađene širom svijeta.
Istorijski podaci
DevOps istraživanje se provodi od 2011. Puppet, programer sistema za upravljanje konfiguracijom, bio je prvi koji ih je sproveo. U to vrijeme, to je bio jedan od glavnih alata za opisivanje infrastrukture u obliku koda. Do 2013. godine ove studije su bile samo zatvorene ankete i bez javnih izvještaja.
2013. godine pojavio se IT Revolution, izdavač svih velikih knjiga o DevOps-u. Zajedno sa Puppet-om pripremili su prvu State of DevOps publikaciju, u kojoj su se po prvi put pojavila 4 ključne metrike. Sljedeće godine uključila se ThoughtWorks, konsultantska kuća poznata po svojim redovnim tehnološkim radarima o industrijskim praksama i alatima. A 2015. je dodat dio s metodologijom i postalo je jasno kako oni vrše analizu.
Autori studije su 2016. godine, nakon što su stvorili vlastitu kompaniju DORA (DevOps Research and Assessment), objavili godišnji izvještaj. Sljedeće godine, DORA i Puppet objavili su posljednji zajednički izvještaj.
A onda je počelo nešto zanimljivo:
Godine 2018. kompanije su se podijelile i objavljena su dva nezavisna izvještaja: jedan od Puppet-a, drugi od DORA-e u suradnji s Google-om. DORA je nastavila da koristi svoju metodologiju sa ključnim metrikama, profilima performansi i inženjerskim praksama koje utiču na ključne metrike i performanse cele kompanije. I Puppet je ponudio vlastiti pristup s opisom procesa i evolucije DevOps-a. Ali priča nije zaživjela, 2019. Puppet je napustio ovu metodologiju i objavio novu verziju izvještaja, u kojoj su navedene ključne prakse i kako one utječu na DevOps sa njihove tačke gledišta. Zatim se dogodio još jedan događaj: Google je kupio DORA-u i zajedno su objavili još jedan izvještaj. Možda ste ga vidjeli.
Ove godine stvari su se zakomplikovale. Poznato je da je Puppet pokrenuo vlastitu anketu. Oni su to uradili nedelju dana ranije od nas, a već je završeno. Učestvovali smo u tome i pogledali koje ih teme zanimaju. Sada Puppet radi analizu i priprema se za objavljivanje izvještaja.
Ali još uvijek nema najave DORA-e i Google-a. U maju, kada je istraživanje obično počelo, stigla je informacija da je Nicole Forsgren, jedna od osnivačica DORE, prešla u drugu kompaniju. Stoga smo pretpostavili da ove godine neće biti istraživanja i izvještaja DORE.
Kako stoje stvari u Rusiji?
Nismo radili DevOps istraživanje. Razgovarali smo na konferencijama, prepričavajući tuđa otkrića, a Raiffeisenbank je prevela "State of DevOps" za 2019. (njihovu najavu možete pronaći na Habréu), veliko im hvala. I to je sve.
Stoga smo sproveli vlastito istraživanje u Rusiji koristeći DORA metodologiju i nalaze. Iskoristili smo izvještaj kolega iz Raiffeisenbanke za naše istraživanje, uključujući i za sinhronizaciju terminologije i prijevoda. A pitanja relevantna za industriju preuzeta su iz izvještaja DORA-e i ovogodišnjeg upitnika za lutke.
Istraživački proces
Izvještaj je samo završni dio. Cijeli proces istraživanja sastoji se od četiri glavna koraka:
Tokom pripremne faze, intervjuisali smo stručnjake iz industrije i pripremili listu hipoteza. Na osnovu njih su sastavljena pitanja i pokrenuta anketa za cijeli avgust. Zatim smo analizirali i pripremili sam izvještaj. Za DORA ovaj proces traje 6 mjeseci. Upoznali smo se u roku od 3 mjeseca, a sada shvaćamo da smo jedva imali dovoljno vremena: tek izvođenjem analize shvatite koja pitanja trebate postaviti.
učesnici
Svi strani izvještaji počinju portretom učesnika, a većina njih nije iz Rusije. Procenat ruskih ispitanika varira između 5 i 1% iz godine u godinu i to ne dozvoljava da se izvlače bilo kakvi zaključci.
Mapa iz izvještaja Accelerate State of DevOps 2019:
U našoj studiji uspjeli smo intervjuisati 889 ljudi – to je dosta (DORA u svojim izvještajima godišnje anketira oko hiljadu ljudi) i ovdje smo postigli cilj:
Istina, nisu svi naši sudionici stigli do kraja: postotak završenosti pokazao se nešto manjim od polovine. Ali i ovo je bilo dovoljno da se dobije reprezentativan uzorak i izvrši analiza. DORA u svojim izvještajima ne objavljuje postotak popunjenosti, tako da ovdje neće biti moguće porediti.
Industrije i pozicije
Naši ispitanici predstavljaju desetak industrija. Pola posla u informatičkoj tehnologiji. Zatim slijede finansijske usluge, trgovina, telekomunikacije i drugo. Među pozicijama su stručnjaci (programer, tester, operativni inženjer) i rukovodno osoblje (šefovi timova, grupa, područja, direktori):
Svaki drugi radi za srednje preduzeće. Svaka treća osoba radi u velikim kompanijama. Većina radi u timovima do 9 ljudi. Odvojeno smo pitali za glavne aktivnosti, a većina je nekako vezana za rad, a oko 40% se bavi razvojem:
Tako smo prikupili informacije za poređenje i analizu predstavnika različitih industrija, kompanija, timova. O analizi će reći moj kolega Vitalij Habarov.
Analiza i poređenje
Vitalij Habarov: Veliko hvala svim učesnicima koji su ispunili našu anketu, popunili upitnike i dali nam podatke za dalju analizu i testiranje naših hipoteza. A zahvaljujući našim klijentima i kupcima, imamo bogato iskustvo koje je pomoglo u prepoznavanju zabrinutosti industrije i formuliranju hipoteza koje smo testirali u našem istraživanju.
Nažalost, ne možete samo uzeti listu pitanja s jedne strane i podatke s druge, nekako ih uporediti, reći: „Da, sve tako funkcionira, bili smo u pravu“ i razići se. Ne, potrebne su metodologija i statističke metode da bismo bili sigurni da nismo pogriješili i da su naši zaključci pouzdani. Tada možemo izgraditi naš dalji rad na osnovu ovih podataka:
Ključne metrike
Za osnovu smo uzeli DORA metodologiju, koju su detaljno opisali u knjizi „Ubrzajte stanje DevOpsa“. Provjerili smo da li su ključne metrike prikladne za rusko tržište, da li se mogu koristiti na isti način kao što DORA koristi za odgovor na pitanje: „Kako industrija u Rusiji odgovara stranoj industriji?“
Ključni pokazatelji:
- Frekvencija implementacije. Koliko često se nova verzija aplikacije postavlja u proizvodno okruženje (planirane promjene, isključujući hitne popravke i odgovor na incidente)?
- Vrijeme dostave. Koliko je prosječno vrijeme između unošenja promjene (pisanja funkcionalnosti kao koda) i implementacije promjene u proizvodno okruženje?
- Vrijeme oporavka. Koliko je u prosjeku potrebno da se aplikacija vrati u proizvodno okruženje nakon incidenta, degradacije usluge ili otkrivanja greške koja pogađa korisnike aplikacije?
- Neuspješne promjene. Koliki postotak implementacija u proizvodnom okruženju dovodi do degradacije aplikacije ili incidenata i zahtijeva sanaciju (povrat promjena, razvoj hitne popravke ili zakrpe)?
DORA je u svom istraživanju pronašla vezu između ovih metrika i organizacijskih performansi. To također testiramo u našoj studiji.
Ali da biste bili sigurni da četiri ključne metrike mogu utjecati na nešto, morate razumjeti – da li su one na neki način povezane jedna s drugom? DORA je odgovorila potvrdno uz jedno upozorenje: odnos između neuspješnih promjena (Change Failure Rate) i tri druge metrike je nešto slabiji. Imamo otprilike istu sliku. Ako su vrijeme isporuke, učestalost implementacije i vrijeme oporavka međusobno u korelaciji (tu korelaciju smo utvrdili kroz Pearsonovu korelaciju i kroz Chaddockovu skalu), onda nema tako jake korelacije s neuspješnim promjenama.
U principu, većina ispitanika sklona je odgovoru da imaju prilično mali broj incidenata u proizvodnji. Iako ćemo kasnije vidjeti da i dalje postoji značajna razlika između grupa ispitanika u pogledu neuspješnih promjena, ovu metriku još ne možemo koristiti za ovu podjelu.
To pripisujemo činjenici da (kako se pokazalo tokom analize i komunikacije sa nekim od naših kupaca) postoji mala razlika u percepciji onoga što se smatra incidentom. Ako smo uspeli da povratimo performanse naše usluge tokom tehničkog perioda, da li se ovo može smatrati incidentom? Vjerovatno ne, jer smo sve sredili, super smo. Možemo li smatrati incidentom ako smo morali ponovo pokrenuti našu aplikaciju 10 puta u normalnom, nama poznatom načinu rada? Izgleda da nije. Stoga ostaje otvoreno pitanje odnosa neuspješnih promjena sa drugim metrikama. Dodatno ćemo ga usavršiti.
Ovdje je važno 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 dalje podijelili ispitanike u grupe učinka.
Koliko treba da visi u gramima?
Koristili smo hijerarhijsku klaster analizu:
- Ispitanike raspoređujemo po n-dimenzionalnom prostoru, gdje su koordinate svakog ispitanika njihovi odgovori na pitanja.
- Svaki ispitanik se proglašava malim klasterom.
- Kombiniramo dva najbliža klastera u jedan veći klaster.
- Pronalazimo sljedeći par klastera i kombiniramo ih u veći klaster.
Na ovaj način grupišemo sve naše ispitanike u broj klastera koji nam je potreban. Uz pomoć dendrograma (stabla veza između klastera) vidimo udaljenost između dva susjedna klastera. Sve što nam preostaje je da postavimo određenu granicu udaljenosti između ovih klastera i kažemo: "Ove dvije grupe se prilično razlikuju jedna od druge jer je udaljenost između njih gigantska."
Ali ovdje 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 čini DORA. Ali smo utvrdili da razlike između ovih grupa postaju neznatne, te ne možemo biti sigurni da ispitanik zaista pripada svojoj grupi, a ne susjednoj. Rusko tržište još ne možemo podijeliti u četiri grupe. Stoga smo se odlučili na tri profila između kojih postoji statistički značajna razlika:
Zatim smo odredili profil po klasterima: uzeli smo medijan za svaku metriku za svaku grupu i sastavili tabelu profila performansi. U stvari, dobili smo profile performansi prosječnog učesnika u svakoj grupi. Identifikovali smo tri profila efikasnosti: Niska, Srednja, Visoka:
Ovdje smo potvrdili našu hipotezu da su 4 ključne metrike pogodne za određivanje profila performansi, a funkcionišu i na zapadnom i na ruskom tržištu. Postoji razlika između grupa i ona je statistički značajna. Naglašavam da postoji značajna razlika između profila performansi u pogledu metrike neuspješnih promjena u smislu prosjeka, iako inicijalno nismo dijelili ispitanike po ovom parametru.
Tada se postavlja pitanje: kako sve to iskoristiti?
Kako koristiti
Ako uzmemo bilo koji tim, 4 ključne metrike i to primijenimo na tabelu, onda u 85% slučajeva nećemo dobiti potpunu utakmicu - ovo je samo prosječan učesnik, a ne ono što je u stvarnosti. Svi smo (i svaki tim) malo drugačiji.
Provjerili smo: uzeli smo naše ispitanike i DORA profil performansi i pogledali koliko ispitanika odgovara ovom ili onom profilu. Otkrili smo da samo 16% ispitanika definitivno spada u neki od profila. Svi ostali su razbacani negdje između:
To znači da profil efikasnosti ima ograničen opseg. Da biste razumjeli gdje se nalazite u prvoj aproksimaciji, možete koristiti ovu tabelu: "Oh, čini se da smo bliže srednjem ili visokom!" Ako shvatite kuda dalje, ovo bi moglo biti dovoljno. Ali ako je vaš cilj stalno, kontinuirano usavršavanje i želite da znate više gde da se razvijate i šta da radite, onda su potrebna dodatna sredstva. Nazvali smo ih kalkulatori:
- DORA kalkulator
- Calculator Express 42* (u razvoju)
- Vlastiti razvoj (možete kreirati vlastiti interni kalkulator).
Za šta su oni potrebni? Razumjeti:
- Da li je tim unutar naše organizacije u skladu sa našim standardima?
- Ako ne, možemo li pomoći, ubrzati u okviru stručnosti koju naša kompanija posjeduje?
- Ako je tako, možemo li još bolje?
Možete ih koristiti i za prikupljanje statistike unutar kompanije:
- Koje ekipe imamo?
- Podijelite timove u profile;
- Vidite: Oh, ove komande su loše (ne povlače se malo), ali su kul: implementiraju se svaki dan, bez grešaka, imaju vrijeme za isporuku manje od sat vremena.
I tada možete saznati da unutar naše kompanije postoji potrebna ekspertiza i alati za one timove koji još nisu na nivou.
Ili, ako shvatite da se u kompaniji osjećate sjajno, bolji ste od mnogih, onda možete pogledati malo šire. Ovo je samo ruska industrija: možemo li dobiti potrebnu ekspertizu u ruskoj industriji kako bismo se ubrzali? Tu će pomoći kalkulator Express 42 (u razvoju je). Ako ste prerasli rusko tržište, pogledajte i na svjetsko tržište.
U redu. A ako ste u Elit grupi na DORA kalkulatoru, šta da radite? Ovdje nema dobrog rješenja. Najvjerovatnije ste na čelu industrije, a daljnje ubrzanje i pouzdanost mogući su kroz interno istraživanje i razvoj i trošenje više resursa.
Pređimo na najslađe – poređenje.
Upoređivanje
U početku smo želeli da uporedimo rusku industriju sa zapadnom industrijom. Ako uporedimo direktno, vidimo da imamo manje profila, a oni su malo više pomiješani jedni s drugima, granice su malo nejasnije:
Naši Elitni izvođači su skriveni među Visokim izvođačima, ali oni su tu - to su elita, jednorozi koji su dostigli značajne visine. U Rusiji razlika između profila Elite i High profila još nije dovoljno značajna. Mislimo da će u budućnosti do ovog razdvajanja doći zbog povećanja inženjerske kulture, kvaliteta implementacije inženjerske prakse i stručnosti unutar kompanija.
Ako pređemo na direktno poređenje unutar ruske industrije, možemo vidjeti da su timovi visokog profila bolji u svim aspektima. Također smo potvrdili našu hipotezu da postoji veza između ovih metrika i organizacijskih performansi: timovi visokog profila imaju mnogo veću vjerovatnoću ne samo da postignu ciljeve, već ih i premaše.
Postanimo timovi visokog profila i nemojmo stati na tome:
Ali ova godina je posebna i odlučili smo provjeriti kako se kompanije ponašaju u pandemiji: timovi visokog profila rade mnogo bolje i osjećaju se bolje od prosjeka industrije:
- 1,5-2 puta veća vjerovatnoća da će objaviti nove proizvode,
- 2 puta veća vjerovatnoća da će poboljšati pouzdanost i/ili performanse aplikativne infrastrukture.
Odnosno, kompetencije koje su već imali pomogle su im da se brže razvijaju, lansiraju nove proizvode, modificiraju postojeće proizvode, čime osvajaju nova tržišta i nove korisnike:
Šta 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 DevOps-u. A unutar DevOps-a vidimo razliku među timovima različitih profila.
Platforma kao usluga
Nismo pronašli značajnu vezu između starosti platforme i profila tima: platforme su se pojavile otprilike u isto vrijeme i za Low-timove i za High-timove. Ali za ovo drugo, platforma pruža, u prosjeku, više usluga i više programskih interfejsa za kontrolu kroz programski kod. I platformski timovi će vjerojatnije pomoći svojim programerima i timovima da koriste platformu, češće rješavaju svoje probleme i incidente vezane za platformu i educiraju druge timove.
Infrastruktura kao kod
Ovdje je sve prilično standardno. Pronašli smo vezu između automatizacije rada infrastrukturnog koda i količine informacija pohranjenih unutar infrastrukturnog spremišta. Komande visokog profila pohranjuju više informacija u spremišta: ovo je konfiguracija infrastrukture, CI/CD cjevovod, postavke okruženja i parametri izgradnje. Oni češće pohranjuju ove informacije, bolje rade s infrastrukturnim kodom i automatiziraju više procesa i zadataka za rad s infrastrukturnim kodom.
Zanimljivo je da nismo vidjeli značajnu razliku u infrastrukturnim testovima. Ovo pripisujem činjenici da timovi visokog profila općenito imaju više automatizacije testiranja. Možda ih ne bi trebalo posebno ometati infrastrukturni testovi, već oni testovi kojima provjeravaju aplikacije i zahvaljujući njima već vide šta su i gdje su pokvarili.
Integracija i isporuka
Najdosadniji dio, jer smo potvrdili da što više automatizacije imate, što bolje radite sa kodom, veća je vjerovatnoća da ćete dobiti bolje rezultate.
arhitektura
Željeli smo vidjeti kako mikroservis utiče na performanse. Istina, nemaju, jer korištenje mikroservisa nije povezano s povećanjem pokazatelja učinka. Mikroservis se koristi i za komande visokog profila i za komande niskog profila.
Ali ono što je značajno je da za High-timove prelazak na mikroservisnu arhitekturu omogućava im da samostalno razvijaju svoje usluge i uvedu ih. Ako arhitektura dozvoljava programerima da djeluju autonomno, bez čekanja na nekoga izvan tima, onda je to ključna kompetencija za povećanje brzine. U ovom slučaju pomažu mikroservis. I samo njihova implementacija ne igra veliku ulogu.
Kako smo sve ovo otkrili?
Imali smo ambiciozan plan da u potpunosti ponovimo DORA metodologiju, ali nam su nedostajali resursi. Ako DORA koristi mnogo sponzorstva i njihovo istraživanje traje pola godine, mi smo svoje istraživanje uradili za kratko vrijeme. Željeli smo izgraditi DevOps model kao što to radi DORA, i to ćemo raditi u budućnosti. Do sada smo se ograničili na toplotne karte:
Pogledali smo distribuciju inženjerskih praksi po timovima u svakom profilu i otkrili da su timovi visokog profila, u prosjeku, češće koristili inženjerske prakse. Više o svemu tome možete pročitati u našoj .
Za promjenu, prijeđimo sa složenih statistika na jednostavne.
Šta smo još otkrili?
Alati
Primećujemo da većinu komandi koristi OS Linux porodice. Ali Windows je i dalje u trendu - najmanje četvrtina naših ispitanika je primijetila korištenje jedne ili druge njegove verzije. Čini se da tržište ima tu potrebu. Stoga možete razvijati ove kompetencije i izlagati na konferencijama.
Među orkestratorima, ni za koga nije tajna, prednjači Kubernetes (52%). Sljedeći u redu orkestrator je Docker Swarm (oko 12%). Najpopularniji CI sistemi su Jenkins i GitLab. Najpopularniji sistem za upravljanje konfiguracijom je Ansible, a slijedi ga naš voljeni Shell.
Amazon je trenutno vodeći provajder hostinga u oblaku. Udio ruskih oblaka se postepeno povećava. Sljedeće godine će biti zanimljivo vidjeti kako će se osjećati ruski cloud provajderi, da li će njihov tržišni udio porasti. Jesu, mogu se koristiti i to je dobro:
Prepuštam riječ Igoru, koji će dati još malo statistike.
Širenje prakse
Igor Kurochkin: Zasebno, pitali smo ispitanike da navedu kako se razmatrane inženjerske prakse distribuiraju u kompaniji. U većini kompanija postoji mješoviti pristup, koji se sastoji od različitog skupa obrazaca, a pilot projekti su veoma popularni. Vidjeli smo i 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 prakse sa drugim timovima. U Medium-u, ovo je inicijativa odozgo prema dolje koja utiče na cijelu kompaniju kroz stvaranje zajednica i centara izvrsnosti:
Agile i DevOps
Pitanje veze između Agile-a i DevOps-a često se raspravlja u industriji. Ovo pitanje je pokrenuto i u Izvještaju o stanju Agile-a za 2019/2020, pa smo odlučili da uporedimo kako su Agile i DevOps aktivnosti povezane u kompanijama. Otkrili smo da je DevOps bez Agile-a rijedak. Za polovinu ispitanika, širenje Agile-a počelo je mnogo ranije, a oko 20% je uočilo istovremeni početak, a jedan od znakova niskog profila bit će odsustvo Agile i DevOps praksi:
Topologije komandi
Krajem prošle godine knjiga“, koji predlaže okvir za opisivanje komandnih topologija. Postalo nam je zanimljivo da li je to primjenjivo na ruske kompanije. I postavili smo pitanje: “Koje obrasce nalazite?”.
Infrastrukturni timovi su posmatrani kod polovine ispitanika, kao i odvojeni timovi za razvoj, testiranje i rad. Odvojeni DevOps timovi zabilježili su 45%, među kojima su češći predstavnici High-a. Sljedeće dolaze multifunkcionalni timovi, koji su također češći u High. Odvojene SRE komande se pojavljuju u visokom, srednjem profilu i rijetko se viđaju u niskom profilu:
DevQaOps omjer
Ovo pitanje smo vidjeli na FaceBook-u od vođe tima Skyeng platformskog tima – zanimao ga je omjer programera, testera i administratora u kompanijama. Pitali smo to i pogledali odgovore na osnovu profila: Predstavnici visokog profila imaju manje testnih i operativnih inženjera za svakog programera:
Planovi za 2021 godinu
U planovima za narednu godinu ispitanici su istakli sljedeće aktivnosti:
Ovdje možete vidjeti raskrsnicu sa konferencijom DevOps Live 2020. Pažljivo smo pregledali program:
- Infrastruktura kao proizvod
- DevOps transformacija
- Distribucija DevOps praksi
- DevSecOps
- Klubovi slučajeva i diskusije
Ali vrijeme našeg izlaganja nije dovoljno da pokrijemo sve teme. Ostalo iza kulisa:
- Platforma kao usluga i kao proizvod;
- Infrastruktura kao kod, okruženja i oblaci;
- Kontinuirana integracija i isporuka;
- Arhitektura;
- DevSecOps obrasci;
- Platformski i višefunkcionalni timovi.
dobili smo obiman, 50 strana, a možete ga pogledati detaljnije.
Sumiranje
Nadamo se da će vas naše istraživanje i izvještaj inspirisati da eksperimentišete s novim pristupima razvoju, testiranju i radu, kao i da će vam pomoći da se krećete, uporedite se s drugim učesnicima u studiji i identificirate područja u kojima možete poboljšati vlastite pristupe.
Rezultati prve studije stanja DevOps-a u Rusiji:
- Ključne metrike. Otkrili smo da su ključne metrike (vrijeme isporuke, učestalost implementacije, vrijeme oporavka i neuspjesi promjena) prikladne za analizu učinkovitosti procesa razvoja, testiranja i rada.
- Profili Visoki, Srednje, Niski. Na osnovu prikupljenih podataka možemo razlikovati statistički različite grupe Visoka, Srednja, Niska sa karakterističnim karakteristikama u pogledu metrike, praksi, procesa i alata. Predstavnici visokog profila pokazuju bolje rezultate od niskog. Veća je vjerovatnoća da će postići i premašiti svoje ciljeve.
- Indikatori, pandemija i planovi za 2021. Poseban pokazatelj ove godine je kako su se kompanije nosile sa pandemijom. Visoki predstavnici su prošli bolje, iskusili povećan angažman korisnika, a glavni razlozi uspjeha bili su efikasni razvojni procesi i jaka inženjerska kultura.
- DevOps prakse, alati i njihov razvoj. Glavni planovi kompanija za narednu godinu su razvoj DevOps praksi i alata, uvođenje DevSecOps praksi, te promjene u organizacionoj strukturi. A efikasna implementacija i razvoj DevOps praksi se odvija uz pomoć pilot projekata, formiranja zajednica i centara izvrsnosti, inicijativa na višim i nižim nivoima kompanije.
Voljeli bismo čuti vaše povratne informacije, priče, povratne informacije. Zahvaljujemo se svima koji su učestvovali u istraživanju i radujemo se vašem učešću sljedeće godine.
izvor: www.habr.com