Jakie są metody pomiaru ROI dla DevOps?

24

DevOps jest złożony i obejmuje wiele niedeterministycznych aspektów, takich jak kultura i proces.
Jakie są sposoby mierzenia inicjatyw DevOps pod kątem sukcesu?
Jak udowodnić firmie, że dokonana inwestycja zwraca (lub oszczędza) prawdziwe dolary?

Dave Swersky
źródło
Hej Dave, zastanawiam się, co rozumiesz przez „pomiar”, zgodnie z jednym z tagów użytych w pytaniu. IMO (nie więcej), bardziej odpowiednie byłoby użycie (istniejącego) tagu „metrics”. Nie? Jeśli nie zgadzasz się (co jest w porządku ...), czy mógłbyś (krótko) wyjaśnić, co według ciebie różnica między tymi 2 tagami jest (lub powinna być)?
Pierre.Vriens
@ Pierre.Vriens Przypuszczam, że pomiar polega na zbieraniu danych, podczas gdy metryka jest czymś, co mierzysz. Usunąłem tag „pomiaru”, ponieważ prawdopodobnie jest nadmiarowy.
Dave Swersky

Odpowiedzi:

16

Świetne pytanie! Większość z nas wie, że inwestowanie w praktyki DevOps jest bardzo opłacalne z wielu powodów; jednak często nie usprawiedliwiamy DevOps samym wpływem na wynik końcowy.

Uwaga : jest to pytanie o charakterze opiniotwórczym, a moja odpowiedź jest podobnie wyrażona.

Tensibai mądrze zasugerował, że znajdziemy odpowiednie wskaźniki, a jako przykład wykorzystał czas na wprowadzenie na rynek. To świetne podejście do całościowego obrazu.

Jako alternatywne podejście, moje doświadczenie z licznikami fasoli polega na tym, że nie muszą one - lub niekoniecznie chcą - znać ogólny obraz, chcą jedynie dowodów odpowiedzialności budżetowej. Chcą zobaczyć trend we właściwym kierunku.

Oto tylko kilka zwycięstw fiskalnych:

  • obliczyć zaoszczędzone koszty serwera, wykorzystując automatyczne skalowanie w chmurze
  • w przypadku witryn generujących dochód ekstrapoluj koszt za minutę przestoju, a następnie pokaż poprawę MTTI i MTTR
  • ponownie w przypadku witryn generujących dochód oszacuj oszczędność kosztu za minutę, wykorzystując wysoce dostępną architekturę na podstawie wcześniejszych incydentów
  • jeśli ulepszyłeś kompilację i wdrażasz potok, pokaż, że zmniejszyłeś regresje i błędy produkcyjne spowodowane przez już wyśledzone błędy
  • jeśli wprowadziłeś ulepszenia w środowiskach testowych dla programistów, a nawet narzędzia i konfigurację na laptopach dla programistów, spójrz na historie zatwierdzania, aby zobaczyć, czy nowi inżynierowie wnoszą swój pierwszy wkład wcześniej po dołączeniu
  • wykonać pełne porównanie kosztów w chmurze i premii , podobnie jak ostatnio Gitlab , aby uzasadnić wydatki na infrastrukturę (inaczej oszczędności!)

Często wystarczające jest wykazanie, że jesteś świadomy pieniędzy i masz kilka wyraźnych wygranych. Z pewnością brakowało mi oczywistych przykładów; dodaj komentarze poniżej.

Woodland Hunter
źródło
2
Jestem za tym 1000%. Myślę, że zbliża się wielka zmiana w monitorowaniu: nie dbam już o to, ile procesora lub pamięci RAM jest używane w danym wystąpieniu, zależy mi na tym, ile płacę za grupę automatycznie skalowanych wystąpień z biegiem czasu. Nie obchodzi mnie, ile żądań może obsłużyć instancja, zależy mi na tym, ile kosztuje obsłużenie żądania. Ta zmiana myślenia może naprawdę pomóc w uzyskaniu lepszych wskaźników dla DevOps, w tym ROI.
Adrian
12

Kluczową miarą dla potoku DevOps jest Czas cyklu (zwany również czasem realizacji ). Jest to czas potrzebny na zmianę (lub prośbę o zmianę, śledzenie aż do powstania pomysłu). Najlepszą ilustracją tego pojęcia, jakie znam, jest książka „The Goal”, która mówi o tym w kontekście produkcyjnym.

Przydatna jest również częstotliwość wdrażania . Chcemy, aby wdrożenia były częste w potoku DevOps. Nie ma magicznego pomiaru „1 dzień jest dobry, 2 dni to zły” pomiar; będzie to wymagało kontekstu historycznego w projekcie, aby był znaczący.

Rozmiar wdrożenia : Mierzony w miarę, jak programiści mierzą pracę - historie użytkowników, punkty historii, quatloos, cokolwiek. Ponownie, chcesz zobaczyć trendy w czasie, a nie wartość bezwzględną.

Pomiędzy częstotliwością a rozmiarem jest historia do opowiedzenia. Czy nasze wydania stają się coraz rzadsze i większe? czemu? Czy stają się coraz mniejsze i częstsze? Znowu dlaczego?

Wyjaśniając, czy trend częstotliwości / wielkości jest dobry, będziemy również potrzebować Procent nieudanych wdrożeń . Odkrywanie „dlaczego” w tych trzech metrykach powie wiele o zdrowiu projektu.

Moim osobistym ulubionym, choć jest to miernikiem próżności, jest Czas na Trivial Deploy . Jeśli znalazłeś najmniejszą możliwą rzecz, którą warto wdrożyć na całej stronie ... może literówka w imieniu CEO ... jak szybko mógłbyś przejść z panicznej rozmowy telefonicznej na wdrożoną stronę? Mówię „próżność”, ponieważ tak naprawdę nie jest tak przewidywalna, jak to omawiają inne powyższe wskaźniki, ale sprawia, że ​​czuję się dobrze, kiedy podoba mi się ta wartość.

Jeśli przejdziemy do monitorowania, istnieje wiele różnych rzeczy, które możemy śledzić ... od wszechstronnych rzeczy, takich jak „ Uptime ”, po naprawdę niskie rzeczy, takie jak czas spędzony na regenerowaniu niestandardowego HTML w cyklu żądanie-odpowiedź ... ale nie są one specyficzne dla ustanowienia kultury DevOps.

Nie wiążą się one bezpośrednio z dolarami ... będzie to wymagało więcej wiedzy na temat twojej organizacji niż ja mogę zaoferować na takim forum; ale są kluczem do POCZĄTKU, aby odpowiedzieć na to pytanie. Gdy już wiesz, że możesz regularnie wypuszczać pracę na produkcję jako nie-wydarzenie, możesz zacząć sprawdzać, ile wysiłku marnowałeś wcześniej. Jak uczy książka „The Goal” (o produkcji rurociągów - jest to istotne), lokalna optymalizacja może wyglądać na oszczędność pieniędzy, ale ostatecznie tworzy po prostu wartość związaną z zapasami (niewdrożone funkcje).

Oprócz tej porady, powinieneś spojrzeć na raport State Of DevOps z ostatnich kilku lat. Jest pełen pomiarów dotyczących projektów z prawdziwego świata, które można naśladować.

David Bock
źródło
8

Kapitan oczywisty: skracając czas wprowadzania na rynek i defektów w wydaniach.

Aby rozszerzyć tę linię, zwykle pułapką jest zmiana organizacji bez żadnego odniesienia.

Zaangażowanie w zmianę kultury lub organizacji wiąże się z pewnym nakładem na szkolenie i zapoznanie ludzi z tą nową metodą, pociąga to za sobą koszty szkolenia, ale także pociąga za sobą spadek wydajności, ponieważ ludzie podczas sesji pociągowej nic nie produkują. To część inwestycyjna zmiany kulturowej.

Aby zmierzyć zwrot z inwestycji, musisz najpierw znaleźć odpowiednie wskaźniki, które należy poprawić (zrozumieć kosztowne, drogie lub źródło utraty zysków). Może to być krótszy czas wprowadzenia produktu na rynek, mniej łatek po każdym wydaniu, lepsze zaangażowanie klientów w Twój produkt. Odpowiednie dane będą ściśle zależały od Twoich produktów.

Pomiar ROI (jak szybko pokryłeś koszty szkolenia) oznacza, że ​​możesz faktycznie przedstawić ewolucję tych wskaźników, więc przed wprowadzeniem jakiejkolwiek zmiany musisz zdefiniować te wskaźniki i zmierzyć je w obiektywny sposób.
Gdy masz już prawdziwą ewolucję do pokazania, możesz stwierdzić, czy poprawiłeś coś w sposób, który pokrył koszty szkolenia i stał się bardziej opłacalny niż wcześniej.

Zwykle pułapką jest angażowanie zmiany przed zdefiniowaniem jakichkolwiek wskaźników, a tym samym oszacowaniem ROI na podstawie odczuć, a nie faktycznych danych.

Wydajność może być metryką, ale jej pomiar jest zwykle bardzo trudny do przeprowadzenia w obiektywny sposób i nie powinien być metryką pierwszej klasy dla tego rodzaju badań.

Tensibai
źródło
1

Spóźniłem się na grę tutaj, ale pomyślałem, że wejdę.

Nie możesz zarządzać tym, czego nie mierzysz, więc na początek, oto kluczowe wskaźniki, które zespoły programistów powinny śledzić w odpowiedzi na incydent:

  • Uptime% : całkowity% dostępnego czasu = [całkowity czas - przestój] / [całkowity czas]
  • MTTR : średni czas do rozwiązania = [przestój] / [# incydentów]
  • MTTA : średni czas do potwierdzenia = [całkowity czas do potwierdzenia] / [liczba incydentów]
  • MTBF : średni czas między awariami = [całkowity czas - przestój] / [liczba incydentów]

Te dane dają ci kontrolę stanu twoich operacji na wysokim poziomie i pomagają ci określić, gdzie musisz dalej się zagłębiać.

Spójrz na animację tablicy, aby uzyskać bardziej szczegółowe spojrzenie na ten temat.

Gdy poznasz swoje dane, możesz je podnieść w stosunku do kosztów przestoju . Możesz zacząć budować ROI swojego zespołu i ustawić pewne wskaźniki ilościowe dla ciągłego doskonalenia.

Yuan Cheng
źródło
Są to wskaźniki niezawodności, które są związane z DevOps, ale nie są wystarczające. Niezawodność to tylko jeden aspekt DevOps.
Phil
Dzięki @Phil. To dobra uwaga - w rzeczywistości są to wskaźniki skoncentrowane na niezawodności, która jest ważną częścią DevOps, ale z pewnością nie całą. Mamy nadzieję, że utrzymanie się na szczycie niezawodności jest dobrym punktem wyjścia, ale nie poprzestawaj na tym!
Yuan Cheng,