Zastrzeżenie: DevOps jako ruch i dyscyplina ma wiele definicji. Na potrzeby artykułu autor wzoruje się na definicji podanej przez Marca Hornbeeka w książce Engineering DevOps, zapożyczając również różne elementy z innych źródeł np. ITILv4.


Czym są trzy drogi DevOps?

Celem artykułu jest pokazać czytelnikom, że dane koncepty można rozumieć na różne sposoby i podzielić się nimi z innymi praktykami DevOps, by dojść do nowych wniosków.

Spróbujmy spojrzeć na trzy drogi DevOps jako jednocześnie:

  • wysokopoziomowe rozbicie całego procesu wytwórczego oprogramowania na trzy części, występujące po sobie w logicznej sekwencji,
  • wartości oraz różne filozofie stojące za procesem wytwórczym przy użyciu dyscypliny DevOps,
  • konkretne zbiory inżynieryjnych praktyk pomagające w optymalizacji procesu pracy, monitorowaniu, obserwowalności i w końcu na umożliwieniu ciągłych, technicznych eksperymentów pozwalających uzyskać przewagę na rynku.

Spokojnie, to jest tak proste jak się wydaje. Jakbym miał to porównać do sprzętu hardware to pewnie byłaby to lornetka z trzema trybami widzenia – normalny, termowizja, noktowizja – jeden przedmiot, natomiast możemy na niego patrzeć z różnych perspektyw, jak i patrząc przez niego możemy dostrzec inne aspekty tego co obserwujemy.

Żeby obraz był pełniejszy, należy uwzględnić jeszcze trzy główne obszary przez jakie dyscyplina DevOps może być i jest rozwijana – Ludzie/Kultura, Procesy/Praktyki oraz Technologie/Narzędzia.

Teraz rozbijmy na części poszczególne trzy drogi DevOps.

Pierwsza droga DevOps – Flow

Nie od dziś wiadomo, że “Flow is the King”. Wszystko płynie – praca, pieniądze, czas… Jak z tego korzystać, by zwiększać sobie szansę na sukces w biznesie? Tak, by praca płynęła przez system stabilnie, wszelkie spowolnienia były wykrywalne i namierzalne do momentu wystąpienia, tak byśmy w takim wypadku mogli odblokować przepływ pracy przez system.

By prawdziwie czerpać korzyści z ciągłego przepływu powinniśmy odpowiedzieć na pytania:

  • Czy nasz przepływ pracy, pomysłów, usprawnień jest ciągły i niezaburzony od etapu planowania do etapu operacji IT?
  • Czy nasze łańcuchy narzędzi są zdefiniowane pod dany strumień wartości, a rezultaty pracy są deterministyczne i powtarzalne?
  • Czy każdy etap naszego strumienia wartości ma jasno zdefiniowane punkty wejścia i wyjścia, jak i bramki logiczne (gates) a praca jest zdefiniowana i nie wypływa poza te etapy?
  • Czy etapy pracy w naszym łańcuchu narzędzi oraz etapy przejściowe są zautomatyzowane na tyle, by zapobiec tworzeniu się poważniejszych „wąskich gardeł” w systemie?
  • Czy procesy do wykrywania i radzenia sobie z problemami z przepływem pracy przez system są zdefiniowane i egzekwowalne w razie potrzeby?

Druga droga DevOps – Feedback

Wygląda na to, że praca w naszym systemie płynie OK. Czy aby na pewno? Jak zmierzyć niejawne cechy systemu? Które miary, metryki, parametry działania systemu mamy obserwować, by wiedzieć, że są to dane prawdziwe, odwzorowujące stan systemu, a nie dane zatrute, które wprowadzają nas w błąd podczas procesu decyzyjnego. Dla przykładu – większy wolumen akcji, za które mamy płacone, niekoniecznie może być dobry, jeśli przekracza przepustowość sumy naszych mocy przerobowych per jednostka czasu.

Jak czerpać korzyści z ciągłości przepływu informacji zwrotnej w naszym systemie? Sprawdźmy: 

  • Czy wdrożyliśmy praktyki, wytyczne i podejścia 1 Drogi DevOps, w sposób stabilny i zadowalający nasze wymagania?
  • Czy miary typu Service Level Agreements, Service Level Objectives oraz Service Level Indicators są zdefiniowane dla aplikacji, łańcucha narzędzi oraz infrastruktury, na której pracujemy? Miary te pozwalają sprawniej zarządzać procesem wydań i wdrożeń systemów i usług.
  • Czy korzystamy z narzędzi do analizy metryk typu panele kontrolne, gdzie algorytmy odpowiadają za agregowanie danych logów i pośrednich miar w celu produkcji wykresów trendów, które wspierają analizę reaktywną?

Trzecia droga DevOps – Continuous Experimentation & Learning

Potrzebujemy ciągle eksperymentować, uczyć się, robić błędy i wyciągać wnioski. Podlegamy ciągłym zmianom, my, systemy pracy. Zmieniają się ludzie, narzędzia, dynamika rynku, trendy. Jak się w tym odnaleźć?

Kiedy jesteśmy gotowi na wprowadzenie praktyk trzeciej drogi DevOps? Sprawdźmy:

  • Czy praktyki, wytyczne drugiej drogi DevOps są wdrożone stabilnie i zadowalają nasze wymagania?
  • Czy przeprowadzamy regularne retrospektywy naszych wydań i wdrożeń by identyfikować obszary do poprawy? Proces retrospektywy rozumiany jest ogólnie, jako przebadanie tego, co się zdarzyło w sposób, jaki uznamy za zasadny, niekoniecznie jako definicja z ujęcia Scrum z tego czy innego źródła.
  • Czy metryki, miary i wskaźniki są analizowane proaktywnie w celu znalezienia obszarów do poprawy praktyk, wytycznych i podejść z pierwszej i drugiej drogi DevOps?
  • Czy nasza organizacja poszukuje nowych rozwiązań z dyscypliny DevOps, tak wewnętrznie jak i zewnętrznie? Badamy to co się dzieje u nas w firmie, badamy trendy rynkowe?

Oto są 3 Drogi DevOps.

Na tym etapie, Drogi Czytelniku, masz już pewnie pojęcie jak odnieść praktyki, wytyczne i podejścia trzech dróg DevOps do wcześniej wspomnianych 3 obszarów DevOps jakimi są – Ludzie/Kultura, Procesy/Praktyki oraz Technologie/Narzędzia.

Poniżej podam kilka przykładów do inspiracji i szukania usprawnień  “u siebie w firmie”.

Ludzie/Kultura

W ramach pierwszej drogi DevOps warto spojrzeć na to, jak płynie informacja w naszym systemie: czy w ogóle płynie, czy dalej mamy tzw. „silosy kompetencyjne”? Patrząc przez pryzmat drugiej drogi DevOps, spójrzmy jak ludzie z tych „silosów” dogadują się pomiędzy sobą? Czy istnieją „obejścia” procesów dla ułatwienia współpracy, być może ze szkodą dla całego systemu?
Pryzmat trzeciej drogi DevOps wskazuje pytania takie jak to, jakie zmiany planujemy wprowadzić do naszego systemu, które są konieczne, które opcjonalne? Może nowa struktura podziału pracy?

Procesy/Praktyki 

By poprawić Flow należy spytać, czy trzymanie się wytycznych tego czy tamtego zestawu praktyk czy przewodnika ma sens w naszym środowisku i kulturze? Jak badamy dynamikę wymaganej biurokracji do sytuacji w rzeczywistości? Czy nie przesadzamy w jedną czy drugą stronę? Czy forsowanie procesów (à la wydarzenia Scrum) ma sens?

By wzmocnić przepływ informacji zwrotnej spytajmy, na ile słuchamy ludzi, którzy faktycznie wykonują pracę będąc na pierwszej linii frontu lub na zapleczu? Na ile nasz system uwzględnia wymagania wewnętrzne jak i zewnętrzne? Co z PESTLE, czyli czynnikami takimi jak – Political, Economical, Social, Technological, Legal, Environmental? Jak się do tego ustosunkujemy?

W końcu, by umożliwić ciągłe eksperymenty i naukę sprawdźmy, patrząc na powyższe, co z tym w ogóle robimy? Jak chcemy pomnażać naszą wiedzę, własność intelektualną i inne dobra?

Technologie/Narzędzia

Jak spojrzeć na narzędzia i technologię z perspektywy trzech Dróg DevOps? Sprawdźmy, jak narzędzia, z których korzystamy, wspierają proces pracy w naszym strumieniu wartości? Firma istnieje po to, by zarabiać. Jak to wspieramy przez nasze wybory narzędzi i technologii?

A jak narzędzia wspierają przepływ informacji zwrotnej w obie strony? Warto zauważyć, że technologia rozwija się tak szybko, że mało kto jest w stanie za nią nadążyć. Jak obserwować naszą infrastrukturę, łańcuchy narzędzi, środowiska aby uzyskać optimum działania i nie robić wolnych przebiegów, skoro wszystko i tak kosztuje?

Jeśli technologie mają nam umożliwić ciągły rozwój to rozważmy, czy chcemy związać się węzłem małżeńsko-biznesowym z jednym konkretnym dostawcą? Czy wolimy sami sobie złożyć nasze łańcuchy narzędzi wspierające biznes? Może Open Source? Co z bezpieczeństwem?

A to wszystko jest zaledwie początkiem przygody z DevOps. Wiedza kryje się w teorii, praktyce, na konferencjach, rozmowach z praktykami i członkami społeczności DevOps. Do czego też zachęcam Czytelników Strefy PMI.