Jak porozumět stavu něčeho?
Můžete se spolehnout na svůj názor vytvořený z různých zdrojů informací, například z publikací na webových stránkách nebo ze zkušeností. Můžete se zeptat kolegů, známých. Další možností je podívat se na témata konferencí: programovým výborem jsou aktivní zástupci oboru, takže jim věříme ve výběru relevantních témat. Samostatnou oblastí jsou výzkumy a zprávy. Ale je tu problém. Ve světě se každoročně provádí průzkum stavu DevOps, zprávy vydávají zahraniční společnosti a o ruských DevOps nejsou téměř žádné informace.
Ale přišel den, kdy byla taková studie provedena, a dnes budeme mluvit o výsledcích. Stav DevOps v Rusku zkoumaly společnosti společně “"A"". Express 42 pomáhá technologickým společnostem implementovat a rozvíjet postupy a nástroje DevOps a byl jedním z prvních, kdo o DevOps mluvil v Rusku. Autoři studie Igor Kurochkin a Vitalij Chabarov se v Express 42 zabývají analýzou a poradenstvím, přičemž mají technické zázemí z provozu a zkušenosti v různých společnostech. Za 8 let se kolegové podívali na desítky firem a projektů – od startupů po podniky – s různými problémy, ale i různou kulturní a inženýrskou vyspělostí.
Igor a Vitaly ve své zprávě řekli, jaké problémy byly v procesu výzkumu, jak je vyřešili, a také jak v zásadě probíhá výzkum DevOps a proč se Express 42 rozhodl provést svůj vlastní. Jejich report je k nahlédnutí .
Výzkum DevOps
Rozhovor zahájil Igor Kurochkin.
Pravidelně se ptáme publika na konferencích DevOps: „Četli jste zprávu o stavu DevOps za tento rok? Málokdo zvedne ruce a naše studie ukázala, že je studuje pouze třetina. Pokud jste takové zprávy ještě neviděli, řekněme rovnou, že jsou si všechny velmi podobné. Nejčastěji se objevují fráze jako: "Ve srovnání s minulým rokem ..."
Zde máme první problém a po něm další dva:
- Údaje za loňský rok nemáme. Stav DevOps v Rusku nikoho nezajímá;
- Metodologie. Není jasné, jak testovat hypotézy, jak vytvářet otázky, jak analyzovat, porovnávat výsledky, nacházet souvislosti;
- Terminologie. Všechny reporty jsou v angličtině, je nutný překlad, společný framework DevOps ještě nebyl vynalezen a každý si přijde na své.
Pojďme se podívat na to, jak byly analýzy stavu DevOps prováděny po celém světě.
Historické informace
Výzkum DevOps se provádí od roku 2011. Jako první je provedl Puppet, vývojář systémů pro správu konfigurace. V té době to byl jeden z hlavních nástrojů pro popis infrastruktury ve formě kódu. Do roku 2013 byly tyto studie pouze uzavřenými průzkumy a žádnými veřejnými zprávami.
V roce 2013 se objevila společnost IT Revolution, vydavatel všech hlavních knih o DevOps. Společně s Puppet připravili první publikaci State of DevOps, kde se poprvé objevily 4 klíčové metriky. Následující rok se zapojila ThoughtWorks, konzultační firma známá svými pravidelnými technologickými radary o průmyslových postupech a nástrojích. A v roce 2015 přibyla sekce s metodikou a bylo jasné, jak tu analýzu provádějí.
V roce 2016 autoři studie po vytvoření vlastní společnosti DORA (DevOps Research and Assessment) zveřejnili výroční zprávu. Následující rok vydala DORA a Puppet svou poslední společnou zprávu.
A pak začalo něco zajímavého:
V roce 2018 se společnosti rozdělily a byly vydány dvě nezávislé zprávy: jedna od Puppet, druhá od DORA společně s Googlem. DORA nadále využívá svou metodologii pomocí klíčových metrik, výkonnostních profilů a technických postupů, které ovlivňují klíčové metriky a celopodnikový výkon. A Puppet nabídl svůj vlastní přístup s popisem procesu a vývoje DevOps. Příběh se ale neujal, v roce 2019 Puppet tuto metodiku opustil a vydal novou verzi reportů, která uváděla klíčové praktiky a jak ovlivňují DevOps z jejich pohledu. Pak se stala další událost: Google koupil DORA a společně vydali další zprávu. Možná jste ho viděli.
Letos se věci zkomplikovaly. Je známo, že Puppet spustil vlastní průzkum. Udělali to o týden dříve než my a už to skončilo. Zúčastnili jsme se toho a podívali se, jaká témata je zajímají. Nyní Puppet provádí analýzu a připravuje zveřejnění zprávy.
Stále však neexistuje žádné oznámení od společností DORA a Google. V květnu, kdy průzkum obvykle začínal, přišla informace, že Nicole Forsgren, jedna ze zakladatelek DORA, přešla do jiné společnosti. Proto jsme předpokládali, že letos žádný výzkum a zpráva od DORA nebude.
Jak je to v Rusku?
Nedělali jsme průzkum DevOps. Mluvili jsme na konferencích, převyprávěli poznatky jiných lidí a Raiffeisenbank přeložila „State of DevOps“ pro rok 2019 (jejich oznámení najdete na Habré), za což jim patří velké díky. A to je všechno.
Proto jsme provedli vlastní výzkum v Rusku s využitím metodik a zjištění DORA. Pro náš výzkum, včetně synchronizace terminologie a překladu, jsme použili zprávu kolegů z Raiffeisenbank. A otázky týkající se odvětví byly převzaty ze zpráv DORA a letošního dotazníku Puppet.
Výzkumný proces
Zpráva je pouze závěrečnou částí. Celý výzkumný proces se skládá ze čtyř hlavních kroků:
Během přípravné fáze jsme vyzpovídali odborníky z oboru a připravili seznam hypotéz. Na jejich základě byly sestaveny otázky a spuštěna anketa na celý srpen. Poté jsme analyzovali a připravili samotnou zprávu. U DORA tento proces trvá 6 měsíců. Setkali jsme se během 3 měsíců a nyní chápeme, že jsme měli sotva dost času: pouze provedením analýzy pochopíte, jaké otázky musíte položit.
Účastníci
Všechny zahraniční zprávy začínají portrétem účastníků a většina z nich není z Ruska. Procento ruských respondentů se rok od roku pohybuje od 5 do 1 %, což neumožňuje vyvozovat žádné závěry.
Mapa ze zprávy Accelerate State of DevOps 2019:
V naší studii se nám podařilo vyzpovídat 889 lidí – to je poměrně hodně (DORA ročně ve svých zprávách anketuje asi tisíc lidí) a zde jsme dosáhli cíle:
Je pravda, že ne všichni naši účastníci dosáhli konce: procento dokončení se ukázalo být o něco méně než polovina. Ale i to stačilo k získání reprezentativního vzorku a provedení analýzy. DORA ve svých přehledech neuvádí procenta plnění, takže zde není žádné srovnání.
Odvětví a pozice
Naši respondenti zastupují tucet odvětví. Poloviční práce v informačních technologiích. Následují finanční služby, obchod, telekomunikace a další. Mezi pozicemi jsou specialisté (vývojář, tester, provozní inženýr) a řídící pracovníci (vedoucí týmů, skupin, oblastí, ředitelé):
Každý druhý pracuje pro středně velkou firmu. Každý třetí člověk pracuje ve velkých společnostech. Většina pracuje v týmech do 9 lidí. Samostatně jsme se zeptali na hlavní činnosti a většina z nich nějak souvisí s provozem a asi 40 % se zabývá vývojem:
Shromáždili jsme tedy informace pro srovnání a analýzu zástupců různých odvětví, společností, týmů. Můj kolega Vitalij Chabarov bude vyprávět o analýze.
Analýza a srovnání
Vitaly Khabarov: Mnohokrát děkujeme všem účastníkům, kteří dokončili náš průzkum, vyplnili dotazníky a poskytli nám data pro další analýzu a testování našich hypotéz. A díky našim klientům a zákazníkům máme bohaté zkušenosti, které nám pomohly identifikovat obavy odvětví a formulovat hypotézy, které jsme testovali v našem výzkumu.
Bohužel si nemůžete vzít seznam otázek na jednu stranu a data na druhou, nějak je porovnat, říct: „Ano, všechno tak funguje, měli jsme pravdu“ a rozejít se. Ne, potřebujeme metodologii a statistické metody, abychom si byli jisti, že se nemýlíme a naše závěry jsou spolehlivé. Pak můžeme naši další práci stavět na těchto datech:
Klíčové metriky
Jako základ jsme vzali metodiku DORA, kterou podrobně popsali v knize „Accelerate State of DevOps“. Ověřili jsme, zda jsou klíčové metriky vhodné pro ruský trh, zda je lze použít stejným způsobem, jakým DORA odpovídá na otázku: „Jak průmysl v Rusku odpovídá zahraničnímu průmyslu?“
Klíčové metriky:
- Frekvence nasazení. Jak často se nová verze aplikace nasazuje do produkčního prostředí (plánované změny, vyjma oprav hotfix a reakce na incidenty)?
- Čas doručení. Jaká je průměrná doba mezi provedením změny (zapsáním funkce jako kódu) a nasazením změny do produkčního prostředí?
- Doba rekonvalescence. Jak dlouho v průměru trvá obnovení aplikace do produkčního prostředí po incidentu, degradaci služby nebo zjištění chyby, která ovlivňuje uživatele aplikace?
- Neúspěšné změny. Jaké procento nasazení v produkčním prostředí vede k degradaci aplikace nebo incidentům a vyžaduje nápravu (vrácení změn, vývoj opravy hotfix nebo opravy)?
DORA ve svém výzkumu našla souvislost mezi těmito metrikami a výkonností organizace. Testujeme to i v naší studii.
Ale abyste se ujistili, že čtyři klíčové metriky mohou něco ovlivnit, musíte pochopit – souvisí spolu nějak? DORA odpověděla kladně s jednou výhradou: vztah mezi neúspěšnými změnami (Change Failure Rate) a třemi dalšími metrikami je o něco slabší. Dostali jsme zhruba stejný obrázek. Pokud spolu čas dodání, frekvence nasazení a doba zotavení korelují (tuto korelaci jsme stanovili pomocí Pearsonovy korelace a pomocí Chaddockovy škály), pak neexistuje žádná tak silná korelace s neúspěšnými změnami.
V zásadě většina respondentů odpovídá, že mají ve výrobě spíše malý počet incidentů. I když později uvidíme, že mezi skupinami respondentů je stále značný rozdíl z hlediska neúspěšných změn, zatím tuto metriku pro toto rozdělení nemůžeme použít.
Přičítáme to tomu, že (jak se ukázalo při analýze a komunikaci s některými našimi zákazníky) je mírný rozdíl ve vnímání toho, co je považováno za incident. Pokud se nám během technického okna podařilo obnovit výkon naší služby, lze to považovat za incident? Asi ne, protože jsme vše opravili, jsme skvělí. Můžeme považovat za incident, pokud jsme museli naši aplikaci 10krát přetočit v normálním, pro nás známém režimu? Zdá se, že ne. Proto zůstává otázka vztahu neúspěšných změn s ostatními metrikami otevřená. Budeme to dále upřesňovat.
Zde je důležité, že jsme našli významnou korelaci mezi dodacími lhůtami, dobou obnovy a frekvencí nasazení. Proto jsme použili tyto tři metriky, abychom dále rozdělili respondenty do výkonnostních skupin.
Kolik stojí v gramech?
Použili jsme hierarchickou shlukovou analýzu:
- Respondenty rozmístíme po n-rozměrném prostoru, kde souřadnicí každého respondenta jsou jeho odpovědi na otázky.
- Každý respondent je prohlášen za malý shluk.
- Spojíme dva shluky nejblíže k sobě do jednoho většího shluku.
- Najdeme další pár shluků a spojíme je do většího shluku.
Takto seskupujeme všechny naše respondenty do počtu shluků, které potřebujeme. Pomocí dendrogramu (stromu vazeb mezi shluky) vidíme vzdálenost mezi dvěma sousedními shluky. Nezbývá nám, než stanovit mezi těmito shluky určitou hranici vzdálenosti a říci: "Tyto dvě skupiny jsou od sebe docela odlišitelné, protože vzdálenost mezi nimi je gigantická."
Je zde ale skrytý problém: nemáme žádná omezení na počet shluků – můžeme získat 2, 3, 4, 10 shluků. A první nápad byl – proč nerozdělit všechny naše respondenty do 4 skupin, jak to dělá DORA. Zjistili jsme ale, že rozdíly mezi těmito skupinami se stávají nevýznamnými a nemůžeme si být jisti, že respondent skutečně patří do své skupiny, a ne do té sousední. Ruský trh zatím nemůžeme rozdělit do čtyř skupin. Proto jsme se rozhodli pro tři profily, mezi kterými je statisticky významný rozdíl:
Dále jsme určili profil podle shluků: vzali jsme medián pro každou metriku pro každou skupinu a sestavili jsme tabulku profilů výkonu. Ve skutečnosti jsme získali výkonnostní profily průměrného účastníka v každé skupině. Identifikovali jsme tři profily účinnosti: Nízká, Střední, Vysoká:
Zde jsme potvrdili naši hypotézu, že pro určení výkonnostního profilu jsou vhodné 4 klíčové metriky, které fungují na západním i ruském trhu. Mezi skupinami je rozdíl a je statisticky významný. Zdůrazňuji, že mezi výkonnostními profily je významný rozdíl z hlediska metriky neúspěšných změn z hlediska průměru, i když jsme původně respondenty tímto parametrem nerozdělovali.
Pak vyvstává otázka: jak to všechno využít?
Jak používat
Pokud vezmeme jakýkoli tým, 4 klíčové metriky a aplikujeme je na tabulku, pak v 85 % případů nezískáme kompletní zápas – jedná se pouze o průměrného účastníka a ne o to, co je ve skutečnosti. Každý jsme (a každý tým) trochu jiný.
Zkontrolovali jsme: vzali jsme naše respondenty a výkonnostní profil DORA a podívali jsme se, kolik respondentů odpovídá tomu či onomu profilu. Zjistili jsme, že pouze 16 % respondentů rozhodně spadalo do některého z profilů. Všechny ostatní jsou rozptýleny někde mezi:
To znamená, že profil účinnosti má omezený rozsah. Abyste pochopili, kde jste v prvním přiblížení, můžete použít tuto tabulku: „Ach, zdá se, že jsme blíže střední nebo vysoké!“ Pokud pochopíte, kam jít dál, může to stačit. Ale pokud je vaším cílem neustálé neustálé zlepšování a chcete přesněji vědět, kde se vyvíjet a co dělat, pak jsou potřeba další finanční prostředky. Říkali jsme jim kalkulačky:
- Kalkulačka DORA
- Calculator Express 42* (ve vývoji)
- Vlastní vývoj (můžete si vytvořit vlastní interní kalkulačku).
K čemu jsou potřeba? Rozumět:
- Odpovídá tým v naší organizaci našim standardům?
- Pokud ne, můžeme tomu pomoci, urychlit to v rámci odbornosti, kterou naše společnost má?
- Pokud ano, můžeme to udělat ještě lépe?
Můžete je také použít ke sběru statistik v rámci společnosti:
- Jaké týmy máme?
- Rozdělte týmy do profilů;
- Viz: Ach, tyto příkazy mají nedostatečnou výkonnost (nevytahují se málo), ale jsou skvělé: nasazují se každý den, bez chyb, mají dobu přípravy méně než hodinu.
A pak můžete zjistit, že v naší společnosti jsou potřebné odborné znalosti a nástroje pro ty týmy, které ještě nejsou na úrovni.
Nebo, pokud pochopíte, že se ve společnosti cítíte skvěle, jste lepší než mnozí, pak můžete vypadat trochu širší. To je jen ruský průmysl: můžeme získat potřebné odborné znalosti v ruském průmyslu, abychom se zrychlili? Zde pomůže kalkulačka Express 42 (je ve vývoji). Pokud jste přerostli ruský trh, pak se podívejte a na světový trh.
Pokuta. A pokud jste ve skupině Elit na kalkulačce DORA, co byste měli udělat? Tady žádné dobré řešení neexistuje. S největší pravděpodobností jste v popředí oboru a další zrychlení a spolehlivost je možná prostřednictvím interního výzkumu a vývoje a vynaložením více zdrojů.
Přejděme k tomu nejmilejšímu – přirovnání.
Porovnání
Původně jsme chtěli porovnat ruský průmysl se západním průmyslem. Pokud porovnáme přímo, vidíme, že máme méně profilů a jsou mezi sebou trochu více smíšené, hranice jsou trochu rozmazanější:
Naši elitní umělci jsou skryti mezi vysoce výkonnými, ale jsou tam - to jsou elitní, jednorožci, kteří dosáhli významných výšin. V Rusku není rozdíl mezi Elite profilem a High profilem zatím dostatečně výrazný. Myslíme si, že v budoucnu k tomuto oddělení dojde díky nárůstu inženýrské kultury, kvality implementace inženýrských postupů a odbornosti v rámci společností.
Pokud přejdeme k přímému srovnání v rámci ruského průmyslu, vidíme, že High profile týmy jsou ve všech ohledech lepší. Potvrdili jsme také naši hypotézu, že mezi těmito metrikami a výkonností organizace existuje vztah: Vysoce profilované týmy mnohem pravděpodobněji nejen dosáhnou cílů, ale také je překročí.
Staňme se vysoce profilovanými týmy a nezastavme se u toho:
Tento rok je ale výjimečný a rozhodli jsme se zkontrolovat, jak si společnosti vedou v pandemii: Vysoce profilované týmy si vedou mnohem lépe a cítí se lépe, než je průměr v oboru:
- 1,5–2krát vyšší pravděpodobnost vydání nových produktů,
- 2krát vyšší pravděpodobnost zlepšení spolehlivosti a/nebo výkonu aplikační infrastruktury.
To znamená, že kompetence, které již měli, jim pomohly vyvinout se rychleji, uvést na trh nové produkty, upravit stávající produkty, a tím dobývat nové trhy a nové uživatele:
Co ještě pomohlo našim týmům?
Inženýrské postupy
Řeknu vám o významných zjištěních pro každou praxi, kterou jsme testovali. Možná týmům pomohlo něco jiného, ale my mluvíme o DevOps. A v rámci DevOps vidíme rozdíl mezi týmy různých profilů.
Platforma jako služba
Nenašli jsme významný vztah mezi věkem platformy a profilem týmu: Platformy se objevily přibližně ve stejnou dobu pro nízké i vysoké týmy. Pro ty druhé však platforma poskytuje v průměru více služeb a více programovacích rozhraní pro ovládání pomocí programového kódu. A platformové týmy budou s větší pravděpodobností pomáhat svým vývojářům a týmům používat platformu, častěji řešit jejich problémy a incidenty související s platformou a vzdělávat další týmy.
Infrastruktura jako kód
Všechno je zde docela standardní. Našli jsme vztah mezi automatizací práce kódu infrastruktury a množstvím informací uložených v úložišti infrastruktury. Příkazy High profile ukládají do úložišť více informací: jedná se o konfiguraci infrastruktury, kanál CI/CD, nastavení prostředí a parametry sestavení. Ukládají tyto informace častěji, lépe pracují s kódem infrastruktury a automatizují více procesů a úloh pro práci s kódem infrastruktury.
Zajímavé je, že jsme nezaznamenali výrazný rozdíl v testech infrastruktury. Přičítám to skutečnosti, že týmy s vysokým profilem mají obecně větší automatizaci testování. Snad by je neměly rozptylovat samostatně testy infrastruktury, ale spíše ty testy, kterými kontrolují aplikace, a díky nim už vidí, co a kde rozbili.
Integrace a dodání
Nejnudnější sekce, protože jsme si potvrdili, že čím více automatizace máte, čím lépe pracujete s kódem, tím je pravděpodobnější, že dosáhnete lepších výsledků.
architektura
Chtěli jsme vidět, jak mikroslužby ovlivňují výkon. Ve skutečnosti nemají, protože používání mikroslužeb není spojeno se zvýšením ukazatelů výkonu. Mikroslužby se používají jak pro příkazy s vysokým profilem, tak pro příkazy s nízkým profilem.
Co je však důležité, je to, že High-týmům přechod na mikroservisní architekturu umožňuje samostatně rozvíjet své služby a zavádět je. Pokud architektura umožňuje vývojářům jednat autonomně, aniž by čekali na někoho mimo tým, pak je to klíčová kompetence pro zvýšení rychlosti. V tomto případě pomáhají mikroslužby. A právě jejich realizace nehraje velkou roli.
Jak jsme to všechno objevili?
Měli jsme ambiciózní plán plně replikovat metodiku DORA, ale chyběly nám zdroje. Pokud DORA využívá hodně sponzoringu a jejich výzkum trvá půl roku, udělali jsme náš výzkum v krátké době. Chtěli jsme vytvořit model DevOps, jako to dělá DORA, a v budoucnu to uděláme. Doposud jsme se omezili na tepelné mapy:
Podívali jsme se na rozložení inženýrských postupů mezi týmy v každém profilu a zjistili jsme, že vysoce profilované týmy v průměru častěji používají inženýrské postupy. Více o tom všem si můžete přečíst v našem .
Přejděme pro změnu od složitých statistik k těm jednoduchým.
Co dalšího jsme objevili?
Nástroje
Pozorujeme, že většinu příkazů používá OS rodiny Linux. Ale Windows je stále v trendu - nejméně čtvrtina našich respondentů zaznamenala použití jedné nebo druhé z jeho verzí. Zdá se, že trh tuto potřebu má. Proto můžete tyto kompetence rozvíjet a prezentovat na konferencích.
Mezi orchestrátory to není pro nikoho tajemstvím, Kubernetes vede (52 %). Dalším orchestrátorem v řadě je Docker Swarm (asi 12 %). Nejoblíbenější CI systémy jsou Jenkins a GitLab. Nejoblíbenějším systémem pro správu konfigurace je Ansible, následovaný naším milovaným Shellem.
Amazon je v současnosti předním poskytovatelem cloudového hostingu. Podíl ruské oblačnosti se postupně zvyšuje. V příštím roce bude zajímavé sledovat, jak se budou cítit ruští cloud poskytovatelé, zda se jejich podíl na trhu zvýší. Jsou, dají se použít, a to je dobře:
Předám slovo Igorovi, který podá další statistiky.
Šíření praktik
Igor Kurochkin: Samostatně jsme požádali respondenty, aby uvedli, jak jsou uvažované inženýrské postupy ve společnosti distribuovány. Ve většině společností existuje smíšený přístup, který se skládá z odlišné sady vzorů, a pilotní projekty jsou velmi oblíbené. Mezi profily jsme také viděli nepatrný rozdíl. Zástupci High profile častěji využívají vzor „Iniciativa zdola“, kdy malé týmy specialistů mění pracovní procesy, nástroje a sdílejí úspěšné postupy s ostatními týmy. Ve společnosti Medium se jedná o iniciativu shora dolů, která ovlivňuje celou společnost prostřednictvím vytváření komunit a center excelence:
Agile a DevOps
Otázka propojení Agile a DevOps je v branži často diskutovaná. Tento problém je nastolen i ve zprávě o stavu Agile za rok 2019/2020, proto jsme se rozhodli porovnat, jak jsou ve firmách propojeny aktivity Agile a DevOps. Zjistili jsme, že DevOps bez Agile je vzácné. U poloviny respondentů začalo šíření Agile mnohem dříve a přibližně 20 % pozorovalo současný začátek a jedním z příznaků nízkého profilu bude absence postupů Agile a DevOps:
Topologie příkazů
Na konci loňského roku vyšla kniha „“, který navrhuje rámec pro popis topologií příkazů. Pro nás začalo být zajímavé, zda je použitelná pro ruské firmy. A položili jsme otázku: "Jaké vzory nacházíte?".
U poloviny respondentů jsou pozorovány infrastrukturní týmy a také samostatné týmy pro vývoj, testování a provoz. Samostatné týmy DevOps zaznamenaly 45 %, mezi nimiž jsou běžnější zástupci High. Dále následují mezifunkční týmy, které jsou na High také běžnější. Samostatné příkazy SRE se objevují v profilech High, Medium a zřídka se vyskytují v profilu Low:
Poměr DevQaOps
Tuto otázku jsme viděli na FaceBooku od team leadera týmu platformy Skyeng – zajímal ho poměr vývojářů, testerů a administrátorů ve firmách. Zeptali jsme se a podívali jsme se na odpovědi na základě profilů: Vysoce profiloví zástupci mají na každého vývojáře méně testovacích a provozních inženýrů:
Plány pro rok 2021
V plánech na příští rok respondenti zaznamenali tyto aktivity:
Zde můžete vidět průnik s konferencí DevOps Live 2020. Program jsme pečlivě zkontrolovali:
- Infrastruktura jako produkt
- Transformace DevOps
- Distribuce postupů DevOps
- DevSecOps
- Případové kluby a diskuze
Čas naší prezentace ale nestačí na pokrytí všech témat. V zákulisí:
- Platforma jako služba a jako produkt;
- Infrastruktura jako kód, prostředí a cloudy;
- Průběžná integrace a poskytování;
- Architektura;
- vzory DevSecOps;
- Platformové a mezifunkční týmy.
dostali jsme objemných 50 stran a můžete si to prohlédnout podrobněji.
Sčítání
Doufáme, že náš výzkum a zpráva vás inspirují k experimentování s novými přístupy k vývoji, testování a provozu a také vám pomohou orientovat se, porovnávat se s ostatními účastníky studie a identifikovat oblasti, kde můžete zlepšit své vlastní přístupy.
Výsledky první studie stavu DevOps v Rusku:
- Klíčové metriky. Zjistili jsme, že klíčové metriky (doba dodání, frekvence nasazení, doba obnovy a selhání změn) jsou vhodné pro analýzu efektivity vývojových, testovacích a provozních procesů.
- Profily Vysoké, Střední, Nízké. Na základě shromážděných dat můžeme rozlišit statisticky odlišné skupiny High, Medium, Low s charakteristickými rysy z hlediska metrik, praktik, procesů a nástrojů. Zástupci profilu High vykazují lepší výsledky než Low. S větší pravděpodobností dosáhnou a překročí své cíle.
- Ukazatele, pandemie a plány na rok 2021. Zvláštním ukazatelem letošního roku je, jak se firmy s pandemií vypořádaly. Vysokým zástupcům se dařilo lépe, zaznamenali větší zapojení uživatelů a hlavními důvody úspěchu byly efektivní vývojové procesy a silná inženýrská kultura.
- DevOps postupy, nástroje a jejich vývoj. Mezi hlavní plány firem na příští rok patří rozvoj DevOps praktik a nástrojů, zavedení DevSecOps praktik a změny v organizační struktuře. A efektivní implementace a rozvoj postupů DevOps se provádí pomocí pilotních projektů, vytváření komunit a center excelence, iniciativ na vyšších a nižších úrovních společnosti.
Rádi bychom slyšeli vaše názory, příběhy, zpětnou vazbu. Děkujeme všem, kteří se studie zúčastnili a těšíme se na vaši účast v příštím roce.
Zdroj: www.habr.com