Jakie kluczowe wskaźniki wydajności (KPI) są używane do pomiaru DevOps?

Staram się kierować dobrymi zachowaniami w ramach programu transformacji DevOps. Aby to wesprzeć, staram się zidentyfikować przydatne parametry wokół dyscyplin operacyjnych:

• Zarządzanie problemami i incydentami
• Zarządzanie pojemnością
• Zarządzanie zmianami i wydaniami

Aby być absolutnie jasnym, są to funkcje, które kiedyś należały do ​​organizacji operacyjnej i są teraz własnością organizacji Agile / DevOps. Istnieją istniejące kluczowe wskaźniki wydajności, które prowadzą do złych zachowań:

• Czas do zakorzenienia Analiza przyczyny zakończona:
  • Prowadzi niekompletne RCA tylko po to, aby wprowadzić je do systemu na czas.
• Czas trwania testu:
  • Wyłącza długotrwałe testy, niezależnie od ich wartości biznesowej.
• Średnie wykorzystanie usług w chmurze:
  • Zachęca do nadmiernego zaangażowania zasobów obliczeniowych, co skutkuje długim czasem reakcji

Jakie kluczowe wskaźniki wydajności można zastosować, aby zachęcić do dobrego zachowania w programie DevOps?

Nie sądzę, żeby istniały jakieś „uniwersalne” KPI DevOps. Na przykład prędkość jest świetna, chyba że nie jest kluczowym czynnikiem napędzającym Twoją firmę. Amazon dba bardzo o prędkość, ponieważ ma masową operację detaliczną. Jest to mniej ważne w przypadku małej aplikacji ze 100 użytkownikami.

Nasuwa się pytanie: w jaki sposób możesz wybrać najlepszą KPI istotnych dla Twojej firmy? To proces badań i odkrywania, który obejmuje całe Twoje przedsiębiorstwo.

Czym się przejmujesz

• Jakość
• Niezawodność
• Konserwowalność
• Prędkość
• Doskonalenie procesów
• Poziomy usług

Co utrzymuje twoich interesariuszy w nocy? Co decyduje o tym, czy zarabiasz pieniądze w tym kwartale, czy nie? Powyższa lista może zawierać niektóre z tych rzeczy lub nie. Zrób listę, a następnie wymyśl, jak dopasować zachęty w każdym dziale, aby je osiągnąć.

Zachęty wpływają na zachowanie, więc wspólnie decyduj o celach SMART. Wybierz dwa lub trzy elementy ze swojej burzy mózgów i rozpocznij cykl pomiaru / naprawy dla każdego. Nie wybieraj zbyt wielu naraz - bardziej prawdopodobne jest odniesienie sukcesu poprzez skupienie się na dwóch lub trzech rzeczach.

DevOps nie ma żadnego KPI . To byłoby jak pytanie o KPI Miłości. Ale niektóre z rzeczy, o których mowa ( problem i Zarządzanie incydentami , zdolności zarządzania , zarządzanie zmianą i Release ) mają dobrą KPI, z których niektóre są w oparciu o teorię za devops.

Zasadniczo dla każdego procesu biznesowego można utworzyć mapę łańcucha wartości opisującą przepływ wartości od klienta , przez przedsiębiorstwo z powrotem do klienta . Cała pętla musi zawsze zaczynać się i kończyć u klienta, ale czasami w organizacji usługowej klient może być wewnętrzny. Przepustowość wartości dzięki takiej sieci może być dobrym sposobem, aby zaprojektować KPI w sposób zabezpieczonej przed sfałszowaniem. Mierzenie dowolnego wskaźnika KPI w dowolnym pojedynczym ogniwie łańcucha wartości ma sens tylko wtedy, gdy to konkretne łącze stanowi wąskie gardło procesu, a Ty próbujesz wykorzystać lub poprawić wąskie gardło.

Częstym problemem związanym z KPI jest sytuacja, gdy zaczyna się on w połowie łańcucha. Na przykład proces zmiany i wydania często rozpoczyna się od programistów, a kończy na wdrożeniu. Ten proces wykluczał:

• Klient ma problem
• Zespół pomocy technicznej identyfikujący problemy
• Zespół produktu definiujący problem zaległości
• Zespół rozwiązań dostosowujący wdrożenie dla klienta
• Klient realizujący wartość z rozwiązania

Problem polega na tym, że sam pomiar czasu cyklu może prowadzić do dwóch głównych problemów:

1. Wąskie gardło występuje w którejkolwiek z wykluczonych części wymienionych powyżej, a Twoi klienci nie zdają sobie sprawy z wartości i nie osiągasz przychodów proporcjonalnych do szybkości twojego cyklu. Tak więc, choć Twoja inżynieria jest doskonała, twój biznes cierpi.

2. Odłączenie się od klientów sprawi, że cykl wydawania będzie pusty - nie wytwarzając żadnej wartości, pomimo wprowadzenia zmian - lub nawet przeciwstawi się potrzebom klientów, a praca, którą wykonasz, może mieć negatywną wartość biznesową.

Innym problemem związanym z KPI jest to, że podczas rozpoczynania i kończenia pracy z klientem może on nie mierzyć wartości dla klienta. Dobrym przykładem może być proces reagowania na problemy i incydenty oraz MTTR (średni czas naprawy) jako KPI. Czy problem w ogóle dotyczy kogokolwiek? Jaka jest wartość dla klientów? Możesz mieć doskonały MTTR wynoszący 3 godziny w przypadku ponad 100 incydentów. Ale jeśli większość z nich miała charakter wewnętrzny, nie miała wpływu lub miała minimalny wpływ na klientów, i została rozwiązana w ciągu kilku minut, podczas gdy jeden duży incydent z ogromnym wpływem na klienta trwał 3 dni, wartość biznesowa jest niższa niż w przypadku 1-dniowego MTTR, ponieważ zignoruj ​​większość wewnętrznych incydentów, ale odpowiedziałeś na ogromny incydent z klientem w ciągu 1 godziny.

UWAGA: W przypadku klienta wewnętrznego, w przypadku procesu biznesowego zespołu wsparcia, wartość pochodna nie jest wartością pracy dla klienta wewnętrznego, ale wartością uzyskaną przez firmę w wyniku odblokowania klienta wewnętrznego w jego własnym procesie biznesowym. Odblokowanie zespołu, który jest wąskim gardłem we własnym procesie, ma wyższą wartość niż odblokowanie zespołu lub wąskiego gardła. Wszystkie KPI takiego zespołu wsparcia muszą uwzględniać wartość biznesową w swoich obliczeniach.

1. Częstotliwość wdrażania
2. Szybkość wdrożenia
3. Wskaźnik powodzenia wdrożenia
4. Jak szybko usługa może zostać przywrócona po nieudanym wdrożeniu
   I na koniec
5. Kultura DevOps, której tak naprawdę nie można zmierzyć