Artykuły
Samouczki
Interaktywne przewodniki
Metryki DevOps
Czym jest sukces w DevOps oraz dlaczego i jak go mierzyć
TOM HALL
Specjalista i praktyk DevOps
Stare powiedzenie, według którego nie można poprawić tego, czego nie się nie zmierzy, jest tak samo prawdziwe w przypadku DevOps, jak każdej innej praktyki. Aby osiągnąć to, co obiecuje DevOps — szybsze dostarczanie produktów o wyższej jakości — zespoły muszą zbierać, analizować i mierzyć liczne wskaźniki. Te wskaźniki DevOps dostarczają zespołom DevOps danych niezbędnych do monitorowania i kontrolowania pipeline'u prac programistycznych.
Czym są wskaźniki DevOps?
Wskaźniki DevOps to punkty danych, które bezpośrednio pokazują wydajność pipeline'u prac programistycznych DevOps oraz pomagają szybko zidentyfikować i usunąć wszelkie wąskie gardła w procesie. Wskaźniki te mogą być wykorzystywane do śledzenia zarówno możliwości technicznych, jak i procesów zespołowych.
W swej istocie DevOps koncentruje się na rozmywaniu granic między zespołami programistycznymi i operacyjnymi, umożliwiając lepszą współpracę między programistami a administratorami systemów. Wskaźniki umożliwiają zespołom DevOps mierzenie i ocenę wspólnych przepływów pracy oraz śledzenie postępów w osiąganiu celów wysokiego poziomu, takich jak poprawa jakości, przyspieszenie cykli wydawania i zwiększenie wydajności aplikacji.
Cztery kluczowe wskaźniki DevOps
Chociaż istnieje wiele wskaźników służących do pomiaru wydajności DevOps, poniżej przedstawiamy cztery kluczowe metryki, które powinien monitorować każdy zespół DevOps.
1. Czas wdrażania zmian
Jednym z najważniejszych wskaźników DevOps, jakie warto śledzić, jest czas wdrażania zmian. Czas wdrażania zmian, którego nie należy mylić z czasem cyklu (zob. niżej), to czas między momentem zatwierdzenia zmiany kodu w gałęzi głównej a osiągnięciem przez nią stanu wdrożenia. Może to być na przykład moment, gdy kod przejdzie wszystkie niezbędne testy wstępne.
2. Wskaźnik błędnych zmian
Wskaźnik błędnych zmian to procent zmian w kodzie, które wymagają bieżących poprawek lub innego rodzaju skorygowania po produkcji. Nie obejmuje on błędów wychwyconych w testach i naprawionych przed wdrożeniem kodu.
3. Częstotliwość wdrażania
Poznanie częstotliwości wdrażania nowego kodu w produkcji ma kluczowe znaczenie dla zrozumienia powodzenia praktyk DevOps. Wielu praktyków używa terminu „dostarczanie” w odniesieniu do zmian kodu, które są wydawane do przedprodukcyjnego środowiska stagingowego, a termin „wdrożenie” rezerwuje wyłącznie dla zmian kodu, które są wydawane w wersji produkcyjnej.
4. Średni czas przywrócenia
Średni czas odzyskiwania (MTTR) określa, ile czasu zajmuje przywrócenie sprawności po częściowym przerwaniu świadczenia usług lub całkowitej awarii. Jest to ważny wskaźnik do śledzenia, niezależnie od tego, czy przerwa w świadczeniu usług jest wynikiem niedawnego wdrożenia, czy odosobnionej awarii systemu.
Poznaj rozwiązanie
Narzędzia dla elitarnego zespołu DevOps
materiały pokrewne
Znaczenie struktury zespołów w DevOps
Jak mierzyć, wykorzystywać i doskonalić wskaźniki DevOps
Podobnie jak w przypadku innych elementów cyklu życia DevOps, do wskaźników DevOps zastosowanie ma kultura ciągłego doskonalenia Zdolność do otrzymywania szybkiej informacji zwrotnej na każdym etapie prac programistycznych w połączeniu z umiejętnością jej wdrażania i uprawnieniem do tego charakteryzuje wysokowydajne zespoły. Autorzy książki o DevOps pt. „Accelerate” zauważają, że cztery podstawowe wskaźniki wymienione powyżej są wspierane przez 24 zdolności, które powinny posiadać wydajne zespoły programistyczne. Poniżej omówimy większość z tych zdolności (CI/CD, automatyzacja testów, praca w małych partiach, monitorowanie i ciągłe uczenie się), ale polecamy lekturę „Accelerate”, aby dokładniej zapoznać się badaniami, na których oparto te praktyki.
Czas wdrażania zmian
Zespoły o wysokiej wydajności zazwyczaj mierzą czas wdrażania w godzinach, podczas gdy zespoły o średniej i niskiej wydajności mierzą go w dniach, tygodniach, a nawet miesiącach.
Automatyzacja testów, tworzenie oprogramowania oparte o gałąź główną i praca w małych partiach są kluczowymi elementami pozwalającym skrócić czas wdrażania. Praktyki te umożliwiają programistom szybkie otrzymywanie informacji zwrotnych na temat jakości zatwierdzanego przez nich kodu, dzięki czemu mogą zidentyfikować i naprawić wszelkie usterki. Długie czasy wdrażania są prawie pewne, jeśli deweloperzy pracują nad dużymi zmianami występującymi w oddzielnych gałęziach i stosują ręczne testowanie w kontroli jakości.
Wskaźnik błędnych zmian
Wskaźnik błędnych zmian dla zespołów o wysokiej wydajności mieści się w zakresie 0–15 proc.
Te same praktyki, które umożliwiają skrócenie czasu wdrażania — automatyzacja testów, tworzenie oprogramowania oparte o gałąź główną i praca w małych partiach — korelują ze zmniejszeniem wskaźników błędnych zmian. Wszystkie te praktyki znacznie ułatwiają identyfikację i naprawienie usterek.
Śledzenie i raportowanie wskaźników błędnych zmian jest ważne nie tylko w kontekście identyfikacji i naprawiania błędów, ale także po to, aby nowe wydania kodu spełniały wymagania dotyczące bezpieczeństwa.
Częstotliwość wdrażania
Zespoły o wysokiej wydajności mogą wdrażać zmiany na żądanie i często robią tak wiele razy dziennie. Zespoły o mniejszej wydajności często wdrażają jedynie co tydzień lub co miesiąc.
Możliwość wdrażania na żądanie wymaga zautomatyzowanego pipeline'u wdrażania, który wykorzystuje zautomatyzowane mechanizmy testowania i informacji zwrotnych, o których wspominaliśmy w poprzednich sekcjach, i który minimalizuje potrzebę interwencji człowieka.
Średni czas przywrócenia
Zespoły o wysokiej wydajności szybko przywracają działanie systemu po awariach — zwykle w mniej niż godzinę — podczas gdy zespoły o niższej wydajności mogą potrzebować na to nawet tygodnia.
Możliwość szybkiego przywrócenia sprawności po awarii wymaga szybkiego zidentyfikowania wystąpienia awarii oraz wdrożenia poprawek lub wycofania zmian, które do niej doprowadziły. Zwykle odbywa się to poprzez ciągłe monitorowanie stanu systemu i ostrzeżenie pracowników działu operacyjnego w przypadku awarii. Personel działu operacyjnego musi dysponować niezbędnymi procesami, narzędziami i uprawnieniami do rozwiązywania incydentów.
Nacisk na MTTR stanowi odejście od dawnej praktyki, która koncentrowała się na średnim czasie między awariami (MTBF). Odzwierciedla to większą złożoność nowoczesnych aplikacji, a tym samym zwiększone ryzyko awarii. Umacnia również praktykę ciągłego uczenia się i doskonalenia. Zamiast czekać, aż wdrożenie będzie „idealne” i odporne na awarie (które powodowały zresetowanie starej tablicy wyników MTBF), zespoły wdrażają w sposób ciągły. Odchodząc od obarczania winą osób, które „zaprzepaściły” „idealny” wynik MTBF, metodyka MTTR promuje perspektywę nieoceniającą, aby pomóc zespołom ulepszać procesy i narzędzia.
Inne powiązane wskaźniki
Innym istotnym wskaźnikiem jest czas cyklu, czyli czas, który zespół poświęca na pracę nad elementem, aż ten nie będzie gotowy do dostarczenia. W świecie programistycznym czas cyklu to okres od zatwierdzenia zadania przez deweloperów po wdrożenie kodu do produkcji. Ten kluczowy wskaźnik DevOps pozwala leadom projektów i kierownikom ds. inżynierii lepiej zrozumieć, które elementy pipeline'u prac programistycznych funkcjonują prawidłowo. Dzięki temu mogą oni lepiej dopasować swoją pracę do oczekiwań interesariuszy i klientów, przyspieszając realizację zadań przez zespół.
Raporty czasu cyklu umożliwiają leadom projektu ustanowienie punktu wyjścia dla pipeline'u prac programistycznych, który może być używany do oceny przyszłych procesów. Gdy zespoły optymalizują czas cyklu, deweloperzy zazwyczaj mają mniej prac w toku i mniej nieefektywnych przepływów pracy.
Zarządzanie produktem zgodnie z metodyką Lean koncentruje się na mapowaniu strumienia wartości, które stanowi wizualizację przepływu, od koncepcji produktu lub funkcji do jego dostarczenia. Wskaźniki DevOps dostarczają wiele istotnych punktów danych potrzebnych do efektywnego mapowania strumienia wartości i zarządzania nim, jednak trzeba je rozszerzyć o inne wskaźniki biznesowe i produktowe, aby uzyskać prawdziwie kompleksową ocenę. Na przykład wykresy spalania sprintów dają wgląd w skuteczność procesów szacowania i planowania, a wskaźnik Net Promoter Score pokazuje, czy ostateczny rezultat spełnia wymagania klientów.
Wnioski…
Ciągłe doskonalenie to podstawowa zasada zespołów praktykujących DevOps. Możliwość pomiaru i śledzenia wyników w zakresie czasu wdrażania zmian, wskaźnika błędnych zmian, częstotliwości wdrażania i MTTR pozwalają zespołom pracować szybciej i poprawiać jakość.
Atlassian Open DevOps zapewnia zespołom wszystko, czego potrzebują do opracowywania i obsługi oprogramowania. Zespoły mogą utworzyć odpowiadający im łańcuch narzędzi DevOps dzięki integracjom z produktami wiodących dostawców i aplikacjom ze sklepu Marketplace. Wypróbuj teraz.
Udostępnij ten artykuł
Następny temat
Zalecane lektury
Dodaj te zasoby do zakładek, aby dowiedzieć się więcej na temat rodzajów zespołów DevOps lub otrzymywać aktualności na temat metodyki DevOps w Atlassian.
Społeczność DevOps
Ścieżka szkoleniowa DevOps
