Metryki DevOps

Metryki devops pozwalają analizować wydajność potoku dostarczania oprogramowania i pomagają szybko identyfikować oraz usuwać wszelkie wąskie gardła w procesie. Mogą być one wykorzystywane zarówno do śledzenia poziomu zdolności technologicznych, jak i wydajności procesów IT.

Miary i metryki DevOps

Pojęcie metryki oprogramowania i jej cechy


Zacznę od kwestii definicyjnych. W codziennej komunikacji zamiennie stosuje się pojęcie metryki i miary oprogramowania. W praktyce te terminy mają jednak różne znaczenie. Metryka oprogramowania jest bowiem miarą pewnej cechy oprogramowania lub specyfiki sposobu jego budowy / dostarczenia. 


Aby metryka była użyteczna, powinna charakteryzować się kilkoma cechami:

  • prostotą (być łatwa do policzenia i wytłumaczenia);
  • jednoznacznością (nie powinna zostawiać wątpliwości interpretacyjnych);
  • spójnością pod względem użytych jednostek (aby nie porównywać przysłowiowych „gruszek i jabłek”);
  • niezależnością od technologii wytwórczej, w szczególności od języka programistycznego;
  • dostarczać wartość (na jej podstawie można podejmować określone działania doskonalące / zarządcze).


Metryki dotyczące DevOps podzieliłem na dwie kategorie – „rekomendowane” i „takie sobie”.


Jeżeli metryka znalazła się na liście rekomendowanych oznacza to, że w literaturze fachowej (książki, blogi) jak i w praktyce (mojej oraz innych ekspertów dziedzinowych) jest ona postrzegana jako mająca sens - jest stosowanie dostarcza wartość.


Metryk z listy „takie sobie” nie przekreślam od razu i nie twierdzę, że są one z gruntu złe. W przypadku niektórych organizacji mogą mieć one sens – ale co do zasady raczej nie są zalecane do stosowania, bo nie dostarczają one wartości (chociaż dobrze brzmią).


Metryki rekomendowane


Częstość wdrażania

Metryka ta pokazuje jak często organizacja jest w stanie wdrażać kod na produkcję - tzn. jak czas potrzebny na wdrożenie, przetestowanie, dostarczenie i wdrożenie na produkcję kodu. W przypadku organizacji, które mają efektywnie wdrożone podejście DevOps, tym możliwa częstotliwość wdrążania zmian jest większa (uwaga: możliwa częstotliwość nie jest tożsama z koniecznością realizacji takich wdrożeń).


Czas realizacji zmian

Metryka ta pokazuje ile czasu zajmuje organizacji wprowadzanie zmian w oprogramowaniu na produkcję. Aby go zmierzyć, zespół wytwórczy musi jasno określić początek i koniec pracy (np. mierzalny czas od zgłoszenia potrzeby zmiany do wdrożenia produkcyjnego). Celem tego wskaźnika jest przyspieszenie wdrożenia zmian poprzez automatyzację i działania optymalizacyjne (np. poprzez optymalizację integracji testów i automatyzacji).


Średni czas przywracania działania (Mean time to recovery - MTTR)

Metryka ta pokazuje ile czasu zajmuje przywrócenie pełnej funkcjonalności niedziałającego oprogramowania. Im bardziej proces wytwarzania oprogramowania uwzględnia kontekst "ops" (a firma ma odpowiednie narzędzia do monitoringu) tym bardziej wartość tej metryki jest mniejsza.


Liczba awaryjnych zmian

Metryka ta pokazuje jaki jest odsetek zmian w oprogramowaniu wprowadzonych na produkcję, które są źródłem awarii (błędów). Im bardziej wygrzany i "szczelny" jest proces SDLC tym liczba pojawiających się awarii jest / powinna być mniejsza. Czasami ta metryka określana jest mianem "Metryką ucieczki błędów".


Średni czas do wykrycia błędu (Mean time to detection - MTTD)

Metryka ta przedstawia, ile średnio czasu upływa do wykrycia poważnych błędów. Kiedy pojawiają się błędu na produkcji, istotne jest, aby móc je szybko zidentyfikować. Ostatnią rzeczą, jaką chce organizacja, to poważna, szeroka awaria kluczowego oprogramowania o której dowiadujemy się późno. Krótszy czas do wykrycia błędu, oznacza, że Krótszy MTTD to znak, że dział obsługi szybko wykrywa poważne zdarzenia.


Przepustowość

Metryka dotycząca przepustowości przedstawia średnią liczbę uruchomień przepływu pracy na dzień. Przepływ pracy jest wyzwalany, gdy deweloper dokonuje aktualizacji bazy kodu w udostępnionym repozytorium. Przekazanie do systemu kontroli wersji (VCS) wyzwala potok ciągłej integracji (CI), który zawiera przepływ pracy.


Metryki takie sobie


Rozmiar wdrożenia

Metryka przedstawia zakres pracy, który został dostarczony w ramach danego wdrożenia. Może być on mierzony np. liczbą story points lub liczbą „zużytych” dni prac programistów. Metryka ta nie przedstawia jednak wartości biznesowej dostarczonej przez dane wdrożenie.


Średni czas wdrożenia

Metryka przedstawia ile czasu zajmuje faktyczne wdrożenie oprogramowania na produkcję. De-facto jest to metryka zawierająca się w metryce dotyczącej czasu realizacji zmiany. Jest ona głównie interesująca dla DevOps Inżyniera / DevOps Architekta.


% zdanych testów automatycznych

Metryka przedstawia jaki % z przygotowanych testów automatycznych przechodzi. Metryka ta może by interesująca dla zespołu deweloperskiego, gdyż pokazuje jak często zmiany w kodzie powodują, że testy automatyczne kończą się niepowodzeniem.


Podsumowanie


Główne cele wdrażania DevOps to zwiększenie szybkości dostarczania oprogramowania, zapewnienie jego wysokiej jakości oraz zapewnienie wydajności działania na produkcji. Warto o tym pamiętać tworząc zestaw metryk dla DevOps, które będą stosowane w Państwa organizacji.

Daj znać

Co sądzisz o naszym artykule? Czy powinniśmy coś w nim zmienić? Rozszerzyć go?