Jakie są metody pomiaru ROI dla DevOps?

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?

Ś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.

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ć.

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ń.

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.