Состојба на DevOps во Русија 2020 година

Како воопшто ја разбираш состојбата на нешто?

Можете да се потпрете на вашето мислење, формирано од различни извори на информации, на пример, публикации на веб-страници или искуство. Можете да прашате колеги, познаници. Друга опција е да се разгледаат темите на конференциите: програмскиот комитет се активни претставници на индустријата, па затоа им веруваме во изборот на релевантни теми. Посебна област се истражувањата и извештаите. Но, постои проблем. Истражувањата за состојбата на DevOps се спроведуваат годишно во светот, извештаите се објавуваат од странски компании, а речиси и да нема информации за руските DevOps.

Но, дојде денот кога беше спроведена таква студија, а денес ќе зборуваме за резултатите. Состојбата на DevOps во Русија беше проучувана заеднички од компаниите "Експрес 42"И"Онтико“. Express 42 им помага на технолошките компании да ги имплементираат и развиваат практиките и алатките на DevOps и беше еден од првите што зборуваше за DevOps во Русија. Авторите на студијата, Игор Курочкин и Виталиј Хабаров, се занимаваат со анализа и консултации во Експрес 42, додека имаат техничка позадина од работењето и искуство во различни компании. За 8 години, колегите разгледуваа десетици компании и проекти - од стартап до претпријатија - со различни проблеми, како и со различна културна и инженерска зрелост.

Во својот извештај, Игор и Виталиј раскажаа какви проблеми имало во процесот на истражување, како ги решиле, како и како во принцип се спроведува истражувањето на DevOps и зошто Express 42 одлучил да го спроведе своето. Нивниот извештај може да се види тука.

Истражување на DevOps

Разговорот го започна Игор Курочкин.

Редовно ја прашуваме публиката на конференциите на DevOps: „Дали го прочитавте извештајот за статусот на DevOps за оваа година? Малкумина креваат раце, а нашата студија покажа дека само една третина ги проучува. Ако никогаш не сте виделе такви извештаи, веднаш да кажеме дека сите се многу слични. Најчесто има фрази како: „Во споредба со минатата година ...“

Тука го имаме првиот проблем, а после него уште два:

1. Немаме податоци за минатата година. Никој не е заинтересиран за состојбата на DevOps во Русија;
2. Методологија. Не е јасно како да се тестираат хипотези, како да се градат прашања, како да се анализираат, споредуваат резултати, да се најдат врски;
3. Терминологија. Сите извештаи се на англиски, потребен е превод, сè уште не е измислена заедничка рамка за DevOps и секој доаѓа со своја.

Ајде да погледнеме како генерално се вршеа анализи на состојбата на DevOps во светот.

историја

Истражувањето на DevOps се спроведува од 2011 година. Првиот што ги спроведе беше Puppet, развивач на системи за управување со конфигурации. Во тоа време, тоа беше една од главните алатки за опишување на инфраструктурата во форма на код. До 2013 година овие студии беа само анкети во затворен формат и без јавно известување.

Во 2013 година се појави IT Revolution, издавач на сите главни книги за DevOps. Заедно со Puppet, тие ја подготвија првата публикација State of DevOps, каде за прв пат се појавија 4 клучни метрики. Следната година, ThoughtWorks, консултантска фирма позната по своите редовни технолошки радари за индустриски практики и алатки, се вклучи. И во 2015 година додаден е дел со методологија и стана јасно како ја вршат анализата.

Во 2016 година, авторите на студијата, откако создадоа сопствена компанија DORA (DevOps Research and Assessment), објавија годишен извештај. Следната година, DORA и Puppet го објавија својот последен заеднички извештај.

И тогаш започна нешто интересно:

Во 2018 година, компаниите се разделија и беа објавени два независни извештаи: еден од Puppet, вториот од DORA заедно со Google. DORA продолжи да ја користи својата методологија со клучни метрики, профили на перформанси и инженерски практики кои влијаат на клучните метрики и перформансите на целата компанија. И Puppet понуди свој пристап со опис на процесот и еволуцијата на DevOps. Но, приказната не се вкорени, во 2019 година Puppet ја напушти оваа методологија и објави нова верзија на извештаите, во која се наведени клучните практики и како тие влијаат на DevOps од нивна гледна точка. Потоа се случи уште еден настан: Google ја купи DORA и заедно објавија уште еден извештај. Можеби сте го виделе.

Оваа година работите се искомплицираа. Познато е дека Puppet започна сопствена анкета. Го направија тоа една недела порано од нас, а веќе заврши. Учествувавме во него и погледнавме кои теми ги интересираат. Puppet сега ја врши својата анализа и се подготвува да го објави извештајот.

Но се уште нема најава од DORA и Google. Во мај, кога вообичаено започнуваше анкетата, дојде информација дека Никол Форсгрен, една од основачите на DORA, се преселила во друга компанија. Затоа, претпоставувавме дека оваа година нема да има истражување и извештај од ДОРА.

Како стојат работите во Русија?

Не сме направиле истражување за DevOps. Зборувавме на конференции, прераскажувајќи ги туѓите наоди, а Рајфајзенбанк ја преведе „Состојба на DevOps“ за 2019 година (нивната објава можете да ја најдете на Хабре), многу благодарност до нив. И тоа е се.

Затоа, ние спроведовме сопствено истражување во Русија користејќи ги методологиите и наодите на DORA. Го користевме извештајот на колегите од Рајфајзенбанк за нашето истражување, вклучително и за синхронизирање на терминологијата и преводот. А прашањата релевантни за индустријата беа преземени од извештаите на DORA и овогодинешниот прашалник за кукли.

Истражувачки процес

Извештајот е само последниот дел. Целиот процес на истражување се состои од четири главни чекори:

За време на подготвителната фаза, интервјуиравме експерти од индустријата и подготвивме листа на хипотези. На нивна основа беа составени прашања и беше спроведена анкета за цел август. Потоа го анализиравме и го подготвивме самиот извештај. За DORA овој процес трае 6 месеци. Се сретнавме во рок од 3 месеци и сега разбираме дека едвај ни беше доволно време: само со извршување на анализата разбирате кои прашања треба да ги поставите.

Учесниците

Сите странски извештаи започнуваат со портрет на учесниците, а повеќето од нив не се од Русија. Процентот на руски испитаници варира од 5 до 1% од година во година, а тоа не дозволува да се извлечат никакви заклучоци.

Карта од извештајот за забрзана состојба на DevOps 2019:

Во нашата студија, успеавме да интервјуираме 889 луѓе - тоа е доста (ДОРА анкетира околу илјада луѓе годишно во своите извештаи) и еве ја постигнавме целта:

Точно, не сите наши учесници стигнаа до крајот: процентот на завршување беше нешто помалку од половина. Но, ова беше доволно за да се добие репрезентативен примерок и да се спроведе анализа. DORA не ги открива стапките на искористеност во своите извештаи, така што овде не може да се прават споредби.

Индустрии и позиции

Нашите испитаници претставуваат десетина индустрии. Половина работа во информатичка технологија. Потоа следат финансиските услуги, трговијата, телекомуникациите и други. Меѓу позициите се специјалисти (програмер, тестер, оперативен инженер) и менаџерски персонал (шефови на тимови, групи, области, директори):

Секој втор човек работи во компанија со средна големина. Секој трет човек работи во големи компании. Повеќето работат во тимови до 9 луѓе. Одделно, прашавме за главните активности, а мнозинството се на еден или друг начин поврзани со работењето, а околу 40% се вклучени во развојот:

Така, собравме информации за споредба и анализа на претставници од различни индустрии, компании, тимови. За анализата ќе каже мојот колега Виталиј Хабаров.

Анализа и споредба

Виталиј Хабаров: Голема благодарност до сите учесници кои ја завршија нашата анкета, пополнија прашалници и ни дадоа податоци за понатамошна анализа и тестирање на нашите хипотези. И благодарение на нашите клиенти и клиенти, имаме богато искуство што помогна да се идентификуваат проблемите во индустријата и да се формулираат хипотезите што ги тестиравме во нашето истражување.

За жал, не можете само да земете список со прашања од една страна и податоци од друга, некако да ги споредувате, да кажете: „Да, сè функционира така, бевме во право“ и да се растурате. Не, потребна е методологија и статистички методи за да бидеме сигурни дека не грешиме и дека нашите заклучоци се веродостојни. Потоа можеме да ја изградиме нашата понатамошна работа врз основа на овие податоци:

Клучни метрики

Како основа ја зедовме методологијата DORA, која детално ја опишаа во книгата „Забрзување на состојбата на DevOps“. Проверивме дали клучните метрики се погодни за рускиот пазар, дали може да се користат на ист начин како што користи DORA за да одговори на прашањето: „Како индустријата во Русија кореспондира со странската индустрија?

Клучни метрики:

1. Фреквенција на распоредување. Колку често новата верзија на апликацијата се распоредува во производствената средина (планирани промени, со исклучок на жешки поправки и одговор на инцидентот)?
2. Време на испорака. Колкаво е просечното време помеѓу извршувањето на промената (запишување на функционалноста како код) и примената на промената во производната средина?
3. Време на опоравување. Колку време е потребно во просек да се врати апликацијата во производствена средина по инцидент, деградација на услугата или откривање на грешка што влијае на корисниците на апликацијата?
4. Неуспешни промени. Колкав процент од распоредувањата во производствената средина доведуваат до деградација на апликацијата или инциденти и бараат санација (враќање на промените, развој на жешка поправка или лепенка)?

Истражувањето на DORA откри врска помеѓу овие метрики и организациските перформанси. Ние го проверуваме и во нашата студија.

Но, за да бидете сигурни дека четирите клучни метрики можат да влијаат на нешто, треба да разберете - дали тие се некако поврзани едни со други? DORA одговори потврдно со едно предупредување: врската помеѓу неуспешните промени (Change Failure Rate) и три други метрики е малку послаба. Ја добивме приближно истата слика. Ако времето на испорака, фреквенцијата на распоредување и времето за обновување корелираат едни со други (оваа корелација ја воспоставивме преку корелацијата Пирсон и преку скалата на Чадок), тогаш не постои таква силна корелација со неуспешните промени.

Во принцип, повеќето од испитаниците имаат тенденција да одговорат дека имаат прилично мал број инциденти во производството. Иако подоцна ќе видиме дека сè уште постои значајна разлика помеѓу групите испитаници во однос на неуспешни промени, сè уште не можеме да ја користиме оваа метрика за оваа поделба.

Ова го припишуваме на фактот дека (како што се покажа во процесот на анализа и комуникација со некои од нашите клиенти) постои мала разлика во перцепцијата на она што се смета за инцидент. Ако успеавме да ја вратиме функционалноста на нашата услуга за време на техничкиот прозорец, дали ова може да се смета за инцидент? Веројатно не, бидејќи сè средивме, супер сме. Дали може да се смета за инцидент ако треба да ја превртиме нашата апликација 10 пати во нормалниот, познат режим? Се чини дека не. Затоа, прашањето за врската помеѓу неуспешните промени и другите метрики останува отворено. Ќе го разјасниме дополнително.

Овде е важно што најдовме значајна корелација помеѓу времето на испорака, времето за обновување и фреквенцијата на распоредување. Затоа, ги зедовме овие три метрики за дополнително да ги поделиме испитаниците во групи за изведба.

Колку виси во грамови?

Користивме хиерархиска кластерска анализа:

• Ние ги дистрибуираме испитаниците низ n-димензионален простор, каде што координатата на секој испитаник е нивните одговори на прашањата.
• Секој испитаник е прогласен за мал кластер.
• Ги комбинираме двете кластери кои се најблиску еден до друг во еден поголем кластер.
• Го наоѓаме следниот пар кластери и ги комбинираме во поголем кластер.

Вака ги групираме сите наши испитаници во бројот на кластери што ни се потребни. Со помош на дендрограм (дрво на врски помеѓу кластери) го гледаме растојанието помеѓу две соседни кластери. Нам ни останува само да поставиме одредена граница на растојание помеѓу овие кластери и да кажеме: „Овие две групи сосема се разликуваат една од друга бидејќи растојанието меѓу нив е џиновско“.

Но, тука има скриен проблем: немаме ограничувања за бројот на кластери - можеме да добиеме 2, 3, 4, 10 кластери. И првата идеја беше - зошто да не ги поделиме сите наши испитаници во 4 групи, како што тоа го прави ДОРА. Но, откривме дека разликите меѓу овие групи стануваат незначителни и не можеме да бидеме сигурни дека испитаникот навистина припаѓа на неговата група, а не на соседната. Сè уште не можеме да го поделиме рускиот пазар во четири групи. Затоа, се населивме на три профили меѓу кои има статистички значајна разлика:

Следно, го одредивме профилот по кластер: ги земавме медијаните за секоја метрика за секоја група и составивме табела со профили на ефикасност. Всушност, добиени се профилите на изведба за просечниот учесник во секоја група. Идентификувавме три профили на ефикасност: ниска, средна, висока:

Овде ја потврдивме нашата хипотеза дека 4 клучни метрики се погодни за одредување на профилот на изведба и тие работат и на западниот и на рускиот пазар. Има разлика меѓу групите и таа е статистички значајна. Нагласувам дека постои значајна разлика меѓу профилите на перформанси во однос на метриката на неуспешни промени во однос на просекот, иако првично не ги поделивме испитаниците по овој параметар.

Тогаш се поставува прашањето: како да се искористи сето ова?

Како да се користи

Ако земеме кој било тим, 4 клучни метрики и го примениме на табелата, тогаш во 85% од случаите нема да добиеме комплетен натпревар - ова е само просечен учесник, а не она што е во реалноста. Сите сме (и секој тим) малку различни.

Проверивме: ги зедовме нашите испитаници и профилот на изведбата на DORA и погледнавме колку испитаници одговараат на овој или оној профил. Откривме дека само 16% од испитаниците дефинитивно паднале на некој од профилите. Сите останати се расфрлани некаде помеѓу:

Ова значи дека профилот на изведба има ограничен опсег. За да добиете прво приближување за тоа каде се наоѓате, можете да ја користите оваа табела: „Ох, изгледа дека сме поблиску до средно или високо! Ако разберете каде одите понатаму, тоа може да биде доволно. Но, ако вашата цел е постојано, континуирано подобрување и сакате попрецизно да знаете каде да се развивате и што да правите, тогаш потребни се дополнителни средства. Ги нарековме калкулатори:

• Калкулатор DORA
• Калкулатор Express 42* (во развој)
• Сопствен развој (можете да креирате сопствен внатрешен калкулатор).

За што се потребни? Да разбере:

• Дали тимот во нашата организација ги исполнува нашите стандарди?
• Ако не, можеме ли да и помогнеме - да го забрзаме во рамките на експертизата што ја има нашата компанија?
• Ако е така, дали можеме уште подобро?

Можете исто така да ги користите за собирање статистика во рамките на компанијата:

• Какви тимови имаме?
• Поделете ги тимовите во профили;
• Видете: О, овие команди слабо се извршуваат (тие не се извлекуваат малку), но овие се одлични: тие се распоредуваат секој ден, без грешки, имаат времетраење од помалку од еден час.

И тогаш можете да дознаете дека во рамките на нашата компанија ја има потребната експертиза и алатки за оние тимови кои сè уште не се на ниво.

Или, ако разбирате дека се чувствувате одлично во друштвото, дека сте подобри од многумина, тогаш можете да погледнете малку пошироко. Ова е токму руската индустрија: дали можеме да ја добиеме потребната експертиза во руската индустрија за да се забрзаме? Калкулаторот Express 42 ќе помогне овде (тој е во развој). Ако сте го надминале рускиот пазар, тогаш погледнете Калкулатор DORA и на светскиот пазар.

Добро. И ако сте во групата Елит според калкулаторот DORA, тогаш што треба да направите? Тука нема добро решение. Најверојатно, вие сте во првите редови на индустријата, а понатамошно забрзување и подобрувања на сигурноста се можни преку внатрешно истражување и развој и трошење на големи ресурси.

Да преминеме на најслаткиот дел - споредбата.

Споредба

Првично сакавме да ја споредиме руската индустрија со западната индустрија. Ако споредиме директно, ќе видиме дека имаме помалку профили, а тие се малку повеќе измешани еден со друг, границите се малку понејасни:

Нашите елитни изведувачи се скриени меѓу високите изведувачи, но тие се таму - тоа се елитата, еднорозите кои достигнаа значителни височини. Во Русија, разликата помеѓу Елитниот профил и Високиот профил сè уште не е доволно значајна. Сметаме дека во иднина оваа поделба ќе се случи поради зголемување на инженерската култура, квалитетот на имплементација на инженерските практики и експертизата во компаниите.

Ако продолжиме со директна споредба во руската индустрија, ќе видиме дека тимовите од висок профил се подобри во сите погледи. Ние, исто така, ја потврдивме нашата хипотеза дека постои врска помеѓу овие метрики и организациската ефективност: Тимовите од висок профил имаат значително поголема веројатност не само да ги постигнат целите, туку и да ги надминат.
Ајде да станеме тимови од висок профил и да не застанеме тука:

Но, оваа година е посебна и решивме да провериме како работат компаниите во пандемија: Тимовите од висок профил работат многу подобро и се чувствуваат подобро од просекот во индустријата:

• 1,5-2 пати поголема веројатност за ослободување на нови производи,
• 2 пати поголема веројатност за подобрување на доверливоста и/или перформансите на апликациската инфраструктура.

Односно, компетенциите што веќе ги имаа им помогнаа да се развијат побрзо, да лансираат нови производи, да ги менуваат постоечките производи, а со тоа да освојат нови пазари и нови корисници:

Што друго им помогна на нашите тимови?

Инженерски практики

Ќе ви кажам за значајни наоди за секоја практика што ја проверивме. Можеби нешто друго им помогна на тимовите, но зборуваме за DevOps. И во рамките на DevOps, гледаме разлики меѓу тимовите од различни профили.

Платформа како услуга

Не најдовме значајна врска помеѓу возраста на платформата и профилот на тимот: платформите се појавија приближно во исто време и за тимовите со низок и за високиот тим. Но, за второто, платформата обезбедува, во просек, повеќе услуги и повеќе програмски интерфејси за контрола преку програмскиот код. И тимовите на платформата имаат поголема веројатност да им помогнат на своите развивачи и тимови да ја користат платформата, да ги решаваат своите проблеми и инцидентите поврзани со платформата почесто и да ги едуцираат другите тимови.

Инфраструктурата како код

Сè е прилично стандардно овде. Најдовме врска помеѓу автоматизирање на работата на инфраструктурниот код и колку информации се складирани во складиштето на инфраструктурата. Командите со висок профил складираат повеќе информации во складиштата: ова се конфигурацијата на инфраструктурата, цевководот CI / CD, поставките за животната средина и параметрите за изградба. Тие почесто ги складираат овие информации, подобро работат со инфраструктурниот код и автоматизираат повеќе процеси и задачи за работа со инфраструктурен код.

Интересно е што не видовме значителна разлика во инфраструктурните тестови. Ова го припишувам на фактот дека тимовите од висок профил имаат повеќе автоматизација на тестовите воопшто. Можеби не треба да им го одвлекуваат вниманието посебно со инфраструктурни тестови, туку оние тестови со кои ги проверуваат апликациите и благодарение на нив веќе гледаат што и каде пукнале.

Интеграција и испорака

Најдосадниот дел, бидејќи потврдивме дека колку повеќе автоматизација имате, толку подобро работите со кодот, толку е поголема веројатноста да добиете подобри резултати.

архитектура

Сакавме да видиме како микросервисите влијаат на перформансите. Навистина, тие не го прават тоа, бидејќи употребата на микроуслуги не е поврзана со зголемување на индикаторите за перформанси. Микроуслугите се користат и за команди со висок профил и за команди со низок профил.

Но, она што е значајно е дека за High-teams, транзицијата кон архитектура на микросервис им овозможува самостојно да ги развиваат своите услуги и да ги промовираат. Ако архитектурата им дозволува на програмерите да дејствуваат автономно, без да чекаат некој надворешен од тимот, тогаш ова е клучна компетентност за зголемување на брзината. Ова е местото каде што микросервисите помагаат. Но, едноставно нивното спроведување не игра голема улога.

Како го откривме сето ова?

Имавме амбициозен план целосно да ја реплицираме методологијата DORA, но немавме ресурси. Ако ДОРА користи многу спонзорства и нивното истражување трае половина година, ние го направивме нашето истражување за кратко време. Сакавме да изградиме модел на DevOps како што тоа го прави DORA, и тоа ќе го правиме во иднина. Досега се ограничивме на топлински мапи:

Ја разгледавме распределбата на инженерските практики меѓу тимовите од секој профил и откривме дека тимовите од високиот профил, во просек, почесто користат инженерски практики. Повеќе за сето ова можете да прочитате во нашата извештај.

За промена, да преминеме од сложени статистики на едноставни.

Што друго откривме?

Алатки

Забележуваме дека повеќето од командите се користат од оперативниот систем од семејството Линукс. Но, Windows е сè уште во тренд - најмалку една четвртина од нашите испитаници забележаа употреба на една или друга од неговите верзии. Се чини дека пазарот ја има оваа потреба. Затоа, можете да ги развиете овие компетенции и да правите презентации на конференции.

Кај оркестраторите никому не е тајна, Кубернетес е во водство (52%). Следниот во редот оркестратор е Docker Swarm (околу 12%). Најпопуларните CI системи се Jenkins и GitLab. Најпопуларниот систем за управување со конфигурации е Ansible, следен од нашата сакана Shell.

Амазон во моментов е водечки провајдер за хостирање облак. Уделот на руските облаци постепено се зголемува. Следната година ќе биде интересно да се види како ќе се чувствуваат руските провајдери на облак, дали нивниот удел на пазарот ќе се зголеми. Тие се, тие можат да се користат, и тоа е добро:

Му предавам збор на Игор, кој ќе даде уште некоја статистика.

Ширење на практики

Игор Курочкин: Одделно, ги замоливме испитаниците да наведат како се распределуваат разгледуваните инженерски практики во компанијата. Во повеќето компании, постои мешан пристап, кој се состои од различен сет на модели, а пилот-проектите се многу популарни. Видовме и мала разлика помеѓу профилите. Претставниците на високиот профил почесто ја користат шемата „Иницијатива одоздола“, кога мали тимови од специјалисти ги менуваат работните процеси, алатките и споделуваат успешни практики со други тимови. Во Medium, ова е иницијатива од врвот надолу која влијае на целата компанија преку создавање на заедници и центри на извонредност:

Agile и DevOps

Прашањето за врската помеѓу Agile и DevOps често се дискутира во индустријата. Ова прашање се покренува и во Извештајот за агилна состојба за 2019/2020 година, па решивме да споредиме како се поврзани активностите Agile и DevOps во компаниите. Откривме дека DevOps без Agile е редок. За половина од испитаниците, ширењето на Agile започна значително порано, а околу 20% забележаа симултан почеток, а еден од знаците за низок профил ќе биде отсуството на практики Agile и DevOps:

Командни топологии

На крајот на минатата година книгата „Тимски топологии“, кој предлага рамка за опишување на тимските топологии. Се прашувавме дали тоа ќе важи за руските компании. И го поставивме прашањето: „Какви модели ги гледате?

Кај половина од испитаниците се набљудувани инфраструктурни тимови, како и посебни тимови за развој, тестирање и работа. Одделни DevOps тимови забележаа 45%, меѓу кои почести се претставниците на High. Следуваат меѓуфункционалните тимови, кои исто така се почести на Хај. Одделни команди SRE се појавуваат во високите, средните профили и ретко се гледаат во низок профил:

Сооднос DevQaOps

Ова прашање го видовме на FaceBook од лидерот на тимот на тимот на платформата Skyeng - тој беше заинтересиран за соодносот на програмери, тестери и администратори во компаниите. Го прашавме и ги разгледавме одговорите врз основа на профилите: Претставниците од висок профил имаат помалку инженери за тестирање и операции за секој развивач:

Планови за 2021 година

Во плановите за наредната година, испитаниците ги забележале следните активности:

Овде можете да го видите пресекот со конференцијата DevOps Live 2020. Внимателно ја разгледавме програмата:

• Инфраструктурата како производ
• Трансформација на DevOps
• Дистрибуција на практики на DevOps
• DevSecOps
• Клубови за случаи и дискусии

Но, времето на нашата презентација не е доволно за да ги покриеме сите теми. Оставени зад сцената:

• Платформа како услуга и како производ;
• Инфраструктура како код, околини и облаци;
• Континуирана интеграција и испорака;
• Архитектура;
• шеми на DevSecOps;
• Платформи и меѓуфункционални тимови.

Извештај добивме обемна, 50 страници, а можете да ја видите подетално.

Сумирање

Се надеваме дека нашето истражување и извештај ќе ве инспирираат да експериментирате со нови пристапи за развој, тестирање и операции, како и да ви помогне да ги добиете вашите ориентации, да се споредувате со другите во студијата и да ги идентификувате областите каде што можете да ги подобрите вашите сопствени пристапи .

Резултати од првата студија за состојбата на DevOps во Русија:

• Клучни метрики. Откривме дека клучните метрики (време на испорака, стапка на распоредување, време за обновување и неуспеси на промени) се погодни за анализа на ефективноста на процесите на развој, тестирање и операции.
• Профили високи, средни, ниски. Врз основа на собраните податоци, можно е да се разликуваат статистички различни групи на високи, средни, ниски со карактеристични карактеристики во однос на метрика, практики, процеси и алатки. Претставниците на Високиот профил покажуваат подобри резултати од Ниските. Поголема е веројатноста да ги постигнат и надминат своите цели.
• Индикатори, пандемија и планови за 2021 година. Посебен показател оваа година е како компаниите се справија со пандемијата. Високот имаше подобри резултати, доживеа зголемување на активноста на корисниците, а главните причини за успех беа ефикасните развојни процеси и силната инженерска култура.
• DevOps практики, алатки и нивниот развој. Главните планови на компаниите за следната година вклучуваат развој на DevOps практики и алатки, воведување на DevSecOps практики и промени во организациската структура. А ефективната имплементација и развој на практиките на DevOps се спроведува со помош на пилот проекти, формирање на заедници и центри на извонредност, иницијативи на горните и долните нивоа на компанијата.

Ќе ни биде мило да ги слушнеме вашите критики, приказни, повратни информации. Им благодариме на сите кои учествуваа во студијата и со нетрпение го очекуваме вашето учество следната година.

Извор: www.habr.com