Kilka lat temu wiele organizacji postrzegało DevOps jako obiecujący eksperyment, a nie główne podejście do tworzenia oprogramowania. DevOps to obecnie sprawdzony i potężny zestaw praktyk i narzędzi programistycznych i wdrożeniowych, które mogą przyspieszyć wydawanie nowych produktów i zwiększyć produktywność. Co ważniejsze, wpływ DevOps ma wpływ na ogólny rozwój biznesu i zwiększoną rentowność.
Zespół przetłumaczone najciekawsze z , opracowane przez ekspertów DevOps Research & Assessment (DORA). W badaniu wzięło udział 31 000 specjalistów z całego świata. Przyjrzyjmy się, co zmieniło się w branży w 2019 roku i jak firmy mogą poprawić efektywność dostarczania oprogramowania.
Jak branża i wielkość firmy wpływają na stan DevOps
Badanie nie wykazało korelacji między wynikami DevOps a branżą organizacji, z wyjątkiem handlu detalicznego, który radził sobie nieco lepiej. Wynika to w szczególności z konieczności szybkiego reagowania sprzedawców detalicznych na wahania popytu i potrzeby klientów. Według badania, wysoki poziom DevOps może osiągnąć każda firma, zarówno w sektorze finansowym, jak i sektorze publicznym.
Wydajność DevOps w firmach zatrudniających powyżej 5000 pracowników była niższa niż w firmach zatrudniających mniej niż 5000 pracowników. Najprawdopodobniej wynika to z faktu, że duże organizacje mają większe procesy, ściślejszą kontrolę i bardziej złożoną architekturę systemów informatycznych, co wprowadza opóźnienia w procesie tworzenia i wdrażania kodu. Jednocześnie eksperci uważają, że skala firmy nie stoi na przeszkodzie sukcesowi w budowaniu DevOps, po prostu w niektórych przypadkach może wymagać większego wysiłku.
Jak ocenić poziom DevOps w firmie
Eksperci porównali procesy DevOps do benchmarku, dzieląc respondentów ankiety na cztery grupy: najlepszych, dobrych, przeciętnych i słabych.
Na potrzeby raportu wykorzystaliśmy cztery kluczowe wskaźniki do oceny efektywności DevOps: czas potrzebny na zakończenie zmian w rozwoju oprogramowania, częstotliwość wdrożeń, wskaźnik awaryjności i czas odzyskiwania.
Cztery poziomy DevOps – oceń, gdzie jest Twoja firma:
Miernik służący do oceny efektywności dostarczania oprogramowania dla głównych usług i aplikacji firmy
Zespoły z najlepszymi wynikami
Zespoły z dobrymi wynikami
Przeciętne zespoły
Zespoły o słabych wynikach
Częstotliwość wdrażania
Jak często firma wdraża kod w środowisku produkcyjnym lub udostępnia go użytkownikom końcowym.
Na życzenie kilka wdrożeń dziennie
Od raz dziennie do raz w tygodniu
Od raz w tygodniu do raz w miesiącu
Raz w miesiącu/kilka miesięcy
Zmień czas wykonania
Ile czasu zajmuje przejście od wersji testowej do oprogramowania działającego pomyślnie w środowisku produkcyjnym?
Za niecały dzień
Od jednego dnia do tygodnia
Od tygodnia do miesiąca
Od miesiąca do sześciu miesięcy
Czas przywracania usługi
Ile czasu zajmuje przywrócenie usługi po incydencie lub błędzie wpływającym na użytkowników.
Mniej niż godzinę
W ciągu dnia
W ciągu tygodnia
Od tygodnia do miesiąca
Zmień wskaźnik awaryjności
Jaki procent aktualizacji lub nowych wydań powoduje pogorszenie jakości usług i wymaga poprawek?
0-15%
0-15%
0-15%
46-60%
Badanie ujawniło następujący trend: liczba zespołów osiągających najlepsze wyniki wzrosła niemal trzykrotnie, z 7% wszystkich respondentów w 2018 r. do 20% w 2019 r.
Podział zespołów programistycznych według poziomu wydajności.
W porównaniu do zespołów z grupy o niskiej wydajności, zespoły DevOps o wysokiej wydajności:
- Wykonaj 208 razy więcej wdrożeń kodu.
- Spędził 106 razy mniej czasu na wdrażaniu kodu.
- Awarie spotykaliśmy 7 razy rzadziej.
- Oprogramowanie po awariach zostało przywrócone 2,604 razy szybciej.
Ponadto zespoły DevOps o wysokiej wydajności mają dwukrotnie większe prawdopodobieństwo osiągnięcia lub przekroczenia wskaźników wydajności organizacji niż zespoły o niskiej wydajności.
Wielu ekspertów uważa, że nie da się osiągnąć wzrostu wszystkich wskaźników jednocześnie i trzeba pójść na kompromis. Dlatego niektórzy uważają, że zwiększenie szybkości wydań może negatywnie wpłynąć na niezawodność procesu dostarczania oprogramowania i świadczenia usług. Badania wykazały jednak, że szybkość i spójność wyników nie wykluczają się wzajemnie.
Nie widzę nic zaskakującego we wzroście liczby zespołów DevOps, to naturalne: filozofia DevOps jest teraz popularna, a liczba startupów rośnie.
Jednak moim zdaniem eksperci wybrali nie do końca prawidłowe parametry do oceny efektywności DevOps.
Ocenianie tego na podstawie szybkości wdrażania kodu jest co najmniej dziwne. Dotyczy to tylko startupów, gdzie kluczowym parametrem będzie szybkość wprowadzenia produktu na rynek, a często produkt wprowadzany jest na rynek w postaci surowej. W takich warunkach istotne są mechanizmy przyspieszające rozwój i dostawę do produkcji. Jednak w przypadku uznanego oprogramowania, takiego jak oprogramowanie finansowe lub medyczne, parametr wskaźnika awaryjności może nie istnieć – awarie mogą być niedopuszczalne.
Podobnie jest z czasem przywracania usług: dla każdej rozwiniętej usługi należy go liczyć w sekundach, jednak w przypadku wielu usług przestój usług jest nie do przyjęcia, w tym celu wymyślono technologie płynnego wdrażania (np. green/blue).
Nie należy też skupiać się na liczbie wdrożeń kodu – zależy to od potrzeb i kompetencji zespołu programistów. Jeśli wdrożenie wiąże się z dodaniem nowej funkcjonalności, to jedno, ale jeśli wiąże się z poprawieniem błędów popełnionych podczas poprzednich wdrożeń, to już coś zupełnie innego.
Denis Romanenko, niezależny ekspert w Mail.ru Cloud Solutions
Jak usprawnić procesy DevOps
W raporcie przedstawiono dwa obszary, które pomogą ulepszyć DevOps: zwiększenie efektywności tworzenia i dostarczania oprogramowania oraz poprawa produktywności pracowników.
Każdy z obszarów zawiera własne komponenty, dzięki którym można osiągnąć zamierzony cel.
Według raportu kluczem do transformacji cyfrowej jest kultura korporacyjna. Wysoko wydajne zespoły DevOps potrzebują kultury zaufania i bezpieczeństwa psychicznego, poczucia wydajności i jasnych celów. To środowisko pozwala członkom zespołu podejmować świadome decyzje, wyrażać swoje opinie i wykazywać się większą kreatywnością.
Technologie chmurowe, ciągłe dostarczanie, testowanie odzyskiwania po awarii i zarządzanie zmianami również pomogą poprawić efektywność tworzenia i dostarczania oprogramowania. Produktywność można zwiększyć inwestując w proste w użyciu narzędzia, zmniejszając dług techniczny – czyli zmniejszając odsetek nieefektywnego kodu i przestarzałej technologii – organizując korporacyjną bazę wiedzy i dostęp do rozwiązań zewnętrznych.
Myślę, że metodologia i ideologia DevOps polega właśnie na tym, że procesy te nie są zależne od warunków zewnętrznych, takich jak chmura czy własny sprzęt. Chmura sama w sobie jest niczym więcej niż narzędziem, w niektórych miejscach pomoże, w innych przeszkodzi lub nie będzie popytu.
Denis Romanenko, niezależny ekspert w Mail.ru Cloud Solutions
Poniżej przyjrzymy się niektórym elementom poprawy efektywności zespołów DevOps.
Technologie chmurowe umożliwiają sukces DevOps
W 2019 roku coraz więcej organizacji wybiera rozwiązania chmurowe, które znacząco zwiększają produktywność zespołów DevOps.
Z jakich infrastruktur korzystają zespoły DevOps?
DORA stwierdziła, że 80% respondentów miejsce . Jednak tylko 29% respondentów wdrożyło wszystkie pięć podstawowych cech chmury opracowanych przez Narodowy Instytut Standardów i Technologii — najważniejszy standard oceny wartości chmury w ramach DevOps.
Charakteryzacja
Procent użytkowników
Samoobsługa na żądanie
Konsumenci mogą automatycznie udostępniać zasoby obliczeniowe
w razie potrzeby, bez udziału dostawcy.
57%
(+ 11% od 2018 r.)
Szeroki dostęp do sieci
Możliwości chmury są dostępne na różnych platformach,
takich jak telefony komórkowe, tablety, laptopy i stacje robocze.
60%
(+ 14% od 2018 r.)
Puli zasobów
Zasoby dostawcy są łączone w model wielodostępny, w którym zasoby fizyczne i wirtualne są przydzielane dynamicznie na żądanie.
58%
(+ 15% od 2018 r.)
Skalowalność i elastyczność
Zasoby skalują się w poziomie lub w pionie na żądanie, są praktycznie nieograniczone i mogą być wydawane w dowolnej ilości w dowolnym momencie.
58%
(+135 od 2018 r.)
przezroczystość
Systemy chmurowe automatycznie monitorują, optymalizują i raportują wykorzystanie zasobów w zależności od rodzaju usługi: przechowywania i przetwarzania danych, wielkości ruchu,
aktywnych kont użytkowników.
62%
(+ 14% od 2018 r.)
Platforma jako usługa (PaaS) w coraz większym stopniu zmierza w stronę modelu wdrażania skupionego wokół kontenerów. Platformy chmurowe ułatwiają wdrażanie oprogramowania, więc zespoły muszą się martwić jedynie o uruchomienie samego kodu aplikacji. Skalowanie, planowanie zasobów, administracja i utrzymanie infrastruktury również przechodzą na dostawców.
Dla dostawców usług w chmurze świadczenie różnorodnych usług staje się uniwersalnym standardem: tworzenie sieci maszyn wirtualnych, zarządzanie tożsamością i dostępem (IAM), przechowywanie i bazy danych, uczenie maszynowe, Internet rzeczy (IoT), rozwiązania kontenerowe, rozwiązania bezpieczeństwa i inne .
Klienci dostawców usług chmurowych płacą jedynie za wykorzystane zasoby, co zapewnia przejrzystość kosztów, w przeciwieństwie do tradycyjnych centrów danych, w których uzyskanie informacji o kosztach rozwoju jest trudne lub niemożliwe. Respondenci z firm, które spełniają wymienione powyżej cechy chmury, 2,6 razy częściej dokładnie szacują koszt uruchomienia oprogramowania, 2 razy częściej rozumieją, które aplikacje wymagają więcej zasobów i 1,65 razy częściej mieszczą się w budżecie IT.
Czasami okazuje się, że wynajęcie kompetentnego specjalisty i przejęcie przydzielonej pojemności w centrum danych jest bardziej opłacalne niż płacenie za chmurę. To, która opcja jest lepsza, zależy od profilu i skali firmy, dostępności własnej kadry specjalistów IT i wiedzy specjalistycznej. Chmura jest wygodna na przykład przy zakładaniu działalności gospodarczej lub gdy firma nie posiada własnego działu IT. W przypadku skalowania bardziej opłacalne może być utrzymanie całości lub części infrastruktury lokalnie.
Denis Romanenko, niezależny ekspert w Mail.ru Cloud Solutions
Praktyki techniczne DevOps
Wiele organizacji chcących wdrożyć DevOps szuka zestawu wytycznych lub najlepszych praktyk. Nie ma jednak dwóch takich samych firm, dlatego to, jakie praktyki wybrać, zależy od aktualnej kondycji przedsiębiorstwa i jego celów.
Biorąc to pod uwagę, istnieją ogólne obszary, które mogą pomóc poprawić wydajność DevOps: niektóre są opracowywane na poziomie zespołu, inne wymagają wysiłku na poziomie organizacji.
Jakie obszary wzrostu są wyróżnione dla zespołów DevOps w 2019 roku:
Na poziomie organizacji
- luźno powiązana architektura
- wdrożenie zmian
- wsparcie kodu
Na poziomie drużyny
- ciągła integracja
- automatyzacja testów
- automatyzacja wdrażania
- monitoring
- rurociąg rozwojowy
Na poziomie zespołu i organizacji
- korzystanie z usług w chmurze
- testowanie odzyskiwania po awarii
Badanie potwierdziło pozytywny wpływ luźno powiązanej architektury na wydajność DevOps.
Architektura luźno powiązana polega na tym, że zespoły mogą niezależnie testować, wdrażać i zmieniać systemy na żądanie, niezależnie od innych zespołów, bez dodatkowego wsparcia, zasobów, zatwierdzenia i przy mniejszej liczbie informacji zwrotnych. Pozwala to na wydajniejszą pracę, ale wymaga wysokiego poziomu organizacji i zarządzania.
Takie podejście jest możliwe tylko w przypadku startupów i z pewnymi zastrzeżeniami. W innych firmach sytuacja może wyglądać inaczej. Dobry przykład: bankowość/fintech. Można tam stosować wyłącznie autorskie rozwiązania, ale zastosowane zostaną praktyki DevOps.
Denis Romanenko, niezależny ekspert w Mail.ru Cloud Solutions
Odnoszące sukcesy zespoły DevOps automatyzują wszystko
pozwala na wypuszczenie usług i aplikacji do produkcji przy niższych kosztach i ryzyku, a także wsparcie wydań zgodnie z celami organizacji.
Pomyślny proces CI/CD oznacza również, że zespoły mogą na żądanie wdrażać zmiany w środowisku produkcyjnym, uzyskiwać natychmiastową informację zwrotną na temat jakości wdrożenia i szybko reagować na nie, aby usprawnić kolejny cykl wdrożeniowy.
Z raportu wynika, że odnoszące sukcesy zespoły DevOps inwestują w szeroką gamę wspierających procesów, praktyk i narzędzi:
- 92% korzysta z automatycznych narzędzi montażowych;
- 87% korzysta z automatycznych testów jednostkowych;
- 57% rozszerza automatyzację na testy akceptacyjne;
- 72% automatyzuje wdrożenia w środowiskach testowych, 69% robi to samo w przypadku wdrożeń w środowisku produkcyjnym;
- 69% integruje chatboty w procesie wdrażania;
- 57% integruje się z narzędziami monitorującymi.
Ważne jest, aby wybrać odpowiednie narzędzia i technologie
Budując złożone systemy i zarządzając infrastrukturą krytyczną dla biznesu, ważny jest dobór technologii:
- które są łatwe w użyciu zarówno przy pierwszym podłączeniu, jak i przy ciągłym użytkowaniu;
- które pomogą Ci osiągnąć Twoje cele.
W raporcie zbadano narzędzia wykorzystywane podczas wdrażania oprogramowania poprzez CI/CD oraz narzędzia do automatyzacji testów – to technologie leżące u podstaw DevOps.
Z jakich technologii korzystają zespoły DevOps:
Technologia
Zespoły o słabych wynikach
Przeciętne zespoły
Zespoły z dobrymi wynikami
Zespoły o wysokich wynikach
Połączenie zastrzeżonych, otwartych i komercyjnych produktów
30%
34%
32%
33%
Głównie rozwiązania open source i wysoce spersonalizowane rozwiązania pakietowe
17%
8%
7%
10%
Przeważnie rozwiązania typu open source i pakietowe z niewielkim dostosowaniem
14%
21%
18%
20%
Głównie pudełkowe rozwiązania komercyjne
8%
12%
8%
4%
Rozwój wewnętrzny i autorskie rozwiązania dla firmy
20%
6%
5%
6%
Przede wszystkim open source z silnym dostosowywaniem
6%
7%
5%
12%
Przede wszystkim open source z niewielkimi dostosowaniami
5%
12%
24%
15%
Użyteczność narzędzi ma znaczący wpływ na zdolność zespołu do maksymalizacji wartości wybranego stosu technologii: inżynierowie dysponujący łatwymi w użyciu technologiami 1,5 razy częściej należą do zespołów charakteryzujących się wysoką wydajnością.
Moim zdaniem ta tabela daje poczucie, że aby odnieść sukces w zespole DevOps, trzeba kierować się modą, a nie problemem technicznym.
Kompetentny specjalista wybiera narzędzia do zadania, a nie odwrotnie. Zawsze istnieje kilka narzędzi i podejść do rozwiązania każdego problemu. O konkretnym narzędziu decyduje: specyfika zadania; stopień znajomości tego narzędzia przez personel (jak wysoki jest próg wejścia, jeśli narzędzie jest nowe); element finansowy, jeśli występuje.
Denis Romanenko, niezależny ekspert w Mail.ru Cloud Solutions
Odzyskiwanie po awarii
Każda organizacja, której funkcjonowanie uzależnione jest od działania oprogramowania musi je posiadać . Raport pokazuje, jakie rodzaje testów odporności na katastrofy stosują różne firmy.
Jakie rodzaje testów stosują firmy w celu odzyskiwania danych po awarii?
Rodzaj testu
Zespoły o słabych wynikach
Przeciętne zespoły
Zespoły z dobrymi wynikami
Zespoły o wysokich wynikach
Przeciętny
Testy, które nie wpływają na rzeczywiste systemy
35%
26%
27%
30%
28%
Awaryjne przełączanie infrastruktury (w tym centra danych)
27%
43%
34%
38%
38%
Testowanie błędów aplikacji
25%
46%
41%
49%
43%
Symulacja incydentów polegających na zakłóceniu systemów testowych
18%
22%
23%
29%
23%
Symulacja zdarzeń polegających na zakłóceniu systemów pracy
18%
11%
12%
13%
12%
Tworzenie automatyzacji i systemów, które zakłócają
systemów produkcyjnych w sposób regularny i ciągły
9%
8%
7%
9%
8%
Tylko 40% respondentów co roku przeprowadza testy odzyskiwania po awarii, korzystając z jednej lub więcej z wymienionych metod. Jednocześnie firmy przeprowadzające testy odtwarzania po awarii mają wyższy poziom dostępności usług. Raport pokazuje, że wysokowydajne zespoły DevOps są 1.4 razy bardziej skłonne do włączania danych testowych odzyskiwania po awarii do swoich procesów tworzenia i wdrażania oprogramowania.
Ważne jest zapewnienie zespołom DevOps dostępu do informacji
Łatwe znajdowanie informacji umożliwiających rozwiązanie problemów może pomóc w utrzymaniu produktywności zespołów DevOps. Jest to szczególnie prawdziwe w dzisiejszym środowisku technologicznym, które składa się ze złożonych systemów.
Źródła takich informacji można podzielić na dwie grupy:
- Źródła wewnętrzne: dokumentacja firmowa dotycząca tworzenia i utrzymywania kodu, korporacyjne bazy wiedzy, repozytoria i nie tylko. Zespoły DevOps korzystające z wewnętrznych źródeł wiedzy były 1,73 razy bardziej produktywne.
- Źródła zewnętrzne: Wyszukiwarki i uzupełnianie stosu. Zewnętrzne zespoły DevOps były 1,67 razy bardziej produktywne. Technologie zewnętrzne zapewniają ogromną przewagę w nauce i rozwoju, zwłaszcza wykorzystanie chmur publicznych i narzędzi open source.
Dla firm ważne jest ograniczanie długu technologicznego
Dług techniczny obejmuje kod lub systemy ze znanymi, ale nienaprawionymi błędami; niewystarczający zasięg testów; kod lub projekt niskiej jakości; artefakty, które nie są używane, ale nie są usuwane; wdrożenia, których zespół nie jest w stanie skutecznie wesprzeć; przestarzałe technologie; niekompletna lub nieaktualna dokumentacja.
Eksperci odkryli, że dług techniczny negatywnie wpływa na wydajność DevOps. Zespoły z wysokim długiem technicznym były 1,6 razy mniej produktywne. Zespoły osiągające wysokie wyniki były 1,4 razy bardziej narażone na niski dług techniczny.
Kluczowe wnioski z badania stanu DevOps
- Odsetek zespołów DevOps o wysokiej wydajności wzrósł prawie trzykrotnie do 20%. Oznacza to, że firmy rozumieją obietnice stosowania praktyk usprawniających tworzenie i dostarczanie oprogramowania, a firmy coraz aktywniej wdrażają DevOps w swoich działach IT.
- Szybkie dostarczanie aplikacji i usług jest podstawą transformacji technologicznej i organizacyjnej. Szybkość i spójność wydań zwiększa zyski i zadowolenie klientów.
- Technologie chmurowe nadal są kluczem do osiągnięcia doskonałości dla zespołów DevOps. Wykorzystanie chmur pozwala na organizację dostarczania oprogramowania z wymaganą szybkością, zapewnia dostępność, skalowalność i wydajność infrastruktury.
- Efektywność zespołów DevOps można poprawić, zwracając uwagę na produktywność członków zespołu, zapewniając komfortową atmosferę psychologiczną i korzystając z wygodnych narzędzi.
- Zwiększanie szybkości wydawania wydań przy odpowiednim podejściu nie wpływa na stabilność usług i aplikacji firmy.
Źródło: www.habr.com