DevOpsin tila Venäjällä 2020

Miten sinä edes ymmärrät jonkin tilan?

Voit luottaa mielipiteeseesi, joka muodostuu erilaisista tietolähteistä, esimerkiksi verkkosivuilla julkaistuista julkaisuista tai kokemuksista. Voit kysyä kollegoiltasi ja ystäviltäsi. Toinen vaihtoehto on tarkastella konferenssien aiheita: ohjelmatoimikunta on alan aktiivisia edustajia, joten luotamme heihin relevanttien aiheiden valinnassa. Erillinen alue on tutkimus ja raportit. Mutta siinä on ongelma. DevOpsin tilatutkimusta tehdään vuosittain ympäri maailmaa, ulkomaisten yritysten raportteja julkaistaan, eikä venäläisistä DevOpsista ole juurikaan tietoa.

Mutta on tullut päivä, jolloin tällainen tutkimus tehtiin, ja tänään kerromme sinulle saaduista tuloksista. Yritykset tutkivat yhdessä DevOpsin tilaa Venäjällä "Express 42"Ja"Ontiko" Express 42 -yritys auttaa teknologiayrityksiä toteuttamaan ja kehittämään DevOps-käytäntöjä ja -työkaluja ja oli yksi ensimmäisistä, jotka puhuivat DevOpsista Venäjällä. Tutkimuksen tekijät Igor Kurochkin ja Vitaly Khabarov harjoittavat analysointia ja konsultointia Express 42:ssa, heillä on tekninen tausta toiminnasta ja kokemusta eri yrityksissä. Yli 8 vuoden aikana kollegat katselivat kymmeniä yrityksiä ja projekteja - startupeista yrityksiin - joilla oli erilaisia ​​ongelmia sekä erilaista kulttuurista ja tekniikan kypsyyttä.

Igor ja Vitaly kertoivat raportissaan, mitä ongelmia tutkimusprosessin aikana oli, miten ne ratkaistiin, sekä miten DevOps-tutkimusta periaatteessa tehdään ja miksi Express 42 päätti tehdä oman. Näet heidän raportin täällä.

DevOps-tutkimus

Igor Kurochkin aloitti keskustelun.

Kysymme säännöllisesti DevOps-konferenssien yleisöltä: "Oletko lukenut tämän vuoden State of DevOps -raportin?" Vain harvat nostavat kätensä, mutta tutkimuksemme osoitti, että vain kolmasosa tutkii heitä. Jos et ole koskaan nähnyt tällaisia ​​raportteja, sanotaan heti, että ne ovat kaikki hyvin samanlaisia. Useimmiten on lauseita, kuten: "Verrattuna viime vuoteen..."

Tässä meillä on ensimmäinen ongelmamme, jota seuraa kaksi muuta:

1. Meillä ei ole tietoja viime vuodesta. Kukaan ei ole kiinnostunut DevOpsin tilasta Venäjällä;
2. Metodologia. Ei ole selvää, miten hypoteeseja testataan, miten kysymyksiä rakennetaan, miten analysoidaan, vertailla tuloksia, löytää yhteyksiä;
3. Terminologia. Kaikki raportit ovat englanninkielisiä, käännös vaaditaan, yhteistä kehystä DevOpsille ei ole vielä keksitty ja jokainen keksii omansa.

Katsotaanpa, miten DevOps-tilan analyyseja maailmassa yleensä tehtiin.

Historialliset tiedot

DevOps-tutkimusta on tehty vuodesta 2011 lähtien. Ensimmäisenä ne toteutti Puppet, konfiguroinnin hallintajärjestelmien kehittäjä. Tuolloin se oli yksi tärkeimmistä työkaluista infrastruktuurin kuvaamiseen koodin muodossa. Vuoteen 2013 asti nämä tutkimukset olivat vain suljetussa muodossa ja ilman julkista raportointia tehtyjä tutkimuksia.

Vuonna 2013 ilmestyi IT Revolution, joka julkaisi kaikki tärkeimmät DevOps-kirjat. Yhdessä Puppetin kanssa he valmistivat ensimmäisen julkaisun "State of DevOps", jossa 4 keskeistä mittaria ilmestyi ensimmäistä kertaa. Seuraavana vuonna mukaan osallistui konsulttiyritys ThoughtWorks, joka tunnetaan tavanomaisista alan käytäntöjä ja työkaluja koskevista teknologiatutkista. Ja vuonna 2015 lisättiin osio metodologiasta, ja kävi selväksi, kuinka he suorittavat analyysin.

Vuonna 2016 tutkimuksen tekijät, jotka ovat perustaneet yrityksensä DORAn (DevOps Research and Assessment), julkaisivat vuosiraportin. Seuraavana vuonna DORA ja Puppet julkaisivat yhteisen loppuraporttinsa.

Ja sitten asiat alkoivat kiinnostaa:

Vuonna 2018 yritykset erosivat ja julkaistiin kaksi riippumatonta raporttia: yksi Puppetilta ja toinen DORAlta yhteistyössä Googlen kanssa. DORA jatkoi metodologiansa käyttöä keskeisten mittareiden, suorituskykyprofiilien ja suunnittelukäytäntöjen kanssa, jotka vaikuttavat keskeisiin mittareihin ja suorituskykyyn koko yrityksessä. Ja Puppet ehdotti lähestymistapaansa kuvauksella prosessista ja DevOpsin kehityksestä. Tarina ei kuitenkaan saanut kiinni; vuonna 2019 Puppet hylkäsi tämän menetelmän ja julkaisi raporteista uuden version, jossa se listasi keskeiset käytännöt ja kuinka ne vaikuttavat DevOpsiin heidän näkökulmastaan. Sitten tapahtui toinen asia: Google osti DORAn, ja yhdessä he julkaisivat uuden raportin. Ehkä olet nähnyt sen.

Tänä vuonna asiat muuttuivat monimutkaisiksi. Tiedetään, että Puppet käynnisti kyselynsä. He tekivät sen viikkoa aikaisemmin kuin me, ja se oli jo valmis. Osallistuimme siihen ja näimme, mitkä aiheet kiinnostavat heitä. Puppet tekee nyt analyysiään ja valmistautuu julkaisemaan raportin.

Mutta DORAlta ja Googlelta ei ole vieläkään saatu ilmoitusta. Toukokuussa, kun kysely yleensä alkoi, tuli tieto, että Nicole Forsgren, yksi DORA:n perustajista, oli siirtynyt toiseen yritykseen. Siksi oletimme, ettei DORAlta tule tänä vuonna tutkimusta tai raporttia.

Miten Venäjällä menee?

Emme ole tehneet DevOps-tutkimusta. Puhuimme konferensseissa ja kerroimme muiden ihmisten johtopäätöksiä, ja Raiffeisenbank käänsi "State of DevOps" vuodelle 2019 (löydät heidän ilmoituksensa Habresta), paljon kiitoksia heille. Ja se on kaikki.

Siksi teimme oman tutkimuksen Venäjällä DORA-metodologioilla ja -löydöillä. Käytimme Raiffeisenbankin kollegoiden raporttia tutkimuksessamme, muun muassa terminologian ja käännösten synkronoinnissa. Ja toimialaan liittyvät kysymykset poimittiin DORA-raporteista ja tämän vuoden Puppet-kyselystä.

Tutkimusprosessi

Raportti on vasta viimeinen osa. Koko tutkimusprosessi koostuu neljästä suuresta vaiheesta:

Valmisteluvaiheessa haastattelimme alan asiantuntijoita ja laadimme listan hypoteeseista. Kokosimme niiden perusteella kysymyksiä ja käynnistimme kyselyn koko elokuulle. Sitten analysoimme ja valmistelimme itse raportin. DORAlla tämä prosessi kestää 6 kuukautta. Saimme sen valmiiksi 3 kuukaudessa, ja nyt ymmärrämme, että aika tuskin ehtinyt: vain tekemällä analyysin ymmärrät, mitä kysymyksiä on kysyttävä.

Osallistujat

Kaikki ulkomaiset raportit alkavat osallistujien muotokuvalla, ja suurin osa heistä ei ole Venäjältä. Venäläisten vastaajien prosenttiosuus vaihtelee 5–1 prosentin välillä vuosittain, eikä tästä voida tehdä johtopäätöksiä.

Kartta Accelerate State of DevOps 2019 -raportista:

Tutkimuksessamme pystyimme haastattelemaan 889 henkilöä - tämä on melko paljon (DORA tekee raporteissaan vuosittain noin tuhatta ihmistä) ja tässä saavutimme tavoitteemme:

Totta, kaikki osallistujamme eivät päässeet loppuun: valmistumisprosentti oli hieman alle puolet. Mutta tämä riitti edustavan näytteen saamiseksi ja analyysin suorittamiseen. DORA ei kerro raporteissaan vuokrausasteita, joten vertailuja ei voi tehdä täällä.

Toimialat ja asemat

Vastaajamme edustavat tusinaa toimialaa. Puolet työstä tietotekniikassa. Tämän jälkeen tulevat rahoituspalvelut, kauppa, televiestintä ja muut. Tehtävissä ovat asiantuntijat (kehittäjä, testaaja, käyttöinsinööri) ja johtohenkilöstö (tiimien, ryhmien, alueiden johtajat, johtajat):

Joka toinen henkilö työskentelee keskisuuressa yrityksessä. Joka kolmas työskentelee suurissa yrityksissä. Useimmat työskentelevät enintään 9 hengen ryhmissä. Kysyimme erikseen päätoimia, joista suurin osa liittyy tavalla tai toisella toimintaan ja noin 40 % on mukana kehittämisessä:

Näin keräsimme tietoa vertailua ja analysointia varten eri toimialojen, yritysten ja tiimien edustajista. Kollegani Vitaly Khabarov kertoo sinulle analyysistä.

Analyysi ja vertailu

Vitaly Khabarov: Suuri kiitos kaikille osallistujille, jotka täyttivät kyselymme, täyttivät kyselylomakkeet ja antoivat meille tietoja hypoteesidemme lisäanalyysiä ja testausta varten. Asiakkaidemme ja asiakkaidemme ansiosta meillä on runsaasti kokemusta, joka on auttanut meitä tunnistamaan toimialalle huolestuttavia kysymyksiä ja muotoilemaan tutkimuksessamme testaamiamme hypoteeseja.

Valitettavasti et voi vain ottaa kysymysluetteloa toisaalta ja tietoja toisaalta, jotenkin verrata niitä, sanoa: "Kyllä, kaikki toimii niin, olimme oikeassa" ja mennä eri tavoin. Ei, tarvitsemme metodologiaa ja tilastollisia menetelmiä varmistaaksemme, ettemme erehtyneet ja että johtopäätöksemme ovat luotettavia. Sitten voimme rakentaa jatkotyömme näiden tietojen pohjalta:

Keskeiset mittarit

Otimme pohjaksi DORA-metodologian, jota he kuvailivat yksityiskohtaisesti kirjassa "Accelerate State of DevOps". Selvitimme, soveltuvatko keskeiset mittarit Venäjän markkinoille, voidaanko niitä käyttää samalla tavalla kuin DORA vastaa kysymykseen: ”Miten Venäjän toimiala vastaa ulkomaista teollisuutta?”

Tärkeimmät tiedot:

1. Käyttöönottotaajuus. Kuinka usein sovelluksen uusi versio otetaan käyttöön tuotantoympäristössä (suunnitellut muutokset, ei hotfix-korjauksia ja tapauksiin reagointia)?
2. Toimitusaika. Mikä on keskimääräinen aika muutoksen tekemisen (toiminnon kirjoittaminen koodiksi) ja muutoksen käyttöönottoon tuotantoympäristöön välillä?
3. Palautumisaika. Kuinka kauan sovelluksen palauttaminen tuotantoympäristössä kestää keskimäärin tapauksen, palvelun heikkenemisen tai sovelluksen käyttäjiin vaikuttavan virheen havaitsemisen jälkeen?
4. Epäonnistuneita muutoksia. Kuinka suuri prosenttiosuus käyttöönotoista tuoteympäristössä johtaa sovelluksen heikkenemiseen tai tapauksiin ja vaatii seurausten eliminoimista (muutosten peruuttaminen, hotfix-korjauksen tai korjaustiedoston kehittäminen)?

DORAn tutkimus on löytänyt yhteyden näiden mittareiden ja organisaation suorituskyvyn välillä. Tarkistamme sen myös tutkimuksestamme.

Mutta varmistaaksesi, että neljä keskeistä mittaria voivat vaikuttaa johonkin, sinun on ymmärrettävä - liittyvätkö ne jotenkin toisiinsa? DORA vastasi kyllä, yhdellä varoituksella: muutos epäonnistumisasteen ja kolmen muun mittarin välinen suhde on hieman heikompi. Meillä on suunnilleen sama kuva. Jos toimitusaika, käyttöönottotiheys ja palautusaika korreloivat keskenään (todisimme tämän korrelaation Pearson-korrelaation ja Chaddock-asteikon kautta), niin vahvaa korrelaatiota epäonnistuneiden muutosten kanssa ei ole.

Periaatteessa suurin osa vastaajista vastaa, että heillä on melko vähän tapauksia tuotannossa. Vaikka näemme myöhemmin, että vastaajaryhmien välillä on edelleen merkittävä ero epäonnistuneiden muutosten määrässä, emme voi vielä käyttää tätä mittaria tähän jakoon.

Tämä johtuu siitä, että (kuten kävi ilmi analysointi- ja viestintäprosessissa joidenkin asiakkaidemme kanssa) havaitaan hieman eroa siitä, mitä pidetään tapahtumana. Jos onnistuimme palauttamaan palvelumme toimivuuden teknisen ikkunan aikana, voidaanko sitä pitää tapahtumana? Todennäköisesti ei, koska korjasimme kaiken, olemme mahtavia. Voiko sitä pitää tapahtumana, jos jouduimme pyörittämään sovelluksemme uudelleen 10 kertaa normaalissa tutussa tilassa? Näyttää siltä, ​​että ei. Siksi kysymys epäonnistuneiden muutosten ja muiden mittareiden välisestä suhteesta jää avoimeksi. Selvennämme asiaa tarkemmin.

Tärkeää tässä on se, että löysimme merkittävän korrelaation toimitusajan, palautusajan ja käyttöönottotiheyden välillä. Siksi otimme nämä kolme mittaria jakaaksemme vastaajat edelleen ryhmiin tuottavuuden perusteella.

Kuinka paljon roikkua grammoina?

Käytimme hierarkkista klusterianalyysiä:

• Jaamme vastaajat n-ulotteiseen avaruuteen, jossa kunkin vastaajan koordinaatti on heidän vastauksensa kysymyksiin.
• Julistamme jokaisen vastaajan pieneksi klusteriksi.
• Yhdistämme kaksi lähimpänä olevaa klusteria yhdeksi suuremmaksi klusteriksi.
• Etsimme seuraavan klusterin parin ja yhdistämme ne suuremmaksi klusteriksi.

Näin ryhmittelemme kaikki vastaajamme tarvitsemiimme klustereihin. Dendrogrammin (rypäiden välisten yhteyksien puu) avulla näemme kahden vierekkäisen klusterin välisen etäisyyden. Jäljelle jää vain asettaa tietty raja näiden klustereiden väliselle etäisyydelle ja sanoa: "Nämä kaksi ryhmää ovat varsin erotettavissa toisistaan, koska niiden välinen etäisyys on jättimäinen."

Mutta tässä on piilotettu ongelma: meillä ei ole rajoituksia klusterien lukumäärälle - voimme saada 2, 3, 4, 10 klusteria. Ja ensimmäinen ajatus oli - miksi ei jakaisi kaikkia vastaajiamme 4 ryhmään, kuten DORA tekee. Mutta havaitsimme, että näiden ryhmien väliset erot ovat merkityksettömiä, emmekä voi olla varmoja siitä, että vastaaja todella kuuluu omaan ryhmään eikä naapuriryhmään. Emme voi vielä jakaa Venäjän markkinoita neljään ryhmään. Siksi päädyimme kolmeen profiiliin, joiden välillä on tilastollisesti merkitsevä ero:

Seuraavaksi määritimme profiilin klusterin mukaan: otimme kunkin ryhmän mediaanit kullekin mittarille ja laatimme tehokkuusprofiilien taulukon. Itse asiassa tuloksena saadut suorituskykyprofiilit keskimääräiselle osallistujalle kussakin ryhmässä saatiin. Olemme tunnistaneet kolme tehokkuusprofiilia: Matala, Keskitaso, Korkea:

Tässä olemme vahvistaneet hypoteesimme, että 4 keskeistä mittaria soveltuvat suoritusprofiilin määrittämiseen ja ne toimivat sekä länsi- että Venäjän markkinoilla. Ryhmien välillä on eroa, ja se on tilastollisesti merkitsevä. Haluan korostaa, että epäonnistuneiden muutosten mittarin suoritusprofiilien keskiarvossa on merkittävä ero, vaikka emme alun perin jakaneet vastaajia tällä parametrilla.

Sitten herää kysymys: kuinka käyttää tätä kaikkea?

Kuinka käyttää

Jos otamme minkä tahansa joukkueen, 4 avainmittaria ja käytämme niitä taulukkoon, 85 prosentissa tapauksista emme saa täydellistä ottelua - tämä on vain keskimääräinen osallistuja, eikä todellisuudessa. Olemme kaikki (ja jokainen joukkue) hieman erilaisia.

Tarkistimme: otimme vastaajamme ja DORA-suoritusprofiilin ja katsoimme kuinka moni vastaaja vastasi yhtä tai toista profiilia. Huomasimme, että vain 16 % vastaajista osui tarkasti johonkin profiiliin. Kaikki loput ovat hajallaan jonnekin siltä väliltä:

Tämä tarkoittaa, että suorituskykyprofiililla on rajoitettu laajuus. Saat ensiarvion sijainnistasi käyttämällä tätä taulukkoa: "Oh, näyttää siltä, ​​että olemme lähempänä keskitasoa tai korkeaa!" Jos ymmärrät, mihin olet menossa seuraavaksi, se saattaa riittää. Mutta jos tavoitteesi on jatkuva, jatkuva parantaminen ja haluat tietää tarkemmin missä kehittyä ja mitä tehdä, tarvitaan lisärahoitusta. Kutsuimme niitä laskimiksi:

• DORA laskin
• Calculator Express 42* (kehitellään)
• Oma kehitys (voit luoda oman sisäisen laskimen).

Mihin niitä tarvitaan? Ymmärtää:

• Täyttääkö organisaatiomme tiimi standardejamme?
• Jos ei, voimmeko auttaa häntä - nopeuttaa sitä yrityksemme osaamisen puitteissa?
• Jos on, voimmeko tehdä vielä paremmin?

Voit käyttää niitä myös tilastojen keräämiseen yrityksen sisällä:

• Millaisia ​​joukkueita meillä on?
• Jaa joukkueet profiileihin;
• Katso: Voi, nämä tiimit ovat alitoimivia (hieman hitaita), mutta nämä ovat mahtavia: ne otetaan käyttöön joka päivä, ilman virheitä, niiden läpimenoaika on alle tunti.

Ja sitten voit huomata, että meillä on yrityksessämme tarvittava asiantuntemus ja työkalut niille tiimeille, jotka ovat vielä vajavaisia.

Tai jos ymmärrät, että tunnet olosi hyväksi yrityksessä, että olet parempi kuin monet, voit katsoa hieman laajemmin. Tämä on nimenomaan Venäjän teollisuus: voimmeko saada Venäjän teollisuudesta tarvittavan asiantuntemuksen nopeuttaaksemme itseämme? Express 42 -laskin auttaa tässä (se on kehitteillä). Jos olet ohittanut Venäjän markkinat, katso DORA laskin ja maailmanmarkkinoille.

Hieno. Ja jos kuulut Elit-ryhmään DORA-laskimen mukaan, niin mitä sinun pitäisi tehdä? Tässä ei ole hyvää ratkaisua. Todennäköisesti olet alan kärjessä, ja lisää kiihtyvyyttä ja luotettavuutta voidaan parantaa sisäisen T&K:n ja suurten resurssien avulla.

Siirrytään suloisimpaan osaan - vertailuun.

vertailu

Alun perin halusimme verrata Venäjän teollisuutta länsimaiseen teollisuuteen. Jos vertaamme suoraan, näemme, että meillä on vähemmän profiileja, ja ne ovat hieman sekoittuneet keskenään, rajat ovat hieman epäselvempiä:

Elite-esiintyjämme ovat piilossa High-performersin joukossa, mutta he ovat siellä - nämä ovat eliittiä, yksisarviset, jotka ovat saavuttaneet merkittäviä korkeuksia. Venäjällä ero Elite- ja High-profiilien välillä ei ole vielä tarpeeksi merkittävä. Uskomme, että jatkossa tämä jakautuminen johtuu insinöörikulttuurin lisääntymisestä, suunnittelukäytäntöjen toteuttamisen laadusta ja yritysten osaamisesta.

Jos siirrymme suoraan vertailuun Venäjän teollisuuden sisällä, näemme korkean profiilin tiimit olevan kaikin puolin parempia. Vahvistimme myös hypoteesimme, että näiden mittareiden ja organisaation tehokkuuden välillä on yhteys: Korkean profiilin tiimit eivät vain saavuta tavoitteita, vaan myös ylittävät ne.
Ryhdytään korkean profiilin tiimeiksi, emmekä jää tähän:

Mutta tämä vuosi on erityinen, ja päätimme tarkistaa, kuinka yritykset elävät pandemiassa: Korkean profiilin tiimit selviytyvät huomattavasti paremmin ja tuntevat olonsa paremmaksi kuin alan keskiarvo:

• Uusia tuotteita julkaistiin 1,5-2 kertaa useammin,
• Sovellusinfrastruktuurin luotettavuus ja/tai suorituskyky paranee 2 kertaa useammin.

Toisin sanoen heillä jo aiemmin ollut osaaminen auttoi heitä kehittymään nopeammin, ottamaan käyttöön uusia tuotteita, muokkaamaan olemassa olevia tuotteita ja valloittamaan siten uusia markkinoita ja uusia käyttäjiä:

Mikä muu on auttanut joukkueitamme?

Tekniset käytännöt

Kerron sinulle merkittävistä havainnoista jokaisessa tarkistamassamme käytännössä. Ehkä jokin muu auttoi tiimejä, mutta puhumme DevOpsista. Ja DevOpsissa näemme eroja eri profiilien tiimien välillä.

Alusta palveluna

Emme löytäneet merkittävää yhteyttä alustan iän ja tiimiprofiilin välillä: alustat ilmestyivät suunnilleen samaan aikaan sekä Low- että High-tiimeille. Mutta jälkimmäiselle alusta tarjoaa keskimäärin enemmän palveluita ja ohjelmistorajapintoja ohjelmakoodin kautta ohjattavaksi. Ja alustatiimit auttavat todennäköisemmin kehittäjiään ja tiimeitään alustan käytössä, ratkaisevat todennäköisemmin alustaan ​​liittyvät ongelmansa ja tapaukset ja kouluttavat muita tiimejä.

Infrastruktuuri koodina

Kaikki täällä on melko vakio. Löysimme yhteyden infrastruktuurikoodin automatisoinnin ja infrastruktuurin arkiston sisällä olevan tiedon välillä. Korkean profiilin tiimit tallentavat arkistoihin lisää tietoa: tämä sisältää infrastruktuurin määritykset, CI/CD-putken, ympäristöasetukset ja koontiparametrit. Ne tallentavat nämä tiedot useammin, toimivat paremmin infrastruktuurikoodin kanssa ja ovat automatisoineet enemmän prosesseja ja tehtäviä infrastruktuurikoodin kanssa työskentelemiseen.

Mielenkiintoista on, ettemme havainneet merkittävää eroa infrastruktuuritesteissä. Tämä johtuu siitä, että korkean profiilin tiimeillä on yleensä enemmän testiautomaatiota. Ehkä niitä ei kannata erikseen häiritä infrastruktuuritesteillä, vaan sovellusten tarkistamiseen käytetyt testit riittävät, ja niiden ansiosta he näkevät mitä ja missä ovat rikkoneet.

Integrointi ja toimitus

Tylsin osio, koska vahvistimme: mitä enemmän automaatiota sinulla on, mitä paremmin työskentelet koodin kanssa, sitä todennäköisemmin saat parempia tuloksia.

Arkkitehtuuri

Halusimme nähdä, kuinka mikropalvelut vaikuttavat suorituskykyyn. Rehellisesti sanottuna eivät, koska mikropalvelujen käyttö ei liity tehokkuusindikaattoreiden nousuun. Mikropalveluita käyttävät sekä korkean että matalan profiilin tiimit.

Merkittävää on kuitenkin se, että High-tiimeille siirtyminen mikropalveluarkkitehtuuriin antaa heille mahdollisuuden kehittää palveluitaan itsenäisesti ja ottaa ne käyttöön. Jos arkkitehtuuri antaa kehittäjille mahdollisuuden toimia itsenäisesti odottamatta jonkun ulkopuolista tiimiin, tämä on avainosaamista nopeuden lisäämisessä. Tässä mikropalvelut auttavat. Mutta yksinkertaisesti niiden täytäntöönpanolla ei ole suurta roolia.

Kuinka löysimme tämän kaiken?

Meillä oli kunnianhimoinen suunnitelma toistaa DORA-metodologia täysin, mutta resurssit puuttuivat. Jos DORA käyttää paljon sponsorointia ja tutkimus kestää kuusi kuukautta, teimme tutkimuksemme lyhyessä ajassa. Halusimme rakentaa DevOps-mallin, kuten DORA tekee, ja teemme sen myös tulevaisuudessa. Toistaiseksi rajoituimme lämpökarttoihin:

Tarkastelimme suunnittelukäytäntöjen jakautumista kunkin profiilin tiimien kesken ja havaitsimme, että korkean profiilin tiimit käyttävät suunnittelukäytäntöjä keskimäärin useammin. Voit lukea lisää tästä kaikesta meidän raportti.

Vaihdetaan monimutkaisista tilastoista yksinkertaisiin tilastoihin.

Mitä muuta olemme havainneet?

Työkalut

Huomaamme, että Linux-käyttöjärjestelmäperhe käyttää eniten komentoja. Mutta Windows on edelleen trendissä - vähintään neljäsosa vastaajistamme totesi yhden tai toisen version käytön. Markkinoilla näyttää olevan tämä tarve. Siksi voit kehittää näitä kompetensseja ja pitää esitelmiä konferensseissa.

Orkesterien joukossa ei ole mikään salaisuus, että Kubernetes johtaa (52 %). Seuraava orkesteri jonossa on Docker Swarm (noin 12 %). Suosituimmat CI-järjestelmät ovat Jenkins ja GitLab. Suosituin kokoonpanonhallintajärjestelmä on Ansible, jota seuraa rakastettu Shell.

Pilvipalveluiden tarjoajista Amazon on tällä hetkellä johtavassa asemassa. Venäjän pilvien osuus kasvaa vähitellen. Ensi vuonna on mielenkiintoista nähdä, miten venäläiset pilvipalveluntarjoajat kokevat ja kasvaako niiden markkinaosuus. Niitä on olemassa, niitä voidaan käyttää, ja se on hyvä:

Annan puheenvuoron Igorille, joka antaa lisää tilastoja.

Käytäntöjen leviäminen

Igor Kurochkin: Pyysimme vastaajia erikseen kertomaan, kuinka harkitut suunnittelukäytännöt jaetaan yrityksessä. Useimmilla yrityksillä on sekoitettu lähestymistapa, joka koostuu erilaisista kuvioista, ja pilottihankkeet ovat erittäin suosittuja. Näimme myös pienen eron profiilien välillä. Korkean profiilin edustajat käyttävät useammin ”Alhaalta aloitteesta” -mallia, kun pienet asiantuntijatiimit vaihtavat työprosesseja, työkaluja ja jakavat onnistuneita kehityshankkeita muiden tiimien kanssa. Mediumilla tämä on ylhäältä alaspäin suuntautuva aloite, joka koskettaa koko yritystä luomalla yhteisöjä ja osaamiskeskuksia:

Ketterä ja DevOps

Agilen ja DevOpsin suhteesta keskustellaan usein alalla. Tämä kysymys on esillä myös Agile-tilaraportissa 2019/2020, joten päätimme verrata, miten Agile- ja DevOps-toiminnat yrityksissä liittyvät toisiinsa. Olemme havainneet, että DevOps ilman Agilea on harvinaista. Puolella vastaajista ketterän leviäminen alkoi huomattavasti aikaisemmin ja noin 20 % havaitsi samanaikaisen alkamisen, ja yksi matalan profiilin merkkejä tulee olemaan ketterän ja DevOps-käytäntöjen puuttuminen:

Joukkueen topologiat

Viime vuoden lopussa kirja "Joukkueen topologiat", joka ehdottaa puitteita tiimitopologioiden kuvaamiselle. Mietimme, soveltuuko se venäläisiin yrityksiin. Ja esitimme kysymyksen: "Mitä kuvioita näet?"

Infrastruktuuritiimejä havaitaan puolella vastaajista sekä erilliset kehitys-, testaus- ja käyttötiimit. Yksittäiset DevOps-tiimit havaitsivat 45 %, joista korkeat edustajat ovat yleisempiä. Seuraavaksi tulevat poikkitoiminnalliset tiimit, jotka ovat myös yleisempiä Highissa. Erilliset SRE-komennot näkyvät High-, Medium-profiileissa, ja niitä löytyy harvoin matalasta profiilista:

DevQaOps-suhde

Näimme tämän kysymyksen FaceBookissa Skyeng-alustatiimin tiiminvetäjältä – hän oli kiinnostunut kehittäjien, testaajien ja ylläpitäjien suhteesta yrityksissä. Kysyimme sitä ja katsoimme vastauksia profiilit huomioiden: High profilen edustajilla on pienempi määrä testaus- ja käyttöinsinöörejä jokaista kehittäjää kohden:

Suunnitelmat 2021-vuodelle

Seuraavan vuoden suunnitelmissaan vastaajat huomioivat seuraavat aktiviteetit:

Täältä näet risteyksen DevOps Live 2020 -konferenssin kanssa. Tarkistimme ohjelman:

• Infrastruktuuri tuotteena
• DevOps-muunnos
• DevOps-käytäntöjen jakelu
• DevSecOps
• Tapausklubit ja keskustelut

Mutta puheemme ei riitä kattamaan kaikkia aiheita. Kulissien takana:

• Alusta palveluna ja tuotteena;
• Infrastruktuuri koodina, ympäristöinä ja pilvinä;
• Jatkuva integrointi ja toimitus;
• Arkkitehtuuri;
• DevSecOps-mallit;
• Alusta ja poikkitoiminnalliset tiimit.

Ilmoita Kirjamme on laaja, 50 sivua pitkä, ja voit tarkastella sitä tarkemmin.

Yhteenvetona

Toivomme, että tutkimuksemme ja raporttimme inspiroivat sinua kokeilemaan uusia lähestymistapoja kehitykseen, testaukseen ja toimintaan sekä auttavat sinua ymmärtämään suuntasi, vertailemaan itseäsi muihin tutkimuksessa osallistuviin ja tunnistamaan alueita, joilla voit parantaa omia lähestymistapojasi. .

Tulokset ensimmäisestä DevOps-tilatutkimuksesta Venäjällä:

• Keskeiset mittarit. Olemme havainneet, että keskeiset mittarit (toimitusaika, käyttöönottonopeus, palautumisaika ja muutosvirheet) sopivat kehitys-, testaus- ja käyttöprosessien tehokkuuden analysointiin.
• Profiilit High, Medium, Low. Kerätyn tiedon perusteella on mahdollista tunnistaa tilastollisesti erilaiset ryhmät: High, Medium, Low, joilla on mittareiden, käytäntöjen, prosessien ja työkalujen perusteella tunnusomaisia ​​piirteitä. Korkean profiilin edustajat osoittavat parempia tuloksia kuin matalat. He todennäköisemmin saavuttavat ja ylittävät tavoitteensa.
• Indikaattorit, pandemia ja suunnitelmat vuodelle 2021. Erityinen indikaattori tänä vuonna on, kuinka yritykset selviytyivät pandemiasta. High suoriutui paremmin, koki käyttäjäaktiivisuuden kasvua, ja tärkeimmät syyt menestykseen olivat tehokkaat kehitysprosessit ja vahva suunnittelukulttuuri.
• DevOps-käytännöt, työkalut ja niiden kehitys. Yritysten ensi vuoden pääsuunnitelmiin kuuluu DevOps-käytäntöjen ja -työkalujen kehittäminen, DevSecOps-käytäntöjen käyttöönotto sekä organisaatiorakenteen muutokset. Ja DevOps-käytäntöjen tehokas käyttöönotto ja kehittäminen toteutetaan pilottiprojekteilla, yhteisöjä ja osaamiskeskuksia muodostamalla, aloitteita yrityksen ylemmillä ja alemmilla tasoilla.

Kuulemme mielellämme arvostelujasi, tarinoitasi, palautettasi. Kiitämme kaikkia tutkimukseen osallistuneita ja odotamme osallistumistasi ensi vuonna.

Lähde: will.com