Starea DevOps în Rusia 2020

Cum înțelegi chiar starea unui lucru?

Te poți baza pe opinia ta, formată din diverse surse de informații, de exemplu, publicații pe site-uri web sau experiență. Îți poți întreba colegii și prietenii. O altă opțiune este să ne uităm la subiectele conferințelor: comitetul de program este reprezentanți activi ai industriei, așa că avem încredere în ei în alegerea subiectelor relevante. O zonă separată este cercetarea și rapoartele. Dar aici e o problema. Cercetările privind starea DevOps sunt efectuate anual în întreaga lume, rapoarte sunt publicate de companii străine și aproape nu există informații despre DevOps rusesc.

Dar a venit ziua în care a fost realizat un astfel de studiu, iar astăzi vă vom povesti despre rezultatele obținute. Starea DevOps în Rusia a fost studiată în comun de companii "Express 42"Și"Ontiko" Compania Express 42 ajută companiile de tehnologie să implementeze și să dezvolte practici și instrumente DevOps și a fost una dintre primele care a vorbit despre DevOps în Rusia. Autorii studiului, Igor Kurochkin și Vitaly Khabarov, sunt angajați în analiză și consultanță la Express 42, având un fundal tehnic de operare și experiență în diferite companii. Pe parcursul a 8 ani, colegii s-au uitat la zeci de companii și proiecte - de la startup-uri la întreprinderi - cu probleme diferite, precum și cu maturitate culturală și inginerească diferită.

În raportul lor, Igor și Vitaly au explicat ce probleme au existat în timpul procesului de cercetare, cum le-au rezolvat, precum și cum se desfășoară în principiu cercetarea DevOps și de ce Express 42 a decis să își desfășoare propria lor activitate. Puteți vedea raportul lor aici.

Cercetare DevOps

Igor Kurochkin a început conversația.

Întrebăm în mod regulat publicul de la conferințele DevOps: „Ați citit raportul Starea DevOps din acest an?” Doar câțiva ridică mâinile, dar cercetările noastre au arătat că doar o treime le studiază. Dacă nu ați văzut niciodată astfel de rapoarte, să spunem imediat că toate sunt foarte asemănătoare. Cel mai adesea există expresii precum: „Comparativ cu anul trecut...”

Aici avem prima noastră problemă, urmată de încă două:

1. Nu avem date pentru anul trecut. Nimeni nu este interesat de starea DevOps din Rusia;
2. Metodologie. Nu este clar cum se testează ipotezele, cum se construiesc întrebări, cum se efectuează analize, cum se compară rezultatele, cum se găsesc conexiuni;
3. Terminologie. Toate rapoartele sunt în limba engleză, este necesară traducerea, un cadru comun pentru DevOps nu a fost încă inventat și fiecare vine cu al lui.

Să ne uităm la modul în care au fost efectuate în general analizele privind starea DevOps în lume.

istorie

Cercetarea DevOps a fost efectuată din 2011. Primul care le-a condus a fost Puppet, un dezvoltator de sisteme de management al configurației. La acea vreme, era unul dintre principalele instrumente de descriere a infrastructurii sub formă de cod. Până în 2013, aceste studii erau pur și simplu sondaje în format închis și fără raportare publică.

În 2013, a apărut IT Revolution, editor al tuturor cărților majore despre DevOps. Împreună cu Puppet, au pregătit prima publicație „State of DevOps”, unde au apărut pentru prima dată 4 metrici cheie. În anul următor, compania de consultanță ThoughtWorks, cunoscută pentru radarele tehnologice obișnuite privind practicile și instrumentele din industrie, s-a implicat. Și în 2015, a fost adăugată o secțiune cu metodologie și a devenit clar cum efectuează analiza.

În 2016, autorii studiului, după ce și-au creat compania DORA (DevOps Research and Assessment), au publicat un raport anual. În anul următor, DORA și Puppet au emis raportul lor final comun.

Și atunci lucrurile au devenit interesante:

În 2018, companiile s-au divizat și au fost lansate două rapoarte independente: unul de la Puppet, al doilea de la DORA în colaborare cu Google. DORA a continuat să-și folosească metodologia cu valori cheie, profiluri de performanță și practici de inginerie care influențează valorile cheie și performanța în cadrul companiei. Și Puppet și-a propus abordarea cu o descriere a procesului și a evoluției DevOps. Dar povestea nu a prins; în 2019, Puppet a abandonat această metodologie și a lansat o nouă versiune a rapoartelor, în care a enumerat practicile cheie și modul în care acestea afectează DevOps din punctul lor de vedere. Apoi s-a întâmplat un alt lucru: Google a cumpărat DORA și împreună au lansat un alt raport. Poate ai văzut-o.

Anul acesta lucrurile s-au complicat. Se știe că Puppet și-a lansat sondajul. Au făcut-o cu o săptămână mai devreme decât noi și era deja finalizată. Am luat parte la ea și am văzut ce subiecte i-au interesat. Puppet își realizează acum analiza și se pregătește să publice raportul.

Dar încă nu există niciun anunț de la DORA și Google. În mai, când a început de obicei sondajul, au venit informații că Nicole Forsgren, unul dintre fondatorii DORA, s-a mutat la o altă companie. Prin urmare, am presupus că nu va exista nicio cercetare sau raport de la DORA în acest an.

Cum stau lucrurile in Rusia?

Nu am efectuat nicio cercetare despre DevOps. Am vorbit la conferințe, reluând concluziile altora, iar Raiffeisenbank a tradus „Starea DevOps” pentru 2019 (puteți găsi anunțul lor pe Habré), multumiri lor. Și e tot.

Prin urmare, ne-am efectuat propriile cercetări în Rusia folosind metodologiile și constatările DORA. Am folosit raportul colegilor de la Raiffeisenbank pentru cercetarea noastră, inclusiv pentru a sincroniza terminologia și traducerea. Și întrebările relevante pentru industrie au fost preluate din rapoartele DORA și din chestionarul Puppet de anul acesta.

Proces de cercetare

Raportul este doar partea finală. Întregul proces de cercetare constă din patru etape mari:

În etapa de pregătire, am intervievat experți din industrie și am pregătit o listă de ipoteze. Pe baza acestora, am compilat întrebări și am lansat un sondaj pentru întreaga lună august. Apoi am analizat și am pregătit raportul în sine. Pentru DORA, acest proces durează 6 luni. L-am finalizat în 3 luni, iar acum înțelegem că abia am avut timp suficient: doar făcând analiza înțelegi ce întrebări trebuie puse.

Participanții

Toate rapoartele străine încep cu un portret al participanților, iar majoritatea nu sunt din Rusia. Procentul respondenților ruși fluctuează de la 5 la 1% de la an la an, iar acest lucru nu ne permite să tragem nicio concluzie.

Harta din raportul Accelerate State of DevOps 2019:

În studiul nostru, am putut intervieva 889 de persoane - aceasta este destul de mult (DORA chestionează aproximativ o mie de persoane anual în rapoartele sale) și aici ne-am atins obiectivul:

Adevărat, nu toți participanții noștri au ajuns la final: procentul de finalizare a fost puțin mai mic de jumătate. Dar acest lucru a fost suficient pentru a obține un eșantion reprezentativ și pentru a efectua analize. DORA nu dezvăluie ratele de ocupare în rapoartele sale, așa că nu se pot face comparații aici.

Industrii și poziții

Respondenții noștri reprezintă o duzină de industrii. Jumătate lucrează în tehnologia informației. Urmează servicii financiare, comerț, telecomunicații și altele. Printre posturi se numără specialiști (dezvoltator, tester, inginer operațional) și personal de conducere (lideri de echipe, grupuri, zone, directori):

Fiecare a doua persoană lucrează într-o companie mijlocie. Fiecare a treia persoană lucrează în companii mari. Majoritatea lucrează în echipe de până la 9 persoane. Separat, am întrebat despre principalele activități, iar majoritatea sunt într-un fel sau altul legate de funcționare, iar aproximativ 40% sunt implicați în dezvoltare:

Așa am colectat informații pentru compararea și analiza reprezentanților diferitelor industrii, companii și echipe. Despre analiză vă va spune colegul meu Vitali Khabarov.

Analiză și comparație

Vitaly Khabarov: Mulțumiri tuturor participanților care au completat sondajul nostru, au completat chestionare și ne-au oferit date pentru analiza și testarea ulterioară a ipotezelor noastre. Și datorită clienților și clienților noștri, avem o experiență bogată care ne-a ajutat să identificăm problemele de interes pentru industrie și să formulăm ipotezele pe care le-am testat în cercetarea noastră.

Din păcate, nu puteți să luați o listă de întrebări pe de o parte și date pe de altă parte, să le comparați cumva, să spuneți: „Da, totul funcționează așa, am avut dreptate” și să mergem pe drumuri separate. Nu, avem nevoie de metodologie și metode statistice pentru a fi siguri că nu ne-am înșelat și că concluziile noastre sunt de încredere. Apoi ne putem construi munca ulterioară pe baza acestor date:

Valori cheie

Am luat ca bază metodologia DORA, pe care au descris-o în detaliu în cartea „Accelerate State of DevOps”. Am verificat dacă valorile cheie sunt potrivite pentru piața rusă, dacă pot fi utilizate în același mod în care DORA îl folosește pentru a răspunde la întrebarea: „Cum corespunde industria din Rusia cu industria străină?”

Valori cheie:

1. Frecvența de desfășurare. Cât de des este implementată o nouă versiune a unei aplicații în mediul de producție (modificări planificate, excluzând remedierile rapide și răspunsul la incident)?
2. Timpul de livrare. Care este timpul mediu dintre efectuarea unei modificări (scrierea funcționalității ca cod) și implementarea modificării în mediul de producție?
3. Timp de recuperare. Cât timp durează în medie restabilirea unei aplicații într-un mediu de producție după un incident, degradarea serviciului sau detectarea unei erori care afectează utilizatorii aplicației?
4. Modificări nereușite. Ce procent de implementări într-un mediu de produs duc la degradarea aplicației sau la incidente și necesită eliminarea consecințelor (retroducerea modificărilor, dezvoltarea unei remedieri rapide sau a unui patch)?

Cercetările DORA au găsit o legătură între aceste metrici și performanța organizațională. O verificăm și în studiul nostru.

Dar pentru a vă asigura că cele patru valori cheie pot influența ceva, trebuie să înțelegeți - sunt cumva legate între ele? DORA a răspuns da, cu o avertizare: relația dintre Rata de eșec al schimbării și celelalte trei metrici este puțin mai slabă. Avem cam aceeași poză. Dacă timpul de livrare, frecvența de desfășurare și timpul de recuperare sunt corelate între ele (am stabilit această corelație prin corelația Pearson și prin scala Chaddock), atunci nu există o corelație atât de puternică cu modificările nereușite.

În principiu, majoritatea respondenților tind să răspundă că au un număr destul de mic de incidente care au loc în producție. Deși vom vedea mai târziu că există încă o diferență semnificativă între grupurile de respondenți în rata modificărilor nereușite, nu putem încă folosi această măsură pentru această diviziune.

Atribuim acest lucru faptului că (după cum sa dovedit în procesul de analiză și comunicare cu unii dintre clienții noștri) există o ușoară diferență în percepția a ceea ce este considerat un incident. Dacă am reușit să restabilim funcționalitatea serviciului nostru în timpul ferestrei tehnice, poate fi considerat un incident? Probabil că nu, pentru că am reparat totul, suntem grozavi. Poate fi considerat un incident dacă ar trebui să re-rollăm aplicația noastră de 10 ori în modul normal, familiar? Se pare că nu. Prin urmare, problema relației dintre modificările nereușite și alte valori rămâne deschisă. Vom clarifica mai departe.

Ceea ce este important aici este că am găsit o corelație semnificativă între timpul de livrare, timpul de recuperare și frecvența de implementare. Prin urmare, am luat aceste trei valori pentru a împărți în continuare respondenții în grupuri în funcție de productivitate.

Cât de mult să stai în grame?

Am folosit analiza cluster ierarhică:

• Distribuim respondenții în spațiul n-dimensional, unde coordonatele fiecărui respondent sunt răspunsurile lor la întrebări.
• Declarăm că fiecare respondent este un grup mic.
• Combinăm cele două clustere cele mai apropiate unul de celălalt într-un cluster mai mare.
• Găsim următoarea pereche de clustere și le combinăm într-un cluster mai mare.

Acesta este modul în care grupăm toți respondenții noștri în numărul de grupuri de care avem nevoie. Folosind o dendrogramă (un arbore de conexiuni între clustere) vedem distanța dintre două clustere învecinate. Tot ce ne rămâne este să stabilim o anumită limită pentru distanța dintre aceste grupuri și să spunem: „Aceste două grupuri se disting destul de mult unul de celălalt, deoarece distanța dintre ele este gigantică”.

Dar există o problemă ascunsă aici: nu avem restricții privind numărul de clustere - putem obține 2, 3, 4, 10 clustere. Și prima idee a fost - de ce să nu împărțim toți respondenții noștri în 4 grupuri, așa cum face DORA. Am constatat însă că diferențele dintre aceste grupuri devin nesemnificative și nu putem fi siguri că respondentul aparține cu adevărat grupului său și nu celui vecin. Încă nu putem împărți piața rusă în patru grupuri. Prin urmare, ne-am stabilit pe trei profiluri, între care există o diferență semnificativă statistic:

Apoi, am determinat profilul după cluster: am luat medianele pentru fiecare metrică pentru fiecare grup și am compilat un tabel cu profile de eficiență. De fapt, au fost obținute profilurile de performanță rezultate pentru participantul mediu din fiecare grup. Am identificat trei profiluri de eficiență: scăzut, mediu, ridicat:

Aici ne-am confirmat ipoteza că 4 metrici cheie sunt potrivite pentru a determina profilul de performanță și funcționează atât pe piața occidentală, cât și pe cea rusă. Există o diferență între grupuri și este semnificativă statistic. Aș dori să subliniez că există o diferență semnificativă în medie între profilurile de performanță pentru metrica modificărilor nereușite, chiar dacă inițial nu am împărțit respondenții la acest parametru.

Atunci apare întrebarea: cum să folosești toate acestea?

Cum să utilizați

Dacă luăm orice echipă, 4 valori cheie și le aplicăm pe tabel, atunci în 85% din cazuri nu vom obține un meci complet - acesta este doar participantul mediu și nu ceea ce este în realitate. Suntem cu toții (și fiecare echipă) puțin diferiți.

Am verificat: am luat respondenții noștri și profilul de performanță DORA și am analizat câți respondenți corespundeau unuia sau altuia profil. Am constatat că doar 16% dintre respondenți s-au încadrat cu acuratețe într-unul dintre profiluri. Toate celelalte sunt împrăștiate undeva la mijloc:

Aceasta înseamnă că profilul de performanță are un domeniu limitat. Pentru a obține o primă aproximare a locului în care vă aflați, puteți utiliza acest tabel: „Oh, se pare că suntem mai aproape de Mediu sau Ridicat!” Dacă înțelegi unde mergi mai departe, asta poate fi suficient. Dar dacă scopul tău este îmbunătățirea constantă, continuă și vrei să știi mai precis unde să te dezvolți și ce să faci, atunci sunt necesare fonduri suplimentare. Le-am numit calculatoare:

• Calculator DORA
• Calculator Express 42* (în dezvoltare)
• Dezvoltarea proprie (vă puteți crea propriul calculator intern).

Pentru ce sunt necesare? A întelege:

• Echipa din cadrul organizației noastre îndeplinește standardele noastre?
• Dacă nu, o putem ajuta - să o accelerăm în cadrul expertizei de care dispune compania noastră?
• Dacă da, putem face și mai bine?

De asemenea, le puteți folosi pentru a colecta statistici în cadrul companiei:

• Ce fel de echipe avem?
• Împărțiți echipele în profiluri;
• Vezi: Oh, aceste echipe au performanțe slabe (puțin lente), dar acestea sunt grozave: se desfășoară în fiecare zi, fără erori, timpul lor de livrare este mai mic de o oră.

Și apoi puteți afla că în cadrul companiei noastre avem expertiza și instrumentele necesare acelor echipe care încă nu sunt în stare.

Sau, dacă înțelegi că te simți grozav în cadrul companiei, că ești mai bun decât mulți, atunci poți arăta puțin mai larg. Aceasta este tocmai industria rusă: putem obține expertiza necesară în industria rusă pentru a ne accelera? Calculatorul Express 42 vă va ajuta aici (este în curs de dezvoltare). Dacă ați depășit piața rusă, atunci uitați-vă la Calculator DORA si pe piata mondiala.

Amenda. Și dacă ești în grupul Elit conform calculatorului DORA, atunci ce ar trebui să faci? Nu există o soluție bună aici. Cel mai probabil, sunteți în fruntea industriei, iar accelerarea și îmbunătățirea în continuare a fiabilității sunt posibile prin cercetare și dezvoltare internă și prin cheltuirea unor resurse mari.

Să trecem la partea cea mai dulce - comparație.

comparație

Am vrut inițial să comparăm industria rusă cu cea occidentală. Dacă comparăm direct, vedem că avem mai puține profiluri și sunt puțin mai amestecate între ele, granițele sunt puțin mai neclare:

Interpreții noștri de elită sunt ascunși printre cei de înaltă performanță, dar sunt acolo - aceștia sunt elita, unicornii care au atins culmi semnificative. În Rusia, diferența dintre profilurile Elite și High nu este încă suficient de semnificativă. Credem că în viitor această diviziune se va produce din cauza creșterii culturii inginerești, a calității implementării practicilor inginerești și a expertizei în cadrul companiilor.

Dacă trecem la comparația directă în cadrul industriei ruse, vedem că echipele de profil înalt sunt mai bune din toate punctele de vedere. De asemenea, am confirmat ipoteza noastră că există o legătură între aceste metrici și eficiența organizațională: echipele de profil înalt au șanse semnificativ mai mari nu numai să atingă obiectivele, ci și să le depășească.
Să devenim echipe de profil înalt și să nu ne oprim aici:

Dar acest an este special și am decis să verificăm modul în care companiile trăiesc într-o pandemie: echipele de profil înalt fac față semnificativ mai bine și se simt mai bine decât media industriei:

• Produsele noi au fost lansate de 1,5-2 ori mai des,
• Fiabilitate și/sau performanță crescută a infrastructurii aplicațiilor de 2 ori mai des.

Adică, competențele pe care le aveau deja i-au ajutat să se dezvolte mai rapid, să introducă noi produse, să modifice produsele existente, cucerind astfel noi piețe și noi utilizatori:

Ce a mai ajutat echipele noastre?

Practici de inginerie

Vă voi spune despre constatările semnificative pentru fiecare practică pe care am verificat-o. Poate că altceva a ajutat echipele, dar vorbim despre DevOps. Și în cadrul DevOps, vedem diferențe între echipele de profiluri diferite.

Platforma ca serviciu

Nu am găsit o relație semnificativă între vârsta platformei și profilul echipei: Platformele au apărut aproximativ în același timp atât pentru echipele Low, cât și pentru High. Dar pentru cei din urmă, platforma oferă în medie mai multe servicii și mai multe interfețe software pentru control prin codul programului. Și echipele platformei sunt mai probabil să-și ajute dezvoltatorii și echipele să folosească platforma, să își rezolve problemele și incidentele legate de platformă și să antreneze alte echipe.

Infrastructura ca cod

Totul aici este destul de standard. Am găsit o relație între automatizarea codului de infrastructură și câte informații sunt stocate în depozitul de infrastructură. Echipele de profil înalt stochează mai multe informații în depozite: acestea includ configurația infrastructurii, conducta CI/CD, setările de mediu și parametrii de construcție. Ei stochează aceste informații mai des, funcționează mai bine cu codul de infrastructură și au automatizat mai multe procese și sarcini pentru lucrul cu codul de infrastructură.

Interesant este că nu am văzut o diferență semnificativă în testele de infrastructură. Atribuiesc acest lucru faptului că echipele de profil înalt au, în general, mai multă automatizare a testelor. Poate că nu ar trebui să fie distrași separat de testele de infrastructură, ci mai degrabă testele pe care le folosesc pentru a verifica aplicațiile sunt suficiente și, datorită lor, pot vedea ce și unde au stricat.

Integrare și livrare

Secțiunea cea mai plictisitoare, pentru că am confirmat: cu cât aveți mai multă automatizare, cu atât lucrați mai bine cu codul, cu atât aveți mai multe șanse să obțineți rezultate mai bune.

Arhitectură

Am vrut să vedem cum microservicii influențează performanța. Sincer să fiu, nu, deoarece utilizarea microserviciilor nu este asociată cu o creștere a indicatorilor de eficiență. Microserviciile sunt folosite atât de echipe de profil înalt, cât și de echipe de profil scăzut.

Dar ceea ce este semnificativ este că pentru echipele înalte, tranziția la o arhitectură de microservicii le permite să-și dezvolte în mod independent serviciile și să le lanseze. Dacă arhitectura permite dezvoltatorilor să acționeze autonom, fără a aștepta pe cineva extern echipei, atunci aceasta este o competență cheie pentru creșterea vitezei. Aici ajută microservicii. Dar, pur și simplu, implementarea lor nu joacă un rol important.

Cum am descoperit toate acestea?

Aveam un plan ambițios de a replica pe deplin metodologia DORA, dar nu aveam resurse. Dacă DORA folosește multă sponsorizare și studiul le ia șase luni, am realizat studiul nostru într-un timp scurt. Am vrut să construim un model DevOps așa cum face DORA și vom face asta în viitor. Deocamdată ne-am limitat la hărți termice:

Am analizat distribuția practicilor de inginerie între echipele fiecărui profil și am constatat că echipele de profil înalt, în medie, folosesc practicile de inginerie mai des. Puteți citi mai multe despre toate acestea în pagina noastră raport.

Pentru o schimbare, să trecem de la statistici complexe la cele simple.

Ce altceva am mai descoperit?

Instrumente

Observăm că familia Linux OS folosește cele mai multe comenzi. Dar Windows este încă în tendință - cel puțin un sfert dintre respondenții noștri au remarcat utilizarea uneia sau alteia versiuni a acestuia. Piața pare să aibă această nevoie. Prin urmare, puteți dezvolta aceste competențe și puteți susține prezentări la conferințe.

Printre orchestratori, nu este un secret că Kubernetes conduce (52%). Următorul orchestrator la rând este Docker Swarm (aproximativ 12%). Cele mai populare sisteme CI sunt Jenkins și GitLab. Cel mai popular sistem de management al configurației este Ansible, urmat de iubitul nostru Shell.

Printre furnizorii de găzduire în cloud, Amazon ocupă în prezent poziția de lider. Ponderea norilor rusești crește treptat. Anul viitor va fi interesant de văzut cum se vor simți furnizorii ruși de cloud și dacă cota lor de piață va crește. Ele există, pot fi folosite și asta e bine:

Dau cuvântul lui Igor, care va mai da câteva statistici.

Răspândirea practicilor

Igor Kurochkin: Separat, le-am cerut respondenților să indice modul în care practicile inginerești luate în considerare sunt distribuite în companie. Majoritatea companiilor au o abordare mixtă constând dintr-un set diferit de modele, iar proiectele pilot sunt foarte populare. Am văzut și o mică diferență între profile. Reprezentanții de profil înalt folosesc mai des modelul „Inițiativa de jos”, atunci când echipele mici de specialiști schimbă procesele de lucru, instrumentele și împărtășesc dezvoltările de succes cu alte echipe. La Medium, aceasta este o inițiativă de sus în jos care atinge întreaga companie prin crearea de comunități și centre de excelență:

Agile și DevOps

Relația dintre Agile și DevOps este adesea discutată în industrie. Această întrebare este ridicată și în Raportul State of Agile pentru 2019/2020, așa că am decis să comparăm modul în care sunt legate activitățile Agile și DevOps din companii. Am descoperit că DevOps fără Agile este rar. Pentru jumătate dintre respondenți, răspândirea Agile a început considerabil mai devreme, iar aproximativ 20% au observat un început simultan, iar unul dintre semnele unui profil scăzut va fi absența practicilor Agile și DevOps:

Topologii de echipă

La sfârșitul anului trecut, cartea „Topologii de echipă„, care propune un cadru pentru descrierea topologiilor de echipă. Ne-am întrebat dacă s-ar aplica companiilor rusești. Și am pus întrebarea: „Ce modele vezi?”

Echipele de infrastructură sunt observate la jumătate dintre respondenți, precum și echipe separate de dezvoltare, testare și operațiuni. Echipele individuale DevOps au remarcat 45%, printre care înalții reprezentanți sunt mai des întâlniți. Urmează echipele interfuncționale, care sunt, de asemenea, mai frecvente la High. Comenzile SRE separate apar în profilurile Înalt, Mediu și se găsesc rar în Profilul scăzut:

Raportul DevQaOps

Am văzut această întrebare pe FaceBook de la șeful echipei platformei Skyeng - era interesat de raportul dintre dezvoltatori, testeri și administratori din companii. Am întrebat-o și am analizat răspunsurile ținând cont de profiluri: reprezentanții High profile au un număr mai mic de ingineri de testare și operațiuni pentru fiecare dezvoltator:

Planuri pentru anul 2021

În planurile lor pentru anul următor, respondenții au notat următoarele activități:

Aici puteți vedea intersecția cu conferința DevOps Live 2020. Am revizuit cu atenție programul:

• Infrastructura ca produs
• Transformarea DevOps
• Distribuirea practicilor DevOps
• DevSecOps
• Cluburi de caz și discuții

Dar discursul nostru nu va avea suficient timp pentru a acoperi toate subiectele. În spatele scenelor:

• Platformă ca serviciu și ca produs;
• Infrastructura ca cod, medii și nori;
• Integrare și livrare continuă;
• Arhitectură;
• Modele DevSecOps;
• Platformă și echipe interfuncționale.

raport Al nostru este voluminos, are 50 de pagini și îl puteți privi mai detaliat.

Rezumând

Sperăm că cercetările și raportul nostru vă vor inspira să experimentați noi abordări ale dezvoltării, testării și operațiunilor, precum și să vă ajute să vă orientați, să vă comparați cu alții din studiu și să identificați domeniile în care vă puteți îmbunătăți propriile abordări. .

Rezultatele primului studiu al stării DevOps în Rusia:

• Valori cheie. Am descoperit că valorile cheie (timpul de livrare, rata de implementare, timpul de recuperare și eșecurile modificării) sunt potrivite pentru analiza eficacității proceselor de dezvoltare, testare și operațiuni.
• Profiluri înalt, mediu, scăzut. Pe baza datelor colectate, este posibil să se identifice statistic diferite grupuri: Ridicat, Mediu, Scăzut, cu caracteristici distinctive bazate pe metrici, practici, procese și instrumente. Reprezentanții Profilului Înalt arată rezultate mai bune decât Low. Au mai multe șanse să-și atingă și să-și depășească obiectivele.
• Indicatori, pandemie și planuri pentru 2021. Un indicator special în acest an este modul în care companiile au făcut față pandemiei. High a avut performanțe mai bune, a cunoscut o creștere a activității utilizatorilor, iar principalele motive pentru succes au fost procesele de dezvoltare eficiente și o cultură inginerească puternică.
• Practicile, instrumentele și dezvoltarea lor DevOps. Principalele planuri ale companiilor pentru anul viitor includ dezvoltarea practicilor și instrumentelor DevOps, introducerea practicilor DevSecOps și schimbări în structura organizațională. Iar implementarea și dezvoltarea efectivă a practicilor DevOps se realizează prin proiecte pilot, formarea de comunități și centre de competență, inițiative la nivelurile superioare și inferioare ale companiei.

Vom fi bucuroși să auzim recenziile, poveștile, feedback-ul dvs. Mulțumim tuturor celor care au participat la studiu și așteptăm cu nerăbdare participarea dumneavoastră anul viitor.

Sursa: www.habr.com