Stav DevOps v Rusku 2020

Ako pochopiť stav niečoho?

Môžete sa spoľahnúť na svoj názor vytvorený z rôznych zdrojov informácií, napríklad z publikácií na webových stránkach alebo zo skúseností. Môžete sa opýtať kolegov, známych. Ďalšou možnosťou je pozrieť sa na témy konferencií: programovým výborom sú aktívni zástupcovia priemyslu, preto im pri výbere relevantných tém dôverujeme. Samostatnou oblasťou sú výskumy a správy. Ale je tu problém. Vo svete sa každoročne robí prieskum o stave DevOps, správy vydávajú zahraničné spoločnosti a o ruských DevOps neexistujú takmer žiadne informácie.

Ale prišiel deň, keď sa takáto štúdia uskutočnila, a dnes budeme hovoriť o výsledkoch. Stav DevOps v Rusku študovali spoločnosti spoločne “Expres 42"A"Ontico". Express 42 pomáha technologickým spoločnostiam implementovať a rozvíjať postupy a nástroje DevOps a bol jedným z prvých, ktorí hovorili o DevOps v Rusku. Autori štúdie Igor Kurochkin a Vitalij Chabarov sa v Express 42 venujú analýze a poradenstvu, pričom disponujú technickým zázemím z prevádzky a skúsenosťami v rôznych spoločnostiach. Za 8 rokov sa kolegovia pozreli na desiatky firiem a projektov – od startupov až po podniky – s rôznymi problémami, ako aj rôznou kultúrnou a inžinierskou vyspelosťou.

Igor a Vitaly vo svojej správe povedali, aké problémy boli v procese výskumu, ako ich vyriešili, ako aj to, ako v zásade prebieha výskum DevOps a prečo sa Express 42 rozhodol uskutočniť svoj vlastný. Ich správu si môžete pozrieť tu.

Výskum DevOps

Rozhovor začal Igor Kurochkin.

Na konferenciách DevOps sa pravidelne pýtame publika: „Čítali ste správu o stave DevOps za tento rok? Len málokto zdvihne ruky a naša štúdia ukázala, že ich skúma iba tretina. Ak ste takéto správy ešte nevideli, povedzme hneď, že sú si všetky veľmi podobné. Najčastejšie sa vyskytujú frázy ako: "V porovnaní s minulým rokom ..."

Tu máme prvý problém a po ňom ďalšie dva:

1. Údaje za minulý rok nemáme. Stav DevOps v Rusku nikoho nezaujíma;
2. Metodológia. Nie je jasné, ako testovať hypotézy, ako zostavovať otázky, ako analyzovať, porovnávať výsledky, nájsť súvislosti;
3. Terminológia. Všetky reporty sú v angličtine, je potrebný preklad, spoločný framework DevOps ešte nebol vynájdený a každý si príde na svoje.

Pozrime sa, ako sa vo svete robili analýzy stavu DevOps.

Historické informácie

Výskum DevOps prebieha od roku 2011. Puppet, vývojár systémov na správu konfigurácie, bol prvý, kto ich vykonal. V tom čase to bol jeden z hlavných nástrojov na popis infraštruktúry vo forme kódu. Do roku 2013 boli tieto štúdie jednoducho uzavretými prieskumami a žiadnymi verejnými správami.

V roku 2013 sa objavila spoločnosť IT Revolution, vydavateľ všetkých hlavných kníh o DevOps. Spolu s Puppet pripravili prvú publikáciu State of DevOps, kde sa prvýkrát objavili 4 kľúčové metriky. Nasledujúci rok sa zapojila ThoughtWorks, konzultačná firma známa svojimi pravidelnými technologickými radarmi o priemyselných postupoch a nástrojoch. A v roku 2015 pribudla časť s metodikou a bolo jasné, ako robia analýzu.

V roku 2016 autori štúdie po vytvorení vlastnej spoločnosti DORA (DevOps Research and Assessment) zverejnili výročnú správu. Nasledujúci rok DORA a Puppet vydali svoju poslednú spoločnú správu.

A potom začalo niečo zaujímavé:

V roku 2018 sa spoločnosti rozdelili a boli zverejnené dve nezávislé správy: jedna od Puppet, druhá od DORA spolu s Google. DORA naďalej využíva svoju metodológiu pomocou kľúčových metrík, výkonnostných profilov a inžinierskych postupov, ktoré ovplyvňujú kľúčové metriky a výkonnosť celej spoločnosti. A Puppet ponúkol svoj vlastný prístup s popisom procesu a vývoja DevOps. Príbeh sa však neujal, v roku 2019 Puppet túto metodiku opustil a vydal novú verziu správ, v ktorej sú uvedené kľúčové postupy a ako ovplyvňujú DevOps z ich pohľadu. Potom sa stala ďalšia udalosť: Google kúpil DORA a spoločne vydali ďalšiu správu. Možno ste ho videli.

Tento rok sa veci skomplikovali. Je známe, že Puppet spustil vlastný prieskum. Urobili to o týždeň skôr ako my a už to skončilo. Zúčastnili sme sa ho a pozreli sme sa, aké témy ich zaujímajú. Teraz Puppet robí analýzu a pripravuje sa na zverejnenie správy.

Stále však neexistuje žiadne oznámenie od spoločností DORA a Google. V máji, keď prieskum zvyčajne začínal, prišla informácia, že Nicole Forsgren, jedna zo zakladateľov DORA, prestúpila do inej spoločnosti. Preto sme predpokladali, že tento rok nebude výskum a správa z DORA.

Ako je to v Rusku?

Nerobili sme prieskum DevOps. Hovorili sme na konferenciách, prerozprávali poznatky iných ľudí a Raiffeisenbank preložila „State of DevOps“ na rok 2019 (ich oznámenie nájdete na Habré), patrí im veľká vďaka. A to je všetko.

Preto sme v Rusku uskutočnili vlastný výskum pomocou metodík a zistení DORA. Správu kolegov z Raiffeisenbank sme použili na náš výskum, vrátane synchronizácie terminológie a prekladu. A otázky týkajúce sa odvetvia boli prevzaté zo správ DORA a tohtoročného dotazníka Puppet.

Výskumný proces

Správa je len záverečnou časťou. Celý výskumný proces pozostáva zo štyroch hlavných krokov:

Počas prípravnej fázy sme viedli rozhovory s odborníkmi z odvetvia a pripravili sme zoznam hypotéz. Na ich základe boli zostavené otázky a spustený prieskum na celý august. Potom sme analyzovali a pripravili samotnú správu. Pre DORA tento proces trvá 6 mesiacov. Stretli sme sa do 3 mesiacov a teraz chápeme, že sme mali sotva dosť času: iba vykonaním analýzy pochopíte, aké otázky musíte položiť.

Účastníci

Všetky zahraničné správy začínajú portrétom účastníkov a väčšina z nich nie je z Ruska. Percento ruských respondentov sa z roka na rok pohybuje medzi 5 a 1 %, čo neumožňuje vyvodzovať žiadne závery.

Mapa zo správy Accelerate State of DevOps 2019:

V našej štúdii sa nám podarilo vyspovedať 889 ľudí – to je pomerne veľa (DORA vo svojich správach ročne zisťuje okolo tisíc ľudí) a tu sme dosiahli cieľ:

Je pravda, že nie všetci naši účastníci dosiahli koniec: percento dokončenia bolo o niečo menej ako polovica. Ale aj to stačilo na získanie reprezentatívnej vzorky a vykonanie analýzy. DORA vo svojich správach nezverejňuje percentá plnenia, takže tu nie je žiadne porovnanie.

Odvetvia a pozície

Naši respondenti zastupujú tucet odvetví. Polovičná práca v informačných technológiách. Nasledujú finančné služby, obchod, telekomunikácie a iné. Medzi pozíciami sú špecialisti (vývojár, tester, prevádzkový inžinier) a riadiaci pracovníci (vedúci tímov, skupín, oblastí, riaditelia):

Každý druhý pracuje pre stredne veľkú firmu. Každý tretí človek pracuje vo veľkých firmách. Väčšina pracuje v tímoch do 9 ľudí. Samostatne sme sa pýtali na hlavné činnosti a väčšina z nich nejako súvisí s prevádzkou a asi 40% sa zaoberá vývojom:

Zozbierali sme teda informácie na porovnanie a analýzu zástupcov rôznych odvetví, spoločností, tímov. O analýze povie môj kolega Vitaly Khabarov.

Analýza a porovnanie

Vitaly Khabarov: Veľká vďaka všetkým účastníkom, ktorí vyplnili náš prieskum, vyplnili dotazníky a poskytli nám údaje na ďalšiu analýzu a testovanie našich hypotéz. A vďaka našim klientom a zákazníkom máme bohaté skúsenosti, ktoré nám pomohli identifikovať obavy odvetvia a formulovať hypotézy, ktoré sme testovali v našom výskume.

Bohužiaľ, nemôžete si vziať zoznam otázok na jednej strane a údaje na strane druhej, nejako ich porovnať, povedať: „Áno, všetko tak funguje, mali sme pravdu“ a rozptýliť sa. Nie, potrebujeme metodológiu a štatistické metódy, aby sme si boli istí, že sa nemýlime a naše závery sú spoľahlivé. Potom môžeme vybudovať našu ďalšiu prácu na základe týchto údajov:

Kľúčové metriky

Ako základ sme si zobrali metodiku DORA, ktorú podrobne opísali v knihe “Accelerate State of DevOps”. Skontrolovali sme, či sú kľúčové metriky vhodné pre ruský trh, či sa dajú použiť rovnakým spôsobom ako DORA pri odpovedi na otázku: „Ako zodpovedá priemysel v Rusku zahraničnému priemyslu?

Kľúčové metriky:

1. Frekvencia nasadenia. Ako často sa nová verzia aplikácie nasadzuje do produkčného prostredia (plánované zmeny, s výnimkou rýchlych opráv a reakcie na incidenty)?
2. Dodacia lehota. Aký je priemerný čas medzi vykonaním zmeny (zápisom funkčnosti ako kódu) a nasadením zmeny do produkčného prostredia?
3. Čas obnovenia. Ako dlho v priemere trvá obnovenie aplikácie do produkčného prostredia po incidente, degradácii služby alebo odhalení chyby, ktorá ovplyvňuje používateľov aplikácie?
4. Neúspešné zmeny. Aké percento nasadení v produkčnom prostredí vedie k degradácii aplikácie alebo incidentom a vyžaduje nápravu (vrátenie zmien, vývoj rýchlej opravy alebo opravy)?

DORA vo svojom výskume našla súvislosť medzi týmito metrikami a výkonnosťou organizácie. Testujeme to aj v našej štúdii.

Aby ste sa však uistili, že štyri kľúčové metriky môžu niečo ovplyvniť, musíte pochopiť - súvisia spolu nejako? DORA odpovedala kladne s jednou výhradou: vzťah medzi neúspešnými zmenami (Change Failure Rate) a tromi ďalšími metrikami je o niečo slabší. Dostali sme približne rovnaký obrázok. Ak čas dodania, frekvencia nasadenia a čas zotavenia navzájom korelujú (túto koreláciu sme stanovili prostredníctvom Pearsonovej korelácie a prostredníctvom Chaddockovej škály), potom neexistuje taká silná korelácia s neúspešnými zmenami.

V zásade má väčšina respondentov tendenciu odpovedať, že majú pomerne malý počet incidentov vo výrobe. Aj keď neskôr uvidíme, že medzi skupinami respondentov je stále výrazný rozdiel z hľadiska neúspešných zmien, túto metriku zatiaľ nemôžeme použiť na toto rozdelenie.

Pripisujeme to tomu, že (ako sa ukázalo pri analýze a komunikácii s niektorými našimi zákazníkmi) je mierny rozdiel vo vnímaní toho, čo sa považuje za incident. Ak sa nám počas technického okna podarilo obnoviť výkon našej služby, možno to považovať za incident? Asi nie, veď sme všetko opravili, je nám super. Môžeme to považovať za incident, ak by sme museli svoju aplikáciu pretočiť 10-krát v normálnom, pre nás známom režime? Zdá sa, že nie. Preto zostáva otvorená otázka vzťahu neúspešných zmien s inými metrikami. Budeme to ďalej dolaďovať.

Dôležité je, že sme našli významnú koreláciu medzi dodacími lehotami, časom obnovy a frekvenciou nasadenia. Preto sme použili tieto tri metriky, aby sme ďalej rozdelili respondentov do výkonnostných skupín.

Koľko stojí v gramoch?

Použili sme hierarchickú zhlukovú analýzu:

• Respondentov rozmiestňujeme v n-rozmernom priestore, kde súradnicami každého respondenta sú jeho odpovede na otázky.
• Každý respondent je vyhlásený za malý zhluk.
• Dva zhluky najbližšie k sebe spojíme do jedného väčšieho zhluku.
• Nájdeme ďalší pár zhlukov a spojíme ich do väčšieho zhluku.

Takto zoskupíme všetkých našich respondentov do počtu zhlukov, ktoré potrebujeme. Pomocou dendrogramu (stromu spojení medzi zhlukmi) vidíme vzdialenosť medzi dvoma susednými zhlukmi. Zostáva nám už len stanoviť určitú hranicu vzdialenosti medzi týmito zhlukmi a povedať: "Tieto dve skupiny sú od seba celkom odlíšiteľné, pretože vzdialenosť medzi nimi je obrovská."

Ale je tu skrytý problém: nemáme žiadne obmedzenia na počet zhlukov - môžeme získať 2, 3, 4, 10 zhlukov. A prvá myšlienka bola – prečo nerozdeliť všetkých našich respondentov do 4 skupín, ako to robí DORA. Zistili sme však, že rozdiely medzi týmito skupinami sú zanedbateľné a nemôžeme si byť istí, že respondent skutočne patrí do svojej skupiny, a nie do susednej. Ruský trh zatiaľ nemôžeme rozdeliť do štyroch skupín. Preto sme sa rozhodli pre tri profily, medzi ktorými je štatisticky významný rozdiel:

Ďalej sme určili profil podľa klastrov: vzali sme medián pre každú metriku pre každú skupinu a zostavili sme tabuľku profilov výkonnosti. V skutočnosti sme získali výkonnostné profily priemerného účastníka v každej skupine. Identifikovali sme tri profily účinnosti: Nízka, Stredná, Vysoká:

Tu sme potvrdili našu hypotézu, že na určenie výkonnostného profilu sú vhodné 4 kľúčové metriky, ktoré fungujú na západnom aj ruskom trhu. Medzi skupinami je rozdiel a je štatisticky významný. Zdôrazňujem, že medzi výkonnostnými profilmi je výrazný rozdiel z hľadiska metriky neúspešných zmien z hľadiska priemeru, aj keď sme pôvodne respondentov týmto parametrom nerozdeľovali.

Potom vyvstáva otázka: ako toto všetko využiť?

Ako používať

Ak vezmeme akýkoľvek tím, 4 kľúčové metriky a aplikujeme ich na tabuľku, potom v 85% prípadov nezískame úplný zápas - je to len priemerný účastník a nie to, čo je v skutočnosti. Všetci (a každý tím) sme trochu iní.

Skontrolovali sme: zobrali sme našich respondentov a výkonnostný profil DORA a pozreli sme sa na to, koľko respondentov vyhovuje tomu alebo tomu profilu. Zistili sme, že len 16 % opýtaných určite spadalo do niektorého z profilov. Všetky ostatné sú rozptýlené niekde medzi:

To znamená, že profil účinnosti má obmedzený rozsah. Ak chcete pochopiť, kde sa nachádzate v prvej aproximácii, môžete použiť túto tabuľku: „Ach, zdá sa, že sme bližšie k strednej alebo vysokej úrovni!“ Ak pochopíte, kam ísť ďalej, môže to stačiť. Ale ak je vaším cieľom neustále, neustále zlepšovanie a chcete presnejšie vedieť, kde sa máte rozvíjať a čo robiť, potom sú potrebné ďalšie finančné prostriedky. Nazvali sme ich kalkulačky:

• Kalkulačka DORA
• Calculator Express 42* (vo vývoji)
• Vlastný vývoj (môžete si vytvoriť vlastnú internú kalkulačku).

Na čo sú potrebné? Rozumieť:

• Spĺňa tím v našej organizácii naše štandardy?
• Ak nie, vieme tomu pomôcť, urýchliť to v rámci odbornosti, ktorou naša spoločnosť disponuje?
• Ak áno, môžeme to urobiť ešte lepšie?

Môžete ich použiť aj na zhromažďovanie štatistík v rámci spoločnosti:

• Aké tímy máme?
• Rozdeľte tímy do profilov;
• Pozri: Ach, tieto príkazy sú nedostatočne výkonné (nevyťahujú sa málo), ale tieto sú skvelé: nasadzujú sa každý deň, bez chýb, majú čas prípravy menej ako hodinu.

A potom môžete zistiť, že v našej spoločnosti sú potrebné odborné znalosti a nástroje pre tie tímy, ktoré ešte nie sú na úrovni.

Alebo, ak pochopíte, že sa v spoločnosti cítite skvele, ste lepší ako mnohí, potom môžete vyzerať trochu širšie. Toto je len ruský priemysel: môžeme získať potrebné odborné znalosti v ruskom priemysle, aby sme sa zrýchlili? Tu pomôže kalkulačka Express 42 (je vo vývoji). Ak ste prerástli ruský trh, pozrite sa Kalkulačka DORA a na svetový trh.

Dobre. A ak ste v skupine Elit na kalkulačke DORA, čo by ste mali urobiť? Dobré riešenie tu neexistuje. S najväčšou pravdepodobnosťou ste v popredí odvetvia a ďalšie zrýchlenie a spoľahlivosť je možné prostredníctvom interného výskumu a vývoja a vynaložením väčšieho množstva zdrojov.

Prejdime k tomu najmilšiemu – prirovnaniu.

Сравнение

Pôvodne sme chceli porovnať ruský priemysel so západným priemyslom. Ak porovnáme priamo, vidíme, že máme menej profilov a sú medzi sebou trochu viac zmiešané, hranice sú trochu rozmazanejšie:

Naši elitní umelci sú skrytí medzi vysokovýkonnými umelcami, ale sú tam - sú to elitní, jednorožci, ktorí dosiahli významné výšky. V Rusku ešte nie je rozdiel medzi profilom Elite a profilom High dostatočne výrazný. Myslíme si, že v budúcnosti k tomuto oddeleniu dôjde v dôsledku nárastu inžinierskej kultúry, kvality implementácie inžinierskych postupov a odbornosti v rámci spoločností.

Ak prejdeme k priamemu porovnaniu v rámci ruského priemyslu, vidíme, že High profile tímy sú lepšie vo všetkých ohľadoch. Potvrdili sme tiež našu hypotézu, že medzi týmito metrikami a výkonnosťou organizácie existuje vzťah: Vysoko profilované tímy s väčšou pravdepodobnosťou nielen dosiahnu ciele, ale ich aj prekročia.
Staňme sa vysokoprofilovými tímami a nezastavme sa tam:

Tento rok je však výnimočný a rozhodli sme sa skontrolovať, ako sa spoločnostiam darí v pandémii: Vysoko profilované tímy sú na tom oveľa lepšie a cítia sa lepšie, než je priemer v odvetví:

• 1,5 až 2-krát vyššia pravdepodobnosť vydania nových produktov,
• 2-krát väčšia pravdepodobnosť zlepšenia spoľahlivosti a/alebo výkonu aplikačnej infraštruktúry.

To znamená, že kompetencie, ktoré už mali, im pomohli rýchlejšie sa rozvíjať, uvádzať na trh nové produkty, upravovať existujúce produkty, čím si podmanili nové trhy a nových používateľov:

Čo ešte pomohlo našim tímom?

Inžinierske postupy

Poviem vám o významných zisteniach pre každú prax, ktorú sme testovali. Možno ešte niečo pomohlo tímom, ale hovoríme o DevOps. A v rámci DevOps vidíme rozdiel medzi tímami rôznych profilov.

Platforma ako služba

Nenašli sme významný vzťah medzi vekom platformy a profilom tímu: Platformy sa objavili približne v rovnakom čase pre nízke aj vysoké tímy. Pre tých druhých však platforma poskytuje v priemere viac služieb a viac programovacích rozhraní na ovládanie prostredníctvom programového kódu. A platformové tímy budú s väčšou pravdepodobnosťou pomáhať svojim vývojárom a tímom používať platformu, častejšie riešiť ich problémy a incidenty súvisiace s platformou a vzdelávať ostatné tímy.

Infraštruktúra ako kód

Všetko je tu celkom štandardné. Našli sme vzťah medzi automatizáciou práce kódu infraštruktúry a množstvom informácií uložených v úložisku infraštruktúry. Príkazy vysokého profilu ukladajú do repozitárov viac informácií: ide o konfiguráciu infraštruktúry, kanál CI/CD, nastavenia prostredia a parametre zostavenia. Tieto informácie ukladajú častejšie, lepšie pracujú s kódom infraštruktúry a automatizujú viac procesov a úloh pre prácu s kódom infraštruktúry.

Zaujímavé je, že v testoch infraštruktúry sme nezaznamenali výrazný rozdiel. Pripisujem to skutočnosti, že tímy s vysokým profilom majú vo všeobecnosti väčšiu automatizáciu testovania. Snáď by sa nemali nechať rozptyľovať samostatne testami infraštruktúry, ale skôr tými testami, ktorými kontrolujú aplikácie a vďaka nim už vidia, čo a kde pokazili.

Integrácia a dodávka

Najnudnejšia sekcia, pretože sme potvrdili, že čím viac automatizácie máte, čím lepšie pracujete s kódom, tým je pravdepodobnejšie, že dosiahnete lepšie výsledky.

architektúra

Chceli sme vidieť, ako mikroslužby ovplyvňujú výkon. V skutočnosti nie, keďže používanie mikroslužieb nie je spojené so zvýšením ukazovateľov výkonnosti. Mikroslužby sa používajú pre vysokoprofilové príkazy aj nízkoprofilové príkazy.

Čo je však dôležité, je to, že pre High-tímy prechod na mikroservisnú architektúru umožňuje samostatne rozvíjať svoje služby a zavádzať ich. Ak architektúra umožňuje vývojárom konať autonómne, bez čakania na niekoho externého v tíme, potom ide o kľúčovú kompetenciu pre zvýšenie rýchlosti. V tomto prípade pomáhajú mikroslužby. A práve ich realizácia nehrá veľkú rolu.

Ako sme to všetko objavili?

Mali sme ambiciózny plán úplne zopakovať metodiku DORA, chýbali nám však zdroje. Ak DORA využíva veľa sponzoringu a ich výskum trvá pol roka, náš prieskum sme urobili v krátkom čase. Chceli sme vybudovať model DevOps, ako to robí DORA, a budeme to robiť aj v budúcnosti. Doteraz sme sa obmedzili na tepelné mapy:

Pozreli sme sa na distribúciu inžinierskych postupov medzi tímy v každom profile a zistili sme, že tímy s vysokým profilom v priemere častejšie používali inžinierske postupy. Viac o tom všetkom si môžete prečítať v našom správa.

Pre zmenu prejdime zo zložitých štatistík na jednoduché.

Čo sme ešte objavili?

Nástroje

Pozorujeme, že väčšinu príkazov používa OS rodiny Linux. Windows je však stále v trende - najmenej štvrtina našich respondentov zaznamenala použitie jednej alebo druhej verzie. Zdá sa, že trh má túto potrebu. Preto môžete tieto kompetencie rozvíjať a robiť prezentácie na konferenciách.

Medzi orchestrátormi to nie je pre nikoho tajomstvo, Kubernetes vedie (52 %). Ďalším v poradí orchestrátorom je Docker Swarm (asi 12%). Najpopulárnejšie CI systémy sú Jenkins a GitLab. Najpopulárnejším systémom na správu konfigurácie je Ansible, po ktorom nasleduje náš milovaný Shell.

Amazon je v súčasnosti popredným poskytovateľom cloud hostingu. Podiel ruskej oblačnosti sa postupne zvyšuje. Budúci rok bude zaujímavé sledovať, ako sa budú cítiť ruskí cloud poskytovatelia, či sa ich podiel na trhu zvýši. Sú, dajú sa použiť, a to je dobré:

Odovzdávam slovo Igorovi, ktorý poskytne ďalšie štatistiky.

Šírenie postupov

Igor Kurochkin: Samostatne sme požiadali respondentov, aby uviedli, ako sú v spoločnosti distribuované uvažované inžinierske postupy. Vo väčšine spoločností existuje zmiešaný prístup pozostávajúci z rôznych vzorov a pilotné projekty sú veľmi obľúbené. Mierny rozdiel sme videli aj medzi profilmi. Zástupcovia vysokého profilu častejšie využívajú model „Iniciatíva zdola“, keď malé tímy špecialistov menia pracovné procesy, nástroje a zdieľajú úspešné postupy s ostatnými tímami. V Medium ide o iniciatívu zhora nadol, ktorá ovplyvňuje celú spoločnosť prostredníctvom vytvárania komunít a centier excelentnosti:

Agile a DevOps

Otázka prepojenia Agile a DevOps je v brandži často diskutovaná. Tento problém je nastolený aj v správe o stave agilnosti za roky 2019/2020, preto sme sa rozhodli porovnať, ako sú vo firmách prepojené aktivity Agile a DevOps. Zistili sme, že DevOps bez Agile je zriedkavý. U polovice respondentov sa rozšírenie Agile začalo oveľa skôr a približne 20 % pozorovalo súčasný začiatok a jedným zo znakov nízkeho profilu bude absencia postupov Agile a DevOps:

Príkazové topológie

Koncom minulého roka knihaTímové topológie“, ktorý navrhuje rámec na popis topológií príkazov. Zaujímalo nás, či je to aplikovateľné na ruské firmy. A položili sme otázku: "Aké vzory nájdete?".

U polovice respondentov sú pozorované tímy infraštruktúry, ako aj samostatné vývojové, testovacie a prevádzkové tímy. Samostatné tímy DevOps zaznamenali 45%, z ktorých zástupcovia High sú bežnejší. Nasledujú multifunkčné tímy, ktoré sú tiež bežnejšie na High. Samostatné príkazy SRE sa zobrazujú v profiloch High, Medium a zriedkavo sa vyskytujú v profile Low:

Pomer DevQaOps

Túto otázku sme videli na FaceBooku od tímlídra tímu platformy Skyeng – zaujímal ho pomer vývojárov, testerov a administrátorov vo firmách. Spýtali sme sa a pozreli sme sa na odpovede založené na profiloch: Vysokoprofiloví zástupcovia majú na každého vývojára menej testovacích a prevádzkových inžinierov:

Plány pre rok 2021

V plánoch na budúci rok respondenti zaznamenali nasledovné aktivity:

Tu si môžete pozrieť prienik s konferenciou DevOps Live 2020. Program sme pozorne preskúmali:

• Infraštruktúra ako produkt
• Transformácia DevOps
• Distribúcia postupov DevOps
• DevSecOps
• Prípadové kluby a diskusie

Čas našej prezentácie však nestačí na pokrytie všetkých tém. Zo zákulisia:

• Platforma ako služba a ako produkt;
• Infraštruktúra ako kód, prostredia a cloudy;
• Nepretržitá integrácia a poskytovanie;
• architektúra;
• vzory DevSecOps;
• Platformové a medzifunkčné tímy.

správa dostali sme objemnú, 50 strán a môžete si ju pozrieť podrobnejšie.

Sčítanie

Dúfame, že náš výskum a správa vás inšpirujú k experimentovaniu s novými prístupmi k vývoju, testovaniu a prevádzke a tiež vám pomôžu orientovať sa, porovnávať sa s ostatnými účastníkmi štúdie a identifikovať oblasti, v ktorých môžete zlepšiť svoje vlastné prístupy.

Výsledky prvej štúdie o stave DevOps v Rusku:

• Kľúčové metriky. Zistili sme, že kľúčové metriky (čas dodania, frekvencia nasadenia, čas obnovy a zlyhania zmien) sú vhodné na analýzu efektívnosti procesov vývoja, testovania a prevádzky.
• Profily Vysoké, Stredné, Nízke. Na základe zozbieraných údajov je možné rozlíšiť štatisticky rozdielne skupiny High, Medium, Low s charakteristickými črtami z hľadiska metrík, praktík, procesov a nástrojov. Zástupcovia vysokého profilu vykazujú lepšie výsledky ako Low. Je pravdepodobnejšie, že dosiahnu a prekročia svoje ciele.
• Ukazovatele, pandémia a plány na rok 2021. Špeciálnym ukazovateľom v tomto roku je, ako sa spoločnosti vysporiadali s pandémiou. Vysokým predstaviteľom sa darilo lepšie, zaznamenali zvýšenú angažovanosť používateľov a hlavnými dôvodmi úspechu boli efektívne vývojové procesy a silná inžinierska kultúra.
• DevOps postupy, nástroje a ich vývoj. Medzi hlavné plány firiem na budúci rok patrí rozvoj praktík a nástrojov DevOps, zavedenie praktík DevSecOps a zmeny v organizačnej štruktúre. A efektívna implementácia a rozvoj postupov DevOps sa uskutočňuje pomocou pilotných projektov, vytvárania komunít a centier excelentnosti, iniciatív na vyšších a nižších úrovniach spoločnosti.

Radi si vypočujeme vašu spätnú väzbu, príbehy, spätnú väzbu. Ďakujeme všetkým, ktorí sa štúdie zúčastnili a tešíme sa na vašu účasť v budúcom roku.

Zdroj: hab.com