Co to jest metodyka DevOps?

Ukończone

Kontrakcja "Dev" i "Ops" odnosi się do zastępowania zespołów programistycznych i operacyjnych działających w odizolowanych silosach. Chodzi o tworzenie zespołów wielodyscyplinarnych, które współpracują ze wspólnymi praktykami, narzędziami i odpowiedzialnością za wyniki. Podstawowe rozwiązania DevOps obejmują elastyczne planowanie, ciągłą integrację, ciągłe dostarczanie i kompleksowe monitorowanie aplikacji. Metodyka DevOps to ciągła podróż do poprawy, a nie miejsce docelowe.

Wartość biznesowa metodyki DevOps

Organizacje wdrażające rozwiązania DevOps zwykle widzą mierzalne ulepszenia kluczowych metryk operacyjnych:

  • Częstotliwość wdrażania: zwiększona z rzadko występujących wydań do regularnych, przewidywalnych wdrożeń
  • Czas realizacji: skrócenie od rozszerzonych cykli programowania po krótsze przedziały czasu dostarczania
  • Średni czas odzyskiwania (MTTR): szybsze rozwiązywanie zdarzeń i przywracanie systemu
  • Współczynnik niepowodzeń zmian: mniejsza liczba problemów produkcyjnych z powodu ulepszonego testowania i automatyzacji

Oczekiwane korzyści obejmują:

  • Skrócony czas wprowadzenia na rynek nowych funkcji
  • Zmniejszone zdarzenia związane z wdrażaniem
  • Zwiększona produktywność i zadowolenie deweloperów
  • Niższe koszty operacyjne dzięki automatyzacji

Diagram przedstawiający cykl DevOps z planowaniem, tworzeniem, integracją, wdrażaniem, obsługą i fazami opinii w pętli ciągłej.

Omówienie i obliczanie czasu cyklu

Zacznijmy od podstawowej koncepcji tworzenia oprogramowania przy użyciu pętli OODA (Obserwuj, Orientuj, Decyduj, Działaj). Pierwotnie zaprojektowana, aby chronić pilotów myśliwców przed zestrzeleniem, pętla OODA jest doskonałym narzędziem do wyprzedzania konkurencji w świecie biznesu.

Pętla OODA w praktyce:

  • Obserwowanie: Monitorowanie metryk biznesowych, trendów rynkowych, zachowań użytkowników i danych telemetrycznych
  • Zorientuj się: przeanalizuj opcje dotyczące tego, co możesz dostarczyć, ewentualnie za pomocą eksperymentów.
  • Zdecyduj: określ, co ma być realizowane na podstawie danych i priorytetów biznesowych
  • Działanie: Dostarczanie działającego oprogramowania do rzeczywistych użytkowników i zbieranie opinii

Ćwiczenie dotyczące obliczania czasu cyklu: Pomyśl o bieżącym procesie programowania. Jak długo trwa przechodzenie z:

  • Zatwierdzenie kodu → wdrożenie produkcyjne?
  • Żądanie funkcji → opinie klientów?
  • Raport o usterce → Naprawa w produkcji?

Przykład: Jeśli wprowadzenie jednowierszowej zmiany konfiguracji zajmuje 2 tygodnie, czas cyklu wynosi 2 tygodnie. Staje się to ograniczeniem prędkości.

Diagram przedstawiający cykl pętli OODA z fazami Obserwowanie, Orientacja, Decyzja i Działanie połączone w cykliczny wzorzec, podkreślając ciągłą iterację.

Podejmuj decyzje w oparciu o dane, a nie pod ich wpływem.

Zalecamy używanie danych do informowania o decyzjach w następnym cyklu, ale unikaj sparaliżowania analizy. Doświadczenie wielu organizacji sugeruje, że wdrożenia często mają różne wyniki:

  • Niektóre wdrożenia będą miały negatywne wyniki biznesowe
  • Niektóre wdrożenia będą miały pozytywne wyniki
  • Niektóre wdrożenia nie będą miały mierzalnego wpływu

Kluczowa zasada: Szybko rezygnować z inicjatyw, które nie rozwijają biznesu, i skoncentrować się podwójnie na wynikach, które wspierają cele biznesowe. Takie podejście jest często nazywane "zwrot lub wytrwanie".

Aplikacja praktyczna:

  • Konfigurowanie testowania A/B dla nowych funkcji
  • Definiowanie metryk powodzenia przed wdrożeniem
  • Ustanawianie procedur wycofywania dla eksperymentów, które zakończyły się niepowodzeniem
  • Tworzenie pętli zwrotnej, aby szybko mierzyć wpływ

Dążenie do zweryfikowanych szkoleń

Jak szybko możesz szybko ponieść porażkę lub podwoić wysiłki, zależy od czasu cyklu — jak długo trwa pętla informacji zwrotnej. Opinie, które zbierasz w każdym cyklu, powinny być następujące:

  • Fakty: na podstawie rzeczywistego zachowania użytkownika i metryk systemowych
  • Do zrealizowania: prowadzące do określenia następnych kroków i decyzji
  • Terminowe: dostępne wystarczająco szybko, aby wpłynąć na następną iterację

Takie podejście oparte na dowodach nazywa się zweryfikowanym uczeniem - podejmowanie decyzji na podstawie dowodów empirycznych, a nie założeń lub opinii.

Przykładowe metryki dla zweryfikowanych szkoleń:

  • Współczynniki zaangażowania użytkowników i wdrażanie funkcji
  • Wydajność systemu i współczynniki błędów
  • Oceny zadowolenia klientów i zgłoszenia do wsparcia
  • Wskaźniki KPI biznesowe (przychody, współczynniki konwersji, przechowywanie)

Diagram ilustrujący zweryfikowany cykl uczenia się pokazujący dobre, obojętne i złe wyniki z pętlami sprzężenia zwrotnego dla ciągłego doskonalenia.

Skracanie czasu cyklu

Podczas wdrażania rozwiązań DevOps:

  • Skracasz czas cyklu, pracując w mniejszych partiach.
  • Korzystanie z większej liczby automatyzacji.
  • Utwardzanie potoku wydania.
  • Ulepszanie telemetrii.
  • Częstsze wdrażanie.

Diagram przedstawiający zweryfikowaną naukę a częstotliwość wdrażania. Dobry, obojętny i zły cykl.

Optymalizacja zweryfikowanego uczenia się

Tym częściej wdrażasz, tym więcej można eksperymentować. Im więcej masz okazji do zmian lub wytrwałości, tym więcej zweryfikowanej wiedzy zyskujesz w każdym cyklu. To przyspieszenie w zweryfikowanej nauce jest wartością poprawy. Pomyśl o tym jako o sumie postępów, które osiągasz, i niepowodzeń, których unikasz.

Diagram przedstawiający zweryfikowaną naukę a częstotliwość wdrażania. Dobry, obojętny i zły cykl. Wartość metryki poprawy.