Czym są wskaźniki DORA i jak wpływają na sukces DevOps?

Miary DORA to cztery kluczowe wymiary, które pomagają liderom zespołów zrozumieć skuteczność ich praktyk DevOps. Zespół DevOps Research and Evaluation (DORA) opracował metryki po sześciu latach badań nad pomyślnym wdrożeniem DevOps.

Mierzenie danych to najlepszy sposób na ocenę wpływu DevOps na Twoją organizację. Skupienie się na aspektach zidentyfikowanych przez DORA może otworzyć możliwości usprawnienia procesów i poprawy wydajności. W tym artykule wyjaśnimy, w jaki sposób każda z czterech metryk przyczynia się do sukcesu DevOps.

Częstotliwość wdrażania

Częstotliwość wdrażania mierzy, jak często wypychasz nowy kod do środowiska produkcyjnego. Ponieważ głównym celem DevOps jest wydajniejsze dostarczanie działającego kodu, częstotliwość wdrażania jest doskonałym punktem wyjścia do mierzenia sukcesu.

Możesz zebrać te dane, po prostu analizując, ile razy nowy kod został wdrożony w danym okresie. Następnie możesz szukać możliwości zwiększenia szybkości uwalniania bez poświęcania jakichkolwiek ogrodzeń, które zachowują standardy jakości. Używanie ciągłego dostarczania do automatycznego wdrażania kodu podczas scalania jest jednym ze sposobów na przyspieszenie przepływu pracy.

Idealna częstotliwość wdrażania zależy od typu budowanego systemu. Chociaż obecnie aplikacje internetowe są zazwyczaj dostarczane kilka razy dziennie, ta częstotliwość nie jest odpowiednia dla twórców gier, którzy tworzą wielogigabajtowe kompilacje.

W niektórych sytuacjach pomocne może być rozpoznanie tej różnicy poprzez nieco inne podejście do częstotliwości wdrażania. Możesz myśleć o tym jako o częstotliwości, z jaką możesz wdrażać kod, jeśli chcesz ograniczyć wydawanie nowej wersji w określonym czasie. Może to być wydajniejszy sposób mierzenia przepustowości, gdy rzeczywiste ciągłe dostarczanie nie jest odpowiednie dla Twojego projektu.

Zmień czas realizacji

Czas realizacji zmiany to interwał między zatwierdzeniem wersji kodu a wydaniem jej na produkcję. Ta metryka pokazuje opóźnienia, które występują podczas przeglądów kodu i iteracji po zakończeniu przez programistów oryginalnego sprintu.

Łatwo jest zmierzyć tę wartość. Musisz znaleźć czas, w którym programista podpisał zmianę, a następnie czas dostarczenia kodu do użytkowników. Czas wykonania to liczba godzin i minut między tymi dwiema wartościami.

Jako przykład rozważ prostą zmianę polegającą na wysyłaniu wiadomości e-mail z ostrzeżeniem o zabezpieczeniach po zalogowaniu się użytkowników. Deweloper kończy zadanie o godzinie 11:00 i przekazuje swoją pracę do oryginalnego repozytorium. O godzinie 12.00 recenzent odczytuje kod i przekazuje go do kontroli jakości. Do godziny 14:00 tester kontroli jakości zauważył literówkę w kopii e-maila. Deweloper zatwierdza poprawkę o 15:00, a kontrola jakości wprowadza ostateczną zmianę w środowisku produkcyjnym o 16:00. Czas na zakończenie tej zmiany wyniósł 5 godzin.

Środowisko wykonawcze służy do ujawniania nieefektywności w miarę przemieszczania się pracy między elementami. Chociaż standardy różnią się znacznie w zależności od branży i organizacji, długi średni czas realizacji może wskazywać na wewnętrzne tarcia i źle zaprojektowany przepływ pracy. Wydłużony czas wykonania może być również spowodowany słabą wydajnością programistów wykonujących pracę o niskiej jakości jako pierwszą iterację zadania.

Niektóre organizacje stosują różne pomiary czasu realizacji. Wiele osób wybiera czas, jaki upływa między uruchomieniem funkcji przez programistę a wprowadzeniem finalnego kodu do produkcji. Inni mogą spojrzeć jeszcze dalej i jako punkt wyjścia przyjąć czas, w którym o zmianę zażądał klient, klient lub menedżer produktu.

Metody te mogą dostarczać informacji, które są szerzej przydatne w firmie, poza zespołami inżynierskimi. Jednak interpretowanie DORA przy użyciu znaczników czasu zatwierdzenia ma jedną wielką zaletę: dane są automatycznie zatwierdzane przez narzędzie kontroli wersji, więc programiści nie muszą ręcznie rejestrować czasu rozpoczęcia każdego nowego zadania.

Zmień współczynnik odrzuceń

Wskaźnik niepowodzeń zmiany to procent wdrożeń produkcyjnych, które spowodowały incydent. Incydent to każdy błąd lub nieoczekiwane zachowanie, które powoduje awarię lub awarię klientów. Deweloperzy i operatorzy będą musieli poświęcić czas na rozwiązanie problemu.

Procent nieudanych zmian można obliczyć, dzieląc liczbę wykonanych wdrożeń przez liczbę nieudanych zmian. To drugie znaczenie uzyskuje się zwykle przez oznaczenie raportów o błędach w oprogramowaniu do zarządzania projektami wdrożeniowymi tym, które je przesłało.

Dokładne przypisanie incydentów do zmiany, która je spowodowała, może czasami być trudne, zwłaszcza jeśli masz dużą częstotliwość wdrażania, ale w wielu przypadkach programiści i zespoły triage mogą określić najbardziej prawdopodobny wyzwalacz. Inną kwestią może być ustalenie, co stanowi awarię: czy drobne błędy powinny zwiększać częstotliwość awarii, czy też interesują Cię tylko poważne awarie? Oba rodzaje problemów wpływają na postrzeganie Twojej usługi przez klientów, dlatego warto zachować kilka różnych wartości dla tego wskaźnika, z których każda odnosi się do innej klasy problemów.

Należy zawsze dążyć do tego, aby wskaźnik awaryjności był jak najniższy. Korzystanie z automatycznych testów, analizy statycznej i ciągłej integracji może pomóc w zapobieganiu wprowadzaniu uszkodzonego kodu do produkcji. Chroń swoje procesy za pomocą nowych narzędzi i praktyk, aby stopniowo zmniejszać liczbę awarii w miarę upływu czasu.

Czas na przywrócenie usługi

Niestety nie da się całkowicie wyeliminować awarii. W końcu napotkasz problem, który zaszkodzi Twoim klientom. Czwarty wskaźnik DORA, Time to Restore Service, analizuje, jak skutecznie możesz zareagować na te zdarzenia.

Podobnie jak w przypadku zmieniających się czasów realizacji, mierzony czas realizacji może się różnić w zależności od organizacji. Niektóre polecenia będą wykorzystywać czas wdrożenia błędu, inne będą pochodzić z pierwszego zgłoszenia klienta, a niektóre mogą wykorzystywać czas wysłania zespołu reagowania na incydenty na stronę. Niezależnie od tego, który punkt wyzwalający wybierzesz, musisz go konsekwentnie używać i mierzyć, aż incydent zostanie oznaczony jako rozwiązany.

Wysoki MTTR to sygnał, że procesy reagowania na incydenty wymagają dopracowania. Skuteczna reakcja zależy od posiadania właściwych osób, które zidentyfikują problem, opracują poprawkę i komunikują się z klientami, których to dotyczy. Możesz skrócić czas odzyskiwania, opracowując spójne procedury reagowania, centralizując dostęp do krytycznych informacji w całej organizacji i wdrażając automatyczne monitorowanie, aby ostrzegać o problemach, gdy tylko się pojawią.

Optymalizacja tego wskaźnika jest często zaniedbywana, ponieważ zbyt wiele zespołów zakłada, że ​​poważna awaria nigdy nie nastąpi. Możesz również mieć stosunkowo niewiele punktów danych do pracy, jeśli Twoja usługa jest ogólnie stabilna. Przeprowadzanie prób reakcji na incydenty przy użyciu metod takich jak testowanie chaosu może dostarczyć bardziej znaczących danych odzwierciedlających aktualny czas odzyskiwania.

Streszczenie

Cztery metryki DORA dostarczają liderom zespołów DevOps dane, które ujawniają możliwości poprawy. Regularne mierzenie i analizowanie częstotliwości wdrażania, czasu wprowadzania zmian, wskaźnika niepowodzeń zmiany i czasu odzyskiwania usług pomoże Ci zrozumieć wydajność i podejmować świadome decyzje o tym, jak ją poprawić.

Metryki DORA można obliczyć ręcznie, korzystając z informacji zawartych w systemie zarządzania projektami. Istnieją również narzędzia, takie jak „ Cztery klucze ” Google Cloud, które automatycznie generują je na podstawie informacji o zatwierdzeniu. Niektóre narzędzia ekosystemowe, takie jak GitLab , również zaczynają obejmować zintegrowane wsparcie.

Najlepsze implementacje DevOps będą zachęcać do szybkich zmian i regularnych wdrożeń, które bardzo rzadko powodują nowe błędy. Wszelkie pojawiające się regresje zostaną szybko rozwiązane, minimalizując przestoje, aby klienci mieli jak najlepsze doświadczenia z Twoją usługą. Śledzenie trendów DORA w czasie pozwala sprawdzić, czy osiągasz te ideały, co daje największe szanse na sukces DevOps.