Stan DevOps w Rosji 2020

Jak zrozumieć stan czegoś?

Możesz polegać na swojej opinii, utworzonej z różnych źródeł informacji, na przykład publikacji na stronach internetowych lub doświadczenia. Możesz zapytać kolegów, znajomych. Inną opcją jest przyjrzenie się tematom konferencji: w komitecie programowym są aktywni przedstawiciele branży, więc ufamy im w doborze odpowiednich tematów. Osobny obszar to badania i raporty. Ale jest problem. Badania stanu DevOps są prowadzone corocznie na świecie, raporty publikowane są przez zagraniczne firmy, a informacji o rosyjskim DevOps prawie nie ma.

Ale nadszedł dzień, w którym przeprowadzono takie badanie, a dziś porozmawiamy o wynikach. Stan DevOps w Rosji był badany wspólnie przez firmy "Ekspres 42"A"Ontico". Express 42 pomaga firmom technologicznym wdrażać i rozwijać praktyki i narzędzia DevOps i jako jeden z pierwszych mówił o DevOps w Rosji. Autorzy badania, Igor Kuroczkin i Witalij Chabarow, zajmują się analizą i doradztwem w Express 42, mając jednocześnie techniczne zaplecze operacyjne i doświadczenie w różnych firmach. Przez 8 lat koledzy przyjrzeli się dziesiątkom firm i projektów – od startupów po przedsiębiorstwa – z różnymi problemami, a także różną dojrzałością kulturową i inżynierską.

W swoim raporcie Igor i Witalij opowiedzieli, jakie problemy były w trakcie badań, jak je rozwiązali, a także jak zasadniczo prowadzone są badania DevOps i dlaczego Express 42 zdecydował się przeprowadzić własne. Ich raport można obejrzeć tutaj.

Badania DevOps

Rozmowę rozpoczął Igor Kuroczkin.

Regularnie pytamy słuchaczy na konferencjach DevOps: „Czy przeczytałeś raport o stanie DevOps w tym roku?” Niewielu podnosi ręce, a nasze badanie wykazało, że tylko jedna trzecia je bada. Jeśli nigdy nie widziałeś takich raportów, powiedzmy od razu, że wszystkie są bardzo podobne. Najczęściej pojawiają się zwroty typu: „W porównaniu do zeszłego roku…”

Tutaj mamy pierwszy problem, a po nim dwa kolejne:

1. Nie mamy danych za ostatni rok. Stan DevOps w Rosji nikogo nie interesuje;
2. Metodologia. Nie jest jasne, jak testować hipotezy, jak konstruować pytania, jak analizować, porównywać wyniki, znajdować powiązania;
3. Terminologia. Wszystkie raporty są w języku angielskim, wymagane jest tłumaczenie, wspólny framework DevOps nie został jeszcze wynaleziony i każdy wymyśla własny.

Przyjrzyjmy się, jak przeprowadzano analizy stanu DevOps na całym świecie.

Historyczne informacje

Badania DevOps prowadzone są od 2011 roku. Jako pierwszy przeprowadził je Puppet, twórca systemów zarządzania konfiguracją. W tamtym czasie było to jedno z głównych narzędzi do opisu infrastruktury w postaci kodu. Do 2013 roku badania te były po prostu zamkniętymi ankietami, a nie raportami publicznymi.

W 2013 roku pojawiła się firma IT Revolution, wydawca wszystkich najważniejszych książek o DevOps. Wspólnie z Puppet przygotowali pierwszą publikację State of DevOps, w której po raz pierwszy pojawiły się 4 kluczowe metryki. W następnym roku w sprawę zaangażowała się firma consultingowa ThoughtWorks, znana ze swoich regularnych radarów technologicznych dotyczących praktyk i narzędzi branżowych. A w 2015 r. dodano sekcję z metodologią i stało się jasne, w jaki sposób przeprowadzają analizę.

W 2016 roku autorzy badania, po utworzeniu własnej firmy DORA (DevOps Research and Assessment), opublikowali roczny raport. W następnym roku DORA i Puppet wydali swój ostatni wspólny raport.

I wtedy zaczęło się coś ciekawego:

W 2018 roku firmy się podzieliły i ukazały się dwa niezależne raporty: jeden od Puppet, drugi od DORA wspólnie z Google. DORA nadal wykorzystuje swoją metodologię za pomocą kluczowych wskaźników, profili wydajności i praktyk inżynierskich, które mają wpływ na kluczowe wskaźniki i wydajność całej firmy. A Puppet zaoferował własne podejście z opisem procesu i ewolucji DevOps. Ale historia się nie zakorzeniła, w 2019 roku Puppet porzucił tę metodologię i opublikował nową wersję raportów, w których wymieniono kluczowe praktyki i ich wpływ na DevOps z ich punktu widzenia. Potem wydarzyło się inne wydarzenie: Google kupił DORA i razem opublikowali kolejny raport. Być może go widziałeś.

W tym roku sprawy się skomplikowały. Wiadomo, że Puppet uruchomił własną ankietę. Zrobili to tydzień wcześniej niż my i już się skończyło. Wzięliśmy w nim udział i sprawdziliśmy, jakie tematy ich interesują. Teraz Puppet przeprowadza analizę i przygotowuje się do opublikowania raportu.

Ale nadal nie ma ogłoszenia od DORA i Google. W maju, kiedy zwykle rozpoczynało się badanie, pojawiła się informacja, że ​​Nicole Forsgren, jedna z założycielek DORA, przeniosła się do innej firmy. Dlatego założyliśmy, że w tym roku badania i raportu DORA nie będzie.

Jak tam sprawy w Rosji?

Nie prowadziliśmy badań DevOps. Przemawialiśmy na konferencjach, opowiadając o ustaleniach innych osób, a Raiffeisenbank przetłumaczył „State of DevOps” na rok 2019 (ich ogłoszenie można znaleźć na stronie Habré), za co bardzo im dziękuję. I to wszystko.

Dlatego przeprowadziliśmy własne badania w Rosji, korzystając z metodologii i ustaleń DORA. Do naszych badań, w tym do synchronizacji terminologii i tłumaczeń, wykorzystaliśmy raport kolegów z Raiffeisenbank. Pytania branżowe zostały zaczerpnięte z raportów DORA i tegorocznego kwestionariusza Puppet.

Proces badawczy

Raport to tylko ostatnia część. Cały proces badawczy składa się z czterech głównych etapów:

Na etapie przygotowań przeprowadziliśmy wywiady z ekspertami branżowymi i przygotowaliśmy listę hipotez. Na ich podstawie opracowano pytania i uruchomiono ankietę na cały sierpień. Następnie przeanalizowaliśmy i przygotowaliśmy sam raport. W przypadku DORA ten proces trwa 6 miesięcy. Spotkaliśmy się w ciągu 3 miesięcy i teraz rozumiemy, że ledwo starczyło nam czasu: dopiero przeprowadzając analizę, zrozumiesz, jakie pytania musisz zadać.

Uczestnicy

Wszystkie zagraniczne reportaże zaczynają się od portretów uczestników, a większość z nich nie pochodzi z Rosji. Odsetek rosyjskich respondentów waha się od 5 do 1% z roku na rok, co nie pozwala na wyciąganie jakichkolwiek wniosków.

Mapa z raportu Accelerate State of DevOps 2019:

W naszym badaniu udało nam się przeprowadzić wywiady z 889 osobami – to całkiem sporo (DORA ankietuje w swoich raportach około tysiąca osób rocznie) i tutaj osiągnęliśmy cel:

To prawda, że ​​nie wszyscy nasi uczestnicy dotarli do końca: procent ukończenia okazał się nieco mniejszy niż połowa. Ale nawet to wystarczyło, aby uzyskać reprezentatywną próbkę i przeprowadzić analizę. DORA nie ujawnia procentu wypełnienia w swoich raportach, więc nie będzie tu możliwości porównania.

Branże i stanowiska

Nasi respondenci reprezentują kilkanaście branż. Połowa pracy w informatyce. W dalszej kolejności plasują się usługi finansowe, handel, telekomunikacja i inne. Wśród stanowisk znajdują się specjaliści (programista, tester, inżynier operacyjny) oraz kadra zarządzająca (szefowie zespołów, grup, obszarów, dyrektorzy):

Jedna osoba na dwie pracuje w firmie średniej wielkości. Co trzecia osoba pracuje w dużych firmach. Większość pracuje w zespołach do 9 osób. Osobno zapytaliśmy o główne działania, a większość jest w jakiś sposób związana z operacją, a około 40% zajmuje się rozwojem:

Zebraliśmy więc informacje do porównania i analizy przedstawicieli różnych branż, firm, zespołów. O analizie opowie mój kolega Witalij Chabarow.

Analiza i porównanie

Witalij Chabarow: Bardzo dziękuję wszystkim uczestnikom, którzy wypełnili naszą ankietę, wypełnili kwestionariusze i dostarczyli nam danych do dalszej analizy i sprawdzenia naszych hipotez. A dzięki naszym klientom i klientom mamy bogate doświadczenie, które pomogło zidentyfikować obawy branży i sformułować hipotezy, które przetestowaliśmy w naszych badaniach.

Niestety nie można tak po prostu wziąć listy pytań z jednej strony i danych z drugiej, jakoś je porównać, powiedzieć: „Tak, wszystko tak działa, mieliśmy rację” i rozproszyć się. Nie, potrzebna jest metodologia i metody statystyczne, aby mieć pewność, że się nie mylimy i że nasze wnioski są wiarygodne. Następnie możemy budować naszą dalszą pracę w oparciu o te dane:

Kluczowe wskaźniki

Za podstawę wzięliśmy metodologię DORA, którą szczegółowo opisali w książce „Accelerate State of DevOps”. Sprawdziliśmy, czy kluczowe wskaźniki są odpowiednie dla rynku rosyjskiego, czy można je wykorzystać w taki sam sposób, w jaki DORA odpowiada na pytanie: „Jak branża w Rosji ma się do branży zagranicznej?”

Kluczowe wskaźniki:

1. Częstotliwość wdrażania. Jak często nowa wersja aplikacji jest wdrażana na środowisko produkcyjne (planowane zmiany, z wyłączeniem poprawek i odpowiedzi na incydenty)?
2. Czas dostawy. Jaki jest średni czas między zatwierdzeniem zmiany (napisaniem funkcjonalności jako kodu) a wdrożeniem zmiany w środowisku produkcyjnym?
3. czas regeneracji. Ile czasu zajmuje średnio przywrócenie aplikacji do środowiska produkcyjnego po incydencie, degradacji usługi lub wykryciu błędu, który dotyka użytkowników aplikacji?
4. Nieudane zmiany. Jaki procent wdrożeń w środowisku produkcyjnym prowadzi do degradacji aplikacji lub incydentów i wymaga działań naprawczych (wycofanie zmian, opracowanie poprawki lub poprawki)?

DORA w swoich badaniach odkryła związek między tymi wskaźnikami a wydajnością organizacyjną. Testujemy to również w naszym badaniu.

Ale aby upewnić się, że cztery kluczowe wskaźniki mogą mieć na coś wpływ, musisz zrozumieć – czy są one w jakiś sposób ze sobą powiązane? DORA odpowiedziała twierdząco z jednym zastrzeżeniem: związek między nieudanymi zmianami (Change Failure Rate) a trzema innymi miernikami jest nieco słabszy. Mamy mniej więcej to samo zdjęcie. Jeśli czas dostawy, częstotliwość wdrażania i czas przywracania są ze sobą skorelowane (zależność tę ustaliliśmy za pomocą korelacji Pearsona i skali Chaddocka), to nie ma tak silnej korelacji z nieudanymi zmianami.

Zasadniczo większość respondentów odpowiada, że ​​mają raczej niewielką liczbę incydentów w produkcji. Chociaż zobaczymy później, że nadal istnieje istotna różnica między grupami respondentów pod względem nieudanych zmian, nie możemy jeszcze użyć tego miernika do tego podziału.

Przypisujemy to temu, że (jak się okazało podczas analizy i komunikacji z niektórymi z naszych klientów) istnieje niewielka różnica w postrzeganiu tego, co uważa się za incydent. Jeśli udało nam się przywrócić działanie naszego serwisu w oknie technicznym, czy można to uznać za incydent? Chyba nie, bo wszystko naprawiliśmy, jesteśmy świetni. Czy możemy uznać to za incydent, gdybyśmy musieli przerzucić naszą aplikację 10 razy w normalnym, znanym nam trybie? Wydaje się, że nie. Otwarta pozostaje więc kwestia związku nieudanych zmian z innymi metrykami. Dopracujemy to dalej.

Ważne jest tutaj to, że znaleźliśmy istotną korelację między czasem dostawy, czasem odzyskiwania i częstotliwością wdrażania. Dlatego przyjęliśmy te trzy wskaźniki, aby dalej podzielić respondentów na grupy wydajności.

Ile można zawiesić w gramach?

Zastosowaliśmy hierarchiczną analizę skupień:

• Rozmieszczamy respondentów w n-wymiarowej przestrzeni, gdzie współrzędną każdego respondenta są jego odpowiedzi na pytania.
• Każdy respondent jest deklarowany jako mały klaster.
• Łączymy dwa skupienia znajdujące się najbliżej siebie w jedno większe skupisko.
• Znajdujemy następną parę klastrów i łączymy je w większy klaster.

W ten sposób grupujemy wszystkich naszych respondentów w potrzebną nam liczbę klastrów. Za pomocą dendrogramu (drzewa powiązań między skupieniami) widzimy odległość między dwoma sąsiednimi skupieniami. Pozostaje nam tylko wyznaczyć pewną granicę odległości między tymi skupiskami i powiedzieć: „Te dwie grupy dość wyraźnie różnią się od siebie, ponieważ odległość między nimi jest gigantyczna”.

Ale jest tu ukryty problem: nie mamy ograniczeń co do liczby klastrów - możemy uzyskać 2, 3, 4, 10 klastrów. I pierwszy pomysł – dlaczego by nie podzielić wszystkich naszych respondentów na 4 grupy, tak jak robi to DORA. Stwierdziliśmy jednak, że różnice między tymi grupami stają się nieznaczne i nie możemy być pewni, czy respondent rzeczywiście należy do swojej grupy, a nie do grupy sąsiedniej. Nie możemy jeszcze podzielić rynku rosyjskiego na cztery grupy. Dlatego zdecydowaliśmy się na trzy profile, między którymi występuje istotna statystycznie różnica:

Następnie określiliśmy profil według klastrów: wzięliśmy medianę dla każdej metryki dla każdej grupy i skompilowaliśmy tabelę profili wydajności. W rzeczywistości otrzymaliśmy profile wydajności przeciętnego uczestnika w każdej grupie. Zidentyfikowaliśmy trzy profile wydajności: Niski, Średni, Wysoki:

Tutaj potwierdziliśmy naszą hipotezę, że do określenia profilu wydajności odpowiednie są 4 kluczowe wskaźniki, które działają zarówno na rynku zachodnim, jak i rosyjskim. Istnieje różnica między grupami i jest ona istotna statystycznie. Podkreślam, że istnieje znacząca różnica między profilami wydajności pod względem metryki nieudanych zmian w ujęciu średniej, mimo że początkowo nie dzieliliśmy respondentów według tego parametru.

Powstaje zatem pytanie: jak to wszystko wykorzystać?

Jak korzystać

Jeśli weźmiemy dowolny zespół, 4 kluczowe wskaźniki i zastosujemy je do tabeli, to w 85% przypadków nie uzyskamy pełnego dopasowania - to tylko przeciętny uczestnik, a nie to, co jest w rzeczywistości. Wszyscy (i każdy zespół) jesteśmy nieco inni.

Sprawdziliśmy: wzięliśmy naszych respondentów i profil wyników DORA i przyjrzeliśmy się, ilu respondentów pasuje do tego lub innego profilu. Okazało się, że tylko 16% respondentów zdecydowanie wpisało się w jeden z profili. Cała reszta jest rozproszona gdzieś pomiędzy:

Oznacza to, że profil efektywności ma ograniczony zakres. Aby zrozumieć, gdzie jesteś w pierwszym przybliżeniu, możesz skorzystać z tej tabeli: „Och, wygląda na to, że jesteśmy bliżej średniego lub wysokiego!” Jeśli wiesz, gdzie iść dalej, to może wystarczyć. Ale jeśli Twoim celem jest stałe, ciągłe doskonalenie i chcesz dokładniej wiedzieć, gdzie się rozwijać i co robić, to potrzebne są dodatkowe środki. Nazywaliśmy je kalkulatorami:

• Kalkulator DORA
• Kalkulator Express 42* (w fazie rozwoju)
• Własny rozwój (można stworzyć własny wewnętrzny kalkulator).

Do czego są potrzebne? Rozumieć:

• Czy zespół w naszej organizacji spełnia nasze standardy?
• Jeśli nie, to czy możemy temu zaradzić, przyspieszyć w ramach ekspertyz, którymi dysponuje nasza firma?
• Jeśli tak, czy możemy zrobić to jeszcze lepiej?

Możesz je również wykorzystać do zbierania statystyk wewnątrz firmy:

• Jakie mamy zespoły?
• Podziel zespoły na profile;
• Zobacz: Och, te polecenia są mało wydajne (trochę się nie wysuwają), ale są fajne: wdrażają się codziennie, bez błędów, mają czas realizacji poniżej godziny.

A potem możesz się przekonać, że w naszej firmie jest niezbędna wiedza i narzędzia dla tych zespołów, które jeszcze nie są na równi.

Lub, jeśli zrozumiesz, że czujesz się świetnie w firmie, jesteś lepszy niż wielu, możesz spojrzeć trochę szerzej. To tylko rosyjski przemysł: czy możemy zdobyć niezbędną wiedzę specjalistyczną w rosyjskim przemyśle, aby się przyspieszyć? Pomoże tutaj kalkulator Express 42 (jest w fazie rozwoju). Jeśli wyrosłeś z rynku rosyjskiego, spójrz Kalkulator DORA i na rynek światowy.

Cienki. A jeśli jesteś w grupie Elit na kalkulatorze DORA, co powinieneś zrobić? Tu nie ma dobrego rozwiązania. Najprawdopodobniej znajdujesz się w czołówce branży, a dalsze przyspieszenie i niezawodność jest możliwe dzięki wewnętrznym działaniom badawczo-rozwojowym i wydatkowaniu większych zasobów.

Przejdźmy do najsłodszego - porównania.

Porównanie

Początkowo chcieliśmy porównać przemysł rosyjski z przemysłem zachodnim. Jeśli porównamy bezpośrednio, zobaczymy, że mamy mniej profili i są one nieco bardziej przemieszane ze sobą, granice są nieco bardziej rozmyte:

Nasi Elitarni wykonawcy są ukryci wśród Wysokich wykonawców, ale tam są - to elita, jednorożce, które osiągnęły znaczne wyżyny. W Rosji różnica między profilem Elite a High nie jest jeszcze wystarczająco znacząca. Sądzimy, że w przyszłości ta separacja nastąpi ze względu na wzrost kultury inżynierskiej, jakości wdrażania praktyk inżynierskich i wiedzy eksperckiej w firmach.

Jeśli przejdziemy do bezpośredniego porównania w rosyjskim przemyśle, zobaczymy, że zespoły High Profile są lepsze pod każdym względem. Potwierdziliśmy również naszą hipotezę, że istnieje związek między tymi wskaźnikami a wydajnością organizacji: zespoły o wysokim profilu mają znacznie większe szanse nie tylko na osiągnięcie celów, ale także na ich przekroczenie.
Zostańmy zespołami o wysokim profilu i nie poprzestawajmy na tym:

Ale ten rok jest wyjątkowy i postanowiliśmy sprawdzić, jak radzą sobie firmy w czasie pandemii: Zespoły o wysokim profilu radzą sobie znacznie lepiej i czują się lepiej niż średnia w branży:

• 1,5-2 razy większe prawdopodobieństwo wypuszczenia nowych produktów,
• 2 razy większe prawdopodobieństwo poprawy niezawodności i/lub wydajności infrastruktury aplikacji.

Czyli kompetencje, które już posiadali pomogły im szybciej się rozwijać, wprowadzać nowe produkty, modyfikować istniejące produkty, a tym samym zdobywać nowe rynki i nowych użytkowników:

Co jeszcze pomogło naszym zespołom?

Praktyki inżynierskie

Opowiem o znaczących ustaleniach dla każdej praktyki, którą przetestowaliśmy. Być może coś innego pomogło zespołom, ale mówimy o DevOps. W ramach DevOps dostrzegamy różnice między zespołami o różnych profilach.

Platforma jako usługa

Nie znaleźliśmy istotnego związku między wiekiem platformy a profilem zespołu: platformy pojawiły się mniej więcej w tym samym czasie zarówno dla zespołów Low-team, jak i High-team. Ale w przypadku tych ostatnich platforma zapewnia średnio więcej usług i więcej interfejsów programistycznych do sterowania za pomocą kodu programu. Zespoły ds. platformy częściej pomagają swoim programistom i zespołom w korzystaniu z platformy, częściej rozwiązują problemy i incydenty związane z platformą oraz edukują inne zespoły.

Infrastruktura jako kod

Tutaj wszystko jest dość standardowe. Znaleźliśmy związek pomiędzy automatyzacją pracy kodu infrastruktury a ilością informacji przechowywanych wewnątrz repozytorium infrastruktury. Polecenia High profile przechowują więcej informacji w repozytoriach: jest to konfiguracja infrastruktury, potok CI/CD, ustawienia środowiska i parametry kompilacji. Częściej przechowują te informacje, lepiej współpracują z kodem infrastruktury i automatyzują więcej procesów i zadań związanych z pracą z kodem infrastruktury.

Co ciekawe, nie zauważyliśmy znaczącej różnicy w testach infrastruktury. Przypisuję to temu, że zespoły o wysokim profilu mają ogólnie większą automatyzację testów. Być może nie powinny być osobno rozpraszane przez testy infrastruktury, a raczej te testy, za pomocą których sprawdzają aplikacje, a dzięki nim już widzą, co i gdzie popsuli.

Integracja i dostawa

Najnudniejsza sekcja, bo potwierdziliśmy, że im więcej masz automatyzacji, tym lepiej pracujesz z kodem, tym większe prawdopodobieństwo, że uzyskasz lepsze wyniki.

Architektura

Chcieliśmy zobaczyć, jak mikrousługi wpływają na wydajność. W rzeczywistości nie, ponieważ korzystanie z mikroserwisów nie wiąże się ze wzrostem wskaźników wydajności. Mikrousługi są używane zarówno w przypadku poleceń o wysokim profilu, jak i poleceń o niskim profilu.

Jednak istotne jest to, że w przypadku dużych zespołów przejście na architekturę mikrousług umożliwia im niezależne rozwijanie i wdrażanie usług. Jeśli architektura pozwala programistom działać autonomicznie, bez czekania na kogoś spoza zespołu, to jest to kluczowa kompetencja do zwiększania szybkości. W tym przypadku pomagają mikroserwisy. I właśnie ich wdrożenie nie odgrywa dużej roli.

Jak to wszystko odkryliśmy?

Mieliśmy ambitny plan pełnego odtworzenia metodologii DORA, ale brakowało nam zasobów. Jeśli DORA korzysta z wielu sponsorów, a ich badania trwają pół roku, zrobiliśmy je w krótkim czasie. Chcieliśmy zbudować model DevOps, tak jak robi to DORA, i zrobimy to w przyszłości. Do tej pory ograniczaliśmy się do map ciepła:

Przyjrzeliśmy się rozmieszczeniu praktyk inżynierskich w zespołach w każdym profilu i stwierdziliśmy, że średnio zespoły o wysokim profilu częściej korzystały z praktyk inżynierskich. Więcej o tym wszystkim przeczytasz w naszym raport.

Dla odmiany przerzućmy się od skomplikowanych statystyk do prostych.

Co jeszcze odkryliśmy?

Narzędzia

Zauważamy, że większość poleceń jest używana przez system operacyjny z rodziny Linux. Ale Windows wciąż jest w modzie - co najmniej jedna czwarta naszych respondentów zauważyła użycie jednej lub drugiej wersji. Wydaje się, że rynek ma taką potrzebę. Dzięki temu możesz rozwijać te kompetencje i prezentować się na konferencjach.

Wśród orkiestratorów dla nikogo nie jest tajemnicą, prym wiedzie Kubernetes (52%). Kolejnym orkiestratorem w kolejce jest Docker Swarm (około 12%). Najpopularniejszymi systemami CI są Jenkins i GitLab. Najpopularniejszym systemem zarządzania konfiguracją jest Ansible, a następnie nasz ukochany Shell.

Amazon jest obecnie wiodącym dostawcą usług hostingowych w chmurze. Stopniowo zwiększa się udział chmur rosyjskich. W przyszłym roku ciekawe będzie, jak poczują się rosyjscy dostawcy chmury, czy ich udział w rynku wzrośnie. Są, można ich używać i to dobrze:

Przekazuję głos Igorowi, który poda więcej statystyk.

Rozpowszechnianie praktyk

Igor Kurochkin: Osobno poprosiliśmy respondentów o wskazanie, w jaki sposób rozłożone są rozważane praktyki inżynierskie w firmie. W większości firm stosuje się podejście mieszane, składające się z innego zestawu wzorców, a dużą popularnością cieszą się projekty pilotażowe. Zauważyliśmy również niewielką różnicę między profilami. Przedstawiciele wysokiego profilu częściej stosują schemat „Inicjatywa od dołu”, kiedy małe zespoły specjalistów zmieniają procesy pracy, narzędzia i dzielą się udanymi praktykami z innymi zespołami. W Medium jest to odgórna inicjatywa, która wpływa na całą firmę poprzez tworzenie społeczności i centrów doskonałości:

Agile i DevOps

Kwestia związku między Agile i DevOps jest często dyskutowana w branży. Kwestia ta poruszana jest również w Raporcie State of Agile za rok 2019/2020, dlatego postanowiliśmy porównać, jak w firmach łączą się działania Agile i DevOps. Odkryliśmy, że DevOps bez Agile jest rzadkością. Dla połowy respondentów rozprzestrzenianie się Agile zaczęło się znacznie wcześniej, a około 20% zaobserwowało równoczesny start, a jednym z przejawów niskiego profilu będzie brak praktyk Agile i DevOps:

Topologie poleceń

Książka pod koniec zeszłego rokuTopologie zespołu”, który proponuje ramy opisu topologii poleceń. Zainteresowało nas, czy dotyczy to rosyjskich firm. I zadaliśmy pytanie: „Jakie wzorce znajdujesz?”.

Zespoły ds. infrastruktury obserwuje się u połowy respondentów, a także osobne zespoły ds. rozwoju, testowania i eksploatacji. Oddzielne zespoły DevOps odnotowały 45%, wśród których częściej spotyka się przedstawicieli High. Następnie pojawiają się zespoły międzyfunkcyjne, które są również bardziej powszechne w High. Oddzielne polecenia SRE pojawiają się w profilach Wysoki, Średni i są rzadko spotykane w profilu Niski:

Współczynnik DevQaOps

To pytanie widzieliśmy na FaceBooku od lidera zespołu platformy Skyeng – interesował go stosunek programistów, testerów i administratorów w firmach. Zapytaliśmy o to i przyjrzeliśmy się odpowiedziom opartym na profilach: Wysocy przedstawiciele mają mniej inżynierów ds. testów i operacji na każdego programistę:

Plany na rok 2021

W planach na kolejny rok respondenci odnotowali następujące działania:

Tutaj możesz zobaczyć skrzyżowanie z konferencją DevOps Live 2020. Dokładnie przejrzeliśmy program:

• Infrastruktura jako produkt
• Transformacja DevOps
• Dystrybucja praktyk DevOps
• DevSecOps
• Kluby przypadków i dyskusje

Czas naszej prezentacji nie wystarczy jednak na omówienie wszystkich tematów. Pozostawione za kulisami:

• Platforma jako usługa i jako produkt;
• Infrastruktura jako kod, środowiska i chmury;
• Ciągła integracja i dostarczanie;
• Architektura;
• wzorce DevSecOps;
• Zespoły platformowe i wielofunkcyjne.

Zgłoś dostaliśmy obszerny, 50 stron, i można go zobaczyć bardziej szczegółowo.

Podsumowując

Mamy nadzieję, że nasze badanie i raport zainspirują Cię do eksperymentowania z nowymi podejściami do programowania, testowania i operacji, a także pomogą Ci nawigować, porównywać się z innymi uczestnikami badania i identyfikować obszary, w których możesz ulepszyć własne podejście.

Wyniki pierwszego badania stanu DevOps w Rosji:

• Kluczowe wskaźniki. Odkryliśmy, że kluczowe metryki (czas dostarczania, częstotliwość wdrożeń, czas przywracania i niepowodzenia zmian) są odpowiednie do analizy efektywności procesów programowania, testowania i operacji.
• Profile Wysoki, Średni, Niski. Na podstawie zebranych danych możemy wyróżnić statystycznie różne grupy Wysokie, Średnie, Niskie o charakterystycznych cechach w zakresie metryk, praktyk, procesów i narzędzi. Reprezentanci profilu High wykazują lepsze wyniki niż Low. Bardziej prawdopodobne jest, że osiągną i przekroczą swoje cele.
• Wskaźniki, pandemia i plany na 2021 rok. Szczególnym wskaźnikiem w tym roku jest to, jak firmy radziły sobie z pandemią. Wysokim przedstawicielom powiodło się lepiej, doświadczyli większego zaangażowania użytkowników, a głównymi przyczynami sukcesu były wydajne procesy rozwoju i silna kultura inżynierska.
• Praktyki DevOps, narzędzia i ich rozwój. Główne plany firm na najbliższy rok to rozwój praktyk i narzędzi DevOps, wprowadzenie praktyk DevSecOps oraz zmiany w strukturze organizacyjnej. A skuteczne wdrażanie i rozwój praktyk DevOps odbywa się za pomocą projektów pilotażowych, tworzenia społeczności i centrów kompetencji, inicjatyw na wyższych i niższych poziomach firmy.

Chcielibyśmy usłyszeć Twoją opinię, historie, opinie. Dziękujemy wszystkim, którzy wzięli udział w badaniu i zapraszamy do udziału w przyszłym roku.

Źródło: www.habr.com