Състояние на DevOps в Русия 2020 г

Как да разберем състоянието на нещо?

Можете да разчитате на вашето мнение, формирано от различни източници на информация, например публикации в уебсайтове или опит. Може да попитате колеги, познати. Друга възможност е да разгледате темите на конференциите: програмният комитет е активен представител на индустрията, така че ние им се доверяваме при избора на подходящи теми. Отделна област са изследванията и докладите. Но има проблем. Изследвания за състоянието на DevOps се провеждат ежегодно в света, доклади се публикуват от чуждестранни компании, а за руските DevOps почти няма информация.

Но дойде денят, когато беше проведено такова проучване и днес ще говорим за резултатите. Състоянието на DevOps в Русия беше проучено съвместно от компаниите "Експрес 42"И"Онтико". Express 42 помага на технологичните компании да внедряват и развиват практики и инструменти на DevOps и е един от първите, които говорят за DevOps в Русия. Авторите на изследването, Игор Курочкин и Виталий Хабаров, се занимават с анализи и консултации в Express 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), публикуваха годишен доклад. На следващата година ДОРА и Puppet издават последния си съвместен доклад.

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

През 2018 г. компаниите се разделиха и бяха публикувани два независими доклада: единият от Puppet, вторият от DORA във връзка с Google. DORA продължи да използва своята методология с ключови показатели, профили на производителност и инженерни практики, които оказват влияние върху ключовите показатели и ефективността на цялата компания. И Puppet предложи свой собствен подход с описание на процеса и еволюцията на DevOps. Но историята не пусна корени, през 2019 г. Puppet изостави тази методология и пусна нова версия на докладите, в която бяха изброени ключовите практики и как те влияят на DevOps от тяхна гледна точка. След това се случи друго събитие: Google купи DORA и заедно пуснаха друг доклад. Може да сте го виждали.

Тази година нещата се усложниха. Известно е, че Puppet стартира свое собствено проучване. Направиха го седмица по-рано от нас и вече приключи. Участвахме в него и разгледахме какви теми ги интересуват. Сега Puppet прави своя анализ и се подготвя да публикува доклада.

Но все още няма съобщение от DORA и Google. През май, когато обикновено започва проучването, се появи информация, че Никол Форсгрен, един от основателите на DORA, се е преместила в друга компания. Затова предположихме, че тази година няма да има изследване и доклад от ДОРА.

Как стоят нещата в Русия?

Не сме правили DevOps изследвания. Говорихме на конференции, преразказвахме откритията на други хора, а Райфайзенбанк преведе „State of DevOps“ за 2019 г. (можете да намерите тяхното съобщение на Хабре), много благодарение на тях. И това е всичко.

Затова проведохме собствено проучване в Русия, използвайки методологиите и откритията на DORA. Използвахме доклада на колеги от Райфайзенбанк за наше проучване, включително за синхронизиране на терминологията и превода. Въпросите, свързани с индустрията, бяха взети от докладите на DORA и тазгодишния въпросник Puppet.

Изследователски процес

Докладът е само финалната част. Целият процес на изследване се състои от четири основни стъпки:

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

Участниците

Всички чуждестранни репортажи започват с портрет на участниците и повечето от тях не са от Русия. Процентът на анкетираните руснаци се колебае между 5 и 1% от година на година и това не позволява да се правят изводи.

Карта от доклада Accelerate State of DevOps 2019:

В нашето проучване успяхме да интервюираме 889 души - това е доста (DORA анкетира около хиляда души годишно в своите доклади) и тук постигнахме целта:

Вярно е, че не всички наши участници стигнаха до края: процентът на изпълнение се оказа малко по-малък от половината. Но дори и това беше достатъчно, за да се получи представителна проба и да се направи анализ. DORA не разкрива проценти на запълване в отчетите си, така че тук няма сравнение.

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

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

Всеки втори работи за средно голяма компания. Всеки трети работи в големи компании. Повечето работят в екипи до 9 души. Отделно попитахме за основните дейности и по-голямата част са свързани по някакъв начин с операцията, а около 40% се занимават с разработка:

Така събрахме информация за сравнение и анализ на представители на различни индустрии, компании, екипи. Колегата Виталий Хабаров ще разкаже за анализа.

Анализ и сравнение

Виталий Хабаров: Благодаря много на всички участници, които попълниха нашата анкета, попълниха въпросници и ни предоставиха данни за по-нататъшен анализ и тестване на нашите хипотези. И благодарение на нашите клиенти и клиенти, ние имаме богат опит, който ни помогна да идентифицираме опасенията на индустрията и да формулираме хипотезите, които тествахме в нашето изследване.

За съжаление, не можете просто да вземете списък с въпроси от една страна и данни от друга, да ги сравните по някакъв начин, да кажете: „Да, всичко работи така, бяхме прави“ и да се разпръснем. Не, необходими са методология и статистически методи, за да сме сигурни, че не грешим и заключенията ни са надеждни. Тогава можем да изградим по-нататъшната си работа въз основа на тези данни:

Ключови показатели

За основа взехме методологията DORA, която те описаха подробно в книгата „Ускоряване на състоянието на DevOps“. Проверихме дали ключовите показатели са подходящи за руския пазар, дали могат да се използват по същия начин, както DORA използва, за да отговори на въпроса: „Как индустрията в Русия съответства на чуждестранната индустрия?“

Ключови показатели:

1. Честота на разполагане. Колко често се внедрява нова версия на приложението в производствената среда (планирани промени, с изключение на актуални корекции и реакция при инциденти)?
2. Време за доставка. Какво е средното време между извършването на промяна (написване на функционалност като код) и внедряването на промяната в производствената среда?
3. Време за възстановяване. Колко време отнема средно възстановяването на приложение в производствена среда след инцидент, влошаване на услугата или откриване на грешка, която засяга потребителите на приложението?
4. Неуспешни промени. Какъв процент от внедряванията в производствената среда водят до влошаване на качеството на приложението или инциденти и изискват коригиране (връщане назад на промените, разработване на актуална корекция или корекция)?

В своето изследване DORA откри връзка между тези показатели и организационното представяне. Ние също го тестваме в нашето проучване.

Но за да сте сигурни, че четирите ключови показателя могат да повлияят на нещо, трябва да разберете – свързани ли са по някакъв начин един с друг? DORA отговори утвърдително с едно предупреждение: връзката между неуспешните промени (Change Failure Rate) и три други показателя е малко по-слаба. Получихме почти същата картина. Ако времето за доставка, честотата на разгръщане и времето за възстановяване корелират помежду си (установихме тази корелация чрез корелацията на Pearson и чрез скалата на Chaddock), тогава няма толкова силна корелация с неуспешни промени.

По принцип повечето от респондентите са склонни да отговорят, че имат сравнително малък брой инциденти в производството. Въпреки че по-късно ще видим, че все още има значителна разлика между групите респонденти по отношение на неуспешни промени, все още не можем да използваме този показател за това разделение.

Отдаваме това на факта, че (както се оказа по време на анализа и комуникацията с някои от нашите клиенти) има малка разлика във възприемането на това какво се счита за инцидент. Ако успеем да възстановим работата на нашата услуга по време на техническия прозорец, може ли това да се счита за инцидент? Вероятно не, защото оправихме всичко, страхотни сме. Можем ли да считаме за инцидент, ако трябва да превъртим приложението си 10 пъти в нормален, познат за нас режим? Изглежда не. Следователно въпросът за връзката на неуспешните промени с други показатели остава отворен. Ще го усъвършенстваме допълнително.

Важно тук е, че открихме значителна корелация между времето за доставка, времето за възстановяване и честотата на внедряване. Затова взехме тези три показателя, за да разделим допълнително респондентите на групи по ефективност.

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

Използвахме йерархичен клъстерен анализ:

• Ние разпределяме респондентите в n-мерно пространство, където координатите на всеки респондент са техните отговори на въпроси.
• Всеки респондент е обявен за малък клъстер.
• Комбинираме двата най-близки един до друг клъстера в един по-голям клъстер.
• Намираме следващата двойка клъстери и ги комбинираме в по-голям клъстер.

По този начин групираме всички наши респонденти в броя на групите, от които се нуждаем. С помощта на дендрограма (дърво на връзките между клъстерите) виждаме разстоянието между два съседни клъстера. Всичко, което остава за нас, е да поставим определена граница на разстоянието между тези клъстери и да кажем: "Тези две групи са доста различими една от друга, защото разстоянието между тях е гигантско."

Но тук има скрит проблем: нямаме ограничения за броя на клъстерите - можем да получим 2, 3, 4, 10 клъстера. И първата идея беше - защо не разделим всички наши респонденти на 4 групи, както прави DORA. Но установихме, че разликите между тези групи стават незначителни и не можем да сме сигурни, че респондентът наистина принадлежи към своята група, а не към съседната. Все още не можем да разделим руския пазар на четири групи. Затова се спряхме на три профила, между които има статистически значима разлика:

След това определихме профила по клъстери: взехме медианата за всеки показател за всяка група и съставихме таблица с профили на ефективност. Всъщност получихме профилите на представяне на средния участник във всяка група. Идентифицирахме три профила на ефективност: Ниска, Средна, Висока:

Тук потвърдихме нашата хипотеза, че 4 ключови показателя са подходящи за определяне на профила на ефективност и работят както на западния, така и на руския пазар. Разлика между групите има и тя е статистически значима. Подчертавам, че има значителна разлика между профилите на ефективност по отношение на метриката на неуспешните промени по отношение на средната стойност, въпреки че първоначално не разделихме респондентите по този параметър.

Тогава възниква въпросът: как да използваме всичко това?

Как да използвате

Ако вземем който и да е отбор, 4 ключови показателя и го приложим към таблицата, тогава в 85% от случаите няма да получим пълно съвпадение - това е просто среден участник, а не това, което е в действителност. Всички (и всеки отбор) сме малко по-различни.

Проверихме: взехме нашите респонденти и профила на представяне на DORA и разгледахме колко респонденти отговарят на този или онзи профил. Установихме, че само 16% от анкетираните със сигурност попадат в някой от профилите. Всички останали са разпръснати някъде по средата:

Това означава, че профилът на ефективност има ограничен обхват. За да разберете къде се намирате в първото приближение, можете да използвате тази таблица: „О, изглежда, че сме по-близо до средно или високо!“ Ако разбирате накъде да отидете, това може да е достатъчно. Но ако целта ви е постоянно, непрекъснато усъвършенстване и искате да знаете по-точно къде да се развивате и какво да правите, тогава са необходими допълнителни средства. Нарекохме ги калкулатори:

• DORA калкулатор
• Calculator Express 42* (в процес на разработка)
• Собствена разработка (можете да създадете свой собствен вътрешен калкулатор).

За какво са нужни? Да разбера:

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

Можете също така да ги използвате за събиране на статистика в компанията:

• Какви отбори имаме?
• Разделете екипите на профили;
• Вижте: О, тези команди не се представят добре (не се измъкват малко), но са страхотни: внедряват се всеки ден, без грешки, имат време за изпълнение по-малко от час.

И тогава можете да разберете, че в нашата компания има необходимата експертиза и инструменти за онези екипи, които все още не са на ниво.

Или, ако разберете, че се чувствате страхотно в компанията, вие сте по-добри от мнозина, тогава можете да погледнете малко по-широко. Това е само руската индустрия: можем ли да получим необходимата експертиза в руската индустрия, за да се ускорим? Тук ще помогне калкулаторът Express 42 (той е в процес на разработка). Ако сте надраснали руския пазар, погледнете DORA калкулатор и към световния пазар.

Глоба. И ако сте в групата на Елит на калкулатора DORA, какво трябва да направите? Тук няма добро решение. Вие най-вероятно сте в челните редици на индустрията и по-нататъшното ускоряване и надеждност са възможни чрез вътрешна научноизследователска и развойна дейност и изразходване на повече ресурси.

Да преминем към най-сладкото - сравнението.

Сравнение

Първоначално искахме да сравним руската индустрия със западната. Ако сравним директно, виждаме, че имаме по-малко профили и те са малко по-смесени един с друг, границите са малко по-размити:

Нашите Елитни изпълнители са скрити сред Високите изпълнители, но те са там - това е елитът, еднорозите, които са достигнали значителни висоти. В Русия разликата между Елитния профил и Високия профил все още не е достатъчно значителна. Смятаме, че в бъдеще това разделение ще се случи поради повишаване на инженерната култура, качеството на прилагане на инженерните практики и експертизата в компаниите.

Ако преминем към директно сравнение в руската индустрия, можем да видим, че екипите с висок профил са по-добри във всички отношения. Ние също така потвърдихме нашата хипотеза, че има връзка между тези показатели и организационното представяне: Екипите с висок профил са много по-склонни не само да постигнат целите, но и да ги надминат.
Нека станем отбори с висок профил и да не спираме дотук:

Но тази година е специална и ние решихме да проверим как се справят компаниите по време на пандемия: Екипите с висок профил се справят много по-добре и се чувстват по-добре от средното за индустрията:

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

Тоест компетенциите, които вече са имали, са им помогнали да се развиват по-бързо, да пускат нови продукти, да модифицират съществуващи продукти, като по този начин завладяват нови пазари и нови потребители:

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

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

Ще ви разкажа за значимите констатации за всяка практика, която тествахме. Може би нещо друго е помогнало на екипите, но ние говорим за DevOps. И в рамките на DevOps виждаме разлика между екипи с различни профили.

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

Не открихме значителна връзка между възрастта на платформата и профила на екипа: Платформите се появиха приблизително по едно и също време както за отбори с ниски нива, така и за отбори с високи нива. Но за последното платформата предоставя средно повече услуги и повече програмни интерфейси за управление чрез програмен код. Екипите на платформата са по-склонни да помагат на своите разработчици и екипи да използват платформата, да решават проблемите си и свързаните с платформата инциденти по-често и да образоват други екипи.

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

Тук всичко е доста стандартно. Открихме връзка между автоматизирането на работата на инфраструктурния код и колко информация се съхранява в хранилището на инфраструктурата. Командите с висок профил съхраняват повече информация в хранилищата: това е конфигурацията на инфраструктурата, тръбопровода CI / CD, настройките на средата и параметрите за изграждане. Те съхраняват тази информация по-често, работят по-добре с инфраструктурен код и автоматизират повече процеси и задачи за работа с инфраструктурен код.

Интересното е, че не видяхме значителна разлика в инфраструктурните тестове. Отдавам това на факта, че екипите с висок профил имат повече автоматизация на тестовете като цяло. Може би не трябва да се разсейват отделно от инфраструктурни тестове, а по-скоро от онези тестове, с които проверяват приложенията и благодарение на тях вече виждат какво и къде са счупили.

Интеграция и доставка

Най-скучният раздел, защото потвърдихме, че колкото повече автоматизация имате, толкова по-добре работите с кода, толкова по-вероятно е да получите по-добри резултати.

архитектура

Искахме да видим как микроуслугите влияят на производителността. Всъщност не го правят, тъй като използването на микроуслуги не е свързано с увеличаване на показателите за ефективност. Микроуслугите се използват както за команди с висок профил, така и за команди с нисък профил.

Но това, което е важно е, че за High-teams преходът към архитектура на микросервизи им позволява самостоятелно да развиват своите услуги и да ги внедряват. Ако архитектурата позволява на разработчиците да действат автономно, без да чакат някой външен за екипа, то това е ключова компетентност за увеличаване на скоростта. В този случай микроуслугите помагат. И само изпълнението им не играе голяма роля.

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

Имахме амбициозен план за пълно копиране на методологията DORA, но липсваха ресурси. Ако ДОРА използва много спонсорство и тяхното проучване отнема половин година, ние направихме нашето проучване за кратко време. Искахме да изградим модел DevOps като DORA и ще го направим в бъдеще. Досега сме се ограничавали до топлинни карти:

Разгледахме разпределението на инженерните практики в екипите във всеки профил и открихме, че екипите с висок профил средно са по-склонни да използват инженерни практики. Можете да прочетете повече за всичко това в нашия доклад.

За разнообразие, нека преминем от сложни статистики към прости.

Какво друго открихме?

Инструменти

Забелязваме, че повечето от командите се използват от операционната система от семейството на Linux. Но Windows все още е в тенденция - поне една четвърт от нашите респонденти отбелязват използването на една или друга от неговите версии. Изглежда, че пазарът има тази нужда. Следователно можете да развиете тези компетенции и да правите презентации на конференции.

Сред оркестрантите, не е тайна за никого, лидерът е Kubernetes (52%). Следващият по ред оркестратор е Docker Swarm (около 12%). Най-популярните CI системи са Jenkins и GitLab. Най-популярната система за управление на конфигурацията е Ansible, следвана от любимата ни Shell.

В момента Amazon е водещ доставчик на облачен хостинг. Делът на руските облаци постепенно нараства. Следващата година ще бъде интересно да видим как ще се почувстват руските облачни доставчици, дали пазарният им дял ще се увеличи. Те са, могат да се използват и това е добре:

Давам думата на Игор, който ще даде още малко статистика.

Разпространение на практики

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

Agile и DevOps

Въпросът за връзката между Agile и DevOps често се обсъжда в индустрията. Този въпрос е повдигнат и в доклада за състоянието на Agile за 2019/2020 г., така че решихме да сравним как Agile и DevOps дейностите са свързани в компаниите. Открихме, че DevOps без Agile е рядкост. За половината от респондентите разпространението на Agile започва много по-рано и около 20% наблюдават едновременното стартиране, а един от признаците за нисък профил ще бъде липсата на Agile и DevOps практики:

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

В края на миналата година книгата „Екипни топологии”, който предлага рамка за описание на командни топологии. Стана ни интересно дали е приложимо за руски компании. И ние зададохме въпроса: „Какви модели намирате?“.

При половината от анкетираните се наблюдават инфраструктурни екипи, както и отделни екипи за разработка, тестване и експлоатация. Отделни екипи на DevOps отбелязаха 45%, сред които представители на High са по-чести. Следват многофункционалните екипи, които също са по-често срещани в High. Отделни SRE команди се появяват в профилите High, Medium и рядко се виждат в профила Low:

Съотношение DevQaOps

Видяхме този въпрос във FaceBook от ръководителя на екипа на платформата Skyeng - той се интересуваше от съотношението на разработчици, тестери и администратори в компаниите. Зададохме го и разгледахме отговорите въз основа на профили: Високопоставените представители имат по-малко тестови и оперативни инженери за всеки разработчик:

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

В плановете за следващата година респондентите отбелязват следните дейности:

Тук можете да видите пресечната точка с конференцията DevOps Live 2020. Ние внимателно прегледахме програмата:

• Инфраструктурата като продукт
• DevOps трансформация
• Разпространение на DevOps практики
• DevSecOps
• Клубове по казуси и дискусии

Но времето на нашата презентация не е достатъчно, за да обхване всички теми. Останал зад кулисите:

• Платформа като услуга и като продукт;
• Инфраструктура като код, среди и облаци;
• Непрекъсната интеграция и доставка;
• Архитектура;
• DevSecOps модели;
• Платформа и многофункционални екипи.

Доклад получихме обемна, 50 страници, и можете да я видите по-подробно.

Резюмиране

Надяваме се, че нашето изследване и доклад ще ви вдъхновят да експериментирате с нови подходи към разработването, тестването и операциите, както и да ви помогнат да се ориентирате, да се сравните с други участници в проучването и да идентифицирате области, в които можете да подобрите собствените си подходи.

Резултати от първото проучване на състоянието на DevOps в Русия:

• Ключови показатели. Установихме, че ключовите показатели (време за доставка, честота на внедряване, време за възстановяване и неуспешни промени) са подходящи за анализиране на ефективността на процесите на разработка, тестване и операции.
• Профили Висок, Среден, Нисък. Въз основа на събраните данни можем да различим статистически различни групи от високо, средно, ниско с отличителни характеристики по отношение на показатели, практики, процеси и инструменти. Представителите на високия профил показват по-добри резултати от ниския. Те са по-склонни да постигнат и надхвърлят целите си.
• Индикатори, пандемия и планове за 2021 г. Специален показател тази година е как фирмите се справиха с пандемията. Върховните представители се представиха по-добре, изпитаха повишена ангажираност на потребителите и основните причини за успеха бяха ефективните процеси на разработка и силната инженерна култура.
• DevOps практики, инструменти и тяхното развитие. Основните планове на компаниите за следващата година включват развитие на DevOps практики и инструменти, въвеждане на DevSecOps практики и промени в организационната структура. А ефективното прилагане и развитие на практиките на DevOps се осъществява с помощта на пилотни проекти, формиране на общности и центрове за върхови постижения, инициативи на горните и долните нива на компанията.

Ще се радваме да чуем вашите отзиви, истории, отзиви. Благодарим на всички, които участваха в проучването и очакваме вашето участие през следващата година.

Източник: www.habr.com