Stanje DevOps v Rusiji 2020

Kako razumeti stanje nečesa?

Lahko se zanesete na svoje mnenje, oblikovano iz različnih virov informacij, na primer iz objav na spletnih mestih ali izkušenj. Lahko vprašate kolege, znance. Druga možnost je pogled na teme konferenc: programski odbor so aktivni predstavniki industrije, zato jim zaupamo pri izbiri relevantnih tem. Posebno področje so raziskave in poročila. Vendar obstaja problem. V svetu vsako leto potekajo raziskave o stanju DevOps, poročila objavljajo tuja podjetja, o ruskih DevOpsih pa skoraj ni informacij.

Toda prišel je dan, ko je bila takšna študija izvedena in danes bomo govorili o rezultatih. Stanje DevOps v Rusiji so skupaj preučila podjetja "Ekspres 42"In"Ontico". Express 42 pomaga tehnološkim podjetjem izvajati in razvijati prakse in orodja DevOps in je bil eden prvih, ki je govoril o DevOps v Rusiji. Avtorja študije, Igor Kurochkin in Vitaly Khabarov, se ukvarjata z analizo in svetovanjem v Express 42, hkrati pa imata tehnično ozadje iz delovanja in izkušnje v različnih podjetjih. V 8 letih so kolegi opazovali na desetine podjetij in projektov – od startupov do podjetij – z različnimi težavami, pa tudi z različno kulturno in inženirsko zrelostjo.

Igor in Vitaly sta v svojem poročilu razložila, kakšne težave so se pojavljale med raziskovalnim procesom, kako so jih reševale, kako načeloma potekajo DevOps raziskave in zakaj so se pri Express 42 odločili za lastne. Ogledate si lahko njihovo poročilo tukaj.

DevOps raziskave

Pogovor je začel Igor Kuročkin.

Občinstvo na konferencah DevOps redno sprašujemo: "Ste prebrali poročilo o stanju DevOps za to leto?" Le redki dvignejo roko, naša študija pa je pokazala, da jih preučuje le tretjina. Če še niste videli takšnih poročil, takoj povejmo, da so si vsa zelo podobna. Najpogosteje so fraze, kot so: "V primerjavi z lanskim letom ..."

Tukaj imamo prvo težavo, za njo pa še dve:

1. Podatkov za lansko leto nimamo. Stanje DevOps v Rusiji nikogar ne zanima;
2. Metodologija. Ni jasno, kako preverjati hipoteze, kako graditi vprašanja, kako analizirati, primerjati rezultate, iskati povezave;
3. Terminologija. Vsa poročila so v angleščini, prevod je obvezen, skupnega ogrodja DevOps še nismo izumili in vsak si izmisli svojega.

Oglejmo si, kako so bile izvedene analize stanja DevOps po vsem svetu.

Zgodovinski podatki

Raziskava DevOps se izvaja od leta 2011. Prvi jih je izvedel Puppet, razvijalec sistemov za upravljanje konfiguracij. Takrat je bilo to eno glavnih orodij za opisovanje infrastrukture v obliki kode. Do leta 2013 so bile te študije preprosto zaprte raziskave in brez javnih poročil.

Leta 2013 se je pojavil IT Revolution, založnik vseh večjih knjig o DevOps. Skupaj s Puppetom so pripravili prvo publikacijo State of DevOps, kjer so se prvič pojavile 4 ključne metrike. Naslednje leto se je vključilo ThoughtWorks, svetovalno podjetje, znano po svojih rednih tehnoloških radarjih za industrijske prakse in orodja. In leta 2015 je bil dodan razdelek z metodologijo in postalo je jasno, kako izvajajo analizo.

Leta 2016 so avtorji študije, ki so ustanovili lastno podjetje DORA (DevOps Research and Assessment), objavili letno poročilo. Naslednje leto sta DORA in Puppet izdali svojo zadnjo skupno reportažo.

In potem se je začelo nekaj zanimivega:

Leta 2018 sta se podjetji razdelili in izdali sta dve neodvisni poročili: eno od Puppet, drugo od DORA v sodelovanju z Googlom. DORA je še naprej uporabljala svojo metodologijo s ključnimi meritvami, profili uspešnosti in inženirskimi praksami, ki vplivajo na ključne meritve in uspešnost celotnega podjetja. In Puppet je predlagal svoj pristop z opisom procesa in razvoja DevOps. Toda zgodba se ni prijela; leta 2019 je Puppet opustil to metodologijo in izdal novo različico poročil, v katerih je navedel ključne prakse in njihov vpliv na DevOps. Nato se je zgodila še ena stvar: Google je kupil DORA in skupaj sta izdala še eno poročilo. Morda ste ga videli.

Letos se je zapletlo. Znano je, da je Puppet sprožil svojo raziskavo. Naredili so teden dni prej kot mi, pa se je že končalo. Sodelovali smo pri njem in pogledali, katere teme jih zanimajo. Sedaj Puppet dela analizo in se pripravlja na objavo poročila.

Toda DORA in Google še vedno ni obvestila. Maja, ko se anketa običajno začne, je prišla informacija, da se je Nicole Forsgren, ena od ustanoviteljic DORE, preselila v drugo podjetje. Zato smo predvidevali, da raziskave in poročila DORA letos ne bo.

Kako je v Rusiji?

Raziskave DevOps nismo opravili. Govorili smo na konferencah, pripovedovali ugotovitve drugih ljudi, Raiffeisenbank pa je prevedla »State of DevOps« za leto 2019 (njihovo objavo najdete na Habréju), za kar se jim zahvaljujemo. In to je vse.

Zato smo v Rusiji izvedli lastno raziskavo z uporabo metodologij in ugotovitev DORA. Za raziskavo smo uporabili poročilo kolegov iz Raiffeisenbank, tudi za sinhronizacijo terminologije in prevoda. In vprašanja, pomembna za industrijo, so bila vzeta iz poročil DORA in letošnjega vprašalnika Puppet.

Raziskovalni proces

Poročilo je le zaključni del. Celoten raziskovalni proces je sestavljen iz štirih glavnih korakov:

V pripravljalni fazi smo intervjuvali strokovnjake iz industrije in pripravili seznam hipotez. Na njihovi podlagi so sestavili vprašanja in sprožili anketo za ves avgust. Nato smo analizirali in pripravili samo poročilo. Za DORA ta postopek traja 6 mesecev. Srečali smo se v 3 mesecih in zdaj razumemo, da smo imeli komaj dovolj časa: šele z izvedbo analize razumete, katera vprašanja morate postaviti.

Člani

Vsa tuja poročila se začnejo s portretom udeležencev in večina jih ni iz Rusije. Delež ruskih anketirancev iz leta v leto niha od 5 do 1 %, kar ne omogoča sklepanja.

Zemljevid iz poročila Accelerate State of DevOps 2019:

V naši raziskavi nam je uspelo intervjuvati 889 ljudi – to je precej (DORA v svojih poročilih letno anketira okoli tisoč ljudi) in tukaj smo dosegli cilj:

Res je, da niso vsi naši udeleženci prišli do konca: odstotek dokončanja se je izkazal za nekoliko manj kot polovico. A tudi to je bilo dovolj za pridobitev reprezentativnega vzorca in analizo. DORA v svojih poročilih ne razkriva odstotkov zapolnjenosti, zato tukaj ni primerjave.

Panoge in položaji

Naši anketiranci predstavljajo ducat panog. Polovica dela v informacijski tehnologiji. Sledijo finančne storitve, trgovina, telekomunikacije in drugo. Med položaji so strokovnjaki (razvijalec, preizkuševalec, operativni inženir) in vodstveno osebje (vodje timov, skupin, področij, direktorji):

Vsak drugi dela v srednje velikem podjetju. Vsak tretji dela v velikih podjetjih. Večina dela v skupinah do 9 ljudi. Posebej smo spraševali o glavnih dejavnostih, večina pa je tako ali drugače povezanih z delovanjem, približno 40% pa je vključenih v razvoj:

Tako smo zbirali informacije za primerjavo in analizo predstavnikov različnih panog, podjetij in timov. O analizi vam bo povedal kolega Vitaly Khabarov.

Analiza in primerjava

Vitaly Khabarov: Najlepša hvala vsem udeležencem, ki so izpolnili našo anketo, izpolnili vprašalnike in nam posredovali podatke za nadaljnjo analizo in testiranje naših hipotez. In zahvaljujoč našim strankam in kupcem imamo bogate izkušnje, ki so pomagale prepoznati pomisleke industrije in oblikovati hipoteze, ki smo jih preizkusili v naši raziskavi.

Na žalost ne morete preprosto vzeti seznama vprašanj na eni strani in podatkov na drugi strani, jih nekako primerjati, reči: "Ja, vse deluje tako, imeli smo prav" in iti vsak svojo pot. Ne, potrebujemo metodologijo in statistične metode, da se prepričamo, da se nismo zmotili in da so naši zaključki zanesljivi. Nato lahko na podlagi teh podatkov gradimo naše nadaljnje delo:

Ključne meritve

Za osnovo smo vzeli metodologijo DORA, ki so jo podrobno opisali v knjigi “Accelerate State of DevOps”. Preverili smo, ali so ključne metrike primerne za ruski trg, ali jih je mogoče uporabiti na enak način, kot jih DORA uporablja za odgovor na vprašanje: »Kako industrija v Rusiji ustreza tuji industriji?«

Ključne meritve:

1. Pogostost uvajanja. Kako pogosto se nova različica aplikacije uvede v produkcijsko okolje (načrtovane spremembe, razen hitrih popravkov in odziva na incidente)?
2. Čas dostave. Kakšen je povprečni čas med objavo spremembe (pisanje funkcionalnosti kot kode) in uvedbo spremembe v produkcijsko okolje?
3. Čas okrevanja. Koliko časa v povprečju traja obnovitev aplikacije v produkcijsko okolje po incidentu, poslabšanju storitve ali odkritju hrošča, ki prizadene uporabnike aplikacije?
4. Neuspešne spremembe. Kolikšen odstotek uvedb v produkcijskem okolju povzroči degradacijo aplikacije ali incidente in zahteva popravek (povrnitev sprememb, razvoj hitrega popravka ali popravka)?

DORA je v svoji raziskavi našla povezavo med temi metrikami in organizacijsko uspešnostjo. Preizkušamo ga tudi v naši študiji.

Če želite zagotoviti, da lahko štiri ključne metrike na nekaj vplivajo, morate razumeti – ali so med seboj nekako povezane? DORA je odgovorila pritrdilno z enim opozorilom: razmerje med neuspešnimi spremembami (Change Failure Rate) in tremi drugimi metrikami je nekoliko šibkejše. Imamo približno isto sliko. Če čas dostave, pogostost uvajanja in čas okrevanja med seboj korelirajo (to korelacijo smo ugotovili s Pearsonovo korelacijo in s Chaddockovo lestvico), potem ni tako močne korelacije z neuspešnimi spremembami.

Načeloma se večina anketirancev nagiba k odgovoru, da imajo razmeroma majhno število incidentov v proizvodnji. Čeprav bomo pozneje videli, da je med skupinami anketirancev še vedno precejšnja razlika glede neuspešnih sprememb, te metrike za to delitev še ne moremo uporabiti.

To pripisujemo dejstvu, da (kot se je izkazalo med analizo in komunikacijo z nekaterimi našimi strankami) obstaja majhna razlika v dojemanju tega, kaj je incident. Če nam je med tehničnim oknom uspelo obnoviti delovanje naše storitve, ali se to lahko šteje za incident? Verjetno ne, saj smo vse uredili, super smo. Ali lahko štejemo za incident, če bi morali našo aplikacijo 10-krat ponovno zavrteti v običajnem, nam znanem načinu? Zdi se, da ne. Zato ostaja odprto vprašanje razmerja neuspešnih sprememb z drugimi metrikami. Še izpopolnili ga bomo.

Pri tem je pomembno, da smo ugotovili pomembno povezavo med časi dostave, časi obnovitve in pogostostjo uvajanja. Zato smo te tri metrike uporabili za nadaljnjo razdelitev anketirancev v skupine uspešnosti.

Koliko obesite v gramih?

Uporabili smo hierarhično analizo grozdov:

• Anketirance porazdelimo po n-dimenzionalnem prostoru, kjer so koordinata vsakega respondenta njegovi odgovori na vprašanja.
• Vsak respondent je razglašen za mali grozd.
• Dva najbližja grozda združimo v eno večjo gručo.
• Poiščemo naslednji par gruč in jih združimo v večjo gručo.

Tako združimo vse naše anketirance v število grozdov, ki jih potrebujemo. Z dendrogramom (drevo povezav med grozdi) vidimo razdaljo med dvema sosednjima grozdoma. Vse, kar nam preostane, je, da določimo določeno mejo razdalje med temi grozdi in rečemo: "Ti dve skupini se med seboj precej razlikujeta, ker je razdalja med njima ogromna."

Tu pa je skrita težava: pri številu grozdov nimamo omejitev – dobimo lahko 2, 3, 4, 10 grozdov. In prva ideja je bila - zakaj ne bi vseh naših anketirancev razdelili v 4 skupine, kot to počne DORA. Ugotovili pa smo, da razlike med temi skupinami postanejo nepomembne in ne moremo biti prepričani, da respondent res pripada svoji skupini, ne pa sosednji. Ruskega trga še ne moremo razdeliti v štiri skupine. Zato smo se ustavili pri treh profilih, med katerimi je statistično pomembna razlika:

Nato smo določili profil po grozdih: vzeli smo mediano za vsako metriko za vsako skupino in sestavili tabelo profilov uspešnosti. Pravzaprav smo dobili profile uspešnosti povprečnega udeleženca v vsaki skupini. Identificirali smo tri profile učinkovitosti: nizka, srednja, visoka:

Tu smo potrdili našo hipotezo, da so 4 ključne metrike primerne za določanje profila uspešnosti in delujejo tako na zahodnem kot ruskem trgu. Razlika med skupinama je in je statistično pomembna. Poudarjam, da obstaja pomembna razlika med profili uspešnosti glede metrike neuspešnih sprememb glede na povprečje, čeprav anketirancev na začetku nismo delili po tem parametru.

Potem se pojavi vprašanje: kako vse to uporabiti?

Kako uporabljati

Če vzamemo katero koli ekipo, 4 ključne metrike in jih uporabimo v tabeli, potem v 85% primerov ne bomo dobili popolnega ujemanja - to je le povprečni udeleženec in ne tisto, kar je v resnici. Vsi (in vsaka ekipa) smo nekoliko drugačni.

Preverili smo: vzeli smo naše anketirance in profil uspešnosti DORA ter pogledali, koliko anketirancev ustreza temu ali onemu profilu. Ugotovili smo, da le 16 % anketirancev zagotovo spada v enega od profilov. Vsi ostali so raztreseni nekje vmes:

To pomeni, da ima profil učinkovitosti omejen obseg. Da bi razumeli, kje ste v prvem približku, lahko uporabite to tabelo: "Oh, zdi se, da smo bližje srednjemu ali visokemu!" Če razumete, kam naprej, bo to morda dovolj. Če pa je vaš cilj nenehno, nenehno izboljševanje in želite natančneje vedeti, kje se razvijati in kaj narediti, potem so potrebna dodatna sredstva. Imenovali smo jih kalkulatorji:

• DORA kalkulator
• Calculator Express 42* (v razvoju)
• Lasten razvoj (lahko ustvarite svoj interni kalkulator).

Za kaj so potrebni? Razumeti:

• Ali ekipa znotraj naše organizacije ustreza našim standardom?
• Če ne, ali lahko pomagamo, pospešimo v okviru strokovnega znanja, ki ga ima naše podjetje?
• Če je tako, ali smo lahko še boljši?

Uporabite jih lahko tudi za zbiranje statistik znotraj podjetja:

• Kakšne ekipe imamo?
• Razdelite ekipe na profile;
• Glej: Oh, ti ukazi so premalo uspešni (ne izvlečejo se malo), ampak ti so kul: uvajajo se vsak dan, brez napak, imajo čas izvedbe manj kot eno uro.

In potem lahko ugotovite, da v našem podjetju obstaja potrebno strokovno znanje in orodja za tiste ekipe, ki še niso na nivoju.

Ali pa, če razumete, da se v podjetju počutite odlično, ste boljši od mnogih, potem lahko pogledate malo širše. To je samo ruska industrija: ali lahko pridobimo potrebno strokovno znanje v ruski industriji, da se pospešimo? Tukaj vam bo pomagal kalkulator Express 42 (je v razvoju). Če ste prerasli ruski trg, potem poglejte DORA kalkulator in na svetovni trg.

Globa. In če ste v skupini Elit na kalkulatorju DORA, kaj storiti? Tu ni dobre rešitve. Najverjetneje ste v ospredju panoge, nadaljnje pospeševanje in zanesljivost pa sta mogoča z notranjimi raziskavami in razvojem ter porabo več sredstev.

Preidimo k najslajšemu delu – primerjavi.

Primerjava

Sprva smo želeli primerjati rusko industrijo z zahodno industrijo. Če neposredno primerjamo, vidimo, da imamo manj profilov, pa tudi malo bolj so med seboj pomešani, meje so malo bolj zabrisane:

Naši Elitni izvajalci so skriti med High performerji, vendar so tam – to so elita, samorogi, ki so dosegli pomembne višine. V Rusiji razlika med profilom Elite in High profile še ni dovolj pomembna. Menimo, da bo v prihodnosti do te ločitve prišlo zaradi dviga inženirske kulture, kakovosti izvajanja inženirskih praks in strokovnega znanja znotraj podjetij.

Če preidemo na neposredno primerjavo znotraj ruske industrije, lahko vidimo, da so odmevne ekipe boljše v vseh pogledih. Potrdili smo tudi našo hipotezo, da obstaja povezava med temi meritvami in organizacijsko uspešnostjo: veliko bolj verjetno je, da bodo odmevne ekipe ne le dosegle cilje, ampak jih tudi presegle.
Postanimo odmevne ekipe in se ne ustavimo pri tem:

Toda to leto je posebno in odločili smo se preveriti, kako gre podjetjem v pandemiji: odmevne ekipe delajo veliko bolje in se počutijo bolje od povprečja v industriji:

• 1,5- do 2-krat večja verjetnost za izdajo novih izdelkov,
• 2-krat večja verjetnost za izboljšanje zanesljivosti in/ali zmogljivosti aplikacijske infrastrukture.

Se pravi, kompetence, ki so jih že imeli, so jim pomagale pri hitrejšem razvoju, lansiranju novih izdelkov, modificiranju obstoječih izdelkov ter s tem osvajanju novih trgov in novih uporabnikov:

Kaj je še pomagalo našim ekipam?

Inženirske prakse

Povedal vam bom o pomembnih ugotovitvah za vsako prakso, ki smo jo preizkusili. Morda je ekipam pomagalo še kaj drugega, vendar govorimo o DevOps. In znotraj DevOps vidimo razlike med ekipami različnih profilov.

Platforma kot storitev

Nismo odkrili pomembne povezave med starostjo platforme in profilom ekipe: platforme so se pojavile približno ob istem času tako za ekipe z nižjo kot za visoko ekipo. Toda za slednje ponuja platforma v povprečju več storitev in več programskih vmesnikov za nadzor preko programske kode. Ekipe platforme bodo bolj verjetno pomagale svojim razvijalcem in ekipam pri uporabi platforme, pogosteje reševale njihove težave in incidente, povezane s platformo, ter izobraževale druge ekipe.

Infrastruktura kot koda

Tukaj je vse precej standardno. Ugotovili smo povezavo med avtomatizacijo infrastrukturne kode in količino informacij, ki so shranjene v infrastrukturnem repozitoriju. Visoko profilirane ekipe shranijo več informacij v repozitorije: to vključuje konfiguracijo infrastrukture, cevovod CI/CD, nastavitve okolja in parametre gradnje. Te podatke shranjujejo pogosteje, bolje delujejo z infrastrukturno kodo in imajo avtomatizirano več procesov in opravil za delo z infrastrukturno kodo.

Zanimivo je, da pri infrastrukturnih testih nismo opazili bistvene razlike. To pripisujem dejstvu, da imajo odmevne ekipe na splošno več avtomatizacije testiranja. Morda jih ne bi smeli posebej motiti infrastrukturni testi, pač pa so dovolj testi, s katerimi preverjajo aplikacije, zaradi katerih lahko vidijo, kaj in kje so pokvarili.

Integracija in dostava

Najbolj dolgočasen razdelek, ker smo potrdili, da več avtomatizacije imate, bolje delate s kodo, večja je verjetnost, da boste dosegli boljše rezultate.

arhitektura

Želeli smo videti, kako mikrostoritve vplivajo na zmogljivost. Pravzaprav ne, saj uporaba mikrostoritev ni povezana s povečanjem kazalnikov uspešnosti. Mikrostoritve se uporabljajo za ukaze visokega profila in ukaze nizkega profila.

Toda pomembno je, da za High-teams prehod na arhitekturo mikrostoritev omogoča neodvisen razvoj in uvedbo svojih storitev. Če arhitektura omogoča razvijalcem, da delujejo avtonomno, ne da bi čakali na nekoga zunaj ekipe, potem je to ključna kompetenca za povečanje hitrosti. V tem primeru pomagajo mikrostoritve. In samo njihovo izvajanje ne igra velike vloge.

Kako smo vse to odkrili?

Imeli smo ambiciozen načrt za popolno ponovitev metodologije DORA, vendar nam je primanjkovalo sredstev. Če ima DORA veliko sponzorstev in njihovo raziskovanje traja pol leta, smo mi raziskavo opravili v kratkem času. Želeli smo zgraditi model DevOps, kot ga ima DORA, in to bomo storili v prihodnosti. Doslej smo se omejili na toplotne karte:

Ogledali smo si porazdelitev inženirskih praks po skupinah v vsakem profilu in ugotovili, da je v povprečju večja verjetnost, da bodo odmevne ekipe uporabljale inženirske prakse. Več o vsem tem si lahko preberete v našem poročilo.

Za spremembo preklopimo s kompleksnih statistik na preproste.

Kaj smo še odkrili?

Orodja

Opažamo, da večino ukazov uporablja operacijski sistem družine Linux. Toda Windows je še vedno v trendu - vsaj četrtina naših anketirancev je opazila uporabo ene ali druge njegove različice. Zdi se, da trg to potrebuje. Zato lahko razvijate te kompetence in izvajate predstavitve na konferencah.

Med orkestratorji, ni za nikogar skrivnost, prednjači Kubernetes (52%). Naslednji v vrsti orkestrator je Docker Swarm (približno 12%). Najbolj priljubljena sistema CI sta Jenkins in GitLab. Najbolj priljubljen sistem za upravljanje konfiguracije je Ansible, ki mu sledi naš ljubljeni Shell.

Amazon je trenutno vodilni ponudnik gostovanja v oblaku. Delež ruskih oblakov postopoma narašča. Naslednje leto bo zanimivo videti, kako se bodo počutili ruski ponudniki oblakov, ali se bo njihov tržni delež povečal. So, jih je mogoče uporabiti in to je dobro:

Besedo dajem Igorju, ki bo povedal še nekaj statistike.

Razširjanje praks

Igor Kurochkin: Ločeno smo prosili anketirance, da navedejo, kako so obravnavane inženirske prakse porazdeljene v podjetju. V večini podjetij opazimo mešani pristop, ki ga sestavljajo različni nabori vzorcev, pilotni projekti pa so zelo priljubljeni. Videli smo tudi rahlo razliko med profili. Predstavniki visokega profila pogosteje uporabljajo vzorec »Pobuda od spodaj«, ko majhne ekipe strokovnjakov spreminjajo delovne procese, orodja in delijo uspešne prakse z drugimi ekipami. Pri Mediumu je to pobuda od zgoraj, ki vpliva na celotno podjetje z ustvarjanjem skupnosti in centrov odličnosti:

Agile in DevOps

V industriji se pogosto razpravlja o razmerju med Agile in DevOps. To problematiko odpira tudi poročilo o stanju agile za 2019/2020, zato smo se odločili primerjati, kako so v podjetjih povezane aktivnosti agile in DevOps. Ugotovili smo, da so DevOps brez Agile redki. Za polovico anketirancev se je širjenje Agile začelo veliko prej in približno 20% jih je opazilo sočasen začetek, eden od znakov nizkega profila pa bo odsotnost praks Agile in DevOps:

Timske topologije

Konec lanskega leta je knjigaTimske topologije”, ki predlaga okvir za opis ukaznih topologij. Postalo nam je zanimivo, ali velja za ruska podjetja. In postavili smo vprašanje: "Kakšne vzorce najdete?".

Infrastrukturne ekipe opažamo pri polovici anketirancev, prav tako ločene ekipe za razvoj, testiranje in delovanje. Ločene ekipe DevOps so opazile 45%, med katerimi so pogostejši predstavniki High. Sledijo medfunkcionalne ekipe, ki so pogostejše tudi na High. Ločeni ukazi SRE se pojavijo v visokem in srednjem profilu in so redko vidni v nizkem profilu:

Razmerje DevQaOps

To vprašanje smo na FaceBooku zasledili od vodje ekipe platforme Skyeng – zanimalo ga je razmerje med razvijalci, preizkuševalci in skrbniki v podjetjih. Vprašali smo in pogledali odgovore na podlagi profilov: Predstavniki visokega profila imajo manj inženirjev za testiranje in operacijo za vsakega razvijalca:

Načrti za leto 2021

V načrtih za naslednje leto so anketiranci zapisali naslednje aktivnosti:

Tukaj lahko vidite presečišče s konferenco DevOps Live 2020. Skrbno smo pregledali program:

• Infrastruktura kot produkt
• Preoblikovanje DevOps
• Distribucija praks DevOps
• DevSecOps
• Klubi primerov in razprave

A čas naše predstavitve ni dovolj, da bi zajeli vse teme. Ostalo v zakulisju:

• Platforma kot storitev in kot izdelek;
• Infrastruktura kot koda, okolja in oblaki;
• Nenehna integracija in dostava;
• Arhitektura;
• vzorci DevSecOps;
• Platformske in medfunkcionalne ekipe.

Poročilo dobili smo zajetnega, 50 strani, in si ga lahko podrobneje ogledate.

Seštejemo

Upamo, da vas bosta naša raziskava in poročilo navdihnila za eksperimentiranje z novimi pristopi k razvoju, testiranju in delovanju ter vam pomagala pri navigaciji, se primerjali z drugimi udeleženci v študiji in prepoznali področja, kjer lahko izboljšate svoje pristope.

Rezultati prve študije o stanju DevOps v Rusiji:

• Ključne meritve. Ugotovili smo, da so ključne metrike (čas dostave, pogostost uvajanja, čas obnovitve in neuspešne spremembe) primerne za analizo učinkovitosti razvojnih, testnih in operativnih procesov.
• Profili High, Medium, Low. Na podlagi zbranih podatkov lahko ločimo statistično različne skupine High, Medium, Low z značilnimi značilnostmi v smislu meritev, praks, procesov in orodij. Predstavniki visokega profila kažejo boljše rezultate kot nizki. Bolj verjetno bodo dosegli in presegli svoje cilje.
• Kazalniki, pandemija in načrti za leto 2021. Poseben pokazatelj letos je, kako so se podjetja spopadla s pandemijo. High se je izkazal bolje, zabeležil je porast uporabniške aktivnosti, glavni razlogi za uspeh pa so bili učinkoviti razvojni procesi in močna inženirska kultura.
• DevOps prakse, orodja in njihov razvoj. Glavni načrti podjetij za naslednje leto so razvoj praks in orodij DevOps, uvedba praks DevSecOps ter spremembe v organizacijski strukturi. In učinkovito izvajanje in razvoj praks DevOps se izvaja s pilotnimi projekti, oblikovanjem skupnosti in kompetenčnih centrov, pobudami na višjih in nižjih ravneh podjetja.

Radi bi slišali vaše povratne informacije, zgodbe, povratne informacije. Zahvaljujemo se vsem, ki ste sodelovali v raziskavi in ​​se veselimo vaše udeležbe naslednje leto.

Vir: www.habr.com